Open Stack

I think the idea was slightly different. We were equating a vif to  NIC in a physical server. A port was equated to a switch port on a physical switch. Doesn't necessarily mean they have to be different. But, there was a reason we used different terminology.

In particular, we felt the vif was something that would continue to be in the server's domain and managed within Nova. A port was a construct that is owned and managed by the network service (Quantum).

Troy

On May 23, 2011, at 3:56 PM, Debo Dutta (dedutta) wrote:

Quick question: it seems we are calling one end of the virtual wire a port and the other a vif. Is there a reason to do that? Can we just call say that that a wire connects 2 ports?

Also another interesting network scenario is when there is a wire connecting 2 ports and you have a tap (for all sorts of scenarios). I think the semantics of the tap might be  quite basic.

Regards
debo

From: openstack-bounces+dedutta=cisco.com at lists.launchpad.net<mailto:openstack-bounces+dedutta=cisco.com at lists.launchpad.net> [mailto:openstack-bounces+dedutta=cisco.com at lists.launchpad.net] On Behalf Of Alex Neefus
Sent: Monday, May 23, 2011 1:05 PM
To: Ying Liu (yinliu2); openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>
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.com at lists.launchpad.net<mailto:openstack-bounces+alex=mellanox.com at lists.launchpad.net> [mailto:openstack-bounces+alex=mellanox.com at lists.launchpad.net] On Behalf Of Ying Liu (yinliu2)
Sent: Saturday, May 21, 2011 1:10 PM
To: openstack at lists.launchpad.net<mailto:openstack at 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 athttp://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 discussionhttp://etherpad.openstack.org/uWXwqQNU4s

Best,
Ying
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp



Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is prohibited.
If you receive this transmission in error, please notify us immediately by e-mail
at abuse at rackspace.com, and delete the original message.
Your cooperation is appreciated.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110523/3051e19f/attachment.html>