[00:11] <kelvinliu_> veebers, agreed.
[01:27] <veebers> kelvinliu_: great work on the snap plugin stuff, lgtm
[01:27] <veebers> oh, let me comment that on the PR :-)
[01:28] <veebers> kelvinliu_: is this cribbed from the godep one?
[01:29] <veebers> if so, would it be possible to inherit from that and just change what's needed (I suspect the pull part)
[01:31] <kelvinliu_> veebers, the go and godeps plugin are very similar.
[01:31] <veebers> kelvinliu_: ack, I wouldn't want to hold up the PR, twas a thought :-)
[01:33] <veebers> kelvinliu_: is GepPlugin a typo?
[01:34] <kelvinliu_> veebers, i was also thinking to inherit existing plugin, but later think the plugin could be changed more often and is not like lib, might be very easy to break.
[01:34] <veebers> kelvinliu_: ack, fair enough
[01:35] <kelvinliu_> veebers, typo! lol
[01:35] <veebers> ^_^
[02:15] <babbageclunk> thumper: hey, quick question? I've upgraded yaml, and a slight behaviour change is causing problems in the netplan tests.
[02:16] <thumper> babbageclunk: what is the problem?
[02:16] <babbageclunk> thumper: we're using UnmarshalStrict and relying on the fact that it will overwrite keys in maps (if you unmarshal into an existing structure).
[02:16] <babbageclunk> thumper: the new version refuses to do this.
[02:16] <babbageclunk> (of UnmarshalStrict)
[02:16] <thumper> what does it do?
[02:17] <babbageclunk> although normal Unmarshal will (but also that implies silently ignoring unrecognised attrs).
[02:17] <babbageclunk> Errors.
[02:18] <thumper> is it a bug in the yaml code?
[02:18] <thumper> or defined behaviour?
[02:18] <babbageclunk> The latter, I think
[02:18] <babbageclunk> Yeah, it's mentioned in the doc
[02:18] <thumper> probably worth checking that bit
[02:18] <thumper> is it only effecting tests and not real code?
[02:21] <babbageclunk> thumper: It's affecting real behaviour
[02:21] <thumper> ugh... what is the new yaml changes needed for?
[02:22] <babbageclunk> I use NewDecoder and NewEncoder in the raftlease code.
[02:22] <babbageclunk> I could rewrite it without them, but that's kind of leaving the problem for someone else who tries to upgrade it next time.
[02:23] <thumper> I guess we should fix the netplan code
[02:23] <thumper> can you do a separate branch that just updates yaml and the netplan bits?
[02:24] <babbageclunk> Also, the feature that netplan uses it for is kind of broken anyway. It's using this to merge multiple configs, but this doesn't merge the mapping values, it just replaces the object at one key with a new one: https://bugs.launchpad.net/juju/+bug/1701429
[02:24] <mup> Bug #1701429: Netplan bridger does not properly merge yaml files <juju:Won't Fix by wpk> <https://launchpad.net/bugs/1701429>
[02:24] <babbageclunk> Yeah, I'll do that.
[02:24] <babbageclunk> (Separate branch for the yaml upgrade.)
[02:26] <thumper> babbageclunk: will you fix bug 1701429 while you are at it?
[02:26] <mup> Bug #1701429: Netplan bridger does not properly merge yaml files <juju:Won't Fix by wpk> <https://launchpad.net/bugs/1701429>
[02:26] <babbageclunk> thumper: No, I wasn't planning on that, but it would be a step towards doing it.
[02:26] <thumper> ok
[02:27] <thumper> leave a bug reference in the code
[02:27] <babbageclunk> Wilco
[02:50]  * thumper sighs...
[03:31] <thumper> vinodhini: commented on goose PR
[03:34] <thumper> oh ffs, I fubared my git thing again
[03:35]  * thumper wonders how to do this...
[03:35] <thumper> how do I merge just one file out of a commit?
[03:40]  * thumper wonders WTF is going on now...
[03:42]  * thumper works it out
[03:42] <thumper> nm everyone, it's all fine
[03:44] <veebers> thumper: to merge a single file from another commit, in the past I've used 'git checkout <branch/commit> -- <paths>'
[03:44] <thumper> oh... nice
[03:44] <thumper> I ended up cherry picking then discarding
[03:45] <veebers> ah, that'll work too
[05:05] <thumper> babbageclunk: please ask jam to review your yaml netplan branch update
[05:06] <babbageclunk> thumper: ok, will do
[05:28] <veebers> kelvinliu_: awesome work with the edge snap, looks like their building fine now
[05:29] <kelvinliu_> veebers, thanks for the help. :->
[05:35] <thumper> hazaah
[05:35] <thumper> well done veebers and kelvinliu_
[05:43] <kelvinliu_> thumper, ^_^
[06:02] <vinodhini> thumper: i have replied to ur comments and added few more unit tests.
[06:06] <thumper> vinodhini: awesome, I'm EOD now, but I'll look tomorrow morning
[06:09] <thumper> later peeps
[06:17] <babbageclunk> hey jam: would you be able to take a look at this? https://github.com/juju/juju/pull/9063
[06:26] <jam> babbageclunk: sure
[10:19] <jam> babbageclunk: reviewed 9063, lgtm
[11:31] <elox> I'm trying to deploy to a specific zone, but "juju status" ends up in "pending" how can I figure out why?
[11:31] <hadrianweb> maybe stack on retrieving lxd image? or downloading rootfs?
[11:32] <elox> Its a maas, to the servers are physical
[11:32] <hadrianweb> so you can see the pxe installation progress
[11:32] <elox> This is what i do: "juju add-machine zone=b209-1040
[11:33] <elox> The output from juju status is "pending"
[11:33] <hadrianweb> have you acces to server, ilo os ipmi to se quehre they are stacked?
[11:35] <elox> I can perform a "power check" successfully, I don't think its the ipmi
[11:50] <elox> If I run "juju deploy ubuntu --to able-stork.maas" .... that works (which is the only host in the zone I need) the host successfully deploy. But as soon as I deploy with "juju deploy ubuntu --to zone=b209-1040", it ends up in pending.
[11:50] <elox> Maybe this is a MAAS specific question.
[12:25] <rick_h_> elox: do you see a machine pop up and start allocating in MAAS?
[12:29] <elox> rick_h: The node works
[12:32] <elox> I'm trying out the zone concept, so its not a crisis, but I keep getting stuck at "pending"
[12:35] <rick_h_> elox: right, so from a Juju perspective it seems it's asked for a machine. So I'm wondering if MAAS is seeing/bringing up that machine at all?
[12:36] <elox> rick_h: It seems that it could have been due to me using another users model which I seem to be able to deploy machines, but not using "zone" as a placement directive... very confusing. I'm now using a model I own and it seems to work now ?
[12:38] <jam> elox: if you're using another users model, then likely it is deploying using *their* credentials. Are they able to see the zone in MAAS?
[12:38] <jam>  and/or do they have machines in that zone available to them from MAAS?
[12:38] <jam> we do a check to see if the availability zone specified is available, and generate a "availability-zone "blah" is unavailable" if we don't see it.
[13:01] <elox> jam: It started to work just now, but stopped to work for newly added zones (!)
[13:02] <elox> Could this be due to some delay in some update frequency for the nodes metadata?
[13:18] <elox> It seems it might not have been due to the ownership of the modes since now after I have made some modifications to the zones again in MAAS, again, I'm getting the "pending" status for using the new zones.
[13:31] <hml> stickupkid: do you want me to wait on reviewing pr 9065 or go ahead?
[13:31] <stickupkid> hml: go ahead
[13:32] <hml> stickupkid: k
[13:45] <elox> I have found that only when starting a new model, it seems to work to deploy to a zone. As soon as I create a new model, it works for that model. This must be a maas/juju bug ?
[13:49] <elox> Is this perhaps "by design" ? keeping zone information imutable ?
[17:08] <stickupkid> hml: I responded to your questions... i've got a potential fix for register credentials comming, but thought i'd give a heads up https://github.com/juju/juju/pull/9065#pullrequestreview-146467062
[20:55] <veebers> rick_h_: you may have seen that kelvinliu_ sorted out the edge snap builds
[20:55] <rick_h_> veebers: yep, awesome stuff. Used it today to test out some stuff
[20:56] <rick_h_> veebers: and ty for your discourse post around the snap stuff
[21:00] <veebers> nw, always good to get the siloed info shared
[22:45] <thumper> anyone? https://github.com/juju/juju/pull/9064
[22:45]  * babbageclunk is someone!
[22:57] <thumper> vinodhini: ping
[23:07] <kwmonroe> thumper: i enjoy reading your PRs.  i'm not qualified to review them, but by golly, i like that even you have to add a 2nd commit that says "fix the tests".
[23:08] <thumper> heh
[23:08] <thumper> kwmonroe: and you can even see that the commit that fixes the test doesn't just delete them or comment them out :)
[23:09] <kwmonroe> yeah thumper, that was weird.  i look forward to a discourse post that says "don't just delete the tests; fix them!"
[23:09] <thumper> :)
[23:10] <kwmonroe> (ps, most tests can be fixed with global vars)
[23:11]  * babbageclunk narrows eyes
[23:11]  * babbageclunk reaches for an obscure unicode character
[23:20] <babbageclunk> I didn't even send it!
[23:29] <kwmonroe> ha babbageclunk!  it took me a minute to get the ref... don't you worry, unicode away, for i have just upgraded my quassel.  you can't hurt me now ∂
[23:30]  * babbageclunk hmms
[23:32] <babbageclunk> Did he just auto-lart?
[23:35] <vern> hey thumper: I've got several bundles that are only different by a few lines in the variables section. can an overlay bundle simply be a variables section? or do I need to also define every application/option that I want to change with those variables?
[23:36] <thumper> vern: the variable substitution is done before the merging code
[23:36] <thumper> as the substitution happens as part of the yaml parsing
[23:36] <thumper> vern: so the latter
[23:36] <vern> thumper: ah, I was worried about that. okay, thanks
[23:40] <kwmonroe> dag nab it.  quassel-client wasn't the problem.  ∫ ∂ ø all day now babbageclunk
[23:44] <vern> thumper: slight variation to the same question: do juju bundles allow any kind of include directive?
[23:45] <thumper> vern: only post parsing... for include and include-base64 for config values
[23:45] <vern> thumper: thank you