[01:23] <wallyworld> thumper: here's that PR to get the final caas things ready for 2.4. pretty please :-) https://github.com/juju/juju/pull/8784
[01:23]  * thumper looks
[01:50] <thumper> wallyworld: just a few small things
[01:51] <wallyworld> tyvm
[01:51] <thumper> I kept getting distracted while reviewing
[01:51] <thumper> email etc.
[01:51] <wallyworld> i also have a feature test to fix
[01:51] <wallyworld> no rush i am waiting for another pr to land first
[01:51] <wallyworld> before i can land this
[03:24] <thumper> wallyworld: ping
[03:25] <wallyworld> yo
[03:25] <thumper> hangout again?
[03:25] <wallyworld> sure
[04:55] <wallyworld> thumper: small one? https://github.com/juju/os/pull/2
[04:56] <wallyworld> needed for caas series checking to be able to give nice errors deploying a caas charm to an iaas model
[05:36] <veebers> wallyworld: just sorting out a merge conflict and will be proposing the tomb v1 -> v2 PR
[05:42] <veebers> wallyworld: https://github.com/juju/juju/pull/8785 just noticed it could do with a commit squash, as I've merged develop in there a couple times too.
[06:09] <wallyworld> veebers: ok, looking
[06:10] <vino> wallyworld: i want u to take a look at mine as well. Made few commits
[06:10] <wallyworld> ok
[06:24] <wallyworld> vino: comments left. main issue is there are mssing tests for application tools methods
[06:24] <wallyworld> plus we don't need any tests for the CLI bit as there's nothing to test really
[06:25] <vino> wallyworld: yes i am writing that now in application_test.go
[06:25] <wallyworld> great!
[06:25] <wallyworld> almost there
[06:33] <vino> Yes. Wallyworld. I verified that with dump-db command as well. No IAAS and CAAS difference.
[06:33] <vino> i will revert the chnages made in dump-db_test
[06:42] <wallyworld> ty
[06:54] <wallyworld> veebers: reviewed, a mighty effort. i have aquestion, it's in the review comment
[07:42] <veebers> wallyworld: wow, I can't believe how many deletemes slipped through muy intial scan of the diff :-\
[09:32] <stickupkid> manadart: can I get a code review of this PR please https://github.com/juju/juju/pull/8787
[09:51] <manadart> stickupkid: Ja.
[10:16] <manadart> stickupkid: Reviewed.
[10:17] <stickupkid> manadart: thanks
[11:40] <stickupkid> manadart: i've updated the PR, we require a few hoops to jump through to now get the bridgeName - not sure if it's 100% right, but works for bionic on first try
[11:40] <stickupkid> https://github.com/juju/juju/pull/8787
[11:40] <manadart> stickupkid: Looking.
[11:52] <elox> bdx: elox -> erik_lonroth
[12:04] <manadart> stickupkid: Approved; couple of minor suggestions.
[12:09] <stickupkid> manadart: nice, i'll fix those, before merging
[14:00] <bissa> Is there a way to specify a subnet when using juju to bootstrap a controller?
[14:07] <pmatulis> bissa, MAAS and AWS backing clouds support "Juju network spaces"
[14:10] <scoobitywoops> @pmatulis doesn't that require a controller to already be up?
[14:14] <pmatulis> scoobitywoops, no
[14:15] <scoobitywoops> juju add-space devqa 10.0.10.0/24
[14:15] <scoobitywoops> ERROR cannot connect to the API server: No controllers registered.
[14:18] <pmatulis> scoobitywoops, now i see what you mean. what *i* meant was that you can apply a space during the creation of a controller
[14:18] <pmatulis> of course, almost all commands require a controller
[14:20] <hml> bissa: what cloud are you using?
[14:20] <bissa> aws
[14:20] <scoobitywoops> I'm working with bissa, we're trying to build the controller in a specific vpc and subnet
[14:21] <scoobitywoops> vpc is fine, but can't get it to stick to a subnet
[14:21] <scoobitywoops> tried --to subnet= but that didn't work
[14:58] <chquark> hello all
[14:58] <chquark> I need a bit of help in juju
[14:58] <chquark> I was following this guide
[14:58] <chquark> https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/latest/install-maas.html
[14:59] <chquark> while deploying all of the nodes on Virtualbox
[14:59] <chquark> as a test environment
[15:01] <chquark> user@user:~/.local/share$ sudo juju bootstrap mymaas maas-cloud-controller --constraints "mem=1G"
[15:01] <chquark> [sudo] password for user:
[15:01] <chquark> Creating Juju controller "maas-cloud-controller" on mymaas Looking for packaged Juju agent version 2.3.8 for amd64 No packaged binary found, preparing local Juju agent binary
[15:01] <chquark> Launching controller instance(s) on mymaas...ERROR failed to bootstrap model: cannot start bootstrap instance in any availability zone (default, Test)
[15:02] <chquark> ^^ that is the error i get, and im at my wits end.
[15:02] <hml> chquark: are you running with —debug ?
[15:03] <chquark> sorry Iḿ not that experienced with juju.
[15:03] <chquark> juju debug-log
[15:03] <chquark> you mean this ?
[15:03] <hml> chquark: no
[15:04] <hml> chquark: you can add a —debug flag (dash dash) to bootstrap for additional data
[15:04] <chquark> got it
[15:07] <chquark> https://pastebin.com/RuGhfVrV
[15:08] <hml> chquark: juju isn’t finding a machine to use to match the constrainsts given:  line 36
[15:09] <hml> chquark: do you want juju to pick a specifc machine?  you can bootstrap specifying a tag as a constraint instead
[15:10] <hml> chquark: https://docs.jujucharms.com/2.3/en/reference-constraints
[15:10] <chquark> well I have 2 VMś
[15:11] <chquark> one for MAAS and another for JUJU
[15:11] <chquark> so which machine is it trying to get ?
[15:12] <hml> chquark:it couldn’t find a machine based on the 1G mem constraint -
[15:12] <hml> chquark: try bootstraping without the mem piece
[15:13] <hml> chquark: you’ll need additional VMs, with the current setup, you’ll be able to bootstrap, but there won’t be any machines available to deploy a charm
[15:13] <chquark> I have also deployed 2 Nodes on VM, let me try it again without any contraints
[15:16] <chquark> https://pastebin.com/YWEGMvZg
[15:17] <chquark> https://i.stack.imgur.com/HSNAp.png
[15:19] <hml> chquark: how much memory do the nodes commissioned by MAAS have?
[15:20] <chquark> 1GB each
[15:22] <chquark> https://imgur.com/a/GAQQnHt
[15:23] <hml> chquark: juju usually looks for nodes with a min mem size of 4G… i  wonder why juju didn’t find the commissioned node when constraints were 1G
[15:24] <hml> chquark: the min controller requirements are 2G:  https://docs.jujucharms.com/2.3/en/controllers
[15:24] <hml> chquark: though the message you’re getting doesn’t indicated that.. juju is still trying with only 1G
[15:25] <chquark> is this not reffering to the Juju server ?
[15:25] <hml> chquark: what do you mean by juju server?
[15:27] <chquark> https://imgur.com/tC6vITo
[15:28] <chquark> the Nodes have 1G ram, but MAAS and JUJU have 2G ram..
[15:29] <hml> chquark:  in the example, node os-juju01.maas will be used as the juju controller
[15:29] <hml> chquark: per your screen shots… is the Juju VM commissioned in maas?
[15:30] <chquark> no Juju vm not commisioned in maas
[15:31] <chquark> so iḿ to understand that i must add it.. let me do that right now..
[15:31] <hml> chquark: per the example, there are 5 machines commissioned in maas for juju to use,
[15:32] <hml> one will be the juju controller, the others are for charms to be deployed to
[15:33] <chquark> ah, crap i see where my mistake can be..
[15:33] <hml> chquark: if you add the juju tag to node os-juju01.maas … then you can bootstrap with the tag as a constraint….
[15:34] <chquark> yes i understand, i did not add the juju node, and had manually deployed the OS..
[15:35] <chquark> so think i will have to redeploy that node again..
[15:38] <hml> chquark: if you have the nodes commissioned in maas, and bootstrap juju with the maas “cloud” - juju will do the work on those nodes for you.
[15:53] <chquark> @hml, thank you for your help. I will get back to you once i have commissioned the juju in maas :)
[17:50] <TheAbsentOne> erik_lonroth: https://github.com/Ciberth/MP-appendix-a/blob/master/appendixA.md this was the guide I was working on btw!
[19:29] <TheAbsentOne> If people are btw interested in reading my master thesis, I would love to receive feedback on wrong or unclear things. I have one more week to finish it so I'm trying to wrap things up. Ping me here if I'm here or on github/twitter: Ciberth if you want to receive the pdf!
[19:29] <TheAbsentOne> The title is: management of polyglot persistent integrations with virtual administrators (hence the generic database use case in juju!)
[20:39] <veebers> Morning o/
[21:15] <thumper> morning
[21:23] <wallyworld> thumper: small review? https://github.com/juju/os/pull/2 and there's a juju one that depends on it https://github.com/juju/juju/pull/8788
[21:23] <thumper> ack
[21:23] <wallyworld> polishing the user experience before release
[21:23]  * thumper nods
[21:24] <wallyworld> it used have a have a crap message
[21:29] <veebers> wallyworld: FYI I addressed your comments on PR: https://github.com/juju/juju/pull/8785
[21:30] <wallyworld> veebers: yeah, just looking :-) found at least one more case of Stop() doing the err != tomb.ErrStillAlive thing
[21:30] <wallyworld> in ping batcher
[21:31] <wallyworld> i think there's 7 cases
[21:31] <veebers> ah man, dropped the ball a couple times on this PR. just too eager to push it up. WIll fix
[21:31] <veebers> ah I know why, faulty grep
[21:31] <wallyworld> no worries, it was a monster
[21:32] <wallyworld> veebers: also, i do think we replace donewhendying() with just <-w.Tomb.Dying
[21:32] <wallyworld> more explicit and less overhead, no need for a func now
[21:32] <veebers> wallyworld: agreed, making it so now
[21:32] <wallyworld> awesome sauce
[21:39] <veebers> wallyworld: have pushed up the changes
[21:46] <wallyworld> veebers: looking
[21:48] <wallyworld> veebers: lgtm! also, don't forget to regenerate dependemcies.tsv before landing
[21:48] <wallyworld> and push that change
[21:48] <wallyworld> ensure that tomb.v1 is missing
[21:49] <veebers> wallyworld: tomb.v1 is needed for /juju/worker.v1 :_|
[21:49] <wallyworld> oh bollocks
[21:49] <wallyworld> do we have w worker.v2
[21:49] <wallyworld> i guess that's next
[21:50] <veebers> wallyworld: indeed, has a target on it's back :-) Diff of godeps -t $(go list ./...) and deps.tsv is no changes
[21:51] <bdx> hey guys
[21:51] <bdx> say my maas controller ip changes
[21:51] <wallyworld> thumper: we couldn't think of a different name for the OS (also called Distro in the charmstore). discussed with john and jaas guys. ideally "Kubernetes" would be the OS and we'd have "1.8" or whatever for series but the versions change too quickly for that to be managable
[21:52] <bdx> is there a way I can update the maas cloud credentials on the controller?
[21:52] <bdx> specifically the endpoint
[21:52] <wallyworld> not easily (yet) sadly
[21:52] <wallyworld> the only way i know is to update mongo directly - shut down the controller agent(s) first
[21:53] <wallyworld> it's something being worked on this cycle
[21:55] <wallyworld> thumper: if we think of something better, we can change it as the charm side of things is still under development etc. fresh ideas welcome :-)
[21:55] <bdx> wallyworld: thanks
[21:56] <wallyworld> bdx: let us know if you need help etc. it's a big gap we know we need to fix
[21:57] <bdx> wallyworld: thanks, I think its going to be easier for me to just give my new maas server the ip of the old maas server
[21:57] <wallyworld> ok
[21:57] <thumper> wallyworld: sure
[21:58] <bdx> some ability to modify a cloud definition via `update-clouds` or other means would be great though
[21:59] <bdx> just super actually
[21:59] <bdx> I'm sure more people will hit this as they upgrade
[21:59] <bdx> as maas 2.4 is bionic only
[22:03] <bdx> users will need to add a new controller and switch to it when they upgrade
[22:08] <wallyworld> bdx: yeah, controller clouds and credentials both need to be managed better. the first thing being done is having juju better manage credentials which expire or become invalid. at the moment, things don't go well when that happens
[22:09] <wallyworld> especially on a jaas controller with lots of models
[22:13] <bdx> I can only imagine
[22:16] <veebers> wallyworld: ah, "if err := pb.tomb.Err(); err != tomb.ErrStillAlive {" is needed for PingBatcher Stop(), that's something you pointed out to me but I'm not 100% certain why it's needed
[22:17] <wallyworld> is that the only place?
[22:18] <veebers> it seems it, will re-run tests to confirm
[22:19] <veebers> yeah looks like it. pushing fix now, PR will have a full unit test run
[23:04] <veebers> wallyworld: yay merged :-)
[23:04] <wallyworld> awesome. i would still like to look into why ping batcher needed that change
[23:06] <veebers> wallyworld: indeed, will look into it when I get a moment
[23:09] <wallyworld> veebers: we're moving to pubsub anyway soon so may not be worth the effort
[23:10] <veebers> wallyworld: ack ok
[23:10] <wallyworld> veebers: i suspect it's because someting is calling Stop() twice
[23:11] <veebers> yeah I would suspect so too