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. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
