Open Stack

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.

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.