* redir eod00:15
redirthanks for the clue axw00:15
menn0thumper: http://reviews.vapour.ws/r/5404/ pls01:40
thumpermenn0: done01:49
menn0thumper: thanks01:49
menn0thumper: dropped your issue (with an explanation)01:52
=== natefinch-afk is now known as natefinch
natefinchaxw: I couldn't tell, did you and William come up with a magic way to make (un)marshaling work nicely with jsonschema and our extra properties?  Seems like the least amount of work would be to define schemas in yaml strings and marshal into Schema, with helpers to get metadata out of the "extras".  Not elegant, but a lot less work than making our own custom jsonschema struct.02:13
axwnatefinch: we did not02:17
natefinchaxw: any preference?02:18
axwnatefinch: I'd prefer if it wasn't just a blob of text, but I'm unsure of how it'd look in the end. I guess you would have to duplicate the entire Schema type02:20
axwand SchemaList etc.02:20
natefinchI think forking that schema package and adding our properties would also be easy enough... just sort of a maintenance burden to keep up with upstream (which looking at gojsconschema, we usually just don't do).02:20
axwnatefinch: I'd prefer if we didn't fork02:20
axwfor that reason02:20
natefinchit sucks that there's no nice way to make recursive data structures easily extensible02:22
natefinchaxw: so... you're saying we're boned :)02:24
axwnatefinch: I don't think so? I think we can duplicate the *types* from the jsonschema package, and then introduce functions to extract/inject the from/into the Extras field02:25
axwnatefinch: we would still rely on the jsonschema package for all of the standard parsing and validation02:26
natefinchaxw: interesting, ok.02:28
natefinchaxw: the tricky thing is that unmarshaling into the Schema type is all hand coded in that go-jsschema package, I think mostly because the rules for jsonschema are really wacky (values that can be a boolean or a list of strings, for example).  Some of it may be overengineered... but I'm guessing we might want to copy a lot of the logic in how to unmarshal... which might make it better to just fork the package outright.02:34
natefinchNote that the validation is actually in a subpackage, the main package is just the types and unmarshalling.02:34
axwnatefinch: I'll have a poke and see if I can come up with something that looks workable02:40
axwnatefinch: https://gist.github.com/axw/0d395b86aa5ac9ee0c4f18a3ca81cb6803:19
axwnatefinch: you would need to have a "toInternal" to do the opposite, putting the juju bits back into the Extras map03:19
menn0axw or thumper: fairly easy one: http://reviews.vapour.ws/r/5405/03:20
axwnatefinch: I dropped all of the json tags from the cloned struct. instead of having tags, you'd have a MarshalJSON and UnmarshalJSON that use from/toInternal03:20
axwmenn0: looking03:20
natefinchaxw: right03:21
natefinchaxw: it's funny, the jsschema thing has custom json (un)marshaling too, so the json tags aren't really used.03:21
natefinchaxw: that looks pretty good. Reusing as much as possible from the internal type, just replacing the recursive part.  Very nice.03:22
axwmenn0: LGTM03:25
menn0axw: (delayed) tyvm04:33
* thumper waits for the featuretest package to run tests...05:04
thumpershould have used -check.v05:04
thumperhow long to wait...05:04
thumperkilled it05:05
thumperPASS: dblog_test.go:149: debugLogDbSuite.TestLogsAPI0.005s05:05
thumperOK: 1 passed05:05
thumperok  github.com/juju/juju/featuretests7.662s05:05
thumper5ms to run the test, the rest of 7.6 seconds for setup / teardown05:05
jammenn0: are you still around?05:46
menn0jam: yes, for a few more minutes05:55
=== frankban|afk is now known as frankban
jammenn0: sorry I ended up missing you, I'll see you at the tech board if you can make it07:54
rogpeppeballoons: the best way is to migrate all the leaf repositories first, then juju-core itself08:00
babbageclunkmenn0: ping?08:22
menn0babbageclunk: hi, in tech board call atm08:27
babbageclunkmenn0: ok08:27
menn0babbageclunk: done!09:13
menn0babbageclunk: I imagine you're bugging me about the email you sent which I didn't reply to?09:14
babbageclunkmenn0: Hi! Yes!09:14
menn0babbageclunk: sorry... I was trying to staying focussed on migrations so email took a back seat today09:14
menn0babbageclunk: I'll reply now but the short answer is that you don't need to worry about migrations for what you're working on09:15
menn0babbageclunk: a migration will abort early if there's any dying/dead machines or units09:15
babbageclunkmenn0: Ok - so I can ditch that commit then?09:16
babbageclunkmenn0: No need to reply right now if that's the takeaway.09:17
menn0babbageclunk: yep, you can ditch that... there will be a higher level check for dying machines09:17
babbageclunkmenn0: Sweet, thanks!09:18
menn0babbageclunk: should be working on prechecks this week09:18
fwereademenn0, if you're still around... the nsWhatever thing09:51
babbageclunkfwereade: I can't see any way of testing apiHandler.ConnectedModel without either adding the test to a suite based on JujuConnSuite (so I can call TestingApiHandler) or adding another TestingApiHandler* func to apiserver/export_test (so I can specify a UUID directly).09:51
fwereademenn0, I feel like I want *some* way to visibly distinguish these (basically) static/stateless types09:52
fwereadebabbageclunk, hmm09:52
babbageclunkfwereade: I'm aware that both are eyebrow-provoking.09:52
fwereadebabbageclunk, let me look09:52
fwereadebabbageclunk, wouldn't surprise me if the use-existing-JujuConnSuite were the pragmatic approach09:52
babbageclunkfwereade: ok, I'll put my test in one of those for now.09:53
fwereadeperrito666, ping re Authorizer.HasPermission09:55
fwereadeperrito666, ehh, don't worry about it10:00
* fwereade needs someone to talk to about structuring/naming some things in state, is off for a ciggie, would be delighted if someone were willing to chat in a few minutes10:01
perrito666fwereade: i am just waking up, if you want I can ping you in a moment?10:01
fwereadeperrito666, ofc10:13
fwereadejam, dimitern, babbageclunk: I am going to waffle vaguely about the ns* types I've been adding to state, please jump in if anything springs to mind10:19
dimiternfwereade: sure ;)10:19
fwereadein the payloads work, we made a stab at separating persistence from business logic10:19
fwereadeand it wasn't entirely successful, but when I moved the necessary payloads bits into state, I tried to preserve the distinction10:20
fwereadeand I ended up with an exported Payloads type that clients use, and an unexported `type nsPayloads_ struct{}` to hold all the internal methods that actually implement the persistence side10:21
fwereade(and an unexported `var nsPayloads nsPayloads_` to actually call methods on)10:22
fwereadeand it's nice that it's entirely stateless, and it has methods like `untrackOp(coll mongo.Collection, docID string) (txn.Op, error)`10:24
fwereadeso I'm pretty happy with the *structure*10:24
fwereadebut the "nsFoo" naming style has raised many eyebrows10:24
fwereadeso the *easy* thing to do is just to drop the ns stuff10:25
fwereadeand just have refcounts.CreateOrIncRefOp, and life.notDeadOp, and so on10:25
fwereadethe style, while I think it is good, is somewhat at odds with the stateful-model-type approach we're currently using almost everywhere10:26
fwereadeand I can't help but feel it needs *something* to clearly and visibly distinguish it from... all the other code10:27
fwereadeam I overthinking this? from a certain perspective the prefix tells you very little, whatever it might be10:27
dimiternfwereade: so you separate the external interface of Payloads from the low-level ops, which go in the ns* internal type?10:27
fwereadedimitern, yeah10:27
dimiternfwereade: ns for namespace.. I could say it's not quite obvious at first10:29
dimiternfwereade: I mean namespaces vs entities10:29
fwereadedimitern, (and in payloads, because it uses that mechanism exclusively, I can implement the Payloads thing largely in terms of distinct Change types which themselves use the ns type)10:29
dimiternfwereade: things we store10:29
fwereadedimitern, yeah, indeed10:29
fwereadedimitern, it is evidently not obvious10:29
dimiternfwereade: how about persistence ? too long I guess..10:30
* xnox is failing to bootstrap localhost provider with 2.0 beta14 on xenial =(10:30
fwereadedimitern, yeah, I guess that's the obvious one, but I rue all the characters it costs every time you want to use it10:30
dimiternfwereade: backing is shorter, and already used here and there10:31
dimiternit's not perfect though..10:31
dimiternxnox: about lxdbr0?10:32
fwereadedimitern, the other solution is to pull them out into their own packages, which is clearly what they *want* to be, but I don't think I can do it non-invasively10:32
fwereadedimitern, state/persistence/life etc10:32
xnoxdimitern, tools info mismatch10:32
fwereadedimitern, you know, the more I talk, the less I care about having any prefix at all10:33
dimiternxnox: oh..10:33
fwereadedimitern, if they ever make it into packages it'll just be `life.notDeadOp(...)` anyway10:33
dimiternfwereade: having the prefix is fine I think10:33
fwereadedimitern, that's seemed to be the major sticking point for people though10:34
dimiternfwereade: the underscore suffix is making me wince a little10:34
xnoxdoes 2.0 need agent-stream: devel ?10:34
xnoxERROR failed to bootstrap model: cannot start bootstrap instance: tools info mismatch ({2.0-alpha1-xenial-amd64  b67c1484745bd58e7fac6ad672a7f6e45042ebef7a1e0e995f3f0f3c2baa7d33 18556414}, {2.0-alpha2-xenial-amd64  ceb165a45206eddadc06a7c986b44a3f76195c71a317d0c87810727c71bcc0f8 18073871})10:35
xnox$ juju bootstrap --config agent-stream=devel localhost localhost10:36
xnoxseems to work better,10:36
xnoxhowever specifying --config cancels "interactive" mode of juju bootstrap10:36
dimiternxnox: nice! I usually always bootstrap from src with --upload-tools10:36
dimiternxnox: yeah any args do that10:37
dimiternfwereade: if not ns how about stored? e.g. storedPayloads10:40
dimiternfwereade: saved ?10:40
dimiternfwereade: dbPayloads even :D10:42
fwereadedimitern, yeah, if you can see a way around the suffix that'd be nice, but you only see that when you're implementing it10:43
fwereadedimitern, hmm10:43
fwereadedimitern, dbPayloads10:43
fwereadedimitern, I think maybe I like that10:43
dimiterndb is short and more obvious yeah10:43
fwereadedimitern, awesome, tyvm10:43
dimitern:) np10:44
fwereadejam, babbageclunk: any thoughts? ^^ or anyone else? :)10:44
* dimitern as usual has a lot of things needing attention.. sinks back to bugs10:47
perrito666ok, this is completely new to me: alarm notification buffer full11:04
babbageclunkfwereade: Sorry, was following but didn't have much to add. I definitely like db better than ns. I don't think the suffix is a problem, since you only have to look at it in the implementation.11:10
fwereadebabbageclunk, cheers :)11:11
babbageclunkfwereade: Also, ns is used a lot in iOS objective-C development (from NextStep), so it's weird seeing it in Go code. :)11:12
babbageclunkOops NeXTSTEP apparently.11:12
fwereadebabbageclunk, a sense of happy familiarity with the NS prefix did sort of come into it, even if it's ultimately unhelpful11:13
dimiternfwereade: m_lpszDataSource evokes that sort of familiarity for me, but with the opposite sign :)11:16
fwereadedimitern, hahaha11:17
babbageclunkdimitern: lol11:17
fwereadedimitern, I wish they'd done hungarian notation right11:17
dimiternoh MFC days...11:17
perrito666does anyone know if the clock interface recently changed?11:25
dimiternperrito666: rogpeppe was talking about changing something there recently IIRC11:26
rogpeppedimitern, perrito666: i haven't actually changed anything recently AFAIR11:26
rogpeppedimitern, perrito666: though I have an unfinished PR that revamps the testing clock stuff and the interface11:27
dimiternrogpeppe: ah ok - wasn't the discussing around alarms though? timers?11:27
rogpeppedimitern, perrito666: i just need to find time to write some tests for it11:27
rogpeppedimitern: i wanted NewTimer11:27
dimiternrogpeppe: that's it11:27
rogpeppedimitern, perrito666: FWIW this is the PR in question: https://github.com/juju/testing/pull/108/files11:28
perrito666rogpeppe: I am getting a strange panic in tests (pastebining now)11:29
perrito666Ill now go see how in the universe I triggered that without even going near it11:30
rogpeppeperrito666: you can fix that by reading from the clock.Alarms channel11:31
perrito666rogpeppe: I am curious on how I originally broke that (more than the actual fix) :)11:32
rogpeppeperrito666: tbh i think that that clock code shouldn't panic in that case11:32
perrito666I mean, I know what I changed, I agree with you that this thing should definitely not panic11:33
dimiternperrito666: I suspect you're using juju/testing/clock whereas before you used juju/juju/testing/clock11:35
perrito666dimitern: I suspect someone made that change and I made a change and we both clashed :p11:35
rogpeppedimitern, perrito666: please, please can we change everything to use juju/testing/clock and remove juju/juju/testing/clock ?11:35
perrito666rogpeppe: sure you can, ill review the PR :p11:36
rogpeppedimitern, perrito666: there's no need for both to exist11:36
dimiternrogpeppe: I don't mind that :)11:36
rogpeppeperrito666: most of what i do these days seems to be juju-core code cleanups11:36
perrito666rogpeppe: and we love you for it11:37
dimiternrogpeppe: indeed <3 :)11:37
rogpeppeperrito666: speaking of which... did you see this? https://bugs.launchpad.net/juju-core/+bug/161137911:38
mupBug #1611379: api/backups: restore code needs improvement <juju-core:New> <https://launchpad.net/bugs/1611379>11:38
perrito666"needs improvement" is perhaps the bigest understatement in history of mankind11:38
rogpeppeperrito666: well, i thought i might be out of order to say "this code is fucking shit" :)11:39
rogpeppeperrito666: in a bug report11:39
rogpeppeperrito666: anyway, i rewrote it, but didn't have time to write the tests (the current code has no tests)11:39
rick_h_macgreagoir: can you review https://github.com/juju/juju/pull/5747 please, I did the QA to make sure it worked when you get a sec12:43
macgreagoirrick_h_: ack13:01
macgreagoirdimitern: Ready for HO when you are.13:02
dimiternmacgreagoir: ok, let's use the standup HO I guess?13:02
voidspacebabbageclunk: ping13:09
babbageclunkvoidspace: pong, sorry!13:15
niedbalskidimitern, https://pastebin.canonical.com/162703/ latest run13:19
niedbalskidimitern, after this the boot gets stuck.13:19
mupBug #1611764 opened: upgraderSuite.SetUpTest An existing connection was forcibly closed <ci> <intermittent-failure> <regression> <unit-tests> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1611764>13:31
mupBug #1611766 opened: upgradeSuite.TearDownTest sockets in a dirty state <ci> <intermittent-failure> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1611766>13:31
rick_h_voidspace: time to sync?13:32
voidspacerick_h_: yep13:33
balloonsrogpeppe, so I worked with Nate and perrito666 yesterday to get everything settled to do the changeover to the git version of gnuflag, but I've hit a snag. juju/romulus and juju/juju both reference each other. It's a circular dependency.13:34
* fwereade has a problem; is anyone up to date with the details of charm migrations?13:34
fwereadebabbageclunk, voidspace perhaps? ^^13:34
rogpeppeballoons: that is annoying13:34
rogpeppeballoons: but13:34
rogpeppeballoons: there's a way around it13:34
balloonsI guess my thought is does juju/romulus really need to depend on juju/juju? And if so, we have to land without attempting to build for the first commit of one of them -- unless you know something cooler we can do13:35
rogpeppeballoons: make a feature branch of either juju-core or romulus that uses only the github gnuflag13:35
rogpeppeballoons: unfortunately it does13:36
rogpeppeballoons: it's ok (temporarily) for a project to depend on a commit in a feature branch13:36
rogpeppeballoons: once you've landed romulus depending on the juju feature branch, you can make juju depend on that just-landed romulus branch13:37
rogpeppeballoons: then you can update romulus to depend on juju master again and delete the juju feature branch13:38
rogpeppeballoons: or you can do it the other way, making a feature branch in romulus13:38
balloonsthis sounds educational13:39
balloonsI think a feature branch in romulus would be preferred perhaps -- avoid invoking a CI run for instance13:39
rogpeppeballoons: good point13:42
babbageclunkfwereade: sorry, not me - voidspace has been doing a fair bit on migrations though.13:45
voidspacefwereade: babbageclunk: not charm migrations, no13:45
fwereadebabbageclunk, voidspace: not to worry13:47
fwereadebabbageclunk, voidspace: (fun fact: the data model *never* actually checked that a given charm existed before creating an application that used it)13:50
fwereadebabbageclunk, voidspace: (which is somewhat cramping my style re refcounting charms, there are a number of state tests that add apps without charms... and *all* migrated apps are added without charms, which are then filled in later)13:51
natefinchsinzui, mgz: the CI scripts ask for an environment... how do I pass a cloud and credentials?13:54
natefinch(running deploy_job.py)13:55
babbageclunkfwereade: doh13:58
rick_h_voidspace: natefinch dimitern standup ping14:01
mupBug # changed: 1502130, 1523608, 1556961, 158619714:10
sinzuinatefinch: the ci script only take an env. uses the clouds.yaml and credentials.yaml in cloud-city ($JUJU_HOME). the env is still needed to provide the config.14:15
=== ivyyyy-brb is now known as ivyyy
natefinchsinzui: so, the thing is, I need to be able to inspect the broken machine, and I thought we had established that I can't rdp into the machines brought up by the cloud-city creds14:36
mupBug #1611463 changed: GUI: test_upgrade_gui failed KeyError: 'bootstrap-config' <ci> <juju-gui> <regression> <unit-tests> <juju-core:Invalid by jcsackett> <https://launchpad.net/bugs/1611463>14:37
mupBug #1611789 opened: GUI: test_upgrade_gui failed KeyError: 'cloud' <ci> <juju-gui> <regression> <unit-tests> <juju-core:Triaged by jcsackett> <https://launchpad.net/bugs/1611789>14:37
sinzuinatefinch: I don't know how to do that with azure. Can we open rdp using the azure portal?14:40
natefinchsinzui: yes.  If I can log into azure with the right credentials14:41
sinzuinatefinch: ah. with azure you login as yourself. I can add you to the subscription14:41
natefinchsinzui: cool14:42
sinzuinatefinch: Register with azure with your canonical address. When Azure knows it, I can add you14:44
arosalesany work arounds folks know to kill a controller15:03
* arosales getting http://paste.ubuntu.com/22918062/15:03
arosalesI destroyed all the models separately15:03
natefinchsinzui: oh, can you just use my current azure account? it's nate.finch@gmail.com15:10
sinzuinatefinch: no, this is a canonical account15:10
natefinchsinzui: is that a can't or won't?  I really don't want to have to keep track of multiple microsoft accounts if I can avoid it15:14
sinzuinatefinch: I wont. and I understand the pain15:14
natefinchsinzui: I guess I don't understand why it matters what email address I used to sign up with15:15
sinzuinatefinch: this isn't my account. it is canonicals and it gets audited15:15
natefinchsinzui: ahh.  OK, I get it.15:15
natefinchsinzui: ok, I have a nate.finch@canonical.com azure account now15:20
sinzuinatefinch: reload the page in azure, I think you can see all the resource groups and vms15:20
natefinchsinzui: ahh yes, once I switch to your directory15:22
natefinchperrito666: works for me15:45
mgzballoons: you're not on the other network...15:50
mgzballoons: see lp:~juju-qa/ubuntu/yakkety/juju/juju-1.25.6 for the base branch without bug fixes or the per-series versions15:51
perrito666aghh 4 hours chasing an isolation problem15:55
balloonsmgz, ty15:57
mgzballoons: there are some existing lintian warnings that I didn't fix15:58
balloonsmgz, sorry can you link me again.. I bounced my bouncer16:00
mgzballoons: lp:~juju-qa/ubuntu/yakkety/juju/juju-1.25.616:01
balloonsnatefinch, sadly looks like updating a dependency perhaps is causing a unit test failure? What do you make of http://juju-ci.vapour.ws:8080/job/github-merge-juju/8699/artifact/artifacts/trusty-out.log/*view*/?16:34
balloonsnatefinch, I'm still trying to land that gnuflags update from yesterday :-)16:34
mgzballoons: did fail the same way both times16:36
balloonsyes it did16:36
mgzwhat's the diff between the gnuflag packages before and after updaye?16:37
balloonsnothing. it was merely a move from bzr to git and lp to github16:38
balloonsbut I pulled forward some outdated depends in a few other places16:38
natefinchballoons: looking16:39
natefinchballoons: just a spurious failure... retry16:40
balloonswhat's our opinions on these spurious failures -- Are we proactively fixing these / filing bugs / disabling?16:41
mgznatefinch: I haven't seen the uniter tests fail like that before16:41
mgzcannot set invalid status "rebooting" seems... not good16:42
natefinchyeah I was just looking at that line16:43
natefinchbut that's obviously nothing to do with gnuflags16:43
natefinchthe reboot tests have always been a little flaky16:44
mgzwe've not had that test fail in CI since May16:44
mgzand then it was a catacomb race16:44
mgznot this error16:44
natefinchERROR juju.apiserver Unable to prime /mnt/tmp/check-2402074302189717898/174/logsink.log (proceeding anyway): chown /mnt/tmp/check-2402074302189717898/174/logsink.log: operation not permitted16:44
mgz...also interesting, though likely not fatal16:45
katconatefinch: mgz: i've seen that before16:45
mgzkatco: which?16:45
katcomgz: the error message natefinch just posted16:46
mgzseems like we need to file at least two bugs...16:46
mgzand I still think balloons' branch is causing this test to fail somehow16:47
katcomgz: i assumed it was something to do with the test environment16:47
mgzthough I don't have a good guess remaining on why16:47
mgzkatco: yeah, I think it probably is, and likely is just fine in general because the tests probably don't care about logsink16:48
mgzbut the code is obviously expecting to be root when running but happening as a normal user when called from a unit test16:48
mgzreally it's an isolation escape...16:48
mgzanyway, not causing this failure, just visible as the log is shown16:49
mgzballoons: so, I don't think it will hurt to try landing again, but I bet it will fail again16:52
balloonsit got conflicted again16:53
balloonsi'll have to fix16:53
mgzyeah, joy for mass renaming16:53
mgzballoons: can you split out the bits?16:53
mgzjust do one branch with one dep change16:53
natefinchballoons: gah, sorry... that's one of the reasons I was trying to rush with LGTMs last night, because I knew it had to go in quick or get conflicted to death16:53
mgzget that landed16:53
mgzthen do the next16:53
mgzthen do the snapcraft bits?16:53
balloonsI don't mind the conflicts, it's fine16:53
mgzwell, it adds another point of failure16:54
balloonsand I had to make a feature branch this morning to depend on it16:54
mgzif you misresolve after review16:54
balloonsimpossible to conflict with snapcraft almost -- it's new16:54
=== frankban is now known as frankban|afk
ionutbalutoiuHello, guys! How are the upstream juju tools for 2.0 beta are generated for Windows ? I tried generating them myself and got this weird error when running the juju service on Nano Server: http://paste.ubuntu.com/22928687/. But on the other side, if use the upstream ones, they work on Nano without a problem.17:08
natefinchionutbalutoiu: that's a weird error17:13
ionutbalutoiuWondering if when generating the tools you guys pass any extra parameters or something. I just pull the sources, do godeps and go install.17:14
natefinchyou're sure the ones we build on nano work?  because I see some Go bugs about not running on nano17:15
alexisbredir, ping17:15
alexisbredir, can you please get this in your review q: http://reviews.vapour.ws/r/5403/17:15
ionutbalutoiunatefinch: Even today I bootstrapped Nano with beta14 and upstream tools and Nano worked.17:16
=== alexisb is now known as alexisb-afk
ionutbalutoiunatefinch: bootstrapped an env and deployed Nano **17:16
redirdo I need to setup mass to test the proposed change? uh17:18
* redir has no maas17:18
natefinchionutbalutoiu: oh, looks like it's maybe not a bug in 1.6.017:18
natefinchsinzui: what version of Go do we build our windows tools with?17:19
ionutbalutoiunatefinch: 1.6.317:19
natefinchionutbalutoiu: there's a bug on this issue for the Go language: https://github.com/golang/go/issues/15286  it seems to indicate that building with 1.6.0 should work.  I'd recommend trying that.17:31
redirI am seeing http://paste.ubuntu.com/22931893/ this locally, but don't think it should be related to my current branch. Does anyone know what it is?17:31
sinzuinatefinch: 1.6-0 from Ubuntu trusty. it is cross-compiled17:32
ionutbalutoiunatefinch: Thanks! I'll give it a shot right now and see if it works.17:34
natefinchsinzui: is there a reason we're not building the tools with a newer version of Go?  There are some security fixes in 1.6.1 and bug fixes in general in .2 and .317:50
natefinch(aside from the fact that it'll evidently break windows nano)17:50
sinzuinatefinch: we use what Ubuntu provides. It is possible to use a newer version if the work is scheduled.17:51
ionutbalutoiunatefinch: Go 1.6.0 worked. :)17:52
natefinchsinzui: I guess I was just thinking that we control what's in streams, so we can build with whatever version we like, as long as the code also builds with what's in Ubuntu17:53
natefinchionutbalutoiu: awesome17:53
sinzuinatefinch: well I am not too keen on arbitray Gos. That is what got us into a mess with utopic. vivid, and wily. I want one go version to do everything. We do want to control the go version. I don't want yakkety's Go 1.7 without using it every where.17:57
sinzuinatefinch: balloons and I want to make CI build all agents separate from ubuntu. Our packages will onyl contain the client. Te client will be buillt with the Go Ubuntu chooses, but the agents use the best Go we can use everywhere17:58
natefinchsinzui: that sounds awesome17:59
sinzuinatefinch: yeah, I wish the plan was a priority17:59
natefinchahh ffs... OSError: [Errno 17] File exists: './logs/controller'18:04
natefinchthere goes 10 minutes of my day :/18:06
redirnatefinch: I think that twice every time I run the test suite18:19
natefinchsinzui:  I keep seeing this: Provisioning failed. Shrinking a disk from 136367309312 bytes to 34359738880 bytes is not supported.. ResizeDiskError18:29
sinzuinatefinch: on the bootstrap machine?18:30
natefinchsinzui: this is using origin/master18:30
natefinchsinzui: no, looks like only on the non-controller model18:30
natefinchso, windows18:31
sinzuinatefinch: ah, that is interesting. We cannot get logs from the windows machines so we cannot see what is going wrong18:31
natefinchsinzui: looks like we're not even successfully starting the vm18:33
natefinchsinzui: I'm going to go write some code and poke axw when he comes on.  Maybe he'll have an idea what's going on.  Google hasn't been much help18:54
sinzuinatefinch: ack18:55
mupBug #1606278 changed: juju (2.0) deploy <charm-name>/<revision#> fails <juju-core:Triaged> <https://launchpad.net/bugs/1606278>18:56
mbruzekI am having some problems with the "charm publish" command, I got this : ERROR cannot publish charm or bundle: cannot publish charm or bundle: cannot update base entity for "cs:~containers/kubernetes-6": Field name duplication not allowed with modifiers19:03
balloonssinzui, do you think there is a risk in removing jujud from 1.25 packages?19:03
mbruzekoh sorry, wrong channel.19:03
mbruzekforgive me19:03
sinzuiballoons: from our packages or ubuntus?19:03
balloonssinzui, ubuntu's really, but I suppose our stable ppa's too19:04
balloonssinzui, my thought is it's not a kosher change, and we should seek to do it in 2.0 only19:04
sinzuiballoons: you cannot remove jujud from our packages until you change CI to make all the agents and change the rlease scripts to retrieve them instead of getting from the the debs19:04
balloonssinzui, right, apart from that19:05
balloonsI feel like 1.25 workflows might use it (who knows what some folks are doing), while since 2.0 isn't released yet, and --upload-tools is dying, we can feel better about removing it19:06
natefinchmanual provider needs it19:06
natefinchdoesn't it?19:06
balloonswell, our adt tests will break without it for instance, :-)19:06
* natefinch forgets19:06
sinzuiballoons: by removing jujud from ubuntu's packages, we ensure no bad jujuds get into production. This prevents uses from using --upload-tools. Users need to ise sync-tools and bootstrap --metadata-source to use a closed network19:07
sinzuinatefinch: manual does not need it because manual works across arch19:08
natefinchsinzui: good point19:08
balloonssinzui, I agree but I guess I'm saying removing a binary isn't really a bugfix SRU, and I think it's saner just to leave it packaged for 1.x series19:08
sinzuinatefinch: I wish add-machine worked with windows. We could start a win2012r2, then add-machine to prove the agent works if the machine comes up19:09
natefinchsinzui: is there a bug filed for that?  I didn't realize add-machine didn't work for windows.19:12
sinzuinatefinch: i thought there was. I brought it up many times in the past. windows doesn't come with ssh and juju doesn't support winrm.19:14
natefinchsinzui: I don't understand why that matters.  We obviously have the ability to bring up a windows machine using juju during deploy.  There's no reason we can't reuse that code and just not deploy anything.19:19
sinzuinatefinch: with the azure provider, it should not matter. add-machine will ask azure to bring up a machine.19:20
rick_h_perrito666: heads up that macgreagoir looked at the pr, I qa'd it and he's got a question before it can land in case we want to get it into the beta tomorrow https://github.com/juju/juju/pull/574719:20
perrito666rick_h_: yup its on my today queue19:21
rick_h_perrito666: coolio19:21
perrito666rick_h_: no need to throw bad 90s music at me ill do it19:22
rick_h_perrito666: :P19:22
* perrito666 sees there is an upgrade for the fortran library... what in the univers is using fortran in my computer19:24
=== alexisb-afk is now known as alexisb
mupBug #1611789 changed: GUI: test_upgrade_gui failed KeyError: 'cloud' <ci> <juju-gui> <regression> <unit-tests> <juju-core:Invalid by jcsackett> <https://launchpad.net/bugs/1611789>19:56
=== jillr_ is now known as jillr
balloonsnatefinch, 3 runs, 3 fails all on that uniter test21:18
balloonsI have to believe it's something in the diff21:19
mgzballoons: can you land just the tomb change or just the gnuflag change?21:20
balloonsit may be possible to land just the tomb change. But I'm lockstep now. it's already landed in the underlying repos; it can't be split now21:21
balloonsI guess I was hoping for understanding why the test is failing -- gnuflag and tomb did NOT change at all21:25
balloonsso mgz, the only possible source of difference is in juju/utils: https://github.com/juju/utils/pull/230/files21:26
balloonsBut to be fair, that's landed, so in theory that should affect everyone's builds right? So there is no reason I can think of why it's failing21:26
balloonsohh right.. they aren't using it, so indeed, I can say that's the issue :-)21:27
mgzballoons: so, that utils rev hasn't changed anything, but you mean there are other interveening changes?21:28
balloonsmgz, that utils rev pulls newer versions of other dependencies. newer commits21:28
mgzballoons: that's actually unimportant21:28
balloonsthat's the only place code could have actually changed though.. nothing else has changed21:29
mgzas when juju itself builds, it goes off its dependencies.tsv which overrides the one in any deps21:29
balloonstrue.. I just am at a loss as to what the issue could be21:29
mgzballoons: run our build tarball script for before and after21:31
mgzand do a diff on the whole tree, and send me that21:31
mgzit's possible there's actually no code change and this is compiler oddness, but I bet we do have a functional change hidden in there21:32
anastasiamacalexisb: rick_h_: release call :)21:32
alexisbanastasiamac, be there soon21:32
mupBug #1418139 changed: Can't reprovision a machine with manual provider <bootstrap> <destroy-environment> <manual-provider> <manual-story> <juju-core:Fix Released by natefinch> <juju-core 1.25:Fix Released by natefinch> <https://launchpad.net/bugs/1418139>21:36
balloonsmgz, pulling the source tarball shows only the expected changes22:12
balloonsI'm giving.. I'll split it tomorrow as you suggest and don't land it together22:12
balloonsperhaps we can piecemeal the problem out22:12
mgzballoons: I see changes in utils exec code and changes in arg parsing22:13
mgzthe uniter tests are unfortunately a twisty mess so it's unclear why it's now unhappy22:13
mgzprobably just want to bug william (or maybe horacio?) to have a look at the test output vs diff22:13
mupBug #1520571 changed: Juju destroy-environment stacktraces on local provider. <landscape> <juju-core:Invalid> <juju-core 1.25:Won't Fix> <https://launchpad.net/bugs/1520571>22:33
mgzballoons: this is perfectly reproducable locally22:34
mgzballoons: it fails because of the utils exec change22:45
mgzjuju/utils pr #20322:46
mgzpresumably because the test framework is somewhat bogus and doesn't expect the error right away, which it should22:46
mupBug #1610037 changed: Juju2 beta14, missing network stanzas. <sts-needs-review> <juju-core:Invalid> <https://launchpad.net/bugs/1610037>22:51
mupBug #1611981 opened: LXD guests not configured due to the lack of DHCP on the interface selected as eth0 <sts> <juju-core:New> <https://launchpad.net/bugs/1611981>22:51
menn0wallyworld, alexisb: no hangout?23:19
menn0standup even23:19
wallyworldmenn0: yeah, we are here23:20
perrito666menn0: you are in the old one23:20
mupBug #1611990 opened: maas bootstrap fails if maasrc is missing <bootstrap> <maas-provider> <juju-core:In Progress by wallyworld> <https://launchpad.net/bugs/1611990>23:33
alexisbaxw, I need a few minutes of your time23:50
alexisbif you dont mind23:50
axwalexisb: sure, gtg help with kids soon though23:50
alexisbit should be quick23:50

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