Hello, Mike! As for Nova connected thoughts, it was just a reference to the Roadmap, that includes implementing the reservations opportunity first of all for the solid virtual resources (VMs, volumes, …) and next for the complex ones (Heat stacks, Savanna clusters, …). To implement complex reservations we need implementation of the simple ones.
Climate will be the independent service, that will the the underlaying layer for other OpenStack services wishing not just start some virtual resource, but reserve it for the future with different policies. We assume the following reservation process for the OpenStack services: 1) User goes to service and and does all actions as usual only passing his/her wish to reserve resource, not really start it. 2) Service does all the usual actions, but not really starts resource. Instead of that is uses Climate to create lease and then Climate decides what events should happen to the lease - start, end, send notification about some event and so on. We were thinking about leases of resources from different services for the first time, but here we found some logical problem - nobody really needs just VM, just volume and just floating IP. To work together, volume should be attached to VM and IP should be assigned too. But this is just the thing that Heat does. That's why now we are thinking of lease as reserving the resources from one service - to reserve VM+volume+IP using Heat will be the better idea I suppose. As for scheduling part, in our current scheme we'll use services' schedulers cause now they do their work in the best way. That's why Climate now looks as the underlaying service, not the upper one. That way provides the opportunity to use all capabilities of existing services and do not proxy all the resource-creation preparations and calls when user really ants to reserve something. Also I think we do not really understand each other in the question of how any OpenStack service and Climate may use each other. We were thinking that any service goes to Climate to create lease with already existing resources IDs in services' DB. In Nova case it looks like Nova schedules VM, creates in DB instance with the 'RESERVED' status and then sends Climate lease creation request. And then Climate uses its internal schedule to do all the actions with that resource defined by plugin for the lease start/end. In this view nobody except Climate really owns lease with all the reservations. But I see you have some other view on how that process may look like. Although it was not the idea we were thinking about for the Climate. As for we were thinking about service->Climate workflow, service already will mark 'RESERVED' resource in its DB when it'll send lease creation request to the Climate. That's why that backing capacity will be already used by service and mentioned in the further scheduling process. Now we'll reserve resource right at the moment of lease creation, that means it's more useful for the not so far future. But also we are thinking to implement the opportunity of not only the immediate resources reservation, but that is questionable. Thank you, Dina On Sun, Oct 6, 2013 at 10:36 AM, Mike Spreitzer <[email protected]> wrote: > I looked at the blueprint ( > https://blueprints.launchpad.net/heat/+spec/stacks-reservation) and > associated wiki page (https://wiki.openstack.org/wiki/Heat/Reservation), > and I have a few comments/questions. > > The wiki page has some remarks that are Nova-centric, and some other > remarks that emphasize that Climate is not just about Nova, and I do not > understand the relationship between these remarks. Is this a roadmapping > thought (start with just Nova, expand to other services later), or the > inclusion of some details (related to Nova) and omission of other similar > details (related to the other services), or what? > > Will Climate be an independent service, or part of Nova, or what? > > What will be the atomic operations? I presume the primary interesting > operation will be something like reserving a bag of resources, where that > bag is allowed to contain any mixture of resources from any services. Have > I got that right? > > What exactly does reserving a resource mean? Does this atomic reservation > operation include some atomic cooperation from the resources' services' > schedulers (e.g., Nova scheduler, Cinder scheduler, etc)? Or is this > reservation service logically independent of the resources' primary > schedulers? Overall I am getting the suggestion that reservation is an > independent service. The flow is something like first reserve a bag of > resources, and then proceed to use them at your leisure. But I also > suppose that the important thing about a reservation is that it includes > the result of scheduling (placement) --- the point of a reservation is that > it is holding capacity to host the reserved resources. You do not want an > atomic operation to take a long time; do the scheduling decisions get made > (tentatively, of course) before the real atomic section, with re-schedule > and re-try on conflict detection, or is scheduling included in the atomic > section? > > For how long does a reservation last? What sort of thing owns a > reservation? I suppose one important use case is that a heat engine, or > the heat service (in the multi-engine world), could own a reservation; in > this use case, the reservation would last until heat releases it. > Hopefully heat will persist its reservation information, so that a process > crash will not cause a dangling reservation; how will you enable complete > avoidance of timing splinters (e.g., heat engine crashes after making > reservation but before persisting information about it)? Presumably other > things besides heat could own reservations. > > Is this primarily about planning for the distant future, or focused on the > immediate future? If a bag of resources (including their backing > capacities) is reserved for a period that starts more than a little while > in the future, what is done with that backing capacity in the meantime? > > I see use cases for immediate future reservations; do you have use cases > for more distant reservations? > > Thanks, > Mike > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Best regards, Dina Belova Software Engineer Mirantis Inc.
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
