From @mattdm :
Do we have anything I should emphasize for beta, coming up next week? What about in May? https://fedoraproject.org/wiki/Fedora_28_talking_points#Fedora_Atomic
Can everyone please add ideas here?
Asking @sanja to be responsible for seeing this one through to completion.
Metadata Update from @dustymabe: - Issue assigned to sanja
Metadata Update from @dustymabe: - Issue tagged with: F28
Metadata Update from @dustymabe: - Issue tagged with: meeting
So for Atomic Workstation, I would say that since gnome-software now support flatpak, you can install things without the CLI.
Maybe mention the first pieces of rpm-ostree automatic update policy have landed
Is there also something on "the-downlaod-system-that-used-to-be-called-jigdo" ?
One high level thing here is that while a lot of the Fedora processes think in terms of the "major" releases, in fact we're usually constantly releasing changes into $currentstable (e.g. 27), even if Fedora as a whole doesn't think of things that way or do much formal around them (aside from the FAH sub-releases which just roll up the general bodhi stream).
27
We don't have different versions of rpm-ostree across different releases since that would be a huge pain. So there's nothing new in 28 that isn't in 27. In fact, for the same reasons e.g. the kernel maintainers.
rpm-ostree
kernel
IMO a lot of the "between major" changes basically boil down to: systemd, GNOME and toolchains (gcc, node.js, java) etc.
Of those, only systemd is relevant for FAH.
We have historically done some "between majors" changes for FAH like switching to overlay. But there's no changes like that queued for FAH28.
On the automatic updates side, I think it's likely we enable it by default, whether that makes 29 or not I'm not sure.
One high level thing here is that while a lot of the Fedora processes think in terms of the "major" releases, in fact we're usually constantly releasing changes into $currentstable (e.g. 27)
Yes, that is a subtle point. I usually take the release as an opportunity to summarize big changes that have happened since last major release (as well as new onces), since people who haven't been following closely might not have noticed them all. It's also a good way to generate buzz multiple times.
WDYT?
+1 for last dusty comment. You were faster than me to answer, but I was about to say the same. We can also turn that as "offered by default" and explain this was backported on the latest stable.
Sure, I have no problem with that. However, I think there's a bigger picture issue here in that we need to fundamentally accelerate the Fedora 6 month cycle; i.e. not have the FAH releases be a sidecar. Let's take the example of Rust. They release every 6 weeks. And they get a lot done in that timeframe.
They actually have the converse problem; they release so quickly that there's plans to introduce "epochs" which are like Fedora major versions which involve a lot of "roll-up marketing" of everything that happened in a bunch of those 6 week releases.
Anyways this isn't the ticket for that discussion...
Also gnome-software should now support rpm-ostree, so you can update your host without the CLI.
gnome-software
Treating the Fedora releases like "epochs" in this sense for marketing Atomic Host makes perfect sense to me. I still need some things to say, though. :)
The Atomic Workstation stuff is certainly interesting, but I'd like that to be separated out clearly.
Also note that @x3mboy is trying to write the beta release announcement right now, so this is fairly urgent. :)
one important change in the atomic system containers is that now an atomic system container uses the SELinux policy from the host. Every file in the container gets the same label it would have if installed on the host (e.g. /usr/bin/foo in the container has the same SELinux label as /usr/bin/foo on the host).
Advantages:
1) We can run containerized system services without losing the possibility of having different SELinux contexts (e.g. the docker system container will run as system_u:system_r:container_runtime_t:s0) 2) We can finally fully deduplicate files on AH with the rest of the system as there is no mismatch in the xattrs.
Some ideas:
the kubernetes system containers are using kube 1.9 now; you could link to the kube release notes, as there is a lot there
https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.9.md#19-release-notes
I'm taking note of everything you are commenting. Thanks so much for your help
@x3mboy - can you update this ticket with the talking points we used for Beta? We'll use that as a starting point (draft) for the talking points for F28 final.
Metadata Update from @miabbott: - Issue untagged with: meeting
Based on the FedMag article, it looks like only Kube 1.9 was mentioned in the Beta talking points - https://fedoramagazine.org/announcing-fedora-28-beta/
Scanning this ticket, here's a shot at some talking points:
Users of Fedora Atomic Host 28 can now configure rpm-ostree to automatically check for updates to the host. This functionality is disabled by default; users will have to opt in. For more information, consult the upstream rpm-ostree pull request.
With the release of Fedora Atomic Host 28, every file in a system container gets the same label it would have if installed on the host (e.g. /usr/bin/foo in the container has the same SELinux label as /usr/bin/foo on the host). This allows users to run containerized system services without losing the possibility of having different SELinux contexts. Additionally, we can finally fully de-duplicate files on Fedora Atomic Host with the rest of the system, as there is no mismatch in the xattrs. For more information, consult the upstream atomic issue.
/usr/bin/foo
xattrs
With the release of Fedora Atomic Host 28, we now have a single ostree repo that serves up all the Fedora 28 content for Atomic Host and Fedora Atomic Workstation. This includes all the multi-arch content for aarch64 and ppc64le.
aarch64
ppc64le
Fedora Atomic Host continues to be available and supported on x86_64, aarch64, and ppcle64 architectures.
x86_64
ppcle64
The release of Fedora Atomic Host 28 introduces two new tools for building and managing containers on your host. The buildah tool allows you to build containers on your host without the need for using the docker daemon. Likewise, the podman tool allows you to pull, run, stop, start, and otherwise manage your containers on your host without the need for the docker daemon. For more information, check out the the upstream repo for buildah and podman.
buildah
docker
podman
Along with the release of Fedora Atomic Host 18, we are pleased to announce the availability of version 1.9 of Kubernetes via containers on the Fedora Container Registry. There is a ton of new features in this release of Kubernetes, for more information consult the Kubernetes 1.9 release notes.
@dustymabe @sanja @jlebon @giuseppep @x3mboy - Could you have look at these notes and see how they look?
I think we should be able to copy/paste them into https://fedoraproject.org/wiki/Fedora_28_talking_points if they look sane
@miabbott LGTM, we might want to remove highlighting of buildah since we may remove it from AH in the future (because podman build will be able to do it all). Or maybe we just change the wording a bit to highlight podman build itself a little more.
podman build
Sure, how about:
The release of Fedora Atomic Host 28 introduces a new tool for building and managing containers on your host. The podman tool allows you to build, pull, run, stop, start, and otherwise manage your containers on your host without the need for the docker daemon. For more information, check out the the upstream repo for podman.
Sure, how about: podman is now included by default in Fedora Atomic Host The release of Fedora Atomic Host 28 introduces a new tool for building and managing containers on your host. The podman tool allows you to build, pull, run, stop, start, and otherwise manage your containers on your host without the need for the docker daemon. For more information, check out the the upstream repo for podman.
podman is now included by default in Fedora Atomic Host
That looks great!
Thanks @dustymabe, one LGTM is good enough for me. :laughing:
If there are further edits, you can note them here or edit the wiki directly.
Automatic update checking is now supported Users of Fedora Atomic Host 28 can now configure rpm-ostree to automatically check for updates to the host. This functionality is disabled by default; users will have to opt in. For more information, consult the upstream rpm-ostree pull request.
Automatic update checking is now supported
Thanks for adding this! Maybe let's instead link to more user-friendly docs, e.g.:
For more information, check out the Project Atomic blog, as well as rpm-ostreed.conf(5) and rpm-ostreed-automatic.service(8).
rpm-ostreed.conf(5)
rpm-ostreed-automatic.service(8)
?
Automatic update checking is now supported Users of Fedora Atomic Host 28 can now configure rpm-ostree to automatically check for updates to the host. This functionality is disabled by default; users will have to opt in. For more information, consult the upstream rpm-ostree pull request. Thanks for adding this! Maybe let's instead link to more user-friendly docs, e.g.: For more information, check out the Project Atomic blog, as well as rpm-ostreed.conf(5) and rpm-ostreed-automatic.service(8). ?
Thanks for adding this! Maybe let's instead link to more user-friendly docs, e.g.: For more information, check out the Project Atomic blog, as well as rpm-ostreed.conf(5) and rpm-ostreed-automatic.service(8). ?
Excellent! Updated the talking points wiki with this
Metadata Update from @dustymabe: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
The Talking Points are perfect, thanks so much for working on this. The Release Announcement is made by the FPL, and I'm pretty sure that he take this one into account.
Login to comment on this ticket.