[16:28] <smoser> harlowja_at_home, pitti (ubuntu systemd maintainer) is complaining about your Before=NetworkManager.service
[16:29] <pitti> well, not "complaining", but it should be a no-op
[16:29] <pitti> all network-y things like NM, networkd, ifupdown etc. already run After=network-pre.target -- that's the raison d'être for that target
[16:30] <pitti> so I was wondering if there is some race condition somewhere and that just hides a real bug
[16:37] <harlowja_at_home> nrezinor1, ^
[16:37] <harlowja_at_home> x58, ^
[16:37] <harlowja_at_home> apparently thats not how it works in RHEL
[16:37] <harlowja_at_home> lol
[16:37] <harlowja_at_home> those 2 folks are the experts here
[16:37] <harlowja_at_home> i'm just a poor small enginner man
[16:37] <harlowja_at_home> lol
[16:39] <harlowja_at_home> bbiab
[17:31] <harlowja> ok backs
[17:45] <nrezinor1> i see my name was pinged lol , wat now
[18:03] <harlowja> nrezinorn something about the network manager stuff
[18:04] <harlowja> nrezinorn  https://irclogs.ubuntu.com/2016/09/26/%23cloud-init.html#t16:28
[18:13] <nrezinorn> yeah i dont remember most of that haha
[18:13] <nrezinorn> that was so last week
[18:13] <harlowja> :-P
[18:13] <nrezinorn> the tl;dr is "MOAR TESTING"
[18:14] <nrezinorn> i dont have time to test things today lol   stupid "real work"
[18:58] <x58> smoser: RHEL requires Before=NetworkManager.service because otherwise NetworkManager starts at the same time as cloud-init-local, and takes over managing /etc/resolv.conf for instance.
[18:58] <x58> smoser: I filed bugs for these issues, that describe what is going on.
[18:59] <x58> RHEL doesn't have NetworkManger.service require network-pre or something that allows us to order cloud-init-local first.
[18:59] <x58> pitti: Yeah, it would be nice if network-pre.target would actually be defined that way on RHEL/CentOS too... but alas it is not.
[19:00] <x58> pitti: Also, networking.service is network.service on RHEL, so there are just difference between Ubuntu/RHEL.
[19:00] <x58> Either split out the systemd per system, or template it someway, but those are things that need to be accounted for.
[19:14] <harlowja> agreed
[19:14] <harlowja> pitti if we need to split out thats fine
[19:14] <harlowja> if there is a RHEL bug somewhere, that'd be nice to know also
[19:18] <smoser> x58, so pitt was saying (i think) that upstream NetworkManager's service file does have network-pre.target
[19:18] <harlowja> in RHEL?
[19:18] <harlowja> or ubuntu
[19:18] <harlowja> ?
[19:18] <smoser> upstream
[19:18] <harlowja> upstream!!!
[19:18] <harlowja> :-P
[19:18] <harlowja> which stream
[19:20] <smoser> https://github.com/NetworkManager/NetworkManager/blob/master/data/NetworkManager.service.in
[19:20] <smoser> that one
[19:23] <harlowja> x58 ^ any idea, maybe RH just doesn't have that one yet
[19:53] <pitti> x58: right, forget the particular .service names; the point is that <stuff that fiddles with network interfaces> is After=network-pre.target, and <stuff that sets up firewall or config> runs before that
[19:54] <pitti> x58: and neither network-pre.target nor NetworkManager.service are an Ubuntu invention -- these both come from their upstream projects
[19:54] <pitti> x58, harlowja: so, it's plausible that RHEL's NetworkManager.service does not (yet) have After=network-pre.target, and then that workaround would actually DTRT; I just wanted to confirm that this is actually the case
[19:55] <pitti> because, if NM.service already does have After=network-pre.target, then that change is a no-op, and something is still not understood
[19:56] <apollo13> are you guessing? cause I can look into centos7 if you want
[19:59] <pitti> I am just guessing, yes (Debian/Ubuntu guy here)
[19:59] <apollo13> https://dpaste.de/UKgv/raw that is the current file on centos/rhel 7
[19:59] <pitti> ah, so that indeed still misses it
[20:00] <apollo13> anything else I should look at?
[20:00] <pitti> so that explains it (even though fixing the actual NM.service would be preferrable, so this ought to be a downstream patch)
[20:01] <pitti> but nevermind, I mostly just wanted to know if that was maybe just a misunderstanding
[20:01] <apollo13> great
[20:02] <apollo13> anyways, your After came in with nm 1.2, centos has 1.0.6
[20:02] <apollo13> https://bugzilla.gnome.org/show_bug.cgi?id=761001 was the original issue
[20:03] <apollo13> although according to that bugreport it would be on 1-0 too? seems that redhat didn't cherrypick that (yet)
[22:32] <x58> Yes it should probably be fixed by RHEL/CentOS, but that will probably take till version 193943834342112 ...
[22:33] <x58> (being overly generous with that version number, knowing how slow RHEL moves)