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 <enikano...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
