[Openstack-operators] [openstack-dev] [openstack-operators] [glance] Austin summit summary: Rolling upgrades

[Nikhil Komawar]

Hello everyone,

Just wanted to send a brief summary of the discussions at the summit.
This list is not holistic however, it covers the relevant aspects that
various stakeholders need to be aware of.

  * The intent is that we want operators to be able to upgrade from one
Glance release to the next with minimal (ideally, zero) downtime.

  * Nova's been working on this, so there's a good example of how to
accomplish this. Also, the product working group has a cross-project
spec on this topic.

  * Glance DB is the one component that would require some sophisticated
logic to avoid the downtime. Other services are being handled by
upgrade & swap mechanism.

  * Some discussion was around relative comparison on what other
services are doing:In terms of performance there's simple schemain
Glance thoughcan have massive data.

  *
The different approaches today include: 

  *
oslo versioned objects

  *
neutron: expansion/contraction scheme; expand, lazy updates, force
contract after some time

  *
ironic: not using versioned objects, pinning the version

  *
cinder: split across multiple releases - add table, code can handle both

  * Besides these there was some discussion around best practices for
upgrades: The preferred upgrade scheme is first DB, then registry
and then API.

  * There were some research items: documenting the draining protocol
for Glance nodes handling uploads. Write up alternatives in the spec
based on findings what other projects are achieving; sign-ups
include mclaren for cinder, rosmaita for neutron, nikhil for nova.
More volunteers are welcome.

For more information please reach out to me on #openstack-glance, email,
reply here etc.

-- 

Thanks,
Nikhil


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] New working group: [fault genes]. Recap from Austin from "Taxonomy of Failure" Ops session and plans going forward as a working group

[Nematollah Bidokhti]

Hi,

This email is a recap from our OpenStack summit meeting "Taxonomy of Failure" 
in Austin. The purpose of this email is to provide a summary of the meeting and 
future plans.

We had between 55-60 people participating in our session and received a number 
of comments and suggestions. Basically all comments were positive and felt we 
are going in a right direction.

The goal is to look at OpenStack resiliency in holistic fashion by identifying 
all possible failure modes (either experienced to date or based on design 
implementation), classifying them, defining the ideal mitigation strategy, how 
should they be reported and how they can be re-created with the OpenStack 
version in mind. The results of this effort will be used throughout OpenStack 
lifecycle (design, development, test, deployment).

After our meeting I met with a lot of companies in the market place and 
received lots of encouragement to complete the effort that we have started. 
There were 20 companies that I met with and all expressed their interest to 
support this activity. As a result, we have decided to start a working group 
"Fault Genes" to focus on all OpenStack failure modes.

The plan is to start with email communications and filling out our Google Sheet 
template 
(https://docs.google.com/spreadsheets/d/1sekKLp7C8lsTh-niPHNa2QLk5kzEC_2w_UsG6ifC-Pw/edit#gid=2142834673)
 that we have set up, start out with a weekly meeting, adjusting as the group 
sees fit and in 3 months have a check point on what we have accomplished. Then, 
we should have a picture of what we have accomplished, where this will go and 
have information to present at OpenStack in Barcelona. Below is the link to the 
etherpad:

https://etherpad.openstack.org/p/AUS-ops-Taxonomy-of-Failures

For those who were in the meeting or discussed this at the summit, and  you 
understand spreadsheet, please take time and fill in the spreadsheet with the 
failure modes that you have experienced so far and related attributes for each 
failure mode.

I'll schedule a meeting to get those who weren't at the summit informed of the 
process and how to use the spreadsheet.

Suggestions of meeting times, or further discussion here is appreciated and 
appropriate.

My availability for meetings is:  1600-2359 UTC

Please use this link http://doodle.com/poll/8ymwuqva7itv84p8 to provide your 
suggested time.

Thanks,

Nemat Bidokhti
Chief Reliability Architect
IT Product Line, Computing 
Lab
Futurewei Technologies, Inc.
HUAWEI R&D USA
Tel: +1-408-330-4714
Cell:   +1-408-528-4909
Fax:+1-408-330-5088
E-mail: 
nematollah.bidok...@huawei.com
2330 Central Expressway 
Santa Clara, CA 95050
http://www.huawei.com
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Nova cells patches against Liberty

[Sam Morrison]

Hi Mike,

I’ve also been working on these and have some updated patches at:

https://github.com/NeCTAR-RC/nova/commits/stable/liberty-cellsv1

There are a couple of patches that you have in your tree that need updating for 
Liberty. Mainly around supporting the v2.1 API and more things moved to 
objects. I have also written some tests for some more of them too. I haven’t 
tested all of these functionally yet but they pass all tox tests.

Cheers,
Sam



> On 5 May 2016, at 4:19 AM, Mike Dorman  wrote:
> 
> I went ahead and pulled out the Nova cells patches we’re running against 
> Liberty so that others can use them if so desired.
> 
> https://github.com/godaddy/openstack-nova-patches 
> 
> 
> Usual disclaimers apply here, your mileage may vary, these may not work as 
> expected in your environment, etc.  We have tested these at a basic level 
> (unit tests), but are not running these for Liberty in real production yet.
> 
> Mike
> 
> 
> 
> 
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [app-catalog] App Catalog IRC meeting Thursday May 5th

[Christopher Aedo]

Join us Thursday for our weekly meeting, scheduled for May 5th at
17:00UTC in #openstack-meeting-3

The agenda can be found here, and please add to if you want to get
something on the agenda:
https://wiki.openstack.org/wiki/Meetings/app-catalog

Looking forward to seeing you there tomorrow!

-Christopher

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] Nova cells patches against Liberty

[Mike Dorman]

I went ahead and pulled out the Nova cells patches we’re running against 
Liberty so that others can use them if so desired.

https://github.com/godaddy/openstack-nova-patches

Usual disclaimers apply here, your mileage may vary, these may not work as 
expected in your environment, etc.  We have tested these at a basic level (unit 
tests), but are not running these for Liberty in real production yet.

Mike




___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] User Survey usage of QEMU (as opposed to KVM) ?

[Daniel P. Berrange]

On Tue, May 03, 2016 at 07:06:56PM +, Jared Wilkinson wrote:
> So forgive my lack of kvm/qemu knowledge but I couldn’t find anything
> on Google on this. If you deployed an instance of a different architecture
> than the physical CPU, wouldn’t qemu just emulate the processor (if you
> were in virt_type=kvm) mode, or would libvirt throw some error?

You would get an error from libvirt because KVM will only work if the
host and guest arches match

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] User Survey usage of QEMU (as opposed to KVM) ?

[Daniel P. Berrange]

On Tue, May 03, 2016 at 10:20:34PM +0300, Maish Saidel-Keesing wrote:
> I would think that the problem is that OpenStack does not really report
> back that you are using KVM - it reports that you are using QEMU.
> 
> Even when in nova.conf I have configured virt_type=kvm, when I run nova
> hypervisor-show XXX | grep hypervisor_type
> 
> I am presented with the following
> 
> | hypervisor_type   | QEMU
> 
> Bug?

Ah that's interesting - its certainly something that would be misleading
to operators.  It seems it is reporting the libvirt driver name, rather
than the actual hypervisor type. It'd be nice to fix it, but I'n not sure
if we can do so without creating upgrade incompatibility if people have
scheduler filters depending on that value :-(


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators