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 <jaypi...@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 <jaypi...@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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
