-
Notifications
You must be signed in to change notification settings - Fork 81
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
[RFE] Creating mirroring config from running clusters #304
Comments
I have some thoughts and questions about this: This would be very helpful for users transitioning from lab environments to subsequent iterations of their practiced cluster deployments. There is a lot to be said for easing the process of authoring the imageset config. We had originally pushed back on this request in favor of an ansible role or script to retrieve this information, but this might be a good fit for oc-mirror. @dinhxuanvu If an operator name and its version are dumped from a cluster, is there any correlation within the cluster to determine the catalog that the operator was installed from? How does the operator hub configuration play into this? Or will we have to get the name and version and then use the oc-mirror list workflows to discover this information? @dmesser I do not see time in the schedule to implement this feature in 4.11. What release are you targeting? |
I have hacked up a simple PoC in goLang that kinda does this, if there is interest, I can look into how to share it, right now its inside an ibm git repo logic
|
Hi folks, While I can see the thought behind this, at the same time I'm not sure about oc-mirror generating a config is a practical use case or make sense given what oc-mirror is for primarily. From the operator mirror perspective, I'm a bit concerned about the prospect of filing the On the question from Alex, finding the installed version is actually quite difficult here without touching other APIs from OLM. oc-mirror is only using FBC API. It currently doesn't touch Subscription API which is needed in this case to find out what is the |
It sounds like the maintenance of this feature would be a distraction to the development of oc-mirror. If that's the case, I think that the resource lookups that this feature requires might be best performed by oc and then templated into an imageset-confg with something like ansible/jinja. |
@dinhxuanvu @afflom I agree with your assessment. This seems like something useful but maybe out of scope for the @dinhxuanvu Yes, such a tool needs to touch probably OLM APIs to do it's job, but I don't see how that is a problem. |
Issues go stale after 90d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle stale |
Stale issues rot after 30d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle rotten |
/lifecycle frozen |
What is desired
The configuration file for
oc mirror
needs to be assembled by the user. Some users may have running clusters that they simply want to clone.oc mirror
should have a feature that allows to create mirroring configuration that corresponds to a cluster that it is being pointed at. The result is a mirror that can be used to run that same cluster disconnected from public registries.What you expected to happen?
oc mirror
would make use of theoc
context that it is running in as a plugin to connect to a particular cluster. It would need sufficient permissions to introspect the cluster and survey the following data points:Duplicate results need to be removed from the above sets.
The output of the survey should be a ready-to-run mirror configuration file that is stored on disk or sent to stdout for reuse.
The text was updated successfully, but these errors were encountered: