> On Sep 6, 2015, at 09:43, Monty Taylor <mord...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
