[openstack-dev] [climate] Mirantis proposal to extend Climate to support virtual resources reservation
dbelova at mirantis.com
Mon Aug 5 13:19:05 UTC 2013
Patrick, Julien, thank you so much for your comments. As for the moments
Patrick mentioned in his letter, I'll describe our vision for them below.
1) Patrick, thank you for the idea! I think it would be great to add not
only 'post-lease actions policy', but also 'start-lease actions policy'. I
mean like having two types of what can be done with resource (virtual one)
on lease starting - 'start VM automatically' or 'start VM manually'. This
means user may not use reserved resources at all, if he needs such a
2) We really believe that creating lease first, and going with its id to
all the OpenStack projects to use is a better idea than 'filling' the lease
with resources just at the moment of its creation. I'll try to explain why.
First of all, as for virtual reservations, we'll need to proxy Nova,
Cinder, etc. APIs through Reservation API to reserve VM or volume or
something else. Workflow for VM/volume/etc. creation is really complicated
and only services written to do this have to do it, in our opinion. Second,
this makes adding new reservations to the created lease simple and user
friendly. And the last moment, we should not copy all these dashboard pages
for instance/volume/... creation to the reservation Dashboard tab in this
case. As for the physical reservations, as you mentioned, there is no way
to 'create' them like virtual resources in the Nova's, for example, API
now. That's why there are two ways to solve this problem and reserve them.
First way is to reserve them from Reservation Service as it is implemented
now and described also in our document (WF-2b part of it). The second
variant (that seems to be more elegant, but more complicated as well) is to
implement needed parts as Nova API extension to let Nova do the things it
does the best way - managing hosts, VMs, etc. Our concern in this question
is not doing things Nova (or any other service) can do much better.
3) We completely agree with you! Our 'nested reservation' vision was
created only to let user the opportunity of checking reservation status of
complex virtual resources (stacks) by having an opportunity to check status
of all its 'nested' components, like VMs, networks, etc. This can be done
as well by using just Heat without reservation service. Now we are thinking
about reservation as the reservation of the OpenStack resource that has ID
in the OpenStack service DB, no matter how complex it is (VM, network,
floating IP, stack, etc.)
4) We were thinking about Reservation Scheduler as a service that controls
lease life cycle (starting, ending, making user notifications, etc.) and
communicates with Reservation Manager via RPC. Reservation Manager can send
user notifications about close lease ending using Ceilometer (this question
has to be researched). As for the time needed to run physical reservation
or complex virtual one, that is used to make preparations and settings, I
think it would be better for user to amortise it in lease using period,
because for physical resources it much depends on hardware resources and
for virtual ones - on hardware, network and geo location of DCs.
On Mon, Aug 5, 2013 at 1:22 PM, Julien Danjou <julien at danjou.info> wrote:
> On Fri, Aug 02 2013, Patrick Petit wrote:
> > 3. The proposal specifies that a lease can contain a combo of different
> > resources types reservations (instances, volumes, hosts, Heat
> > stacks, ...) that can even be nested and that the reservation
> > service will somehow orchestrate their deployment when the lease
> > kicks in. In my opinion, many use cases (at least ours) do not
> > warrant for that level of complexity and so, if that's something
> > that is need to support your use cases, then it should be delivered
> > as module that can be loaded optionally in the system. Our preferred
> > approach is to use Heat for deployment orchestration.
> I agree that this is not something Climate should be in charge. If the
> user wants to reserve a set of services and deploys them automatically,
> Climate should provide the lease and Heat the deployment orchestration.
> Also, for example, it may be good to be able to reserve automatically
> the right amount of resources needed to deploy a Heat stack via Climate.
> Julien Danjou
> // Free Software hacker / freelance consultant
> // http://julien.danjou.info
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev