Open Stack

On 07/16/2013 05:14 PM, Nachi Ueno wrote:
> Hi Jay
>
> IMO, you are mixing 'What' and "How".
> This is my understandings.
>
> "What is needed (Requirement)"
>      [Requirement1]  Network and Subnet will be assigned for new tenant
> automatically
>        by the configuration
>
> "How to do it (Implementation)"
>     - [nova-network] PreCreate list of networks which is not owned
>      -[Neutron]   additional neutron api call on tenant creation
> (additional script is needed) or better support (keystone integration)

No, this is not done on tenant creation. That's my point. This was done 
on instance launch with communication between Nova and nova-network (and 
should be done on instance creation between nova and quantum, IMO)

> In folsom days, tenant can't create network by themselves via API.
> so that implementation is needed.

Again, this isn't about a tenant creating networks :) It's about 
launching instances without needing to manually supply a network ID.

> Also, the requirement1 don't fit for all cases, so IMO it is
> sufficient to provide API to do that,
> because to combine API is not burden.

All I'm asking for is an API to create networks without a tenant ID :) 
And an API call that returns an available network. In other words, I'm 
asking for the Nova network-related API that made things easy on the 
user in Folsom and earlier.

Best,
-jay

> Best
> Nachi
>
> 2013/7/16 Jay Pipes <jaypipes at gmail.com>:
>> 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
>>>
>>
>>
>> _______________________________________________
>> 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
>