Thanks, Alex.
I'd like to add few points. Our proposal is not intended to provide the whole extension mechanism for Quantum Service. Instead, we are proposing an extensible construct to Quantum core API. Thus, we can have a flexible and scalable way to describe the port's configurations. For example, the Port Profile includes a set of configurations. Thus, Port profile is defined once and it can be associated with multiple ports. If we need to create 30 ports with the same configuration settings, we don't need to do the same configurations 30 times. We agree with standard extension mechanism drafted by Jorge. With which, we can extend attributes, actions, headers, resources and etc. Considering our proposals, I think there are three options: 1. We keep "Port Profile", the extensible construct for the port. It's just for the configuration extension. All other extensions go through the standard extension mechanism. The reason is that configuration extension is just adding an attribute to the port. With extensible "Port Profile", we can quickly add it. For the extended <key>, we can require using vendor ID as the prefix. For example, <NASA-newKey>. 2. We keep the "Port Profile" construct associated with the port. But, it only has fixed set of basic keys for common configurations. All the extensions are handled by standard extension mechanism. With this approach, we can still have scalable way to configure a large network. Plus, we won't need extension unless we need some configuration beyond that common configuration set. 3. In core API, only port id is associated with the port. (any other basic attributes should associated with a port?). All the extension are handled by extension mechanisms. With this option, any additional attribute/configuration request an extension. We are fine with any of them and I can update wiki based on the community's decision. Best, Ying From: Alex Neefus [mailto:a...@mellanox.com] Sent: Monday, May 23, 2011 1:05 PM To: Ying Liu (yinliu2); openstack@lists.launchpad.net Cc: Rick Clark Subject: RE: [Openstack] [NetStack] Quantum Service API extension proposal Hi All - I wanted to lend support to this proposal, however I don't think we should be so quick to say this whole thing is an extension. We benefit a lot from having a standard capabilities mechanism as part of our core Quantum API. I like Ying's key value method as well. I think it's logical, clean and scalable. I propose that basic read access of "cap" off of our major objects: network, port, interface be included in our first release. So in summary I would like to encourage us to add: GET /networks/{net_id}/conf GET /networks/{net_id}/ports/{port_id}/conf/ GET {entity}/VIF/conf/ Each of these would return a list of keys. Additionally Quantum base should support GET /networks/{net_id}/conf/{key} GET /networks/{net_id}/ports/{port_id}/conf/{key} GET {entity}/VIF/conf/{key} Where {key} is the name of either a standard capability or an extention capability. We can define an error code now to designate a capability not supported by the plugin. (i.e. 472 - CapNotSupported) Finally we don't need to standardize on every capability that might be supported if we provide this simple mechanism. Specific capabilities Key,Value sets can be added later but or included as vendor specific extensions. I'm happy to add this to the wiki if there is consensus. Rick/Dan - Maybe this should be a topic for Tuesdays meeting. Alex --- Alex Neefus Senior System Engineer | Mellanox Technologies (o) 617.337.3116 | (m) 201.208.5771 | (f) 617.337.3019 From: openstack-bounces+alex=mellanox....@lists.launchpad.net [mailto:openstack-bounces+alex=mellanox....@lists.launchpad.net] On Behalf Of Ying Liu (yinliu2) Sent: Saturday, May 21, 2011 1:10 PM To: openstack@lists.launchpad.net Subject: [Openstack] [NetStack] Quantum Service API extension proposal Hi all, We just posted a proposal for OpenStack Quantum Service API extension on community wiki page at http://wiki.openstack.org/QuantumAPIExtensions?action=AttachFile&do=view &target=quantum_api_extension.pdf or http://wiki.openstack.org/QuantumAPIExtensions?action=AttachFile&do=view &target=quantum_api_extension.docx Please review and let us know your comments/suggestions. An etherpad page is created for API extension discussion http://etherpad.openstack.org/uWXwqQNU4s Best, Ying
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
