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.

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

docs: Add apply-live #2655

Merged
merged 1 commit into from
Mar 12, 2021
Merged

docs: Add apply-live #2655

merged 1 commit into from
Mar 12, 2021

Conversation

cgwalters
Copy link
Member

Continuing the more docs momentum.

@cgwalters
Copy link
Member Author

/override ci/prow/images
/override ci/prow/build-clang

@openshift-ci-robot
Copy link
Collaborator

@cgwalters: Overrode contexts on behalf of cgwalters: ci/prow/build-clang, ci/prow/images

In response to this:

/override ci/prow/images
/override ci/prow/build-clang

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.

docs/apply-live.md Outdated Show resolved Hide resolved
Comment on lines +41 to +46
## Updating /etc

The second aspect we need to take care of is `/etc`. Normally, the libostree
core handles the `/etc` merge during shutdown as part of `ostree-finalize-staged.service`,
but we need to do it now in order to ensure that we get new config files
(or remove ones).
Copy link
Member

Choose a reason for hiding this comment

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

Hmm, is there a gap here? If we fiddle with /etc, then the changes are not actually completely transient, and we may accumulate cruft in /etc which never goes away (e.g. if you then rpm-ostree cleanup -p because you actually just wanted to install a debug package you never intended to permanently overlay).

Copy link
Member Author

Choose a reason for hiding this comment

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

Yep, this is absolutely an issue, but mostly mitigated by the fact that what we're stabilizing so far is rpm-ostree install -A in which case the admin is expressing the desire for the changes to persist.

If we added something like rpm-ostree install --transient this would be more of an issue.

I added a blurb on this.

Continuing the more docs momentum.
Copy link
Member

@jlebon jlebon left a comment

Choose a reason for hiding this comment

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

/lgtm

@cgwalters
Copy link
Member Author

Prow isn't enabled here anymore, need to use the button 😄

@cgwalters
Copy link
Member Author

Though I don't see the "merge after checks"...looking

@cgwalters
Copy link
Member Author

OK cool that's enabled. Hmm we didn't talk about which merge format to prefer. I guess...hmmm I dunno. We've been having Prow rebase. I have lost my "merge commits are too ugly for small PRs" feeling over time so I'm also fine with that.

@jlebon jlebon merged commit ac1c75e into coreos:master Mar 12, 2021
@jlebon
Copy link
Member

jlebon commented Mar 12, 2021

OK cool that's enabled. Hmm we didn't talk about which merge format to prefer. I guess...hmmm I dunno. We've been having Prow rebase. I have lost my "merge commits are too ugly for small PRs" feeling over time so I'm also fine with that.

Heh, same here actually. What I don't like is in busy repos where the graph width can get really large, but I don't think we'll have that problem here.

I like that with merge commits you can tell from the git log --graph all the commits which were part of the same PR. My ideal would actually be something like: rebase and then do a trivial merge commit. So then you get the best of both worlds IMO.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants