I think we will probably end up having to support the direct pass through
anyway. The reason that landed in the spec is because someone claimed they
had switches that couldn't do translation very well. We will just need
volunteers to make the changes required on the Neutron side.
On Wed, Dec 7, 20
On Wed, Dec 7, 2016 at 7:34 PM, Kevin Benton wrote:
> >It work only when whole switch is aimed by single customer, it will not
> work when several customers sharing the same switch.
>
> Do you know what vendors have this limitation? I know the broadcom
> chipsets didn't prevent this (we allowed V
>It work only when whole switch is aimed by single customer, it will not
work when several customers sharing the same switch.
Do you know what vendors have this limitation? I know the broadcom chipsets
didn't prevent this (we allowed VLAN rewrites scoped to ports at Big
Switch). If it's common to
On Wed, Dec 7, 2016 at 7:12 PM, Kevin Benton wrote:
>
>
> On Wed, Dec 7, 2016 at 8:47 AM, Vasyl Saienko
> wrote:
>
>> @Armando: IMO the spec [0] is not about enablement of Trunks and
>> baremetal. This spec is rather about trying to make user request with any
>> network configuration (number of
On Wed, Dec 7, 2016 at 8:47 AM, Vasyl Saienko wrote:
> @Armando: IMO the spec [0] is not about enablement of Trunks and
> baremetal. This spec is rather about trying to make user request with any
> network configuration (number of requested NICs) to be able successfully
> deployed on ANY ironic n
@Armando: IMO the spec [0] is not about enablement of Trunks and baremetal.
This spec is rather about trying to make user request with any network
configuration (number of requested NICs) to be able successfully deployed
on ANY ironic node (even when number of hardware interfaces is less than
numbe
Just to be clear, in this case the switches don't support VLAN translation
(e.g. [1])? Because that also solves the problem you are running into. This
is the preferable path for bare metal because it avoids exposing provider
details to users and doesn't tie you to VLANs on the backend.
1. http://i
On 7 December 2016 at 04:02, Vasyl Saienko wrote:
> Armando, Kevin,
>
> Thanks for your comments.
>
> To be more clear we are trying to use neutron trunks implementation with
> baremetal servers (Ironic). Baremetal servers are plugged to Tor (Top of
> the Rack) switch. User images are spawned dir
Armando, Kevin,
Thanks for your comments.
To be more clear we are trying to use neutron trunks implementation with
baremetal servers (Ironic). Baremetal servers are plugged to Tor (Top of
the Rack) switch. User images are spawned directly onto hardware.
Ironic uses Neutron ML2 drivers to plug bar
On 6 December 2016 at 08:49, Vasyl Saienko wrote:
> Hello Neutron Community,
>
>
> I've found that nice feature vlan-aware-vms was implemented in Newton [0].
> However the usage of this feature for regular users is impossible, unless
> I'm missing something.
>
> As I understood correctly it shoul
The segmentation type of the trunk (how the VM attached to the parent port
sees the traffic) has nothing to do with the provider segmentation details
(how the traffic will be encapsulated when it leaves the compute node).
You're right that a normal user won't know the latter details, but they
don'
Hello Neutron Community,
I've found that nice feature vlan-aware-vms was implemented in Newton [0].
However the usage of this feature for regular users is impossible, unless
I'm missing something.
As I understood correctly it should work in the following way:
1. It is possible to group neutr
ge questions)
> Subject: [openstack-dev] [neutron] VLAN aware VMs: Current status?
>
> I'm sending this email to solicit a response from the owners of the VLAN
> aware VMs spec [1] [2]. The spec was merged on June 24,
> and I haven't seen any code posted. Given I expect this to
I'm sending this email to solicit a response from the owners of the VLAN
aware VMs spec [1] [2]. The spec was merged on June 24, and I haven't seen
any code posted. Given I expect this to take some iterations in review, is
the plan to push code for this sometime soon?
Thanks!
Kyle
[1] https://rev
ds,
Ildikó
> -Original Message-
> From: Kyle Mestery [mailto:mest...@mestery.com]
> Sent: June 15, 2015 15:52
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Neutron] VLAN-aware VMs meeting
>
> On Mon, Jun 15, 2015 at 7
On Mon, Jun 15, 2015 at 7:40 AM, Ildikó Váncsa
wrote:
> Hi Kyle,
>
> > -Original Message-
> > From: Kyle Mestery [mailto:mest...@mestery.com]
> > Sent: June 15, 2015 04:26
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject
Hi Kyle,
> -Original Message-
> From: Kyle Mestery [mailto:mest...@mestery.com]
> Sent: June 15, 2015 04:26
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Neutron] VLAN-aware VMs meeting
>
> On Fri, Jun 12, 20
On Fri, Jun 12, 2015 at 8:51 AM, Ildikó Váncsa
wrote:
> Hi,
>
>
>
> Since we reopened the review for this blueprint we’ve got a large number
> of comments. It can be clearly seen that the original proposal has to be
> changed, although it still requires some discussion to define a reasonable
> d
Hi,
Since we reopened the review for this blueprint we've got a large number of
comments. It can be clearly seen that the original proposal has to be changed,
although it still requires some discussion to define a reasonable design that
provides the desired feature and is aligned with the archi
ntext (when a firewall VM uses a trunk port to connect
> > > > multiple networks). The basic question is how we should present a
> > trunk port
> > > > and the vlan on a trunk port to Neutron.
> > > >
> > > >
> > > >
> > >
; > and the vlan on a trunk port to Neutron.
> > >
> > >
> > >
> > > Yi
> > >
> > >
> > >
> > > From: Erik Moe [mailto:emoe...@gmail.com]
> > > Sent: Monday, October 28, 2013 1:56 PM
> > > To: openstack-dev@l
e fwaas context (when a firewall VM uses a trunk port to connect
> > > multiple networks). The basic question is how we should present a
> trunk port
> > > and the vlan on a trunk port to Neutron.
> > >
> > >
> > >
> > > Yi
> > >
>
>
> > Yi
> >
> >
> >
> > From: Erik Moe [mailto:emoe...@gmail.com]
> > Sent: Monday, October 28, 2013 1:56 PM
> > To: openstack-dev@lists.openstack.org
> > Subject: [openstack-dev] [Neutron] VLAN aware VMs
> >
> >
> >
> > Hi!
> >
ultiple networks). The basic question is how we should present a trunk
> port
> > and the vlan on a trunk port to Neutron.
> >
> >
> >
> > Yi
> >
> >
> >
> > From: Erik Moe [mailto:emoe...@gmail.com ]
> > Sent: Monday, October 28, 2013 1:
gt;> >
>> >
>> > Yi
>> >
>> >
>> >
>> > From: Erik Moe [mailto:emoe...@gmail.com > 'emoe...@gmail.com');>]
>> > Sent: Monday, October 28, 2013 1:56 PM
>> > To: openstack-dev@lists.openstack.org > 'ope
M uses a trunk port to connect
> > multiple networks). The basic question is how we should present a trunk
> port
> > and the vlan on a trunk port to Neutron.
> >
> >
> >
> > Yi
> >
> >
> >
> > From: Erik Moe [mailto:emoe
28, 2013 1:56 PM
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] [Neutron] VLAN aware VMs
>
>
>
> Hi!
>
> We are looking into how to make it possible for tenant VMs to use VLAN
> tagged traffic to connect to different Neutron networks.
>
>
>
ld present a trunk port and the
> vlan on a trunk port to Neutron.
>
> Yi
>
> From: Erik Moe [mailto:emoe...@gmail.com]
> Sent: Monday, October 28, 2013 1:56 PM
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] [Neutron] VLAN aware VMs
>
> Hi!
&g
.
Yi
From: Erik Moe [mailto:emoe...@gmail.com]
Sent: Monday, October 28, 2013 1:56 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Neutron] VLAN aware VMs
Hi!
We are looking into how to make it possible for tenant VMs to use VLAN
tagged traffic to connect to different
Hi!
We are looking into how to make it possible for tenant VMs to use VLAN
tagged traffic to connect to different Neutron networks.
The VID on frames sent/received will determine which Neutron network the
frames are connected to.
https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms
I w
30 matches
Mail list logo
