[00:10] <hloeung> NickZ: all the configs are exposed to all hooks, you need to use 'config-get' to retrieve the vaules
[00:11] <hloeung> NickZ: might want to look at using charmhelpers which helps make writing charms easier
[00:12] <hloeung> NickZ: anyways, I think this might help you - https://docs.jujucharms.com/2.4/en/reference-hook-tools#config-get
[00:12] <NickZ> ah hah
[00:12] <NickZ> thats the one
[00:12] <NickZ> thanks
[02:49] <veebers> wallyworld: FYI https://paste.ubuntu.com/p/XtJPrZzMgN/ just fleshing out a unit test or 2 to make sure the changes are covered properly (and not just tangentially)
[02:50] <wallyworld> looks good
[03:13] <veebers> wallyworld: *sigh* I don't see the 'active' status set come through at all on a 'good run', investigating
[03:14] <wallyworld> that would be triggered when container status flips to running
[03:15] <veebers> wallyworld: it's not in the collection at all, status is 'Started Container' (i.e. from cloud container status update)
[03:16] <wallyworld> that cloud container status change to "started container" should cause the unit status to be re-evaluated
[03:16] <veebers> indeed
[03:16] <wallyworld> and written to history
[03:24] <wallyworld> kelvinliu_: this PR add constrains support. the actual change is small - the k8s tests add several lines to the diff https://github.com/juju/juju/pull/9187
[03:28] <kelvinliu_> wallyworld, looking it now
[03:28] <wallyworld> ty. no rush
[03:39] <kelvinliu_> wallyworld, looks awesome! just not sure if the constraint is the max or min?
[03:39] <wallyworld> kelvinliu_: it is the max for k8s
[03:39] <wallyworld> similar to lxd
[03:39] <wallyworld> whereas for clouds it is the min
[03:40] <wallyworld> we haven't sorted out a syntax yet to cover both cases in a way the everyone could agree on
[03:41] <kelvinliu_> wallyworld, ic. great thanks
[03:42] <wallyworld> kelvinliu_: any luck with the controller.yaml hacking?
[03:47] <kelvinliu_> wallyworld, agent.conf is always changing for each run of `jujud machine`/`jujud bootstrap-state`. the changes include controllercert, controllerkey, password,ipaddress, sharedserets, etc
[03:48] <wallyworld> kelvinliu_: that's because jujud bootstrap-state re-generates all that stuff (from memory). it is only supposed to be run once to set everything up
[03:49] <kelvinliu_> wallyworld, im wondering how to register a 2nd controller.
[03:49] <kelvinliu_> wallyworld, im guessing whenever jujud machine starts, it will be a brand new controller?
[03:51] <wallyworld> kelvinliu_: "jujud machine-0..." is the start of a configured controller and can be done many times as the systemd server restarts. agent.conf is all set up and the key things like cert etc are fixed.
[03:51] <wallyworld> jujud bootstrap is used to initialise things and only runs once
[03:52] <kelvinliu_> wallyworld, `var/lib/juju/tools/machine-0/jujud machine --data-dir '/var/lib/juju' --machine-id 0 --debug` always changes the conf file for each run
[03:52] <wallyworld> in what way?
[03:52] <kelvinliu_> wallyworld, yes
[03:52] <wallyworld> what changes is jujud machine macking?
[03:53] <wallyworld> it might update some things, but not ca cert or api addresses
[03:54] <kelvinliu_> it changes  controllercert, controllerkey,ipaddress
[03:55] <wallyworld> something is wrong then i think. i expected the cert and key to be set up as part of bootstrap and then left alone
[03:56] <wallyworld> i have a meeting in a minute, i can look as the code after
[03:57] <kelvinliu_> wallyworld, i m going to grab some food, then continue to look into it soon.
[03:57] <wallyworld> no worries
[06:02] <wallyworld> kelvinliu_: how'd you go, did you need me to look at anything?
[06:06] <kelvinliu_> wallyworld, did some hardcode, and fixed a bug at /github.com/juju/juju/utils/scriptrunner/scriptrunner.go, just got `juju status` talked with apiserver successfully.
[06:06] <wallyworld> great
[06:07] <wallyworld> kelvinliu_: so you run jujud bootstrap-state once, and then jujud machine as many times as you want
[06:07] <wallyworld> and that specific controller agent works with a hacked controllers.yaml
[06:09] <kelvinliu_> wallyworld, yes, the controller key/cert changed still, but I made the apiaddress unchanged by hack the code.
[06:09] <wallyworld> hmmm, the key/cert should not change when jujud machine is run
[06:09] <kelvinliu_> wallyworld, I added the local controller info into my juju home
[06:13] <kelvinliu_> wallyworld, seems we include the current ipadress into the cert
[06:16] <kelvinliu_> wallyworld, so now i have to cp the latest cert from agent.conf to ~/.local/share/juju/controllers.yaml to let juju cli working whenever jujud restarted
[13:39] <hml> stickupkid: i moved the pr for changing the v7-unstable to reference itself into the review colomn, that “should” land before the profile changes.   we’ll see after the mtg
[13:51] <stickupkid> hml: i've made a few comments, but not approved until after the meeting :D
[13:53] <hml> stickupkid: ty - understood.  i’ll have the other piece up shortly
[14:05] <hml> stickupkid: i’m thinking empty should check for config and devices, i wasn’t going to bother with name or description.  any preference?
[14:05] <stickupkid> hml: yeah, that's fine with me, I'm not a fan of name anyway, so config and devices wfm
[14:54] <hml> stickupkid: quick HO?
[14:54] <stickupkid> hml: of course
[15:39] <hml> stickupkid: pr updates available for your viewing pleasure.  :-)
[15:40] <stickupkid> hml: sweet
[15:46] <stickupkid> hml: note we can do this https://play.golang.org/p/YNNbd7jAqCh
[15:47] <stickupkid> hml: i.e. we can move between structs without manual conversion, as long as the types align
[15:49] <hml> stickupkid: do the func magic() inside juju?
[15:49] <stickupkid> hml: yeah
[15:50] <hml> k
[17:06] <rick_h_> kwmonroe: cory_fu bdx magicaltrout zeestrat juju show countdown, 54min to go
[17:06] <rick_h_> juju show everyone! refill your coffee, batten down all hatches!
[17:16] <aisrael> cory_fu, I noticed charm-tools depends on python3.5 when I try to build, but 3.5 isn't available on bionic. Thoughts on either moving it to 3.6 or build/testing on bionic?
[17:22] <cory_fu> aisrael: Yeah, it should work with 3.6.  I didn't know there was a hard req on 3.5
[17:22] <cory_fu> aisrael: I'm working on the snap build, so I can take a look
[17:23] <aisrael> cory_fu: yep, fails w/"ERROR:   py35: InterpreterNotFound: python3.5" when I run `make`
[17:24] <aisrael> I pushed a change for review, but haven't been able to test it locally because of that
[17:28] <zeestrat> rick_h_: sorry, can't make this one. As a suggestion for the next one, it would be cool to have some of the Openstack charmers on to talk about their latest release.
[17:29] <rick_h_> zeestrat: I'll ping beisner on that <3
[17:39] <cory_fu> aisrael: Change tox.ini to have these:
[17:39] <cory_fu> envlist = py27, py35, py36, py37
[17:39] <cory_fu> skip_missing_interpreters = true
[17:40] <aisrael> cory_fu, ack
[17:48] <rick_h_> folks that want to join the juju show and chat can use: https://hangouts.google.com/hangouts/_/vw67fkh53jhurbafbnrohikvfme
[17:48] <rick_h_> agenda so far: https://discourse.jujucharms.com/t/juju-show-39-beedy-show-and-tell-and-news/233
[17:48] <rick_h_> and those that want to watch the stream: https://www.youtube.com/watch?v=OH1TMQzep1s
[17:48] <beisner> Just a heads up on that skip missing interpreters trick, if the machine has none of those versions, it will exit cleanly and pass without executing any tests.
[17:49] <rick_h_> beisner: hah, that sounds less than helpful
[17:49] <beisner> cory_fu aisrael fyi ^
[17:49] <aisrael> beisner, sounds about right ^_^
[17:50] <cory_fu> beisner: yeah, but I don't know of an alternative
[17:51] <cory_fu> aisrael: You could maybe try just using "py3" but I feel like I remember that not working
[17:51] <beisner> py3 works now
[17:52] <beisner> But it’s also not a perfect solution as you may want to actually test against multiple py3x’s.
[17:55] <cory_fu> beisner: True.
[17:55] <cory_fu> aisrael: I do think py3 would be better for the charm-tools case, as we don't have any specific py3.x requirements
[17:56] <beisner> rick_h_  What is the date and time of that session?
[17:56] <rick_h_> beisner: so it'd be two weeks from right now
[17:56] <rick_h_> beisner: or we could shift it it's helpful for TZs
[17:56] <rick_h_> bdx: ping-ping
[17:57] <aisrael> cory_fu, makes sense. I'll update tox and see about adding a test for my pr
[17:57] <rick_h_> 3min warning for anyone else that wants to join in
[18:02] <beisner> rick_h_: should work - can you send me an invite / details?
[18:02] <beisner> for +2wks
[18:04] <kwmonroe> hey! you weren't lying.. my jaas models are 2.4.3.  neat!
[18:25] <rick_h_> kwmonroe: would I like to you :p
[18:28] <NickZ> aw
[18:29] <NickZ> i missed it
[20:32] <NickZ> what's going on in salt lake city?
[20:37] <veebers> Morning all o/
[20:58] <thumper> NickZ: the next product sprint in october
[21:01] <NickZ> ah hah
[22:13] <veebers> wallyworld: we have an issue, if the charm sets status as active before the pods are done we loose that history (status is stored, but not history, so 'juju status' shows the active message once everything is resolved, but show-status-log won't show it as the current active)
[22:59] <wallyworld> veebers: when the container status changes state, it is supposed to see if unit status would be different and update history
[23:00] <wallyworld> call probablyUpdateHistory() - that checks the last known historical value and updates if needed
[23:04] <veebers> wallyworld: hmm, good point, I think it might be a small tweak then; We're no longer losing that data as I just fixed that (active being overwritten by 'waiting for container' due to timing)
[23:06] <wallyworld> perceived unit status = func(unit status, container status).... so when either changes, call probablyUpdateHistory()
[23:06] <veebers> aye