[03:21:25] <cdanis>	 _joe_: in modules/systemd/manifests/service.pp -- why is there no dependency between the Service[$label] that ensure_resource() creates and the systemd::unit created?  Shouldn't the systemd::unit have before => [Service[$label]] ?
[06:38:10] <_joe_>	 cdanis: uhm lemme see the code, but if the two are sequential within the same class/define, the sequence is guaranteed
[06:38:29] <_joe_>	 unless you add some explicit dependency elsewhere
[06:40:32] <_joe_>	 cdanis: hah it's done /inside/ systemd::unit
[06:40:48] <_joe_>	 as sometimes we don't want to also declare the service ourselves
[06:41:28] <_joe_>	 also allows to control the relationship between the unit file and the service (with the "restart" parameter)
[06:42:30] <_joe_>	 also depending on ensure present/absent, we make the daemon-reload depend on the service, or vice-versa
[10:46:16] <jynus>	 for some reason the puppet issue got cut "wikireplica_analytics: Change"
[10:46:20] <jynus>	 not sure if on purpose
[12:49:49] <cdanis>	 _joe_: oh, I did not know that re: ordering (but in this case the ordering is backwards anyway)
[12:50:09] <_joe_>	 cdanis: yeah read the rest of the comment
[12:50:22] <_joe_>	 basically we make the service depend on the daemon-reload exec
[12:50:27] <_joe_>	 within systemd::unit
[12:50:42] <_joe_>	 so ordering is correctly ensured even if you just use systemd::unit
[12:51:10] <cdanis>	 and the creation of the unit file has a notify on the exec
[12:51:13] <cdanis>	 ok
[12:55:37] <_joe_>	 yes
[12:55:53] <_joe_>	 in general I prefer to keep the dependencies at the actual resource levels
[12:55:59] <_joe_>	 rather than on their containers
[13:19:36] <cdanis>	 in other news, no one else has used OnUnitInactiveSec much and that makes me worried
[13:21:38] <apergos>	 now reading the "Services Endgame" doc and already finding it entertaining:
[13:21:50] <apergos>	 "RESTRouter was formerly known as RESTBase, before it was refactored to move storage to a separate service (with an unfortunate name)."
[13:23:37] <cdanis>	 apergos: can you link me?
[13:23:46] <apergos>	 https://docs.google.com/document/d/1vfgMJBNIcbXDv4blyE6ni62kErPFUfpsXzuytvnG79o/edit?ts=5dc3d6e0#
[13:24:08] <apergos>	 draft, don't know how open it is for comments yet
[13:24:14] <cdanis>	 ty
[13:24:18] <apergos>	 but figured I should see where folks are going with it at least
[14:45:59] <andrewbogott>	 jbond42: I've rebuild labtestpuppetmaster2001 and now all my clients are complaining about "unable to get local issuer certificate for /CN=puppet" — I know I'm not using quite the same puppet manifests that you're using in prod, but do you happen to know what step I'm missing?
[14:46:17] <andrewbogott>	 (I've seen this error a dozen times in the past but I dont' remember how I fixed it)
[14:52:06] <jbond42>	 andrewbogott: what odo you mean by "all my clients"?  im still not that sure what labtestpuppetmaster2001 does
[14:52:26] <andrewbogott>	 it's a puppetmaster for VMs in the codfw1 (aka -dev) region
[14:53:02] <andrewbogott>	 it's aliased to 'puppet' for those VMs
[14:53:23] <andrewbogott>	 although if I point to it by fqdn I get the same error (but with fqdn rather than 'puppet')
[14:54:22] <jbond42>	 is there a host i can log into on codfw to test
[14:54:42] <andrewbogott>	 master or client?
[14:54:46] <jbond42>	 client
[14:55:23] <andrewbogott>	 connect to cloudvirt2001-dev.codfw.wmnet
[14:55:31] <andrewbogott>	 then "sudo virsh console --devname serial1 ad120c42-a7e7-409a-8333-66734dd9990a"
[14:55:38] <andrewbogott>	 that will give you a console on an affected VM
[14:55:46] <andrewbogott>	 effected?
[14:55:50] <andrewbogott>	 one of those :)
[14:56:14] <jbond42>	 ack cheers
[14:56:27] <andrewbogott>	 (ever since that VM spent a semester in Belgium it talks with a fake french accent)
[14:56:55] <andrewbogott>	 thank you for looking!
[14:58:39] <jbond42>	 andrewbogott: is labtestpuppetmaster2001 the only puppet master for the dev network?
[14:58:48] <andrewbogott>	 yes
[14:58:56] <andrewbogott>	 at least it's meant to be
[14:59:15] <jbond42>	 im gussing you backed up the CA matirial and restopred it after the rebuild?
[14:59:38] <andrewbogott>	 It only has like three clients, all of them disposable.  So I didn't bother to retain old certs, figured I'd just wipe or rebuild the clients after
[14:59:53] <jbond42>	 have you dont that
[15:00:09] <jbond42>	 *done
[15:00:10] <andrewbogott>	 yes, but feel free to repeat :)
[15:00:23] <andrewbogott>	 by 'wipe' I mean rm -rf /var/lib/puppet/ssl
[15:00:34] <andrewbogott>	 maybe there's another dir I should be clearing
[15:00:44] <jbond42>	 yes thats should be enough and it looks like this one has the same ca
[15:12:29] <andrewbogott>	 jbond42: do you see what I was seeing or did it start working as soon as you logged in?
[15:15:11] <jbond42>	 no sorry im still looking at it
[15:15:15] <jbond42>	 i do see what you see
[15:15:17] <andrewbogott>	 ok :)
[15:29:51] <jbond42>	 andrewbogott: the certificate /var/lib/puppet/ssl/certs/puppet.pem is genrated before /var/lib/puppet/server/ssl/certs/ca.pem
[15:30:00] <jbond42>	 the content of the former is pulled in via Profile::Openstack::Base::Puppetmaster::Frontend/Puppetmaster::Web_frontend
[15:30:18] <jbond42>	 and lookslike it is still using the old certificate
[15:30:40] <jbond42>	 youll need to generate a new certificate for puppet and add it to the repo
[15:31:09] <jbond42>	 I can help on monday but bit busy today (and not sure i want to break production ssl at the end of a friday)
[15:31:40] <andrewbogott>	 jbond42: ok!  I'll fuss with it and (probably) bug you more on Monday
[15:31:41] <andrewbogott>	 thank you
[15:33:14] <jbond42>	 ack and no probs