Open Stack

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 <mspreitz at us.ibm.com> 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
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 

Best regards,

Dina Belova

Software Engineer

Mirantis Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131006/890b61e7/attachment.html>