[openstack-dev] Neutron -- creating networks with no assigned tenant

Jay Pipes jaypipes at gmail.com
Tue Jul 16 22:11:14 UTC 2013


On 07/16/2013 06:09 PM, Rick Jones wrote:
> On 07/16/2013 02:56 PM, Jay Pipes wrote:
>> 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)
>
> But *could* it be done on tenant creation?  A "default" network if you
> will - along perhaps with things like default security groups etc...  If
> that were indeed done, then I believe that the pre-quantum, err,
> pre-neutron users would get a network associated with their instances
> without their having to do the five or so neutron commands to create a
> network and get it connected to the rest of the world.
>
> As it stands today under grizzly if launch an instance it will be
> automagically connected to whatever networks my tenant happens to have.
>   So, if there is a network created when the tenant is
> created/instantiated/whatever, what you want to have happen - nova
> instances created connected to a network without need of explicit action
> on the part of the user - will take place no?

Absolutely, that is what our tools team is now having to do. All I'm 
saying is that this wasn't necessary in Folsom and wouldn't be necessary 
if the API didn't force networks to be created with a tenant ID.

Best,
-jay




More information about the OpenStack-dev mailing list