You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Pierre-Luc Dion <pd...@cloudops.com> on 2014/07/31 21:52:16 UTC
[PROPOSAL] systemvm upgrade process
since 4.3 the management-server can tell if systemvm and VR require
upgrade, which is great ! but, as of 4.4 it's not working anymore and
systemvm must be upgrade as well.
And what if their is another hartbleed issue between release requiring
upgrade of systemvm ?
Citrix is providing a Python script to CloudPlatform in order to upgrade
the systemvm template to a latest 4.3from jun 2014, which is not bad. but...
Doing automatic upgrade of system vm is out of scope because of implicated
downtime.
But could it be possible to implement a naming standard of systemvm
template so the management server would detect a newer version of template
and ask for upgrade of systemvm and VR?
Something like if I have those systemvm templates:
- SystemVM Template (XenServer)
- systemvm-xenserver-4.3
- systemvm-xenserver-4.4
right now in 4.4 it will use systemvm-xenserver-4.3 template which is not
working with acs4.4.
Could the detection of a new template be automated? like if I have to
upgrade to a newer version withing 4.4, like systemvm-xenserver-4.4.1 ?
or
Could it be simple to have a Global setting where we define the
systemvm-template to use and by default it would be SystemVM Template (*) ?
unless something like that is already in place?
Thanks,
PL
Re: [PROPOSAL] systemvm upgrade process
Posted by Pierre-Luc Dion <pd...@cloudops.com>.
apparently Global settings for VR already exist !
router.template.xen
router.template.kvm
router.template.vmware
Sheng, I hope you will have some time to spend on your idea to use package
repo :-)
Thanks,
*Pierre-Luc DION*
Architecte de Solution Cloud | Cloud Solutions Architect
t 855.652.5683
*CloudOps* Votre partenaire infonuagique* | *Cloud Solutions Experts
420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
w cloudops.com *|* tw @CloudOps_
On Fri, Aug 1, 2014 at 6:23 PM, Pierre-Luc Dion <pd...@cloudops.com> wrote:
> sounds cool!
>
> no chance we could have something fast and simple to put in place like a
> global or region setting for the name of the latest systemvm template?
>
> Thanks,
>
>
> *Pierre-Luc DION*
> Architecte de Solution Cloud | Cloud Solutions Architect
> t 855.652.5683
>
> *CloudOps* Votre partenaire infonuagique* | *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> w cloudops.com *|* tw @CloudOps_
>
>
>
> On Thu, Jul 31, 2014 at 8:03 PM, Sheng Yang <sh...@yasker.org> wrote:
>
>> In fact we're think about the ultimate solution for it.
>> Utilize deb repo.
>>
>> But we haven't got time to implement it yet. Hope we can get this idea on
>> track soon.
>>
>> --Sheng
>>
>>
>> On Thu, Jul 31, 2014 at 12:52 PM, Pierre-Luc Dion <pd...@cloudops.com>
>> wrote:
>>
>> > since 4.3 the management-server can tell if systemvm and VR require
>> > upgrade, which is great ! but, as of 4.4 it's not working anymore and
>> > systemvm must be upgrade as well.
>> >
>> > And what if their is another hartbleed issue between release requiring
>> > upgrade of systemvm ?
>> >
>> > Citrix is providing a Python script to CloudPlatform in order to upgrade
>> > the systemvm template to a latest 4.3from jun 2014, which is not bad.
>> > but...
>> >
>> >
>> > Doing automatic upgrade of system vm is out of scope because of
>> implicated
>> > downtime.
>> >
>> > But could it be possible to implement a naming standard of systemvm
>> > template so the management server would detect a newer version of
>> template
>> > and ask for upgrade of systemvm and VR?
>> >
>> > Something like if I have those systemvm templates:
>> > - SystemVM Template (XenServer)
>> > - systemvm-xenserver-4.3
>> > - systemvm-xenserver-4.4
>> >
>> > right now in 4.4 it will use systemvm-xenserver-4.3 template which is
>> not
>> > working with acs4.4.
>> >
>> > Could the detection of a new template be automated? like if I have to
>> > upgrade to a newer version withing 4.4, like systemvm-xenserver-4.4.1 ?
>> >
>> > or
>> >
>> > Could it be simple to have a Global setting where we define the
>> > systemvm-template to use and by default it would be SystemVM Template
>> (*) ?
>> >
>> > unless something like that is already in place?
>> >
>> > Thanks,
>> >
>> > PL
>> >
>>
>
>
Re: [PROPOSAL] systemvm upgrade process
Posted by Pierre-Luc Dion <pd...@cloudops.com>.
sounds cool!
no chance we could have something fast and simple to put in place like a
global or region setting for the name of the latest systemvm template?
Thanks,
*Pierre-Luc DION*
Architecte de Solution Cloud | Cloud Solutions Architect
t 855.652.5683
*CloudOps* Votre partenaire infonuagique* | *Cloud Solutions Experts
420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
w cloudops.com *|* tw @CloudOps_
On Thu, Jul 31, 2014 at 8:03 PM, Sheng Yang <sh...@yasker.org> wrote:
> In fact we're think about the ultimate solution for it.
> Utilize deb repo.
>
> But we haven't got time to implement it yet. Hope we can get this idea on
> track soon.
>
> --Sheng
>
>
> On Thu, Jul 31, 2014 at 12:52 PM, Pierre-Luc Dion <pd...@cloudops.com>
> wrote:
>
> > since 4.3 the management-server can tell if systemvm and VR require
> > upgrade, which is great ! but, as of 4.4 it's not working anymore and
> > systemvm must be upgrade as well.
> >
> > And what if their is another hartbleed issue between release requiring
> > upgrade of systemvm ?
> >
> > Citrix is providing a Python script to CloudPlatform in order to upgrade
> > the systemvm template to a latest 4.3from jun 2014, which is not bad.
> > but...
> >
> >
> > Doing automatic upgrade of system vm is out of scope because of
> implicated
> > downtime.
> >
> > But could it be possible to implement a naming standard of systemvm
> > template so the management server would detect a newer version of
> template
> > and ask for upgrade of systemvm and VR?
> >
> > Something like if I have those systemvm templates:
> > - SystemVM Template (XenServer)
> > - systemvm-xenserver-4.3
> > - systemvm-xenserver-4.4
> >
> > right now in 4.4 it will use systemvm-xenserver-4.3 template which is
> not
> > working with acs4.4.
> >
> > Could the detection of a new template be automated? like if I have to
> > upgrade to a newer version withing 4.4, like systemvm-xenserver-4.4.1 ?
> >
> > or
> >
> > Could it be simple to have a Global setting where we define the
> > systemvm-template to use and by default it would be SystemVM Template
> (*) ?
> >
> > unless something like that is already in place?
> >
> > Thanks,
> >
> > PL
> >
>
Re: [PROPOSAL] systemvm upgrade process
Posted by Sheng Yang <sh...@yasker.org>.
In fact we're think about the ultimate solution for it.
Utilize deb repo.
But we haven't got time to implement it yet. Hope we can get this idea on
track soon.
--Sheng
On Thu, Jul 31, 2014 at 12:52 PM, Pierre-Luc Dion <pd...@cloudops.com>
wrote:
> since 4.3 the management-server can tell if systemvm and VR require
> upgrade, which is great ! but, as of 4.4 it's not working anymore and
> systemvm must be upgrade as well.
>
> And what if their is another hartbleed issue between release requiring
> upgrade of systemvm ?
>
> Citrix is providing a Python script to CloudPlatform in order to upgrade
> the systemvm template to a latest 4.3from jun 2014, which is not bad.
> but...
>
>
> Doing automatic upgrade of system vm is out of scope because of implicated
> downtime.
>
> But could it be possible to implement a naming standard of systemvm
> template so the management server would detect a newer version of template
> and ask for upgrade of systemvm and VR?
>
> Something like if I have those systemvm templates:
> - SystemVM Template (XenServer)
> - systemvm-xenserver-4.3
> - systemvm-xenserver-4.4
>
> right now in 4.4 it will use systemvm-xenserver-4.3 template which is not
> working with acs4.4.
>
> Could the detection of a new template be automated? like if I have to
> upgrade to a newer version withing 4.4, like systemvm-xenserver-4.4.1 ?
>
> or
>
> Could it be simple to have a Global setting where we define the
> systemvm-template to use and by default it would be SystemVM Template (*) ?
>
> unless something like that is already in place?
>
> Thanks,
>
> PL
>