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.ubu...@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 <yuyan...@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: yuyan...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
