[openstack-dev] [nova] FYI: Removing default flavors from nova

Fox, Kevin M Kevin.Fox at pnnl.gov
Wed Apr 6 18:50:59 UTC 2016


Ive treated m1 flavors as an abstraction layer for flavours. I create other flavors that match various other things, but leave the m1's around as a target for generic, "I need about x size" things. I tweak them slightly to match up with the compute nodes closer but never shrink them past what the default is, so they should work generically. There's no reason flavors can't be used that way, and provide some uniformity across clouds.

My point is, app developers aren't because its too hard. :/

Without stuff like instance users to deal with https certificate storage and other important missing features, the generic app developer use case for anything non trivial just can't be handled today. So they tend to only exist on individual clouds.

We've seen that in the app catalog by not seeing many contributions. Its just too hard to write things generically enough to contribute. This is detrimental to OpenStack and really needs to be fixed, or other technology will come in to replace it.

Thanks,
Kevin
________________________________________
From: Christopher Aedo [doc at aedo.net]
Sent: Wednesday, April 06, 2016 11:24 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova] FYI: Removing default flavors from nova

On Wed, Apr 6, 2016 at 9:29 AM, Fox, Kevin M <Kevin.Fox at pnnl.gov> wrote:
> It feels kind of like a defcore issue though. Its harder for app developers to create stuff like heat templates intended for cross cloud that recommend a size, m1.small, without a common reference.

For most deployments thought, the flavor definition is a function of
their compute node design.  Trying to standardize (and force that
standard via defcore) would likely drive away the biggest consumers of
OpenStack.

In my opinion this just shines a light on something missing from heat
(or maybes it exists and I'm just unaware) - the ability to discover
flavor details and find one that matches the minimum should be all
that's necessary in this case.  I think in general though, choosing
heat as a cross-cloud compatible application packaging tool is always
going to lead to problems.  Otherwise I think we would have seen an
emergence of people sharing heat templates that deploy applications
and work across many different OpenStack clouds.

> We keep making it hard for app developers to target openstack, so they don't join, and then don't complain about when openstack makes their life harder. we need to encourage ease of development on top of the platform.

I absolutely feel this pain point, but I'm still wondering what
applications people *are* developing for OpenStack (and how they're
packaging and distributing them - opinions welcome![1])

[1]: http://lists.openstack.org/pipermail/user-committee/2016-April/000722.html

-Christopher

>
> Thanks,
> Kevin
> ________________________________________
> From: Sean Dague [sean at dague.net]
> Sent: Wednesday, April 06, 2016 3:47 AM
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [nova] FYI: Removing default flavors from nova
>
> On 04/06/2016 04:19 AM, Sylvain Bauza wrote:
>>
>>
>> Le 06/04/2016 06:44, Qiming Teng a écrit :
>>> Not an expert of Nova but I am really shocked by such a change. Because
>>> I'm not a Nova expert, I don't have a say on the *huge* efforts in
>>> maintaining some builtin/default flavors. As a user I don't care where
>>> the data have been stored, but I do care that they are gone. They are
>>> gone because they **WILL** be supported by devstack. They are gone with
>>> the workflow +1'ed **BEFORE** the devstack patch gets merged (many
>>> thanks to the depends-on tag). They are gone in hope that all deployment
>>> tools will know this when they fail, or fortunately they read this email,
>>> or they were reviewing nova patches.
>>>
>>> It would be a little nicer to initiate a discussion on the mailinglist
>>> before such a change is introduced.
>>
>>
>> It was communicated accordingly to operators with no strong arguments :
>> http://lists.openstack.org/pipermail/openstack-operators/2016-March/010045.html
>
> Not only with no strong arguments, but with a general - "yes please,
> that simplifies our life".
>
>> You can also see that https://review.openstack.org/#/c/300127/ is having
>> three items :
>>  - a DocImpact tag creating a Launchpad bug for documentation about that
>>  - a reno file meaning that our release notes will provide also some
>> comments about that
>>  - a Depends-On tag (like you said) on a devstack change meaning that
>> people using devstack won't see a modified behavior.
>>
>> Not sure what you need more.
>
> The default flavors were originally hardcoded in Nova (in the initial
> commit) -
> https://github.com/openstack/nova/commit/bf6e6e718cdc7488e2da87b21e258ccc065fe499#diff-5ca8c06795ef481818ea1710fce91800R64
>  and moved into the db 5 years ago to be a copy of the EC2 flavors at
> the time -
> https://github.com/openstack/nova/commit/563a77fd4aa80da9bddac5cf7f8f27ed2dedb39d.
> Those flavors were meant to be examples, not the final story.
>
> All the public clouds delete these and do their own thing, as do I
> expect many of the products. Any assumption that software or users have
> that these will exist is a bad assumption.
>
> It is a big change, which is why it's being communicated on Mailing
> Lists in addition to in the release notes so that people have time to
> make any of their tooling not assume these flavors by name will be
> there, or to inject them yourself if you are sure you need them (as was
> done in the devstack case).
>
>         -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __________________________________________________________________________
> 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

__________________________________________________________________________
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



More information about the OpenStack-dev mailing list