<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page Section1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-GB link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>>
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. <br>
<br>
</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>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.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>>
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 <o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>>
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.<br>
<br>
</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I have no idea what you’re trying to say here. Could
you try again?<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>> </span><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>3)
We fail if we put native debugging capability in front of properly architected
and designed OS API semantics<br>
<br>
</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Nobody did, did they? We are all trying very hard to make
the OpenStack API the best that it can be.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>>
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 <o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>>
context but still..)<br>
<br>
</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>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).<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>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.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>> </span><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>We
all need to get out of reactive, myopic, API-to-API-parity mode and into
OpenStack centric API capability mode.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Tahoma","sans-serif"'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>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.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>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.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Cheers,<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Ewan.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div style='border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt'>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'>
<p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:
"Tahoma","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:10.0pt;
font-family:"Tahoma","sans-serif"'> Jan Drake [mailto:jan_drake@hotmail.com] <br>
<b>Sent:</b> 11 July 2011 01:44<br>
<b>To:</b> Ewan Mellor; devin.carlen@gmail.com; soren@linux2go.dk<br>
<b>Cc:</b> chris.behrens@rackspace.com; ed.leafe@rackspace.com;
openstack@lists.launchpad.net<br>
<b>Subject:</b> RE: [Openstack] Cross-zone instance identifiers in EC2 API - Is
it worth the effort?<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<div>
<p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:10.0pt;
font-family:"Tahoma","sans-serif"'>First, y'all need to remember that it isn't
just AWS... it's N systems that back-end OS API over time.<br>
<br>
Ewan, I understand your intent, but it is a bit myopic:<br>
<br>
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. <br>
<br>
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.<br>
<br>
3) We fail if we put native debugging capability in front of properly
architected and designed OS API semantics<br>
<br>
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..)<br>
<br>
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. <br>
<br>
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.<br>
<br>
We all need to get out of reactive, myopic, API-to-API-parity mode and into
OpenStack centric API capability mode.<br>
<br>
OpenStack will win on ubiquity of cloud capability not on API/feature parity
with whomever is out there.<br>
<br>
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_drake@hotmail.com.<br>
<br>
I'd value key architects for OS reaching out to me on this and other topics.<br>
<br>
Jan Drake<o:p></o:p></span></p>
<div>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>>
From: Ewan.Mellor@eu.citrix.com<br>
> To: devin.carlen@gmail.com; soren@linux2go.dk<br>
> Date: Mon, 11 Jul 2011 06:43:32 +0100<br>
> CC: chris.behrens@rackspace.com; ed.leafe@rackspace.com;
openstack@lists.launchpad.net<br>
> Subject: Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is
it worth the effort?<br>
> <br>
> > From: Devin Carlen<br>
> > <br>
> > Here's a few crazy questions for you guys to consider:<br>
> > <br>
> > 1) Why are we even trying to have the same ID for an instance or
image<br>
> > across two different APIs?<br>
> <br>
> To reduce complexity (particularly when trying to debug the system as a
whole).<br>
> <br>
> > 2) How many people really switch back and forth between OpenStack and<br>
> > EC2 API once they pick one?<br>
> <br>
> 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.<br>
> <br>
> 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.<br>
> <br>
> > 3) How many people really expect euca2ools and python-novatools to<br>
> > return the same IDs for the same instances?<br>
> <br>
> It sure would make it a lot easier to debug!<br>
> <br>
> > 4) Why not just store a EC2 ID and a OS ID alongside an actual row
PK?<br>
> > <br>
> > My point with these questions is that very little is gained from<br>
> > forcing two different APIs to try to use the same ID, especially
given<br>
> > that the format is different. I would argue that it has created a lot<br>
> > more problems than it has solved.<br>
> <br>
> 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.<br>
> <br>
> 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.<br>
> <br>
> Ewan.<br>
> <br>
> <br>
> > <br>
> > <br>
> > Devin<br>
> > <br>
> > <br>
> > <br>
> > On Jul 8, 2011, at 3:12 PM, Soren Hansen wrote:<br>
> > <br>
> > > 2011/7/8 Vishvananda Ishaya <vishvananda@gmail.com>:<br>
> > >> Yes they seem to apply to all ids<br>
> > >> r-XXXXXXX<br>
> > >> ami-XXXXXXX<br>
> > >> i-XXXXXXX<br>
> > >> vol-XXXXXXX<br>
> > >> snap-XXXXXXX<br>
> > >><br>
> > >> That said we are using base-36 for the hex in reservation
ids and no<br>
> > one has complained, so i don't think they are used by the tools that<br>
> > much.<br>
> > ><br>
> > > Not true. ElasticFox does not work with this.<br>
> > ><br>
> > > I don't think we're yet at a point where we can say that lack of<br>
> > > complaints about stuff means something's fine. That sort of<br>
> > assumption<br>
> > > only starts to be useful when we have lots of real users. The
users<br>
> > we<br>
> > > have so far are people who care about OpenStack for OpenStack's
sake,<br>
> > > not "random" users who are being given access to an
OpenStack<br>
> > > deployment and being told "talk to this like you would talk
to EC2.<br>
> > > It'll work fine." Different expectations.<br>
> > ><br>
> > > --<br>
> > > Soren Hansen | http://linux2go.dk/<br>
> > > Ubuntu Developer | http://www.ubuntu.com/<br>
> > > OpenStack Developer | http://www.openstack.org/<br>
> > ><br>
> > > _______________________________________________<br>
> > > Mailing list: https://launchpad.net/~openstack<br>
> > > Post to : openstack@lists.launchpad.net<br>
> > > Unsubscribe : https://launchpad.net/~openstack<br>
> > > More help : https://help.launchpad.net/ListHelp<br>
> > <br>
> > <br>
> > _______________________________________________<br>
> > Mailing list: https://launchpad.net/~openstack<br>
> > Post to : openstack@lists.launchpad.net<br>
> > Unsubscribe : https://launchpad.net/~openstack<br>
> > More help : https://help.launchpad.net/ListHelp<br>
> <br>
> _______________________________________________<br>
> Mailing list: https://launchpad.net/~openstack<br>
> Post to : openstack@lists.launchpad.net<br>
> Unsubscribe : https://launchpad.net/~openstack<br>
> More help : https://help.launchpad.net/ListHelp<o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</body>
</html>