-
Notifications
You must be signed in to change notification settings - Fork 15
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
fixes for pipeline flow/dependencies #38
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
…es-base 2. network-tools: revert to able to build for 4.12 branch 3. ovn-kubernetes{,-base}: the only 4.13 depends on Dockerfile.*rhel9, 4.12, 4.14+ are built by just Dockerfile
build sequance: 10-* ovn-kubernetes-base 20-* ovn-kubernetes, ovn-kubenetes-microshift 30-* network-tools
@@ -0,0 +1,21 @@ | |||
FROM release:artifacts as artifacts |
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 want to avoid adding new Dockerfiles here.
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.
Right, we don't need those. okd-rpms
is useful for Assisted Installer but not usable for SCOS installs
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.
so, what is the solution? should okd-rpms be build separately out of main pipeline? or just create symlinks inside release:artifacts imagestream to make assisted installer feature supported? but ai still refers to release:okd-rpms
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.
i'd say symbolic links could be good.
To resolve the release:okd-rpms
missing ISTag, can we create it in advance even if the source IStag (artifacts) is not yet available?
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.
just for my understanding: will release:artifacts
and release:installer-artifacts
be converged further?
@@ -0,0 +1,18 @@ | |||
apiVersion: machineconfiguration.openshift.io/v1 |
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.
Ditto, we should build SCOS with these options enabled (not sure if intel_pstate is necessary anymore)
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.
@vrutkovs we don't build scos here yet as we consume it directly from the artifacts produced by the okd-project/okd-scos pipeline.
Ideally, we should reach a target like:
- okd-project/okd-scos produces a base scos image (w/o okd-specific content)
- we build the layered okd-specific scos as we do for fcos (leveraging a third repo similar to openshift/okd-machine-os)
right?
included into #39 (comment) |
hello, dear okd-team,
please review the pull-req
ovn-kubernetes
andovn-kubernetes-base
must be built viaDockerfile
andDockerfile.base
, except for 4.13 branch(i see there is a new kustomization rule for 4.13
- op: replace
seems Dockerfile.*rhel9 migth be applied here)okd-payload-pipeline/buildconfigs/kustomization.yaml
Line 8 in a1c1361
ovn-kubernetes
depends onovn-kubernetes-base
and must be build on the next step of the pipelineregistry.ci.openshift.org/ocp/4.12:ovn-kubernetes
as FROM