| === hbaum_ is now known as hbaum | ||
| sur_ | anrah: | 06:17 |
|---|---|---|
| sur_ | are you there | 06:17 |
| sur_ | sur: | 06:18 |
| sur_ | sur_: | 06:18 |
| === frankban|afk is now known as frankban | ||
| anrah | now i am | 08:34 |
| kjackal | Good morning Juju world! | 08:44 |
| 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? | 09:04 |
| brym | morning all | 11:26 |
| magicaltrout | lazyPower: lmk when you're in your seat | 12:16 |
| 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 | 12:45 |
| === 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 | ||
| joedborg | hello all. does anyone know if there's a juju command to monitor which set_states are being called in real time? | 16:37 |
| === mup_ is now known as mup | ||
| === mup_ is now known as mup | ||
| 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' | 16:59 |
| 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. | 17:00 |
| === mup_ is now known as mup | ||
| === mup_ is now known as mup | ||
| === mup_ is now known as mup | ||
| === mup_ is now known as mup | ||
| joedborg | @kwmonroe thanks | 17:14 |
| joedborg | @kwmonroe although everything seems to come back as None value, is this normal? | 17:14 |
| 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:18 |
| cory_fu | Right, the only states that would have values are relation states. That helper should really just be returning the keys | 17:19 |
| === frankban is now known as frankban|afk | ||
| 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:17 |
| kwmonroe | merged cory_fu.. don't worry about releasing cwr-52 to stable, i'll cut a new one that picks this up. | 18:20 |
| kwmonroe | hahah cory_fu, you just conflicted kjackal (https://github.com/juju-solutions/layer-cwr/pull/93). payback, eh? | 18:22 |
| cory_fu | :) | 18:23 |
| joedborg | @corey_fu @kwmonroe: ah, so these all are one that have been fired? | 18:23 |
| joedborg | @cory_fu ^^ | 18:24 |
| 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:26 |
| 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:27 |
| stormmore | o/ juju world | 18:28 |
| redir | \o stormmore | 18:51 |
| stormmore | are we having fun today? | 19:03 |
| 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:04 |
| 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:05 |
| joedborg | @kwmonroe thanks | 19:07 |
| 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:08 |
| joedborg | kwmonroe: thanks man, I'll probably take you up on that offer :) | 19:28 |
| 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:31 |
| cory_fu | kwmonroe: I really don't recall | 19:34 |
| === lamont` is now known as lamont | ||
| tvansteenburgh | lorenzotomasini: https://github.com/juju/python-libjuju/pull/56 | 19:52 |
| 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 | 19:53 |
| 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:04 |
| 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:05 |
| tvansteenburgh | rick_h: got any code i can look at? i don't entirely follow | 21:07 |
| rick_h | tvansteenburgh: https://pastebin.canonical.com/180574/ is what I've got in my head/current code | 21:10 |
| 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:11 |
| 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:15 |
| 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 | 21:16 |
| bdx | is remote lxd provider a thing now? | 22:42 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!