Re: [openstack-dev] Climate Incubation Application
Russell, first of all thanks for your opinion and taking part in this discussion. What we need to dig in to is *why* do you feel it needs to be global? I'm trying to understand what you're saying here ... do you mean that since we're trying to get to where there's a global scheduler, that it makes sense there should be a central point for this, even if the API is through the existing compute/networking/storage APIs? If so, I think that makes sense. However, until we actually have something for scheduling, I think we should look at implementing all of this in the services, and perhaps share some code with a Python library. Well, let me give you some reasons I'm thinking about speaking about separated service with its own endpoints, etc. * as you said, we propose different resources reservations to be implemented for OS, and compute resources (VMs and hosts) are not only ones for that; * there should be support of time management, checking leases statuses, sending user notifications, etc. - even if that'll be implemented as library, it'll need separately running service in Nova, because there will be some specific periodic tasks and so on. Of course, that might be part of nova-scheduler, but in this case such things as sending notifications will look strange here - and that will allow to manage only VMs, not hosts, at least if we are speaking about traditional Nova scheduling process; * and the last: previous points might be implemented as some library, and work ok, I quite agree with you here. Although in this case there will be no centralised point of leases management, as there is no one point for quotas management now. And if for quotas that's uncomfortable to manage them in case of huge clouds, for leases it will be simply impossible to have one picture of what will be going with all resources in future - as there are many things to keep track on - compute capacity, storage capacity, etc. The last point seems most important for me, as the idea of centralised resource time management looks better for me than idea of each service having simply the same code working on its own reservation, plus the fact we consider that some scheduling dependencies could happen with heterogenous resources like reserving a volume with an instance booting on it. I quite agree that for user it'll be more comfortable to use services as is, and as Sylvain said, that might implemented quite nice due to, for example, Nova extensions (as it's done now for VM reservations). But at the same moment all logic related to leases will be in one place, allowing cloud administrators manage cloud capacity usage in time from one place. And I'm not talking about additional load to core reviewers of all projects in case of implementing that feature in every single project, although there is already existing team on Climate. That's not the main thing. As said that's my personal opinion, and I'll be really glad to discuss this problem and solve it in the best way chosen by community with taking into account different points of view and ideas. Thanks On Thu, Mar 13, 2014 at 6:44 PM, Russell Bryant rbry...@redhat.com wrote: On 03/12/2014 12:14 PM, Sylvain Bauza wrote: Hi Russell, Thanks for replying, 2014-03-12 16:46 GMT+01:00 Russell Bryant rbry...@redhat.com mailto:rbry...@redhat.com: The biggest concern seemed to be that we weren't sure whether Climate makes sense as an independent project or not. We think it may make more sense to integrate what Climate does today into Nova directly. More generally, we think reservations of resources may best belong in the APIs responsible for managing those resources, similar to how quota management for resources lives in the resource APIs. There is some expectation that this type of functionality will extend beyond Nova, but for that we could look at creating a shared library of code to ease implementing this sort of thing in each API that needs it. That's really a good question, so maybe I could give some feedback on how we deal with the existing use-cases. About the possible integration with Nova, that's already something we did for the virtual instances use-case, thanks to an API extension responsible for checking if a scheduler hint called 'reservation' was spent, and if so, take use of the python-climateclient package to send a request to Climate. I truly agree with the fact that possibly users should not use a separate API for reserving resources, but that would be worth duty for the project itself (Nova, Cinder or even Heat). That said, we think that there is need for having a global ordonancer managing resources and not siloing the resources. Hence that's why we still think there is still a need for a Climate Manager. What we need to dig in to is *why* do you feel it needs to be global? I'm trying to understand what you're saying here ... do you mean that since we're
Re: [openstack-dev] Climate Incubation Application
On 03/12/2014 12:14 PM, Sylvain Bauza wrote: Hi Russell, Thanks for replying, 2014-03-12 16:46 GMT+01:00 Russell Bryant rbry...@redhat.com mailto:rbry...@redhat.com: The biggest concern seemed to be that we weren't sure whether Climate makes sense as an independent project or not. We think it may make more sense to integrate what Climate does today into Nova directly. More generally, we think reservations of resources may best belong in the APIs responsible for managing those resources, similar to how quota management for resources lives in the resource APIs. There is some expectation that this type of functionality will extend beyond Nova, but for that we could look at creating a shared library of code to ease implementing this sort of thing in each API that needs it. That's really a good question, so maybe I could give some feedback on how we deal with the existing use-cases. About the possible integration with Nova, that's already something we did for the virtual instances use-case, thanks to an API extension responsible for checking if a scheduler hint called 'reservation' was spent, and if so, take use of the python-climateclient package to send a request to Climate. I truly agree with the fact that possibly users should not use a separate API for reserving resources, but that would be worth duty for the project itself (Nova, Cinder or even Heat). That said, we think that there is need for having a global ordonancer managing resources and not siloing the resources. Hence that's why we still think there is still a need for a Climate Manager. What we need to dig in to is *why* do you feel it needs to be global? I'm trying to understand what you're saying here ... do you mean that since we're trying to get to where there's a global scheduler, that it makes sense there should be a central point for this, even if the API is through the existing compute/networking/storage APIs? If so, I think that makes sense. However, until we actually have something for scheduling, I think we should look at implementing all of this in the services, and perhaps share some code with a Python library. So, I'm thinking along the lines of ... 1) Take what Climate does today and work to integrate it into Nova, using as much of the existing Climate code as makes sense. Be careful about coupling in Nova so that we can easily split out the right code into a library once we're ready to work on integration in another project. 2) In parallel, continue working on decoupling nova-scheduler from the rest of Nova, so that we can split it out into its own project. 3) Once the scheduler is split out, re-visit what part of reservations functionality belongs in the new scheduling project and what parts should remain in each of the projects responsible for managing resources. Once I said that, there are different ways to plug in with the Manager, our proposal is to deliver a REST API and a python client so that there could be still some operator access for managing the resources if needed. The other way would be to only expose an RPC interface like the scheduler does at the moment but as the move to Pecan/WSME is already close to be done (reviews currently in progress), that's still a good opportunity for leveraging the existing bits of code. Yes, I would want to use as much of the existing code as possible. As I said above, I just think it's premature to make this its own project on its own, unless we're able to look at scheduling more broadly as its own project. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Climate Incubation Application
Thanks TC for spending time on Blazar (ex. Climate, in process of renaming) discussion! It was decided that potentially reservation idea is interesting for OS and it'll be great to have cross-project session on ongoing Atlanta Summit and discuss future of reservation/scheduling management in OpenStack. Here is link to cross-project session proposal: http://summit.openstack.org/cfp/details/45 Thanks everyone and let's keep working on that idea. Dina On Fri, Mar 7, 2014 at 12:56 PM, Thierry Carrez thie...@openstack.orgwrote: Dina Belova wrote: I'd like to request Climate project review for incubation. Here is official incubation application: https://wiki.openstack.org/wiki/Climate/Incubation After watching this thread a bit, it looks like this is more a preemptive where fo I fit advice request than a formal incubation request. These are interesting questions, and useful answers to projects. We (the TC) may need an avenue for projects to request such feedback without necessarily engaging in a formal incubation request... -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Climate Incubation Application
On 03/12/2014 07:35 AM, Dina Belova wrote: Thanks TC for spending time on Blazar (ex. Climate, in process of renaming) discussion! It was decided that potentially reservation idea is interesting for OS and it'll be great to have cross-project session on ongoing Atlanta Summit and discuss future of reservation/scheduling management in OpenStack. Here is link to cross-project session proposal: http://summit.openstack.org/cfp/details/45 Thanks everyone and let's keep working on that idea. Yes, I do think it would be useful to discuss this in person. However, I don't think that was the most important feedback from the TC meeting. The biggest concern seemed to be that we weren't sure whether Climate makes sense as an independent project or not. We think it may make more sense to integrate what Climate does today into Nova directly. More generally, we think reservations of resources may best belong in the APIs responsible for managing those resources, similar to how quota management for resources lives in the resource APIs. There is some expectation that this type of functionality will extend beyond Nova, but for that we could look at creating a shared library of code to ease implementing this sort of thing in each API that needs it. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Climate Incubation Application
Hi Russell, Thanks for replying, 2014-03-12 16:46 GMT+01:00 Russell Bryant rbry...@redhat.com: On 03/12/2014 07:35 AM, Dina Belova wrote: Thanks TC for spending time on Blazar (ex. Climate, in process of renaming) discussion! It was decided that potentially reservation idea is interesting for OS and it'll be great to have cross-project session on ongoing Atlanta Summit and discuss future of reservation/scheduling management in OpenStack. Here is link to cross-project session proposal: http://summit.openstack.org/cfp/details/45 Thanks everyone and let's keep working on that idea. Yes, I do think it would be useful to discuss this in person. However, I don't think that was the most important feedback from the TC meeting. The biggest concern seemed to be that we weren't sure whether Climate makes sense as an independent project or not. We think it may make more sense to integrate what Climate does today into Nova directly. More generally, we think reservations of resources may best belong in the APIs responsible for managing those resources, similar to how quota management for resources lives in the resource APIs. There is some expectation that this type of functionality will extend beyond Nova, but for that we could look at creating a shared library of code to ease implementing this sort of thing in each API that needs it. That's really a good question, so maybe I could give some feedback on how we deal with the existing use-cases. About the possible integration with Nova, that's already something we did for the virtual instances use-case, thanks to an API extension responsible for checking if a scheduler hint called 'reservation' was spent, and if so, take use of the python-climateclient package to send a request to Climate. I truly agree with the fact that possibly users should not use a separate API for reserving resources, but that would be worth duty for the project itself (Nova, Cinder or even Heat). That said, we think that there is need for having a global ordonancer managing resources and not siloing the resources. Hence that's why we still think there is still a need for a Climate Manager. Once I said that, there are different ways to plug in with the Manager, our proposal is to deliver a REST API and a python client so that there could be still some operator access for managing the resources if needed. The other way would be to only expose an RPC interface like the scheduler does at the moment but as the move to Pecan/WSME is already close to be done (reviews currently in progress), that's still a good opportunity for leveraging the existing bits of code. -Sylvain ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Climate Incubation Application
Dina Belova wrote: I'd like to request Climate project review for incubation. Here is official incubation application: https://wiki.openstack.org/wiki/Climate/Incubation After watching this thread a bit, it looks like this is more a preemptive where fo I fit advice request than a formal incubation request. These are interesting questions, and useful answers to projects. We (the TC) may need an avenue for projects to request such feedback without necessarily engaging in a formal incubation request... -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Climate Incubation Application
Thierry, hello. Anne Gentle wrote: It feels like it should be part of a scheduler or reservation program but we don't have one today. We also don't have a workflow, planning, or capacity management program, all of which these use cases could fall under. (I should know this but) What are the options when a program doesn't exist already? Am I actually struggling with a scope expansion beyond infrastructure definitions? I'd like some more discussion by next week's TC meeting. When a project files for incubation and covers a new scope, they also file for a new program to go with it. Yes, we've prepared 'Resource Reservation' program - but it seems to me, that now we should reexamine it due to idea of common program for Gantt and Climate, and, probably, Mistral (as Anne said We also don't have a workflow, planning, or capacity management program, all of which these use cases could fall under. ) Dina Belova wrote: I think your idea is really interesting. I mean, that thought Gantt - where to schedule, Climate - when to schedule is quite understandable and good looking. Would Climate also be usable to support functionality like Spot Instances ? Schedule when spot price falls under X ? Really good question. Personally I think that Climate might help implementing this feature, but probably it's not the main thing that will work there. Here are my concerns about it. Spot instances require way of counting instance price: * that might be done by *online* counting of free capacity. If so, that's something that might be managed by billing service - price counting due to current load. In this case I can imagine hardly how lease service might help - that will be only some approximate capacity planning help in future * there is other way - if every instance in cloud will be reserved via Climate (so there will be full planning). If so, Climate will know for sure what and when will be running. And price will be some priority stuff there - due to it not started leases will be rescheduled. Like if capacity load in moment X is Y and user gives price Z for some VM and it's more than minimal price counted for that X moment, his VM will be leased for X. If not, place for VM will be found later. It were some quick thoughts about this idea, I'm pretty sure there might be some other variants about it. Thanks Dina On Wed, Mar 5, 2014 at 7:35 PM, Thierry Carrez thie...@openstack.orgwrote: Dina Belova wrote: I think your idea is really interesting. I mean, that thought Gantt - where to schedule, Climate - when to schedule is quite understandable and good looking. Would Climate also be usable to support functionality like Spot Instances ? Schedule when spot price falls under X ? -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Climate Incubation Application
Dina Belova wrote: Would Climate also be usable to support functionality like Spot Instances ? Schedule when spot price falls under X ? Really good question. Personally I think that Climate might help implementing this feature, but probably it’s not the main thing that will work there. Here are my concerns about it. Spot instances require way of counting instance price: [...] Not necessarily. It's a question of whether Climate would handle only schedule at (a given date), or more generally schedule when (a certain event happens, with date just being one event type). You can depend on some external system setting spot prices, or any other information, and climate rules that would watch regularly that external information to decide if it's time to run resources or not. I don't think it should be Climate's responsibility to specifically maintain spot price, everyone can come up with their own rules. -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Climate Incubation Application
Hi Thierry, 2014-03-06 11:46 GMT+01:00 Thierry Carrez thie...@openstack.org: Dina Belova wrote: Would Climate also be usable to support functionality like Spot Instances ? Schedule when spot price falls under X ? Really good question. Personally I think that Climate might help implementing this feature, but probably it's not the main thing that will work there. Here are my concerns about it. Spot instances require way of counting instance price: [...] Not necessarily. It's a question of whether Climate would handle only schedule at (a given date), or more generally schedule when (a certain event happens, with date just being one event type). You can depend on some external system setting spot prices, or any other information, and climate rules that would watch regularly that external information to decide if it's time to run resources or not. I don't think it should be Climate's responsibility to specifically maintain spot price, everyone can come up with their own rules. I can't agree more on this. The goal of Climate is to provide some formal contract agreement in betwen an user and the Reservation service, for ensuring that the order will be placed and served correctly (with regards to quotas and capacity). Of course, what we call 'user' doesn't formally tend to be a 'real' user. About spot instances use-case, I don't pretend to design it, but I could easily imagine that a call to Nova for booting an instance would place an order to Climate with a specific type of contract (what we began to call 'best-effort' and which needs to be implemented yet) where notifications for acquitting the order would come from Ceilometer (for instance). If no notifications come to Climate, the lease would not be honored. See https://wiki.openstack.org/wiki/Climate#Lease_types_.28concepts.29 for best-effort definition of a lease. -Sylvain ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Climate Incubation Application
Sylvain, I love your idea. As you said, that should be designed, but for the first sight your proposal looks quite nice. On Thu, Mar 6, 2014 at 3:11 PM, Sylvain Bauza sylvain.ba...@gmail.comwrote: Hi Thierry, 2014-03-06 11:46 GMT+01:00 Thierry Carrez thie...@openstack.org: Dina Belova wrote: Would Climate also be usable to support functionality like Spot Instances ? Schedule when spot price falls under X ? Really good question. Personally I think that Climate might help implementing this feature, but probably it's not the main thing that will work there. Here are my concerns about it. Spot instances require way of counting instance price: [...] Not necessarily. It's a question of whether Climate would handle only schedule at (a given date), or more generally schedule when (a certain event happens, with date just being one event type). You can depend on some external system setting spot prices, or any other information, and climate rules that would watch regularly that external information to decide if it's time to run resources or not. I don't think it should be Climate's responsibility to specifically maintain spot price, everyone can come up with their own rules. I can't agree more on this. The goal of Climate is to provide some formal contract agreement in betwen an user and the Reservation service, for ensuring that the order will be placed and served correctly (with regards to quotas and capacity). Of course, what we call 'user' doesn't formally tend to be a 'real' user. About spot instances use-case, I don't pretend to design it, but I could easily imagine that a call to Nova for booting an instance would place an order to Climate with a specific type of contract (what we began to call 'best-effort' and which needs to be implemented yet) where notifications for acquitting the order would come from Ceilometer (for instance). If no notifications come to Climate, the lease would not be honored. See https://wiki.openstack.org/wiki/Climate#Lease_types_.28concepts.29 for best-effort definition of a lease. -Sylvain ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Climate Incubation Application
On Thu, Mar 6, 2014 at 3:11 AM, Sylvain Bauza sylvain.ba...@gmail.com wrote: Hi Thierry, 2014-03-06 11:46 GMT+01:00 Thierry Carrez thie...@openstack.org: Dina Belova wrote: Would Climate also be usable to support functionality like Spot Instances ? Schedule when spot price falls under X ? Really good question. Personally I think that Climate might help implementing this feature, but probably it's not the main thing that will work there. Here are my concerns about it. Spot instances require way of counting instance price: [...] Not necessarily. It's a question of whether Climate would handle only schedule at (a given date), or more generally schedule when (a certain event happens, with date just being one event type). You can depend on some external system setting spot prices, or any other information, and climate rules that would watch regularly that external information to decide if it's time to run resources or not. I don't think it should be Climate's responsibility to specifically maintain spot price, everyone can come up with their own rules. I can't agree more on this. The goal of Climate is to provide some formal contract agreement in betwen an user and the Reservation service, for ensuring that the order will be placed and served correctly (with regards to quotas and capacity). Of course, what we call 'user' doesn't formally tend to be a 'real' user. About spot instances use-case, I don't pretend to design it, but I could easily imagine that a call to Nova for booting an instance would place an order to Climate with a specific type of contract (what we began to call 'best-effort' and which needs to be implemented yet) where notifications for acquitting the order would come from Ceilometer (for instance). If no notifications come to Climate, the lease would not be honored. See https://wiki.openstack.org/wiki/Climate#Lease_types_.28concepts.29 for best-effort definition of a lease. Immediate reservation. Resources are provisioned immediately (like VM boot or moving host to reserved user aggregate) or not at all. If request can be fulfilled, lease is created and success status is returned. Lease should be marked as active or to_be_started. Otherwise (if request resource cannot be provisioned right now) failure status for this request should be returned. Isn't this what what nova does today? why is climate needed for this? Also your concept of 'Best-effort reservation.' is very different from spot instances. Spot instances will terminate terminate when the price goes above a threshhold, I didn't see anything like that here. -Sylvain ___ OpenStack-dev mailing list 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] Climate Incubation Application
Dina Belova wrote: I think your idea is really interesting. I mean, that thought “Gantt - where to schedule, Climate - when to schedule” is quite understandable and good looking. Would Climate also be usable to support functionality like Spot Instances ? Schedule when spot price falls under X ? -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Climate Incubation Application
Anne Gentle wrote: It feels like it should be part of a scheduler or reservation program but we don't have one today. We also don't have a workflow, planning, or capacity management program, all of which these use cases could fall under. (I should know this but) What are the options when a program doesn't exist already? Am I actually struggling with a scope expansion beyond infrastructure definitions? I'd like some more discussion by next week's TC meeting. When a project files for incubation and covers a new scope, they also file for a new program to go with it. https://wiki.openstack.org/wiki/Governance/NewProjects -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Climate Incubation Application
Joe, thanks for discussion. I think nova should natively support booting an instance for a limited amount of time. I would use this all the time to boot up devstack instances (boot devstack instance for 5 hours) Really nice idea, but to provide time based resource management for any resource type in OS (instance, volume, compute host, Heat stack, etc.) that needs to be implemented in every project. And even with that feature implemented, without central leasing service, there should be some other reservation connected opportunities like user notifications about close end of lease / energy efficiency, etc. that do not really fit idea of some already existing project / program. Reserved and Spot Instances. I like Amazon's concept of reserved and spot instances it would be cool if we could support something similar AWS reserved instances look like your first idea with instances booted for a limited amount of time - even that in Amazon use case that's *much* time. As for spot instances, I believe this idea is more about some billing service that counts current instance/host/whatever price due to current compute capacity load, etc. Boot an instances for 4 hours every morning. This sounds like something that https://wiki.openstack.org/wiki/Mistral#Tasks_Scheduling_-_Cloud_Cron can handle. That's not really thing we've implemented in Climate - we have not implemented periodic tasks like that - now lease might be not started, started and ended - without any 'sleeping' periods. Although, that's quite nice idea to implement this feature using Mistral. Give someone 100 CPU hours per time period of quota. Support quotas by overall usage not current usage. This sounds like something that each service should support natively. Quotas (if we speak about time management) should be satisfied in any time period. Now in Climate that's done by getting cloud resources from common pool at the lease creation moment - but, as you guess, that does not allow to have resource reusage at the time lease has not started yet. To implement resource reusage advanced quota management is truly needed. That idea was the first at the very beginning of Climate project and we definitely need that in future. Reserved Volume: Not sure how that works. Now we're in the process of investigating this moment too. Ideally that should be some kind of volume state, that simply means only DB record without real block storage created - and it'll be created only at the lease start date. But that requires many changes to Cinder. Other idea is to do the same as Climate does with compute hosts - consider cinder-volumes as dedicated to Climate and Climate will manage them itself. Reserved volume idea came from thoughts about 'reserved stack' - to have working group like vm+volume+assigned_ip time you really need that. Virtual Private Cloud. It would be great to see OpenStack support a hardware isolated virtual private cloud, but not sure what the best way to implement that is. There was proposal with pclouds by Phil Day, that was changed after Icehouse summit to something new. First idea was to use exactly pclouds, but as they are not implemented now, Climate works directly with hosts aggregates to imitate them. In future, when we'll have opportunity to use pcloud (it does not matter how it'll be called really), we'll do it, of course. Capacity Planning. Sure, but it would be nice to see a more fleshed out story for it. Sure. I believe, that having resource reusage opportunity (when lease creation and resource allocation steps won't be the same one) will help to manage future capacity peak loads - because cloud provider will know about future user needs before resources will be really used. Cheers Dina On Tue, Mar 4, 2014 at 12:30 AM, Joe Gordon joe.gord...@gmail.com wrote: Overall I think Climate is trying to address some very real use cases, but its unclear to me where these solutions should live or how to solve them. Furthermore I understand what a reservation means for nova but I am not sure what it means in Cinder, Swift etc. To give a few examples: * I think nova should natively support booting an instance for a limited amount of time. I would use this all the time to boot up devstack instances (boot devstack instance for 5 hours) * Reserved and Spot Instances. I like Amazon's concept of reserved and spot instances it would be cool if we could support something similar * Boot an instances for 4 hours every morning. This sounds like something that https://wiki.openstack.org/wiki/Mistral#Tasks_Scheduling_-_Cloud_Cron can handle. * Give someone 100 CPU hours per time period of quota. Support quotas by overall usage not current usage. This sounds like something that each service should support natively. * Reserved Volume: Not sure how that works. * Virtual Private Cloud. It would be great to see OpenStack support a hardware isolated virtual private cloud, but not sure what the
Re: [openstack-dev] Climate Incubation Application
On Tue, Mar 4, 2014 at 5:25 AM, Dina Belova dbel...@mirantis.com wrote: Joe, thanks for discussion. I think nova should natively support booting an instance for a limited amount of time. I would use this all the time to boot up devstack instances (boot devstack instance for 5 hours) Really nice idea, but to provide time based resource management for any resource type in OS (instance, volume, compute host, Heat stack, etc.) that needs to be implemented in every project. And even with that feature implemented, without central leasing service, there should be some other reservation connected opportunities like user notifications about close end of lease / energy efficiency, etc. that do not really fit idea of some already existing project / program. So I understand the use case where I want a instance for x amount of time, because the cloud model makes compute resources (instances) ephemeral. But volumes and object storage are explicitly persistent, so not sure why you would want to consume one of those resources for a finite amount of time. Reserved and Spot Instances. I like Amazon's concept of reserved and spot instances it would be cool if we could support something similar AWS reserved instances look like your first idea with instances booted for a limited amount of time - even that in Amazon use case that's *much* time. As for spot instances, I believe this idea is more about some billing service that counts current instance/host/whatever price due to current compute capacity load, etc. Actually you have it backwards. Reserved Instances are easy to use and require no change to how you use EC2. When computing your bill, our system will automatically apply Reserved Instance rates first to minimize your costs. An instance hour will only be charged at the On-Demand rate when your total quantity of instances running that hour exceeds the number of applicable Reserved Instances you own. https://aws.amazon.com/ec2/purchasing-options/reserved-instances/ https://aws.amazon.com/ec2/purchasing-options/spot-instances/ Boot an instances for 4 hours every morning. This sounds like something that https://wiki.openstack.org/wiki/Mistral#Tasks_Scheduling_-_Cloud_Cron can handle. That's not really thing we've implemented in Climate - we have not implemented periodic tasks like that - now lease might be not started, started and ended - without any 'sleeping' periods. Although, that's quite nice idea to implement this feature using Mistral. Give someone 100 CPU hours per time period of quota. Support quotas by overall usage not current usage. This sounds like something that each service should support natively. Quotas (if we speak about time management) should be satisfied in any time period. Now in Climate that's done by getting cloud resources from common pool at the lease creation moment - but, as you guess, that does not allow to have resource reusage at the time lease has not started yet. To implement resource reusage advanced quota management is truly needed. That idea was the first at the very beginning of Climate project and we definitely need that in future. This is the crux of my concern: without 'resource reusage' at the time lease has not started yet. I don't see what climate provides. How would climate handle quotas? Currently quotas are up to each project to manage. Reserved Volume: Not sure how that works. Now we're in the process of investigating this moment too. Ideally that should be some kind of volume state, that simply means only DB record without real block storage created - and it'll be created only at the lease start date. But that requires many changes to Cinder. Other idea is to do the same as Climate does with compute hosts - consider cinder-volumes as dedicated to Climate and Climate will manage them itself. Reserved volume idea came from thoughts about 'reserved stack' - to have working group like vm+volume+assigned_ip time you really need that. I would like to see a clear roadmap for this with input from the Cinder team. Because I am not sure if this really makes much sense. Virtual Private Cloud. It would be great to see OpenStack support a hardware isolated virtual private cloud, but not sure what the best way to implement that is. There was proposal with pclouds by Phil Day, that was changed after Icehouse summit to something new. First idea was to use exactly pclouds, but as they are not implemented now, Climate works directly with hosts aggregates to imitate them. In future, when we'll have opportunity to use pcloud (it does not matter how it'll be called really), we'll do it, of course. That brings up another point, having a project that imports nova code directly is bad. You are using non-public non-contractual APIs that nova can change at any time. http://git.openstack.org/cgit/stackforge/climate-nova/tree/climatenova/api/extensions/reservation.py Having a nova filter that lives in
Re: [openstack-dev] Climate Incubation Application
Hello Joe, Thierry, Sylvain. Joe, I pretty agree with Sylvain in how he had described Climate idea. I hope it is more understandable now. Thierry, thanks for answering. I'm sorry I did not send this email before :) Thanks Dina On Mon, Mar 3, 2014 at 4:42 PM, Sylvain Bauza sylvain.ba...@bull.netwrote: Hi Joe, Thanks for your reply, I'll try to further explain. Le 03/03/2014 05:33, Joe Gordon a écrit : On Sun, Mar 2, 2014 at 11:32 AM, Dina Belova dbel...@mirantis.com wrote: Hello, folks! I'd like to request Climate project review for incubation. Here is official incubation application: https://wiki.openstack.org/wiki/Climate/Incubation I'm unclear on what Climate is trying to solve. I read the 'Detailed Description' from the link above, and it states Climate is trying to solve two uses cases (and the more generalized cases of those). 1) Compute host reservation (when user with admin privileges can reserve hardware resources that are dedicated to the sole use of a tenant) 2) Virtual machine (instance) reservation (when user may ask reservation service to provide him working VM not necessary now, but also in the future) Climate is born from the idea of dedicating compute resources to a single tenant or user for a certain amount of time, which was not yet implemented in Nova: how as an user, can I ask Nova for one compute host with certain specs to be exclusively allocated to my needs, starting in 2 days and being freed in 5 days ? Albeit the exclusive resource lock can be managed on the Nova side, there is currently no possibilities to ensure resource planner. Of course, and that's why we think Climate can also stand by its own Program, resource reservation can be seen on a more general way : what about reserving an Heat stack with its volume and network nested resources ? You want to support being able to reserve an instance in the future. As a cloud operator how do I take advantage of that information? As a cloud consumer, what is the benefit? Today OpenStack supports both uses cases, except it can't request an Instance for the future. Again, that's not only reserving an instance, but rather a complex mix of resources. At the moment, we do provide way to reserve virtual instances by shelving/unshelving them at the lease start, but we also give possibility to provide dedicated compute hosts. Considering it, the logic of resource allocation and scheduling (take the word as resource planner, in order not to confuse with Nova's scheduler concerns) and capacity planning is too big to fail under the Compute's umbrella, as it has been agreed within the Summit talks and periodical threads. From the user standpoint, there are multiple ways to integrate with Climate in order to get Capacity Planning capabilities. As you perhaps noticed, the workflow for reserving resources is different from one plugin to another. Either we say the user has to explicitly request for dedicated resources (using Climate CLI, see dedicate compute hosts allocation), or we implicitly integrate resource allocation from the Nova API (see virtual instance API hook). We truly accept our current implementation as a first prototype, where scheduling decisions can be improved (possibly thanks to some tight integration with a future external Scheduler aaS, hello Gantt), where also resource isolation and preemption must also be integrated with subprojects (we're currently seeing how to provision Cinder volumes and Neutron routers and nets), but anyway we still think there is a (IMHO big) room for resource and capacity management on its own project. Hoping it's clearer now, -Sylvain ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Climate Incubation Application
Forgot to put openstack-tc@ in the loop... Sorry for resending this email. -Sylvain Le 03/03/2014 13:42, Sylvain Bauza a écrit : Hi Joe, Thanks for your reply, I'll try to further explain. Le 03/03/2014 05:33, Joe Gordon a écrit : On Sun, Mar 2, 2014 at 11:32 AM, Dina Belova dbel...@mirantis.com wrote: Hello, folks! I'd like to request Climate project review for incubation. Here is official incubation application: https://wiki.openstack.org/wiki/Climate/Incubation I'm unclear on what Climate is trying to solve. I read the 'Detailed Description' from the link above, and it states Climate is trying to solve two uses cases (and the more generalized cases of those). 1) Compute host reservation (when user with admin privileges can reserve hardware resources that are dedicated to the sole use of a tenant) 2) Virtual machine (instance) reservation (when user may ask reservation service to provide him working VM not necessary now, but also in the future) Climate is born from the idea of dedicating compute resources to a single tenant or user for a certain amount of time, which was not yet implemented in Nova: how as an user, can I ask Nova for one compute host with certain specs to be exclusively allocated to my needs, starting in 2 days and being freed in 5 days ? Albeit the exclusive resource lock can be managed on the Nova side, there is currently no possibilities to ensure resource planner. Of course, and that’s why we think Climate can also stand by its own Program, resource reservation can be seen on a more general way : what about reserving an Heat stack with its volume and network nested resources ? You want to support being able to reserve an instance in the future. As a cloud operator how do I take advantage of that information? As a cloud consumer, what is the benefit? Today OpenStack supports both uses cases, except it can't request an Instance for the future. Again, that’s not only reserving an instance, but rather a complex mix of resources. At the moment, we do provide way to reserve virtual instances by shelving/unshelving them at the lease start, but we also give possibility to provide dedicated compute hosts. Considering it, the logic of resource allocation and scheduling (take the word as resource planner, in order not to confuse with Nova’s scheduler concerns) and capacity planning is too big to fail under the Compute’s umbrella, as it has been agreed within the Summit talks and periodical threads. From the user standpoint, there are multiple ways to integrate with Climate in order to get Capacity Planning capabilities. As you perhaps noticed, the workflow for reserving resources is different from one plugin to another. Either we say the user has to explicitly request for dedicated resources (using Climate CLI, see dedicate compute hosts allocation), or we implicitly integrate resource allocation from the Nova API (see virtual instance API hook). We truly accept our current implementation as a first prototype, where scheduling decisions can be improved (possibly thanks to some tight integration with a future external Scheduler aaS, hello Gantt), where also resource isolation and preemption must also be integrated with subprojects (we’re currently seeing how to provision Cinder volumes and Neutron routers and nets), but anyway we still think there is a (IMHO big) room for resource and capacity management on its own project. Hoping it's clearer now, -Sylvain ___ OpenStack-dev mailing list 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] Climate Incubation Application
On Mon, Mar 3, 2014 at 8:20 AM, Joe Gordon joe.gord...@gmail.com wrote: On Mon, Mar 3, 2014 at 4:42 AM, Sylvain Bauza sylvain.ba...@bull.net wrote: Hi Joe, Thanks for your reply, I'll try to further explain. Le 03/03/2014 05:33, Joe Gordon a écrit : On Sun, Mar 2, 2014 at 11:32 AM, Dina Belova dbel...@mirantis.com wrote: Hello, folks! I'd like to request Climate project review for incubation. Here is official incubation application: https://wiki.openstack.org/wiki/Climate/Incubation I'm unclear on what Climate is trying to solve. I read the 'Detailed Description' from the link above, and it states Climate is trying to solve two uses cases (and the more generalized cases of those). 1) Compute host reservation (when user with admin privileges can reserve hardware resources that are dedicated to the sole use of a tenant) 2) Virtual machine (instance) reservation (when user may ask reservation service to provide him working VM not necessary now, but also in the future) Climate is born from the idea of dedicating compute resources to a single tenant or user for a certain amount of time, which was not yet implemented in Nova: how as an user, can I ask Nova for one compute host with certain specs to be exclusively allocated to my needs, starting in 2 days and being freed in 5 days ? Albeit the exclusive resource lock can be managed on the Nova side, there is currently no possibilities to ensure resource planner. Of course, and that's why we think Climate can also stand by its own Program, resource reservation can be seen on a more general way : what about reserving an Heat stack with its volume and network nested resources ? You want to support being able to reserve an instance in the future. As a cloud operator how do I take advantage of that information? As a cloud consumer, what is the benefit? Today OpenStack supports both uses cases, except it can't request an Instance for the future. Again, that's not only reserving an instance, but rather a complex mix of resources. At the moment, we do provide way to reserve virtual instances by shelving/unshelving them at the lease start, but we also give possibility to provide dedicated compute hosts. Considering it, the logic of resource allocation and scheduling (take the word as resource planner, in order not to confuse with Nova's scheduler concerns) and capacity planning is too big to fail under the Compute's umbrella, as it has been agreed within the Summit talks and periodical threads. Capacity planning not falling under Compute's umbrella is news to me, are you referring to Gantt and scheduling in general? Perhaps I don't fully understand the full extent of what 'capacity planning' actually is. From the user standpoint, there are multiple ways to integrate with Climate in order to get Capacity Planning capabilities. As you perhaps noticed, the workflow for reserving resources is different from one plugin to another. Either we say the user has to explicitly request for dedicated resources (using Climate CLI, see dedicate compute hosts allocation), or we implicitly integrate resource allocation from the Nova API (see virtual instance API hook). I don't see how Climate reserves resources is relevant to the user. We truly accept our current implementation as a first prototype, where scheduling decisions can be improved (possibly thanks to some tight integration with a future external Scheduler aaS, hello Gantt), where also resource isolation and preemption must also be integrated with subprojects (we're currently seeing how to provision Cinder volumes and Neutron routers and nets), but anyway we still think there is a (IMHO big) room for resource and capacity management on its own project. Hoping it's clearer now, Unfortunately that doesn't clarify things for me. From the user's point of view what is the benefit from making a reservation in the future? Versus what Nova supports today, asking for an instance in the present. Same thing from the operator's perspective, what is the benefit of taking reservations for the future? This whole model is unclear to me because as far as I can tell no other clouds out there support this model, so I have nothing to compare it to. Hi Joe, I think it's meant to save consumers money by pricing instances based on today's prices. https://aws.amazon.com/ec2/purchasing-options/reserved-instances/ Anne -Sylvain ___ OpenStack-dev mailing list 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 ___ OpenStack-dev mailing
Re: [openstack-dev] Climate Incubation Application
On 03/02/2014 02:32 PM, Dina Belova wrote: Hello, folks! I'd like to request Climate project review for incubation. Here is official incubation application: https://wiki.openstack.org/wiki/Climate/Incubation Additionally due to the project scope and the roadmap, we don't see any currently existing OpenStack program that fits Climate. So we've prepared new program request too: https://wiki.openstack.org/wiki/Climate/Program TL;DR Our team is working on providing OpenStack with resource reservation opportunity in time-based manner, including close integration with all other OS projects. As Climate initiative is targeting to provide not only compute resources revervation, but also volumes, network resources, storage nodes reservation opportunity, we consider it is not about being a part of some existing OpenStack program. This initiative needs to become a part of completely new Resource Reservation Program, that aims to implement time-based cloud resource management. At a high level this feels like this should be part of scheduling. Scheduling might include resources you want right now, but it could include resources you want in the future. It also makes sense for scheduling to include deadlines, so that resources are reclaimed when they expire. Especially given quota implications of asking for resources now vs. resources that a user has reserved in the future. What happens when a user has used all their quota in the present, and a future reservation comes up for access? Scheduling today is under compute. The proposal to pull Gantt out still leaves it in the compute program. So I would naturally assume this should live under compute. I could understand that if this Gantt emerged together and wanted to create a Resource Allocation program, that might make sense. But I think that's way down the road. However, that's just a quick look at this. I think it will be an interesting discussion in how this effort moves forward. -Sean -- Sean Dague Samsung Research America s...@dague.net / sean.da...@samsung.com http://dague.net signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Climate Incubation Application
Hi Sean, 2014-03-03 16:04 GMT+01:00 Sean Dague s...@dague.net: At a high level this feels like this should be part of scheduling. Scheduling might include resources you want right now, but it could include resources you want in the future. It also makes sense for scheduling to include deadlines, so that resources are reclaimed when they expire. Especially given quota implications of asking for resources now vs. resources that a user has reserved in the future. What happens when a user has used all their quota in the present, and a future reservation comes up for access? Scheduling today is under compute. The proposal to pull Gantt out still leaves it in the compute program. So I would naturally assume this should live under compute. I could understand that if this Gantt emerged together and wanted to create a Resource Allocation program, that might make sense. But I think that's way down the road. However, that's just a quick look at this. I think it will be an interesting discussion in how this effort moves forward. -Sean I'm also particularly conviced that Gantt and Climate can work together for scheduling purposes, and that point has also been raised by other people during Gantt meetings, as you would find if you look at the logs. Climate raised the need of having a external scheduler for planning purposes during last design Summit, and I'm personnally following Gantt efforts as I think it would be worth contributing to it for our purposes. That said, I'm also been surprised that people within Gantt meetings raised the point of using Climate for scheduling decisions (see also threads about it with Solver Scheduler, for instance). So, when seeing some areas of mutual work in between Gantt and Climate, I can't say more. That said, albeit I'm thinking there could be some tight interactions between those 2 projects, they both stand by their own and address different needs : Gantt for what and Climate for when, as Dina said. Gantt is still in the early phase for incubation, still needing some Nova changes before standing by itself so I don't think they can't apply yet for a Program. That said, that's maybe a good opportunity to discuss about this Program, in particular about its mission statement, but again, it sounds like a good fit. -Sylvain ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Climate Incubation Application
On Mon, Mar 3, 2014 at 6:27 AM, Anne Gentle a...@openstack.org wrote: On Mon, Mar 3, 2014 at 8:20 AM, Joe Gordon joe.gord...@gmail.com wrote: On Mon, Mar 3, 2014 at 4:42 AM, Sylvain Bauza sylvain.ba...@bull.net wrote: Hi Joe, Thanks for your reply, I'll try to further explain. Le 03/03/2014 05:33, Joe Gordon a écrit : On Sun, Mar 2, 2014 at 11:32 AM, Dina Belova dbel...@mirantis.com wrote: Hello, folks! I'd like to request Climate project review for incubation. Here is official incubation application: https://wiki.openstack.org/wiki/Climate/Incubation I'm unclear on what Climate is trying to solve. I read the 'Detailed Description' from the link above, and it states Climate is trying to solve two uses cases (and the more generalized cases of those). 1) Compute host reservation (when user with admin privileges can reserve hardware resources that are dedicated to the sole use of a tenant) 2) Virtual machine (instance) reservation (when user may ask reservation service to provide him working VM not necessary now, but also in the future) Climate is born from the idea of dedicating compute resources to a single tenant or user for a certain amount of time, which was not yet implemented in Nova: how as an user, can I ask Nova for one compute host with certain specs to be exclusively allocated to my needs, starting in 2 days and being freed in 5 days ? Albeit the exclusive resource lock can be managed on the Nova side, there is currently no possibilities to ensure resource planner. Of course, and that's why we think Climate can also stand by its own Program, resource reservation can be seen on a more general way : what about reserving an Heat stack with its volume and network nested resources ? You want to support being able to reserve an instance in the future. As a cloud operator how do I take advantage of that information? As a cloud consumer, what is the benefit? Today OpenStack supports both uses cases, except it can't request an Instance for the future. Again, that's not only reserving an instance, but rather a complex mix of resources. At the moment, we do provide way to reserve virtual instances by shelving/unshelving them at the lease start, but we also give possibility to provide dedicated compute hosts. Considering it, the logic of resource allocation and scheduling (take the word as resource planner, in order not to confuse with Nova's scheduler concerns) and capacity planning is too big to fail under the Compute's umbrella, as it has been agreed within the Summit talks and periodical threads. Capacity planning not falling under Compute's umbrella is news to me, are you referring to Gantt and scheduling in general? Perhaps I don't fully understand the full extent of what 'capacity planning' actually is. From the user standpoint, there are multiple ways to integrate with Climate in order to get Capacity Planning capabilities. As you perhaps noticed, the workflow for reserving resources is different from one plugin to another. Either we say the user has to explicitly request for dedicated resources (using Climate CLI, see dedicate compute hosts allocation), or we implicitly integrate resource allocation from the Nova API (see virtual instance API hook). I don't see how Climate reserves resources is relevant to the user. We truly accept our current implementation as a first prototype, where scheduling decisions can be improved (possibly thanks to some tight integration with a future external Scheduler aaS, hello Gantt), where also resource isolation and preemption must also be integrated with subprojects (we're currently seeing how to provision Cinder volumes and Neutron routers and nets), but anyway we still think there is a (IMHO big) room for resource and capacity management on its own project. Hoping it's clearer now, Unfortunately that doesn't clarify things for me. From the user's point of view what is the benefit from making a reservation in the future? Versus what Nova supports today, asking for an instance in the present. Same thing from the operator's perspective, what is the benefit of taking reservations for the future? This whole model is unclear to me because as far as I can tell no other clouds out there support this model, so I have nothing to compare it to. Hi Joe, I think it's meant to save consumers money by pricing instances based on today's prices. https://aws.amazon.com/ec2/purchasing-options/reserved-instances/ The reserved concept in Amazon, is very different then the one proposed here. The amazon concept doesn't support saying I will need an instance in 3 days, this is trying to support that use case. Furthermore I am not sure how the climate proposal would allow a cloud provider to offer a cheaper offering. Anne -Sylvain
Re: [openstack-dev] Climate Incubation Application
Joe, as said, Amazon reservation is not like implemented in Climate - and really we had different original use cases to have the same result. Amazon instances reservations do not guarantee that instance will be provided to user, as in Climate we started implemented reservations possibilities with this guarantee (due to original use cases). That's why we're mostly speaking about time-based resource management now, not billing purposes. Lease creation request now contains the following steps: create lease - start lease - end lease Also there are user notifications, but they are connected with lease start/end events, so that's not some separated stuff now. Although, if we'll implement one more second step like 'allocate resources' - that will allow us to have reservations with no guarantees, and that will make Climate possibilities containing Amazon use case. Thanks On Mon, Mar 3, 2014 at 9:04 PM, Joe Gordon joe.gord...@gmail.com wrote: On Mon, Mar 3, 2014 at 6:27 AM, Anne Gentle a...@openstack.org wrote: On Mon, Mar 3, 2014 at 8:20 AM, Joe Gordon joe.gord...@gmail.com wrote: On Mon, Mar 3, 2014 at 4:42 AM, Sylvain Bauza sylvain.ba...@bull.net wrote: Hi Joe, Thanks for your reply, I'll try to further explain. Le 03/03/2014 05:33, Joe Gordon a écrit : On Sun, Mar 2, 2014 at 11:32 AM, Dina Belova dbel...@mirantis.com wrote: Hello, folks! I'd like to request Climate project review for incubation. Here is official incubation application: https://wiki.openstack.org/wiki/Climate/Incubation I'm unclear on what Climate is trying to solve. I read the 'Detailed Description' from the link above, and it states Climate is trying to solve two uses cases (and the more generalized cases of those). 1) Compute host reservation (when user with admin privileges can reserve hardware resources that are dedicated to the sole use of a tenant) 2) Virtual machine (instance) reservation (when user may ask reservation service to provide him working VM not necessary now, but also in the future) Climate is born from the idea of dedicating compute resources to a single tenant or user for a certain amount of time, which was not yet implemented in Nova: how as an user, can I ask Nova for one compute host with certain specs to be exclusively allocated to my needs, starting in 2 days and being freed in 5 days ? Albeit the exclusive resource lock can be managed on the Nova side, there is currently no possibilities to ensure resource planner. Of course, and that's why we think Climate can also stand by its own Program, resource reservation can be seen on a more general way : what about reserving an Heat stack with its volume and network nested resources ? You want to support being able to reserve an instance in the future. As a cloud operator how do I take advantage of that information? As a cloud consumer, what is the benefit? Today OpenStack supports both uses cases, except it can't request an Instance for the future. Again, that's not only reserving an instance, but rather a complex mix of resources. At the moment, we do provide way to reserve virtual instances by shelving/unshelving them at the lease start, but we also give possibility to provide dedicated compute hosts. Considering it, the logic of resource allocation and scheduling (take the word as resource planner, in order not to confuse with Nova's scheduler concerns) and capacity planning is too big to fail under the Compute's umbrella, as it has been agreed within the Summit talks and periodical threads. Capacity planning not falling under Compute's umbrella is news to me, are you referring to Gantt and scheduling in general? Perhaps I don't fully understand the full extent of what 'capacity planning' actually is. From the user standpoint, there are multiple ways to integrate with Climate in order to get Capacity Planning capabilities. As you perhaps noticed, the workflow for reserving resources is different from one plugin to another. Either we say the user has to explicitly request for dedicated resources (using Climate CLI, see dedicate compute hosts allocation), or we implicitly integrate resource allocation from the Nova API (see virtual instance API hook). I don't see how Climate reserves resources is relevant to the user. We truly accept our current implementation as a first prototype, where scheduling decisions can be improved (possibly thanks to some tight integration with a future external Scheduler aaS, hello Gantt), where also resource isolation and preemption must also be integrated with subprojects (we're currently seeing how to provision Cinder volumes and Neutron routers and nets), but anyway we still think there is a (IMHO big) room for resource and
Re: [openstack-dev] Climate Incubation Application
On Mon, Mar 3, 2014 at 8:00 AM, Dina Belova dbel...@mirantis.com wrote: Capacity planning not falling under Compute's umbrella is news to me, are you referring to Gantt and scheduling in general? Perhaps I don't fully understand the full extent of what 'capacity planning' actually is. We intend that 'capacity' means not only 'compute capacity', but any kind of resources capacity - we may plan not only compute resources usage, but also storage, etc. Gantt is about 'where to schedule' potentially any kind of resources, Climate is about 'when'. Term 'scheduling' in Climate sphere has no reference to common OS scheduling process, here we mean something like 'timetable', that's much closer. Capacity planning here is ability to predict the fact of resource usage in future (for cloud providers), and provide these resources to users. I don't see how Climate reserves resources is relevant to the user. From the user's point of view what is the benefit from making a reservation in the future? Versus what Nova supports today, asking for an instance in the present. Same thing from the operator's perspective, what is the benefit of taking reservations for the future? Joe, I'll describe two original use cases, that were the reason for Climate to be created. I suppose it might give idea of what we were thinking about while its implementation. Host reservation use case This use case was born to fit XLcloud (http://www.xlcloud.org) project. Needs of this project require usage of whole hosts compute capacities without any other VMs running on them - and to create some kind of hosts usage timetable. The last thing is needed to implement energy efficiency for OS cloud, where these High Performance Cloud Computing jobs will be running on. That will allow to keep unused hosts in 'shut down' state and to wake them up where they'll be really needed. Steps for this use case may be described in the following way: 1) admin user marks some hosts from common pool as 'reservable' - these hosts then will be given to user who wants to use their whole capacity and will be 'isolated' to the solely use of Climate until they are freed 2) if user wants to use some of these hosts, he/she asks Climate to provide some amount of these hosts with any wanted specs - like amount of RAM, CPU, etc. 3) Climate remembers that these hosts will be used in some time for some amount of time 4) when lease (contract between user and Climate) will start, user may use these hosts to run VMs on them In future we'll implement energy efficiency, that will completely fit this first use case. This sounds like something that belongs in nova, Phil Day has an elegant solution for this: https://blueprints.launchpad.net/nova/+spec/whole-host-allocation === VM reservation use case === This use case was created as a result of automated virtual resource allocation/reclaiming idea for dev clouds. If company has dev cloud for its developers, it'll be great if there won't be created and forgotten VMs running on - for this, process of VMs booting/shutting them down should be automated and processed by some independent service. Heat? I spin up dev instances all the time and have never had this problem in part because if I forget my quota will remind me. Here was born idea of virtual reservations. Some usual workflow for this use case looks like: 1) user knows that in future he'll need lab with some VMs in it and he asks Climate to reserve them (now we've implemented one VM reservation) Why does he need to reserve them in the future? When he wants an instance can't he just get one? As Sean said, what happens if someone has no free quota when the reservation kicks in? 2) Climate remembers that this VM will be used in some time for some amount of time (now we've implemented plugins that keeps these VMs in shelved state while they are not used) 3) when lease starts, Climate wakes this VM and it's completely ready to be used How is this different from 'nova boot?' When nova boot finishes the VM is completely ready to be used As we've discussed with Cafe project folks (https://wiki.openstack.org/wiki/Cafe) - this ability will be helpful for academic usage, where students also need to have automatically allocated/reclaimed virtual resources. Cafe sounds a bit like more sophisticated quotas, quotas that work on overall usage not just current usage. = As said, these two use cases were original ones, and now we're thinking about more general view - any type of physical/virtual resource to be managed in time. For example, we're planning to implement complex virtual resource reservations (like Heat stacks), that will allow developers/students to have working small OS clouds by the time they'll need them. I can do that today, I spin a up a devstack VM in the
Re: [openstack-dev] Climate Incubation Application
On Mon, Mar 3, 2014 at 9:22 AM, Dina Belova dbel...@mirantis.com wrote: Joe, as said, Amazon reservation is not like implemented in Climate - and really we had different original use cases to have the same result. Amazon instances reservations do not guarantee that instance will be provided to user, as in Climate we started implemented reservations possibilities with this guarantee (due to original use cases). That's why we're mostly speaking about time-based resource management now, not billing purposes. Reliable Reserved Instances provide a capacity reservation so that you can have confidence in your ability to launch the number of instances you have reserved when you need them. https://aws.amazon.com/ec2/purchasing-options/reserved-instances/ That sounds like a guarantee to me. How does climate enforce a guarantee while freeing the physical resource for something else to use? Otherwise you are consuming a resource without charging anyone (assuming you don't charge anything for a reservation for a lease that hasn't started. Lease creation request now contains the following steps: create lease - start lease - end lease Also there are user notifications, but they are connected with lease start/end events, so that's not some separated stuff now. Although, if we'll implement one more second step like 'allocate resources' - that will allow us to have reservations with no guarantees, and that will make Climate possibilities containing Amazon use case. Thanks On Mon, Mar 3, 2014 at 9:04 PM, Joe Gordon joe.gord...@gmail.com wrote: On Mon, Mar 3, 2014 at 6:27 AM, Anne Gentle a...@openstack.org wrote: On Mon, Mar 3, 2014 at 8:20 AM, Joe Gordon joe.gord...@gmail.com wrote: On Mon, Mar 3, 2014 at 4:42 AM, Sylvain Bauza sylvain.ba...@bull.net wrote: Hi Joe, Thanks for your reply, I'll try to further explain. Le 03/03/2014 05:33, Joe Gordon a écrit : On Sun, Mar 2, 2014 at 11:32 AM, Dina Belova dbel...@mirantis.com wrote: Hello, folks! I'd like to request Climate project review for incubation. Here is official incubation application: https://wiki.openstack.org/wiki/Climate/Incubation I'm unclear on what Climate is trying to solve. I read the 'Detailed Description' from the link above, and it states Climate is trying to solve two uses cases (and the more generalized cases of those). 1) Compute host reservation (when user with admin privileges can reserve hardware resources that are dedicated to the sole use of a tenant) 2) Virtual machine (instance) reservation (when user may ask reservation service to provide him working VM not necessary now, but also in the future) Climate is born from the idea of dedicating compute resources to a single tenant or user for a certain amount of time, which was not yet implemented in Nova: how as an user, can I ask Nova for one compute host with certain specs to be exclusively allocated to my needs, starting in 2 days and being freed in 5 days ? Albeit the exclusive resource lock can be managed on the Nova side, there is currently no possibilities to ensure resource planner. Of course, and that's why we think Climate can also stand by its own Program, resource reservation can be seen on a more general way : what about reserving an Heat stack with its volume and network nested resources ? You want to support being able to reserve an instance in the future. As a cloud operator how do I take advantage of that information? As a cloud consumer, what is the benefit? Today OpenStack supports both uses cases, except it can't request an Instance for the future. Again, that's not only reserving an instance, but rather a complex mix of resources. At the moment, we do provide way to reserve virtual instances by shelving/unshelving them at the lease start, but we also give possibility to provide dedicated compute hosts. Considering it, the logic of resource allocation and scheduling (take the word as resource planner, in order not to confuse with Nova's scheduler concerns) and capacity planning is too big to fail under the Compute's umbrella, as it has been agreed within the Summit talks and periodical threads. Capacity planning not falling under Compute's umbrella is news to me, are you referring to Gantt and scheduling in general? Perhaps I don't fully understand the full extent of what 'capacity planning' actually is. From the user standpoint, there are multiple ways to integrate with Climate in order to get Capacity Planning capabilities. As you perhaps noticed, the workflow for reserving resources is different from one plugin to another. Either we say the user has to explicitly request for dedicated resources (using Climate CLI, see dedicate compute hosts allocation), or we
Re: [openstack-dev] Climate Incubation Application
On 03/03/14 12:32, Joe Gordon wrote: - if you're reserving resources far before you'll need them, it'll be cheaper Why? How does this save a provider money? If an operator has zero information about the level of future demand, they will have to spend a *lot* of money on excess capacity or risk running out. If an operator has perfect information about future demand, then they need spend no money on excess capacity. Everywhere in between, the amount of extra money they need to spend is a non-increasing function of the amount of information they have. QED. cheers, Zane. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Climate Incubation Application
On Mon, Mar 3, 2014 at 10:01 AM, Zane Bitter zbit...@redhat.com wrote: On 03/03/14 12:32, Joe Gordon wrote: - if you're reserving resources far before you'll need them, it'll be cheaper Why? How does this save a provider money? If an operator has zero information about the level of future demand, they will have to spend a *lot* of money on excess capacity or risk running out. If an operator has perfect information about future demand, then they need spend no money on excess capacity. Everywhere in between, the amount of extra money they need to spend is a non-increasing function of the amount of information they have. QED. Sure. if an operator has perfect information about future demand they won't need any excess capacity. But assuming you know some future demand, how do you figure out how much of the future demand you know? But sure I can see this as a potential money saver, but unclear by how much. The Amazon model for this is a reservation is at minimum a year, I am not sure how useful short term reservations would be in determining future demand. cheers, Zane. ___ OpenStack-dev mailing list 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] Climate Incubation Application
Oh, Sylvain, you were first :) I have just small things to add here: Joe, resource usage planning is great feature, that, I believe, is not supported in OS services now. Resource planning will allow cloud providers to react on future picks of loads, because they *will know* about that. As Zane said, otherwise you need to spend much money keeping much extra capacity in common pool, or have real risks to run out of resources. Everything else was described by Sylvain, I guess :) -- Dina On Mon, Mar 3, 2014 at 10:13 PM, Sylvain Bauza sylvain.ba...@gmail.comwrote: Hi Joe, 2014-03-03 18:32 GMT+01:00 Joe Gordon joe.gord...@gmail.com: This sounds like something that belongs in nova, Phil Day has an elegant solution for this: https://blueprints.launchpad.net/nova/+spec/whole-host-allocation This blueprint has already been addressed by Climate team, and we discussed about this with Phil directly. This blueprint has been recently abandoned by its author and Phil is trying to focus on dedicated instances instead. As we identified this blueprint as non-supported yet, we implemented its logic directly within Climate. That said, don't confuse 2 different things : - the locking process for isolating one compute node to a single tenant : that should be done in Nova - the timetable for scheduling hosts and electing which ones are appropriate : that must be done in Climate (and in the future, should use Gantt as external scheduler for electing from a pool of available hosts on that timeframe) Don't let me say that the resource isolation must be done within Climate : I'm definitely conviced that this logic should be done on the resource project level (Nova, Cinder, Neutron) and Climate should use their respective CLI for asking isolation. The overall layer for defining what will available when, and what are the dependencies in between projects, still relies on a shared service, which is Climate. Heat? I spin up dev instances all the time and have never had this problem in part because if I forget my quota will remind me. How do you ensure that you won't run out of resources when firing up an instance in 3 days ? How can you guaranttee that in the next couple of days, you would be able to create a volume with 50GB of space ? I'm not saying that the current Climate implementation does all the work. I'm just saying it's duty of Climate to look at Quality of Service aspects for resource allocation (or say SLA if you prefer) Why does he need to reserve them in the future? When he wants an instance can't he just get one? As Sean said, what happens if someone has no free quota when the reservation kicks in? That's the role of the resource plugin to manage capacity and ensure everything can be charged correctly. Regarding the virtual instances plugin logic, that's something that can be improved, but consider the thing that the instance is already created but not spawned when the lease is created, so that the quota is decreased from one. With the compute hosts plugin, we manage availability thanks to a resource planner, based on a fixed set of resources (enrolled compute hosts within Climate), so we can almost guaranttee this (minus the hosts outages we could get, of course) How is this different from 'nova boot?' When nova boot finishes the VM is completely ready to be used Nova boot directly creates the VM when the command is issued, while the proposal here is to defer the booting itself only at the lease start (which can happen far later than when the lease is created) - if you're reserving resources far before you'll need them, it'll be cheaper Why? How does this save a provider money? From a cloud operator point of view, don't you think it's way preferrable to get feedback for future capacity needs ? Don't you feel it would be interesting for him to propose a business model like this ? Reserved Instances provide a capacity reservation so that you can have confidence in your ability to launch the number of instances you have reserved when you need them. https://aws.amazon.com/ec2/purchasing-options/reserved-instances/ Amazon does guarantee the resource will be available. Amazon can guarantee the resource because they can terminate spot instances at will, but OpenStack doesn't have this concept today. That's why we think there is a need for guarantteing resource allocation within Openstack. Spot instances can be envisaged thanks to Climate as a formal contract for reserving resources that can be freed if needed. -Sylvain ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org
Re: [openstack-dev] Climate Incubation Application
On 03/03/2014 01:35 PM, Joe Gordon wrote: On Mon, Mar 3, 2014 at 10:01 AM, Zane Bitter zbit...@redhat.com wrote: On 03/03/14 12:32, Joe Gordon wrote: - if you're reserving resources far before you'll need them, it'll be cheaper Why? How does this save a provider money? If an operator has zero information about the level of future demand, they will have to spend a *lot* of money on excess capacity or risk running out. If an operator has perfect information about future demand, then they need spend no money on excess capacity. Everywhere in between, the amount of extra money they need to spend is a non-increasing function of the amount of information they have. QED. Sure. if an operator has perfect information about future demand they won't need any excess capacity. But assuming you know some future demand, how do you figure out how much of the future demand you know? But sure I can see this as a potential money saver, but unclear by how much. The Amazon model for this is a reservation is at minimum a year, I am not sure how useful short term reservations would be in determining future demand. There are other useful things with reservations though. In a private context the classic one is running number for close of business. Or software team that's working towards a release might want to preallocate resources for longer scale runs during a particular week. Reservation can really be about global policy giving some tenants more priority in getting resources than others (because you pre-allocate them). I also know that with a lot of the HPC teams using OpenStack, this is a fundamental part of scheduling. Not just the when, but the how long. Having systems automatically get reaped after a certain amount of time is something they very much want. So I think the general idea have merrit. I just think we need to make sure it integrates well with the rest of OpenStack, which I believe means strong coupling to the scheduler. -Sean -- Sean Dague Samsung Research America s...@dague.net / sean.da...@samsung.com http://dague.net signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Climate Incubation Application
On Mon, Mar 3, 2014 at 10:13 AM, Sylvain Bauza sylvain.ba...@gmail.com wrote: Hi Joe, 2014-03-03 18:32 GMT+01:00 Joe Gordon joe.gord...@gmail.com: This sounds like something that belongs in nova, Phil Day has an elegant solution for this: https://blueprints.launchpad.net/nova/+spec/whole-host-allocation This blueprint has already been addressed by Climate team, and we discussed about this with Phil directly. This blueprint has been recently abandoned by its author and Phil is trying to focus on dedicated instances instead. As we identified this blueprint as non-supported yet, we implemented its logic directly within Climate. That said, don't confuse 2 different things : - the locking process for isolating one compute node to a single tenant : that should be done in Nova - the timetable for scheduling hosts and electing which ones are appropriate : that must be done in Climate (and in the future, should use Gantt as external scheduler for electing from a pool of available hosts on that timeframe) Don't let me say that the resource isolation must be done within Climate : I'm definitely conviced that this logic should be done on the resource project level (Nova, Cinder, Neutron) and Climate should use their respective CLI for asking isolation. The overall layer for defining what will available when, and what are the dependencies in between projects, still relies on a shared service, which is Climate. Heat? I spin up dev instances all the time and have never had this problem in part because if I forget my quota will remind me. How do you ensure that you won't run out of resources when firing up an instance in 3 days ? How can you guaranttee that in the next couple of days, you would be able to create a volume with 50GB of space ? I have access to 2 public clouds that both would be very embarrassed if they ran out of capacity, so they make sure that doesn't happen. I'm not saying that the current Climate implementation does all the work. I'm just saying it's duty of Climate to look at Quality of Service aspects for resource allocation (or say SLA if you prefer) Why does he need to reserve them in the future? When he wants an instance can't he just get one? As Sean said, what happens if someone has no free quota when the reservation kicks in? That's the role of the resource plugin to manage capacity and ensure everything can be charged correctly. Regarding the virtual instances plugin logic, that's something that can be improved, but consider the thing that the instance is already created but not spawned when the lease is created, so that the quota is decreased from one. With the compute hosts plugin, we manage availability thanks to a resource planner, based on a fixed set of resources (enrolled compute hosts within Climate), so we can almost guaranttee this (minus the hosts outages we could get, of course) I don't follow, how does climate make these guarantees? How is this different from 'nova boot?' When nova boot finishes the VM is completely ready to be used Nova boot directly creates the VM when the command is issued, while the proposal here is to defer the booting itself only at the lease start (which can happen far later than when the lease is created) Why can't I just run 'nova boot' when I want the lease to start. - if you're reserving resources far before you'll need them, it'll be cheaper Why? How does this save a provider money? From a cloud operator point of view, don't you think it's way preferrable to get feedback for future capacity needs ? Don't you feel it would be interesting for him to propose a business model like this ? Not really, the amazon model, where a reservation is long term makes sense, but I don't see how short term reservations would help cloud operators. Reserved Instances provide a capacity reservation so that you can have confidence in your ability to launch the number of instances you have reserved when you need them. https://aws.amazon.com/ec2/purchasing-options/reserved-instances/ Amazon does guarantee the resource will be available. Amazon can guarantee the resource because they can terminate spot instances at will, but OpenStack doesn't have this concept today. That's why we think there is a need for guarantteing resource allocation within Openstack. Spot instances can be envisaged thanks to Climate as a formal contract for reserving resources that can be freed if needed. I like this idea, but something should be in Nova. Not sure how this concept of spot instances works for other resource such as object or volume storage. -Sylvain ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org
Re: [openstack-dev] Climate Incubation Application
On Mon, Mar 3, 2014 at 10:39 AM, Dina Belova dbel...@mirantis.com wrote: Oh, Sylvain, you were first :) I have just small things to add here: Joe, resource usage planning is great feature, that, I believe, is not supported in OS services now. Resource planning will allow cloud providers to react on future picks of loads, because they *will know* about that. As Zane said, otherwise you need to spend much money keeping much extra capacity in common pool, or have real risks to run out of resources. I think OpenStack supports resource planning today, otherwise how could public clouds do it? You can look at usage trends and make an educated guess what future usage will be and plan accordingly. I like amazon's concept of reserved instances, where reservations are long term (1 to 3 years) https://aws.amazon.com/ec2/purchasing-options/reserved-instances/ Everything else was described by Sylvain, I guess :) -- Dina On Mon, Mar 3, 2014 at 10:13 PM, Sylvain Bauza sylvain.ba...@gmail.com wrote: Hi Joe, 2014-03-03 18:32 GMT+01:00 Joe Gordon joe.gord...@gmail.com: This sounds like something that belongs in nova, Phil Day has an elegant solution for this: https://blueprints.launchpad.net/nova/+spec/whole-host-allocation This blueprint has already been addressed by Climate team, and we discussed about this with Phil directly. This blueprint has been recently abandoned by its author and Phil is trying to focus on dedicated instances instead. As we identified this blueprint as non-supported yet, we implemented its logic directly within Climate. That said, don't confuse 2 different things : - the locking process for isolating one compute node to a single tenant : that should be done in Nova - the timetable for scheduling hosts and electing which ones are appropriate : that must be done in Climate (and in the future, should use Gantt as external scheduler for electing from a pool of available hosts on that timeframe) Don't let me say that the resource isolation must be done within Climate : I'm definitely conviced that this logic should be done on the resource project level (Nova, Cinder, Neutron) and Climate should use their respective CLI for asking isolation. The overall layer for defining what will available when, and what are the dependencies in between projects, still relies on a shared service, which is Climate. Heat? I spin up dev instances all the time and have never had this problem in part because if I forget my quota will remind me. How do you ensure that you won't run out of resources when firing up an instance in 3 days ? How can you guaranttee that in the next couple of days, you would be able to create a volume with 50GB of space ? I'm not saying that the current Climate implementation does all the work. I'm just saying it's duty of Climate to look at Quality of Service aspects for resource allocation (or say SLA if you prefer) Why does he need to reserve them in the future? When he wants an instance can't he just get one? As Sean said, what happens if someone has no free quota when the reservation kicks in? That's the role of the resource plugin to manage capacity and ensure everything can be charged correctly. Regarding the virtual instances plugin logic, that's something that can be improved, but consider the thing that the instance is already created but not spawned when the lease is created, so that the quota is decreased from one. With the compute hosts plugin, we manage availability thanks to a resource planner, based on a fixed set of resources (enrolled compute hosts within Climate), so we can almost guaranttee this (minus the hosts outages we could get, of course) How is this different from 'nova boot?' When nova boot finishes the VM is completely ready to be used Nova boot directly creates the VM when the command is issued, while the proposal here is to defer the booting itself only at the lease start (which can happen far later than when the lease is created) - if you're reserving resources far before you'll need them, it'll be cheaper Why? How does this save a provider money? From a cloud operator point of view, don't you think it's way preferrable to get feedback for future capacity needs ? Don't you feel it would be interesting for him to propose a business model like this ? Reserved Instances provide a capacity reservation so that you can have confidence in your ability to launch the number of instances you have reserved when you need them. https://aws.amazon.com/ec2/purchasing-options/reserved-instances/ Amazon does guarantee the resource will be available. Amazon can guarantee the resource because they can terminate spot instances at will, but OpenStack doesn't have this concept today. That's why we think there is a need for guarantteing resource allocation within Openstack. Spot instances can be envisaged thanks to Climate as a formal contract for reserving
Re: [openstack-dev] Climate Incubation Application
On Mon, Mar 3, 2014 at 11:04 AM, Joe Gordon joe.gord...@gmail.com wrote: On Mon, Mar 3, 2014 at 6:27 AM, Anne Gentle a...@openstack.org wrote: On Mon, Mar 3, 2014 at 8:20 AM, Joe Gordon joe.gord...@gmail.com wrote: On Mon, Mar 3, 2014 at 4:42 AM, Sylvain Bauza sylvain.ba...@bull.net wrote: Hi Joe, Thanks for your reply, I'll try to further explain. Le 03/03/2014 05:33, Joe Gordon a écrit : On Sun, Mar 2, 2014 at 11:32 AM, Dina Belova dbel...@mirantis.com wrote: Hello, folks! I'd like to request Climate project review for incubation. Here is official incubation application: https://wiki.openstack.org/wiki/Climate/Incubation I'm unclear on what Climate is trying to solve. I read the 'Detailed Description' from the link above, and it states Climate is trying to solve two uses cases (and the more generalized cases of those). 1) Compute host reservation (when user with admin privileges can reserve hardware resources that are dedicated to the sole use of a tenant) 2) Virtual machine (instance) reservation (when user may ask reservation service to provide him working VM not necessary now, but also in the future) Climate is born from the idea of dedicating compute resources to a single tenant or user for a certain amount of time, which was not yet implemented in Nova: how as an user, can I ask Nova for one compute host with certain specs to be exclusively allocated to my needs, starting in 2 days and being freed in 5 days ? Albeit the exclusive resource lock can be managed on the Nova side, there is currently no possibilities to ensure resource planner. Of course, and that's why we think Climate can also stand by its own Program, resource reservation can be seen on a more general way : what about reserving an Heat stack with its volume and network nested resources ? You want to support being able to reserve an instance in the future. As a cloud operator how do I take advantage of that information? As a cloud consumer, what is the benefit? Today OpenStack supports both uses cases, except it can't request an Instance for the future. Again, that's not only reserving an instance, but rather a complex mix of resources. At the moment, we do provide way to reserve virtual instances by shelving/unshelving them at the lease start, but we also give possibility to provide dedicated compute hosts. Considering it, the logic of resource allocation and scheduling (take the word as resource planner, in order not to confuse with Nova's scheduler concerns) and capacity planning is too big to fail under the Compute's umbrella, as it has been agreed within the Summit talks and periodical threads. Capacity planning not falling under Compute's umbrella is news to me, are you referring to Gantt and scheduling in general? Perhaps I don't fully understand the full extent of what 'capacity planning' actually is. From the user standpoint, there are multiple ways to integrate with Climate in order to get Capacity Planning capabilities. As you perhaps noticed, the workflow for reserving resources is different from one plugin to another. Either we say the user has to explicitly request for dedicated resources (using Climate CLI, see dedicate compute hosts allocation), or we implicitly integrate resource allocation from the Nova API (see virtual instance API hook). I don't see how Climate reserves resources is relevant to the user. We truly accept our current implementation as a first prototype, where scheduling decisions can be improved (possibly thanks to some tight integration with a future external Scheduler aaS, hello Gantt), where also resource isolation and preemption must also be integrated with subprojects (we're currently seeing how to provision Cinder volumes and Neutron routers and nets), but anyway we still think there is a (IMHO big) room for resource and capacity management on its own project. Hoping it's clearer now, Unfortunately that doesn't clarify things for me. From the user's point of view what is the benefit from making a reservation in the future? Versus what Nova supports today, asking for an instance in the present. Same thing from the operator's perspective, what is the benefit of taking reservations for the future? This whole model is unclear to me because as far as I can tell no other clouds out there support this model, so I have nothing to compare it to. Hi Joe, I think it's meant to save consumers money by pricing instances based on today's prices. https://aws.amazon.com/ec2/purchasing-options/reserved-instances/ The reserved concept in Amazon, is very different then the one proposed here. The amazon concept doesn't support saying I will need an
Re: [openstack-dev] Climate Incubation Application
On Mon, Mar 3, 2014 at 10:43 AM, Sean Dague s...@dague.net wrote: On 03/03/2014 01:35 PM, Joe Gordon wrote: On Mon, Mar 3, 2014 at 10:01 AM, Zane Bitter zbit...@redhat.com wrote: On 03/03/14 12:32, Joe Gordon wrote: - if you're reserving resources far before you'll need them, it'll be cheaper Why? How does this save a provider money? If an operator has zero information about the level of future demand, they will have to spend a *lot* of money on excess capacity or risk running out. If an operator has perfect information about future demand, then they need spend no money on excess capacity. Everywhere in between, the amount of extra money they need to spend is a non-increasing function of the amount of information they have. QED. Sure. if an operator has perfect information about future demand they won't need any excess capacity. But assuming you know some future demand, how do you figure out how much of the future demand you know? But sure I can see this as a potential money saver, but unclear by how much. The Amazon model for this is a reservation is at minimum a year, I am not sure how useful short term reservations would be in determining future demand. There are other useful things with reservations though. In a private context the classic one is running number for close of business. Or software team that's working towards a release might want to preallocate resources for longer scale runs during a particular week. Why can't they pre-allocate now? Reservation can really be about global policy giving some tenants more priority in getting resources than others (because you pre-allocate them). I also know that with a lot of the HPC teams using OpenStack, this is a fundamental part of scheduling. Not just the when, but the how long. Having systems automatically get reaped after a certain amount of time is something they very much want. Agreed, I think this should either be part of Nova or Heat directly. So I think the general idea have merrit. I just think we need to make sure it integrates well with the rest of OpenStack, which I believe means strong coupling to the scheduler. -Sean -- Sean Dague Samsung Research America s...@dague.net / sean.da...@samsung.com http://dague.net ___ OpenStack-dev mailing list 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] Climate Incubation Application
Overall I think Climate is trying to address some very real use cases, but its unclear to me where these solutions should live or how to solve them. Furthermore I understand what a reservation means for nova but I am not sure what it means in Cinder, Swift etc. To give a few examples: * I think nova should natively support booting an instance for a limited amount of time. I would use this all the time to boot up devstack instances (boot devstack instance for 5 hours) * Reserved and Spot Instances. I like Amazon's concept of reserved and spot instances it would be cool if we could support something similar * Boot an instances for 4 hours every morning. This sounds like something that https://wiki.openstack.org/wiki/Mistral#Tasks_Scheduling_-_Cloud_Cron can handle. * Give someone 100 CPU hours per time period of quota. Support quotas by overall usage not current usage. This sounds like something that each service should support natively. * Reserved Volume: Not sure how that works. * Virtual Private Cloud. It would be great to see OpenStack support a hardware isolated virtual private cloud, but not sure what the best way to implement that is. * Capacity Planning. Sure, but it would be nice to see a more fleshed out story for it. It would be nice to see more of these use cases discussed. On Mon, Mar 3, 2014 at 11:16 AM, Joe Gordon joe.gord...@gmail.com wrote: On Mon, Mar 3, 2014 at 10:43 AM, Sean Dague s...@dague.net wrote: On 03/03/2014 01:35 PM, Joe Gordon wrote: On Mon, Mar 3, 2014 at 10:01 AM, Zane Bitter zbit...@redhat.com wrote: On 03/03/14 12:32, Joe Gordon wrote: - if you're reserving resources far before you'll need them, it'll be cheaper Why? How does this save a provider money? If an operator has zero information about the level of future demand, they will have to spend a *lot* of money on excess capacity or risk running out. If an operator has perfect information about future demand, then they need spend no money on excess capacity. Everywhere in between, the amount of extra money they need to spend is a non-increasing function of the amount of information they have. QED. Sure. if an operator has perfect information about future demand they won't need any excess capacity. But assuming you know some future demand, how do you figure out how much of the future demand you know? But sure I can see this as a potential money saver, but unclear by how much. The Amazon model for this is a reservation is at minimum a year, I am not sure how useful short term reservations would be in determining future demand. There are other useful things with reservations though. In a private context the classic one is running number for close of business. Or software team that's working towards a release might want to preallocate resources for longer scale runs during a particular week. Why can't they pre-allocate now? Reservation can really be about global policy giving some tenants more priority in getting resources than others (because you pre-allocate them). I also know that with a lot of the HPC teams using OpenStack, this is a fundamental part of scheduling. Not just the when, but the how long. Having systems automatically get reaped after a certain amount of time is something they very much want. Agreed, I think this should either be part of Nova or Heat directly. So I think the general idea have merrit. I just think we need to make sure it integrates well with the rest of OpenStack, which I believe means strong coupling to the scheduler. -Sean -- Sean Dague Samsung Research America s...@dague.net / sean.da...@samsung.com http://dague.net ___ OpenStack-dev mailing list 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] Climate Incubation Application
On Sun, Mar 2, 2014 at 11:32 AM, Dina Belova dbel...@mirantis.com wrote: Hello, folks! I'd like to request Climate project review for incubation. Here is official incubation application: https://wiki.openstack.org/wiki/Climate/Incubation I'm unclear on what Climate is trying to solve. I read the 'Detailed Description' from the link above, and it states Climate is trying to solve two uses cases (and the more generalized cases of those). 1) Compute host reservation (when user with admin privileges can reserve hardware resources that are dedicated to the sole use of a tenant) 2) Virtual machine (instance) reservation (when user may ask reservation service to provide him working VM not necessary now, but also in the future) You want to support being able to reserve an instance in the future. As a cloud operator how do I take advantage of that information? As a cloud consumer, what is the benefit? Today OpenStack supports both uses cases, except it can't request an Instance for the future. Additionally due to the project scope and the roadmap, we don't see any currently existing OpenStack program that fits Climate. So we've prepared new program request too: https://wiki.openstack.org/wiki/Climate/Program TL;DR Our team is working on providing OpenStack with resource reservation opportunity in time-based manner, including close integration with all other OS projects. As Climate initiative is targeting to provide not only compute resources revervation, but also volumes, network resources, storage nodes reservation opportunity, we consider it is not about being a part of some existing OpenStack program. This initiative needs to become a part of completely new Resource Reservation Program, that aims to implement time-based cloud resource management. Thanks! Best regards, Dina Belova Climate Technical Lead Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list 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
