add: okd-rpms buildconfig and tools:fedora37 istag; change: fedora-coreos buidconfig to point to git ref release-4.12, build-from-scrathc and full-rebuild pipeline to include okd-rpms build #36
Conversation
change: fedora-coreos buidconfig to point to git ref release-4.12, build-from-scrathc and full-rebuild pipeline to include okd-rpms build
variants/fcos/okd-rpms/manifests/99-okd-master-disable-mitigations.yaml
Outdated
Show resolved
Hide resolved
variants/fcos/okd-rpms/manifests/99-okd-worker-disable-mitigations.yaml
Outdated
Show resolved
Hide resolved
| @@ -0,0 +1,17 @@ | |||
| FROM release:artifacts as artifacts | |||
| FROM release:machine-config-operator as mcd | |||
There was a problem hiding this comment.
mcd layer might be unnecessary, it was introduced just for "backward compatibility" and used for
# TODO: check: is it really needed
COPY --from=mcd /usr/bin/machine-config-daemon /binaries/machine-config-daemon
|
|
||
| RUN \ | ||
| mkdir -p /rpms && \ | ||
| mv -v /tmp/rpms/$([ -d /tmp/rpms/$(uname -m) ] && echo $(uname -m)/)*.rpm /rpms/ && \ |
There was a problem hiding this comment.
is it worth adding the rpms in the artifacts and adding an imagestreamtag referencing it with name okd-rpms?
In future, the two names should converge.
There was a problem hiding this comment.
wouldn't like to break any builds which depend on original quay.io/coreos-assembler/fcos:next-devel, if any
There was a problem hiding this comment.
as i understand correctly scos would be like rhel coreos and it will contain any necessary rpms (including crio), its a reason when fcos variant is a little separated at the momemnt (or opposite)
There was a problem hiding this comment.
The artifacts image is not part of the payload but an auxiliary image.
Adding the cri-o rpms and using some symbolic links to refer the rpms where they are currently stored should be enough if I understand correctly the use case. The consumers of the rpms will use the rpms at need...
There was a problem hiding this comment.
there are still some references to GetOKDRPMSImage within assisted service codebase:
https://github.com/openshift/assisted-service/blob/99125bfa925143394e32f785e104c63624d1f601/internal/oc/release.go#L45
https://github.com/openshift/assisted-service/blob/99125bfa925143394e32f785e104c63624d1f601/internal/ignition/ignition.go#L1627
finally the GetOKDRPMSImage refers to okdRPMSImageName = "okd-rpms" as tag for registry/okd/okd-contents:4.12.0-0.okd-xxxx-okd-rpms
and this is a point where scos might be more suitable: full control for OS version/build and ostree (including crio, kubelet, cli, ncat, etc) without temporary rpm overlaying on bootkube/bootstrap procedure
|
included into #39 (comment) |
hello dear okd-team, please review pull-req
tldr:
added ability to build
okd-rpmsas a part of the pipelinebuild-from-scratchdetails:
registry/okd/okd-release:4.12.0, so its addedvariants/fcos/40-okd-rpms.yaml, with refers toistag tools:fedora37okd-rpmsin the main pipeline (sorry not able to find better way at the moment than refer of array indices like3and0via hardcoded style), it needs to be fixedbuild-from-scratchpipeline (taskbatch-03), also i'm not sure the pipelinefull-rebuildis not out of date, since i've not foundmachine-os-contentbuildconfig, although found `machine-os-content' istagrelease-4.12and it has some side effetcs for the bcfedora-coreos(30-fedora-coreos.yaml) which belogs of tools:fedora-coreos, wich points to quay.io/coreos-assembler/fcos:next-devel; and i'm not sure that fedora-coreos:next-devel is the best choice for 4.12 (cri-o 1.28), it seems fedora-coreos:stable most suitable at the moment? lets fix this by changingrefattribute of 30-fedora-coreos.yaml builconfig to git refrelease-4.12