[00:13] <aisrael> axw, cholcombe: bootstrapping from a centos7 host or using centos7 to host the controller?
[00:13] <axw> aisrael: the latter
[00:13] <axw> former should not matter
[00:14] <aisrael> axw, gotcha, I have nothing to add then. ;)
[02:31] <cholcombe> axw: both worked.  i used centos7 for the bootstrap machine and the deploy machine :)
[02:46] <axw> cholcombe: okey dokey. I doubt we'll ever officially support it though
[02:46] <cholcombe> axw: yeah i'm not holding my breath
[07:06] <stub> lazyPower:  Using the -broken hook for cleanup will fail if you do 'remove-machine --force-units', but I suspect that would break most cleanup mechanisms
[07:08] <stub> lazyPower: The remaining units in their departed hook need to cope with a failed unit disappearing without notice, which I think in your case is just some way to tell which unit is disappearing in the -deperted hook (eg. env variable)
[07:10] <stub> lazyPower: Which might be fixable in the short term if you file a new bug, unlike my bug which requires an entire new hook to solve as best I can tell.
[08:37] <erik_lonroth> Hello guys/gals
[10:53] <cnf> hmm, i'm still vague on how to kick juju to retry things
[10:54] <cnf> i have units that are blocked, but no real indication blocked by what?
[10:54] <cnf> how do i resolve this?
[13:36] <kklimonda> cnf: try going through the unit logs, looking for anything related
[13:36] <cnf> kklimonda: i know wht it was broken, i just don't know what the right way to make it retry is
[13:36] <cnf> atm i'm doing juju run-commands unit/0 pause and resome
[13:37] <cnf> resume*
[13:37] <cnf> can't use juju resolved on something that is blocked
[13:40] <kklimonda> I *think* charms just retry after some timeout, even in blocked state - every deployment I have something stuck blocked, waiting for relationships, and then it just sorts itself out
[13:41] <cnf> well, it's a long wait when you are trying to fix something
[13:41] <cnf> "did that fix work?"
[13:45] <kklimonda> cnf: try doing: "juju run --unit [unit] ./hooks/[hook name]
[13:46] <cnf> how do i get the hook name?
[13:48] <kklimonda> cnf: juju show-status-log [unit] should show you the last unit that has execute, perhaps you can just retry it
[13:52] <cnf> uhm
[13:52] <cnf> the type?
[13:53] <cnf> or parse it from the message?
[14:37] <kklimonda> cnf: yes, parse the message - e.g. "running leader-settings-changed hook" => leader-settings-changed
[15:01] <cnf> ok
[15:01] <cnf> that didn't work :P
=== admcleod is now known as not_adam
=== not_adam is now known as admcleod
=== frankban is now known as frankban|afk
[17:32] <cholcombe> anyone else had an issue with d2 large instances on ec2 not detecting all the drives?
[17:33] <cholcombe> i tried a scsi bus rescan but it's not helping
[19:40] <derekcat> Hey everyone.  Anyone ever seen this error on the LXD (2.0.9) charm?
[19:40] <derekcat> config-changed modprobe: ERROR: could not insert 'netlink_diag': Operation not permitted
[20:58] <derekcat> [Trying to do https://docs.openstack.org/developer/charm-guide/openstack-on-lxd.html but using the bundle-mitaka-novalxd.yaml]
[22:39] <cholcombe> derekcat: i haven't
[22:39] <cholcombe> have you tried setting superuser permissions on the lxc profile?
[22:59] <derekcat> cholcombe: Hey!  I'm not sure what you mean - Juju's ubuntu user has sudo privileges, is there something else that should be set?
[22:59] <derekcat> This is the LXD profile that the containers are using: https://github.com/openstack-charmers/openstack-on-lxd/blob/master/lxd-profile.yaml
[22:59] <cholcombe> derekcat: ok so you've alright got priv containers going
[22:59] <cholcombe> looks like it's erroring out on a modprobe?
[23:00] <cholcombe> i'm just stabbing in the dark here
[23:01] <cholcombe> derekcat: jamespage might have an answer for this when he comes back
[23:04] <derekcat> cholcombe: So it says, though I'm not sure what modprobe does - is that Juju trying to verify modifications?
[23:04] <derekcat> No worries - everything appears to be working with this deploy except for that error..  Just not sure what the consequences of ignoring it might be.
[23:04] <derekcat> Ahh ok.  Hopefully it's not a critical error.  Thankfully this is still in testing for us at the moment. >_<
[23:04] <cholcombe> derekcat: cool
[23:05] <derekcat> cholcombe: Thanks for the help! ^_^
[23:05] <cholcombe> derekcat: no modprobe is where you find and insert a module into the linux kernel.  i'm not exactly sure how lxd exposes modules to the container.  Maybe there's a cgroup for modules.  I'm not sure
[23:10] <derekcat> Ahh Gotcha.  >_< Not sure I'm ready to try diving into cgroup documentation again..  It was pretty opaque last time.