pvo, Yep. I'm responding to the slide having "3 services, 5 endpoints" (nova, glance, swift)
Since the number of endpoints will depend on deployment configuration. And nova being a single repository doesn't mean it is a single service. Jesse On Mar 1, 2011, at 1:07 AM, Paul Voccio wrote: > Jesse, > > I agree that some implementations can want to have a single endpoint. I think > this is doable with a simple proxy that can pass requests back to each > service apis. This can also be accomplished by having configuration variables > in your bindings to talk to something that looks like the following: > > compute=api.compute.example.com > volume=api.volume.example.com > image=api.image.example.com > network=api.network.example.com > > Or for behind the proxies: > > compute=api.example.com > volume=api.example.com > image=api.example.com > network=api.example.com > > Maybe this is something the auth services return? > > > From: Jesse Andrews <[email protected]> > Date: Mon, 28 Feb 2011 19:53:01 -0800 > To: Erik Carlin <[email protected]> > Cc: "[email protected]" <[email protected]> > Subject: Re: [Openstack] OpenStack Compute API for Cactus (critical!) > >> I'm also confused because nova (compute/block/network) is in 1 repository >> doesn't mean it isn't 3 different services. >> >> We've talked about moving the services inside nova to not reaching inside of >> each other via RPC calls and instead making HTTP calls. But they are mostly >> already designed in a way that allows them to operate independantly. >> >> And I would also say that while rackspace may deploy with 3 endpoints, >> openstack might want to deploy multiple services behind a single endpoint. >> >> Jesse >> >> On Feb 28, 2011, at 3:52 PM, Erik Carlin wrote: >> >>> I was talking with Will Reese about this more. If we are eventually going >>> to decompose into independent services with separate endpoints, he thought >>> we should do that now. I like that idea better. For cactus, we still have >>> a single nova service "black box" but we put multiple OpenStack API >>> endpoints on the front side, one for each future service. In other words, >>> use separate endpoints instead of extensions in a single endpoint to expose >>> the current capabilities. That way, it sets us on the right path and >>> consumers don't have to refactor to support between cactus and diable. In >>> diablo, we decompose into separate services and the endpoints move with >>> them. It's a bit hard to visualize so I put together the attached pdf. >>> I'm assuming glance is a separate service and endpoint for cactus (still >>> need to figure out per my message below) and swift already is. >>> >>> Erik >>> >>> From: Erik Carlin <[email protected]> >>> Date: Mon, 28 Feb 2011 17:07:22 -0600 >>> To: John Purrier <[email protected]>, <[email protected]> >>> Subject: Re: [Openstack] OpenStack Compute API for Cactus (critical!) >>> >>> That all sounds good. My only question is around images. Is glance ready >>> to be an independent service (and thus have a separate API) in Cactus? >>> >>> Erik >>> >>> From: John Purrier <[email protected]> >>> Date: Mon, 28 Feb 2011 16:53:53 -0600 >>> To: Erik Carlin <[email protected]>, <[email protected]> >>> Subject: RE: [Openstack] OpenStack Compute API for Cactus (critical!) >>> >>> Hi Erik, today we have compute, block/volume, and network all encompassed >>> in nova. Along with image and object storage these make the whole of >>> OpenStack today. The goal is to see where we are at wrt the OpenStack API >>> (compute/network/volume/image) and coverage of the underlying >>> implementation as well as what is available through the EC2 API today. >>> >>> I would propose that volume and network API’s be exposed not through the >>> core compute API, but as extensions. Once we create separate services and >>> factor network and volume services out of nova these API’s will form the >>> core API’s for these services. We may also need to up-version these service >>> API’s between Cactus and Diablo as they are currently under heavy >>> discussion and design. >>> >>> John >>> >>> From: Erik Carlin [mailto:[email protected]] >>> Sent: Monday, February 28, 2011 3:16 PM >>> To: John Purrier; [email protected] >>> Subject: Re: [Openstack] OpenStack Compute API for Cactus (critical!) >>> >>> John - >>> >>> Are we just talking about compute aspects? IMO, we should NOT be exposing >>> block functionality in the OS compute API. In Diablo, we will break out >>> block into a separate service with it's own OS block API. That means for >>> now, there may be functionality in nova that isn't exposed (an artifact of >>> originally mimicing EC2) until we can fully decompose nova into independent >>> services. >>> >>> Erik >>> >>> From: John Purrier <[email protected]> >>> Date: Mon, 28 Feb 2011 14:16:20 -0600 >>> To: <[email protected]> >>> Subject: [Openstack] OpenStack Compute API for Cactus (critical!) >>> >>> Has anyone done a gap analysis against the proposed OpenStack Compute API >>> and a) the implemented code, and b) the EC2 API? >>> >>> It looks like we have had a breakdown in process, as the community review >>> process of the proposed spec has not generated discussion of the missing >>> aspects of the proposed spec. >>> >>> Here is what we said on Feb 3 as the goal for Cactus: >>> >>> OpenStack Compute API completed. We need to complete a working set of API's >>> that are consistent and inclusive of all the exposed functionality. >>> >>> We need to *very* quickly identify the missing elements that are required >>> in the OpenStack Compute API, and then discuss how we mobilize to get this >>> work done for Cactus. As this is the #1 priority for this release there are >>> implications on milestones dates depending on the results of this exercise. >>> The 1.1 spec should be complete and expose all current Nova functionality >>> (superset of EC2/RS). >>> >>> Dendrobates, please take the lead on this, anyone who can help please >>> coordinate with Rick. Can we get a fairly complete view by EOD tomorrow? >>> Please set up a wiki page to identify the gaps, I suggest 3 columns (Actual >>> code / EC2 / OpenStack Compute). >>> >>> Thanks, >>> >>> John >>> _______________________________________________ Mailing list: >>> https://launchpad.net/~openstack Post to : [email protected] >>> Unsubscribe : https://launchpad.net/~openstack More help : >>> https://help.launchpad.net/ListHelp >>> >>> Confidentiality Notice: This e-mail message (including any attached or >>> embedded documents) is intended for the exclusive and confidential use of >>> the >>> individual or entity to which this message is addressed, and unless >>> otherwise >>> expressly indicated, is confidential and privileged information of >>> Rackspace. >>> Any dissemination, distribution or copying of the enclosed material is >>> prohibited. >>> If you receive this transmission in error, please notify us immediately by >>> e-mail >>> at [email protected], and delete the original message. >>> Your cooperation is appreciated. >>> Confidentiality Notice: This e-mail message (including any attached or >>> embedded documents) is intended for the exclusive and confidential use of >>> the >>> individual or entity to which this message is addressed, and unless >>> otherwise >>> expressly indicated, is confidential and privileged information of >>> Rackspace. >>> Any dissemination, distribution or copying of the enclosed material is >>> prohibited. >>> If you receive this transmission in error, please notify us immediately by >>> e-mail >>> at [email protected], and delete the original message. >>> Your cooperation is appreciated. >>> <Cactus-Diablo APIs.pdf>_______________________________________________ >>> Mailing list: https://launchpad.net/~openstack >>> Post to : [email protected] >>> Unsubscribe : https://launchpad.net/~openstack >>> More help : https://help.launchpad.net/ListHelp >> >> _______________________________________________ Mailing list: >> https://launchpad.net/~openstack Post to : [email protected] >> Unsubscribe : https://launchpad.net/~openstack More help : >> https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
