Open Stack

On 06/04/16 19:28, "Fox, Kevin M" <Kevin.Fox at pnnl.gov> wrote:

>+1
>________________________________________
>From: Neil Jerram [Neil.Jerram at metaswitch.com]
>Sent: Wednesday, April 06, 2016 10:15 AM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [nova] [all] FYI: Removing default flavors from nova
>
>I hesitate to write this, even now, but I do think that OpenStack has a
>problem with casual incompatibilities, such as this appears to be.  But,
>frankly, I've been slapped down for expressing my opinion in the past
>(on the pointless 'tenant' to 'project' change), so I just quietly
>despaired when I saw that ops thread, rather than saying anything.
>
>I haven't researched this particular case in detail, so I could be
>misunderstanding its implications.  But in general my impression, from
>the conversations that occur when these topics are raised, is that many
>prominent OpenStack developers do not care enough about
>release-to-release compatibility.  The rule for incompatible changes
>should be "Just Don't", and I believe that if everyone internalized
>that, they could easily find alternative approaches without breaking
>compatibility.
>
>When an incompatible change like this is made, imagine the 1000s of
>operators and users around the world, with complex automation around
>OpenStack, who see their deployment or testing failing, spend a couple
>of hours debugging, and eventually discover 'oh, they removed m1.small'
>or 'oh, they changed the glance command line'.  Given that hassle and
>bad feeling, is the benefit that developers get from the incompatibility
>still worth it?

I have rarely seen the operator community so in agreement as on this change impact.
Over the past 4 years, there have been lots of changes which were debated
with major impacts on end users (EC2, nova-network, …). However, I do not believe 
that this is one of those:

This change

- does not break existing clouds
- has a simple 5 line shell script to cover the new cloud install and can
be applied before opening the cloud to the end users
- raises a fundamental compatibility question to be solved by the community

What I’d like to replace it is a generic query along the lines of

give me a flavor with X GB RAM, Y cores, Z system disk and the metadata flags so I
get a GCPU and ideally huge pages

There is a major difference from option dropped or major functionality deprecated
as I can hide it from my end users with a few flavor definitions which make sense 
for my cloud.

Incompatible changes for existing production deployments, e.g. CLIs,  should be handled very
carefully. Cleaning up some past choices for new clouds with appropriate documentation
and workarounds to keep the old behaviour seems reasonable.

>
>I would guess there are many others like me, who generally don't say
>anything because they've already observed that the prevailing sentiment
>is not sufficiently on the side of compatibility.

We have a production cloud with 2,200 users who feel the pain of incompatible change (and
pass that on to the support teams :-) I feel there is a strong distinction between 
incompatible change (i.e. you cannot hide this from your end users) vs change with a workaround
(where you can do some work for some projects to emulate the prior environment, but new projects
can be working with the future only, not accidentally selecting the legacy options).

I do feel that people should be able raise their concerns, each environment is different and
there is no single scenario. Thus, a debate, such as this one, is valuable to find the balance
between the need to move forward versus the risks. 

Tim

>
>        Neil
>
>
>__________________________________________________________________________
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>__________________________________________________________________________
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev