Re: [DISCUSS] [IMPORTANT] CloudStack 4.14 release WITH updated UI
Thanks for your comments and feedback Gabriel. In terms of releasing, realistically due to dependency of UI and backend/API layer they must be released together. So, if there's a demand or need a CloudStack minor release or a specific more agile release of just the cloudstack-ui package should be possible (if the changes are UI only). Regards. From: Gabriel Bräscher Sent: Thursday, December 17, 2020 19:04 To: dev Subject: Re: [DISCUSS] [IMPORTANT] CloudStack 4.14 release WITH updated UI 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 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 > Sent: Saturday, December 5, 2020 14:32 > To: dev > 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 > 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 whi
Re: [DISCUSS] [IMPORTANT] CloudStack 4.14 release WITH updated UI
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 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 > Sent: Saturday, December 5, 2020 14:32 > To: dev > 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 > 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
Re: [DISCUSS] [IMPORTANT] CloudStack 4.14 release WITH updated UI
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 Sent: Saturday, December 5, 2020 14:32 To: dev 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 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 a
Re: [DISCUSS] [IMPORTANT] CloudStack 4.14 release WITH updated UI
/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 > Sent: Friday, December 4, 2020 15:06 > To: 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
Re: [DISCUSS] [IMPORTANT] CloudStack 4.14 release WITH updated UI
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 Sent: Friday, December 4, 2020 15:06 To: 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.. > >
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 > 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 >
Re: [DISCUSS] [IMPORTANT] CloudStack 4.14 release WITH updated UI
On Thu, Dec 3, 2020 at 7:09 PM wrote: > > Hi all, > [ snip ] > > 1. I think that the repo 'apache/cloudstack-primate' should be renamed to > '/apache/cloudstack-ui', to keep everything just 'cloudstack'. No big opinion here. 'cloudstack-ui' makes it a bit clearer what it is/does > 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. I've not used cloudstack for a while, is it a requirement to run both the mgmt/api and primate/ui on the same machine? If not then I would vote -1 to make mgmt a requirement for primate unless 'cloudstack' is a meta package to give you an all-in-one package. (e.g. if it is possible to install the mgmt by using a more distinct name like cloudstack-mgmt, then I am fine with the proposal) I can see why people would want to separate them -- Erik
Re: [DISCUSS] [IMPORTANT] CloudStack 4.14 release WITH updated UI
Paul, not much reaction so far, :( I would prefer to have them both be installed separately when I `require cloudstack` or ` install cloudstack`, but still be able to install them separately if i want them on different machines i.e. `install cloudstack-management` or alternatively `install cloudstack-engine and `install cloudstack-ui`. ad 1: +1 from me ad 2: as said rather a virtual package that depends on both. I think the direct dependency is wrong, but we're a bit late in the process. I'm not sure if we can take the time to properly implement this over all systems, given the input so far. I'd go for the dependency of the ui on the engine as a temporary solution. On Thu, Dec 3, 2020 at 7:09 PM 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
[DISCUSS] [IMPORTANT] CloudStack 4.14 release WITH updated UI
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
