Re: [Openstack] Federated Identity Management (bursting and zones)
From: Eric Day [e...@oddments.org] Well, they should start off with what the request specifies. For the 1.1 API, this takes the for of POST /v1.1/owner/servers/ so owner would be the owner. This could be anything depending on what the authenticated user has access to do and what the authz system defines for types, but Nova doesn't care as it's just a string. Yes, this is a slight variation on our previous discussions, but I like it. What we're saying is that Instance (resource) names will be prefixed with container names and permissions will be applied to containers. It's good because it solves the problem of on behalf of. However, what I need to wrap my head around is how this would work in a federated fashion. MyCo has a container structure and SP has a container structure. We need to manage permissions on: /myco/instances/finance/ami- /myco/instances/alice/ami- /myco/instance/bob/ami-*** /sp/myco/instances/finance/ami-*** /sp/myco/instances/alice/ami-*** /sp/myco/instances/bob/ami-*** and place the permissions at the top of the tree. Or, /instances/finance/myco/ami-*** /instances/finance/SP/ami-*** and place the permissions at the /instances/finance level ... but how would these transfer across the public/private zone boundaries? (since MyCo.authz controls the permissions and SP.authz just enforces it) From an end-user perspective, does Alice or Bob need to know to manage permissions for MyCo and for the situations when the instances live with SP? I need to stew on that some more. This implies, of course, that there would be a means to chgrp() a resource in Nova across Zones. Not a big deal and pretty handy actually. Well, we may not always want to change the owner for this, we may want to simply add to the list of entities (user/groups/whatever) that can access it. Owner alone is not enough. In this scenario chgrp() would equate to a move() operation ... to move from one container to another. but I don't care enough to spend time on what we call it. :) +1 One thing to also think about is where we actually describe permissions. I mentioned this briefly in a previous thread, but I think this needs more exploration. Lets approach authz as looking at what Swift does today and expanding on it. A authenticated user in swift gets a list of 'groups' that user belongs to. This is just like what we've been talking about, except swift only has group name, not (group,action) tuples. A name in the group list can be anything, from another account, a tag, whatever. It's just a string. For now lets use 'group' and mean account/entity/whatever from above. There are then permissions on containers that specify actions for groups (think of group/action tuples on a resource). So if container X has write permission for group A, a user with group A in their list can insert objects there. The shortcoming with this model is that you need a resource to exist to assign permissions to it (for example, a container needs to be created by the account owner first). I asked Chuck and it sounds like you can't specify group A can create containers for group/account B. Not sure if I like the idea of read/write permissions vs. Rights (strings), but that's a side discussion. With Rights we could grant permission for a user to create a new container and assign Account B access to it. can_create_container, can_change_owner Or perhaps I'm missing the subtly here. In Nova, and probably other services, we want the ability to specify actions for groups when a resource doesn't exist. For example, I want to give group A the ability to create instances for group B, but there is no container resource yet. The obvious way to solve this is to do what we've been discussing and have the authz system return not just group name, but (group,action) tuples. Can't the user just create the container first and then create the instance in the container? The question now is do we restrict the types of actions that can be specified in the authz system vs per-resource for a service? If you can specify can_reboot in both the authz system and per-resource, how are ambiguities resolved? For example, the authz system may return (group A, [can_create, can_reboot]), but an instance record may contain the permission tuple (group A, can_associate_ip). What can group A really do to that instance? Is it the union, intersection, or the most specific set of actions? If we design our authz in this way, we just need to be aware and choose. I'm not clear how we ended up with permissions in two places? I thought the AuthZ would manage the tree of containers and permissions, not the services. The service would just do the permission check. Are you talking about per-resource overrides on the authz permissions? -S -Eric Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the
Re: [Openstack] Federated Identity Management (bursting and zones)
On Thu, Apr 07, 2011 at 11:54:26AM +, Sandy Walsh wrote: Well, they should start off with what the request specifies. For the 1.1 API, this takes the for of POST /v1.1/owner/servers/ so owner would be the owner. This could be anything depending on what the authenticated user has access to do and what the authz system defines for types, but Nova doesn't care as it's just a string. Yes, this is a slight variation on our previous discussions, but I like it. What we're saying is that Instance (resource) names will be prefixed with container names and permissions will be applied to containers. Not really. We don't have containers in Nova now, and I don't think we really need them. I just meant that owner is a required parameter when creating an instance, so the API needs to get it from somewhere (default to authenticated user, from path, json param, etc). The above could be POST /v1.1/servers just like it is today, and owner was given in the JSON of the request body. owner required just like flavor, image, etc. and place the permissions at the top of the tree. Or, /instances/finance/myco/ami-*** /instances/finance/SP/ami-*** and place the permissions at the /instances/finance level ... but how would these transfer across the public/private zone boundaries? (since MyCo.authz controls the permissions and SP.authz just enforces it) What do you mean SP.authz enforces? SP.authz should not ever be contacted when dealing with MyCO.authz users, no? This implies, of course, that there would be a means to chgrp() a resource in Nova across Zones. Not a big deal and pretty handy actually. Well, we may not always want to change the owner for this, we may want to simply add to the list of entities (user/groups/whatever) that can access it. Owner alone is not enough. In this scenario chgrp() would equate to a move() operation ... to move from one container to another. Hmm, you lost me here. :) One thing to also think about is where we actually describe permissions. I mentioned this briefly in a previous thread, but I think this needs more exploration. Lets approach authz as looking at what Swift does today and expanding on it. A authenticated user in swift gets a list of 'groups' that user belongs to. This is just like what we've been talking about, except swift only has group name, not (group,action) tuples. A name in the group list can be anything, from another account, a tag, whatever. It's just a string. For now lets use 'group' and mean account/entity/whatever from above. There are then permissions on containers that specify actions for groups (think of group/action tuples on a resource). So if container X has write permission for group A, a user with group A in their list can insert objects there. The shortcoming with this model is that you need a resource to exist to assign permissions to it (for example, a container needs to be created by the account owner first). I asked Chuck and it sounds like you can't specify group A can create containers for group/account B. Not sure if I like the idea of read/write permissions vs. Rights (strings), but that's a side discussion. I was reviewing what Swift does above, not making suggestions for Nova. In Nova, and probably other services, we want the ability to specify actions for groups when a resource doesn't exist. For example, I want to give group A the ability to create instances for group B, but there is no container resource yet. The obvious way to solve this is to do what we've been discussing and have the authz system return not just group name, but (group,action) tuples. Can't the user just create the container first and then create the instance in the container? As I mentioned above, I don't think we should introduce containers, which gets back to the issue of how to grant group-level permission without a resource (such as ability to create new resources). Switching from the swift style group list to (group,action) list solves this. The question now is do we restrict the types of actions that can be specified in the authz system vs per-resource for a service? If you can specify can_reboot in both the authz system and per-resource, how are ambiguities resolved? For example, the authz system may return (group A, [can_create, can_reboot]), but an instance record may contain the permission tuple (group A, can_associate_ip). What can group A really do to that instance? Is it the union, intersection, or the most specific set of actions? If we design our authz in this way, we just need to be aware and choose. I'm not clear how we ended up with permissions in two places? I thought the AuthZ would manage the tree of containers and permissions, not the services. The service would just do the permission check. Are you talking about per-resource overrides on the authz permissions? Yes. We could have authz for an entity
[Openstack] Proposal for Justin Santa Barbara to join Nova-Core
Hey all, Subject basically says it all. Justin has proven to be a regular and thorough reviewer and unless he objects, I propose he join the nova-core team as a core reviewer. -jay ___ 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] Proposal for Justin Santa Barbara to join Nova-Core
+1 On Thu, Apr 7, 2011 at 2:18 PM, Jay Pipes jaypi...@gmail.com wrote: Hey all, Subject basically says it all. Justin has proven to be a regular and thorough reviewer and unless he objects, I propose he join the nova-core team as a core reviewer. -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ 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] Proposal for Justin Santa Barbara to join Nova-Core
+1 On Apr 7, 2011, at 12:18 PM, Jay Pipes wrote: Hey all, Subject basically says it all. Justin has proven to be a regular and thorough reviewer and unless he objects, I propose he join the nova-core team as a core reviewer. -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ 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] Proposal for Justin Santa Barbara to join Nova-Core
+2 :) Sent from my iPhone On Apr 7, 2011, at 12:18 PM, Jay Pipes jaypi...@gmail.com wrote: Hey all, Subject basically says it all. Justin has proven to be a regular and thorough reviewer and unless he objects, I propose he join the nova-core team as a core reviewer. -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ 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] Proposal for Justin Santa Barbara to join Nova-Core
+1 From: openstack-bounces+rick.harris=rackspace@lists.launchpad.net [openstack-bounces+rick.harris=rackspace@lists.launchpad.net] on behalf of Vishvananda Ishaya [vishvana...@gmail.com] Sent: Thursday, April 07, 2011 2:19 PM To: Jay Pipes Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Proposal for Justin Santa Barbara to join Nova-Core +1 On Apr 7, 2011, at 12:18 PM, Jay Pipes wrote: Hey all, Subject basically says it all. Justin has proven to be a regular and thorough reviewer and unless he objects, I propose he join the nova-core team as a core reviewer. -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net 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 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
Re: [Openstack] Last day before GammaFreeze and Gamma milestone release !
These are all looking to be in good shape. I approved for merge all the ones that have sufficient reviews. On Apr 7, 2011, at 2:23 AM, Thierry Carrez wrote: Hello everyone, Today is the last day of unrestricted bugfix merging. At the end of the day (23:59 PST) we'll switch to release-critical bugfixing only, in order to avoid introducing a last-minute critical issue. That means we need to get as many of those 42+1+3 in progress fixes in by the end of the day, so please wear your reviewer suit today. The non-critical bugfixes that don't get merged will have to wait one week for Diablo to open. In particular, I'd like to see the following fixes make it: Nova: Some instances can't connect to metadata due to ARP failure https://code.launchpad.net/~vishvananda/nova/automatic-metadata/+merge/56672 Nova: Incoherent use of is_public creates havoc when using euca-describe-images https://code.launchpad.net/~vishvananda/nova/fix-describe-images/+merge/55617 Nova: live_migration failing due to network filter not found https://code.launchpad.net/~nttdata/nova/lp746821/+merge/56322 Nova: Sporadic failure when creating XS vms from machine-images https://code.launchpad.net/~johannes.erdfelt/nova/bug732801/+merge/56625 Glance: glance-manage not respecting config https://code.launchpad.net/~jaypipes/glance/bug742190/+merge/56220 Swift: .pot files not being generated in setup.py build https://code.launchpad.net/~jaypipes/swift/bug752610/+merge/56593 Thanks, -- 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 ___ 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-poc] PPB Meeting tomorrow
cool with me. On Thu, Apr 7, 2011 at 2:46 PM, Jonathan Bryce jbr...@jbryce.com wrote: So no one has had anything they wanted to discuss. I propose we skip this week's meeting and let everyone have a productive hour back. Any objections? Jonathan. On Apr 6, 2011, at 12:47 PM, Jonathan Bryce wrote: Anyone have any agenda items for tomorrow? Thierry has scheduled a session at the design summit to talk releases which was a pending item. I don't have anything else to discuss right now. Jonathan. ___ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp
Re: [Openstack-poc] PPB Meeting tomorrow
Fine by me. Thanks, Ewan. -Original Message- From: openstack-poc-bounces+ewan.mellor=citrix@lists.launchpad.net [mailto:openstack-poc- bounces+ewan.mellor=citrix@lists.launchpad.net] On Behalf Of Jonathan Bryce Sent: 07 April 2011 19:47 To: openstack-poc@lists.launchpad.net Subject: Re: [Openstack-poc] PPB Meeting tomorrow So no one has had anything they wanted to discuss. I propose we skip this week's meeting and let everyone have a productive hour back. Any objections? Jonathan. On Apr 6, 2011, at 12:47 PM, Jonathan Bryce wrote: Anyone have any agenda items for tomorrow? Thierry has scheduled a session at the design summit to talk releases which was a pending item. I don't have anything else to discuss right now. Jonathan. ___ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp
