<div dir="ltr">Some comments inline:<br><div class="gmail_extra"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div dir="ltr"><div><div><div class="gmail_extra"><div class="gmail_quote"><div><div><br></div></div><div><div>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).</div>

</div></div></div></div></div></div></blockquote><div>Agree here.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div dir="ltr"><div><div><div class="gmail_extra"><div class="gmail_quote"><div><div>
<div><br></div></div><div>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.</div>

</div></div></div></div></div></div></blockquote><div> </div><div>Yes, we did!</div><div> The original problem has several aspects aspects: </div><div>1) providing users with some information about what service implementation they get (capabilities)</div>

<div>2) providing users with ability to specify (choose, actually) some implementation details that don't relate to a logical configuration</div><div>(capacity, insertion mode, HA mode, resiliency, security standards, etc)</div>

<div>3) providing operators a way to setup different modes of one driver</div><div>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)</div>

<div><br></div><div>The proposal we're discussing right is mostly covering points (2), (3) and (4) which is already a good thing.</div><div>So for now I'd propose to put 'information about service implementation' in the description to cover (1)</div>

<div><br></div><div>I'm currently implementing the proposal (API and DB parts, no integration with services yet)</div><div><br></div><div><br></div><div>Thanks,</div><div>Eugene.</div></div></div></div>