Add 20181017 meeting log

[debian-ctte.git] / meetings / 20181017 / debian-ctte.2018-10-17-19.00.log.txt

19:00:24 <marga> #startmeeting
19:00:24 <MeetBot> Meeting started Wed Oct 17 19:00:24 2018 UTC.  The chair is marga. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:24 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:41 <marga> #topic roll call
19:00:57 <OdyX> I'm likely to drop in ½ hour; I can only chair for that part.
19:01:01 <OdyX> Didier Raboud
19:01:02 <fil> Philip Hands
19:01:08 <gwolf> Gunnar Wolf
19:01:09 * marga Margarita Manterola
19:01:10 <smcv> Simon McVittie
19:01:17 <ntyni> Niko Tyni
19:01:20 <bremner> David Bremner
19:02:11 <Mithrandir> Tollef Fog Heen
19:02:16 <Mithrandir> (distracted too)
19:02:56 <marga> #topic Review of previous meeting AIs
19:03:32 <marga> I think Simon did the summing up really nicely.
19:03:41 <smcv> https://lists.debian.org/debian-ctte/2018/10/msg00015.html
19:04:30 <OdyX> (crazy how fast months go; I haven't dared to open my TC folder yet :-(
19:05:00 <marga> Mithrandir, you were supposed to send the vote for the other issue, right?
19:05:31 <Mithrandir> yes, I still have that outstanding
19:05:43 <Mithrandir> will do ASAP
19:05:45 <marga> Is there anything in the way?
19:05:50 <Mithrandir> time on my side
19:06:11 <gwolf> Absolute time? Negative time? ;-)
19:06:16 <Mithrandir> free time.
19:06:16 <marga> Ok, would you rather someone else took over?
19:06:37 <Mithrandir> give me a week, if I fail to do something within then, I'm fine with somebody taking over.
19:06:41 <Mithrandir> sounds ok?
19:06:54 <fil> Mithrandir: BTW were you taking my (and possibly Ian's) ramblings into account re the vote? (I think there was some merit in there)
19:07:01 <Mithrandir> fil: yes.
19:07:09 <gwolf> Mithrandir: I'd add a bit to it - If in a week you cannot do this, please bring it up explicitly on the rest of us!
19:07:20 <Mithrandir> gwolf: sounds good
19:07:42 <gwolf> (so somebody can raise their hand - I guess we'd all prefer if Somebody Else™ did it)
19:08:21 <fil> well, I seem to have touched it last, so I could give it a go
19:08:38 <marga> #action Mithrandir should raise the vote in the upcoming week. If that doesn't happen, fil can take over
19:08:45 <OdyX> Cool
19:08:48 <marga> Sounds good?
19:08:53 <fil> fine
19:09:32 <Mithrandir> yup
19:11:31 <OdyX> #topic #904302 Whether vendor-specific patch series should be permitted in the archive
19:12:14 <Mithrandir> is there anything more we need to discuss on that?
19:12:16 <gwolf> not #topiced
19:12:42 <OdyX> (I just assumed marga lost connectivity, and can't chair myself)
19:13:05 <OdyX> Also, I'm totally useless on all these issues, I really haven't caught up :-(
19:13:09 <gwolf> Right... Never mind, then :-]
19:13:27 <gwolf> I... Think we should be ready to vote on this one as well
19:13:44 <Mithrandir> this is the one we just talked about that I'm going to write up the actual vote text for.
19:13:51 <gwolf> I mean, there were some more rounds of argument, but...
19:13:56 <gwolf> Right
19:14:12 <OdyX> So next topic?
19:14:12 <marga> Ok, we can skip the next topic I think?
19:14:13 <gwolf> (oh, yes, sorry - ape brain multitasking here)
19:14:38 <marga> #topic #904558 What should happen when maintscripts fail to restart a service
19:15:31 <marga> So, this one is still very much under discussion...
19:15:54 <Mithrandir> I think smcv's summary is a good writeup.
19:16:06 <marga> Agreed
19:16:17 <marga> But the question is how we move forward
19:17:05 <smcv> Ian and Wouter proposed an interface based on policy-rc.d where sysadmins can arrange for service restart failures to be ignored or not
19:17:09 <marga> My impression was that there was some rough agreement that in general we want to recommend maintainers not to fail their maintscripts unless they think it's worth the breakage
19:17:14 <gwolf> Right. The discussion in the last few weeks *did* illustrate very big expectative differences in very different use cases :-/
19:17:56 <marga> Right, they proposed doing some changes which might be interesting to have. But I don't think we can rul such solutions should be implemented...
19:18:41 <fil> The fact that most things used to quietly ignore restart failures under sysvinit seemed like a rather important point that was mentioned recently
19:18:54 <gwolf> marga: I tend to side with your interpretation and motivation, but I didn't feel there was a "rough agreement" towards that end
19:19:09 <Mithrandir> fil: did actually most things do that?  I haven't seen numbers one way or the other.
19:19:33 <smcv> I am wary of solutions involving policy-rc.d, because you have a problem, and you think "I know, I'll solve it with policy-rc.d", and now you have an unpackaged file in /usr/sbin that may or may not get overwritten by debootstrap, and two problems
19:19:51 <Mithrandir> smcv: yeah, I agree
19:19:59 <smcv> or at least that's been my experience in Debian derivatives with non-trivial policy-rc.d
19:20:08 <OdyX> Also, policy-rc.d is vastly unknownk
19:20:27 <marga> fil, yes, I was also surprised that that was the case.
19:20:34 <smcv> SteamOS is meant to have a policy-rc.d that suppresses restarts when we are upgrading during shutdown because $reasons
19:20:48 <smcv> it turns out that it does not, in practice, exist, because it gets overwritten by debootstrap
19:21:06 <fil> Mithrandir: well, that was Michael Biebl's assertion (which seemed plausible, but I've not checked)
19:21:32 * gwolf prefers not to even try to wrap brain around smcv's last idea. Sounds too perferse and obscure :-P
19:21:35 <smcv> re ignored restart failures: it partly depends how carefully the daemon was written
19:22:22 <smcv> there is a Right Way, that nobody implements, where you only double-fork after you have read all configuration, done everything that could fail (except the things that you can only do after double-forking), etc.
19:22:23 <gwolf> OdyX: I agree that this would require pushing policy-rc.d closer to the consciousness of developers -- And users.
19:23:02 <marga> There was a mention of 'the daemon was running before the upgrade and it's not running after the upgrade, so we know it's a problem', but I don't know most maintscripts actually know that much.  Most only know that it failed to restart not that it was running before... Am I wrong there?
19:23:36 <smcv> initscripts often implement restart as stop; start
19:23:41 <gwolf> marga: That would be easy to solve, even if it brought up a mass instant-buggy - `status` before `restart`
19:23:53 * bremner tries to catch up
19:24:08 <smcv> aka `systemctl try-restart`
19:24:18 <marga> gwolf, sure, I understand it's possible, I'm asking whether maintscripts actually check.
19:24:23 <smcv> I'm not sure whether there was a traditional sysvinit equivalent of try-restart
19:24:54 <gwolf> smcv: I would really not like tech-ctte to mandate systemd interfaces...
19:25:00 <marga> Agreed
19:25:05 <OdyX> on the other hand, the good argument for /usr/sbin/policy-rc.d is that executables should not be in /etc, but it really feels ugly (.d for a binary, managed through alternatives, really?)
19:25:09 <marga> So, the thing is, what do we want to mandate on?
19:25:25 <smcv> gwolf: no, of course not, I'm just saying there is prior art for "restart this, but only if it's running"
19:25:32 <gwolf> right
19:25:48 <smcv> I wonder whether deb-systemd-invoke uses it
19:25:56 <smcv> /usr/share/debhelper/autoscripts/postinst-init-restart doesn't
19:26:21 <marga> I expect most packages use dh_installinit, and will keep using it for the near future
19:26:26 <smcv> neither does /usr/share/debhelper/autoscripts/postinst-systemd-restart
19:27:41 <smcv> so, indeed, most of the time the maintscript that responds to a restart failure doesn't even know whether it's a regression
19:27:49 <marga> Right
19:28:17 <marga> So, we were asked to provide at least a recommendation.  Do you think we could recommend something?
19:28:56 <marga> I think we can also encourage people to develop better methods for both informing the user and handling errors, but we can't really rule about non-existant things...
19:29:11 <bremner> I thought the original question was about whether a sensible policy could exist
19:29:44 <bremner> so, no, would be an (unhelpful) answer
19:30:07 <gwolf> This has proven to be thorny enough. Again, the use cases are distant enough... That shoehorning a set of users into a given behavior can be seen as bad no matter what
19:30:44 <marga> We can recommend without shoehorning
19:31:02 <OdyX> that makes a policy-rd.d route somewhat "the least worst" idea: a middle ground.
19:31:59 <gwolf> Yes. But not in a way that makes it mandatory (or we will just have most daemons buggy because they don't check for status beforehand)
19:32:14 <marga> How would that look like as a ruling?
19:32:43 <smcv> I think if we are going for wouter's policy-rc.d route, then it would have to be something like
19:33:07 <bremner> we could block the tech-ctte bug on a policy-rc.d wishlist bug
19:33:18 <smcv> if invoke-rc.d exits with nonzero status when restarting a service, this should make the maintainer script fail
19:33:39 <bremner> oh, that's more sensible than my idea.
19:34:05 <smcv> (sysadmins are reminded that policy-rc.d can give invoke-rc.d error-handling behaviour that results in it recovering from failures and exiting 0)
19:34:36 <smcv> ... but there are a couple of reasons I find that unsatisfying
19:34:56 <bremner> ignorant question, is invoke-rc.d used by non-sysvinit things?
19:35:11 <smcv> no, good point
19:35:15 <gwolf> smcv: I would add to this that restarting a service SHOULD follow querying for its status
19:35:19 <marga> How would this look like in a real life use case?
19:35:27 <smcv> s/invoke-rc.d/invoke-rc.d or deb-systemd-invoke/
19:35:30 <gwolf> (and, of course, not restart non-running stuff)
19:35:51 <marga> Say, a service fails to start because the config is now outdated and fails to parse?
19:35:56 <smcv> (or an actual ruling would have to have some words about possible alternative implementations but we would all know that it meant invoke-rc.d and deb-systemd-invoke)
19:36:27 <smcv> for context, pure systemd services don't use invoke-rc.d, they use deb-systemd-invoke
19:36:40 <smcv> but both invoke-rc.d and deb-systemd-invoke call out to policy-rc.d
19:36:48 <smcv> I don't know whether deb-systemd-invoke implements the 106 thing
19:37:04 <smcv> it does not
19:37:21 <marga> I fear we are going too much into implementations details... Is that something we want to / should do?
19:37:50 <smcv> perhaps not, but now we know that wouter's plan doesn't work as stated
19:38:03 <OdyX> / can do? (re: $6.3.5)
19:38:35 <Mithrandir> bremner: invoke-rc.d and policy-rc.d is also randomly-ish used by things like ifup scripts and so on
19:38:53 <bremner> Mithrandir: that's documented as unsupported, more or less?
19:39:10 <gwolf> OdyX: Re 6.3.5, we can sketch it in text without describing the tooling?
19:39:24 <gwolf> That would free us from invoke-rc.d and deb-systemd-invoke
19:39:56 <bremner> I think the constitutional meta discussion happened before didn't it?
19:39:59 <smcv> so, what, we'd say "Someone™ should implement an interface for sysadmins to decide what happens on this class of failure?"
19:40:31 <marga> Yeah, exactly, I think we need to refrain from describing the exact implementation and instead focus on what are the results we want
19:40:36 <gwolf> bremner: yes, (IIRC I brought it up last meeting) but I think it's sensible to be reminded of
19:41:21 <smcv> marga: you wanted a description of what happens in real world use cases, do you still?
19:41:51 <marga> Not sure, I guess it depends on how we plan to move forward
19:42:05 <marga> I mostly want to move forward and not keep stalling
19:42:07 <smcv> so what wouter and ian were advocating in recent discussion was
19:42:20 <smcv> your daemon fails to restart because its config is outdated or whatever
19:42:56 <smcv> in a system with no special configuration, invoke-rc.d fails, the maintscript fails, the package fails to configure, dpkg fails, apt fails
19:44:02 <smcv> in a system that has been preconfigured by marga's sysadmin team, the restart fails, the failure is caught, magic happens, invoke-rc.d does not fail, everything continues as though it was all OK
19:44:38 <fil> that (global failure) seems like a poor default to me -- even more so if the scripts are not checking whether the daemon was able to run before we started
19:44:44 <smcv> (implementation detail: the magic that would happen, according to wouter's plan, is that you install a policy-rc.d that tells invoke-rc.d "on failure, just stop it")
19:44:52 <marga> How far away are we from making this possible? It wasn't clear to me from the discussion if this was actually something already implemented or something that needed more work.
19:46:02 <smcv> for invoke-rc.d, afaics it can happen already, *if* you drop in a suitable policy-rc.d
19:46:08 <OdyX> I haven't read the thread (booo), but as framed, it feels weird to use the dpkg -> apt pipeline to signal for $any service restart failure.
19:46:33 <bremner> it's about unconfigured packages?
19:46:37 <smcv> for systemd-only services, afaics it can't, because deb-systemd-invoke doesn't implement that particular little-known corner of the policy-rc.d API
19:46:40 <OdyX> (sorry if that's rehash)
19:47:30 <bremner> OdyX: we could state the default in terms of "package fails to configure"
19:47:43 <smcv> hmm, wait, I'm not actually even sure whether 106 does what wouter said it does
19:48:23 <marga> OdyX, I agree with you, but some people don't and they insist on using the output of maintscripts as a signal of failures
19:49:10 <marga> Alright, we are at 50 minutes past the hour and it doesn't seem we are getting anywhere... We should stop discussing the issue and instead decide how we want to reach consensus...
19:49:34 <OdyX> on the other hand, if SSH failed to restart and died, having apt in a weird state is the least of my concerns
19:49:48 <Mithrandir> I think we need to reach for ietf consensus, ie what are you willing to live with, more than what's a perfect solution.
19:50:14 <marga> Well, we are already living with "each maintainer decides whatever they want"
19:50:31 <fil> is there some way to make the default something like "carry blithely on unless the maintainer has somehow tagged their package as being too important to fail" ?  and then let the local admin override that (to be more or less fragile) it they feel the need
19:50:59 <gwolf> marga: Right. Some lines ago, there was mention (by whom? Don't remember - again, multitasking here :-P) of "depends on the nature of your service"...
19:51:14 <smcv> fil: for the maintainer part, dh_installinit --error-handler=function
19:51:15 <gwolf> So, yes, this could be _legitimately_ left as part of the maintainer's decision grounds
19:51:30 <OdyX> There's likely value in having two classes of services, yes.
19:51:37 <Mithrandir> gwolf: I think it's important that we give advice about what the default should be
19:51:49 <Mithrandir> since else we have the current situation where it's half and half (or thereabouts)
19:51:58 <smcv> fil: not implemented by dh_installsystemd but I think it's a reasonable feature request, unless we come to the conclusion that there is only one legitimate value for the error handler, in which case there's no point in implementing it
19:52:01 <bremner> Mithrandir: that feels strange if the default is not possible with current tooling
19:52:15 <bremner> *shrug*, maybe that's the least of our problems
19:52:19 <smcv> for the "sysadmin can override to be more or less fragile", no that's not currently possible
19:52:25 <gwolf> Mithrandir: the default should be, the new package works like a charm and never fails in any way :-]
19:52:51 <Mithrandir> gwolf: not what we're talking about though. :-)
19:52:56 <gwolf> yup, sadly
19:52:56 <smcv> I would prefer the signalling mechanism to not be policy-rc.d
19:53:21 <bremner> what cross-init alternatives are there?
19:53:23 <gwolf> I also think policy-rc.d is too obscure to most people
19:53:43 <smcv> this is not the init's problem
19:54:02 <smcv> both invoke-rc.d and systemctl will give you an exit status and let you do what you want with it
19:54:47 <smcv> this is entirely an issue for dh_install{init,systemd} (and their open-coded equivalents, for people who like artisanal handcrafted maintainer scripts)
19:55:05 <OdyX> We're left 5 minutes. Could anyone wrap these arguments up in a mail?
19:55:28 <smcv> unless we want to mandate that invoke-rc.d and dh-systemd-invoke gain new error handling behaviour
19:56:02 <gwolf> OdyX: Right. I hope to be more useful next meeting (that means, no, I'm not volunteering to wrap up), as I am too attention-dilluted right now :-(
19:56:24 <marga> I'll volunteer for trying to move the discussion forward, but I feel like we didn't make much progress today :-/
19:56:35 <marga> I feel like we are running in circles
19:56:37 <smcv> I volunteer to reply to wouter re the policy-rc.d thing, since I've done the research now
19:56:49 <marga> Ok, thanks :)
19:57:06 <smcv> if we want a summary of this meeting's discussion I'd prefer that to be not me
19:57:11 <marga> #action smcv to clarify what can be done through policy-rc.d to the mailing list
19:57:25 <marga> #action marga to try to summarize the discussion and move the discussion forward
19:57:29 <marga> Does that seem fair?
19:57:32 <smcv> great
19:57:41 <OdyX> Cool
19:57:41 <marga> #topic Recruiting efforts
19:58:00 <marga> We are in mid-October and I think we need to start recruiting again
19:58:24 <marga> It's just OdyX that leaves us after December, right?
19:58:31 <gwolf> and Mithrandir IIRC
19:58:36 <marga> Ah, yes...
19:58:44 <fil> fair enough -- I'll fire up the randomizer :-)
19:58:49 <marga> So sad, time goes so quickly
19:59:00 <OdyX> Yep. Two members go.
19:59:03 <marga> Yes, fil, please fire the randomizer.
19:59:03 <Mithrandir> time flies when we're having fun.
19:59:12 <Mithrandir> I need to nominate some folks, I think I have a small list somewhere.
19:59:26 <marga> Alright, I'll action you two
19:59:46 <marga> #action fil will do a few rounds of the random emailer to try to get nominations
19:59:48 <gwolf> Just FTR - We *can* operate with a shortage in membership. We are supposed to have between 4 and 8 members. So, yes, we should act on it. But it's not like we are time-stressed to get new bl00d.
19:59:55 <marga> #action Mithrandir will nominate people
20:00:15 <marga> And maybe I should email d-d-a?
20:00:43 <gwolf> Yes, to seek self-nominations
20:00:44 <marga> gwolf, true, but we don't want to be understaffed. A plurality of opinions is good.
20:00:49 <marga> Alright, then.
20:00:52 <OdyX> gwolf: true. But the TC loses two every year, it goes quick
20:01:06 <marga> #action marga to email d-d-a to encourage self-nominations.
20:01:09 <gwolf> Right to both of you - We are not _constitutionally_ stressed yet.
20:01:37 <fil> 10 mails sent
20:01:43 <marga> Awesome :)
20:01:48 <gwolf> Efficient!
20:01:51 <marga> #topic Any other business
20:01:59 * fil has a little script
20:02:02 <gwolf> I have to go. I'm late to have lunch with my kids
20:02:20 <gwolf> So... I'll leave the AOB (including the new bug) to you.
20:02:30 <marga> I wanted to ask whether we should meet more often now that we have open issues and apparently more controversial than initially expected?
20:03:11 <OdyX> As long as the calendar is kept up-to-date, I'll try.
20:03:22 <OdyX> But not more than every 3 weeks
20:03:23 <marga> Would it make sense to schedule an "extraordinary meeting" in 2 weeks instead of next month?
20:03:32 <OdyX> or that, yes.
20:03:47 <fil> or just chat in IRC a bit more?
20:04:06 <bremner> it's probably important to have fixed meeting times.
20:04:12 <marga> I feel like having the actual meeting deadline / time helps.
20:04:18 <bremner> from a transparency point of view, alaso
20:04:20 <bremner> also
20:04:25 <marga> yup
20:05:14 <fil> fair enough
20:05:23 <marga> Anyway, we are over time. I'll send this to the mailing list as well.
20:05:32 <bremner> I can make a meeting in two weeks.
20:05:49 <marga> Let's end here and leave people free to go. Thanks everyone for attending!
20:05:56 <marga> #endmeeting