You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Pearl d'Silva <pe...@shapeblue.com> on 2021/09/01 12:19:36 UTC
[DISCUSS] SystemVM template upgrade improvements
Hi All,
We have been working on a feature that simplifies SystemVM template install and upgrades for CloudStack. Historically we've required users to seed the template on secondary storage during fresh installation and register the template before an upgrade - this really does not make CloudStack turnkey, as we end up maintaining and managing them as a separate component - for example, users can't simply do an apt-get upgrade or yum upgrade to upgrade CloudStack.
The feature works by automatically initiating registration of the SystemVM templates during upgrades or when the first secondary storage is added to a zone where the SystemVM template hasn't been seeded. This feature addresses several operational pain points for example, when the admin user forgets to register the SystemVM template prior to an upgrade and faces the issue of having to roll back the database midway during the upgrade process. With this feature the upgrade process is seamless, such that the end users do not need to worry about having to perform template registration, but rather have the upgrade process take care of everything that is required.
In order to facilitate this feature, the SystemVM templates have to be bundled with the cloudstack-management rpm/deb package which causes the total noredist cloudstack-management package size to increase to about 1.6GB. We currently are packaging templates of only the three widely supported hypervisors - KVM, XenServer/XCP-ng and VMWare.
(These templates are only packaged if the build is initiated with the noredist flag.)
We'd like to get your opinion on this idea.
Thanks & Regards,
Pearl Dsilva
Re: [DISCUSS] SystemVM template upgrade improvements
Posted by Pearl d'Silva <pe...@shapeblue.com>.
Hi Nathan,
You are right, the inclusion of templates as part of the cloudstack management package was done bearing in mind that we may have users with restricted internet connection.
With respect to the second point you make, while creating separate packages for different hypervisor templates would solve the issue of the size of the package, we may still end up facing the same issue of missing systemVM templates in scenarios where we start off with a zone with say, KVM hosts and in due course of time, decide to add XenServer/ VMWare hosts and the admin doesn't install the hypervisor specific packages. Keeping that in mind, we thought that the all-in-one approach covers more ground.
Thanks,
Pearl
________________________________
From: Nathan McGarvey <na...@gmail.com>
Sent: Friday, September 3, 2021 11:53 AM
To: users@cloudstack.apache.org <us...@cloudstack.apache.org>
Subject: Re: [DISCUSS] SystemVM template upgrade improvements
+1
This is also helpful for restricted-from-internet installations. (E.g.
places with on-site installs and strong firewall/proxy/air-gap rules.)
Which is a feature that is increasingly hard to come by for cloud-based
underpinnings, but increasingly of interest for many organizations who
like to have control of where their data resides. (Banks, medical
institutions, governments, etc.)
Should it be in the same packaging, or be a separate package entirely?
That way the current packaging could still remain as-is but have the
option of obtaining the seperately packaged systemVMs in package-manager
format. If you really wanted to, you could even break out the KVM vs Xen
vs VMWare into separate packages to help reduce size and increase
modularity. Then you still are hooking into the turnkey-method since it
lends itself to a apt-get upgrade or yum upgrade, and can update
components individually and maintain that certain versions of SystemVMs
require certain cloudstack versions and vice-versa.
Thanks,
-Nathan McGarvey
On 9/2/21 9:29 AM, Rohit Yadav wrote:
> Hi Hean,
>
> Yes I think the old approach of registering systemvm template prior to upgrade as well as the option to switch between systemvmtemplate continues to be supported. What this feature primarily aims is to make CloudStack turnkey operationally.
>
> May I ask if anyone has any objections on the increased package size? Due to the trade off of including systemvmtemplates in the management package the size increased to about 1-1.5GB which is the only thing I didn't like. However I think this can be optimised in future releases.
>
> Regards.
> ________________________________
> From: Hean Seng <he...@gmail.com>
> Sent: Thursday, September 2, 2021 7:34:32 AM
> To: users@cloudstack.apache.org <us...@cloudstack.apache.org>
> Cc: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
> Subject: Re: [DISCUSS] SystemVM template upgrade improvements
>
> This is good idea. Or else , we shall allow manual upload via. GUI, and
> mark for system template .
>
> On Wed, Sep 1, 2021 at 9:08 PM Pearl d'Silva <pe...@shapeblue.com>
> wrote:
>
>> I probably missed adding the PR link to the feature -
>> https://github.com/apache/cloudstack/pull/4329. Please do provide you
>> inputs.
>>
>>
>> Thanks,
>> Pearl
>>
>> ________________________________
>> From: Pearl d'Silva <pe...@shapeblue.com>
>> Sent: Wednesday, September 1, 2021 5:49 PM
>> To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
>> Subject: [DISCUSS] SystemVM template upgrade improvements
>>
>> Hi All,
>>
>> We have been working on a feature that simplifies SystemVM template
>> install and upgrades for CloudStack. Historically we've required users to
>> seed the template on secondary storage during fresh installation and
>> register the template before an upgrade - this really does not make
>> CloudStack turnkey, as we end up maintaining and managing them as a
>> separate component - for example, users can't simply do an apt-get upgrade
>> or yum upgrade to upgrade CloudStack.
>>
>> The feature works by automatically initiating registration of the SystemVM
>> templates during upgrades or when the first secondary storage is added to a
>> zone where the SystemVM template hasn't been seeded. This feature addresses
>> several operational pain points for example, when the admin user forgets to
>> register the SystemVM template prior to an upgrade and faces the issue of
>> having to roll back the database midway during the upgrade process. With
>> this feature the upgrade process is seamless, such that the end users do
>> not need to worry about having to perform template registration, but rather
>> have the upgrade process take care of everything that is required.
>>
>> In order to facilitate this feature, the SystemVM templates have to be
>> bundled with the cloudstack-management rpm/deb package which causes the
>> total noredist cloudstack-management package size to increase to about
>> 1.6GB. We currently are packaging templates of only the three widely
>> supported hypervisors - KVM, XenServer/XCP-ng and VMWare.
>> (These templates are only packaged if the build is initiated with the
>> noredist flag.)
>>
>> We'd like to get your opinion on this idea.
>>
>> Thanks & Regards,
>> Pearl Dsilva
>>
>>
>>
>>
>>
>>
>>
>
> --
> Regards,
> Hean Seng
>
>
>
>
Re: [DISCUSS] SystemVM template upgrade improvements
Posted by Nathan McGarvey <na...@gmail.com>.
+1
This is also helpful for restricted-from-internet installations. (E.g.
places with on-site installs and strong firewall/proxy/air-gap rules.)
Which is a feature that is increasingly hard to come by for cloud-based
underpinnings, but increasingly of interest for many organizations who
like to have control of where their data resides. (Banks, medical
institutions, governments, etc.)
Should it be in the same packaging, or be a separate package entirely?
That way the current packaging could still remain as-is but have the
option of obtaining the seperately packaged systemVMs in package-manager
format. If you really wanted to, you could even break out the KVM vs Xen
vs VMWare into separate packages to help reduce size and increase
modularity. Then you still are hooking into the turnkey-method since it
lends itself to a apt-get upgrade or yum upgrade, and can update
components individually and maintain that certain versions of SystemVMs
require certain cloudstack versions and vice-versa.
Thanks,
-Nathan McGarvey
On 9/2/21 9:29 AM, Rohit Yadav wrote:
> Hi Hean,
>
> Yes I think the old approach of registering systemvm template prior to upgrade as well as the option to switch between systemvmtemplate continues to be supported. What this feature primarily aims is to make CloudStack turnkey operationally.
>
> May I ask if anyone has any objections on the increased package size? Due to the trade off of including systemvmtemplates in the management package the size increased to about 1-1.5GB which is the only thing I didn't like. However I think this can be optimised in future releases.
>
> Regards.
> ________________________________
> From: Hean Seng <he...@gmail.com>
> Sent: Thursday, September 2, 2021 7:34:32 AM
> To: users@cloudstack.apache.org <us...@cloudstack.apache.org>
> Cc: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
> Subject: Re: [DISCUSS] SystemVM template upgrade improvements
>
> This is good idea. Or else , we shall allow manual upload via. GUI, and
> mark for system template .
>
> On Wed, Sep 1, 2021 at 9:08 PM Pearl d'Silva <pe...@shapeblue.com>
> wrote:
>
>> I probably missed adding the PR link to the feature -
>> https://github.com/apache/cloudstack/pull/4329. Please do provide you
>> inputs.
>>
>>
>> Thanks,
>> Pearl
>>
>> ________________________________
>> From: Pearl d'Silva <pe...@shapeblue.com>
>> Sent: Wednesday, September 1, 2021 5:49 PM
>> To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
>> Subject: [DISCUSS] SystemVM template upgrade improvements
>>
>> Hi All,
>>
>> We have been working on a feature that simplifies SystemVM template
>> install and upgrades for CloudStack. Historically we've required users to
>> seed the template on secondary storage during fresh installation and
>> register the template before an upgrade - this really does not make
>> CloudStack turnkey, as we end up maintaining and managing them as a
>> separate component - for example, users can't simply do an apt-get upgrade
>> or yum upgrade to upgrade CloudStack.
>>
>> The feature works by automatically initiating registration of the SystemVM
>> templates during upgrades or when the first secondary storage is added to a
>> zone where the SystemVM template hasn't been seeded. This feature addresses
>> several operational pain points for example, when the admin user forgets to
>> register the SystemVM template prior to an upgrade and faces the issue of
>> having to roll back the database midway during the upgrade process. With
>> this feature the upgrade process is seamless, such that the end users do
>> not need to worry about having to perform template registration, but rather
>> have the upgrade process take care of everything that is required.
>>
>> In order to facilitate this feature, the SystemVM templates have to be
>> bundled with the cloudstack-management rpm/deb package which causes the
>> total noredist cloudstack-management package size to increase to about
>> 1.6GB. We currently are packaging templates of only the three widely
>> supported hypervisors - KVM, XenServer/XCP-ng and VMWare.
>> (These templates are only packaged if the build is initiated with the
>> noredist flag.)
>>
>> We'd like to get your opinion on this idea.
>>
>> Thanks & Regards,
>> Pearl Dsilva
>>
>>
>>
>>
>>
>>
>>
>
> --
> Regards,
> Hean Seng
>
>
>
>
Re: [DISCUSS] SystemVM template upgrade improvements
Posted by Rohit Yadav <ro...@shapeblue.com>.
Hi Hean,
Yes I think the old approach of registering systemvm template prior to upgrade as well as the option to switch between systemvmtemplate continues to be supported. What this feature primarily aims is to make CloudStack turnkey operationally.
May I ask if anyone has any objections on the increased package size? Due to the trade off of including systemvmtemplates in the management package the size increased to about 1-1.5GB which is the only thing I didn't like. However I think this can be optimised in future releases.
Regards.
________________________________
From: Hean Seng <he...@gmail.com>
Sent: Thursday, September 2, 2021 7:34:32 AM
To: users@cloudstack.apache.org <us...@cloudstack.apache.org>
Cc: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
Subject: Re: [DISCUSS] SystemVM template upgrade improvements
This is good idea. Or else , we shall allow manual upload via. GUI, and
mark for system template .
On Wed, Sep 1, 2021 at 9:08 PM Pearl d'Silva <pe...@shapeblue.com>
wrote:
> I probably missed adding the PR link to the feature -
> https://github.com/apache/cloudstack/pull/4329. Please do provide you
> inputs.
>
>
> Thanks,
> Pearl
>
> ________________________________
> From: Pearl d'Silva <pe...@shapeblue.com>
> Sent: Wednesday, September 1, 2021 5:49 PM
> To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
> Subject: [DISCUSS] SystemVM template upgrade improvements
>
> Hi All,
>
> We have been working on a feature that simplifies SystemVM template
> install and upgrades for CloudStack. Historically we've required users to
> seed the template on secondary storage during fresh installation and
> register the template before an upgrade - this really does not make
> CloudStack turnkey, as we end up maintaining and managing them as a
> separate component - for example, users can't simply do an apt-get upgrade
> or yum upgrade to upgrade CloudStack.
>
> The feature works by automatically initiating registration of the SystemVM
> templates during upgrades or when the first secondary storage is added to a
> zone where the SystemVM template hasn't been seeded. This feature addresses
> several operational pain points for example, when the admin user forgets to
> register the SystemVM template prior to an upgrade and faces the issue of
> having to roll back the database midway during the upgrade process. With
> this feature the upgrade process is seamless, such that the end users do
> not need to worry about having to perform template registration, but rather
> have the upgrade process take care of everything that is required.
>
> In order to facilitate this feature, the SystemVM templates have to be
> bundled with the cloudstack-management rpm/deb package which causes the
> total noredist cloudstack-management package size to increase to about
> 1.6GB. We currently are packaging templates of only the three widely
> supported hypervisors - KVM, XenServer/XCP-ng and VMWare.
> (These templates are only packaged if the build is initiated with the
> noredist flag.)
>
> We'd like to get your opinion on this idea.
>
> Thanks & Regards,
> Pearl Dsilva
>
>
>
>
>
>
>
--
Regards,
Hean Seng
Re: [DISCUSS] SystemVM template upgrade improvements
Posted by Rohit Yadav <ro...@shapeblue.com>.
Hi Hean,
Yes I think the old approach of registering systemvm template prior to upgrade as well as the option to switch between systemvmtemplate continues to be supported. What this feature primarily aims is to make CloudStack turnkey operationally.
May I ask if anyone has any objections on the increased package size? Due to the trade off of including systemvmtemplates in the management package the size increased to about 1-1.5GB which is the only thing I didn't like. However I think this can be optimised in future releases.
Regards.
________________________________
From: Hean Seng <he...@gmail.com>
Sent: Thursday, September 2, 2021 7:34:32 AM
To: users@cloudstack.apache.org <us...@cloudstack.apache.org>
Cc: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
Subject: Re: [DISCUSS] SystemVM template upgrade improvements
This is good idea. Or else , we shall allow manual upload via. GUI, and
mark for system template .
On Wed, Sep 1, 2021 at 9:08 PM Pearl d'Silva <pe...@shapeblue.com>
wrote:
> I probably missed adding the PR link to the feature -
> https://github.com/apache/cloudstack/pull/4329. Please do provide you
> inputs.
>
>
> Thanks,
> Pearl
>
> ________________________________
> From: Pearl d'Silva <pe...@shapeblue.com>
> Sent: Wednesday, September 1, 2021 5:49 PM
> To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
> Subject: [DISCUSS] SystemVM template upgrade improvements
>
> Hi All,
>
> We have been working on a feature that simplifies SystemVM template
> install and upgrades for CloudStack. Historically we've required users to
> seed the template on secondary storage during fresh installation and
> register the template before an upgrade - this really does not make
> CloudStack turnkey, as we end up maintaining and managing them as a
> separate component - for example, users can't simply do an apt-get upgrade
> or yum upgrade to upgrade CloudStack.
>
> The feature works by automatically initiating registration of the SystemVM
> templates during upgrades or when the first secondary storage is added to a
> zone where the SystemVM template hasn't been seeded. This feature addresses
> several operational pain points for example, when the admin user forgets to
> register the SystemVM template prior to an upgrade and faces the issue of
> having to roll back the database midway during the upgrade process. With
> this feature the upgrade process is seamless, such that the end users do
> not need to worry about having to perform template registration, but rather
> have the upgrade process take care of everything that is required.
>
> In order to facilitate this feature, the SystemVM templates have to be
> bundled with the cloudstack-management rpm/deb package which causes the
> total noredist cloudstack-management package size to increase to about
> 1.6GB. We currently are packaging templates of only the three widely
> supported hypervisors - KVM, XenServer/XCP-ng and VMWare.
> (These templates are only packaged if the build is initiated with the
> noredist flag.)
>
> We'd like to get your opinion on this idea.
>
> Thanks & Regards,
> Pearl Dsilva
>
>
>
>
>
>
>
--
Regards,
Hean Seng
Re: [DISCUSS] SystemVM template upgrade improvements
Posted by Pearl d'Silva <pe...@shapeblue.com>.
Hi Hean,
Thanks for your response. As mentioned, the usual upgrade procedure, of admins registering template prior upgrade continues to be supported and if we find the new systemvm template already registered the new logic for setting up the templates doesn't kick in.
Thanks,
Pearl
________________________________
From: Hean Seng <he...@gmail.com>
Sent: Thursday, September 2, 2021 7:34 AM
To: users@cloudstack.apache.org <us...@cloudstack.apache.org>
Cc: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
Subject: Re: [DISCUSS] SystemVM template upgrade improvements
This is good idea. Or else , we shall allow manual upload via. GUI, and
mark for system template .
On Wed, Sep 1, 2021 at 9:08 PM Pearl d'Silva <pe...@shapeblue.com>
wrote:
> I probably missed adding the PR link to the feature -
> https://github.com/apache/cloudstack/pull/4329. Please do provide you
> inputs.
>
>
> Thanks,
> Pearl
>
> ________________________________
> From: Pearl d'Silva <pe...@shapeblue.com>
> Sent: Wednesday, September 1, 2021 5:49 PM
> To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
> Subject: [DISCUSS] SystemVM template upgrade improvements
>
> Hi All,
>
> We have been working on a feature that simplifies SystemVM template
> install and upgrades for CloudStack. Historically we've required users to
> seed the template on secondary storage during fresh installation and
> register the template before an upgrade - this really does not make
> CloudStack turnkey, as we end up maintaining and managing them as a
> separate component - for example, users can't simply do an apt-get upgrade
> or yum upgrade to upgrade CloudStack.
>
> The feature works by automatically initiating registration of the SystemVM
> templates during upgrades or when the first secondary storage is added to a
> zone where the SystemVM template hasn't been seeded. This feature addresses
> several operational pain points for example, when the admin user forgets to
> register the SystemVM template prior to an upgrade and faces the issue of
> having to roll back the database midway during the upgrade process. With
> this feature the upgrade process is seamless, such that the end users do
> not need to worry about having to perform template registration, but rather
> have the upgrade process take care of everything that is required.
>
> In order to facilitate this feature, the SystemVM templates have to be
> bundled with the cloudstack-management rpm/deb package which causes the
> total noredist cloudstack-management package size to increase to about
> 1.6GB. We currently are packaging templates of only the three widely
> supported hypervisors - KVM, XenServer/XCP-ng and VMWare.
> (These templates are only packaged if the build is initiated with the
> noredist flag.)
>
> We'd like to get your opinion on this idea.
>
> Thanks & Regards,
> Pearl Dsilva
>
>
>
>
>
>
>
--
Regards,
Hean Seng
Re: [DISCUSS] SystemVM template upgrade improvements
Posted by Hean Seng <he...@gmail.com>.
This is good idea. Or else , we shall allow manual upload via. GUI, and
mark for system template .
On Wed, Sep 1, 2021 at 9:08 PM Pearl d'Silva <pe...@shapeblue.com>
wrote:
> I probably missed adding the PR link to the feature -
> https://github.com/apache/cloudstack/pull/4329. Please do provide you
> inputs.
>
>
> Thanks,
> Pearl
>
> ________________________________
> From: Pearl d'Silva <pe...@shapeblue.com>
> Sent: Wednesday, September 1, 2021 5:49 PM
> To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
> Subject: [DISCUSS] SystemVM template upgrade improvements
>
> Hi All,
>
> We have been working on a feature that simplifies SystemVM template
> install and upgrades for CloudStack. Historically we've required users to
> seed the template on secondary storage during fresh installation and
> register the template before an upgrade - this really does not make
> CloudStack turnkey, as we end up maintaining and managing them as a
> separate component - for example, users can't simply do an apt-get upgrade
> or yum upgrade to upgrade CloudStack.
>
> The feature works by automatically initiating registration of the SystemVM
> templates during upgrades or when the first secondary storage is added to a
> zone where the SystemVM template hasn't been seeded. This feature addresses
> several operational pain points for example, when the admin user forgets to
> register the SystemVM template prior to an upgrade and faces the issue of
> having to roll back the database midway during the upgrade process. With
> this feature the upgrade process is seamless, such that the end users do
> not need to worry about having to perform template registration, but rather
> have the upgrade process take care of everything that is required.
>
> In order to facilitate this feature, the SystemVM templates have to be
> bundled with the cloudstack-management rpm/deb package which causes the
> total noredist cloudstack-management package size to increase to about
> 1.6GB. We currently are packaging templates of only the three widely
> supported hypervisors - KVM, XenServer/XCP-ng and VMWare.
> (These templates are only packaged if the build is initiated with the
> noredist flag.)
>
> We'd like to get your opinion on this idea.
>
> Thanks & Regards,
> Pearl Dsilva
>
>
>
>
>
>
>
--
Regards,
Hean Seng
Re: [DISCUSS] SystemVM template upgrade improvements
Posted by Hean Seng <he...@gmail.com>.
This is good idea. Or else , we shall allow manual upload via. GUI, and
mark for system template .
On Wed, Sep 1, 2021 at 9:08 PM Pearl d'Silva <pe...@shapeblue.com>
wrote:
> I probably missed adding the PR link to the feature -
> https://github.com/apache/cloudstack/pull/4329. Please do provide you
> inputs.
>
>
> Thanks,
> Pearl
>
> ________________________________
> From: Pearl d'Silva <pe...@shapeblue.com>
> Sent: Wednesday, September 1, 2021 5:49 PM
> To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
> Subject: [DISCUSS] SystemVM template upgrade improvements
>
> Hi All,
>
> We have been working on a feature that simplifies SystemVM template
> install and upgrades for CloudStack. Historically we've required users to
> seed the template on secondary storage during fresh installation and
> register the template before an upgrade - this really does not make
> CloudStack turnkey, as we end up maintaining and managing them as a
> separate component - for example, users can't simply do an apt-get upgrade
> or yum upgrade to upgrade CloudStack.
>
> The feature works by automatically initiating registration of the SystemVM
> templates during upgrades or when the first secondary storage is added to a
> zone where the SystemVM template hasn't been seeded. This feature addresses
> several operational pain points for example, when the admin user forgets to
> register the SystemVM template prior to an upgrade and faces the issue of
> having to roll back the database midway during the upgrade process. With
> this feature the upgrade process is seamless, such that the end users do
> not need to worry about having to perform template registration, but rather
> have the upgrade process take care of everything that is required.
>
> In order to facilitate this feature, the SystemVM templates have to be
> bundled with the cloudstack-management rpm/deb package which causes the
> total noredist cloudstack-management package size to increase to about
> 1.6GB. We currently are packaging templates of only the three widely
> supported hypervisors - KVM, XenServer/XCP-ng and VMWare.
> (These templates are only packaged if the build is initiated with the
> noredist flag.)
>
> We'd like to get your opinion on this idea.
>
> Thanks & Regards,
> Pearl Dsilva
>
>
>
>
>
>
>
--
Regards,
Hean Seng
Re: [DISCUSS] SystemVM template upgrade improvements
Posted by Pearl d'Silva <pe...@shapeblue.com>.
I probably missed adding the PR link to the feature - https://github.com/apache/cloudstack/pull/4329. Please do provide you inputs.
Thanks,
Pearl
________________________________
From: Pearl d'Silva <pe...@shapeblue.com>
Sent: Wednesday, September 1, 2021 5:49 PM
To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
Subject: [DISCUSS] SystemVM template upgrade improvements
Hi All,
We have been working on a feature that simplifies SystemVM template install and upgrades for CloudStack. Historically we've required users to seed the template on secondary storage during fresh installation and register the template before an upgrade - this really does not make CloudStack turnkey, as we end up maintaining and managing them as a separate component - for example, users can't simply do an apt-get upgrade or yum upgrade to upgrade CloudStack.
The feature works by automatically initiating registration of the SystemVM templates during upgrades or when the first secondary storage is added to a zone where the SystemVM template hasn't been seeded. This feature addresses several operational pain points for example, when the admin user forgets to register the SystemVM template prior to an upgrade and faces the issue of having to roll back the database midway during the upgrade process. With this feature the upgrade process is seamless, such that the end users do not need to worry about having to perform template registration, but rather have the upgrade process take care of everything that is required.
In order to facilitate this feature, the SystemVM templates have to be bundled with the cloudstack-management rpm/deb package which causes the total noredist cloudstack-management package size to increase to about 1.6GB. We currently are packaging templates of only the three widely supported hypervisors - KVM, XenServer/XCP-ng and VMWare.
(These templates are only packaged if the build is initiated with the noredist flag.)
We'd like to get your opinion on this idea.
Thanks & Regards,
Pearl Dsilva
Re: [DISCUSS] SystemVM template upgrade improvements
Posted by Rohit Yadav <ro...@shapeblue.com>.
+1
Love this idea, I had actually tweeted about it and many from the community on Twitter really liked it at the time:
https://twitter.com/rhtyd/status/1420364812056350720
Regards.
________________________________
From: Pearl d'Silva <pe...@shapeblue.com>
Sent: Wednesday, September 1, 2021 17:49
To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
Subject: [DISCUSS] SystemVM template upgrade improvements
Hi All,
We have been working on a feature that simplifies SystemVM template install and upgrades for CloudStack. Historically we've required users to seed the template on secondary storage during fresh installation and register the template before an upgrade - this really does not make CloudStack turnkey, as we end up maintaining and managing them as a separate component - for example, users can't simply do an apt-get upgrade or yum upgrade to upgrade CloudStack.
The feature works by automatically initiating registration of the SystemVM templates during upgrades or when the first secondary storage is added to a zone where the SystemVM template hasn't been seeded. This feature addresses several operational pain points for example, when the admin user forgets to register the SystemVM template prior to an upgrade and faces the issue of having to roll back the database midway during the upgrade process. With this feature the upgrade process is seamless, such that the end users do not need to worry about having to perform template registration, but rather have the upgrade process take care of everything that is required.
In order to facilitate this feature, the SystemVM templates have to be bundled with the cloudstack-management rpm/deb package which causes the total noredist cloudstack-management package size to increase to about 1.6GB. We currently are packaging templates of only the three widely supported hypervisors - KVM, XenServer/XCP-ng and VMWare.
(These templates are only packaged if the build is initiated with the noredist flag.)
We'd like to get your opinion on this idea.
Thanks & Regards,
Pearl Dsilva
Re: [DISCUSS] SystemVM template upgrade improvements
Posted by Pearl d'Silva <pe...@shapeblue.com>.
I probably missed adding the PR link to the feature - https://github.com/apache/cloudstack/pull/4329. Please do provide you inputs.
Thanks,
Pearl
________________________________
From: Pearl d'Silva <pe...@shapeblue.com>
Sent: Wednesday, September 1, 2021 5:49 PM
To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
Subject: [DISCUSS] SystemVM template upgrade improvements
Hi All,
We have been working on a feature that simplifies SystemVM template install and upgrades for CloudStack. Historically we've required users to seed the template on secondary storage during fresh installation and register the template before an upgrade - this really does not make CloudStack turnkey, as we end up maintaining and managing them as a separate component - for example, users can't simply do an apt-get upgrade or yum upgrade to upgrade CloudStack.
The feature works by automatically initiating registration of the SystemVM templates during upgrades or when the first secondary storage is added to a zone where the SystemVM template hasn't been seeded. This feature addresses several operational pain points for example, when the admin user forgets to register the SystemVM template prior to an upgrade and faces the issue of having to roll back the database midway during the upgrade process. With this feature the upgrade process is seamless, such that the end users do not need to worry about having to perform template registration, but rather have the upgrade process take care of everything that is required.
In order to facilitate this feature, the SystemVM templates have to be bundled with the cloudstack-management rpm/deb package which causes the total noredist cloudstack-management package size to increase to about 1.6GB. We currently are packaging templates of only the three widely supported hypervisors - KVM, XenServer/XCP-ng and VMWare.
(These templates are only packaged if the build is initiated with the noredist flag.)
We'd like to get your opinion on this idea.
Thanks & Regards,
Pearl Dsilva
[DISCUSS] Upgrade to Vue3 library
Posted by Mai Nguyen <ho...@ext.ewerk.com>.
Hi All,
We are upgrading a Vue 2 application to Vue 3 on CloudStack. As far as our investigation goes, Vue 3 does support migration from Vue 2 to Vue 3 by using `@vue/compat` (aka "the migration build"). However, it is worth mentioning that there are some incompatible features (please refer to: https://v3.vuejs.org/guide/migration/migration-build.html#overview).
The biggest differences between Vue 2 and Vue 3 on Cloudstack are:
- mount: https://v3.vuejs.org/guide/migration/mount-changes.html#overview
- Slots: https://v3.vuejs.org/guide/component-slots.html#slots
- Async components: https://v3.vuejs.org/guide/migration/async-components.html#async-components
- Events: https://v3.vuejs.org/guide/migration/events-api.html#overview
- Watch: https://v3.vuejs.org/guide/migration/watch.html#overview
In order to make them compatible with Vue 3, it is necessary to upgrade or replace some libraries as well as some other components, which are listed below:
- Antd: https://2x.antdv.com/components/overview
- Router: https://next.router.vuejs.org/installation.html
- I18n: https://vue-i18n.intlify.dev/introduction.html
- Clipboard: https://www.npmjs.com/package/vue3-clipboard
- Vue-ls (https://www.npmjs.com/package/vue-ls) => vue-web-storage (https://github.com/ankurk91/vue-web-storage)
These upgrades and replacements will require changes in source code, structure and elements in UI. We would like to have your opinions about it.
Thank you and best regards,
__
Mai Nguyen
Frontend Developer
EWERK DIGITAL GmbH
Brühl 24, D-04109 Leipzig
P
F +49 341 42649 - 98
hoang.nguyen@ext.ewerk.com
www.ewerk.com
Geschäftsführer:
Dr. Erik Wende, Hendrik Schubert, Tassilo Möschke
Registergericht: Leipzig HRB 9065
Support:
+49 341 42649 555
Zertifiziert nach:
ISO/IEC 27001:2013
DIN EN ISO 9001:2015
DIN ISO/IEC 20000-1:2018
ISAE 3402 Typ II Assessed
EWERK-Blog<https://blog.ewerk.com/> | LinkedIn<https://www.linkedin.com/company/ewerk-group> | Xing<https://www.xing.com/company/ewerk> | Twitter<https://twitter.com/EWERK_Group> | Facebook<https://de-de.facebook.com/EWERK.Group/>
Auskünfte und Angebote per Mail sind freibleibend und unverbindlich.
Disclaimer Privacy:
Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter Dateien) ist vertraulich und nur für den Empfänger bestimmt. Sollten Sie nicht der bestimmungsgemäße Empfänger sein, ist Ihnen jegliche Offenlegung, Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte informieren Sie in diesem Fall unverzüglich den Absender und löschen Sie die E-Mail (einschließlich etwaiger beigefügter Dateien) von Ihrem System. Vielen Dank.
The contents of this e-mail (including any attachments) are confidential and may be legally privileged. If you are not the intended recipient of this e-mail, any disclosure, copying, distribution or use of its contents is strictly prohibited, and you should please notify the sender immediately and then delete it (including any attachments) from your system. Thank you.