STF 1.5.4 release ops #129
Conversation
[zuul] Add zuul jobs to sg-core
* Add prometheus to devstack plugin * Add uidmap installation for ubuntu distributions In order to interact with podman, we need the newuidmap binary. I've seen this being present on centos vms by default, but on some ubuntu / debian vms this isn't the case and the plugin fails to pull images.
Instead of updating the .zuul.yaml file everytime infrawatch/service-telemetry-operator adds a new job, the project-template can be updated in STO, which will propogate the change to the project and avoid leaving gaps in testing. Depends-On: infrawatch/service-telemetry-operator#514
Often times during unstack, containers get stuck in "Stopping" state and do not get cleaned up. These left over containers cause next run of stack.sh to fail because the script tries to spawn them with the name same.
Remove sg-core & prometheus containers with force
* Move to golang 1.20 * Bump golangci-lint to 1.51 for golang 1.20 support
|
recheck |
|
None of the changes here seem related to STF functionality (more to do with devstack and RHOSO 18). Do we really need this merge to stable-1.5? (which is focused on only STF related functionality)? |
Interesting observation! We definitely need a rebuild of this container on golang 1.20, but I cherry-picked that change awhile ago when the priority was set higher and we thought there would be an async release. I think you're right that we could otherwise not bother with this PR and just tag/rebuild what is already on the stable-1.5 branch. OTOH, merging this seems entirely risk-free and means we've followed the expected pattern and won't have to consider this again next time. |
So the base image for golang is entirely controlled downstream, independent of merging anything here (unless there were code changes required or go.mod updates etc to satisfy for that). I agree though, there is very little to no risk here to merge this down as-is. I just wanted to note these changes are primarily directed at RHOSO 18, and we need to be aware that stable-1.5 needs to be kept free of any future features or changes related to RHOSO in order to keep STF stable. Going forward, I will expect sg-core to get a separate |
|
recheck |
Agreed that the downstream base image is controlled elsewhere, but changing the go version does require a change to go.mod (35d6fbe#diff-33ef32bf6c23acb95f5902d7097b7a1d5128ca061167ec0716715b0b9eeaa5f6L3) I'm unsure what happens if we build in the 1.20 container with a go.mod that says 1.19.
This is a very good point - @vkmc , we were talking about how every repo seems like it can follow the simple master -> stable-1.5 merge workflow this time (and hoped for that for the future, too), but it looks like this will need to be an exception. As Leif mentions, future feature work will be targetting a rhoso-18 branch, and we should only be cherry-picking specific changes that are needed for security updates to stable-1.5. We should update the README in this repo to mention that, and also add it to our release process documentation. |
Ah good point! I didn't realize go.mod also had a version association. I'll try and store that somewhere in my brain.
Yea I'm not exactly sure how this will work, but I would suggest sync'ing with the OSP squad and RelDel to make sure there is an understanding what should/will happen here. Based on some other discussions it looked like there was potential new development, and we want to make sure that's not landing in stable-1.5 and have to deal with regressions in STF 1.5 for future work. Ideally nothing really lands in stable-1.5 going forward, but if there are CVE fixes for some reason that aren't just base image changes, and we need to import, I'd just hate to spend time debugging. Might not be a real issue, but something to keep in mind. I think sg-core is the only repo that will be used across projects. |
No description provided.