Prasanna,

I'm all for automating the process, be it puppet or chef. Though for now, I 
would like to get bash script version functional.

Alex,

I agree, we should let the user build their own system VMs - and have the 
ability to pull from the internet as needed.
One other good reason as to why you should be able to build your own - is for 
security and compliance. If cloudstack is going to be used in strict compliance 
subjected environment - they should be able to build their own system 
offerings. It's a bit hard to justify a system VM template created by someone 
else.

However, the supportability of custom build system offerings may become a 
challenge down the road.

Regards
ilya

-----Original Message-----
From: Alex Huang [mailto:[email protected]] 
Sent: Thursday, January 10, 2013 11:37 AM
To: [email protected]
Subject: RE: [DISCUSS] Hosting CS System Offerings using Oralce/Sun Java VS 
OpenJDK



> -----Original Message-----
> From: prasanna [mailto:[email protected]] On Behalf Of 
> Prasanna Santhanam
> Sent: Tuesday, January 08, 2013 9:47 PM
> To: [email protected]
> Subject: Re: [DISCUSS] Hosting CS System Offerings using Oralce/Sun 
> Java VS OpenJDK
> 
> On Tue, Jan 08, 2013 at 02:51:32PM -0500, Musayev, Ilya wrote:
> > Alex,
> >
> > It's a bit more complex, here is why:
> >
> > 1) The build process for CentOS - uses system specific commands that 
> > are only available in RedHat like system (i.e. yum and others).  2) 
> > The build process for Debian - has its own system specific commands 
> > like apt-get, debootstrap and others.
> >
> > In order to build the system offering - you CS management server 
> > will be either CentOS/Debian which means you will be successful at 
> > only building one type of system offering - by default.
> 
> How about puppetize the configuration and installation of these 
> systemvm packages? You could provide those to people who want to 
> build-their-own and pre-built binaries for others.
> 

We should think in general in those terms when thinking ahead into the future.  
Currently, CloudStack has three and a half system VMs (the half being the dhcp 
only vm deployed only in basic zone) but the future points to more and more of 
CloudStack's functionality being carried out in system VMs rather than 
concentrated in the management server.  Just off the top of my head I can think 
of Security Group and OVS propagation being done in that manner to make them 
scalable.  So to me the functionality carried on the system vms should be 
constructed by the management server after the admin decided what functionality 
they want in their deployment.  Now, I'm all for being able to construct it in 
under 5 minutes.  If it takes an hour, it is a big impediment to this thought 
process.

--Alex


Reply via email to