=== Spads_ is now known as Spads
menn0ericsnow: ping?00:25
ericsnowmenn0: hey00:25
menn0ericsnow: quick question... why is the vsphere provider set up to not build under gccgo or go 1.2?00:26
ericsnowmenn0: dependencies00:27
menn0ericsnow: 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 along00:27
ericsnowmenn0: (govmomi requires 1.3+)00:27
menn0ericsnow: but the ssh client should work fine?00:27
ericsnowmenn0: yep00:27
menn0ericsnow: ok, i'll mention that the build tag should go00:27
ericsnowmenn0: it's just the Go bindings to the vsphere API that were the problem00:27
menn0ericsnow: thanks00:28
ericsnowmenn0: np00:28
menn0ericsnow: 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:28
ericsnowmenn0: for vsphere I expect it's okay00:29
menn0ericsnow: any idea when it comes to rackspace? this PR is using the same code there.00:29
ericsnowmenn0: rackspace is openstack under the hood00:30
menn0ericsnow: and openstack does appear to support windows hosts, but I don't know about rackspace00:32
menn0ericsnow: i'l raise it as a possible issue. thanks.00:32
ericsnowmenn0: k, cool00:32
natefinchkatco, ericsnow, wwitzel3: evening01:08
katconatefinch: o/01:09
katconatefinch: i'm in moonstone. eric and wayne are taking a break01:09
wallyworldthumper: have you forward ported bug 1468581?02:20
mupBug #1468581: juju bootstrap fails - Waiting for API to become available ERROR cannot get all blocks: EOF <api> <bootstrap> <oil> <juju-core:In Progress by thumper> <juju-core 1.24:Fix Released by thumper> <https://launchpad.net/bugs/1468581>02:20
thumperI think so...02:20
thumperlet me check02:20
wallyworldaxw: and bug 147461402:20
mupBug #1474614: rsyslog connections fail with certificate verification errors after upgrade to 1.24.2 <regression> <juju-core:Triaged by axwalk> <juju-core 1.24:Fix Released by axwalk> <https://launchpad.net/bugs/1474614>02:20
wallyworldand there's a few from menno as well02:20
wallyworldmenn0 even02:21
axwwallyworld: 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
wallyworldah ok02:21
wallyworlddidn't read the bug :-)02:21
axwwallyworld: I'll look at doing that after I finish up what I'm working on02:21
wallyworldjust the milestone page02:22
wallyworldwe're aiming to cut 1.25 alpha 1 real soon02:22
wallyworldhence the follow up02:22
menn0wallyworld: i'm planning on doing the forward port for bug 1474195 this afternoon02:22
mupBug #1474195: juju 1.24 memory leakage <cpec> <deployer> <performance> <regression> <juju-core:In Progress by menno.smits> <juju-core 1.24:Fix Released by menno.smits> <https://launchpad.net/bugs/1474195>02:22
wallyworldawesome tyvm02:23
menn0wallyworld: actually, I lie. I have the PR ready for that but want Will's review (have emailed him)02:23
thumperwallyworld: no02:23
menn0wallyworld: i'm doing bug 1474606 this afternoon02:23
wallyworldmenn0: and the other 2 against you?02:23
mupBug #1474606: $set updates may clear out the env-uuid field <juju-core:In Progress by menno.smits> <juju-core 1.24:Fix Released by menno.smits> <https://launchpad.net/bugs/1474606>02:23
thumperwallyworld: I must have forgotten02:23
thumperbad me02:23
* wallyworld spanks thumper02:23
thumpernone of that02:24
menn0wallyworld: bug 1474588 is nowhere near investigated let alone fixed02:24
mupBug #1474588: Many hook failures after upgrade <regression> <juju-core:Triaged by menno.smits> <juju-core 1.24:Triaged by menno.smits> <https://launchpad.net/bugs/1474588>02:24
wallyworldmenn0: the othr one i was refering to in marked in progress bug 145722502:25
wallyworldwake up mup bug 145722502:26
wallyworldoh right, you answer that02:27
menn0wallyworld: mup knew that :)02:51
mupBug #1476895 opened: ec2: auto-created EBS volumes are not tagged <ec2-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1476895>02:52
mupBug #1476895 changed: ec2: auto-created EBS volumes are not tagged <ec2-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1476895>02:58
mupBug #1476895 opened: ec2: auto-created EBS volumes are not tagged <ec2-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1476895>03:16
katcoericsnow: wwitzel3: if by any chance you're lurking around, natefinch and i are in moonstone03:34
thumpermenn0: ignore http://reviews.vapour.ws/r/2234/03:37
axwwallyworld: would you PTAL at https://github.com/go-goose/goose/pull/1203:37
menn0thumper: happily ignoring :)03:38
wallyworldaxw: +103:39
axwwallyworld: ta03:40
menn0wallyworld: 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
mupBug #1474606: $set updates may clear out the env-uuid field <juju-core:In Progress by menno.smits> <juju-core 1.24:Fix Released by menno.smits> <https://launchpad.net/bugs/1474606>03:59
mupBug #1474195: juju 1.24 memory leakage <cpec> <deployer> <performance> <regression> <juju-core:In Progress by menno.smits> <juju-core 1.24:Fix Released by menno.smits> <https://launchpad.net/bugs/1474195>03:59
menn0wallyworld: can it wait until tomorrow?03:59
wallyworldmenn0: for both? can wait if necessary04:03
wallyworldi ping william later to make sure he reviews04:04
menn0wallyworld: thanks. the second one doesn't need will's review, just the one that's up.04:13
menn0wallyworld: i've emailed him about it as well.04:13
mupBug #1457797 changed: Juju bootstrap doesn't work behind proxy <bootstrap> <juju> <juju-core:Expired> <https://launchpad.net/bugs/1457797>04:25
mupBug #1457797 opened: Juju bootstrap doesn't work behind proxy <bootstrap> <juju> <juju-core:Expired> <https://launchpad.net/bugs/1457797>04:40
mupBug #1457797 changed: Juju bootstrap doesn't work behind proxy <bootstrap> <juju> <juju-core:Expired> <https://launchpad.net/bugs/1457797>04:46
mupBug #1476918 opened: juju switch doesn't work without an environments.yaml file <cli> <jes> <juju-core:Triaged> <https://launchpad.net/bugs/1476918>04:46
axwwallyworld: another small review if you don't mind: https://github.com/go-amz/amz/pull/5604:59
wallyworldjam: morning, would you have time soonish to talk about resources? in maybe 15 minutes when anastasia gets back from school pickup?05:18
jamwallyworld: sure, are you available now?05:40
wallyworldjam: 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 time05:41
wallyworldjam: you free now?06:06
jamwallyworld: sure06:06
* thumper looks around for urulama06:09
mupBug #1476996 opened: Network communication failed during juju bootstrap <juju-core:New> <https://launchpad.net/bugs/1476996>08:11
mupBug #1477010 opened: provider/openstack: volumes may not attach if instance takes a long time to provision <openstack-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1477010>08:47
dooferladfwereade: hangout?09:00
frankban_ocr: quick deps update http://reviews.vapour.ws/r/2238/ thanks!09:38
fwereadewallyworld, you still around?10:15
fwereadewallyworld, I'm wondering whether we need to read the whole previous status doc every time we set10:17
fwereadewallyworld, could we just write the same data to both the watched and the raw collections every time?10:18
fwereadewallyworld, (and fwiw I think it might be more reliable?)10:18
* fwereade was doing some python the other day and just spent *far* too long wondering why gofmt didn't like "def"10:38
bogdanteleagawallyworld: https://bugs.launchpad.net/juju-core/+bug/128794910:44
mupBug #1287949: {image,tools}-metadata-url not usable w/ ec2 provider <arm64> <config> <hs-arm64> <ppc64el> <juju-core:Triaged> <https://launchpad.net/bugs/1287949>10:44
wallyworldbogdanteleaga: by design, we currently only allow signed image metadata for ec2. i don't know the reason for that decision10:57
wallyworldthe the metadata were to be signed, it would work10:58
bogdanteleagayes, but as per the guy above me in the bug report10:58
bogdanteleagathere's no way of specifying a key10:59
bogdanteleagaso it has to be official?10:59
fwereadewallyworld, 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 key10:59
wallyworldfwereade: that is true, but for ec2 it currently requires user specified image metadata to be signed11:00
bogdanteleagadefinitely makes sense, but then there's no way of specifying custom images11:00
fwereadewallyworld, bogdanteleaga: I can't see any reason not to allow either additional keys or to allow unsigned -- so long as we check our source11:00
wallyworldand i don't know why11:00
fwereadewallyworld, nor do I but I strongly suspect it was an all-we-had-time-for deal11:00
wallyworldmaybe because - can people add custom images to ec2?11:01
fwereadewallyworld, yes, and IMO that's a good thing11:01
wallyworldmaybe the reasoning was, well if you can't add cutom images....11:01
bogdanteleagano, but there's no way of using a ec2 AMI that's not specified on cloud-images.ubuntu.com11:01
bogdanteleagai.e. a windows ami11:01
wallyworldthis was all done prior to windows :-)11:01
wallyworldso the code needs changing for windows11:02
bogdanteleagayeah, I'm aware and I do understand11:02
fwereadewallyworld, 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
bogdanteleagawas just signaling it's an actual bug and it's getting more important11:02
wallyworldfwereade: ec2 was configured to only use signed metadatsa before genetate metatdata came along11:02
wallyworldgenerate metadata was only for openstack11:03
wallyworldfor private clouds11:03
bogdanteleagaand I wasn't aware it was a design decision until now11:03
wallyworldwhere there were no official images11:03
wallyworldbogdanteleaga: it made sense at the time because there were no unofficial images possible11:03
fwereadewallyworld, 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 badwrongevil11:03
wallyworldfwereade: at the time, everything was based on simplestreams - that was our language11:04
wallyworldand only openstack had the need for custom images11:04
wallyworldand ec2 i think deliberately precluded them11:05
fwereadewallyworld, custom images are super-cool all over the place11:05
bogdanteleagaok, so for a fix: do we want to allow unsigned or to allow specifying a key?11:05
fwereadewallyworld, if we *just* let people do this we can have the big data folks deploying an image with their JVM already in place11:05
fwereadewallyworld, and cut their deployment times like anything11:05
wallyworldfwereade: i agree, but at the time it was impossible to have custom images for aws11:05
wallyworldso why support something impossibe11:06
fwereadewallyworld, I am certain that I was building custom images for aws before even ensemble was a thing11:06
wallyworldi'm guessing - maybe it was a policy deciison11:06
wallyworldnot sure now11:06
wallyworldbogdanteleaga: allow unsigned i think11:06
wallyworldto be consistent with ec211:07
wallyworldi meant11:07
bogdanteleagawallyworld: so I'm guessing ec2 is asking for signed only right? I was disabling it for everything for testing11:07
wallyworldfwereade: to answer your other question - i'm not sure why whole status record written each time - histerical reaosns?11:07
wallyworldbogdanteleaga: from memory there's a bool constant11:07
fwereadewallyworld, no, read each time, for copying into hysterical statues11:08
fwereadewallyworld, bogdanteleaga: it *would* IMO be best to allow specification of acceptable keys as well11:08
wallyworldfwereade: that's a bigger change, but sure11:08
wallyworldbut do we really need that straight up?11:09
fwereadewallyworld, bogdanteleaga: and that feels like something that shouldn't take too much per-env configuration11:09
fwereadewallyworld, 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 deploy11:10
wallyworldi agree, just ensuring it's the right time to do it11:11
bogdanteleagahow about I enable the unsigned one, and add a todo+bug report for doing signed with key11:11
fwereadewallyworld, bogdanteleaga: that sgtm11:11
wallyworldthat's what i was expecting to hapen11:11
fwereadewallyworld, bogdanteleaga: indeed11:11
fwereadebogdanteleaga, 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 juju11:12
fwereadewallyworld, anyway re status11:13
fwereadewallyworld, what I really want to do11:13
fwereadewallyworld, is have every setstatus method be11:13
fwereadego setHistoricalStatus(key, doc) // logs but ignore errors11:14
fwereade...and then to just set txnal status as usual11:14
fwereadewallyworld, if I *just* do that, we'll miss one hostirical value around an upgrade11:15
wallyworldfwereade: looking at the code, it seems that it is excluing the actual current status from the history?11:15
fwereadewallyworld, and if I take on an upgrade step as well I will feel I've strayed too far from "enable leadership"11:15
fwereadewallyworld, hmm, hadn't looked there11:16
fwereadewallyworld, any particular reason?11:16
fwereadewallyworld, seems surprising11:16
wallyworldmaybe "history" was taken as lieterally meaning in the past11:16
wallyworldbut yeah surprising11:16
fwereadewallyworld, <pedant>latest know status is still part of history because it was set in the past11:16
wallyworldfwereade: i can't see a reason not to make the change you suggest11:17
fwereadewallyworld, cool, thanks11:17
fwereadewallyworld, oh hell, status history is still txnal in 1.2411:19
fwereadewallyworld, shouldn't it be backported?11:19
wallyworlddamn, i'll ask horatio to backport - i thought it was done there11:19
fwereadewallyworld, no worries, thanks11:20
fwereadewallyworld, that's the trouble with branches, so many exciting opportunities to miss stuff11:20
wallyworldand we branched 1.24 off too early11:21
wallyworldway too early11:21
fwereadewallyworld, that too11:44
=== natefinch is now known as natefinch-afk
fwereadewallyworld, 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:45
fwereadewallyworld, I probably won't either way, am trying not to distract myself11:46
wallyworldi'd rather apiserver not contain any business logic11:46
wallyworldbusiness logic should be in a separate service layer11:46
wallyworldother services may call the status service to set the status11:47
wallyworldand we'd want the status service to set the time11:47
fwereadewallyworld, so, apiserver->model->persistence, and the rules in model?11:48
wallyworldthose other services may be co-located, hence the network layer would be short circuited11:48
wallyworldi'd characterise it as apiserver->business_services->domain_model->persistence11:49
wallyworldbusiness services sit on an enterprise bus11:49
fwereadewell, that implies the model knowing about persistence rather than vice versa, but that's an aside11:50
wallyworldthey operate on a domain model, the model is independent of persistence11:50
wallyworldyea, the linear representation doesn't work11:50
wallyworldand the enterprise bus would provide pubsub, rpc, service discovery etc11:50
fwereadewallyworld, so something akin to https://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html11:51
fwereadewallyworld, or not?11:51
fwereadewallyworld, because the representation as services doesn't *necessarily* fit11:51
wallyworldyeah, my concept doesn't quite fit that particular model11:52
fwereadewallyworld, 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
fwereadewallyworld, the main driver for this is the uncommitted-state/transactionality stuff11:53
wallyworldagree with the above, need to think about the bit in brackets11:53
wallyworldby state, do you mean "persistence"?11:54
fwereadewallyworld, 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 state11:54
fwereadewallyworld, yeah11:54
fwereadewallyworld, although it's sorta tricky because it's still going to have a bunch of consistency concerns that are hard enough to deserve thought11:55
fwereadewallyworld, so, "state" as shorthand for "what's in state today, referencing business rules defined elsewhere"11:55
fwereadestate without the business rules11:55
wallyworld+1 for getting business rules right out of state11:55
wallyworldthat would be a big win11:56
wallyworldfor not that much effort in the big cheme of things11:56
wallyworldideally, persistence would be abstracted so it were pluggable11:56
wallyworldthat would help ensure a clean design11:56
fwereadewallyworld, well, if you have insights, I want you to share them, because... *all* our business rules are encoded in dynamically generated strings of transaction operations11:57
wallyworldfwereade: that's an artifact of out current implementation, and sadly ties us to mongo, and sadly weaves separate concerns together11:57
fwereadewallyworld, 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 operations11:57
wallyworldfwereade: we should be able to hand off model changes to a persistence layer, over a well defined interface boundary11:58
wallyworldwe should nut this out next week11:59
wallyworldwhen i am less tired11:59
fwereadewallyworld, sgtm :)11:59
wallyworldflagging a bit atm11:59
fwereadewallyworld, sorry to keep you up11:59
wallyworldnp, only 10pm but i'm tired11:59
wallyworldbrain needs rest11:59
wallyworldhard to give decent answers and think deeply about complex issues12:00
wwitzel3it's best to just avoid it ;)12:00
TheMueheya perrito66612:31
jamfwereade: did I completely miss you guys on actions?12:41
jamjw4: ^^12:41
jamI realize I'm late coming out of the last meeting.12:42
fwereadejam, heyhey, jw4 is having mic troubles12:42
natefinch-afknick natefinch12:51
=== natefinch-afk is now known as natefinch
natefinchman, 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 codebase12:57
mgzmattyw: bug 147715713:44
mupBug #1477157: Broken windows dependencies <blocker> <ci> <regression> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1477157>13:44
mupBug #1477157 opened: Broken windows dependencies <blocker> <ci> <regression> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1477157>13:44
mattywmgz, ah crap, ack, I'll fix it13:45
mattywmgz, https://github.com/juju/juju/pull/286013:52
dooferladTheMue: This is what I have so far for CreateSpace: https://github.com/juju/juju/compare/net-cli...dooferlad:net-cli-api-spaces-create?expand=113:56
mgzmattyw: shipit13:57
TheMuedooferlad: one moment, will take a look in a few secs13:57
dooferladTheMue: 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:58
TheMuedooferlad: spaces.go line 34 has a typo13:59
dooferladTheMue: wasn't expecting a full code review, I just want to discuss client side params checking.14:00
TheMuedooferlad: only seen it while flying over the code, eagle eyes *cough* *cough*14:00
TheMuedooferlad: what do you think, could it make sense to rename the params type now, from add to create? simply using the opportunity14:02
dooferladTheMue: sure14:02
TheMuedooferlad: 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 index14:03
TheMuedooferlad: rest looks fine so far, I maybe would move testCreateSpace as a closure into TestCreateSpace.14:06
fwereadeperrito666, did wallyworld mention backporting status-history txnality to 1.24?14:06
TheMuedooferlad: a very good example for the while testing is dimiterns instancepoller14:07
fwereadeperrito666, should be simple, 1.24 has state.Database now14:07
perrito666fwereade: yup. already assigned me a card :)14:07
fwereadeperrito666, cool14:07
fwereadeperrito666, would you ping me when it's ready to review, I will at some stage become blocked on it14:07
perrito666fwereade: sure14:07
perrito666fwereade: want to tell me more?14:08
fwereadeperrito666, cheers14:08
fwereadeperrito666, I have to do gated service.SetStatus14:08
fwereadeperrito666, which means I need to at least touch the status-history storage14:09
fwereadeperrito666, and I would rather someone else had that change in place before I got involved in the details14:09
perrito666fwereade: ill do as fast as possible :)14:10
fwereadeperrito666, oh, and if you're doing that, would you please make the updateStatusHistory signature match all the other similar funcs? (st, globalkey, doc)14:10
perrito666fwereade: k14:11
dooferladTheMue: http://reviews.vapour.ws/r/2241/14:12
TheMuedooferlad: reviewed14:22
dooferladTheMue: Thanks!14:22
TheMuedooferlad: yw14:23
mattywmgz, can we close this yet? https://bugs.launchpad.net/juju-core/+bug/147715715:30
mupBug #1477157: Broken windows dependencies <blocker> <ci> <regression> <windows> <juju-core:In Progress by mattyw> <https://launchpad.net/bugs/1477157>15:30
mattywbogdanteleaga, yeah - totally forgot to do the GOOS=windows thing15:31
mattywbogdanteleaga, copied and pasted an old script :(15:31
mgzmattyw: really the process is let ci bless the branhc and close the bug itself15:31
mattywmgz, ack15:32
bogdanteleagamattyw: heh, I remember doing that a few times, but I got scared when I did git diff :)15:34
mattywbogdanteleaga, I saw it in the diff, and got over excited by deps being removed15:39
bogdanteleagamattyw: haha15:49
dooferladTheMue: could you take a look again at that review?16:15
mgzokay, new run on 1.24 branch has started16:26
perrito666if you ever feel bad about a hack https://twitter.com/adrianchm/status/62348562353871257616:34
natefinchperrito666: lol, that's amazing16:47
mupBug #1476996 changed: Network communication failed during juju bootstrap <bootstrap> <mongodb> <juju-core:New> <https://launchpad.net/bugs/1476996>17:24
mgzjuju upgrade on windows just passed for the first time.18:29
* perrito666 cries18:29
wwitzel3ericsnow: ping18:48
ericsnowwwitzel3: hey18:49
wwitzel3ericsnow: never mind, I'm going ot look at the board18:49
ericsnowwwitzel3: k18:49
wwitzel3ericsnow: we have an issue with the charm in that without having destroy available .. we can't really do much other than add-relattion18:50
wwitzel3katco: ^18:50
katcowwitzel3: ah, because docker containers are static and need to be torn down anytime something changes?18:51
wwitzel3katco: right18:51
ericsnowwwitzel3: you could add a basic proc-destroy script to the charm that calls juju-process-docker destroy...18:51
ericsnowwwitzel3: in case you missed it, I didn't merge that --extends patch (we didn't get it quite right)18:54
katcowwitzel3: 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:54
katcowwitzel3: ericsnow: natefinch: i.e. i don't know if it's worth the time to write a destroy script18:55
ericsnowkatco: well, the script would just be a one-liner call to the plugin18:56
wwitzel3I don't even have to make a script18:56
wwitzel3I can just call it directly from the charm18:56
wwitzel3which I just tested, it works18:56
ericsnowwwitzel3: true18:56
katcowwitzel3: pft. over achiever18:57
wwitzel3I'm going a end to end of the latest charm now, no intervention, will see how it goes18:58
* katco crosses fingers18:58
wwitzel3katco: it worked here, so please give it a try19:00
wwitzel3ericsnow: how did we get the parseUpdates wrong? ..19:00
wwitzel3ericsnow: nvm I'll look at the reivew19:00
katcowwitzel3: cool, pull from gh?19:00
wwitzel3katco: yep19:00
ericsnowwwitzel3: we weren't supposed to apply the updates to c.info19:01
ericsnowwwitzel3: I left a review comment19:01
mupBug #1477263 opened: Enabling allow-lxc-loop-mounts can cause error when destroying an environment <juju-core:New> <https://launchpad.net/bugs/1477263>19:06
wwitzel3ericsnow: so when I implement the changes you suggested, our test suite fails all over the place :(19:16
ericsnowwwitzel3: :(19:17
ericsnowwwitzel3: likely due to s.setMetadata calls19:17
ericsnowwwitzel3: I can take over that patch if you need to work on the charm19:18
wwitzel3ericsnow: that would be great19:18
ericsnowwwitzel3: k19:18
katcowwitzel3: hm. i think i'm doing something wrong19:36
katcowwitzel3: i deploy wordpress-wpm, i deploy mysql19:36
katcowwitzel3: i relate them19:36
katcowwitzel3: but wordpress-wpm is stuck in the install hook19:36
wwitzel3katco: the install can take a while .. since we pull the image down19:36
wwitzel3katco: how long has it been stuck?19:36
katcowwitzel3: most likely longer than it should be19:39
katcowwitzel3: like... 15m maybe? i dunno i'm hopping around a lot19:39
katcowwitzel3: actually more like 25 doing some timestamp math19:39
katcowwitzel3: what order do you do things in?19:40
wwitzel3katco: it shouldn't matter :)19:40
katcowwitzel3: very true :)19:40
wwitzel3katco: sounds like the install hook is getting hungup on the pull19:40
katcowwitzel3: debug-log just spams: unit-wordpress-wpm-0[2980]: 2015-07-22 19:40:44 INFO unit.wordpress-wpm/0.install logger.go:4019:40
katcowwitzel3: empty log message19:41
katcowwitzel3: so i'm not missing any steps? just need to relate the two, yeah?19:41
wwitzel3katco: I'm doing a fresh deploy, see if I get that same install hook hanging issue19:43
katcowwitzel3: k, i'm retrying as well19:43
katcowwitzel3: weird... docker.io is consuming most of the cpu19:48
katcowwitzel3: but the image isn't listed19:48
katcowwitzel3: any ideas why docker.io would be spinning? never seen that19:51
wwitzel3katco: no idea, my install hook is spinning as well20:02
wwitzel3katco: I am wondering if there is just not enough time between installing the docker.io service and starting it and issuing the pull20:03
wwitzel3katco: going to try it with a sleep, see if that helps20:03
katcowwitzel3: doesn't apt-get install docker.io start the docker.io service already?20:03
katcowwitzel3: instead of a sleep, query the status of the service20:03
mupBug #1477281 opened: machine#0 jujud using ~100% cpu, slow to update units state <canonical-bootstack> <canonical-is> <juju-core:New> <https://launchpad.net/bugs/1477281>20:06
katcorunning into bug 1168154 too20:07
mupBug #1168154: Destroying a service in error state fails silently <destroy-service> <juju-core:Triaged> <https://launchpad.net/bugs/1168154>20:07
natefinchericsnow: process.Info.Id()'s comment states "ID composes a unique ID for the process" .... does that mean that we don't expect the process name to be unique?20:08
ericsnownatefinch: potentially20:09
natefinchericsnow: the reason I ask is that the status output as stated in the spec is using the process name as the key to a map, so if there's a collision.... badness20:09
ericsnownatefinch: we had discussed support for launching multiple copies of a proc20:09
ericsnownatefinch: I suppose we can cross the bridge later20:10
natefinchwe seem to be doing a lot of "let's worry about that later" with this feature, which makes me worry about it now.20:11
ericsnownatefinch: well, currently we don't support multiple copies of a proc (and we may never)20:12
natefinchericsnow: fair enough20:13
natefinchericsnow: I'm all good with YAGNI, so long as it's not YAGNIUNW  (You ain't gonna need it ... until next week)20:13
ericsnownatefinch: :)20:14
bogdanteleagamgz: yay!20:22
bogdanteleagaperrito666: tears of joy? :p20:22
perrito666bogdanteleaga: ??20:23
bogdanteleaga<mgz> juju upgrade on windows just passed for the first time.20:24
bogdanteleaga* perrito666 cries20:24
perrito666ah si20:25
wwitzel3katco: looks like there is an issue with the registry20:26
wwitzel3katco: I can't pull the wp container at all, atm20:26
katcowwitzel3: as in the official docker registry?20:26
wwitzel3katco: yeah20:26
katcowwitzel3: well that explains things lol. do they have a status page or something?20:26
natefinchoh great, one more thing to break20:27
katcowwitzel3: https://status.docker.com/20:28
wwitzel3katco: nope, but after running it 4 or 5 times it started working :)20:28
wwitzel32015/07/22 20:19:45 Could not find repository on any of the indexed registries.20:28
wwitzel3Pulling repository wordpress20:28
wwitzel348e924db07d1: Pulling dependent layers20:28
wwitzel3so now it works, lol20:28
wwitzel3aaaand now it doesn't work again, wtf20:30
katcowwitzel3: i wonder if there's a route issue b/t ec2 <-> registry?20:31
wwitzel3katco: something weird for sure, it is working locally jsut fine20:34
katcowwitzel3: again, top shows docker.io is spinning20:34
katcowwitzel3: i'll try pulling it manually, but yeah something odd is happening20:35
katcowwitzel3: whoa: $ docker pull wordpress20:36
katco2015/07/22 20:35:39 Post http:///var/run/docker.sock/images/create?fromImage=wordpress&tag=: dial unix /var/run/doc20:36
katcoker.sock: permission denied20:36
katcowwitzel3: does it have to be sudo pull?20:36
katcowwitzel3: says job is already started. log doesn't have anything interesting20:37
wwitzel3katco: you have to be in the group or you have to be sudo, yes20:41
katcowwitzel3: cycled docker.io service, now: Could not find repository on any of the indexed registries.20:45
katco[a0bad6af] -job pull(wordpress, latest) = ERR (1)20:45
wwitzel3katco: yeah, something odd is going on since it was working with out incident the dozen other times I did it today20:48
wwitzel3and yesterday20:48
mupBug #1477293 opened: Bootstrap attempts to use a private network address instead of the public address <bootstrap> <ec2-provider> <network> <juju-core:Triaged> <juju-core jes-cli:Triaged> <https://launchpad.net/bugs/1477293>21:00
mupBug #1477293 changed: Bootstrap attempts to use a private network address instead of the public address <bootstrap> <ec2-provider> <network> <juju-core:Triaged> <juju-core jes-cli:Triaged> <https://launchpad.net/bugs/1477293>21:03
katcowwitzel3: so i'm pulling this manually from the ec instance, and it's doing "stuff", but it keeps returning to a header "pulling fs layer"21:04
wwitzel3katco: yeah, it should do that for a while21:05
wwitzel3katco: and download little bits and fs layers21:05
katcowwitzel3: just seems to be taking a long, long time21:05
wwitzel3katco: yeah, the registry isn't fast21:05
wwitzel3katco: I've had it take 20 minuites or longer to get an image21:05
katcowwitzel3: k21:05
wwitzel3katco: once I get another copy of it downloaded successfully21:09
wwitzel3katco: I'll put it in the charm and we can just load it locally21:09
wwitzel3katco: so we won't have to worry about network for it21:09
katcowwitzel3: good idea. or i wonder if we have a docker repo charmed up :)21:09
mupBug #1477293 opened: Bootstrap attempts to use a private network address instead of the public address <bootstrap> <ec2-provider> <network> <juju-core:Triaged> <juju-core jes-cli:Triaged> <https://launchpad.net/bugs/1477293>21:09
perrito666katco: can I get an amen http://reviews.vapour.ws/r/2244/ ?21:19
katcoperrito666: tal21:20
* perrito666 brain makes an odd connection and its taken back to the past to the zope template attribute language21:21
katcoperrito666: did we address fwereade's concern in the todo there?21:23
perrito666yup, that is what the pr does :D removing all trace of txn in status history21:23
perrito666pure raw metal.. err mongo insertion :p21:23
katcoperrito666: i recall him disagreeing with that approach pretty strongly. i can't remember if it was ever resolved. hm21:25
perrito666katco: he did disagree with a previous patch, which led to uncovering an issue in envuuid automatic patching21:26
perrito666I recalled that pr and made this new one21:26
katcoperrito666: well not just the patch, but the idea of doing "raw" mongo ops w/o txns21:26
perrito666katco: in this particular case it was his idea to completely remove, history works much like logs21:27
perrito666we push on the top and remove on the bottom21:27
katcoperrito666: yeah i recall the counter-argument, i guess i never saw it get resolved21:28
katcoperrito666: i have a meeting now, ian is in it, so i'll talk to him too21:28
perrito666fantastic :)21:28
katcoperrito666: you're good! :D21:33
cmarswaigani or menn0, could one of you review http://reviews.vapour.ws/r/2167/?21:34
perrito666oh, blocked again, it was good while it lasted21:37
menn0cmars: i'll take a look21:40
cmarsmenn0, thanks!21:40
ericsnowwwitzel3: http://reviews.vapour.ws/r/2245/21:48
menn0cmars: done. just a few little things.21:51
menn0cmars: fwereade is right though: this will need to change soon when env destruction is done properly. But this is fine for now.21:53
sinzuikatco: https://launchpad.net/juju-core/1.26 exists. I as does https://launchpad.net/juju-core/+milestone/1.26.021:54
katcosinzui: ty sir!21:54
cmarsmenn0, ok, we'll have to watch out for that .. any advance notice would be helpful, we're ready to make whatever changes necessary21:56
menn0cmars: you guys might not need to worry about it. we just have to move when the last ditch metric sending happens to somewhere else.22:00
cmarsmenn0, gotcha22:00
menn0cmars: the plan is to have a state server worker that manages environment life cycle instead of doing env destruction synchronously in the api call22:01
menn0cmars: b/c as it stands if anything goes wrong (e.g. machine destruction get stuck) the user has very little visibility22:02
menn0cmars: we also need to shut down things like storage in a more controlled fashion22:02
menn0cmars: all this will happen "soon". we'll keep you in the loop but you don't need to worry too much about it.22:03
cmarsmenn0, ack. cool stuff. the env lifecycle mgmt sounds especially interesting22:03
katcosinzui: i proposed a blueprint for 1.26... who does that approval go to?22:04
menn0cmars: interesting/necessary whatever :)22:04
sinzuikatco: I think mramm, the driver of the project22:05
katcosinzui: ah ok22:05
sinzuiwallyworld: abentley my go1.4 juju on vivid is succeeding22:05
wallyworldoh interesting22:05
wallyworldcan we drop the bug then :-)22:06
katcosinzui: what is feature-proc-mgmt in this context? https://bugs.launchpad.net/juju-core/feature-proc-mgmt22:07
sinzuikatco: There is/was a branch in github that was tested and failed. We registered the series to report bugs against it22:09
katcosinzui: ah ok. i just created a blueprint... would it make more sense to report bugs against that? or is series considered a branch in lp parlance?22:10
sinzuikatco: I wish the later part of your statement was 100% true. A series should be assocated with a branch. A line of development that changes will be made too. Lp doesn't enforce the branch22:11
katcosinzui: would it be an imposition to ask you to target bugs against the blueprint instead?22:12
sinzuikatco: Thate is difficult to do22:13
katcosinzui: in an automated fashion, or just in general?22:13
sinzuikatco: bugs can be linked ot a blueprint, but since the blueprint feasture is broken in many places, I cannot do it22:13
katcosinzui: oh, it's a permissions/lacking feature thing?22:14
sinzuialso the blueprints cannot be managed by the team. You for example could make the milkestone and series, but blueprints don't have sane ownership22:14
katcosinzui: not sure what you mean? i am the starter, drafter, and assignee, and i can link bugs... do you mean no one BUT the starter can assign bugs?22:15
sinzuikatco I am not writing software to use blueprints, you are free to link issues you want fixes in blueprints. CI is not concerned with feature planning22:17
thumperwallyworld: menno said he'd look at the go 1.3 on vivid issue23:24
menn0sinzui: ping?23:44
menn0sinzui, wallyworld: i'm trying to be sure what the aws-deploy-trusty-amd64-on-vivid-amd64 CI job does23:45
menn0I think it means, deploy an EC2 env using trusty instances, with the client running on vivid23:45
menn0sinzui, wallyworld, mgz: is that right?23:45
mgzmenn0: that's correct23:47
mgzmenn0: it's mostly just exercising the vivid client23:47
mgzmenn0: unrelated, I added some comments to the rackspace provider review23:48
menn0mgz: ok cool. i only managed to look at some of it.23:48
menn0mgz: i'm currently looking at bug 147729323:49
mupBug #1477293: Bootstrap fails to connect on vivid/go 1.3 <blocker> <bootstrap> <ci> <ec2-provider> <network> <vivid> <juju-core:Triaged> <juju-core 1.24:Triaged by menno.smits> <https://launchpad.net/bugs/1477293>23:49
menn0mgz: I can only see one CI run where bootstrap failed due to not being able to connect23:49
mgzmenn0: on the ssh bug, I feel like it's just as likely to be another manifestation of ssh config screwing up juju as anything else23:49
menn0mgz: and it works for me23:49
menn0mgz: the other failed runs with the same rev seem to be something else23:49
menn0mgz: so i'm looking at that23:50
mgzjuju 1.24 makes ssh generally dodgy in the presence of any existing ssh setup23:50
menn0mgz: what do you mean by "any existing ssh setup"?23:50
mgzeg, I have ~/.ssh/config with stuff in it and an agent and several keys23:50
mgzjuju doesn't like me much.23:51
wallyworldthumper: menn0: sorry, just got out of meeting, reading backscroll23:51
menn0mgz: hmmm, I have that too and it works for me. but of course it might something specific in your config.23:51
mgzmenn0: the other failed runs at the same rev look like job setup debugging23:51
menn0mgz: the bootstrap is failing: "Bootstrap failed, destroying environment"23:52
menn0mgz: but i'm not sure why23:52
wallyworldmenn0: mgz: sinzui switched to go 1.4 and said it worked23:52
mgznah, he tried the same thing via osx which happens to use go 1.4 and it works23:52
menn0Juju cannot bootstrap because no tools are available for your environment.23:52
wallyworldif it is a go 1.3 issue, then i say we don't fix anything23:52
menn0mgz: there it is23:52
wallyworldmgz: oh, i thought we were going to use everything the exact same, but just switck go verson23:53
menn0so the earlier CI failures were due to missing tools23:53
mgzoh, he did also use go 1.4 on ubuntu, but wily23:54
mgzbut that's still proxuing through a different machine23:54
wallyworldbut we want a controlled experiement23:54
mgzso it's hard to make it identical23:54
wallyworldonly changde one thing23:54
wallyworldcan't we switch go version on the vivid machine23:55
mgzwe could download and build go 1.4 on that machine and make the job use it maybe23:56
katcowwitzel3: /entrypoint.sh apach   19 minutes ago      Exited (1)23:57
katcowwitzel3: 2015/07/22 23:36:38 Stopping proxy on tcp/[::]:8080 for tcp/ (accept tcp [::]:8080: use of closed network connection)23:57
mgzI think going through the workspace runner just tickles ssh issues23:59

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