Open Stack

And here is the code that does this (for cloudinit 0.7.x):

https://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/sources/helpers/openstack.py

This same code is used by the config drive datasource (the one that 
makes a disk/iso) in cloudinit and the http endpoint based datasource in 
cloudinit (the one that exports /openstack/ on the metadata server).

https://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/sources/helpers/openstack.py#L320 
(for the config drive subclass) and 
https://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/sources/helpers/openstack.py#L419 
(for the http endpoint based subclass).

Note that in the following: 
https://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/sources/DataSourceOpenStack.py#L77 
you can already provide a different metadata url (say one that uses 
ipv6) that will override the default "http://169.254.169.254" defined in 
there. This can be done in a few various ways but feel free to jump on 
#cloud-init IRC channel and ask if interested or find me on IRC 
somewhere (since I'm the main one who worked on all the above code).

-Josh

Fox, Kevin M wrote:
> No, we already extend the metadata server with our own stuff. See
> /openstack/ on the metadata server. Cloudinit even supports the
> extensions. Supporting ipv6 as well as v4 is the same. Why does it
> matter if aws doesnt currently support it? They can support it if they
> want in the future and reuse code, or do their own thing and have to
> convince cloudinit to support there way too. But why should that hold
> back the openstack metadata server now? Lets lead rather then follow.
>
> Thanks,
> Kevin *
> *
> ------------------------------------------------------------------------
> *From:* Sean M. Collins
> *Sent:* Saturday, September 05, 2015 3:19:48 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Cc:* Fox, Kevin M; PAUL CARVER
> *Subject:* OpenStack support for Amazon Concepts - was Re:
> [openstack-dev] cloud-init IPv6 support
>
> On Fri, Sep 04, 2015 at 04:20:23PM EDT, Kevin Benton wrote:
>>  Right, it depends on your perspective of who 'owns' the API. Is it
>>  cloud-init or EC2?
>>
>>  At this point I would argue that cloud-init is in control because it would
>>  be a large undertaking to switch all of the AMI's on Amazon to something
>>  else. However, I know Sean disagrees with me on this point so I'll let him
>>  reply here.
>
>
> Here's my take:
>
> Cloud-Init is a *client* of the Metadata API. The OpenStack Metadata API
> in both the Neutron and Nova projects should all the details of the
> Metadata API that is documented at:
>
> http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html
>
> This means that this is a compatibility layer that OpenStack has
> implemented so that users can use appliances, applications, and
> operating system images in both Amazon EC2 and an OpenStack environment.
>
> Yes, we can make changes to cloud-init. However, there is no guarantee
> that all users of the Metadata API are exclusively using cloud-init as
> their client. It is highly unlikely that people are rolling their own
> Metadata API clients, but it's a contract we've made with users. This
> includes transport level details like the IP address that the service
> listens on.
>
> The Metadata API is an established API that Amazon introduced years ago,
> and we shouldn't be "improving" APIs that we don't control. If Amazon
> were to introduce IPv6 support the Metadata API tomorrow, we would
> naturally implement it exactly the way they implemented it in EC2. We'd
> honor the contract that Amazon made with its users, in our Metadata API,
> since it is a compatibility layer.
>
> However, since they haven't defined transport level details of the
> Metadata API, regarding IPv6 - we can't take it upon ourselves to pick a
> solution. It is not our API.
>
> The nice thing about config-drive is that we've created a new mechanism
> for bootstrapping instances - by replacing the transport level details
> of the API. Rather than being a link-local address that instances access
> over HTTP, it's a device that guests can mount and read. The actual
> contents of the drive may have a similar schema as the Metadata API, but
> I think at this point we've made enough of a differentiation between the
> EC2 Metadata API and config-drive that I believe the contents of the
> actual drive that the instance mounts can be changed without breaking
> user expectations - since config-drive was developed by the OpenStack
> community. The point being that we call it "config-drive" in
> conversation and our docs. Users understand that config-drive is a
> different feature.
>
> I've had this same conversation about the Security Group API that we
> have. We've named it the same thing as the Amazon API, but then went and
> made all the fields different, inexplicably. Thankfully, it's just the
> names of the fields, rather than being huge conceptual changes.
>
> http://lists.openstack.org/pipermail/openstack-dev/2015-June/068319.html
>
> Basically, I believe that OpenStack should create APIs that are
> community driven and owned, and that we should only emulate
> non-community APIs where appropriate, and explicitly state that we only
> are emulating them. Putting improvements in APIs that came from
> somewhere else, instead of creating new OpenStack branded APIs is a lost
> opportunity to differentiate OpenStack from other projects, as well as
> Amazon AWS.
>
> Thanks for reading, and have a great holiday.
>
> --
> Sean M. Collins
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev