Open Stack

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140716/796d0952/attachment.html>