[openstack-dev] [Ceilometer] Updated blueprint for Dynamic Meters in Ceilometer
Hi, Updated the blueprint based on the suggestions from the community. Mentioned high level call-flow. Please go through it and let me know your views. https://blueprints.launchpad.net/ceilometer/+spec/dynamic-meters Regards, VijayKumar Kodam ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer] Dynamic Meters in Ceilometer
From: ext Doug Hellmann [mailto:doug.hellm...@dreamhost.com] Sent: Wednesday, January 08, 2014 10:21 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Ceilometer] Dynamic Meters in Ceilometer On Wed, Jan 8, 2014 at 3:09 PM, Kodam, Vijayakumar (EXT-Tata Consultancy Ser - FI/Espoo) vijayakumar.kodam@nsn.commailto:vijayakumar.kodam@nsn.com wrote: From: ext Doug Hellmann [doug.hellm...@dreamhost.commailto:doug.hellm...@dreamhost.com] Sent: Wednesday, January 08, 2014 8:26 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Ceilometer] Dynamic Meters in Ceilometer On Wed, Jan 8, 2014 at 12:35 PM, Ildikó Váncsa ildiko.van...@ericsson.commailto:ildiko.van...@ericsson.com wrote: Hi Doug, Answers inline again. Best Regards, Ildiko On Wed, Jan 8, 2014 at 3:16 AM, Ildikó Váncsa ildiko.van...@ericsson.commailto:ildiko.van...@ericsson.com wrote: Hi, I've started to work on the idea of supporting a kind of tenant/project based configuration for Ceilometer. Unfortunately I haven't reached the point of having a blueprint that could be registered until now. I do not have a deep knowledge about the collector and compute agent services, but this feature would require some deep changes for sure. Currently there are pipelines for data collection and transformation, where the counters can be specified, about which data should be collected and also the time interval for data collection and so on. These pipelines can be configured now globally in the pipeline.yaml file, which is stored right next to the Ceilometer configuration files. Yes, the data collection was designed to be configured and controlled by the deployer, not the tenant. What benefits do we gain by giving that control to the tenant? ildikov: Sorry, my explanation was not clear. I meant there the configuration of data collection for projects, what was mentioned by Tim Bell in a previous email. This would mean that the project administrator is able to create a data collection configuration for his/her own project, which will not affect the other project's configuration. The tenant would be able to specify meters (enabled/disable based on which ones are needed) for the given project also with project specific time intervals, etc. OK, I think some of the confusion is terminology. Who is a project administrator? Is that someone with access to change ceilometer's configuration file directly? Someone with a particular role using the API? Or something else? ildikov: As project administrator I meant a user with particular role, a user assigned to a tenant. OK, so like I said, we did not design the system with the idea that a user of the cloud (rather than the deployer of the cloud) would have any control over what data was collected. They can ask questions about only some of the data, but they can't tell ceilometer what to collect. There's a certain amount of danger in giving the cloud user (no matter their role) an off switch for the data collection. As Julien pointed out, it can have a negative effect on billing -- if they tell the cloud not to collect data about what instances are created, then the deployer can't bill for those instances. Differentiating between the values that always must be collected and the ones the user can control makes providing an API to manage data collection more complex. Is there some underlying use case behind all of this that someone could describe in more detail, so we might be able to find an alternative, or explain how to use the existing features to achieve the goal? For example, it is already possible to change the pipeline config file to control which data is collected and stored. If we make the pipeline code in ceilometer watch for changes to that file, and rebuild the pipelines when the config is updated, would that satisfy the requirements? Yes. That's exactly the requirement for our blueprint. To avoid ceilometer restart for changes to take effect, when the config file changes. API support was added later based on the request in this mail chain. We actually don't need APIs and can be removed. So as you mentioned above, whenever the config file is changed, ceilometer should update the meters accordingly. OK, I think that's something reasonable to implement, although I would have to look at the collector to make sure we could rebuild the pipelines safely without losing any data as more messages come in. But it should be possible, if not easy. :-) The blueprint should be updated to reflect this approach. Doug Thanks Doug. I shall update the blueprint accordingly. VijayKumar In my view, we could keep the dynamic meter configuration bp with considering to extend it to dynamic
Re: [openstack-dev] [Ceilometer] Dynamic Meters in Ceilometer
Hi, -Original Message- From: ext Neal, Phil [mailto:phil.n...@hp.com] Sent: Wednesday, January 08, 2014 12:50 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Ceilometer] Dynamic Meters in Ceilometer For multi-node deployments, implementing something like inotify would allow administrators to push configuration changes out to multiple targets using puppet/chef/etc. and have the daemons pick it up without restart. Thumbs up to that. Thanks! As Tim Bell suggested, API-based enabling/disabling would allow users to update meters via script, but then there's the question of how to work out the global vs. per-project tenant settings...right now we collect specified meters for all available projects, and the API returns whatever data is stored minus filtered values. Maybe I'm missing something in the suggestion, but turning off collection for an individual project seems like it'd require some deep changes. Vijay, I'll repeat dhellmann's request: do you have more detail in another doc? :-) - Phil I concur with the opinion to use APIs for dynamically enabling/disabling meters. I have updated the design accordingly. According to the latest update: User calls the API(1) to disable a meter along with a meter id. Ceilometer-api handles the api request, adds the meter id to disabled_meters config file and informs ceilometer agents. Ceilometer agents will read the disabled_meters config file and disables the meter. More detailed information about this blueprint can be found at https://etherpad.openstack.org/p/dynamic-meters There will be no inotify() or inotifywait() calls to monitor the modifications of the configuration file. Whenever the APIs are called, ceilometer-api upon receiving the request, will modify the config file and informs the ceilometer agents. There are no per-project settings currently considered for this blueprint. IMHO, per-project settings should be implemented for all the meters/resources/APIs in ceilometer and should be handled by a different blueprint. Regards, VijayKumar -Original Message- From: Kodam, Vijayakumar (EXT-Tata Consultancy Ser - FI/Espoo) [mailto:vijayakumar.kodam@nsn.com] Sent: Tuesday, January 07, 2014 2:49 AM To: OpenStack Development Mailing List (not for usage questions) Cc: chmo...@enovance.com Subject: Re: [openstack-dev] [Ceilometer] Dynamic Meters in Ceilometer From: ext Chmouel Boudjnah [mailto:chmo...@enovance.com] Sent: Monday, January 06, 2014 2:19 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Ceilometer] Dynamic Meters in Ceilometer On Mon, Jan 6, 2014 at 12:52 PM, Kodam, Vijayakumar (EXT-Tata Consultancy Ser - FI/Espoo) vijayakumar.kodam@nsn.com wrote: In this case, simply changing the meter properties in a configuration file should be enough. There should be an inotify signal which shall notify ceilometer of the changes in the config file. Then ceilometer should automatically update the meters without restarting. Why it cannot be something configured by the admin with inotifywait(1) command? Or this can be an API call for enabling/disabling meters which could be more useful without having to change the config files. Chmouel. I haven't tried inotifywait() in this implementation. I need to check if it will be useful for the current implementation. Yes. API call could be more useful than changing the config files manually. Thanks, VijayKumar ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer] Dynamic Meters in Ceilometer
From: ext Tim Bell [mailto:tim.b...@cern.ch] Sent: Tuesday, January 07, 2014 8:22 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Ceilometer] Dynamic Meters in Ceilometer Thinking using inotify/configuration file changes to implement dynamic meters, this would be limited to administrators of ceilometer itself (i.e. with write access to the file) rather than the project administrators (as defined by keystone roles). Thus, as a project administrator who is not the cloud admin, I could not enable/disable the meter for a project only. It would mean that scripting meter on/off would not be possible if there was not an API to perform this. Not sure if these requirements are significant and the associated impact on implementation complexity, but they may be relevant in scoping out the blueprint and subsequent changes Tim Tim, Agree with your suggestion. I have updated the design by adding APIs. Whenever an API request is received by the ceilometer-api, it shall modify the config file and inform the ceilometer agents. You can find detailed information at https://etherpad.openstack.org/p/dynamic-meters Regards, VijayKumar From: Doug Hellmann [mailto:doug.hellm...@dreamhost.com] Sent: 06 January 2014 23:35 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Ceilometer] Dynamic Meters in Ceilometer On Tue, Dec 31, 2013 at 4:53 AM, Kodam, Vijayakumar (EXT-Tata Consultancy Ser - FI/Espoo) vijayakumar.kodam@nsn.commailto:vijayakumar.kodam@nsn.com wrote: Hi, Currently there is no way to enable or disable meters without restarting ceilometer. There are cases where operators do not want to run all the meters continuously. In these cases, there should be a way to disable or enable them dynamically. We are working on this feature right now. I have also created a blueprint for the same. https://blueprints.launchpad.net/ceilometer/+spec/dynamic-meters We would love to hear your views on this feature. There isn't much detail in the blueprint. Do you have a more comprehensive document you can link to that talks about how you intend for it to work? Doug Regards, VijayKumar Kodam ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer] Dynamic Meters in Ceilometer
. For example the log settings could be a good candidate, as for example the change of log levels, without service restart, in case debugging the system can be a useful feature for all of the OpenStack services. I misspoke earlier. If we're talking about meters, those are actually defined by the pipeline file (not oslo.config). So if we do want that file re-read automatically, we can implement that within ceilometer itself, though I'm still reluctant to say we want to provide API access for modifying those settings. That's *really* not something we've designed the rest of the system to accommodate, so I don't know what side-effects we might introduce. ildikov: In case of oslo.config, I meant the ceilometer.conf file in my answer above, not pipeline.yaml. As for the API part, I do not know the consequences of that implementation either, so now I’m kind of waiting for the outcome of this Dynamic Meters bp. As far as the other configuration settings, we had the conversation about updating those through some sort of API early on, and decided that there are already lots of operational tools out there to manage changes to those files. I would need to see a list of which options people would want to have changed through an API to comment further. ildikov: Yes, I agree that not all the parameters should be configured dynamically. It just popped into my mind regarding the dynamic configuration, that there would be a need to configure other configuration parameters, not just meters, that is why I mentioned it as a considerable item. If it is ok for you, I will register the bp for this per-project tenant settings with some details, when I'm finished with the initial design of how this feature could work. Best Regards, Ildiko -Original Message- From: Neal, Phil [mailto:phil.n...@hp.com] Sent: Tuesday, January 07, 2014 11:50 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Ceilometer] Dynamic Meters in Ceilometer For multi-node deployments, implementing something like inotify would allow administrators to push configuration changes out to multiple targets using puppet/chef/etc. and have the daemons pick it up without restart. Thumbs up to that. As Tim Bell suggested, API-based enabling/disabling would allow users to update meters via script, but then there's the question of how to work out the global vs. per-project tenant settings...right now we collect specified meters for all available projects, and the API returns whatever data is stored minus filtered values. Maybe I'm missing something in the suggestion, but turning off collection for an individual project seems like it'd require some deep changes. Vijay, I'll repeat dhellmann's request: do you have more detail in another doc? :-) - Phil On Mon, Jan 6, 2014 at 12:52 PM, Kodam, Vijayakumar (EXT-Tata Consultancy Ser - FI/Espoo) vijayakumar.kodam@nsn.commailto:vijayakumar.kodam@nsn.com wrote: In this case, simply changing the meter properties in a configuration file should be enough. There should be an inotify signal which shall notify ceilometer of the changes in the config file. Then ceilometer should automatically update the meters without restarting. Why it cannot be something configured by the admin with inotifywait(1) command? Or this can be an API call for enabling/disabling meters which could be more useful without having to change the config files. Chmouel. I haven't tried inotifywait() in this implementation. I need to check if it will be useful for the current implementation. Yes. API call could be more useful than changing the config files manually. Thanks, VijayKumar ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer] Dynamic Meters in Ceilometer
From: ext Chmouel Boudjnah [mailto:chmo...@enovance.com] Sent: Monday, January 06, 2014 2:19 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Ceilometer] Dynamic Meters in Ceilometer On Mon, Jan 6, 2014 at 12:52 PM, Kodam, Vijayakumar (EXT-Tata Consultancy Ser - FI/Espoo) vijayakumar.kodam@nsn.commailto:vijayakumar.kodam@nsn.com wrote: In this case, simply changing the meter properties in a configuration file should be enough. There should be an inotify signal which shall notify ceilometer of the changes in the config file. Then ceilometer should automatically update the meters without restarting. Why it cannot be something configured by the admin with inotifywait(1) command? Or this can be an API call for enabling/disabling meters which could be more useful without having to change the config files. Chmouel. I haven't tried inotifywait() in this implementation. I need to check if it will be useful for the current implementation. Yes. API call could be more useful than changing the config files manually. Thanks, VijayKumar ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer] Dynamic Meters in Ceilometer
-Original Message- From: ext Julien Danjou [mailto:jul...@danjou.info] Subject: Re: [openstack-dev] [Ceilometer] Dynamic Meters in Ceilometer On Tue, Dec 31 2013, Kodam, Vijayakumar (EXT-Tata Consultancy Ser - FI/Espoo) wrote: Hi, Currently there is no way to enable or disable meters without restarting ceilometer. There are cases where operators do not want to run all the meters continuously. In these cases, there should be a way to disable or enable them dynamically. We are working on this feature right now. I have also created a blueprint for the same. https://blueprints.launchpad.net/ceilometer/+spec/dynamic-meters We would love to hear your views on this feature. This looks like a good idea, but it was my understanding that it was pretty much already doable by modifying the configuration file and reloading the daemons. What else would you have in mind? Changes to the meters or configuration files should reflect immediately without restarting daemons. One scenario where this feature could be useful is, when Ceilometer is processing several hundreds of meters and operator decides to disable some specific meters without affecting other meters. In this case, simply changing the meter properties in a configuration file should be enough. There should be an inotify signal which shall notify ceilometer of the changes in the config file. Then ceilometer should automatically update the meters without restarting. That is the main idea of this blueprint. 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
-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] Custom Flavor creation through Heat
not the video I was looking for, but he kind of makes the point about planning... http://youtu.be/2E0C9zLSINE?t=42m55s # Shawn Hartsock Thanks Shawn for your inputs. As I have mentioned earlier, the usecase is mostly for telecom cloud applications running in our private cloud. The hardware requirements for them are quite different from the usual IT hardware requirements. We also have to use extra-specs to help nova schedule the virtual instances and to make other decisions. And the flavors we create will be mostly visible/accessible to the tenant which creates them. This restriction could be imposed using flavor-access feature of nova. Regards, VijayKumar - Original Message - From: Shawn Hartsock hartso...@vmware.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Tuesday, November 12, 2013 6:38:21 PM Subject: Re: [openstack-dev] Custom Flavor creation through Heat - Original Message - From: Yunhong Jiang yunhong.ji...@intel.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Tuesday, November 12, 2013 5:39:58 PM Subject: Re: [openstack-dev] Custom Flavor creation through Heat -Original Message- From: Shawn Hartsock [mailto:hartso...@vmware.com] Sent: Tuesday, November 12, 2013 12:56 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova] [heat] Custom Flavor creation through Heat My concern with proliferating custom flavors is that it might play havoc with the underlying root-case for flavors. My understanding of flavors is that they are used to solve the resource packing problem in elastic cloud scenarios. That way you know that 256 tiny VMs fit cleanly into your hardware layout and so do 128 medium VMs and 64 large VMs. If you allow flavor of the week then the packing problem re-asserts itself and scheduling becomes harder. I'm a bit surprised that the flavor is used to resolve the packing problem. I thought it should be handled by scheduler, although it's a NP problem. I should have said flavors help to make the packing problem simpler for the scheduler ... flavors do not solve the packing problem. As for custom flavor, I think at least it's against current nova assumption. Currently nova assume flavor should only be created by admin, who knows the cloud quite well. One example is, flavor may contain extra-spec, so if an extra-spec value is specified in the flavor, while the corresponding scheduler filter is not enabled, then the extra-spec has no effect and may cause issue. Beyond merely extra-specs my understanding was that because you *have* flavors you can make assumptions about packing that make the problem space smaller... someone made a nice presentation showing how having restricted flavors made scheduling easier. I can't find it right now. It was presented at an OpenStack summit IIRC. ___ 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
