On 10/9/13 6:53 AM, Mike Spreitzer wrote:
Yes, that helps. Please, guys, do not interpret my questions as
hostility, I really am just trying to understand. I think there is
some overlap between your concerns and mine, and I hope we can work
together.
No probs at all. Don't see a sign of hostility at all. Potential
collaboration and understanding is really how we perceive your questions...
Sticking to the physical reservations for the moment, let me ask for a
little more explicit details. In your outline below, late in the game
you write "the actual reservation is performed by the lease manager
plugin". Is that the point in time when something (the lease manager
plugin, in fact) decides which hosts will be used to satisfy the
reservation?
Yes. The reservation service should return only a Pcloud uuid that is
empty. The description of host capabilities and extra-specs is only
defined as metadata of the Pcloud at this point.
Or is that decided up-front when the reservation is made? I do not
understand how the lease manager plugin can make this decision on its
own, isn't the nova scheduler also deciding how to use hosts? Why
isn't there a problem due to two independent allocators making
allocations of the same resources (the system's hosts)?
The way we are designing it excludes race conditions between Nova
scheduler and the lease manager plugin for host reservations because the
lease manager plugin will use a private pool of hosts for reservation
(reservation pool) that is not shared with Nova scheduler. In our view,
this is not a convenience design artifact but a purpose. It is because
what we'd like to achieve really is energy efficiency management based
on a reservation backlog and possibly dynamic management of host
resources between the reservation pool and the multi-tenant pool. A
Climate scheduler filter in Nova will do the triage filtering out those
hosts that belong to the reservation pool and hosts that are reserved in
an active lease. Another (longer term) goal behind this (was actually
the primary justification for the reservation pool) is that the lease
manager plugin could turn machines off to save electricity when the
reservation backlog allows to do so and consequently turn them back on
when a lease kicks in if that's needed. We anticipate that the resource
management algorithms / heuristics behind that behavior is non-trivial
but we believe that it would be hardly achievable without a reservation
backlog and some form of capacity management capabilities left open to
the provider. In particular, things become much trickier when it to
comes decide what to do with the reserved hosts when a lease ends. We
foresee few options:
1) Forcibly kill the instances running on reserved hosts and move them
back to the reservation pool for the next lease to come
2) Keep the instances running on the reserved hosts and move them to an
intermediary "recycling pool" until all the instances die at which point
in time those hosts that are released from duty can return to the
reservation pool. Case 1 and 2 could optionally be augmented by a grace
period
3) Keep the instances running on the reserved hosts and move them to the
multi-tenant pool. Then, it'll be up to the operator to repopulate the
reservation pool using free hosts. Would require administrative tasks
like disabling hosts, instance migrations, ... in other words certainly
a pain if not fully automated.
So, you noticed that all this relies very much on manipulating hosts
aggregates, metadata and filtering behind the scene. That's one way of
implementing the whole-host-reservation feature based on the tools we
have at our disposable today. A substantial refactoring of Nova and
scheduler could/should be a better way to go? Is it worth it? We don't
know. We anyway have zero visibility on that.
HTH,
Patrick
Thanks,
Mike
Patrick Petit <[email protected]> wrote on 10/07/2013 07:02:36 AM:
> Hi Mike,
>
> There are actually more facets to this. Sorry if it's a little
> confusing :-( Climate's original blueprint https://
> wiki.openstack.org/wiki/Blueprint-nova-planned-resource-reservation-api
> was about physical host reservation only. The typical use case
> being: "I want to reserve x number of hosts that match the
> capabilities expressed in the reservation request". The lease is
> populated with reservations which at this point are only capacity
> descriptors. The reservation becomes active only when the lease
> starts at a specified time and for a specified duration. The lease
> manager plugin in charge of the physical reservation has a planning
> of reservations that allows Climate to grant a lease only if the
> requested capacity is available at that time. Once the lease becomes
> active, the user can request instances to be created on the reserved
> hosts using a lease handle as a Nova's scheduler hint. That's
> basically it. We do not assume or enforce how and by whom (Nova,
> Heat ,...) a resource instantiation is performed. In other words, a
> host reservation is like a whole host allocation https://
> wiki.openstack.org/wiki/WholeHostAllocation that is reserved ahead
> of time by a tenant in anticipation of some workloads that is bound
> to happen in the future. Note that while we are primarily targeting
> hosts reservations the same service should be offered for storage.
> Now, Mirantis brought in a slew of new use cases that are targeted
> toward virtual resource reservation as explained earlier by Dina.
> While architecturally both reservation schemes (physical vs virtual)
> leverage common components, it is important to understand that they
> behave differently. For example, Climate exposes an API for the
> physical resource reservation that the virtual resource reservation
> doesn't. That's because virtual resources are supposed to be already
> reserved (through some yet to be created Nova, Heat, Cinder,...
> extensions) when the lease is created. Things work differently for
> the physical resource reservation in that the actual reservation is
> performed by the lease manager plugin not before the lease is
> created but when the lease becomes active (or some time before
> depending on the provisioning lead time) and released when the lease
ends.
> HTH clarifying things.
> BR,
> Patrick
--
Patrick Petit
Cloud Computing Principal Architect, Innovative Products
Bull, Architect of an Open World TM
Tél : +33 (0)4 76 29 70 31
Mobile : +33 (0)6 85 22 06 39
http://www.bull.com
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
