[Starlingx-discuss] Build Layering and refactoring of repos
Hi Scott, I was reviewing the google spreadsheet [0] you shared during the Build Sub-team [1] meeting last week. I think this is a good direction and I am beginning to understand your logic and urgency around making the changes. I have some comments some of the moves. 1) Did you factor in any of Dean's thoughts about reorgs? email [2] / ethercalc [3] 2) can we remove the stx- prefix from the new repos to start with instead of propagating that given we are inside the starlingx/ namespace alread? 3) not sure if "compile" is right name the layer of packages (go, python, rpm, and bash), does bash really belong here, I don't think we depend on it for the build, do we ? Is there a specific modification to bash that build specific? 4) openstack-helm* I believe is used by stx-platform-helm, at least we saw that dependency with the MultiOS/openSUSE specfiles. 5) Maybe a future move is getting integ/puppet into the toplevel puppet repo and ultimately part of ansible-playbooks if the plan is to convert to ansible. Thanks Sau! [0] https://docs.google.com/spreadsheets/d/1zURL1UlDST8lnvw3dMlNWN6pkLX6EVF6TDBw... [1] https://etherpad.openstack.org/p/stx-build [2] http://lists.starlingx.io/pipermail/starlingx-discuss/2019-May/004597.html [3] https://ethercalc.openstack.org/stx-repo-org
On 2019-07-16 4:42 p.m., Saul Wold wrote:
Hi Scott,
I was reviewing the google spreadsheet [0] you shared during the Build Sub-team [1] meeting last week. I think this is a good direction and I am beginning to understand your logic and urgency around making the changes. I have some comments some of the moves.
1) Did you factor in any of Dean's thoughts about reorgs? email [2] / ethercalc [3]
No, I had missed that one. Was rather busy with containerized builds back then. They all seem like good goals, but orthagonal to partitioning the build into Distro/Flock. I think they should be persued as independent projects. The tool I am developing to assist in the proposed movements might aid those projects as well.
2) can we remove the stx- prefix from the new repos to start with instead of propagating that given we are inside the starlingx/ namespace alread?
We should be able to do this concurrently if desired. I like the idea of getting both high impact changes done at the same time. My only concern is that this expands the scope to additional high churn repos.
3) not sure if "compile" is right name the layer of packages (go, python, rpm, and bash), does bash really belong here, I don't think we depend on it for the build, do we ? Is there a specific modification to bash that build specific?
Virtually everything depends on bash directly or indirectly through other build tools.
4) openstack-helm* I believe is used by stx-platform-helm, at least we saw that dependency with the MultiOS/openSUSE specfiles.
Agree
5) Maybe a future move is getting integ/puppet into the toplevel puppet repo and ultimately part of ansible-playbooks if the plan is to convert to ansible.
I'd like Don's input on this.
Thanks Sau!
[0] https://docs.google.com/spreadsheets/d/1zURL1UlDST8lnvw3dMlNWN6pkLX6EVF6TDBw... [1] https://etherpad.openstack.org/p/stx-build [2] http://lists.starlingx.io/pipermail/starlingx-discuss/2019-May/004597.html [3] https://ethercalc.openstack.org/stx-repo-org
On 7/17/19 8:44 AM, Scott Little wrote:
On 2019-07-16 4:42 p.m., Saul Wold wrote:
Hi Scott,
I was reviewing the google spreadsheet [0] you shared during the Build Sub-team [1] meeting last week. I think this is a good direction and I am beginning to understand your logic and urgency around making the changes. I have some comments some of the moves.
1) Did you factor in any of Dean's thoughts about reorgs? email [2] / ethercalc [3]
No, I had missed that one. Was rather busy with containerized builds back then.
They all seem like good goals, but orthagonal to partitioning the build into Distro/Flock. I think they should be persued as independent projects. The tool I am developing to assist in the proposed movements might aid those projects as well.
Fair enough, let's get Dean's input here at least.
2) can we remove the stx- prefix from the new repos to start with instead of propagating that given we are inside the starlingx/ namespace alread?
We should be able to do this concurrently if desired. I like the idea of getting both high impact changes done at the same time. My only concern is that this expands the scope to additional high churn repos.
3) not sure if "compile" is right name the layer of packages (go, python, rpm, and bash), does bash really belong here, I don't think we depend on it for the build, do we ? Is there a specific modification to bash that build specific?
Virtually everything depends on bash directly or indirectly through other build tools.
But why can't we use the system provided bash rather then needing the patched version, what specific patches are needed? I don't then the extra logging is the requirement here.
4) openstack-helm* I believe is used by stx-platform-helm, at least we saw that dependency with the MultiOS/openSUSE specfiles.
Agree
5) Maybe a future move is getting integ/puppet into the toplevel puppet repo and ultimately part of ansible-playbooks if the plan is to convert to ansible.
I'd like Don's input on this.
Sure. Sau!
Thanks Sau!
[0] https://docs.google.com/spreadsheets/d/1zURL1UlDST8lnvw3dMlNWN6pkLX6EVF6TDBw...
[1] https://etherpad.openstack.org/p/stx-build [2] http://lists.starlingx.io/pipermail/starlingx-discuss/2019-May/004597.html
On 2019-07-17 12:28 p.m., Saul Wold wrote:
3) not sure if "compile" is right name the layer of packages (go, python, rpm, and bash), does bash really belong here, I don't think we depend on it for the build, do we ? Is there a specific modification to bash that build specific?
Virtually everything depends on bash directly or indirectly through other build tools.
But why can't we use the system provided bash rather then needing the patched version, what specific patches are needed? I don't then the extra logging is the requirement here.
I agreed our current patch should not alter how anything builds in any direct way. However it does cause royal havoc on the build order. It's presence as a buildable object creates many dependency loops. Not only do a lot of packages depend on bash, bash alos depends on a lot of packages. Build-pkgs can't determine a build order and must guess. It wastes a lot of time trying to build packages in the wrong order, and failing, before it stumbles onto a good order. Scott
participants (2)
-
Saul Wold
-
Scott Little