Open Stack

Most projects let you specify a name, and only force you to use a uuid IFF there is a conflict, leaving it up to the user to decide if they want the ease of use of names and being careful to name things, or having to use uuid's and not.

Neutron also has the odd wrinkle in that if your a cloud admin, it always gives you all the resources back in a listing rather then just the current tenant with a flag saying all.

This means if you try to use the "default" security group for example, it may work as a user, and then fail as an admin on the same tenant. very annoying. :/

I've had to work around that in heat templates before.

Thanks,
Kevin


________________________________________
From: Matt Riedemann [mriedem at linux.vnet.ibm.com]
Sent: Tuesday, September 15, 2015 11:28 AM
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

On 9/15/2015 10:27 AM, Mike Spreitzer wrote:
> Monty Taylor <mordred at inaugust.com> wrote on 09/15/2015 11:04:07 AM:
>
>  > a) an update to python-novaclient to allow a named network to be passed
>  > to satisfy the "you have more than one network" - the nics argument is
>  > still useful for more complex things
>
> I am not using the latest, but rather Juno.  I find that in many places
> the Neutron CLI insists on a UUID when a name could be used.  Three
> cheers for any campaign to fix that.

It's my understanding that network names in neutron, like security
groups, are not unique, that's why you have to specify a UUID.

>
> And, yeah, creating VMs on a shared public network is good too.
>
> Thanks,
> mike
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

--

Thanks,

Matt Riedemann


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev