Hi Salvatore,<div> Thanks for the reply.</div><div>Currently in our deployments, we do have an Orchestrated implementation using neutron API calls in nova to assign Floating IP to the VM port. As you rightly said, there are numerous API calls to Neutron involved. Hence wanted to move to Neutron.</div>
<div><br></div><div>One use case which is making us think is the ability to provide this floating IP assignment per tenant's choice. Currently the blueprint suggests global option. Any suggestion on overriding this option per tenant basis?</div>
<div><br></div><div>One way is to leave this choice to the deployment. If a tenant does not want Floating IP assigned to his instances must not associate the subnet to the router which has external network attached. This way no need to change in API specs. Will that be good enough?</div>
<div><br></div><div>Appreciate your suggestions.</div><div><br></div><div>Thanks,</div><div>-Ravi.</div><div><br></div><div><br><div class="gmail_quote">On Wed, Jul 31, 2013 at 11:18 AM, Salvatore Orlando <span dir="ltr"><<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.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="ltr">Providing this capability in Neutron won't be hard.<div>As discussed previously in this thread this operation can be achieved using a sequence of Neutron API calls.</div>
<div>The sequence would be pretty much the following:</div>
<div>1) verify network is associated with router, and router has external gateway configured<br></div><div>2) create port</div><div>3) allocate floating IP<br></div><div>4) associate floating IP with port</div><div><br></div>
<div>You can surely implement it directly in Neutron - and there's no strong opposition fromme.</div><div>From an architectural perspective, Neutron exposes an API for 'atomic' operations. Composite, or orchestrated, operations, are better delegated to an appropriate service, which, in this case, if the nova.network.neutronv2.api module.</div>
<div><br></div><div>The argument for building this capability directly in neutron would be to reduce the amount of API calls needed to achieve this goal.</div><div>If you want to proceed with implementing it directly in neutron, don't mind my opinion. I am just a grumpy guy who loves to moan about pretty much everything.<span class="HOEnZb"><font color="#888888"><br>
</font></span></div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Salvatore</div><div><br></div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">
On 31 July 2013 19:41, Ravi Chunduru <span dir="ltr"><<a href="mailto:ravivsn@gmail.com" target="_blank">ravivsn@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The blueprint proposed to assign auto floating IP during port creation. <div>Since auto floating IP is supported in nova-network, +1 to implement the same in Neutron.</div>
<div><br></div><div>Salvatore,</div><div> Can you share with us the concerns in implementing in Neutron?</div>
<div><br></div><div>Thanks,</div><div>-Ravi.<br><div><br></div><div><br><div><br></div><div><br><div><div><div><br><br><div class="gmail_quote">On Wed, Jul 31, 2013 at 12:57 AM, Salvatore Orlando <span dir="ltr"><<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.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="ltr">Hi Ofer,<div><br></div><div>Basically this operation consists in ensuring that an instance, when it's booted, is also associated with a floating IP address, and therefore publicly accessible.</div>
<div>I discussed this topic a couple months ago with another developer, but I am now unable to find the chat in the openstack-dev IRC logs.</div>
<div><br></div><div>The bottom line is that even if this is registered as a neutron blueprint, we are not really sure Neutron is the right place to perform orchestration operation.</div><div>And this operation falls into this category - since it involves, creating a port, ensuring the network for that port is associated with a router, allocating a floating IP, and associating it with the port.</div>
<div><br></div><div>Currently all the orchestration operations are performed in the module which configures instances networking, which is part of nova. This module (nova.network.quantumv2.api) uses the quantum API.</div>
<div>I reckon this blueprint should be implemented there performing the operations listed above.</div><span><font color="#888888"><div><br></div><div>Salvatore</div></font></span></div><div>
<div><div class="gmail_extra"><br><br><div class="gmail_quote">On 28 July 2013 16:16, Ofer Blaut <span dir="ltr"><<a href="mailto:oblaut@redhat.com" target="_blank">oblaut@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi<br>
<br>
Hi, I am interested in helping out with QE efforts on upstream<br>
OpenStack, specifically around Neutron.<br>
<br>
I'm trying to understand the following blueprint,can you please point me to more detailed design<br>
<br>
<a href="https://blueprints.launchpad.net/neutron/+spec/auto-associate-floating-ip" target="_blank">https://blueprints.launchpad.net/neutron/+spec/auto-associate-floating-ip</a><br>
<br>
<br>
Thanks<br>
<br>
Ofer Blaut<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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>
</blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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><br clear="all"><div><br></div></div></div><span><font color="#888888">-- <br>Ravi<br>
</font></span></div></div></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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>
</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><br clear="all"><div><br></div>-- <br>Ravi<br>
</div>