Re: [Openstack] [Merge] lp:~mdragon/nova/multi-tenant-accounting into lp:nova
Justin Santa Barbara wrote: The usages system (which is dependant on this) ... It has not been coded yet, since it is dependant on this multitenant bp. It *is* scheduled, and approved for the cactus release, for which merge-prop freeze is in ~2 weeks. Ouch. Even though it's approved though, my understanding is that we're not obligated to deliver it, because we're doing time-based releases, not feature-based releases ? (And that is a question - any PM types want to chip in here?) The only specs we *have to* deliver are the ones marked essential in the plan. Those may even push back release dates if needed. The two mentioned specs are Medium priority, which means should have. So we are not obligated to deliver them, as far as the project is concerned, but we should do our best to try, if it doesn't jeopardize the Essential and High specs. I hope that answers your question. -- Thierry Carrez (ttx) Release Manager, OpenStack ___ 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] [Merge] lp:~mdragon/nova/multi-tenant-accounting into lp:nova
I think, really, we are getting off on a tangent here. The purpose of
multitenant is to have a label ('account' or 'project' or whatever )
that we tag resources (instances, etc) in nova with so that we can group
together usage reports, etc, that go to some system outside of openstack for
reporting/billing/etc purpose.
I think the purpose of multitenant is to support multiple tenants :-)
It's not clear to me that you can't do this multi-tenant billing /
reporting with what we have today - without changing the URL, we know the
user-id today (with our 'stub' auth). We'll likely know _more_ when
real-auth lands.
Can you explain what the proposed patch actually achieves?
I think maybe the problem is that the patches are in the wrong order - I'm
guessing you have a billing/reporting solution and know that this is
required, but you haven't contributed it yet. Without that, we can't see
the reason why you were motivated to make this change. (This out-of-order
patching is something I'm very guilty of as well!)
Justin
___
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] [Merge] lp:~mdragon/nova/multi-tenant-accounting into lp:nova
Taking this from the MP to ML for wider audience. On Thu, Mar 03, 2011 at 11:29:43PM -, Monsyne Dragon wrote: Actually, the OpenStack API only defines compute methods, it punts on auth currently (as it should). There is no definitive OpenStack Auth document or service right now, which is what all the recent chatter is about. We need one, and we need a common service. This is bigger than just OpenStack API in Nova. While cloud servers uses token based auth, there is nothing saying we need to. The OpenStack API in Nova could take a basic auth request directly if the current middleware is replaced, which means there is no service URL returned from the token validation (there is no service URL, we're already at the service). There are other methods of handling service URLs with methods without tokens such as a http redirect, but it's not been discussed at all. Yah, I wasn't talking about the auth specifically. I was explaining that the openstack apis defined as being off of an endpoint found by some sort of service discovery, (in this case the url returned in the headers of the auth request.), thus changing that endpoint url will not break existing clients. Getting into this a bit more, I'm not sure this is something that should be the default. For CloudServers v1.0 token auth compatibility, I'm not even sure this is the best path. It seems like this is something that should be handled at the service level with the API version, not by the token server. For v1.0, account=user from token. For v1.1, just look at the path element for account. Speaking for just OpenStack in general, I don't think we should generate a token or provide a service URL (once we have a token server) with a hard coded account ID. For example, If I authn with account 'eday' and I have access to two other accounts representing groups in my org, 'dev' and 'production', should I really need two tokens to interact with each? I think we should just have one token auth, and then I get: X-Compute-Service: http://nova.openstack.org/v1.1 X-Auth-Token: eday_token X-Auth-Groups: dev, production # probably not the best discovery mechanism And then I can: # Launch a server in my account POST /v1.1/eday/servers Host: nova.openstack.org X-Auth-Token: eday_token # Launch a server in production POST /v1.1/production/servers Host: nova.openstack.org X-Auth-Token: eday_token # Launch a server in dev POST /v1.1/dev/servers Host: nova.openstack.org X-Auth-Token: eday_token # List all servers in my account and accounts I have access to # Probably not the best method, but gets the idea out there GET /v1.1/*/servers Host: nova.openstack.org X-Auth-Token: eday_token All this is done with the same token, I didn't need three tokens and service URLs for each account I'm a part of. -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] [Merge] lp:~mdragon/nova/multi-tenant-accounting into lp:nova
On 3/3/11 5:51 PM, Eric Day wrote: Taking this from the MP to ML for wider audience. On Thu, Mar 03, 2011 at 11:29:43PM -, Monsyne Dragon wrote: Actually, the OpenStack API only defines compute methods, it punts on auth currently (as it should). There is no definitive OpenStack Auth document or service right now, which is what all the recent chatter is about. We need one, and we need a common service. This is bigger than just OpenStack API in Nova. While cloud servers uses token based auth, there is nothing saying we need to. The OpenStack API in Nova could take a basic auth request directly if the current middleware is replaced, which means there is no service URL returned from the token validation (there is no service URL, we're already at the service). There are other methods of handling service URLs with methods without tokens such as a http redirect, but it's not been discussed at all. Yah, I wasn't talking about the auth specifically. I was explaining that the openstack apis defined as being off of an endpoint found by some sort of service discovery, (in this case the url returned in the headers of the auth request.), thus changing that endpoint url will not break existing clients. Getting into this a bit more, I'm not sure this is something that should be the default. For CloudServers v1.0 token auth compatibility, I'm not even sure this is the best path. It seems like this is something that should be handled at the service level with the API version, not by the token server. For v1.0, account=user from token. For v1.1, just look at the path element for account. sorry, a bit confused... I'm not even sure this is the best path... 'this' == ? (mental buffer overflow here...) Speaking for just OpenStack in general, I don't think we should generate a token or provide a service URL (once we have a token server) with a hard coded account ID. For example, If I authn with account 'eday' and I have access to two other accounts representing groups in my org, 'dev' and 'production', should I really need two tokens to interact with each? I think we should just have one token auth, and then I get: [example trimmed] in the case of the v1.1 api, yes, that would be much preferred. Simply spec the account as part of the url for the api, thus the token is an auth for a given user, on whatever account he has access to. (actually, I just thought of another problem w/ our current service url, too, namely, we include the version identifier in the server-management-url :P ) The mergeprop I have is for fixing the v1.0 api to work the way CloudServers currently does, so we can inject an account identifier, without breaking current clients. We haven't really started implementing the v1.1 api yet, and that isn't going to make cactus. -- -- -Monsyne Dragon work: 210-312-4190 mobile210-441-0965 google voice: 210-338-0336 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 ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
