Re: [VOTE] Apache Cloudstack 4.16.0.0 RC1
Thanks Rohit, I agree on documenting the secondary storage mount on the management server to avoid the issue (as you mentioned that's a known practice for seeding the system VM template). I think it is useful to bundle the 3 major system VM templates in the cloudstack-management package as it simplifies the upgrading process even though it increases significantly the size of the package. On that note, this PR created by Daniel: https://github.com/apache/cloudstack/pull/5602 is a great improvement for more granular control over the system VM templates to be downloaded and reducing the package size. However, I think it may introduce more complexity as administrators may want to use the auto-upgrade feature for their hypervisor, in which case we will need one package per hypervisor for the cloudstack-management package instead of simply one in which the 3 major system VM templates are included. On the original issue posted by Daniel, this PR has been tested and fixes the issue: https://github.com/apache/cloudstack/pull/5598. Regards, Nicolas Vazquez From: Rohit Yadav Sent: Thursday, October 21, 2021 1:17 PM To: dev@cloudstack.apache.org Subject: Re: [VOTE] Apache Cloudstack 4.16.0.0 RC1 All, Daniel, Paul, I had shared the Debian pkg changelog issue on this thread when I shared the convenience packages, it turns out Nicolas doesn't have en_* locale set as default which caused this when creating the release artifacts. The bundling of systemvmtemplates in cloudstack-management package is a feature to make ACS turnkey for users and assist in automatic upgrades/seeding. The trade-off of this feature is the increased size of the cloudstack-maangement package which may be optimised/reduced in the future. However, having look at the k8s binaries, ~1GB additional size does not sound like a big issue for most users with good Internet connections in their lab/datacenters. This further solves the issue of setting up ACS in environments where there's no/restricted Internet access (admin only needs to mirror the repos). For community convenience builds/packages it won't make sense to favour a specific hypervisor and that's why we bundle all of the three most popular hypervisors (Vmware, KVM, XenServer/XCP-ng). Since the project votes and releases source code, my understaind is we can't still bundle vmware/vim and other jars within the source code. However, I think most nonoss dependencies [2] we need with main/4.16 may be redistributable (someone from legal@ needs checking, the last thread I had started in private@ Mike helped got rid of the one know non-redist pkg/code). On the issue of 'noredist' build profile, it may not be needed as 'noredist' has been the default build profile and all the convenience packages built and hosted by the community and 3rd party servers [1] are noredist packages. Essentially you've two build profiles, one which is oss only and doesn't bundle nonoss components incl. systemvmtemplates, and noredist (we may discuss to change the name) which is all-included turnkey mvn build profile. The issue of secondary storage mounting/access on management server is a environment issue, we can document that but we implictly require that for two cases: (1) when seeding systevmtemplate for fresh installation (see docs that mention how/where to mount and seed it) and (2) for config drive feature to work (I don't remember if it's all of kvm, vmware, xenserver or only xenserver/vmware) we expect mgmt server to be able to mount secondary storage on mgmt server host. This PR https://github.com/apache/cloudstack/pull/5598, when oss packages are built (i.e. systemvmtemplates will not be bundled) should fix Daniel's issue, however, it then requires that systemvmtemplates are registered prior to the upgrade (like before). [1] https://cloudstack.apache.org/downloads.html [2] https://github.com/shapeblue/cloudstack-nonoss Regards. From: Nicolas Vazquez Sent: Thursday, October 21, 2021 04:06 To: dev@cloudstack.apache.org Subject: 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
Re: [VOTE] Apache Cloudstack 4.16.0.0 RC1
All, Daniel, Paul, I had shared the Debian pkg changelog issue on this thread when I shared the convenience packages, it turns out Nicolas doesn't have en_* locale set as default which caused this when creating the release artifacts. The bundling of systemvmtemplates in cloudstack-management package is a feature to make ACS turnkey for users and assist in automatic upgrades/seeding. The trade-off of this feature is the increased size of the cloudstack-maangement package which may be optimised/reduced in the future. However, having look at the k8s binaries, ~1GB additional size does not sound like a big issue for most users with good Internet connections in their lab/datacenters. This further solves the issue of setting up ACS in environments where there's no/restricted Internet access (admin only needs to mirror the repos). For community convenience builds/packages it won't make sense to favour a specific hypervisor and that's why we bundle all of the three most popular hypervisors (Vmware, KVM, XenServer/XCP-ng). Since the project votes and releases source code, my understaind is we can't still bundle vmware/vim and other jars within the source code. However, I think most nonoss dependencies [2] we need with main/4.16 may be redistributable (someone from legal@ needs checking, the last thread I had started in private@ Mike helped got rid of the one know non-redist pkg/code). On the issue of 'noredist' build profile, it may not be needed as 'noredist' has been the default build profile and all the convenience packages built and hosted by the community and 3rd party servers [1] are noredist packages. Essentially you've two build profiles, one which is oss only and doesn't bundle nonoss components incl. systemvmtemplates, and noredist (we may discuss to change the name) which is all-included turnkey mvn build profile. The issue of secondary storage mounting/access on management server is a environment issue, we can document that but we implictly require that for two cases: (1) when seeding systevmtemplate for fresh installation (see docs that mention how/where to mount and seed it) and (2) for config drive feature to work (I don't remember if it's all of kvm, vmware, xenserver or only xenserver/vmware) we expect mgmt server to be able to mount secondary storage on mgmt server host. This PR https://github.com/apache/cloudstack/pull/5598, when oss packages are built (i.e. systemvmtemplates will not be bundled) should fix Daniel's issue, however, it then requires that systemvmtemplates are registered prior to the upgrade (like before). [1] https://cloudstack.apache.org/downloads.html [2] https://github.com/shapeblue/cloudstack-nonoss Regards. From: Nicolas Vazquez Sent: Thursday, October 21, 2021 04:06 To: dev@cloudstack.apache.org Subject: 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
Re: Local simulation of Apache Cloudstack instances/API endpoints: state of the art, target groups and use cases
Hi Peter, For cloudstack simulator, you can use docker image from my repository: https://hub.docker.com/repository/docker/ustcweizhou/cloudstack-simulator It is not up-to-date. I will build a docker image for 4.16.0.0-RC1 later today. You can build your own image from source code as well. -Wei On Thu, 21 Oct 2021 at 12:32, Muryshkin, Peter < peter.murysh...@zv.fraunhofer.de> wrote: > Hi all, > > from what I can find, there are three more or less established/already > well elaborated approaches to simulate a CloudStack instance locallly. > Depending on the target group and their goals, they can have different > levels of fidelity and usability. > > 1. Obviously CloudStack developers confgure a KVM development environment > to work inside it, this is part of the Apache CloudStack Hackerbook kindly > shared by ShapeBlue. [1] > 2. For test scenarios, Hackerbook describes a mocked simulator approach [2] > 3. For users for whom the whole cloud system is just a "black box", > especially cloud beginners, there is a single integrated Docker container. > [3] > > With the rise of CI/CD and infrastructure as code automation practices, > where you just need more or less on demand one or even many versions of the > CloudStack API, > [3] appears to be a crucial building block in the cloud userspace before > just "trying out CloudStack". > > So it appears that there might be much demand on a Apache CloudStack > containerized instance: > > 1. Demand from potential new adopters, for their "Apache CloudStack to go" > demos > 2. Demand from DevOps/GitOps/SRE/you-name-it enabled teams who implement > their virtual infrastructure for example with Terraform and the CloudStack > provider plugin and want to simulate rollout scenarios. > > However, is this true? > > * the container simulator hasn't been updated on DockerHub since a couple > of years; is there another place in meantime or will this approach dumped > for some reason? > * there is not so much discussion about this asset on mailing lists; so > there is not so much demand as one might assume? > > What do you think? > > kind regards > > -- > > Peter Muryshkin > Fraunhofer Gesellschaft > https://www.linkedin.com/in/muryshkin/
RE: Local simulation of Apache Cloudstack instances/API endpoints: state of the art, target groups and use cases
Hi Peter, I need to get round to polishing a dockerfile that would create an image to be run as a CloudStack simulator in a container (or if there's enough interest I could share it's current state for others to finish). But. If you want to work on real world integrations, I'd guess that you would likely to need real hosts to create VMs on. Trillian (https://github.com/shapeblue/trillian) was created for the exact purpose that you are describing. In fact it runs most of the automated testing done on CloudStack. And can support 10s even 100s of concurrent environments. I'm not going to lie - it takes a bit of setting up (and isn't local) - but it's run thousands of times creating environments for testing business logic and integrations Regards Paul Angus -Original Message- From: Muryshkin, Peter Sent: Thursday, October 21, 2021 11:30 AM To: dev@cloudstack.apache.org; us...@cloudstack.apache.org Subject: Local simulation of Apache Cloudstack instances/API endpoints: state of the art, target groups and use cases Hi all, from what I can find, there are three more or less established/already well elaborated approaches to simulate a CloudStack instance locallly. Depending on the target group and their goals, they can have different levels of fidelity and usability. 1. Obviously CloudStack developers confgure a KVM development environment to work inside it, this is part of the Apache CloudStack Hackerbook kindly shared by ShapeBlue. [1] 2. For test scenarios, Hackerbook describes a mocked simulator approach [2] 3. For users for whom the whole cloud system is just a "black box", especially cloud beginners, there is a single integrated Docker container. [3] With the rise of CI/CD and infrastructure as code automation practices, where you just need more or less on demand one or even many versions of the CloudStack API, [3] appears to be a crucial building block in the cloud userspace before just "trying out CloudStack". So it appears that there might be much demand on a Apache CloudStack containerized instance: 1. Demand from potential new adopters, for their "Apache CloudStack to go" demos 2. Demand from DevOps/GitOps/SRE/you-name-it enabled teams who implement their virtual infrastructure for example with Terraform and the CloudStack provider plugin and want to simulate rollout scenarios. However, is this true? * the container simulator hasn't been updated on DockerHub since a couple of years; is there another place in meantime or will this approach dumped for some reason? * there is not so much discussion about this asset on mailing lists; so there is not so much demand as one might assume? What do you think? kind regards -- Peter Muryshkin Fraunhofer Gesellschaft https://www.linkedin.com/in/muryshkin/
Local simulation of Apache Cloudstack instances/API endpoints: state of the art, target groups and use cases
Hi all, from what I can find, there are three more or less established/already well elaborated approaches to simulate a CloudStack instance locallly. Depending on the target group and their goals, they can have different levels of fidelity and usability. 1. Obviously CloudStack developers confgure a KVM development environment to work inside it, this is part of the Apache CloudStack Hackerbook kindly shared by ShapeBlue. [1] 2. For test scenarios, Hackerbook describes a mocked simulator approach [2] 3. For users for whom the whole cloud system is just a "black box", especially cloud beginners, there is a single integrated Docker container. [3] With the rise of CI/CD and infrastructure as code automation practices, where you just need more or less on demand one or even many versions of the CloudStack API, [3] appears to be a crucial building block in the cloud userspace before just "trying out CloudStack". So it appears that there might be much demand on a Apache CloudStack containerized instance: 1. Demand from potential new adopters, for their "Apache CloudStack to go" demos 2. Demand from DevOps/GitOps/SRE/you-name-it enabled teams who implement their virtual infrastructure for example with Terraform and the CloudStack provider plugin and want to simulate rollout scenarios. However, is this true? * the container simulator hasn't been updated on DockerHub since a couple of years; is there another place in meantime or will this approach dumped for some reason? * there is not so much discussion about this asset on mailing lists; so there is not so much demand as one might assume? What do you think? kind regards -- Peter Muryshkin Fraunhofer Gesellschaft https://www.linkedin.com/in/muryshkin/
RE: New Terraform artifacts published for testing
Hi Harikrishna! I test this provider strongly and so far I have not found any errors (eg work as expected). But I have a question, do you plan to adapt this provider's capabilities to the new CS 4.16 and kubernetes plugin? I am very interested in setting up a K8S cluster using CS (preferably with kubernetes plugin) with terraform (or CS + kubespray + terraform without plugin). Will this privider be published (along with the documentation) in registry.terraform.io? Any roadmap? :-) Regards, Piotr -Original Message- From: Harikrishna Patnala Sent: Wednesday, October 20, 2021 4:12 PM To: 'us...@cloudstack.apache.org' Cc: dev@cloudstack.apache.org Subject: 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: [cloudstack-go] sdk releasing
Hi PL, I don't have an issue with the versioning/tagging of releases, I think we can continue to do the v2 for example for ACS 4.15.2 I see Pearl did https://github.com/apache/cloudstack-go/releases/tag/v2.11.0 My email was requesting community for comments/objections if we continue the approach you started do the tags without an explicit vote required. My suggestion is that it's not needed as the go-sdk can then in turn voted/tested with its currently known consumers: https://github.com/apache/cloudstack-terraform-provider https://github.com/apache/cloudstack-kubernetes-provider Regards. From: Pierre-Luc Dion Sent: Wednesday, October 20, 2021 22:13 To: Rohit Yadav Cc: dev Subject: 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 mailto:rohit.ya...@shapeblue.com>> 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 mailto:rohit.ya...@shapeblue.com>> Sent: Wednesday, September 8, 2021 13:49 To: Pierre-Luc Dion mailto:pdion...@apache.org>>; dev mailto: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 mailto:pdion...@apache.org>> Sent: Friday, August 27, 2021 17:57 To: Rohit Yadav mailto:rohit.ya...@shapeblue.com>>; dev mailto: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?
