Open Stack

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.petit at bull.net 
> <mailto:patrick.petit at 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 at lists.openstack.org  <mailto:OpenStack-dev at lists.openstack.org>
>>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Patrick Petit
Cloud Computing Principal Architect, Innovative Products
Bull, Architect of an Open World TM
Tél : +33 (0)4 76 29 70 31
Mobile : +33 (0)6 85 22 06 39
http://www.bull.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130812/f6a2add0/attachment.html>