#282 Atomic Host images omit many common locales that all other flavors include
Closed: Fixed 2 years ago Opened 2 years ago by adamwill.

Apparently, it was decided that Fedora Atomic Host images should include only the locales 'officially supported' by RHEL 7 - see https://bugzilla.redhat.com/show_bug.cgi?id=1430182 , jlebon says it was decided to apply the same choice to Fedora as to RHEL.

This is entirely out of step with all other Fedora flavors, though, I believe. These include far, far more locales. The 'RHEL supported' list doesn't include such obvious and widely-used locales as en_CA and en_AU. I'm not sure it makes sense to just decide the RHEL 'supported locales' list is an appropriate basis for the list of locales to include in Fedora images.

[Transferred from https://bugzilla.redhat.com/show_bug.cgi?id=1459341 as requested there].


What is the size impact? Is it possible or will it be possible in the near future to add locales (perhaps as system containers)?

Metadata Update from @dustymabe:
- Issue tagged with: meeting

2 years ago

As a side note: some work in anaconda was done to make it so that the installer doesn't show options that aren't in the ostree. We need to get this merged in Fedora as well.

Current tree with locale subset (built locally)

/srv/walters/src/github/ostreedev/ostree-releng-scripts/print-commitsize repo fedora/26/x86_64/atomic-host{^,}
fedora/26/x86_64/atomic-host^ => 6e37b6ca5050933cd998256cf00f9108d9687ac4c67bb37516b92d2d4c6d7be3
Meta: 3421 Content: 22891
0 => 26175 (500 MB)
1 => 59 (79 MB)
2 => 31 (75 MB)
3 => 10 (35 MB)
4 => 5 (22 MB)
5 => 2 (10 MB)
6 => 3 (19 MB)
7 => 8 (59 MB)
9 => 4 (38 MB)
10 => 1 (10 MB)
11 => 1 (11 MB)
12 => 2 (25 MB)
18 => 1 (18 MB)
20 => 1 (20 MB)
21 => 1 (21 MB)
25 => 1 (25 MB)
26 => 1 (26 MB)
31 => 1 (31 MB)
34 => 1 (34 MB)
45 => 2 (91 MB)
95 => 1 (95 MB)
102 => 1 (102 MB)
Total: 1356 MB

With all locales:

fedora/26/x86_64/atomic-host => 60a7f03935e0beb51cc44d0d74413e40700f972472852185ef7ee7c3a5dec4a1
Meta: 3683 Content: 24281
0 => 27827 (551 MB)
1 => 59 (79 MB)
2 => 31 (75 MB)
3 => 10 (35 MB)
4 => 5 (22 MB)
5 => 2 (10 MB)
6 => 3 (19 MB)
7 => 8 (59 MB)
9 => 4 (38 MB)
10 => 1 (10 MB)
11 => 1 (11 MB)
12 => 2 (25 MB)
18 => 1 (18 MB)
20 => 1 (20 MB)
21 => 1 (21 MB)
25 => 1 (25 MB)
31 => 1 (31 MB)
34 => 1 (34 MB)
45 => 2 (91 MB)
95 => 1 (95 MB)
102 => 1 (102 MB)
112 => 1 (112 MB)
Total: 1493 MB

Size difference: 137 MB, or 10% larger.

As far as dynamic locale installation: difficult but still doable. I think for every treecompose we'd need to generate a new second ref like fedora/26/x86_64/locales/atomic-host. And we'd need a new client side command to install it, and logic to treat it like an overlay. We already have overlay logic for RPM packages, but this wouldn't be an RPM. (Or well we could make it into one but I'm not sure that fixes more problems than it would create)

(It's worth noting here that flatpak which uses ostree as well has logic and standards for separate Locale and Debug refs).

1) Why do locales need to be installed into the tree? Isn't this just configuration?

2) Maybe we just need an all-locales option.

3) If Flatpak has a solution that works, can we emulate/copy it?

So just ballparking here, but 137 MB on disk will probably translate to ~35 MB additional space of the qcow2 (based on the same compression ratios I found in https://bugzilla.redhat.com/show_bug.cgi?id=1186757). I think if we're comfortable with that (I am :)), I'd vote for just shipping all the locales.

@jlebon given that we're currently trying to shrink the base image, I'm not keen on adding 137MB of storage if we can find another option. Currently the CoreOS ISO is half the size of Fedora Atomic, and that's an issue which folks bring up with me at container conferences, a lot.

I'd be up for an "all-locales" branch. I'd prefer a locales system container, but I realize that's probably pie-in-the-sky right now.

I'm not worried about 10% bigger image, esp since we have cutting kube on the horizon. Smaller is nice, but how many ppl might we be cutting out / turning off w/ this? I guess some sense of that might shape the decision.

The reason this is really visible is that anaconda did not filter out locales that aren't in the to-be-installed tree: https://github.com/rhinstaller/anaconda/pull/871 . Once we have that fixed in Fedora (I am unsure of which Fedora branches it is / isn't on), the problem will be somewhat less obvious. Though there is still the question of how badly people feel about not being able to use pretty common locales like en_CA.

These changes should be hitting rawhide once the next anaconda build is out.

Metadata Update from @dustymabe:
- Issue untagged with: meeting
- Issue assigned to jlebon
- Issue tagged with: host

2 years ago

Verified the changes hit rawhide. They will hit f26 as soon as we get the anaconda and productimg tested.

ok all changes are in F26. closing this issue.

Metadata Update from @dustymabe:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

2 years ago

So, I'm not sure this should have been closed quite yet. The patches above only changed Anaconda so we do not show locales we don't actually ship. Though the question of whether we should ship all locales either in-tree or through some other mechanism is still open, right? Maybe let's open a separate issue for that?

Maybe let's open a separate issue for that?

+1 - please open a separate issue.

Login to comment on this ticket.

Metadata