compose: Delete non-unified-core code #1793
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
OK, so this is much more aggressive than #1739. ⏩ That WFM, though at the same time, we only really have a lot of experience with unified core mode through FCOS and RHCOS.
Did you also boot it up? Before doing this, as a basic sanity check, we should definitely do test composes of SB and AH and boot up/rebase hosts to the composes. I don't expect anything to go wrong, but checking now is much cheaper than potentially reverting or fixing things once this is in the runroot or OSTrees are pushed out. |
+1 - could we just take this patch and apply it to the rpm in rawhide now and test things there ? Maybe we should also wait til after f30 GA so we can stabilize and get f30SB out without issues. |
|
I don't think we need to worry too much about FAH; we just don't ship this in f29 right? (Though I did a quick test and it builds fine) I've been testing FSB29 with this effectively by using my branch to make it build with cosa (and that includes running it, in fact the desktop I'm typing this from was built that way, although later rebased to the f30 ref not built via unified core). I think you're right that the rebase is a good test. I'll do that, and also look at the filesystem-level difference. The thing that's striking though is just how much nicer cosa is to use than raw rpm-ostree...going back to the past where you init repos by hand, the configs are JSON, there's no handy |
|
OK the filesystem level diff (from non-unified ➡️ unified) shows some likely issues, here's the abbreviated version. Full version. Mainly it looks like we for some reason gain docs, and we're not using the workstation presets, note |
|
The filesystem diff is a good idea!
We still have a lot of f29 consumers though (i.e. SB, FCOS, cosa). I'd like to keep releasing there until at least FCOS and cosa are bumped. (Though one way out would be to use the Koji tag Dusty is setting up so we can just build the latest there). |
Meaning we never update rpm-ostree again in f29? We are planning to continue to ship f29AH until f29 EOL (i.e. no F30 atomic host, and FCOS just in preview) so that might cause pain if we maintain a diff between f29 and latest.
yeah I was going to suggest once beta f30 lands for us to switch over. Would also be nice if we managed to get rid of anaconda first before we switch to f30 so we don't have to deal with "anaconda differences" between f29 and f30. One that I know of is that |
cgwalters
force-pushed
the
unified-only
branch
3 times, most recently
from
fc87031
to
ed1441f
Compare
|
Whee, now passing all tests. I'll look at a PR to fix the Workstation 29 presets. And I'll take a look at the filesystem-level diff for AH.
I am not aware of a way in which Anaconda intersects with this. It's not impossible but did you have something in mind? |
Fair. No reason not to bump fcos right now right? For |
I agree anaconda doesn't have implications for this suggested change. My comment was in response to @jlebon where he was talking about moving COSA/FCOS to f30. I made a similar comment over in the appropriate place now that he has opened it up over there. |
|
We should be able to merge this now right? |
|
Did we get to the bottom of the diff on SB? Some things that jump out from a quick scan: it looks like we're losing fontconfig cache, the workstation preset (which you mentioned already, is that fixed now?), and we're enabling sshd by default? |
|
The fontconfig stuff varies every build I think; looks like fontconfig gives each font a local UUID for presumably bad reasons. Anyways so I tried rebasing a sb30 build and actually it doesn't work. I think it relates to this: Which is probably fallout from us ignoring all of the crazy systemd unit stuff going on in |
We still accept the `--unified-core` option, it just does nothing. We're talking about making 2019.2 the last release to support RHEL7. That makes it also a good cutover point to just drop the non-unified-core codepath. Since coreos-assembler defaults to it, we know it works. I also tested Silverblue with it. Alternative to coreos#1739
|
Probably should revisit this again and see what needs to be resolved. |
|
@cgwalters: PR needs rebase. 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. |
cgwalters
added a commit
to cgwalters/rpm-ostree
that referenced
this pull request
May 17, 2020
Start adding some pain if `--unified-core` isn't provided to help flush out anyone relying on it. (And I think today pungi is not passing it, so e.g. Fedora IoT/Silverblue are impacted) Prep for merging coreos#1793
cgwalters
added a commit
to cgwalters/rpm-ostree
that referenced
this pull request
May 18, 2020
Start adding some pain if `--unified-core` isn't provided to help flush out anyone relying on it. (And I think today pungi is not passing it, so e.g. Fedora IoT/Silverblue are impacted) Prep for merging coreos#1793
cgwalters
added a commit
to cgwalters/rpm-ostree
that referenced
this pull request
May 18, 2020
Start adding some pain if `--unified-core` isn't provided to help flush out anyone relying on it. (And I think today pungi is not passing it, so e.g. Fedora IoT/Silverblue are impacted) Prep for merging coreos#1793
cgwalters
added a commit
to cgwalters/rpm-ostree
that referenced
this pull request
May 19, 2020
Start adding some pain if `--unified-core` isn't provided to help flush out anyone relying on it. (And I think today pungi is not passing it, so e.g. Fedora IoT/Silverblue are impacted) Prep for merging coreos#1793 Co-authored-by: Jonathan Lebon <jonathan@jlebon.com>
openshift-merge-robot
pushed a commit
that referenced
this pull request
May 20, 2020
Start adding some pain if `--unified-core` isn't provided to help flush out anyone relying on it. (And I think today pungi is not passing it, so e.g. Fedora IoT/Silverblue are impacted) Prep for merging #1793 Co-authored-by: Jonathan Lebon <jonathan@jlebon.com>
|
@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. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We still accept the
--unified-coreoption, it just doesnothing.
We're talking about making 2019.2 the last release to support
RHEL7. That makes it also a good cutover point to just drop
the non-unified-core codepath.
Since coreos-assembler defaults to it, we know it works.
I also tested Silverblue with it.
Alternative to #1739