<div dir="ltr">Geoff<div><br></div><div>I noticed the following two blueprints:</div><div><p style="margin:0in;font-family:Calibri;font-size:11pt"><br></p><p style="margin:0in;font-family:Calibri;font-size:11pt"><a href="https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms">https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms</a></p>
<p style="margin:0in;font-family:Calibri;font-size:11pt"><span style="color:rgb(51,51,51);font-family:sans-serif;font-size:12px;line-height:18px"><br></span></p><p style="margin:0in;font-family:Calibri;font-size:11pt"><span style="color:rgb(51,51,51);font-family:sans-serif;font-size:12px;line-height:18px">This blueprint defines a framework for creating, managing and deploying Neutron advanced services implemented as virtual machines. The goal is to enable advanced network services (e.g. Load Balancing, Security, Monitoring) that may be supplied by third party vendors, are deployed as virtual machines, and are launched and inserted into the tenant network on demand.</span><span style="color:rgb(51,51,51);font-family:sans-serif;font-size:12px;line-height:18px"><br>
</span></p><div><br></div>
<p style="margin:0in;font-family:Calibri;font-size:11pt"><a href="https://blueprints.launchpad.net/neutron/+spec/dynamic-network-resource-mgmt">https://blueprints.launchpad.net/neutron/+spec/dynamic-network-resource-mgmt</a></p>
<p style="margin:0in;font-family:Calibri;font-size:11pt"><br></p><p style="margin:0in;font-family:Calibri;font-size:11pt"><span style="color:rgb(51,51,51);font-family:sans-serif;font-size:12px;line-height:18px">This blueprint proposes the addition to OpenStack of a framework for dynamic network resource management (DNRM). This framework includes a new OpenStack resource management and provisioning service, a refactored scheme for Neutron API extensions, a policy-based resource allocation system, and dynamic mapping of resources to plugins. It is intended to address a number of use cases, including multivendor environments, policy-based resource scheduling, and virtual appliance provisioning. We are proposing this as a single blueprint in order to create an efficiently integrated implementation.</span><br>
</p><p style="margin:0in;font-family:Calibri;font-size:11pt"><span style="color:rgb(51,51,51);font-family:sans-serif;font-size:12px;line-height:18px"><br></span></p><p style="margin:0in;font-family:Calibri;font-size:11pt">
the latter was submitted by you. This sounds like step in the right direction and I would like to understand the designs/scope/limitation in a little more details.<span style="color:rgb(51,51,51);font-family:sans-serif;font-size:12px;line-height:18px"><br>
</span></p><p style="margin:0in;font-family:Calibri;font-size:11pt"><br></p><p style="margin:0in;font-family:Calibri;font-size:11pt">What is the status of your blueprint? Any early designs/use cases that you would be willing to share?</p>
<p style="margin:0in;font-family:Calibri;font-size:11pt"><br></p><p style="margin:0in;font-family:Calibri;font-size:11pt">Regards Susanne</p><p style="margin:0in;font-family:Calibri;font-size:11pt"><br></p></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Tue, Mar 25, 2014 at 10:07 AM, Geoff Arnold <span dir="ltr"><<a href="mailto:geoff@geoffarnold.com" target="_blank">geoff@geoffarnold.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="auto"><div>There are (at least) two ways of expressing differentiation:</div><div>- through an API extension, visible to the tenant</div><div>- though an internal policy mechanism, with specific policies inferred from tenant or network characteristics</div>
<div><br></div><div>Both have their place. Please don't fall into the trap of thinking that differentiation requires API extension. <br><br>Sent from my iPhone - please excuse any typos or "creative" spelling corrections! </div>
<div><div class="h5"><div><br>On Mar 25, 2014, at 1:36 PM, Eugene Nikanorov <<a href="mailto:enikanorov@mirantis.com" target="_blank">enikanorov@mirantis.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">
Hi John,<div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Mar 25, 2014 at 7:26 AM, John Dewey <span dir="ltr"><<a href="mailto:john@dewey.ws" target="_blank">john@dewey.ws</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
I have a similar concern. The underlying driver may support different functionality, but the differentiators need exposed through the top level API.</div></blockquote><div>Not really, whole point of the service is to abstract the user from specifics of backend implementation. So for any feature there is a common API, not specific to any implementation.</div>
<div><br></div><div>There probably could be some exception to this guide line that lays in the area of admin API, but that's yet to be discussed.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br></div><div>I see the SSL work is well underway, and I am in the process of defining L7 scripting requirements. However, I will definitely need L7 scripting prior to the API being defined.</div><div>Is this where vendor extensions come into play? I kinda like the route the Ironic guy safe taking with a “vendor passthru” API. </div>
</blockquote><div>I may say that core team has rejected 'vendor extensions' idea due to potential non-uniform user API experience. That becomes even worse with flavors introduced, because users don't know what vendor is backing up the service they have created.</div>
<div><br></div><div>Thanks,</div><div>Eugene.</div></div><br></div></div>
</div></blockquote></div></div><div class=""><blockquote type="cite"><div><span>_______________________________________________</span><br><span>OpenStack-dev mailing list</span><br><span><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a></span><br>
<span><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></span><br></div></blockquote></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>