Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
On Jul 11, 2011, at 9:23 AM, Sandy Walsh wrote: Ugh, sorry, burned again by outlook web. Let me continue ... I'm still stewing on this but at first blush this seems like an artificial abstraction. What do we really gain from having another layer above the service api's? Can't they just live at the service api? For example: nova.compute.api:create_instance() vs. nova.business_layer:create_instance() What's the real win here? I was initially confused by the self.compute_api.create call in the nova/api/ec2/cloud.py:CloudController.run_instances method. I think my source of confusion was: why is the compute API being called directly, shouldn't the scheduler do this? (I didn't realize at the time that this leads to a scheduler request). Would pushing this down one layer have helped me understand this better? In retrospect, maybe not... I agree that the heavy lifting logic should be removed from the os/ec2 api layers and only be doing parameter checking ... but they may also do mapping/translations to the underlying service api's. Perhaps the issue is that the lower level (nova.[service].api) doesn't have a formal enough definition and is getting pulled in two directions by ec2/os api? Perhaps making this layer have a clear contract is what we're missing? Yeah, I'm not sure what the best solution is here... Lorin -- Lorin Hochstein, Computer Scientist USC Information Sciences Institute 703.812.3710 http://www.east.isi.edu/~lorin -S From: Lorin Hochstein [lo...@isi.edu] I think it actually looks more like this right now: EC2 Client OS Client | | EC2 APIOS API \ / [nova-*] service APIs There isn't really a single back-end API for the front-end APIs to call into. Instead, each of them makes calls to the multiple service APIs (e.g., scheduler, network, compute). I would advocate for something more like this: EC2 Client OS Client | | EC2 APIOS API \ / internal nova API | [nova-*] service APIs This is a single, unified API that is meant only for internal use. This would reduce the coupling between front-end and back-end. It would make it easier for someone with less expertise in the code (hello!) to find the location in the code that answers questions like: What does nova do when a user requests that an instance is launched? They would just look at the internal API and find the appropriate method. It would also make it easier to add additional front-ends, if there's ever any interest in that. This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
On Jul 11, 2011, at 6:19 PM, Ewan Mellor wrote: [Snip summary] The only question that needs to be considered is where do we move from here? Do we accept the limitation that the EC2 API and any tool which relies upon that will be only available for single-zone deployments, and if you want distributed zones, you must use the OS API? Up to now, I have assumed that zones would be used as the construct that isolated different service offerings, e.g. VMware vs XenServer or 10G networking versus 1G, or whatever. Zones therefore play two roles: they give you the architecture for large-scale deployments, and they also allow for distinguished service offerings. Are you thinking along these lines? Note that we aren't using zones this way: we're assuming that there can be different kinds of service offerings within a single zone (For example, we have a single zone that contains multiple machine architectures). Lorin -- Lorin Hochstein, Computer Scientist USC Information Sciences Institute 703.812.3710 http://www.east.isi.edu/~lorin ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
From: Devin Carlen Here's a few crazy questions for you guys to consider: 1) Why are we even trying to have the same ID for an instance or image across two different APIs? To reduce complexity (particularly when trying to debug the system as a whole). 2) How many people really switch back and forth between OpenStack and EC2 API once they pick one? This will be very common. We're going to have UIs that use the OpenStack API, monitoring systems that use the EC2 API, CLIs using either, all in use on the same cloud, by the same users, at the same time. Also, the multi-zone support is built using the OpenStack API, and the Quantum integration will no doubt use it too, so in reality any use of the EC2 API at all is going to give us a multi-API cloud. 3) How many people really expect euca2ools and python-novatools to return the same IDs for the same instances? It sure would make it a lot easier to debug! 4) Why not just store a EC2 ID and a OS ID alongside an actual row PK? My point with these questions is that very little is gained from forcing two different APIs to try to use the same ID, especially given that the format is different. I would argue that it has created a lot more problems than it has solved. This is certainly a possibility. The problem with this is you have to do the central allocation for the EC2 ID, so you destroy the performance benefits of using a UUID. I could imagine a scheme where the EC2 ID was lazily generated, so you didn't allocate one unless that API was used. That would meet all of _my_ requirements, I think (I'm not sure about anyone else's). The downside with that is it's more complicated, of course. Ewan. Devin On Jul 8, 2011, at 3:12 PM, Soren Hansen wrote: 2011/7/8 Vishvananda Ishaya vishvana...@gmail.com: Yes they seem to apply to all ids r-XXX ami-XXX i-XXX vol-XXX snap-XXX That said we are using base-36 for the hex in reservation ids and no one has complained, so i don't think they are used by the tools that much. Not true. ElasticFox does not work with this. I don't think we're yet at a point where we can say that lack of complaints about stuff means something's fine. That sort of assumption only starts to be useful when we have lots of real users. The users we have so far are people who care about OpenStack for OpenStack's sake, not random users who are being given access to an OpenStack deployment and being told talk to this like you would talk to EC2. It'll work fine. Different expectations. -- Soren Hansen| http://linux2go.dk/ Ubuntu Developer| http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
First, y'all need to remember that it isn't just AWS... it's N systems that back-end OS API over time. Ewan, I understand your intent, but it is a bit myopic: 1) Done right, the only time I need native IDs is when I have a complex situation which needs debugging. It isn't the norm (or if it is, we've failed) -- so really I ONLY need native IDs when it's all gone pear shaped. 2) Multi-API integration is (see point above) a secondary or tertiary set of use cases. Consider using discovery pattern for those integrations rather than trying to shove them as primary into the OS interfaces... which will only end in maddening disaster after you add more than AWS in terms of required support. A general pattern for native discovery in these exception cases needs to be the focus. 3) We fail if we put native debugging capability in front of properly architected and designed OS API semantics 4) Performance benefits? You need to convince me the transaction rate capability is seriously impacted on string vs guid implementations. Sorry, but doubtful. (mea culpa: I am not familiar with implementation details of this context but still..) Look, as an API user... frankly, I don't want to manage complexity across providers. The more OS can insulate me from the details while providing equivalent functionality the better. And quickly, please. I'm rather interested in betting a whole company on an API that groks that value equals maximum insulation from native platforms while giving me 80% plus of capabilities across all native platforms... and APIs to support exploration and integration for the 20% that I invest in. We all need to get out of reactive, myopic, API-to-API-parity mode and into OpenStack centric API capability mode. OpenStack will win on ubiquity of cloud capability not on API/feature parity with whomever is out there. This is my final post on this topic here. I'll be focusing on other topics but I'm glad this gave the opportunity to share the perspective I have and I very much desire further conversation along any dimension at jan_dr...@hotmail.com. I'd value key architects for OS reaching out to me on this and other topics. Jan Drake From: ewan.mel...@eu.citrix.com To: devin.car...@gmail.com; so...@linux2go.dk Date: Mon, 11 Jul 2011 06:43:32 +0100 CC: chris.behr...@rackspace.com; ed.le...@rackspace.com; openstack@lists.launchpad.net Subject: Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort? From: Devin Carlen Here's a few crazy questions for you guys to consider: 1) Why are we even trying to have the same ID for an instance or image across two different APIs? To reduce complexity (particularly when trying to debug the system as a whole). 2) How many people really switch back and forth between OpenStack and EC2 API once they pick one? This will be very common. We're going to have UIs that use the OpenStack API, monitoring systems that use the EC2 API, CLIs using either, all in use on the same cloud, by the same users, at the same time. Also, the multi-zone support is built using the OpenStack API, and the Quantum integration will no doubt use it too, so in reality any use of the EC2 API at all is going to give us a multi-API cloud. 3) How many people really expect euca2ools and python-novatools to return the same IDs for the same instances? It sure would make it a lot easier to debug! 4) Why not just store a EC2 ID and a OS ID alongside an actual row PK? My point with these questions is that very little is gained from forcing two different APIs to try to use the same ID, especially given that the format is different. I would argue that it has created a lot more problems than it has solved. This is certainly a possibility. The problem with this is you have to do the central allocation for the EC2 ID, so you destroy the performance benefits of using a UUID. I could imagine a scheme where the EC2 ID was lazily generated, so you didn't allocate one unless that API was used. That would meet all of _my_ requirements, I think (I'm not sure about anyone else's). The downside with that is it's more complicated, of course. Ewan. Devin On Jul 8, 2011, at 3:12 PM, Soren Hansen wrote: 2011/7/8 Vishvananda Ishaya vishvana...@gmail.com: Yes they seem to apply to all ids r-XXX ami-XXX i-XXX vol-XXX snap-XXX That said we are using base-36 for the hex in reservation ids and no one has complained, so i don't think they are used by the tools that much. Not true. ElasticFox does not work with this. I don't think we're yet at a point where we can say that lack of complaints about stuff means something's fine. That sort of assumption only starts to be useful when we have lots of real users. The users we have so far are people who care about OpenStack
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
1) Done right, the only time I need native IDs is when I have a complex situation which needs debugging. It isn't the norm (or if it is, we've failed) -- so really I ONLY need native IDs when it's all gone pear shaped. Speak for yourself! I debug complex situations every day. Sure, I don't expect my end users to be doing that every day, because I expect to have shipped them production-quality code. For my own sanity, I would like the system as simple as possible. 2) Multi-API integration is (see point above) a secondary or tertiary set of use cases. Consider using discovery pattern for those integrations rather than trying to shove them as primary into the OS interfaces... which will only end in maddening disaster after you add more than AWS in terms of required support. A general pattern for native discovery in these exception cases needs to be the focus. I have no idea what you're trying to say here. Could you try again? 3) We fail if we put native debugging capability in front of properly architected and designed OS API semantics Nobody did, did they? We are all trying very hard to make the OpenStack API the best that it can be. 4) Performance benefits? You need to convince me the transaction rate capability is seriously impacted on string vs guid implementations. Sorry, but doubtful. (mea culpa: I am not familiar with implementation details of this context but still..) No, not string vs guid. Current AWS IDs are 32 bits. Being a small key space, this means that you either need to allocate them incrementally (implying a distributed transaction across the incrementer) or you need to perform a collision detection (implying a distributed transaction across the database, or maybe even all the databases in all the zones). UUIDs, being 128 bits, can be allocated randomly without fear of collisions, which means you can do it even before you've been anywhere near the database. We all need to get out of reactive, myopic, API-to-API-parity mode and into OpenStack centric API capability mode. I don't want the OpenStack API to aim for feature parity with the AWS API. I said that elsewhere in this thread. I don't think anyone who's working on the OpenStack API wants that. We all agree that the OpenStack API is there so that we can innovate around the API, and add new features to the platform as quickly as possible. That's a primary goal for the whole project. All we're trying to do is to figure out a way to do that while leveraging a large ecosystem of existing tools, so that people can get onto OpenStack as painlessly as possible. Cheers, Ewan. From: Jan Drake [mailto:jan_dr...@hotmail.com] Sent: 11 July 2011 01:44 To: Ewan Mellor; devin.car...@gmail.com; so...@linux2go.dk Cc: chris.behr...@rackspace.com; ed.le...@rackspace.com; openstack@lists.launchpad.net Subject: RE: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort? First, y'all need to remember that it isn't just AWS... it's N systems that back-end OS API over time. Ewan, I understand your intent, but it is a bit myopic: 1) Done right, the only time I need native IDs is when I have a complex situation which needs debugging. It isn't the norm (or if it is, we've failed) -- so really I ONLY need native IDs when it's all gone pear shaped. 2) Multi-API integration is (see point above) a secondary or tertiary set of use cases. Consider using discovery pattern for those integrations rather than trying to shove them as primary into the OS interfaces... which will only end in maddening disaster after you add more than AWS in terms of required support. A general pattern for native discovery in these exception cases needs to be the focus. 3) We fail if we put native debugging capability in front of properly architected and designed OS API semantics 4) Performance benefits? You need to convince me the transaction rate capability is seriously impacted on string vs guid implementations. Sorry, but doubtful. (mea culpa: I am not familiar with implementation details of this context but still..) Look, as an API user... frankly, I don't want to manage complexity across providers. The more OS can insulate me from the details while providing equivalent functionality the better. And quickly, please. I'm rather interested in betting a whole company on an API that groks that value equals maximum insulation from native platforms while giving me 80% plus of capabilities across all native platforms... and APIs to support exploration and integration for the 20% that I invest in. We all need to get out of reactive, myopic, API-to-API-parity mode and into OpenStack centric API capability mode. OpenStack will win on ubiquity of cloud capability not on API/feature parity with whomever is out there. This is my final post on this topic here. I'll be focusing on other topics but I'm glad this gave the opportunity to share the perspective I have
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
2011/7/11 Ewan Mellor ewan.mel...@eu.citrix.com: No, not string vs guid. Current AWS IDs are 32 bits. Being a small key space, this means that you either need to allocate them incrementally (implying a distributed transaction across the incrementer) This is only a real problem if you insist on generating them in real time rather than pre-allocate them. Each compute node could have pool of thousands of ID's it could use as it pleased. That would still allow for millions of compute nodes. The ID's could be centrally assigned. Even if the central component that hands them out goes away, a couple of thousand ID's should provide ample time for a replacement to be spun up (or for the original one to come back). or you need to perform a collision detection (implying a distributed transaction across the database, or maybe even all the databases in all the zones). Yeah, that would suck. -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
Ugh, sorry, burned again by outlook web. Let me continue ... I'm still stewing on this but at first blush this seems like an artificial abstraction. What do we really gain from having another layer above the service api's? Can't they just live at the service api? For example: nova.compute.api:create_instance() vs. nova.business_layer:create_instance() What's the real win here? I agree that the heavy lifting logic should be removed from the os/ec2 api layers and only be doing parameter checking ... but they may also do mapping/translations to the underlying service api's. Perhaps the issue is that the lower level (nova.[service].api) doesn't have a formal enough definition and is getting pulled in two directions by ec2/os api? Perhaps making this layer have a clear contract is what we're missing? -S From: Lorin Hochstein [lo...@isi.edu] I think it actually looks more like this right now: EC2 Client OS Client | | EC2 APIOS API \ / [nova-*] service APIs There isn't really a single back-end API for the front-end APIs to call into. Instead, each of them makes calls to the multiple service APIs (e.g., scheduler, network, compute). I would advocate for something more like this: EC2 Client OS Client | | EC2 APIOS API \ / internal nova API | [nova-*] service APIs This is a single, unified API that is meant only for internal use. This would reduce the coupling between front-end and back-end. It would make it easier for someone with less expertise in the code (hello!) to find the location in the code that answers questions like: What does nova do when a user requests that an instance is launched? They would just look at the internal API and find the appropriate method. It would also make it easier to add additional front-ends, if there's ever any interest in that. This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
On Mon, Jul 11, 2011 at 12:27:16PM +0200, Soren Hansen wrote: 2011/7/11 Ewan Mellor ewan.mel...@eu.citrix.com: No, not string vs guid. Current AWS IDs are 32 bits. Being a small key space, this means that you either need to allocate them incrementally (implying a distributed transaction across the incrementer) This is only a real problem if you insist on generating them in real time rather than pre-allocate them. Each compute node could have pool of thousands of ID's it could use as it pleased. That would still allow for millions of compute nodes. The ID's could be centrally assigned. Even if the central component that hands them out goes away, a couple of thousand ID's should provide ample time for a replacement to be spun up (or for the original one to come back). This assumes you still have something you can call central. What about hybrid or peer-to-peer clouds? Does each zone get assigned a ID allocator service? Each account? What if it is behind a firewall but I have public cloud bursting and don't want to open it up? I think we need to use a completely distributed solution and just let EC2 be second class, requiring a local, centralized mapping service per endpoint (or endpoint cluster) if you really want to use it. This will provide more incentive for folks to move to the OS API, support the OS API in popular tools and services, and develop new (and hopefully better) tools for it. Just my thoughts, -Eric ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
2011/7/11 Eric Day e...@oddments.org: On Mon, Jul 11, 2011 at 12:27:16PM +0200, Soren Hansen wrote: 2011/7/11 Ewan Mellor ewan.mel...@eu.citrix.com: No, not string vs guid. Current AWS IDs are 32 bits. Being a small key space, this means that you either need to allocate them incrementally (implying a distributed transaction across the incrementer) This is only a real problem if you insist on generating them in real time rather than pre-allocate them. Each compute node could have pool of thousands of ID's it could use as it pleased. That would still allow for millions of compute nodes. The ID's could be centrally assigned. Even if the central component that hands them out goes away, a couple of thousand ID's should provide ample time for a replacement to be spun up (or for the original one to come back). This assumes you still have something you can call central. What about hybrid or peer-to-peer clouds? How would you share these keyspaces anyway (be they uuid, arbitratry strings, urls, 32 bit integers, whateveR)? You can only rely on their global uniqueness if you actually trust the entities generating them. -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
1) Done right, the only time I need native IDs is when I have a complex situation which needs debugging. It isn't the norm (or if it is, we've failed) -- so really I ONLY need native IDs when it's all gone pear shaped. As the human presentation interface, sure, but the *automated* control surfaces under the hood shouldn't be using 32-bit ids that break when you cross zones or zones change. nova-compute service shouldn't know what a zone is other than a membership in one-or-more RabbitMQ topics. Look, as an API user... frankly, I don't want to manage complexity across providers. The more OS can insulate me from the details while providing equivalent functionality the better. And quickly, please. Agreed. I don't want to know the underlying structure of every provider. I've had trouble understanding the notion of zones where I have to programmatically traverse a provider's datacenter like company.com/country/state/datacenter/floor/row/rack/shelf/blade/vm. Sure, this is good for datacenter maintenance, but I *never* want to see it as a customer. From this perspective, the EC2 API has a better customer abstraction. - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com ph: 443-274-6064 fx: 443-274-6060 smime.p7s Description: S/MIME cryptographic signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
Perhaps. That sometimes happens when trying to make a very nuanced point :-). I spent a lot of time hacking at nova-compute and the schemas for the heterogeneous instance types blueprint and noticed a lot of EC2-isms buried down in the code. Even though I've been using the EC2 interface mostly and want to extend OpenStack EC2 interface support for things like cluster compute instances, I think that the low-level nova-compute service should have a higher level of abstraction about compute resources and virtual machine instances. Pushing the OS API constraints clear down to the libvirt level and breaking EC2 is as bad as those EC2isms currently in the code. We're in general agreement that a single auto-increment identifier doesn't scale and isn't robust. Partitioning the integer instance ids number space doesn't work if you ever expect to reconfigure your zones, merge two clouds, or do anything else that potentially causes integer partitioning to go catastrophic. Suppose company A purchases company B and both deployments starting counting instances ids from 1. Can you merge them without B customers losing their running instances? You could if all openstack deployments use UUID for object identifiers. Unless you want to go the IPv4 route Two big complaints in recent threads about using UUIDs for instance ids has been that 1) long strings look bad in the RESTful OS API, and 2) EC2 is only using integers how do we map, which devolved into do we really need EC2 support? My question is: Why should the internal IDs used by nova-compute, nova-network, etc. to reference instance objects for VMs, volumes, network endpoints, etc. be dictated by what a human sees? The mapping from long-form UUID to short form integer/string that the user sees is a problem for the OS/EC2 (and others if ever developed) presentation layer. All of the internal orchestration/control logic should be using UUID exclusively. Maybe the first-8 approach would work in both EC2 and OS API interfaces. In the highly unlikely collision case where two different users get short-form ID i-abcdefgh from the API service, the API service resolves the ambiguity based on other context information in the call (user-id, tag/name/label, state, ...). - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com ph: 443-274-6064 fx: 443-274-6060 On Jul 11, 2011, at 1:05 AM, Jan Drake wrote: Brian, your two posts seem at odds with each other. So, I've got this completely external view and possibly my own particular skew on the vision for OpenStack... specifically, I want it to isolate me from provider as much as possible. Either I'm going to use AWS compatible interfaces for a provider or OpenStack and one has to win in the long run... okay, maybe not, maybe two co-exist as presentation layers for an internal cloud engine that's extensible middleware or some similar model. Regardless, I want OpenStack API to run anywhere for any provider so I can choose from a marketplace of providers and have more than one PROVIDER for HA/DR reasons. I also use the right tool for the job but when it comes to entire classes of APIs I'm going to make a business choice and... well, I'll tell ya... I'm not going to write for each provider if I can avoid it... I'm going to pick one. I want that one to end up being OpenStack with a fan-out to whatever provider fills in the back-end (common design pattern here). I use the right tool for the right job as well, like you mentioned in your prior post; however, I pick and make investments in platform APIs which is what OpenStack, IMNSHO, aspires to be. I'm curious whether the product managers/owners involved think the focus should be on AWS API compatibility or whether it should be about OpenStack functionality compatibly executed on the AWS platform. In my opinion OpenStack shouldn't be trying to be Euca and a Euca/AWS-compatible presentation layer to OpenStack is interesting but not terribly strategic. The market is still emergent and the enterprise is the big win so... I'd let tool-switchers switch to a new, better, OS API set rather than trying to backfill a presentation layer for existing SMB market on AWS. I'd think the Highlander approach: There can be only one, in terms of API set, is what we'd be striving for. Not that I, like, have an opinion or anything. ;) Jan Drake From: brian.sch...@nimbisservices.com Date: Sun, 10 Jul 2011 22:53:45 -0400 To: devin.car...@gmail.com CC: openstack@lists.launchpad.net Subject: Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort? Devin, agree with you 100% that the EC2 and OS APIs are presentation/view layer. I also think that there is way too much view/control and policy dependencies buried down in the core nova-* services. The core services like
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
On Jul 11, 2011, at 11:28 AM, Eric Day wrote: This is only a real problem if you insist on generating them in real time rather than pre-allocate them. Each compute node could have pool of thousands of ID's it could use as it pleased. That would still allow for millions of compute nodes. The ID's could be centrally assigned. Even if the central component that hands them out goes away, a couple of thousand ID's should provide ample time for a replacement to be spun up (or for the original one to come back). This assumes you still have something you can call central. What about hybrid or peer-to-peer clouds? Does each zone get assigned a ID allocator service? Each account? What if it is behind a firewall but I have public cloud bursting and don't want to open it up? The notion of a partitioning of potential IDs was considered and rejected in favor of using UUIDs. The notion of a central repository was considered and rejected in favor of a 'shared nothing' approach to distributed zones. I'd like to keep this discussion focused on moving from where we are today to where we'd like to be. Right now we have UUIDs as the primary key for instances, as well as sequential integer IDs that are unique within a zone. The code base was changed to only use UUIDs at inter-zone boundaries, and preserve the practice of basing the EC2 ID on the instance's integer ID, effectively relegating EC2 to single-zone deployments only. The only question that needs to be considered is where do we move from here? Do we accept the limitation that the EC2 API and any tool which relies upon that will be only available for single-zone deployments, and if you want distributed zones, you must use the OS API? Or do we reconsider the hybrid UUID/integer zone design, and move to a full UUID design? If we decide to move to a full UUID design with EC2 API as a first-class citizen, then we have the question of how to represent the 32-character UUID in the 8-character EC2 ID format. Our choices there are: 1) Use the full 32 chars, and let the tools that assume 8 chars break. 2) Use the first 8 chars, and accept an occasional duplicate ID. 3) Use the first 8 chars, but add duplication checking. -- Ed Leafe This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
Ed, Thanks for the succinct summary. On Jul 11, 2011, at 12:05 PM, Ed Leafe wrote: If we decide to move to a full UUID design with EC2 API as a first-class citizen, then we have the question of how to represent the 32-character UUID in the 8-character EC2 ID format. Our choices there are: 1) Use the full 32 chars, and let the tools that assume 8 chars break. -1 bad for existing tool compatibility, probably a waste of time 2) Use the first 8 chars, and accept an occasional duplicate ID. +1 this will be incredibly rare, just return an API error if request is ambiguous 3) Use the first 8 chars, but add duplication checking. +1 no duplication checking on UUID creation (this breaks UUID benefits), but try to resolve the ambiguity in the API service handler when processing the call. If you filter on user permissions to the instance and the probability of collision plummets. You have to authenticate the user credentials anyway, right? The probability that the same user will have an internal collision in his own pool of instances is very small. - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com ph: 443-274-6064 fx: 443-274-6060 smime.p7s Description: S/MIME cryptographic signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
At the risk of making things more complicated, we should anticipate an eventual Cloud API standard which could be any solution from EC2/OpenStack/OCCI/... and a set of legacy interfaces for backwards compatibility. This, as far as I see, pushes us strongly towards the multiple APIs as a presentation layer and a backend which is relatively flexible (as we also can adapt the presentation layers to convert if required without impacting the clients). Some interfaces, such as the OpenStack one could be relatively light and the additional business logic of mapping/transforming added to the other interfaces as required. Tim Bell CERN ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
Ahhh.. OK. The namespace is embedded in the instance ID depending on the type, so it should be sufficient to: GET /servers/instance uuid Regardless, uuid is sufficient and globally unique. This doesn't consider authentication. I'd assumed that username and realm and the like had been handled by REST-based authentication and would be available to the API service. - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com ph: 443-274-6064 fx: 443-274-6060 On Jul 11, 2011, at 2:04 PM, Eric Day wrote: On Mon, Jul 11, 2011 at 05:17:05PM +, Sandy Walsh wrote: How is nova-account-instance uuid any different than: ---- Where // (or some subset of them) are reserved/regulated? Nothing, if -- is a full UUID. If we compare to swift, the account prefix is a UUID too. The account prefix could be fixed for a session or passed in to every request depending on how things are decided. For example: GET /servers/account id/instance uuid where account ID could be a domain, uuid, etc. Another way to pass the namespace is through part of the token: GET /servers/instance uuid Token: token tied to a specific account The latter is simpler but less flexible since it may not allow for operations on instances outside of the account the token was created for. I'm a bit out of the loop on those type of API decisions right now, so I'll stop there. :) -Eric ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp smime.p7s Description: S/MIME cryptographic signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
On Mon, Jul 11, 2011 at 05:17:05PM +, Sandy Walsh wrote: How is nova-account-instance uuid any different than: ---- Where // (or some subset of them) are reserved/regulated? Nothing, if -- is a full UUID. If we compare to swift, the account prefix is a UUID too. The account prefix could be fixed for a session or passed in to every request depending on how things are decided. For example: GET /servers/account id/instance uuid where account ID could be a domain, uuid, etc. Another way to pass the namespace is through part of the token: GET /servers/instance uuid Token: token tied to a specific account The latter is simpler but less flexible since it may not allow for operations on instances outside of the account the token was created for. I'm a bit out of the loop on those type of API decisions right now, so I'll stop there. :) -Eric ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
Eric, I've heard this argument before, but I don't understand how account can't be injected as well to cause collisions. UUIDs can't be trusted when user generated. As long as the UUIDs are generated consistently across all OpenStack deployments (using the same UUID type and consistent policy on any input parameters) they could be globally unique for all time (in the long term, we're all dead, so close enough). So, nova-uuid is sufficient. On Jul 11, 2011, at 12:42 PM, Eric Day wrote: Agreed, anyone could inject UUIDs that collide. UUIDs alone are not sufficient, you need a namespace prefix as well (something I brought up many times before on other ID threads). The full ID needs to be something like: nova-account-instance uuid Or something along those lines (service and account/namespace can be another part of a URL, it doesn't need to be the ID string itself). Swift already does this (account/container/object), so we have a pretty good example to follow here. - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com ph: 443-274-6064 fx: 443-274-6060 smime.p7s Description: S/MIME cryptographic signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
+1 I think the work really lives with formalizing the contracts at the nova.[service].api level and pushing the discrepancies into the respective public API's. -S From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net [openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of Tim Bell [tim.b...@cern.ch] Sent: Monday, July 11, 2011 2:38 PM To: Soren Hansen; Eric Day Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort? At the risk of making things more complicated, we should anticipate an eventual Cloud API standard which could be any solution from EC2/OpenStack/OCCI/... and a set of legacy interfaces for backwards compatibility. This, as far as I see, pushes us strongly towards the multiple APIs as a presentation layer and a backend which is relatively flexible (as we also can adapt the presentation layers to convert if required without impacting the clients). Some interfaces, such as the OpenStack one could be relatively light and the additional business logic of mapping/transforming added to the other interfaces as required. Tim Bell CERN ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
Hi Brian, I think there may be a disconnect somewhere, perhaps we have different deployments in mind or something. In my opinion, it seems we should take the fully distributed, multi-tentant route to allow peering of deployments. So whether we use UUIDs or not, the goal is to: * Have account level namespaces. * Don't have a central authority handing out resource IDs. If you have a global namespace for a service, and anyone can peer with that service (combining global namespaces for each peer), you can purposefully create a collision. If you have account namspaces for a service, and anyone can peer with that service (combining each account namespace for each peer), you can only create collisions within a single account. With the former, you don't need access to my account to create a collision with one of my resources. With the latter, I don't need to worry about collisions from you if you don't have access to my account. Collisions are still possible within an account, so we still need to handle this case, but at least you can limit the potential damage to your account, not other tenants of the service. If this deployment is what you had in mind, please describe how a single non-centrally generated UUID could still give account-level protections. -Eric On Mon, Jul 11, 2011 at 02:09:05PM -0400, Brian Schott wrote: Eric, I've heard this argument before, but I don't understand how account can't be injected as well to cause collisions. UUIDs can't be trusted when user generated. As long as the UUIDs are generated consistently across all OpenStack deployments (using the same UUID type and consistent policy on any input parameters) they could be globally unique for all time (in the long term, we're all dead, so close enough). So, nova-uuid is sufficient. On Jul 11, 2011, at 12:42 PM, Eric Day wrote: Agreed, anyone could inject UUIDs that collide. UUIDs alone are not sufficient, you need a namespace prefix as well (something I brought up many times before on other ID threads). The full ID needs to be something like: nova-account-instance uuid Or something along those lines (service and account/namespace can be another part of a URL, it doesn't need to be the ID string itself). Swift already does this (account/container/object), so we have a pretty good example to follow here. - Brian Schott, CTO Nimbis Services, Inc. brian.sch...@nimbisservices.com ph: 443-274-6064 fx: 443-274-6060 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
On Jul 11, 2011, at 2:04 PM, Eric Day wrote: How is nova-account-instance uuid any different than: ---- Where // (or some subset of them) are reserved/regulated? Nothing, if -- is a full UUID. If we compare to swift, the account prefix is a UUID too. The account prefix could be fixed for a session or passed in to every request depending on how things are decided. sigh It's a shame that the ipv6 proposal was never more fully considered. That would handle the uniqueness, with the added benefit of providing simple zone routing via DNS, with the exact same 128-bit/32 char size. -- Ed Leafe This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
On Jul 11, 2011, at 12:01 PM, Ed Leafe wrote: On Jul 11, 2011, at 2:04 PM, Eric Day wrote: How is nova-account-instance uuid any different than: ---- Where // (or some subset of them) are reserved/regulated? Nothing, if -- is a full UUID. If we compare to swift, the account prefix is a UUID too. The account prefix could be fixed for a session or passed in to every request depending on how things are decided. sigh It's a shame that the ipv6 proposal was never more fully considered. That would handle the uniqueness, with the added benefit of providing simple zone routing via DNS, with the exact same 128-bit/32 char size. I don't I remember that proposal, but that's such a neat idea. Was anything discussed at all in Santa Clara regarding encoding zone information in the instance identifier? I apparently missed the instance identifier discussion somehow. - Chris This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
Won't an IPv6 address do that by it's very nature? -S From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net [openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of Chris Behrens [chris.behr...@rackspace.com] Sent: Monday, July 11, 2011 4:24 PM To: Ed Leafe Cc: openstack@lists.launchpad.net; Chris Behrens Subject: Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort? On Jul 11, 2011, at 12:01 PM, Ed Leafe wrote: On Jul 11, 2011, at 2:04 PM, Eric Day wrote: How is nova-account-instance uuid any different than: ---- Where // (or some subset of them) are reserved/regulated? Nothing, if -- is a full UUID. If we compare to swift, the account prefix is a UUID too. The account prefix could be fixed for a session or passed in to every request depending on how things are decided. sigh It's a shame that the ipv6 proposal was never more fully considered. That would handle the uniqueness, with the added benefit of providing simple zone routing via DNS, with the exact same 128-bit/32 char size. I don't I remember that proposal, but that's such a neat idea. Was anything discussed at all in Santa Clara regarding encoding zone information in the instance identifier? I apparently missed the instance identifier discussion somehow. - Chris This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
On Jul 11, 2011, at 12:37 PM, Ed Leafe wrote: On Jul 11, 2011, at 3:24 PM, Chris Behrens wrote: It's a shame that the ipv6 proposal was never more fully considered. That would handle the uniqueness, with the added benefit of providing simple zone routing via DNS, with the exact same 128-bit/32 char size. I don't I remember that proposal, but that's such a neat idea. Was anything discussed at all in Santa Clara regarding encoding zone information in the instance identifier? I apparently missed the instance identifier discussion somehow. At the end of the instance referencing discussion, Van Lindbergh brought up the idea. We discussed it with several people both in the conference room and over lunch. I believe that the main objections were that not everyone would have an IPv6 creation scheme, whereas UUID generators are ubiquitous. The other was a vague concern Ya, I was guessing that would be a concern. Doesn't seem like a huge deal, since everyone should be moving towards ipv6 only anyway. I could see some objections raised if you didn't want any sort of public network interface at all... but you could still assign an unused address. about revealing internal structure, but since the information revealed would be the exact same info in the instance's public network info, it didn't strike me as a serious concern. Right. As long as there is a public network interface, people are going to be able to figure out at least some part of 'internal structure'. - Chris This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
We did discuss using IPV6 addresses as IDs months ago (IRC and email), but I don't remember why we decided not to. It may have been due to current adoption. I think it was pvo who originally had the idea. -Eric On Mon, Jul 11, 2011 at 07:24:39PM +, Chris Behrens wrote: On Jul 11, 2011, at 12:01 PM, Ed Leafe wrote: On Jul 11, 2011, at 2:04 PM, Eric Day wrote: How is nova-account-instance uuid any different than: ---- Where // (or some subset of them) are reserved/regulated? Nothing, if -- is a full UUID. If we compare to swift, the account prefix is a UUID too. The account prefix could be fixed for a session or passed in to every request depending on how things are decided. sigh It's a shame that the ipv6 proposal was never more fully considered. That would handle the uniqueness, with the added benefit of providing simple zone routing via DNS, with the exact same 128-bit/32 char size. I don't I remember that proposal, but that's such a neat idea. Was anything discussed at all in Santa Clara regarding encoding zone information in the instance identifier? I apparently missed the instance identifier discussion somehow. - Chris This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
If you're referring to encoding zone information, yes it would. I was trying to ask more generally as well. IPv6 would be a very good solution, IMO. - Chris On Jul 11, 2011, at 12:47 PM, Sandy Walsh wrote: Won't an IPv6 address do that by it's very nature? -S From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net [openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of Chris Behrens [chris.behr...@rackspace.com] Sent: Monday, July 11, 2011 4:24 PM To: Ed Leafe Cc: openstack@lists.launchpad.net; Chris Behrens Subject: Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort? On Jul 11, 2011, at 12:01 PM, Ed Leafe wrote: On Jul 11, 2011, at 2:04 PM, Eric Day wrote: How is nova-account-instance uuid any different than: ---- Where // (or some subset of them) are reserved/regulated? Nothing, if -- is a full UUID. If we compare to swift, the account prefix is a UUID too. The account prefix could be fixed for a session or passed in to every request depending on how things are decided. sigh It's a shame that the ipv6 proposal was never more fully considered. That would handle the uniqueness, with the added benefit of providing simple zone routing via DNS, with the exact same 128-bit/32 char size. I don't I remember that proposal, but that's such a neat idea. Was anything discussed at all in Santa Clara regarding encoding zone information in the instance identifier? I apparently missed the instance identifier discussion somehow. - Chris This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
I kind of like the IPv6 idea myself. How would it work with a service provider that, for example, assigns a /96 address for an instance? If the user can change the IP address, would that mean that the instance ID would change as well? Or should we just keep with the original /96 (::0) address? On 7/11/11 2:57 PM, Chris Behrens chris.behr...@rackspace.com wrote: If you're referring to encoding zone information, yes it would. I was trying to ask more generally as well. IPv6 would be a very good solution, IMO. - Chris On Jul 11, 2011, at 12:47 PM, Sandy Walsh wrote: Won't an IPv6 address do that by it's very nature? -S From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net [openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of Chris Behrens [chris.behr...@rackspace.com] Sent: Monday, July 11, 2011 4:24 PM To: Ed Leafe Cc: openstack@lists.launchpad.net; Chris Behrens Subject: Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort? On Jul 11, 2011, at 12:01 PM, Ed Leafe wrote: On Jul 11, 2011, at 2:04 PM, Eric Day wrote: How is nova-account-instance uuid any different than: ---- Where // (or some subset of them) are reserved/regulated? Nothing, if -- is a full UUID. If we compare to swift, the account prefix is a UUID too. The account prefix could be fixed for a session or passed in to every request depending on how things are decided. sigh It's a shame that the ipv6 proposal was never more fully considered. That would handle the uniqueness, with the added benefit of providing simple zone routing via DNS, with the exact same 128-bit/32 char size. I don't I remember that proposal, but that's such a neat idea. Was anything discussed at all in Santa Clara regarding encoding zone information in the instance identifier? I apparently missed the instance identifier discussion somehow. - Chris This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
On Jul 11, 2011, at 4:03 PM, Glen Campbell wrote: I kind of like the IPv6 idea myself. How would it work with a service provider that, for example, assigns a /96 address for an instance? If the user can change the IP address, would that mean that the instance ID would change as well? Or should we just keep with the original /96 (::0) address? The PK for the instance would be the /96 (::0) address. -- Ed Leafe This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
What happens when you've shared the primary IPv6 address of a VM with another VM? To which VM does the primary key point to? I think overloading the IPv6 address to also mean the primary key is probably a mistake that will cause serious trouble with network-as-a-service portability. -C On Mon, Jul 11, 2011 at 1:03 PM, Glen Campbell glen.campb...@rackspace.comwrote: I kind of like the IPv6 idea myself. How would it work with a service provider that, for example, assigns a /96 address for an instance? If the user can change the IP address, would that mean that the instance ID would change as well? Or should we just keep with the original /96 (::0) address? On 7/11/11 2:57 PM, Chris Behrens chris.behr...@rackspace.com wrote: If you're referring to encoding zone information, yes it would. I was trying to ask more generally as well. IPv6 would be a very good solution, IMO. - Chris On Jul 11, 2011, at 12:47 PM, Sandy Walsh wrote: Won't an IPv6 address do that by it's very nature? -S From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net [openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of Chris Behrens [chris.behr...@rackspace.com] Sent: Monday, July 11, 2011 4:24 PM To: Ed Leafe Cc: openstack@lists.launchpad.net; Chris Behrens Subject: Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort? On Jul 11, 2011, at 12:01 PM, Ed Leafe wrote: On Jul 11, 2011, at 2:04 PM, Eric Day wrote: How is nova-account-instance uuid any different than: ---- Where // (or some subset of them) are reserved/regulated? Nothing, if -- is a full UUID. If we compare to swift, the account prefix is a UUID too. The account prefix could be fixed for a session or passed in to every request depending on how things are decided. sigh It's a shame that the ipv6 proposal was never more fully considered. That would handle the uniqueness, with the added benefit of providing simple zone routing via DNS, with the exact same 128-bit/32 char size. I don't I remember that proposal, but that's such a neat idea. Was anything discussed at all in Santa Clara regarding encoding zone information in the instance identifier? I apparently missed the instance identifier discussion somehow. - Chris This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Christopher MacGown Piston Cloud Computing, Inc. (415) 300-0944 ch...@piston.cc ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
On Jul 11, 2011, at 4:21 PM, Christopher MacGown wrote: What happens when you've shared the primary IPv6 address of a VM with another VM? To which VM does the primary key point to? I think overloading the IPv6 address to also mean the primary key is probably a mistake that will cause serious trouble with network-as-a-service portability. When each instance is created, it is assigned a unique IPv6 /96 address. The ::0 is then assigned to the PK for that instance. If you later change the network address of the instance, its PK doesn't change. Also, isn't shared IPs a thing of the past with IPv6? I thought we weren't going to be supporting that in nova. -- Ed Leafe This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
[Snip summary] The only question that needs to be considered is where do we move from here? Do we accept the limitation that the EC2 API and any tool which relies upon that will be only available for single-zone deployments, and if you want distributed zones, you must use the OS API? Up to now, I have assumed that zones would be used as the construct that isolated different service offerings, e.g. VMware vs XenServer or 10G networking versus 1G, or whatever. Zones therefore play two roles: they give you the architecture for large-scale deployments, and they also allow for distinguished service offerings. Are you thinking along these lines? If so, then I would say that your proposed limitation above is not acceptable. We don't want a situation where tenants have to stop using the EC2 API as soon as their service provider wants to offer a rich set of offerings. Cheers, Ewan. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
2011/7/11 Ed Leafe ed.le...@rackspace.com: On Jul 11, 2011, at 2:04 PM, Eric Day wrote: It's a shame that the ipv6 proposal was never more fully considered. That would handle the uniqueness, with the added benefit of providing simple zone routing via DNS, with the exact same 128-bit/32 char size. I can think of a number of reasons why using ipv6 addresses are a bad idea. 1. They only naturally map to VM's. Using them for any other object types seems artifical (why would a snapshot need an ipv6 address?) 2. One of the reasons UUID's were chosen was because it gave us a gigantic key space that made collisions unlikely enough that we needn't worry about them. If you use ipv6 addressses as your ID's, you're limited to the part of the ipv6 address space you've been assigned (rather than the full 128 bit key space). I realise /64's are pretty commonplace, but collisions are ~10 orders of magnitudes more likely in a /64 keyspace than they are in a /128. 3. You'd never be able to recycle IP's. UUID's are (and EC2 ID's are said to be) perpetually unique. They do not get recycled. If an instance's ipv6 address is its instance ID, you'll have to either live with your pool of ipv6 addresses slowly depleting (even though their corresponding instances have been deleted) or recycle the instance ID's (and hence IP's). Neither of those options seem very cool. -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
Den 11/07/2011 19.08 skrev Brian Schott brian.sch...@nimbisservices.com: On Jul 11, 2011, at 12:05 PM, Ed Leafe wrote: 2) Use the first 8 chars, and accept an occasional duplicate ID. +1 this will be incredibly rare, just return an API error if request is ambiguous 3) Use the first 8 chars, but add duplication checking. +1 no duplication checking on UUID creation (this breaks UUID benefits), but try to resolve the ambiguity in the API service handler when processing the call. This would mean you'd have to perfrom collision checking on every single API call except the create calls. I think it's a reasonably fair assumption that you'll be querying/performing actions on existing objects much more often than you'll create new ones, so that's much, much worse than just doing it at create time. -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
I'd add a fairly fundamental rule of ID design is that ID should never, ever have any meaning except to serve as identifiers. The minute you tie them to IPv6 values, you are giving them meaning. On Jul 11, 2011, at 6:49 PM, Soren Hansen wrote: 2011/7/11 Ed Leafe ed.le...@rackspace.com: On Jul 11, 2011, at 2:04 PM, Eric Day wrote: It's a shame that the ipv6 proposal was never more fully considered. That would handle the uniqueness, with the added benefit of providing simple zone routing via DNS, with the exact same 128-bit/32 char size. I can think of a number of reasons why using ipv6 addresses are a bad idea. 1. They only naturally map to VM's. Using them for any other object types seems artifical (why would a snapshot need an ipv6 address?) 2. One of the reasons UUID's were chosen was because it gave us a gigantic key space that made collisions unlikely enough that we needn't worry about them. If you use ipv6 addressses as your ID's, you're limited to the part of the ipv6 address space you've been assigned (rather than the full 128 bit key space). I realise /64's are pretty commonplace, but collisions are ~10 orders of magnitudes more likely in a /64 keyspace than they are in a /128. 3. You'd never be able to recycle IP's. UUID's are (and EC2 ID's are said to be) perpetually unique. They do not get recycled. If an instance's ipv6 address is its instance ID, you'll have to either live with your pool of ipv6 addresses slowly depleting (even though their corresponding instances have been deleted) or recycle the instance ID's (and hence IP's). Neither of those options seem very cool. -- Soren Hansen| http://linux2go.dk/ Ubuntu Developer| http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comt: @GeorgeReesep: +1.207.956.0217f: +1.612.338.5041 enStratus: Governance for Public, Private, and Hybrid Clouds - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese smime.p7s Description: S/MIME cryptographic signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
-Original Message- From: Sandy Walsh [mailto:sandy.wa...@rackspace.com] Sent: 11 July 2011 17:10 To: Ewan Mellor; Ed Leafe; Eric Day Cc: openstack@lists.launchpad.net Subject: RE: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort? From: Ewan Mellor [ewan.mel...@eu.citrix.com] If so, then I would say that your proposed limitation above is not acceptable. We don't want a situation where tenants have to stop using the EC2 API as soon as their service provider wants to offer a rich set of offerings. Hmm, two concerns here: 1. What's the alternative? Should we embrace and extend EC2 API to ensure compatibility with OS API? No, I was expecting that we could squeeze this through the existing EC2 API. The service provider could have instance types that mapped to service offerings: superfastnetworking.large or xenserver.medium or whatever, as opposed to EC2's m1.small, etc. I hope that most clients are written expecting the instance types to change over time (Amazon have added instance types themselves in the past). Embrace and extend definitely isn't going to work. You can only do that if you are the big guy. Little old OpenStack won't be able to bully the EC2 ecosystem. 2. Could we not have plain vanilla EC2 at the top-level zone and do all the funky stuff under the hood, mapping EC2 artifacts to OS artifacts as needed? If EC2 wants 8-character with a prefix, we can map it to our UUID's across Zones, but with obvious limitations. If EC2 runs out of space in their identifiers, that's that. Either start using the OS API or use a new shard. We play the game ... to a point. When it no longer makes sense we don't try to put a square peg in a round hole. Same argument goes for OCCI, Bob's Cloud Mart and whatever other API's show up down the road. At first blush I don't think there's really any reason why we can't make the top-level Zone look and feel like an EC2 deployment? I'm not close enough to the code to make an assessment, but I agree with you. At first blush, it doesn't look like it should be impossible. Having EC2 API (even 80% compatible) allows them to dip their toes in the water without a large engineering effort to re-tool. Ideally, re- point their URL to a Nova install and play around. If they like what they see, they can slowly migrate away from the limitations of the EC2 world and join the party. This was the Nova vision all along, no? Incremental development vs. boil-the-ocean. As a consumer of cloud services, that sounds like a pretty compelling argument to me. I agree 100%. This is what I want. Ewan. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
-Original Message- From: openstack-bounces+ewan.mellor=citrix@lists.launchpad.net [mailto:openstack-bounces+ewan.mellor=citrix@lists.launchpad.net] On Behalf Of Ed Leafe Sent: 11 July 2011 16:39 To: openstack@lists.launchpad.net Subject: Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort? On Jul 11, 2011, at 6:46 PM, Ed Leafe wrote: If so, then I would say that your proposed limitation above is not acceptable. We don't want a situation where tenants have to stop using the EC2 API as soon as their service provider wants to offer a rich set of offerings. That was my working premise, too, but the decision was made within Rackspace to not spend time on EC2 support for zones since we use the OS API exclusively, so my hands were tied. Wait, that didn't sound right. What I should have said is that the decision was made within *my team* at Rackspace, not by Rackspace as a whole. Our team's job is to make sure that everything is implemented in nova that we will need to switch our code base, and since the EC2 API isn't one of those things, it was decided not to spend any time on it. That doesn't mean that we wouldn't love someone for whom EC2 compatibility matters to add it in; it just means that it isn't going to be us. ;-) Well, as long as it's not precluded by design choices that you're making, then someone else can pick up the work and finish the job. No-one expects Rackspace to do _everything_ -- that's what the other (*checks ever increasing counters on openstack.org*) 82 companies and 1150 people are here for! Ewan. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
I agree that implementing a perfect EC2 simulator would be hard. We shouldn't try and do that. We should have an EC2-compatible API for a sensible feature-set, but we shouldn't try and add support for every new feature that Amazon adds. The value of this API is that EC2-compatible tools can be used against OpenStack. That doesn't mean that we're trying to make a drop-in replacement for EC2, including all its new features. You're right that that would be very hard, and we shouldn't try. Ewan. -Original Message- From: openstack-bounces+ewan.mellor=citrix@lists.launchpad.net [mailto:openstack-bounces+ewan.mellor=citrix@lists.launchpad.net] On Behalf Of George Reese Sent: 09 July 2011 07:49 To: Sandy Walsh Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort? The other piece of the puzzle is that it is very easy to keep a client consistent with the API; it's very hard to keep an implementation up- to-date. I've built an EC2 compatible API and the problem is that understanding what has changed in the API (and it changes fairly frequently) is hard. On the other hand, AWS is great at not breaking clients. So, when they roll out a change, it doesn't impact clients; but anyone implementing an EC2-compatible API will immediately be broken for clients taking advantage of new features. Furthermore, it may not be entirely clear from your end what it is that broke things. -George On Jul 9, 2011, at 9:30 AM, Sandy Walsh wrote: Ok, so let's look at this from another perspective ... how far away are we? I thought our EC2 binding was pretty good (admittedly, I don't use it). Are we radically out in left field or is this a game of inches? Any hardcore EC2 users care to comment? -S From: Jorge Williams Sent: Saturday, July 09, 2011 2:28 AM To: Sandy Walsh Cc: Soren Hansen; openstack@lists.launchpad.net Subject: Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort? On Jul 8, 2011, at 10:44 PM, Sandy Walsh wrote: Wow, really? Is EC2 really that sporadic/chaotic? I have to plead ignorance because I don't know where the rubber meets the road, but that kinda surprises me. I'm not saying that. In fact let me say that I don't think the Windows API itself is sporadic or chaotic. I used to be a Windows dev way back in the day and I never got that impression. The problem is that the Windows API is not open and is not really designed to be implemented by others. The Wine folks (and the ReactOS folks) have been working really hard to implement it for a long time. And with good reason, there are a lot of incentives to have a free Windows compatible OS. The task the Wine folks have is very hard though. There are no reference implementations for the Windows API, so you can't look at the code, you have to replicate bugs in the implementation and bugs in client apps etc, oh and do you really think MS wants a free Windows compatible OS on the market? -- you have to account for them messing with you as well. Soren was suggesting that supporting EC2 was much like writing an implementation of HTTP or SMTP (both open specs with open reference implementations). All I'm saying is that reverse engineering a living, rapidly changing, closed system and writing another system that behaves like it exactly (bugs and all) is not the same thing as implementing an open spec -- it's harder. -jOrGe W. This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comt: @GeorgeReesep: +1.207.956.0217 f: +1.612.338.5041 enStratus: Governance for Public, Private, and Hybrid Clouds - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
Brian, your two posts seem at odds with each other. So, I've got this completely external view and possibly my own particular skew on the vision for OpenStack... specifically, I want it to isolate me from provider as much as possible. Either I'm going to use AWS compatible interfaces for a provider or OpenStack and one has to win in the long run... okay, maybe not, maybe two co-exist as presentation layers for an internal cloud engine that's extensible middleware or some similar model. Regardless, I want OpenStack API to run anywhere for any provider so I can choose from a marketplace of providers and have more than one PROVIDER for HA/DR reasons. I also use the right tool for the job but when it comes to entire classes of APIs I'm going to make a business choice and... well, I'll tell ya... I'm not going to write for each provider if I can avoid it... I'm going to pick one. I want that one to end up being OpenStack with a fan-out to whatever provider fills in the back-end (common design pattern here). I use the right tool for the right job as well, like you mentioned in your prior post; however, I pick and make investments in platform APIs which is what OpenStack, IMNSHO, aspires to be. I'm curious whether the product managers/owners involved think the focus should be on AWS API compatibility or whether it should be about OpenStack functionality compatibly executed on the AWS platform. In my opinion OpenStack shouldn't be trying to be Euca and a Euca/AWS-compatible presentation layer to OpenStack is interesting but not terribly strategic. The market is still emergent and the enterprise is the big win so... I'd let tool-switchers switch to a new, better, OS API set rather than trying to backfill a presentation layer for existing SMB market on AWS. I'd think the Highlander approach: There can be only one, in terms of API set, is what we'd be striving for. Not that I, like, have an opinion or anything. ;) Jan Drake From: brian.sch...@nimbisservices.com Date: Sun, 10 Jul 2011 22:53:45 -0400 To: devin.car...@gmail.com CC: openstack@lists.launchpad.net Subject: Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort? Devin, agree with you 100% that the EC2 and OS APIs are presentation/view layer. I also think that there is way too much view/control and policy dependencies buried down in the core nova-* services. The core services like nova-compute shouldn't be using things like EC2 instance-id, instance-type, flavor, etc. they should be dealing with a more abstract pool of resources hosts, instances, networks, etc. -Brian Schott, CTONimbis Services, Inc.brian.schott@nimbisservices.comph: 443-274-6064 fx: 443-274-6060 On Jul 9, 2011, at 8:19 PM, Devin Carlen wrote:Yes - and this is a perfect example of why it's important for people to think of the EC2 and OpenStack API's not as mid-layer APIs in some stack. These APIs are actually presentation layers. Currently there is far too much core logic happening in the EC2 API for sure. At this tier, there shouldn't be anything other than data transforming and API specific muck going on. Nova is currently missing a classic middle tier, and this is why it gets difficult to circle back and add support for security groups to the OpenStack API. There's no common layer that both APIs rely on. This way you end up with a middle tier that is a super set of both OpenStack and EC2 APIs, and then exposing functionality in one API or the other is truly just a presentation issue, because by forcing the core to be implemented in a common layer, you force the person(s) implementing the feature to deal with the bigger picture, and not favor one API over the other. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
Ok, so let's look at this from another perspective ... how far away are we? I thought our EC2 binding was pretty good (admittedly, I don't use it). Are we radically out in left field or is this a game of inches? Any hardcore EC2 users care to comment? -S From: Jorge Williams Sent: Saturday, July 09, 2011 2:28 AM To: Sandy Walsh Cc: Soren Hansen; openstack@lists.launchpad.net Subject: Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort? On Jul 8, 2011, at 10:44 PM, Sandy Walsh wrote: Wow, really? Is EC2 really that sporadic/chaotic? I have to plead ignorance because I don't know where the rubber meets the road, but that kinda surprises me. I'm not saying that. In fact let me say that I don't think the Windows API itself is sporadic or chaotic. I used to be a Windows dev way back in the day and I never got that impression. The problem is that the Windows API is not open and is not really designed to be implemented by others. The Wine folks (and the ReactOS folks) have been working really hard to implement it for a long time. And with good reason, there are a lot of incentives to have a free Windows compatible OS. The task the Wine folks have is very hard though. There are no reference implementations for the Windows API, so you can't look at the code, you have to replicate bugs in the implementation and bugs in client apps etc, oh and do you really think MS wants a free Windows compatible OS on the market? -- you have to account for them messing with you as well. Soren was suggesting that supporting EC2 was much like writing an implementation of HTTP or SMTP (both open specs with open reference implementations). All I'm saying is that reverse engineering a living, rapidly changing, closed system and writing another system that behaves like it exactly (bugs and all) is not the same thing as implementing an open spec -- it's harder. -jOrGe W. This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
The other piece of the puzzle is that it is very easy to keep a client consistent with the API; it's very hard to keep an implementation up-to-date. I've built an EC2 compatible API and the problem is that understanding what has changed in the API (and it changes fairly frequently) is hard. On the other hand, AWS is great at not breaking clients. So, when they roll out a change, it doesn't impact clients; but anyone implementing an EC2-compatible API will immediately be broken for clients taking advantage of new features. Furthermore, it may not be entirely clear from your end what it is that broke things. -George On Jul 9, 2011, at 9:30 AM, Sandy Walsh wrote: Ok, so let's look at this from another perspective ... how far away are we? I thought our EC2 binding was pretty good (admittedly, I don't use it). Are we radically out in left field or is this a game of inches? Any hardcore EC2 users care to comment? -S From: Jorge Williams Sent: Saturday, July 09, 2011 2:28 AM To: Sandy Walsh Cc: Soren Hansen; openstack@lists.launchpad.net Subject: Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort? On Jul 8, 2011, at 10:44 PM, Sandy Walsh wrote: Wow, really? Is EC2 really that sporadic/chaotic? I have to plead ignorance because I don't know where the rubber meets the road, but that kinda surprises me. I'm not saying that. In fact let me say that I don't think the Windows API itself is sporadic or chaotic. I used to be a Windows dev way back in the day and I never got that impression. The problem is that the Windows API is not open and is not really designed to be implemented by others. The Wine folks (and the ReactOS folks) have been working really hard to implement it for a long time. And with good reason, there are a lot of incentives to have a free Windows compatible OS. The task the Wine folks have is very hard though. There are no reference implementations for the Windows API, so you can't look at the code, you have to replicate bugs in the implementation and bugs in client apps etc, oh and do you really think MS wants a free Windows compatible OS on the market? -- you have to account for them messing with you as well. Soren was suggesting that supporting EC2 was much like writing an implementation of HTTP or SMTP (both open specs with open reference implementations). All I'm saying is that reverse engineering a living, rapidly changing, closed system and writing another system that behaves like it exactly (bugs and all) is not the same thing as implementing an open spec -- it's harder. -jOrGe W. This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comt: @GeorgeReesep: +1.207.956.0217f: +1.612.338.5041 enStratus: Governance for Public, Private, and Hybrid Clouds - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese smime.p7s Description: S/MIME cryptographic signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
What if we wrote our own spec of the common features. Document the heck out of anything where the amazon spec and implementation differ and follow the implementation. Do to amazon what WS-I did to SOAP tools. Any fraction of the market we can get perceiving value in the true interoperability spec will become a weight around Amazon's neck. Many adopters want switch-ability, as they are wise to the lock-in tricks of market leaders. Open standards can deliver that, and reverse engineered specs that become de facto standards can deliver that. The contest between the two is to see which has more features and more implementations. On 7/8/11 2:35 PM, Ewan Mellor ewan.mel...@eu.citrix.com wrote: If you believe that that's true, then we should get Amazon to redefine the EC2 spec to match the reality of what's in the field. Ewan. This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
But this cuts both ways: many of their clients don't immediately adopt new changes, and if we can provide a spec for what parts of the amazon api you have to stay within to obtain switch-ability with openstack, then we slow down the adoption of those new features. The clients that are happy with lock-in and already on amazon aren't going to change to openstack anyway. But let's be clear, Amazon is not Microsoft, and I don't think this category is the dominant one. The market is growing and the biggest opportunity is for new adopters. It's valuable to openstack for some new adopters to have the option to switch back to EC2, because we are the newcomer. We also want to win some directly to the open APIs, and convert some once they get here by offering a better overall feature set in the open API. On 7/9/11 9:48 AM, George Reese george.re...@enstratus.com wrote: The other piece of the puzzle is that it is very easy to keep a client consistent with the API; it's very hard to keep an implementation up-to-date. I've built an EC2 compatible API and the problem is that understanding what has changed in the API (and it changes fairly frequently) is hard. On the other hand, AWS is great at not breaking clients. So, when they roll out a change, it doesn't impact clients; but anyone implementing an EC2-compatible API will immediately be broken for clients taking advantage of new features. Furthermore, it may not be entirely clear from your end what it is that broke things. This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
Here's a few crazy questions for you guys to consider: 1) Why are we even trying to have the same ID for an instance or image across two different APIs? 2) How many people really switch back and forth between OpenStack and EC2 API once they pick one? 3) How many people really expect euca2ools and python-novatools to return the same IDs for the same instances? 4) Why not just store a EC2 ID and a OS ID alongside an actual row PK? My point with these questions is that very little is gained from forcing two different APIs to try to use the same ID, especially given that the format is different. I would argue that it has created a lot more problems than it has solved. Devin On Jul 8, 2011, at 3:12 PM, Soren Hansen wrote: 2011/7/8 Vishvananda Ishaya vishvana...@gmail.com: Yes they seem to apply to all ids r-XXX ami-XXX i-XXX vol-XXX snap-XXX That said we are using base-36 for the hex in reservation ids and no one has complained, so i don't think they are used by the tools that much. Not true. ElasticFox does not work with this. I don't think we're yet at a point where we can say that lack of complaints about stuff means something's fine. That sort of assumption only starts to be useful when we have lots of real users. The users we have so far are people who care about OpenStack for OpenStack's sake, not random users who are being given access to an OpenStack deployment and being told talk to this like you would talk to EC2. It'll work fine. Different expectations. -- Soren Hansen| http://linux2go.dk/ Ubuntu Developer| http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
On Jul 8, 2011, at 2:19 PM, Vishvananda Ishaya wrote: My hope was that turning ec2 into a compatibility api would force people adding the ec2 features to make them work in the openstack api as well. I really feel like we're failing in producing a cloud standard api if we don't have all of the features. It is quite sad that we are still missing security group support in the os api for example. Yes - and this is a perfect example of why it's important for people to think of the EC2 and OpenStack API's not as mid-layer APIs in some stack. These APIs are actually presentation layers. Currently there is far too much core logic happening in the EC2 API for sure. At this tier, there shouldn't be anything other than data transforming and API specific muck going on. Nova is currently missing a classic middle tier, and this is why it gets difficult to circle back and add support for security groups to the OpenStack API. There's no common layer that both APIs rely on. This way you end up with a middle tier that is a super set of both OpenStack and EC2 APIs, and then exposing functionality in one API or the other is truly just a presentation issue, because by forcing the core to be implemented in a common layer, you force the person(s) implementing the feature to deal with the bigger picture, and not favor one API over the other. That said, I'm not wedded to this approach; I don't mind ec2 talking directly to the service apis. I just want to make sure that we understand only way we are going to get to the goal of a standard ubiquitous os api is if we make sure to add the features there as well. Said another way, I have two goals: Goal 1. OS api becomes a complete standard that supports the entire nova feature set. Goal 2. EC2 api implements as close to amazon's apis as possible and supports as many features as possible without breaking compatibility. I think that there is little disagreement in the goals, it is just how to get there that we are quibbling over. Option 1 EC2 | OS | Internal This gets a huge -1 from me for the exact reasons I described above. Advantage: forces us to add extensions to the OS api to support ec2 features, which makes the OS api more complete. Disadvantage: harder to add features to the EC2 api Option 2 EC2 OS \ / Internal Advantage: easier to add the ec2 features, so we end up with a more feature-rich ec2 api Disadvantage: OS api can get skipped when new features are added Huge +1 here. Like I said above, even if the OS API gets skipped in the initial implementation, that isn't as big of a deal now. All of the core logic exists. Now all someone has to do is expose the data transforms and API specific bits into the OS API. The problem now is for someone to implement security groups in the OS API requires a lot of work because there's a fair amount of actual logic in the EC2 API code. If we gave that logic a better place to live, it's far less painful to expose in multiple APIs. I feel that goal 1 is slightly more important than goal 2 so I'm leaning towards implementation option 1. This is not a strong preference, though. I think with the right focus we can achieve both goals in either scenario. I feel very strongly that option 2 is the right move. Devin ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
Apologies but I've been lurking on this thread and I have to agree with Devin. What I want from Openstack APIs is a consistent API that handles the provider platform behind the scenes. In a scenario where i need to manage aws separately, for instance, I may need openstack to expose native identifiers for debugging and extra complex management functions so I can get to that data outdide the OStack APIs. So, for me, I'd like to see a general pattern across openstack APIs that models and provides what I need while providing discovery interfaces for the underlying provider. Jan Drake Principal Cloud Architect The Walt Disney Company On Jul 9, 2011, at 5:23 PM, Devin Carlen devin.car...@gmail.com wrote: Here's a few crazy questions for you guys to consider: 1) Why are we even trying to have the same ID for an instance or image across two different APIs? 2) How many people really switch back and forth between OpenStack and EC2 API once they pick one? 3) How many people really expect euca2ools and python-novatools to return the same IDs for the same instances? 4) Why not just store a EC2 ID and a OS ID alongside an actual row PK? My point with these questions is that very little is gained from forcing two different APIs to try to use the same ID, especially given that the format is different. I would argue that it has created a lot more problems than it has solved. Devin On Jul 8, 2011, at 3:12 PM, Soren Hansen wrote: 2011/7/8 Vishvananda Ishaya vishvana...@gmail.com: Yes they seem to apply to all ids r-XXX ami-XXX i-XXX vol-XXX snap-XXX That said we are using base-36 for the hex in reservation ids and no one has complained, so i don't think they are used by the tools that much. Not true. ElasticFox does not work with this. I don't think we're yet at a point where we can say that lack of complaints about stuff means something's fine. That sort of assumption only starts to be useful when we have lots of real users. The users we have so far are people who care about OpenStack for OpenStack's sake, not random users who are being given access to an OpenStack deployment and being told talk to this like you would talk to EC2. It'll work fine. Different expectations. -- Soren Hansen| http://linux2go.dk/ Ubuntu Developer| http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
2011/7/8 Ed Leafe ed.le...@rackspace.com: On Jul 7, 2011, at 11:46 AM, Trey Morris wrote: If I had to choose between dropping or truncating UUIDs and failing feature parity with the ec2 api, i'd go with the latter. Pros and cons for UUIDs have already been discussed and decisions made. The EC2 api shouldn't get in the way. A translation layer to sit in between the EC2 and OS APIs would solve this issue without revisiting the UUID argument. The code to use the first 8 chars of the UUID in the ec2 id was created and working well, but discarded in favor of a more limited approach. Why? The only issue was the increased likelihood of a duplicate ec2 id, as we'd be limited to only 4 billion of them or so. I thought that it would be fairly straightforward to add code to detect such dupes, and re-generate a new UUID for the instance in that event. How would that work? The frontend gets a reqeust for a new instance, it sends it on to the backend that starts handling the request and sends back the ID. What then? Either the backend would need to be changed to wait for an yes, I accept this UUID from the frontend, which is unfortunate, or the frontend would have to get the response back, go hm, this collides with an existing ID. Cancel the request, and start over. In the latter case, a cost has already been incurred by starting up and immediately shutting down the instance. Also, if instances had already been created through the OpenStack API and were being queried through the EC2 API, there's no guarantee that colliding ID's don't already exist. In that case, you need to figure how to try to make sure that a request asking for that particular ID always gives a response corresponding to the same actual instance. This sounds crappy for a distributed system. If you want to perform the collision check even for intances created through the OpenStack API, then the reasons for choosing UUID's to begin with are moot. -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
I would just like to re-iterate that I think the entire UUID approach is flawed and issues like this are one of the key reasons why. -George On Jul 8, 2011, at 7:02 AM, Soren Hansen wrote: 2011/7/8 Ed Leafe ed.le...@rackspace.com: On Jul 7, 2011, at 11:46 AM, Trey Morris wrote: If I had to choose between dropping or truncating UUIDs and failing feature parity with the ec2 api, i'd go with the latter. Pros and cons for UUIDs have already been discussed and decisions made. The EC2 api shouldn't get in the way. A translation layer to sit in between the EC2 and OS APIs would solve this issue without revisiting the UUID argument. The code to use the first 8 chars of the UUID in the ec2 id was created and working well, but discarded in favor of a more limited approach. Why? The only issue was the increased likelihood of a duplicate ec2 id, as we'd be limited to only 4 billion of them or so. I thought that it would be fairly straightforward to add code to detect such dupes, and re-generate a new UUID for the instance in that event. How would that work? The frontend gets a reqeust for a new instance, it sends it on to the backend that starts handling the request and sends back the ID. What then? Either the backend would need to be changed to wait for an yes, I accept this UUID from the frontend, which is unfortunate, or the frontend would have to get the response back, go hm, this collides with an existing ID. Cancel the request, and start over. In the latter case, a cost has already been incurred by starting up and immediately shutting down the instance. Also, if instances had already been created through the OpenStack API and were being queried through the EC2 API, there's no guarantee that colliding ID's don't already exist. In that case, you need to figure how to try to make sure that a request asking for that particular ID always gives a response corresponding to the same actual instance. This sounds crappy for a distributed system. If you want to perform the collision check even for intances created through the OpenStack API, then the reasons for choosing UUID's to begin with are moot. -- Soren Hansen| http://linux2go.dk/ Ubuntu Developer| http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- George Reese - Chief Technology Officer, enStratus e: george.re...@enstratus.comt: @GeorgeReesep: +1.207.956.0217f: +1.612.338.5041 enStratus: Governance for Public, Private, and Hybrid Clouds - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese smime.p7s Description: S/MIME cryptographic signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
2011/7/8 Ewan Mellor ewan.mel...@eu.citrix.com:
From Thorsten von Eicken
FYI, there's nothing in the EC2 API that limits instance identifiers
(or other IDs) to 32 bits. The IDs are strings, so it's trivial for EC2 to
add another digit when running out of 32-bit IDs.
If that's the case (and I believe you, that's always how I assumed it would
be) why don't we just make the EC2 ID be ami-uuid?
Vish already explained it in this thread, but the problem is that
while the spec just says it's a string, most clients have much
stricter expectations.
ElasticFox (which Amazon develops themselves) requires e.g. an AMI id
to match ^ami-[0-9a-f]{8}$. I also expect most tools that use a
database store these ID's use a VARCHAR(XXX) (or perhaps even a
CHAR(XXX)). Having a max length at all is wrong according to the spec
(which says it's just a string).
The whole point of supporting the EC2 API is to support people's
existing tools and whatnot. If we follow the spec, but the clients
don't work, we're doing it wrong.
--
Soren Hansen | http://linux2go.dk/
Ubuntu Developer | http://www.ubuntu.com/
OpenStack Developer | http://www.openstack.org/
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
[Snip] The whole point of supporting the EC2 API is to support people's existing tools and whatnot. If we follow the spec, but the clients don't work, we're doing it wrong. True enough. However, in the case where we've got a demonstrated divergence from the spec, we should report that against the client. I agree that we want to support pre-existing tools, but it's less clear that we want to support _buggy_ tools. If Amazon turn out to be resistant to fixing that problem, then we'll obviously have to accept that and move on, but we should at least give them a chance to respond on that. Cheers, Ewan. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
2011/7/7 Vishvananda Ishaya vishvana...@gmail.com: On Jul 7, 2011, at 11:35 AM, Soren Hansen wrote: 2011/7/7 Trey Morris trey.mor...@rackspace.com: The goal isn't for ec2 api to be a second class citizen, but to keep it from being a limiting factor since we don't have control over it. How does the compatibility layer make it second class? Well, for one thing because you'll be limiting the EC2 API to what the OpenStack API is capable of doing and/or expressing. Actually, we can add any code that is necessary to make the ec2 api work properly as extensions to the os api. Maybe it's functionality that we don't want anywhere near the OpenStack API? My main reason for suggesting the switch over to a compatibility layer is so that we don't have multiple code paths into the heart of nova. Both frontend types will be speaking to the same backend API. That's where we translate the user's requests into actions that the backend can perform. This sounds like a very reasonable split to me. I don't understand why we'd change that. Building a backend that is reasonably frontend-API-agnostic is a good thing. It keeps us honest and helps maintain a clear separation of the various components. Eric did a lot of excellent work to make this split cleaner. I'd hate it if we blurred the lines between frontend and backend again. This has been a pain point already, and it will only get more painful as we move forward. IMO, reworking things to achieve looser coupling is tricky and painful, but time well spent. If all the stuff that makes ec2 compatibility work is in one place at the top layer, it is easier to maintain. I'll see your unsubstantiated claim, and raise you another one: It'll simply make other parts harder to maintain. If we need to maintain entirely disparate code paths from the api all the way down to the hypervisor, things will continue to be very fragile. It's not at all down the hypervisor. Not even close. The (currently) two different API frontends will interact with the relevant services (network, compute or scheduler), all of which should have a well-defined, flexible API. So far, these API's have been extended on a very ad-hoc basis to support some new functionality in either of the frontend API's. Just to be clear: I'm guilty of this too! What we should be doing is defining sensiblem coherent API's for these backend services, document their interfaces and treat them with respect, be aware when/how they change, attempt to maintain backwards/forwards compatiblity. When we start to think about how to upgrade Nova deployments, this will be very helpful. Having different things talking to the same API's keeps us more honest in this regard. So, I feel the exact opposite. A lot of the current fragility of Nova stems from the fact that we've focused a lot on specific features and not very much on these grander, more holistic things. When something is tightly coupled, and you try to bolt something else onto it, yes, it becomes fragile. Not because you're bolting things on, but because you didn't consider early enough that other things might be bolted on further down the road. -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
2011/7/8 Ed Leafe ed.le...@rackspace.com: No, it would work more like: a new instance is requested, and the host selected. A candidate UUID would be generated and checked for first 8 uniqueness (I had already added a db method to locate by the first 8 chars of a UUID across nested zones). When an acceptable UUID was generated, it would be passed to the selected host along with the create request. The instance would only have to be created once. If we're doing collision checking anyway, using UUID's to being with is pointless. We're effectively reduced to a 32 bit key space and, even worse, we're not being smart enough about it to actually do without the extra DB roundtrip to check for collisions. -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
On Fri, Jul 8, 2011 at 9:54 AM, Soren Hansen so...@linux2go.dk wrote: 2011/7/8 Ed Leafe ed.le...@rackspace.com: No, it would work more like: a new instance is requested, and the host selected. A candidate UUID would be generated and checked for first 8 uniqueness (I had already added a db method to locate by the first 8 chars of a UUID across nested zones). When an acceptable UUID was generated, it would be passed to the selected host along with the create request. The instance would only have to be created once. If we're doing collision checking anyway, using UUID's to being with is pointless. We're effectively reduced to a 32 bit key space and, even worse, we're not being smart enough about it to actually do without the extra DB roundtrip to check for collisions. That may be true, but only for the EC2 API, not the OpenStack API, right? The question remains from my original post: do we really care enough about this? Put another way: do we want to expend more resources on an API we don't control? -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
+1 to Soren's argument that ec2 is the 1000lb gorilla and should be central to nova. We definitely need to support it with as close to 100% compatibility as we can. Sounds like the only option is to embrace and extend it. Do everything it can do, and layer on what we need provided it doesn't break the core EC2 commands. If the customer wants pure EC2, they'll have to live with the limitations. That said, is this the proposal I'm hearing? ... Since our separation is done at the service.api layer, the service.api's get pulled in two directions with each change in ec2/os. The idea is to have ec2 be a translation layer to os api? Preventing ec2 api from calling [service].api directly? So, instead of EC2 Client OS Client | | EC2 APIOS API \ / [Service] API We'd be shifting to: EC2 Client EC2 API | OS Client -- OS API | [Service] API I need to think more about this, but at first blush, it doesn't seem like such a thing? At some point the abstraction layer needs to be locked down doesn't it? -S Put another way: do we want to expend more resources on an API we don't control? -jay This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
Ugh ... ... but at first blush, it doesn't seem like such a *bad* thing? This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
I'm with Ewan on this point: One of the nice thing about having a contract is that it clearly designates what's a bug and what isn't. If the spec says the ID is a string and the client assumes it's an integer, then the client is at fault. End of story. It would be a different issue if the contract didn't specify what an ID was or if the contract only allowed for integers. It's bad enough that we are spending resources trying to support an API which isn't open and which we don't control, now on top of that we want to support buggy clients that don't follow the spec? Where do we draw the line? I'm all for being flexible and forgiving in what we expect from clients, but I don't think we should be making serious engineering decisions based on the fact that a client developer made a bad assumption or didn't read the spec. If we know that there are clients out there that make the assumptions then contact the folks that maintain the client and ask them to adjust their code. If they give you grief, point to the contract and that should settle the issue. It's to their interest to support as many deployments of the API as possible. It's not our responsibility to support their buggy code. Though I have some reservations about it, I'm okay offering some support for the EC2 contract. What I'm not okay with is in being in the business of reverse engineering Amazon's EC2 implementation. Those are two very different things and I think the latter is orders of magnitude more difficult. In fact I would argue that reverse engineering EC2 is a project onto itself. That means that when EC2 has a bug, we need to replicate it etc. That's almost impossible and it makes it really easy for Amazon to disrupt our efforts if they so wish. What's more, it gets in the way of our ability to innovate and break new ground. -jOrGe W. On Jul 8, 2011, at 7:39 AM, Soren Hansen wrote: 2011/7/8 Ewan Mellor ewan.mel...@eu.citrix.com: The whole point of supporting the EC2 API is to support people's existing tools and whatnot. If we follow the spec, but the clients don't work, we're doing it wrong. True enough. However, in the case where we've got a demonstrated divergence from the spec, we should report that against the client. I agree that we want to support pre-existing tools, but it's less clear that we want to support _buggy_ tools. We do. We have to. We have no way to know what sort of clients people are using. We can only attempt to check the open source ones, but there's likely loads of other ones that people have built themselves and never shared. Not only do people have to be able, motivated and allowed to change their tools to work with OpenStack, they also need to *realise* that this is something that needs to happen. We can't assume the symptoms they'll experience even gives as much as a hint that the ID's they're getting back is too long. They may just get a general error of some sort. If we a) expect people to consume the EC2 API we expose, and (more importantly) b) expect ISP's to offer this API to their customers, it needs to be as close to just another EC2 region as possible. If Amazon turn out to be resistant to fixing that problem, then we'll obviously have to accept that and move on, but we should at least give them a chance to respond on that. Amazon is not the problem. At least not the only problem. I'm not even going to begin to guess how many different tools exist to talk to the EC2 API. -- Soren Hansen| http://linux2go.dk/ Ubuntu Developer| http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
I don't think this is a technical issue, it's a business issue. If we want adoption, we have to reduce switching friction. Sadly, this means EC2 bugs/nuances and all. The better a job we do of this, the easier it will be for users to transition from EC2 to OpenStack and benefit from all the chocolatey goodness we're baking into it. $0.02 From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net [openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of Jorge Williams [jorge.willi...@rackspace.com] Sent: Friday, July 08, 2011 12:01 PM To: Soren Hansen Cc: Ewan Mellor; openstack@lists.launchpad.net Subject: Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort? I'm with Ewan on this point: One of the nice thing about having a contract is that it clearly designates what's a bug and what isn't. If the spec says the ID is a string and the client assumes it's an integer, then the client is at fault. End of story. It would be a different issue if the contract didn't specify what an ID was or if the contract only allowed for integers. It's bad enough that we are spending resources trying to support an API which isn't open and which we don't control, now on top of that we want to support buggy clients that don't follow the spec? Where do we draw the line? I'm all for being flexible and forgiving in what we expect from clients, but I don't think we should be making serious engineering decisions based on the fact that a client developer made a bad assumption or didn't read the spec. If we know that there are clients out there that make the assumptions then contact the folks that maintain the client and ask them to adjust their code. If they give you grief, point to the contract and that should settle the issue. It's to their interest to support as many deployments of the API as possible. It's not our responsibility to support their buggy code. Though I have some reservations about it, I'm okay offering some support for the EC2 contract. What I'm not okay with is in being in the business of reverse engineering Amazon's EC2 implementation. Those are two very different things and I think the latter is orders of magnitude more difficult. In fact I would argue that reverse engineering EC2 is a project onto itself. That means that when EC2 has a bug, we need to replicate it etc. That's almost impossible and it makes it really easy for Amazon to disrupt our efforts if they so wish. What's more, it gets in the way of our ability to innovate and break new ground. -jOrGe W. On Jul 8, 2011, at 7:39 AM, Soren Hansen wrote: 2011/7/8 Ewan Mellor ewan.mel...@eu.citrix.com: The whole point of supporting the EC2 API is to support people's existing tools and whatnot. If we follow the spec, but the clients don't work, we're doing it wrong. True enough. However, in the case where we've got a demonstrated divergence from the spec, we should report that against the client. I agree that we want to support pre-existing tools, but it's less clear that we want to support _buggy_ tools. We do. We have to. We have no way to know what sort of clients people are using. We can only attempt to check the open source ones, but there's likely loads of other ones that people have built themselves and never shared. Not only do people have to be able, motivated and allowed to change their tools to work with OpenStack, they also need to *realise* that this is something that needs to happen. We can't assume the symptoms they'll experience even gives as much as a hint that the ID's they're getting back is too long. They may just get a general error of some sort. If we a) expect people to consume the EC2 API we expose, and (more importantly) b) expect ISP's to offer this API to their customers, it needs to be as close to just another EC2 region as possible. If Amazon turn out to be resistant to fixing that problem, then we'll obviously have to accept that and move on, but we should at least give them a chance to respond on that. Amazon is not the problem. At least not the only problem. I'm not even going to begin to guess how many different tools exist to talk to the EC2 API. -- Soren Hansen| http://linux2go.dk/ Ubuntu Developer| http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help :
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
On Jul 8, 2011, at 10:36 AM, Sandy Walsh wrote: +1 to Soren's argument that ec2 is the 1000lb gorilla and should be central to nova. We definitely need to support it with as close to 100% compatibility as we can. Sounds like the only option is to embrace and extend it. Do everything it can do, and layer on what we need provided it doesn't break the core EC2 commands. If the customer wants pure EC2, they'll have to live with the limitations. That said, is this the proposal I'm hearing? ... Since our separation is done at the service.api layer, the service.api's get pulled in two directions with each change in ec2/os. The idea is to have ec2 be a translation layer to os api? Preventing ec2 api from calling [service].api directly? So, instead of EC2 Client OS Client | | EC2 APIOS API \ / [Service] API We'd be shifting to: EC2 Client EC2 API | OS Client -- OS API | [Service] API I need to think more about this, but at first blush, it doesn't seem like such a [bad] thing? At some point the abstraction layer needs to be locked down doesn't it? I think it actually looks more like this right now: EC2 Client OS Client | | EC2 APIOS API \ / [nova-*] service APIs There isn't really a single back-end API for the front-end APIs to call into. Instead, each of them makes calls to the multiple service APIs (e.g., scheduler, network, compute). I would advocate for something more like this: EC2 Client OS Client | | EC2 APIOS API \ / internal nova API | [nova-*] service APIs This is a single, unified API that is meant only for internal use. This would reduce the coupling between front-end and back-end. It would make it easier for someone with less expertise in the code (hello!) to find the location in the code that answers questions like: What does nova do when a user requests that an instance is launched? They would just look at the internal API and find the appropriate method. It would also make it easier to add additional front-ends, if there's ever any interest in that. Lorin -- Lorin Hochstein, Computer Scientist USC Information Sciences Institute 703.812.3710 http://www.east.isi.edu/~lorin ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
2011/7/8 Jay Pipes jaypi...@gmail.com: On Fri, Jul 8, 2011 at 9:54 AM, Soren Hansen so...@linux2go.dk wrote: 2011/7/8 Ed Leafe ed.le...@rackspace.com: No, it would work more like: a new instance is requested, and the host selected. A candidate UUID would be generated and checked for first 8 uniqueness (I had already added a db method to locate by the first 8 chars of a UUID across nested zones). When an acceptable UUID was generated, it would be passed to the selected host along with the create request. The instance would only have to be created once. If we're doing collision checking anyway, using UUID's to being with is pointless. We're effectively reduced to a 32 bit key space and, even worse, we're not being smart enough about it to actually do without the extra DB roundtrip to check for collisions. That may be true, but only for the EC2 API, not the OpenStack API, right? Depends. If you want to let people use either API, you need to impose this check for objects created through the OpenStack API too, otherwise you'll run into problems when you try to query them when using the EC2 API. The question remains from my original post: do we really care enough about this? Yes. Put another way: do we want to expend more resources on an API we don't control? Yes. Being able to reuse your existing tools is tremendously valuable. Eventaully, when the OpenStack API offers compelling functionality that you cannot get through the EC2 API, there'll be motivation for people to switch. But even then, being able to easily start using OpenStack and the convert to the OpenStack API piecemeal makes for a fantastic migration path. Until then, what exactly would be people's motivation to rework their client tools to a different API? -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
2011/7/8 Jorge Williams jorge.willi...@rackspace.com: I'm with Ewan on this point: One of the nice thing about having a contract is that it clearly designates what's a bug and what isn't. If the spec says the ID is a string and the client assumes it's an integer, then the client is at fault. End of story. It would be a different issue if the contract didn't specify what an ID was or if the contract only allowed for integers. Answer me this: If the spec says a particular method was called Foo, but EC2 actually calls it Bar and every client on the planet calls it Bar, would you still insist on following the spec and ignoring what the clients do? Also, if the spec said that two arguments to a method needed to be passed in one order, but they actually needed to be passed the other way around and every single client on the planet had figured this out and followed what EC2 *actually* does rather than what it says in the spec would you insist on following the spec? What good could that possibly serve? The EC2 API isn't a published, open standard with many implementations of both server and client. What EC2 *actually* does is the real spec. And what the clients *actually* expect is what we need to deliver. We can argue all day long that the spec says this or that, but if every client expects something else (or something more specific), that's what we need to deal with. We're not on a mission to create something that is a stricter implementation of the EC2 API. We're trying to provide something that people can use. If someone was trying to offer me something, claiming it's compatible with something I've used for years, but as we're closing the deal he says oh, by the way.. you're probably going to have to change your tools for this to *actually* work, I'd tell him to take his compatibility and stick it somewhere (in)appropriate. It's bad enough that we are spending resources trying to support an API which isn't open and which we don't control, now on top of that we want to support buggy clients that don't follow the spec? The spec is completely irrelevant. You can call it a compatibility layer all day long, but if it's *actually* incompatible with what the clients expect, it's worthless. If we know that there are clients out there that make the assumptions then contact the folks that maintain the client and ask them to adjust their code. How do you suggest we find them? If they give you grief, point to the contract and that should settle the issue. Nonsense. They might be perfectly happy with EC2. If you want them to switch to OpenStack, that's going to be a tough sell if they can't reuse their code. To them, it's *you* who's doing something wrong, because you're doing something different from what EC2 does. Though I have some reservations about it, I'm okay offering some support for the EC2 contract. What I'm not okay with is in being in the business of reverse engineering Amazon's EC2 implementation. Those are two very different things and I think the latter is orders of magnitude more difficult. Making useful software is difficult. Anyone claiming otherwise is full of it. Of course we should follow the spec, but if there are well-known places where reality is different, we need to follow reality. That's what the clients do. -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
If you believe that that's true, then we should get Amazon to redefine the EC2 spec to match the reality of what's in the field. Ewan. -Original Message- From: Soren Hansen [mailto:so...@linux2go.dk] Sent: 08 July 2011 05:40 To: Ewan Mellor Cc: Thorsten von Eicken; openstack@lists.launchpad.net Subject: Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort? 2011/7/8 Ewan Mellor ewan.mel...@eu.citrix.com: The whole point of supporting the EC2 API is to support people's existing tools and whatnot. If we follow the spec, but the clients don't work, we're doing it wrong. True enough. However, in the case where we've got a demonstrated divergence from the spec, we should report that against the client. I agree that we want to support pre-existing tools, but it's less clear that we want to support _buggy_ tools. We do. We have to. We have no way to know what sort of clients people are using. We can only attempt to check the open source ones, but there's likely loads of other ones that people have built themselves and never shared. Not only do people have to be able, motivated and allowed to change their tools to work with OpenStack, they also need to *realise* that this is something that needs to happen. We can't assume the symptoms they'll experience even gives as much as a hint that the ID's they're getting back is too long. They may just get a general error of some sort. If we a) expect people to consume the EC2 API we expose, and (more importantly) b) expect ISP's to offer this API to their customers, it needs to be as close to just another EC2 region as possible. If Amazon turn out to be resistant to fixing that problem, then we'll obviously have to accept that and move on, but we should at least give them a chance to respond on that. Amazon is not the problem. At least not the only problem. I'm not even going to begin to guess how many different tools exist to talk to the EC2 API. -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
2011/7/8 Ewan Mellor ewan.mel...@eu.citrix.com: If you believe that that's true, then we should get Amazon to redefine the EC2 spec to match the reality of what's in the field. What would their motivation be? -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
One thing that keeps coming up in this discussion is the issue of being tied to an API we don't control. People... We're *fantastically* privileged that we get to define an API of our own. Lots and lots and lots of people and projects spend all their time implementing existing (open, but completely static) protocols and specifications. Every HTTP, SMTP, and IMAP server on the planet does it. Every single C compiler on the planet does it. All of these are things that have been defined a long time ago. You can have all the opinions you want about IMAP, but that doesn't mean you can just implement it differently. At least not if you expect people to support your stuff. When there are ambiguities in the spec, sure, you can insist on taking one path even though everyone else has taken a different one, but don't expect the rest of the world to change to accommodate you. If you want to do offer something better by doing something differently, offer it as an alternative that people can switch to once you've won them over. Don't make it a prerequisite. There's a golden rule when implementing things according to an existing specification: Be very conservative in what you deliver, and be very liberal in what you accept. Otherwise, people. will. use. something. else. period. -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
Isn't there a concern of leaking internal Zone information to the outside world (particularly in the Service Provider model)? If so, we're back to the mapping table. And, when multi-instance boot commands are more common (provision me 10 servers vs. 1), then more people will be searching by Reservation Id, Project Id or Owner Id (I suspect). So, how long will this be a problem for? Do the same quirks apply to EC2 Reservation ID's as Instance ID's? -S From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net [openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of Chris Behrens [chris.behr...@rackspace.com] Sent: Friday, July 08, 2011 5:43 PM To: George Reese Cc: openstack@lists.launchpad.net; Ed Leafe; Chris Behrens Subject: Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort? On Jul 8, 2011, at 5:11 AM, George Reese wrote: I would just like to re-iterate that I think the entire UUID approach is flawed and issues like this are one of the key reasons why. The only problem I'm aware of is that developers using the EC2 API are not adhering to the spec. If everyone treated them as strings, as they are supposed to be, then we wouldn't have to have this discussion. That said, I do have a particular problem with the current UUID implementation in that I wish some sort of unique zone identifier were a part of it. Accompany that with some other changes to zones and we could have more efficient zone routing. A side effect of that would be that it is less work to come up with an ID that, if truncated, would also be unique to EC2. Taking Ed Leafe's approach, you could remove the recursive zone checks. I'm not sure I'd vote for that route, though. It implies we kludge UUID generation just for EC2 in the heart of nova, which I think is completely wrong. I'm pretty much with Vish on everything he's said so far in this thread. - Chris This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
Yeah, I'm not sure *how much* of the zone information would be sensitive, though. Ie, is it okay to expose a unique identifier and nothing more? Or do we want to expose _nothing_? - Chris On Jul 8, 2011, at 2:28 PM, Sandy Walsh wrote: Isn't there a concern of leaking internal Zone information to the outside world (particularly in the Service Provider model)? If so, we're back to the mapping table. And, when multi-instance boot commands are more common (provision me 10 servers vs. 1), then more people will be searching by Reservation Id, Project Id or Owner Id (I suspect). So, how long will this be a problem for? Do the same quirks apply to EC2 Reservation ID's as Instance ID's? -S From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net [openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of Chris Behrens [chris.behr...@rackspace.com] Sent: Friday, July 08, 2011 5:43 PM To: George Reese Cc: openstack@lists.launchpad.net; Ed Leafe; Chris Behrens Subject: Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort? On Jul 8, 2011, at 5:11 AM, George Reese wrote: I would just like to re-iterate that I think the entire UUID approach is flawed and issues like this are one of the key reasons why. The only problem I'm aware of is that developers using the EC2 API are not adhering to the spec. If everyone treated them as strings, as they are supposed to be, then we wouldn't have to have this discussion. That said, I do have a particular problem with the current UUID implementation in that I wish some sort of unique zone identifier were a part of it. Accompany that with some other changes to zones and we could have more efficient zone routing. A side effect of that would be that it is less work to come up with an ID that, if truncated, would also be unique to EC2. Taking Ed Leafe's approach, you could remove the recursive zone checks. I'm not sure I'd vote for that route, though. It implies we kludge UUID generation just for EC2 in the heart of nova, which I think is completely wrong. I'm pretty much with Vish on everything he's said so far in this thread. - Chris This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
Yes they seem to apply to all ids r-XXX ami-XXX i-XXX vol-XXX snap-XXX That said we are using base-36 for the hex in reservation ids and no one has complained, so i don't think they are used by the tools that much. Vish On Jul 8, 2011, at 2:28 PM, Sandy Walsh wrote: Isn't there a concern of leaking internal Zone information to the outside world (particularly in the Service Provider model)? If so, we're back to the mapping table. And, when multi-instance boot commands are more common (provision me 10 servers vs. 1), then more people will be searching by Reservation Id, Project Id or Owner Id (I suspect). So, how long will this be a problem for? Do the same quirks apply to EC2 Reservation ID's as Instance ID's? -S From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net [openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of Chris Behrens [chris.behr...@rackspace.com] Sent: Friday, July 08, 2011 5:43 PM To: George Reese Cc: openstack@lists.launchpad.net; Ed Leafe; Chris Behrens Subject: Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort? On Jul 8, 2011, at 5:11 AM, George Reese wrote: I would just like to re-iterate that I think the entire UUID approach is flawed and issues like this are one of the key reasons why. The only problem I'm aware of is that developers using the EC2 API are not adhering to the spec. If everyone treated them as strings, as they are supposed to be, then we wouldn't have to have this discussion. That said, I do have a particular problem with the current UUID implementation in that I wish some sort of unique zone identifier were a part of it. Accompany that with some other changes to zones and we could have more efficient zone routing. A side effect of that would be that it is less work to come up with an ID that, if truncated, would also be unique to EC2. Taking Ed Leafe's approach, you could remove the recursive zone checks. I'm not sure I'd vote for that route, though. It implies we kludge UUID generation just for EC2 in the heart of nova, which I think is completely wrong. I'm pretty much with Vish on everything he's said so far in this thread. - Chris This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
2011/7/8 Vishvananda Ishaya vishvana...@gmail.com: Yes they seem to apply to all ids r-XXX ami-XXX i-XXX vol-XXX snap-XXX That said we are using base-36 for the hex in reservation ids and no one has complained, so i don't think they are used by the tools that much. Not true. ElasticFox does not work with this. I don't think we're yet at a point where we can say that lack of complaints about stuff means something's fine. That sort of assumption only starts to be useful when we have lots of real users. The users we have so far are people who care about OpenStack for OpenStack's sake, not random users who are being given access to an OpenStack deployment and being told talk to this like you would talk to EC2. It'll work fine. Different expectations. -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
HTTP, SMTP, and IMAP and even ANSI C are all open standards. The specs were developed and continue to be developed in the open -- and both clients and servers (proprietary and open source) are very compliant to them. I'd like to propose that our APIs take the same approach. You are proposing something different than simply implementing HTTP or SMTP. What you are proposing that we try to achieve with EC2 what the Wine folks want to achieve with the Windows API. It's a different problem. It's a much harder problem because it involves reverse engineering and it's prone to more risk. -jOrGe W. On Jul 8, 2011, at 3:05 PM, Soren Hansen wrote: One thing that keeps coming up in this discussion is the issue of being tied to an API we don't control. People... We're *fantastically* privileged that we get to define an API of our own. Lots and lots and lots of people and projects spend all their time implementing existing (open, but completely static) protocols and specifications. Every HTTP, SMTP, and IMAP server on the planet does it. Every single C compiler on the planet does it. All of these are things that have been defined a long time ago. You can have all the opinions you want about IMAP, but that doesn't mean you can just implement it differently. At least not if you expect people to support your stuff. When there are ambiguities in the spec, sure, you can insist on taking one path even though everyone else has taken a different one, but don't expect the rest of the world to change to accommodate you. If you want to do offer something better by doing something differently, offer it as an alternative that people can switch to once you've won them over. Don't make it a prerequisite. There's a golden rule when implementing things according to an existing specification: Be very conservative in what you deliver, and be very liberal in what you accept. Otherwise, people. will. use. something. else. period. -- Soren Hansen| http://linux2go.dk/ Ubuntu Developer| http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
If the spec doesn't match the specification then they are admitting that they have a bug. They broke the contract, we can lobby them to change it or write an implementation that does the right thing. Or we should not be using the spec at all. I'd much rather encourage clients to implement against an Open API. -jOrGe W. On Jul 8, 2011, at 2:41 PM, Soren Hansen wrote: 2011/7/8 Jorge Williams jorge.willi...@rackspace.com: I'm with Ewan on this point: One of the nice thing about having a contract is that it clearly designates what's a bug and what isn't. If the spec says the ID is a string and the client assumes it's an integer, then the client is at fault. End of story. It would be a different issue if the contract didn't specify what an ID was or if the contract only allowed for integers. Answer me this: If the spec says a particular method was called Foo, but EC2 actually calls it Bar and every client on the planet calls it Bar, would you still insist on following the spec and ignoring what the clients do? Also, if the spec said that two arguments to a method needed to be passed in one order, but they actually needed to be passed the other way around and every single client on the planet had figured this out and followed what EC2 *actually* does rather than what it says in the spec would you insist on following the spec? What good could that possibly serve? The EC2 API isn't a published, open standard with many implementations of both server and client. What EC2 *actually* does is the real spec. And what the clients *actually* expect is what we need to deliver. We can argue all day long that the spec says this or that, but if every client expects something else (or something more specific), that's what we need to deal with. We're not on a mission to create something that is a stricter implementation of the EC2 API. We're trying to provide something that people can use. If someone was trying to offer me something, claiming it's compatible with something I've used for years, but as we're closing the deal he says oh, by the way.. you're probably going to have to change your tools for this to *actually* work, I'd tell him to take his compatibility and stick it somewhere (in)appropriate. It's bad enough that we are spending resources trying to support an API which isn't open and which we don't control, now on top of that we want to support buggy clients that don't follow the spec? The spec is completely irrelevant. You can call it a compatibility layer all day long, but if it's *actually* incompatible with what the clients expect, it's worthless. If we know that there are clients out there that make the assumptions then contact the folks that maintain the client and ask them to adjust their code. How do you suggest we find them? If they give you grief, point to the contract and that should settle the issue. Nonsense. They might be perfectly happy with EC2. If you want them to switch to OpenStack, that's going to be a tough sell if they can't reuse their code. To them, it's *you* who's doing something wrong, because you're doing something different from what EC2 does. Though I have some reservations about it, I'm okay offering some support for the EC2 contract. What I'm not okay with is in being in the business of reverse engineering Amazon's EC2 implementation. Those are two very different things and I think the latter is orders of magnitude more difficult. Making useful software is difficult. Anyone claiming otherwise is full of it. Of course we should follow the spec, but if there are well-known places where reality is different, we need to follow reality. That's what the clients do. -- Soren Hansen| http://linux2go.dk/ Ubuntu Developer| http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
Stepping back for a moment, I think the two main benefits of supporting the EC2 API are: - Leverage existing 3rd party tools that talk to EC2 API (e.g., euca2ools, boto, Elasticfox/Hybridfox) - Reduce the cost of switching to OpenStack for EC2 users I agree with Soren that these benefits are lost if OpenStack supports the official EC2 spec but breaks compatibility with the existing tools and scripts people already have. Better to not have an EC2 API at all than to lose new users because they think OpenStack is broken when their EC2-based tool fails to work. While the comparison with Wine is apt, I think an even more relevant comparison would be Microsoft trying to stay compatible with third party applications that worked on previous versions of Windows, even ones that broke the API but still worked (See Raymon Chen's excellent The Old New Thing blog for the Herculean efforts that MS developers had to put in to accomplish this http://blogs.msdn.com/b/oldnewthing/). I don't think that the OpenStack project should commit to maintaining EC2 compatibility at all costs, only as long as the benefits outweigh the development costs. In particular, if Amazon deliberately started making changes to break the API, that would be a good time to consider dropping support. Lorin -- Lorin Hochstein, Computer Scientist USC Information Sciences Institute 703.812.3710 http://www.east.isi.edu/~lorin On Jul 8, 2011, at 6:59 PM, Jorge Williams wrote: HTTP, SMTP, and IMAP and even ANSI C are all open standards. The specs were developed and continue to be developed in the open -- and both clients and servers (proprietary and open source) are very compliant to them. I'd like to propose that our APIs take the same approach. You are proposing something different than simply implementing HTTP or SMTP. What you are proposing that we try to achieve with EC2 what the Wine folks want to achieve with the Windows API. It's a different problem. It's a much harder problem because it involves reverse engineering and it's prone to more risk. -jOrGe W. On Jul 8, 2011, at 3:05 PM, Soren Hansen wrote: One thing that keeps coming up in this discussion is the issue of being tied to an API we don't control. People... We're *fantastically* privileged that we get to define an API of our own. Lots and lots and lots of people and projects spend all their time implementing existing (open, but completely static) protocols and specifications. Every HTTP, SMTP, and IMAP server on the planet does it. Every single C compiler on the planet does it. All of these are things that have been defined a long time ago. You can have all the opinions you want about IMAP, but that doesn't mean you can just implement it differently. At least not if you expect people to support your stuff. When there are ambiguities in the spec, sure, you can insist on taking one path even though everyone else has taken a different one, but don't expect the rest of the world to change to accommodate you. If you want to do offer something better by doing something differently, offer it as an alternative that people can switch to once you've won them over. Don't make it a prerequisite. There's a golden rule when implementing things according to an existing specification: Be very conservative in what you deliver, and be very liberal in what you accept. Otherwise, people. will. use. something. else. period. -- Soren Hansen| http://linux2go.dk/ Ubuntu Developer| http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
+1 Devin On Jul 8, 2011, at 10:29 AM, Lorin Hochstein lo...@isi.edu wrote: On Jul 8, 2011, at 10:36 AM, Sandy Walsh wrote: +1 to Soren's argument that ec2 is the 1000lb gorilla and should be central to nova. We definitely need to support it with as close to 100% compatibility as we can. Sounds like the only option is to embrace and extend it. Do everything it can do, and layer on what we need provided it doesn't break the core EC2 commands. If the customer wants pure EC2, they'll have to live with the limitations. That said, is this the proposal I'm hearing? ... Since our separation is done at the service.api layer, the service.api's get pulled in two directions with each change in ec2/os. The idea is to have ec2 be a translation layer to os api? Preventing ec2 api from calling [service].api directly? So, instead of EC2 Client OS Client | | EC2 APIOS API \ / [Service] API We'd be shifting to: EC2 Client EC2 API | OS Client -- OS API | [Service] API I need to think more about this, but at first blush, it doesn't seem like such a [bad] thing? At some point the abstraction layer needs to be locked down doesn't it? I think it actually looks more like this right now: EC2 Client OS Client | | EC2 APIOS API \ / [nova-*] service APIs There isn't really a single back-end API for the front-end APIs to call into. Instead, each of them makes calls to the multiple service APIs (e.g., scheduler, network, compute). I would advocate for something more like this: EC2 Client OS Client | | EC2 APIOS API \ / internal nova API | [nova-*] service APIs This is a single, unified API that is meant only for internal use. This would reduce the coupling between front-end and back-end. It would make it easier for someone with less expertise in the code (hello!) to find the location in the code that answers questions like: What does nova do when a user requests that an instance is launched? They would just look at the internal API and find the appropriate method. It would also make it easier to add additional front-ends, if there's ever any interest in that. Lorin -- Lorin Hochstein, Computer Scientist USC Information Sciences Institute 703.812.3710 http://www.east.isi.edu/~lorin ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
This ship may have sailed, but given what I have seen across a wide variety of cloud APIs and what I are here, I strongly question the value of supporting an EC2 API. I think you overestimate the value of supporting existing tools. Sent from my iPhone On Jul 8, 2011, at 19:32, Lorin Hochstein lo...@isi.edu wrote: Stepping back for a moment, I think the two main benefits of supporting the EC2 API are: - Leverage existing 3rd party tools that talk to EC2 API (e.g., euca2ools, boto, Elasticfox/Hybridfox) - Reduce the cost of switching to OpenStack for EC2 users I agree with Soren that these benefits are lost if OpenStack supports the official EC2 spec but breaks compatibility with the existing tools and scripts people already have. Better to not have an EC2 API at all than to lose new users because they think OpenStack is broken when their EC2-based tool fails to work. While the comparison with Wine is apt, I think an even more relevant comparison would be Microsoft trying to stay compatible with third party applications that worked on previous versions of Windows, even ones that broke the API but still worked (See Raymon Chen's excellent The Old New Thing blog for the Herculean efforts that MS developers had to put in to accomplish this http://blogs.msdn.com/b/oldnewthing/). I don't think that the OpenStack project should commit to maintaining EC2 compatibility at all costs, only as long as the benefits outweigh the development costs. In particular, if Amazon deliberately started making changes to break the API, that would be a good time to consider dropping support. Lorin -- Lorin Hochstein, Computer Scientist USC Information Sciences Institute 703.812.3710 http://www.east.isi.edu/~lorin On Jul 8, 2011, at 6:59 PM, Jorge Williams wrote: HTTP, SMTP, and IMAP and even ANSI C are all open standards. The specs were developed and continue to be developed in the open -- and both clients and servers (proprietary and open source) are very compliant to them. I'd like to propose that our APIs take the same approach. You are proposing something different than simply implementing HTTP or SMTP. What you are proposing that we try to achieve with EC2 what the Wine folks want to achieve with the Windows API. It's a different problem. It's a much harder problem because it involves reverse engineering and it's prone to more risk. -jOrGe W. On Jul 8, 2011, at 3:05 PM, Soren Hansen wrote: One thing that keeps coming up in this discussion is the issue of being tied to an API we don't control. People... We're *fantastically* privileged that we get to define an API of our own. Lots and lots and lots of people and projects spend all their time implementing existing (open, but completely static) protocols and specifications. Every HTTP, SMTP, and IMAP server on the planet does it. Every single C compiler on the planet does it. All of these are things that have been defined a long time ago. You can have all the opinions you want about IMAP, but that doesn't mean you can just implement it differently. At least not if you expect people to support your stuff. When there are ambiguities in the spec, sure, you can insist on taking one path even though everyone else has taken a different one, but don't expect the rest of the world to change to accommodate you. If you want to do offer something better by doing something differently, offer it as an alternative that people can switch to once you've won them over. Don't make it a prerequisite. There's a golden rule when implementing things according to an existing specification: Be very conservative in what you deliver, and be very liberal in what you accept. Otherwise, people. will. use. something. else. period. -- Soren Hansen| http://linux2go.dk/ Ubuntu Developer| http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help :
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
From: Jorge Williams [jorge.willi...@rackspace.com] What you are proposing that we try to achieve with EC2 what the Wine folks want to achieve with the Windows API. It's a different problem. It's a much harder problem because it involves reverse engineering and it's prone to more risk. -jOrGe W. Wow, really? Is EC2 really that sporadic/chaotic? I have to plead ignorance because I don't know where the rubber meets the road, but that kinda surprises me. This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
-Original Message- From: Soren Hansen [mailto:so...@linux2go.dk] Sent: 08 July 2011 12:43 To: Ewan Mellor Cc: Thorsten von Eicken; openstack@lists.launchpad.net Subject: Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort? 2011/7/8 Ewan Mellor ewan.mel...@eu.citrix.com: If you believe that that's true, then we should get Amazon to redefine the EC2 spec to match the reality of what's in the field. What would their motivation be? The same motivation that they had for publishing the spec in the first place: good compatibility across the various clients means that they are free to improve their server-side implementation within the bounds of the spec. If they have clients in their ecosystem (whether they wrote them or not) that aren't conforming to the spec, then that harms their future freedom to innovate (in the same way as it's harming us now). Ewan. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
On Jul 8, 2011, at 10:44 PM, Sandy Walsh wrote: Wow, really? Is EC2 really that sporadic/chaotic? I have to plead ignorance because I don't know where the rubber meets the road, but that kinda surprises me. I'm not saying that. In fact let me say that I don't think the Windows API itself is sporadic or chaotic. I used to be a Windows dev way back in the day and I never got that impression. The problem is that the Windows API is not open and is not really designed to be implemented by others. The Wine folks (and the ReactOS folks) have been working really hard to implement it for a long time. And with good reason, there are a lot of incentives to have a free Windows compatible OS. The task the Wine folks have is very hard though. There are no reference implementations for the Windows API, so you can't look at the code, you have to replicate bugs in the implementation and bugs in client apps etc, oh and do you really think MS wants a free Windows compatible OS on the market? -- you have to account for them messing with you as well. Soren was suggesting that supporting EC2 was much like writing an implementation of HTTP or SMTP (both open specs with open reference implementations). All I'm saying is that reverse engineering a living, rapidly changing, closed system and writing another system that behaves like it exactly (bugs and all) is not the same thing as implementing an open spec -- it's harder. -jOrGe W. This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
2011/7/7 Jay Pipes jaypi...@gmail.com: Multiple zones is currently only supported in the OpenStack API, and the question has been raised whether effort should be expended to get parity in the EC2 API for this. The problem with the EC2 API is that we do not have control over the instance identifiers -- they are an 8 character text string. We would still need to map the EC2 instance identifier to some globally unique identifier (like a UUID), but the solutions for how to do this aren't pretty (see http://etherpad.openstack.org/EC2UUID). I don't particularly like the idea of maintaining a mapping table. If such a method is to be guaranteed to function, we need something that can reliably assign EC2-compatible ID's corresponding to the UUID's without collisions. If we can come up with such a method anyway, why use UUID's to begin with? (For the record, I do believe we *can* come up with such a method. I raised this point in one of the (several) disucssions we've had on the subject of ID's, but the ability to assign an unlimited amount of non-colliding ID's perpetually autonomously took precedence) I think the only sensible route is truncating (or by other means reducing) the UUIDs to 32 bits (or revisit (again) the choice of UUID's, of course). With a 32 bit key space, a user with 1 active objects of the same type (so in the same key space) will have a 1% chance of having colliding ID's. With ~78000 objects, we're at 50%. I guess that's a risk we'll have to live with. The tricky part is figuring out how to handle the collisions when they actually arise. -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
FYI, there's nothing in the EC2 API that limits instance identifiers (or other IDs) to 32 bits. The IDs are strings, so it's trivial for EC2 to add another digit when running out of 32-bit IDs. TvE On 7/7/2011 7:57 AM, Soren Hansen wrote: 2011/7/7 Jay Pipes jaypi...@gmail.com: Multiple zones is currently only supported in the OpenStack API, and the question has been raised whether effort should be expended to get parity in the EC2 API for this. The problem with the EC2 API is that we do not have control over the instance identifiers -- they are an 8 character text string. We would still need to map the EC2 instance identifier to some globally unique identifier (like a UUID), but the solutions for how to do this aren't pretty (see http://etherpad.openstack.org/EC2UUID). I don't particularly like the idea of maintaining a mapping table. If such a method is to be guaranteed to function, we need something that can reliably assign EC2-compatible ID's corresponding to the UUID's without collisions. If we can come up with such a method anyway, why use UUID's to begin with? (For the record, I do believe we *can* come up with such a method. I raised this point in one of the (several) disucssions we've had on the subject of ID's, but the ability to assign an unlimited amount of non-colliding ID's perpetually autonomously took precedence) I think the only sensible route is truncating (or by other means reducing) the UUIDs to 32 bits (or revisit (again) the choice of UUID's, of course). With a 32 bit key space, a user with 1 active objects of the same type (so in the same key space) will have a 1% chance of having colliding ID's. With ~78000 objects, we're at 50%. I guess that's a risk we'll have to live with. The tricky part is figuring out how to handle the collisions when they actually arise. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
Yes the issue isn't the actual api definition, the issue is that most of the ec2 clients expect the exact format that amazon currently uses ami-8 hex chars. I think we should move toward ec2 being a compatibility layer that is translated into the os api. This compatibility layer would sit at the top level zone and could maintain its own database for conversion of ids, management of secret and access keys, etc. On Jul 7, 2011, at 8:05 AM, Thorsten von Eicken wrote: FYI, there's nothing in the EC2 API that limits instance identifiers (or other IDs) to 32 bits. The IDs are strings, so it's trivial for EC2 to add another digit when running out of 32-bit IDs. TvE On 7/7/2011 7:57 AM, Soren Hansen wrote: 2011/7/7 Jay Pipes jaypi...@gmail.com: Multiple zones is currently only supported in the OpenStack API, and the question has been raised whether effort should be expended to get parity in the EC2 API for this. The problem with the EC2 API is that we do not have control over the instance identifiers -- they are an 8 character text string. We would still need to map the EC2 instance identifier to some globally unique identifier (like a UUID), but the solutions for how to do this aren't pretty (see http://etherpad.openstack.org/EC2UUID). I don't particularly like the idea of maintaining a mapping table. If such a method is to be guaranteed to function, we need something that can reliably assign EC2-compatible ID's corresponding to the UUID's without collisions. If we can come up with such a method anyway, why use UUID's to begin with? (For the record, I do believe we *can* come up with such a method. I raised this point in one of the (several) disucssions we've had on the subject of ID's, but the ability to assign an unlimited amount of non-colliding ID's perpetually autonomously took precedence) I think the only sensible route is truncating (or by other means reducing) the UUIDs to 32 bits (or revisit (again) the choice of UUID's, of course). With a 32 bit key space, a user with 1 active objects of the same type (so in the same key space) will have a 1% chance of having colliding ID's. With ~78000 objects, we're at 50%. I guess that's a risk we'll have to live with. The tricky part is figuring out how to handle the collisions when they actually arise. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
If I had to choose between dropping or truncating UUIDs and failing feature parity with the ec2 api, i'd go with the latter. Pros and cons for UUIDs have already been discussed and decisions made. The EC2 api shouldn't get in the way. A translation layer to sit in between the EC2 and OS APIs would solve this issue without revisiting the UUID argument. On Thu, Jul 7, 2011 at 9:57 AM, Soren Hansen so...@linux2go.dk wrote: 2011/7/7 Jay Pipes jaypi...@gmail.com: Multiple zones is currently only supported in the OpenStack API, and the question has been raised whether effort should be expended to get parity in the EC2 API for this. The problem with the EC2 API is that we do not have control over the instance identifiers -- they are an 8 character text string. We would still need to map the EC2 instance identifier to some globally unique identifier (like a UUID), but the solutions for how to do this aren't pretty (see http://etherpad.openstack.org/EC2UUID). I don't particularly like the idea of maintaining a mapping table. If such a method is to be guaranteed to function, we need something that can reliably assign EC2-compatible ID's corresponding to the UUID's without collisions. If we can come up with such a method anyway, why use UUID's to begin with? (For the record, I do believe we *can* come up with such a method. I raised this point in one of the (several) disucssions we've had on the subject of ID's, but the ability to assign an unlimited amount of non-colliding ID's perpetually autonomously took precedence) I think the only sensible route is truncating (or by other means reducing) the UUIDs to 32 bits (or revisit (again) the choice of UUID's, of course). With a 32 bit key space, a user with 1 active objects of the same type (so in the same key space) will have a 1% chance of having colliding ID's. With ~78000 objects, we're at 50%. I guess that's a risk we'll have to live with. The tricky part is figuring out how to handle the collisions when they actually arise. -- Soren Hansen| http://linux2go.dk/ Ubuntu Developer| http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
2011/7/7 Vishvananda Ishaya vishvana...@gmail.com: I think we should move toward ec2 being a compatibility layer that is translated into the os api. This compatibility layer would sit at the top level zone and could maintain its own database for conversion of ids, management of secret and access keys, etc. With all due respect, I think this is a terrible idea. From a technical perspective, a backend that is flexible enough to support both the EC2 and the OpenStack (and OCCI and vCloud and whatever else) APIs without translation layers is a good thing and helps keep the separation clean. From an adoption perspective, like it or not, EC2 is popular. Lots of people use it and are comfortable and familiar with its API. I don't see what we'll win by so thoroughly reducing the EC2 API to a second class citizen in Nova. -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
On 7/7/2011 8:53 AM, Soren Hansen wrote: 2011/7/7 Vishvananda Ishaya vishvana...@gmail.com: I think we should move toward ec2 being a compatibility layer that is translated into the os api. This compatibility layer would sit at the top level zone and could maintain its own database for conversion of ids, management of secret and access keys, etc. With all due respect, I think this is a terrible idea. From a technical perspective, a backend that is flexible enough to support both the EC2 and the OpenStack (and OCCI and vCloud and whatever else) APIs without translation layers is a good thing and helps keep the separation clean. From an adoption perspective, like it or not, EC2 is popular. Lots of people use it and are comfortable and familiar with its API. I don't see what we'll win by so thoroughly reducing the EC2 API to a second class citizen in Nova. I totally agree. I understand the issues around an API we don't control but the EC2 API has stood the test of time and a LOT of evolution. I have yet to work with a cloud API that comes anywhere close to it. There's a lot of benefit in treating it as a first class citizen in the OpenStack project (or at least as a 1.5th class citizen). Yes, it will cost some extra discussions, but that's worth it. The native API may one day make the EC2 one uninteresting, but that day is not yet on the horizon. I hope I'm not offending anyone, just trying to look at the reality. And yes, we are targeting the native API in our OpenStack support. Thorsten ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
The goal isn't for ec2 api to be a second class citizen, but to keep it from being a limiting factor since we don't have control over it. How does the compatibility layer make it second class? On Thu, Jul 7, 2011 at 10:53 AM, Soren Hansen so...@linux2go.dk wrote: 2011/7/7 Vishvananda Ishaya vishvana...@gmail.com: I think we should move toward ec2 being a compatibility layer that is translated into the os api. This compatibility layer would sit at the top level zone and could maintain its own database for conversion of ids, management of secret and access keys, etc. With all due respect, I think this is a terrible idea. From a technical perspective, a backend that is flexible enough to support both the EC2 and the OpenStack (and OCCI and vCloud and whatever else) APIs without translation layers is a good thing and helps keep the separation clean. From an adoption perspective, like it or not, EC2 is popular. Lots of people use it and are comfortable and familiar with its API. I don't see what we'll win by so thoroughly reducing the EC2 API to a second class citizen in Nova. -- Soren Hansen| http://linux2go.dk/ Ubuntu Developer| http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
2011/7/7 Trey Morris trey.mor...@rackspace.com: The goal isn't for ec2 api to be a second class citizen, but to keep it from being a limiting factor since we don't have control over it. How does the compatibility layer make it second class? Well, for one thing because you'll be limiting the EC2 API to what the OpenStack API is capable of doing and/or expressing. -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
On Jul 7, 2011, at 11:35 AM, Soren Hansen wrote: 2011/7/7 Trey Morris trey.mor...@rackspace.com: The goal isn't for ec2 api to be a second class citizen, but to keep it from being a limiting factor since we don't have control over it. How does the compatibility layer make it second class? Well, for one thing because you'll be limiting the EC2 API to what the OpenStack API is capable of doing and/or expressing. Actually, we can add any code that is necessary to make the ec2 api work properly as extensions to the os api. My main reason for suggesting the switch over to a compatibility layer is so that we don't have multiple code paths into the heart of nova. This has been a pain point already, and it will only get more painful as we move forward. If all the stuff that makes ec2 compatibility work is in one place at the top layer, it is easier to maintain. If we need to maintain entirely disparate code paths from the api all the way down to the hypervisor, things will continue to be very fragile. It means we have to make the ec2 api work across zones. It actually doesn't matter to me particularly if we are speaking to the rest api or some sort of internal api, but we are currently exposing the os api for multiple zones so it seems like we are moving in that direction. Vish ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
On Jul 7, 2011, at 11:46 AM, Trey Morris wrote: If I had to choose between dropping or truncating UUIDs and failing feature parity with the ec2 api, i'd go with the latter. Pros and cons for UUIDs have already been discussed and decisions made. The EC2 api shouldn't get in the way. A translation layer to sit in between the EC2 and OS APIs would solve this issue without revisiting the UUID argument. The code to use the first 8 chars of the UUID in the ec2 id was created and working well, but discarded in favor of a more limited approach. The only issue was the increased likelihood of a duplicate ec2 id, as we'd be limited to only 4 billion of them or so. I thought that it would be fairly straightforward to add code to detect such dupes, and re-generate a new UUID for the instance in that event. Then we would have no limits on ec2 compatibility, and we wouldn't need this discussion. -- Ed Leafe This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
From Thorsten von Eicken FYI, there's nothing in the EC2 API that limits instance identifiers (or other IDs) to 32 bits. The IDs are strings, so it's trivial for EC2 to add another digit when running out of 32-bit IDs. If that's the case (and I believe you, that's always how I assumed it would be) why don't we just make the EC2 ID be ami-uuid? Ewan. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?
Agreed. That's the downside of not having control of an API. Unless we do the Embrace and Extend thing, but that just seems fraught with problems if Amazon should zig when we zag. That said, top-level Zones may still operate using EC2 API, but all child-zones may be OS-API. We'd only need to translate at the outer level. Kind of like a Facade. -S From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net [openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of Jay Pipes [jaypi...@gmail.com] Sent: Wednesday, July 06, 2011 8:35 PM To: openstack@lists.launchpad.net Subject: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort? Hey all, Recently, Nova added support for multiple zones in the OpenStack API. Using the nova-manage tool, you can get a list of instances in a single zone or in multiple zones using the --recurse option. When just querying a local zone's API server, the listed instance identifiers will be integer IDs. When using the --recurse option, the listed instance identifiers are UUIDs since they are globally unique. Multiple zones is currently only supported in the OpenStack API, and the question has been raised whether effort should be expended to get parity in the EC2 API for this. The problem with the EC2 API is that we do not have control over the instance identifiers -- they are an 8 character text string. We would still need to map the EC2 instance identifier to some globally unique identifier (like a UUID), but the solutions for how to do this aren't pretty (see http://etherpad.openstack.org/EC2UUID). Personally, I don't think it is worth expending the effort to get this feature parity between the OpenStack API and the EC2 API, especially considering we have little (or no) control over the EC2 API. Thoughts? -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
