Debo: A tap is nothing different than a VM vnics from a switch perspective, it still contains a portion owned by Nova (the tap itself) and it connects to a port, which is owned by Quantum. So in essence, the tap still has both a "vif" and a "port" in this terminology.
Thanks, Kyle On May 23, 2011, at 4:10 PM, Debo Dutta (dedutta) wrote: > Hi Troy > > What about a tap? Its also like a port ….Should that be in quantum? > > Regards > Debo > > From: Troy Toman [mailto:troy.to...@rackspace.com] > Sent: Monday, May 23, 2011 2:10 PM > To: Debo Dutta (dedutta) > Cc: Alex Neefus; Ying Liu (yinliu2); <openstack@lists.launchpad.net> > Subject: Re: [Openstack] [NetStack] Quantum Service API extension proposal > > 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....@lists.launchpad.net > [mailto:openstack-bounces+dedutta=cisco....@lists.launchpad.net] On Behalf Of > Alex Neefus > Sent: Monday, May 23, 2011 1:05 PM > To: Ying Liu (yinliu2); openstack@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....@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 > 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@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 ab...@rackspace.com, and delete the original message. > Your cooperation is appreciated. > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
