Re: [Openstack] Pondering multi-tenant needs in nova.
This is slightly tangental but assume there are environments running both Swift and Nova with a set of customers using both compute and object store services. For example, user johnsmith logs into his future openstack portal and sees both his VMs and his files and containers. Even though these two underlying services are separate technologies its likely we will be be creating facilities to integrate them for various functions. In the future when I backup or save my VM, those disk image archives should be uploaded to my swift account in some special container so that that disk space used can be billed accordingly against johnsmith. I may then in the future spawn a new VM and the source of the image would be a swift container:object. I may also upload an ISO to swift and create new images from scratch by having kvm/xen boot from the ISO and I use ajaxterm to install the OS, etc. I just list these as possibilities to strengthen my case that there could be a 1 to 1 relationship to swift and nova accounts. With this relationship, I will then also need facilities to impersonate or carry out API commands on behalf johnsmith from nova to swift. How does nova send something to swift on half of specific account without storing the actual credentials of the swift users in nova? The simple answer could just be a private set of swift proxies with custom auth middleware, but we still need to track this 1 to 1 relationship of accounts, or we need to unify auth/project/account layers? Maybe somebody has already thought this out and knows a simpler way to do it? -JC On Feb 8, 2011, at 10:15 AM, Paul Voccio wrote: On 2/8/11 10:30 AM, Vishvananda Ishaya vishvana...@gmail.com wrote: This thread is enormous, so I'm I'm going to briefly summarize the two options as I see them: 1. Project Id is an opaque string, and it simply represents some kind of collection of users. It is the responsibility of external systems (authn, authz, billing, and monitoring) to define what the string means, and what the relationships between the different groups and objects are. Nova needs a few plug-in points to authn and authz, but the logic relating these projects to users happens external to the nova code. Networking concerns are isolated to the project level. Pros: * Almost no changes to existing code (supporting multiple networks per project isonly necessary if we want to support multi-tenancy in vlan mode) Won't we still have to support multiple networks per project in flat networking as well? You could go into multiple zones, supported by different networking gear that will need different networks routed to them. * project code is simple and unencumbered (most small deployments don't need multi-tenancy) Cons: * pushing a lot of potentially useful code into external systems * potential for lack of code sharing between external sytsems 2. We change the project code into a more general concept of groups. Groups can contain other groups, and users and groups can be members of multiple groups. This would mirror the possibilities available in ldap. Pros: * Greater flexibility of implementation. * Group implementation code is in one place, minimizing different implementations per component Cons: * Much more complexity in the nova code. * The greater complexity/flexibility won't be needed for smaller deployments. This seems like it is an issue only larger deployments of Nova will encounter. Trying to guess how someone will try to implement and bill for resellers and groups and which group should have access to another group's resources seems almost out of scope at the moment. Both of these options seem viable to me, but I'm actually leaning toward adding flexible groups into nova proper. A complete authentication system IMO needs to support, flexible groups. If we increase the flexibility of nova in this regard, it gives us a springboard to breaking out authz into a more complete separate service. I like this more than rewriting the entire thing from scratch as a completely new component. Vish On Feb 8, 2011, at 8:11 AM, Jay Pipes wrote: Hey Paul, yeah, see what happens when you take a little time away from email? ;P So, I'm satisfied that I've highlighted the trade-offs that come along with Nova not inherently understanding the relationships between accounts. Having an external system understand these account relationships is fine, and the posters on this thread have done a good job explaining the benefits that come along with federating the responsibility to an external plugin/service, but there are some performance issues that come along with it. However, as long as these inefficiencies are known, I'm satisfied. :) Cheers! jay On Mon, Feb 7, 2011 at 11:37 PM, Paul Voccio paul.voc...@rackspace.com wrote: Woah, seems I missed a lot by not being around email today. I was a bit confused at to why we
[Openstack] Do these commands belong in the API or nova-manage?
Quick question ... For multi-cluster/zones I have a bunch of commands that need to be exposed to administrators: 1. CRUD child zones 2. CRUD hosts to a zone 3. CRUD zone host capabilities to a zone Do you think these belong in the admin-only OpenStack API or only available via nova-manage? Perhaps just the (R)ead operations are available via the API and CUD via nova-manage? Opinions? -Sandy 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] Do these commands belong in the API or nova-manage?
On Tue, Feb 8, 2011 at 5:09 PM, Sandy Walsh sandy.wa...@rackspace.com wrote: Quick question ... For multi-cluster/zones I have a bunch of commands that need to be exposed to administrators: 1. CRUD child zones 2. CRUD hosts to a zone 3. CRUD zone host capabilities to a zone Do you think these belong in the admin-only OpenStack API or only available via nova-manage? Admin-only OpenStack API, since they won't have anything to do with EC2 API, and at this point, nova-manage is very EC2-centric, and adding it to nova-manage could potentially be extremely confusing. Since this functionality is mostly going to be used by service providers, most of which have their own set of custom management tools (see: python-novatools, etc..), I think it's best to stick it only in the admin API for now. My 1.5 cents, -jay Perhaps just the (R)ead operations are available via the API and CUD via nova-manage? Opinions? -Sandy 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 ___ 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] Do these commands belong in the API or nova-manage?
I think you are confusing the EC2 admin API with what Sandy was talking about, which is the OpenStack admin API commands, which has been in Nova for months now. See /nova/api/openstack/__init__.py, lines 74 through 81. -jay On Tue, Feb 8, 2011 at 5:58 PM, Devin Carlen devin.car...@gmail.com wrote: Only place for it to go now is the ec2 admin extension api (nova/api/ec2/admin.py). Until we get the OpenStack API out in the open, we can't add anything to it. The goal is to move the admin functions to the OpenStack API when that becomes an option, but I'm guessing that won't be until diablo. On Feb 8, 2011, at 4:54 PM, Jay Pipes wrote: On Tue, Feb 8, 2011 at 5:09 PM, Sandy Walsh sandy.wa...@rackspace.com wrote: Quick question ... For multi-cluster/zones I have a bunch of commands that need to be exposed to administrators: 1. CRUD child zones 2. CRUD hosts to a zone 3. CRUD zone host capabilities to a zone Do you think these belong in the admin-only OpenStack API or only available via nova-manage? Admin-only OpenStack API, since they won't have anything to do with EC2 API, and at this point, nova-manage is very EC2-centric, and adding it to nova-manage could potentially be extremely confusing. Since this functionality is mostly going to be used by service providers, most of which have their own set of custom management tools (see: python-novatools, etc..), I think it's best to stick it only in the admin API for now. My 1.5 cents, -jay Perhaps just the (R)ead operations are available via the API and CUD via nova-manage? Opinions? -Sandy 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 ___ 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] Do these commands belong in the API or nova-manage?
Yep, you're right. I misread. There is still a longer conversation to be had about admin API in general. All the functions in the ec2 admin api will need to be available in the openstack admin api at some point. On Feb 8, 2011, at 5:01 PM, Jay Pipes wrote: I think you are confusing the EC2 admin API with what Sandy was talking about, which is the OpenStack admin API commands, which has been in Nova for months now. See /nova/api/openstack/__init__.py, lines 74 through 81. -jay On Tue, Feb 8, 2011 at 5:58 PM, Devin Carlen devin.car...@gmail.com wrote: Only place for it to go now is the ec2 admin extension api (nova/api/ec2/admin.py). Until we get the OpenStack API out in the open, we can't add anything to it. The goal is to move the admin functions to the OpenStack API when that becomes an option, but I'm guessing that won't be until diablo. On Feb 8, 2011, at 4:54 PM, Jay Pipes wrote: On Tue, Feb 8, 2011 at 5:09 PM, Sandy Walsh sandy.wa...@rackspace.com wrote: Quick question ... For multi-cluster/zones I have a bunch of commands that need to be exposed to administrators: 1. CRUD child zones 2. CRUD hosts to a zone 3. CRUD zone host capabilities to a zone Do you think these belong in the admin-only OpenStack API or only available via nova-manage? Admin-only OpenStack API, since they won't have anything to do with EC2 API, and at this point, nova-manage is very EC2-centric, and adding it to nova-manage could potentially be extremely confusing. Since this functionality is mostly going to be used by service providers, most of which have their own set of custom management tools (see: python-novatools, etc..), I think it's best to stick it only in the admin API for now. My 1.5 cents, -jay Perhaps just the (R)ead operations are available via the API and CUD via nova-manage? Opinions? -Sandy 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 ___ 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
