Open Stack

(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 <yuyangbj at 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 <vishvananda at gmail.com <vishvananda at gmail.com>>*
>
> 2013-12-06 02:34
>  Please respond to
> "OpenStack Development Mailing List \(not for usage questions\)" <
> openstack-dev at lists.openstack.org>
>
>   To
> "OpenStack Development Mailing List \(not for usage questions\)" <
> openstack-dev at 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.ubuntu at cack.org.uk*<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*<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/*<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 at lists.openstack.org* <OpenStack-dev at 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 at lists.openstack.org* <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
>
>
> _______________________________________________
> 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/20131212/b8e7beec/attachment.html>