openstack team mailing list archive

[Paul Voccio <paul.voccio@xxxxxxxxxxxxx>]

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 <anotherjesse@xxxxxxxxx<mailto:anotherjesse@xxxxxxxxx>>
Date: Mon, 28 Feb 2011 19:53:01 -0800
To: Erik Carlin <erik.carlin@xxxxxxxxxxxxx<mailto:erik.carlin@xxxxxxxxxxxxx>>
Cc: "openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>" <openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>>
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 <erik.carlin@xxxxxxxxxxxxx<mailto:erik.carlin@xxxxxxxxxxxxx>>
Date: Mon, 28 Feb 2011 17:07:22 -0600
To: John Purrier <john@xxxxxxxxxxxxx<mailto:john@xxxxxxxxxxxxx>>, <openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>>
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 <john@xxxxxxxxxxxxx<mailto:john@xxxxxxxxxxxxx>>
Date: Mon, 28 Feb 2011 16:53:53 -0600
To: Erik Carlin <erik.carlin@xxxxxxxxxxxxx<mailto:erik.carlin@xxxxxxxxxxxxx>>, <openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>>
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:erik.carlin@xxxxxxxxxxxxx]
Sent: Monday, February 28, 2011 3:16 PM
To: John Purrier; openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>
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 <john@xxxxxxxxxxxxx<mailto:john@xxxxxxxxxxxxx>>
Date: Mon, 28 Feb 2011 14:16:20 -0600
To: <openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>>
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 : openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx> 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 abuse@xxxxxxxxxxxxx<mailto:abuse@xxxxxxxxxxxxx>, 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 abuse@xxxxxxxxxxxxx<mailto:abuse@xxxxxxxxxxxxx>, and delete the original message.
Your cooperation is appreciated.


<Cactus-Diablo APIs.pdf>_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx> Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp