-
Notifications
You must be signed in to change notification settings - Fork 107
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add initial draft for building WMCore images via CI/CD #11339
Conversation
And, I adjusted CMSKubernetes area to use explicit TAG version in all WMCore Dockefiles, see dmwm/CMSKubernetes@942145b. The tag used in Dockefiles will be replaced by the tag used during a build, see relevant lines in this PR. |
This PR also contains commented sections which we will enable later on once all images will be build. The commented sections require to add CERN registry credentials and we should decide if we'd like to automatically upload images to testbed/testX clusters via imagebot daemon. To do that, we should explicitly change imagebot daemon configuration to add section for appropriate services. If you'll inspect last section you'll see how it is done for all other services, e.g. DAS, WMArchive, etc., on testbed. This step is optional though and we can easily discard it if we do not want automatic deployment of images to testbed/testX clusters. I already instructed @muhammadimranfarooqi and @arooshap to install imagebot on testX clusters such that it will be available for automatic image deployment. |
Jenkins results:
|
Jenkins results:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@vkuznet thanks for providing this action, Valentin.
I have a few remarks to make:
- creating a docker image depends on having the Pypi packages available. So there is a synchronization step that we need to consider when building both PyPi and Docker images on top of a freshly create tag.
- I also left a comment along the code for the tags, where there is a pattern that needs to be excluded
- on what concerns the images that we need to build, please check this list (some are missing here): https://github.com/dmwm/WMCore/wiki/Managing-WMCore-services-in-CMSWEB-kubernetes#list-of-services-and-images-that-need-to-be-provided-from-wmcore
Out of the scope of this PR, I think we should fist close the loop into these new Dockerfiles before throwing many things in parallel (there are many GH issues ongoing, and some should actually be preceding this one).
Jenkins results:
|
Jenkins results:
|
Jenkins results:
|
@amaltaro , @khurtado I updated this PR and switched from @khurtado , could you please try it out as separate step in CI/CD workflow on GitHub Action such that we can test this procedure. For the record here is a diff between
and you can find both files in this CMSKubernetes/docker/pypy/reqmgr2 area. |
Jenkins results:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Valentin, there are a few comments along the code and one of them needs to be definitely addressed.
There is still something that I don't quite get. From the Dockerfile.dist:
RUN pip install reqmgr2ms-monitor-$TAG.tar.gz
how will it work if we do not have such tarball? Once we make a new tag, the only thing we have is:
https://github.com/dmwm/WMCore/archive/refs/tags/2.1.4.tar.gz
Is there something internally that does a magic mapping?
push: | ||
tags: | ||
- '*' | ||
- '!JENKINS*' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given that we are currently struggling with this syntax in the PyPi workflow, I checked the documentation and it seems to be one of the ways to allow/disallow actions based on the tag name.
Another option would be:
tags-ignore:
- 'JENKINS*'
as documented in: https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#onpushbranchestagsbranches-ignoretags-ignore
Just an FYI @khurtado
|
||
- name: Build t0_reqmon image | ||
run: | | ||
curl -ksLO https://raw.githubusercontent.com/dmwm/CMSKubernetes/master/docker/pypi/t0_reqmon/Dockerfile.dist |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We still do not have this t0_reqmon
package in PyPi. I need to review it, but I think the Dockerfile will have to:
RUN pip install reqmon-$TAG.tar.gz
we need to investigate if:
- t0_reqmon is even expected to be packaged in WMCore
- if so, if the package is the same as
reqmon
. It could be that it's during service start up that we decide which CouchApps to use and whatnot.
|
||
- name: Build reqmgr2 image | ||
run: | | ||
curl -ksLO https://raw.githubusercontent.com/dmwm/CMSKubernetes/master/docker/pypi/reqmgr2/Dockerfile.dist |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This Dockerfile seems to be incorrect.
|
||
- name: Build reqmgr2ms-unmerged image | ||
run: | | ||
curl -ksLO https://raw.githubusercontent.com/dmwm/CMSKubernetes/master/docker/pypi/reqmgr2ms-unmerged/Dockerfile.dist |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For this MSUnmerged, I see that the Dockerfile actually depends on two images:
FROM registry.cern.ch/cmsweb/gfal:latest as gfal
FROM python:3.8-bullseye
can you please point to this gfal
Dockerfile?
Alan, of course there is no magic how tar ball should appear in Dockerfile.dist, there are few possibilities which I left out until we make a decision:
So far, I provided a skeleton |
My take on this is that we should not use tarball to deploy WMCore python-based applications. The reason is that we miss the logic embedded in the requirements.txt and setup scripts used to build the PyPi packages with the proper 3rd-party libraries dependencies. Of course we could somehow do the same in the image built script/GH action, but then what is the point of uploading packages to PyPi if we are not using them to create our docker images and deploy services with kuberentes(?) |
Alan, I'm not sure I understand your comment. The line https://github.com/dmwm/WMCore/blob/master/.github/workflows/pypy_build_publish_template.yaml#L33 creates a tarball. And, next section takes tar ball to upload it to pypi. So, during GH Action we create tarballs, and my suggestion to add section which will create images before or after we submit tarball to pypi. This is why everything can be automated within the same GH Action, i.e. it create new tarball based on give tag, it uploads tarball to pypi and it creates corresponding image and upload it to registry. If you need further clarification I suggest to discuss it via zoom chat. Please let me know. |
I see. I guess I was mixing up the WMCore tag tarball from the tarball that gets published to PyPi. If we use it from PyPi, then we indeed get all the python required dependencies in place. I agree that this is what we should do. I think it would be great if we had a way to easily separate these tasks into different GH actions. But expanding the current action template will do the job as well. @khurtado since you wrote the PyPi action scripts, do you have any concerns or opinions on this subject? |
Finally, I managed to build all WMCore MS images via CI/CD GH Action. Please see
I used separate repo to test GH Action, and in this repo I uploaded and modified |
We may close this issue in favor of #11374 |
@vkuznet Valentin, I am not sure I understand what you said. We have been working on this issue: #10921 However, you created a new issue: #11374 and you say the changes provided in this PR are no longer relevant. Besides a possible deployment in k8s, what is the difference between #10921 and #11374 ? |
@amaltaro , on Monday meeting you requested to create a new issue and even put an Action item for it: |
So, the text says to create a PR - pull request - not a GH issue. The issue itself already existed. |
@amaltaro , I followed the same pattern as with any other development. I created an issue and now you have a PR for it #11377 The issue described the logic of steps, e.g. separate repo, why it was created, etc. The PR now contains pull request to WMCore repo. Feel free to close #11374 if you think it is irrelevant. |
I'm closing this now since it is no longer relevant |
Fixes #10921
Status
In development
Description
Add new CI/CD workflow to build WMCore images
Is it backward compatible (if not, which system it affects?)
YES
Related PRs
#11318
External dependencies / deployment changes
GitHub Actions workflow