I agree, that is my take too.
Russell, since you lead the OVN session in Vancouver, would it be possible to
include the VLAN-aware-vms BP in that session?
Thanks,
Bob
From: Ian Wells mailto:ijw.ubu...@cack.org.uk>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
mailto
Hi Eric,
Cisco is also interested in the kind of VLAN trunking feature that your
VLAN-aware VM’s BP describe. If this could be achieved in Liberty it’d be great.
Perhaps your BP could be brought up during one of the Neutron sessions in
Vancouver, e.g., the one on OVN since there seems to be some
Hi Salvatore,
Two questions/remarks below.
From: Salvatore Orlando mailto:sorla...@nicira.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
Date: onsdag 6 maj 2015 00:13
To: OpenStack Development Mailing List
mailto:opensta
What scares me a bit about the “let’s find a common solution for both external
devices and VMs” approach is the challenge to reach an agreement. I remember a
rather long discussion in the dev lounge in HongKong about trunking support
that ended up going in all kinds of directions.
I work on imp
I suppose this BP also has some relevance to such a discussion.
https://review.openstack.org/#/c/100278/
/ Bob
On 2014-10-22 15:42, "Kyle Mestery" wrote:
>There are currently at least two BPs registered for VLAN trunk support
>to VMs in neutron-specs [1] [2]. This is clearly something that I'
Hi Zzelle, Carl and others,
We’ve been doing work on a more modular agent whose responsibilities are
basically to:
1: apply configurations in devices when Neutron service resources (like Neutron
Routers) are created or updated.
2: monitor the health of devices hosting such service resources
Our
I agree. With your patch it ought to be possible to make the distributed router
a provider type so to me it seems like a good match.
Thanks,
Bob
From: Gary Duan mailto:gd...@varmour.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.opensta
Somewhat related: Sharing of networks between tenants has also come up in the
discussions on trunk support; One use case there is , a VM VIF is plugged to
multiple networks at the same time and packets are VLAN tagged (visible to the
VM) to separate those networks. For usage with service VMs it
in most of physical appliances.
Regards
-Harshad
On Oct 10, 2013, at 12:44 AM, "Bob Melander (bmelande)"
mailto:bmela...@cisco.com>> wrote:
Harshad,
By service instance I referred to the logical entities that Neutron creates
(e.g. Neutron's router). I see a service VM as a
Hi Edgar,
I'm also interested in a broadening of NAT capability in Neutron using the
evolving service framework.
Thanks,
Bob
From: Edgar Magana mailto:emag...@plumgrid.com>>
Reply-To: OpenStack Development Mailing List
mailto:openstack-dev@lists.openstack.org>>
Date: onsdag 9 oktober 2013 21:3
nism in openstack. If the service instance belonged to a particular
project then other tenants should by definition should not be able to use this
instance.
On Tue, Oct 8, 2013 at 11:34 PM, Bob Melander (bmelande)
mailto:bmela...@cisco.com>> wrote:
For use case 2, ability to "pin" a
Tue, Oct 8, 2013 at 11:34 PM, Bob Melander (bmelande)
mailto:bmela...@cisco.com>> wrote:
For use case 2, ability to "pin" an admin/operator owned VM to a particular
tenant can be useful.
I.e., the service VMs are owned by the operator but a particular service VM
will only allow ser
For use case 2, ability to "pin" an admin/operator owned VM to a particular
tenant can be useful.
I.e., the service VMs are owned by the operator but a particular service VM
will only allow service instances from a single tenant.
Thanks,
Bob
From: , Greg J
mailto:greg.j.regn...@intel.com>>
Rep
13 matches
Mail list logo
