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 <sorlando@nicira.com> wrote: -----To: openstack-dev@lists.openstack.org
From: Salvatore Orlando <sorlando@nicira.com>
Date: 07/17/2012 03:30PM
Cc: 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"]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"]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-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"]http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 <sorlando@nicira.com> wrote: -----To: openstack-dev@lists.openstack.org
From: Salvatore Orlando <sorlando@nicira.com>
Date: 07/17/2012 03:30PM
Cc: 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"]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"]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-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"]http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev