Good summary Rohit, Just one addition, in my original reaction I meant the following:
Option D: Introduce a new cloudstack-ui rpm/deb pkg which is independent. Create a new "virtual" package cloudstack that depends on both cloudstack-ui and cloudstack-management (and consequently cloudstack-common). So installing cloudstack-management will install cloudstack-common; installing cloudstack-ui will only install UI at the mgmt server webapps path, ex: /usr/share/cloudstack-management/webapps, and installing cloudstack will do the whole job. I am not sure it is worth the trouble but it seems the most flexible and cleanest way to do it. for 4.15 i think we should just do whatever gives us a stable release ASAP. regards On Fri, Dec 4, 2020 at 6:21 PM Rohit Yadav <rohit.ya...@shapeblue.com> wrote: > 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 > > > -- Daan
