Open Stack

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 <sorlando at nicira.com>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 <ravivsn at gmail.com> 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 <sorlando at nicira.com>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 <oblaut at redhat.com> 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
>>>> OpenStack-dev at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>> Ravi
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Ravi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130731/969285f0/attachment.html>