[00:15] * redir eod [00:15] thanks for the clue axw [01:40] thumper: http://reviews.vapour.ws/r/5404/ pls [01:49] menn0: done [01:49] thumper: thanks [01:52] thumper: dropped your issue (with an explanation) [01:52] ok === natefinch-afk is now known as natefinch [02:13] axw: 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:17] natefinch: we did not [02:18] axw: any preference? [02:20] natefinch: 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 type [02:20] and SchemaList etc. [02:20] I 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] natefinch: I'd prefer if we didn't fork [02:20] for that reason [02:22] it sucks that there's no nice way to make recursive data structures easily extensible [02:24] axw: so... you're saying we're boned :) [02:25] natefinch: 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 field [02:26] natefinch: we would still rely on the jsonschema package for all of the standard parsing and validation [02:28] axw: interesting, ok. [02:34] axw: 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] Note that the validation is actually in a subpackage, the main package is just the types and unmarshalling. [02:40] natefinch: I'll have a poke and see if I can come up with something that looks workable [03:19] natefinch: https://gist.github.com/axw/0d395b86aa5ac9ee0c4f18a3ca81cb68 [03:19] natefinch: you would need to have a "toInternal" to do the opposite, putting the juju bits back into the Extras map [03:20] axw or thumper: fairly easy one: http://reviews.vapour.ws/r/5405/ [03:20] natefinch: 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/toInternal [03:20] menn0: looking [03:21] axw: right [03:21] axw: it's funny, the jsschema thing has custom json (un)marshaling too, so the json tags aren't really used. [03:22] axw: that looks pretty good. Reusing as much as possible from the internal type, just replacing the recursive part. Very nice. [03:25] menn0: LGTM [04:33] axw: (delayed) tyvm [04:33] np [05:04] * thumper waits for the featuretest package to run tests... [05:04] should have used -check.v [05:04] hmm... [05:04] how long to wait... [05:05] killed it [05:05] PASS: dblog_test.go:149: debugLogDbSuite.TestLogsAPI 0.005s [05:05] OK: 1 passed [05:05] PASS [05:05] ok github.com/juju/juju/featuretests 7.662s [05:05] 5ms to run the test, the rest of 7.6 seconds for setup / teardown [05:06] w00t [05:46] menn0: are you still around? [05:55] jam: yes, for a few more minutes === frankban|afk is now known as frankban [07:54] menn0: sorry I ended up missing you, I'll see you at the tech board if you can make it [08:00] balloons: the best way is to migrate all the leaf repositories first, then juju-core itself [08:22] menn0: ping? [08:27] babbageclunk: hi, in tech board call atm [08:27] menn0: ok [09:13] babbageclunk: done! [09:14] babbageclunk: I imagine you're bugging me about the email you sent which I didn't reply to? [09:14] menn0: Hi! Yes! [09:14] babbageclunk: sorry... I was trying to staying focussed on migrations so email took a back seat today [09:15] babbageclunk: I'll reply now but the short answer is that you don't need to worry about migrations for what you're working on [09:15] babbageclunk: a migration will abort early if there's any dying/dead machines or units [09:16] menn0: Ok - so I can ditch that commit then? [09:17] menn0: No need to reply right now if that's the takeaway. [09:17] babbageclunk: yep, you can ditch that... there will be a higher level check for dying machines [09:18] menn0: Sweet, thanks! [09:18] babbageclunk: should be working on prechecks this week [09:51] menn0, if you're still around... the nsWhatever thing [09:51] fwereade: 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:52] menn0, I feel like I want *some* way to visibly distinguish these (basically) static/stateless types [09:52] babbageclunk, hmm [09:52] fwereade: I'm aware that both are eyebrow-provoking. [09:52] babbageclunk, let me look [09:52] babbageclunk, wouldn't surprise me if the use-existing-JujuConnSuite were the pragmatic approach [09:53] fwereade: ok, I'll put my test in one of those for now. [09:55] perrito666, ping re Authorizer.HasPermission [10:00] perrito666, ehh, don't worry about it [10:01] * 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 minutes [10:01] fwereade: i am just waking up, if you want I can ping you in a moment? [10:13] perrito666, ofc [10:19] jam, 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 mind [10:19] so [10:19] fwereade: sure ;) [10:19] in the payloads work, we made a stab at separating persistence from business logic [10:20] and it wasn't entirely successful, but when I moved the necessary payloads bits into state, I tried to preserve the distinction [10:21] and 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 side [10:22] (and an unexported `var nsPayloads nsPayloads_` to actually call methods on) [10:24] and it's nice that it's entirely stateless, and it has methods like `untrackOp(coll mongo.Collection, docID string) (txn.Op, error)` [10:24] so I'm pretty happy with the *structure* [10:24] but the "nsFoo" naming style has raised many eyebrows [10:25] so the *easy* thing to do is just to drop the ns stuff [10:25] and just have refcounts.CreateOrIncRefOp, and life.notDeadOp, and so on [10:26] but [10:26] the style, while I think it is good, is somewhat at odds with the stateful-model-type approach we're currently using almost everywhere [10:27] and I can't help but feel it needs *something* to clearly and visibly distinguish it from... all the other code [10:27] am I overthinking this? from a certain perspective the prefix tells you very little, whatever it might be [10:27] fwereade: so you separate the external interface of Payloads from the low-level ops, which go in the ns* internal type? [10:27] dimitern, yeah [10:29] fwereade: ns for namespace.. I could say it's not quite obvious at first [10:29] fwereade: I mean namespaces vs entities [10:29] dimitern, (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] fwereade: things we store [10:29] dimitern, yeah, indeed [10:29] dimitern, it is evidently not obvious [10:30] fwereade: how about persistence ? too long I guess.. [10:30] * xnox is failing to bootstrap localhost provider with 2.0 beta14 on xenial =( [10:30] dimitern, yeah, I guess that's the obvious one, but I rue all the characters it costs every time you want to use it [10:31] fwereade: backing is shorter, and already used here and there [10:31] it's not perfect though.. [10:32] xnox: about lxdbr0? [10:32] dimitern, 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-invasively [10:32] dimitern, state/persistence/life etc [10:32] dimitern, tools info mismatch [10:33] dimitern, you know, the more I talk, the less I care about having any prefix at all [10:33] xnox: oh.. [10:33] dimitern, if they ever make it into packages it'll just be `life.notDeadOp(...)` anyway [10:33] fwereade: having the prefix is fine I think [10:34] dimitern, that's seemed to be the major sticking point for people though [10:34] fwereade: the underscore suffix is making me wince a little [10:34] does 2.0 need agent-stream: devel ? [10:35] ERROR 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:36] $ juju bootstrap --config agent-stream=devel localhost localhost [10:36] seems to work better, [10:36] however specifying --config cancels "interactive" mode of juju bootstrap [10:36] xnox: nice! I usually always bootstrap from src with --upload-tools [10:37] xnox: yeah any args do that [10:40] fwereade: if not ns how about stored? e.g. storedPayloads [10:40] fwereade: saved ? [10:42] fwereade: dbPayloads even :D [10:43] dimitern, yeah, if you can see a way around the suffix that'd be nice, but you only see that when you're implementing it [10:43] dimitern, hmm [10:43] dimitern, dbPayloads [10:43] dimitern, I think maybe I like that [10:43] db is short and more obvious yeah [10:43] dimitern, awesome, tyvm [10:44] :) np [10:44] jam, babbageclunk: any thoughts? ^^ or anyone else? :) [10:47] * dimitern as usual has a lot of things needing attention.. sinks back to bugs [11:04] ok, this is completely new to me: alarm notification buffer full [11:10] fwereade: 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:11] babbageclunk, cheers :) [11:12] fwereade: Also, ns is used a lot in iOS objective-C development (from NextStep), so it's weird seeing it in Go code. :) [11:12] Oops NeXTSTEP apparently. [11:13] babbageclunk, a sense of happy familiarity with the NS prefix did sort of come into it, even if it's ultimately unhelpful [11:16] fwereade: m_lpszDataSource evokes that sort of familiarity for me, but with the opposite sign :) [11:17] dimitern, hahaha [11:17] dimitern: lol [11:17] dimitern, I wish they'd done hungarian notation right [11:17] oh MFC days... [11:17] :) [11:25] does anyone know if the clock interface recently changed? [11:26] perrito666: rogpeppe was talking about changing something there recently IIRC [11:26] dimitern, perrito666: i haven't actually changed anything recently AFAIR [11:27] dimitern, perrito666: though I have an unfinished PR that revamps the testing clock stuff and the interface [11:27] rogpeppe: ah ok - wasn't the discussing around alarms though? timers? [11:27] dimitern, perrito666: i just need to find time to write some tests for it [11:27] dimitern: i wanted NewTimer [11:27] rogpeppe: that's it [11:28] dimitern, perrito666: FWIW this is the PR in question: https://github.com/juju/testing/pull/108/files [11:29] rogpeppe: I am getting a strange panic in tests (pastebining now) [11:30] http://pastebin.ubuntu.com/22902510/ [11:30] Ill now go see how in the universe I triggered that without even going near it [11:31] perrito666: you can fix that by reading from the clock.Alarms channel [11:32] rogpeppe: I am curious on how I originally broke that (more than the actual fix) :) [11:32] perrito666: tbh i think that that clock code shouldn't panic in that case [11:33] I mean, I know what I changed, I agree with you that this thing should definitely not panic [11:35] perrito666: I suspect you're using juju/testing/clock whereas before you used juju/juju/testing/clock [11:35] dimitern: I suspect someone made that change and I made a change and we both clashed :p [11:35] dimitern, perrito666: please, please can we change everything to use juju/testing/clock and remove juju/juju/testing/clock ? [11:36] rogpeppe: sure you can, ill review the PR :p [11:36] dimitern, perrito666: there's no need for both to exist [11:36] rogpeppe: I don't mind that :) [11:36] perrito666: most of what i do these days seems to be juju-core code cleanups [11:37] rogpeppe: and we love you for it [11:37] rogpeppe: indeed <3 :) [11:38] perrito666: speaking of which... did you see this? https://bugs.launchpad.net/juju-core/+bug/1611379 [11:38] Bug #1611379: api/backups: restore code needs improvement [11:38] "needs improvement" is perhaps the bigest understatement in history of mankind [11:38] lol [11:39] perrito666: well, i thought i might be out of order to say "this code is fucking shit" :) [11:39] perrito666: in a bug report [11:39] perrito666: anyway, i rewrote it, but didn't have time to write the tests (the current code has no tests) [12:43] 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 sec [13:01] rick_h_: ack [13:02] dimitern: Ready for HO when you are. [13:02] macgreagoir: ok, let's use the standup HO I guess? [13:09] babbageclunk: ping [13:15] voidspace: pong, sorry! [13:19] dimitern, https://pastebin.canonical.com/162703/ latest run [13:19] dimitern, after this the boot gets stuck. [13:31] Bug #1611764 opened: upgraderSuite.SetUpTest An existing connection was forcibly closed

[13:31] Bug #1611766 opened: upgradeSuite.TearDownTest sockets in a dirty state

[13:32] voidspace: time to sync? [13:33] rick_h_: yep [13:34] rogpeppe, 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] babbageclunk, voidspace perhaps? ^^ [13:34] balloons: that is annoying [13:34] balloons: but [13:34] balloons: there's a way around it [13:35] I 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 do [13:35] balloons: make a feature branch of either juju-core or romulus that uses only the github gnuflag [13:36] balloons: unfortunately it does [13:36] balloons: it's ok (temporarily) for a project to depend on a commit in a feature branch [13:37] balloons: once you've landed romulus depending on the juju feature branch, you can make juju depend on that just-landed romulus branch [13:38] balloons: then you can update romulus to depend on juju master again and delete the juju feature branch [13:38] balloons: or you can do it the other way, making a feature branch in romulus [13:39] this sounds educational [13:39] I think a feature branch in romulus would be preferred perhaps -- avoid invoking a CI run for instance [13:42] balloons: good point [13:45] fwereade: sorry, not me - voidspace has been doing a fair bit on migrations though. [13:45] fwereade: babbageclunk: not charm migrations, no [13:47] babbageclunk, voidspace: not to worry [13:50] babbageclunk, voidspace: (fun fact: the data model *never* actually checked that a given charm existed before creating an application that used it) [13:51] nice [13:51] babbageclunk, 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:54] sinzui, mgz: the CI scripts ask for an environment... how do I pass a cloud and credentials? [13:55] (running deploy_job.py) [13:58] fwereade: doh [14:01] voidspace: natefinch dimitern standup ping [14:01] omw [14:10] Bug # changed: 1502130, 1523608, 1556961, 1586197 [14:15] natefinch: 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. === ivyyyy-brb is now known as ivyyy [14:36] sinzui: 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 creds [14:37] Bug #1611463 changed: GUI: test_upgrade_gui failed KeyError: 'bootstrap-config'

[14:37] Bug #1611789 opened: GUI: test_upgrade_gui failed KeyError: 'cloud'

[14:40] natefinch: I don't know how to do that with azure. Can we open rdp using the azure portal? [14:41] sinzui: yes. If I can log into azure with the right credentials [14:41] natefinch: ah. with azure you login as yourself. I can add you to the subscription [14:42] sinzui: cool [14:44] natefinch: Register with azure with your canonical address. When Azure knows it, I can add you [15:03] any work arounds folks know to kill a controller [15:03] * arosales getting http://paste.ubuntu.com/22918062/ [15:03] I destroyed all the models separately [15:10] sinzui: oh, can you just use my current azure account? it's nate.finch@gmail.com [15:10] natefinch: no, this is a canonical account [15:14] sinzui: 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 it [15:14] natefinch: I wont. and I understand the pain [15:15] sinzui: I guess I don't understand why it matters what email address I used to sign up with [15:15] natefinch: this isn't my account. it is canonicals and it gets audited [15:15] sinzui: ahh. OK, I get it. [15:20] sinzui: ok, I have a nate.finch@canonical.com azure account now [15:20] natefinch: reload the page in azure, I think you can see all the resource groups and vms [15:22] sinzui: ahh yes, once I switch to your directory [15:45] perrito666: works for me [15:50] balloons: you're not on the other network... [15:51] balloons: see lp:~juju-qa/ubuntu/yakkety/juju/juju-1.25.6 for the base branch without bug fixes or the per-series versions [15:55] aghh 4 hours chasing an isolation problem [15:57] mgz, ty [15:58] balloons: there are some existing lintian warnings that I didn't fix [16:00] mgz, sorry can you link me again.. I bounced my bouncer [16:01] balloons: lp:~juju-qa/ubuntu/yakkety/juju/juju-1.25.6 [16:05] morning [16:34] natefinch, 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] natefinch, I'm still trying to land that gnuflags update from yesterday :-) [16:36] balloons: did fail the same way both times [16:36] yes it did [16:37] what's the diff between the gnuflag packages before and after updaye? [16:38] nothing. it was merely a move from bzr to git and lp to github [16:38] but I pulled forward some outdated depends in a few other places [16:39] balloons: looking [16:40] balloons: just a spurious failure... retry [16:41] what's our opinions on these spurious failures -- Are we proactively fixing these / filing bugs / disabling? [16:41] natefinch: I haven't seen the uniter tests fail like that before [16:42] cannot set invalid status "rebooting" seems... not good [16:43] yeah I was just looking at that line [16:43] but that's obviously nothing to do with gnuflags [16:44] the reboot tests have always been a little flaky [16:44] we've not had that test fail in CI since May [16:44] and then it was a catacomb race [16:44] not this error [16:44] ERROR juju.apiserver Unable to prime /mnt/tmp/check-2402074302189717898/174/logsink.log (proceeding anyway): chown /mnt/tmp/check-2402074302189717898/174/logsink.log: operation not permitted [16:45] ...also interesting, though likely not fatal [16:45] natefinch: mgz: i've seen that before [16:45] katco: which? [16:46] mgz: the error message natefinch just posted [16:46] seems like we need to file at least two bugs... [16:47] and I still think balloons' branch is causing this test to fail somehow [16:47] mgz: i assumed it was something to do with the test environment [16:47] though I don't have a good guess remaining on why [16:48] katco: yeah, I think it probably is, and likely is just fine in general because the tests probably don't care about logsink [16:48] but the code is obviously expecting to be root when running but happening as a normal user when called from a unit test [16:48] really it's an isolation escape... [16:49] anyway, not causing this failure, just visible as the log is shown [16:52] balloons: so, I don't think it will hurt to try landing again, but I bet it will fail again [16:53] it got conflicted again [16:53] i'll have to fix [16:53] yeah, joy for mass renaming [16:53] balloons: can you split out the bits? [16:53] just do one branch with one dep change [16:53] balloons: 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 death [16:53] get that landed [16:53] then do the next [16:53] then do the snapcraft bits? [16:53] I don't mind the conflicts, it's fine [16:54] well, it adds another point of failure [16:54] and I had to make a feature branch this morning to depend on it [16:54] if you misresolve after review [16:54] impossible to conflict with snapcraft almost -- it's new === frankban is now known as frankban|afk [17:08] Hello, 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:13] ionutbalutoiu: that's a weird error [17:14] Wondering if when generating the tools you guys pass any extra parameters or something. I just pull the sources, do godeps and go install. [17:15] you're sure the ones we build on nano work? because I see some Go bugs about not running on nano [17:15] redir, ping [17:15] pong [17:15] redir, can you please get this in your review q: http://reviews.vapour.ws/r/5403/ [17:15] yup [17:16] thanks [17:16] natefinch: Even today I bootstrapped Nano with beta14 and upstream tools and Nano worked. === alexisb is now known as alexisb-afk [17:16] natefinch: bootstrapped an env and deployed Nano ** [17:18] do I need to setup mass to test the proposed change? uh [17:18] * redir has no maas [17:18] ionutbalutoiu: oh, looks like it's maybe not a bug in 1.6.0 [17:19] sinzui: what version of Go do we build our windows tools with? [17:19] natefinch: 1.6.3 [17:31] ionutbalutoiu: 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] I 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:32] natefinch: 1.6-0 from Ubuntu trusty. it is cross-compiled [17:34] natefinch: Thanks! I'll give it a shot right now and see if it works. [17:50] sinzui: 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 .3 [17:50] (aside from the fact that it'll evidently break windows nano) [17:51] natefinch: we use what Ubuntu provides. It is possible to use a newer version if the work is scheduled. [17:52] natefinch: Go 1.6.0 worked. :) [17:53] sinzui: 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 Ubuntu [17:53] ionutbalutoiu: awesome [17:57] natefinch: 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:58] natefinch: 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 everywhere [17:59] sinzui: that sounds awesome [17:59] natefinch: yeah, I wish the plan was a priority [18:04] ahh ffs... OSError: [Errno 17] File exists: './logs/controller' [18:06] there goes 10 minutes of my day :/ [18:19] natefinch: I think that twice every time I run the test suite [18:19] yeah [18:29] sinzui: I keep seeing this: Provisioning failed. Shrinking a disk from 136367309312 bytes to 34359738880 bytes is not supported.. ResizeDiskError [18:30] natefinch: on the bootstrap machine? [18:30] sinzui: this is using origin/master [18:30] sinzui: no, looks like only on the non-controller model [18:31] so, windows [18:31] natefinch: ah, that is interesting. We cannot get logs from the windows machines so we cannot see what is going wrong [18:33] sinzui: looks like we're not even successfully starting the vm [18:33] :/ [18:54] sinzui: 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 help [18:55] natefinch: ack [18:56] Bug #1606278 changed: juju (2.0) deploy / fails [19:03] I 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 modifiers [19:03] sinzui, do you think there is a risk in removing jujud from 1.25 packages? [19:03] oh sorry, wrong channel. [19:03] forgive me [19:03] balloons: from our packages or ubuntus? [19:04] sinzui, ubuntu's really, but I suppose our stable ppa's too [19:04] sinzui, my thought is it's not a kosher change, and we should seek to do it in 2.0 only [19:04] balloons: 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 debs [19:05] sinzui, right, apart from that [19:06] I 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 it [19:06] manual provider needs it [19:06] doesn't it? [19:06] well, our adt tests will break without it for instance, :-) [19:06] * natefinch forgets [19:07] balloons: 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 network [19:08] natefinch: manual does not need it because manual works across arch [19:08] sinzui: good point [19:08] sinzui, 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 series [19:09] natefinch: I wish add-machine worked with windows. We could start a win2012r2, then add-machine to prove the agent works if the machine comes up [19:12] sinzui: is there a bug filed for that? I didn't realize add-machine didn't work for windows. [19:14] natefinch: 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:19] sinzui: 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:20] natefinch: with the azure provider, it should not matter. add-machine will ask azure to bring up a machine. [19:20] 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/5747 [19:21] rick_h_: yup its on my today queue [19:21] perrito666: coolio [19:22] rick_h_: no need to throw bad 90s music at me ill do it [19:22] perrito666: :P [19:24] * perrito666 sees there is an upgrade for the fortran library... what in the univers is using fortran in my computer [19:25] lol === alexisb-afk is now known as alexisb [19:56] Bug #1611789 changed: GUI: test_upgrade_gui failed KeyError: 'cloud'

=== jillr_ is now known as jillr [21:18] natefinch, 3 runs, 3 fails all on that uniter test [21:19] I have to believe it's something in the diff [21:20]