Hey Rohit, This is a lot to take in at once. We have discussed some of those off line but let me give my initial answers to your discussion points inline. Hopefully those more directly involved and with more at stake can give some input as well.
On Wed, May 6, 2020 at 3:03 PM Rohit Yadav <rohit.ya...@shapeblue.com> wrote: > All, > > With this thread I want to start a discussion around: > > * How do we host/publish technical preview release > * How do we host/publish technical preview documentation (release > notes, setup/install instructions) > > To set the expectation: > > * This thread limits discussion wrt technical preview (beta). > * Plan we've already agreed, just to recap: .... ... > * References: > * Voting thread: https://markmail.org/message/tblrbrtew6cvrusr > * Proposal: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Proposal%3A+CloudStack+Primate+UI > * Discussion thread: https://markmail.org/message/z6fuvw4regig7aqb > ... > * Outstanding issues wrt 0.5-technical-preview milestone: > https://github.com/apache/cloudstack-primate/milestone/1 > * Oustanding PRs for 0.5-technical-preview: > https://github.com/apache/cloudstack-primate/pulls?q=is%3Aopen+is%3Apr+no%3Amilestone > ... > 1. Documentation for tech preview: > > It is preferred that Primate be developed, maintained and released > separately from CloudStack. Primate would require its own docs > website/location for hosting release notes etc. I can think of two ways: > > * For tech preview, let's just a section/topic on Primate on how > users can install and use Primate on the docs website: > http://docs.cloudstack.apache.org/en/latest/primateguide (it does not > exist, just for example) > For each CloudStack release, the docs may be updated, including list of > supported/required versions matrix (both CloudStack and Primate). > For tech preview, this needs to be on the 4.14.0.0 docs website. > > * On Github wiki: https://github.com/apache/cloudstack-primate/wiki > we can maintain a copy of text/pages from above ^^, as well as links on the > Github release for every git tag. A general guide (agnostic of Primate > version) could be written/hosted there. > (similar to CloudStack releases, for example: > https://github.com/apache/cloudstack/releases/tag/4.13.0.0) > 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) > 2. Types of Primate packages: > > * deb/rpm: Primate already supports deb/rpm packages. This mode > will allow users to install "cloudstack-primate" on the management server > where Primate will be served from the management server just like the old > UI. > * docker container: Primate support docker containers to be > built/used which takes a nginx config to proxy /client path to any > management server. > * archive build: A built archive (tar.gz) of Primate can be > extracted and allow users/admins to do any custom hosting with it, other > than (a) or (b). > > The install/setup/usage instructions are in general as follows: (will be > properly documented on the docs website/location) > - For (a), we need setup the repository, then run (1) yum/apt-get update, > (2) yum/apt-get install <cloudstack-primate> on a management server host. > - For (b), we need to run the docker container and pass a nginx config > file. (similar to https://github.com/apache/cloudstack-primate#docker) > - For (c), we extract and use Primate in a custom setup (that's upto the > user/admin); they may also fork/customise Primate and build (as per > https://github.com/apache/cloudstack-primate#production). > I agree, it makes it easier to develop. as long as the installation can combine a suitable primate with each cloudstack, OR vice versa; one could `dnf/pkg install cloudstack --withUI`. This might be unecessary complivcated in wich case we could go for separate pkgs and pkgs-withUI. In general the flexibility you are describing is good but might be hard to maintain. > > 3. Hosting packages/releases: > * Use download.cloudstack.org for hosting (a) deb/rpm repos, and > (c) archive builds. > > For example: I've setup a Jenkins job that builds (daily) latest Primate > master and rsyncs the (a) and (c) packages here "for testing purposes only": > http://download.cloudstack.org/primate/testing/master/ > > In additional, for every release we can have a Github release/tag (where > we attach archive builds). > > * Use the apache dockerhub org to publish official Primate > container images: > https://hub.docker.com/r/apache/cloudstack-primate > (this is 404 for now, I've started a discuss with asf infra/dev community > to have this sorted, we've a dockerfile in git repo; for "testing only" I > was able to build and publish image here: > https://hub.docker.com/r/cloudstack/primate -- I'll remove this once the > apache/cloudstack-primate is setup) > > Alternative, host on Github: > https://github.com/apache/cloudstack-primate/packages?package_type=Docker this is only for source archives right? not packages. 4. Tech Preview releasing: > > * The versioning is set to: <major>.<minor>.<security>-<date-stamp> > for example: > cloudstack-primate-0.4.0-20200506.x86_64.rpm< > http://download.cloudstack.org/primate/testing/master/centos/cloudstack-primate-0.4.0-20200506.x86_64.rpm > > > cloudstack-primate_0.4.0-20200506_all.deb< > http://download.cloudstack.org/primate/testing/master/debian/cloudstack-primate_0.4.0-20200506_all.deb > > > cloudstack-primate-0.4.0-20200506.tar.gz< > http://download.cloudstack.org/primate/testing/master/cloudstack-primate-0.4.0-20200506.tar.gz > > > > apache/cloudstack-primate:latest (or some tag similar to above for docker > builds ^^) > > * Since this is not the official/GA release, tech preview does not > need to be voted. Any other thoughts? > right, let's double check this maybe @Sven, our VP can ask around? > * Should we do a single tech preview RC/release, or we setup a > periodic build/release (say every day/week/month) on all the tech preview > release channels (deb/rpm repositories, dockerhub etc.) This would allow us > to take feedback/bugs/issues, fix them and release them quickly for users > to test. > I think git clone and git pull would suffice for those that need a newer version (packaging scripts are included in the repo, right?) > We already have a daily job that runs builds latest master and rsyncs on > http://download.cloudstack.org/primate/testing/master/ now (just deb/rpm > and tar.gz archive). We also have a live QA Primate server that we can > build/test Primate master against > http://primate-qa.cloudstack.cloud:8080/client/master (this auto-updates > against master every 30mins). > I think all in all this has been a great job, Rohit. Thanks to you and all other involved! Please discuss and share your feedback, agreements/disagreements, > solutions. Anything else we should consider? > Thanks. > > > Regards, > > Rohit Yadav > > Software Architect, ShapeBlue > > https://www.shapeblue.com > > rohit.ya...@shapeblue.com > www.shapeblue.com > 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK > @shapeblue > > > > -- Daan
