[01:36] <wallyworld> kwmonroe: will do :-)
[02:48] <thumper> I'm not sure it is juju... just sayin
[02:48] <thumper> although I'm biased
[02:49] <thumper> wallyworld: just chatted with veebers about the launchpadlib upload bug
[02:49] <thumper> it seems it is a bug in the underlying python library, but we identified a potential work around
[02:49] <wallyworld> great ok
[02:49] <thumper> and veebers is testing it against staging lp
[02:49] <wallyworld> awesome
[02:49] <wallyworld> ty
[02:49] <thumper> thank veebers
[02:50] <veebers> thumper: no worries, thanks for chasing that up
[02:57] <veebers> thumper, wallyworld argh, need to sort out 2fa for the staging sso. I set it up years ago. I think I might still have paper codes somewhere :-\
[02:57] <thumper> haha
[02:58] <thumper> veebers: if it takes more than a few minutes, see if you can poke IS about it
[02:58] <thumper> sometimes it is faster to get it reset...
[02:59] <veebers> thumper: heh have already pinged. I think a reset is all that's possible :-)
[02:59] <thumper> I noticed :)
[03:00]  * veebers checks room for thumpers hidden cameras
[03:00] <thumper> no, but I'm in the IS channel :)
[03:01] <thumper> and I have the konversation summary view with all channels in it
[03:03] <veebers> hah ack, I have something similar
[03:20] <veebers> thumper: remind me that emacs mode you liked for binary/hex data
[03:20] <thumper> hexl-mode
[03:21] <veebers> sweet, thanks
[04:35] <thumper> https://bugs.launchpad.net/bugs/1778749
[04:35] <mup> Bug #1778749: error when using juju-reboot from hook <juju:New> <https://launchpad.net/bugs/1778749>
[04:47] <wallyworld> babbageclunk: not sure if you'll have time today for that review? if you're in the middle of something can wait till another time
[04:47] <babbageclunk> wallyworld: oh, sorry! looking now
[04:48] <wallyworld> no worries, can wait if you're busy
[05:16] <vino> wallyworld: I have pushed the PR. please review it.
[05:16] <wallyworld> sure
[05:16] <vino> iam yet to test the charm push
[05:16] <vino> also please let me know if more work is needed in unit test case.
[05:25] <wallyworld> vino: let me know if comments don't make sense
[05:26] <vino> sure wallyworld
[05:29] <vino> wallyworld: mostly name conventions.
[05:29] <vino> but just one question
[05:29] <wallyworld> sure
[05:30] <vino> we are not returning error incase version string is generated
[05:30] <vino> so incase of error instead of logging what needs to be done.
[05:30] <vino> i just want to make sure its empty string
[05:30] <vino> annotate the err
[05:30] <vino> ?
[05:32] <wallyworld> you could argue that an error should result in the operation failing. but then again, should it be fatal if someone has a git charm checkout and no git available. i think we can start with just logging an error
[05:35] <vino> ok. i will log at error.
[05:38] <wallyworld> or maybe a warning
[05:38] <wallyworld> i think a warning is better as an eror means fatal
[05:42] <vino> ok sure.
[05:42] <vino> and the last comment.
[05:42] <vino> is that for unit tests ?
[05:42] <wallyworld> yeah, there's ArchiveTo tests
[05:42] <vino> more units tests for ArchieveTo
[05:43] <wallyworld> they need to be updated or a new one added
[05:43] <vino> ok.
[06:05] <veebers> thumper, wallyworld: just finished testing the launchpadlib upload issue workaround and it's all good. I'll push the updated script and fire off an email so the team is aware (in case, for whatever reason, things go borked during a release)
[06:05] <wallyworld> yay, ty
[06:05] <wallyworld> veebers: will ned to update the jenkins job to remove the warning text also
[06:07] <veebers> wallyworld: it might be worth keeping it there, in case something goes wrong with the work around. Although perhaps you're right /me being over cautious
[06:07] <wallyworld> ifsomething goes wrong withthe workaround that's a bug to be fixed IMO
[06:08] <veebers> true, but it'll be good to have documented a workaround for the workaround, in case its work isn't around ^_^
[06:10] <wallyworld> it would but that's just papering over a problem that shjould now be considered fixed
[06:11] <wallyworld> i'm sure we could manually recovere from other issues with release jobs but we don't - we fix the job
[07:23] <thumper> veebers: thanks, I appreciate your effort around testing and checking
[09:01] <manadart> jam: Any glaring issues with mine and Simon's PRs? Keen to merge and move it along.
[09:02] <jam> will look now
[09:30] <jam> manadart: there is something
[09:30] <jam> probably small, thoug
[09:31] <manadart> jam: Shoot.
[09:33] <jam> manadart: specifically, you changed contanier.Metadata instead of being a map[string]string it is now *just* a modelUUID, and we shouldn't call that Metadata
[09:37] <manadart> The prior implementation of metadata was an unnecessarily heavy abstraction that meterialised container config into a data structure called where it was set/retrieved and transparently written as container config prefixed with "user." where necessary.
[09:39] <manadart> Now, config is set directly with the prefixes, and metadata is just a method to retrieve the user-namespaced keys directly for all those custom keys - container UUID, model UUID , cloud-init ser-data etc.
[09:39] <manadart> ^ "... into a data structure where it was..."
[09:45] <jam> manadart: yeah, actually I missed that you were passing the key *into* Metadata()
[10:00] <naturalblue> Hi. Is it possible to have juju run a script on deploy of a machine. i am trying to have a loopback device created on deploy. Thanks
[12:46] <rick_h_> morning party people
[14:18] <cory_fu> kwmonroe, wallyworld, thumper: To be fair, the most reasonable explanation that I can come up with for so many VMs is multiple runs of conjure-up, thinking that maybe some of them failed while waiting for the cluster to report ready, or during a post-deployment step.  We need to make it more obvious when a deployment fails after handing it off to Juju that it may be partially or even fully functional and how to interact with it or at least tear it
[14:18] <cory_fu> down.
[14:27] <cory_fu> stokachu: https://github.com/conjure-up/conjure-up/issues/1482 re ^
[14:31] <stokachu> +1
[15:16] <naturalblue> can you change a space binding once lxd has been deployed
[15:22] <manadart> rick_h_: I said constraints should be easy, but it was *really* easy. I actually have it working here. Instance types is trivial too. I will test it properly and propose a PR in the morning.
[15:22] <rick_h_> manadart: cool ty for looking. It'll be fun to play with and I'm sure bdx and magicaltrout  will be very interested
[16:25] <bdx> manadart: thats great news
[16:36] <hml> stickupkid: if you look at https://github.com/juju/juju/pull/8849 - i added the gomock matcher
[16:39] <stickupkid> hml: OfTypeBool to me sounds like any bool would suffice, should the name be IsTrue?
[16:40] <hml> stickupkid: i think i have it working for your choice of true or false
[16:40] <hml> stickupkid:  at least the tests seems to indicate
[16:43] <stickupkid> hml: maybe we should explicitly test for bool i.e. return o.b == b.(bool)
[16:44] <hml> stickupkid: perhap… gomock didn’t like the reflect line i had to check that the value was a bool
[16:44] <stickupkid> hml: https://github.com/juju/juju/pull/8849/files#r198563697
[16:44] <stickupkid> hml: better explained
[16:45] <hml> stickupkid: thx
[21:14] <Daltron7> Hello there,
[21:14] <Daltron7> Can anyone tell me if they seen the error: DEBUG unit.neutron-gateway/0.config-changed Cannot find device "eno2" and ERROR juju.worker.uniter.operation hook "config-changed" failed: exit status 1.
[21:15] <Daltron7> P.S. I already have `net.ifaces=0` configured on the MAAS server
[21:18] <rick_h_> Daltron7: not sure, so the config-changed hook ran and whatever the charm is doing in that hood is failing with the error about eno2
[21:19] <rick_h_> Daltron7: the config in question here is the application config "juju config neutron-gateway"
[21:19] <rick_h_> Daltron7: might have to hit up the charm authors to see what's failing
[21:20] <Daltron7> seems like it is trying to configure eno2 and failing: unit.neutron-gateway/0.config-changed subprocess.CalledProcessError: Command '['ip', 'link', 'set', 'eno2', 'up']' returned non-zero exit status 1.
[22:39] <wallyworld> babbageclunk: thanks for review! the k8s stuff is gnarly for sure. but it works. i'll be documenting ther workflow and expected setup of storage classes etc and feedback there will help finetune the api usage
[22:43] <babbageclunk> wallyworld: cool, sounds good!
[23:03] <veebers> wallyworld, babbageclunk: When using state.db().Run(...) with a simple []txn.Op{} Inserting a doc that has an Id, should I expect that Id to be == _id for that entry?
[23:04] <wallyworld> no, as the model uuid is prepended
[23:04] <wallyworld> if you look at mongo directly
[23:04] <veebers> wallyworld: ah *thats* what it is, cool thanks
[23:05] <wallyworld> that's done automagically
[23:05] <wallyworld> and it is stripped off on the way out
[23:06] <babbageclunk> what wallyworld said
[23:06] <veebers> wallyworld: I'm not seeing it stripped off when I do "coll.FindId(resourceID).One(&raw)" raw["_id"] == "some-uuid-string-here:<actual id>"
[23:06] <veebers> Ah, am I circumventing the auto-niceness doing it that way
[23:06] <wallyworld> it won't be there as you're looking at the raw data
[23:07] <wallyworld> the doc itself will have the correct DocId
[23:07] <babbageclunk> veebers: note, this also doesn't happen for collections that are marked as Global: true in allcollections.go
[23:07] <veebers> ah right, that makes sense. Cheers wallyworld
[23:07] <wallyworld> global collections are used across models without the need for discrimination
[23:08] <veebers> wallyworld, babbageclunk oh, right saw that too (Global in allcollections). Ian, should the docker resource storage be global? I presume at the moment the uuid used in the id will be the controller?
[23:08] <wallyworld> charms are per model so no
[23:09] <veebers> wallyworld: ack
[23:16] <wallyworld> veebers: veeeeeeeebeeeeeera
[23:16] <wallyworld> staaaaaaanduuuuuup
[23:18] <veebers> wallyworld: oh oop ssory omw
[23:19] <hml> wallyworld: my fault :-)
[23:19] <babbageclunk> good one hml
[23:22] <veebers> hml: re: adding a failure cause, it's not a job change but a thing added via jenkins ui. Will walk through after standupp :-)
[23:37] <veebers> hml: actually I got ahead of myself, there was already a rule there that I only had to tweak (use \d+ instead of a specific number). If you have a look now at the job the failure reason is obvious
[23:38] <hml> veebers: i see it.  thank you.  :-)
[23:40] <veebers> hml: not the description is wrong :-| I updated it to be correct. I'll add what I did to our discourse
[23:40] <hml> ty