All, I discussed the issue with few colleagues and came with the following commentary and proposal with their inputs:
Problems with the current setup observed over last year: * Two different Github repositories (apache/cloudstack and apache/cloudstack-primate) with their own issue tracking, PRs and separate milestone. * We've seen users report UI issue on apache/cloudstack and backend/mgmt server bugs on apache/cloudstack-primate. * For any feature/enhancement/bugfix the work is split between two PRs in those two Github repos and it requires some overhead to manage to review and test both the linked PRs. In few instance, we've already seen the issue of one PR merged but the other one (UI changes) not merged. * The two loosely repositories also make it difficult to do packaging and installation and it's not turnkey (compared to old mechanism where installing cloudstack-management would install both server and UI components). * It's difficult to enforce and ensure that any release/version of UI will be fully backward or forward compatible with backend changes. We've seen with some recent PRs which has added dependency of a VM deployment form on specific backend feature/cases. The loose coupling works for a simple client such as CloudMonkey but not the new UI (Primate) which has custom components (not a standard interface/input pattern like cmk). The UI repository was made separate with thoughts that it would make it easier/faster to work on it, I think it's served its purpose now that the UI is on par/parity with the legacy UI. WIth this background here are some ideas that are largely around backward compatibility for user/usage, let's discuss and hopefully it may satisfy most of our requirements: For current 4.15, do: * Enforce UI deprecation by moving the legacy UI to a ui/legacy directory, see PR proposed: https://github.com/apache/cloudstack/pull/4518 This is to follow what was discussed and voted in the original proposal and documented in 4.14.0.0's release notes (that in 4.15.0.0 we'll deprecate the legacy UI). * Follow the usual release process and start a voting thread with source artifacts for both apache/cloudstack and apache/cloudstack-primate repos (I see confirmed/advised in the other thread by Craig we can do this). * Since from a project point of view we only ship source code, we can deal with the one-time issue of the disjoint pkgs by building cloudstack repo and adding the UI build in the cloudstack-management pkg itself by: * build new UI (primate) from source and create an archive (hosted on a URL/host such as http://download.cloudstack.org/primate/testing/preview/archive/) * get the CloudStack 4.15.0.0 voted source code * extract the new UI archive at ui/ folder * kick the packaging which will automatically bundle anything in ui/ directory in the cloudstack-management deb/rpm pkgs After 4.15, i.e. starting 4.16/master and later do: * Address most open PRs on apache/cloudstack-primate and ask authors to re-open the PRs under apache/cloudstack. * Merge the apache/cloudstack-primate within apache/cloudstack's ui/ directory, where we remove the ui/legacy source code (old UI code). * Delete or archive apache/cloudstack-primate - request ASF infra. * Fix/update docs as necessary wrt next milestone 4.16.0.0. * Address packaging as follows: * Option A or B: cloudstack-management will install both server and UI (current and experience/behaviour) - if someone does not want UI on their mgmt server, they may delete it from /usr/share/cloudstack-management/webapps path). Ship only UI either as an installable cloudstack-ui rpm/deb package (that installs in a different path such as at /opt etc) or ship an archive similar to what we did for tech preview (example: http://download.cloudstack.org/primate/testing/preview/archive/) * Option C: Introduce a new cloudstack-ui rpm/deb pkg which is a dependency on cloudstack-management pkg, therefore installing cloudstack-management will install cloudstack-ui and cloudstack-common; but installing cloudstack-ui will only install UI at the mgmt server webapps path, ex: /usr/share/cloudstack-management/webapps Thanks for reading, hope to hear your views. Regards. ________________________________ From: Rakesh v <www.rakeshv....@gmail.com> Sent: Friday, December 4, 2020 15:06 To: dev@cloudstack.apache.org <dev@cloudstack.apache.org> Subject: Re: [DISCUSS] [IMPORTANT] CloudStack 4.14 release WITH updated UI I agree to it. Having one package which deploys both backend and frontend is better Sent from my iPhone rohit.ya...@shapeblue.com www.shapeblue.com 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK @shapeblue > On 03-Dec-2020, at 7:09 PM, pau...@apache.org wrote: > > PMC members, PLEASE ONLY RESPOND ON THE DEV THREAD. > > > > Hi all, > > > > Please read all of this, I know it's a bit wordy.. > > > > We're pretty much there wrt to RC1 of CloudStack and the updated UI. We > have one issue remaining, and that is about the packaging and voting on > CloudStack 'engine' and its UI. > > The UI has been developed asynchronously, but at time of a CloudStack > release, we really need to be able have definite link between the two > codebases so that we release 'one thing' when we release CloudStack. > > > > A while back, I created a proposal [1], which I'd like to again put forward > as the default process unless there are any objections. > > > > In addition; > > > > 1. I think that the repo 'apache/cloudstack-primate' should be renamed to > '/apache/cloudstack-ui', to keep everything just 'cloudstack'. > > > > 2. In the repo RPM/DEB packaging make cloudstack-ui a dependency of > cloudstack - and finally, when creating the repo, include both the > 'cloudstack' and 'cloudstack-ui' RPMs/DEBs so that there is one repo > (http://download.cloudstack.org/centos7/4.15/) which contains both. > > > > PS - PMC members, PLEASE ONLY RESPOND ON THE DEV THREAD. > > > > [1] > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=165222727 > > > > Kind regards > > > > Paul Angus >
