Bugzilla

It probably isn't a massive amount of work (a few days), but I also know how a couple of days can roll into a couple of weeks if we encounter strange issues on the way.

The multiuser engine in generic-worker is currently designed to create users, configure auto-login on reboot, and then reboot the computer to get an interactive user desktop, which is then controlled by a windows service / mac launch daemon. On Linux this may look a little different, since there isn't a defacto window manager (e.g. some tasks may not require a graphical context, some may want to use GNOME, others KDE, etc...) so implementing the existing stubs for Linux for the multiuser engine would mean either wiring it to a particular desktop manager, or faking these methods to pretend to be providing a graphical context, etc.

Since I'm not too clear at the moment on the specific requirements of the Linux jobs that need to run under separate user accounts, it isn't clear to me at the moment if we can get away entirely without a graphical context for the tasks, or if one is needed, and if we need to be able to flexibly choose one, or whether we can pick an arbitrary Desktop Environment (e.g. xfce/kde/gnome/cinnamon/...) and wire the tasks to run under it.

So depending on the answers to these questions, the work is probably between a few days' and a few weeks' work.

It probably isn't a massive amount of work (a few days), but I also know how a couple of days can roll into a couple of weeks if we encounter strange issues on the way.

The multiuser engine in generic-worker is currently designed to create users, configure auto-login on reboot, and then reboot the computer to get an interactive user desktop, which is then controlled by a windows service / mac launch daemon. On Linux this may look a little different, since there isn't a defacto desktop environment (e.g. some tasks may not require a graphical context, some may want to use GNOME, others KDE, etc...) so implementing the existing stubs for Linux for the multiuser engine would mean either wiring it to a particular desktop environment, or faking these methods to pretend to be providing a graphical context, etc.

Since I'm not too clear at the moment on the specific requirements of the Linux jobs that need to run under separate user accounts, it isn't clear to me at the moment if we can get away entirely without a graphical context for the tasks, or if one is needed, and if we need to be able to flexibly choose one, or whether we can pick an arbitrary Desktop Environment (e.g. xfce/kde/gnome/cinnamon/...) and wire the tasks to run under it.

So depending on the answers to these questions, the work is probably between a few days' and a few weeks' work.

It probably isn't a massive amount of work (a few days), but I also know how a couple of days can roll into a couple of weeks if we encounter strange issues on the way.

The multiuser engine in generic-worker is currently designed to create users, configure auto-login on reboot, and then reboot the computer to get an interactive user desktop, which is then controlled by a windows service / mac launch daemon. On Linux this may look a little different, since there isn't a defacto desktop environment (e.g. some tasks may not require a graphical context, some may want to use GNOME, others KDE, etc...) so implementing the existing stubs for Linux for the multiuser engine would mean either wiring it to a particular desktop environment, or faking these methods to pretend to be providing a graphical context, etc.

Since I'm not too clear at the moment on the specific requirements of the Linux jobs that need to run under separate user accounts, it isn't clear to me at the moment if we can get away entirely without a graphical context for the tasks, or if one is needed, and if we need to be able to flexibly choose one, or whether we can pick an arbitrary Desktop Environment (e.g. xfce/kde/gnome/cinnamon/...) and wire the tasks to run under it.

So depending on the answers to these questions, the work is probably between a few days' and a few weeks' work.

Note: in addition to the development and test time, there is also the additional liaison work to do with releng in order to have the hosts set up appropriately with required toolchains, build images, create worker types, help troubleshoot/debug any issues during rollout, etc. This can sometimes take more cycles than might be at first anticipated.

It probably isn't a massive amount of work (a few days), but I also know how a couple of days can roll into a couple of weeks if we encounter strange issues on the way.

The multiuser engine in generic-worker is currently designed to create users, configure auto-login on reboot, and then reboot the computer to get an interactive user desktop, which is then controlled by a windows service / mac launch daemon. On Linux this may look a little different, since there isn't a defacto desktop environment (e.g. some tasks may not require a graphical context, some may want to use GNOME, others KDE, etc...) so implementing the existing stubs for Linux for the multiuser engine would mean either wiring it to a particular desktop environment, or faking these methods to pretend to be providing a graphical context, etc, or adapting multiuser engine to be more general purpose so that linux can behave a little differently to windows/mac and allow the task to launch a window manager / desktop environment etc.

Since I'm not too clear at the moment on the specific requirements of the Linux jobs that need to run under separate user accounts, it isn't clear to me at the moment if we can get away entirely without a graphical context for the tasks, or if one is needed, and if we need to be able to flexibly choose one, or whether we can pick an arbitrary Desktop Environment (e.g. xfce/kde/gnome/cinnamon/...) and wire the tasks to run under it.

So depending on the answers to these questions, the work is probably between a few days' and a few weeks' work.

Note: in addition to the development and test time, there is also the additional liaison work to do with releng in order to have the hosts set up appropriately with required toolchains, build images, create worker types, help troubleshoot/debug any issues during rollout, etc. This can sometimes take more cycles than might be at first anticipated (i.e. swallow up a couple more weeks).