<p dir="ltr">So it's been pointed out that <a href="http://169.254.169.254/openstack">http://169.254.169.254/openstack</a> is completed OpenStack invented. I don't quite understand how that's not violating the contract you said we have with end users about EC2 compatibility under the restriction of 'no new stuff'. </p>
<p dir="ltr">If we added an IPv6 endpoint that the metadata service listens on, it would just be another place that non cloud-init clients don't know how to talk to. It's not going to break our compatibility with any clients that connect to the IPv4 address. </p>
<div class="gmail_quote">On Sep 5, 2015 3:22 PM, "Sean M. Collins" <<a href="mailto:sean@coreitpro.com">sean@coreitpro.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Sep 04, 2015 at 04:20:23PM EDT, Kevin Benton wrote:<br>
> Right, it depends on your perspective of who 'owns' the API. Is it<br>
> cloud-init or EC2?<br>
><br>
> At this point I would argue that cloud-init is in control because it would<br>
> be a large undertaking to switch all of the AMI's on Amazon to something<br>
> else. However, I know Sean disagrees with me on this point so I'll let him<br>
> reply here.<br>
<br>
<br>
Here's my take:<br>
<br>
Cloud-Init is a *client* of the Metadata API. The OpenStack Metadata API<br>
in both the Neutron and Nova projects should all the details of the<br>
Metadata API that is documented at:<br>
<br>
<a href="http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html" rel="noreferrer" target="_blank">http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html</a><br>
<br>
This means that this is a compatibility layer that OpenStack has<br>
implemented so that users can use appliances, applications, and<br>
operating system images in both Amazon EC2 and an OpenStack environment.<br>
<br>
Yes, we can make changes to cloud-init. However, there is no guarantee<br>
that all users of the Metadata API are exclusively using cloud-init as<br>
their client. It is highly unlikely that people are rolling their own<br>
Metadata API clients, but it's a contract we've made with users. This<br>
includes transport level details like the IP address that the service<br>
listens on.<br>
<br>
The Metadata API is an established API that Amazon introduced years ago,<br>
and we shouldn't be "improving" APIs that we don't control. If Amazon<br>
were to introduce IPv6 support the Metadata API tomorrow, we would<br>
naturally implement it exactly the way they implemented it in EC2. We'd<br>
honor the contract that Amazon made with its users, in our Metadata API,<br>
since it is a compatibility layer.<br>
<br>
However, since they haven't defined transport level details of the<br>
Metadata API, regarding IPv6 - we can't take it upon ourselves to pick a<br>
solution. It is not our API.<br>
<br>
The nice thing about config-drive is that we've created a new mechanism<br>
for bootstrapping instances - by replacing the transport level details<br>
of the API. Rather than being a link-local address that instances access<br>
over HTTP, it's a device that guests can mount and read. The actual<br>
contents of the drive may have a similar schema as the Metadata API, but<br>
I think at this point we've made enough of a differentiation between the<br>
EC2 Metadata API and config-drive that I believe the contents of the<br>
actual drive that the instance mounts can be changed without breaking<br>
user expectations - since config-drive was developed by the OpenStack<br>
community. The point being that we call it "config-drive" in<br>
conversation and our docs. Users understand that config-drive is a<br>
different feature.<br>
<br>
I've had this same conversation about the Security Group API that we<br>
have. We've named it the same thing as the Amazon API, but then went and<br>
made all the fields different, inexplicably. Thankfully, it's just the<br>
names of the fields, rather than being huge conceptual changes.<br>
<br>
<a href="http://lists.openstack.org/pipermail/openstack-dev/2015-June/068319.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2015-June/068319.html</a><br>
<br>
Basically, I believe that OpenStack should create APIs that are<br>
community driven and owned, and that we should only emulate<br>
non-community APIs where appropriate, and explicitly state that we only<br>
are emulating them. Putting improvements in APIs that came from<br>
somewhere else, instead of creating new OpenStack branded APIs is a lost<br>
opportunity to differentiate OpenStack from other projects, as well as<br>
Amazon AWS.<br>
<br>
Thanks for reading, and have a great holiday.<br>
<br>
--<br>
Sean M. Collins<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div>