Re: [DISCUSS] Primate - publishing release and docs
Thank you all for your feedback and suggestions. For the scope of the technical preview, I would like to conclude this thread that unless there are any objections there will be no formal voting, no formal release, and therefore no RCs etc. * Tech preview publishing: * Archive, deb, rpm here: http://download.cloudstack.org/primate/testing/preview/ (for tracking, builds will have date-stamps) * Docker builds here: https://hub.docker.com/r/apache/cloudstack-primate (marked :latest tag) * Primate technical preview documentation will be within the 4.14 docs website: * Documentation will be limited simple instructions on installing Primate tech preview (in most cases, few commands to download and install/extract artifact) * WIP doc pull request: https://github.com/apache/cloudstack-documentation/pull/122 * The 4.14 docs website (in release notes) and the announcement(s) will include legacy UI deprecation notice as previously discussed and agreed [1][2] * Feedback/issue gathering: * In addition to welcoming any discussion(s) on MLs, the footer of Primate will have a link to report issues, request missing features etc. until 1.0/GA https://github.com/apache/cloudstack-primate/issues/new/choose Let's discuss other points (outside of the scope for the tech preview) in a different thread (after 4.14) over the next weeks/months towards 1.0/GA (with ACS 4.15). Any objections? Thanks. Additional notes and updates: * Daily builds for the latest master are rsync'd here: http://download.cloudstack.org/primate/testing/master/ * Blueorangutan is now setup for Primate pull requests, we'll explore testing towards 1.0/GA. [1] Voting thread: https://markmail.org/message/tblrbrtew6cvrusr [2] Proposal: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Proposal%3A+CloudStack+Primate+UI Regards, Rohit Yadav Software Architect, ShapeBlue https://www.shapeblue.com From: Andrija Panic Sent: Monday, May 11, 2020 19:23 To: users Cc: dev Subject: Re: [DISCUSS] Primate - publishing release and docs Hi Rohit, I have no major remarks on what you've already shared/proposed, besides a few things: - From user-perspective (even though ACS and Primate are separate projects) - in my opinion, we should keep al Primate documentation together with CloudStack documentation, so that a user can see everything in one place (single place of truth) - this means keeping the Primate WIKI as "empty" as possible (i.e. the WIKI page can contain links back to the docs.cloudstack.apache.org, beside's some DEV specifics that you might want to keep in WIKI only) - For the Technical preview, I would agree with skipping the official voting process now, as it's "just" a preview - once we have this release ready, I would be happy to see those links/instructions in the official 4.14 documentation - I still think we should use the originally proposed naming convention for nightly build - in case we ever decide to support different branches of Primate (for whatever reason) - and for the official/voted builds - I don't see any issues keeping the timestamp (some package vendrods/devs do that), though it looks more polished if we remove the date stamp for these official builds. - For official releases of Primate (delivered with i.e. ACS 4.15 in figure), we should carefully craft folder structure on download.cloudstack.apache.org to make it easy for end-user to know which specific Primate version is shipped/voted to work with a specific CloudStack version (as we most probably won't be bundling that with the cloudstack-management RPM/DEB packages) Regards, Andrija rohit.ya...@shapeblue.com www.shapeblue.com 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK @shapeblue On Mon, 11 May 2020 at 11:04, Sven Vogel wrote: > Hi Rohit, Hi Daan, > > 1. Documentation for tech preview > > I agree with Rohit. For me the both suggestions with links sound like a > good idea. We should add the download links for official releases or > installations for each method on both sites. Maybe its a good idea to have > both in sync to we save us the double work. How can we get them in sync? An > important point is always the double work. So if there is a method to get > them fast in sync in see no problem but if there is many hand work to do > maybe its easier to refer from wiki -> to readthedocs or vice versa. I > would like to prevent outdated docs on one place. > > @Daan > I think Primate should be documented by means of help pop-ups with links to > the underlaying API and admin docs. How big do you expect this > documentation to become? (I would think it is only a short readme on first > use) > > — How could this work? Where we could find the help pop-ups and where > should they located? > > >
[GitHub] [cloudstack-primate] utchoang commented on pull request #320: Explore Test Automation
utchoang commented on pull request #320: URL: https://github.com/apache/cloudstack-primate/pull/320#issuecomment-630077683 * Views > AutogenView.vue - processing 43%  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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [cloudstack-primate] rhtyd opened a new issue #344: [BUG] Add secondary storage form passes zone name and not zoneid
rhtyd opened a new issue #344: URL: https://github.com/apache/cloudstack-primate/issues/344 **Describe the bug** Add secondary storage form does not pass zone ID in the URL request but zone name and the API/action fails. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [VOTE] Apache CloudStack 4.14.0.0 RC3
The issue sounds severe enough that a release note probably won't suffice - unless there's a documented way to recover we'd never want to leave a system susceptible to being unrecoverable, even if it's rarely triggered. What's involved in "failing gracefully"? Is this a small fix, or an overhaul? Perhaps the new feature could be disabled for VMware, or disabled altogether until a fix is made in a patch release. Does it only affect new templates, or is there a risk that an existing template out in vSphere could suddenly cause problems? On Mon, May 18, 2020 at 12:49 AM Boris Stoyanov < boris.stoya...@shapeblue.com> wrote: > Hi guys, > > A little further info on this, it appears when we use a corrupted template > and UEFI/Legacy mode when deploy a VM, it breaks the connection between > cloudstack and vCenter. > > All hosts become unreachable and basically the cluster is not functional, > have not investigated a way to recover this but seems like a huge mess.. > Please note that user is not able to register such template in vCenter > directly, but cloudstack allows using it. > > Open to discuss if we'll fix this, since it's expected users to use > working templates, I think we should be failing gracefully and such action > should not be able to create downtime on such a large scale. > > I believe the boot type feature is new one and it's not available in older > releases, so this issue should be limited to 4.14/current master. > > Thanks, > Bobby. > > On 15.05.20, 17:07, "Boris Stoyanov" > wrote: > > I'll have to -1 RC3, we've discovered details about an issue which is > causing severe consequences with a particular hypervisor in the afternoon. > We'll need more time to investigate before disclosing. > > Bobby. > > On 15.05.20, 9:12, "Boris Stoyanov" > wrote: > > +1 (binding) > > I've executed upgrade tests with the following configurations: > > 4.13.1 with KVM on CentOS7 hosts > 4.13 with VMware6.5 hosts > 4.11.3 with KVM on CentOS7 hosts > 4.11.2 with XenServer7 hosts > 4.11.1 with VMware 6.7 > 4.9.3 with XenServer 7 hosts > 4.9.2 with KVM on CentOS 7 hosts > > Also I've run basic lifecycle operations on the following > components: > VMs > Volumes > Infra (zones, pod, clusters, hosts) > Networks > and more > > I did not come across any problems during this testing. > > Thanks, > Bobby. > > > On 11.05.20, 18:21, "Andrija Panic" > wrote: > > Hi All, > > I've created a 4.14.0.0 release (RC3), with the following > artefacts up for > testing and a vote: > > Git Branch and Commit SH: > > https://gitbox.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.14.0.0-RC20200511T1503 > Commit: 6f96b3b2b391a9b7d085f76bcafa3989d9832b4e > > Source release (checksums and signatures are available at the > same > location): > https://dist.apache.org/repos/dist/dev/cloudstack/4.14.0.0/ > > PGP release keys (signed using 3DC01AE8): > https://dist.apache.org/repos/dist/release/cloudstack/KEYS > > The vote will be open until 14th May 2020, 17.00 CET (72h). > > For sanity in tallying the vote, can PMC members please be > sure to indicate > "(binding)" with their vote? > > [ ] +1 approve > [ ] +0 no opinion > [ ] -1 disapprove (and reason why) > > Additional information: > > For users' convenience, I've built packages from > 6f96b3b2b391a9b7d085f76bcafa3989d9832b4e and published RC3 > repository here: > http://packages.shapeblue.com/testing/41400rc3/ (CentOS 7 and > Debian/generic, both with noredist support) > and here > > https://download.cloudstack.org/testing/4.14.0.0-RC20200506T2028/ubuntu/bionic/ > (Ubuntu 18.04 specific, no noredist support - thanks to > Gabriel): > > The release notes are still work-in-progress, but for the > upgrade > instructions (including the new systemVM templates) you may > refer to the > following URL: > > https://acs-www.shapeblue.com/docs/WIP-PROOFING/pr112/upgrading/index.html > > 4.14.0.0 systemVM templates are available from here: > http://download.cloudstack.org/systemvm/4.14/ > > NOTES on issues fixed in this RC3 release: > > (this one does *NOT* require a full retest if you were testing > RC1/RC2 > already - just if you were affected this issue): > - https://github.com/apache/cloudstack/pull/4064 - affects > hostnames when > attaching a VM to additional networks > > Regards, > > > Andrija Panić > > > > > > boris.stoya...@shapeblue.com > www.shapeblue.com > 3 London Bridge Street, 3rd fl
Re: [VOTE] Apache CloudStack 4.14.0.0 RC3
Hey Marcus, i tried to partially disable it today but it seems I can still corrupt a system so, I'll create a block for all of the VMware functionality tomorrow. On Mon, 18 May 2020, 22:01 Marcus, wrote: > The issue sounds severe enough that a release note probably won't suffice - > unless there's a documented way to recover we'd never want to leave a > system susceptible to being unrecoverable, even if it's rarely triggered. > > What's involved in "failing gracefully"? Is this a small fix, or an > overhaul? Perhaps the new feature could be disabled for VMware, or > disabled altogether until a fix is made in a patch release. > > Does it only affect new templates, or is there a risk that an existing > template out in vSphere could suddenly cause problems? > > On Mon, May 18, 2020 at 12:49 AM Boris Stoyanov < > boris.stoya...@shapeblue.com> wrote: > > > Hi guys, > > > > A little further info on this, it appears when we use a corrupted > template > > and UEFI/Legacy mode when deploy a VM, it breaks the connection between > > cloudstack and vCenter. > > > > All hosts become unreachable and basically the cluster is not functional, > > have not investigated a way to recover this but seems like a huge mess.. > > Please note that user is not able to register such template in vCenter > > directly, but cloudstack allows using it. > > > > Open to discuss if we'll fix this, since it's expected users to use > > working templates, I think we should be failing gracefully and such > action > > should not be able to create downtime on such a large scale. > > > > I believe the boot type feature is new one and it's not available in > older > > releases, so this issue should be limited to 4.14/current master. > > > > Thanks, > > Bobby. > > > > On 15.05.20, 17:07, "Boris Stoyanov" > > wrote: > > > > I'll have to -1 RC3, we've discovered details about an issue which is > > causing severe consequences with a particular hypervisor in the > afternoon. > > We'll need more time to investigate before disclosing. > > > > Bobby. > > > > On 15.05.20, 9:12, "Boris Stoyanov" > > wrote: > > > > +1 (binding) > > > > I've executed upgrade tests with the following configurations: > > > > 4.13.1 with KVM on CentOS7 hosts > > 4.13 with VMware6.5 hosts > > 4.11.3 with KVM on CentOS7 hosts > > 4.11.2 with XenServer7 hosts > > 4.11.1 with VMware 6.7 > > 4.9.3 with XenServer 7 hosts > > 4.9.2 with KVM on CentOS 7 hosts > > > > Also I've run basic lifecycle operations on the following > > components: > > VMs > > Volumes > > Infra (zones, pod, clusters, hosts) > > Networks > > and more > > > > I did not come across any problems during this testing. > > > > Thanks, > > Bobby. > > > > > > On 11.05.20, 18:21, "Andrija Panic" > > wrote: > > > > Hi All, > > > > I've created a 4.14.0.0 release (RC3), with the following > > artefacts up for > > testing and a vote: > > > > Git Branch and Commit SH: > > > > > https://gitbox.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.14.0.0-RC20200511T1503 > > Commit: 6f96b3b2b391a9b7d085f76bcafa3989d9832b4e > > > > Source release (checksums and signatures are available at the > > same > > location): > > https://dist.apache.org/repos/dist/dev/cloudstack/4.14.0.0/ > > > > PGP release keys (signed using 3DC01AE8): > > https://dist.apache.org/repos/dist/release/cloudstack/KEYS > > > > The vote will be open until 14th May 2020, 17.00 CET (72h). > > > > For sanity in tallying the vote, can PMC members please be > > sure to indicate > > "(binding)" with their vote? > > > > [ ] +1 approve > > [ ] +0 no opinion > > [ ] -1 disapprove (and reason why) > > > > Additional information: > > > > For users' convenience, I've built packages from > > 6f96b3b2b391a9b7d085f76bcafa3989d9832b4e and published RC3 > > repository here: > > http://packages.shapeblue.com/testing/41400rc3/ (CentOS 7 > and > > Debian/generic, both with noredist support) > > and here > > > > > https://download.cloudstack.org/testing/4.14.0.0-RC20200506T2028/ubuntu/bionic/ > > (Ubuntu 18.04 specific, no noredist support - thanks to > > Gabriel): > > > > The release notes are still work-in-progress, but for the > > upgrade > > instructions (including the new systemVM templates) you may > > refer to the > > following URL: > > > > > https://acs-www.shapeblue.com/docs/WIP-PROOFING/pr112/upgrading/index.html > > > > 4.14.0.0 systemVM templates are available from here: > > http://download.cloudstack.org/systemvm/4.14/ > > > > NOTES on issues fixed
Re: [VOTE] Apache CloudStack 4.14.0.0 RC3
On Mon, 18 May 2020, 23:12 Daan Hoogland, wrote: > > On Mon, 18 May 2020, 22:01 Marcus, wrote: > >> ... > >> Does it only affect new templates, or is there a risk that an existing >> template out in vSphere could suddenly cause problems? >> > The boot mode and type are entered at deploy time, so yes, this is a possibility.
[GitHub] [cloudstack-primate] Pearl1594 opened a new pull request #345: Fix for secondary storage form - zone id
Pearl1594 opened a new pull request #345: URL: https://github.com/apache/cloudstack-primate/pull/345 Zone name being passed instead of zone id Addresses issue : https://github.com/apache/cloudstack-primate/issues/344 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
