<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<div>Yeah, we heve been trying to work through how to make instance users work with config drive and its staticness makes the problem very difficult. It just trades one problem for another.<br>
<br>
Thanks,<br>
Kevin <strong>
<div><font face="Tahoma" color="#000000" size="2"> </font></div>
</strong>
<hr tabindex="-1">
<font face="Tahoma" size="2"><b>From:</b> Jim Rollenhagen<br>
<b>Sent:</b> Sunday, September 06, 2015 5:02:24 PM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] OpenStack support for Amazon Concepts - was Re: cloud-init IPv6 support<br>
</font><br>
<div></div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText"><br>
<br>
> On Sep 6, 2015, at 09:43, Monty Taylor <mordred@inaugust.com> wrote:<br>
> <br>
>> On 09/05/2015 06:19 PM, Sean M. Collins wrote:<br>
>>> 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">
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>
> Another great part about config-drive is that it's scalable. At infra's application scale, we take pains to disable anyting in our images that might want to contact the metadata API because we're essentially a DDOS on it.<br>
<br>
So, I tend to think a simple API service like this should never be hard to scale. Put a bunch of hosts behind a load balancer, boom, done. Even 1000 requests/s shouldn't be hard, though it may require many hosts, and that's far beyond what infra would hit today.
<br>
<br>
The one problem I have with config-drive is that it is static. I'd love for systems like cloud-init, glean, etc, to be able to see changes to mounted disks, attached networks, etc. Attaching things after the fact isn't uncommon, and to make the user config
the thing is a terrible experience. :(<br>
<br>
// jim <br>
<br>
> <br>
> config-drive being local to the hypervisor host makes it MUCH more stable at scale.<br>
> <br>
> cloud-init supports config-drive<br>
> <br>
> If it were up to me, nobody would be enablig the metadata API in new deployments.<br>
> <br>
> I totally agree that we should not make changes in the metadata API.<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">
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>
> I could not possibly agree more if our brains were physically fused.<br>
> <br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div>
</span></font>
</body>
</html>