Re: [openstack-dev] [nova] [heat] Custom Flavor creation through Heat
-Original Message- From: ext Steven Hardy [mailto:sha...@redhat.com] Sent: Thursday, November 14, 2013 2:33 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova] [heat] Custom Flavor creation through Heat On Thu, Nov 14, 2013 at 08:22:57AM +, Kodam, Vijayakumar (EXT-Tata Consultancy Ser - FI/Espoo) wrote: snip Thanks Steve Baker for the information. I am also waiting to hear from Steve Hardy, if keystone trust system will fix the nova flavors admin privileges issue. So, basically, no. Trusts only allow you to delegate roles you already have, so if nova requires admin to create a flavor, and the user creating the heat stack doesn't have admin, then they can't create a flavor. Trusts won't solve this problem, they won't allow users to gain roles they don't already have. As Clint has pointed out, if you control the OpenStack deployment, you are free to modify the policy for any API to suit your requirements - the policy provided by projects is hopefully a sane set of defaults, but the whole point of policy.json is that it's configurable. One option to control the proliferation of nova flavors is to make them private to the tenant (using flavor-access?) who created them. This provides the needed privacy so that others tenants cannot view them. This is the first step IMO - the nova flavors aren't scoped per tenant atm, which will be a big problem if you start creating loads of non-public flavors via stack templates. At the moment, you can specify --is-public false when creating a flavor, but this doesn't really mean that the flavor is private to the user, or tenant, it just means non-admin users can't see it AFAICT. So right now, if User1 in Tenant1 does: nova flavor-create User1Flavor auto 128 10 1 --is-public false Every user in every tenant will see it via tenant-list --all, if they have the admin role. This lack of proper role-based request scoping is an issue throughout OpenStack AFAICS, Heat included (I'm working on fixing it). Probably what we need is something like: - Normal user : Can create a private flavor in a tenant where they have the Member role (invisible to any other users) - Tenant Admin user : Can create public flavors in the tenants where they have the admin role (visible to all users in the tenant) - Domain admin user : Can create public flavors in the domains where they have the admin role (visible to all users in all tenants in that domain) Note the current admin user scope is like the last case, only for the default domain. So for now, I'm -1 on adding a heat resource to create flavors, we should fix the flavor scoping in Nova first IMO. Steve ___ Can we expect role-based request scoping for heat in icehouse-1 or near future? VijayKumar ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] [heat] Custom Flavor creation through Heat
-Original Message- From: Clint Byrum [mailto:cl...@fewbar.com] Sent: Tuesday, November 12, 2013 9:24 PM To: openstack-dev Subject: Re: [openstack-dev] [nova] [heat] Custom Flavor creation through Heat Excerpts from Kodam, Vijayakumar (EXT-Tata Consultancy Ser - FI/Espoo)'s message of 2013-11-12 09:25:19 -0800: Hi, In Telecom Cloud applications, the requirements for every application are different. One application might need 10 CPUs, 10GB RAM and no disk. Another application might need 1 CPU, 512MB RAM and 100GB Disk. This varied requirements directly affects the flavors which need to be created for different applications (virtual instances). Customer has his own custom requirements for CPU, RAM and other hardware requirements. So, based on the requests from the customers, we believe that the flavor creation should be done along with the instance creation, just before the instance is created. Most of flavors will be specific to that application and therefore will not be suitable by other instances. The obvious way is to allow users to create flavors and boot customized instances through Heat. As of now, users can launch instances through heat along with predefined nova flavors only. We have made some changes in our setup and tested it. This change allows creation of customized nova flavors using heat templates. We are also using extra-specs in the flavors for use in our private cloud deployment. This gives an option to the user to mention custom requirements for the flavor in the heat template directly along with the instance details. There is one problem in the nova flavor creation using heat templates. Admin privileges are required to create nova flavors. There should be a way to allow a normal user to create flavors. Your comments and suggestions are most welcome on how to handle this problem !!! Seems like you just need to setup your Nova policy to allow a role to do flavor creation: compute_extension:flavormanage: rule:admin_api, compute_extension:v3:flavor-manage: rule:admin_api, And then enhance Heat to make those API calls. There must be some valid reason for adding those checks in the Nova Policy. I would like to understand the implications before making any changes. Regards, VijayKumar ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] [heat] Custom Flavor creation through Heat
From: Steve Baker [mailto:sba...@redhat.com] Sent: Tuesday, November 12, 2013 9:25 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [nova] [heat] Custom Flavor creation through Heat On 11/13/2013 07:50 AM, Steven Dake wrote: On 11/12/2013 10:25 AM, Kodam, Vijayakumar (EXT-Tata Consultancy Ser - FI/Espoo) wrote: Hi, In Telecom Cloud applications, the requirements for every application are different. One application might need 10 CPUs, 10GB RAM and no disk. Another application might need 1 CPU, 512MB RAM and 100GB Disk. This varied requirements directly affects the flavors which need to be created for different applications (virtual instances). Customer has his own custom requirements for CPU, RAM and other hardware requirements. So, based on the requests from the customers, we believe that the flavor creation should be done along with the instance creation, just before the instance is created. Most of the flavors will be specific to that application and therefore will not be suitable by other instances. The obvious way is to allow users to create flavors and boot customized instances through Heat. As of now, users can launch instances through heat along with predefined nova flavors only. We have made some changes in our setup and tested it. This change allows creation of customized nova flavors using heat templates. We are also using extra-specs in the flavors for use in our private cloud deployment. This gives an option to the user to mention custom requirements for the flavor in the heat template directly along with the instance details. There is one problem in the nova flavor creation using heat templates. Admin privileges are required to create nova flavors. There should be a way to allow a normal user to create flavors. Your comments and suggestions are most welcome on how to handle this problem !!! Regards, Vijaykumar Kodam Vjaykumar, I have long believed that an OS::Nova::Flavor resource would make a good addition to Heat, but as you pointed out, this type of resource requires administrative priveleges. I generally also believe it is bad policy to implement resources that *require* admin privs to operate, because that results in yet more resources that require admin. We are currently solving the IAM user cases (keystone doesn't allow the creation of users without admin privs). It makes sense that cloud deployers would want to control who could create flavors to avoid DOS attacks against their inrastructure or prevent trusted users from creating a wacky flavor that the physical infrastructure can't support. I'm unclear if nova offers a way to reduce permissions required for flavor creation. One option that may be possible is via the keystone trusts mechanism. Steve Hardy did most of the work integrating Heat with the new keystone trusts system - perhaps he has some input. I would be happy for you to submit your OS::Nova::Flavor resource to heat. There are a couple of nova-specific issues that will need to be addressed: * Is there optimization in nova required to handle the proliferation of flavors? Nova may currently make the assumption that the flavor list is short and static. * How to provide an authorization policy that allows non-admins to create flavors. Maybe something role-based? Thanks Steve Baker for the information. I am also waiting to hear from Steve Hardy, if keystone trust system will fix the nova flavors admin privileges issue. One option to control the proliferation of nova flavors is to make them private to the tenant (using flavor-access?) who created them. This provides the needed privacy so that others tenants cannot view them. Regards, VijayKumar ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] [heat] Custom Flavor creation through Heat
On Thu, Nov 14, 2013 at 08:22:57AM +, Kodam, Vijayakumar (EXT-Tata Consultancy Ser - FI/Espoo) wrote: snip Thanks Steve Baker for the information. I am also waiting to hear from Steve Hardy, if keystone trust system will fix the nova flavors admin privileges issue. So, basically, no. Trusts only allow you to delegate roles you already have, so if nova requires admin to create a flavor, and the user creating the heat stack doesn't have admin, then they can't create a flavor. Trusts won't solve this problem, they won't allow users to gain roles they don't already have. As Clint has pointed out, if you control the OpenStack deployment, you are free to modify the policy for any API to suit your requirements - the policy provided by projects is hopefully a sane set of defaults, but the whole point of policy.json is that it's configurable. One option to control the proliferation of nova flavors is to make them private to the tenant (using flavor-access?) who created them. This provides the needed privacy so that others tenants cannot view them. This is the first step IMO - the nova flavors aren't scoped per tenant atm, which will be a big problem if you start creating loads of non-public flavors via stack templates. At the moment, you can specify --is-public false when creating a flavor, but this doesn't really mean that the flavor is private to the user, or tenant, it just means non-admin users can't see it AFAICT. So right now, if User1 in Tenant1 does: nova flavor-create User1Flavor auto 128 10 1 --is-public false Every user in every tenant will see it via tenant-list --all, if they have the admin role. This lack of proper role-based request scoping is an issue throughout OpenStack AFAICS, Heat included (I'm working on fixing it). Probably what we need is something like: - Normal user : Can create a private flavor in a tenant where they have the Member role (invisible to any other users) - Tenant Admin user : Can create public flavors in the tenants where they have the admin role (visible to all users in the tenant) - Domain admin user : Can create public flavors in the domains where they have the admin role (visible to all users in all tenants in that domain) Note the current admin user scope is like the last case, only for the default domain. So for now, I'm -1 on adding a heat resource to create flavors, we should fix the flavor scoping in Nova first IMO. Steve ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] [heat] Custom Flavor creation through Heat
Hi, In Telecom Cloud applications, the requirements for every application are different. One application might need 10 CPUs, 10GB RAM and no disk. Another application might need 1 CPU, 512MB RAM and 100GB Disk. This varied requirements directly affects the flavors which need to be created for different applications (virtual instances). Customer has his own custom requirements for CPU, RAM and other hardware requirements. So, based on the requests from the customers, we believe that the flavor creation should be done along with the instance creation, just before the instance is created. Most of the flavors will be specific to that application and therefore will not be suitable by other instances. The obvious way is to allow users to create flavors and boot customized instances through Heat. As of now, users can launch instances through heat along with predefined nova flavors only. We have made some changes in our setup and tested it. This change allows creation of customized nova flavors using heat templates. We are also using extra-specs in the flavors for use in our private cloud deployment. This gives an option to the user to mention custom requirements for the flavor in the heat template directly along with the instance details. There is one problem in the nova flavor creation using heat templates. Admin privileges are required to create nova flavors. There should be a way to allow a normal user to create flavors. Your comments and suggestions are most welcome on how to handle this problem !!! Regards, Vijaykumar Kodam ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
