In Fedora 27 we released https://dl.fedoraproject.org/pub/fedora/linux/releases/27/WorkstationOstree/... Now that https://pagure.io/atomic-wg/issue/373 is fixed, the first update is available, i.e. you can `rpm-ostree upgrade`.
``` # rpm-ostree status State: idle Deployments: fedora-workstation:fedora/27/x86_64/workstation Version: 27.4 (2017-11-27 18:48:44) Commit: 2ee80f9aeb4c7fb4abe08c6e54fb0fd494e6ece00044ee3c8d78672cf44b64b7 GPGSignature: Valid signature by 860E19B0AFA800A1751881A6F55E7430F5282EE4
● fedora-workstation:fedora/27/x86_64/workstation Version: 27.1.6 (2017-11-05 07:09:26) Commit: 508b92bec034a075873091c57eae549acec3814d2381da103448f980814296fa GPGSignature: Valid signature by 860E19B0AFA800A1751881A6F55E7430F5282EE4 ```
Having an updated ostree commit stream in sync with the bodhi batches should help with synchronization issues.
There's a bit more information about the project at https://pagure.io/workstation-ostree-config
I and several other people use it as a "daily driver"; as the page says I think the project is useful for interested technical users, but there's a whole lot more to do; I just noticed the rpm-ostree plugin for gnome-software isn't enabled, going to fix that. I'd also really like to plumb through automatic updates by default.
A big picture question is how much we stay in sync with Workstation as it exists today; for example I find it confusing to have applications both via rpm and flatpak, and I think it'd make sense to thin things down more. At least drop gnome-boxes by default, and potentially libvirt too.
In this path we'd really be expecting most users to do package layering for things like that; personally I use `vagrant-libvirt` a lot for example. But OTOH there's already PRs like: https://pagure.io/workstation-ostree-config/pull-request/47 which add things.
On 11/28/2017 02:31 AM, Colin Walters wrote:
I and several other people use it as a "daily driver"; as the page says I think the project is useful for interested technical users, but there's a whole lot more to do; I just noticed the rpm-ostree plugin for gnome-software isn't enabled, going to fix that. I'd also really like to plumb through automatic updates by default.
Can you hold on with enabling gnome-software rpm-ostree plugin for F27, please? I just saw that you filed a bug upstream about rpm-ostree issues and commented on another; I'd like to fix at least some of these before enabling the backend on F27 (it's enabled in rawhide already, so people should be able to test easily). Especially the polkit prompts issue, I'd like to fix that first before turning it on.
Hey Colin,
----- Original Message -----
In Fedora 27 we released https://dl.fedoraproject.org/pub/fedora/linux/releases/27/WorkstationOstree/... Now that https://pagure.io/atomic-wg/issue/373 is fixed, the first update is available, i.e. you can `rpm-ostree upgrade`.
<snip>
I and several other people use it as a "daily driver"; as the page says I think the project is useful for interested technical users, but there's a whole lot more to do; I just noticed the rpm-ostree plugin for gnome-software isn't enabled, going to fix that. I'd also really like to plumb through automatic updates by default.
I had a chat with Owen shortly after the Fedora 27 release, and I'm guessing the status hasn't changed for folks like myself that need to be able to make changes to the lower OS layers and have them persist across reboots, correct?
I need to be able to, amongst other things: - be able to switch kernels independently of the OS installation - be able to install external kernel modules for particular kernel revisions and have them persist across reboots - be able to modify daemons, be it startup scripts, udev/hwdb rules, or binaries and have them persist across reboots
And unfortunately, most of that work cannot be done in VMs, due to the lack of hardware passthrough for a lot of the devices I work with, along with the side effects of having an OS that tries to handle them (that's Bluetooth, USB, I2C, HDMI/DisplayPort, at least).
Do we have any tracking bugs to collect requirements for that sort of usage, or is it outside the scope of Atomic Workstation?
Cheers
On Tue, Nov 28, 2017, at 09:37 AM, Bastien Nocera wrote:
I had a chat with Owen shortly after the Fedora 27 release, and I'm guessing the status hasn't changed for folks like myself that need to be able to make changes to the lower OS layers and have them persist across reboots, correct?
I'd like to refer things like this to docs; there's https://github.com/projectatomic/atomic-host-docs/pull/84 which unfortunately is stalled a bit, see https://github.com/projectatomic/atomic-host-docs/issues/95
Will try to pick that back up.
I need to be able to, amongst other things:
- be able to switch kernels independently of the OS installation
This one is https://github.com/projectatomic/rpm-ostree/issues/946
- be able to install external kernel modules for particular kernel revisions and have them persist across reboots
- be able to modify daemons, be it startup scripts, udev/hwdb rules, or binaries and have them persist across reboots
We actually do support this today with `ostree admin unlock --hotfix`. I tend to discourage people from using it because changes will be silently discarded if you upgrade (or make any other changes via rpm-ostree).
That said we totally could support a model where we capture changes from `sudo make install` and the like in a layer and have it re-apply on top of everything else. A lot like combining `rpm-ostree install /path/to/local.rpm` with `rpm-ostree ex livefs`. Would that cover what you wanted?
Can you flesh this out slightly more and we can write up an upstream issue? For example are you using `sudo make install` or are you building local RPMs or something else? Is jhbuild involved, etc.
Do we have any tracking bugs to collect requirements for that sort of usage, or is it outside the scope of Atomic Workstation?
It's completely in scope; generally rpm-ostree issues upstream are the best place to track this. The big picture vision is that we support all types of development/testing scenarios, the same as one would with a traditional package manager. Because in production, one often needs the ability to e.g. install a patched iptables RPM to add some debug printfs.
But all host system mutation runs through rpm-ostree which means it has the opportunity to make all changes transactional, and avoids the hysteresis of traditional package management - we make it easy to reset back to the "gold master" state which is always there.
On Mon, 2017-11-27 at 20:31 -0500, Colin Walters wrote:
In Fedora 27 we released https://dl.fedoraproject.org/pub/fedora/linux/releases/27/WorkstationOstree/... Now that https://pagure.io/atomic-wg/issue/373 is fixed, the first update is available, i.e. you can `rpm-ostree upgrade`.
Is there some kind of policy / plan about when and how often updates will be shipped? Should/will Atomic Workstation follow the 'two-week Atomic' process? Thanks!
On Tue, Nov 28, 2017 at 11:00:03AM -0800, Adam Williamson wrote:
https://dl.fedoraproject.org/pub/fedora/linux/releases/27/WorkstationOstree/... Now that https://pagure.io/atomic-wg/issue/373 is fixed, the first update is available, i.e. you can `rpm-ostree upgrade`.
Is there some kind of policy / plan about when and how often updates will be shipped? Should/will Atomic Workstation follow the 'two-week Atomic' process? Thanks!
If we're going to use the Atomic brand for it, please, please, please keep as many things as similar as possible.
On Tue, Nov 28, 2017, at 03:29 PM, Matthew Miller wrote:
On Tue, Nov 28, 2017 at 11:00:03AM -0800, Adam Williamson wrote:
https://dl.fedoraproject.org/pub/fedora/linux/releases/27/WorkstationOstree/... Now that https://pagure.io/atomic-wg/issue/373 is fixed, the first update is available, i.e. you can `rpm-ostree upgrade`.
Is there some kind of policy / plan about when and how often updates will be shipped? Should/will Atomic Workstation follow the 'two-week Atomic' process? Thanks!
If we're going to use the Atomic brand for it, please, please, please keep as many things as similar as possible.
I don't think we can decouple the ostree image updates from the rpm-md repo updates; doing so creates too many problems with package layering[1], and while a lot of Atomic Host server use cases can avoid layering, I think it's a lot harder to avoid for "pet" desktop machines that comprise a lot of the use case that people mean when they say "I use Fedora". (Of course for desktops the "computer lab" or "corporate standard laptop build" use case is probably more where one wants custom composes probably pre-configured; that's a whole story starting with https://github.com/projectatomic/rpm-ostree/pull/96#issuecomment-69592571 leading to https://github.com/projectatomic/rpm-ostree/issues/442 and https://github.com/projectatomic/rpm-ostree/pull/1039 etc.)
Anyways now that Bodhi has batches, I think it's really simplest to just match that, and I saw some discussion to that effect on #atomic, so I think it's being implemented.
On Tue, Nov 28, 2017, at 03:29 PM, Matthew Miller wrote:
If we're going to use the Atomic brand for it, please, please, please keep as many things as similar as possible.
Also, for Atomic Host we have a whole other layer of "images" like qcow2, uploads to public cloud providers like AWS, etc. None of that applies at all to workstation - it's just ostree + rpm-md, though I think we should respin the ISO at least once a month or so.
On 27/11/17 05:31 PM, Colin Walters wrote:`
Having an updated ostree commit stream in sync with the bodhi batches should help with synchronization issues.
There's a bit more information about the project at https://pagure.io/workstation-ostree-config
I and several other people use it as a "daily driver"; as the page says I think the project is useful for interested technical users, but there's a whole lot more to do; I just noticed the rpm-ostree plugin for gnome-software isn't enabled, going to fix that. I'd also really like to plumb through automatic updates by default.
A big picture question is how much we stay in sync with Workstation as it exists today; for example I find it confusing to have applications both via rpm and flatpak, and I think it'd make sense to thin things down more. At least drop gnome-boxes by default, and potentially libvirt too.
Will it be useful for labs variants like Design Suite which is based on Workstation?
On Wed, Nov 29, 2017 at 11:23:20PM -0800, Luya Tshimbalanga wrote:
A big picture question is how much we stay in sync with Workstation as it exists today; for example I find it confusing to have applications both via rpm and flatpak, and I think it'd make sense to thin things down more. At least drop gnome-boxes by default, and potentially libvirt too.
Will it be useful for labs variants like Design Suite which is based on Workstation?
I'd *really* like to see these be primarily add-ons available through the Software center rather than completely different install media — although we could also produce ISOs for use at events or whatever where a particular live image makes sense.
----- Original Message -----
On Tue, Nov 28, 2017, at 09:37 AM, Bastien Nocera wrote:
I had a chat with Owen shortly after the Fedora 27 release, and I'm guessing the status hasn't changed for folks like myself that need to be able to make changes to the lower OS layers and have them persist across reboots, correct?
I'd like to refer things like this to docs; there's https://github.com/projectatomic/atomic-host-docs/pull/84 which unfortunately is stalled a bit, see https://github.com/projectatomic/atomic-host-docs/issues/95
Will try to pick that back up.
Subbed.
I need to be able to, amongst other things:
- be able to switch kernels independently of the OS installation
This one is https://github.com/projectatomic/rpm-ostree/issues/946
Subbed as well.
- be able to install external kernel modules for particular kernel
revisions and have them persist across reboots
- be able to modify daemons, be it startup scripts, udev/hwdb rules, or
binaries and have them persist across reboots
We actually do support this today with `ostree admin unlock --hotfix`. I tend to discourage people from using it because changes will be silently discarded if you upgrade (or make any other changes via rpm-ostree).
Does it come back if you rollback, or is it dropped to the floor?
That said we totally could support a model where we capture changes from `sudo make install` and the like in a layer and have it re-apply on top of everything else. A lot like combining `rpm-ostree install /path/to/local.rpm` with `rpm-ostree ex livefs`. Would that cover what you wanted?
That would be useful.
Can you flesh this out slightly more and we can write up an upstream issue? For example are you using `sudo make install` or are you building local RPMs or something else? Is jhbuild involved, etc.
Usually, it's either: - install locally built or scratch RPM(s), of kernels, or system daemons. This is also useful for testing changes in user-sessions outside interactive user's grasp, like gdm and its session, or things that are hard to use without breaking the development env, like gnome-session or a Wayland gnome-shell - data files such as as udev rules/hwdb quirks, modprobe configuration changes to allow the installation of out-of-tree modules. This is an example of testing an out-of-tree driver: https://github.com/hadess/retrode/blob/master/README.md Mistakes will require a reboot, obviously - Sometimes, it would be "make install" of custom built software
I think that a single overlay for hacks and tests would be fine. Something like: - unlock the overlay - throw stuff in the overlay - reboot, it uses the overlay by default, test - reboot and pass a command-line option to reset the overlay
You would probably also want a configuration option that makes it impossible to use that overlay.
Do we have any tracking bugs to collect requirements for that sort of usage, or is it outside the scope of Atomic Workstation?
It's completely in scope; generally rpm-ostree issues upstream are the best place to track this. The big picture vision is that we support all types of development/testing scenarios, the same as one would with a traditional package manager. Because in production, one often needs the ability to e.g. install a patched iptables RPM to add some debug printfs.
But all host system mutation runs through rpm-ostree which means it has the opportunity to make all changes transactional, and avoids the hysteresis of traditional package management - we make it easy to reset back to the "gold master" state which is always there.
And that'd very useful indeed, to allow starting from a blank slate.
Cheers
desktop@lists.fedoraproject.org
-
Adam Williamson -
Bastien Nocera -
Colin Walters -
Kalev Lember -
Luya Tshimbalanga -
Matthew Miller