menn0davecheney: 62097950d4677fb8ef6c9c83e3d7555eebf2c653 means that the tests in cmd/jujud/agent now don't run at all00:07
davecheneywill fix00:07
menn0davecheney: package_test.go is in the agent_test package but all the tests are in the "agent" package00:07
menn0davecheney: thanks00:08
davecheneywell, that was unexpected00:08
davecheneyi'll fix asap00:08
menn0davecheney: i'm currently ripping out the upgrade_test.go tests, which is why I noticed00:09
davecheneymenn0: hmm00:10
davecheneytests run on my machine00:10
davecheneythe way gocheck tests work00:10
davecheneyi think i got away with it00:10
davecheneybut it's inconsistent and i'll fix it00:10
menn0davecheney: if I run "go test ./cmd/jujud/agent -gocheck.f UpgradeSuite" the UpgradeSuite tests don't run but they used to before00:11
davecheneygot it00:12
davecheneyfix coming asap00:12
davecheneymenn0: https://github.com/juju/juju/pull/382800:14
menn0davecheney: ship it, with commentary00:17
davecheneylucky(~/src/github.com/juju/juju/cmd/jujud/agent) % go test -v00:18
davecheney=== RUN   TestPackage00:18
davecheneyOK: 107 passed, 3 skipped00:18
davecheney--- PASS: TestPackage (175.62s)00:18
davecheneyok      github.com/juju/juju/cmd/jujud/agent    175.672s00:18
davecheneylucky(~/src/github.com/juju/juju/cmd/jujud/agent) % go test -v00:18
davecheney=== RUN   TestPackage00:19
davecheneyOK: 107 passed, 3 skipped00:19
davecheney--- PASS: TestPackage (173.66s)00:19
davecheneyok      github.com/juju/juju/cmd/jujud/agent    173.710s00:19
davecheneybefore vs after00:19
davecheneynot seeing a difference in test runs00:19
davecheneyhow many tests do you see ?00:19
davecheneymenn0: ^^00:21
menn0but I wasn't in the same directory00:23
menn0I did "go test -v ./cmd/jujud/agent -gocheck.v"00:23
davecheneyi don't really understand how that matters00:25
davecheneygocheck is a singleton00:25
davecheneyso all the tests are registered during init00:25
davecheneythen something has to hook them up00:25
davecheneyit's fixed00:25
menn0davecheney: thank you00:26
davecheneyzero ducks00:26
davecheneyaxw: you're on call review today? https://github.com/juju/juju/pull/382900:52
axwdavecheney: yup. looking00:52
axwdavecheney: LGTM00:54
thumperbah humbug01:06
* thumper wants sinzui01:06
davecheneydon't we all01:06
thumperI've worked out why my call fails...01:15
thumperwhat I'm not sure about is how it passed before01:16
davecheneyaxw: https://github.com/juju/juju/pull/383001:20
thumperoh FFS02:16
thumperwallyworld: got a minute to talk about a bug?02:17
thumper1:1 hangout02:17
thumperdavecheney, menn0, mwhudson, waigani: going to have to skip the standup tomorrow morning as I'm ferrying kids down to the university for a school trip02:41
thumperwill work from the library down there for the moring02:41
menn0thumper: ok cool02:46
waiganithumper: I might see you there if marsh centre is closed02:47
thumperwaigani: kk02:48
mupBug #1519995 changed: Upgrades from 1.20.11 to 1.25.2 fail because of status <blocker> <ci> <regression> <status> <upgrade-juju> <juju-core:Invalid> <juju-core 1.25:In Progress by thumper> <https://launchpad.net/bugs/1519995>02:52
mupBug #1519995 opened: Upgrades from 1.20.11 to 1.25.2 fail because of status <blocker> <ci> <regression> <status> <upgrade-juju> <juju-core:Invalid> <juju-core 1.25:In Progress by thumper> <https://launchpad.net/bugs/1519995>02:55
mupBug #1519995 changed: Upgrades from 1.20.11 to 1.25.2 fail because of status <blocker> <ci> <regression> <status> <upgrade-juju> <juju-core:Invalid> <juju-core 1.25:In Progress by thumper> <https://launchpad.net/bugs/1519995>02:58
mupBug #1519403 changed: 1.24 upgrade does not set environ-uuid <juju-core:Won't Fix by thumper> <https://launchpad.net/bugs/1519403>03:01
mupBug #1519403 opened: 1.24 upgrade does not set environ-uuid <juju-core:Won't Fix by thumper> <https://launchpad.net/bugs/1519403>03:04
mupBug #1519403 changed: 1.24 upgrade does not set environ-uuid <juju-core:Won't Fix by thumper> <https://launchpad.net/bugs/1519403>03:07
=== mwenning is now known as mwenning-afk
mupBug #1519403 opened: 1.24 upgrade does not set environ-uuid <juju-core:Won't Fix by thumper> <https://launchpad.net/bugs/1519403>03:10
thumperwow mup is confused03:12
mupBug #1519403 changed: 1.24 upgrade does not set environ-uuid <juju-core:Won't Fix by thumper> <https://launchpad.net/bugs/1519403>03:16
mupBug #1519403 opened: 1.24 upgrade does not set environ-uuid <juju-core:Won't Fix by thumper> <https://launchpad.net/bugs/1519403>03:19
mupBug #1519403 changed: 1.24 upgrade does not set environ-uuid <juju-core:Won't Fix by thumper> <https://launchpad.net/bugs/1519403>03:22
axwthumper: do you think it would be reasonable to reject upgrading to 2.0 if the env has no UUID?03:47
axwthumper: ... or is there always a UUID now?03:48
thumperaxw: ummm.... can you explain more?03:48
thumperyou mean cached locally?03:48
axwthumper: in environs/config there's a "ok bool" on UUID that says if the config has a UUID or not03:48
axwthumper: is it only the client that might not have one?03:48
thumperconfig that comes from the environments.yaml will not have a UUID03:48
thumperit is expected that all servers will have one03:49
thumperas of 1.20, it is cached in response to API connections03:49
thumperas of 1.24 or 1.25, it is written to the cache as part of bootstrap rather than the first connect after bootstrap03:50
axwthumper: ok, cool. it would be nice if 99% of callers didn't have to use the (UUID, bool) call03:50
thumperas of 2.0, there is no environments.yaml03:50
axwleading to confusing me :)03:50
thumperso this should no longer be an issue03:51
thumpermore cleanup03:51
axwthumper: excellent03:51
wallyworldaxw: we do need to pass the series to the backend. if the user overrides the series, we can't put that into the charm url and just pass that as we do now, because the modified charm url will not be resolvable in the store as it doesn't exist03:57
wallyworldso we need to record the true charm url and user specified series separately03:57
wallyworldthis applies when the user forces a series not supported by the charm03:58
axwwallyworld: why do we resolve the URL in the backend?03:58
axwwallyworld: or try to fetch it on the backend03:58
wallyworldi'd have to check the code again but we do03:58
wallyworldwe call repo.Resolve() server side03:58
wallyworldto add the charm to state03:59
wallyworldfrom emmory03:59
axwwallyworld: ok03:59
wallyworldaxw: i had the same thought as you originally but ran into these issues03:59
wallyworldwhen i tested live with series override03:59
axwwallyworld: what exactly is hte issue with revision in the URL? you've taken out the revision in the bundle tests, but surely we still need to be able to specify revision somehow04:09
wallyworldaxw: you can only specify revision if a series is in the url, so name-42 is not allowed but trusty/name-42 is. these changes are upstream charmstore changes04:10
wallyworldsince in a multi-series world they reckon name-42 is ambiguous04:10
wallyworldnot sure i agree tbh04:10
axwwallyworld: yeah, likewise. in any case, you removed revision from trusty/wordpress and wordpress both04:11
wallyworldworks either way, i can add it back to the trusty case04:11
wallyworldmust have been a typo04:11
axwwallyworld: for a new charm with series in metadata, can you resolve a URL with series if the series is supported?04:30
axwwallyworld: ok, good. so it's just unsupported series that you can't resolve. makes sense04:31
davecheneywallyworld: axw mgz can someone trigger a run of this job please http://juju-ci.vapour.ws:8080/job/run-unit-tests-race/04:49
axwdavecheney: sure, if I can work out how04:49
wallyworlddavecheney: what revision_build?04:50
axwwas about to ask04:50
wallyworldi'm not sure what to type in there04:51
davecheneywallyworld: axw04:51
davecheneyi have no idea04:51
davecheneyits supposed to be automatic04:51
davecheneyi've tried feeding it a revisoin and it barfs04:51
axwdavecheney: I think it's dependent on the build-revision job, which hasn't run for ToT yet04:51
davecheneythere is some extrenal process that kicks off the job04:51
davecheneybut i don't know what it is04:51
davecheneytot ?04:51
axwtop of tree04:52
davecheneyworst alias for master, ever04:52
axwyes, that one04:52
axwworking in LLVM has messed with my brain04:52
davecheneyseek professional counciling04:53
davecheneyis it possible to bump the build-revision job ?04:53
davecheneyoh, my other gripe about the race job04:53
davecheneyif you stop the job04:53
davecheneybecuase it's testing a branch that you know won't pass04:54
davecheneysomething resubmits that job04:54
axwdavecheney: trying a new build-revision now04:54
axwdavecheney: race job is running now05:03
wallyworldaxw:  lts and model series are validated now06:14
axwwallyworld: ta, looking06:15
wallyworldthanks axw, have to wait to land after charmstore is cut over06:38
=== Makyo is now known as Guest70426
=== meetingology` is now known as meetingology
=== JoseeAntonioR is now known as jose
=== JoseeAntonioR is now known as jose
=== marlinc_ is now known as marlinc
mupBug #1519527 changed: MAAS 1.9b2+ with juju 1.25.1:  lxc units all have the same IP address <openstack> <sts> <uosci> <MAAS:Triaged by mpontillo> <MAAS 1.9:Triaged by mpontillo> <MAAS trunk:Triaged by mpontillo> <https://launchpad.net/bugs/1519527>08:13
=== wgrant is now known as Guest42266
=== tasdomas` is now known as tasdomas
frobwaredimitern_, ping09:16
dimitern_frobware, pong09:17
voidspacedooferlad: just to let you know I'm blocked on the fixed range stuff09:19
dooferladvoidspace: OK, I should be on that soon.09:20
dooferladvoidspace: just juggling multiple tasks :-(09:20
=== mup_ is now known as mup
=== MmikeM is now known as Mmike
dimitern_voidspace, jam, fwereade, standup?10:00
=== dimitern_ is now known as dimitern
voidspacedimitern: omw10:03
dooferladfrobware: if you are trying to hangout in Firefox and having sound problems then try Chrome - I had a similar issue.10:11
=== akhavr1 is now known as akhavr
axwdooferlad: sorry, I brainfarted - of course it should be possible for the keepalive goroutine to be reentered. re-reviewing that bit now10:36
dooferladaxw: no problem10:36
dooferladaxw: thanks for taking another look.10:36
frobwaredooferlad, voidspace, dimitern: looks like most folks have either declined or maybe'd the OS call today - I propose we cancel unless there are some agenda items10:37
dooferladfrobware: +110:38
dimiternfrobware, sgtm10:39
dooferladvoidspace: AddFixedAddressRange change just pushed10:46
dooferladvoidspace: making SetNodeNetworkLink nicer now.10:46
dooferladvoidspace: and now the SetNodeNetworkLink update you asked for is done.10:52
voidspacedooferlad: awesome, thanks11:45
voidspacedooferlad: hmmm... setting the range with the new api doesn't *seem* to work11:52
voidspacedooferlad: digging in (will check the test code to see if I'm doing it right)11:52
dooferladvar ar AddressRange11:52
dooferladar.Start = ""11:52
dooferladar.End = ""11:52
dooferladar.Purpose = []string{"dynamic"}11:52
dooferladts.AddFixedAddressRange(subnet.ID, ar)11:52
voidspacedooferlad: and also I still get nil back instead of an empty array when there are no ranges11:52
dooferladwhere ts is the test server11:52
voidspacedooferlad: suite.testMAASObject.TestServer11:52
voidspacedooferlad: that's *exactly* what I'm doing11:53
voidspaceand reserved_ip_ranges for that subnet returns null11:53
dooferladvoidspace: http://pastebin.ubuntu.com/13513986/ is my little live test server11:54
dooferladClearly you need to have something to run it...11:55
dooferladhttp://pastebin.ubuntu.com/13513993/ for example11:55
dooferladfrom http://localhost:6776/api/1.0/subnets/1/?op=reserved_ip_ranges I get http://pastebin.ubuntu.com/13513997/11:56
voidspacedooferlad: try it without the call to NewIPAddress11:57
voidspaceI have a hunch11:57
voidspacestill hacking my code to try it11:57
dooferladvoidspace: good hunch11:57
voidspacedooferlad: early short circuit in your code11:57
voidspacedooferlad: ok, so my code now runs11:58
voidspacedooferlad: however the tests pass, which is bad - they should fail because now the allocatable range should be different11:58
voidspacedooferlad: but that's probably a bug in my code :-)11:58
voidspacedooferlad: I can remove the adding of the extra IPAddress once that's fixed11:59
dooferladvoidspace: fixed and pushed.12:00
voidspacedooferlad: that was quick :-)12:00
dooferladvoidspace: oh hang on. Fscked up. Wrong repo.12:03
dooferladvoidspace: try now12:03
voidspacedooferlad: I have a suspicion my Purpose may be being overwritten12:04
voidspacethat may not be true12:04
voidspacebut I'm not seeing the range with the right Purpose yet12:05
voidspacedooferlad: hah no, typo in my code12:06
voidspacedooferlad: and it's found another bug in my code :-)12:13
voidspaceI was using net.IP(..) not net.ParseIP(...)12:14
dooferladvoidspace: success!12:14
voidspacedooferlad: and now it's done12:14
voidspacedooferlad: yep, mine is ready to land12:14
voidspacedooferlad: (or at least ready for review)12:14
voidspacedooferlad: is your branch proposed?12:14
dooferladvoidspace: sweet! I will propose my branch now.12:14
dooferladvoidspace: https://code.launchpad.net/~dooferlad/gomaasapi/subnets/+merge/27834212:16
voidspacedooferlad: great12:16
voidspacedimitern: frobware: dooferlad: http://reviews.vapour.ws/r/3252/12:18
dimiternvoidspace, looking12:19
mupBug #1520199 opened: provider/maas: better handling of devices claim-sticky-ip-address failures and absence of reserved IP address <kanban-cross-team> <maas-provider> <reliability> <tech-debt> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1520199>12:32
frobwarevoidspace, looking12:34
mattywis anyone around today?13:04
dimiternvoidspace, reviewed13:07
voidspacedimitern: thanks13:30
voidspacedimitern: I didn't make dummy provider configurable because it's not needed as part of this PR13:31
voidspacedimitern: it can be made configurable when it's needed13:31
voidspacedimitern: and I don't think you're right about the space name transforming code13:32
voidspacedimitern: we store juju name and provider name and we need to be able to convert between them13:32
voidspacedimitern: so it shouldn't return an error13:33
voidspacedimitern: and yet again I disagree with your comments about nesting structs in tests13:34
voidspacedimitern: I think it makes them much harder to read13:34
voidspacedimitern: whitespace is good!13:34
dimiternvoidspace, too much whitespace can kill you know :D13:36
voidspacedimitern: that's propaganda, there are no known cases13:36
voidspacedimitern: I think collapsing them will make them uglier13:36
dimiternvoidspace, I disagree about the space names not needing to validate the juju name13:37
voidspacedimitern: I can wrap them in a helper as per  one of your other sessions13:37
voidspacedimitern: we do validate - that's what my code does13:37
voidspacedimitern: it transforms into a valid namme13:37
voidspacedimitern: so it can't return an error13:37
dimiternvoidspace, how about tests where you get a space13:37
dimiternvoidspace, like "#$^#$^" from maas?13:37
voidspacedimitern: what do you want to do with them?13:38
voidspacedimitern: we haven't defined that behaviour yet - so just changing the name of the existing function won't help that case13:38
dimiternvoidspace, report an error, rather than pass it happily back to the apiserver and fail on import13:38
voidspacedimitern: what error?13:39
voidspacedimitern: you haven't defined the error cases13:39
voidspacedimitern: and we *still* need a transform13:39
voidspacedimitern: why shouldn't we use #$^ as a space name13:39
dimiternvoidspace, ok, can we then at least replace not just " " -> "-", but also any invalid chars for a juju space name to "_"13:39
dimiternvoidspace, because that would be unusable in constraints or anywhere pretty much13:40
voidspacedimitern: where are the valid characters defined13:40
voidspacedimitern: can't you use strings for constraints - no escaping?13:41
dimiternvoidspace, check names.IsValidSpace13:41
voidspace(as in use quotes)13:41
voidspacedimitern: ok, thanks13:41
voidspacedimitern: I still think you need therapy for your anti-whitespace prejudice13:41
voidspacedimitern: I good course of Python should help13:42
dimiternvoidspace, I like whitespace, in general, but having 3 levels of mostly empty lines (except for "{") nested moves the EOL too much for my taste when reading the code, but I guess that's just me13:43
dimiternvoidspace, and the same goes for too long lines that can be wrapped nicely, instead of arbitrarily according to various editor settings13:45
voidspacedimitern: well, the edit you're suggesting would result in *massively* long and completely unreadable lines13:45
voidspacewhereas as it is I can just glance at it and understand it13:45
voidspacethe whitespace shows up the structure as well as making the contents easier to read (single member per line)13:46
dimiternvoidspace, with the risk of wasting a couple more minutes on an issue with hardly any consequence, what's unreadable?13:46
voidspaceso I genuinely disagree and don't see the problem13:46
voidspacecollapsing all the whitespace into a single line13:46
voidspaceas you suggest13:46
voidspace []network.SpaceInfo{{ .. }, { .. }}13:47
voidspacethat would be one line of about three hundred chars13:47
voidspaceor more13:47
voidspace800 maybe13:47
voidspaceand just breaking the line, instead of using whitespace for structure, means you have to pick along it to work out where members are13:48
voidspacethere's a reason that all json pretty printers use whitespace to show structure13:48
voidspacebecause it makes data structures easy to read13:48
dimiternvoidspace, I'm not saying use v := []map[string]string{map[string]string{"foo":"bar","one":"two"},map[string]string{"bar":"baz", "four":"five"}}13:48
voidspaceit makes the vertically verbose but easy to scan13:48
voidspacedimitern: well, that's *specifically* what you say13:48
dimiternvoidspace, I'm not saying use v := []map[string]string{ \n \t map[string]string{"foo":"bar","one":"two"}, \n \t map[string]string{"bar":"baz", "four":"five"}}\n13:49
voidspacedimitern: I still think the SubnetInfo as single lines would be too long and harder to read13:50
dimiternvoidspace, oops anyway - I meant multi-line, but some braces together on the same line, rather than having "{\n" followed by "{\n" etc13:50
voidspacedimitern: ok, I'll see how that looks13:50
voidspacethat maybe fine to me and would lose a level of indentation13:50
voidspacefair enough13:51
dimiternI should've pasted a formatted snippet rather than being lazy and trying to express what I meant on one line13:51
mupBug #1520247 opened: TestContainerProvisionerStarted fails due to unknown container type: lxd <ci> <lxd> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1520247>14:05
mgz_version bump review please: http:..reviews.vapour.ws/r/3254/14:34
mgz_non-americans, rally to the cause! plzreviewplz15:10
frobwaremgz_, done15:41
voidspacedimitern: I totally misunderstood!15:44
voidspacedimitern: where you said "please call IsValidSpace" I misread it as "please call the function" (i.e. rename) IsValidSpace15:45
voidspacedimitern: I agree with you :-)15:45
mgz_frobware: merci15:45
mgz_we may actually not do a 1.26-alpha3 - but I also don't want to handle a major version bump in the code right now15:46
mupBug # changed: 1261780, 1493602, 1496652, 1499277, 1511135, 1513236, 1515736, 151734415:54
mupBug #1520292 opened: Upgrade from 1.21.3 -> 1.22.8 -> 1.23.3 fails with 'ERROR a hosted environment cannot have a higher version than the server environment: >' <sts> <juju-core:New> <https://launchpad.net/bugs/1520292>15:54
dimiternvoidspace, oh :)15:59
voidspacedimitern: yeah, oops...16:00
dimiternvoidspace, no worries16:00
mgz_I think we need a basic-of-git session in a couple of weeks16:10
voidspacedimitern: ping16:25
voidspacedimitern: so we have to decide what to do with invalid space names16:26
voidspacedimitern: do you think that converting invalid chars to "_" is the right thing to do?16:26
voidspacedimitern: if we error out instead we either have Spaces/Subnets return an error when they encounter an invalid space name16:27
voidspacedimitern: which would mean you can't use *any* spaces or subnets if one of the space names is invalid16:27
voidspacedimitern: or we just drop the invalid space and its subnets16:27
voidspacedimitern: but if we do multiple character substitutions we risk name clashes (two different MAAS spaces being seen as the same juju space)16:28
dimiternvoidspace, I think we need to be consistent16:29
voidspacedimitern: we need to eat too16:30
voidspacedimitern: but that doesn't answer the question either... ;-)16:30
dimiternvoidspace, sorry, typing still..16:30
voidspaceI agree we *must* be consistent16:30
voidspaceI'm only teasing16:30
dimiternvoidspace, if a maas space name cannot be converted to a valid juju space name, we can use a generated name or ask user to provide one16:31
voidspacedimitern: how can we ask the user to provide one?16:31
dimiternvoidspace, or both (i.e. use a generated-but-valid when importing, and allow the user to rename it)16:31
dimiternvoidspace, if we added them manually, that wouldn't be an issue, as we ask for a name anyway16:32
voidspacedimitern: right16:32
dimiternvoidspace, but the problem is with auto importing16:33
voidspacedimitern: however, the provider has no access to state - so that will have to happen a layer above the provider16:33
voidspacedimitern: I'm almost tempted to remove SpaceName from SpaceInfo and SubnetInfo and only use ProviderSpaceId16:33
dimiternvoidspace, yeah - so doesn't that imply we shouldn't try to convert them in the provider ?:)16:33
voidspaceand let the conversion happen elsewhere16:33
dimiternvoidspace, that sounds better than inventing names16:33
voidspacedimitern: well, it doesn't avoid the problem - just moves it...16:34
voidspacebut moving it out of *my* code is fine16:34
dimiternvoidspace, well, we should talk to the provider with names/ids it understands16:34
voidspacedimitern: yep16:34
dimiternvoidspace, but the translation needs to happen in the apiserver I think16:34
voidspacedimitern: I'll leave SpaceName on SpaceInfo but remove it from SubnetInfo16:34
dimiternvoidspace, we do have a similar case already - with relation tags16:35
voidspaceah right16:35
dimiternvoidspace, since "relation-#" is the tag format but can't be converted to the other form "svc1:rel1 svc2:rel2", there's an api call to do that16:35
dimiternvoidspace, I had a similar issue to solve with subnetsToZones - so the provisioner apiserver facade does the translation between juju id (cidr) and provider subnet id16:37
dimiternbefore calling start instance16:38
fwereadeif anyone feels like punishing themselves, http://reviews.vapour.ws/r/3255/ is another monster :-/16:56
fwereadebut it has a number of pleasing features, and a *lot* of it is moves/renames that both GH and RB are getting confused by16:57
mupBug #1520314 opened: Environment not usable after upgrade from 1.21.3 -> 1.25.0 fails with '"cannot retrieve meter status for unit xxx/0: not found"' <sts> <juju-core:New> <https://launchpad.net/bugs/1520314>17:03
voidspacedimitern: ping18:27
voidspacedimitern: does MAAS support ipv6 subnets?18:30
voidspacedimitern: looks like it does, but you can only have one ipv6 subnet per interface18:33
voidspacedimitern: https://maas.ubuntu.com/docs/ipv6.html18:33
=== beisner- is now known as beisner
frobwarevoidspace, part me says land something with ipv4, then we can look at ipv6. thoughts?19:15
=== akhavr1 is now known as akhavr
voidspacefrobware: yeah, that's maybe good enough for now19:38
voidspacefrobware: ipv6 needs careful thinking about19:38
voidspacefrobware: in which case, it's done19:38
voidspacethat was the last issue19:38
=== akhavr1 is now known as akhavr
=== mwhudson_ is now known as mwhudson
thumpermorning team20:33
thumperI'm going to be looking into the instance poller and presense code today20:33
thumperas it appears to not be working, and will impact the HA ability20:33
thumperwhat I observed yesterday on EC2 with 1.25 was a working HA system, up until I took down machine-020:33
thumperThe machine was never shown as missing, and all the calls around HA, rsyslog worker etc that need the addresses of the state servers kept saying that machine-0 was good20:34
thumperand the workers would die because they couldn't connect to it20:34
thumperthis also stopped all logs flowing from all machines as the rsyslog worker kept restarting20:35
thumperso, I'm going to check the logging that I can ratchet up for instance polling and presense, possibly add some extra, and try to reproduce20:35
=== beisner- is now known as beisner
* thumper headdesks21:05
thumperoh FFS21:07
thumperthe instance poller worker takes the "instance not found" error, and logs a warning, then returns nil for the error21:08
thumperit's all good21:08
mgz_heya thumper21:30
thumpero/ mgz_21:30
davechen1ythumper: kill.it.with.fire21:36
mgz_menn0: when you have a chance, can you look over bug 1520314?21:45
mupBug #1520314: Environment not usable after upgrade from 1.21.3 -> 1.25.0 fails with '"cannot retrieve meter status for unit xxx/0: not found"' <sts> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1520314>21:45
menn0mgz_: will take a look soon22:08
thumperthat's how I feel reading this code22:14
thumperI have a very strong suspicition that this code may deadlock an agent coming down in some situations22:15
thumperbecause naken channel writes and reads are fine right?22:15
thumperno problem there22:15
* thumper has to close up and go and move some kids22:21
mupBug #1520373 opened: stopped instance in EC2 always considered "started" <juju-core:Triaged> <https://launchpad.net/bugs/1520373>22:27
menn0mgz_: you still around?22:47
mgz_menn0: yo22:51
menn0mgz_: looking at bug 1520314, your big comment implies you tried the upgrades yourself. is that right?22:52
mupBug #1520314: Environment not usable after upgrade from 1.21.3 -> 1.25.0 fails with '"cannot retrieve meter status for unit xxx/0: not found"' <sts> <upgrade-juju> <juju-core:Triaged by menno.smits> <juju-core 1.25:In Progress by menno.smits> <https://launchpad.net/bugs/1520314>22:52
menn0or were you just looking at the logs?22:52
mgz_menn0: no, I read the logs22:52
menn0ok right22:52
menn0mgz_: do you know who the env was being deployed/22:53
mgz_niedbalski tried to repo, but hit some other 1.23 weirdness in bug 152029222:53
mupBug #1520292: Upgrade from 1.21.3 -> 1.22.8 -> 1.23.3 fails with 'ERROR a hosted environment cannot have a higher version than the server environment: >' <bug-squad> <sts> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1520292>22:53
mgz_menn0: dtag22:53
menn0mgz_: sorry, I meant "how" not "who"22:54
mgz_would have been deployer, in stages22:55
menn0mgz_: do I have access to that and are there any instructions you know of?22:55
mgz_no, reproducing the deployments we do on site is kind of an ongoing pain22:56
mgz_I have a google doc for dtag overall, not sure if it's the same steps we're looking at here though22:57
menn0ok fair enough22:57
* menn0 digs22:57
mgz_I emailed you a link.22:58
menn0mgz_: thanks22:58
thumpermgz_: that bug 1520292 above, the only way that could occur is if there is juju 1.25 in the mix somehow23:01
mupBug #1520292: Upgrade from 1.21.3 -> 1.22.8 -> 1.23.3 fails with 'ERROR a hosted environment cannot have a higher version than the server environment: >' <bug-squad> <sts> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1520292>23:01
thumperthat error doesn't exist in the codebase before 1.2523:01
mgz_thumper: my assumption is the staged upgrade was continued, but it was in the borked-1.23 status23:01
mgz_so, we had agents on all different versions muddled up23:02
thumperI'm prepared to say won't fix for anything that goes through a 1.23 version23:02
thumperthat was so full of ail23:02
mgz_we don't seem to have communicated that well, even to the guys we have deploying stuff for customers23:03
mgz_(I agree, it's what I said in the bugs)23:03
menn0mgz_, thumper : we should get 1.23 out of the public streams23:05
menn0there really is no reason to let anyone use it23:05
mgz_I was thinking about that, does it screw up existing deployments at all?23:05
mgz_we're already sticking tools in mongo in 1.23, are there any circumstances we go back to streams for the current tools version?23:07
mgz_the original promise was we never remove anything from streams once added.23:08
menn0mgz_: I guess it needs some thought by various people23:09
mgz_if only we were getting the relevent people in the same place some time soon23:09
menn0mgz_: shall we get it on the agenda then?23:11
wallyworldanastasiamac: standup?23:17
davechen1ythumper: i can apply the same methodology using build tags to exclude failing packages from building with go > 1.2 ?23:49
davechen1yand get wily and xenial passing23:49
davechen1ythen voting23:49
=== beisner- is now known as beisner

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