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.vo...@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.ya...@shapeblue.com
<mailto:rohit.ya...@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<mailto:s.vo...@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.hoogl...@gmail.com<mailto:
daan.hoogl...@gmail.com>>
Sent: Thursday, May 7, 2020 12:34
To: dev <dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>>
Cc: us...@cloudstack.apache.org<mailto:us...@cloudstack.apache.org> <
us...@cloudstack.apache.org<mailto: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 <rohit.ya...@shapeblue.com
<mailto:rohit.ya...@shapeblue.com>>
wrote:
All,
With this thread I want to start a discussion around:
* How do we host/publish technical preview release
* How do we host/publish technical preview documentation (release
notes, setup/install instructions)
To set the expectation:
* This thread limits discussion wrt technical preview (beta).
* Plan we've already agreed, just to recap: ....
...
* References:
* Voting thread: https://markmail.org/message/tblrbrtew6cvrusr
* Proposal:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Proposal%3A+CloudStack+Primate+UI
* Discussion thread:
https://markmail.org/message/z6fuvw4regig7aqb
...
* Outstanding issues wrt 0.5-technical-preview milestone:
https://github.com/apache/cloudstack-primate/milestone/1
* Oustanding PRs for 0.5-technical-preview:
https://github.com/apache/cloudstack-primate/pulls?q=is%3Aopen+is%3Apr+no%3Amilestone
...
1. Documentation for tech preview:
It is preferred that Primate be developed, maintained and released
separately from CloudStack. Primate would require its own docs
website/location for hosting release notes etc. I can think of two
ways:
* For tech preview, let's just a section/topic on Primate on how
users can install and use Primate on the docs website:
http://docs.cloudstack.apache.org/en/latest/primateguide (it does not
exist, just for example)
For each CloudStack release, the docs may be updated, including list
of
supported/required versions matrix (both CloudStack and Primate).
For tech preview, this needs to be on the 4.14.0.0 docs website.
* On Github wiki:
https://github.com/apache/cloudstack-primate/wiki
we can maintain a copy of text/pages from above ^^, as well as links
on the
Github release for every git tag. A general guide (agnostic of Primate
version) could be written/hosted there.
(similar to CloudStack releases, for example:
https://github.com/apache/cloudstack/releases/tag/4.13.0.0)
I think Primate should be documented by means of help pop-ups with
links to
the underlaying API and admin docs. How big do you expect this
documentation to become? (I would think it is only a short readme on
first
use)
2. Types of Primate packages:
* deb/rpm: Primate already supports deb/rpm packages. This mode
will allow users to install "cloudstack-primate" on the management
server
where Primate will be served from the management server just like the
old
UI.
* docker container: Primate support docker containers to be
built/used which takes a nginx config to proxy /client path to any
management server.
* archive build: A built archive (tar.gz) of Primate can be
extracted and allow users/admins to do any custom hosting with it,
other
than (a) or (b).
The install/setup/usage instructions are in general as follows: (will
be
properly documented on the docs website/location)
- For (a), we need setup the repository, then run (1) yum/apt-get
update,
(2) yum/apt-get install <cloudstack-primate> on a management server
host.
- For (b), we need to run the docker container and pass a nginx config
file. (similar to https://github.com/apache/cloudstack-primate#docker)
- For (c), we extract and use Primate in a custom setup (that's upto
the
user/admin); they may also fork/customise Primate and build (as per
https://github.com/apache/cloudstack-primate#production).
I agree, it makes it easier to develop. as long as the installation
can
combine a suitable primate with each cloudstack, OR vice versa; one
could
`dnf/pkg install cloudstack --withUI`. This might be unecessary
complivcated in wich case we could go for separate pkgs and
pkgs-withUI.
In general the flexibility you are describing is good but might be
hard to
maintain.
3. Hosting packages/releases:
* Use download.cloudstack.org<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.ya...@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.ya...@shapeblue.com<mailto:rohit.ya...@shapeblue.com>
www.shapeblue.com<http://www.shapeblue.com/>
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
