Hi Salvatore, Thanks for the reply. 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.
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? 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? Appreciate your suggestions. Thanks, -Ravi. On Wed, Jul 31, 2013 at 11:18 AM, Salvatore Orlando <[email protected]>wrote: > Providing this capability in Neutron won't be hard. > As discussed previously in this thread this operation can be achieved > using a sequence of Neutron API calls. > The sequence would be pretty much the following: > 1) verify network is associated with router, and router has external > gateway configured > 2) create port > 3) allocate floating IP > 4) associate floating IP with port > > You can surely implement it directly in Neutron - and there's no strong > opposition fromme. > 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. > > The argument for building this capability directly in neutron would be to > reduce the amount of API calls needed to achieve this goal. > 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. > > Salvatore > > > > On 31 July 2013 19:41, Ravi Chunduru <[email protected]> wrote: > >> The blueprint proposed to assign auto floating IP during port creation. >> Since auto floating IP is supported in nova-network, +1 to implement the >> same in Neutron. >> >> Salvatore, >> Can you share with us the concerns in implementing in Neutron? >> >> Thanks, >> -Ravi. >> >> >> >> >> >> >> On Wed, Jul 31, 2013 at 12:57 AM, Salvatore Orlando >> <[email protected]>wrote: >> >>> Hi Ofer, >>> >>> 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. >>> 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. >>> >>> 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. >>> 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. >>> >>> 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. >>> I reckon this blueprint should be implemented there performing the >>> operations listed above. >>> >>> Salvatore >>> >>> >>> On 28 July 2013 16:16, Ofer Blaut <[email protected]> wrote: >>> >>>> Hi >>>> >>>> Hi, I am interested in helping out with QE efforts on upstream >>>> OpenStack, specifically around Neutron. >>>> >>>> I'm trying to understand the following blueprint,can you please point >>>> me to more detailed design >>>> >>>> >>>> https://blueprints.launchpad.net/neutron/+spec/auto-associate-floating-ip >>>> >>>> >>>> Thanks >>>> >>>> Ofer Blaut >>>> >>>> >>>> _______________________________________________ >>>> OpenStack-dev mailing list >>>> [email protected] >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>> >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> [email protected] >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> >> -- >> Ravi >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Ravi
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
