Open Stack

On 07/16/2013 03:30 PM, Nachi Ueno wrote:
> Hi Jay
>
> I agree for that usecase is needed.
> # But some users wan't to setup their own networks, so this case
> usecase will be also exists.
>
> This function needes keystone notification bp (and it looks targeted for H3).
> https://blueprints.launchpad.net/keystone/+spec/notifications
>
> I'm not sure this kind of function should be in Neutron or not.
> IMO, if there is some kind of orchestrator, it is best.

I don't think you understand the use case :) Let me explain.

Previously, when a user launched an instance in Folsom (without Quantum, 
using nova-network), the user did not need to specify a network manually 
when launching their instance. If a network was available -- i.e. it was 
not in use by another tenant -- then *during the instance launch*, that 
network was assigned to be used by the tenant, and their instances would 
automatically receive an IP address in that network.

Previously, if the user wanted to specify a particular network when 
launching an instance, they could certainly do so. However, this was not 
*required* -- as noted above, an available network would automatically 
be assigned the tenant if one was available.

In the current Nova <--> Quantum interaction, that default behaviour of 
automatically assigning a tenant to an available network is now gone, 
and I believe it is a mistake that this was allowed to happen.

This doesn't have anything to do with Keystone. This has to do with the 
decision by the Quantum development team to:

* Force networks to have a tenant ID [1]
* Force subnets to have a tenant ID [2]

If Quantum allowed for multiple networks to be created without a tenant 
ID -- as was the case in Nova with nova-network -- then during the 
process of launching an instance, if the user did NOT specify a network 
then Nova could call out to Quantum to get the first available network. 
But since the decision was made to enforce tenant ID being not null in 
the Quantum network API (not the database model, which allows a NULL 
tenant ID), that is not possible anymore.

And I think the user experience suffers because of that.

Note that the use case of specifying a network on instance creation was 
and still is supported by Nova with nova-network. This conversation has 
strictly been about the removal of the auto-assignment behaviour.

Best,
-jay

[1] 
https://github.com/openstack/neutron/blob/master/neutron/api/v2/attributes.py#L533
[2] 
https://github.com/openstack/neutron/blob/master/neutron/api/v2/attributes.py#L625

> 2013/7/16 Jay Pipes <jaypipes at gmail.com>:
>> On 07/16/2013 02:03 PM, Nachi Ueno wrote:
>>>
>>> Hi Jay
>>>
>>> It is not supported now, and there is no bp proposed to do that.
>>> It can be done via API (CLI), so we can write a script for tenant setup.
>>
>>
>> Hi Nachi,
>>
>> IMO, this is a step backwards and a deficiency. Basically, the user
>> interface was needlessly made more complicated for the tenant. Instead of
>> just launching their instance, the tenant now needs to create a subnet and
>> then launch their instance, passing the subnet ID in the nova boot command.
>>
>> -jay
>>
>>
>>> 2013/7/16 Jay Pipes <jaypipes at gmail.com>:
>>>>
>>>> The way that folsom and nova + nova-network works is that you create a
>>>> bunch
>>>> of unassigned (no tenant assigned to the networks) networks and when a
>>>> tenant first launches an instance, nova grabs an available network for
>>>> the
>>>> tenant and assigns it to the tenant. Then each instance the tenant spins
>>>> up
>>>> after that gets an IP in the specific network it was assigned.
>>>>
>>>> How can I do the same thing with Neutron? I don't want my tenants or an
>>>> admin to have to manually create a network in Neutron every time a tenant
>>>> is
>>>> added.
>>>>
>>>> Thanks,
>>>> -jay
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>
>>
>> _______________________________________________
>> 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
>