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