[00:01] <teranet> k done : http://paste.ubuntu.com/23631252/
[00:02] <marcoceppi> teranet: what does MAAS say now?
[00:02] <teranet> 3 Ready  3 deployed
[00:02] <marcoceppi> teranet: okay, so you've got 3 nodes doing something else?
[00:03] <teranet> nope
[00:03] <teranet> should I release those too ?
[00:03] <marcoceppi> teranet: release those manually then
[00:03] <teranet> 1 I know had a hardware issue which I fixed
[00:03] <teranet> ok will do
[00:04] <teranet> ok now they are all ready
[00:05] <teranet> so now I should bootstap again ?
[00:07] <teranet> correct ?
[00:12] <teranet> ok bootstapping a controller again
[00:12] <marcoceppi> teranet: yes, bootstrap and deploy again
[00:13] <teranet> for juju-gui can I only deploy the gui to make it work or does the rabbitmq server has to be deployed too?
[00:13] <teranet> and mysql sorry forgot that one LOL
[00:14] <bdx> teranet: what I would do, when all your maas machines are in a 'ready' state, is `juju add-machine -n 6`
[00:14] <bdx> teranet: and just make sure they all deploy successfully without any charms or bundles
[00:14] <teranet> hmm ok will do that
[00:15] <bdx> then once you verify that, the rest should fall into place
[00:15] <teranet> how do I add later more to it ?? does juju does it automaticly once maas say''s they are ready ?
[00:15] <bdx> teranet: yea, your `juju status` will show them as 'started'
[00:16] <bdx> if you succeed in ^, the rest will work given you have your maas<->juju<->openstack networking aligned
[00:16] <teranet> ok will check it
[00:21] <marcoceppi> teranet: juju gui doesn't require anything
[00:21] <marcoceppi> teranet: it's already deployed by default, just run `juju gui` command
[00:24] <teranet> ah ok cool
[04:30] <wetoolaguer> Hi everybody, I'm trying to use this bundle https://jujucharms.com/kubernetes-core/ but it's installing the latest version of kubernetes. How can I force it to use an older version? Thanks a lot!
[04:48] <stub> skay: ta. I'll test and merge that and add some docs on the charm store publication workaround.
[06:03] <stub> skay: released
[06:28] <stub> kwmonroe: My issue on that is https://github.com/juju/charmstore-client/issues/103
[08:46] <kjackal> Good morning Juju world!
[13:30] <deanman> Hello, is it possible to auto-scale (regardless the infra) the worker node of a juju kubernetes deployment?
[13:30] <deanman> or do you have to create a custom solution that monitors kube workers load and decides whether to request for extra resources (lxd, VMs) using the API of the underlying infra?
[13:33] <voidspace> frankban: ping
[13:33] <frankban> voidspace: hey
[13:33] <voidspace> frankban: hey, hi
[13:34] <voidspace> frankban: I have made a change to bundlechanges that I would appreciate you looking at
[13:34] <frankban> voidspace: sure
[13:34] <voidspace> frankban: https://github.com/juju/bundlechanges/pull/29
[13:34] <voidspace> frankban: we need container placement to honour application constraints
[13:34] <voidspace> frankban: this change implements that
[13:34] <voidspace> frankban: but the bundlechanges package is new to me :-)
[13:35] <voidspace> frankban: when you get a chance anyway
[13:36] <frankban> voidspace: looking
[13:37] <voidspace> frankban: for context, this is the juju bug https://bugs.launchpad.net/juju/+bug/1626597
[13:37] <mup> Bug #1626597: Juju ignores constraints set in the bundle and deploys KVMs with default values <4010> <juju:Triaged by mfoord> <https://launchpad.net/bugs/1626597>
[13:53] <frankban> voidspace: reviewed
[13:54] <voidspace> frankban: your analysis of the bug seems correct and passing constraint only rather than application is reasonable, however also <shrug>
[13:54] <voidspace> frankban: :-)
[13:55] <voidspace> frankban: the new test, when the unit is located to "new", that can't be a container can it?
[13:55] <frankban> voidspace: yeah that's the kind of "take it or leave it" suggestion, the branch is good, happy to see that bug discovered
[13:55] <voidspace> frankban: a unit can only be located on a container if placement is specified
[13:55] <voidspace> frankban: i.e. I'm not entirely sure what you mean by "new" :-)
[13:55] <frankban> voidspace: it cannot, but since your change touches that it would be nice if that's exercised by a test anyway
[13:56] <frankban> voidspace: "new" is a special placement meaning new top level machine
[13:56] <voidspace> frankban: right
[13:57] <voidspace> frankban: is that an explicit placement?
[13:57] <voidspace> frankban: ah, I see it in the code - I will try and work it out
[13:57] <frankban> voidspace: which is the default if no placement is specified, but for instance, IIRC, can be used in a multiple placement definition, like to: ["1", "new", "lxd:2"] or similar
[13:57] <voidspace> frankban: ah, I see
[13:57] <voidspace> frankban: understood
[13:57] <frankban> cool
[13:58] <voidspace> frankban: I may be able to remove that change - let me check
[13:58] <frankban> voidspace: for instance https://github.com/voidspace/bundlechanges/blob/37e0752c3c530d1af168b3a2f90592dc9ce85549/changes_test.go#L286
[13:58] <voidspace> frankban: I added the change there too because I saw a ContainerType
[13:59] <voidspace> frankban: yep
[13:59] <frankban> voidspace: I don't think that's a bad change, maybe that's required as well
[13:59] <voidspace> frankban: right, it might actually be a different bug...
[13:59] <voidspace> frankban: ok, I'll add a new test :-)
[13:59] <frankban> voidspace: ty
[13:59] <voidspace> the new machine should honour application constraints as well
[14:00] <frankban> indeed
[15:53] <CarlFK> juju deploy /home/juser/temp/charm-ubuntu/builds/ubuntu monitor - 27 of those, 25 started, 2 are State:pending
[15:54] <CarlFK> it has been like that at least 5 hours.
[16:00] <voidspace> frankban: I've added a new test for the case you suggested and made the change to explicitly pass constraints rather than the whole application spec
[16:00] <voidspace> frankban: and I'm going to land the change
[16:00] <frankban> voidspace: cool thanks
[16:00] <voidspace> frankban: thanks for your help
[16:01] <voidspace> frankban: is it the usual $$magic$$ to trigger the landing bot on that branch as far as you know?
[16:03] <voidspace> frankban: if there's no landing bot I might will have to ask you to land it, as I don't have write access to that repo
[16:06] <voidspace> frankban: it's alright, I found the magic...
[16:07] <frankban> voidspace: sorry, on call, it's :shipit: probably
[16:07] <voidspace> frankban: it is, and it's done - sorry for the noise
[16:07] <frankban> np
[16:31] <cory_fu> tvansteenburgh: I'm trying to see the delta between the latest and next-most-recent review rev of https://review.jujucharms.com/reviews/24 and it seems to include a bunch of stuff that was not specifically changed in the latest rev.  Am I missing something?
[16:33]  * tvansteenburgh looks
[16:36] <cory_fu> tvansteenburgh: nm, I was reading the diff wrong.  It's actually showing the right stuff
[16:36] <tvansteenburgh> cory_fu: can you give an example of a something that's displayed but shouldn't be? like, name a file
[16:36] <tvansteenburgh> oh okay
[16:47] <teranet> ok quick question on juju network ranges
[16:48] <teranet> I have my MAAS to use 10.5.x.x/24 but somehow now all of the sudden when I deployed juju charms those charms took 10.0.0.x IP's where do I can see and change that ?
[17:22] <marcoceppi> teranet: that's odd, do you have multiple spaces configured?
[17:24] <teranet> no not yet
[17:25] <teranet> where could I see what spaces / ranges juju uses ?
[17:25] <rick_h> teranet: it reads them from maas. You can use list-spaces to see what spaces it sees
[17:25] <rick_h> teranet: and show-machine 0 to see details about the machine and what networks it's on
[17:27] <teranet> ok that only shows what I  configured : http://paste.ubuntu.com/23634617/
[17:28] <teranet> but below you can see my charm's somehow have also 10.0.0 in use .....
[17:28] <rick_h> teranet: adjust the number of the machine to the one that your charm is deployed on
[17:28] <teranet> can that be something within the charms ? even when I deployed the yaml none had any network setups in it
[17:29] <rick_h> teranet: not really, the charms are handed a machine to run on so it's what maas has for network config and what you've done in Juju to specify deployment constraints
[17:29] <teranet> ok updated
[17:30] <rick_h> teranet: when you update the pastebin the link url changes
[17:30] <rick_h> teranet: so can't see any changes with the other url
[17:30] <teranet> http://paste.ubuntu.com/23634623/
[17:30] <teranet> ups :-) there we go
[17:33] <rick_h> teranet: does MAAS provide dhcp and is it providing dhcp on both subnets?
[17:33] <rick_h> teranet: in Juju the containers should be getting their IP addresses from the MAAS dhcp server
[17:35] <teranet> MAAs provides DHCP on the default which is 10.5.100...
[17:35] <teranet> but only on eth0
[17:35] <teranet> eth1 is reserved for public only
[20:39] <teranet> any idea ?
[23:06] <gQuigs> how do I tell juju2.0 to use a specific LXD image?
[23:06] <gQuigs> that I installed into LXD manually
[23:26] <gQuigs> or do I have no choice and I have to use simplestreams?  (the environment this is going in is completely offline, with manually syncing of everythng)