[openstack-dev] [Neutron] Flavor framework proposal

Sumit Naiksatam sumitnaiksatam at gmail.com
Wed Jul 16 15:25:08 UTC 2014


To the earlier question on whether we had defined what we wanted to
solve with the flavors framework, a high level requirement was
captured in the following approved spec for advanced services:
https://review.openstack.org/#/c/92200

On Wed, Jul 16, 2014 at 5:18 AM, Eugene Nikanorov
<enikanorov at mirantis.com> wrote:
> Some comments inline:
>
>>
>> Agreed-- I think we need to more fully flesh out how extension list / tags
>> should work here before we implement it. But this doesn't prevent us from
>> rolling forward with a "version 1" of flavors so that we can start to use
>> some of the benefits of having flavors (like the ability to use multiple
>> service profiles with a single driver/provider, or multiple service profiles
>> for a single kind of service).
>
> Agree here.
>
>>
>>
>> Yes, I think there are many benefits we can get out of the flavor
>> framework without having to have an extensions list / tags at this revision.
>> But I'm curious: Did we ever define what we were actually trying to solve
>> with flavors?  Maybe that's the reason the discussion on this has been all
>> of the place: People are probably making assumptions about the problem we're
>> trying to solve and we need to get on the same page about this.
>
>
> Yes, we did!
>  The original problem has several aspects aspects:
> 1) providing users with some information about what service implementation
> they get (capabilities)
> 2) providing users with ability to specify (choose, actually) some
> implementation details that don't relate to a logical configuration
> (capacity, insertion mode, HA mode, resiliency, security standards, etc)
> 3) providing operators a way to setup different modes of one driver
> 4) providing operators to seamlessly change drivers backing up existing
> logical configurations (now it's not so easy to do because logical config is
> tightly coupled with provider/driver)
>
> The proposal we're discussing right is mostly covering points (2), (3) and
> (4) which is already a good thing.
> So for now I'd propose to put 'information about service implementation' in
> the description to cover (1)
>
> I'm currently implementing the proposal (API and DB parts, no integration
> with services yet)
>
>
> Thanks,
> Eugene.
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



More information about the OpenStack-dev mailing list