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 ijw.ubu...@cack.org.ukmailto:ijw.ubu...@cack.org.uk
Reply-To: OpenStack Development Mailing List (not for usage
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
Hi Salvatore,
Two questions/remarks below.
From: Salvatore Orlando sorla...@nicira.commailto:sorla...@nicira.com
Reply-To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: onsdag 6 maj 2015 00:13
To:
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
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 mest...@mestery.com wrote:
There are currently at least two BPs registered for VLAN trunk support
to VMs in neutron-specs [1] [2]. This is clearly
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
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 gd...@varmour.commailto:gd...@varmour.com
Reply-To: OpenStack Development Mailing List (not for usage questions)
the
tenant level isolation?
Thanks,
~Sumit.
On Tue, Oct 8, 2013 at 11:34 PM, Bob Melander (bmelande)
bmela...@cisco.commailto: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
be controlled via already existing access control
mechanism 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)
bmela...@cisco.commailto:bmela
Hi Edgar,
I'm also interested in a broadening of NAT capability in Neutron using the
evolving service framework.
Thanks,
Bob
From: Edgar Magana emag...@plumgrid.commailto:emag...@plumgrid.com
Reply-To: OpenStack Development Mailing List
appliances.
Regards
-Harshad
On Oct 10, 2013, at 12:44 AM, Bob Melander (bmelande)
bmela...@cisco.commailto: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 (virtual) host where one
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: Regnier, Greg J
12 matches
Mail list logo
