Re: [VOTE] Apache Cloudstack 4.16.0.0 RC1
Thanks Daniel and Paul for your feedback. The issue with changelog was related to having the Spanish locale set, will make sure it will be fixed on RC2. Will analyze the proposals for the other issues you have described. Regards, Nicolas Vazquez From: Daniel Augusto Veronezi Salvador Sent: Wednesday, October 20, 2021 3:52 PM To: dev@cloudstack.apache.org Subject: Re: [VOTE] Apache Cloudstack 4.16.0.0 RC1 Paul, I see, I am not familiar with the details of VMware SDK JARs. However, to avoid mixing things up I suggest we create an issue to discuss this topic in the future. What I pointed out is that the process of downloading system VMs templates was added in the "noredist" profile, which is, right now, used to build ACS with VMware JARs (not judging if we need or not to handle this process in an isolated profile). I then suggested to separate that process into specific build profiles, so we can activate/deactivate the download process whenever we want, and also to avoid mix this process (download of system VMs templates) with VMware JAR packaging. Best regards, Daniel Salvador On 20/10/2021 15:37, Paul Angus wrote: > Thanks Daniel, > > My point is that I'm not sure that the VMware jars _need_ to be noredist, > which would simplify things for everyone. > > Kind Regards > > > Paul Angus > > -Original Message- > From: Daniel Augusto Veronezi Salvador > Sent: Wednesday, October 20, 2021 6:20 PM > To: dev@cloudstack.apache.org > Subject: Re: [VOTE] Apache Cloudstack 4.16.0.0 RC1 > > Paul, > > > Noredist packages are only necessary to VMWare. > > KVM/XenServer infrastructures don't use noredist packages. > > > Best regards, > Daniel Salvador > > On 20/10/2021 12:29, Paul Angus wrote: >> I vaguely thought that the VMware jars come under a compatible license these >> days, so don't need to be noredist anymore? >> >> >> -Original Message- >> From: Daniel Augusto Veronezi Salvador >> Sent: Wednesday, October 20, 2021 2:53 PM >> To: dev@cloudstack.apache.org >> Subject: Re: [VOTE] Apache Cloudstack 4.16.0.0 RC1 >> >> Hi Nicolas, thanks for the work. >> >> I started testing this RC and unfortunately I ran into some problems related >> to building/upgrading ACS. >> >>From the less to the more complex: >> >> - When building ".deb", there is a problem with the Debian changelog: >> invalid weekday 'lun'; >> >> - Regarding auto upgrading "systemvms-templates", I analyzed the code and >> concluded that "systemvms-templates" will only "autoupgrade" if we use the >> profile "noredist" when building the packages, which is necessary only to >> VMWare. Some people, might not want the noredist JARs, and therefore will >> not build with this profile. With that said, there are some points regarding >> it that I think are important: >> - Package "cloudstack-management" goes from ~100Mb to more than 1.5Gb, >> when using "noredist" while executing the 4.16.0.0 build. It happens due to >> "cloudstack/engine/schema/pom.xml" automatically downloading XenServer, KVM, >> and VMware "systemvms-templates". Every time that we build the packages, it >> will download all these systemvms-templates; we are unable to decide which >> one is necessary or not. If we do not use XenServer, or other hypervisors, >> why download it? >> - If we build the packages with "noredist", when we are first running >> ACS after upgrading it to 4.16, it will try to autoupgrade the >> systemvms-templates, however, some KVM/XenServer infrastructures don't allow >> the management server to access the secondary storage directly (except for >> the first systemvm-template seed). This will cause >> "mount.nfs: access denied by server while mounting ". >> After generating this error, ACS continues the upgrade and updates the >> database; however, the new systemvm-template will not be in the secondary >> storage. If we try to deploy a system (like virtual router), it will fail >> (as expected). >> - I rolled back my environment to 4.15, did a manual seed of >> systemvmtemplate-4.16.0-kvm.qcow2.bz2, built the packages without "noredist" >> and tried to upgrade the environment to 4.16. Then, ACS automatically tried >> to upgrade the systemvm-templates; even though the system VM template for >> 4.16 is already there, it throws some errors: >> >> 2021-10-19 23:08:02,684 DEBUG [c.c.u.d.Upgrade41520to41600] (main:null) >> (logid:) Updating System Vm template IDs >> 2021-10-19 23:08:02,904 DEBUG [c.c.u.SystemVmTemplateRegistration] >> (main:null) (logid:) Updating System Vm template IDs >> 2021-10-19 23:08:02,910 DEBUG [c.c.u.SystemVmTemplateRegistration] >> (main:null) (logid:) Updating VMware System Vms >> 2021-10-19 23:08:02,915 WARN [c.c.u.SystemVmTemplateRegistration] >> (main:null) (logid:) 4.16.0 VMware SystemVm template not found. Cannot >> upgrade system Vms hypervisor is not used, so not failing upgrade >> 2021-10-19 23:08:02,962 DEBUG
Re: [VOTE] Apache Cloudstack 4.16.0.0 RC1
Paul, I see, I am not familiar with the details of VMware SDK JARs. However, to avoid mixing things up I suggest we create an issue to discuss this topic in the future. What I pointed out is that the process of downloading system VMs templates was added in the "noredist" profile, which is, right now, used to build ACS with VMware JARs (not judging if we need or not to handle this process in an isolated profile). I then suggested to separate that process into specific build profiles, so we can activate/deactivate the download process whenever we want, and also to avoid mix this process (download of system VMs templates) with VMware JAR packaging. Best regards, Daniel Salvador On 20/10/2021 15:37, Paul Angus wrote: Thanks Daniel, My point is that I'm not sure that the VMware jars _need_ to be noredist, which would simplify things for everyone. Kind Regards Paul Angus -Original Message- From: Daniel Augusto Veronezi Salvador Sent: Wednesday, October 20, 2021 6:20 PM To: dev@cloudstack.apache.org Subject: Re: [VOTE] Apache Cloudstack 4.16.0.0 RC1 Paul, Noredist packages are only necessary to VMWare. KVM/XenServer infrastructures don't use noredist packages. Best regards, Daniel Salvador On 20/10/2021 12:29, Paul Angus wrote: I vaguely thought that the VMware jars come under a compatible license these days, so don't need to be noredist anymore? -Original Message- From: Daniel Augusto Veronezi Salvador Sent: Wednesday, October 20, 2021 2:53 PM To: dev@cloudstack.apache.org Subject: Re: [VOTE] Apache Cloudstack 4.16.0.0 RC1 Hi Nicolas, thanks for the work. I started testing this RC and unfortunately I ran into some problems related to building/upgrading ACS. From the less to the more complex: - When building ".deb", there is a problem with the Debian changelog: invalid weekday 'lun'; - Regarding auto upgrading "systemvms-templates", I analyzed the code and concluded that "systemvms-templates" will only "autoupgrade" if we use the profile "noredist" when building the packages, which is necessary only to VMWare. Some people, might not want the noredist JARs, and therefore will not build with this profile. With that said, there are some points regarding it that I think are important: - Package "cloudstack-management" goes from ~100Mb to more than 1.5Gb, when using "noredist" while executing the 4.16.0.0 build. It happens due to "cloudstack/engine/schema/pom.xml" automatically downloading XenServer, KVM, and VMware "systemvms-templates". Every time that we build the packages, it will download all these systemvms-templates; we are unable to decide which one is necessary or not. If we do not use XenServer, or other hypervisors, why download it? - If we build the packages with "noredist", when we are first running ACS after upgrading it to 4.16, it will try to autoupgrade the systemvms-templates, however, some KVM/XenServer infrastructures don't allow the management server to access the secondary storage directly (except for the first systemvm-template seed). This will cause "mount.nfs: access denied by server while mounting ". After generating this error, ACS continues the upgrade and updates the database; however, the new systemvm-template will not be in the secondary storage. If we try to deploy a system (like virtual router), it will fail (as expected). - I rolled back my environment to 4.15, did a manual seed of systemvmtemplate-4.16.0-kvm.qcow2.bz2, built the packages without "noredist" and tried to upgrade the environment to 4.16. Then, ACS automatically tried to upgrade the systemvm-templates; even though the system VM template for 4.16 is already there, it throws some errors: 2021-10-19 23:08:02,684 DEBUG [c.c.u.d.Upgrade41520to41600] (main:null) (logid:) Updating System Vm template IDs 2021-10-19 23:08:02,904 DEBUG [c.c.u.SystemVmTemplateRegistration] (main:null) (logid:) Updating System Vm template IDs 2021-10-19 23:08:02,910 DEBUG [c.c.u.SystemVmTemplateRegistration] (main:null) (logid:) Updating VMware System Vms 2021-10-19 23:08:02,915 WARN [c.c.u.SystemVmTemplateRegistration] (main:null) (logid:) 4.16.0 VMware SystemVm template not found. Cannot upgrade system Vms hypervisor is not used, so not failing upgrade 2021-10-19 23:08:02,962 DEBUG [c.c.u.SystemVmTemplateRegistration] (main:null) (logid:) Updating KVM System Vms 2021-10-19 23:08:02,966 INFO [c.c.u.SystemVmTemplateRegistration] (main:null) (logid:) Grabbing lock to register templates. 2021-10-19 23:08:02,976 ERROR [c.c.u.SystemVmTemplateRegistration] (main:null) (logid:) Failed to calculate template checksum java.nio.file.NoSuchFileException: /usr/share/cloudstack-management/templates/systemvm/systemvmtemplate-4.16.0-kvm.qcow2.bz2 at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92) at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111) at
RE: [VOTE] Apache Cloudstack 4.16.0.0 RC1
Thanks Daniel, My point is that I'm not sure that the VMware jars _need_ to be noredist, which would simplify things for everyone. Kind Regards Paul Angus -Original Message- From: Daniel Augusto Veronezi Salvador Sent: Wednesday, October 20, 2021 6:20 PM To: dev@cloudstack.apache.org Subject: Re: [VOTE] Apache Cloudstack 4.16.0.0 RC1 Paul, Noredist packages are only necessary to VMWare. KVM/XenServer infrastructures don't use noredist packages. Best regards, Daniel Salvador On 20/10/2021 12:29, Paul Angus wrote: > I vaguely thought that the VMware jars come under a compatible license these > days, so don't need to be noredist anymore? > > > -Original Message- > From: Daniel Augusto Veronezi Salvador > Sent: Wednesday, October 20, 2021 2:53 PM > To: dev@cloudstack.apache.org > Subject: Re: [VOTE] Apache Cloudstack 4.16.0.0 RC1 > > Hi Nicolas, thanks for the work. > > I started testing this RC and unfortunately I ran into some problems related > to building/upgrading ACS. > > From the less to the more complex: > > - When building ".deb", there is a problem with the Debian changelog: > invalid weekday 'lun'; > > - Regarding auto upgrading "systemvms-templates", I analyzed the code and > concluded that "systemvms-templates" will only "autoupgrade" if we use the > profile "noredist" when building the packages, which is necessary only to > VMWare. Some people, might not want the noredist JARs, and therefore will not > build with this profile. With that said, there are some points regarding it > that I think are important: > - Package "cloudstack-management" goes from ~100Mb to more than 1.5Gb, > when using "noredist" while executing the 4.16.0.0 build. It happens due to > "cloudstack/engine/schema/pom.xml" automatically downloading XenServer, KVM, > and VMware "systemvms-templates". Every time that we build the packages, it > will download all these systemvms-templates; we are unable to decide which > one is necessary or not. If we do not use XenServer, or other hypervisors, > why download it? > - If we build the packages with "noredist", when we are first running > ACS after upgrading it to 4.16, it will try to autoupgrade the > systemvms-templates, however, some KVM/XenServer infrastructures don't allow > the management server to access the secondary storage directly (except for > the first systemvm-template seed). This will cause > "mount.nfs: access denied by server while mounting ". > After generating this error, ACS continues the upgrade and updates the > database; however, the new systemvm-template will not be in the secondary > storage. If we try to deploy a system (like virtual router), it will fail (as > expected). > - I rolled back my environment to 4.15, did a manual seed of > systemvmtemplate-4.16.0-kvm.qcow2.bz2, built the packages without "noredist" > and tried to upgrade the environment to 4.16. Then, ACS automatically tried > to upgrade the systemvm-templates; even though the system VM template for > 4.16 is already there, it throws some errors: > > 2021-10-19 23:08:02,684 DEBUG [c.c.u.d.Upgrade41520to41600] (main:null) > (logid:) Updating System Vm template IDs > 2021-10-19 23:08:02,904 DEBUG [c.c.u.SystemVmTemplateRegistration] > (main:null) (logid:) Updating System Vm template IDs > 2021-10-19 23:08:02,910 DEBUG [c.c.u.SystemVmTemplateRegistration] > (main:null) (logid:) Updating VMware System Vms > 2021-10-19 23:08:02,915 WARN [c.c.u.SystemVmTemplateRegistration] > (main:null) (logid:) 4.16.0 VMware SystemVm template not found. Cannot > upgrade system Vms hypervisor is not used, so not failing upgrade > 2021-10-19 23:08:02,962 DEBUG [c.c.u.SystemVmTemplateRegistration] > (main:null) (logid:) Updating KVM System Vms > 2021-10-19 23:08:02,966 INFO [c.c.u.SystemVmTemplateRegistration] > (main:null) (logid:) Grabbing lock to register templates. > 2021-10-19 23:08:02,976 ERROR [c.c.u.SystemVmTemplateRegistration] > (main:null) (logid:) Failed to calculate template checksum > java.nio.file.NoSuchFileException: > /usr/share/cloudstack-management/templates/systemvm/systemvmtemplate-4.16.0-kvm.qcow2.bz2 > at > java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92) > at > java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111) > at > java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116) > at > java.base/sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:219) > at java.base/java.nio.file.Files.newByteChannel(Files.java:371) > at java.base/java.nio.file.Files.newByteChannel(Files.java:422) > at > java.base/java.nio.file.spi.FileSystemProvider.newInputStream(FileSystemProvider.java:420) > at java.base/java.nio.file.Files.newInputStream(Files.java:156) > at > com.cloud.upgrade.SystemVmTemplateRegistration.calculateChecksum(SystemVmTemplateRegistration.java:330) > at >
Re: [VOTE] Apache Cloudstack 4.16.0.0 RC1
Paul, Noredist packages are only necessary to VMWare. KVM/XenServer infrastructures don't use noredist packages. Best regards, Daniel Salvador On 20/10/2021 12:29, Paul Angus wrote: I vaguely thought that the VMware jars come under a compatible license these days, so don't need to be noredist anymore? -Original Message- From: Daniel Augusto Veronezi Salvador Sent: Wednesday, October 20, 2021 2:53 PM To: dev@cloudstack.apache.org Subject: Re: [VOTE] Apache Cloudstack 4.16.0.0 RC1 Hi Nicolas, thanks for the work. I started testing this RC and unfortunately I ran into some problems related to building/upgrading ACS. From the less to the more complex: - When building ".deb", there is a problem with the Debian changelog: invalid weekday 'lun'; - Regarding auto upgrading "systemvms-templates", I analyzed the code and concluded that "systemvms-templates" will only "autoupgrade" if we use the profile "noredist" when building the packages, which is necessary only to VMWare. Some people, might not want the noredist JARs, and therefore will not build with this profile. With that said, there are some points regarding it that I think are important: - Package "cloudstack-management" goes from ~100Mb to more than 1.5Gb, when using "noredist" while executing the 4.16.0.0 build. It happens due to "cloudstack/engine/schema/pom.xml" automatically downloading XenServer, KVM, and VMware "systemvms-templates". Every time that we build the packages, it will download all these systemvms-templates; we are unable to decide which one is necessary or not. If we do not use XenServer, or other hypervisors, why download it? - If we build the packages with "noredist", when we are first running ACS after upgrading it to 4.16, it will try to autoupgrade the systemvms-templates, however, some KVM/XenServer infrastructures don't allow the management server to access the secondary storage directly (except for the first systemvm-template seed). This will cause "mount.nfs: access denied by server while mounting ". After generating this error, ACS continues the upgrade and updates the database; however, the new systemvm-template will not be in the secondary storage. If we try to deploy a system (like virtual router), it will fail (as expected). - I rolled back my environment to 4.15, did a manual seed of systemvmtemplate-4.16.0-kvm.qcow2.bz2, built the packages without "noredist" and tried to upgrade the environment to 4.16. Then, ACS automatically tried to upgrade the systemvm-templates; even though the system VM template for 4.16 is already there, it throws some errors: 2021-10-19 23:08:02,684 DEBUG [c.c.u.d.Upgrade41520to41600] (main:null) (logid:) Updating System Vm template IDs 2021-10-19 23:08:02,904 DEBUG [c.c.u.SystemVmTemplateRegistration] (main:null) (logid:) Updating System Vm template IDs 2021-10-19 23:08:02,910 DEBUG [c.c.u.SystemVmTemplateRegistration] (main:null) (logid:) Updating VMware System Vms 2021-10-19 23:08:02,915 WARN [c.c.u.SystemVmTemplateRegistration] (main:null) (logid:) 4.16.0 VMware SystemVm template not found. Cannot upgrade system Vms hypervisor is not used, so not failing upgrade 2021-10-19 23:08:02,962 DEBUG [c.c.u.SystemVmTemplateRegistration] (main:null) (logid:) Updating KVM System Vms 2021-10-19 23:08:02,966 INFO [c.c.u.SystemVmTemplateRegistration] (main:null) (logid:) Grabbing lock to register templates. 2021-10-19 23:08:02,976 ERROR [c.c.u.SystemVmTemplateRegistration] (main:null) (logid:) Failed to calculate template checksum java.nio.file.NoSuchFileException: /usr/share/cloudstack-management/templates/systemvm/systemvmtemplate-4.16.0-kvm.qcow2.bz2 at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92) at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111) at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116) at java.base/sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:219) at java.base/java.nio.file.Files.newByteChannel(Files.java:371) at java.base/java.nio.file.Files.newByteChannel(Files.java:422) at java.base/java.nio.file.spi.FileSystemProvider.newInputStream(FileSystemProvider.java:420) at java.base/java.nio.file.Files.newInputStream(Files.java:156) at com.cloud.upgrade.SystemVmTemplateRegistration.calculateChecksum(SystemVmTemplateRegistration.java:330) at com.cloud.upgrade.SystemVmTemplateRegistration.validateTemplates(SystemVmTemplateRegistration.java:690) at com.cloud.upgrade.SystemVmTemplateRegistration.registerTemplates(SystemVmTemplateRegistration.java:713) at com.cloud.upgrade.SystemVmTemplateRegistration$5.doInTransactionWithoutResult(SystemVmTemplateRegistration.java:824) at com.cloud.utils.db.TransactionCallbackNoReturn.doInTransaction(TransactionCallbackNoReturn.java:25) at
Re: [cloudstack-go] sdk releasing
Hi Rohit, I've tried the approach when I did the release of cloudstack-go SDK v4.15.1. I had to remove it and create v2.10.0; The reason is captured here [1] Basically, because we call our go module cloudstack/v2 if we want to have release v4.x we would need to change our module to cloudstack/v4. I don't know how big of a deal this is to move from /v2 to /v4, on the other hand, why not get rid of the version in the module definition instead ? [1] https://github.com/apache/cloudstack-go/pull/7#issuecomment-918225329 [2] https://go.dev/blog/publishing-go-modules Regards, On Tue, Oct 19, 2021 at 3:57 AM Rohit Yadav wrote: > Hi All, cc PL > > I thought to check with the community for any objections, following PL's > approach for ACS 4.15.2 we've created: > https://github.com/apache/cloudstack-go/releases/tag/v2.11.0 > > Explicit testing/voting may not be necessary as it's largely autogenerated > against API of an ACS release and further it doesn't serve purpose in > itself but currently used by the CloudStack k8s provider and terrraform > provider which will be tested/voted against (indirectly testing/voting > these projects will also validate/test the go-sdk). > > Unless there are any objections, do we agree to tag the cloudstack-go repo > with tags against ACS releases using the approach PL started? > > Regards. > > > > > > -- > *From:* Rohit Yadav > *Sent:* Wednesday, September 8, 2021 13:49 > *To:* Pierre-Luc Dion ; dev < > dev@cloudstack.apache.org> > *Subject:* Re: [cloudstack-go] sdk releasing > > +1 > > That makes sense. In the go-sdk we've a generator that consumes the > listApis output of a ACS release and generates the library - > https://github.com/apache/cloudstack-go/tree/main/generate > > I suppose for every ACS release, we can update go-sdk with > release-specific API list, test it, release and tag it. Even automate this? > > I would say - no need to vote it unless the SDK is manually changed. Since > it is used with the k8s provider or the terraform provider so tags on > go-sdk may go in-line with tags/release of these users. > > Regards. > > > From: Pierre-Luc Dion > Sent: Friday, August 27, 2021 17:57 > To: Rohit Yadav ; dev < > dev@cloudstack.apache.org> > Subject: [cloudstack-go] sdk releasing > > I've messing around with cloudstack-go > > Did a fix that rohit merged yesturday for hostsservices, but this fix will > only work for acs4.15, I'd like to fix it for previous acs version too, but > look like the version of the SDK depend on acs version; > > Example; for the hostservices, the host attribute managementserverid is a > UUID in 4.15, but an integer in an older version of xenserver. This breaks > the structs,or map, we must have some other similar issue. > > so I'd like to help on creating a tag or version of the SDK so they would > match acs version target, > ie: SDK version = v4.15-0; where the last digit would define the sdk > version or increase with fixes. > Current versioning in use = > https://github.com/apache/cloudstack-go/releases > > The issue I'm expecting to face is if we create a release , let's say > v4.15-0 from main branch today, if we want to create v4.14.0, it will not > be possible from the main branch because we need to revert the last commit > but also fix hostservices. > > Here are a bunch of questions I have: > 1. Should we create a branch for older ACS versions and keep main for > latest fixes and future releases ? > 2. Do we need to vote for such changes? > 3. Does such releases could impact other Go projects that use this one, > such as terraform and kubernetes drivers? > 4. Should we provide similar versioning on our kubernetes driver? > > > > >
RE: [VOTE] Apache Cloudstack 4.16.0.0 RC1
I vaguely thought that the VMware jars come under a compatible license these days, so don't need to be noredist anymore? -Original Message- From: Daniel Augusto Veronezi Salvador Sent: Wednesday, October 20, 2021 2:53 PM To: dev@cloudstack.apache.org Subject: Re: [VOTE] Apache Cloudstack 4.16.0.0 RC1 Hi Nicolas, thanks for the work. I started testing this RC and unfortunately I ran into some problems related to building/upgrading ACS. From the less to the more complex: - When building ".deb", there is a problem with the Debian changelog: invalid weekday 'lun'; - Regarding auto upgrading "systemvms-templates", I analyzed the code and concluded that "systemvms-templates" will only "autoupgrade" if we use the profile "noredist" when building the packages, which is necessary only to VMWare. Some people, might not want the noredist JARs, and therefore will not build with this profile. With that said, there are some points regarding it that I think are important: - Package "cloudstack-management" goes from ~100Mb to more than 1.5Gb, when using "noredist" while executing the 4.16.0.0 build. It happens due to "cloudstack/engine/schema/pom.xml" automatically downloading XenServer, KVM, and VMware "systemvms-templates". Every time that we build the packages, it will download all these systemvms-templates; we are unable to decide which one is necessary or not. If we do not use XenServer, or other hypervisors, why download it? - If we build the packages with "noredist", when we are first running ACS after upgrading it to 4.16, it will try to autoupgrade the systemvms-templates, however, some KVM/XenServer infrastructures don't allow the management server to access the secondary storage directly (except for the first systemvm-template seed). This will cause "mount.nfs: access denied by server while mounting ". After generating this error, ACS continues the upgrade and updates the database; however, the new systemvm-template will not be in the secondary storage. If we try to deploy a system (like virtual router), it will fail (as expected). - I rolled back my environment to 4.15, did a manual seed of systemvmtemplate-4.16.0-kvm.qcow2.bz2, built the packages without "noredist" and tried to upgrade the environment to 4.16. Then, ACS automatically tried to upgrade the systemvm-templates; even though the system VM template for 4.16 is already there, it throws some errors: 2021-10-19 23:08:02,684 DEBUG [c.c.u.d.Upgrade41520to41600] (main:null) (logid:) Updating System Vm template IDs 2021-10-19 23:08:02,904 DEBUG [c.c.u.SystemVmTemplateRegistration] (main:null) (logid:) Updating System Vm template IDs 2021-10-19 23:08:02,910 DEBUG [c.c.u.SystemVmTemplateRegistration] (main:null) (logid:) Updating VMware System Vms 2021-10-19 23:08:02,915 WARN [c.c.u.SystemVmTemplateRegistration] (main:null) (logid:) 4.16.0 VMware SystemVm template not found. Cannot upgrade system Vms hypervisor is not used, so not failing upgrade 2021-10-19 23:08:02,962 DEBUG [c.c.u.SystemVmTemplateRegistration] (main:null) (logid:) Updating KVM System Vms 2021-10-19 23:08:02,966 INFO [c.c.u.SystemVmTemplateRegistration] (main:null) (logid:) Grabbing lock to register templates. 2021-10-19 23:08:02,976 ERROR [c.c.u.SystemVmTemplateRegistration] (main:null) (logid:) Failed to calculate template checksum java.nio.file.NoSuchFileException: /usr/share/cloudstack-management/templates/systemvm/systemvmtemplate-4.16.0-kvm.qcow2.bz2 at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92) at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111) at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116) at java.base/sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:219) at java.base/java.nio.file.Files.newByteChannel(Files.java:371) at java.base/java.nio.file.Files.newByteChannel(Files.java:422) at java.base/java.nio.file.spi.FileSystemProvider.newInputStream(FileSystemProvider.java:420) at java.base/java.nio.file.Files.newInputStream(Files.java:156) at com.cloud.upgrade.SystemVmTemplateRegistration.calculateChecksum(SystemVmTemplateRegistration.java:330) at com.cloud.upgrade.SystemVmTemplateRegistration.validateTemplates(SystemVmTemplateRegistration.java:690) at com.cloud.upgrade.SystemVmTemplateRegistration.registerTemplates(SystemVmTemplateRegistration.java:713) at com.cloud.upgrade.SystemVmTemplateRegistration$5.doInTransactionWithoutResult(SystemVmTemplateRegistration.java:824) at com.cloud.utils.db.TransactionCallbackNoReturn.doInTransaction(TransactionCallbackNoReturn.java:25) at com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:50) at com.cloud.utils.db.Transaction.execute(Transaction.java:40) at com.cloud.utils.db.Transaction.execute(Transaction.java:47) at
Network Selection in ACS
Hello We have implemented ACS to sell public cloud. Need guidance on which network we should implement while creating the instance. Assuming LB and Firewall features we can provide to the users only when we have the isolated network but when creating the isolated network one public IP address is getting assigned to source-nat and separate IP is assigned to the VM. In this case we have to waste 1 IP address for each network. So tomorrow let suppose we have 1000 users and each will have their own individual isolated network, in this case 1000 IP's will be wasted. Can someone please guide here what process we should follow so IP's can be saved while creating the networks. Also, considering our requirement if there is any other approach then please let me know. Thanks in Advance. Regards Saurabh
New Terraform artifacts published for testing
Hi All, We have published the new artifacts to the Terraform registry https://registry.terraform.io/providers/cloudstack/cloudstack/latest. These are created only for testing purposes with tag v0.4.0-pre. May I ask the terraform users to help in testing it and report if you find any issues here at on https://github.com/apache/cloudstack-terraform-provider/issues? We have already fixed some issues and done some testing. If everything goes well we can create RC1 in the next week or so. Regards, Harikrishna
Re: [VOTE] Apache Cloudstack 4.16.0.0 RC1
Hi Nicolas, thanks for the work. I started testing this RC and unfortunately I ran into some problems related to building/upgrading ACS. From the less to the more complex: - When building ".deb", there is a problem with the Debian changelog: invalid weekday 'lun'; - Regarding auto upgrading "systemvms-templates", I analyzed the code and concluded that "systemvms-templates" will only "autoupgrade" if we use the profile "noredist" when building the packages, which is necessary only to VMWare. Some people, might not want the noredist JARs, and therefore will not build with this profile. With that said, there are some points regarding it that I think are important: - Package "cloudstack-management" goes from ~100Mb to more than 1.5Gb, when using "noredist" while executing the 4.16.0.0 build. It happens due to "cloudstack/engine/schema/pom.xml" automatically downloading XenServer, KVM, and VMware "systemvms-templates". Every time that we build the packages, it will download all these systemvms-templates; we are unable to decide which one is necessary or not. If we do not use XenServer, or other hypervisors, why download it? - If we build the packages with "noredist", when we are first running ACS after upgrading it to 4.16, it will try to autoupgrade the systemvms-templates, however, some KVM/XenServer infrastructures don't allow the management server to access the secondary storage directly (except for the first systemvm-template seed). This will cause "mount.nfs: access denied by server while mounting ". After generating this error, ACS continues the upgrade and updates the database; however, the new systemvm-template will not be in the secondary storage. If we try to deploy a system (like virtual router), it will fail (as expected). - I rolled back my environment to 4.15, did a manual seed of systemvmtemplate-4.16.0-kvm.qcow2.bz2, built the packages without "noredist" and tried to upgrade the environment to 4.16. Then, ACS automatically tried to upgrade the systemvm-templates; even though the system VM template for 4.16 is already there, it throws some errors: 2021-10-19 23:08:02,684 DEBUG [c.c.u.d.Upgrade41520to41600] (main:null) (logid:) Updating System Vm template IDs 2021-10-19 23:08:02,904 DEBUG [c.c.u.SystemVmTemplateRegistration] (main:null) (logid:) Updating System Vm template IDs 2021-10-19 23:08:02,910 DEBUG [c.c.u.SystemVmTemplateRegistration] (main:null) (logid:) Updating VMware System Vms 2021-10-19 23:08:02,915 WARN [c.c.u.SystemVmTemplateRegistration] (main:null) (logid:) 4.16.0 VMware SystemVm template not found. Cannot upgrade system Vms hypervisor is not used, so not failing upgrade 2021-10-19 23:08:02,962 DEBUG [c.c.u.SystemVmTemplateRegistration] (main:null) (logid:) Updating KVM System Vms 2021-10-19 23:08:02,966 INFO [c.c.u.SystemVmTemplateRegistration] (main:null) (logid:) Grabbing lock to register templates. 2021-10-19 23:08:02,976 ERROR [c.c.u.SystemVmTemplateRegistration] (main:null) (logid:) Failed to calculate template checksum java.nio.file.NoSuchFileException: /usr/share/cloudstack-management/templates/systemvm/systemvmtemplate-4.16.0-kvm.qcow2.bz2 at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92) at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111) at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116) at java.base/sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:219) at java.base/java.nio.file.Files.newByteChannel(Files.java:371) at java.base/java.nio.file.Files.newByteChannel(Files.java:422) at java.base/java.nio.file.spi.FileSystemProvider.newInputStream(FileSystemProvider.java:420) at java.base/java.nio.file.Files.newInputStream(Files.java:156) at com.cloud.upgrade.SystemVmTemplateRegistration.calculateChecksum(SystemVmTemplateRegistration.java:330) at com.cloud.upgrade.SystemVmTemplateRegistration.validateTemplates(SystemVmTemplateRegistration.java:690) at com.cloud.upgrade.SystemVmTemplateRegistration.registerTemplates(SystemVmTemplateRegistration.java:713) at com.cloud.upgrade.SystemVmTemplateRegistration$5.doInTransactionWithoutResult(SystemVmTemplateRegistration.java:824) at com.cloud.utils.db.TransactionCallbackNoReturn.doInTransaction(TransactionCallbackNoReturn.java:25) at com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:50) at com.cloud.utils.db.Transaction.execute(Transaction.java:40) at com.cloud.utils.db.Transaction.execute(Transaction.java:47) at com.cloud.upgrade.SystemVmTemplateRegistration.updateSystemVmTemplates(SystemVmTemplateRegistration.java:802) at com.cloud.upgrade.dao.Upgrade41520to41600.updateSystemVmTemplates(Upgrade41520to41600.java:105) at com.cloud.upgrade.DatabaseUpgradeChecker.updateSystemVmTemplates(DatabaseUpgradeChecker.java:258) at
[GitHub] [cloudstack-terraform-provider] rhtyd merged pull request #10: Fix or update dependencies
rhtyd merged pull request #10: URL: https://github.com/apache/cloudstack-terraform-provider/pull/10 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@cloudstack.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [cloudstack-terraform-provider] harikrishna-patnala opened a new pull request #10: Fix or update dependencies
harikrishna-patnala opened a new pull request #10: URL: https://github.com/apache/cloudstack-terraform-provider/pull/10 'go mod tidy' fixes the dependencies. Also added new cloudstack-go version. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@cloudstack.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [cloudstack-go] rhtyd merged pull request #18: Cleanup tests
rhtyd merged pull request #18: URL: https://github.com/apache/cloudstack-go/pull/18 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@cloudstack.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: Network selection specifically for Hosting provider
Hi, For each isolated network with source NAT, cloudstack assigns a public IP to the network as the source NAT IP. Therefore it is not an issue. To add secondary IPs, go to vm details -> NICs tab -> choose a NIC -> click icon 'Edit secondary IPs'. -Wei On Tue, 19 Oct 2021 at 23:35, Ranjit Jadhav wrote: > Hello guys, > > We are using Xenserver for host and configured Isolated Network . but > we are facing the following issues > > 1) One IP gets reserved for source-nat per user > > 2) How can we assign secondary IP to the instance. > > There are a few more issues/queries related to the network. > > Thanks and Regards, > Ranjit >
