<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jul 8, 2011, at 10:36 AM, Sandy Walsh wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>+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. <br><br>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.<br><br>That said, is this the proposal I'm hearing? ...<br><br>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?<br><br>So, instead of <br><br>EC2 Client OS Client<br> | |<br>EC2 API OS API<br> \ /<br> [Service] API<br><br>We'd be shifting to:<br><br>EC2 Client ---- EC2 API<br> |<br>OS Client ------ OS API<br> |<br> [Service] API<br><br>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?<br><br></div></blockquote><div><br></div><div>I think it actually looks more like this right now: </div><div><br></div></div><br><div><span class="Apple-style-span" style="font-family: 'Courier New'; ">EC2 Client OS Client</span></div><div><div><font class="Apple-style-span" face="'Courier New'"> | |</font></div><div><font class="Apple-style-span" face="'Courier New'">EC2 API OS API</font></div><div><font class="Apple-style-span" face="'Courier New'"> \ /</font></div><div><font class="Apple-style-span" face="'Courier New'"> [nova-*] service APIs</font></div></div><div><br></div><div>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). </div><div><br></div><div>I would advocate for something more like this:</div><div><br></div><div><br></div><div><div><span class="Apple-style-span" style="font-family: 'Courier New'; ">EC2 Client OS Client</span></div><div><div><font class="Apple-style-span" face="'Courier New'"> | |</font></div><div><font class="Apple-style-span" face="'Courier New'">EC2 API OS API</font></div><div><font class="Apple-style-span" face="'Courier New'"> \ /</font></div><div><font class="Apple-style-span" face="'Courier New'"> internal nova API</font></div></div></div><div><font class="Apple-style-span" face="'Courier New'"> |</font></div><div><font class="Apple-style-span" face="'Courier New'"><div style="font-family: Helvetica; "><div><font class="Apple-style-span" face="'Courier New'"> [nova-*] service APIs</font></div><div><font class="Apple-style-span" face="'Courier New'"><br></font></div><div><font class="Apple-style-span" face="'Courier New'"><br></font></div></div></font></div><div><font class="Apple-style-span" face="'Courier New'"><div style="font-family: Helvetica; ">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.</div><div style="font-family: Helvetica; "><br></div><div style="font-family: Helvetica; "><br></div><div style="font-family: Helvetica; "><span class="Apple-style-span" style="font-size: 12px; ">Lorin</span></div><div style="font-family: Helvetica; "><span class="Apple-style-span" style="font-size: 12px; ">--</span></div><div><div style="font-family: Helvetica; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Lorin Hochstein, Computer Scientist</div><div>USC Information Sciences Institute<br></div><div>703.812.3710</div><div><a href="http://www.east.isi.edu/~lorin">http://www.east.isi.edu/~lorin</a></div><div><br></div></div></span></div></span></div></span></div></span></span></div></div></font></div></body></html>