Re: [DISCUSS] we need a better SSVM solution

[Pierre-Luc Dion]

Paul,
For your #1, there is this page [1] that might be a bit outdated but the
system-vm section is fairly complete. but effectively things could be
better address.

I know there is currently an initiative on changing how configuration are
sent to VR and system-vms. theres was some discussions at CCCEU14 on this.
I think it would be interesting to have a design spec in the wiki about
it.  Also, the way the sysvm is currently provision kind of make sense,
look like it's a basic debian templates, cloudstack push a system.iso into
at when VR, SSVM, CPVM are created, the iso contain all latest scripts from
the cloudstack-management server. the system iso can also be modified if
required (ex to install xentool in VR).  it's far from being perfect, but
might worth digging into the current deployment method?

I would add to the current discussion this :
Our current method of build system-vm templates used by the community is
becoming outdated, the way we generate generic system-vm template is due
for an update, as example we use veewee which might worth replacing this by
vagrant...  also, we should be able to embed xentools or vmware tools
inside the templates...

I haven't found much documentation on how to customize system vm templates
(ex: send cloud.log into a syslog server) but I think it's something we can
do with the current system.

Still, I'm +1



[1]
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Compatibility+Matrices



On Fri, Jan 30, 2015 at 1:58 AM, linux...@gmail.com 
wrote:

> I thinks John's idea is very good.
>
> we should fource on the security ,not others.
>
>
> 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.
>
> 2015-01-30 7:47 GMT+08:00 Adrian Lewis :
> > From a non-dev user's perspective I think Paul's pretty much nailed the
> key
> > issues I'd like to see improve with the system VMs. The big one for us is
> > the ability to customise the VR template to add things like netflow
> export
> > and other value-add services through additional software packages without
> > having to do this individually on each VR deployed.
> >
> > -Original Message-
> > From: Ahmad Emneina [mailto:aemne...@gmail.com]
> > Sent: 29 January 2015 22:17
> > To: dev@cloudstack.apache.org
> > Subject: Re: [DISCUSS] we need a better SSVM solution
> >
> > Pauls suggestion reminds me of some awesome functionality I see in the
> > aftermarket android ROM community. That is 'Kitchens'[1].
> >
> > A utility/site that provides functionality that allows for admins to
> create
> > customized system templates...
> >
> > Giving choices of:
> > - OS
> > - kernel
> > - VPN server
> > - various other services...
> >
> > Of course this is fantasy at the moment, I see the lowest barrier to
> entry
> > would be a cloud-init style utility where we can pass in commands or
> > scripts, like the steps to mitigate the GHOST vuln (which seems to be a
> few
> > apt commands). That would easily resolve issues where a vulnerable
> service
> > could easily be updated post boot, and propagated to all new/restarted
> > system vm's.
> >
> > [1] http://forum.xda-developers.com/showthread.php?t=633246
> >
> > On Thu, Jan 29, 2015 at 1:55 PM, John Kinsella  wrote:
> >
> >> Decent points. You think the difference between the VR/CP is different
> >> enough to have a second image?
> >>
> >> > On Jan 29, 2015, at 1:41 PM, Paul Angus 
> >> wrote:
> >> >
> >> > Hi All,
> >> >
> >> > I think that there are 3 things people would like to see:
> >> >
> >> > 1. clear versioning of system vm templates, with some kind of
> >> compatibility matrix so they know which one(s) they can use with
> >> different versions of CloudStack
> >> > 2. an easy way to update the system vm template 3. an easy(ish) way
> >> > to customise system vm templates
> >> >
> >> > It might be worth considering have two types of template a. the
> >> > console proxy and secondary storage template b. the virtual router/
> >&g

RE: [DISCUSS] we need a better SSVM solution

[Paul Angus]

...also.
I'm not a fan of us different configuration processes for different 
hypervisors. I'm fairly sure that where the hypervisor still uses the 
systemvm.iso it overwrites the scripts which are already on the system vm, 
whereas with xenserver we only inject config in through pvgrub.

I think that the systemvm.iso should only contain the same data as is injected 
via xenserver for consistency, or xenserver system vms should go back to using 
systemvm.iso

There are a load of global settings which allow you to specify the system vm 
template for each hypervisor, I guess this effectively allows you to have 
different router templates to the ssvm/consoleproxy  template.

router.template.vmwareName of the default router template on Vmware
router.template.xenName of the default router template on Xenserver

I'm not sure why it exists, you can't change the ssvm or cpvm template per 
hypervisor.

Regards,

Paul Angus
Cloud Architect
S: +44 20 3603 0540 | M: +447711418784 | T: @CloudyAngus
paul.an...@shapeblue.com

-Original Message-
From: Adrian Lewis [mailto:adr...@alsiconsulting.co.uk]
Sent: 29 January 2015 23:47
To: dev@cloudstack.apache.org
Subject: RE: [DISCUSS] we need a better SSVM solution

From a non-dev user's perspective I think Paul's pretty much nailed the key 
issues I'd like to see improve with the system VMs. The big one for us is the 
ability to customise the VR template to add things like netflow export and 
other value-add services through additional software packages without having to 
do this individually on each VR deployed.

-Original Message-
From: Ahmad Emneina [mailto:aemne...@gmail.com]
Sent: 29 January 2015 22:17
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] we need a better SSVM solution

Pauls suggestion reminds me of some awesome functionality I see in the 
aftermarket android ROM community. That is 'Kitchens'[1].

A utility/site that provides functionality that allows for admins to create 
customized system templates...

Giving choices of:
- OS
- kernel
- VPN server
- various other services...

Of course this is fantasy at the moment, I see the lowest barrier to entry 
would be a cloud-init style utility where we can pass in commands or scripts, 
like the steps to mitigate the GHOST vuln (which seems to be a few apt 
commands). That would easily resolve issues where a vulnerable service could 
easily be updated post boot, and propagated to all new/restarted system vm's.

[1] http://forum.xda-developers.com/showthread.php?t=633246

On Thu, Jan 29, 2015 at 1:55 PM, John Kinsella  wrote:

> Decent points. You think the difference between the VR/CP is different
> enough to have a second image?
>
> > On Jan 29, 2015, at 1:41 PM, Paul Angus 
> wrote:
> >
> > Hi All,
> >
> > I think that there are 3 things people would like to see:
> >
> > 1. clear versioning of system vm templates, with some kind of
> compatibility matrix so they know which one(s) they can use with
> different versions of CloudStack
> > 2. an easy way to update the system vm template 3. an easy(ish) way
> > to customise system vm templates
> >
> > It might be worth considering have two types of template a. the
> > console proxy and secondary storage template b. the virtual router/
> > VPC template.
> >
> >
> >
> > Regards
> >
> > Paul Angus
> > Cloud Architect
> > S: +44 20 3603 0540 | M: +447711418784 | T: CloudyAngus
> > paul.an...@shapeblue.com
> >
> > -Original Message-
> > From: John Kinsella [mailto:j...@stratosec.co]
> > Sent: 29 January 2015 18:06
> > To: dev@cloudstack.apache.org
> > Subject: Re: [DISCUSS] we need a better SSVM solution
> >
> > Interesting…
> >
> > 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 p

Re: [DISCUSS] we need a better SSVM solution

[linux...@gmail.com]

I thinks John's idea is very good.

we should fource on the security ,not others.


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.

2015-01-30 7:47 GMT+08:00 Adrian Lewis :
> From a non-dev user's perspective I think Paul's pretty much nailed the key
> issues I'd like to see improve with the system VMs. The big one for us is
> the ability to customise the VR template to add things like netflow export
> and other value-add services through additional software packages without
> having to do this individually on each VR deployed.
>
> -Original Message-
> From: Ahmad Emneina [mailto:aemne...@gmail.com]
> Sent: 29 January 2015 22:17
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] we need a better SSVM solution
>
> Pauls suggestion reminds me of some awesome functionality I see in the
> aftermarket android ROM community. That is 'Kitchens'[1].
>
> A utility/site that provides functionality that allows for admins to create
> customized system templates...
>
> Giving choices of:
> - OS
> - kernel
> - VPN server
> - various other services...
>
> Of course this is fantasy at the moment, I see the lowest barrier to entry
> would be a cloud-init style utility where we can pass in commands or
> scripts, like the steps to mitigate the GHOST vuln (which seems to be a few
> apt commands). That would easily resolve issues where a vulnerable service
> could easily be updated post boot, and propagated to all new/restarted
> system vm's.
>
> [1] http://forum.xda-developers.com/showthread.php?t=633246
>
> On Thu, Jan 29, 2015 at 1:55 PM, John Kinsella  wrote:
>
>> Decent points. You think the difference between the VR/CP is different
>> enough to have a second image?
>>
>> > On Jan 29, 2015, at 1:41 PM, Paul Angus 
>> wrote:
>> >
>> > Hi All,
>> >
>> > I think that there are 3 things people would like to see:
>> >
>> > 1. clear versioning of system vm templates, with some kind of
>> compatibility matrix so they know which one(s) they can use with
>> different versions of CloudStack
>> > 2. an easy way to update the system vm template 3. an easy(ish) way
>> > to customise system vm templates
>> >
>> > It might be worth considering have two types of template a. the
>> > console proxy and secondary storage template b. the virtual router/
>> > VPC template.
>> >
>> >
>> >
>> > Regards
>> >
>> > Paul Angus
>> > Cloud Architect
>> > S: +44 20 3603 0540 | M: +447711418784 | T: CloudyAngus
>> > paul.an...@shapeblue.com
>> >
>> > -Original Message-
>> > From: John Kinsella [mailto:j...@stratosec.co]
>> > Sent: 29 January 2015 18:06
>> > To: dev@cloudstack.apache.org
>> > Subject: Re: [DISCUSS] we need a better SSVM solution
>> >
>> > Interesting…
>> >
>> > 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
>> W

RE: [DISCUSS] we need a better SSVM solution

[Adrian Lewis]

>From a non-dev user's perspective I think Paul's pretty much nailed the key
issues I'd like to see improve with the system VMs. The big one for us is
the ability to customise the VR template to add things like netflow export
and other value-add services through additional software packages without
having to do this individually on each VR deployed.

-Original Message-
From: Ahmad Emneina [mailto:aemne...@gmail.com]
Sent: 29 January 2015 22:17
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] we need a better SSVM solution

Pauls suggestion reminds me of some awesome functionality I see in the
aftermarket android ROM community. That is 'Kitchens'[1].

A utility/site that provides functionality that allows for admins to create
customized system templates...

Giving choices of:
- OS
- kernel
- VPN server
- various other services...

Of course this is fantasy at the moment, I see the lowest barrier to entry
would be a cloud-init style utility where we can pass in commands or
scripts, like the steps to mitigate the GHOST vuln (which seems to be a few
apt commands). That would easily resolve issues where a vulnerable service
could easily be updated post boot, and propagated to all new/restarted
system vm's.

[1] http://forum.xda-developers.com/showthread.php?t=633246

On Thu, Jan 29, 2015 at 1:55 PM, John Kinsella  wrote:

> Decent points. You think the difference between the VR/CP is different
> enough to have a second image?
>
> > On Jan 29, 2015, at 1:41 PM, Paul Angus 
> wrote:
> >
> > Hi All,
> >
> > I think that there are 3 things people would like to see:
> >
> > 1. clear versioning of system vm templates, with some kind of
> compatibility matrix so they know which one(s) they can use with
> different versions of CloudStack
> > 2. an easy way to update the system vm template 3. an easy(ish) way
> > to customise system vm templates
> >
> > It might be worth considering have two types of template a. the
> > console proxy and secondary storage template b. the virtual router/
> > VPC template.
> >
> >
> >
> > Regards
> >
> > Paul Angus
> > Cloud Architect
> > S: +44 20 3603 0540 | M: +447711418784 | T: CloudyAngus
> > paul.an...@shapeblue.com
> >
> > -Original Message-
> > From: John Kinsella [mailto:j...@stratosec.co]
> > Sent: 29 January 2015 18:06
> > To: dev@cloudstack.apache.org
> > Subject: Re: [DISCUSS] we need a better SSVM solution
> >
> > Interesting…
> >
> > 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.
> >
> > John
> >
> >> 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:
> >>
> >> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Agents+Frame
> >> work
> >>
> >> 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 (

Re: [DISCUSS] we need a better SSVM solution

[Ahmad Emneina]

Pauls suggestion reminds me of some awesome functionality I see in the
aftermarket android ROM community. That is 'Kitchens'[1].

A utility/site that provides functionality that allows for admins to create
customized system templates...

Giving choices of:
- OS
- kernel
- VPN server
- various other services...

Of course this is fantasy at the moment, I see the lowest barrier to entry
would be a cloud-init style utility where we can pass in commands or
scripts, like the steps to mitigate the GHOST vuln (which seems to be a few
apt commands). That would easily resolve issues where a vulnerable service
could easily be updated post boot, and propagated to all new/restarted
system vm's.

[1] http://forum.xda-developers.com/showthread.php?t=633246

On Thu, Jan 29, 2015 at 1:55 PM, John Kinsella  wrote:

> Decent points. You think the difference between the VR/CP is different
> enough to have a second image?
>
> > On Jan 29, 2015, at 1:41 PM, Paul Angus 
> wrote:
> >
> > Hi All,
> >
> > I think that there are 3 things people would like to see:
> >
> > 1. clear versioning of system vm templates, with some kind of
> compatibility matrix so they know which one(s) they can use with different
> versions of CloudStack
> > 2. an easy way to update the system vm template
> > 3. an easy(ish) way to customise system vm templates
> >
> > It might be worth considering have two types of template
> > a. the console proxy and secondary storage template
> > b. the virtual router/ VPC template.
> >
> >
> >
> > Regards
> >
> > Paul Angus
> > Cloud Architect
> > S: +44 20 3603 0540 | M: +447711418784 | T: CloudyAngus
> > paul.an...@shapeblue.com
> >
> > -----Original Message-----
> > From: John Kinsella [mailto:j...@stratosec.co]
> > Sent: 29 January 2015 18:06
> > To: dev@cloudstack.apache.org
> > Subject: Re: [DISCUSS] we need a better SSVM solution
> >
> > Interesting…
> >
> > 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.
> >
> > John
> >
> >> 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:
> >>
> >> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Agents+Framework
> >>
> >> 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

Re: [DISCUSS] we need a better SSVM solution

[John Kinsella]

Decent points. You think the difference between the VR/CP is different enough 
to have a second image?

> On Jan 29, 2015, at 1:41 PM, Paul Angus  wrote:
> 
> Hi All,
> 
> I think that there are 3 things people would like to see:
> 
> 1. clear versioning of system vm templates, with some kind of compatibility 
> matrix so they know which one(s) they can use with different versions of 
> CloudStack
> 2. an easy way to update the system vm template
> 3. an easy(ish) way to customise system vm templates
> 
> It might be worth considering have two types of template
> a. the console proxy and secondary storage template
> b. the virtual router/ VPC template.
> 
> 
> 
> Regards
> 
> Paul Angus
> Cloud Architect
> S: +44 20 3603 0540 | M: +447711418784 | T: CloudyAngus
> paul.an...@shapeblue.com
> 
> -Original Message-
> From: John Kinsella [mailto:j...@stratosec.co]
> Sent: 29 January 2015 18:06
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] we need a better SSVM solution
> 
> Interesting…
> 
> 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.
> 
> John
> 
>> 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:
>> 
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Agents+Framework
>> 
>> 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 be.
>>> 
>>> 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. U

RE: [DISCUSS] we need a better SSVM solution

[Paul Angus]

Hi All,

I think that there are 3 things people would like to see:

1. clear versioning of system vm templates, with some kind of compatibility 
matrix so they know which one(s) they can use with different versions of 
CloudStack
2. an easy way to update the system vm template
3. an easy(ish) way to customise system vm templates

It might be worth considering have two types of template
a. the console proxy and secondary storage template
b. the virtual router/ VPC template.



Regards

Paul Angus
Cloud Architect
S: +44 20 3603 0540 | M: +447711418784 | T: CloudyAngus
paul.an...@shapeblue.com

-Original Message-
From: John Kinsella [mailto:j...@stratosec.co]
Sent: 29 January 2015 18:06
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] we need a better SSVM solution

Interesting…

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.

John

> 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:
>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Agents+Framework
>
> 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 be.
>>
>> 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

Re: [DISCUSS] we need a better SSVM solution

[John Kinsella]

Interesting…

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.

John

> 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:
> 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Agents+Framework
> 
> 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 be.
>> 
>> 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 | rohit.ya...@shapeblue.com
> Blog: bhaisaab.org | 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

Re: [DISCUSS] we need a better SSVM solution

[Andrei Mikhailovsky]

I am also +1 on this. 

For large deployments it is a must feature to automatically upgrade a zone or 
region level system vms. I think that ACS should not only automatically upgrade 
the templates, but also have the option to automatically upgrade the running 
system vms. 

It would also be awesome if ACS could fire up a temporary/redundant virtual 
router before upgrading the live one. This will minimise the downtime. Similar 
to what the redundant virtual routers do. Once the live router is upgraded and 
switched to master/primary function, the temporary one could be automatically 
deleted. 

Andrei 

- Original Message -

> From: "Daan Hoogland" 
> To: "dev" 
> Sent: Thursday, 29 January, 2015 10:52:53 AM
> Subject: Re: [DISCUSS] we need a better SSVM solution

> I don't like the puppet/chef idea but at Schuberg Philis we use
> ansible which negates most of my opposition :p

> I would rather have a 'upload or sysvmtemplate' the system vm
> template
> has some requirements so I think we would either require it to be
> build (on the ms?) or be checked during upload. At least the MS
> should
> allow for automatic update. Remi and I got some inspiration last
> night
> from our update of about 200 routers and some ssvm's and cpvm's. To
> cut it short; i'm with scenario 1.

> On Wed, Jan 28, 2015 at 10:09 PM, Andrija Panic
>  wrote:
> > +1 !
> > On Jan 28, 2015 10:01 PM, "Erik Weber"  wrote:
> >
> >> On Wed, Jan 28, 2015 at 9:44 PM, 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 be.
> >> >
> >> > 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.
> >> >
> >> >
> >> Totally agree, but we should consider the fact that users might
> >> not use our
> >> builds and make it equally easy to update with a custom one.
> >>
> >> 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
> >> >
> >> >
> >> If the user is using one of the published templates, why not just
> >> download
> >> the new one and send a notification that a new template is ready
> >> and that
> >> systemvms should be scheduled for a restart?
> >>
> >>
> >> > 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?
> >> >
> >> >
> >> I've wondered for quite some time why we haven't had a simple
> >> checkbox in
> >> the template register view that says 'Use as System VM' or
> >> similar.
> >>
> >> Anyway, huge +1
> >>
> >> --
> >> Erik
> >>

> --
> Daan

Re: [DISCUSS] we need a better SSVM solution

[Daan Hoogland]

I don't like the puppet/chef idea but at Schuberg Philis we use
ansible which negates most of my opposition :p

I would rather have a 'upload or sysvmtemplate' the system vm template
has some requirements so I think we would either require it to be
build (on the ms?) or be checked during upload. At least the MS should
allow for automatic update. Remi and I got some inspiration last night
from our update of about 200 routers and some ssvm's and cpvm's. To
cut it short; i'm with scenario 1.

On Wed, Jan 28, 2015 at 10:09 PM, Andrija Panic  wrote:
> +1 !
> On Jan 28, 2015 10:01 PM, "Erik Weber"  wrote:
>
>> On Wed, Jan 28, 2015 at 9:44 PM, 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 be.
>> >
>> > 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.
>> >
>> >
>> Totally agree, but we should consider the fact that users might not use our
>> builds and make it equally easy to update with a custom one.
>>
>> 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
>> >
>> >
>> If the user is using one of the published templates, why not just download
>> the new one and send a notification that a new template is ready and that
>> systemvms should be scheduled for a restart?
>>
>>
>> > 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?
>> >
>> >
>> I've wondered for quite some time why we haven't had a simple checkbox in
>> the template register view that says 'Use as System VM' or similar.
>>
>> Anyway, huge +1
>>
>> --
>> Erik
>>



-- 
Daan

Re: [DISCUSS] we need a better SSVM solution

[Rohit Yadav]

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:

https://cwiki.apache.org/confluence/display/CLOUDSTACK/Agents+Framework

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 be.
>
> 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 | rohit.ya...@shapeblue.com
Blog: bhaisaab.org | 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.

Re:[DISCUSS] we need a better SSVM solution

[ChunFeng]

+1


some trivial cases:


When user upload a template , add option or tags to identify the template is 
SystemVm template .


Allow user have their own custom "SystemVm Service Offering " , in which has an 
option for user assign/choice systemvm template .



--


Regards,


ChunFeng




 

 
 
 
-- Original --
From:  "John Kinsella";
Date:  Thu, Jan 29, 2015 04:44 AM
To:  ""; 

Subject:  [DISCUSS] we need a better SSVM solution

 
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 be.

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

Re: [DISCUSS] we need a better SSVM solution

[Andrija Panic]

+1 !
On Jan 28, 2015 10:01 PM, "Erik Weber"  wrote:

> On Wed, Jan 28, 2015 at 9:44 PM, 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 be.
> >
> > 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.
> >
> >
> Totally agree, but we should consider the fact that users might not use our
> builds and make it equally easy to update with a custom one.
>
> 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
> >
> >
> If the user is using one of the published templates, why not just download
> the new one and send a notification that a new template is ready and that
> systemvms should be scheduled for a restart?
>
>
> > 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?
> >
> >
> I've wondered for quite some time why we haven't had a simple checkbox in
> the template register view that says 'Use as System VM' or similar.
>
> Anyway, huge +1
>
> --
> Erik
>

Re: [DISCUSS] we need a better SSVM solution

[Erik Weber]

On Wed, Jan 28, 2015 at 9:44 PM, 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 be.
>
> 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.
>
>
Totally agree, but we should consider the fact that users might not use our
builds and make it equally easy to update with a custom one.

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
>
>
If the user is using one of the published templates, why not just download
the new one and send a notification that a new template is ready and that
systemvms should be scheduled for a restart?


> 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?
>
>
I've wondered for quite some time why we haven't had a simple checkbox in
the template register view that says 'Use as System VM' or similar.

Anyway, huge +1

-- 
Erik