cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Kinsella <>
Subject Re: [DISCUSS] we need a better SSVM solution
Date Thu, 29 Jan 2015 18:05:32 GMT

Concur on having an open/standardized protocol. Something clustered like Serf/Consul could
be attractive, but the overhead/requirements of those type of things usually scares me away.

Having ACS act as a CA would be quite interesting for some things. It’s one of the reasons
I’ve pondered a “hook” in the past to notify 3rd party upon VM creation/deletion/etc.
Wonder if we could take advantage of dogtag or similar. All that said - setup/management of
a CA is a PIA and probably outside scope of ACS, unless you did a “light” one similar
to Puppet by default...

An aside on that “hook” idea - something scriptable similar to (I said “similar to,"
no flames!) systemd for this could be interesting.

A good portion of users would resist having an agent installed on the user VM, but I guess
we’re in that position already, and they just wouldn’t get the added functionality.

One user experience point: Almost every time Parallels comes out with a new version, I have
to update their agent on my VMs, which on the Windows side means a reboot. That gets old,
and I’ve only got a handful of win VMs there...

Going to see if I can puppet-ize one of the SSVMs over the weekend to see what other thoughts
come up.


> On Jan 29, 2015, at 2:06 AM, Rohit Yadav <> wrote:
> Good ideas John.
> I’m in fact already discussing a design I’m calling it "agents framework” (suggestions
for better name are welcome!), I will try to share and update the spec soon that aims for
this feature and refactoring work for ACS 4.6/master. For now, I’ve shared an architecture
diagram here and some high level goals:
> Along with this, I’ve strong opinions and interests in just getting rid of Java based
agents in systemvms (to reduce memory footprint) and replace the current agent-management
server protocol (TCP based, which connects to only one management server on prt 8250 even
if there are multiple management servers) with some interoperable protocol such as json/http,
thrift etc that allows us to build better/scalable console proxy services (for example). People
don’t discuss much, but virtual routers and systemvms are not well tested at all, we should
also need efforts/infra to test these components with less human QA.
> Regards.
>> On 29-Jan-2015, at 2:14 am, John Kinsella <> wrote:
>> Every time there’s an issue (security or otherwise) with the system VM ISOs, it’s
a relative pain to fix. They’re sort of a closed system, people know little (relative to
other ACS parts, IMHO) about their innards, and updating them is more difficult than it should
>> I’d love to see a Better Way. I think these things could be dynamically built,
with the option to have them connect to a configuration management (CM) system such as Puppet,
Chef, Salt-Stack or whatever else floats people’s boat.
>> One possible use case:
>> * User installs new ACS system.
>> * User logs into mgmt server, goes to Templates area, clicks button to fetch default
SSVM image. UI allows providing alternative URL, other options as needed.
>> * (time passes)
>> * Security issue is announced. User goes back into Templates area, selects SSVM template,
clicks “Download updated template” and it does. Under infrastructure/system VMs and infrastrucutre/virtual
routers, there’s buttons to update one or more running instances to use the new template
>> Another possible use case:
>> * User installs new ACS system
>> * User uploads SSVM template that has CM agent configured to talk to their CM server
(I’ve been wanting to lab this for a while now)
>> * As ACS creates system VMs, they phone home to CM server, it provides them with
instructions to install various packages and config as needed to be domr/console proxy/whatever.
We provide basic “recipes” for CM systems for people to use and grow from.
>> * Security issue is announced. User updates recipe in CM system, a few minutes later
the SSVMs are up-to-date.
>> Modification on that use case: We ship the SSVM with puppet/chef/blah installed,
part of the SSVM “patch” process configures appropriate CM system.
>> What might make the second use case easier would be to have some hooks in ACS that
when a system is created/destroyed/modified, it informs 3rd party via API.
>> (Obviously API calls for all of the above to allow process without touching the UI)
>> Thoughts?
>> John
> Regards,
> Rohit Yadav
> Software Architect, ShapeBlue
> M. +91 88 262 30892 |
> Blog: | Twitter: @_bhaisaab
> Find out more about ShapeBlue and our range of CloudStack related services
> IaaS Cloud Design & Build<>
> CSForge – rapid IaaS deployment framework<>
> CloudStack Consulting<>
> CloudStack Software Engineering<>
> CloudStack Infrastructure Support<>
> CloudStack Bootcamp Training Courses<>
> This email and any attachments to it may be confidential and are intended solely for
the use of the individual to whom it is addressed. Any views or opinions expressed are solely
those of the author and do not necessarily represent those of Shape Blue Ltd or related companies.
If you are not the intended recipient of this email, you must neither take any action based
upon its contents, nor copy or show it to anyone. Please contact the sender if you believe
you have received this email in error. Shape Blue Ltd is a company incorporated in England
& Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated
under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated
in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company
registered by The Republic of South Africa and is traded under license from Shape Blue Ltd.
ShapeBlue is a registered trademark.

View raw message