<div dir="ltr">Hi Stephen,<div><br></div><div>So, as was discussed, existing proposal has some aspects which better to be postponed, like extension list on the flavor (instead of tags). </div><div>Particularly that idea has several drawbacks:</div>
<div> - it makes public API inflexible</div><div> - turning features on/off is not what flavors should be doing, it's a task for policy framework and not flavors</div><div> - flavor-based rest call dispatching is quite complex solution giving no benefits for service plugins</div>
<div>While this is not explicitly written in proposal - that's what implied there.</div><div>I think that one is a major blocker of the proposal right now, it deserves future discussion and not essential to the problem flavors are supposed to solve.</div>
<div>Other than that, I personally don't have much disagreements on the proposal.</div><div><br></div><div>The question about service type on the flavor is minor IMO. We can allow it to be NULL, which would mean multiservice flavor.</div>
<div>However, multiservice flavors may put some minor requirements to driver API (that's mainly because of how flavor plugin interacts with service plugins)</div><div><br></div><div>Thanks,</div><div>Eugene.</div></div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jul 15, 2014 at 11:21 PM, Stephen Balukoff <span dir="ltr"><<a href="mailto:sbalukoff@bluebox.net" target="_blank">sbalukoff@bluebox.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi folks!<div><br></div><div>I've noticed progress on the flavor framework discussion slowing down over the last week. We would really like to see this happen for Juno because it's critical for many of the features we'd also like to get into Juno for LBaaS. I understand there are other Neutron extensions which will need it too.</div>

<div><br></div><div>The proposal under discussion is here:</div><div><br></div><div><a href="https://review.openstack.org/#/c/102723/" target="_blank">https://review.openstack.org/#/c/102723/</a><br></div><div><br></div>
<div>One of the things I've seen come up frequently in the comments is the idea that a single flavor would apply to more than one service type (service type being 'LBaaS', 'FWaaS', 'VPNaaS', etc.). I've commented extensively on this, and my opinion is that this doesn't make a whole lot of sense.  However, there are people who have a different view on this, so I would love to hear from them:</div>

<div><br></div><div><span style="color:rgb(0,0,0);font-family:sans-serif">Could you describe a specific usage scenario where this makes sense? What are the characteristics of a flavor that applies to more than one service type?</span><br>

</div><div><br></div><div>Let's see if we can come to some conclusions on this so that we can get flavors into Juno, please!</div><div><br></div><div>Thanks,</div><div>Stephen<span class="HOEnZb"><font color="#888888"><br clear="all">
<div><br></div>-- <br><span></span>Stephen Balukoff
<br>Blue Box Group, LLC
<br>(800)613-4305 x807

</font></span></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>