You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cloudstack.apache.org by Rohit Yadav <ro...@shapeblue.com> on 2020/05/06 13:03:27 UTC
[DISCUSS] Primate - publishing release and docs
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: (see voting/proposal references)
* Primate tech preview releases with 4.14.
* 4.14 release notes and announcement will have a deprecation notice wrt the old UI, will have docs/links on Primate tech preview.
* Primate will GA with next CloudStack release, old UI removal final notice will part of the next CloudStack release (summer/lts).
* Old UI will be finally removed in the next to next CloudStack release (winter/lts).
* Starting master/4.15, we want to encourage contributors to submit any new UI features/enhancements/changes to Primate; old UI can still receive bug/security fixes until removal but large changes are discouraged.
* In the next few months until GA/1.0, we'll discuss releasing/hosting/publishing Primate longer-term in a separate discussion thread after tech-preview.
* 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
Current status wrt technical preview:
* We're 100% done with the list of supported APIs against 4.13, including support for some features in 4.14 (such as CKS, B&R etc)
* 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
* Technical Preview RC will be cut as soon as the issues/PRs are closed
To get some initial discussion going, here are my views (I've discussed a few of those during the last Primate SIG meeting).
Please discuss:
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)
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).
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
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?
* 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.
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).
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.yadav@shapeblue.com
www.shapeblue.com
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
Re: [DISCUSS] Primate - publishing release and docs
Posted by nu...@li.nux.ro.
Thanks Rohit!
On 2020-05-23 01:15, Rohit Yadav wrote:
> All,
>
> Since no objections were raised, I've created the following doc PR:
> https://github.com/apache/cloudstack-documentation/pull/122
>
> The following publishing channels will be used for the technical
> preview: (TBD: long-term GA/1.0, I'll start another discussion thread
> in future)
> http://download.cloudstack.org/primate/testing/preview/ (rpm, deb,
> archive)
> https://hub.docker.com/r/apache/cloudstack-primate/tags (docker
> container build)
>
> Thanks.
>
> Regards,
>
> Rohit Yadav
>
> Software Architect, ShapeBlue
>
> https://www.shapeblue.com
>
> ________________________________
> From: Rohit Yadav <ro...@shapeblue.com>
> Sent: Monday, May 18, 2020 15:21
> To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
> Cc: users <us...@cloudstack.apache.org>
> Subject: Re: [DISCUSS] Primate - publishing release and docs
>
> Thank you all for your feedback and suggestions.
>
> For the scope of the technical preview, I would like to conclude this
> thread that unless there are any objections there will be no formal
> voting, no formal release, and therefore no RCs etc.
>
> * Tech preview publishing:
> * Archive, deb, rpm here:
> http://download.cloudstack.org/primate/testing/preview/ (for
> tracking, builds will have date-stamps)
> * Docker builds here:
> https://hub.docker.com/r/apache/cloudstack-primate (marked :latest
> tag)
> * Primate technical preview documentation will be within the 4.14
> docs website:
> * Documentation will be limited simple instructions on
> installing Primate tech preview (in most cases, few commands to
> download and install/extract artifact)
> * WIP doc pull request:
> https://github.com/apache/cloudstack-documentation/pull/122
> * The 4.14 docs website (in release notes) and the
> announcement(s) will include legacy UI deprecation notice as
> previously discussed and agreed [1][2]
> * Feedback/issue gathering:
> * In addition to welcoming any discussion(s) on MLs, the footer
> of Primate will have a link to report issues, request missing features
> etc. until 1.0/GA
> https://github.com/apache/cloudstack-primate/issues/new/choose
>
> Let's discuss other points (outside of the scope for the tech preview)
> in a different thread (after 4.14) over the next weeks/months towards
> 1.0/GA (with ACS 4.15).
>
> Any objections? Thanks.
>
>
> Additional notes and updates:
>
> * Daily builds for the latest master are rsync'd here:
> http://download.cloudstack.org/primate/testing/master/
> * Blueorangutan is now setup for Primate pull requests, we'll
> explore testing towards 1.0/GA.
>
> [1] Voting thread: https://markmail.org/message/tblrbrtew6cvrusr
>
> [2] Proposal:
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Proposal%3A+CloudStack+Primate+UI
>
>
> Regards,
>
> Rohit Yadav
>
> Software Architect, ShapeBlue
>
> https://www.shapeblue.com
>
> ________________________________
> From: Andrija Panic <an...@gmail.com>
> Sent: Monday, May 11, 2020 19:23
> To: users <us...@cloudstack.apache.org>
> Cc: dev <de...@cloudstack.apache.org>
> Subject: Re: [DISCUSS] Primate - publishing release and docs
>
> Hi Rohit,
>
> I have no major remarks on what you've already shared/proposed, besides
> a
> few things:
>
> - From user-perspective (even though ACS and Primate are separate
> projects)
> - in my opinion, we should keep al Primate documentation together with
> CloudStack documentation, so that a user can see everything in one
> place
> (single place of truth) - this means keeping the Primate WIKI as
> "empty"
> as possible (i.e. the WIKI page can contain links back to the
> docs.cloudstack.apache.org, beside's some DEV specifics that you might
> want
> to keep in WIKI only)
> - For the Technical preview, I would agree with skipping the official
> voting process now, as it's "just" a preview - once we have this
> release
> ready, I would be happy to see those links/instructions in the official
> 4.14 documentation
> - I still think we should use the originally proposed naming convention
> for
> nightly build - in case we ever decide to support different branches of
> Primate (for whatever reason) - and for the official/voted builds - I
> don't
> see any issues keeping the timestamp (some package vendrods/devs do
> that),
> though it looks more polished if we remove the date stamp for these
> official builds.
> - For official releases of Primate (delivered with i.e. ACS 4.15 in
> figure), we should carefully craft folder structure on
> download.cloudstack.apache.org to make it easy for end-user to know
> which
> specific Primate version is shipped/voted to work with a specific
> CloudStack version (as we most probably won't be bundling that with the
> cloudstack-management RPM/DEB packages)
>
> Regards,
> Andrija
>
>
>
> rohit.yadav@shapeblue.com
> www.shapeblue.com<http://www.shapeblue.com>
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
>
>
>
>
> rohit.yadav@shapeblue.com
> www.shapeblue.com
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
>
>
>
> On Mon, 11 May 2020 at 11:04, Sven Vogel <S....@ewerk.com> wrote:
>
>> Hi Rohit, Hi Daan,
>>
>> 1. Documentation for tech preview
>>
>> I agree with Rohit. For me the both suggestions with links sound like
>> a
>> good idea. We should add the download links for official releases or
>> installations for each method on both sites. Maybe its a good idea to
>> have
>> both in sync to we save us the double work. How can we get them in
>> sync? An
>> important point is always the double work. So if there is a method to
>> get
>> them fast in sync in see no problem but if there is many hand work to
>> do
>> maybe its easier to refer from wiki -> to readthedocs or vice versa. I
>> would like to prevent outdated docs on one place.
>>
>> @Daan
>> 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)
>>
>> — How could this work? Where we could find the help pop-ups and where
>> should they located?
>>
>>
>> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>
>> 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).
>>
>> — For me all three methods are a good idea because we give the user
>> the
>> greatest flexibility.
>>
>> a) a repository for rpm and deb
>> b) publish a docker like ready to use version always dockerhub. By the
>> way
>> everybody can build there own docker container
>>
>> c) publish the tar.gz on the release section in GitHub or as tar.gz on
>> repository too? What do you think @Rohit, @Daan?
>>
>>
>> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>
>> 3. Hosting packages/releases
>>
>> * Use download.cloudstack.org<http://download.cloudstack.org> for
>> hosting (a) deb/rpm repos, and (c) archive builds.
>>
>> — sounds good to me. I would prefer this place.
>>
>> * Use the apache dockerhub org to publish official Primate container
>> images: https://hub.docker.com/r/apache/cloudstack-primate
>>
>> — sounds good to me. I would prefer docker hub
>>
>> My suggestion is to host the tar.gz as release with tags on GitHub,
>> but I
>> am open to put it on the repsository too. Its depend on the work we
>> have
>> and maybe its better to have rpm, deb or
>>
>> So I thinks this is good because we have three good understandable
>> places.
>> Most people look for a repository for rpm/deb, docker on dockerhub and
>> code
>> release (tar.gz) on GitHub.
>>
>>
>> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>
>> 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
>>
>> — sounds good to me. Its a good practise to use the kernel versioning
>> like
>> <major>.<minor>.<security/patchlevel/revision>.<stable version>. Maybe
>> we
>> should remove the timestamp.
>>
>> cloudtack-primate-4.11.13.1.rpm
>> cloudtack-primate-4.11.13.1.deb
>>
>> For docker we need maybe a simpler one
>>
>> cloudstack-prinate:latest
>> cloudtack-primate:4.11.13.1
>>
>> For me its the best way don’t use names like stable or nightly
>> directly in
>> the file names. So we have always a increasing number but in different
>> directory. its possible to mix them if you want. Normally no one
>> should do
>> that but… A better way would for me like
>>
>> http://download.cloudstack.org/primate/releases/centos/4.11/
>> http://download.cloudstack.org/primate/releases/debian/4.11/
>> http://download.cloudstack.org/primate/releases/centos/latest -> point
>> to
>> centos/4.11 or whatever
>> http://download.cloudstack.org/primate/releases/nightly/centos/
>> http://download.cloudstack.org/primate/releases/nightly/debian/<
>> http://download.cloudstack.org/primate/releases/centos/latest>
>>
>> Or
>>
>> http://download.cloudstack.org/primate/releases/stable/centos/4.11/
>> http://download.cloudstack.org/primate/releases/stable/debian/4.11/
>> http://download.cloudstack.org/primate/releases/centos/latest -> point
>> to
>> 4.11 or whatever
>> http://download.cloudstack.org/primate/releases/nightly/centos/
>> http://download.cloudstack.org/primate/releases/nightly/debian/<
>> http://download.cloudstack.org/primate/releases/centos/latest>
>>
>> Its sure possible to make it more clear like /el7/ or /el8/ but I
>> think
>> this is not so important.
>>
>> I hope I don’t forget something in the discussion. Thanks Rohit for
>> your
>> good prepare of the work here. So its now easier to refine this.
>>
>> Cheers
>>
>> Sven
>>
>>
>>
>> __
>>
>> Sven Vogel
>> Lead Cloud Solution Architect
>>
>> EWERK DIGITAL GmbH
>> Brühl 24, D-04109 Leipzig
>> P +49 341 42649 - 99
>> F +49 341 42649 - 98
>> S.Vogel@ewerk.com
>> www.ewerk.com<http://www.ewerk.com>
>>
>> Geschäftsführer:
>> Dr. Erik Wende, Hendrik Schubert, Tassilo Möschke
>> Registergericht: Leipzig HRB 9065
>>
>> Support:
>> +49 341 42649 555
>>
>> Zertifiziert nach:
>> ISO/IEC 27001:2013
>> DIN EN ISO 9001:2015
>> DIN ISO/IEC 20000-1:2011
>>
>> ISAE 3402 Typ II Assessed
>>
>> EWERK-Blog<https://blog.ewerk.com/> | LinkedIn<
>> https://www.linkedin.com/company/ewerk-group> | Xing<
>> https://www.xing.com/company/ewerk> | Twitter<
>> https://twitter.com/EWERK_Group> | Facebook<
>> https://de-de.facebook.com/EWERK.IT/>
>>
>>
>> Auskünfte und Angebote per Mail sind freibleibend und unverbindlich.
>>
>> Disclaimer Privacy:
>> Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter Dateien)
>> ist
>> vertraulich und nur für den Empfänger bestimmt. Sollten Sie nicht der
>> bestimmungsgemäße Empfänger sein, ist Ihnen jegliche Offenlegung,
>> Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte
>> informieren Sie in diesem Fall unverzüglich den Absender und löschen
>> Sie
>> die E-Mail (einschließlich etwaiger beigefügter Dateien) von Ihrem
>> System.
>> Vielen Dank.
>>
>> The contents of this e-mail (including any attachments) are
>> confidential
>> and may be legally privileged. If you are not the intended recipient
>> of
>> this e-mail, any disclosure, copying, distribution or use of its
>> contents
>> is strictly prohibited, and you should please notify the sender
>> immediately
>> and then delete it (including any attachments) from your system. Thank
>> you.
>>
>> Am 08.05.2020 um 12:21 schrieb Rohit Yadav <rohit.yadav@shapeblue.com
>> <ma...@shapeblue.com>>:
>>
>> Hi Daan,
>>
>> Thanks for replying and participating. Some points:
>>
>> * The document links within Primate is a different topic than the
>> docs
>> for Primate itself, the scope of current discussion is limited to
>> documentation for Primate. The doc link within Primate would be done
>> against the 1.0/GA milestone, it would require going through all the
>> sections/APIs against the current CloudStack docs and put a link (or
>> part
>> of it).
>> * The documentation for Primate currently won't be huge, perhaps a
>> single long page would do (to explain how to install).
>> * Primate would be a separately installable package and installing
>> cloudstack-management won't automatically trigger installing it (at
>> least
>> in the tech preview, we can discuss how we handle longer term starting
>> with
>> GA/1.0 later).
>> * We've setup automation for all kinds of packaging
>> formats/channels
>> (we already have that for rpm/deb and archive formats, except for
>> dockerhub
>> hosting which is in discussion with ASF infra). I think publishing
>> artifacts should be quick and mostly automated.
>> * Github has a new feature called Github packages for each repo,
>> where
>> one can host things like npm, docker packages etc. We can explore this
>> feature.
>> On a Github release wrt a git tag, we can upload an artifact (I've
>> seen
>> many projects doing this).
>> * On releasing without voting, my thought and preference is that as
>> our
>> users test Primate, and report bugs and until GA/1.0 we fix those
>> issues,
>> implement missing feature users get faster fixes via a "preview" or
>> "testing" or "beta" release channel periodically (deb/rpms repos,
>> archives,
>> docker container builds).
>>
>> Doing this would require that we agree on this strategy, without a
>> single
>> tag/version but a set of releases (with a timestamp, so packages would
>> look
>> like cloudstack-primate-$version-$date). So effectively we're saying -
>> let's release the tech preview without doing an official release
>> (which
>> would mean a fix git tag/version). This is where the discussion of a
>> single
>> tech preview release vs rolling tech preview release would come in.
>>
>> Looking forward to more feedback from our dev/user community and of
>> course
>> our VP @Sven Vogel<ma...@ewerk.com> who has been a major
>> Primate-SIG collaborator. Thanks.
>>
>> Regards,
>>
>> Rohit Yadav
>>
>> Software Architect, ShapeBlue
>>
>> https://www.shapeblue.com<https://www.shapeblue.com/>
>>
>> ________________________________
>> From: Daan Hoogland <daan.hoogland@gmail.com<mailto:
>> daan.hoogland@gmail.com>>
>> Sent: Thursday, May 7, 2020 12:34
>> To: dev <de...@cloudstack.apache.org>>
>> Cc: users@cloudstack.apache.org<ma...@cloudstack.apache.org> <
>> users@cloudstack.apache.org<ma...@cloudstack.apache.org>>
>> Subject: Re: [DISCUSS] Primate - publishing release and docs
>>
>> 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.yadav@shapeblue.com
>> <ma...@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<http://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.yadav@shapeblue.com
>> www.shapeblue.com<http://www.shapeblue.com/><http://www.shapeblue.com<
>> http://www.shapeblue.com/>>
>> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
>> @shapeblue
>>
>>
>>
>>
>>
>> --
>> Daan
>>
>> rohit.yadav@shapeblue.com<ma...@shapeblue.com>
>> www.shapeblue.com<http://www.shapeblue.com/>
>> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
>> @shapeblue
>>
>>
>
> --
>
> Andrija Panić
Re: [DISCUSS] Primate - publishing release and docs
Posted by Rohit Yadav <ro...@shapeblue.com>.
All,
Since no objections were raised, I've created the following doc PR:
https://github.com/apache/cloudstack-documentation/pull/122
The following publishing channels will be used for the technical preview: (TBD: long-term GA/1.0, I'll start another discussion thread in future)
http://download.cloudstack.org/primate/testing/preview/ (rpm, deb, archive)
https://hub.docker.com/r/apache/cloudstack-primate/tags (docker container build)
Thanks.
Regards,
Rohit Yadav
Software Architect, ShapeBlue
https://www.shapeblue.com
________________________________
From: Rohit Yadav <ro...@shapeblue.com>
Sent: Monday, May 18, 2020 15:21
To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
Cc: users <us...@cloudstack.apache.org>
Subject: Re: [DISCUSS] Primate - publishing release and docs
Thank you all for your feedback and suggestions.
For the scope of the technical preview, I would like to conclude this thread that unless there are any objections there will be no formal voting, no formal release, and therefore no RCs etc.
* Tech preview publishing:
* Archive, deb, rpm here: http://download.cloudstack.org/primate/testing/preview/ (for tracking, builds will have date-stamps)
* Docker builds here: https://hub.docker.com/r/apache/cloudstack-primate (marked :latest tag)
* Primate technical preview documentation will be within the 4.14 docs website:
* Documentation will be limited simple instructions on installing Primate tech preview (in most cases, few commands to download and install/extract artifact)
* WIP doc pull request: https://github.com/apache/cloudstack-documentation/pull/122
* The 4.14 docs website (in release notes) and the announcement(s) will include legacy UI deprecation notice as previously discussed and agreed [1][2]
* Feedback/issue gathering:
* In addition to welcoming any discussion(s) on MLs, the footer of Primate will have a link to report issues, request missing features etc. until 1.0/GA
https://github.com/apache/cloudstack-primate/issues/new/choose
Let's discuss other points (outside of the scope for the tech preview) in a different thread (after 4.14) over the next weeks/months towards 1.0/GA (with ACS 4.15).
Any objections? Thanks.
Additional notes and updates:
* Daily builds for the latest master are rsync'd here: http://download.cloudstack.org/primate/testing/master/
* Blueorangutan is now setup for Primate pull requests, we'll explore testing towards 1.0/GA.
[1] Voting thread: https://markmail.org/message/tblrbrtew6cvrusr
[2] Proposal: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Proposal%3A+CloudStack+Primate+UI
Regards,
Rohit Yadav
Software Architect, ShapeBlue
https://www.shapeblue.com
________________________________
From: Andrija Panic <an...@gmail.com>
Sent: Monday, May 11, 2020 19:23
To: users <us...@cloudstack.apache.org>
Cc: dev <de...@cloudstack.apache.org>
Subject: Re: [DISCUSS] Primate - publishing release and docs
Hi Rohit,
I have no major remarks on what you've already shared/proposed, besides a
few things:
- From user-perspective (even though ACS and Primate are separate projects)
- in my opinion, we should keep al Primate documentation together with
CloudStack documentation, so that a user can see everything in one place
(single place of truth) - this means keeping the Primate WIKI as "empty"
as possible (i.e. the WIKI page can contain links back to the
docs.cloudstack.apache.org, beside's some DEV specifics that you might want
to keep in WIKI only)
- For the Technical preview, I would agree with skipping the official
voting process now, as it's "just" a preview - once we have this release
ready, I would be happy to see those links/instructions in the official
4.14 documentation
- I still think we should use the originally proposed naming convention for
nightly build - in case we ever decide to support different branches of
Primate (for whatever reason) - and for the official/voted builds - I don't
see any issues keeping the timestamp (some package vendrods/devs do that),
though it looks more polished if we remove the date stamp for these
official builds.
- For official releases of Primate (delivered with i.e. ACS 4.15 in
figure), we should carefully craft folder structure on
download.cloudstack.apache.org to make it easy for end-user to know which
specific Primate version is shipped/voted to work with a specific
CloudStack version (as we most probably won't be bundling that with the
cloudstack-management RPM/DEB packages)
Regards,
Andrija
rohit.yadav@shapeblue.com
www.shapeblue.com<http://www.shapeblue.com>
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
rohit.yadav@shapeblue.com
www.shapeblue.com
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
On Mon, 11 May 2020 at 11:04, Sven Vogel <S....@ewerk.com> wrote:
> Hi Rohit, Hi Daan,
>
> 1. Documentation for tech preview
>
> I agree with Rohit. For me the both suggestions with links sound like a
> good idea. We should add the download links for official releases or
> installations for each method on both sites. Maybe its a good idea to have
> both in sync to we save us the double work. How can we get them in sync? An
> important point is always the double work. So if there is a method to get
> them fast in sync in see no problem but if there is many hand work to do
> maybe its easier to refer from wiki -> to readthedocs or vice versa. I
> would like to prevent outdated docs on one place.
>
> @Daan
> 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)
>
> — How could this work? Where we could find the help pop-ups and where
> should they located?
>
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> 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).
>
> — For me all three methods are a good idea because we give the user the
> greatest flexibility.
>
> a) a repository for rpm and deb
> b) publish a docker like ready to use version always dockerhub. By the way
> everybody can build there own docker container
>
> c) publish the tar.gz on the release section in GitHub or as tar.gz on
> repository too? What do you think @Rohit, @Daan?
>
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> 3. Hosting packages/releases
>
> * Use download.cloudstack.org<http://download.cloudstack.org> for
> hosting (a) deb/rpm repos, and (c) archive builds.
>
> — sounds good to me. I would prefer this place.
>
> * Use the apache dockerhub org to publish official Primate container
> images: https://hub.docker.com/r/apache/cloudstack-primate
>
> — sounds good to me. I would prefer docker hub
>
> My suggestion is to host the tar.gz as release with tags on GitHub, but I
> am open to put it on the repsository too. Its depend on the work we have
> and maybe its better to have rpm, deb or
>
> So I thinks this is good because we have three good understandable places.
> Most people look for a repository for rpm/deb, docker on dockerhub and code
> release (tar.gz) on GitHub.
>
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> 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
>
> — sounds good to me. Its a good practise to use the kernel versioning like
> <major>.<minor>.<security/patchlevel/revision>.<stable version>. Maybe we
> should remove the timestamp.
>
> cloudtack-primate-4.11.13.1.rpm
> cloudtack-primate-4.11.13.1.deb
>
> For docker we need maybe a simpler one
>
> cloudstack-prinate:latest
> cloudtack-primate:4.11.13.1
>
> For me its the best way don’t use names like stable or nightly directly in
> the file names. So we have always a increasing number but in different
> directory. its possible to mix them if you want. Normally no one should do
> that but… A better way would for me like
>
> http://download.cloudstack.org/primate/releases/centos/4.11/
> http://download.cloudstack.org/primate/releases/debian/4.11/
> http://download.cloudstack.org/primate/releases/centos/latest -> point to
> centos/4.11 or whatever
> http://download.cloudstack.org/primate/releases/nightly/centos/
> http://download.cloudstack.org/primate/releases/nightly/debian/<
> http://download.cloudstack.org/primate/releases/centos/latest>
>
> Or
>
> http://download.cloudstack.org/primate/releases/stable/centos/4.11/
> http://download.cloudstack.org/primate/releases/stable/debian/4.11/
> http://download.cloudstack.org/primate/releases/centos/latest -> point to
> 4.11 or whatever
> http://download.cloudstack.org/primate/releases/nightly/centos/
> http://download.cloudstack.org/primate/releases/nightly/debian/<
> http://download.cloudstack.org/primate/releases/centos/latest>
>
> Its sure possible to make it more clear like /el7/ or /el8/ but I think
> this is not so important.
>
> I hope I don’t forget something in the discussion. Thanks Rohit for your
> good prepare of the work here. So its now easier to refine this.
>
> Cheers
>
> Sven
>
>
>
> __
>
> Sven Vogel
> Lead Cloud Solution Architect
>
> EWERK DIGITAL GmbH
> Brühl 24, D-04109 Leipzig
> P +49 341 42649 - 99
> F +49 341 42649 - 98
> S.Vogel@ewerk.com
> www.ewerk.com<http://www.ewerk.com>
>
> Geschäftsführer:
> Dr. Erik Wende, Hendrik Schubert, Tassilo Möschke
> Registergericht: Leipzig HRB 9065
>
> Support:
> +49 341 42649 555
>
> Zertifiziert nach:
> ISO/IEC 27001:2013
> DIN EN ISO 9001:2015
> DIN ISO/IEC 20000-1:2011
>
> ISAE 3402 Typ II Assessed
>
> EWERK-Blog<https://blog.ewerk.com/> | LinkedIn<
> https://www.linkedin.com/company/ewerk-group> | Xing<
> https://www.xing.com/company/ewerk> | Twitter<
> https://twitter.com/EWERK_Group> | Facebook<
> https://de-de.facebook.com/EWERK.IT/>
>
>
> Auskünfte und Angebote per Mail sind freibleibend und unverbindlich.
>
> Disclaimer Privacy:
> Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter Dateien) ist
> vertraulich und nur für den Empfänger bestimmt. Sollten Sie nicht der
> bestimmungsgemäße Empfänger sein, ist Ihnen jegliche Offenlegung,
> Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte
> informieren Sie in diesem Fall unverzüglich den Absender und löschen Sie
> die E-Mail (einschließlich etwaiger beigefügter Dateien) von Ihrem System.
> Vielen Dank.
>
> The contents of this e-mail (including any attachments) are confidential
> and may be legally privileged. If you are not the intended recipient of
> this e-mail, any disclosure, copying, distribution or use of its contents
> is strictly prohibited, and you should please notify the sender immediately
> and then delete it (including any attachments) from your system. Thank you.
>
> Am 08.05.2020 um 12:21 schrieb Rohit Yadav <rohit.yadav@shapeblue.com
> <ma...@shapeblue.com>>:
>
> Hi Daan,
>
> Thanks for replying and participating. Some points:
>
> * The document links within Primate is a different topic than the docs
> for Primate itself, the scope of current discussion is limited to
> documentation for Primate. The doc link within Primate would be done
> against the 1.0/GA milestone, it would require going through all the
> sections/APIs against the current CloudStack docs and put a link (or part
> of it).
> * The documentation for Primate currently won't be huge, perhaps a
> single long page would do (to explain how to install).
> * Primate would be a separately installable package and installing
> cloudstack-management won't automatically trigger installing it (at least
> in the tech preview, we can discuss how we handle longer term starting with
> GA/1.0 later).
> * We've setup automation for all kinds of packaging formats/channels
> (we already have that for rpm/deb and archive formats, except for dockerhub
> hosting which is in discussion with ASF infra). I think publishing
> artifacts should be quick and mostly automated.
> * Github has a new feature called Github packages for each repo, where
> one can host things like npm, docker packages etc. We can explore this
> feature.
> On a Github release wrt a git tag, we can upload an artifact (I've seen
> many projects doing this).
> * On releasing without voting, my thought and preference is that as our
> users test Primate, and report bugs and until GA/1.0 we fix those issues,
> implement missing feature users get faster fixes via a "preview" or
> "testing" or "beta" release channel periodically (deb/rpms repos, archives,
> docker container builds).
>
> Doing this would require that we agree on this strategy, without a single
> tag/version but a set of releases (with a timestamp, so packages would look
> like cloudstack-primate-$version-$date). So effectively we're saying -
> let's release the tech preview without doing an official release (which
> would mean a fix git tag/version). This is where the discussion of a single
> tech preview release vs rolling tech preview release would come in.
>
> Looking forward to more feedback from our dev/user community and of course
> our VP @Sven Vogel<ma...@ewerk.com> who has been a major
> Primate-SIG collaborator. Thanks.
>
> Regards,
>
> Rohit Yadav
>
> Software Architect, ShapeBlue
>
> https://www.shapeblue.com<https://www.shapeblue.com/>
>
> ________________________________
> From: Daan Hoogland <daan.hoogland@gmail.com<mailto:
> daan.hoogland@gmail.com>>
> Sent: Thursday, May 7, 2020 12:34
> To: dev <de...@cloudstack.apache.org>>
> Cc: users@cloudstack.apache.org<ma...@cloudstack.apache.org> <
> users@cloudstack.apache.org<ma...@cloudstack.apache.org>>
> Subject: Re: [DISCUSS] Primate - publishing release and docs
>
> 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.yadav@shapeblue.com
> <ma...@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<http://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.yadav@shapeblue.com
> www.shapeblue.com<http://www.shapeblue.com/><http://www.shapeblue.com<
> http://www.shapeblue.com/>>
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
>
>
>
>
>
> --
> Daan
>
> rohit.yadav@shapeblue.com<ma...@shapeblue.com>
> www.shapeblue.com<http://www.shapeblue.com/>
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
>
>
--
Andrija Panić
Re: [DISCUSS] Primate - publishing release and docs
Posted by Rohit Yadav <ro...@shapeblue.com>.
All,
Since no objections were raised, I've created the following doc PR:
https://github.com/apache/cloudstack-documentation/pull/122
The following publishing channels will be used for the technical preview: (TBD: long-term GA/1.0, I'll start another discussion thread in future)
http://download.cloudstack.org/primate/testing/preview/ (rpm, deb, archive)
https://hub.docker.com/r/apache/cloudstack-primate/tags (docker container build)
Thanks.
Regards,
Rohit Yadav
Software Architect, ShapeBlue
https://www.shapeblue.com
________________________________
From: Rohit Yadav <ro...@shapeblue.com>
Sent: Monday, May 18, 2020 15:21
To: dev@cloudstack.apache.org <de...@cloudstack.apache.org>
Cc: users <us...@cloudstack.apache.org>
Subject: Re: [DISCUSS] Primate - publishing release and docs
Thank you all for your feedback and suggestions.
For the scope of the technical preview, I would like to conclude this thread that unless there are any objections there will be no formal voting, no formal release, and therefore no RCs etc.
* Tech preview publishing:
* Archive, deb, rpm here: http://download.cloudstack.org/primate/testing/preview/ (for tracking, builds will have date-stamps)
* Docker builds here: https://hub.docker.com/r/apache/cloudstack-primate (marked :latest tag)
* Primate technical preview documentation will be within the 4.14 docs website:
* Documentation will be limited simple instructions on installing Primate tech preview (in most cases, few commands to download and install/extract artifact)
* WIP doc pull request: https://github.com/apache/cloudstack-documentation/pull/122
* The 4.14 docs website (in release notes) and the announcement(s) will include legacy UI deprecation notice as previously discussed and agreed [1][2]
* Feedback/issue gathering:
* In addition to welcoming any discussion(s) on MLs, the footer of Primate will have a link to report issues, request missing features etc. until 1.0/GA
https://github.com/apache/cloudstack-primate/issues/new/choose
Let's discuss other points (outside of the scope for the tech preview) in a different thread (after 4.14) over the next weeks/months towards 1.0/GA (with ACS 4.15).
Any objections? Thanks.
Additional notes and updates:
* Daily builds for the latest master are rsync'd here: http://download.cloudstack.org/primate/testing/master/
* Blueorangutan is now setup for Primate pull requests, we'll explore testing towards 1.0/GA.
[1] Voting thread: https://markmail.org/message/tblrbrtew6cvrusr
[2] Proposal: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Proposal%3A+CloudStack+Primate+UI
Regards,
Rohit Yadav
Software Architect, ShapeBlue
https://www.shapeblue.com
________________________________
From: Andrija Panic <an...@gmail.com>
Sent: Monday, May 11, 2020 19:23
To: users <us...@cloudstack.apache.org>
Cc: dev <de...@cloudstack.apache.org>
Subject: Re: [DISCUSS] Primate - publishing release and docs
Hi Rohit,
I have no major remarks on what you've already shared/proposed, besides a
few things:
- From user-perspective (even though ACS and Primate are separate projects)
- in my opinion, we should keep al Primate documentation together with
CloudStack documentation, so that a user can see everything in one place
(single place of truth) - this means keeping the Primate WIKI as "empty"
as possible (i.e. the WIKI page can contain links back to the
docs.cloudstack.apache.org, beside's some DEV specifics that you might want
to keep in WIKI only)
- For the Technical preview, I would agree with skipping the official
voting process now, as it's "just" a preview - once we have this release
ready, I would be happy to see those links/instructions in the official
4.14 documentation
- I still think we should use the originally proposed naming convention for
nightly build - in case we ever decide to support different branches of
Primate (for whatever reason) - and for the official/voted builds - I don't
see any issues keeping the timestamp (some package vendrods/devs do that),
though it looks more polished if we remove the date stamp for these
official builds.
- For official releases of Primate (delivered with i.e. ACS 4.15 in
figure), we should carefully craft folder structure on
download.cloudstack.apache.org to make it easy for end-user to know which
specific Primate version is shipped/voted to work with a specific
CloudStack version (as we most probably won't be bundling that with the
cloudstack-management RPM/DEB packages)
Regards,
Andrija
rohit.yadav@shapeblue.com
www.shapeblue.com<http://www.shapeblue.com>
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
rohit.yadav@shapeblue.com
www.shapeblue.com
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
On Mon, 11 May 2020 at 11:04, Sven Vogel <S....@ewerk.com> wrote:
> Hi Rohit, Hi Daan,
>
> 1. Documentation for tech preview
>
> I agree with Rohit. For me the both suggestions with links sound like a
> good idea. We should add the download links for official releases or
> installations for each method on both sites. Maybe its a good idea to have
> both in sync to we save us the double work. How can we get them in sync? An
> important point is always the double work. So if there is a method to get
> them fast in sync in see no problem but if there is many hand work to do
> maybe its easier to refer from wiki -> to readthedocs or vice versa. I
> would like to prevent outdated docs on one place.
>
> @Daan
> 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)
>
> — How could this work? Where we could find the help pop-ups and where
> should they located?
>
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> 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).
>
> — For me all three methods are a good idea because we give the user the
> greatest flexibility.
>
> a) a repository for rpm and deb
> b) publish a docker like ready to use version always dockerhub. By the way
> everybody can build there own docker container
>
> c) publish the tar.gz on the release section in GitHub or as tar.gz on
> repository too? What do you think @Rohit, @Daan?
>
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> 3. Hosting packages/releases
>
> * Use download.cloudstack.org<http://download.cloudstack.org> for
> hosting (a) deb/rpm repos, and (c) archive builds.
>
> — sounds good to me. I would prefer this place.
>
> * Use the apache dockerhub org to publish official Primate container
> images: https://hub.docker.com/r/apache/cloudstack-primate
>
> — sounds good to me. I would prefer docker hub
>
> My suggestion is to host the tar.gz as release with tags on GitHub, but I
> am open to put it on the repsository too. Its depend on the work we have
> and maybe its better to have rpm, deb or
>
> So I thinks this is good because we have three good understandable places.
> Most people look for a repository for rpm/deb, docker on dockerhub and code
> release (tar.gz) on GitHub.
>
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> 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
>
> — sounds good to me. Its a good practise to use the kernel versioning like
> <major>.<minor>.<security/patchlevel/revision>.<stable version>. Maybe we
> should remove the timestamp.
>
> cloudtack-primate-4.11.13.1.rpm
> cloudtack-primate-4.11.13.1.deb
>
> For docker we need maybe a simpler one
>
> cloudstack-prinate:latest
> cloudtack-primate:4.11.13.1
>
> For me its the best way don’t use names like stable or nightly directly in
> the file names. So we have always a increasing number but in different
> directory. its possible to mix them if you want. Normally no one should do
> that but… A better way would for me like
>
> http://download.cloudstack.org/primate/releases/centos/4.11/
> http://download.cloudstack.org/primate/releases/debian/4.11/
> http://download.cloudstack.org/primate/releases/centos/latest -> point to
> centos/4.11 or whatever
> http://download.cloudstack.org/primate/releases/nightly/centos/
> http://download.cloudstack.org/primate/releases/nightly/debian/<
> http://download.cloudstack.org/primate/releases/centos/latest>
>
> Or
>
> http://download.cloudstack.org/primate/releases/stable/centos/4.11/
> http://download.cloudstack.org/primate/releases/stable/debian/4.11/
> http://download.cloudstack.org/primate/releases/centos/latest -> point to
> 4.11 or whatever
> http://download.cloudstack.org/primate/releases/nightly/centos/
> http://download.cloudstack.org/primate/releases/nightly/debian/<
> http://download.cloudstack.org/primate/releases/centos/latest>
>
> Its sure possible to make it more clear like /el7/ or /el8/ but I think
> this is not so important.
>
> I hope I don’t forget something in the discussion. Thanks Rohit for your
> good prepare of the work here. So its now easier to refine this.
>
> Cheers
>
> Sven
>
>
>
> __
>
> Sven Vogel
> Lead Cloud Solution Architect
>
> EWERK DIGITAL GmbH
> Brühl 24, D-04109 Leipzig
> P +49 341 42649 - 99
> F +49 341 42649 - 98
> S.Vogel@ewerk.com
> www.ewerk.com<http://www.ewerk.com>
>
> Geschäftsführer:
> Dr. Erik Wende, Hendrik Schubert, Tassilo Möschke
> Registergericht: Leipzig HRB 9065
>
> Support:
> +49 341 42649 555
>
> Zertifiziert nach:
> ISO/IEC 27001:2013
> DIN EN ISO 9001:2015
> DIN ISO/IEC 20000-1:2011
>
> ISAE 3402 Typ II Assessed
>
> EWERK-Blog<https://blog.ewerk.com/> | LinkedIn<
> https://www.linkedin.com/company/ewerk-group> | Xing<
> https://www.xing.com/company/ewerk> | Twitter<
> https://twitter.com/EWERK_Group> | Facebook<
> https://de-de.facebook.com/EWERK.IT/>
>
>
> Auskünfte und Angebote per Mail sind freibleibend und unverbindlich.
>
> Disclaimer Privacy:
> Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter Dateien) ist
> vertraulich und nur für den Empfänger bestimmt. Sollten Sie nicht der
> bestimmungsgemäße Empfänger sein, ist Ihnen jegliche Offenlegung,
> Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte
> informieren Sie in diesem Fall unverzüglich den Absender und löschen Sie
> die E-Mail (einschließlich etwaiger beigefügter Dateien) von Ihrem System.
> Vielen Dank.
>
> The contents of this e-mail (including any attachments) are confidential
> and may be legally privileged. If you are not the intended recipient of
> this e-mail, any disclosure, copying, distribution or use of its contents
> is strictly prohibited, and you should please notify the sender immediately
> and then delete it (including any attachments) from your system. Thank you.
>
> Am 08.05.2020 um 12:21 schrieb Rohit Yadav <rohit.yadav@shapeblue.com
> <ma...@shapeblue.com>>:
>
> Hi Daan,
>
> Thanks for replying and participating. Some points:
>
> * The document links within Primate is a different topic than the docs
> for Primate itself, the scope of current discussion is limited to
> documentation for Primate. The doc link within Primate would be done
> against the 1.0/GA milestone, it would require going through all the
> sections/APIs against the current CloudStack docs and put a link (or part
> of it).
> * The documentation for Primate currently won't be huge, perhaps a
> single long page would do (to explain how to install).
> * Primate would be a separately installable package and installing
> cloudstack-management won't automatically trigger installing it (at least
> in the tech preview, we can discuss how we handle longer term starting with
> GA/1.0 later).
> * We've setup automation for all kinds of packaging formats/channels
> (we already have that for rpm/deb and archive formats, except for dockerhub
> hosting which is in discussion with ASF infra). I think publishing
> artifacts should be quick and mostly automated.
> * Github has a new feature called Github packages for each repo, where
> one can host things like npm, docker packages etc. We can explore this
> feature.
> On a Github release wrt a git tag, we can upload an artifact (I've seen
> many projects doing this).
> * On releasing without voting, my thought and preference is that as our
> users test Primate, and report bugs and until GA/1.0 we fix those issues,
> implement missing feature users get faster fixes via a "preview" or
> "testing" or "beta" release channel periodically (deb/rpms repos, archives,
> docker container builds).
>
> Doing this would require that we agree on this strategy, without a single
> tag/version but a set of releases (with a timestamp, so packages would look
> like cloudstack-primate-$version-$date). So effectively we're saying -
> let's release the tech preview without doing an official release (which
> would mean a fix git tag/version). This is where the discussion of a single
> tech preview release vs rolling tech preview release would come in.
>
> Looking forward to more feedback from our dev/user community and of course
> our VP @Sven Vogel<ma...@ewerk.com> who has been a major
> Primate-SIG collaborator. Thanks.
>
> Regards,
>
> Rohit Yadav
>
> Software Architect, ShapeBlue
>
> https://www.shapeblue.com<https://www.shapeblue.com/>
>
> ________________________________
> From: Daan Hoogland <daan.hoogland@gmail.com<mailto:
> daan.hoogland@gmail.com>>
> Sent: Thursday, May 7, 2020 12:34
> To: dev <de...@cloudstack.apache.org>>
> Cc: users@cloudstack.apache.org<ma...@cloudstack.apache.org> <
> users@cloudstack.apache.org<ma...@cloudstack.apache.org>>
> Subject: Re: [DISCUSS] Primate - publishing release and docs
>
> 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.yadav@shapeblue.com
> <ma...@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<http://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.yadav@shapeblue.com
> www.shapeblue.com<http://www.shapeblue.com/><http://www.shapeblue.com<
> http://www.shapeblue.com/>>
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
>
>
>
>
>
> --
> Daan
>
> rohit.yadav@shapeblue.com<ma...@shapeblue.com>
> www.shapeblue.com<http://www.shapeblue.com/>
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
>
>
--
Andrija Panić
Re: [DISCUSS] Primate - publishing release and docs
Posted by Rohit Yadav <ro...@shapeblue.com>.
Thank you all for your feedback and suggestions.
For the scope of the technical preview, I would like to conclude this thread that unless there are any objections there will be no formal voting, no formal release, and therefore no RCs etc.
* Tech preview publishing:
* Archive, deb, rpm here: http://download.cloudstack.org/primate/testing/preview/ (for tracking, builds will have date-stamps)
* Docker builds here: https://hub.docker.com/r/apache/cloudstack-primate (marked :latest tag)
* Primate technical preview documentation will be within the 4.14 docs website:
* Documentation will be limited simple instructions on installing Primate tech preview (in most cases, few commands to download and install/extract artifact)
* WIP doc pull request: https://github.com/apache/cloudstack-documentation/pull/122
* The 4.14 docs website (in release notes) and the announcement(s) will include legacy UI deprecation notice as previously discussed and agreed [1][2]
* Feedback/issue gathering:
* In addition to welcoming any discussion(s) on MLs, the footer of Primate will have a link to report issues, request missing features etc. until 1.0/GA
https://github.com/apache/cloudstack-primate/issues/new/choose
Let's discuss other points (outside of the scope for the tech preview) in a different thread (after 4.14) over the next weeks/months towards 1.0/GA (with ACS 4.15).
Any objections? Thanks.
Additional notes and updates:
* Daily builds for the latest master are rsync'd here: http://download.cloudstack.org/primate/testing/master/
* Blueorangutan is now setup for Primate pull requests, we'll explore testing towards 1.0/GA.
[1] Voting thread: https://markmail.org/message/tblrbrtew6cvrusr
[2] Proposal: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Proposal%3A+CloudStack+Primate+UI
Regards,
Rohit Yadav
Software Architect, ShapeBlue
https://www.shapeblue.com
________________________________
From: Andrija Panic <an...@gmail.com>
Sent: Monday, May 11, 2020 19:23
To: users <us...@cloudstack.apache.org>
Cc: dev <de...@cloudstack.apache.org>
Subject: Re: [DISCUSS] Primate - publishing release and docs
Hi Rohit,
I have no major remarks on what you've already shared/proposed, besides a
few things:
- From user-perspective (even though ACS and Primate are separate projects)
- in my opinion, we should keep al Primate documentation together with
CloudStack documentation, so that a user can see everything in one place
(single place of truth) - this means keeping the Primate WIKI as "empty"
as possible (i.e. the WIKI page can contain links back to the
docs.cloudstack.apache.org, beside's some DEV specifics that you might want
to keep in WIKI only)
- For the Technical preview, I would agree with skipping the official
voting process now, as it's "just" a preview - once we have this release
ready, I would be happy to see those links/instructions in the official
4.14 documentation
- I still think we should use the originally proposed naming convention for
nightly build - in case we ever decide to support different branches of
Primate (for whatever reason) - and for the official/voted builds - I don't
see any issues keeping the timestamp (some package vendrods/devs do that),
though it looks more polished if we remove the date stamp for these
official builds.
- For official releases of Primate (delivered with i.e. ACS 4.15 in
figure), we should carefully craft folder structure on
download.cloudstack.apache.org to make it easy for end-user to know which
specific Primate version is shipped/voted to work with a specific
CloudStack version (as we most probably won't be bundling that with the
cloudstack-management RPM/DEB packages)
Regards,
Andrija
rohit.yadav@shapeblue.com
www.shapeblue.com
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
On Mon, 11 May 2020 at 11:04, Sven Vogel <S....@ewerk.com> wrote:
> Hi Rohit, Hi Daan,
>
> 1. Documentation for tech preview
>
> I agree with Rohit. For me the both suggestions with links sound like a
> good idea. We should add the download links for official releases or
> installations for each method on both sites. Maybe its a good idea to have
> both in sync to we save us the double work. How can we get them in sync? An
> important point is always the double work. So if there is a method to get
> them fast in sync in see no problem but if there is many hand work to do
> maybe its easier to refer from wiki -> to readthedocs or vice versa. I
> would like to prevent outdated docs on one place.
>
> @Daan
> 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)
>
> — How could this work? Where we could find the help pop-ups and where
> should they located?
>
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> 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).
>
> — For me all three methods are a good idea because we give the user the
> greatest flexibility.
>
> a) a repository for rpm and deb
> b) publish a docker like ready to use version always dockerhub. By the way
> everybody can build there own docker container
>
> c) publish the tar.gz on the release section in GitHub or as tar.gz on
> repository too? What do you think @Rohit, @Daan?
>
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> 3. Hosting packages/releases
>
> * Use download.cloudstack.org<http://download.cloudstack.org> for
> hosting (a) deb/rpm repos, and (c) archive builds.
>
> — sounds good to me. I would prefer this place.
>
> * Use the apache dockerhub org to publish official Primate container
> images: https://hub.docker.com/r/apache/cloudstack-primate
>
> — sounds good to me. I would prefer docker hub
>
> My suggestion is to host the tar.gz as release with tags on GitHub, but I
> am open to put it on the repsository too. Its depend on the work we have
> and maybe its better to have rpm, deb or
>
> So I thinks this is good because we have three good understandable places.
> Most people look for a repository for rpm/deb, docker on dockerhub and code
> release (tar.gz) on GitHub.
>
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> 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
>
> — sounds good to me. Its a good practise to use the kernel versioning like
> <major>.<minor>.<security/patchlevel/revision>.<stable version>. Maybe we
> should remove the timestamp.
>
> cloudtack-primate-4.11.13.1.rpm
> cloudtack-primate-4.11.13.1.deb
>
> For docker we need maybe a simpler one
>
> cloudstack-prinate:latest
> cloudtack-primate:4.11.13.1
>
> For me its the best way don’t use names like stable or nightly directly in
> the file names. So we have always a increasing number but in different
> directory. its possible to mix them if you want. Normally no one should do
> that but… A better way would for me like
>
> http://download.cloudstack.org/primate/releases/centos/4.11/
> http://download.cloudstack.org/primate/releases/debian/4.11/
> http://download.cloudstack.org/primate/releases/centos/latest -> point to
> centos/4.11 or whatever
> http://download.cloudstack.org/primate/releases/nightly/centos/
> http://download.cloudstack.org/primate/releases/nightly/debian/<
> http://download.cloudstack.org/primate/releases/centos/latest>
>
> Or
>
> http://download.cloudstack.org/primate/releases/stable/centos/4.11/
> http://download.cloudstack.org/primate/releases/stable/debian/4.11/
> http://download.cloudstack.org/primate/releases/centos/latest -> point to
> 4.11 or whatever
> http://download.cloudstack.org/primate/releases/nightly/centos/
> http://download.cloudstack.org/primate/releases/nightly/debian/<
> http://download.cloudstack.org/primate/releases/centos/latest>
>
> Its sure possible to make it more clear like /el7/ or /el8/ but I think
> this is not so important.
>
> I hope I don’t forget something in the discussion. Thanks Rohit for your
> good prepare of the work here. So its now easier to refine this.
>
> Cheers
>
> Sven
>
>
>
> __
>
> Sven Vogel
> Lead Cloud Solution Architect
>
> EWERK DIGITAL GmbH
> Brühl 24, D-04109 Leipzig
> P +49 341 42649 - 99
> F +49 341 42649 - 98
> S.Vogel@ewerk.com
> www.ewerk.com<http://www.ewerk.com>
>
> Geschäftsführer:
> Dr. Erik Wende, Hendrik Schubert, Tassilo Möschke
> Registergericht: Leipzig HRB 9065
>
> Support:
> +49 341 42649 555
>
> Zertifiziert nach:
> ISO/IEC 27001:2013
> DIN EN ISO 9001:2015
> DIN ISO/IEC 20000-1:2011
>
> ISAE 3402 Typ II Assessed
>
> EWERK-Blog<https://blog.ewerk.com/> | LinkedIn<
> https://www.linkedin.com/company/ewerk-group> | Xing<
> https://www.xing.com/company/ewerk> | Twitter<
> https://twitter.com/EWERK_Group> | Facebook<
> https://de-de.facebook.com/EWERK.IT/>
>
>
> Auskünfte und Angebote per Mail sind freibleibend und unverbindlich.
>
> Disclaimer Privacy:
> Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter Dateien) ist
> vertraulich und nur für den Empfänger bestimmt. Sollten Sie nicht der
> bestimmungsgemäße Empfänger sein, ist Ihnen jegliche Offenlegung,
> Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte
> informieren Sie in diesem Fall unverzüglich den Absender und löschen Sie
> die E-Mail (einschließlich etwaiger beigefügter Dateien) von Ihrem System.
> Vielen Dank.
>
> The contents of this e-mail (including any attachments) are confidential
> and may be legally privileged. If you are not the intended recipient of
> this e-mail, any disclosure, copying, distribution or use of its contents
> is strictly prohibited, and you should please notify the sender immediately
> and then delete it (including any attachments) from your system. Thank you.
>
> Am 08.05.2020 um 12:21 schrieb Rohit Yadav <rohit.yadav@shapeblue.com
> <ma...@shapeblue.com>>:
>
> Hi Daan,
>
> Thanks for replying and participating. Some points:
>
> * The document links within Primate is a different topic than the docs
> for Primate itself, the scope of current discussion is limited to
> documentation for Primate. The doc link within Primate would be done
> against the 1.0/GA milestone, it would require going through all the
> sections/APIs against the current CloudStack docs and put a link (or part
> of it).
> * The documentation for Primate currently won't be huge, perhaps a
> single long page would do (to explain how to install).
> * Primate would be a separately installable package and installing
> cloudstack-management won't automatically trigger installing it (at least
> in the tech preview, we can discuss how we handle longer term starting with
> GA/1.0 later).
> * We've setup automation for all kinds of packaging formats/channels
> (we already have that for rpm/deb and archive formats, except for dockerhub
> hosting which is in discussion with ASF infra). I think publishing
> artifacts should be quick and mostly automated.
> * Github has a new feature called Github packages for each repo, where
> one can host things like npm, docker packages etc. We can explore this
> feature.
> On a Github release wrt a git tag, we can upload an artifact (I've seen
> many projects doing this).
> * On releasing without voting, my thought and preference is that as our
> users test Primate, and report bugs and until GA/1.0 we fix those issues,
> implement missing feature users get faster fixes via a "preview" or
> "testing" or "beta" release channel periodically (deb/rpms repos, archives,
> docker container builds).
>
> Doing this would require that we agree on this strategy, without a single
> tag/version but a set of releases (with a timestamp, so packages would look
> like cloudstack-primate-$version-$date). So effectively we're saying -
> let's release the tech preview without doing an official release (which
> would mean a fix git tag/version). This is where the discussion of a single
> tech preview release vs rolling tech preview release would come in.
>
> Looking forward to more feedback from our dev/user community and of course
> our VP @Sven Vogel<ma...@ewerk.com> who has been a major
> Primate-SIG collaborator. Thanks.
>
> Regards,
>
> Rohit Yadav
>
> Software Architect, ShapeBlue
>
> https://www.shapeblue.com<https://www.shapeblue.com/>
>
> ________________________________
> From: Daan Hoogland <daan.hoogland@gmail.com<mailto:
> daan.hoogland@gmail.com>>
> Sent: Thursday, May 7, 2020 12:34
> To: dev <de...@cloudstack.apache.org>>
> Cc: users@cloudstack.apache.org<ma...@cloudstack.apache.org> <
> users@cloudstack.apache.org<ma...@cloudstack.apache.org>>
> Subject: Re: [DISCUSS] Primate - publishing release and docs
>
> 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.yadav@shapeblue.com
> <ma...@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<http://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.yadav@shapeblue.com
> www.shapeblue.com<http://www.shapeblue.com/><http://www.shapeblue.com<
> http://www.shapeblue.com/>>
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
>
>
>
>
>
> --
> Daan
>
> rohit.yadav@shapeblue.com<ma...@shapeblue.com>
> www.shapeblue.com<http://www.shapeblue.com/>
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
>
>
--
Andrija Panić
Re: [DISCUSS] Primate - publishing release and docs
Posted by Rohit Yadav <ro...@shapeblue.com>.
Thank you all for your feedback and suggestions.
For the scope of the technical preview, I would like to conclude this thread that unless there are any objections there will be no formal voting, no formal release, and therefore no RCs etc.
* Tech preview publishing:
* Archive, deb, rpm here: http://download.cloudstack.org/primate/testing/preview/ (for tracking, builds will have date-stamps)
* Docker builds here: https://hub.docker.com/r/apache/cloudstack-primate (marked :latest tag)
* Primate technical preview documentation will be within the 4.14 docs website:
* Documentation will be limited simple instructions on installing Primate tech preview (in most cases, few commands to download and install/extract artifact)
* WIP doc pull request: https://github.com/apache/cloudstack-documentation/pull/122
* The 4.14 docs website (in release notes) and the announcement(s) will include legacy UI deprecation notice as previously discussed and agreed [1][2]
* Feedback/issue gathering:
* In addition to welcoming any discussion(s) on MLs, the footer of Primate will have a link to report issues, request missing features etc. until 1.0/GA
https://github.com/apache/cloudstack-primate/issues/new/choose
Let's discuss other points (outside of the scope for the tech preview) in a different thread (after 4.14) over the next weeks/months towards 1.0/GA (with ACS 4.15).
Any objections? Thanks.
Additional notes and updates:
* Daily builds for the latest master are rsync'd here: http://download.cloudstack.org/primate/testing/master/
* Blueorangutan is now setup for Primate pull requests, we'll explore testing towards 1.0/GA.
[1] Voting thread: https://markmail.org/message/tblrbrtew6cvrusr
[2] Proposal: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Proposal%3A+CloudStack+Primate+UI
Regards,
Rohit Yadav
Software Architect, ShapeBlue
https://www.shapeblue.com
________________________________
From: Andrija Panic <an...@gmail.com>
Sent: Monday, May 11, 2020 19:23
To: users <us...@cloudstack.apache.org>
Cc: dev <de...@cloudstack.apache.org>
Subject: Re: [DISCUSS] Primate - publishing release and docs
Hi Rohit,
I have no major remarks on what you've already shared/proposed, besides a
few things:
- From user-perspective (even though ACS and Primate are separate projects)
- in my opinion, we should keep al Primate documentation together with
CloudStack documentation, so that a user can see everything in one place
(single place of truth) - this means keeping the Primate WIKI as "empty"
as possible (i.e. the WIKI page can contain links back to the
docs.cloudstack.apache.org, beside's some DEV specifics that you might want
to keep in WIKI only)
- For the Technical preview, I would agree with skipping the official
voting process now, as it's "just" a preview - once we have this release
ready, I would be happy to see those links/instructions in the official
4.14 documentation
- I still think we should use the originally proposed naming convention for
nightly build - in case we ever decide to support different branches of
Primate (for whatever reason) - and for the official/voted builds - I don't
see any issues keeping the timestamp (some package vendrods/devs do that),
though it looks more polished if we remove the date stamp for these
official builds.
- For official releases of Primate (delivered with i.e. ACS 4.15 in
figure), we should carefully craft folder structure on
download.cloudstack.apache.org to make it easy for end-user to know which
specific Primate version is shipped/voted to work with a specific
CloudStack version (as we most probably won't be bundling that with the
cloudstack-management RPM/DEB packages)
Regards,
Andrija
rohit.yadav@shapeblue.com
www.shapeblue.com
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
On Mon, 11 May 2020 at 11:04, Sven Vogel <S....@ewerk.com> wrote:
> Hi Rohit, Hi Daan,
>
> 1. Documentation for tech preview
>
> I agree with Rohit. For me the both suggestions with links sound like a
> good idea. We should add the download links for official releases or
> installations for each method on both sites. Maybe its a good idea to have
> both in sync to we save us the double work. How can we get them in sync? An
> important point is always the double work. So if there is a method to get
> them fast in sync in see no problem but if there is many hand work to do
> maybe its easier to refer from wiki -> to readthedocs or vice versa. I
> would like to prevent outdated docs on one place.
>
> @Daan
> 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)
>
> — How could this work? Where we could find the help pop-ups and where
> should they located?
>
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> 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).
>
> — For me all three methods are a good idea because we give the user the
> greatest flexibility.
>
> a) a repository for rpm and deb
> b) publish a docker like ready to use version always dockerhub. By the way
> everybody can build there own docker container
>
> c) publish the tar.gz on the release section in GitHub or as tar.gz on
> repository too? What do you think @Rohit, @Daan?
>
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> 3. Hosting packages/releases
>
> * Use download.cloudstack.org<http://download.cloudstack.org> for
> hosting (a) deb/rpm repos, and (c) archive builds.
>
> — sounds good to me. I would prefer this place.
>
> * Use the apache dockerhub org to publish official Primate container
> images: https://hub.docker.com/r/apache/cloudstack-primate
>
> — sounds good to me. I would prefer docker hub
>
> My suggestion is to host the tar.gz as release with tags on GitHub, but I
> am open to put it on the repsository too. Its depend on the work we have
> and maybe its better to have rpm, deb or
>
> So I thinks this is good because we have three good understandable places.
> Most people look for a repository for rpm/deb, docker on dockerhub and code
> release (tar.gz) on GitHub.
>
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> 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
>
> — sounds good to me. Its a good practise to use the kernel versioning like
> <major>.<minor>.<security/patchlevel/revision>.<stable version>. Maybe we
> should remove the timestamp.
>
> cloudtack-primate-4.11.13.1.rpm
> cloudtack-primate-4.11.13.1.deb
>
> For docker we need maybe a simpler one
>
> cloudstack-prinate:latest
> cloudtack-primate:4.11.13.1
>
> For me its the best way don’t use names like stable or nightly directly in
> the file names. So we have always a increasing number but in different
> directory. its possible to mix them if you want. Normally no one should do
> that but… A better way would for me like
>
> http://download.cloudstack.org/primate/releases/centos/4.11/
> http://download.cloudstack.org/primate/releases/debian/4.11/
> http://download.cloudstack.org/primate/releases/centos/latest -> point to
> centos/4.11 or whatever
> http://download.cloudstack.org/primate/releases/nightly/centos/
> http://download.cloudstack.org/primate/releases/nightly/debian/<
> http://download.cloudstack.org/primate/releases/centos/latest>
>
> Or
>
> http://download.cloudstack.org/primate/releases/stable/centos/4.11/
> http://download.cloudstack.org/primate/releases/stable/debian/4.11/
> http://download.cloudstack.org/primate/releases/centos/latest -> point to
> 4.11 or whatever
> http://download.cloudstack.org/primate/releases/nightly/centos/
> http://download.cloudstack.org/primate/releases/nightly/debian/<
> http://download.cloudstack.org/primate/releases/centos/latest>
>
> Its sure possible to make it more clear like /el7/ or /el8/ but I think
> this is not so important.
>
> I hope I don’t forget something in the discussion. Thanks Rohit for your
> good prepare of the work here. So its now easier to refine this.
>
> Cheers
>
> Sven
>
>
>
> __
>
> Sven Vogel
> Lead Cloud Solution Architect
>
> EWERK DIGITAL GmbH
> Brühl 24, D-04109 Leipzig
> P +49 341 42649 - 99
> F +49 341 42649 - 98
> S.Vogel@ewerk.com
> www.ewerk.com<http://www.ewerk.com>
>
> Geschäftsführer:
> Dr. Erik Wende, Hendrik Schubert, Tassilo Möschke
> Registergericht: Leipzig HRB 9065
>
> Support:
> +49 341 42649 555
>
> Zertifiziert nach:
> ISO/IEC 27001:2013
> DIN EN ISO 9001:2015
> DIN ISO/IEC 20000-1:2011
>
> ISAE 3402 Typ II Assessed
>
> EWERK-Blog<https://blog.ewerk.com/> | LinkedIn<
> https://www.linkedin.com/company/ewerk-group> | Xing<
> https://www.xing.com/company/ewerk> | Twitter<
> https://twitter.com/EWERK_Group> | Facebook<
> https://de-de.facebook.com/EWERK.IT/>
>
>
> Auskünfte und Angebote per Mail sind freibleibend und unverbindlich.
>
> Disclaimer Privacy:
> Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter Dateien) ist
> vertraulich und nur für den Empfänger bestimmt. Sollten Sie nicht der
> bestimmungsgemäße Empfänger sein, ist Ihnen jegliche Offenlegung,
> Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte
> informieren Sie in diesem Fall unverzüglich den Absender und löschen Sie
> die E-Mail (einschließlich etwaiger beigefügter Dateien) von Ihrem System.
> Vielen Dank.
>
> The contents of this e-mail (including any attachments) are confidential
> and may be legally privileged. If you are not the intended recipient of
> this e-mail, any disclosure, copying, distribution or use of its contents
> is strictly prohibited, and you should please notify the sender immediately
> and then delete it (including any attachments) from your system. Thank you.
>
> Am 08.05.2020 um 12:21 schrieb Rohit Yadav <rohit.yadav@shapeblue.com
> <ma...@shapeblue.com>>:
>
> Hi Daan,
>
> Thanks for replying and participating. Some points:
>
> * The document links within Primate is a different topic than the docs
> for Primate itself, the scope of current discussion is limited to
> documentation for Primate. The doc link within Primate would be done
> against the 1.0/GA milestone, it would require going through all the
> sections/APIs against the current CloudStack docs and put a link (or part
> of it).
> * The documentation for Primate currently won't be huge, perhaps a
> single long page would do (to explain how to install).
> * Primate would be a separately installable package and installing
> cloudstack-management won't automatically trigger installing it (at least
> in the tech preview, we can discuss how we handle longer term starting with
> GA/1.0 later).
> * We've setup automation for all kinds of packaging formats/channels
> (we already have that for rpm/deb and archive formats, except for dockerhub
> hosting which is in discussion with ASF infra). I think publishing
> artifacts should be quick and mostly automated.
> * Github has a new feature called Github packages for each repo, where
> one can host things like npm, docker packages etc. We can explore this
> feature.
> On a Github release wrt a git tag, we can upload an artifact (I've seen
> many projects doing this).
> * On releasing without voting, my thought and preference is that as our
> users test Primate, and report bugs and until GA/1.0 we fix those issues,
> implement missing feature users get faster fixes via a "preview" or
> "testing" or "beta" release channel periodically (deb/rpms repos, archives,
> docker container builds).
>
> Doing this would require that we agree on this strategy, without a single
> tag/version but a set of releases (with a timestamp, so packages would look
> like cloudstack-primate-$version-$date). So effectively we're saying -
> let's release the tech preview without doing an official release (which
> would mean a fix git tag/version). This is where the discussion of a single
> tech preview release vs rolling tech preview release would come in.
>
> Looking forward to more feedback from our dev/user community and of course
> our VP @Sven Vogel<ma...@ewerk.com> who has been a major
> Primate-SIG collaborator. Thanks.
>
> Regards,
>
> Rohit Yadav
>
> Software Architect, ShapeBlue
>
> https://www.shapeblue.com<https://www.shapeblue.com/>
>
> ________________________________
> From: Daan Hoogland <daan.hoogland@gmail.com<mailto:
> daan.hoogland@gmail.com>>
> Sent: Thursday, May 7, 2020 12:34
> To: dev <de...@cloudstack.apache.org>>
> Cc: users@cloudstack.apache.org<ma...@cloudstack.apache.org> <
> users@cloudstack.apache.org<ma...@cloudstack.apache.org>>
> Subject: Re: [DISCUSS] Primate - publishing release and docs
>
> 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.yadav@shapeblue.com
> <ma...@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<http://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.yadav@shapeblue.com
> www.shapeblue.com<http://www.shapeblue.com/><http://www.shapeblue.com<
> http://www.shapeblue.com/>>
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
>
>
>
>
>
> --
> Daan
>
> rohit.yadav@shapeblue.com<ma...@shapeblue.com>
> www.shapeblue.com<http://www.shapeblue.com/>
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
>
>
--
Andrija Panić
Re: [DISCUSS] Primate - publishing release and docs
Posted by Andrija Panic <an...@gmail.com>.
Hi Rohit,
I have no major remarks on what you've already shared/proposed, besides a
few things:
- From user-perspective (even though ACS and Primate are separate projects)
- in my opinion, we should keep al Primate documentation together with
CloudStack documentation, so that a user can see everything in one place
(single place of truth) - this means keeping the Primate WIKI as "empty"
as possible (i.e. the WIKI page can contain links back to the
docs.cloudstack.apache.org, beside's some DEV specifics that you might want
to keep in WIKI only)
- For the Technical preview, I would agree with skipping the official
voting process now, as it's "just" a preview - once we have this release
ready, I would be happy to see those links/instructions in the official
4.14 documentation
- I still think we should use the originally proposed naming convention for
nightly build - in case we ever decide to support different branches of
Primate (for whatever reason) - and for the official/voted builds - I don't
see any issues keeping the timestamp (some package vendrods/devs do that),
though it looks more polished if we remove the date stamp for these
official builds.
- For official releases of Primate (delivered with i.e. ACS 4.15 in
figure), we should carefully craft folder structure on
download.cloudstack.apache.org to make it easy for end-user to know which
specific Primate version is shipped/voted to work with a specific
CloudStack version (as we most probably won't be bundling that with the
cloudstack-management RPM/DEB packages)
Regards,
Andrija
On Mon, 11 May 2020 at 11:04, Sven Vogel <S....@ewerk.com> wrote:
> Hi Rohit, Hi Daan,
>
> 1. Documentation for tech preview
>
> I agree with Rohit. For me the both suggestions with links sound like a
> good idea. We should add the download links for official releases or
> installations for each method on both sites. Maybe its a good idea to have
> both in sync to we save us the double work. How can we get them in sync? An
> important point is always the double work. So if there is a method to get
> them fast in sync in see no problem but if there is many hand work to do
> maybe its easier to refer from wiki -> to readthedocs or vice versa. I
> would like to prevent outdated docs on one place.
>
> @Daan
> 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)
>
> — How could this work? Where we could find the help pop-ups and where
> should they located?
>
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> 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).
>
> — For me all three methods are a good idea because we give the user the
> greatest flexibility.
>
> a) a repository for rpm and deb
> b) publish a docker like ready to use version always dockerhub. By the way
> everybody can build there own docker container
>
> c) publish the tar.gz on the release section in GitHub or as tar.gz on
> repository too? What do you think @Rohit, @Daan?
>
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> 3. Hosting packages/releases
>
> * Use download.cloudstack.org<http://download.cloudstack.org> for
> hosting (a) deb/rpm repos, and (c) archive builds.
>
> — sounds good to me. I would prefer this place.
>
> * Use the apache dockerhub org to publish official Primate container
> images: https://hub.docker.com/r/apache/cloudstack-primate
>
> — sounds good to me. I would prefer docker hub
>
> My suggestion is to host the tar.gz as release with tags on GitHub, but I
> am open to put it on the repsository too. Its depend on the work we have
> and maybe its better to have rpm, deb or
>
> So I thinks this is good because we have three good understandable places.
> Most people look for a repository for rpm/deb, docker on dockerhub and code
> release (tar.gz) on GitHub.
>
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> 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
>
> — sounds good to me. Its a good practise to use the kernel versioning like
> <major>.<minor>.<security/patchlevel/revision>.<stable version>. Maybe we
> should remove the timestamp.
>
> cloudtack-primate-4.11.13.1.rpm
> cloudtack-primate-4.11.13.1.deb
>
> For docker we need maybe a simpler one
>
> cloudstack-prinate:latest
> cloudtack-primate:4.11.13.1
>
> For me its the best way don’t use names like stable or nightly directly in
> the file names. So we have always a increasing number but in different
> directory. its possible to mix them if you want. Normally no one should do
> that but… A better way would for me like
>
> http://download.cloudstack.org/primate/releases/centos/4.11/
> http://download.cloudstack.org/primate/releases/debian/4.11/
> http://download.cloudstack.org/primate/releases/centos/latest -> point to
> centos/4.11 or whatever
> http://download.cloudstack.org/primate/releases/nightly/centos/
> http://download.cloudstack.org/primate/releases/nightly/debian/<
> http://download.cloudstack.org/primate/releases/centos/latest>
>
> Or
>
> http://download.cloudstack.org/primate/releases/stable/centos/4.11/
> http://download.cloudstack.org/primate/releases/stable/debian/4.11/
> http://download.cloudstack.org/primate/releases/centos/latest -> point to
> 4.11 or whatever
> http://download.cloudstack.org/primate/releases/nightly/centos/
> http://download.cloudstack.org/primate/releases/nightly/debian/<
> http://download.cloudstack.org/primate/releases/centos/latest>
>
> Its sure possible to make it more clear like /el7/ or /el8/ but I think
> this is not so important.
>
> I hope I don’t forget something in the discussion. Thanks Rohit for your
> good prepare of the work here. So its now easier to refine this.
>
> Cheers
>
> Sven
>
>
>
> __
>
> Sven Vogel
> Lead Cloud Solution Architect
>
> EWERK DIGITAL GmbH
> Brühl 24, D-04109 Leipzig
> P +49 341 42649 - 99
> F +49 341 42649 - 98
> S.Vogel@ewerk.com
> www.ewerk.com
>
> Geschäftsführer:
> Dr. Erik Wende, Hendrik Schubert, Tassilo Möschke
> Registergericht: Leipzig HRB 9065
>
> Support:
> +49 341 42649 555
>
> Zertifiziert nach:
> ISO/IEC 27001:2013
> DIN EN ISO 9001:2015
> DIN ISO/IEC 20000-1:2011
>
> ISAE 3402 Typ II Assessed
>
> EWERK-Blog<https://blog.ewerk.com/> | LinkedIn<
> https://www.linkedin.com/company/ewerk-group> | Xing<
> https://www.xing.com/company/ewerk> | Twitter<
> https://twitter.com/EWERK_Group> | Facebook<
> https://de-de.facebook.com/EWERK.IT/>
>
>
> Auskünfte und Angebote per Mail sind freibleibend und unverbindlich.
>
> Disclaimer Privacy:
> Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter Dateien) ist
> vertraulich und nur für den Empfänger bestimmt. Sollten Sie nicht der
> bestimmungsgemäße Empfänger sein, ist Ihnen jegliche Offenlegung,
> Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte
> informieren Sie in diesem Fall unverzüglich den Absender und löschen Sie
> die E-Mail (einschließlich etwaiger beigefügter Dateien) von Ihrem System.
> Vielen Dank.
>
> The contents of this e-mail (including any attachments) are confidential
> and may be legally privileged. If you are not the intended recipient of
> this e-mail, any disclosure, copying, distribution or use of its contents
> is strictly prohibited, and you should please notify the sender immediately
> and then delete it (including any attachments) from your system. Thank you.
>
> Am 08.05.2020 um 12:21 schrieb Rohit Yadav <rohit.yadav@shapeblue.com
> <ma...@shapeblue.com>>:
>
> Hi Daan,
>
> Thanks for replying and participating. Some points:
>
> * The document links within Primate is a different topic than the docs
> for Primate itself, the scope of current discussion is limited to
> documentation for Primate. The doc link within Primate would be done
> against the 1.0/GA milestone, it would require going through all the
> sections/APIs against the current CloudStack docs and put a link (or part
> of it).
> * The documentation for Primate currently won't be huge, perhaps a
> single long page would do (to explain how to install).
> * Primate would be a separately installable package and installing
> cloudstack-management won't automatically trigger installing it (at least
> in the tech preview, we can discuss how we handle longer term starting with
> GA/1.0 later).
> * We've setup automation for all kinds of packaging formats/channels
> (we already have that for rpm/deb and archive formats, except for dockerhub
> hosting which is in discussion with ASF infra). I think publishing
> artifacts should be quick and mostly automated.
> * Github has a new feature called Github packages for each repo, where
> one can host things like npm, docker packages etc. We can explore this
> feature.
> On a Github release wrt a git tag, we can upload an artifact (I've seen
> many projects doing this).
> * On releasing without voting, my thought and preference is that as our
> users test Primate, and report bugs and until GA/1.0 we fix those issues,
> implement missing feature users get faster fixes via a "preview" or
> "testing" or "beta" release channel periodically (deb/rpms repos, archives,
> docker container builds).
>
> Doing this would require that we agree on this strategy, without a single
> tag/version but a set of releases (with a timestamp, so packages would look
> like cloudstack-primate-$version-$date). So effectively we're saying -
> let's release the tech preview without doing an official release (which
> would mean a fix git tag/version). This is where the discussion of a single
> tech preview release vs rolling tech preview release would come in.
>
> Looking forward to more feedback from our dev/user community and of course
> our VP @Sven Vogel<ma...@ewerk.com> who has been a major
> Primate-SIG collaborator. Thanks.
>
> Regards,
>
> Rohit Yadav
>
> Software Architect, ShapeBlue
>
> https://www.shapeblue.com<https://www.shapeblue.com/>
>
> ________________________________
> From: Daan Hoogland <daan.hoogland@gmail.com<mailto:
> daan.hoogland@gmail.com>>
> Sent: Thursday, May 7, 2020 12:34
> To: dev <de...@cloudstack.apache.org>>
> Cc: users@cloudstack.apache.org<ma...@cloudstack.apache.org> <
> users@cloudstack.apache.org<ma...@cloudstack.apache.org>>
> Subject: Re: [DISCUSS] Primate - publishing release and docs
>
> 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.yadav@shapeblue.com
> <ma...@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<http://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.yadav@shapeblue.com
> www.shapeblue.com<http://www.shapeblue.com/><http://www.shapeblue.com<
> http://www.shapeblue.com/>>
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
>
>
>
>
>
> --
> Daan
>
> rohit.yadav@shapeblue.com<ma...@shapeblue.com>
> www.shapeblue.com<http://www.shapeblue.com/>
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
>
>
--
Andrija Panić
RE: [DISCUSS] Primate - publishing release and docs
Posted by Paul Angus <pa...@shapeblue.com>.
With a bit of - TL;DR ...
And as per Rohit's scope, I'm hand-waving over the formal release process and cycle for now.
From our by-laws [1], Non-technical decisions don’t require a vote (I don’t agree the rule, but it is what it is); so as no one has disagreed with the idea of skipping an RC vote for a tech preview of Primate, I think that’s we can go ahead with that unless someone does pop up with an objection.
I would suggest that we don't have call iterations of the tech preview 'RCs'. The tech preview is not a 'Release', as that _would_ require a vote, so to have release candidates would confuse the issue.
Wrt documentation, as this is a tech preview, I think that we should limit ourselves to the bare minimum to get Primate up and running. The project has a readme for those looking to develop Primate already.
I think that we need a BIG disclaimer/health warning at the start, instructions to download and 'install' and we can trawl github for open issues to give a 'point-in-time' list of known issues (similar to what we do for PRs in the CloudStack releases).
My 10c would be to simply: agree when the preview is ready, build the static pages, create a tarball and put that on downloads.cloudstack.org .
The instructions are then download, unpack, and place in /usr/share/cloudstack-management/webapp/Primate ...
...super simple.
Regards
Paul.
[1] http://cloudstack.apache.org/bylaws.html section 3.4.2
paul.angus@shapeblue.com
www.shapeblue.com
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
-----Original Message-----
From: Sven Vogel <S....@ewerk.com>
Sent: 11 May 2020 10:04
To: users@cloudstack.apache.org
Cc: dev <de...@cloudstack.apache.org>
Subject: Re: [DISCUSS] Primate - publishing release and docs
Hi Rohit, Hi Daan,
1. Documentation for tech preview
I agree with Rohit. For me the both suggestions with links sound like a good idea. We should add the download links for official releases or installations for each method on both sites. Maybe its a good idea to have both in sync to we save us the double work. How can we get them in sync? An important point is always the double work. So if there is a method to get them fast in sync in see no problem but if there is many hand work to do maybe its easier to refer from wiki -> to readthedocs or vice versa. I would like to prevent outdated docs on one place.
@Daan
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)
— How could this work? Where we could find the help pop-ups and where should they located?
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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).
— For me all three methods are a good idea because we give the user the greatest flexibility.
a) a repository for rpm and deb
b) publish a docker like ready to use version always dockerhub. By the way everybody can build there own docker container
c) publish the tar.gz on the release section in GitHub or as tar.gz on repository too? What do you think @Rohit, @Daan?
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
3. Hosting packages/releases
* Use download.cloudstack.org<http://download.cloudstack.org> for hosting (a) deb/rpm repos, and (c) archive builds.
— sounds good to me. I would prefer this place.
* Use the apache dockerhub org to publish official Primate container images: https://hub.docker.com/r/apache/cloudstack-primate
— sounds good to me. I would prefer docker hub
My suggestion is to host the tar.gz as release with tags on GitHub, but I am open to put it on the repsository too. Its depend on the work we have and maybe its better to have rpm, deb or
So I thinks this is good because we have three good understandable places. Most people look for a repository for rpm/deb, docker on dockerhub and code release (tar.gz) on GitHub.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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
— sounds good to me. Its a good practise to use the kernel versioning like <major>.<minor>.<security/patchlevel/revision>.<stable version>. Maybe we should remove the timestamp.
cloudtack-primate-4.11.13.1.rpm
cloudtack-primate-4.11.13.1.deb
For docker we need maybe a simpler one
cloudstack-prinate:latest
cloudtack-primate:4.11.13.1
For me its the best way don’t use names like stable or nightly directly in the file names. So we have always a increasing number but in different directory. its possible to mix them if you want. Normally no one should do that but… A better way would for me like
http://download.cloudstack.org/primate/releases/centos/4.11/
http://download.cloudstack.org/primate/releases/debian/4.11/
http://download.cloudstack.org/primate/releases/centos/latest -> point to centos/4.11 or whatever http://download.cloudstack.org/primate/releases/nightly/centos/
http://download.cloudstack.org/primate/releases/nightly/debian/<http://download.cloudstack.org/primate/releases/centos/latest>
Or
http://download.cloudstack.org/primate/releases/stable/centos/4.11/
http://download.cloudstack.org/primate/releases/stable/debian/4.11/
http://download.cloudstack.org/primate/releases/centos/latest -> point to 4.11 or whatever http://download.cloudstack.org/primate/releases/nightly/centos/
http://download.cloudstack.org/primate/releases/nightly/debian/<http://download.cloudstack.org/primate/releases/centos/latest>
Its sure possible to make it more clear like /el7/ or /el8/ but I think this is not so important.
I hope I don’t forget something in the discussion. Thanks Rohit for your good prepare of the work here. So its now easier to refine this.
Cheers
Sven
__
Sven Vogel
Lead Cloud Solution Architect
EWERK DIGITAL GmbH
Brühl 24, D-04109 Leipzig
P +49 341 42649 - 99
F +49 341 42649 - 98
S.Vogel@ewerk.com
www.ewerk.com
Geschäftsführer:
Dr. Erik Wende, Hendrik Schubert, Tassilo Möschke
Registergericht: Leipzig HRB 9065
Support:
+49 341 42649 555
Zertifiziert nach:
ISO/IEC 27001:2013
DIN EN ISO 9001:2015
DIN ISO/IEC 20000-1:2011
ISAE 3402 Typ II Assessed
EWERK-Blog<https://blog.ewerk.com/> | LinkedIn<https://www.linkedin.com/company/ewerk-group> | Xing<https://www.xing.com/company/ewerk> | Twitter<https://twitter.com/EWERK_Group> | Facebook<https://de-de.facebook.com/EWERK.IT/>
Auskünfte und Angebote per Mail sind freibleibend und unverbindlich.
Disclaimer Privacy:
Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter Dateien) ist vertraulich und nur für den Empfänger bestimmt. Sollten Sie nicht der bestimmungsgemäße Empfänger sein, ist Ihnen jegliche Offenlegung, Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte informieren Sie in diesem Fall unverzüglich den Absender und löschen Sie die E-Mail (einschließlich etwaiger beigefügter Dateien) von Ihrem System. Vielen Dank.
The contents of this e-mail (including any attachments) are confidential and may be legally privileged. If you are not the intended recipient of this e-mail, any disclosure, copying, distribution or use of its contents is strictly prohibited, and you should please notify the sender immediately and then delete it (including any attachments) from your system. Thank you.
Am 08.05.2020 um 12:21 schrieb Rohit Yadav <ro...@shapeblue.com>>:
Hi Daan,
Thanks for replying and participating. Some points:
* The document links within Primate is a different topic than the docs for Primate itself, the scope of current discussion is limited to documentation for Primate. The doc link within Primate would be done against the 1.0/GA milestone, it would require going through all the sections/APIs against the current CloudStack docs and put a link (or part of it).
* The documentation for Primate currently won't be huge, perhaps a single long page would do (to explain how to install).
* Primate would be a separately installable package and installing cloudstack-management won't automatically trigger installing it (at least in the tech preview, we can discuss how we handle longer term starting with GA/1.0 later).
* We've setup automation for all kinds of packaging formats/channels (we already have that for rpm/deb and archive formats, except for dockerhub hosting which is in discussion with ASF infra). I think publishing artifacts should be quick and mostly automated.
* Github has a new feature called Github packages for each repo, where one can host things like npm, docker packages etc. We can explore this feature.
On a Github release wrt a git tag, we can upload an artifact (I've seen many projects doing this).
* On releasing without voting, my thought and preference is that as our users test Primate, and report bugs and until GA/1.0 we fix those issues, implement missing feature users get faster fixes via a "preview" or "testing" or "beta" release channel periodically (deb/rpms repos, archives, docker container builds).
Doing this would require that we agree on this strategy, without a single tag/version but a set of releases (with a timestamp, so packages would look like cloudstack-primate-$version-$date). So effectively we're saying - let's release the tech preview without doing an official release (which would mean a fix git tag/version). This is where the discussion of a single tech preview release vs rolling tech preview release would come in.
Looking forward to more feedback from our dev/user community and of course our VP @Sven Vogel<ma...@ewerk.com> who has been a major Primate-SIG collaborator. Thanks.
Regards,
Rohit Yadav
Software Architect, ShapeBlue
https://www.shapeblue.com<https://www.shapeblue.com/>
________________________________
From: Daan Hoogland <da...@gmail.com>>
Sent: Thursday, May 7, 2020 12:34
To: dev <de...@cloudstack.apache.org>>
Cc: users@cloudstack.apache.org<ma...@cloudstack.apache.org> <us...@cloudstack.apache.org>>
Subject: Re: [DISCUSS] Primate - publishing release and docs
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 <ro...@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<http://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.yadav@shapeblue.com
www.shapeblue.com<http://www.shapeblue.com/><http://www.shapeblue.com<http://www.shapeblue.com/>>
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK @shapeblue
--
Daan
rohit.yadav@shapeblue.com<ma...@shapeblue.com>
www.shapeblue.com<http://www.shapeblue.com/>
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK @shapeblue
RE: [DISCUSS] Primate - publishing release and docs
Posted by Paul Angus <pa...@shapeblue.com>.
With a bit of - TL;DR ...
And as per Rohit's scope, I'm hand-waving over the formal release process and cycle for now.
From our by-laws [1], Non-technical decisions don’t require a vote (I don’t agree the rule, but it is what it is); so as no one has disagreed with the idea of skipping an RC vote for a tech preview of Primate, I think that’s we can go ahead with that unless someone does pop up with an objection.
I would suggest that we don't have call iterations of the tech preview 'RCs'. The tech preview is not a 'Release', as that _would_ require a vote, so to have release candidates would confuse the issue.
Wrt documentation, as this is a tech preview, I think that we should limit ourselves to the bare minimum to get Primate up and running. The project has a readme for those looking to develop Primate already.
I think that we need a BIG disclaimer/health warning at the start, instructions to download and 'install' and we can trawl github for open issues to give a 'point-in-time' list of known issues (similar to what we do for PRs in the CloudStack releases).
My 10c would be to simply: agree when the preview is ready, build the static pages, create a tarball and put that on downloads.cloudstack.org .
The instructions are then download, unpack, and place in /usr/share/cloudstack-management/webapp/Primate ...
...super simple.
Regards
Paul.
[1] http://cloudstack.apache.org/bylaws.html section 3.4.2
paul.angus@shapeblue.com
www.shapeblue.com
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
-----Original Message-----
From: Sven Vogel <S....@ewerk.com>
Sent: 11 May 2020 10:04
To: users@cloudstack.apache.org
Cc: dev <de...@cloudstack.apache.org>
Subject: Re: [DISCUSS] Primate - publishing release and docs
Hi Rohit, Hi Daan,
1. Documentation for tech preview
I agree with Rohit. For me the both suggestions with links sound like a good idea. We should add the download links for official releases or installations for each method on both sites. Maybe its a good idea to have both in sync to we save us the double work. How can we get them in sync? An important point is always the double work. So if there is a method to get them fast in sync in see no problem but if there is many hand work to do maybe its easier to refer from wiki -> to readthedocs or vice versa. I would like to prevent outdated docs on one place.
@Daan
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)
— How could this work? Where we could find the help pop-ups and where should they located?
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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).
— For me all three methods are a good idea because we give the user the greatest flexibility.
a) a repository for rpm and deb
b) publish a docker like ready to use version always dockerhub. By the way everybody can build there own docker container
c) publish the tar.gz on the release section in GitHub or as tar.gz on repository too? What do you think @Rohit, @Daan?
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
3. Hosting packages/releases
* Use download.cloudstack.org<http://download.cloudstack.org> for hosting (a) deb/rpm repos, and (c) archive builds.
— sounds good to me. I would prefer this place.
* Use the apache dockerhub org to publish official Primate container images: https://hub.docker.com/r/apache/cloudstack-primate
— sounds good to me. I would prefer docker hub
My suggestion is to host the tar.gz as release with tags on GitHub, but I am open to put it on the repsository too. Its depend on the work we have and maybe its better to have rpm, deb or
So I thinks this is good because we have three good understandable places. Most people look for a repository for rpm/deb, docker on dockerhub and code release (tar.gz) on GitHub.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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
— sounds good to me. Its a good practise to use the kernel versioning like <major>.<minor>.<security/patchlevel/revision>.<stable version>. Maybe we should remove the timestamp.
cloudtack-primate-4.11.13.1.rpm
cloudtack-primate-4.11.13.1.deb
For docker we need maybe a simpler one
cloudstack-prinate:latest
cloudtack-primate:4.11.13.1
For me its the best way don’t use names like stable or nightly directly in the file names. So we have always a increasing number but in different directory. its possible to mix them if you want. Normally no one should do that but… A better way would for me like
http://download.cloudstack.org/primate/releases/centos/4.11/
http://download.cloudstack.org/primate/releases/debian/4.11/
http://download.cloudstack.org/primate/releases/centos/latest -> point to centos/4.11 or whatever http://download.cloudstack.org/primate/releases/nightly/centos/
http://download.cloudstack.org/primate/releases/nightly/debian/<http://download.cloudstack.org/primate/releases/centos/latest>
Or
http://download.cloudstack.org/primate/releases/stable/centos/4.11/
http://download.cloudstack.org/primate/releases/stable/debian/4.11/
http://download.cloudstack.org/primate/releases/centos/latest -> point to 4.11 or whatever http://download.cloudstack.org/primate/releases/nightly/centos/
http://download.cloudstack.org/primate/releases/nightly/debian/<http://download.cloudstack.org/primate/releases/centos/latest>
Its sure possible to make it more clear like /el7/ or /el8/ but I think this is not so important.
I hope I don’t forget something in the discussion. Thanks Rohit for your good prepare of the work here. So its now easier to refine this.
Cheers
Sven
__
Sven Vogel
Lead Cloud Solution Architect
EWERK DIGITAL GmbH
Brühl 24, D-04109 Leipzig
P +49 341 42649 - 99
F +49 341 42649 - 98
S.Vogel@ewerk.com
www.ewerk.com
Geschäftsführer:
Dr. Erik Wende, Hendrik Schubert, Tassilo Möschke
Registergericht: Leipzig HRB 9065
Support:
+49 341 42649 555
Zertifiziert nach:
ISO/IEC 27001:2013
DIN EN ISO 9001:2015
DIN ISO/IEC 20000-1:2011
ISAE 3402 Typ II Assessed
EWERK-Blog<https://blog.ewerk.com/> | LinkedIn<https://www.linkedin.com/company/ewerk-group> | Xing<https://www.xing.com/company/ewerk> | Twitter<https://twitter.com/EWERK_Group> | Facebook<https://de-de.facebook.com/EWERK.IT/>
Auskünfte und Angebote per Mail sind freibleibend und unverbindlich.
Disclaimer Privacy:
Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter Dateien) ist vertraulich und nur für den Empfänger bestimmt. Sollten Sie nicht der bestimmungsgemäße Empfänger sein, ist Ihnen jegliche Offenlegung, Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte informieren Sie in diesem Fall unverzüglich den Absender und löschen Sie die E-Mail (einschließlich etwaiger beigefügter Dateien) von Ihrem System. Vielen Dank.
The contents of this e-mail (including any attachments) are confidential and may be legally privileged. If you are not the intended recipient of this e-mail, any disclosure, copying, distribution or use of its contents is strictly prohibited, and you should please notify the sender immediately and then delete it (including any attachments) from your system. Thank you.
Am 08.05.2020 um 12:21 schrieb Rohit Yadav <ro...@shapeblue.com>>:
Hi Daan,
Thanks for replying and participating. Some points:
* The document links within Primate is a different topic than the docs for Primate itself, the scope of current discussion is limited to documentation for Primate. The doc link within Primate would be done against the 1.0/GA milestone, it would require going through all the sections/APIs against the current CloudStack docs and put a link (or part of it).
* The documentation for Primate currently won't be huge, perhaps a single long page would do (to explain how to install).
* Primate would be a separately installable package and installing cloudstack-management won't automatically trigger installing it (at least in the tech preview, we can discuss how we handle longer term starting with GA/1.0 later).
* We've setup automation for all kinds of packaging formats/channels (we already have that for rpm/deb and archive formats, except for dockerhub hosting which is in discussion with ASF infra). I think publishing artifacts should be quick and mostly automated.
* Github has a new feature called Github packages for each repo, where one can host things like npm, docker packages etc. We can explore this feature.
On a Github release wrt a git tag, we can upload an artifact (I've seen many projects doing this).
* On releasing without voting, my thought and preference is that as our users test Primate, and report bugs and until GA/1.0 we fix those issues, implement missing feature users get faster fixes via a "preview" or "testing" or "beta" release channel periodically (deb/rpms repos, archives, docker container builds).
Doing this would require that we agree on this strategy, without a single tag/version but a set of releases (with a timestamp, so packages would look like cloudstack-primate-$version-$date). So effectively we're saying - let's release the tech preview without doing an official release (which would mean a fix git tag/version). This is where the discussion of a single tech preview release vs rolling tech preview release would come in.
Looking forward to more feedback from our dev/user community and of course our VP @Sven Vogel<ma...@ewerk.com> who has been a major Primate-SIG collaborator. Thanks.
Regards,
Rohit Yadav
Software Architect, ShapeBlue
https://www.shapeblue.com<https://www.shapeblue.com/>
________________________________
From: Daan Hoogland <da...@gmail.com>>
Sent: Thursday, May 7, 2020 12:34
To: dev <de...@cloudstack.apache.org>>
Cc: users@cloudstack.apache.org<ma...@cloudstack.apache.org> <us...@cloudstack.apache.org>>
Subject: Re: [DISCUSS] Primate - publishing release and docs
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 <ro...@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<http://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.yadav@shapeblue.com
www.shapeblue.com<http://www.shapeblue.com/><http://www.shapeblue.com<http://www.shapeblue.com/>>
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK @shapeblue
--
Daan
rohit.yadav@shapeblue.com<ma...@shapeblue.com>
www.shapeblue.com<http://www.shapeblue.com/>
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK @shapeblue
Re: [DISCUSS] Primate - publishing release and docs
Posted by Andrija Panic <an...@gmail.com>.
Hi Rohit,
I have no major remarks on what you've already shared/proposed, besides a
few things:
- From user-perspective (even though ACS and Primate are separate projects)
- in my opinion, we should keep al Primate documentation together with
CloudStack documentation, so that a user can see everything in one place
(single place of truth) - this means keeping the Primate WIKI as "empty"
as possible (i.e. the WIKI page can contain links back to the
docs.cloudstack.apache.org, beside's some DEV specifics that you might want
to keep in WIKI only)
- For the Technical preview, I would agree with skipping the official
voting process now, as it's "just" a preview - once we have this release
ready, I would be happy to see those links/instructions in the official
4.14 documentation
- I still think we should use the originally proposed naming convention for
nightly build - in case we ever decide to support different branches of
Primate (for whatever reason) - and for the official/voted builds - I don't
see any issues keeping the timestamp (some package vendrods/devs do that),
though it looks more polished if we remove the date stamp for these
official builds.
- For official releases of Primate (delivered with i.e. ACS 4.15 in
figure), we should carefully craft folder structure on
download.cloudstack.apache.org to make it easy for end-user to know which
specific Primate version is shipped/voted to work with a specific
CloudStack version (as we most probably won't be bundling that with the
cloudstack-management RPM/DEB packages)
Regards,
Andrija
On Mon, 11 May 2020 at 11:04, Sven Vogel <S....@ewerk.com> wrote:
> Hi Rohit, Hi Daan,
>
> 1. Documentation for tech preview
>
> I agree with Rohit. For me the both suggestions with links sound like a
> good idea. We should add the download links for official releases or
> installations for each method on both sites. Maybe its a good idea to have
> both in sync to we save us the double work. How can we get them in sync? An
> important point is always the double work. So if there is a method to get
> them fast in sync in see no problem but if there is many hand work to do
> maybe its easier to refer from wiki -> to readthedocs or vice versa. I
> would like to prevent outdated docs on one place.
>
> @Daan
> 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)
>
> — How could this work? Where we could find the help pop-ups and where
> should they located?
>
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> 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).
>
> — For me all three methods are a good idea because we give the user the
> greatest flexibility.
>
> a) a repository for rpm and deb
> b) publish a docker like ready to use version always dockerhub. By the way
> everybody can build there own docker container
>
> c) publish the tar.gz on the release section in GitHub or as tar.gz on
> repository too? What do you think @Rohit, @Daan?
>
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> 3. Hosting packages/releases
>
> * Use download.cloudstack.org<http://download.cloudstack.org> for
> hosting (a) deb/rpm repos, and (c) archive builds.
>
> — sounds good to me. I would prefer this place.
>
> * Use the apache dockerhub org to publish official Primate container
> images: https://hub.docker.com/r/apache/cloudstack-primate
>
> — sounds good to me. I would prefer docker hub
>
> My suggestion is to host the tar.gz as release with tags on GitHub, but I
> am open to put it on the repsository too. Its depend on the work we have
> and maybe its better to have rpm, deb or
>
> So I thinks this is good because we have three good understandable places.
> Most people look for a repository for rpm/deb, docker on dockerhub and code
> release (tar.gz) on GitHub.
>
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> 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
>
> — sounds good to me. Its a good practise to use the kernel versioning like
> <major>.<minor>.<security/patchlevel/revision>.<stable version>. Maybe we
> should remove the timestamp.
>
> cloudtack-primate-4.11.13.1.rpm
> cloudtack-primate-4.11.13.1.deb
>
> For docker we need maybe a simpler one
>
> cloudstack-prinate:latest
> cloudtack-primate:4.11.13.1
>
> For me its the best way don’t use names like stable or nightly directly in
> the file names. So we have always a increasing number but in different
> directory. its possible to mix them if you want. Normally no one should do
> that but… A better way would for me like
>
> http://download.cloudstack.org/primate/releases/centos/4.11/
> http://download.cloudstack.org/primate/releases/debian/4.11/
> http://download.cloudstack.org/primate/releases/centos/latest -> point to
> centos/4.11 or whatever
> http://download.cloudstack.org/primate/releases/nightly/centos/
> http://download.cloudstack.org/primate/releases/nightly/debian/<
> http://download.cloudstack.org/primate/releases/centos/latest>
>
> Or
>
> http://download.cloudstack.org/primate/releases/stable/centos/4.11/
> http://download.cloudstack.org/primate/releases/stable/debian/4.11/
> http://download.cloudstack.org/primate/releases/centos/latest -> point to
> 4.11 or whatever
> http://download.cloudstack.org/primate/releases/nightly/centos/
> http://download.cloudstack.org/primate/releases/nightly/debian/<
> http://download.cloudstack.org/primate/releases/centos/latest>
>
> Its sure possible to make it more clear like /el7/ or /el8/ but I think
> this is not so important.
>
> I hope I don’t forget something in the discussion. Thanks Rohit for your
> good prepare of the work here. So its now easier to refine this.
>
> Cheers
>
> Sven
>
>
>
> __
>
> Sven Vogel
> Lead Cloud Solution Architect
>
> EWERK DIGITAL GmbH
> Brühl 24, D-04109 Leipzig
> P +49 341 42649 - 99
> F +49 341 42649 - 98
> S.Vogel@ewerk.com
> www.ewerk.com
>
> Geschäftsführer:
> Dr. Erik Wende, Hendrik Schubert, Tassilo Möschke
> Registergericht: Leipzig HRB 9065
>
> Support:
> +49 341 42649 555
>
> Zertifiziert nach:
> ISO/IEC 27001:2013
> DIN EN ISO 9001:2015
> DIN ISO/IEC 20000-1:2011
>
> ISAE 3402 Typ II Assessed
>
> EWERK-Blog<https://blog.ewerk.com/> | LinkedIn<
> https://www.linkedin.com/company/ewerk-group> | Xing<
> https://www.xing.com/company/ewerk> | Twitter<
> https://twitter.com/EWERK_Group> | Facebook<
> https://de-de.facebook.com/EWERK.IT/>
>
>
> Auskünfte und Angebote per Mail sind freibleibend und unverbindlich.
>
> Disclaimer Privacy:
> Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter Dateien) ist
> vertraulich und nur für den Empfänger bestimmt. Sollten Sie nicht der
> bestimmungsgemäße Empfänger sein, ist Ihnen jegliche Offenlegung,
> Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte
> informieren Sie in diesem Fall unverzüglich den Absender und löschen Sie
> die E-Mail (einschließlich etwaiger beigefügter Dateien) von Ihrem System.
> Vielen Dank.
>
> The contents of this e-mail (including any attachments) are confidential
> and may be legally privileged. If you are not the intended recipient of
> this e-mail, any disclosure, copying, distribution or use of its contents
> is strictly prohibited, and you should please notify the sender immediately
> and then delete it (including any attachments) from your system. Thank you.
>
> Am 08.05.2020 um 12:21 schrieb Rohit Yadav <rohit.yadav@shapeblue.com
> <ma...@shapeblue.com>>:
>
> Hi Daan,
>
> Thanks for replying and participating. Some points:
>
> * The document links within Primate is a different topic than the docs
> for Primate itself, the scope of current discussion is limited to
> documentation for Primate. The doc link within Primate would be done
> against the 1.0/GA milestone, it would require going through all the
> sections/APIs against the current CloudStack docs and put a link (or part
> of it).
> * The documentation for Primate currently won't be huge, perhaps a
> single long page would do (to explain how to install).
> * Primate would be a separately installable package and installing
> cloudstack-management won't automatically trigger installing it (at least
> in the tech preview, we can discuss how we handle longer term starting with
> GA/1.0 later).
> * We've setup automation for all kinds of packaging formats/channels
> (we already have that for rpm/deb and archive formats, except for dockerhub
> hosting which is in discussion with ASF infra). I think publishing
> artifacts should be quick and mostly automated.
> * Github has a new feature called Github packages for each repo, where
> one can host things like npm, docker packages etc. We can explore this
> feature.
> On a Github release wrt a git tag, we can upload an artifact (I've seen
> many projects doing this).
> * On releasing without voting, my thought and preference is that as our
> users test Primate, and report bugs and until GA/1.0 we fix those issues,
> implement missing feature users get faster fixes via a "preview" or
> "testing" or "beta" release channel periodically (deb/rpms repos, archives,
> docker container builds).
>
> Doing this would require that we agree on this strategy, without a single
> tag/version but a set of releases (with a timestamp, so packages would look
> like cloudstack-primate-$version-$date). So effectively we're saying -
> let's release the tech preview without doing an official release (which
> would mean a fix git tag/version). This is where the discussion of a single
> tech preview release vs rolling tech preview release would come in.
>
> Looking forward to more feedback from our dev/user community and of course
> our VP @Sven Vogel<ma...@ewerk.com> who has been a major
> Primate-SIG collaborator. Thanks.
>
> Regards,
>
> Rohit Yadav
>
> Software Architect, ShapeBlue
>
> https://www.shapeblue.com<https://www.shapeblue.com/>
>
> ________________________________
> From: Daan Hoogland <daan.hoogland@gmail.com<mailto:
> daan.hoogland@gmail.com>>
> Sent: Thursday, May 7, 2020 12:34
> To: dev <de...@cloudstack.apache.org>>
> Cc: users@cloudstack.apache.org<ma...@cloudstack.apache.org> <
> users@cloudstack.apache.org<ma...@cloudstack.apache.org>>
> Subject: Re: [DISCUSS] Primate - publishing release and docs
>
> 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.yadav@shapeblue.com
> <ma...@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<http://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.yadav@shapeblue.com
> www.shapeblue.com<http://www.shapeblue.com/><http://www.shapeblue.com<
> http://www.shapeblue.com/>>
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
>
>
>
>
>
> --
> Daan
>
> rohit.yadav@shapeblue.com<ma...@shapeblue.com>
> www.shapeblue.com<http://www.shapeblue.com/>
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
>
>
--
Andrija Panić
Re: [DISCUSS] Primate - publishing release and docs
Posted by Sven Vogel <S....@ewerk.com>.
Hi Rohit, Hi Daan,
1. Documentation for tech preview
I agree with Rohit. For me the both suggestions with links sound like a good idea. We should add the download links for official releases or installations for each method on both sites. Maybe its a good idea to have both in sync to we save us the double work. How can we get them in sync? An important point is always the double work. So if there is a method to get them fast in sync in see no problem but if there is many hand work to do maybe its easier to refer from wiki -> to readthedocs or vice versa. I would like to prevent outdated docs on one place.
@Daan
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)
— How could this work? Where we could find the help pop-ups and where should they located?
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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).
— For me all three methods are a good idea because we give the user the greatest flexibility.
a) a repository for rpm and deb
b) publish a docker like ready to use version always dockerhub. By the way everybody can build there own docker container
c) publish the tar.gz on the release section in GitHub or as tar.gz on repository too? What do you think @Rohit, @Daan?
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
3. Hosting packages/releases
* Use download.cloudstack.org<http://download.cloudstack.org> for hosting (a) deb/rpm repos, and (c) archive builds.
— sounds good to me. I would prefer this place.
* Use the apache dockerhub org to publish official Primate container images: https://hub.docker.com/r/apache/cloudstack-primate
— sounds good to me. I would prefer docker hub
My suggestion is to host the tar.gz as release with tags on GitHub, but I am open to put it on the repsository too. Its depend on the work we have and maybe its better to have rpm, deb or
So I thinks this is good because we have three good understandable places. Most people look for a repository for rpm/deb, docker on dockerhub and code release (tar.gz) on GitHub.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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
— sounds good to me. Its a good practise to use the kernel versioning like <major>.<minor>.<security/patchlevel/revision>.<stable version>. Maybe we should remove the timestamp.
cloudtack-primate-4.11.13.1.rpm
cloudtack-primate-4.11.13.1.deb
For docker we need maybe a simpler one
cloudstack-prinate:latest
cloudtack-primate:4.11.13.1
For me its the best way don’t use names like stable or nightly directly in the file names. So we have always a increasing number but in different directory. its possible to mix them if you want. Normally no one should do that but… A better way would for me like
http://download.cloudstack.org/primate/releases/centos/4.11/
http://download.cloudstack.org/primate/releases/debian/4.11/
http://download.cloudstack.org/primate/releases/centos/latest -> point to centos/4.11 or whatever
http://download.cloudstack.org/primate/releases/nightly/centos/
http://download.cloudstack.org/primate/releases/nightly/debian/<http://download.cloudstack.org/primate/releases/centos/latest>
Or
http://download.cloudstack.org/primate/releases/stable/centos/4.11/
http://download.cloudstack.org/primate/releases/stable/debian/4.11/
http://download.cloudstack.org/primate/releases/centos/latest -> point to 4.11 or whatever
http://download.cloudstack.org/primate/releases/nightly/centos/
http://download.cloudstack.org/primate/releases/nightly/debian/<http://download.cloudstack.org/primate/releases/centos/latest>
Its sure possible to make it more clear like /el7/ or /el8/ but I think this is not so important.
I hope I don’t forget something in the discussion. Thanks Rohit for your good prepare of the work here. So its now easier to refine this.
Cheers
Sven
__
Sven Vogel
Lead Cloud Solution Architect
EWERK DIGITAL GmbH
Brühl 24, D-04109 Leipzig
P +49 341 42649 - 99
F +49 341 42649 - 98
S.Vogel@ewerk.com
www.ewerk.com
Geschäftsführer:
Dr. Erik Wende, Hendrik Schubert, Tassilo Möschke
Registergericht: Leipzig HRB 9065
Support:
+49 341 42649 555
Zertifiziert nach:
ISO/IEC 27001:2013
DIN EN ISO 9001:2015
DIN ISO/IEC 20000-1:2011
ISAE 3402 Typ II Assessed
EWERK-Blog<https://blog.ewerk.com/> | LinkedIn<https://www.linkedin.com/company/ewerk-group> | Xing<https://www.xing.com/company/ewerk> | Twitter<https://twitter.com/EWERK_Group> | Facebook<https://de-de.facebook.com/EWERK.IT/>
Auskünfte und Angebote per Mail sind freibleibend und unverbindlich.
Disclaimer Privacy:
Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter Dateien) ist vertraulich und nur für den Empfänger bestimmt. Sollten Sie nicht der bestimmungsgemäße Empfänger sein, ist Ihnen jegliche Offenlegung, Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte informieren Sie in diesem Fall unverzüglich den Absender und löschen Sie die E-Mail (einschließlich etwaiger beigefügter Dateien) von Ihrem System. Vielen Dank.
The contents of this e-mail (including any attachments) are confidential and may be legally privileged. If you are not the intended recipient of this e-mail, any disclosure, copying, distribution or use of its contents is strictly prohibited, and you should please notify the sender immediately and then delete it (including any attachments) from your system. Thank you.
Am 08.05.2020 um 12:21 schrieb Rohit Yadav <ro...@shapeblue.com>>:
Hi Daan,
Thanks for replying and participating. Some points:
* The document links within Primate is a different topic than the docs for Primate itself, the scope of current discussion is limited to documentation for Primate. The doc link within Primate would be done against the 1.0/GA milestone, it would require going through all the sections/APIs against the current CloudStack docs and put a link (or part of it).
* The documentation for Primate currently won't be huge, perhaps a single long page would do (to explain how to install).
* Primate would be a separately installable package and installing cloudstack-management won't automatically trigger installing it (at least in the tech preview, we can discuss how we handle longer term starting with GA/1.0 later).
* We've setup automation for all kinds of packaging formats/channels (we already have that for rpm/deb and archive formats, except for dockerhub hosting which is in discussion with ASF infra). I think publishing artifacts should be quick and mostly automated.
* Github has a new feature called Github packages for each repo, where one can host things like npm, docker packages etc. We can explore this feature.
On a Github release wrt a git tag, we can upload an artifact (I've seen many projects doing this).
* On releasing without voting, my thought and preference is that as our users test Primate, and report bugs and until GA/1.0 we fix those issues, implement missing feature users get faster fixes via a "preview" or "testing" or "beta" release channel periodically (deb/rpms repos, archives, docker container builds).
Doing this would require that we agree on this strategy, without a single tag/version but a set of releases (with a timestamp, so packages would look like cloudstack-primate-$version-$date). So effectively we're saying - let's release the tech preview without doing an official release (which would mean a fix git tag/version). This is where the discussion of a single tech preview release vs rolling tech preview release would come in.
Looking forward to more feedback from our dev/user community and of course our VP @Sven Vogel<ma...@ewerk.com> who has been a major Primate-SIG collaborator. Thanks.
Regards,
Rohit Yadav
Software Architect, ShapeBlue
https://www.shapeblue.com<https://www.shapeblue.com/>
________________________________
From: Daan Hoogland <da...@gmail.com>>
Sent: Thursday, May 7, 2020 12:34
To: dev <de...@cloudstack.apache.org>>
Cc: users@cloudstack.apache.org<ma...@cloudstack.apache.org> <us...@cloudstack.apache.org>>
Subject: Re: [DISCUSS] Primate - publishing release and docs
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 <ro...@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<http://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.yadav@shapeblue.com
www.shapeblue.com<http://www.shapeblue.com/><http://www.shapeblue.com<http://www.shapeblue.com/>>
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
--
Daan
rohit.yadav@shapeblue.com<ma...@shapeblue.com>
www.shapeblue.com<http://www.shapeblue.com/>
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
Re: [DISCUSS] Primate - publishing release and docs
Posted by Sven Vogel <S....@ewerk.com>.
Hi Rohit, Hi Daan,
1. Documentation for tech preview
I agree with Rohit. For me the both suggestions with links sound like a good idea. We should add the download links for official releases or installations for each method on both sites. Maybe its a good idea to have both in sync to we save us the double work. How can we get them in sync? An important point is always the double work. So if there is a method to get them fast in sync in see no problem but if there is many hand work to do maybe its easier to refer from wiki -> to readthedocs or vice versa. I would like to prevent outdated docs on one place.
@Daan
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)
— How could this work? Where we could find the help pop-ups and where should they located?
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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).
— For me all three methods are a good idea because we give the user the greatest flexibility.
a) a repository for rpm and deb
b) publish a docker like ready to use version always dockerhub. By the way everybody can build there own docker container
c) publish the tar.gz on the release section in GitHub or as tar.gz on repository too? What do you think @Rohit, @Daan?
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
3. Hosting packages/releases
* Use download.cloudstack.org<http://download.cloudstack.org> for hosting (a) deb/rpm repos, and (c) archive builds.
— sounds good to me. I would prefer this place.
* Use the apache dockerhub org to publish official Primate container images: https://hub.docker.com/r/apache/cloudstack-primate
— sounds good to me. I would prefer docker hub
My suggestion is to host the tar.gz as release with tags on GitHub, but I am open to put it on the repsository too. Its depend on the work we have and maybe its better to have rpm, deb or
So I thinks this is good because we have three good understandable places. Most people look for a repository for rpm/deb, docker on dockerhub and code release (tar.gz) on GitHub.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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
— sounds good to me. Its a good practise to use the kernel versioning like <major>.<minor>.<security/patchlevel/revision>.<stable version>. Maybe we should remove the timestamp.
cloudtack-primate-4.11.13.1.rpm
cloudtack-primate-4.11.13.1.deb
For docker we need maybe a simpler one
cloudstack-prinate:latest
cloudtack-primate:4.11.13.1
For me its the best way don’t use names like stable or nightly directly in the file names. So we have always a increasing number but in different directory. its possible to mix them if you want. Normally no one should do that but… A better way would for me like
http://download.cloudstack.org/primate/releases/centos/4.11/
http://download.cloudstack.org/primate/releases/debian/4.11/
http://download.cloudstack.org/primate/releases/centos/latest -> point to centos/4.11 or whatever
http://download.cloudstack.org/primate/releases/nightly/centos/
http://download.cloudstack.org/primate/releases/nightly/debian/<http://download.cloudstack.org/primate/releases/centos/latest>
Or
http://download.cloudstack.org/primate/releases/stable/centos/4.11/
http://download.cloudstack.org/primate/releases/stable/debian/4.11/
http://download.cloudstack.org/primate/releases/centos/latest -> point to 4.11 or whatever
http://download.cloudstack.org/primate/releases/nightly/centos/
http://download.cloudstack.org/primate/releases/nightly/debian/<http://download.cloudstack.org/primate/releases/centos/latest>
Its sure possible to make it more clear like /el7/ or /el8/ but I think this is not so important.
I hope I don’t forget something in the discussion. Thanks Rohit for your good prepare of the work here. So its now easier to refine this.
Cheers
Sven
__
Sven Vogel
Lead Cloud Solution Architect
EWERK DIGITAL GmbH
Brühl 24, D-04109 Leipzig
P +49 341 42649 - 99
F +49 341 42649 - 98
S.Vogel@ewerk.com
www.ewerk.com
Geschäftsführer:
Dr. Erik Wende, Hendrik Schubert, Tassilo Möschke
Registergericht: Leipzig HRB 9065
Support:
+49 341 42649 555
Zertifiziert nach:
ISO/IEC 27001:2013
DIN EN ISO 9001:2015
DIN ISO/IEC 20000-1:2011
ISAE 3402 Typ II Assessed
EWERK-Blog<https://blog.ewerk.com/> | LinkedIn<https://www.linkedin.com/company/ewerk-group> | Xing<https://www.xing.com/company/ewerk> | Twitter<https://twitter.com/EWERK_Group> | Facebook<https://de-de.facebook.com/EWERK.IT/>
Auskünfte und Angebote per Mail sind freibleibend und unverbindlich.
Disclaimer Privacy:
Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter Dateien) ist vertraulich und nur für den Empfänger bestimmt. Sollten Sie nicht der bestimmungsgemäße Empfänger sein, ist Ihnen jegliche Offenlegung, Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte informieren Sie in diesem Fall unverzüglich den Absender und löschen Sie die E-Mail (einschließlich etwaiger beigefügter Dateien) von Ihrem System. Vielen Dank.
The contents of this e-mail (including any attachments) are confidential and may be legally privileged. If you are not the intended recipient of this e-mail, any disclosure, copying, distribution or use of its contents is strictly prohibited, and you should please notify the sender immediately and then delete it (including any attachments) from your system. Thank you.
Am 08.05.2020 um 12:21 schrieb Rohit Yadav <ro...@shapeblue.com>>:
Hi Daan,
Thanks for replying and participating. Some points:
* The document links within Primate is a different topic than the docs for Primate itself, the scope of current discussion is limited to documentation for Primate. The doc link within Primate would be done against the 1.0/GA milestone, it would require going through all the sections/APIs against the current CloudStack docs and put a link (or part of it).
* The documentation for Primate currently won't be huge, perhaps a single long page would do (to explain how to install).
* Primate would be a separately installable package and installing cloudstack-management won't automatically trigger installing it (at least in the tech preview, we can discuss how we handle longer term starting with GA/1.0 later).
* We've setup automation for all kinds of packaging formats/channels (we already have that for rpm/deb and archive formats, except for dockerhub hosting which is in discussion with ASF infra). I think publishing artifacts should be quick and mostly automated.
* Github has a new feature called Github packages for each repo, where one can host things like npm, docker packages etc. We can explore this feature.
On a Github release wrt a git tag, we can upload an artifact (I've seen many projects doing this).
* On releasing without voting, my thought and preference is that as our users test Primate, and report bugs and until GA/1.0 we fix those issues, implement missing feature users get faster fixes via a "preview" or "testing" or "beta" release channel periodically (deb/rpms repos, archives, docker container builds).
Doing this would require that we agree on this strategy, without a single tag/version but a set of releases (with a timestamp, so packages would look like cloudstack-primate-$version-$date). So effectively we're saying - let's release the tech preview without doing an official release (which would mean a fix git tag/version). This is where the discussion of a single tech preview release vs rolling tech preview release would come in.
Looking forward to more feedback from our dev/user community and of course our VP @Sven Vogel<ma...@ewerk.com> who has been a major Primate-SIG collaborator. Thanks.
Regards,
Rohit Yadav
Software Architect, ShapeBlue
https://www.shapeblue.com<https://www.shapeblue.com/>
________________________________
From: Daan Hoogland <da...@gmail.com>>
Sent: Thursday, May 7, 2020 12:34
To: dev <de...@cloudstack.apache.org>>
Cc: users@cloudstack.apache.org<ma...@cloudstack.apache.org> <us...@cloudstack.apache.org>>
Subject: Re: [DISCUSS] Primate - publishing release and docs
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 <ro...@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<http://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.yadav@shapeblue.com
www.shapeblue.com<http://www.shapeblue.com/><http://www.shapeblue.com<http://www.shapeblue.com/>>
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
--
Daan
rohit.yadav@shapeblue.com<ma...@shapeblue.com>
www.shapeblue.com<http://www.shapeblue.com/>
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
Re: [DISCUSS] Primate - publishing release and docs
Posted by "Riepl, Gregor (SWISS TXT)" <Gr...@swisstxt.ch>.
Hi Rohit,
Let me comment on just a few of the topics:
> Release cycle
I think we should definitely have a daily/nightly build, at least as long as a lot of changes are incoming.
I'm think along the lines of a parallel installation, so all versions can be tested and users still get a fallback in case of bugs:
- Stable legacy UI (included in cloudstack-management-server, as long as it's available)
- Stable new UI (alongside legacy UI, updated manually)
- Beta test from nightly (updated by an automated script)
> Versioning
Nightlies should not bear a release version, IMHO.
Something like cloudstack-primate-nightly-20200506.x86_64.rpm would be enough.
These should be built and published automatically, and no voting should take place.
When an actual stable/beta release is made, it should only contain the version and not the date, such as cloudstack-primate-0.4.0.x86_64.rpm
These could be voted on, depending on how often they're released.
> Package types and documentation
I'm in favour of supplying all three types of packages, and adding installation instructions for all three.
For the container variant, it may also make sense to provide an example Kubernetes manifest. In can contribute that if desired.
Regards,
Gregor
________________________________
From: Rohit Yadav <ro...@shapeblue.com>
Sent: 08 May 2020 12:21
To: dev <de...@cloudstack.apache.org>; Sven Vogel <S....@ewerk.com>
Cc: users@cloudstack.apache.org <us...@cloudstack.apache.org>
Subject: Re: [DISCUSS] Primate - publishing release and docs
Hi Daan,
Thanks for replying and participating. Some points:
* The document links within Primate is a different topic than the docs for Primate itself, the scope of current discussion is limited to documentation for Primate. The doc link within Primate would be done against the 1.0/GA milestone, it would require going through all the sections/APIs against the current CloudStack docs and put a link (or part of it).
* The documentation for Primate currently won't be huge, perhaps a single long page would do (to explain how to install).
* Primate would be a separately installable package and installing cloudstack-management won't automatically trigger installing it (at least in the tech preview, we can discuss how we handle longer term starting with GA/1.0 later).
* We've setup automation for all kinds of packaging formats/channels (we already have that for rpm/deb and archive formats, except for dockerhub hosting which is in discussion with ASF infra). I think publishing artifacts should be quick and mostly automated.
* Github has a new feature called Github packages for each repo, where one can host things like npm, docker packages etc. We can explore this feature.
On a Github release wrt a git tag, we can upload an artifact (I've seen many projects doing this).
* On releasing without voting, my thought and preference is that as our users test Primate, and report bugs and until GA/1.0 we fix those issues, implement missing feature users get faster fixes via a "preview" or "testing" or "beta" release channel periodically (deb/rpms repos, archives, docker container builds).
Doing this would require that we agree on this strategy, without a single tag/version but a set of releases (with a timestamp, so packages would look like cloudstack-primate-$version-$date). So effectively we're saying - let's release the tech preview without doing an official release (which would mean a fix git tag/version). This is where the discussion of a single tech preview release vs rolling tech preview release would come in.
Looking forward to more feedback from our dev/user community and of course our VP @Sven Vogel<ma...@ewerk.com> who has been a major Primate-SIG collaborator. Thanks.
Regards,
Rohit Yadav
Software Architect, ShapeBlue
https://www.shapeblue.com
________________________________
From: Daan Hoogland <da...@gmail.com>
Sent: Thursday, May 7, 2020 12:34
To: dev <de...@cloudstack.apache.org>
Cc: users@cloudstack.apache.org <us...@cloudstack.apache.org>
Subject: Re: [DISCUSS] Primate - publishing release and docs
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 <ro...@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.yadav@shapeblue.com
> www.shapeblue.com<http://www.shapeblue.com>
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
>
>
>
>
--
Daan
rohit.yadav@shapeblue.com
www.shapeblue.com<http://www.shapeblue.com>
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
Re: [DISCUSS] Primate - publishing release and docs
Posted by "Riepl, Gregor (SWISS TXT)" <Gr...@swisstxt.ch>.
Hi Rohit,
Let me comment on just a few of the topics:
> Release cycle
I think we should definitely have a daily/nightly build, at least as long as a lot of changes are incoming.
I'm think along the lines of a parallel installation, so all versions can be tested and users still get a fallback in case of bugs:
- Stable legacy UI (included in cloudstack-management-server, as long as it's available)
- Stable new UI (alongside legacy UI, updated manually)
- Beta test from nightly (updated by an automated script)
> Versioning
Nightlies should not bear a release version, IMHO.
Something like cloudstack-primate-nightly-20200506.x86_64.rpm would be enough.
These should be built and published automatically, and no voting should take place.
When an actual stable/beta release is made, it should only contain the version and not the date, such as cloudstack-primate-0.4.0.x86_64.rpm
These could be voted on, depending on how often they're released.
> Package types and documentation
I'm in favour of supplying all three types of packages, and adding installation instructions for all three.
For the container variant, it may also make sense to provide an example Kubernetes manifest. In can contribute that if desired.
Regards,
Gregor
________________________________
From: Rohit Yadav <ro...@shapeblue.com>
Sent: 08 May 2020 12:21
To: dev <de...@cloudstack.apache.org>; Sven Vogel <S....@ewerk.com>
Cc: users@cloudstack.apache.org <us...@cloudstack.apache.org>
Subject: Re: [DISCUSS] Primate - publishing release and docs
Hi Daan,
Thanks for replying and participating. Some points:
* The document links within Primate is a different topic than the docs for Primate itself, the scope of current discussion is limited to documentation for Primate. The doc link within Primate would be done against the 1.0/GA milestone, it would require going through all the sections/APIs against the current CloudStack docs and put a link (or part of it).
* The documentation for Primate currently won't be huge, perhaps a single long page would do (to explain how to install).
* Primate would be a separately installable package and installing cloudstack-management won't automatically trigger installing it (at least in the tech preview, we can discuss how we handle longer term starting with GA/1.0 later).
* We've setup automation for all kinds of packaging formats/channels (we already have that for rpm/deb and archive formats, except for dockerhub hosting which is in discussion with ASF infra). I think publishing artifacts should be quick and mostly automated.
* Github has a new feature called Github packages for each repo, where one can host things like npm, docker packages etc. We can explore this feature.
On a Github release wrt a git tag, we can upload an artifact (I've seen many projects doing this).
* On releasing without voting, my thought and preference is that as our users test Primate, and report bugs and until GA/1.0 we fix those issues, implement missing feature users get faster fixes via a "preview" or "testing" or "beta" release channel periodically (deb/rpms repos, archives, docker container builds).
Doing this would require that we agree on this strategy, without a single tag/version but a set of releases (with a timestamp, so packages would look like cloudstack-primate-$version-$date). So effectively we're saying - let's release the tech preview without doing an official release (which would mean a fix git tag/version). This is where the discussion of a single tech preview release vs rolling tech preview release would come in.
Looking forward to more feedback from our dev/user community and of course our VP @Sven Vogel<ma...@ewerk.com> who has been a major Primate-SIG collaborator. Thanks.
Regards,
Rohit Yadav
Software Architect, ShapeBlue
https://www.shapeblue.com
________________________________
From: Daan Hoogland <da...@gmail.com>
Sent: Thursday, May 7, 2020 12:34
To: dev <de...@cloudstack.apache.org>
Cc: users@cloudstack.apache.org <us...@cloudstack.apache.org>
Subject: Re: [DISCUSS] Primate - publishing release and docs
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 <ro...@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.yadav@shapeblue.com
> www.shapeblue.com<http://www.shapeblue.com>
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
>
>
>
>
--
Daan
rohit.yadav@shapeblue.com
www.shapeblue.com<http://www.shapeblue.com>
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
Re: [DISCUSS] Primate - publishing release and docs
Posted by Rohit Yadav <ro...@shapeblue.com>.
Hi Daan,
Thanks for replying and participating. Some points:
* The document links within Primate is a different topic than the docs for Primate itself, the scope of current discussion is limited to documentation for Primate. The doc link within Primate would be done against the 1.0/GA milestone, it would require going through all the sections/APIs against the current CloudStack docs and put a link (or part of it).
* The documentation for Primate currently won't be huge, perhaps a single long page would do (to explain how to install).
* Primate would be a separately installable package and installing cloudstack-management won't automatically trigger installing it (at least in the tech preview, we can discuss how we handle longer term starting with GA/1.0 later).
* We've setup automation for all kinds of packaging formats/channels (we already have that for rpm/deb and archive formats, except for dockerhub hosting which is in discussion with ASF infra). I think publishing artifacts should be quick and mostly automated.
* Github has a new feature called Github packages for each repo, where one can host things like npm, docker packages etc. We can explore this feature.
On a Github release wrt a git tag, we can upload an artifact (I've seen many projects doing this).
* On releasing without voting, my thought and preference is that as our users test Primate, and report bugs and until GA/1.0 we fix those issues, implement missing feature users get faster fixes via a "preview" or "testing" or "beta" release channel periodically (deb/rpms repos, archives, docker container builds).
Doing this would require that we agree on this strategy, without a single tag/version but a set of releases (with a timestamp, so packages would look like cloudstack-primate-$version-$date). So effectively we're saying - let's release the tech preview without doing an official release (which would mean a fix git tag/version). This is where the discussion of a single tech preview release vs rolling tech preview release would come in.
Looking forward to more feedback from our dev/user community and of course our VP @Sven Vogel<ma...@ewerk.com> who has been a major Primate-SIG collaborator. Thanks.
Regards,
Rohit Yadav
Software Architect, ShapeBlue
https://www.shapeblue.com
________________________________
From: Daan Hoogland <da...@gmail.com>
Sent: Thursday, May 7, 2020 12:34
To: dev <de...@cloudstack.apache.org>
Cc: users@cloudstack.apache.org <us...@cloudstack.apache.org>
Subject: Re: [DISCUSS] Primate - publishing release and docs
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 <ro...@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.yadav@shapeblue.com
> www.shapeblue.com<http://www.shapeblue.com>
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
>
>
>
>
--
Daan
rohit.yadav@shapeblue.com
www.shapeblue.com
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
Re: [DISCUSS] Primate - publishing release and docs
Posted by Rohit Yadav <ro...@shapeblue.com>.
Hi Daan,
Thanks for replying and participating. Some points:
* The document links within Primate is a different topic than the docs for Primate itself, the scope of current discussion is limited to documentation for Primate. The doc link within Primate would be done against the 1.0/GA milestone, it would require going through all the sections/APIs against the current CloudStack docs and put a link (or part of it).
* The documentation for Primate currently won't be huge, perhaps a single long page would do (to explain how to install).
* Primate would be a separately installable package and installing cloudstack-management won't automatically trigger installing it (at least in the tech preview, we can discuss how we handle longer term starting with GA/1.0 later).
* We've setup automation for all kinds of packaging formats/channels (we already have that for rpm/deb and archive formats, except for dockerhub hosting which is in discussion with ASF infra). I think publishing artifacts should be quick and mostly automated.
* Github has a new feature called Github packages for each repo, where one can host things like npm, docker packages etc. We can explore this feature.
On a Github release wrt a git tag, we can upload an artifact (I've seen many projects doing this).
* On releasing without voting, my thought and preference is that as our users test Primate, and report bugs and until GA/1.0 we fix those issues, implement missing feature users get faster fixes via a "preview" or "testing" or "beta" release channel periodically (deb/rpms repos, archives, docker container builds).
Doing this would require that we agree on this strategy, without a single tag/version but a set of releases (with a timestamp, so packages would look like cloudstack-primate-$version-$date). So effectively we're saying - let's release the tech preview without doing an official release (which would mean a fix git tag/version). This is where the discussion of a single tech preview release vs rolling tech preview release would come in.
Looking forward to more feedback from our dev/user community and of course our VP @Sven Vogel<ma...@ewerk.com> who has been a major Primate-SIG collaborator. Thanks.
Regards,
Rohit Yadav
Software Architect, ShapeBlue
https://www.shapeblue.com
________________________________
From: Daan Hoogland <da...@gmail.com>
Sent: Thursday, May 7, 2020 12:34
To: dev <de...@cloudstack.apache.org>
Cc: users@cloudstack.apache.org <us...@cloudstack.apache.org>
Subject: Re: [DISCUSS] Primate - publishing release and docs
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 <ro...@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.yadav@shapeblue.com
> www.shapeblue.com<http://www.shapeblue.com>
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
>
>
>
>
--
Daan
rohit.yadav@shapeblue.com
www.shapeblue.com
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
Re: [DISCUSS] Primate - publishing release and docs
Posted by Daan Hoogland <da...@gmail.com>.
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 <ro...@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.yadav@shapeblue.com
> www.shapeblue.com
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
>
>
>
>
--
Daan
Re: [DISCUSS] Primate - publishing release and docs
Posted by Daan Hoogland <da...@gmail.com>.
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 <ro...@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.yadav@shapeblue.com
> www.shapeblue.com
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
>
>
>
>
--
Daan