[Starlingx-discuss] [Build] Create mechanism to publish tarballs in StarlingX
Hi all, As a result of our review for story 2003736 [0], here you have our first level of findings but most important a request for comments: [ Objective ] "Create a new zuul check job to create tarballs from stx projects" Taking the existing OpenStack tarball infrastructure, we have the url tarballs @ openstack org [1] so initial idea would be to host StarlingX tarballs in tarballs @ starlingx io [2] - Any question on the objective? Anything to highlight? - Any other preference where to host the tarballs? [ Zuul ] There are some examples of jobs related to tarballs: - publish-openstack-artifacts - publish-openstack-python-branch-tarball - build-openstack-puppet-tarball - publish-openstack-puppet-branch-tarball Should we target a reuse of existing jobs, probably not listed above or create a new set of jobs? - build-starlingx-tarball - publish-starlingx-tarball Getting your feedback in these first 2 questions will allow us to get a solid direction for the rest of the week. [0] https://storyboard.openstack.org/#!/story/2003736 [1] http://tarballs.openstack.org/ [2] http://tarballs.starlingx.io/
Would we want to publish tarballs on mirrors.starlingx.cengn.ca as part of the build process? Tarball would be updated nightly, rather than with every update as a zuul based solution would have it. e.g. http://mirror.starlingx.cengn.ca/mirror/starlingx/<branch>/centos/<timestamp>/outputs/tarballs/<repo-name>-<branch>.tar.gz or only publish the latest on branch... an in a structure more like that seen in http://tarballs.openstack.org ... http://mirror.starlingx.cengn.ca/mirror/starlingx/tarballs/<repo-name>/<repo-name>-<branch>.tar.gz On 18-11-21 10:14 AM, Arce Moreno, Abraham wrote:
Hi all,
As a result of our review for story 2003736 [0], here you have our first level of findings but most important a request for comments:
[ Objective ]
"Create a new zuul check job to create tarballs from stx projects"
Taking the existing OpenStack tarball infrastructure, we have the url tarballs @ openstack org [1] so initial idea would be to host StarlingX tarballs in tarballs @ starlingx io [2]
- Any question on the objective? Anything to highlight? - Any other preference where to host the tarballs?
[ Zuul ]
There are some examples of jobs related to tarballs:
- publish-openstack-artifacts - publish-openstack-python-branch-tarball - build-openstack-puppet-tarball - publish-openstack-puppet-branch-tarball
Should we target a reuse of existing jobs, probably not listed above or create a new set of jobs?
- build-starlingx-tarball - publish-starlingx-tarball
Getting your feedback in these first 2 questions will allow us to get a solid direction for the rest of the week.
[0] https://storyboard.openstack.org/#!/story/2003736 [1] http://tarballs.openstack.org/ [2] http://tarballs.starlingx.io/
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
Thanks Scott,
Would we want to publish tarballs on mirrors.starlingx.cengn.ca as part of the build process?
Yes, another path to go: [ Hosting Site ] Everyone: Pros? Cons? 1. tarballs.starlingx.io 2. mirrors.starlingx.cengn.ca Then let me put high level [ Zuul ] implementation on hold and focus for now on how to reach our rephrased [ Objective ]: "Create a new job to create tarballs from stx projects in our path to have a build system architecture for Multi OS" Everyone? Is this a reasonable objective for this story?
Tarball would be updated nightly, rather than with every update as a zuul based solution would have it.
e.g. http://mirror.starlingx.cengn.ca/mirror/starlingx/<branch>/centos/<timesta mp>/outputs/tarballs/<repo-name>-<branch>.tar.gz
or only publish the latest on branch... an in a structure more like that seen in http://tarballs.openstack.org ...
http://mirror.starlingx.cengn.ca/mirror/starlingx/tarballs/<repo- name>/<repo-name>-<branch>.tar.gz
I am taking your feedback to line up the following 2 procedures: - Build Process - Updates every night - Zuul - Updates every change merged Everyone: Pros? Cons? Future Limitations?
On Mon, Nov 26, 2018 at 10:53 AM Arce Moreno, Abraham <abraham.arce.moreno@intel.com> wrote:
Thanks Scott,
Would we want to publish tarballs on mirrors.starlingx.cengn.ca as part of the build process?
Yes, another path to go:
[ Hosting Site ]
Everyone: Pros? Cons?
1. tarballs.starlingx.io 2. mirrors.starlingx.cengn.ca
Then let me put high level [ Zuul ] implementation on hold and focus for now on how to reach our rephrased [ Objective ]:
"Create a new job to create tarballs from stx projects in our path to have a build system architecture for Multi OS"
Everyone? Is this a reasonable objective for this story?
yes +1
Tarball would be updated nightly, rather than with every update as a zuul based solution would have it.
e.g. http://mirror.starlingx.cengn.ca/mirror/starlingx/<branch>/centos/<timesta mp>/outputs/tarballs/<repo-name>-<branch>.tar.gz
or only publish the latest on branch... an in a structure more like that seen in http://tarballs.openstack.org ...
http://mirror.starlingx.cengn.ca/mirror/starlingx/tarballs/<repo- name>/<repo-name>-<branch>.tar.gz
Are we going to increase the version of the tar.gz on every change?
I am taking your feedback to line up the following 2 procedures:
- Build Process - Updates every night - Zuul - Updates every change merged
Everyone: Pros? Cons? Future Limitations?
This is necessary from the SW release perspective. If we can separate the STX SW from the distro management is much more easy to deploy a MultiOS solution for STX Let's take for example httpd: httpd community creates a release, let's say httpd-2.4.35. They create a tarball for every release with release notes of what they fix/improve Other distributions can generate spec files or debs acording to their needs and installing httpd as they prefer on their Linux distributions Son in general +1 to this Abraham I refer to this change in my multi OS spec : https://review.openstack.org/#/c/619801/ Regards
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
participants (3)
-
Arce Moreno, Abraham
-
Scott Little
-
Victor Rodriguez