Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Drop operating system from status, print client side #72

Merged
merged 1 commit into from
Oct 12, 2020
Merged

Drop operating system from status, print client side #72

merged 1 commit into from
Oct 12, 2020

Conversation

cgwalters
Copy link
Member

@cgwalters cgwalters commented Oct 7, 2020 •
edited

For now let's address concerns over how we represent
the operating system by dropping them from the status
JSON. Instead detect CoreOS specifically client side
too and print the aleph there.

@cgwalters cgwalters marked this pull request as draft October 7, 2020 21:06
@cgwalters
Copy link
Member Author

Draft since this depends on #71

@cgwalters cgwalters mentioned this pull request Oct 8, 2020
Merged
@cgwalters cgwalters changed the title model: Serialize CoreOS without going kebab-case Drop operating system from status, print client side Oct 8, 2020
@cgwalters
Copy link
Member Author

OK I reworked this, see commit msg/code.

@cgwalters
Drop operating system from status, print client side
b2f6f0f 
For now let's address concerns over how we represent
the operating system by dropping them from the status
JSON.  Instead detect CoreOS specifically client side
too and print the aleph there.
@cgwalters cgwalters marked this pull request as ready for review October 9, 2020 12:25
@cgwalters
Copy link
Member Author

Rebased 🏄

@cgwalters cgwalters mentioned this pull request Oct 9, 2020
Merged
@lucab
Copy link
Contributor

lucab commented Oct 9, 2020 •
edited

I guess the longer term plan is to reinstate this logic, right? Otherwise a containerized client will end up going off-track.

@cgwalters
Copy link
Member Author

I guess the longer term plan is to reinstate this logic, right? Otherwise a containerized client will end up going off-track.

Mmm...this is just informational. The current client and server logic uses this internally but we're just showing it because it is relevant too.

A bit like how eventually it might make sense to have rpm-ostree status -v at least also chain to bootupctl status perhaps. The daemon wouldn't rely on that in any way, it's just extra information.

@cgwalters
Copy link
Member Author

Any other comments on this?

@lucab
Copy link
Contributor

lucab commented Oct 12, 2020

@cgwalters I think we can merge (although I'm a bit confused about the final goal, but I guess this won't hurt for now).

lucab
lucab approved these changes Oct 12, 2020
View reviewed changes
Copy link
Contributor

@lucab lucab left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm

@openshift-ci-robot
Copy link
Collaborator

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: cgwalters, lucab

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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-merge-robot openshift-merge-robot merged commit 9fb4418 into coreos:master Oct 12, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@lucab lucab lucab approved these changes

@kelvinfan001 kelvinfan001 Awaiting requested review from kelvinfan001

@travier travier Awaiting requested review from travier

Assignees

@lucab lucab

Labels
approved lgtm
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
4 participants
@cgwalters @lucab @openshift-ci-robot @openshift-merge-robot