[00:07] <tlm> what do we consider the primary web domain for juju? Need to inject a proper unique domain into kubernetes for the controller
[00:08] <timClicks> tlm: juju.is will be our home shortly
[00:08] <tlm> sold, thanks
[00:23] <hpidcock> tlm: inside k8s we use juju.io
[00:24] <hpidcock> but I think that is wrong
[00:24] <tlm> oh
[00:25] <timClicks> we never actually acquired that domain I think
[00:25] <hpidcock> yep
[00:26] <tlm> i am looking for refs in the code
[00:26] <tlm> we use it only in annotations now
[00:27] <tlm> should we change to something we own ?
[00:50] <anastasiamac> babbageclunk: https://github.com/juju/juju-restore/pull/6 has the one char read :)
[00:51] <babbageclunk> ok looking
[01:08] <babbageclunk> anastasiamac: neat! but the patches make me sad
[01:14] <babbageclunk> thumper: (or rick_h if you haven't gone to sleep yet) can you make one for juju/symlink as well? Otherwise juju/tar still depends on juju/utils/symlink
[01:56] <anastasiamac> babbageclunk: yeah :( i did not like ti eiether but i was not too keen to add yet another func as a property everywhere
[01:56] <anastasiamac> babbageclunk: anyway changed now.. PTAL ?
[01:58] <tlm> hey hpidcock hit a snag with ssl certs. Got time for HO ?
[01:59] <hpidcock> sure
[02:02] <babbageclunk> anastasiamac: approved!
[02:02] <anastasiamac> babbageclunk: \o/
[02:02] <anastasiamac> babbageclunk: wot's worng with 'in a raw mode"?
[02:02] <babbageclunk> anastasiamac: I know what you mean about passing in more things - it kind of means they end up leaky
[02:03] <anastasiamac> yeah main command call is growing :(
[02:03] <babbageclunk> anastasiamac: Well, there's only one raw mode, and the terminal's in it!
[02:03] <anastasiamac> i can honestly say that English articles r confusing!! :D
[02:04] <babbageclunk> yeah, that's probably fair
[02:11] <rick_h> babbageclunk:  https://github.com/juju/symlink
[02:21] <babbageclunk> yay thanks again rick_h - I think thumper's ignoring me.
[02:47] <thumper> babbageclunk: not ignoring, just busy
[02:48] <babbageclunk> thumper: I know, just hassling!
[02:48] <thumper> babbageclunk: the fileutils part was one of the next things I was wanting to extract
[02:48] <thumper> particularly the exec handling
[02:48] <thumper> but it was always just a bit "later"
[03:45] <thumper> wallyworld: seeing multiple intermittent test failures in ActionSuite.TestFindActionTagsByLegacyId trying to land in develop
[03:45] <wallyworld> ok
[03:46] <thumper> also in worker/caasoperator
[03:49] <thumper> jam: updated https://github.com/juju/juju/pull/11208 to use mark and sweep to indicate initialization step
[03:49] <thumper> to avoid calculating summaries while initializing
[04:56] <hpidcock> thumper: wallyworld: my pr fixes that intermittent failure
[04:57] <hpidcock> which has landed
[06:20] <tlm> hpidcock wallyworld: still sorting out stuff but start of PR https://github.com/juju/juju/pull/11089
[06:21]  * tlm will be back at 5
=== narindergupta is now known as narinderguptamac
[09:35] <achilleasa> hpidcock: so is this block copied over from the uniter and not in use atm? (https://github.com/juju/juju/blob/develop/apiserver/facades/agent/caasoperator/operator.go#L187-L211). Are there any plans to use it in the future? I guess I might as well add a leadership check there too to be safe... just need to figure out what AuthOwner() returns when inside the operator facade
[09:56] <hpidcock> achilleasa: when I looked a few hours ago there is no call to that from the caasoperator worker. It sets up an interface, casts the client to that interface, stores it and that was all. Only the uniter runner context has any mention of calling setpodspec. It looks like its been there for two years and nothing used it. Or uses it anymore. So without going through the history, I can't say for sure. But what I can say is
[09:56] <hpidcock> that an application should only have one caasoperator worker, so the leadership check is unnecessary.
[10:13] <achilleasa> hpidcock: that was my thought exactly which is why I am currently bypassing the check there (and in the migration path)
[11:04] <stickupkid> manadart, quick ho around openstack
[11:04] <stickupkid> ?
[11:06] <manadart> stickupkid: OMW
[11:06] <achilleasa> jam: when we introduce new hook types do we need to also open PRs against charm tools (e.g. to populate the symlinks when building the charm?)
[12:00] <nammn_de> manadart: later time for a ho about move-to-space and fan networking?
[12:04] <manadart> nammn_de: Sure. Let's do it after stand-up. I have to relocate home before then.
[12:04] <nammn_de> manadart: rgr
[12:35] <stickupkid> achilleasa, i'm seriously thinking of adding multiple errors to pkg/err
[12:35] <stickupkid> achilleasa, i'm sure we roll our own everytime
[12:36] <achilleasa> stickupkid: params.ErrorResult is one place
[12:36] <achilleasa> and I think we do something similar for bundlechanges
[12:36] <stickupkid> achilleasa, just done a new one in provider/openstack \o/
[13:25] <achilleasa> can I get a quick CR on this tiny change? https://github.com/juju/charm/pull/304
[15:19] <zeestrat> Hey, we're hitting something strange with where deploying cs:ubuntu-14 in a bundle fails, but deploying it manually with `juju deploy ubuntu --series xenial` works. Could someone humor me and deploy http://paste.ubuntu.com/p/XFqtd6qc7q/ with Juju 2.7.2 on local LXD before I write up a bug?
[15:23] <zeestrat> https://www.irccloud.com/pastebin/J43EZZHw/
=== parlos is now known as parlos_afk
=== narindergupta is now known as narinderguptamac
[15:46] <stickupkid> zeestrat, this might be related https://github.com/juju/charm-helpers/pull/434#pullrequestreview-361992024
[15:47] <zeestrat> stickupkid: thanks, looks that way. Still rather confused why it hits in bundle deploys but not CLI deploy. Thanks for the info!
[17:05] <achilleasa> stickupkid: can you take a look? https://github.com/juju/juju/pull/11237
[17:19] <achilleasa> stickupkid: added extra context for the uniter change
[17:20] <stickupkid> achilleasa, happy with that :+1:
[21:19] <thumper> aah... who changed history on the 2.7 branch?
[21:21] <thumper> also, how did the history get rewritten on the 2.7 branch
[21:21] <hml> thumper: when?
[21:21] <thumper> since Feb 1
[21:21] <thumper> which was the last time I pulled 2.7
[21:22] <thumper> https://github.com/juju/juju/commits/2.7?after=9da5b593fa1d096220230143f1e1fea5c4eb56ad+69
[21:22] <thumper> suspect there
[21:22] <hml> thumper: rick_h, we needed a backport from achilleasa  for 2.7.2 - there shoudl be 3 commits that got placed after his
[21:22] <thumper> Jan 23 looks right
[21:23] <hml> thumper: i’m not sure of the date though.
[21:25] <thumper> I'm not sure what has happened here
[21:27]  * thumper sighs
[21:27] <thumper> looks like the 2.7 branch was renaemd to 2.7-configoption
[21:27] <hml> thumper: it was around feb 10
[21:27] <thumper> and and older branch was pushed to 2.7
[21:27] <thumper> no idea what/why
[21:27] <thumper> not even sure if the 2.7-configoption is in 2.7
[21:28] <thumper> because one of my fixes doesn't appear to be in 2.7 any more
[21:28] <thumper> this needs more digging
[21:28] <hml> thumper: i don’t think that was us?  <crossing fingers>
[21:30] <thumper> FFS
[21:34] <thumper> and... those commits aren't in our latest release
[21:34] <thumper> so we are missing about four bug fixes in the 2.7 branch
[21:53] <babbageclunk> oh crap
[22:13] <timClicks_> wallyworld: which release notes template did you used for your 2.7.3 WIP post?
[22:13] <wallyworld> i copied 2.7.2 and hacked it up
[22:14] <wallyworld> there is a template somewher ei tihnk
[22:15] <timClicks_> which would have been copied from 2.7.1
[22:15] <timClicks_> they're using an old template
[22:15] <timClicks_> simon's release of 2.7.0 is using the current one
[22:23] <hpidcock> so turns out AWS instance pricing index.json is somewhat wrong. It shows prices for instance types for regions that don't fully support that type. It just means at least one AZ in that region supports that instance type...