-
Notifications
You must be signed in to change notification settings - Fork 104
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
MCO-280: extensions: Add container to serve repository with extensions #763
Conversation
Skipping CI for Draft Pull Request. |
Let's put all these files in an |
That makes sense, I'll push that change today. |
0bf0a32
to
92ed4c6
Compare
Cross-linking to https://issues.redhat.com/browse/MCO-288 I've been thinking about this one more, particularly in light of the discovery in coreos/coreos-assembler#2685 (comment) I think combining those two facts pulls this back towards being something like |
Closing this PR in favor of the above. |
Ideally though, we can reuse some or most of the code/approach here. We still need the webserver, etc. This was definitely not a lost effort! I might have said we should keep the PR open as a reference and then rework it, but either way the code isn't lost. Or alternatively...we could keep this all as is, but have a flow that updates meta.json after the "main" RHCOS build job. (Though, this gets into races unless we have a coordinator...needs some design) |
I understand that, but does it still make sense to have most of that code here? I would imagine we would want to move a good chunk of this to cosa? |
Joseph and I had a live chat about this. We're thinking we can:
|
Let's keep this open since I think we can likely reuse 95% of this work! |
574e822
to
6d274b8
Compare
6d274b8
to
abae295
Compare
This depends on coreos/rpm-ostree#3819 |
abae295
to
78329d2
Compare
6d4e7dd
to
9223edb
Compare
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cgwalters, jmarrero The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
@jmarrero: all tests passed! Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
controllerconfig The extensions for our layered/bootable `rhel-coreos` images are no longer going to be contained within the image themselves. They will be a separate container. See: openshift/os#763 This makes sure that, if present, the new extensions image gets pushed through to controllerconfig and is available when merging machineconfigs.
controllerconfig The extensions for our layered/bootable `rhel-coreos` images are no longer going to be contained within the image themselves. They will be a separate container. See: openshift/os#763 This makes sure that, if present, the new extensions image gets pushed through to controllerconfig and is available when merging machineconfigs.
controllerconfig The extensions for our layered/bootable `rhel-coreos` images are no longer going to be contained within the image themselves. They will be a separate container. See: openshift/os#763 This makes sure that, if present, the new extensions image gets pushed through to controllerconfig and is available when merging machineconfigs.
controllerconfig The extensions for our layered/bootable `rhel-coreos` images are no longer going to be contained within the image themselves. They will be a separate container. See: openshift/os#763 This makes sure that, if present, the new extensions image gets pushed through to controllerconfig and is available when merging machineconfigs.
controllerconfig The extensions for our layered/bootable `rhel-coreos` images are no longer going to be contained within the image themselves. They will be a separate container. See: openshift/os#763 This makes sure that, if present, the new extensions image gets pushed through to controllerconfig and is available when merging machineconfigs.
The extensions for our layered/bootable `rhel-coreos` images are no longer going to be contained within the image themselves. They will be a separate container. See: openshift/os#763 This makes sure that, if present, the new extensions image gets pushed through to controllerconfig and is available when merging machineconfigs.
For OCP layering, we're changing the way the extensions are retrieved -- they are present in their own separate container, intended to be run as a service that serves up the RPM repo (see openshift/os#763) for details. This adds manifests for that extensions container deployment and the service that will allow the nodes to connect to it.
For OCP layering, we're changing the way the extensions are retrieved -- they are present in their own separate container, intended to be run as a service that serves up the RPM repo (see openshift/os#763) for details. This adds manifests for that extensions container deployment and the service that will allow the nodes to connect to it.
depends on: coreos/rpm-ostree#3562
This container will create a small service that will host the extensions rpms that we will be shipping. The idea is that this new container will be shipped alongside the machine-os and would provide a way for users layering extensions a way to do so without depending of connections outside of the cluster.
https://issues.redhat.com/browse/MCO-288