Open Stack

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.

Thanks,
Kevin

________________________________
From: Jim Rollenhagen
Sent: Sunday, September 06, 2015 5:02:24 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] OpenStack support for Amazon Concepts - was Re: cloud-init IPv6 support



> 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

__________________________________________________________________________
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150908/65bde1bf/attachment.html>