> This is a fantastic, multi-leveled proposal with lots of implications. I > think that I'm going to keep my comments to the high-level intent of the > document, and ask that we re-initiate discussions on the implementation > details individually. In general, I'm highly supportive of this! > > Some specific questions from the slides: > > Slide 2 (Design Goals) - to me, the idea of "Allowing cloudstack components > to be written in any language" has some significant implications on choice > of framework and implementation design decisions for the refactoring work. > Do you agree?
Absolutely. I do believe we will keep the core orchestration together in Java. There's several reasons for that. I believe orchestration is the key to provide a consistent platform for people to add services ontop of IaaS so we have to keep tight control of that. However, when orchestration requires provisioning of the actual hardware, it should be able to accommodate that provisioning being written in a separate language. Even in the current version of CloudStack, that was the intent but it got muddled. All provisioning is expected to be carried out in ServerResource. The communication to those ServerResource is JSON but for various reasons none of the resources were written in a different language. I believe it has to do with - We didn't specify the JSON specifically. It's just implied in the Java class serilization and deserialization. - JSON is carried over a TCP connection which made other language have a difficult time maintaining that TCP connection and session. - We didn't write KVM in python as an example of how it should work. So the proposal to this is that each resource will be setup to accept RPC calls that are JSON based. There's no need to maintain the TCP connection. This has multiple benefits. One of which is that the resource can be tested individually. > > Slide 10 - there is a mention of a Policy Monitoring Service - what is that? Ignore it. I mean to say others can write these services as additions but it won't affect orchestration. > > Slide 10 - Is the box labeled CloudStack Orchestration Platform more > correctly labeled Cloud Engine? If not, I think I'm not understanding the > diagram. If so, then it makes sense to me. That's correct. The diagram was from when I first proposed this. The names kept changing. I will change it. > > Slide 21 - The "Account database" is shown. Any thoughts in how would > multi-region users be synced? I've answered that in the other answer to Sebastian. Please see there. --Alex
