<div dir="ltr">I think I've provided some examples in the review.<div><br></div><div>However, the point is mostly to simplify usage from a user perspective - allowing consumers of the neutron API to use the same flavour object for multiple services.</div>
<div>There are other considerations which could be made, but since they're dependent on features which do not yet exist (NFV, service insertion, chaining and steering) I think there is no point in arguing over it.<br>
</div><div><br></div><div>In conclusion I think the idea makes sense, and is a minor twist in the current design which should not either make the feature too complex neither prevent any other use case for which the flavours are being conceived. For the very same reason however, it is worth noting that this is surely not an aspect which will cause me or somebody else to put a veto on this work item.</div>
<div><br></div><div>Another aspect to consider is how the flavours will work when the advanced service type they refer to is not consumable through the neutron API, which would be the case with an independent load balancing API endpoint. But this is probably another story.</div>
<div><br></div><div>Salvatore</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 15 July 2014 21:21, 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>