axw 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:21
axwwallyworld: ^^ I'd rather not spend all my time fixing Windows unit tests right at this point in time00:22
wallyworldaxw: agreed, i'm not sure why gating was turned on before tests passed00:23
wallyworldwe may have to skip them depending on how many there are00:24
wallyworldaxw: did i recall perhaps incorrectly that bug 1598049 had been sorted out in some form?02:18
=== mup_ is now known as mup
axwwallyworld: I *think* that's sorted out by perrito666's patch, which I merged into my branch and landed02:20
axwbut I don't have windows handy to verify02:20
wallyworldaxw: yeah, that rings a bell, that's what i thought had happened02:20
wallyworldi might mark as fix committed02:20
wallyworldaxw: this updates the juju/rfc repo with the changes to remove the custom tls package https://github.com/juju/rfc/pull/102:35
axwwallyworld: you just did a straight copy of changes from juju/juju/standards right?02:37
axwapart from txt file of course02:37
wallyworldaxw: yep, and i could only see that one change02:37
wallyworldclient.go plus deletes02:37
axwwallyworld: cool. LGTM, thanks02:37
axwwallyworld: I'd like to move that rfc5424 package to live under juju/syslog at some point02:38
axwlumping all standards together is a bit odd, since there's many standards for wildly different things02:38
wallyworldyeah, could do. although i thik the intent was to gather all rfc things there02:39
axwwallyworld: I know that was the intent, it just seems very strange to me. maybe just me...02:39
wallyworldcan easily be done, let's discuss with tech board or whatever02:40
axwsure, no rush anyway02:40
wallyworldaxw: and here's the juju/juju change http://reviews.vapour.ws/r/5218/ (not that it can land, sigh)02:55
axwwallyworld: LGTM02:57
veebersHi 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:03
veebersaxw 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 correctly04:04
axwveebers: what are you using for "syslog-host" config?04:06
veebersaxw syslog-host:
veebersaxw I'm using certtool to gen the certs (creating a ca cert and some client/server certs too)04:07
axwveebers: try using the hostname that you used when generating the cert04:08
axwrather than IP04:08
veebersaxw: 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:15
axwveebers: either you need DNS, or when you generate the cert you need to include an IP SAN04:16
veebersaxw: 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 cert04:17
axwveebers: for the server cert at least, not sure how client cert verification works04:18
veebersaxw: 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:20
axwveebers: 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
veebersProbably worth mentioning; the certs that I'm generating work fine when using just rsyslog (i.e. 2 machines one sending to the other)04:24
axwveebers: interesting. that would seem to imply they're not doing strict host verification04:25
veebersaxw: 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 joy04:25
veebersaxw: that thought did cross my mind, could be the way I have it configured04:26
veebersi.e. Using the config from the top answer here: http://serverfault.com/questions/666827/using-rsyslog-with-tls-without-generating-a-self-signed-cert04:26
veebersaxw: huh, I think that's working now. Is there an action I can do that would create a log that would be forwarded?04:43
axwveebers: anything and everything that goes over the API04:44
axwveebers: you shouldn't need to do anything really, logs just happen04:45
veebersaxw: I'm wanting something reproduce-able so I can check that it works now as well as incorporate it into the ci test :-)04:46
veebersI 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 correctly04:47
axwveebers: 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 message04:47
axwthat should have the word "FullStatus" in it04:47
veebersaxw: 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:50
axwveebers: 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 messages04:51
axwalthough, I think we default to WARNING?04:52
veebersI'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 cover04:54
axwveebers: 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
axwveebers: if you're at INFO level, you should see "API connection from <IP>" whenever a client connects04:57
axwveebers: so you could just run "juju status" and look for that04:58
veebersaxw: sweet, so changing log level is as easy as: juju set-model-config logging-config="<root>=INFO" -m controller ?04:58
axwveebers: yup04:58
veeberssweet cheers04:58
veebersaxw: wow ok, so doing that and then a status floods the log with: http://pastebin.ubuntu.com/19050776/04:59
veebersover and over again04:59
veebersI just killed the controller as it was pegging my system (jujud)05:00
axwveebers: huh :/05:03
axwwallyworld: ^^ there's probably a log forwarding loop05:03
wallyworldhmmm, i think i saw a bug last week with that outout05:05
wallyworldveebers:  axw: this seems to be the same thing https://bugs.launchpad.net/juju-core/+bug/159977905:09
mupBug #1599779: Very high CPU usage from 'creating cloud image metadata storage'  emitted in debug log every second <juju-core:New> <https://launchpad.net/bugs/1599779>05:09
wallyworldnot sure that it's log forward related05:09
axwah 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 state05:10
veeberswallyworld: that looks like what I saw, but seems it was more than once a second. /var/log/syslog on the controller was flooded05:11
wallyworldhmmm, maybe the log forward worker is not marking logs as sent, so it just keeps sending the same thing, not sure05:12
veebersaxw, 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 environment05:13
axwveebers: no worries05:13
mupBug #1600722 opened: MachineSuite.TestHostedModelWorkers is unreliable <intermittent-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1600722>08:56
voidspacefrobware: babbageclunk: be at standup in 5 minutes or so09:02
frobwaredooferlad: standup today?09:09
axwwallyworld: first of many: http://reviews.vapour.ws/r/5219/09:12
wallyworldaxw: fyi i've removed the controller model check - just get the controller uuid directly now, still getting tests to pass in my branch09:15
axwwallyworld: great, thanks09:15
wallyworldaxw: lgtm, hopefully we can land stuff soon09:23
axwwallyworld: ta. I've got another one coming with changes how we pass timeouts to MAAS and the bootstrap-state jujud code09:24
wallyworldok, may be afk for a fried time09:24
urulamaaxw, wallyworld: is this a fix for access key issue?09:24
axwurulama: authorized-keys issue?09:25
urulamaaxw, wallyworld: and good evening :)09:25
urulamaaxw: yes, sorry09:25
wallyworldurulama: yeah09:25
wallyworldbut the landing bot is preventing landings as it wants all windows tests to pass09:25
urulamageat :-/09:27
frobwarevoidspace: want to do 1:1?09:36
urulamamgz: you around? can you revert the changes for windows tests so that beta12 actually becomes useful (like be able to deploy an application)09:38
urulamawallyworld, axw: do you know what the status of this one is? https://bugs.launchpad.net/juju-core/+bug/159382809:41
mupBug #1593828: cannot assign unit E11000 duplicate key error collection: juju.txns.stash <ci> <conjure> <deploy> <intermittent-failure> <oil> <juju-core:In Progress by 2-xtian> <https://launchpad.net/bugs/1593828>09:41
axwurulama: no clue, sorry09:43
voidspacefrobware: sorry, my wife got back from dropping off her dad at the airport and I went to talk to her09:44
voidspacefrobware: sure, can do 1:109:44
frobwarevoidspace: in the ho09:46
babbageclunkurulama: 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:51
babbageclunkurulama: once it's merged into the v2 branch I can start updating the mgo version in the various dependencies.tsv files.09:52
urulamababbageclunk: 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
urulama(annoyingly consistent at failing that is)09:53
babbageclunkurulama: 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:57
babbageclunkurulama: Are you using beta packages or source? It should be in the beta getting cut this week.09:58
urulamababbageclunk: 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/29109:58
babbageclunkurulama: Yeah - that's an occasional failure in the mgo test suite. :(09:59
urulamababbageclunk: using source, will have an eye on when this lands10:00
babbageclunkurulama: not anything to do with my change but I'm going to try to sort it out, it's bitten me twice now.10:00
babbageclunkurulama: ok - I'll put an update on the bug now and keep you updated when there's movement10:01
jamespagefrobware, one for your list - https://bugs.launchpad.net/juju-core/+bug/160054610:08
mupBug #1600546: lxd subnet setup by juju will interfere with openstack instance traffic <sts> <juju-core:New> <nova-compute (Juju Charms Collection):New> <https://launchpad.net/bugs/1600546>10:09
frobwarejamespage: ack & thanks10:11
jamespagewell lathiat can take the credit for finding that one :-)10:12
babbageclunkUgh, I just realised I'll need to do a topological sort of the transitive closure of packages that depend on mgo.10:17
urulamababbageclunk: thanks (and auch, on the last one)10:37
babbageclunkurulama: :)10:37
mgzurulama: sorry, which tests?11:21
mgzoh, it's the whole do we want gating or not thing11:21
mgzwell, there's a reason I pushed back on adding gating here, but... we *were* asked to11:21
mgzurulama: there's actually a fun bug that circumvents the gate11:22
mgzurulama: but I will disable the windows part if we have general agreement11:22
urulamai mean, critical bug fixes can't land11:23
urulamawe can wait for Torsten to be up in 2h ...11:23
mgzurulama: more a question for cherylj/alexisb11:23
mgzbut you+ian will do11:23
mgztest regressions generally are critical bugs11:23
mgzurulama: anyway, I'll fix the bug in the script and remove windows from the list of jobs for now11:24
urulamamgz: ok, thanks11:25
mgzurulama: done11:26
urulamaty ... now i hope Andrew's branches land soon :)11:26
mgzyou can retrigger if it's approved11:26
mgzI doubt he'd mind11:27
urulamamgz: done, let's see if tests pass now :)11:29
babbageclunkjam: 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:31
dooferladmacgreagoir: standup?11:32
urulamarogpeppe, ashipika: ^ see comment from babbageclunk11:32
mgzbabbageclunk: kill romulus11:32
babbageclunkmgz: very classical11:33
ashipikamgz:  et tu?11:34
ashipikaurulama, mgz, babbageclunk: the proposed solution was to integrate romulus into juju core.. which is on our todo list..11:34
mgzkill, integrate, much the same11:35
ashipikamgz: there's a certain Julius C. that would disagree :D11:35
ashipikawe're one sprint in Rome short of a Remus.. then we'd have a classical duel on our hands :)11:36
urulamamgz: thanks, https://github.com/juju/juju/pull/5772 landed11:43
mgzurulama: ace11:44
babbageclunkashipika: 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:44
ashipikababbageclunk: update the juju-core dependency first, merge, update the romulus dependency second (it depends on the core), merge.. i guess11:45
babbageclunkashipika: And it doesn't matter that the dependencies will conflict?11:46
babbageclunkashipika: does godeps handle that already?11:47
ashipikababbageclunk: hmmm.. i think it should all work out.. i hope..11:47
babbageclunkashipika: I guess I can just try it! Thx11:47
ashipikababbageclunk: good luck.. ping me if it doesn't work11:48
babbageclunkashipika: It should be ok, since the bugfix doesn't change any interfaces.11:49
babbageclunkashipika: thanks, will do!11:49
urulamamgz: 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:52
mgzurulama: hm, I guess I screwed something up11:54
mgzoh, there's a trailing backslash all the way over there >_<11:55
urulamababbageclunk: does this mean that you already have your fix landed in mgo?11:56
mgzwelp. fixed, good thing the branch had in fact already passed.11:59
rogpeppebabbageclunk: what specific problem are you having?12:05
babbageclunkurulama: No, just getting ready for the next bit.12:08
babbageclunkrogpeppe: nothing yet - just trying to decide what order to update the dependencies when it's time to.12:09
rogpeppebabbageclunk: note that the cyclic dependencies from charmstore<->charmrepo are only because charmrepo uses charmstore for its tests12:09
babbageclunkrogpeppe: ah, ok - that is a lot less worrying.12:10
rogpeppebabbageclunk: 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 that12:10
babbageclunkrogpeppe: but if the tests pass then it should be ok, anyway.12:11
rogpeppebabbageclunk: yup12:11
babbageclunkrogpeppe: 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
rogpeppebabbageclunk: right12:13
rogpeppebabbageclunk: you'll need to choose one version for all deps12:14
rogpeppebabbageclunk: i usually use the newest version of all deps if in doubt12:14
babbageclunkrogpeppe: yeah, that makes sense12:14
rogpeppebabbageclunk: the -N flag to godeps can be useful too12:14
rogpeppebabbageclunk: for coming up with a coherent "latest tested" set of deps from several projects' dependencies.tsv files12:15
babbageclunkrogpeppe: ok, will use that. Thanks!12:15
jambabbageclunk: I would think that neither romulus or charmrepo expose mgo as part of their interface.13:27
jamas long as they aren't returning an mgo.Doc or something like that, we should be ok13:27
jambabbageclunk: 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
jambabbageclunk: they need your mgo fix more than they need newest of all other deps13:28
junaidaliHi everyone, what is the equivalent command for $ juju set-constraints tags=controller     in Juju2.013:42
frobwarejunaidali: set-model-constraints (http://pastebin.ubuntu.com/19079305/)13:53
junaidalithanks frobware14:09
babbageclunkjam: good point, I'll make sure that I'm only updating deps (other than mgo) when they're on the latest.14:11
mupBug #1600600 changed: Docs are incorrect for Azure bootstrap <juju-core:Invalid> <https://launchpad.net/bugs/1600600>16:09
voidspacebabbageclunk: frobware: dooferlad: firefox crash! omw16:12
mupBug #1600600 opened: Docs are incorrect for Azure bootstrap <juju-core:Invalid> <https://launchpad.net/bugs/1600600>16:24
voidspacefrobware: are you going to mid-cycle?16:26
frobwarevoidspace: nope16:26
mupBug #1600600 changed: Docs are incorrect for Azure bootstrap <juju-core:Invalid> <https://launchpad.net/bugs/1600600>16:27
voidspacefrobware: do you know anyone from the UK who is?16:27
frobwarevoidspace: and from juju core?16:27
voidspacefrobware: 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 back16:28
voidspacefrobware: then it will be cheaper than getting them shipped to the UK16:28
voidspacefrobware: anyone from the UK willing to do me a favour... :-)16:28
voidspacefrobware: but I have no idea who's going16:28
mupBug #1600600 opened: Docs are incorrect for Azure bootstrap <juju-core:Incomplete> <https://launchpad.net/bugs/1600600>17:09
mupBug #1600600 changed: Docs are incorrect for Azure bootstrap <juju-core:Incomplete> <https://launchpad.net/bugs/1600600>17:12
mupBug #1600600 opened: Docs are incorrect for Azure bootstrap <juju-core:Incomplete> <https://launchpad.net/bugs/1600600>17:30
mgzanyone got something they want to land and doesn't mind being a guinea pig?17:32
voidspacedooferlad: ping17:37
mbruzekmgz: or balloons: did you come up with another solution for the bash completion problem?18:56
mbruzekmgz: 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
mupBug #1600257: The tab completion on juju yields KeyError: 'services' <bash-completion> <packaging> <juju-core:New> <juju-core (Ubuntu):New> <https://launchpad.net/bugs/1600257>18:57
mgzmbruzek: 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 that19:01
mgzdoes it avoid registering completions twice if the same script is executed twice under different names?19:01
mbruzek mgz: OK but I believe the issue was how to not collide with juju1 bash completion19:01
mgzis there a better way of auto-loading for aliases?19:01
mgzmbruzek: that is an issue, but we also need to update the juju 1.25 packaging, and own both parts19:02
mbruzekmgz in my testing the symbolic link worked and I was not getting double completions, but I will admit my testing was incomplete19:02
mgzmbruzek: so, that's the jist of my code review questions19:03
mbruzekmgz: 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 down19:04
alexisbdo we have anyone still online on the networking side21:10
alexisbfrobware, voidspace possible??21:10
frobwarealexisb: if we're quick...21:11
alexisbfrobware, was just recreating this bug: https://bugs.launchpad.net/juju-core/+bug/151615021:12
mupBug #1516150: LXC containers getting HA VIP addresses after reboot <canonical-bootstack> <juju-reboot> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1516150>21:12
alexisband when looking at the code paths for filtering ip address I found this fucntion:21:12
alexisbin : juju/juju/network/network.go21:12
alexisbwhich seems rather useless given /etc/default/lxc-net doesnt exits anymore, right??21:13
alexisbfrobware, this is not urgent I am just curious21:13
alexisbif I should open a bug21:13
frobwarealexisb: jam recently landed a change for filtering lxd bridge addresses21:14
alexisbah, ok I iwll look at those21:14
frobwarealexisb: http://reviews.vapour.ws/r/4478/21:15
frobwarealexisb: if there's nothing else then it's EOD for me. I only popped in to turn off some of my machines...21:16
alexisbfrobware, nope, I will catch you tomorrow, thanks!21:16
alexisbsorry for the intrusion21:16
mupBug #1602010 opened: juju status doens't display proper error when machine fails <juju-core:New> <https://launchpad.net/bugs/1602010>21:24
jcastrodoes anyone know how I can set this? https://github.com/juju/juju/search?utf8=%E2%9C%93&q=test-mode%3A+true21:46
jcastroI need to be able to set that variable in 2.x21:47
jcastrobut since I don't have an environments.yaml to put it in ...21:47
jcastrotest-mode:true is what I am trying to set21:47
=== urulama is now known as urulama|__
=== alexisb is now known as alexisb-afk
mupBug #1602032 opened: Add machine and core count to 'models' output <juju-core:New> <https://launchpad.net/bugs/1602032>23:22
mgzwallyworld: can you explain your change for bug 1599905 to me?23:45
mupBug #1599905: rfc5424 standard has a non-free license <juju-core:In Progress by wallyworld> <https://launchpad.net/bugs/1599905>23:45
axwwallyworld: http://reviews.vapour.ws/r/5221/23:49
mupBug #1602034 opened: 'ERROR connecting with bootstrap config' for status on destroyed model <juju-core:New> <https://launchpad.net/bugs/1602034>23:52

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!