[00:21] mgz: are you about? CI won't merge my critical fix, looks like because we have turned on Windows unit test gating but still have a bunch of failing Windows unit tests ... [00:22] wallyworld: ^^ I'd rather not spend all my time fixing Windows unit tests right at this point in time [00:23] axw: agreed, i'm not sure why gating was turned on before tests passed [00:24] we may have to skip them depending on how many there are [02:18] axw: did i recall perhaps incorrectly that bug 1598049 had been sorted out in some form? === mup_ is now known as mup [02:20] wallyworld: I *think* that's sorted out by perrito666's patch, which I merged into my branch and landed [02:20] but I don't have windows handy to verify [02:20] axw: yeah, that rings a bell, that's what i thought had happened [02:20] i might mark as fix committed [02:35] axw: this updates the juju/rfc repo with the changes to remove the custom tls package https://github.com/juju/rfc/pull/1 [02:37] wallyworld: you just did a straight copy of changes from juju/juju/standards right? [02:37] apart from txt file of course [02:37] axw: yep, and i could only see that one change [02:37] client.go plus deletes [02:37] wallyworld: cool. LGTM, thanks [02:38] ta [02:38] wallyworld: I'd like to move that rfc5424 package to live under juju/syslog at some point [02:38] lumping all standards together is a bit odd, since there's many standards for wildly different things [02:39] yeah, could do. although i thik the intent was to gather all rfc things there [02:39] wallyworld: I know that was the intent, it just seems very strange to me. maybe just me... [02:40] can easily be done, let's discuss with tech board or whatever [02:40] sure, no rush anyway [02:55] axw: and here's the juju/juju change http://reviews.vapour.ws/r/5218/ (not that it can land, sigh) [02:57] wallyworld: LGTM [02:57] ta [04:03] Hi axw, you have a moment to help me out. I'm attempting to generate some certs that I can use with the log forwarding feature and a rsyslog sink (this is for testing the feature) [04:04] axw I can't seem to generate a cert that juju is happy with, it complains about there not being any IP SANs, I'm sure I'm generating the certs correctly [04:06] veebers: what are you using for "syslog-host" config? [04:07] axw syslog-host: 10.194.140.165:10514 [04:07] axw I'm using certtool to gen the certs (creating a ca cert and some client/server certs too) [04:08] veebers: try using the hostname that you used when generating the cert [04:08] rather than IP [04:15] axw: I don't have any dns setup for this as I've just bootstrapped and deployed rsyslog, added certs and config then exposed it for the rsyslog sink. Are you suggesting that I need dns settings for that machine for this to work? [04:16] veebers: either you need DNS, or when you generate the cert you need to include an IP SAN [04:17] axw: the IP SAN is that for both the ca cert and the client/server cert or just one of them? I'm pretty sure I'm setting that for the ca cert [04:18] veebers: for the server cert at least, not sure how client cert verification works [04:20] axw: hmm so what I'm doing at the moment is creating a ca cert, then I'm creating a cert that I sign with the ca cert and using that on the rsyslog server as well as the juju config. For the server should I create a cert and use that + ca cert and then a different cert for the client? [04:24] veebers: for a more realistic setup, yes. I'd stick with the one cert to start with until you get that working, and expand, though. [04:24] Probably worth mentioning; the certs that I'm generating work fine when using just rsyslog (i.e. 2 machines one sending to the other) [04:25] veebers: interesting. that would seem to imply they're not doing strict host verification [04:25] axw: ok, right now I'll try adding the ip address to the client cert (as opposed to the ca cert) too and see if I get any joy [04:26] axw: that thought did cross my mind, could be the way I have it configured [04:26] i.e. Using the config from the top answer here: http://serverfault.com/questions/666827/using-rsyslog-with-tls-without-generating-a-self-signed-cert [04:43] axw: huh, I think that's working now. Is there an action I can do that would create a log that would be forwarded? [04:44] veebers: anything and everything that goes over the API [04:45] veebers: you shouldn't need to do anything really, logs just happen [04:46] axw: I'm wanting something reproduce-able so I can check that it works now as well as incorporate it into the ci test :-) [04:47] I saw a large influx of messages just at the end of the bootstrap but nothing since, want to force some message so I can confirm all is wired up correctly [04:47] veebers: fair enough. umm. I'm not sure what's a good candidate for a useful log message. you can just do "juju status", and you should expect to see an apiserver log message [04:47] that should have the word "FullStatus" in it [04:50] axw: Hmm, 'juju status' doesn't change anything in either the rsyslog sync or the logs in /var/log/juju/machine-0.log (on the newly bootstrapped machine) although there seems to be an error in the last log: http://pastebin.ubuntu.com/19050127/ [04:51] veebers: dunno what that's about. I think you won't get the log message unless you're at DEBUG level. I'll see if there are anyt interesting INFO messages [04:52] although, I think we default to WARNING? [04:54] I'm not sure about the default logging level, I don't mind changing it for now or during the test assuming that's valid test cover [04:57] veebers: I think it's going to be necessary, at least until we change the default to INFO (which I think there was agreement upon in London) [04:57] veebers: if you're at INFO level, you should see "API connection from " whenever a client connects [04:58] veebers: so you could just run "juju status" and look for that [04:58] axw: sweet, so changing log level is as easy as: juju set-model-config logging-config="=INFO" -m controller ? [04:58] veebers: yup [04:58] sweet cheers [04:59] axw: wow ok, so doing that and then a status floods the log with: http://pastebin.ubuntu.com/19050776/ [04:59] over and over again [05:00] I just killed the controller as it was pegging my system (jujud) [05:03] veebers: huh :/ [05:03] wallyworld: ^^ there's probably a log forwarding loop [05:04] awesome [05:05] hmmm, i think i saw a bug last week with that outout [05:09] veebers: axw: this seems to be the same thing https://bugs.launchpad.net/juju-core/+bug/1599779 [05:09] Bug #1599779: Very high CPU usage from 'creating cloud image metadata storage' emitted in debug log every second [05:09] not sure that it's log forward related [05:10] ah yes, I think this is the same issue that jam mentioned to me during the sprint - because of how we're using "ForModel" internally in state [05:11] wallyworld: that looks like what I saw, but seems it was more than once a second. /var/log/syslog on the controller was flooded [05:12] hmmm, maybe the log forward worker is not marking logs as sent, so it just keeps sending the same thing, not sure [05:13] axw, thanks for you help. At any rate I was able to get something working. I'll look at using dns in the certs and how we might do that under a test environment [05:13] veebers: no worries [08:56] Bug #1600722 opened: MachineSuite.TestHostedModelWorkers is unreliable

[09:02] frobware: babbageclunk: be at standup in 5 minutes or so [09:09] dooferlad: standup today? [09:12] wallyworld: first of many: http://reviews.vapour.ws/r/5219/ [09:12] ok [09:15] axw: fyi i've removed the controller model check - just get the controller uuid directly now, still getting tests to pass in my branch [09:15] wallyworld: great, thanks [09:23] axw: lgtm, hopefully we can land stuff soon [09:24] wallyworld: ta. I've got another one coming with changes how we pass timeouts to MAAS and the bootstrap-state jujud code [09:24] ok, may be afk for a fried time [09:24] brief [09:24] lol [09:24] axw, wallyworld: is this a fix for access key issue? [09:25] urulama: authorized-keys issue? [09:25] axw, wallyworld: and good evening :) [09:25] axw: yes, sorry [09:25] urulama: yeah [09:25] but the landing bot is preventing landings as it wants all windows tests to pass [09:27] geat :-/ [09:36] voidspace: want to do 1:1? [09:38] mgz: you around? can you revert the changes for windows tests so that beta12 actually becomes useful (like be able to deploy an application) [09:41] wallyworld, axw: do you know what the status of this one is? https://bugs.launchpad.net/juju-core/+bug/1593828 [09:41] Bug #1593828: cannot assign unit E11000 duplicate key error collection: juju.txns.stash

[09:43] urulama: no clue, sorry [09:44] frobware: sorry, my wife got back from dropping off her dad at the airport and I went to talk to her [09:44] frobware: sure, can do 1:1 [09:46] voidspace: in the ho [09:51] urulama: I'm working on it - it's a bug in mgo. There's a PR to fix it, I've had it reviewed and am waiting to get it merged. [09:52] urulama: once it's merged into the v2 branch I can start updating the mgo version in the various dependencies.tsv files. [09:53] babbageclunk: thanks ... any estimation when it might land? it's annoyingly consistent when trying to stress test the controller how many machines and units it can handle :) [09:53] (annoyingly consistent at failing that is) [09:57] urulama: Hopefully merged into mgo today (depending on reviewer time) - then there are 11 packages to get updated, so that might not get into juju/juju (at the end of the dependency chain) until tomorrow sometime. [09:58] urulama: Are you using beta packages or source? It should be in the beta getting cut this week. [09:58] babbageclunk: cool, thanks. also, it looks like tests are failing, which might be an issue to land it as well :) https://github.com/go-mgo/mgo/pull/291 [09:59] urulama: Yeah - that's an occasional failure in the mgo test suite. :( [10:00] babbageclunk: using source, will have an eye on when this lands [10:00] urulama: not anything to do with my change but I'm going to try to sort it out, it's bitten me twice now. [10:01] urulama: ok - I'll put an update on the bug now and keep you updated when there's movement [10:08] frobware, one for your list - https://bugs.launchpad.net/juju-core/+bug/1600546 [10:09] Bug #1600546: lxd subnet setup by juju will interfere with openstack instance traffic

[10:11] jamespage: ack & thanks [10:12] well lathiat can take the credit for finding that one :-) [10:17] Ugh, I just realised I'll need to do a topological sort of the transitive closure of packages that depend on mgo. [10:37] babbageclunk: thanks (and auch, on the last one) [10:37] urulama: :) [11:21] urulama: sorry, which tests? [11:21] oh, it's the whole do we want gating or not thing [11:21] yes [11:21] well, there's a reason I pushed back on adding gating here, but... we *were* asked to [11:21] ok [11:22] urulama: there's actually a fun bug that circumvents the gate [11:22] lol [11:22] urulama: but I will disable the windows part if we have general agreement [11:23] i mean, critical bug fixes can't land [11:23] we can wait for Torsten to be up in 2h ... [11:23] urulama: more a question for cherylj/alexisb [11:23] but you+ian will do [11:23] test regressions generally are critical bugs [11:24] agree [11:24] urulama: anyway, I'll fix the bug in the script and remove windows from the list of jobs for now [11:25] mgz: ok, thanks [11:26] urulama: done [11:26] ty ... now i hope Andrew's branches land soon :) [11:26] you can retrigger if it's approved [11:27] I doubt he'd mind [11:29] mgz: done, let's see if tests pass now :) [11:31] jam: gah, so there are a couple of cycles in the dependencies: juju-romulus and charmstore-charmrepo. How do you think I should handle those? [11:32] macgreagoir: standup? [11:32] rogpeppe, ashipika: ^ see comment from babbageclunk [11:32] babbageclunk: kill romulus [11:32] LOL [11:33] mgz: very classical [11:34] mgz: et tu? [11:34] urulama, mgz, babbageclunk: the proposed solution was to integrate romulus into juju core.. which is on our todo list.. [11:35] kill, integrate, much the same [11:35] mgz: there's a certain Julius C. that would disagree :D [11:36] we're one sprint in Rome short of a Remus.. then we'd have a classical duel on our hands :) [11:43] mgz: thanks, https://github.com/juju/juju/pull/5772 landed [11:44] urulama: ace [11:44] ashipika: Ok, that's the long-term solution, but how should I update mgo in the meantime? (Trying to think it through but it's making my head hurt.) [11:45] babbageclunk: update the juju-core dependency first, merge, update the romulus dependency second (it depends on the core), merge.. i guess [11:46] ashipika: And it doesn't matter that the dependencies will conflict? [11:47] ashipika: does godeps handle that already? [11:47] babbageclunk: hmmm.. i think it should all work out.. i hope.. [11:47] ashipika: I guess I can just try it! Thx [11:48] babbageclunk: good luck.. ping me if it doesn't work [11:49] ashipika: It should be ok, since the bugfix doesn't change any interfaces. [11:49] ashipika: thanks, will do! [11:52] mgz: hm, so how come that branch from Andrew got merged, but then CI stated it's bad (at juju.fail) and then if you try it, it works? (/me just tries to understand what failed and why :D) [11:54] urulama: hm, I guess I screwed something up [11:55] oh, there's a trailing backslash all the way over there >_< [11:56] babbageclunk: does this mean that you already have your fix landed in mgo? [11:59] welp. fixed, good thing the branch had in fact already passed. [12:05] babbageclunk: what specific problem are you having? [12:08] urulama: No, just getting ready for the next bit. [12:09] rogpeppe: nothing yet - just trying to decide what order to update the dependencies when it's time to. [12:09] babbageclunk: note that the cyclic dependencies from charmstore<->charmrepo are only because charmrepo uses charmstore for its tests [12:10] rogpeppe: ah, ok - that is a lot less worrying. [12:10] babbageclunk: FWIW i think it's a mistake that it should do so and i think i've worked out what the right answer is, but it'll be a while before we get around to fixing that [12:11] rogpeppe: but if the tests pass then it should be ok, anyway. [12:11] babbageclunk: yup [12:13] rogpeppe: Thinking it through a bit more I was worrying too much - it's not like there'll be two versions of the code in memory, it just determines which version godeps checks out. Right? [12:13] babbageclunk: right [12:14] babbageclunk: you'll need to choose one version for all deps [12:14] babbageclunk: i usually use the newest version of all deps if in doubt [12:14] rogpeppe: yeah, that makes sense [12:14] babbageclunk: the -N flag to godeps can be useful too [12:15] babbageclunk: for coming up with a coherent "latest tested" set of deps from several projects' dependencies.tsv files [12:15] rogpeppe: ok, will use that. Thanks! [13:27] babbageclunk: I would think that neither romulus or charmrepo expose mgo as part of their interface. [13:27] as long as they aren't returning an mgo.Doc or something like that, we should be ok [13:27] (mgo.D/B) [13:28] babbageclunk: I'm in favor of updating deps, I'd just mention that if we aren't on the latest *today*, there there is probably a reason, and I don't want to dump all of that on you. [13:28] babbageclunk: they need your mgo fix more than they need newest of all other deps [13:42] Hi everyone, what is the equivalent command for $ juju set-constraints tags=controller in Juju2.0 [13:53] junaidali: set-model-constraints (http://pastebin.ubuntu.com/19079305/) [14:09] thanks frobware [14:11] jam: good point, I'll make sure that I'm only updating deps (other than mgo) when they're on the latest. [16:09] Bug #1600600 changed: Docs are incorrect for Azure bootstrap [16:12] babbageclunk: frobware: dooferlad: firefox crash! omw [16:24] Bug #1600600 opened: Docs are incorrect for Azure bootstrap [16:26] frobware: are you going to mid-cycle? [16:26] voidspace: nope [16:27] Bug #1600600 changed: Docs are incorrect for Azure bootstrap [16:27] frobware: do you know anyone from the UK who is? [16:27] voidspace: and from juju core? [16:28] frobware: I left my boots behind in the US - so if I can get them shipped to someone in the US going to the mid-cycle and get someone from the UK to bring them back [16:28] frobware: then it will be cheaper than getting them shipped to the UK [16:28] frobware: anyone from the UK willing to do me a favour... :-) [16:28] frobware: but I have no idea who's going [17:09] Bug #1600600 opened: Docs are incorrect for Azure bootstrap [17:12] Bug #1600600 changed: Docs are incorrect for Azure bootstrap [17:30] Bug #1600600 opened: Docs are incorrect for Azure bootstrap [17:32] anyone got something they want to land and doesn't mind being a guinea pig? [17:37] dooferlad: ping [18:56] mgz: or balloons: did you come up with another solution for the bash completion problem? [18:57] mgz: or balloons: I had the wrong target on Friday, it is cleaned up to this: https://bugs.launchpad.net/juju-core/+bug/1600257 but balloons mentioned there might be a "better" way to solve that problem. [18:57] Bug #1600257: The tab completion on juju yields KeyError: 'services'

[19:01] mbruzek: I do wonder if we want a wrapper script like juju-version rather than a symlink, I'm not sure how nicely the bash completion mechanism plays with that [19:01] does it avoid registering completions twice if the same script is executed twice under different names? [19:01] mgz: OK but I believe the issue was how to not collide with juju1 bash completion [19:01] is there a better way of auto-loading for aliases? [19:02] mbruzek: that is an issue, but we also need to update the juju 1.25 packaging, and own both parts [19:02] mgz in my testing the symbolic link worked and I was not getting double completions, but I will admit my testing was incomplete [19:03] mbruzek: so, that's the jist of my code review questions [19:04] mgz: OK I will read up on bash completion aliases and see what I can find. If you or balloons have a different solution please let me know to stand down [21:10] do we have anyone still online on the networking side [21:10] frobware, voidspace possible?? [21:11] alexisb: if we're quick... [21:12] frobware, was just recreating this bug: https://bugs.launchpad.net/juju-core/+bug/1516150 [21:12] Bug #1516150: LXC containers getting HA VIP addresses after reboot

[21:12] and when looking at the code paths for filtering ip address I found this fucntion: [21:12] filterLXCAddresses [21:12] in : juju/juju/network/network.go [21:13] which seems rather useless given /etc/default/lxc-net doesnt exits anymore, right?? [21:13] frobware, this is not urgent I am just curious [21:13] if I should open a bug [21:14] alexisb: jam recently landed a change for filtering lxd bridge addresses [21:14] ah, ok I iwll look at those [21:14] thanks [21:15] alexisb: http://reviews.vapour.ws/r/4478/ [21:16] alexisb: if there's nothing else then it's EOD for me. I only popped in to turn off some of my machines... [21:16] frobware, nope, I will catch you tomorrow, thanks! [21:16] sorry for the intrusion [21:16] np [21:24] Bug #1602010 opened: juju status doens't display proper error when machine fails [21:46] does anyone know how I can set this? https://github.com/juju/juju/search?utf8=%E2%9C%93&q=test-mode%3A+true [21:47] I need to be able to set that variable in 2.x [21:47] but since I don't have an environments.yaml to put it in ... [21:47] test-mode:true is what I am trying to set === urulama is now known as urulama|__ === alexisb is now known as alexisb-afk [23:22] Bug #1602032 opened: Add machine and core count to 'models' output [23:45] wallyworld: can you explain your change for bug 1599905 to me? [23:45] Bug #1599905: rfc5424 standard has a non-free license [23:49] wallyworld: http://reviews.vapour.ws/r/5221/ [23:52] Bug #1602034 opened: 'ERROR connecting with bootstrap config' for status on destroyed model