[02:28] <veebers> babbageclunk: will juju version always be major.minor.patch? when we release 2.4 will it be 2.4.0 or 2.4?
[02:29] <veebers> anastasiamac: ^^?
[02:30] <anastasiamac> veebers: yes, always... 2.4.0 :)]
[02:30] <veebers> awesome, cheers anastasiamac :-)
[02:30] <anastasiamac> veebers: nws
[02:40] <veebers> gah, I can't just take a 2.4-beta2 jujud, repackage it as 2.4-beta3.*.tgz and have a streams entry as 2.3-beta3 right? the actual upgrade will fail as it'll check the `jujud version` I presume?
[02:42] <babbageclunk> veebers: you can put a force-version file in there, which will change what jujud version reports
[02:42] <veebers> babbageclunk: oh, tell me more. Is that put in the agent tarball?
[02:43] <babbageclunk> look at what's in the directory when you do upgrade-juju --build-agent
[02:43] <babbageclunk> hang on, I'm just looking myself
[02:44] <babbageclunk> yeah, it's FORCE-VERSION
[02:45] <babbageclunk> veebers: https://github.com/juju/juju/blob/develop/version/version.go#L36
[02:47] <veebers> babbageclunk: awesome thanks! I'll incorp into the functional test
[02:48] <babbageclunk> yeah, I think it just needs to be included in the tarball - if you search for FORCE-VERSION in the codebase you can see where upgrade-juju --build-agent includes it.
[02:57] <veebers> much appreciated (damn I tried finding that strongbad vid but couldn't find it)
[03:15] <babbageclunk> appriciated?
[03:16] <veebers> babbageclunk: my search only comes up with the technology introduction one
[03:19] <babbageclunk> veebers: http://www.homestarrunner.com/sbemail53.html
[03:20] <veebers> babbageclunk: you're a star!
[03:20] <babbageclunk> thanks hrwiki.org, you saved my bacon again!
[03:20] <veebers> ah and it's such a milestone vid too!
[03:20] <veebers> hah
[05:11] <vino> babbageclunk: hi I have the remaining unittests and addressed the review comments.
[05:14] <babbageclunk> vino: ok, taking a look now
[05:14] <vino> sure.
[05:18] <veebers> babbageclunk: hah I'm vying for your attention too :-) I've finally pushed the upgrade CI test updates for the agent-stream PR if you could take a look when you can (and addressed your comments too)
[05:18] <babbageclunk> veebers: ok, will do
[06:04] <babbageclunk> hey veebers, I have to go and help wrangle the animals now, I'll loook at your PR first thing tomorrow, sorry!
[07:11] <veebers> babbageclunk: no worries, good luck with the wranglin'
[08:55] <ice9> when i bootsrap localhost, it throw error about unknown certificate authority and it doesn't create the controller!
[11:04] <BlackDex> Hello there. I have an environment with juju 1.25.13 (not able to upgrade now) and i have several sub-charms (nrpe) running, which aren't beining removed. I tried several times to do remove-relation, but they are still there. No action is taken it seems
[11:04] <BlackDex> i Also tried to restart the jujud-unit-nrpe on these nodes.
[11:04] <BlackDex> no effect
[12:58] <CG__> hi..
[12:59] <CG__> am using jenkins charm..
[12:59] <CG__> when i do $juju gui --browser
[12:59] <CG__> it opens up a browser, and am looking to change the UI
[12:59] <CG__> please suggest how to
[13:06] <BlackDex> change the UI?
[13:07] <CG__> yes, am looking to modify/change the UI
[13:07] <BlackDex> of juju web-interface?
[13:08] <BlackDex> i think you should take a look at https://github.com/juju/juju-gui
[13:08] <CG__> yes correct
[13:09] <BlackDex> and the juju-gui is located on the system where you installed the controller
[13:09] <BlackDex> so where  you bootstraped juju to
[13:09] <BlackDex> https://github.com/juju/juju-gui/blob/develop/docs/hacking.md
[13:09] <BlackDex> is what you are looking for i think
[13:11] <CG__> not exactly. Have tried that as well.
[13:12] <CG__> am planning to develop my own UI
[13:15] <ice9> is possible to deploy charms (model) on one lxc container or each charm must have it's own container?
[13:20] <BlackDex> ice9: Why do you want to deploy multiple charms in one container?
[13:21] <BlackDex> kinda defeats the purpose of containers
[13:55] <ice9> BlackDex, if they are small services that you want to keep on one container only
[14:04] <BlackDex> but why do you want to keep them in one container? containers don't use much resources, so i do not see why you want to merge those :).
[14:04] <BlackDex> But it is possible
[14:06] <BlackDex> just use `juju deploy cs:charm application-name --to 0/lxd/1` where you need to change the 0/lxd/1 to the correct machine id
[14:06] <ice9> when i try to create a juju controller i get this error
[14:06] <ice9> "x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate
[14:07] <BlackDex> never saw that before
[17:12] <ice9> how to specify ubuntu version when creating controller?
[17:13] <bdx> ice9: juju help bootstrap
[17:14] <bdx> ice9: `juju help <any-juju-command-you-want-help-with>`
[17:22] <ice9> bdx, it's not clear in the help about which option can do that
[17:23] <bdx> ice9: juju help bootstrap | grep series
[17:23] <ice9> thanks
[17:23] <bdx> np
[19:18] <[Kid]> anyone had issues with juju deploying openstack on hosts that have shared storage?
[19:19] <[Kid]> specifically fiber channel multipathed storage
[19:19] <[Kid]> i am using conjure and juju is failing at provisioning the osd container
[19:19] <[Kid]> hook failed: "mon-relation-changed" for ceph-mon:osd
[19:20] <[Kid]> and it is saying it cannot lock the device that is one of the paths to my shared storage
[19:21] <[Kid]> https://paste.ubuntu.com/p/Y6Hh758CPQ/
[20:43] <veebers> Morning o/
[21:36] <babbageclunk> ok veebers, looking at your PR now!
[21:37] <veebers> babbageclunk: excellent, thanks!
[22:06] <babbageclunk> veebers: approved! (with a couple of minor comments)
[22:07] <veebers> \o/ thanks babbageclunk
[22:07]  * babbageclunk highfives veebers
[22:08] <veebers> o/*\o
[22:12] <babbageclunk> oh thanks
[23:54] <veebers> babbageclunk: so, to test the early error (arg not support on ye old controller) I need a MockAPIConnection and try get a upgradeJujuCommand command that uses that (and set the bestFacadeVersion)?
[23:54] <veebers> babbageclunk: oh, or do I patch the s.APIState in the test (api.Connection) so that BestFacadeVersion returns the value I want?
[23:55] <babbageclunk> veebers: yeah, basically - I think we should have something that does it, since it's a reasonably common kind of test for the API clients
[23:55] <babbageclunk> Hang on, just having a look
[23:58] <veebers> babbageclunk: awesome thanks, I had a look but the one thing I can find that does what I want (cmd/juju/machin/remove_test.go) doesn't mesh with the upgrademodel_test.go stuff that is currently there