[00:52] wallyworld, should i be doing a PR against staging branch on GH? [00:52] it's a small change to the bash completion so nothing major [00:52] stokachu: what release is it for? [00:52] stokachu: propose against develop. that will get into staging automatically after each blessed CI tun [00:52] stokachu: develop is essentially 2.2 [00:53] ok cool [00:53] stokachu: if u need it in 2.1, propose against 2.1 [00:53] good point if it's for 2.1 then PR gainst 2.1 [00:53] stokachu: which will b merged in develop and then eventually staging [00:53] ok so propose against 2.1 branch and it will go into develop/staging? [00:54] stokachu: yes [00:54] anastasiamac, great, thanks [00:54] stokachu: here to help \o/ [01:09] ok lets see how this looks https://github.com/juju/juju/pull/6927 [01:09] * anastasiamac looking [01:17] anastasiamac, when you say flag do you just have to mention them and thats it? [01:17] or do i need to do anything [01:18] stokachu: I have "flagged" them by virtue of @ on github :) hipefully they'll notice and will know what to do with it ;) [01:18] anastasiamac, ok cool thanks [01:19] stokachu: ideally, we'd ove to have QA tests for this to ensure that code behaves but also that priorites are respected [01:19] love* [01:20] anastasiamac, yea maybe some expect tests would be nice [01:44] perrito666: did you test your mongo tuning work when the server rebooted? it seems the values as set in mongo.go are not sticky [01:46] I did I even upgraded [01:46] You mean the cache size one? [01:48] wallyworld, do you guys want a force push to squish additional commits into one? [01:48] anastasiamac, ^ [01:48] stokachu: many folks do that, some don't [01:48] us bzr refugees hate throwing away history [01:48] is there a preference? [01:49] depends who you ask :-) [01:49] haha [01:49] stokachu: no preference here, but history is nice \o/ [01:49] ok cool ill stick to that [01:49] world would b better place if history was remembered :D [01:49] except git discourages that :-( [01:58] stokachu: in my opinion history is good while each commit compiles [01:59] wallyworld: btw, did you see my answer to the mongo tuning? [01:59] which answer? [01:59] oh, that one [01:59] perrito666: i mean a server reboot [02:00] wallyworld: but by tuning you mean the mongo cache size? [02:00] the hugepage values are not applied again [02:00] ahh I see, that is odd [02:00] well ensure mongo is not run every agent start yo [02:00] up [02:00] wallyworld: it should [02:01] unless i tested wrong [02:01] which i could have done [02:02] wallyworld: mm, you might be right [02:02] did you test it? [02:02] enesure mongo only runs at bootstrap i am almost certain [02:02] wallyworld: I did, but I might have got confused by the syslog output [02:02] and hence the hugpage values are no reapplied [02:03] i can't see a way of adding those to sysctl.conf so will find another way [02:04] wallyworld: I believe ensuremongoserver IS called upon restart but cant be sure because its inside a convoluted network of manifold nonsense [02:04] this code looks like javascript spaghetti [02:04] EnsureMongo is called from jujud/bootstrap.go [02:04] that is only run once at bootstrap time [02:04] becaise its called by MachineAgent.initState which is passed as OpenState in machine.ManifoldsConfig [02:05] wallyworld: EnsureMongoServer [02:05] wallyworld: for reasons completely unknown to me: cmd/jujud/util/util.go: EnsureMongoServer = mongo.EnsureServer [02:05] right, called from func (c *BootstrapCommand) startMongo [02:05] wallyworld: then cmd/jujud/agent/machine.go: if err := cmdutil.EnsureMongoServer(ensureServerParams); err != nil { [02:06] wallyworld: that is eventually called by MachineAgent.ensureMongoServer [02:06] is that in 2.1? [02:07] wallyworld: ghaa, that fix is not applied to 2.1 of course, [02:07] it is though [02:07] if you look at cmd/jujud/agent/machine.go line 1352 [02:08] ok, i'll dig into it a bit [02:08] the only difference is that a fix removing the if !mongoInstalled has not been applied [02:09] right, i do not want to remove that [02:09] that check is there for a reason [02:09] wallyworld: no, it isnt [02:09] removing it would be wrong [02:09] wallyworld: its wrong [02:10] if we have already installed mongo, there's no need to go through the work of doing it again [02:10] wallyworld: that check means "if there is a service file for mongo dont make sure its there" [02:10] wallyworld: its just por wording [02:10] wallyworld: what it actually checks is that systemd/upstart file is there [02:10] if not it re-generates it [02:10] you want to re-generate it in case mongo parameters have changed [02:11] but it all installs mongod all over again etc [02:11] EnsureMongo does a lot more than just mess with conf files [02:13] wallyworld: it should be idempotent, if its not, something is effed up [02:13] is is of course. but it's unnecessary work [02:13] overhead to starting up the agent [02:14] messing with packaging etc [02:14] maybe we don't care [02:14] wallyworld: you are not restarting 1k times per second [02:15] still potentially hits repos etc [02:15] its an unnecessary optimization and, incidentally, also a bug :p [02:15] slow network would cause agent startup to hang for a bit [02:15] i disagree it's unnecessary [02:16] wallyworld: allow me to quote william on that one: show me numbers [02:16] there's a difference between applying new config and installing mongo [02:16] apt will not hit repos for installed packages [02:16] apt will just say "all this is installed" since the dependency resolution is done offline [02:17] i'll backport from develop then since it's already landed there [02:18] wallyworld: :) see, all it takes is some civiliced conversation and quoting william [02:18] i still think we should have separated cfg management from othe rthings [02:18] it's just too hard to do anything else right now [02:18] wallyworld: sure, also we should not have used mongo but we are too late to fix things done 2 years ago [02:19] well changing this behaviour wasn't done 2 years ago [02:19] ugh [02:19] wallyworld: EnsureMongo is at least 2 years old [02:19] we don't for example attempt to install over and over all of our other packages [02:19] fixing the conflicts in this branch is *awesome* [02:19] perrito666: sure ENsureMongo is 2 years old, but calling it every time unnecessarily isn't [02:20] wallyworld: we dont install other packages, juju is not installed using apt [02:20] juju install dependencies [02:20] using apt as part of bootstrap [02:20] wallyworld: perhaps we should [02:20] disagree [02:21] wallyworld: apt-get install on an already intalled package takes: [02:21] real 0m0.807s [02:21] user 0m0.768s [02:21] sys 0m0.028s [02:21] it's not just that - it's the inconsistent behaviour [02:22] we install mongo separately from the other packages, its not entirely inconsistent [02:22] some packages are reinstalled each agent start up, others aren't [02:22] anyways, looks like there's only one way forward [02:22] wallyworld: there are not reisntalled, its a no-op they are never going to be reinstalled [02:22] i didn't mean that literally [02:22] wallyworld: you are free to add an EnsureServerParams field that avoids the apt call if it makes you happy [02:23] it should be trivial and harmless [02:23] not for 2.1, i'll just stick to what was done for develop [02:23] we haven't got time to change all that at the moment [02:24] wallyworld: suit yourself, for me the apt call is free and harmless and consistent with a gazillion other idempotent behaviors and keeps mongo startup encapsulated [02:24] leverage the tools at hand, no need to re-implement checks that the package manager does for free [02:25] nothing is ever "free" :-) but will stick to that [02:25] wallyworld: we should have a discussion about marginal costs some day :p [02:25] also my eye drops just stopped making effect so I am going to sleep [02:25] ttyl [02:29] axw: remind me, do we support controllers on redhat? or just ubuntu [02:29] wallyworld: just ubuntu [02:29] ok, ta. the kernal tweaks to disable hug pages are potentially different on redhat [02:34] hug pages? [02:34] * thumper needs a hug [02:35] thumper: potentially different hug, like redhat? [02:35] :) [02:35] looks like we are disabling hugs per above :D [02:51] sigh [03:06] thumper: can you please take a look at https://github.com/juju/cmd/pull/46? [03:07] * thumper looks [03:07] axw: we don't need to do it this way... I don't think [03:07] axw: we have other places that do special output for a single value [03:07] you just don't call the format method [03:07] but write the output [03:08] thumper: we have a broken version in "model-config", which isn't honouring --output [03:08] thumper: fixed in my upcoming PR [03:08] ok [03:09] thumper: the alternative would be to expose the io.WriteCloser to the command, but then it needs to close the file. seems a bit safer/neater this way to me [03:09] * thumper nods [03:11] axw: lgtm [03:11] thumper: thanks [03:26] * thumper out... [03:34] anastasiamac and/or wallyworld: when you can, please take a look at https://github.com/juju/juju/pull/6928 [03:34] ok [03:38] axw: what was the dep change? [03:40] wallyworld: https://github.com/juju/cmd/pull/46 [03:43] lgtm, thNK [04:25] anastasiamac: what is "eda" ? [04:26] axw: Escaped Defect Analysis [04:26] anastasiamac: okey dokey. thanks [04:26] axw: means it got out into the wild, should have been caught in QA by functional test (possibly) [04:26] * axw nods [04:27] axw: QA specifically monitor bugs with this tag :) so it's a means of us flagging the bug to their attention... [04:27] for us* [04:27] anastasiamac: ah ok [06:07] Hi. I have a question regarding Cinder charm. [06:08] If i locally modify the cinder.conf through the shell and then modify config through the juju-gui [06:08] the local changes get overridden. Any workaround this? [07:14] pranav_: you may be better asking in #juju where likely to be folks with more direct experience on that issue [07:20] Anything I can do to get new regions available in GCE on 2.0.2? [07:24] axw: m looking at ur 6929 pr :) [07:26] wallyworld: doing it in parallel on both :) [07:27] if you don't what you need, an email to the juju list normally gets answers as well [07:28] blahdeblah: is the region in public clouds yaml? if so, update-clouds should do it [07:29] wallyworld: I did an upgrade-clouds, and the regions closest to us (US West & Asia East) weren't there. [07:30] blahdeblah: hmmm, it may be the publoc clouds yaml needs updating [07:32] blahdeblah: yeah, the public clouds yaml file oooks out of date to me http://streams.canonical.com/juju/public-clouds.syaml [07:33] blahdeblah: you can for now edit your own clouds.yaml file with the new regions [07:33] * blahdeblah looks for clouds.yaml [07:34] it won't be there unless you create it [07:34] you can use juju add-cloud [07:34] I've got a ~/.local/share/juju/clouds.yaml with canonistack & maas in it. [07:34] that CLI command takes a cloud name and an optional yaml file [07:35] ok, so you can copy the gce cloud info from public clouds and edit it [07:35] OK - thanks; will give that a try [07:35] put it in your local file [07:35] keep the cloud name the same - it will override the upstream [07:36] we'll haveto organise to get publoc clouds yaml updated [07:39] thanks wallyworld [07:39] i'm off to soccer soon, but let me know if you still have issues with the workaround [07:43] that seemed to work fine; much appreciated, wallyworld [07:47] yay, great [07:50] blahdeblah: i raised bug 1662449. no need to target to 2.1 since fixing the yaml will alllow 2.1 and 2.0.2 to get the latest regions with upload-clouds [07:50] Bug #1662449: public clouds missing google regions [07:51] I had it wrong; it was US West & Asia Northeast which were missing [07:51] I'll update bug === aluria` is now known as aluria [08:40] protip: reboot -h does not mean reboot --help [08:57] anastasiamac: if you're still around, here's another one: https://github.com/juju/juju/pull/6930 [08:59] axw: have soccer but m happy to look when/if m back [08:59] anastasiamac: I hope you don't stay at soccer forever... thanks :p it can wait till tomorrow [09:00] axw: \o/ soccer forever... nice :D [10:32] axw: yeah, same for shutdown -h [10:33] jam: yeah I knew that one, didn't realise reboot did the same [10:33] reboot --halt seems weird [10:34] poweroff rather [10:34] axw: I have a feeling it is the sort of 'everything is linked to the same object' [10:34] axw: good one \o/ i hope it did not cause u too much pain ;( [10:34] jam: yup. -> systemctl [10:34] anastasiamac: nah, just annoying [10:34] axw: or ultimately "busybox" :) [10:35] axw: i imagine :) [10:35] jam: can you bind an endpoint to a space after deployment? [10:36] axw: no, we don't have moving things [10:36] axw: we'd probably like to get there, but there are the risks around "not all units are in the same space" [10:37] axw: would you mind if we set up a regular "standup" like call together? I'm finding that without a team around it can be hard for me to organize my next steps sometimes. [10:37] jam: sure, no worries [10:38] jam: what time would be best for you? you're +4 right? [10:41] yeah. start-of-my-day would be good, which is around UTC 5, but I'm open for whatever time [10:41] jam: that'll work [10:42] * axw bbl === rogpeppe1 is now known as rogpeppe [11:19] axw: (I hope u r afk but) LGTM :) [11:42] anastasiamac_: thanks [11:42] axw: my pleasure \o/ awlways amazingly nice to see ur code ;) [11:44] morning all [11:45] perrito666: o/ [11:57] jam: would you stamp the backport? https://github.com/juju/juju/pull/6931 [11:58] perrito666: submitted [11:59] jam: tx [11:59] perrito666: backports only need stamps if there is significant difference... if it's exactly the same as the originally reviewed code, feel free to self-stamp :) why re-invent the wheeel and re-stamp? [12:01] perrito666 is probably worried that he'll accidentally get a tramp-stamp [12:01] I am sure there is ajoke there [12:01] but perrito666, I agree with anastasiamac_ that backports/forward ports can be self-stamped if there isn't any significant changes. With the caveat that 2.1 is in prep-for-RC mode so we should be careful what we want to put in it [12:01] but it requires for me to google [15:22] perrito666: any chance you could look at https://github.com/juju/juju/pull/6933 [15:24] jam: certainly, any chance you can jump into the outage channel on the other irc? :) need a second opinion [15:25] outage? [15:49] Was credentials support added for lxd in the latest beta? It has started prompting me for a credential when working with a shared lxd controller where it did not previously, and I have no credential to supply it with. [15:54] jam: ship it [16:04] cory_fu: axw was the one making some of those changes. I'm not sure how it interacts with existing LXD deployments. I think there is an upgrade step to fix that sort of thing, but that would be a 2.0=>2.1x upgrade [16:04] vs a 2.1b4 => 2.1b5 [16:09] jam: I don't understand. This is a freshly bootstrapped 2.1b5 localhost controller. I used add-user + grant, then registered the controller with another juju and tried to add model from there and it said "no controller specified." This worked in the last beta. I could add a credential for the controller like I have to do for aws, etc, but I don't have a credential to add [16:29] jam, axw: So, I tried upgrading a juju 2.0.2 to the latest beta and then registering the controller, and I got a new error about an invalid credential: http://pastebin.ubuntu.com/23948469/ [16:34] cory_fu: sounds like a bug we need to address in 2.1b5, can you submit one and we'll poke axw to look into it [16:34] Sure [16:34] cory_fu: I know we were doing bad things with credentials and LXD before, it looks like fixing credentials may have broken multi-user [16:35] jam: I'm currently testing whether how I bootstrapped it has an effect. I don't recall if I bootstrapped it as lxd or localhost. Testing with localhost to be sure [16:54] jam, axw: Filed https://bugs.launchpad.net/juju/+bug/1662587 Thanks [16:54] Bug #1662587: 2.1beta5 breaks lxd shared controller [17:22] morning juju-dev (almost forgot!) [17:23] morning redir [17:24] redir: morning [17:24] :) [17:26] Bug #1662599 opened: Change maas api and password controller in model already created === frankban is now known as frankban|afk [18:06] hey Ill step out for a moment and return later, cheers === frankban|afk is now known as frankban === frankban is now known as frankban|afk [19:26] intermittent internet today [19:26] lots of rains [19:26] and winds [19:46] easy PR: https://github.com/juju/juju/pull/6935 [20:09] redir: ship it [20:19] tx [20:19] perrito666: [20:19] wallyworld: yt? [20:48] me steps away shortly to run a couple errands. [21:50] cory_fu! i'm so l33t. i shared a lxd controller and added a localhost stanza to the credentials.yaml on the remote user (jenkins in your case). it needs the contents of server.crt, client.crt, and client.key from the remote lxd host. then a set-default-credential for jenkins, and bingo bango, add-model for days. [21:50] i'll expand on the workaround in https://bugs.launchpad.net/juju/+bug/1662587, but wanted to let you know in case you were stuck. [21:50] Bug #1662587: 2.1beta5 breaks lxd shared controller [21:51] kwmonroe: Awesome! [21:55] kwmonroe: Is that with beta5 on both the sharer and sharee? [21:55] you made up some of those words cory_fu [21:55] yes, b5 all around [21:55] :) Ok [21:56] perrito666, you on-call reviewer? [21:57] cory_fu, ouch that bug [22:00] balloons: no, but I am keen to review things if you need [22:00] perrito666, ohh, well then; https://github.com/juju/juju/pull/6936 [22:01] ugh, who decided that using dashes as the separator between items that have dashes in them was a good idea? [22:01] not sure how much you've played around with snaps, so this is your chance to vet [22:02] balloons: build-packages: [gcc] ? [22:03] balloons: I have snapped things, go things to be accurate :) [22:03] perrito666, that was requested by snapcraft upstream for there builder. It's no-change from the previou [22:04] k then, lgtm, let me stamp it [22:04] perrito666, mind trying out a build; I'm keen to make sure it's easy for developers to snap up there local repo [22:04] cory_fu: bug 1662587 updated if you need the steps.. [22:04] Bug #1662587: 2.1beta5 breaks lxd shared controller [22:05] not sure how much you've tried to to that. snap, and then push to the store [22:05] balloons: let me see if this computer has the snapcraft things [22:05] perrito666, ahh, no worries if not [22:06] balloons: building [22:07] kwmonroe: Thanks. Does set-default-credential actually work with beta5 on an imported controller? [22:07] $ juju set-default-credential localhost hamburgalar [22:07] Default credential for localhost set to "hamburgalar". [22:08] yeah, looks to work for me.. subsequent "juju add-model blah" don't need a --credential flag [22:09] $ juju add-model see-cory-fu [22:09] Uploading credential 'localhost/cwr-ci/hamburgalar' to controller [22:09] Added 'see-cory-fu' model on localhost/localhost with credential 'hamburgalar' for user 'cwr-ci' [22:10] and now i need to google how to spell hamburgalar.. i think it probably hamburgler [22:10] i'm sure that's not a special case in the juju code though, so you should be fine. [22:11] kwmonroe: Ok, so they fixed that, so that's nice. Not sure how we'll handle the transition, though [22:12] kwmonroe: Interesting. Doing `juju add-credential localhost` in 2.0.2 creates a cred with "auth-type: empty" and no other props, like we tried to create before [22:23] it's hamburglar [22:27] balloons: interesting, I have time to take a shower while snap builds juju [22:27] actually I could take two since it has not finished yet and I am already back [22:34] perrito666, :p [22:37] kwmonroe: Good to know [22:37] :) [23:13] wallyworld, perrito666, anastasiamac_, abentley, sinzui, https://github.com/juju/juju/pull/6936 is the PR. I have pushed 2.1-beta5 to the beta channel, and 2.0.2 to the stable channel. Check them out. snap install juju --classic and snap install juju --classic --beta [23:13] they should all "just work" as you expect [23:14] thank you balloons [23:14] awesome [23:15] wallyworld, you'll note btw it uses your local tree by default, but there's a few options to specify tags, commits or branches as well as location. Should make dev builds easy [23:15] ok, i'll check it out