It looks like there's no objections to this proposal so I'm going to start work on this. It will be a bit of a mess during transition. Will try to keep changes to a minimal.
--Alex > -----Original Message----- > From: Alex Huang > Sent: Tuesday, June 05, 2012 10:32 AM > To: cloudstack-dev@incubator.apache.org > Subject: RE: [PROPOSAL] Further refinement of CloudStack modules... > > > > > -----Original Message----- > > From: Matthew Hartmann [mailto:mhartm...@tls.net] > > Sent: Tuesday, June 05, 2012 10:17 AM > > To: cloudstack-dev@incubator.apache.org > > Subject: Re: [PROPOSAL] Further refinement of CloudStack modules... > > > > On 6/5/2012 10:19 AM, Alex Huang wrote: > > >> Great diagram! I have a silly question though, is there any > > >> particular reason why cloud-orchestration was selected over cloud- > > management? > > >> > > > > > > That's a good question. The management server is actually two > > > parts. The > > first part is the orchestration engine (cloud-orchestration). The > > second part are the auth, acl, and services built on top of > > orchestration engine (cloud-api- server). Together that constructs the > management server. > > > > > > CloudStack today is somewhat deployed as such because there are two > > different pools of threads handling each. We're going to make that > > more explicit by breaking it into two modules. > > > > > > --Alex > > > > Fantastic! Thanks for the clarification, Alex! As a heavy user of > > CloudStack, I would like to propose an addition to your packaging model. > > I would like to see a cloud-docs package that includes documentation > > for command line utilities that are available on the Management > > Server. I think it would also be advantageous to include the Admin & > > Install guides in HTML format in a cloud-docs package. Do you think > > there is any possibility of that happening? It seems some of the most > > common questions that come across IRC and the mailing lists have to do > > with documentation; it seems the community could greatly benefit from > such a package. > > > +1 > > I also think we need packages for client stubs for different languages. > > --Alex
