> > - I know it makes no sense in a container, but fix it so that it properly > > installs by changing default config/postinst or whatever you see fit > > See below, I need an example/more details of what is actually expected. >
example: $ apt install zsys do that in a container and it is not allowed to fo RC!=0. The way you do it depends on your case (conditions in .service and such) > > - add watch file to your github > > Done in master > (https://github.com/ubuntu/zsys/commit/c390e46aa951c71b4154d769497a4a47e44aaae9). > However this triggers a lintian warning: W: zsys source: debian-watch- > file-in-native-package and I don't really like keeping lintian warnings. > > > - please resolve the lintian copyright complains > > Need feedback from you. What do you need? > > - extend autopkgtests to cover some real use-cases > > This is planned but not real for targetting eoan TBH. As you saw, we have a > very extensive testsuite (similary to ubuntu-report) and are really hard on > testing (running as part of building the package, but also in term of > upstream CI). > However, running on a real zfs-on-root system in autopkgtests is quite hard > to setup right now. This is why before zsys go "production ready", we really > need this (so that I can sleep at night ;)), knowing though that it needs a > lot of fundamental work to be setup on autopkgtests system. We already have > some autopkgtests to ensure we are compatible with our libzfs shipped by > ubuntu and that new zfs or grub doesn't regress us. But here, it means > installing a real entire system, with zfs on root (so debootstrapping or > copying current system, creating and accessing disks…), changing grub boot > menu entry for next reboot and cross-reboot tests (I worked with pitti in the > past to do this last item already for systemd autopkgtests, so it's not the > most worrying part compared to initial setup). This is logged as > https://github.com/orgs/ubuntu/projects/1#card-24794108. In a nutshell, I'm > afraid that's not a realistic target for eoan (and part of the reason we keep > it under the "experimental" flag). ok, but don't loose/punt the task after things got promoted :-) > > > - this seems to be at a very early stage, every here and there more features > are mentioned but not yet implemented. To review this it should sort of > feature complete at least to the extend that are planned for the comi,ng > release. Otherwise reviews cover what is there in 0.1 but e.g. 1.0 will > look much much different (If the feature is too far out at least add the > docs and specs to check if the design fits main inclusion) > > Indeed. We had a plan that you can see on > https://github.com/orgs/ubuntu/projects/1. However, we didn't get the time > resources (even less than half of what expected) we budgeted on at the start > of the cycle due to other customer work which got high priority. We thus > reduced to a MVP allowing people installing a zfs system on root, with > separated boot partition, enabling multiple (manual) snapshots for > rollbacking system AND/OR user data attached to it. This experimental option > will already help us a lot in term of exploring, testing and hardening zfs as > a viable root option before turning it to stable. > The most complex logic (grub + zsys boot) is now implemented. This > fundamental work is the most complex as it means datasets managements, > grouping them logically in different machines,- cloning system when booting > on snapshot, handling parallel installations, handling partial "system only" > revert. > The internal API for interacting with ZFS itself is already there and tested, > even if not used (destroy, snapshot and other tagging…). It means that future > improvement will be: > - implementing CLI options to expose/list what is already available on the > backend (installed machines, available snapshots, takes a snapshot and more). > However no "background work" should be needed and thus, this is just > "cosmetic" features if you prefer. > - implementing a GUI, which will use the exact same API than the CLI. > - doing some background automated snapshots, which is just going to be a > systemd unit triggering the same user command than manual snapshots. Tweaking > those will be done via systemd timer units. > - separate (which is already separated in code: internal/ vs cmd/) CLI and > backend, so that we have an on-demand zsys single daemon (avoiding having > multiple parallel commands starting in parallel for integrity, a single > daemon will know the state of the system and interact with it). This > client/server local communication will mean that we need some polkit > integration. This is the most invasive change in design between now and 1.0 > that we have and this means that we, as the Desktop team, will request later > on a security review again to ensure we did make it right security-wise. Yeah I think this is a special case, due to its timing constraint but also due to the desktop-team not only being the maintainer but also the upstream for this. So you are on the hook for it no matter how you turn it around. Due to that it might be ok to pass, but at least security review (which is queued) might have to be re-done once the extra bits are added to be sure. > I gave management the choice between keeping zsys to universe and call > for testing and pushing this to main (as we are going to support it, > even if experimental). The second option got the favor to get wider > testing. It's just that we are going to warn to not use that on > production as dataset layout changes (or even data loss?) may incur. Thanks for explaining the reasoning. [... snip more reasoning ...] This is too much of a special case, we might ack it for the special case, but to do so I'd: - ask you to resched security reviews for when the rest of the code is added (essentially gating the upload to Eoan+1 of those new features) - get to the MIR meeting in ~60 min and lets get a group ack there -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1839271 Title: [MIR] zsys To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/zsys/+bug/1839271/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
