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 [mrie...@linux.vnet.ibm.com] Sent: Tuesday, September 15, 2015 11:28 AM To: openstack-dev@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 <mord...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
