Open Stack

I created a nova bug for this: https://bugs.launchpad.net/nova/+bug/1693535. I am currently working on a code patch for it.

--Robert

On 5/24/17, 3:52 PM, "Robert Li (baoli)" <baoli at cisco.com<mailto:baoli at cisco.com>> wrote:

Thanks for the pointer. I think your suggestion in comments #14 https://bugs.launchpad.net/neutron/+bug/1631371/comments/14 makes sense. I actually meant to address the nova side so that trunk details can be exposed in the metadata and configdrive.

-Robert



On 5/24/17, 1:52 PM, "Armando M." <armamig at gmail.com<mailto:armamig at gmail.com>> wrote:



On 24 May 2017 at 08:53, Robert Li (baoli) <baoli at cisco.com<mailto:baoli at cisco.com>> wrote:
Hi Kevin,

In that case, I will start working on it. Should this be considered a RFE or a regular bug?

There have been discussions in the past about this [1]. The conclusion of the discussion was: Nova should have everything it needs to expose trunk details to guest via the metadata API/config drive and at this stage nothing is required from the neutron end (and hence there's no point in filing a Neutron RFE).

While notifying trunk changes to nova require a simple minor enhancement in neutron, it seems premature to go down that path when there's no nova scaffolding yet. Someone should then figure out how the guest itself gets notified of trunk changes so that it can rearrange its networking stack. That might as well be left to some special sauce added to the guest image, though no meaningful discussion has taken place on how to crack this particular nut.

HTH
Armando

[1] https://bugs.launchpad.net/neutron/+bug/1631371



Thanks,
Robert

On 5/23/17, 12:12 AM, "Kevin Benton" <kevin at benton.pub<mailto:kevin at benton.pub>> wrote:

I think we just need someone to volunteer to do the work to expose it as metadata to the VM in Nova.

On May 22, 2017 1:27 PM, "Robert Li (baoli)" <baoli at cisco.com<mailto:baoli at cisco.com>> wrote:
Hi Levi,

Thanks for the info. I noticed that support in the nova code, but was wondering why something similar is not available for vlan trunking.

--Robert


On 5/22/17, 3:34 PM, "Moshe Levi" <moshele at mellanox.com<mailto:moshele at mellanox.com>> wrote:

Hi Robert,
The closes thing that I know about is tagging of SR-IOV physical function’s VLAN tag to guests see [1]
Maybe you can leverage the same mechanism to config vlan trunking in guest.

[1] - https://specs.openstack.org/openstack/nova-specs/specs/ocata/implemented/sriov-pf-passthrough-neutron-port-vlan.html


From: Robert Li (baoli) [mailto:baoli at cisco.com<mailto:baoli at cisco.com>]
Sent: Monday, May 22, 2017 8:49 PM
To: openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>
Subject: [openstack-dev] [nova][vlan trunking] Guest networking configuration for vlan trunk

Hi,

I’m trying to find out if there is support in nova (in terms of metadata and cfgdrive) to configure vlan trunking in the guest. In the ‘CLI usage example’ provided in this wiki https://wiki.openstack.org/wiki/Neutron/TrunkPort, it indicates:

# The typical cloud image will auto-configure the first NIC (eg. eth0) only and not the vlan interfaces (eg. eth0.VLAN-ID).
ssh VM0-ADDRESS sudo ip link add link eth0 name eth0.101 type vlan id 101

I’d like to understand why the support of configuring vlan interfaces in the guest is not added. And should it be added?

Thanks,
Robert

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170525/65169fbc/attachment.html>