At the meeting I was not convinced that the name needs to be optional. I believe is need to be ‘not optional’ and ‘unique’.
My perspective is that a network should be created with a name. It is the systems responsibility to assign a UUID to it as it will be used by the system for referring to it internally. Needless to say that UUID are alright to use between machines and when humans get involved reasonable names are useful. Example: I create a network with a name ‘vlan3’ – (hopefully used for deploying vlanid=3) and much later (maybe a week later) I want to deploy a VM which will use this network. From the UI is will be hard to refer to this network using a UUID. (it is pretty similar to file names and inodes, as a human I am glad I never think in terms of inodes I am happy with filenames) -Shiv From: netstack-bounces+sharis=brocade....@lists.launchpad.net [mailto:netstack-bounces+sharis=brocade....@lists.launchpad.net] On Behalf Of Yong Sheng Gong Sent: Tuesday, July 17, 2012 1:31 AM To: Salvatore Orlando Cc: OpenStack Development Mailing List; netstack@lists.launchpad.net Subject: Re: [Netstack] [openstack-dev] [Quantum] Starting a discussion on the official spec for v2 API Hi, I thought we agreed to make the name optional and up to user to decide its uniqueness at meeting. Thanks Yong Sheng Gong -----Salvatore Orlando <sorla...@nicira.com><mailto:sorla...@nicira.com> wrote: ----- To: openstack-...@lists.openstack.org<mailto:openstack-...@lists.openstack.org> From: Salvatore Orlando <sorla...@nicira.com><mailto:sorla...@nicira.com> Date: 07/17/2012 03:30PM Cc: netstack@lists.launchpad.net<mailto:netstack@lists.launchpad.net> Subject: [openstack-dev] [Quantum] Starting a discussion on the official spec for v2 API Hello people of Quantum! As the Folsom release approaches, it is time to gather together and finalize the specification for the v2 API, so that the Openstack-doc team might cast it in stone for the sake of the Quantum users! In order to make this happen, it looks like there are just a few bits that needs to be agreed upon, and I think they can be summarized as follows: - 'name' attributes and whether they should be mandatory. It looks like we all agree we want them, but it has to be decided whether i) they should be unique or not. ii) they should be mandatory or not. - 'public' attribute for networks. As we did not get negative feedback on the proposal, I am going to assume nobody has strong opinions against this decision. - security group API. We have a blueprint open and targeted to F-3 (https://blueprints.launchpad.net/quantum/+spec/quantum-security-groups). Personally I do not feel it is a good idea at this stage proposing them for the core v2 API in Folsom. Apart from the necessary discussion concerning the APIs, we will need support across all the plugins, which is hardly going to happen IMHO. If you have a different opinion, this is the right thread to shout it! - NOTE: Leaving the security groups outside of Quantum core API also means that we *must* ensure Quantum still allows Nova to use its own firewall drivers. - L3 features (https://blueprints.launchpad.net/quantum/+spec/quantum-l3-fwd-nat): among the various sub-blueprints in which this blueprint can be broken, there's one concerning APIs. As I have not followed the development of this particular blueprint, I'll leave it to Dan whether L3 & NAT APIs should be part of Folsom core. From my perspective, the above list includes all the items concerning the Quantum v2 API which have not yet stabilized. Please do let me know if I forgot anything. Thanks and have a good day, Salvatore _______________________________________________ OpenStack-dev mailing list openstack-...@lists.openstack.org<mailto:openstack-...@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
