Open Stack

> On Sep 6, 2015, at 09:43, Monty Taylor <mordred at inaugust.com> wrote:
> 
>> On 09/05/2015 06:19 PM, Sean M. Collins wrote:
>>> 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.
> 
> 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.

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. 

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. :(

// jim 

> 
> config-drive being local to the hypervisor host makes it MUCH more stable at scale.
> 
> cloud-init supports config-drive
> 
> If it were up to me, nobody would be enablig the metadata API in new deployments.
> 
> I totally agree that we should not make changes in the metadata API.
> 
>> 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.
> 
> I could not possibly agree more if our brains were physically fused.
> 
> __________________________________________________________________________
> 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