=== hbaum_ is now known as hbaum
[06:17] <sur_> anrah:
[06:17] <sur_> are you there
[06:18] <sur_> sur:
[06:18] <sur_> sur_:
=== frankban|afk is now known as frankban
[08:34] <anrah> now i am
[08:44] <kjackal> Good morning Juju world!
[09:04] <Zic> hi here, if I want to remove on of my kubernetes-worker in a CDK bundle, do I simply need to remove that machine from Juju and charms will do the proper cleanup expected?
[11:26] <brym> morning all
[12:16] <magicaltrout> lazyPower: lmk when you're in your seat
[12:45] <Zic> -> to answer myself, yeah, the kubernetes-worker charms manage remove-unit well, I did a test on my test cluster
[12:45] <Zic> it was cleanly remove from Kubernetes before removing it from Juju
=== gaughen_ is now known as gaughen
=== mup_ is now known as mup
=== mup_ is now known as mup
=== mup_ is now known as mup
=== mup_ is now known as mup
=== mup_ is now known as mup
=== mup_ is now known as mup
=== mup_ is now known as mup
[16:37] <joedborg> hello all.  does anyone know if there's a juju command to monitor which set_states are being called in real time?
=== mup_ is now known as mup
=== mup_ is now known as mup
[16:59] <kwmonroe> joedborg: this isn't what you asked for, but in case it's helpful, i use this to monitor states on a given unit:  juju run --unit foo/0 'charms.reactive get_states'
[17:00] <kwmonroe> that's not real-time, but it's useful to know what states are set to debug why a handler is (or isn't) firing.
=== mup_ is now known as mup
=== mup_ is now known as mup
=== mup_ is now known as mup
=== mup_ is now known as mup
[17:14] <joedborg> @kwmonroe thanks
[17:14] <joedborg> @kwmonroe although everything seems to come back as None value, is this normal?
[17:18] <kwmonroe> joedborg: yeah, i don't think state keys have 'values' per se.  cory_fu might have more enlightening things to say about the normalcy of "state: null", but fwiw, here's an example of the states set on a hadoop slave:  http://paste.ubuntu.com/24054153/
[17:18] <kwmonroe> ^^ and that's normal
[17:19] <cory_fu> Right, the only states that would have values are relation states.  That helper should really just be returning the keys
=== frankban is now known as frankban|afk
[18:17] <cory_fu> kwmonroe, petevg: Travis passing: https://github.com/juju-solutions/layer-cwr/pull/94
[18:17] <kwmonroe> crap, i guess i have to merge stuff now
[18:20] <kwmonroe> merged cory_fu.. don't worry about releasing cwr-52 to stable, i'll cut a new one that picks this up.
[18:22] <kwmonroe> hahah cory_fu, you just conflicted kjackal (https://github.com/juju-solutions/layer-cwr/pull/93).  payback, eh?
[18:23] <cory_fu> :)
[18:23] <joedborg> @corey_fu @kwmonroe: ah, so these all are one that have been fired?
[18:24] <joedborg> @cory_fu ^^
[18:26] <kwmonroe> joedborg: 'charms.reactive get_states' will show you all the states that have been set.  that doesn't necessarily mean any handler has fired, only that it could if it's written to react to those states.
[18:27] <joedborg> @kwmonroe ah okay, i'm trying to see which ones have been fired to debug an issue
[18:27] <admcleod_> joedborg: i find this useful: jgs() { juju run --unit $1 "charms.reactive --format=yaml get_states"; }
[18:28] <stormmore> o/ juju world
[18:51] <redir> \o stormmore
[19:03] <stormmore> are we having fun today?
[19:04] <kwmonroe> joedborg: i don't think there's a history of handlers that have fired outside of "juju debug-log -i unit-foo-0 --replay" and fancy grepping...
[19:05] <kwmonroe> still, if you see a state has been set, it's pretty safe to assume any handler reacting to that state has fired.
[19:07] <joedborg> @kwmonroe thanks
[19:08] <kwmonroe> np joedborg - if you need any help debugging, just holler... i'm happy to dig through debug-log output with you.  well, maybe not happy, but i'll do it :)
[19:28] <joedborg> kwmonroe: thanks man, I'll probably take you up on that offer :)
[19:31] <kwmonroe> cory_fu: did we have a rationale for making hadoop-client single-series?  https://jujucharms.com/hadoop-client/.  i think we didn't want to mess with the trusty version (perhaps back when the java interface was added?) but i need to rebuild it and am curious if we should just make it multi.
[19:34] <cory_fu> kwmonroe: I really don't recall
=== lamont` is now known as lamont
[19:52] <tvansteenburgh> lorenzotomasini: https://github.com/juju/python-libjuju/pull/56
[19:53] <tvansteenburgh> lorenzotomasini: that addresses the issues we talked about last week. trying to get some tests in there before merging, but hoping to release those changes soon
[21:04] <rick_h> tvansteenburgh: ping
[21:04] <tvansteenburgh> rick_h: pong
[21:04] <rick_h> tvansteenburgh: back from a break and poking at this adding of list models method
[21:05] <rick_h> tvansteenburgh: is there some pattern established for turning a Model object from the _client into a Model object from model.py?
[21:05] <rick_h> tvansteenburgh: I feel like I should get the facade bits back and build a proper Model object out of it somehow but not seeing anything atm
[21:07] <tvansteenburgh> rick_h: got any code i can look at? i don't entirely follow
[21:10] <rick_h> tvansteenburgh: https://pastebin.canonical.com/180574/ is what I've got in my head/current code
[21:11] <rick_h> tvansteenburgh: basically I'm looking that I shouldn't expose the end user of the controller/model code to the internal object types used in _client.py
[21:11] <rick_h> tvansteenburgh: so I'm wondering if there's any pattern for transforming one into the other
[21:15] <tvansteenburgh> rick_h: so you'll want to make new Model() and then call connect(...) on them
[21:15] <rick_h> tvansteenburgh: right, but list_models should return what, in your mind?
[21:15] <rick_h> tvansteenburgh: in the spirit of the library atm
[21:16] <tvansteenburgh> imo it should just return strings
[21:16] <rick_h> tvansteenburgh: of what? uuids? names?
[21:16] <tvansteenburgh> list of model names
[21:16] <tvansteenburgh> or uuids
[22:42] <bdx> is remote lxd provider a thing now?