On Mon, May 13, 2013 at 09:32:32PM -0700, Kelven Yang wrote: > Murali, > > I've updated the document to give more background details on the thought > process. I'm sorry that I'm having hard time to describe it like other > normal high-level FS, since the change is at architecture level, and to > understand why we are doing this makes sense from conceptual level. The > document is more organized as a thought process.
Actually Kelven, I appreciate reading the thought process on this one. This is one of the more useful and interesting discussions of a change like this. It's a model that I'd suggest we use again for these types of interesting architectural questions. Well done. I have one other suggested use case for you (and feel free to push back on me if you don't think it's related): Hosts placed in maintenance mode by the local element manager (ex: vSphere Virtual Center) are detected as such by ACS, as well as the reverse. This is a very common thing for a operations team that may have access to the underlying infra to do, and it would be great if it was coordinated with ACS. +1 from me on the rest of the proposal. A strong +1 on the (as you say) long road forward to promote jobs from implicit to explicit. IMO, orchestration tasks themselves are basically a combination of flow control and job control tasks for the developer. The implicit nature of job control today is, IMO, why we have different thread management implementations sprinkled around. -chip
