=== Spads_ is now known as Spads [00:25] ericsnow: ping? [00:25] menn0: hey [00:26] ericsnow: quick question... why is the vsphere provider set up to not build under gccgo or go 1.2? [00:27] menn0: dependencies [00:27] ericsnow: i'm reviewing the rackspace provider PR and the sshclient from vsphere has been moved and generalised to support it and the build tags came along [00:27] menn0: (govmomi requires 1.3+) [00:27] ericsnow: but the ssh client should work fine? [00:27] menn0: yep [00:27] ericsnow: ok, i'll mention that the build tag should go [00:27] menn0: it's just the Go bindings to the vsphere API that were the problem [00:28] ericsnow: thanks [00:28] menn0: np [00:28] ericsnow: actually, one more thing, the sshclient code assumes the host is Linux so won't work with windows hosts. is this ok/expected? (i know nothing about vsphere) [00:29] menn0: for vsphere I expect it's okay [00:29] ericsnow: any idea when it comes to rackspace? this PR is using the same code there. [00:30] menn0: rackspace is openstack under the hood [00:32] ericsnow: and openstack does appear to support windows hosts, but I don't know about rackspace [00:32] ericsnow: i'l raise it as a possible issue. thanks. [00:32] menn0: k, cool [01:08] katco, ericsnow, wwitzel3: evening [01:09] natefinch: o/ [01:09] natefinch: i'm in moonstone. eric and wayne are taking a break [02:20] thumper: have you forward ported bug 1468581? [02:20] Bug #1468581: juju bootstrap fails - Waiting for API to become available ERROR cannot get all blocks: EOF

[02:20] I think so... [02:20] let me check [02:20] axw: and bug 1474614 [02:20] Bug #1474614: rsyslog connections fail with certificate verification errors after upgrade to 1.24.2

[02:20] and there's a few from menno as well [02:21] menn0 even [02:21] wallyworld: from the bug, "Forward-porting fix to 1.25 is currently blocked on other changes to the rsyslog worker being forward ported (i.e. the change that the upgrade step is concerned with)." [02:21] ah ok [02:21] didn't read the bug :-) [02:21] wallyworld: I'll look at doing that after I finish up what I'm working on [02:22] just the milestone page [02:22] ty [02:22] we're aiming to cut 1.25 alpha 1 real soon [02:22] hence the follow up [02:22] wallyworld: i'm planning on doing the forward port for bug 1474195 this afternoon [02:22] Bug #1474195: juju 1.24 memory leakage

[02:23] awesome tyvm [02:23] wallyworld: actually, I lie. I have the PR ready for that but want Will's review (have emailed him) [02:23] wallyworld: no [02:23] wallyworld: i'm doing bug 1474606 this afternoon [02:23] menn0: and the other 2 against you? [02:23] Bug #1474606: $set updates may clear out the env-uuid field

[02:23] wallyworld: I must have forgotten [02:23] bad me [02:23] * wallyworld spanks thumper [02:24] oi [02:24] none of that [02:24] wallyworld: bug 1474588 is nowhere near investigated let alone fixed [02:24] Bug #1474588: Many hook failures after upgrade

[02:25] menn0: the othr one i was refering to in marked in progress bug 1457225 [02:26] wake up mup bug 1457225 [02:27] oh right, you answer that [02:27] sorry [02:51] wallyworld: mup knew that :) [02:52] Bug #1476895 opened: ec2: auto-created EBS volumes are not tagged

[02:58] Bug #1476895 changed: ec2: auto-created EBS volumes are not tagged

[03:16] Bug #1476895 opened: ec2: auto-created EBS volumes are not tagged

[03:34] ericsnow: wwitzel3: if by any chance you're lurking around, natefinch and i are in moonstone [03:37] menn0: ignore http://reviews.vapour.ws/r/2234/ [03:37] wallyworld: would you PTAL at https://github.com/go-goose/goose/pull/12 [03:38] sure [03:38] thumper: happily ignoring :) [03:39] axw: +1 [03:40] wallyworld: ta [03:59] wallyworld: cherry picking the fixes for bug 1474606 is proving difficult because it depends the fixes for bug 1474195 (which i'm waiting on a review from will on) [03:59] Bug #1474606: $set updates may clear out the env-uuid field

[03:59] Bug #1474195: juju 1.24 memory leakage

[03:59] wallyworld: can it wait until tomorrow? [04:03] menn0: for both? can wait if necessary [04:04] i ping william later to make sure he reviews [04:13] wallyworld: thanks. the second one doesn't need will's review, just the one that's up. [04:13] wallyworld: i've emailed him about it as well. [04:18] ty [04:25] Bug #1457797 changed: Juju bootstrap doesn't work behind proxy

[04:40] Bug #1457797 opened: Juju bootstrap doesn't work behind proxy

[04:46] Bug #1457797 changed: Juju bootstrap doesn't work behind proxy

[04:46] Bug #1476918 opened: juju switch doesn't work without an environments.yaml file

[04:59] wallyworld: another small review if you don't mind: https://github.com/go-amz/amz/pull/56 [04:59] sure [05:18] jam: morning, would you have time soonish to talk about resources? in maybe 15 minutes when anastasia gets back from school pickup? [05:40] wallyworld: sure, are you available now? [05:41] jam: almost, just waiting to hear back from anastasia who is caught in traffic. may have to defer if it gets to close to my school pickup time [05:41] k [06:06] jam: you free now? [06:06] wallyworld: sure [06:06] https://plus.google.com/hangouts/_/canonical.com/tanzanite-stand [06:09] * thumper looks around for urulama [08:11] Bug #1476996 opened: Network communication failed during juju bootstrap [08:47] Bug #1477010 opened: provider/openstack: volumes may not attach if instance takes a long time to provision

[09:00] fwereade: hangout? [09:38] ocr: quick deps update http://reviews.vapour.ws/r/2238/ thanks! [10:15] wallyworld, you still around? [10:17] wallyworld, I'm wondering whether we need to read the whole previous status doc every time we set [10:18] wallyworld, could we just write the same data to both the watched and the raw collections every time? [10:18] wallyworld, (and fwiw I think it might be more reliable?) [10:38] * fwereade was doing some python the other day and just spent *far* too long wondering why gofmt didn't like "def" [10:41] lol [10:44] wallyworld: https://bugs.launchpad.net/juju-core/+bug/1287949 [10:44] Bug #1287949: {image,tools}-metadata-url not usable w/ ec2 provider

[10:57] bogdanteleaga: by design, we currently only allow signed image metadata for ec2. i don't know the reason for that decision [10:58] the the metadata were to be signed, it would work [10:58] if [10:58] yes, but as per the guy above me in the bug report [10:59] there's no way of specifying a key [10:59] so it has to be official? [10:59] wallyworld, bogdanteleaga: nor do I, but it crosses my mind that we want to be sure that anything we think is the official source is signed with our key [11:00] fwereade: that is true, but for ec2 it currently requires user specified image metadata to be signed [11:00] definitely makes sense, but then there's no way of specifying custom images [11:00] wallyworld, bogdanteleaga: I can't see any reason not to allow either additional keys or to allow unsigned -- so long as we check our source [11:00] and i don't know why [11:00] wallyworld, nor do I but I strongly suspect it was an all-we-had-time-for deal [11:01] maybe because - can people add custom images to ec2? [11:01] wallyworld, yes, and IMO that's a good thing [11:01] maybe the reasoning was, well if you can't add cutom images.... [11:01] no, but there's no way of using a ec2 AMI that's not specified on cloud-images.ubuntu.com [11:01] i.e. a windows ami [11:01] this was all done prior to windows :-) [11:02] so the code needs changing for windows [11:02] yeah, I'm aware and I do understand [11:02] wallyworld, bogdanteleaga: I strongly agree that is a bug and it's symptomatic of a wider one -- we have metadata generate-image, but a cloud configured to never work with it? [11:02] was just signaling it's an actual bug and it's getting more important [11:02] fwereade: ec2 was configured to only use signed metadatsa before genetate metatdata came along [11:03] generate metadata was only for openstack [11:03] for private clouds [11:03] and I wasn't aware it was a design decision until now [11:03] where there were no official images [11:03] bogdanteleaga: it made sense at the time because there were no unofficial images possible [11:03] wallyworld, heh, not in my mind, I always thought that the ability to specify custom images was important, just that the way we were originally doing it was badwrongevil [11:04] fwereade: at the time, everything was based on simplestreams - that was our language [11:04] and only openstack had the need for custom images [11:05] and ec2 i think deliberately precluded them [11:05] wallyworld, custom images are super-cool all over the place [11:05] ok, so for a fix: do we want to allow unsigned or to allow specifying a key? [11:05] wallyworld, if we *just* let people do this we can have the big data folks deploying an image with their JVM already in place [11:05] wallyworld, and cut their deployment times like anything [11:05] fwereade: i agree, but at the time it was impossible to have custom images for aws [11:06] so why support something impossibe [11:06] wallyworld, I am certain that I was building custom images for aws before even ensemble was a thing [11:06] i'm guessing - maybe it was a policy deciison [11:06] not sure now [11:06] bogdanteleaga: allow unsigned i think [11:07] to be consistent with ec2 [11:07] openstack [11:07] i meant [11:07] wallyworld: so I'm guessing ec2 is asking for signed only right? I was disabling it for everything for testing [11:07] fwereade: to answer your other question - i'm not sure why whole status record written each time - histerical reaosns? [11:07] bogdanteleaga: from memory there's a bool constant [11:08] wallyworld, no, read each time, for copying into hysterical statues [11:08] wallyworld, bogdanteleaga: it *would* IMO be best to allow specification of acceptable keys as well [11:08] fwereade: that's a bigger change, but sure [11:09] but do we really need that straight up? [11:09] wallyworld, bogdanteleaga: and that feels like something that shouldn't take too much per-env configuration [11:10] wallyworld, I am encouraging bogdanteleaga to do it, because apart from anything else I think security-conscious people *will* want to use signed simplestreams, and we're not going to sign the metadata for every OS we can deploy [11:11] i agree, just ensuring it's the right time to do it [11:11] how about I enable the unsigned one, and add a todo+bug report for doing signed with key [11:11] wallyworld, bogdanteleaga: that sgtm [11:11] that's what i was expecting to hapen [11:11] wallyworld, bogdanteleaga: indeed [11:12] bogdanteleaga, please talk it through with gsamfira_ though, I think it will be relevant if we expect Serious People to deploy a bunch of different OSs with juju [11:13] wallyworld, anyway re status [11:13] wallyworld, what I really want to do [11:13] wallyworld, is have every setstatus method be [11:14] go setHistoricalStatus(key, doc) // logs but ignore errors [11:14] ...and then to just set txnal status as usual [11:15] wallyworld, if I *just* do that, we'll miss one hostirical value around an upgrade [11:15] fwereade: looking at the code, it seems that it is excluing the actual current status from the history? [11:15] wallyworld, and if I take on an upgrade step as well I will feel I've strayed too far from "enable leadership" [11:16] wallyworld, hmm, hadn't looked there [11:16] wallyworld, any particular reason? [11:16] wallyworld, seems surprising [11:16] maybe "history" was taken as lieterally meaning in the past [11:16] but yeah surprising [11:16] wallyworld, latest know status is still part of history because it was set in the past [11:17] fwereade: i can't see a reason not to make the change you suggest [11:17] wallyworld, cool, thanks [11:19] wallyworld, oh hell, status history is still txnal in 1.24 [11:19] wallyworld, shouldn't it be backported? [11:19] damn, i'll ask horatio to backport - i thought it was done there [11:20] wallyworld, no worries, thanks [11:20] sorry [11:20] wallyworld, that's the trouble with branches, so many exciting opportunities to miss stuff [11:21] yeah [11:21] and we branched 1.24 off too early [11:21] way too early [11:44] wallyworld, that too === natefinch is now known as natefinch-afk [11:45] wallyworld, if you're still here: if I were to make SetStatus accept a StatusInfo, and apiserver responsible for setting the time, would that be a Bad Thing? [11:46] wallyworld, I probably won't either way, am trying not to distract myself [11:46] i'd rather apiserver not contain any business logic [11:46] business logic should be in a separate service layer [11:47] other services may call the status service to set the status [11:47] and we'd want the status service to set the time [11:48] wallyworld, so, apiserver->model->persistence, and the rules in model? [11:48] those other services may be co-located, hence the network layer would be short circuited [11:48] yes [11:49] i'd characterise it as apiserver->business_services->domain_model->persistence [11:49] business services sit on an enterprise bus [11:50] well, that implies the model knowing about persistence rather than vice versa, but that's an aside [11:50] they operate on a domain model, the model is independent of persistence [11:50] right [11:50] yea, the linear representation doesn't work [11:50] and the enterprise bus would provide pubsub, rpc, service discovery etc [11:51] wallyworld, so something akin to https://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html [11:51] wallyworld, or not? [11:51] looking [11:51] wallyworld, because the representation as services doesn't *necessarily* fit [11:52] yeah, my concept doesn't quite fit that particular model [11:53] wallyworld, and my current background thoughts are directed towards extracting an in-memory model layer, and moving business-rule responsibilities into there from state (but state still referencing the model) [11:53] wallyworld, the main driver for this is the uncommitted-state/transactionality stuff [11:53] agree with the above, need to think about the bit in brackets [11:54] by state, do you mean "persistence"? [11:54] wallyworld, in which I contend that having a dependency-free model representation, with a *single* and authoritative implementation of the business rules, is critical for composing and checking sanity of large logical operations without reference to db state [11:54] wallyworld, yeah [11:55] wallyworld, although it's sorta tricky because it's still going to have a bunch of consistency concerns that are hard enough to deserve thought [11:55] wallyworld, so, "state" as shorthand for "what's in state today, referencing business rules defined elsewhere" [11:55] state without the business rules [11:55] +1 for getting business rules right out of state [11:56] that would be a big win [11:56] for not that much effort in the big cheme of things [11:56] ideally, persistence would be abstracted so it were pluggable [11:56] that would help ensure a clean design [11:57] wallyworld, well, if you have insights, I want you to share them, because... *all* our business rules are encoded in dynamically generated strings of transaction operations [11:57] fwereade: that's an artifact of out current implementation, and sadly ties us to mongo, and sadly weaves separate concerns together [11:57] wallyworld, and I need a sane and comprehensible model of the world, its changes, and the conditions those changes require -- that I can effectively render down into txn operations [11:58] fwereade: we should be able to hand off model changes to a persistence layer, over a well defined interface boundary [11:59] we should nut this out next week [11:59] when i am less tired [11:59] wallyworld, sgtm :) [11:59] flagging a bit atm [11:59] wallyworld, sorry to keep you up [11:59] np, only 10pm but i'm tired [11:59] brain needs rest [12:00] hard to give decent answers and think deeply about complex issues [12:00] it's best to just avoid it ;) [12:26] morning [12:31] heya perrito666 [12:41] fwereade: did I completely miss you guys on actions? [12:41] jw4: ^^ [12:42] I realize I'm late coming out of the last meeting. [12:42] jam, heyhey, jw4 is having mic troubles [12:42] ah [12:51] nick natefinch === natefinch-afk is now known as natefinch [12:51] heh [12:51] *lol* [12:57] man, I *love* that we made workload processes use plugins and not hardcoded stuff from juju-core. It makes it trivial to produce specific fake technology plugins that mimic real ones without having to muddy juju-core codebase [13:44] mattyw: bug 1477157 [13:44] Bug #1477157: Broken windows dependencies

[13:44] Bug #1477157 opened: Broken windows dependencies

[13:45] mgz, ah crap, ack, I'll fix it [13:45] ta! [13:52] mgz, https://github.com/juju/juju/pull/2860 [13:56] TheMue: This is what I have so far for CreateSpace: https://github.com/juju/juju/compare/net-cli...dooferlad:net-cli-api-spaces-create?expand=1 [13:57] mattyw: shipit [13:57] dooferlad: one moment, will take a look in a few secs [13:58] TheMue: I am not doing any param checking in CreateSpace on the client side since the CLI already does that. This is also the case in api/action/client.go, but I wanted to start that conversation early. [13:59] dooferlad: spaces.go line 34 has a typo [14:00] TheMue: wasn't expecting a full code review, I just want to discuss client side params checking. [14:00] dooferlad: only seen it while flying over the code, eagle eyes *cough* *cough* [14:02] dooferlad: what do you think, could it make sense to rename the params type now, from add to create? simply using the opportunity [14:02] TheMue: sure [14:03] dooferlad: and when adding the subnetIds as tags into the params, don't work with append but make it with the right length and use the index [14:06] dooferlad: rest looks fine so far, I maybe would move testCreateSpace as a closure into TestCreateSpace. [14:06] perrito666, did wallyworld mention backporting status-history txnality to 1.24? [14:07] dooferlad: a very good example for the while testing is dimiterns instancepoller [14:07] perrito666, should be simple, 1.24 has state.Database now [14:07] fwereade: yup. already assigned me a card :) [14:07] perrito666, cool [14:07] perrito666, would you ping me when it's ready to review, I will at some stage become blocked on it [14:07] fwereade: sure [14:08] fwereade: want to tell me more? [14:08] perrito666, cheers [14:08] perrito666, I have to do gated service.SetStatus [14:09] perrito666, which means I need to at least touch the status-history storage [14:09] perrito666, and I would rather someone else had that change in place before I got involved in the details [14:10] fwereade: ill do as fast as possible :) [14:10] perrito666, oh, and if you're doing that, would you please make the updateStatusHistory signature match all the other similar funcs? (st, globalkey, doc) [14:11] fwereade: k [14:12] TheMue: http://reviews.vapour.ws/r/2241/ [14:22] dooferlad: reviewed [14:22] TheMue: Thanks! [14:23] dooferlad: yw [15:30] mgz, can we close this yet? https://bugs.launchpad.net/juju-core/+bug/1477157 [15:30] Bug #1477157: Broken windows dependencies

[15:31] bogdanteleaga, yeah - totally forgot to do the GOOS=windows thing [15:31] bogdanteleaga, copied and pasted an old script :( [15:31] mattyw: really the process is let ci bless the branhc and close the bug itself [15:32] mgz, ack [15:34] mattyw: heh, I remember doing that a few times, but I got scared when I did git diff :) [15:39] bogdanteleaga, I saw it in the diff, and got over excited by deps being removed [15:49] mattyw: haha [16:15] TheMue: could you take a look again at that review? [16:26] okay, new run on 1.24 branch has started [16:34] if you ever feel bad about a hack https://twitter.com/adrianchm/status/623485623538712576 [16:47] perrito666: lol, that's amazing [17:24] Bug #1476996 changed: Network communication failed during juju bootstrap

[18:29] juju upgrade on windows just passed for the first time. [18:29] * perrito666 cries [18:48] ericsnow: ping [18:49] wwitzel3: hey [18:49] ericsnow: never mind, I'm going ot look at the board [18:49] wwitzel3: k [18:50] ericsnow: we have an issue with the charm in that without having destroy available .. we can't really do much other than add-relattion [18:50] katco: ^ [18:51] wwitzel3: ah, because docker containers are static and need to be torn down anytime something changes? [18:51] katco: right [18:51] wwitzel3: you could add a basic proc-destroy script to the charm that calls juju-process-docker destroy... [18:54] wwitzel3: in case you missed it, I didn't merge that --extends patch (we didn't get it quite right) [18:54] wwitzel3: ericsnow: natefinch: wondering how critical it is to get that right just for the demo. we probably only need the container to spin up once, yeah? [18:55]