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 <patrick.pe...@bull.net
<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 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
<patrick.pe...@bull.net <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 (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
<mailto: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
