Thanks for bringing this discussion, Rohit. I have no objections to proceeding with the VOTE.
But I would like to bring a small consern. I see benefits in combining both projects into one; however, I also find it quite interesting to provide some "autonomy" to the UI project. At least in terms of releasing agility, I think it would allow to quickly release UI upgrades & fixes, as it tends to be simpler to develop and test UI when compared to the core system. Do you think that it would still be possible to have a faster release pace for the UI, or would it all be one release at a time for both components? To counterpoint my question above: I do see options to keep agility on UI and stability on CloudStack core, for instance, making CloudStack "in-between" releases keeping the previous core stable commits, and adding a bunch of UI commits to it. Best regards, Gabriel. Em qui., 17 de dez. de 2020 às 09:59, Rohit Yadav <rohit.ya...@shapeblue.com> escreveu: > All - if there are no objections a vote thread with following, request for > your comments: > > * Request ASF infra to archive the apache/cloudstack-primate > (read-only) repository and remove all references to 'primate' > * Move the UI code from apache/cloudstack-primate to > apache/cloudstack's ui/ directory (old code has been moved to ui/legacy > directory already and will be removed on master after 4.15 branch is cut) > * Fix packaging to build and bundle the ui/ codebase using npm and > mvn; when not packaged but built by developers the UI codebase is not > bundled but needs to be run separately > * The cloudstack-management rpm/deb pkg will include built UI (using > same path at /usr/share/cloudstack-management/webapps) and a new package > cloudstack-ui will install the UI at a differnet location (say > /usr/share/cloudstack-ui) > > I'll start the vote if there are no objections sometime next week. > > > Regards. > > ________________________________ > From: Daan Hoogland <daan.hoogl...@gmail.com> > Sent: Saturday, December 5, 2020 14:32 > To: dev <dev@cloudstack.apache.org> > Subject: Re: [DISCUSS] [IMPORTANT] CloudStack 4.14 release WITH updated UI > > 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< > http://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<http://www.shapeblue.com> > > 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK > > @shapeblue > > > > > > > > > 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 >
