[10:48] <Laney> sil2100: starting this review by rebasing your branch
[10:48] <Laney> conflicts /o\
[12:00] <Laney> alright, done I think, was a bit hairy at times
[12:00] <Laney> sil2100: I'm going to force push that to your branch - would you mind rearranging the commits, merging temporary ones and so on so they tell a logical story please? After lunch I will give a review on the code itself :-)
[12:03] <Laney> (hopefully I didn't break it 😬)
=== Eighth_Doctor is now known as Conan_Kudo
=== Conan_Kudo is now known as Eighth_Doctor
[13:28] <xnox> teward:  my question about restarting, is mostly about "after we fix network-online.target during firstboot; what do we do during the remainder of the machine runtime" since networking does come and go.
[13:29] <xnox> vorlon:  it was not trolling, but actual concert / upstream position statement. Just because one fixes the ordering during firstboot, it doesn't help with the lifecycle.
[13:33] <teward> xnox: I think then thats a larger issue that goes beyond SystemD.  Because then we have to define every possible case for what a 'network reload' is and that will get very complex quickly.  Most good utils I find needing that level of sensitivity already have their own tests in place, and anything requiring DNS is not going to be able to follow the usual tests (rtelink tracking etc) to ID if its up or not - at that point it becomes a
[13:33] <teward> software issue for those pieces of software moreso than a systemd issue in my opinion
[13:33] <teward> at that point its a can of worms and a rabbit hole so...
[13:35] <sil2100> Conflicts again?!
[13:36] <sil2100> Laney: ok, let me get to that in a moment once I'm done with this NEW review
[13:38] <sil2100> Laney: some time ago I merged trunk to avoid conflicts, but from that time there prorbably was some changes pushed - sorry about that
[13:39] <xnox> teward:  the systemd upstream stance is that a service should stay up; itself know what it needs; and retry/backoff.
[13:39] <xnox> teward:  for example, on ubuntu, in standard configuration dns resolution is available After=systemd-resolved.service And if dns name fails to resolve, it should just poll and retry.
[13:40] <xnox> teward:  i'm not advocating that we need or should support restarting services, that are not smart enough to retry things themselves.
[13:40] <teward> ack.
[13:41] <teward> thats a given in most services heh
[13:43] <xnox> teward:  is the unit service in question does mounts or exports?
[13:44] <xnox> teward:  cause i would have thought that anything that does network mounts (aka nfs client) should be part of the remote-fs.target which already should be after network.target
[13:44] <teward> xnox: ERR:NotTheInitialFilerOfQuestion
[13:44] <xnox> teward:  ack.
[13:45] <teward> xnox: i just weighed my opinions in here and was unsure of the scope of the discussion hence my showing up
[13:45] <teward> ;)
[13:45] <xnox> teward:  cause i wanted to say, surely we can convert all of those things into systemd generator of the .mount units which systemd seems to handle fine for nfs ;-)
[13:45] <xnox> ack
[13:46] <teward> xnox: no disagreement, but it goes back to "customized configs after install" which goes back to rbasak's opinion
[13:47] <teward> nothing I have uses at boot nfs mounts heh.  Except VMware which... is not Ubuntu xD
[14:06] <Laney> sil2100: no worries, the main branched moved quite rapidly in the last few weeks once we deployed
[15:47] <vorlon> xnox: this was all about the nfs server, not nfs mounts; the root bug in the thread was about /etc/exports using DNS names and not being guaranteed to be able to resolve those until after network-online.target, thus making an unreliable boo
[15:48] <vorlon> t
=== RzR is now known as rZr