(2) should read 'the data should appear on both metadata and the config drive', I would say. Vish was making a point that this metadata changes (e.g. when running nova interface-attach) and it might be nice if the metadata server updated its information. It might be, and changing metadata has been discussed more than once before, but that's a can of worms that no-one is going to rush to open so it's not going to affect tests right now.
To run that test case, I don't think you have any option right now but to use a special interface template - it's that or go reading your addresses from the Neutron API directly when your machine tries to configure, and no-one would set up a VM like that. -- Ian. On 12 December 2013 10:33, Yang XY Yu <yuyan...@cn.ibm.com> wrote: > Hi Ian and Vish, > > Thanks for your reply. From your response, I still have some questions, > hope you can help me to clear up them. > > <1> From Vish's response, may I believe that static IPv6 injection using > the interface.template will be dropped in future because it is not a > correct way to do net config as you said? > > <2> If we still use the interface.template to do net config, we'd better > put it into metadata server, right? > > <3> If these two assumption above are correct, my question is we still > need to prepare some special ENV such as images with cloud-init to run this > tempest case > *https://review.openstack.org/#/c/58721/*<https://review.openstack.org/#/c/58721/>, > is it reasonable to be accepted by community? Is it the correct direction > to submit case for IPv6? How should I ask community to prepare the this > special ENV？ > > Thanks & Best Regards, > ---------------------------------------------------- > Yang Yu(于杨) > ---------------------------------------------------- > > > *Vishvananda Ishaya <vishvana...@gmail.com <vishvana...@gmail.com>>* > > 2013-12-06 02:34 > Please respond to > "OpenStack Development Mailing List \(not for usage questions\)" < > openstack-dev@lists.openstack.org> > > To > "OpenStack Development Mailing List \(not for usage questions\)" < > openstack-dev@lists.openstack.org> > cc > Subject > Re: [openstack-dev] [Neutron] Interfaces file format, was [Tempest] > Need to prepare the IPv6 environment for static IPv6 injection test > case > > > > > 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*<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*<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/*<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* <http://ifc.name/> }} > {% if use_ipv6 -%} > iface {{ *ifc.name* <http://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(于杨) > ---------------------------------------------------- > _______________________________________________ > OpenStack-dev mailing list > > *OpenStack-dev@lists.openstack.org* <OpenStack-dev@lists.openstack.org> > *http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev*<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> > > > _______________________________________________ > OpenStack-dev mailing list > *OpenStack-dev@lists.openstack.org* <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 > > > _______________________________________________ > 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
