| davecheney | cherylj: looks like CI is still running 1.2 | 00:07 |
|---|---|---|
| davecheney | at least on the 1.25 branch | 00:07 |
| davecheney | does sinzui 's fix need to be backported to 1.25 ? | 00:08 |
| davecheney | >was it just that the go compiler sucks compared to c++? | 00:08 |
| davecheney | ^ i literally cannot even | 00:08 |
| anastasiamac_ | wallyworld: axw: i think this is ready to go http://reviews.vapour.ws/r/4573/ could someone plz stamp it? :D | 00:09 |
| sinzui | davecheney: What is happening here http://reports.vapour.ws/releases/3933/job/run-unit-tests-race/attempt/1387 | 00:09 |
| davecheney | ta | 00:10 |
| wallyworld | sinzui: are all the juju tests now run on go 1.6? | 00:10 |
| wallyworld | for 2.0? | 00:10 |
| davecheney | the race detector does not support ppc64 | 00:10 |
| davecheney | hang on | 00:10 |
| davecheney | is this ppc64 | 00:10 |
| sinzui | wallyworld: no windows and centos are tested on both 1.2 and 1,6 because the 1.6 do not pass | 00:10 |
| davecheney | no, this is amazon | 00:10 |
| sinzui | davecheney: That is exactly my wtf moment. a trusty containter that thinks it is ppc | 00:11 |
| wallyworld | sinzui: that's the unit tests right? | 00:11 |
| sinzui | wallyworld: yes | 00:11 |
| davecheney | ok, so the race deector in the trusty golang1.6 deb is busted | 00:11 |
| davecheney | :9 | 00:11 |
| davecheney | :( | 00:11 |
| davecheney | paging mwhudson | 00:11 |
| wallyworld | sinzui: i thought horatio fixed the windows tests on 1.6, i'll need to check | 00:12 |
| mwhudson | davecheney: ah yes | 00:12 |
| sinzui | wallyworld: no his last fix was for go 1.2 regressions | 00:12 |
| sinzui | wallyworld all packages have been built with go 1.6 for several weeks | 00:12 |
| mwhudson | davecheney: try https://launchpad.net/~mwhudson/+archive/ubuntu/trusty-race-detector/+packages ? | 00:12 |
| wallyworld | sinzui: the issue right now is there's some upstream azure sdk changes we need but those require go 1.6 to build, so we need 1.6 everywhere first | 00:13 |
| wallyworld | so those tests need fixing | 00:13 |
| sinzui | wallyworld: IU ask every day in meeting for them to be fixed | 00:13 |
| wallyworld | yeah, everyone is busy :-( | 00:14 |
| sinzui | davecheney: I am inclined to make the race tests non-voting until we sort out what happened | 00:15 |
| sinzui | wallyworld: in the case of windows, I see bugs we already see, but more often, and some that seem to have been revealed by recent fixes http://reports.vapour.ws/releases/3933/job/run-unit-tests-win2012-amd64-go1_6/attempt/51 | 00:17 |
| wallyworld | sinzui: oh the fix for beta6 for ODS - the pinger shutdown fix - may have introduced a new window failure | 00:19 |
| sinzui | wallyworld: :( | 00:19 |
| wallyworld | well just just a guess | 00:19 |
| sinzui | wallyworld: I am on unknowns tomorrow. I will get every bug files for the remaining Go 1.6 tests | 00:19 |
| wallyworld | it seems go 1.6 on windows slowness may be exaserbating some of these failures | 00:20 |
| sinzui | wallyworld: and as for slowness. I think we need to extend timeouts for centos and windows | 00:20 |
| wallyworld | if that helps short term, that would be nice so we can get the azure fixes in | 00:20 |
| sinzui | wallyworld: I will also get that sorted out tomorrow | 00:23 |
| wallyworld | ok, ty | 00:23 |
| sinzui | davecheney: I think we need to force the race tests to run with go1.2 or quickly solve the golang 1.6 ld issue | 00:36 |
| davecheney | mwhudson: what say you to that ? | 00:37 |
| davecheney | afaik the race detector in go 1.6 works fine | 00:37 |
| davecheney | but something is wrong with how it's pacakged in trusty | 00:37 |
| mwhudson | ah | 00:37 |
| * redir is eod later #juju-dev | 00:37 | |
| mwhudson | sinzui, davecheney: there is a ppa with the support files needed | 00:37 |
| mwhudson | https://launchpad.net/~mwhudson/+archive/ubuntu/trusty-race-detector/+packages | 00:37 |
| davecheney | sinzui: is using that ppa an option ? | 00:37 |
| mwhudson | sinzui, davecheney: i should get this into trusty too | 00:38 |
| mwhudson | sinzui, davecheney: alternatively, can you run the race tests on xenial? | 00:38 |
| sinzui | davecheney: yes, yes I think it is | 00:38 |
| davecheney | cool | 00:38 |
| sinzui | mwhudson: I just switched the tests to xenial. got the same error though | 00:39 |
| mwhudson | sinzui: oh that's more surprising | 00:39 |
| mwhudson | sinzui: do you have apt/apt-get installing recommends by default? | 00:39 |
| sinzui | mwhudson: no, but we support installing a different set of packages instead of using the makefile (tht is how we test s390x and arm64) | 00:41 |
| mwhudson | shouldn't matter | 00:41 |
| mwhudson | sinzui: can you link me to the log of it failing on xenial? | 00:41 |
| sinzui | mwhudson: It is happening right now at http://juju-ci.vapour.ws:8080/job/run-unit-tests-race/1388/console. You need to log in as a dveloper to see it | 00:42 |
| davecheney | can someone send me the developer credentials | 00:44 |
| davecheney | my browser has forgotten them | 00:44 |
| mwhudson | sinzui: how does the golang-1.6 package get installed there? | 00:47 |
| mwhudson | all i see is golang-1.6 is already the newest version (1.6.1-0ubuntu1). | 00:47 |
| mwhudson | sinzui: anyway, somehow the golang-1.6-race-detector-runtime package needs to get installed | 00:49 |
| mwhudson | sinzui: usually that gets installed when golang-1.6 does, because golang-1.6 Recommends: it | 00:49 |
| mwhudson | er golang-1.6-go Recommends it, to be more precise | 00:49 |
| mwhudson | sinzui: but if golang-1.6-go is somehow installed when recommends are disabled, it won't, so that's my guess as to what's happening here | 00:50 |
| sinzui | mwhudson: understood. The makefile forces no-recommends. the makefile got an update today to ensure golang 1.6 or higher is preffered. I will reconfigure the job to install the required packages. | 00:53 |
| mwhudson | sinzui: ah makes sense | 00:57 |
| axw | anastasiamac_: LGTM | 00:59 |
| anastasiamac_ | axw: \o/ | 01:00 |
| sinzui | thans not fair. the rules to install extra packages conflict with the rules run with --race | 01:01 |
| sinzui | oh, all is good. thank you mwhudson and davecheney . I can see golang-1.6-race-detector-runtime is installed and the tests are running with --race on xenial | 01:05 |
| mwhudson | sinzui: \o/ | 01:06 |
| davecheney | woot | 01:20 |
| natefinch | menn0, axw, wallyworld: anyone care for a quick review? It's fairly trivial, but for a critical bug: http://reviews.vapour.ws/r/4735/ | 02:41 |
| wallyworld | sure | 02:42 |
| natefinch | I'd gotten eric to review, but he had some questions, so I wanted another pair of eyes | 02:43 |
| wallyworld | natefinch: if we have test coverage for proper use of ssl via other means, then we probably can remove that special case in the test | 02:50 |
| natefinch | wallyworld: well, my static analysis tests are stuck in committee... so right now, we don't. | 02:50 |
| wallyworld | natefinch: ok, so no harm leaving it there for now. i think the pr is lgtm | 02:51 |
| natefinch | wallyworld: ok... i think that's basically where eric landed too, just wanted a second opinion. Thanks. | 02:51 |
| wallyworld | np | 02:51 |
| natefinch | wallyworld: do you know if the apt mirrors thing is *only* applicable to MAAS? | 03:03 |
| wallyworld | natefinch: the general principal is applicable anywhere, but as axw mentioned to me, maas allows apt mirroe to be configured for it so juju could make special use of that to set the juju apt mirror setting off of what maas uses | 03:04 |
| wallyworld | instead of making the user to specify manuall in 2 places | 03:05 |
| axw | natefinch wallyworld: I'm not sure if it does now ... it has configuration for proxies for sure | 03:05 |
| natefinch | wallyworld: does juju's apt mirror get propagated to containers? | 03:06 |
| wallyworld | natefinch: no, that's the whole point of this work :-) | 03:06 |
| wallyworld | it is supposed to | 03:06 |
| wallyworld | so we need to figure out why not and fix | 03:06 |
| wallyworld | that's my understanding anyway | 03:07 |
| natefinch | wallyworld: ok... just making sure I understand the problem correctly. Sounds like it's two things: 1.) juju apt mirrors don't get propagated to containers. 2.) (bonus points) juju should pick up maas's apt mirror and pass it into containers juju creates on maas nodes | 03:07 |
| wallyworld | yes, assuming maas has such a setting | 03:07 |
| axw | yup | 03:07 |
| wallyworld | given all this, we need to audit what's there in juju already | 03:07 |
| wallyworld | so we understand the current actual behaviour | 03:08 |
| wallyworld | and figure out the gap between that and the to be | 03:08 |
| wallyworld | and document the to be in that spec | 03:08 |
| axw | wallyworld: I meant to ask, when you've got a spare few minutes, can you please have a look over my openstack PR? | 03:10 |
| wallyworld | sure | 03:11 |
| wallyworld | axw: looks like you already have a +1? | 03:12 |
| axw | wallyworld: yeah, but babbageclunk is not a graduated reviewer AFAIK | 03:13 |
| wallyworld | ah, i didn't check who did it | 03:13 |
| wallyworld | just saw the tick | 03:13 |
| mup | Bug #1334481 changed: juju should not record ssh certificates of ephemeral hosts <ci> <cloud-installer> <landscape> <juju-core:In Progress> <https://launchpad.net/bugs/1334481> | 03:24 |
| natefinch | where did all the help go? | 03:27 |
| natefinch | do we not have help on the providers in the CLI anymore? | 03:27 |
| wallyworld | axw: lgtm with a drive by request | 03:27 |
| wallyworld | natefinch: i think the help topics are under construction, not sure | 03:28 |
| axw | wallyworld: ta | 03:28 |
| natefinch | wallyworld: ok, that gives me hope. Right now, juju bootstrap on a new cloud basically just gives me the middle finger with no way to figure out what I'm supposed to do. | 03:28 |
| wallyworld | what do you mean? | 03:28 |
| natefinch | $ juju bootstrap google google | 03:29 |
| natefinch | ERROR detecting credentials for "google" cloud provider: gce credentials not found | 03:29 |
| natefinch | and as far as I can tell, none of our help actually tells you how to enter those credentials | 03:30 |
| wallyworld | juju help add-credentials | 03:30 |
| natefinch | $ juju help add-credentials | 03:30 |
| natefinch | ERROR unknown command or topic for add-credentials | 03:30 |
| wallyworld | sorry, no s | 03:31 |
| wallyworld | juju help add-credential | 03:31 |
| natefinch | oh man... bad one to not have a plural alias | 03:31 |
| wallyworld | well, it is only a single credential | 03:31 |
| natefinch | it is very often used in the plural, though | 03:32 |
| wallyworld | natefinch: juju help bootstrap tells you what you need anyway | 03:32 |
| wallyworld | but spot the sypo | 03:32 |
| wallyworld | typo | 03:32 |
| natefinch | yeah, IWas gonna say, it even says to see "add-credentials" | 03:33 |
| wallyworld | so i'm not sure how the current help is deficient | 03:33 |
| wallyworld | bootstrap failed, juju help bootstrap has the answer | 03:33 |
| wallyworld | albeit with a typo | 03:33 |
| natefinch | juju help bootstrap is a wall of text. it woudl be nice if the error about "credentials not found" also said "see juju help add-credential" | 03:34 |
| wallyworld | hopefully that stuff is being addressed | 03:35 |
| natefinch | I hope so :) | 03:35 |
| natefinch | we do still need juju help google/gce | 03:35 |
| wallyworld | i'm not 100% sure of the status of all that | 03:35 |
| natefinch | understood | 03:36 |
| natefinch | gah | 03:57 |
| natefinch | spend 15 minutes figuring out gce's credentials only to hit another bootstrap error: | 03:58 |
| natefinch | cannot start bootstrap instance: sending new instance request: sending new instance request: googleapi: Error 400: Invalid value for field 'resource.networkInterfaces[0].network': 'global/networks/default'. The referenced network resource cannot be found., invalid | 03:58 |
| menn0 | davecheney: small utils/ssh change to allow StrictHostKeyChecking to be turned on: http://reviews.vapour.ws/r/4738/ | 04:00 |
| menn0 | axw: or you? ^^ | 04:01 |
| axw | menn0: looking | 04:02 |
| menn0 | cheers | 04:02 |
| natefinch | whelp, can't bootstrap gce... guess it's time to file a bug | 04:02 |
| axw | natefinch: :/ how are we not finding that in CI ... | 04:06 |
| axw | pretty sure I bootstrapped gce last week, must be something new or maybe region or account specific | 04:07 |
| natefinch | axw: there was some networking stuff landed today... maybe it hasn't made it through CI yet | 04:07 |
| axw | ah | 04:07 |
| natefinch | axw: or at least, I heard them talking about networking stuff... I don't know for sure if anything landed | 04:07 |
| natefinch | hmm.. the commit history on master does not look like anything interesting landed lately | 04:09 |
| natefinch | yeah, weird, even if I do it from master weeks ago, still fails same way | 04:10 |
| natefinch | I must be special | 04:10 |
| natefinch | or I have to configure my GCE account in some way that I haven't | 04:11 |
| menn0 | axw: thanks for the review. I think strict should be the default too but I didn't want to break existing consumers of utils/ssh | 04:15 |
| menn0 | axw: FWIW it will soon default to on for juju ssh/scp" | 04:15 |
| menn0 | it's working on my machine | 04:15 |
| menn0 | pulling the host keys from the API server etc | 04:16 |
| menn0 | but needs tidying up and better test coverage | 04:16 |
| axw | natefinch: did it fail for you immediately? it seems to be working for me, but hasn't finished yet | 04:16 |
| axw | menn0: fair enough | 04:16 |
| axw | menn0: cool :) | 04:16 |
| natefinch | axw: failed in 10 seconds | 04:17 |
| axw | natefinch: I guess it's something about your account/project | 04:17 |
| natefinch | axw: yeah, I'll try creating a new project | 04:17 |
| anastasiamac_ | yes, my gce is bootstrapping fine too from master tip.. | 04:18 |
| natefinch | this was a fairly old project... I'll see if a new one works better | 04:19 |
| natefinch | still weird | 04:19 |
| natefinch | that seems to be working better. | 04:22 |
| davecheney | menn0: lookin | 04:25 |
| menn0 | davecheney: it's all good. axw already reviewed. | 04:25 |
| mgz | axw: http://reports.vapour.ws/releases/3933 <- note gce | 04:28 |
| mup | Bug #1576503 opened: Agents stuck in failed state <juju-core:New> <https://launchpad.net/bugs/1576503> | 05:00 |
| axw | mgz: interesting, seems to be different tho | 05:01 |
| menn0 | davecheney: screw you fslock... | 05:06 |
| mgz | axw: possibly over quota and bad message? | 05:06 |
| mgz | axw: we had passes since then | 05:07 |
| axw | mgz: hmm dunno, not much to go on apart from failing to get public addresses... | 05:08 |
| axw | sounds plausible tho | 05:08 |
| axw | mgz: ah yes, GCE operation error: (QUOTA_EXCEEDED) Quota 'CPUS' exceeded. Limit: 96.0 | 05:09 |
| mup | Bug #1576509 opened: Race in macaroon-bakery <ci> <race-condition> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1576509> | 05:19 |
| mup | Bug #1576510 opened: Race in macaroon-bakery <ci> <race-condition> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1576510> | 05:19 |
| === urulama|____ is now known as urulama | ||
| menn0 | axw: i've just realised that this SSH host key work has some interestsing corner cases with "juju scp" | 05:39 |
| menn0 | axw: do we care much about "juju scp 0:some.file 1:" | 05:39 |
| menn0 | ? | 05:39 |
| menn0 | axw: it doesn't work by default because the keys aren't in place but it could | 05:39 |
| axw | menn0: does scp let you do that? I thought it didn't | 05:40 |
| menn0 | axw: it definitely does... I've just been reading up on it | 05:40 |
| axw | so it does | 05:40 |
| axw | menn0: I must be living in the past | 05:40 |
| axw | uummm | 05:40 |
| axw | menn0: what do you mean "keys aren't in place"? | 05:41 |
| axw | why is it different to making two ssh connections, and writing to known_hosts twice? | 05:41 |
| menn0 | axw: when you do "scp host1:some.file host2:" there's a connection from your local machine to host1, and then host1 connects to host2 | 05:44 |
| menn0 | with juju there's no keys in place to allow connections between host1 and host2 | 05:44 |
| axw | menn0: ah, I see. | 05:44 |
| axw | menn0: I would say that's up to the user to manage | 05:44 |
| menn0 | axw: that said, with "scp -3 host1:... host2:" the connections are local -> host1 and local -> host2 | 05:45 |
| menn0 | so that's more likely to work | 05:45 |
| menn0 | except I can't make it work right now | 05:45 |
| axw | menn0: I don't really think it's worth worrying about | 05:46 |
| menn0 | axw: with a bit of work I could have juju scp generate a known hosts with the keys for both hosts | 05:46 |
| menn0 | axw: but it does make things a bit more complex | 05:46 |
| menn0 | axw: for now I'll generate a known hosts for the first host | 05:47 |
| menn0 | axw: that covers the majority of cases | 05:47 |
| axw | menn0: that will still cover "juju scp /local/file 0:remote/path" right? | 05:47 |
| menn0 | axw: of course. "0:" would be the first (and only host) in that command line | 05:48 |
| axw | menn0: ok, just making sure I understood you. sounds good | 05:48 |
| menn0 | cool | 05:48 |
| mup | Bug #1576503 changed: Agents stuck in failed state <juju-core:New> <https://launchpad.net/bugs/1576503> | 05:49 |
| wallyworld | axw: a small one for friday? http://reviews.vapour.ws/r/4739/ | 05:49 |
| axw | wallyworld: ok | 05:50 |
| axw | wallyworld: how does that satisfyPrerequisites function work on ubuntu < trusty? | 05:52 |
| axw | wallyworld: oh, this is only for series where mongo-3.2 is available | 05:53 |
| axw | never mind | 05:53 |
| wallyworld | yeah | 05:53 |
| axw | separate command, was thinking it was run by the machine agent | 05:54 |
| axw | wallyworld: LGTM | 05:54 |
| wallyworld | ty | 05:54 |
| anastasiamac_ | have u seen this before? I have just destroyed a controller (had 2 models: admin and default)... | 06:15 |
| anastasiamac_ | when i list-controllers, i get empty list (just the headers) as expected | 06:15 |
| anastasiamac_ | but when i list-models, i get "error: controller local.volumes not found" | 06:15 |
| anastasiamac_ | i would have expected (and have in the past) to see empty list with just headers | 06:15 |
| anastasiamac_ | it seems that maybe we are no longer cleaning current-controller ?.. is it bug-worthy?.. | 06:15 |
| mup | Bug #1576527 opened: listSuite.TestListJSON got null (showSuite too) <ci> <regression> <test-failure> <unit-tests> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1576527> | 06:22 |
| mup | Bug #1576528 opened: current controller not cleared on destroy <juju-core:New> <https://launchpad.net/bugs/1576528> | 06:22 |
| mup | Bug #1576534 opened: upgrade-charm refuses to upgrade <juju-core:New> <https://launchpad.net/bugs/1576534> | 06:31 |
| bdx | hello everyone | 06:49 |
| bdx | is 'juju deploy <service> --to lxd:<machine#>' supported by the maas provider in 2.0? | 06:49 |
| frobware | bdx: are you talking about MAAS 2.0, or Juju 2.0? Currently supported for Juju 2.0. For MAAS 2.0 & Juju 2.0 currently WIP and only available behind a feature flag and building from tip.... | 07:19 |
| bdx | frobware: nice, whats the flag? | 07:22 |
| bdx | frobware: maas2? | 07:22 |
| frobware | bdx: yep | 07:23 |
| bdx | frobware: I also must build master? | 07:23 |
| bdx | will this be dropping into beta7 then? | 07:24 |
| frobware | bdx: yep, and a moving target... currently very active for maas2 work | 07:24 |
| frobware | bdx: tbd | 07:24 |
| bdx | frobware: yea, I've been following along ... entirely. thx | 07:24 |
| frobware | bdx: we haven't done a CI run yet with this flag, so YMMV | 07:25 |
| bdx | I have a lab up with juju2.0 + MAAS2.0 + the flag | 07:25 |
| bdx | just not a build of master :-( | 07:25 |
| bdx | I'll give tip a build and see what gives | 07:27 |
| frobware | bdx: I would initially try the sinlge NIC setup, just a hint. :) | 07:28 |
| bdx | frobware: thanks, by single nic, you mean enlisted maas nodes only have 1 nic ? | 07:29 |
| frobware | bdx: yep. though things could have moved on since wed/thu when I was last tracking this. | 07:30 |
| bdx | that way no one has to decide what interface to put the bridge on | 07:30 |
| bdx | ? | 07:30 |
| frobware | bdx: we bridge all interfaces now | 07:31 |
| frobware | bdx: I just recall see a comment from voidspace that he was trying/testing single NIC setup to begin with | 07:32 |
| bdx | nice, ok | 07:32 |
| frobware | bdx: single NIC, with multiple VLANs, all end up with their own bridge: http://pastebin.ubuntu.com/16123783/ | 07:33 |
| rogpeppe1 | anyone know why aws-china is a separate cloud rather than just an aws region ? | 08:00 |
| mattyw | rogpeppe1, something something firewalls I think | 08:06 |
| mattyw | wallyworld, you around mate? | 08:06 |
| voidspace | frobware: bdx: I was testing containers deployed on machines with a single nic first | 08:08 |
| voidspace | frobware: bdx: that worked and then we got multiple nics working too | 08:08 |
| frobware | voidspace: ooh nice | 08:09 |
| voidspace | frobware: maas2 work is now feature complete - as soon as we get it passing CI we'll remove the flag | 08:09 |
| voidspace | frobware: so still *technically* experimental, but hopefully not for much longer | 08:09 |
| anastasiamac_ | rogpeppe1: different clouds for aws, aws-china and aws-gov because they require different authentication types or secret information for different regions | 08:13 |
| rogpeppe1 | anastasiamac_: ok, so you can't use the same credentials across those clouds? that makes sense. | 08:14 |
| voidspace | frobware: we're still getting maas schema failures though (json doesn't match what we expect) | 08:15 |
| voidspace | frobware: this is the latest CI run: http://reports.vapour.ws/releases/3934/job/maas-2_0-deploy-xenial-amd64/attempt/5 | 08:15 |
| voidspace | frobware: I'll fix that | 08:15 |
| anastasiamac_ | rogpeppe1: essentially, yes... quoting the spec for more details :D..."There can only be one default credential for a given cloud. If that credential does not work on a particular region then you will need to specify the credential used to deploy in that region. There can only be one default region for a cloud." | 08:17 |
| rogpeppe1 | anastasiamac_: thanks | 08:17 |
| anastasiamac_ | rogpeppe1: i hope this helps \o/ | 08:18 |
| anastasiamac_ | rogpeppe1: there is a similar separation for azure :D | 08:18 |
| voidspace | frobware: standup | 09:01 |
| frobware | voidspace: arriving... now! | 09:01 |
| voidspace | frobware: babbageclunk: https://github.com/juju/gomaasapi/pull/52 | 09:06 |
| rogpeppe1 | fwereade: ping | 10:20 |
| Mo0O | hello | 10:43 |
| babbageclunk | frobware: maas is up and running, but my nodes won't pxe boot to enlist. I've turned on DHCP and downloaded a boot image. What have I missed? | 10:54 |
| frobware | babbageclunk: boot order on VM nodes? | 10:55 |
| babbageclunk | frobware: the nodes have their nics first in the boot order. | 10:55 |
| babbageclunk | frobware: ha ha | 10:55 |
| frobware | babbageclunk: images imported? | 10:56 |
| frobware | babbageclunk: eth0 configured to be managed (and dns and dchp)? | 10:56 |
| babbageclunk | yup - do I still need a 14.04 image imported? | 10:56 |
| frobware | babbageclunk: you have 16.04? | 10:56 |
| babbageclunk | frobware: yup | 10:57 |
| frobware | babbageclunk: what does commisionning node say in your maas settings? (the drop-down in the UI) | 10:57 |
| babbageclunk | frobware: xenial | 10:57 |
| frobware | babbageclunk: HO? | 10:58 |
| babbageclunk | yes | 10:58 |
| frobware | babbageclunk: https://plus.google.com/hangouts/_/canonical.com/juju-sapphire | 10:59 |
| fwereade | rogpeppe1, pong | 11:02 |
| rogpeppe1 | fwereade: np, IS just saw an occurrence of this bug after upgrading to 1.25. fixed by a manual JS script https://bugs.launchpad.net/juju-core/+bug/1516989 (but not quite sure why the upgrade migration hadn't worked) | 11:03 |
| mup | Bug #1516989: juju status <service_name> broken <canonical-bootstack> <sts> <juju-core:Invalid by waigani> <juju-core 1.25:Fix Released by waigani> <juju-core (Ubuntu):Confirmed> <https://launchpad.net/bugs/1516989> | 11:03 |
| rogpeppe1 | fwereade: so, incident fixed, but not sure why it happened. | 11:04 |
| fwereade | rogpeppe1, huh | 11:06 |
| fwereade | rogpeppe1, sorry, I have only the vaguest memories of writing that script, and I don't recall tracking the fix in 1.25 | 11:06 |
| rogpeppe1 | fwereade: np :) | 11:07 |
| rogpeppe1 | fwereade: just thought you might be able to provide some insight at the time | 11:07 |
| fwereade | rogpeppe1, PR3860 went into 1.25 on dec 1, it seems -- is it remotely possible this was somehow an upgrade to an unfixed 1.25? | 11:08 |
| rogpeppe1 | fwereade: i don't think so; let me check | 11:08 |
| rogpeppe1 | fwereade: the version was 1.25.5 | 11:09 |
| fwereade | rogpeppe1, yeah, that should be fine | 11:09 |
| fwereade | rogpeppe1, no further insights here, I'm afraid :( | 11:10 |
| rogpeppe1 | fwereade: thanks | 11:10 |
| frobware | babbageclunk: if you do try my scripts you want to invoke as ... $ VIRT_RAM=1024 ./add-node ... | 11:25 |
| frobware | babbageclunk: because the default is 4GB, which may cause you a few problems | 11:25 |
| voidspace | babbageclunk: how's your branch doing? | 11:39 |
| babbageclunk | voidspace: finally got maas set up again, just setting up the private space node so I can have some constraints. | 11:40 |
| voidspace | babbageclunk: ok | 11:40 |
| babbageclunk | voidspace: it occurs to me I could test the change with storage constraints rather than space ones, sorry. | 11:42 |
| babbageclunk | voidspace: did you try adding a machine without a constraint? | 11:42 |
| voidspace | babbageclunk: I've added machines, yes | 11:43 |
| babbageclunk | voidspace: so should I just kick off the merge anyway? Not making anything worse if it doesn't work (although I think it will) and then unblocking you. | 11:44 |
| voidspace | babbageclunk: go for it | 11:44 |
| voidspace | babbageclunk: you might still need to JFDI it | 11:44 |
| babbageclunk | voidspace: oh, also dimiter made some comments that I should address. | 11:45 |
| voidspace | babbageclunk: cool | 11:46 |
| voidspace | babbageclunk: let me know when it's landed please | 11:47 |
| babbageclunk | voidspace: wilco | 11:50 |
| babbageclunk | voidspace: will $$jfdi$$ still run the tests? | 11:51 |
| frobware | babbageclunk: yes | 11:52 |
| voidspace | ^^^^ | 11:52 |
| babbageclunk | voidspace, frobware: so it just bypasses blocking? Or it runs them and then merges regardless of the result? | 11:53 |
| voidspace | babbageclunk: bypasses blocking | 11:53 |
| babbageclunk | voidspace: thanks | 11:53 |
| babbageclunk | voidspace: building now, also successfully added a machine with a space constraint. | 12:00 |
| voidspace | babbageclunk: awesome! | 12:01 |
| voidspace | great news | 12:01 |
| dooferlad | frobware: could you take a look at http://reviews.vapour.ws/r/4741/ please? It is a rather important fix for the last bridge script mods. | 12:24 |
| frobware | dooferlad: looking | 12:24 |
| * dooferlad goes for lunch | 12:25 | |
| * babbageclunk is lunching | 12:27 | |
| frobware | dooferlad: reviewed | 12:43 |
| mup | Bug #1576670 opened: undefined: tls.TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 <build> <centos> <ci> <regression> <test-failure> <unit-tests> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1576670> | 12:47 |
| mup | Bug #1576510 changed: Race in macaroon-bakery <ci> <race-condition> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1576510> | 13:17 |
| mup | Bug #1576674 opened: 2.0 beta6: only able to access LXD containers (on maas deployed host) from the maas network <oil> <juju-core:New> <https://launchpad.net/bugs/1576674> | 13:17 |
| mup | Bug #1576686 opened: bundle repository/bundles-lxd.yaml is invalid <juju-core:Triaged> <https://launchpad.net/bugs/1576686> | 13:41 |
| babbageclunk | voidspace, frobware: is there any way to get maas-cli 2 installed on wily? | 13:43 |
| babbageclunk | experimental3 only has xenial. | 13:43 |
| frobware | babbageclunk: is this because your laptop is running wily? | 13:43 |
| babbageclunk | frobware: yeah | 13:43 |
| babbageclunk | frobware: can't try to use/adapt your scripts without it | 13:44 |
| mup | Bug #1576695 opened: Deployer cannot talk to Juju2 (on maas2) because :tlsv1 alert protocol version <ci> <deployer> <maas-provider> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1576695> | 13:53 |
| dooferlad | frobware: updated http://reviews.vapour.ws/r/4741/ | 14:01 |
| mup | Bug #1576700 opened: Misleading "Waiting for agent initialization to finish" message <ci> <status> <juju-core:New> <https://launchpad.net/bugs/1576700> | 14:11 |
| mup | Bug #1576704 opened: MigrationExportSuite.TestUnits unequal results <ci> <go1.6> <regression> <test-failure> <unit-tests> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1576704> | 14:11 |
| mup | Bug #1576705 opened: cloudImageMetadataSuite.TestSaveDiffMetadataConcurrentlyAndOrderByDateCreated wrong order <ci> <go1.6> <regression> <test-failure> <unit-tests> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1576705> | 14:11 |
| alexisb | babbageclunk, voidspace just want to make sure you guys saw this from mgz : https://bugs.launchpad.net/juju-core/+bug/1576368 | 14:19 |
| mup | Bug #1576368: blockdevice 2.0 schema check failed: model: expected string, got nothing <ci> <deploy> <maas-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1576368> | 14:19 |
| babbageclunk | alexisb: yup, voidspace is on it - https://github.com/juju/gomaasapi/pull/52 | 14:21 |
| frobware | dooferlad: it's not clear to me why we don't know all the routing information as and when we create the new stanzas and simply accumulate them. if we accumulate then it also means those bridging functions have no side effects. | 14:27 |
| dooferlad | frobware: the only function that has a side effect is bridge_now. | 14:28 |
| dooferlad | frobware: the most reliable thing to do is save routes for an interface, bridge the interface, restore routes that vanished. | 14:29 |
| frobware | dooferlad: iff, you first successfully write the new file | 14:29 |
| frobware | dooferlad: hence my preferred order. transform, successfully write new file, bridge-le-world. | 14:30 |
| dooferlad | frobware: you meen you want to not do anything unelss you have generated a new e/n/i? | 14:30 |
| dooferlad | frobware: I did just update the rev with a comment about that | 14:30 |
| frobware | dooferlad: it's moot. but if you can't write the file all bets sjould be off. | 14:30 |
| dooferlad | frobware: seems reasonable | 14:31 |
| dooferlad | frobware: so I just suggested not running the bridge_now loop until after the if not args.activate: ... exit(0) code | 14:32 |
| frobware | dooferlad: that would re-read the (new) eni file? | 14:32 |
| dooferlad | frobware: no | 14:32 |
| frobware | dooferlad: so what happesn before your exemplary if not activate? | 14:32 |
| dooferlad | frobware: easiest if I just write the code. Will be two minutes. | 14:33 |
| frobware | :) | 14:33 |
| alexisb | babbageclunk, voidspace awesome | 14:33 |
| babbageclunk | alexisb: just doing the juju diff to update the dependency now. | 14:34 |
| dooferlad | frobware: http://reviews.vapour.ws/r/4741/ updated | 14:39 |
| mup | Bug #1576728 opened: ConnectSuite.TestLocalConnectError: windows cannot connect to local lxd server <ci> <go1.6> <regression> <test-failure> <unit-tests> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1576728> | 14:45 |
| voidspace | alexisb: we're playing whackamole with maas schema oddities :-/ | 14:47 |
| voidspace | alexisb: we'll get there though | 14:47 |
| babbageclunk | voidspace, frobware: review please? http://reviews.vapour.ws/r/4742/ | 14:47 |
| babbageclunk | voidspace: figured I'd just do this bit | 14:47 |
| voidspace | babbageclunk: you beat me to it! | 14:48 |
| babbageclunk | voidspace: :) | 14:48 |
| voidspace | babbageclunk: thanks, LGTM | 14:48 |
| alexisb | voidspace, understood, thank you for the quick turn around it makes it so the CI runs can continue to move forward | 14:49 |
| babbageclunk | voidspace: I'm going to quickly make a list of the attributes we use and see if roaksoax or anyone else in #maas can point out others that are optional | 14:49 |
| voidspace | babbageclunk: it's any that appear in the gomaasapi schema - so depending on what you mean by "we use" it's not just the ones we use | 14:50 |
| voidspace | babbageclunk: but yeah, catching these ahead of time would be good | 14:51 |
| babbageclunk | voidspace: yeah, that's what I meant - frustratingly, in some of these cases they're not even things we use | 14:51 |
| babbageclunk | voidspace: we're still good to JFDI things, right? | 14:52 |
| babbageclunk | voidspace: (optional or nullable, I guess) | 14:53 |
| voidspace | babbageclunk: yep | 14:53 |
| voidspace | babbageclunk: and yep | 14:53 |
| babbageclunk | voidspace: huh. Exact spelling of JFDI please? | 14:56 |
| mgz | I feel like our blocking process has not been working the past few weeks | 14:57 |
| mgz | babbageclunk: how about we just use fixes-BUGNUM instead | 14:57 |
| katco | ericsnow: redir: hey i'm going to miss this morning's standup... guy who is refinishing our floor just showed up | 14:57 |
| mgz | babbageclunk: I marked bug 1576368 blocking so don't jfdi, use magic string 'fixes-1576368' | 14:58 |
| mup | Bug #1576368: blockdevice 2.0 schema check failed: model: expected string, got nothing <blocker> <ci> <deploy> <maas-provider> <juju-core:Triaged by 2-xtian> <https://launchpad.net/bugs/1576368> | 14:58 |
| babbageclunk | mgz: Ok, thanks | 14:58 |
| ericsnow | katco: k, good luck | 14:58 |
| redir_ | katco: standup? | 15:10 |
| redir_ | katco: OK. Missed the scrollback, eric passed it on. | 15:15 |
| perrito666 | wallyworld: still working? | 15:33 |
| mup | Bug #1576743 opened: juju agent 1.25.5 crashes on ubuntu 14.04 in an private openstack cloud <juju-core:New> <https://launchpad.net/bugs/1576743> | 15:33 |
| mup | Bug #1576750 opened: juju2 usability: many options have to be specified for every bootstrap <landscape> <juju-core:New> <https://launchpad.net/bugs/1576750> | 15:33 |
| mup | Bug #1576756 opened: cannot shut down controllers running other people's models <juju-core:New> <https://launchpad.net/bugs/1576756> | 15:33 |
| rogpeppe1 | anyone know how i can "juju switch" to a different account? | 15:37 |
| cherylj | rogpeppe1 you mean be a different user? | 15:37 |
| rogpeppe1 | cherylj: yes | 15:37 |
| rogpeppe1 | cherylj: i'm getting "ERROR getting controller environ: getting bootstrap config from API: permission denied (unauthorized access)" when i try to destroy a controller | 15:38 |
| rogpeppe1 | cherylj: and i think the problem is probably that i'm using the wrong account | 15:38 |
| cherylj | there was a switch-user, I thought. hmm maybe that was removed | 15:38 |
| mup | Bug #1576756 changed: cannot shut down controllers running other people's models <juju-core:New> <https://launchpad.net/bugs/1576756> | 15:39 |
| rogpeppe1 | cherylj: i see two users for the controller in accounts.yaml | 15:39 |
| rogpeppe1 | cherylj: but the current user is not the admin user | 15:39 |
| cherylj | rogpeppe1: maybe logout / login? | 15:40 |
| rogpeppe1 | cherylj: i don't think that's what i want | 15:41 |
| rogpeppe1 | cherylj: looks like logout will delete my password | 15:41 |
| rogpeppe1 | http://paste.ubuntu.com/16127920/ | 15:41 |
| frobware | dooferlad, voidspace, babbageclunk: PTAL @ http://reviews.vapour.ws/r/4743/ | 15:43 |
| cherylj | rogpeppe1: sounds like you want to change your password first :) | 15:43 |
| cherylj | I've never done that before, so I can't tell you what will happen | 15:43 |
| rogpeppe1 | cherylj: tbh i don't want to clear the credentials from the client | 15:44 |
| rogpeppe1 | cherylj: i ended up just manually editing the accounts.yaml file | 15:44 |
| cherylj | that works too | 15:44 |
| rogpeppe1 | cherylj: thanks for the help | 15:44 |
| dooferlad | frobware: looking | 15:49 |
| dooferlad | frobware: http://reviews.vapour.ws/r/4741/ is updated again | 15:50 |
| dooferlad | frobware: +1 | 15:52 |
| babbageclunk | voidspace: this is the schema as we have it now (munged for a bit more clarity): http://paste.ubuntu.com/16127709/ | 15:55 |
| babbageclunk | roaksoax is going to get someone to go through it. | 15:55 |
| frobware | dooferlad: thanks. I raised the question about `ip route' and IPv6 - what happens when the iface has an IPv6 route in addition to 4? | 16:05 |
| frobware | cherylj: master is blocked... or not? | 16:29 |
| cherylj | frobware: it is blocked | 16:29 |
| cherylj | there are new failures | 16:29 |
| cherylj | and they need to be addressed | 16:30 |
| frobware | cherylj: ok, see you next week. :) | 16:30 |
| cherylj | haha | 16:30 |
| cherylj | frobware: it's going to be hot and humid. Hope you're prepared | 16:30 |
| frobware | cherylj: it's trying to snow here... ??? | 16:31 |
| cherylj | https://weather.com/weather/tenday/l/78757:4:US | 16:31 |
| frobware | ooh, some of the numbers start at 8 | 16:31 |
| cherylj | high of 30C Friday | 16:32 |
| frobware | cherylj: I'll go with old money; 80 sounds way higher | 16:32 |
| voidspace | babbageclunk: awesome | 16:32 |
| voidspace | babbageclunk: nice work | 16:32 |
| cherylj | hehe | 16:33 |
| mup | Bug #1576778 opened: juju2 tab-completion for sub commands is broken in beta6 <landscape> <usability> <juju-core:New> <juju (Ubuntu):New> <https://launchpad.net/bugs/1576778> | 16:42 |
| === urulama is now known as urulama|afk | ||
| alexisb | katco, ping | 16:50 |
| katco | alexisb: pong | 16:51 |
| alexisb | heya katco , we need some help unblocking master and cherylj is currently occupied with sprint tasks for next week | 16:51 |
| alexisb | katco, can you please rally the troupes around these 1.6 failures: | 16:52 |
| alexisb | https://goo.gl/0jYcTy | 16:52 |
| katco | alexisb: sure thing | 16:52 |
| alexisb | thank you, I am here if you have qs | 16:52 |
| alexisb | though I will be changing locations here in a minute | 16:52 |
| katco | alexisb: thanks | 16:52 |
| katco | alexisb: for bug 1576670. what substrates are still on 1.2? i thought we had 1.6 backported to trusty and we were now fully on 1.6? | 16:54 |
| mup | Bug #1576670: undefined: tls.TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 <blocker> <build> <centos> <ci> <go1.2> <go1.6> <regression> <test-failure> <unit-tests> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1576670> | 16:54 |
| alexisb | 1.6 | 16:54 |
| alexisb | no more 1.2 | 16:54 |
| cherylj | katco: that bug started the discussion this morning | 16:54 |
| cherylj | of whether or not we still use go 1.2 for our windows / centos unit tests | 16:55 |
| cherylj | because those unit tests fail under go 1.6 | 16:55 |
| katco | cherylj: if we do, that's a bug against CI i think? windows can use 1.6 without any problem. centos i'm less sure of. what do you think? | 16:55 |
| cherylj | so if we can get the windows / centos tests working with go 1.6, that bug will be invalid | 16:55 |
| mgz | katco: 'without any problem' is the issue | 16:55 |
| cherylj | yeah | 16:55 |
| katco | cherylj: mgz: ah i see... chicken and egg problem? there are some centos/windows tests failing on 1.6? | 16:56 |
| cherylj | katco: exactly :) | 16:56 |
| cherylj | so we're asking for help to fix those other tests | 16:56 |
| alexisb | 1.6 all the way! | 16:56 |
| katco | cherylj: read my mind: i think we should push forward. mark bug 1576670 as invalid and flag failing tests as blockers | 16:56 |
| mup | Bug #1576670: undefined: tls.TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 <blocker> <build> <centos> <ci> <go1.2> <go1.6> <regression> <test-failure> <unit-tests> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1576670> | 16:57 |
| mgz | 200% compile time slowdowns all the way! | 16:57 |
| cherylj | huzzah! | 16:57 |
| katco | mgz: that has been addressed in tip :) | 16:57 |
| katco | cherylj: so are you fine with me marking this as invalid? can you raise the other test failures as blocking bugs? | 16:57 |
| cherylj | katco: already did | 16:58 |
| cherylj | :) | 16:58 |
| katco | cherylj: ty kindly :) | 16:58 |
| alexisb | katco, what we need from the core team is to fix the test failures | 16:58 |
| katco | alexisb: agreed | 16:58 |
| mgz | katco: yeah, it's now just a 100% slowdown | 16:58 |
| katco | mgz: native go compiler > c compiler, and slowdowns will be addressed over time :) it's a good thing overall! | 16:59 |
| katco | ericsnow: redir: redir_: what are you 2 up to? | 16:59 |
| katco | perrito666: what are you working on? | 16:59 |
| mgz | katco: I'm not being too serious :) | 16:59 |
| cherylj | okay, I'm going to get some lunch. bbiab | 16:59 |
| ericsnow | katco: syslog | 17:00 |
| katco | ericsnow: the 1-pager? | 17:00 |
| alexisb | folks these blockers are top priority so if you have a nice stopping point | 17:00 |
| ericsnow | katco: yep | 17:00 |
| redir | katco: The LTS update fix and ian's feedback. | 17:00 |
| katco | ericsnow: sounds like that's getting trumped | 17:00 |
| katco | redir: k, carry on | 17:00 |
| * redir nods | 17:00 | |
| katco | redir: hi btw | 17:01 |
| redir | morning katco :) | 17:01 |
| * alexisb changes locations brb | 17:01 | |
| katco | ericsnow: you have your pick: | 17:01 |
| katco | https://bugs.launchpad.net/juju-core/+bugs?field.searchtext=&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.st | 17:01 |
| * katco now understands why alexisb put that in a url shortener | 17:01 | |
| ericsnow | katco: k | 17:02 |
| katco | ericsnow: lmk which one you pick up so i can pick something else | 17:02 |
| ericsnow | katco: it'll be a few minutes before I can get to a stopping point | 17:04 |
| katco | ericsnow: np at all, same here | 17:04 |
| mup | Bug #1576670 changed: undefined: tls.TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 <blocker> <build> <centos> <ci> <go1.2> <go1.6> <regression> <test-failure> <unit-tests> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1576670> | 17:12 |
| mup | Bug #1576778 changed: juju2 tab-completion for sub commands is broken in beta6 <landscape> <usability> <juju-core:New> <juju (Ubuntu):New> <https://launchpad.net/bugs/1576778> | 18:03 |
| mup | Bug #1576318 opened: juju register not clear that you're creating a new password <apport-bug> <i386> <usability> <xenial> <juju-core:Triaged> <juju-core (Ubuntu):New> <https://launchpad.net/bugs/1576318> | 18:03 |
| mup | Bug #1576805 opened: Juju controllers set the rsyslog NetstreamDriver affecting all subsequent rsyslog configuration <juju-core:New> <https://launchpad.net/bugs/1576805> | 18:03 |
| katco | cherylj: hey, build bot is wrong? https://github.com/juju/juju/pull/5318 | 18:35 |
| * cherylj looks | 18:36 | |
| mgz | katco: it's being fussy about high vs critical | 18:36 |
| katco | mgz: ah ok. jfdi? | 18:36 |
| mgz | go again, I edited the bug | 18:36 |
| katco | mgz: ta | 18:36 |
| mgz | use $$fixes-NNN$$ | 18:36 |
| katco | mgz: sanity check: for bug 1576728, i'm just not going to run any tests for lxd on windows | 19:22 |
| mup | Bug #1576728: ConnectSuite.TestLocalConnectError: windows cannot connect to local lxd server <blocker> <ci> <go1.6> <regression> <test-failure> <unit-tests> <windows> <juju-core:In Progress by cox-katherine-e> <https://launchpad.net/bugs/1576728> | 19:22 |
| katco | cherylj: ^^ | 19:22 |
| cherylj | katco: sounds good. You may also need to include a skip for centos too | 19:23 |
| cherylj | so, I guess if ! ubuntu | 19:23 |
| katco | mgz: cherylj: when/if lxd is supported on windows, this code will have to be modified to be platform independent anyway. the error instructions don't make sense for anything but ubuntu | 19:23 |
| katco | cherylj: yeah good point | 19:24 |
| mgz | katco: I'm not sure on that, | 19:24 |
| mgz | we have some general isolation test failures with lxd | 19:24 |
| cherylj | but yeah, we'd want to move to a mocked out lxd client | 19:24 |
| katco | mgz: i don't follow | 19:24 |
| katco | cherylj: not only that, but these tests would be testing code that would never be exercised on those platforms | 19:25 |
| cherylj | that's true | 19:25 |
| mgz | katco: I've not looked in detail, but we have a bunch of tests that aren't very unity and actually try to talk to the local lxd | 19:26 |
| mgz | which should really just not do that at all, rather than be skipped on some platforms | 19:26 |
| katco | mgz: oh, yes. i completely agree there. just trying to remove the blocker pedantically | 19:26 |
| katco | mgz: not really prepared to do major surgery atm :) | 19:26 |
| mgz | katco: eg bug 1564511 - which is a different suite | 19:27 |
| mup | Bug #1564511: cmd/jujud/reboot tests fail with lxd container running <ci> <regression> <s390x> <tech-debt> <test-failure> <unit-tests> <xenial> <juju-core:Triaged> <https://launchpad.net/bugs/1564511> | 19:27 |
| katco | mgz: yeah. that's just so awful. | 19:27 |
| mgz | so, I'm not anti skipping on windows where the test otherwise makes sense but isn't code we ever run on windows | 19:27 |
| katco | mgz: i'll lay down robustness in layers. i'll address platform robustness in this patch | 19:28 |
| redir | katco: ericsnow got a minute to help me understan PatchValue? | 20:27 |
| ericsnow | redir: sure | 20:28 |
| katco | redir: sure, moonstone? | 20:28 |
| redir | sure | 20:28 |
| ericsnow | mgz: do you know of any problems we have had (testing or otherwise) due to Windows's long clock tick (15.6 ms by default)? | 20:33 |
| mup | Bug #1571783 changed: Windows unit tests cannot setup under go 1.6 <ci> <go1.6> <jujuqa> <regression> <test-failure> <unit-tests> <windows> <juju-core:Fix Released by hduran-8> <https://launchpad.net/bugs/1571783> | 20:33 |
| mgz | ericsnow: not with juju I think | 20:36 |
| ericsnow | mgz: k | 20:36 |
| ericsnow | mgz: I'm thinking that the bug I'm working on may be due to that long clock tick | 20:37 |
| mgz | ericsnow: it's possible, given we have a number of rather timing dependent tests | 20:40 |
| mup | Bug #1576851 opened: juju debug-log -i unit-rabbitmq-server-0 is unfriendly <juju-core:New> <https://launchpad.net/bugs/1576851> | 20:43 |
| alexisb | anastasiamac, are you there | 21:32 |
| anastasiamac | alexisb: i am | 21:32 |
| alexisb | heya | 21:33 |
| anastasiamac | alexisb: do u have a sec? | 21:33 |
| alexisb | I do | 21:33 |
| anastasiamac | could we go to our 1:1? | 21:33 |
| alexisb | yep | 21:33 |
| mup | Bug #1576873 opened: Juju2 cannot deploy centos or windows workloads on maas 1.9 <blocker> <centos> <ci> <maas-provider> <regression> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1576873> | 22:19 |
| mup | Bug #1576874 opened: restore-backup never completes <backup-restore> <blocker> <ci> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1576874> | 22:19 |
| perrito666 | alexisb: still here? | 22:28 |
| redir | thanks katco ericsnow that was very useful | 22:29 |
| alexisb | perrito666, yes | 22:29 |
| alexisb | wuz up? | 22:29 |
| perrito666 | alexisb: priv | 22:29 |
| katco | redir: np | 22:29 |
| ericsnow | katco: you have a sec for a quick review? http://reviews.vapour.ws/r/4746/ | 22:45 |
| katco | ericsnow: sure tal | 22:45 |
| katco | ericsnow: do we have a way to test this empirically? | 22:46 |
| ericsnow | katco: test what exactly? | 22:46 |
| katco | ericsnow: that the fix for your bug works | 22:46 |
| ericsnow | katco: I suppose I could spin up my KVM, update it, etc. and then run that test and hope my local timing isn't slow anyway... | 22:47 |
| ericsnow | katco: but running in KVM might mask the issue | 22:48 |
| ericsnow | probably | 22:48 |
| katco | ericsnow: i think it'd be enough to land the fix and coordinate with ci folks | 22:48 |
| katco | ericsnow: to ensure it's really solved | 22:48 |
| ericsnow | katco: that's what I was thinking | 22:49 |
| katco | ericsnow: shipit | 22:49 |
| ericsnow | katco: thanks | 22:49 |
| ericsnow | mgz: are all the go-1.6, windows blocks supposed to be critical? | 22:52 |
| ericsnow | mgz: trying to merge a fix | 22:52 |
| katco | ericsnow: flag your bug as critical to get it through | 22:52 |
| ericsnow | katco: done | 22:53 |
| perrito666 | :950 | 23:23 |
| perrito666 | meh, wrong window | 23:23 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!