[openstack-dev] [Neutron] Interfaces file format, was [Tempest] Need to prepare the IPv6 environment for static IPv6 injection test case

Vishvananda Ishaya vishvananda at gmail.com
Thu Dec 5 18:34:58 UTC 2013


Hi Ian,

The rendered network template was a legacy item that got stuck onto the config drive so we could remove file injection. It is not intended that this is the correct way to do net config. We have intended in the past to put a generic form of network info into the metadata service and config drive. Cloud-init can parse this data and have code to set up networking config on different operating systems.

We actually discussed doing this during the Havana summit, but no one ever made any progress. There was some debate about whether there was an existing xml format and someone was going to investigate. Since this has not happened, I propose we scrap that idea and just produce the network info in json.

Nova should be able to populate this data from its cached network info. It might also be nice to stick it in a known location on the metadata server so the neutron proxy could potentially overwrite it with more current network data if it wanted to.

Vish

On Dec 4, 2013, at 8:26 AM, Ian Wells <ijw.ubuntu at cack.org.uk> wrote:

> We seem to have bound our config drive file formats to those used by the operating system we're running, which doesn't seem like the right approach to take.
> 
> Firstly, the above format doesn't actually work even for Debian-based systems - if you have a network without ipv6, ipv6 ND will be enabled on the ipv4-only interfaces, which strikes me as wrong.  (This is a feature of Linux - ipv4 is enabled on interfaces which are specifically configured with ipv4, but ipv6 is enabled on all interfaces that are brought up.)
> 
> But more importantly, the above file template only works for Debian-based machines - not Redhat, not Windows, not anything else - and we seem to have made that a feature of Openstack from the relatively early days of file injection.  That's not an ipv6 only thing but a general statement.  It seems wrong to have to extend Openstack's config drive injection for every OS that might come along, so is there a way we can make this work without tying the two things together?  Are we expecting the cloud-init code in whatever OS to parse and understand this file format, or are they supposed to use other information?  In general, what would the recommendation be for someone using a VM where this config format is not native?
> 
> -- 
> Ian.
> 
> 
> On 2 December 2013 03:01, Yang XY Yu <yuyangbj at cn.ibm.com> wrote:
> Hi all stackers, 
> 
> Currently Neutron/Nova code has supported the static IPv6 injection, but there is no tempest scenario coverage to support IPv6 injection test case. So I finished the test case and run the it successfully in my local environment, and already submitted the code-review in community: https://review.openstack.org/#/c/58721/, but the community Jenkins env has not supported IPv6 and there are still a few pre-requisites setup below if running the test case correctly, 
> 
> 1. Special Image needed to support IPv6 by using cloud-init, currently the cirros image used by tempest does not installed cloud-init. 
> 
> 2. Prepare interfaces.template file below on compute node. 
>     edit  /usr/share/nova/interfaces.template 
> 
> # Injected by Nova on instance boot 
> # 
> # This file describes the network interfaces available on your system 
> # and how to activate them. For more information, see interfaces(5). 
> 
> # The loopback network interface 
> auto lo 
> iface lo inet loopback 
> 
> {% for ifc in interfaces -%} 
> auto {{ ifc.name }} 
> {% if use_ipv6 -%} 
> iface {{ ifc.name }} inet6 static 
>     address {{ ifc.address_v6 }} 
>     netmask {{ ifc.netmask_v6 }} 
> {%- if ifc.gateway_v6 %} 
>     gateway {{ ifc.gateway_v6 }} 
> {%- endif %} 
> {%- endif %} 
> 
> {%- endfor %} 
> 
> 
> So considering these two pre-requisites, what should be done to enable this patch for IPv6 injection? Should I open a bug for cirros to enable cloud-init?   Or skip the test case because of this bug ? 
> Any comments are appreciated! 
> 
> Thanks & Best Regards,
> ----------------------------------------------------
> Yang Yu(于杨)
> Cloud Solutions and OpenStack Development
> China Systems & Technology Laboratory Beijing
> E-mail: yuyangbj at cn.ibm.com 
> Tel: 86-10-82452757
> Address: Ring Bldg. No.28 Building, Zhong Guan Cun Software Park, 
> No. 8 Dong Bei Wang West Road, ShangDi, Haidian District, Beijing 100193, P.R.China 
> ---------------------------------------------------- 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/20131205/7dbc377c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131205/7dbc377c/attachment.pgp>


More information about the OpenStack-dev mailing list