Open Stack

Hi

I think I was unclear. What I meant were having network wire constructs
like a T where there are actually 3 end points and one of the end points
of the T could be in sniff mode or in a bump-in-the-wire mode. I am not
sure how the current API would support these semantics. 

Use case: imagine vm A talks to B and one wants to monitor the content
by sniffing and the monitoring agent is in vm C. This is not a uncommon
use case. 

Regards
Debo

-----Original Message-----
From: Kyle Mestery (kmestery) 
Sent: Monday, May 23, 2011 4:54 PM
To: Debo Dutta (dedutta)
Cc: Troy Toman; openstack at lists.launchpad.net
Subject: Re: [Openstack] [NetStack] Quantum Service API extension
proposal

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.toman at RACKSPACE.COM] 
> Sent: Monday, May 23, 2011 2:10 PM
> To: Debo Dutta (dedutta)
> Cc: Alex Neefus; Ying Liu (yinliu2); <openstack at 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.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
> 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] On
Behalf Of Ying Liu (yinliu2)
> Sent: Saturday, May 21, 2011 1:10 PM
> To: 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=vi
ew&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
> 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.
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp