systemd-sysupdate support for slow rollout (aka A/B testing)
Hey everyone, does sysupdate currently support any way to slowly roll out updates where the server providing the files can be in control? This would be used to slowly make a new version available and have it at e.g. 1% adoption for a day to monitor regressions before increasing the coverage. I was unable to find any information about it in the documentation. Currently it seems like I would have to implement a different service which calls the sysupdate binary (or uses dbus once #28134 has landed) and then decides based on some other information. One idea I had would be that systemd-pull could send the machine-id based on which the server could then decide to provide the newer file (e.g. last two chars == "00" would roll it out to ~1/255). Though I am not sure if sd-pull is supposed to be "anonymous", i.e. do not provide this identifying information. Another drawback of this would be that stateless systems which reboot often get a new machine-id each boot, thus having an increased chance to get the newer version. Does anything like this already exist or is planned? Or should that be done by different applications on the client side? I also remember there being a discussion about plugging in different sd-pull like implementations/backends[1] to support delta updates, other transports, or TLS client authentication. This could at least be adapted to support my idea to send the machine-id as an HTTP header (e.g. X-MACHINE-ID). Greetings, Nils [1] https://lists.freedesktop.org/archives/systemd-devel/2023-February/048856.html
Re: [systemd-devel] setting cpulimit/iolimit on mysql thread not entire process
Hello. On Tue, Nov 28, 2023 at 08:35:29AM +0200, Mantas Mikulėnas wrote: > 1) the limits are per-cgroup and the entire service is a single cgroup; They could create own service unit for the DB with Delegate=cpu,io and create a subtree manually. > 2) the threads are created by mysqld, That^^ Picking random threads out of the service and enforcing control on them without considering their internal dependencies is asking for^W^W creating hard-to debug troubles. > 3) afaik, in cgroups v2 it isn't even allowed for threads of a single > process to straddle multiple cgroups anymore. It depends on enabled controllers, threaded subtrees for controllers have thread granularity (cpu does, io not). > I'm not a DBA but I've heard that one common way to handle this would be to > create a separate MySQL instance (probably on a separate machine, even) > that would replicate all the data, for the heavy users to query. That sounds like much more sensible approach. SCNR, Michal signature.asc Description: PGP signature
mDNS resolution with systemd
Hi, On one of my servers, I use avahi to realize mDNS resolution. With avahi I am able to choose on which ip version I want avahi to answer to mdns requests (ipv4 or ipv6). In my opinion, this is convenient on local networks with both stacks, espacially for tracking purposes on the network). I have understood that avahi has to be replaced by systemd-networkd and/or systemd-resolved and I have tried to implement the save behavior with it... Without success (may be I have not found the correct place to adjust it). Following are the capabilities I would like to find in systemd for mDNS resolution (espacially on a server) : - One can specify If he wants systemd to respond only in ipv4 or ipv6 (or both, by default ?) ; - In ipv4, one can specify the sub-network on which he wants systemd to respond to mdns requests (in my opinion, the full ipv4 adresse is to be elaborated by systemd-network) ; - in ipv6, one can specify the prefix on which he wants systemd to respond to mdns requests (in my opinion, the full ipv6 adresse is to be elaborated by systemd-network) ; Thank you in advance for reading me. Regards. Jean-Marie Delapierre
