Open Stack

On 25/09/13 07:03, Mike Spreitzer wrote:
>
> Zane wrote:
>  > To take the first example, wouldn't your holistic scheduler
> effectively have
>  > to reserve a compute instance and some directly attached block
> storage prior
>  > to actually creating them? Have you considered Climate rather than
> Heat as
>  > an integration point?
>
> I had not considered Climate.  Based on recent ML traffic, I see that
> Climate is about scheduling into the future, whereas I am only trying to
> talk about scheduling for the present.  OTOH, perhaps you are concerned
> about concurrency issues.  I am too.  Doing a better job on that is a
> big part of the revision my group is working on now.  I think it can be
> done.  I plan to post a pointer to some details soon.

Your diagrams clearly show scheduling happening in a separate stage to 
(infrastructure) orchestration, which is to say that at the point where 
resources are scheduled, their actual creation is in the *future*.

I am not a Climate expert, but it seems to me that they have a 
near-identical problem to solve: how do they integrate with Heat such 
that somebody who has reserved resources in the past can actually create 
them (a) as part of a Heat stack or (b) as standalone resources, at the 
user's option. IMO OpenStack should solve this problem only once.

> Perhaps the concern is about competition between two managers trying to
> manage the same resources.  I think that is (a) something that can not
> be completely avoided and (b) impossible to do well.  My preference is
> to focus on one manager, and make sure it tolerates surprises in a way
> that is not terrible.  Even without competing managers, bugs and other
> unexpected failures will cause nasty surprises.
>
> Zane later wrote:
>  > As proposed, the software configs contain directives like 'hosted_on:
>  > server_name'. (I don't know that I'm a huge fan of this design, but I
> don't
>  > think the exact details are relevant in this context.) There's no
>  > non-trivial processing in the preparatory stage of software orchestration
>  > that would require it to be performed before scheduling could occur.
>
> I hope I have addressed that with my remarks above about software
> orchestration.

If I understood your remarks correctly, we agree that there is no 
(known) reason that the scheduling has to occur in the middle of 
orchestration (which would have implied that it needed to be 
incorporated in some sense into Heat).

> Zane also wrote:
>  > Let's make sure we distinguish between doing holistic scheduling, which
>  > requires a priori knowledge of the resources to be created, and automatic
>  > scheduling, which requires psychic knowledge of the user's mind. (Did the
>  > user want to optimise for performance or availability? How would you
> infer
>  > that from the template?)
>
> One reason I favor holistic infrastructure scheduling is that I want its
> input to be richer than today's CFN templates.  Like Debo, I think the
> input can contain the kind of information that would otherwise require
> mind-reading.  My group has been working examples involving multiple
> levels of anti-co-location statements, network reachability and
> proximity statements, disk exclusivity statements, and statements about
> the presence of licensed products.

Right, so what I'm saying is that if all those things are _stated_ in 
the input then there's no need to run the orchestration engine to find 
out what they'll be; they're already stated.

cheers,
Zane.