-
Notifications
You must be signed in to change notification settings - Fork 410
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
Switch to https://github.com/coreos/rpmostree-client-go #3302
Switch to https://github.com/coreos/rpmostree-client-go #3302
Conversation
If we go this route (and I think we should) a next step would be to just remove the |
Prep for openshift#3302 We should either use dependabot for openshift/ or use another similar tool.
Yes, I think we can probably work through what to do with the "node updater client" as we work through layering? |
We'll definitely move this into github.com/coreos/rpmostree-client-go - and anyone on the coreos team hence could review and merge PRs. (Not to mention, happy to give review/commit access to you too 😄 ) |
Depends on #3325 |
ad107e9
to
6294094
Compare
OK now that #3317 merged, I've rebased 🏄 this |
6294094
to
bf31968
Compare
I've invited @jkyros from this team as a collaborator on https://github.com/coreos/rpmostree-client-go (and am happy to add others) to ensure the MCO team can always get timely and quick fixes into that repo. (But that said again, nothing at all stops the MCO or anyone else from continuing to just run |
Just wanted to add that I like this change and am happy to see rpm-ostree get its own proper client! |
/test okd-e2e-aws |
Friendly ping, seems like everyone's in favor, can someone drop a lgtm? |
Don't see any concern with this move. Also happy that rpm-ostree will be having its own client lib which multiple project can directly use (including MCO) Minor update in commit message and PR header |
We have a lot of ad-hoc code in the MCO interacting with rpm-ostree. There's about 50% of it that uses this "NodeUpdaterClient" abstraction which I guess in theory could have tried to also support e.g. traditional dnf/apt systems or whatever, but never did - and its API has grown things that make no sense on those systems (e.g. "staged deployment" etc.) The other half of the code ignores that abstraction (sensibly) and just runs `rpm-ostree` via the CLI directly, crafting command line arguments. We now have https://github.com/coreos/rpmostree-client-go which is intending to be "official" Go bindings which for now just wrap the CLI, but do so in a more consistent way and offering a cleaner API.
bf31968
to
3e58742
Compare
Ah yep, updated the commit and PR title. |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cgwalters, sinnykumari 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 |
@cgwalters: The following tests failed, say
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. |
We have a lot of ad-hoc code in the MCO interacting with rpm-ostree.
There's about 50% of it that uses this "NodeUpdaterClient" abstraction
which I guess in theory could have tried to also support e.g.
traditional dnf/apt systems or whatever, but never did - and
its API has grown things that make no sense on those systems (e.g.
"staged deployment" etc.)
The other half of the code ignores that abstraction (sensibly) and
just runs
rpm-ostree
via the CLI directly, crafting commandline arguments.
We now have https://github.com/coreos/rpmostree-client-go
which is intending to be "official" Go bindings which for now
just wrap the CLI, but do so in a more consistent way and offering
a cleaner API.