Re: [openstack-dev] [climate] Mirantis proposal to extend Climate to support virtual resources reservation

[Dina Belova]

Patrick, I had an opportunity to take just a quick look on Haizea project
(only ideas of it and some common things). Actually we had not so much time
to investigate it in better way, so we'll do it this week.


On Tue, Aug 13, 2013 at 5:50 PM, Patrick Petit wrote:

>  Hi Dina,
> Sounds great! Speaking on behalf of Francois feel free to proceed with
> points below. I don't think he would have issues with that. We'll close the
> loop when he returns. BTW, did you get a chance to take a look at Haizea's
> design and implementation?
> Thanks
> Patrick
> On 8/13/13 3:08 PM, Dina Belova wrote:
>
>  Patrick, we are really glad we've found the way to deal with both use
> cases.
>
>
>  As for your patches, that are on review and were already merged, we are
> thinking about the following actions to commit:
>
>
>  1) Oslo was merged, but it is a little bit old verdant (with setup and
> version module, that are not really used now because of new per project).
> So we (Mirantis) can update it as a first step.
>
>  2) We need to implement comfortable to use DB layer to allow using of
> different DB types (SQL and NoSQL as well), so that's the second step. Here
> we'll also create new abstractions like lease and physical or virtual
> reservations (I think we can implement it really before end of August).
>
>
>  3) After that we'll have the opportunity to modify Francois' patches for
> the physical hosts reservation in the way to be a part of our new common
> vision together.
>
>
>  Thank you.
>
>
> On Tue, Aug 13, 2013 at 4:23 PM, Patrick Petit wrote:
>
>>  Hi Nikolay,
>> Please see comments inline.
>> Thanks
>> Patrick
>>
>> On 8/12/13 5:28 PM, Nikolay Starodubtsev wrote:
>>
>>  Hi, again!
>>
>>  Partick, I’ll try to explain why do we belive in some base actions like
>> instance starting/deleting in Climate. We are thinking about the following
>> workflow (that will be quite comfortable and user friendly, and now we have
>> more than one customer who really want it):
>>
>>  1) User goes to the OpenStack dashboard and asks Heat to reserve
>> several stacks.
>>
>>  2) Heat goes to the Climate and creates all needed leases. Also Heat
>> reserves all resources for these stacks.
>>
>>  3) When time comes, user goes to the OpenStack cloud and here we think
>> he wants to see already working stacks (ideal version) or (at least)
>> already started. If no, user will have to go to the Dashboard and wake up
>> all the stacks he or she reserved. This means several actions, that may be
>> done for the user automatically, because it will be needed to do them no
>> matter what is the aim for these stacks - if user reserves them, he / she
>> needs them.
>>
>>  We understand, that there are situations when these actions may be done
>> by some other system (like some hypothetical Jenkins). But if we speak
>> about users, this will be useful. We also understand that this default way
>> of behavior should be implemented in some kind of long term life cycle
>> management system (which is not Heat), but we have no one in the OpenStack
>> now. Because the best may to implement it is to use Convection, that is
>> only proposal now...
>>
>>  That’s why we think that for the behavior like “user just reserves
>> resources and then does anything he / she wants to” physical leases are
>> better variant, when user may reserve several nodes and use it in different
>> ways. For the virtual reservations it will be better to start / delete them
>> as a default way (for something unusual Heat may be used and modified).
>>
>>  Okay. So let's bootstrap it this way then. There will be two different
>> ways the reservation service will deal with reservations depending on
>> whether its physical or virtual. All things being equal, future will tell
>> how things settle. We will focus on the physical host reservation side of
>> things. It think having this contradictory debate helped to understand each
>> others use cases and requirements that the initial design has to cope with.
>> Francois who already submitted a bunch of code for review will not return
>> from vacation until the end of August. So things on our side are a little
>> on the standby until he returns but it might help if you could take a look
>> at it. I suggest you start with your vision and we will iterate from there.
>> Is that okay with you?
>>
>>
>>
>>  Do you think that this workflow is useful too and if so can you propose
>> another implementation  variant for it?
>>
>>  Thank you.
>>
>>
>>
>>  On Mon, Aug 12, 2013 at 1:55 PM, Patrick Petit 
>> wrote:
>>
>>>  On 8/9/13 3:05 PM, Nikolay Starodubtsev wrote:
>>>
>>> Hello, Patrick!
>>>
>>> We have several reasons to think that for the virtual resources this
>>> possibility is interesting. If we speak about physical resources, user may
>>> use them in the different ways, that's why it is impossible to include base
>>> actions with them to the reservation service. But speaking about virtual
>>> reservations, let's imagine user wants to reserve 

Re: [openstack-dev] [climate] Mirantis proposal to extend Climate to support virtual resources reservation

[Patrick Petit]

Hi Dina,
Sounds great! Speaking on behalf of Francois feel free to proceed with 
points below. I don't think he would have issues with that. We'll close 
the loop when he returns. BTW, did you get a chance to take a look at 
Haizea's design and implementation?

Thanks
Patrick
On 8/13/13 3:08 PM, Dina Belova wrote:


Patrick, we are really glad we've found the way to deal with both use 
cases.



As for your patches, that are on review and were already merged, we 
are thinking about the following actions to commit:



1) Oslo was merged, but it is a little bit old verdant (with setup and 
version module, that are not really used now because of new per 
project). So we (Mirantis) can update it as a first step.


2) We need to implement comfortable to use DB layer to allow using of 
different DB types (SQL and NoSQL as well), so that's the second step. 
Here we'll also create new abstractions like lease and physical or 
virtual reservations (I think we can implement it really before end of 
August).



3) After that we'll have the opportunity to modify Francois' patches 
for the physical hosts reservation in the way to be a part of our new 
common vision together.



Thank you.



On Tue, Aug 13, 2013 at 4:23 PM, Patrick Petit > wrote:


Hi Nikolay,
Please see comments inline.
Thanks
Patrick

On 8/12/13 5:28 PM, Nikolay Starodubtsev wrote:


Hi, again!


Partick, I'll try to explain why do we belive in some base
actions like instance starting/deleting in Climate. We are
thinking about the following workflow (that will be quite
comfortable and user friendly, and now we have more than one
customer who really want it):


1) User goes to the OpenStack dashboard and asks Heat to reserve
several stacks.


2) Heat goes to the Climate and creates all needed leases. Also
Heat reserves all resources for these stacks.


3) When time comes, user goes to the OpenStack cloud and here we
think he wants to see already working stacks (ideal version) or
(at least) already started. If no, user will have to go to the
Dashboard and wake up all the stacks he or she reserved. This
means several actions, that may be done for the user
automatically, because it will be needed to do them no matter
what is the aim for these stacks - if user reserves them, he /
she needs them.


We understand, that there are situations when these actions may
be done by some other system (like some hypothetical Jenkins).
But if we speak about users, this will be useful. We also
understand that this default way of behavior should be
implemented in some kind of long term life cycle management
system (which is not Heat), but we have no one in the OpenStack
now. Because the best may to implement it is to use Convection,
that is only proposal now...


That's why we think that for the behavior like "user just
reserves resources and then does anything he / she wants to"
physical leases are better variant, when user may reserve several
nodes and use it in different ways. For the virtual reservations
it will be better to start / delete them as a default way (for
something unusual Heat may be used and modified).


Okay. So let's bootstrap it this way then. There will be two
different ways the reservation service will deal with reservations
depending on whether its physical or virtual. All things being
equal, future will tell how things settle. We will focus on the
physical host reservation side of things. It think having this
contradictory debate helped to understand each others use cases
and requirements that the initial design has to cope with.
Francois who already submitted a bunch of code for review will not
return from vacation until the end of August. So things on our
side are a little on the standby until he returns but it might
help if you could take a look at it. I suggest you start with your
vision and we will iterate from there. Is that okay with you?




Do you think that this workflow is useful too and if so can you
propose another implementation  variant for it?


Thank you.




On Mon, Aug 12, 2013 at 1:55 PM, Patrick Petit
mailto:patrick.pe...@bull.net>> wrote:

On 8/9/13 3:05 PM, Nikolay Starodubtsev wrote:

Hello, Patrick!

We have several reasons to think that for the virtual
resources this possibility is interesting. If we speak about
physical resources, user may use them in the different ways,
that's why it is impossible to include base actions with
them to the reservation service. But speaking about virtual
reservations, let's imagine user wants to reserve virtual
machine. He knows everything about it - its parameters,
flavor and time to be leased for. Really, in this case user
wants to have already working (or at

Re: [openstack-dev] [climate] Mirantis proposal to extend Climate to support virtual resources reservation

[Dina Belova]

Patrick, we are really glad we've found the way to deal with both use cases.


As for your patches, that are on review and were already merged, we are
thinking about the following actions to commit:


1) Oslo was merged, but it is a little bit old verdant (with setup and
version module, that are not really used now because of new per project).
So we (Mirantis) can update it as a first step.


2) We need to implement comfortable to use DB layer to allow using of
different DB types (SQL and NoSQL as well), so that's the second step. Here
we'll also create new abstractions like lease and physical or virtual
reservations (I think we can implement it really before end of August).


3) After that we'll have the opportunity to modify Francois' patches for
the physical hosts reservation in the way to be a part of our new common
vision together.


Thank you.


On Tue, Aug 13, 2013 at 4:23 PM, Patrick Petit wrote:

>  Hi Nikolay,
> Please see comments inline.
> Thanks
> Patrick
>
> On 8/12/13 5:28 PM, Nikolay Starodubtsev wrote:
>
>  Hi, again!
>
>  Partick, I’ll try to explain why do we belive in some base actions like
> instance starting/deleting in Climate. We are thinking about the following
> workflow (that will be quite comfortable and user friendly, and now we have
> more than one customer who really want it):
>
>  1) User goes to the OpenStack dashboard and asks Heat to reserve several
> stacks.
>
>  2) Heat goes to the Climate and creates all needed leases. Also Heat
> reserves all resources for these stacks.
>
>  3) When time comes, user goes to the OpenStack cloud and here we think
> he wants to see already working stacks (ideal version) or (at least)
> already started. If no, user will have to go to the Dashboard and wake up
> all the stacks he or she reserved. This means several actions, that may be
> done for the user automatically, because it will be needed to do them no
> matter what is the aim for these stacks - if user reserves them, he / she
> needs them.
>
>  We understand, that there are situations when these actions may be done
> by some other system (like some hypothetical Jenkins). But if we speak
> about users, this will be useful. We also understand that this default way
> of behavior should be implemented in some kind of long term life cycle
> management system (which is not Heat), but we have no one in the OpenStack
> now. Because the best may to implement it is to use Convection, that is
> only proposal now...
>
>  That’s why we think that for the behavior like “user just reserves
> resources and then does anything he / she wants to” physical leases are
> better variant, when user may reserve several nodes and use it in different
> ways. For the virtual reservations it will be better to start / delete them
> as a default way (for something unusual Heat may be used and modified).
>
> Okay. So let's bootstrap it this way then. There will be two different
> ways the reservation service will deal with reservations depending on
> whether its physical or virtual. All things being equal, future will tell
> how things settle. We will focus on the physical host reservation side of
> things. It think having this contradictory debate helped to understand each
> others use cases and requirements that the initial design has to cope with.
> Francois who already submitted a bunch of code for review will not return
> from vacation until the end of August. So things on our side are a little
> on the standby until he returns but it might help if you could take a look
> at it. I suggest you start with your vision and we will iterate from there.
> Is that okay with you?
>
>
>
>  Do you think that this workflow is useful too and if so can you propose
> another implementation  variant for it?
>
>  Thank you.
>
>
>
>  On Mon, Aug 12, 2013 at 1:55 PM, Patrick Petit wrote:
>
>>  On 8/9/13 3:05 PM, Nikolay Starodubtsev wrote:
>>
>> Hello, Patrick!
>>
>> We have several reasons to think that for the virtual resources this
>> possibility is interesting. If we speak about physical resources, user may
>> use them in the different ways, that's why it is impossible to include base
>> actions with them to the reservation service. But speaking about virtual
>> reservations, let's imagine user wants to reserve virtual machine. He knows
>> everything about it - its parameters, flavor and time to be leased for.
>> Really, in this case user wants to have already working (or at least
>> starting to work) reserved virtual machine and it would be great to include
>> this opportunity to the reservation service.
>>
>>  We are thinking about base actions for the virtual reservations that
>> will be supported by Climate, like boot/delete for instance, create/delete
>> for volume and create/delete for the stacks. The same will be with volumes,
>> IPs, etc. As for more complicated behaviour, it may be implemented in Heat.
>> This will make reservations simpler to use for the end users.
>>
>> Don't you think so?
>>
>>  Well yes and an

Re: [openstack-dev] [climate] Mirantis proposal to extend Climate to support virtual resources reservation

[Patrick Petit]

Hi Nikolay,
Please see comments inline.
Thanks
Patrick
On 8/12/13 5:28 PM, Nikolay Starodubtsev wrote:


Hi, again!


Partick, I’ll try to explain why do we belive in some base actions 
like instance starting/deleting in Climate. We are thinking about the 
following workflow (that will be quite comfortable and user friendly, 
and now we have more than one customer who really want it):



1) User goes to the OpenStack dashboard and asks Heat to reserve 
several stacks.



2) Heat goes to the Climate and creates all needed leases. Also Heat 
reserves all resources for these stacks.



3) When time comes, user goes to the OpenStack cloud and here we think 
he wants to see already working stacks (ideal version) or (at least) 
already started. If no, user will have to go to the Dashboard and wake 
up all the stacks he or she reserved. This means several actions, that 
may be done for the user automatically, because it will be needed to 
do them no matter what is the aim for these stacks - if user reserves 
them, he / she needs them.



We understand, that there are situations when these actions may be 
done by some other system (like some hypothetical Jenkins). But if we 
speak about users, this will be useful. We also understand that this 
default way of behavior should be implemented in some kind of long 
term life cycle management system (which is not Heat), but we have no 
one in the OpenStack now. Because the best may to implement it is to 
use Convection, that is only proposal now...



That’s why we think that for the behavior like “user just reserves 
resources and then does anything he / she wants to” physical leases 
are better variant, when user may reserve several nodes and use it in 
different ways. For the virtual reservations it will be better to 
start / delete them as a default way (for something unusual Heat may 
be used and modified).


Okay. So let's bootstrap it this way then. There will be two different 
ways the reservation service will deal with reservations depending on 
whether its physical or virtual. All things being equal, future will 
tell how things settle. We will focus on the physical host reservation 
side of things. It think having this contradictory debate helped to 
understand each others use cases and requirements that the initial 
design has to cope with. Francois who already submitted a bunch of code 
for review will not return from vacation until the end of August. So 
things on our side are a little on the standby until he returns but it 
might help if you could take a look at it. I suggest you start with your 
vision and we will iterate from there. Is that okay with you?




Do you think that this workflow is useful too and if so can you 
propose another implementation  variant for it?



Thank you.




On Mon, Aug 12, 2013 at 1:55 PM, Patrick Petit > wrote:


On 8/9/13 3:05 PM, Nikolay Starodubtsev wrote:

Hello, Patrick!

We have several reasons to think that for the virtual resources
this possibility is interesting. If we speak about physical
resources, user may use them in the different ways, that's why it
is impossible to include base actions with them to the
reservation service. But speaking about virtual reservations,
let's imagine user wants to reserve virtual machine. He knows
everything about it - its parameters, flavor and time to be
leased for. Really, in this case user wants to have already
working (or at least starting to work) reserved virtual machine
and it would be great to include this opportunity to the
reservation service.
We are thinking about base actions for the virtual reservations
that will be supported by Climate, like boot/delete for instance,
create/delete for volume and create/delete for the stacks. The
same will be with volumes, IPs, etc. As for more complicated
behaviour, it may be implemented in Heat. This will make
reservations simpler to use for the end users.

Don't you think so?

Well yes and and no. It really depends upon what you put behind
those lease actions. The view I am trying to sustain is separation
of duties to keep the service simple, ubiquitous and non
prescriptive of a certain kind of usage pattern. In other words,
keep Climate for reservation of capacity (physical or virtual),
Heat for orchestration, and so forth. ... Consider for example the
case of reservation as a non technical act but rather as a
business enabler for wholesales activities. Don't need, and
probably don't want to start or stop any resource there. I do not
deny that there are cases where it is desirable but then how
reservations are used and composed together at the end of the day
mainly depends on exogenous factors which couldn't be anticipated
because they are driven by the business.

And so, rather than coupling reservations with wired resource
instantiation actions, I would rathe

Re: [openstack-dev] [climate] Mirantis proposal to extend Climate to support virtual resources reservation

[Nikolay Starodubtsev]

Hi, again!

Partick, I’ll try to explain why do we belive in some base actions like
instance starting/deleting in Climate. We are thinking about the following
workflow (that will be quite comfortable and user friendly, and now we have
more than one customer who really want it):

1) User goes to the OpenStack dashboard and asks Heat to reserve several
stacks.

2) Heat goes to the Climate and creates all needed leases. Also Heat
reserves all resources for these stacks.

3) When time comes, user goes to the OpenStack cloud and here we think he
wants to see already working stacks (ideal version) or (at least) already
started. If no, user will have to go to the Dashboard and wake up all the
stacks he or she reserved. This means several actions, that may be done for
the user automatically, because it will be needed to do them no matter what
is the aim for these stacks - if user reserves them, he / she needs them.

We understand, that there are situations when these actions may be done by
some other system (like some hypothetical Jenkins). But if we speak about
users, this will be useful. We also understand that this default way of
behavior should be implemented in some kind of long term life cycle
management system (which is not Heat), but we have no one in the OpenStack
now. Because the best may to implement it is to use Convection, that is
only proposal now...

That’s why we think that for the behavior like “user just reserves
resources and then does anything he / she wants to” physical leases are
better variant, when user may reserve several nodes and use it in different
ways. For the virtual reservations it will be better to start / delete them
as a default way (for something unusual Heat may be used and modified).

Do you think that this workflow is useful too and if so can you propose
another implementation  variant for it?

Thank you.



On Mon, Aug 12, 2013 at 1:55 PM, Patrick Petit wrote:

>  On 8/9/13 3:05 PM, Nikolay Starodubtsev wrote:
>
> Hello, Patrick!
>
> We have several reasons to think that for the virtual resources this
> possibility is interesting. If we speak about physical resources, user may
> use them in the different ways, that's why it is impossible to include base
> actions with them to the reservation service. But speaking about virtual
> reservations, let's imagine user wants to reserve virtual machine. He knows
> everything about it - its parameters, flavor and time to be leased for.
> Really, in this case user wants to have already working (or at least
> starting to work) reserved virtual machine and it would be great to include
> this opportunity to the reservation service.
>
>  We are thinking about base actions for the virtual reservations that
> will be supported by Climate, like boot/delete for instance, create/delete
> for volume and create/delete for the stacks. The same will be with volumes,
> IPs, etc. As for more complicated behaviour, it may be implemented in Heat.
> This will make reservations simpler to use for the end users.
>
> Don't you think so?
>
> Well yes and and no. It really depends upon what you put behind those
> lease actions. The view I am trying to sustain is separation of duties to
> keep the service simple, ubiquitous and non prescriptive of a certain kind
> of usage pattern. In other words, keep Climate for reservation of capacity
> (physical or virtual), Heat for orchestration, and so forth. ... Consider
> for example the case of reservation as a non technical act but rather as a
> business enabler for wholesales activities. Don't need, and probably don't
> want to start or stop any resource there. I do not deny that there are
> cases where it is desirable but then how reservations are used and composed
> together at the end of the day mainly depends on exogenous factors which
> couldn't be anticipated because they are driven by the business.
>
> And so, rather than coupling reservations with wired resource
> instantiation actions, I would rather couple them with notifications that
> everybody can subscribe to (as opposed to the Resource Manager only) which
> would let users decide what to do with the life-cycle events. The what to
> do may very well be what you advocate i.e. start a full stack of reserved
> and interwoven resources, or at the other end of the spectrum, do nothing
> at all. This approach IMO would keep things more open.
>
>
> P.S. Also we remember about the problem you mentioned some letters ago -
> how to guarantee that user will have already working and prepared host / VM
> / stack / etc. by the time lease actually starts, no just "lease begins and
> preparing process begins too". We are working on it now.
>
> Yes. I think I was explicitly referring to hosts instantiation also
> because there is no support of that in Nova API. Climate should support
> some kind of "reservation kick-in heads-up" notification whereby the
> provider and/or some automated provisioning tools could do the heavy
> lifting work of bringing physical hosts on

Re: [openstack-dev] [climate] Mirantis proposal to extend Climate to support virtual resources reservation

[Patrick Petit]

On 8/9/13 9:06 PM, Scott Devoid wrote:

Hi Nikolay and Patrick, thanks for your replies.

Virtual vs. Physical Resources
Ok, now I realize what you meant by "virtual resources," e.g. 
instances, volumes, networks...resources provided by existing 
OpenStack schedulers. In this case "physical resources" are actually 
more "removed" since there are no interfaces to them in the user-level 
OpenStack APIs. If you make a physical reservation on "this rack of 
machines right here", how do you supply this reservation information 
to nova-scheduler? Probably via scheduler hints + an availability zone 
or host-aggregates. At which point you're really defining a instance 
reservation that includes explicit scheduler hints. Am I missing 
something?


Hi Scott!
No, you don't. At least, it's how I see things working for hosts 
reservation. In fact, it is already partially addressed in Havana with 
https://wiki.openstack.org/wiki/WholeHostAllocation. What's missing is 
the ability to automate the create and release of those pools based on a 
lease schedule.

Thanks
Patrick

Eviction:
Nikolay, to your point that we might evict something that was already 
paid for: in the design I have in mind, this would only happen if the 
policies set up by the operator caused one reservation to be weighted 
higher than another reservation. Maybe because one client paid more? 
The point is that this would be configurable and the sensible default 
is to not evict anything.



On Fri, Aug 9, 2013 at 8:05 AM, Nikolay Starodubtsev 
mailto:nstarodubt...@mirantis.com>> wrote:


Hello, Patrick!

We have several reasons to think that for the virtual resources
this possibility is interesting. If we speak about physical
resources, user may use them in the different ways, that's why it
is impossible to include base actions with them to the reservation
service. But speaking about virtual reservations, let's imagine
user wants to reserve virtual machine. He knows everything about
it - its parameters, flavor and time to be leased for. Really, in
this case user wants to have already working (or at least starting
to work) reserved virtual machine and it would be great to include
this opportunity to the reservation service. We are thinking about
base actions for the virtual reservations that will be supported
by Climate, like boot/delete for instance, create/delete for
volume and create/delete for the stacks. The same will be with
volumes, IPs, etc. As for more complicated behaviour, it may be
implemented in Heat. This will make reservations simpler to use
for the end users.

Don't you think so?

P.S. Also we remember about the problem you mentioned some letters
ago - how to guarantee that user will have already working and
prepared host / VM / stack / etc. by the time lease actually
starts, no just "lease begins and preparing process begins too".
We are working on it now.


On Thu, Aug 8, 2013 at 8:18 PM, Patrick Petit
mailto:patrick.pe...@bull.net>> wrote:

Hi Nikolay,

Relying on Heat for orchestration is obviously the right thing
to do. But there is still something in your design approach
that I am having difficulties to comprehend since the
beginning. Why do you keep thinking that orchestration and
reservation should be treated together? That's adding
unnecessary complexity IMHO. I just don't get it. Wouldn't it
be much simpler and sufficient to say that there are pools of
reserved resources you create through the reservation service.
Those pools could be of different types i.e. host, instance,
volume, network,.., whatever if that's really needed. Those
pools are identified by a unique id that you pass along when
the resource is created. That's it. You know, the AWS
reservation service doesn't even care about referencing a
reservation when an instance is created. The association
between the two just happens behind the scene. That would work
in all scenarios, manual, automatic, whatever... So, why do
you care so much about this in a first place?
Thanks,
Patrick

On 8/7/13 3:35 PM, Nikolay Starodubtsev wrote:

Patrick, responding to your comments:

1) Dina mentioned "start automatically" and "start manually"
only as examples of how these politics may look like. It
doesn't seem to be a correct approach to put orchestration
functionality (that belongs to Heat) in Climate. That's why
now we can implement the basics like starting Heat stack, and
for more complex actions we may later utilize something like
Convection (Task-as-a-Service) project.

2) If we agree that Heat is the main consumer of
Reservation-as-a-Service, we can agree that lease may be
created according to one of the following scenarions (b

Re: [openstack-dev] [climate] Mirantis proposal to extend Climate to support virtual resources reservation

[Patrick Petit]

On 8/9/13 3:05 PM, Nikolay Starodubtsev wrote:

Hello, Patrick!

We have several reasons to think that for the virtual resources this 
possibility is interesting. If we speak about physical resources, user 
may use them in the different ways, that's why it is impossible to 
include base actions with them to the reservation service. But 
speaking about virtual reservations, let's imagine user wants to 
reserve virtual machine. He knows everything about it - its 
parameters, flavor and time to be leased for. Really, in this case 
user wants to have already working (or at least starting to work) 
reserved virtual machine and it would be great to include this 
opportunity to the reservation service.
We are thinking about base actions for the virtual reservations that 
will be supported by Climate, like boot/delete for instance, 
create/delete for volume and create/delete for the stacks. The same 
will be with volumes, IPs, etc. As for more complicated behaviour, it 
may be implemented in Heat. This will make reservations simpler to use 
for the end users.


Don't you think so?
Well yes and and no. It really depends upon what you put behind those 
lease actions. The view I am trying to sustain is separation of duties 
to keep the service simple, ubiquitous and non prescriptive of a certain 
kind of usage pattern. In other words, keep Climate for reservation of 
capacity (physical or virtual), Heat for orchestration, and so forth. 
... Consider for example the case of reservation as a non technical act 
but rather as a business enabler for wholesales activities. Don't need, 
and probably don't want to start or stop any resource there. I do not 
deny that there are cases where it is desirable but then how 
reservations are used and composed together at the end of the day mainly 
depends on exogenous factors which couldn't be anticipated because they 
are driven by the business.


And so, rather than coupling reservations with wired resource 
instantiation actions, I would rather couple them with notifications 
that everybody can subscribe to (as opposed to the Resource Manager 
only) which would let users decide what to do with the life-cycle 
events. The what to do may very well be what you advocate i.e. start a 
full stack of reserved and interwoven resources, or at the other end of 
the spectrum, do nothing at all. This approach IMO would keep things 
more open.


P.S. Also we remember about the problem you mentioned some letters ago 
- how to guarantee that user will have already working and prepared 
host / VM / stack / etc. by the time lease actually starts, no just 
"lease begins and preparing process begins too". We are working on it now.
Yes. I think I was explicitly referring to hosts instantiation also 
because there is no support of that in Nova API. Climate should support 
some kind of "reservation kick-in heads-up" notification whereby the 
provider and/or some automated provisioning tools could do the heavy 
lifting work of bringing physical hosts online before a hosts 
reservation lease starts. I think it doesn't have to be rocket-science 
either. It's probably sufficient to make Climate fire up a notification 
that say "Lease starting in x seconds", x being an offset value against 
T0 that could be defined by the operator based on heuristics. A 
dedicated (e.g. IPMI) module of the Resource Manager for hosts 
reservation would subscribe as listener to those events.



On Thu, Aug 8, 2013 at 8:18 PM, Patrick Petit > wrote:


Hi Nikolay,

Relying on Heat for orchestration is obviously the right thing to
do. But there is still something in your design approach that I am
having difficulties to comprehend since the beginning. Why do you
keep thinking that orchestration and reservation should be treated
together? That's adding unnecessary complexity IMHO. I just don't
get it. Wouldn't it be much simpler and sufficient to say that
there are pools of reserved resources you create through the
reservation service. Those pools could be of different types i.e.
host, instance, volume, network,.., whatever if that's really
needed. Those pools are identified by a unique id that you pass
along when the resource is created. That's it. You know, the AWS
reservation service doesn't even care about referencing a
reservation when an instance is created. The association between
the two just happens behind the scene. That would work in all
scenarios, manual, automatic, whatever... So, why do you care so
much about this in a first place?
Thanks,
Patrick

On 8/7/13 3:35 PM, Nikolay Starodubtsev wrote:

Patrick, responding to your comments:

1) Dina mentioned "start automatically" and "start manually" only
as examples of how these politics may look like. It doesn't seem
to be a correct approach to put orchestration functionality (that
belongs to Heat) in Climate. That's why now we can implemen

Re: [openstack-dev] [climate] Mirantis proposal to extend Climate to support virtual resources reservation

[Scott Devoid]

Hi Nikolay and Patrick, thanks for your replies.

Virtual vs. Physical Resources
Ok, now I realize what you meant by "virtual resources," e.g. instances,
volumes, networks...resources provided by existing OpenStack schedulers. In
this case "physical resources" are actually more "removed" since there are
no interfaces to them in the user-level OpenStack APIs. If you make a
physical reservation on "this rack of machines right here", how do you
supply this reservation information to nova-scheduler? Probably via
scheduler hints + an availability zone or host-aggregates. At which point
you're really defining a instance reservation that includes explicit
scheduler hints. Am I missing something?

Eviction:
Nikolay, to your point that we might evict something that was already paid
for: in the design I have in mind, this would only happen if the policies
set up by the operator caused one reservation to be weighted higher than
another reservation. Maybe because one client paid more? The point is that
this would be configurable and the sensible default is to not evict
anything.


On Fri, Aug 9, 2013 at 8:05 AM, Nikolay Starodubtsev <
nstarodubt...@mirantis.com> wrote:

> Hello, Patrick!
>
> We have several reasons to think that for the virtual resources this
> possibility is interesting. If we speak about physical resources, user may
> use them in the different ways, that's why it is impossible to include base
> actions with them to the reservation service. But speaking about virtual
> reservations, let's imagine user wants to reserve virtual machine. He knows
> everything about it - its parameters, flavor and time to be leased for.
> Really, in this case user wants to have already working (or at least
> starting to work) reserved virtual machine and it would be great to include
> this opportunity to the reservation service. We are thinking about base
> actions for the virtual reservations that will be supported by Climate,
> like boot/delete for instance, create/delete for volume and create/delete
> for the stacks. The same will be with volumes, IPs, etc. As for more
> complicated behaviour, it may be implemented in Heat. This will make
> reservations simpler to use for the end users.
>
> Don't you think so?
>
> P.S. Also we remember about the problem you mentioned some letters ago -
> how to guarantee that user will have already working and prepared host / VM
> / stack / etc. by the time lease actually starts, no just "lease begins and
> preparing process begins too". We are working on it now.
>
>
> On Thu, Aug 8, 2013 at 8:18 PM, Patrick Petit wrote:
>
>>  Hi Nikolay,
>>
>> Relying on Heat for orchestration is obviously the right thing to do. But
>> there is still something in your design approach that I am having
>> difficulties to comprehend since the beginning. Why do you keep thinking
>> that orchestration and reservation should be treated together? That's
>> adding unnecessary complexity IMHO. I just don't get it. Wouldn't it be
>> much simpler and sufficient to say that there are pools of reserved
>> resources you create through the reservation service. Those pools could be
>> of different types i.e. host, instance, volume, network,.., whatever if
>> that's really needed. Those pools are identified by a unique id that you
>> pass along when the resource is created. That's it. You know, the AWS
>> reservation service doesn't even care about referencing a reservation when
>> an instance is created. The association between the two just happens behind
>> the scene. That would work in all scenarios, manual, automatic, whatever...
>> So, why do you care so much about this in a first place?
>> Thanks,
>> Patrick
>>
>> On 8/7/13 3:35 PM, Nikolay Starodubtsev wrote:
>>
>>  Patrick, responding to your comments:
>>
>>  1) Dina mentioned "start automatically" and "start manually" only as
>> examples of how these politics may look like. It doesn't seem to be a
>> correct approach to put orchestration functionality (that belongs to Heat)
>> in Climate. That's why now we can implement the basics like starting Heat
>> stack, and for more complex actions we may later utilize something like
>> Convection (Task-as-a-Service) project.
>>
>>
>>  2) If we agree that Heat is the main consumer of
>> Reservation-as-a-Service, we can agree that lease may be created according
>> to one of the following scenarions (but not multiple):
>> - a Heat stack (with requirements to stack's contents) as a resource to
>> be reserved
>> - some amount of physical hosts (random ones or filtered based on certain
>> characteristics).
>> - some amount of individual VMs OR Volumes OR IPs
>>
>>  3) Heat might be the main consumer of virtual reservations. If not,
>> Heat will require development efforts in order to support:
>> - reservation of a stack
>> - waking up a reserved stack
>> - performing all the usual orchestration work
>>
>>  We will support reservation of individual instance/volume/ IP etc, but
>> the use case with "giving user already workin

Re: [openstack-dev] [climate] Mirantis proposal to extend Climate to support virtual resources reservation

[Nikolay Starodubtsev]

Hello, Patrick!

We have several reasons to think that for the virtual resources this
possibility is interesting. If we speak about physical resources, user may
use them in the different ways, that's why it is impossible to include base
actions with them to the reservation service. But speaking about virtual
reservations, let's imagine user wants to reserve virtual machine. He knows
everything about it - its parameters, flavor and time to be leased for.
Really, in this case user wants to have already working (or at least
starting to work) reserved virtual machine and it would be great to include
this opportunity to the reservation service. We are thinking about base
actions for the virtual reservations that will be supported by Climate,
like boot/delete for instance, create/delete for volume and create/delete
for the stacks. The same will be with volumes, IPs, etc. As for more
complicated behaviour, it may be implemented in Heat. This will make
reservations simpler to use for the end users.

Don't you think so?

P.S. Also we remember about the problem you mentioned some letters ago -
how to guarantee that user will have already working and prepared host / VM
/ stack / etc. by the time lease actually starts, no just "lease begins and
preparing process begins too". We are working on it now.


On Thu, Aug 8, 2013 at 8:18 PM, Patrick Petit wrote:

>  Hi Nikolay,
>
> Relying on Heat for orchestration is obviously the right thing to do. But
> there is still something in your design approach that I am having
> difficulties to comprehend since the beginning. Why do you keep thinking
> that orchestration and reservation should be treated together? That's
> adding unnecessary complexity IMHO. I just don't get it. Wouldn't it be
> much simpler and sufficient to say that there are pools of reserved
> resources you create through the reservation service. Those pools could be
> of different types i.e. host, instance, volume, network,.., whatever if
> that's really needed. Those pools are identified by a unique id that you
> pass along when the resource is created. That's it. You know, the AWS
> reservation service doesn't even care about referencing a reservation when
> an instance is created. The association between the two just happens behind
> the scene. That would work in all scenarios, manual, automatic, whatever...
> So, why do you care so much about this in a first place?
> Thanks,
> Patrick
>
> On 8/7/13 3:35 PM, Nikolay Starodubtsev wrote:
>
>  Patrick, responding to your comments:
>
>  1) Dina mentioned "start automatically" and "start manually" only as
> examples of how these politics may look like. It doesn't seem to be a
> correct approach to put orchestration functionality (that belongs to Heat)
> in Climate. That's why now we can implement the basics like starting Heat
> stack, and for more complex actions we may later utilize something like
> Convection (Task-as-a-Service) project.
>
>
>  2) If we agree that Heat is the main consumer of
> Reservation-as-a-Service, we can agree that lease may be created according
> to one of the following scenarions (but not multiple):
> - a Heat stack (with requirements to stack's contents) as a resource to be
> reserved
> - some amount of physical hosts (random ones or filtered based on certain
> characteristics).
> - some amount of individual VMs OR Volumes OR IPs
>
>  3) Heat might be the main consumer of virtual reservations. If not, Heat
> will require development efforts in order to support:
> - reservation of a stack
> - waking up a reserved stack
> - performing all the usual orchestration work
>
>  We will support reservation of individual instance/volume/ IP etc, but
> the use case with "giving user already working group of connected VMs,
> volumes, networks" seems to be the most interesting one.
> As for Heat autoscaling, reservation of the maximum instances set in the
> Heat template (not the minimum value) has to be implemented in Heat. Some
> open questions remain though - like updating of Heat stack when user
> changes the template to support higher max number of running instances
>
>  4) As a user, I would of course want to have it already working, running
> any configured hosts/stacks/etc by the time lease starts. But in reality we
> can't predict how much time the preparation process should take for every
> single use case. So if you have an idea how this should be implemented, it
> would be great you share your opinion.
>
>
>
> ___
> OpenStack-dev mailing 
> listOpenStack-dev@lists.openstack.orghttp://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] Mirantis proposal to extend Climate to support virtual resources reservation

[Patrick Petit]

Hi Nikolay,

Relying on Heat for orchestration is obviously the right thing to do. 
But there is still something in your design approach that I am having 
difficulties to comprehend since the beginning. Why do you keep thinking 
that orchestration and reservation should be treated together? That's 
adding unnecessary complexity IMHO. I just don't get it. Wouldn't it be 
much simpler and sufficient to say that there are pools of reserved 
resources you create through the reservation service. Those pools could 
be of different types i.e. host, instance, volume, network,.., whatever 
if that's really needed. Those pools are identified by a unique id that 
you pass along when the resource is created. That's it. You know, the 
AWS reservation service doesn't even care about referencing a 
reservation when an instance is created. The association between the two 
just happens behind the scene. That would work in all scenarios, manual, 
automatic, whatever... So, why do you care so much about this in a first 
place?

Thanks,
Patrick
On 8/7/13 3:35 PM, Nikolay Starodubtsev wrote:

Patrick, responding to your comments:

1) Dina mentioned "start automatically" and "start manually" only as 
examples of how these politics may look like. It doesn't seem to be a 
correct approach to put orchestration functionality (that belongs to 
Heat) in Climate. That's why now we can implement the basics like 
starting Heat stack, and for more complex actions we may later utilize 
something like Convection (Task-as-a-Service) project.


2) If we agree that Heat is the main consumer of 
Reservation-as-a-Service, we can agree that lease may be created 
according to one of the following scenarions (but not multiple):
- a Heat stack (with requirements to stack's contents) as a resource 
to be reserved
- some amount of physical hosts (random ones or filtered based on 
certain characteristics).

- some amount of individual VMs OR Volumes OR IPs

3) Heat might be the main consumer of virtual reservations. If not, 
Heat will require development efforts in order to support:

- reservation of a stack
- waking up a reserved stack
- performing all the usual orchestration work

We will support reservation of individual instance/volume/ IP etc, but 
the use case with "giving user already working group of connected VMs, 
volumes, networks" seems to be the most interesting one.
As for Heat autoscaling, reservation of the maximum instances set in 
the Heat template (not the minimum value) has to be implemented in 
Heat. Some open questions remain though - like updating of Heat stack 
when user changes the template to support higher max number of running 
instances


4) As a user, I would of course want to have it already working, 
running any configured hosts/stacks/etc by the time lease starts. But 
in reality we can't predict how much time the preparation process 
should take for every single use case. So if you have an idea how this 
should be implemented, it would be great you share your opinion.



___
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] Mirantis proposal to extend Climate to support virtual resources reservation

[Patrick Petit]

Hi Scott,

Thanks for your inputs. Please see some comments below.
BR,
Patrick
On 8/6/13 6:58 PM, Scott Devoid wrote:

Some thoughts:

0. Should Climate also address the need for an eviction service? That 
is, a service that can weight incoming requests and existing resource 
allocations using some set of policies and evict an existing resource 
allocations to make room for the higher weighted request. Eviction is 
necessary if you want to implement a Spot-like service. And if you 
want Climate reservations that do not tie physical resources to the 
reservation, this is also required to ensure that requests against the 
reservation succeed. (Note that even if you do tie physical resources 
as in whole-host reservations, an eviction service can help when 
physical resources fail.)
Good point. We probably don't want to to tie physical resources to a 
reservations until the lease becomes active.


1. +1 Let end users continue to use existing APIs for resources and 
extend those interfaces with reservation attributes. Climate should 
only handle reservation crud and tracking.


2a. As an operator, I want the power to define reservations in terms 
of host capacity / flavor, min duration, max duration... and limit 
what kind of reservation requests can come in. Basically define 
"reservation flavors" and let users submit requests as instances of 
one "reservation flavor". If you let the end user define all of these 
parameters I will be rejecting a lot of reservation requests.
Sure, however it is unclear what is the state of reflection about 
creating host flavor types and extend Nova and API to support that 
case...? Meanwhile, I think the approach proposed in 
https://wiki.openstack.org/wiki/WholeHostAllocation to use pre-defined 
metadata in aggregates should work for categorizing host reservation 
flavors.


2b. What's the point of an "immediate lease"? This should be 
equivalent to making the request against Nova directly right? Perhaps 
there's a rational for this w.r.t. billing? Otherwise I'm not sure 
what utility this kind of reservation provides?
Well, Amazon uses it as a business enabler for whole sales activities. 
From the end-user standpoint it ensures that the resources is available 
for the duration of the lease. I think it is useful when your cloud has 
limited capacity with capacity contenders.


2c. Automatic vs. manual reservation approval:

What a user wants to know is whether a reservation can be granted
in a all-or-nothing manner at the time he is asking the lease.


This is a very hard problem to solve: you have to model resource 
availability (MTTF, MTBF), resource demand (how full are we going to 
be), and bake in explicit policies (this tenant gets priority) to 
automatically grant / deny such reservations. Having reservations go 
through a manual request -> operator approval system is extremely 
simple and allows operators to tackle the automated case as they need to.
I agree, but I think that was Dina was referring to when speaking of 
automatic vs manual reservation is the ability to express whether the 
resource is started automatically or not by the reservation service. My 
point was to say that reservation and instantiation are two different 
and separate things and so the specification of post-lease actions 
should not be restricted to that if it was only because a reservation 
that is not started automatically by the reservation service could still 
be started automatically by someone else like auto-scaling.


All I need is a tool that lets a tenant spawn a single critical 
instance even when another tenant is running an application that's 
constantly trying to grab as many instances as it can get.
3. This will add a lot of complexity, particularly if you want to 
tackle #0.


5. (NEW) Note that Amazon's reserved instances feature doesn't tie 
reservations against specific instances. Effectively you purchase 
discount coupons to be applied at the end of the billing cycle. I am 
not sure how Amazon handles tenants with multiple reservations at 
different utilization levels (prioritize heavy -> light?).
Amazon knows how to handle tenant's dedicated instances with 
reservations in the context of VPC. Not sure either how or if it works 
at all when mixed with prioritization levels. That's tough!


~ Scott


On Tue, Aug 6, 2013 at 6:12 AM, Patrick Petit > wrote:


Hi Dina and All,
Please see comments inline. We can  drill down on the specifics
off-line if that's more practical.
Thanks in advance,
Patrick

On 8/5/13 3:19 PM, Dina Belova wrote:


Hello, everyone!


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

Re: [openstack-dev] [climate] Mirantis proposal to extend Climate to support virtual resources reservation

[Nikolay Starodubtsev]

Scott, thank you so much for taking part in our discussion!

0) Introducing the eviction mechanism is really interesting idea, it
potentially makes reservation service more flexible and well organized. But
we need to think about the case - if user, who has already created a
reservation, has lower priority, he will lose this reservation because of
more prioritized request. This may not work well if the reservation was
paid for.

1) Yes, we think it is better too. What do you think about our vision of
Heat being the main consumer of virtual reservations? Do you think the
support of reservations for individual items of resources/groups of
same-type resources is necessary?

2a) I think that letting user to make a reservation of just resources he or
she wants to should not be a problem. Could you please talk more about your
idea about reservation flavors and their usage?

2b) +1 Patrick, we saw this type of lease in your BP, could you please
describe your use cases for this reservation type?

2c) Actually we were speaking about manual and automated starting of
virtual resources usage (like starting VMs when lease starts). Scott, we
think that Patrick can be right speaking about users willing to know if the
requested resources will be granted or not. The prioritization problem is
connected with what you are speaking about in the 0th point.

3) With our new vision, reservations won't be nested. They'll just contain
stack / some amount of hosts / some amount of identical instances (last
item - if we agree that it's needed).

5) Within our vision user is supposed to know whether the resources will be
granted or not right after lease is created. Amazons scheme is different,
that's why they have priorities and so on.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [climate] Mirantis proposal to extend Climate to support virtual resources reservation

[Nikolay Starodubtsev]

Patrick, responding to your comments:

1) Dina mentioned "start automatically" and "start manually" only as
examples of how these politics may look like. It doesn't seem to be a
correct approach to put orchestration functionality (that belongs to Heat)
in Climate. That's why now we can implement the basics like starting Heat
stack, and for more complex actions we may later utilize something like
Convection (Task-as-a-Service) project.

2) If we agree that Heat is the main consumer of Reservation-as-a-Service,
we can agree that lease may be created according to one of the following
scenarions (but not multiple):
- a Heat stack (with requirements to stack's contents) as a resource to be
reserved
- some amount of physical hosts (random ones or filtered based on certain
characteristics).
- some amount of individual VMs OR Volumes OR IPs

3) Heat might be the main consumer of virtual reservations. If not, Heat
will require development efforts in order to support:
- reservation of a stack
- waking up a reserved stack
- performing all the usual orchestration work

We will support reservation of individual instance/volume/ IP etc, but the
use case with "giving user already working group of connected VMs, volumes,
networks" seems to be the most interesting one.
As for Heat autoscaling, reservation of the maximum instances set in the
Heat template (not the minimum value) has to be implemented in Heat. Some
open questions remain though - like updating of Heat stack when user
changes the template to support higher max number of running instances

4) As a user, I would of course want to have it already working, running
any configured hosts/stacks/etc by the time lease starts. But in reality we
can't predict how much time the preparation process should take for every
single use case. So if you have an idea how this should be implemented, it
would be great you share your opinion.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [climate] Mirantis proposal to extend Climate to support virtual resources reservation

[Nikolay Starodubtsev]

Hello, Patrick, Scott!

I'll try to answer all your comments and show what vision we have now
(after some internal discussions lasted all yesterday).

As for now we're under strong impression that the main consumer of
Reservation-as-a-Service (as long as virtual resources are concerned) will
be HEAT.

Why?

>From end user's perspective, it seems to be not sufficient to have separate
reservations for a VM instance, Volume and Floating IP. User needs a way to
attach reserved Volume to a reserved VM and associate Floating IP with it.
Also, if there's a use case for that, we can support reservations of
individual resources as well through Heat.

That's why our current vision implies Heat as a main reservation consumer,
and Climate as a service managing lease abstractions with its politics,
notifications and so on.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [climate] Mirantis proposal to extend Climate to support virtual resources reservation

[Scott Devoid]

Some thoughts:

0. Should Climate also address the need for an eviction service? That is, a
service that can weight incoming requests and existing resource allocations
using some set of policies and evict an existing resource allocations to
make room for the higher weighted request. Eviction is necessary if you
want to implement a Spot-like service. And if you want Climate reservations
that do not tie physical resources to the reservation, this is also
required to ensure that requests against the reservation succeed. (Note
that even if you do tie physical resources as in whole-host reservations,
an eviction service can help when physical resources fail.)

1. +1 Let end users continue to use existing APIs for resources and extend
those interfaces with reservation attributes. Climate should only handle
reservation crud and tracking.

2a. As an operator, I want the power to define reservations in terms of
host capacity / flavor, min duration, max duration... and limit what kind
of reservation requests can come in. Basically define "reservation flavors"
and let users submit requests as instances of one "reservation flavor". If
you let the end user define all of these parameters I will be rejecting a
lot of reservation requests.

2b. What's the point of an "immediate lease"? This should be equivalent to
making the request against Nova directly right? Perhaps there's a rational
for this w.r.t. billing? Otherwise I'm not sure what utility this kind of
reservation provides?

2c. Automatic vs. manual reservation approval:

What a user wants to know is whether a reservation can be granted in a
> all-or-nothing manner at the time he is asking the lease.


This is a very hard problem to solve: you have to model resource
availability (MTTF, MTBF), resource demand (how full are we going to be),
and bake in explicit policies (this tenant gets priority) to automatically
grant / deny such reservations. Having reservations go through a manual
request -> operator approval system is extremely simple and allows
operators to tackle the automated case as they need to.

All I need is a tool that lets a tenant spawn a single critical instance
even when another tenant is running an application that's constantly trying
to grab as many instances as it can get.

3. This will add a lot of complexity, particularly if you want to tackle #0.

5. (NEW) Note that Amazon's reserved instances feature doesn't tie
reservations against specific instances. Effectively you purchase discount
coupons to be applied at the end of the billing cycle. I am not sure how
Amazon handles tenants with multiple reservations at different utilization
levels (prioritize heavy -> light?).

~ Scott


On Tue, Aug 6, 2013 at 6:12 AM, Patrick Petit wrote:

>  Hi Dina and All,
> Please see comments inline. We can  drill down on the specifics off-line
> if that's more practical.
> Thanks in advance,
> Patrick
>
> On 8/5/13 3:19 PM, Dina Belova wrote:
>
>  Hello, everyone!
>
>
>  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
> behaviour.
>
> Something along those lines would work but I think the 'start VM manually'
> keeps over specifying the behavior IMO since you still make the assumption
> that reserved resources are always started using a term 'manually' that is
> misleading because if not automatically started by the reservation service
> they can still be automatically started elsewhere like in Heat. I general I
> agree that users can take advantage of being able to specify pre and post
> lease actions / conditions although it shouldn't be prescriptive of
> something binary like start automatically or manually. Another beneficial
> usage could be to send parametrized notifications. I would also make the
> pre and post action optional so that if the user choose not to associate an
> action with the realization of a lease, he doesn't have to specify
> anything. Finally, I would also  that the specification of a pre and post
> action is assorted of a time offset to take into account the lead time to
> provision certain types of resources like physical hosts. That's a possible
> solution to point 4.
>
>
>  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. Workfl

Re: [openstack-dev] [climate] Mirantis proposal to extend Climate to support virtual resources reservation

[Patrick Petit]

Hi Dina and All,
Please see comments inline. We can  drill down on the specifics off-line 
if that's more practical.

Thanks in advance,
Patrick
On 8/5/13 3:19 PM, Dina Belova wrote:


Hello, everyone!


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 behaviour.


Something along those lines would work but I think the 'start VM 
manually' keeps over specifying the behavior IMO since you still make 
the assumption that reserved resources are always started using a term 
'manually' that is misleading because if not automatically started by 
the reservation service they can still be automatically started 
elsewhere like in Heat. I general I agree that users can take advantage 
of being able to specify pre and post lease actions / conditions 
although it shouldn't be prescriptive of something binary like start 
automatically or manually. Another beneficial usage could be to send 
parametrized notifications. I would also make the pre and post action 
optional so that if the user choose not to associate an action with the 
realization of a lease, he doesn't have to specify anything. Finally, I 
would also  that the specification of a pre and post action is assorted 
of a time offset to take into account the lead time to provision certain 
types of resources like physical hosts. That's a possible solution to 
point 4.



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.


Well, I am under the impression that you put forward an argumentation 
that is mostly based on an implementation artifact which takes advantage 
of the actual resource provisioning workflow and dashboard rather than 
taking into account the most common use cases and practices. There maybe 
use cases that mandate for an iterative  workflow that is similar to 
what you describe. I may be wrong, but I am doubtful it is going to be a 
common use case. We tend to think of AWS as being a reference and you've 
probably noticed that reservations in AWS are performed by chunk (the 
more I reserve for the longer period of time, the cheaper). The problem 
with adding reservations into a lease on a continuous basis is that as a 
user I may end up undo what I have done (e.g. I got only 900 out of the 
1000 VMs I want) and keep trying forever. That's potentially a lot of 
overhead. Also, as a cloud operator, I'd like to know what my 
reservation pipeline looks like ahead of time so that I can provision 
new hardware in due time. That's capacity planning. As an operator, I 
also want to be able grant reservations and charge for it even if I 
don't have the capacity right now provided the lead time to provisioning 
new hardware doesn't conflict with the terms of the pending leases. If a 
user can add reservations to a lease at the last moment, that 
flexibility may be compromised. In any events, this is how we envision 
the behavior of the reservation service for the reservation of physical 
capacity and so, it is important the service API can support that 
interaction model. I think it's probably okay to do it in two separate 
steps 1) create the lease, 2) add reservation (although it seems 
problematic in the case of immediate lease) but the actual hosts

Re: [openstack-dev] [climate] Mirantis proposal to extend Climate to support virtual resources reservation

[Dina Belova]

Hello, everyone!


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
behaviour.


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.


Thank you,

DIna.


On Mon, Aug 5, 2013 at 1:22 PM, Julien Danjou  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@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] Mirantis proposal to extend Climate to support virtual resources reservation

[Julien Danjou]

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


signature.asc
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [climate] Mirantis proposal to extend Climate to support virtual resources reservation

[Patrick Petit]

Dear All,

There has been some discussions recently about project Climate on 
Stackforge which aim is to provide host reservation services. This 
project is somehow related to 
https://wiki.openstack.org/wiki/WholeHostAllocation in that Climate 
intends to deal with the reservation part of dedicated resource pools 
called Pclouds in that blueprint. Climate wiki page can be found here 
https://wiki.openstack.org/wiki/Blueprint-nova-planned-resource-reservation-api.


The purpose of that email is that a team at Mirantis is proposing to 
extend the scope of that service so that all sorts of resources 
(physical and virtual) could be reserved. The architectural approach of 
Mirantis is giving a first shot of this extension at 
https://wiki.openstack.org/wiki/Resource-reservation-service. We 
reviewed the proposal to evaluate how it fits with the initial use cases 
and objectives of Climate. However, as the scope is becoming much 
bigger, I thought we'd better bring the discussion to the open instead 
of discussing it in private so that everybody who a stake or general 
interest in that subject can chime in.


In the review below, I am referring to the Mirantis proposal at 
https://docs.google.com/document/d/1vsN9LLq9pEP4c5BJyfG8g2TecoPxWqIY4WMT1juNBPI/edit?pli=1


Here are four general comments/questions.

1. The primary assumption of Climate is that the role of the
   reservation service is to manage resource reservations and only
   resource reservations. This is because reserving a resource doesn't
   imply necessarily that the user wants to use it. In fact, as a user
   I may decide not to use a reservation at all and decide instead to
   resell it through some market place if that's possible. In its
   proposal, Mirantis specifies that the reservation service is also
   responsible for managing the life cycle of the reservations like
   starting instances when a lease becomes active. I foresee several
   situations where this behavior is not desirable like reserved
   instances to be launched upon some external conditions that can be
   time based or load based regardless of the lease terms. In this
   situation, this is typically not the reservation service but the
   auto-scaling service (Heat) who's in charge. So, is it planned in
   your design to make the life-cycle management part of the service
   optional or completely disabled if not needed?

2. The proposal specifies that the usage workflow is to first create a
   lease (with parameters including start and end dates) and then
   populate it with resource reservations requests to the Nova, Cinder,
   Neutron, ... APIs . I think this workflow can create two kinds of
   problems. First, a lease request could be synchronous or
   asynchronous but it should be transactional in my opinion. A second
   problem is that it probably won't work for physical host
   reservations since there is no support for that in Nova API.
   Originally, the idea of Climate is that the lease creation request
   contains the terms of the lease along with a specification of the
   type of resource (e.g. host capacity) to be reserved and the number
   of those. In the case of an immediate lease, the request would
   return success if the lease can be satisfied or failure otherwise.
   If successful, reservation is effective as soon as the lease
   creation request returns. This I think is a central principal both
   from a usability standpoint and an operational standpoint. What a
   user wants to know is whether a reservation can be granted in a
   all-or-nothing manner at the time he is asking the lease. Second, an
   operator wants to know what a lease entails operationally speaking
   both in terms of capacity availability and planing at the time a
   user requests the lease. Consequently, I think that the reservation
   API should allow a user to specify in the lease request the number
   and type of resource he wants to reserve along with the lease term
   parameters and that the system responds yes or no in a transactional
   manner.

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.

4. The proposal specifies that the Reservation Scheduler notifies the
   Reservation Manager when a lease starts and ends. Do you intend to
   send those notifications directly or through Ceilometer? Reservation
   state changes are of general interest for operational and billing
   purposes. I also think that the Reservation Manager may want