[05:21] <cpaelzer> good morning
[05:31]  * bryceh waves
[06:04] <utkarsh2102> cpaelzer: o/
[06:13] <cpaelzer> hi utkarsh2102
[06:14] <cpaelzer> This isn't selective unfairness, b_ryceh I already spoke with in other channels :-)
[06:15] <utkarsh2102> hehe
[07:28] <mirespace> good morning
[07:30] <cpaelzer> hi mirespace
[07:31] <mirespace> hi :)
[07:32] <utkarsh2102> mirespace: o/
[07:33] <cpaelzer> mirespace: I heard in the news another pack of sahara sand is sent our way - since last time we had like 4 days delay and 1/4 let me ask if this one passed you again and how it was compared to last time?
[07:34] <mirespace> we had the second on last Thursday and it ended on Saturday
[07:34] <mirespace> It was less orange
[07:35] <mirespace> we had muddy rains, but less dense
[07:35] <cpaelzer> hmm, ok then the delay stays the same it started here with slightly odd colored low clouds
[07:36] <mirespace> :) Yes, the feeling when walking through the street was better than the first
[07:36] <mirespace> And now is raining a lot
[07:37] <mirespace> in the news here : "did you believe the spring had arriven? No! take off your coat from the wardrobe.. winter is coming !"
[07:39] <cpaelzer> yeah we seem to have the same predictions over here
[07:43] <mirespace> :)
[10:48] <yurtesen> In Ubuntu, rsyslogd runs as syslog:syslog by default. This cause problems with packages imported from Debian which expect syslog can set file ownerships correctly as it runs as root in Debian.
[10:49] <yurtesen> can rsyslogd user be changed?
[11:59] <athos> good morning :)
[12:02] <ahasenack> morning
[12:14] <ahasenack> kanashiro_: resource-agents-extra is in main, according to rmadison
[12:14] <ahasenack> both in impish and jammy
[12:14] <ahasenack>  resource-agents-extra | 1:4.7.0-1ubuntu5 | impish | amd64, arm64, armhf, ppc64el, riscv64, s390x
[12:14] <ahasenack>  resource-agents-extra | 1:4.7.0-1ubuntu6 | jammy  | amd64, arm64, armhf, ppc64el, riscv64, s390x
[12:27] <kanashiro_> ahasenack, ah okay, src:resource-agents and its binaries were in main before we start the current work to split agents
[12:27] <kanashiro_> I think fence-agents-extra is not in main
[12:28] <ahasenack> if they remained in main, then either they are seeded, or something is still pulling them in
[12:28] <ahasenack> bin:resource-agents-extra I mean
[12:29] <kanashiro_> yes, fence agents has what I was expecting:
[12:29] <kanashiro_>  fence-agents-extra | 4.7.1-1ubuntu7 | impish/universe | amd64, arm64, armhf, ppc64el, riscv64, s390x
[12:29] <kanashiro_>  fence-agents-extra | 4.7.1-1ubuntu8 | jammy/universe  | amd64, arm64, armhf, ppc64el, riscv64, s390x
[12:29] <kanashiro_> we should demote bin:resource-agents-extra
[12:30] <ahasenack> can you check what is holding it in main?
[12:31] <kanashiro_> ahasenack, I think nothing, src:resource-agents and bin:resource-agents were in main, then we split the agents into resource-agent-base and resource-agents-extra, and now everything is in main
[12:32] <kanashiro_> cpaelzer, what should I do to demote only bin:resource-agents-extra?
[12:38] <ahasenack> pacemaker-resource-agents is in main, and suggests resource-agents-extra, but depends on resource-agents-base
[12:38] <ahasenack> so that's not it
[12:39] <ahasenack> oh, resource-agents depends on resource-agents-extra
[12:39] <ahasenack> and resource-agents is in main
[12:39] <ahasenack> kanashiro_: ^
[12:39] <ahasenack> $ apt-cache show resource-agents|grep Depends
[12:39] <ahasenack> Depends: resource-agents-base (>= 1:4.7.0-1ubuntu6), resource-agents-extra (>= 1:4.7.0-1ubuntu6)
[12:40] <kanashiro_> ahasenack, hum, yes, resource-agents depends on -base and -extra indeed
[12:41] <kanashiro_> but it still the issue I mentioned, everything provided by src:resource-agents is in main
[12:42] <kanashiro_> we need to demote bin:resource-agents and bin:resource-agents-extra then
[12:44] <kanashiro_> fence-agents is correct:
[12:44] <kanashiro_>  fence-agents        | 4.7.1-1ubuntu8 | jammy          | source
[12:44] <kanashiro_>  fence-agents        | 4.7.1-1ubuntu8 | jammy/universe | all
[12:44] <kanashiro_>  fence-agents-base   | 4.7.1-1ubuntu8 | jammy          | all
[12:44] <kanashiro_>  fence-agents-common | 4.7.1-1ubuntu8 | jammy          | amd64, arm64, armhf, ppc64el, riscv64, s390x
[12:44] <kanashiro_>  fence-agents-extra  | 4.7.1-1ubuntu8 | jammy/universe | amd64, arm64, armhf, ppc64el, riscv64, s390x
[12:45] <cpaelzer> hi kanashiro_ only started to read this now ...
[12:46] <ahasenack> resource-agents reverse tree: https://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.jammy/rdepends/resource-agents/resource-agents
[12:46] <ahasenack> pacemaker-cli-utils (in main) depends on resource-agents
[12:47] <cpaelzer> also resource-agents itself (transitional) is in main still it seems and depends on it as well
[12:47] <cpaelzer> yep
[12:47] <cpaelzer> andreas already found it
[12:48] <cpaelzer> maybe that dep can/should be changed to resource-agents-base?
[12:49] <kanashiro_> meh, yes, I think I forgot to update pacemaker-cli-utils runtime deps
[12:49] <kanashiro_> the other pacemaker binaries are ok
[12:49] <kanashiro_> cpaelzer, yes, I'll do that
[12:51] <ahasenack> are we sure it does not need or expect the bits in resource-agents-extra?
[12:58] <ahasenack> cpaelzer: why not do a proper merge with debian for libtpms?
[12:59] <ahasenack> they are at 0.9.3 too
[12:59] <ahasenack> oh
[12:59] <ahasenack> my eyes deceived me, they are at 0.9.2-3
[13:00] <cpaelzer> ahasenack: that plus we have no properly split delta yet AND they have changes we are not needing atm (post FF)
[13:37] <cpaelzer> ahasenack: I replied in the libtpms MR
[13:37] <cpaelzer> ahasenack: but to make this quick let me ask here - I could make it ppc64 only, but I used it int he way it was in debian already (proven to work) instead of modifying it
[13:38] <cpaelzer> ahasenack: do you think it worth and/or important to make it ppc64-only?
[13:38] <ahasenack> I'm ok with that, just replied (but didn't submit yet)
[13:38] <ahasenack> just doing a quick install check
[13:40] <ahasenack> cpaelzer: done
[13:40] <cpaelzer> thank you , having a look
[13:42] <cpaelzer> Thanks, I'll be waiting what foundations says before an upload (and also beta-freeze)
[14:35] <kanashiro> do I need the release team blessing to upload pacemaker fixing the resource-agents dependency?
[14:37] <kanashiro> AFAICS it is not seeded
[14:48] <ahasenack> I'm unsure, it's a change in behavior for "apt-get install resource-agents"
[14:49] <kanashiro> "apt-get install resource-agents" will pull in the same set of packages than before, the difference is that not all of them will not be in main
[14:50] <kanashiro> s/will not/will/
[15:59] <bryceh> lvoytek, for the SRU reviews on mysql, I've been keeping my eye out for them to show up at https://code.launchpad.net/~canonical-server/+activereviews.
[16:00] <lvoytek> That's fair, I think they disappeared because the canonical-server slot was consumed, I'll re-add them
[16:01] <bryceh> do I recall correctly that it's the two for lp: #1964969?
[16:02] <lvoytek> yeah in combo with lp: #1899248
[16:02] <bryceh> right
[16:58] <sbeattie> cpaelzer: hey, what needs to happen for the nftables seed change merge to happen?
[17:05] <ahasenack> sbeattie: is there an mp up?
[17:19] <ahasenack> kanashiro: so, to recap, what is the plan again? bin:resource-agents-base in main, bin:resource-agents-extra in universe?
[17:20] <ahasenack> and what about bin:resource-agents (the meta package), that will have to be in universe too, no? Because it pulls in -base and -extra
[17:43] <ahasenack> rbasak: is "network-online-ordering" the correct tag? I get only one bug with it: https://bugs.launchpad.net/ubuntu/+source/rsync/+bugs?field.tag=network-online-ordering
[17:43] <ahasenack> I thought we had more
[17:43] <ahasenack> (hence the desire for a tag)
[17:43] <ahasenack> maybe they were closed
[17:43]  * ahasenack does a broader search
[17:43] <ahasenack> still just that one
[17:51] <kanashiro> ahasenack, yes, bin:resource-agents should be in universe, and ideally removed in the future
[17:52] <ahasenack> kanashiro: and some time ago, before you started working on the HA stack, it was a real package with a lot of agents in it, right?
[17:52] <ahasenack> you split it
[17:52] <ahasenack> is that the tl;dr history?
[17:52] <kanashiro> exactly
[18:18] <rbasak> ahasenack: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=network-online-ordering - you have to remove the rsync package filter
[18:31] <cpaelzer> sbeattie: you'd need a seed change and/or something in main that depends on nftables
[18:31] <cpaelzer> that will pull it into component mismatches
[18:31] <cpaelzer> and then it can be promoted
[18:32] <cpaelzer> sbeattie: do you intend to replace iptables (a lot of potential effort and churn late in the cycle) or only to support nftables along side it (for now) ?
[18:33] <cpaelzer> sbeattie: also - do you want it to be auto-installed?
[18:33] <ahasenack> ah, duh
[18:34] <cpaelzer> sbeattie: oh I see it was explained int he bug
[18:34] <cpaelzer> * iptables will be switching to nftables backend, but
[18:34] <cpaelzer> iptables availability and usage will probably continue for
[18:34] <cpaelzer> forseeable future.
[18:34] <cpaelzer> ok then
[18:35] <cpaelzer> sbeattie: something like https://paste.ubuntu.com/p/VtcgvsDh8Z/ on https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/platform
[18:36] <cpaelzer> that will also install it by default in everything using the standard seed. If you do not want it installed by default, the change would be in a different place 
[18:37] <ahasenack> cpaelzer: iptables is already using the nft backend, fwiw
[18:37] <cpaelzer> sbeattie: I'm no more around :-/ but I hope this helps, and if in doubt e.g. ahasenack / bryceh can also answer most questions you might have
[18:37] <ahasenack>  /etc/alternatives/iptables -> /usr/sbin/iptables-nft
[18:37] <cpaelzer> ahasenack: if you read the initial statement in the MIR bug you'll see it
[18:38] <cpaelzer> this is like "start supporting nftables, but do not replace iptables yet"
[18:38] <cpaelzer> so given how far in the cycle we are this is no funcitonal change, but declaring nftables supported
[18:38] <ahasenack> yeah, it's like ifconfig vs ip
[18:38] <cpaelzer> and then in coming cycles more and more changes can happen to swicth over
[18:38] <ahasenack> ip is nftables in this comparison
[18:38] <cpaelzer> which also needed to both be around for a while
[18:39] <cpaelzer> if/once sbeattie is back try to help him ahasenack / bryceh
[18:39] <ahasenack> yep
[18:39] <cpaelzer> and if help worked feel free to nudge him for glusterfs :-)
[18:39] <cpaelzer> (most subtle comment ever)
[18:48] <ahasenack> hah
[18:49] <bryceh> guessing sbeattie's lunching (I just finished myself)
[18:50] <sarnold> mmm, lunch
[18:50]  * ahasenack had a snack
[19:01] <sbeattie> cpaelzer: sorry was in meetings plus lunch, was trying to figure out what needed to happen wrt https://code.launchpad.net/~alexmurray/ubuntu-seeds/+git/ubuntu-seeds/+merge/417621 
[19:41] <ahasenack> sbeattie: I can take a look
[19:50] <ahasenack> server team, do you recall a service where we changed the systemd unit file from Type=simple to Type=forking so we could detect config file errors at startup?
[19:50] <ahasenack> IIRC we did it somewhat recently for a package
[19:50] <ahasenack> well, this year, not like this month
[19:50] <ahasenack> athos: did you work on that perhaps? Do you remember?
[19:51] <bryceh> 'forking' not ringing a bell for me
[19:53] <sarnold> as in, deliberately introduce a mistake into a systemd unit file so you could try to find it as a mistake later?
[19:54] <ahasenack> it was a service where "systemctl start <service>" would not tell you if it started or not
[19:54] <ahasenack> and that seems to be the common case for Type=simple and Type=exec
[19:55] <ahasenack> imagine scripts starting stuff, they most of the time rely on "systemctl start <foo>" telling them if <foo> started or not
[19:55] <ahasenack> Type=notify works well,
[19:56] <ahasenack> ssh being an example
[19:56] <ahasenack> like here: https://pastebin.ubuntu.com/p/2pwsJwpcPM/
[19:57] <ahasenack> ah, I think it was bind9
[19:57] <sdeziel> ahasenack: yeah https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1899902
[19:58] <ahasenack>     - d/bind9.named.service: use systemd Type=forking to signal daemon init.
[19:58] <ahasenack>       This fixes a regression of #900788 where services whose startup depend
[19:58] <ahasenack>       on name resolutions may fail due to bind9 not being ready (LP #1899902).
[19:58] <ahasenack> so it wasn't about a failure
[19:58] <ahasenack> just timing
[19:58] <ahasenack> and with forking, systemd had to wait for named to be really running
[19:59] <sarnold> ahhhhhhh!
[19:59] <sdeziel> and upstream wants to go to Type=notify (https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1899902) so that should be even better
[19:59] <sdeziel> https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5514 <= proper link
[19:59] <ahasenack> and as a result, they are implementing notify: https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5514 ^
[20:00] <sarnold> nice
[20:01]  * ahasenack subscribes to that PR
[20:03] <athos> well, I guess I came late to the party, ahasenack 
[20:03] <athos> :)
[20:03] <ahasenack> :)
[20:03] <ahasenack> I just didn't find the part where I realized this would help with detecting config file errors
[20:04] <athos> you even found the upstream follow-ups though!
[20:05] <ahasenack> sdeziel did first :P
[20:07] <sdeziel> ahasenack: for config check, nginx uses ExecStartPre=
[20:07] <ahasenack> does it behave the same wrt Type=exec|simple|notify?
[20:08] <ahasenack> rsync (my case) doesn't have a "-t" option to check the config
[20:08] <ahasenack> and in this particular case, the config syntax fine, it's the ip it's told to bind to that doesn't exist
[20:10] <ahasenack> yeah, ExecStartPre won't help in this case
[20:10] <sdeziel> right and I don't think Type=notify would either since rsync wants to fail if the configured address is missing
[20:11] <ahasenack> oh, it does fail
[20:11] <ahasenack> the issue is sytemd not detecting it at start time, I'm thinking scripts
[20:11] <ahasenack> systemctl status knows it failed
[20:11] <sdeziel> isn't it restarting it?
[20:11] <ahasenack> so type=notify would work
[20:12] <ahasenack> no, I don't think it is, but that could be another workaround for one particular scenario, boot ordering, when eventually the selected ip becomes available
[20:12] <ahasenack> in any case, it's a specific situation, I don't see a way to make it generic other than was said in the bug (btw, #1774788)
[20:20] <sdeziel> ahasenack: agreed on the "site-specific" nature of the problem. That said, to make things recover on their one, `Restart=on-failure` should be added to the systemd unit
[20:21] <ahasenack> can you add this suggestion there?
[20:21] <kanashiro> ahasenack, could you take a final look at the resource-agents MP? I'd like to upload it today
[20:21] <sdeziel> ahasenack: sure
[20:21] <ahasenack> kanashiro: I thought you uploaded it already
[20:21]  * ahasenack checks his notifications
[20:21] <kanashiro> I uploaded pacemaker :)
[20:21] <ahasenack> ah
[20:22] <ahasenack> see, pings are valuable
[20:24] <ahasenack> kanashiro: which package holds the deprecated agents, -extra?
[20:24] <ahasenack> yes
[20:24] <kanashiro> yep
[20:24] <ahasenack> +1
[20:25] <kanashiro> thank you
[20:27] <sdeziel> ahasenack: I also updated the upstream bug with an alternative solution (`RestartForceExitStatus=10`)
[20:27] <ahasenack> do you know if rsync uses 10 for something else?
[20:28] <ahasenack> 10 seems to be a generic "Error in socket I/O"
[20:28] <ahasenack> so network in general?
[20:28] <ahasenack> good tip in any case
[20:29] <ahasenack> someone can decide to apply that locally
[20:33] <sdeziel> man systemd.service: "Setting this to on-failure is the recommended choice for long-running services"