| axw_ | wallyworld: one thing we talked about after you'd gone on Friday was that remotestate should probably be renamed to "goal state" or "desired state", and we'll move all watcher-related things in there | 01:23 |
|---|---|---|
| axw_ | wallyworld: and that updating status should move into there | 01:23 |
| axw_ | wallyworld: I've just found that updating status is done as a separate channel in the loop, so I'll move that over... maybe not immediately, depends on how much it gets in the way of testing | 01:24 |
| wallyworld | name change sounds good. not sure about adding in update status though | 01:24 |
| wallyworld | i think polling update status should be a uniter responsbility | 01:25 |
| wallyworld | maybe it could be in goal state; if stuff is changing and we are running hook regularly, no need for polling a charm's status. | 01:26 |
| wallyworld | but seems kinda othogonal to goal state to me | 01:27 |
| axw_ | wallyworld: I just don't want there to be a lot of concurrency spread around again | 01:28 |
| wallyworld | yeah, i was mulling over the same thought | 01:29 |
| axw_ | wallyworld: and I'd like to keep as much business logic out of the loop as possible | 01:30 |
| rick_h_ | wallyworld: got a sec to chat? can you ping when you do? | 01:30 |
| wallyworld | rick_h_: sure, now? | 01:30 |
| rick_h_ | wallyworld: sure thing https://plus.google.com/hangouts/_/canonical.com/daily-standup?authuser=1 adjust authuser | 01:31 |
| mup | Bug #1489215 opened: Output from metadata generate-image looks bad <juju-core:New> <https://launchpad.net/bugs/1489215> | 01:32 |
| davechen1y | sinzui: wallyworld anyone https://bugs.launchpad.net/juju-core/+bug/1489218 | 01:37 |
| mup | Bug #1489218: go get cannot fetch launchpad.net/gomassapi <juju-core:New> <https://launchpad.net/bugs/1489218> | 01:37 |
| davechen1y | can you reproduce this issue ? | 01:37 |
| davechen1y | mwhudson: https://bugs.launchpad.net/juju-core/+bug/1489218 | 01:37 |
| davechen1y | is this related to the launchpad change that happened recently ? | 01:37 |
| sinzui | davechen1y: I think someone renamed ir disbaled the project! | 01:38 |
| mwhudson | davechen1y: gomassapi or gomaasapi? | 01:38 |
| davechen1y | good point | 01:39 |
| davechen1y | i think i fat fingered it trying to investigate https://bugs.launchpad.net/juju-core/+bug/1489217 | 01:40 |
| mup | Bug #1489217: godeps -u dependencies.tsv from scratch fails with Go 1.5 <juju-core:New> <https://launchpad.net/bugs/1489217> | 01:40 |
| sinzui | :) | 01:40 |
| mwhudson | oh good | 01:40 |
| mwhudson | message is plenty confusing though | 01:40 |
| * mwhudson disappears | 01:40 | |
| mup | Bug #1489217 opened: godeps -u dependencies.tsv from scratch fails with Go 1.5 <juju-core:New> <https://launchpad.net/bugs/1489217> | 01:56 |
| wallyworld | davechen1y: looking, was otp | 01:56 |
| wallyworld | davechen1y: oh, just read backscroll. ooops | 01:57 |
| davechen1y | wallyworld: what do to | 02:00 |
| davechen1y | ? | 02:00 |
| davechen1y | something is screwed with that repo in a way we cannot detect with the build bot | 02:01 |
| wallyworld | not sure, i'll ask in the lauchpad channel if i can reporoduce | 02:02 |
| menn0 | waigani: review please: http://reviews.vapour.ws/r/2496/ | 02:08 |
| wallyworld | davechen1y: so it's only a go 1.5 thing? i'm still on 1.4 and it's fine for me | 02:22 |
| wallyworld | so what would there be to fix in launchpad | 02:23 |
| mup | Bug #1489131 changed: BootstrapSuite.TestRunTests fails on non-amd64 archs <blocker> <ci> <ppc64el> <regression> <test-failure> <unit-tests> <juju-core:Fix Released by cherylj> <https://launchpad.net/bugs/1489131> | 02:26 |
| mup | Bug #1489131 opened: BootstrapSuite.TestRunTests fails on non-amd64 archs <blocker> <ci> <ppc64el> <regression> <test-failure> <unit-tests> <juju-core:Fix Released by cherylj> <https://launchpad.net/bugs/1489131> | 02:32 |
| mup | Bug #1489131 changed: BootstrapSuite.TestRunTests fails on non-amd64 archs <blocker> <ci> <ppc64el> <regression> <test-failure> <unit-tests> <juju-core:Fix Released by cherylj> <https://launchpad.net/bugs/1489131> | 02:35 |
| waigani | menn0: done. I replied to your review also. | 02:38 |
| davechen1y | wallyworld: i believe mwhudson made (or asked) for a change to happen in the Go tool that made launchpad less special | 02:58 |
| davechen1y | so depdency resolution for lp repos has changed | 02:58 |
| davechen1y | i don't know the details | 02:58 |
| wallyworld | ah ok | 02:58 |
| wallyworld | but the change was made in Go | 02:58 |
| wallyworld | so Go needs to be fixed, not launchpad | 02:59 |
| axw_ | wallyworld: in my upgrade branch, I'm getting a failure at https://github.com/juju/juju/blob/maltese-falcon/worker/uniter/uniter_test.go#L346. in my branch, the config-changed doesn't happen because it was resolved without retry above | 03:38 |
| axw_ | wallyworld: seems that previously we would run another config-changed after start, even if we resolved without retry a previous config-changed | 03:39 |
| axw_ | wallyworld: seems wrong to me. what do you think? | 03:39 |
| wallyworld | it does but i'd defer to william for a definitive answer. maybe tweak the test with a todo and land and then i can ask him tonight | 03:40 |
| axw_ | wallyworld: sounds good, thanks | 03:42 |
| axw_ | wallyworld: also fixing a bug in storage resolver, it's running storage-attached for unattached (but "alive") storage attachments | 03:42 |
| davechen1y | https://github.com/juju/juju/pull/3119 | 04:16 |
| davechen1y | anyone ? | 04:16 |
| dimitern | wallyworld, hey, still about? | 05:23 |
| wallyworld | dimitern: hey. thanks for taking up those bugs, sorry for not saying good morning in the email :-) | 05:23 |
| dimitern | wallyworld, oh :) no worries at all | 05:24 |
| dimitern | wallyworld, the backport didn't happen, but it should today I hope | 05:24 |
| wallyworld | no hurry with that - we are concentrating on 1.25 right at the moment | 05:25 |
| dimitern | wallyworld, the other armhf issue - I have access to the lab and their maas, but need to investigate today | 05:25 |
| wallyworld | was meant to go out today but there was a regression | 05:25 |
| dimitern | wallyworld, oh? which one this time.. | 05:25 |
| wallyworld | a test failure due to arch != amd64 | 05:25 |
| dimitern | wallyworld, and btw you're perhaps the perfect person to ask - how to set up armhf tools/images/metadata/etc. locally? | 05:26 |
| wallyworld | use juju metadata generate-images | 05:26 |
| wallyworld | that will put metadata in a directory | 05:27 |
| wallyworld | you specify the directory with -d | 05:27 |
| dimitern | wallyworld, I guess I can use the 1.24.5 (was it?) release packages.. but no upgrade --upload-tools then, which is not good for debugging | 05:27 |
| wallyworld | or else i think it uses ~/.juju | 05:27 |
| dimitern | wallyworld, ah, ok will try this | 05:27 |
| dimitern | wallyworld, so far istm to debug the issue I need to start another armhf node to build juju from source on it :) | 05:28 |
| wallyworld | you can't geneate arm tools though unless you're on arm of course | 05:28 |
| wallyworld | assuming use used -d mydir | 05:28 |
| wallyworld | then you bootstrap with | 05:28 |
| dimitern | yeah | 05:28 |
| wallyworld | juju bootstrap --metadata-source mydir | 05:29 |
| wallyworld | the tools command is juju metadata generate-tools | 05:29 |
| dimitern | it was asking if my agent-tools-url is set correctly btw | 05:29 |
| wallyworld | it will do that if it can't find tools | 05:29 |
| dimitern | right | 05:29 |
| dimitern | but generate-tools will need already built arm binaries, right? could they be simply in $PATH? | 05:30 |
| wallyworld | generate tools will build the tools from source if there's no binary in the path | 05:31 |
| wallyworld | i think | 05:31 |
| axw_ | wallyworld: would you please review the final commit on https://github.com/juju/juju/pull/3105/commits? | 05:32 |
| wallyworld | sure | 05:32 |
| dimitern | good, so if I manage to build it from source on an arm machine, then do generate-images and generate-tools, I should be able to bootstrap a custom binary | 05:32 |
| axw_ | wallyworld: various bugs cropped up when I made my sweeping change for upgrades | 05:32 |
| wallyworld | that's what tests are for :-) | 05:32 |
| wallyworld | axw_: lgtm. i assume we delete the operation.Queued check in the leader resolved because that's handled externally. now that i think about it, i also seem to maybe recall that the could have been a blanket policy to always run config changed after a start hook just because, but i'll check with william | 05:42 |
| axw_ | wallyworld: you assume correctly. ok, thanks. we'll need to update resolvers if that's the case, so best done in a separate branch anyway | 05:43 |
| wallyworld | yup | 05:44 |
| wallyworld | axw_: school pickup time, but here's a trivial http://reviews.vapour.ws/r/2499/ | 05:50 |
| wallyworld | axw_: could you ltgm and merge for me while i'm out, ty | 05:50 |
| axw_ | wallyworld: sure | 05:52 |
| wallyworld | axw_: thanks for landing. what bit you working on now? | 06:43 |
| axw_ | wallyworld: TestUniterUpgradeConflicts | 06:44 |
| wallyworld | just as the board says, doh | 06:44 |
| axw_ | wallyworld: just about ready to land | 06:44 |
| axw_ | I mean propose | 06:44 |
| wallyworld | i wonder if that will fix any of the other upgrade ones, maybenot | 06:44 |
| axw_ | ashipika: I had to make the remoteState.Life==Dead check for another test, so it's also in https://github.com/juju/juju/pull/3121 | 06:53 |
| axw_ | ashipika: I didn't uncomment the unit test you're working on though, cos it still fails for some other reason | 06:53 |
| ashipika | axw_: ack! | 06:54 |
| axw_ | wallyworld: UniterSuite.TestUniterUpgradeGitConflicts works with my branch, with a trivial change to expect leader-settings-changed | 06:55 |
| wallyworld | axw_: great :-) assign yourself to the card | 06:56 |
| wallyworld | luckily i had just phone my niece for her birthday so hadn't started yet | 06:56 |
| axw_ | wallyworld: I'll check the other upgrade tests before sending a change | 06:56 |
| axw_ | cool | 06:56 |
| wallyworld | sounds good, i'm hoping they may work of the changes to make them work are trivial | 06:57 |
| axw_ | yeah the other one is fixed too | 06:58 |
| axw_ | wallyworld: I'll just update my current PR | 06:58 |
| wallyworld | yup | 06:58 |
| ashipika | axw, wallyworld: can you assign/move corresponding cards on the uniter sprint board, as well? | 07:17 |
| wallyworld | ashipika: we are :-) | 07:17 |
| ashipika | wallyworld: excellent! :) | 07:18 |
| wallyworld | getting there slowly | 07:18 |
| wallyworld | and sometimes quickly | 07:18 |
| wallyworld | axw_: i had a couple of questions on the review | 07:21 |
| axw_ | wallyworld: thanks for the review. please see my replies, let me know if they make sense | 07:37 |
| wallyworld | looking | 07:37 |
| wallyworld | axw_: let's get it landed | 07:41 |
| axw_ | wallyworld: ta | 07:41 |
| axw_ | wallyworld: any idea why we run actions in ModeTerminating? | 07:42 |
| wallyworld | nope. i didn't realise we did. i'm curious as to why | 07:43 |
| dimitern | dooferlad, morning | 07:45 |
| dooferlad | hi | 07:45 |
| dimitern | dooferlad, since we discussed the needed changes around provider/ec2, I've landed the foundation that should give the provider what it needs - subnets-to-zones map | 07:46 |
| dimitern | dooferlad, so, slight change of plans, hopefully simplifying what's left | 07:46 |
| dooferlad | dimitern: great. Just dealing with email then will take a look. I spotted that you had done something in that area. | 07:48 |
| dimitern | dooferlad, ok | 07:49 |
| voidspace | dimitern: I don't know if you saw my message yesterday | 08:42 |
| voidspace | dimitern: that forward port is already on trunk | 08:42 |
| voidspace | dimitern: is there an issue for me to close related to it? | 08:43 |
| dimitern | voidspace, yeah, I've updated the card | 08:45 |
| dimitern | voidspace, it's a backport to 1.24, not forward port to master | 08:45 |
| dimitern | voidspace, sorry, my bad :/ | 08:45 |
| voidspace | dimitern: hah! | 08:46 |
| voidspace | dimitern: ok, that's easy to do :-) | 08:46 |
| dimitern | voidspace, yep ;) | 08:46 |
| voidspace | dimitern: and for the IP address bug I'm targetting 1.24 and will forward port when it's done | 08:47 |
| dimitern | voidspace, sounds good | 08:48 |
| voidspace | dimitern: PR created, just running tests | 08:52 |
| dimitern | voidspace, awesome! | 08:53 |
| mup | Bug #1489346 opened: /var/lib/juju/db taking lots of disk space <juju-core:New> <https://launchpad.net/bugs/1489346> | 09:01 |
| axw_ | wallyworld: there's a bug in remotestate watcher. I'm going out in a little while to the school, will fix it later on. just letting you know in case anyone sees weird timing errors like http://juju-ci.vapour.ws:8080/job/github-merge-juju/4504/consoleFull | 09:01 |
| voidspace | dimitern: thanks for the LGTM | 09:02 |
| voidspace | dimitern: I still have the problem that running all cmd/juju tests times out on my main box | 09:02 |
| voidspace | dimitern: going to run just the upgrade tests | 09:02 |
| dimitern | voidspace, have you tried make check? | 09:03 |
| dimitern | voidspace, dooferlad, standup | 09:04 |
| voidspace | dimitern: ah, that does a full test run | 09:04 |
| voidspace | dimitern: just kicked it off | 09:04 |
| voidspace | omw | 09:04 |
| mattyw | fwereade, ping? | 09:04 |
| dooferlad | dimitern: having sound issues | 09:05 |
| dooferlad | dimitern: hopefully there in a second | 09:05 |
| wallyworld | axw_: ty | 09:05 |
| fwereade | mattyw, pong, I observe I ought to be in my standup | 09:06 |
| mattyw | fwereade, should be quick - we think a flowchart of hooks - and what is called when would be useful, we think something existed but not sure if there is anything up to date | 09:07 |
| mattyw | fwereade, asking if you knew of one | 09:07 |
| fwereade | mattyw, I don't think all the recent hooks have been added | 09:10 |
| fwereade | mattyw, but https://jujucharms.com/docs/devel/authors-charm-hooks should still be accurate for the hooks it references | 09:11 |
| fwereade | mattyw, not a flowchart | 09:11 |
| mattyw | fwereade, ok, I'm drawing one - we can see how useful it is after its been drawn | 09:12 |
| fwereade | mattyw, cool | 09:14 |
| wallyworld | mattyw: or fwereade: a trivial one if you have a moment http://reviews.vapour.ws/r/2503/ | 09:30 |
| mattyw | wallyworld, I think that's the one I just did | 09:32 |
| wallyworld | oh joy | 09:32 |
| mattyw | wallyworld, yep - posted 6 minutes from now | 09:32 |
| wallyworld | you did the same work? | 09:32 |
| wallyworld | oh, a lgtm | 09:33 |
| wallyworld | ty | 09:33 |
| wallyworld | dimitern: have you seen this failure before? https://pastebin.canonical.com/138582/ | 10:02 |
| dimitern | wallyworld, yes | 10:03 |
| dimitern | wallyworld, is it on master? | 10:03 |
| wallyworld | dimitern: we are seeing that in our feature branch | 10:03 |
| wallyworld | we merged master about 12 houra ago | 10:03 |
| dimitern | wallyworld, yeah, dooferlad fixed it on master | 10:03 |
| wallyworld | dimitern: ty, we will remerge master | 10:03 |
| dimitern | wallyworld, it needed a bump of deps.tsv for amz.v3 | 10:03 |
| wallyworld | dimitern: ah, ty | 10:04 |
| dimitern | wallyworld, but that fix was done ~6 days ago (http://reviews.vapour.ws/r/2434/diff/#) - I hope it's not a new regression | 10:04 |
| wallyworld | dimitern: okay, we'll look into it - i thought we had the latest master | 10:05 |
| wallyworld | fwereade: can you join us in the uniter meeting? | 10:06 |
| wallyworld | https://plus.google.com/hangouts/_/canonical.com/discuss-missing | 10:06 |
| TheMue | dimitern: PR is http://reviews.vapour.ws/r/2504/. had to assure first to not merge the whole net-cli branch again, the first naive diff looked awful. :D | 10:45 |
| dimitern | TheMue, ok, will look in a bit | 10:45 |
| TheMue | dimitern: tia, just added 2nd card for the client side and CLI | 10:50 |
| dimitern | TheMue, you've got a review | 12:02 |
| TheMue | dimitern: thx | 12:02 |
| === revagomes_ is now known as revagomes | ||
| * TheMue is afk for a moment, visiting daughter in hospital and bring some sweets. bbiab | 13:10 | |
| perrito666 | omg I hope she is ok | 13:13 |
| wwitzel3 | marcoceppi: how's things? any more core issues last night? | 13:20 |
| marcoceppi | wwitzel3: m4.xlarge is not a "valid" instance-type on aws for 1.24.5 | 13:21 |
| marcoceppi | other than that, demo is setup | 13:21 |
| wwitzel3 | marcoceppi: doesn't appear to be a type in master either, glad to hear the demo is up and going | 13:22 |
| marcoceppi | wwitzel3: I'll file a bu | 13:22 |
| marcoceppi | g | 13:22 |
| wwitzel3 | ty | 13:22 |
| natefinch | ideally, if you use instance-type as a constraint, we don't check it and just try it with amazon :/ | 13:24 |
| wwitzel3 | marcoceppi: of all the people I know with the last name Ceppi, you're my favorite. | 13:25 |
| natefinch | it doesn't matter if *juju* knows what the instance type means | 13:25 |
| natefinch | man, all this indirection and layering is killing me | 13:27 |
| katco | wwitzel3: natefinch: ty both for helping marco et. al. get the demo running | 13:27 |
| natefinch | ericsnow, wwitzel3: where's the concrete type that implements Component? | 13:27 |
| katco | natefinch: https://godoc.org/golang.org/x/tools/cmd/oracle | 13:28 |
| katco | natefinch: know thy programming toolchain | 13:28 |
| perrito666 | no one knows their whole programming toolchain | 13:28 |
| wwitzel3 | natefinch: it is in component/all/workload.go | 13:29 |
| katco | perrito666: you should at least be aware of the pointers into interesting spaces :) | 13:29 |
| perrito666 | katco: I am they have all been nicely integrated into go-vim :p | 13:29 |
| natefinch | katco: yeah, I've tried to use the oracle before... couldn't figure it out. Seems like it kinda requires editor integration, and I didn't have time to get hat settled last time | 13:29 |
| katco | perrito666: haha, same here for emacs | 13:29 |
| katco | natefinch: alan is a heavy emacs user, for sure | 13:29 |
| katco | natefinch: https://github.com/waigani/GoOracle | 13:30 |
| perrito666 | katco: that it in itself a problem though, sometimes I need to go figure how to call these things in the comand line | 13:30 |
| katco | perrito666: clearly you just need to move to an OS that is also an editor ;p | 13:31 |
| perrito666 | lol | 13:31 |
| perrito666 | I concede, you won this round | 13:31 |
| katco | no, perrito666. emacs has won. it always wins. PLEASE HELP I CAN ONLY CONTROL MY EDITOR ONCE EVERY but emacs is great | 13:32 |
| perrito666 | loooolo | 13:32 |
| natefinch | katco: yeah, I saw waigani's oracle integration... couldn't get it to work either | 13:33 |
| perrito666 | natefinch: I think I saw a sublime-go thing around | 13:34 |
| natefinch | perrito666: there's a couple | 13:35 |
| lazyPower | wwitzel3: Mornin o/ Whats the current state of the union on process management? Are we almost ready for me to have another go at the feature branch next week? | 13:37 |
| katco | lazyPower: there's only a few user-facing things that have changed this iteration. what are you interested in? | 13:39 |
| wwitzel3 | lazyPower: yep, when we end this current iteration (Friday) we will have landed all of the major changes | 13:40 |
| wwitzel3 | lazyPower: there are still some features that we need to implement, but the interface for your will stop being a moving target | 13:40 |
| lazyPower | katco: if I can fully test it without embedding the plugin bins in my charms :) | 13:40 |
| lazyPower | end to end from a user perspective. I've got some new iteration charms that leverage charm composition and the reactive framework | 13:40 |
| lazyPower | we're working on docs to land before the charmer summit and I'd love to spotlight the proc mgmt from a charming with containers perspective - as its a solid path forward for new charmers. | 13:41 |
| lazyPower | I'm thinking i'll wind up running a workshop on it for anyone thats interested in getting hands on with the tech while we're at the summit | 13:41 |
| katco | lazyPower: from a charmer perspective, i think wwitzel3 is correct. you should see much more stability :) | 13:42 |
| wwitzel3 | lazyPower: yeah, that's my personal goal too is to have something beta-able for the summit | 13:42 |
| katco | lazyPower: there are still a few commands to be hashed out | 13:42 |
| wwitzel3 | yep ^ | 13:42 |
| lazyPower | Solid. Once that release lands i'll get my grubby mits on it and do the second cycle of early feedback. Everything else was a bit natural given the model we're implementing works pretty well. | 13:42 |
| wwitzel3 | <3 | 13:43 |
| lazyPower | has core taken a look at the reactive framework example cory_fu wrote up using vanilla as an example? | 13:43 |
| wwitzel3 | I have, Cory had me do a proof of the docs before he talked about it on the last office hours. | 13:44 |
| katco | lazyPower: i've talked to ben about it and given it a cursory look. looks awesome | 13:44 |
| lazyPower | katco: wwitzel3: excellent. We'll have a few docker examples that we're going to re-tool to using the proc mgmt stuff once that hits (next week you say?) so having that precursory info really helps. | 13:45 |
| katco | lazyPower: i am always a bit skeptical at our claim that you can charm in any language. all the cool stuff is in py | 13:45 |
| wwitzel3 | I'm pretty sure there is reactive hooks for bash too | 13:45 |
| lazyPower | well, we also claim "integrate with any cm framework" when in reality we're giving you a root shell and then jerry-rig that language into juju w/ bash or python glue code | 13:45 |
| lazyPower | but yeah, reactive works in python and bash | 13:46 |
| lazyPower | and looks strikingly similar | 13:46 |
| wwitzel3 | yeah, not sure what form of hand wavey black magic happened to get them in to bash, but they are there | 13:46 |
| katco | haha | 13:46 |
| katco | that's interesting | 13:46 |
| natefinch | what's this reactive stuff? | 13:46 |
| wwitzel3 | teh future | 13:46 |
| lazyPower | natefinch: its a pattern to surface events and handling events in charms outside of just hook context. | 13:47 |
| lazyPower | natefinch: one way to look at it - is a state machine in a state machine | 13:47 |
| katco | https://www.youtube.com/watch?v=Vm8S331kUPQ | 13:47 |
| natefinch | lazyPower: and its power is only exceeded by its mystery? | 13:47 |
| lazyPower | natefinch: i think thats a byproduct of how new it is :) | 13:47 |
| * perrito666 approves of quoting that movie | 13:48 | |
| lazyPower | let me fish up the docs. that video link is our office hours though and cory gives a pretty good walktrhough | 13:48 |
| natefinch | perrito666: heh, wondered who would get that. Love that movie. | 13:48 |
| lazyPower | and my pop culture reference gland is on vacation today | 13:48 |
| cory_fu | natefinch, lazyPower: http://52.0.202.26:8000/en/authors-charm-composing.html | 13:49 |
| lazyPower | thanks cory_fu | 13:49 |
| perrito666 | lazyPower: it is a really bad movie that manages to drive the entire plot around a very cheap literrary resource | 13:49 |
| wwitzel3 | dangit! I was looking for that exact link | 13:49 |
| wwitzel3 | thanks a lot cory_fu | 13:49 |
| cory_fu | There are actually three connected concepts: composing charms from layers (a pre-release step), using pre-built relation stubs, and using the reactive pattern (reacting to semantic states instead of hook contexts directly) | 13:50 |
| cory_fu | Together, they are basically a framework, so there's an inherent amount of hand-waviness, but I think the end result is easy to follow. Certainly more so than the services framework ever was | 13:51 |
| natefinch | wow... that's um. Something. | 13:53 |
| natefinch | do you have a page written for idiots? | 13:54 |
| * katco always shudders at the site of php | 13:55 | |
| perrito666 | o cmon, php in itself its not that bad (after 10 years) it just has tolerance for bad programmers | 13:56 |
| katco | perrito666: i wrote lots of php in <= v4... it just seems like there are much better alternatives now. and yeah, for whatever reason it has a rep. for bad coding | 13:57 |
| perrito666 | katco: I believe it depends a lot on your business, there is a lot done and allows you to get things working fast without requiring people to savvy I know companies that have big (properly writen) chunks of their user facing bits in php because it allows them to find devs easy | 13:59 |
| perrito666 | in my city I know a good 100 ootb good php devs, 40 python (of which I had to train half) and 2 go (both working for canonical) :p | 14:01 |
| mgz | version bump review please: http://reviews.vapour.ws/r/2505/ | 14:11 |
| mattyw | mgz, lgtm | 14:11 |
| mgz | mattyw: ta! | 14:12 |
| mup | Bug #1489477 opened: m4 instance types not supported on AWS <juju-core:New> <https://launchpad.net/bugs/1489477> | 14:19 |
| mup | Bug #1489484 opened: Juju should support passing an AMI to deploy <juju-core:New> <https://launchpad.net/bugs/1489484> | 14:19 |
| === mgz is now known as mgz_ | ||
| mup | Bug # changed: 1174610, 1265871, 1401368, 1447899, 1449210, 1450737, 1452649, 1455260, 1456265, 1456343, 1457122, 1459093, 1459775, 1464237, 1464392, 1467037, 1467379, | 14:34 |
| mup | 1468153, 1468579, 1471771, 1472632, 1474614, 1475779, 1476895, 1477263, 1479546, 1481500, 1483082, 1483083, 1483086, 1484403, 1484789, 1486074, 1486640, 1486749 | 14:34 |
| frobware | dimitern, do you have some (HO) time to talk about network spaces...? | 14:40 |
| dimitern | frobware, sure | 14:42 |
| dimitern | frobware, standup HO ? | 14:42 |
| frobware | dimitern, yep | 14:42 |
| mup | Bug # opened: 1174610, 1265871, 1401368, 1447899, 1449210, 1450737, 1452649, 1455260, 1456265, 1456343, 1457122, 1459093, 1459775, 1464237, 1464392, 1467037, 1467379, | 14:46 |
| mup | 1468153, 1468579, 1471771, 1472632, 1474614, 1475779, 1476895, 1477263, 1479546, 1481500, 1483082, 1483083, 1483086, 1484403, 1484789, 1486074, 1486640, 1486749 | 14:46 |
| mup | Bug # changed: 1174610, 1265871, 1401368, 1447899, 1449210, 1450737, 1452649, 1455260, 1456265, 1456343, 1457122, 1459093, 1459775, 1464237, 1464392, 1467037, 1467379, | 14:49 |
| mup | 1468153, 1468579, 1471771, 1472632, 1474614, 1475779, 1476895, 1477263, 1479546, 1481500, 1483082, 1483083, 1483086, 1484403, 1484789, 1486074, 1486640, 1486749 | 14:49 |
| mattyw | fwereade, ping? | 15:21 |
| fwereade | mattyw, hey, am indeed back | 15:21 |
| fwereade | mattyw, sorry I couldn't get back online | 15:21 |
| fwereade | mattyw, I feel like we'd covered most of the high ground there though? | 15:21 |
| mattyw | fwereade, no problem at all, I think we're ok | 15:21 |
| mattyw | fwereade, I can't remember which side you were on about states being specific to each resolver (who is on who's side doesn't really matter) | 15:22 |
| mattyw | we decided to make them specific | 15:22 |
| fwereade | mattyw, excellent :) | 15:22 |
| mattyw | fwereade, I'm just carrying on with the action resolver | 15:23 |
| fwereade | mattyw, cool | 15:23 |
| mattyw | fwereade, and the reason I'm pinging | 15:23 |
| fwereade | mattyw, I still haven't sent you any comments, have I :( | 15:23 |
| mattyw | fwereade, to have a sort of nebulous chat about it | 15:23 |
| mattyw | fwereade, I'm fine for the moment but will hassle you later I think | 15:23 |
| fwereade | mattyw, ok, cool | 15:23 |
| natefinch | ericsnow: you around? | 15:37 |
| ericsnow | natefinch: yep | 15:37 |
| natefinch | ericsnow: in your latest comment, you say "we should be passing a full ID (e.g. "my-proc/some-id") to the hook context method" ... but I don't think that's realistic. The code calling the hook tool is only likely to know the workload name, not the ID. So, like, workload-untrack myproc | 15:39 |
| ericsnow | natefinch: I was referring to the method, not the command | 15:40 |
| ericsnow | natefinch: at some point a bare name must be converted to a full ID | 15:40 |
| natefinch | ericsnow: so maybe the right answer is to try to parse the argument in init, and if it has a name + id, then we're good. If it doesn't, and it's just a name, try to look up the id for the name there, and fail. Then run can just pass the id as-is | 15:44 |
| natefinch | (er fail if the lookup fails) | 15:44 |
| ericsnow | natefinch: that sounds like what we've already been doing :) | 15:44 |
| natefinch | ericsnow: maybe I didn't understand the code that was doing it, then. | 15:46 |
| ericsnow | natefinch: well, I could be misunderstanding too :) | 15:46 |
| fwereade | https://github.com/juju/juju/wiki/Managing-complexity -- comments and edits accepted gratefully | 15:53 |
| fwereade | (some people have already commented and I haven't actually included all those, but I wanted to post it and not get further distracted) | 15:55 |
| ericsnow | fwereade: thanks! | 15:55 |
| perrito666 | off course, I try to use the recommended editor by katco and among the possible key shortcuts there is one that, I kid you not, is described as: toggle the battery status | 16:44 |
| katco | perrito666: core team call | 18:02 |
| perrito666 | well connection sucks, I tried to join but saw people move a bit then lost all | 18:24 |
| === akhavr1 is now known as akhavr | ||
| wwitzel3 | oh yay, my internet is back | 19:33 |
| katco | wwitzel3: welcome back. juju is now rewritten in emacs lisp. | 19:34 |
| Makyo | C-m C-x juju-mode | 19:34 |
| wwitzel3 | rewritten/assimilated | 19:35 |
| wwitzel3 | emacs will be skynet, when it decides the time is right | 19:36 |
| katco | boy the emacs jokes are running heavy today. i had not intended that. | 19:36 |
| perrito666 | katco: lol | 19:37 |
| * katco is also wondering if Makyo has a notification set up for emacs mentions | 19:37 | |
| Makyo | Alas, I'm a vim-er and an Atom-er, but I'm not about to pass up a good emacs joke if it comes up :) | 19:38 |
| wwitzel3 | "emacs at least it isn't acme" | 19:43 |
| perrito666 | to each its editor, I know people that work in either mcedit or gedit | 19:44 |
| katco | wwitzel3: haha | 19:45 |
| wwitzel3 | without the banter about ones choice in editor, I'm lost .. don't ruin this for me perrito666 | 19:46 |
| katco | wwitzel3: all i'm saying is vimscript is awesome! | 19:46 |
| perrito666 | wwitzel3: life is about choices, you can bash people about their choice on about anything | 19:46 |
| wwitzel3 | perrito666: umm, but it is only fun to do it about choices that don't have any real impact or meaning | 19:46 |
| ericsnow | cmars: does the uniter currently run any "subordinate" workers | 19:51 |
| cmars | ericsnow, checking.. | 19:51 |
| ericsnow | cmars: as far as I can tell, it doesn't | 19:51 |
| cmars | ericsnow, doesn't look like it | 19:52 |
| ericsnow | cmars: I've realized that the workers we're running for workloads should be running under the uniter | 19:52 |
| ericsnow | cmars: not directly under the unit agent | 19:52 |
| ericsnow | cmars: maybe | 19:52 |
| cmars | ericsnow, what do the workload workers need of the uniter? | 19:53 |
| ericsnow | cmars: per the doc comment, "Uniter implements the capabilities of the unit agent." | 19:54 |
| cmars | ericsnow, doc comment might be wrong now :) | 19:54 |
| ericsnow | cmars: ha | 19:54 |
| ericsnow | cmars: from what I can tell, the uniter is the worker that handles all the work of a unit | 19:55 |
| ericsnow | cmars: workload [processes] are a part of that | 19:56 |
| cmars | ericsnow, how? | 19:56 |
| ericsnow | cmars: they are a part of the workload dictated by a charm | 19:56 |
| cmars | ericsnow, right.. but it sounds like there's a worker associated with each process.. what does that worker need to do exactly? | 19:57 |
| ericsnow | cmars: API calls and possibly persist some data locally | 19:58 |
| ericsnow | cmars: plus, of course, interact with the workloads (e.g. docker) | 19:58 |
| cmars | ericsnow, i'd see if they could be managed independently of the uniter worker if at all possible. uniter already does too much imo | 19:59 |
| cmars | ericsnow, and then the questions to ask & answer are: what do these process workers need from the uniter? and then we can possibly encapsulate that into a resource that is managed by uniter and consumed by process workers | 20:00 |
| ericsnow | cmars: per the uniter's manifold doc comment: "...We expect to break it up further in the coming weeks" | 20:00 |
| cmars | ericsnow, see http://reviews.vapour.ws/r/2511/ for an example of this kind of interaction. in this PR, there's a resource that coordinates between uniter & consumers, so that we don't operate on a workload while it's upgrading, or not started | 20:02 |
| ericsnow | cmars: under a consolidated (unit+machine) agent there will be multiple uniters per agent, right? | 20:02 |
| cmars | ericsnow, i imagine you could do something similar to safely operate on a workload without getting entangled in the reactor loop of the uniter itself | 20:03 |
| ericsnow | cmars: good point | 20:03 |
| ericsnow | cmars: I definitely don't want to get involved in that :) | 20:03 |
| * ericsnow shudders | 20:04 | |
| cmars | ericsnow, nice thing about this model is that it is so much more testable. mock out the resources and test each side of the interactions independently.. then move the end-to-end tests (conn suite) out to integration tests | 20:04 |
| ericsnow | cmars: yay | 20:04 |
| cmars | ericsnow, i think actions should come out as well.. though i think we'll need to get them working as they were before making that leap | 20:04 |
| ericsnow | cmars: actions are tied into the uniter? | 20:05 |
| cmars | ericsnow, currently, yes. they have their own operations & remote/local state resolver. | 20:06 |
| sinzui | wallyworld: I will branch 1.25 from mgz's commit. No backports needed | 21:44 |
| wallyworld | sinzui: that is most excellent, thank you | 21:44 |
| sinzui | wallyworld: I will also prepare a branch to rename master 1.26-alaph1 | 21:44 |
| wallyworld | ok | 21:45 |
| cmars | hey wallyworld, i'm looking at TestUniterUpgradeConflicts, seems to be failing for me in maltese-falcon branch | 21:46 |
| wallyworld | cmars: i thought that one had been fixed yesterday | 21:46 |
| cmars | what I can't figure out is, how the unit resolved state is supposed to go from ResolvedNoHooks to ResolvedNone | 21:46 |
| wallyworld | we can fix that today if you want | 21:46 |
| wallyworld | i need to see why it is not fixed when i hought it was | 21:47 |
| wallyworld | unit resolved state is changed by the user in practice | 21:47 |
| wallyworld | and then is propogated to the remote snapshot | 21:47 |
| cmars | wallyworld, here's a paste of what i'm seeing: http://paste.ubuntu.com/12209761/ | 21:49 |
| cmars | wallyworld, two runs of the test, one with an induced panic during waitUnitAgent | 21:50 |
| cmars | wallyworld, but it must be that the unit watcher isn't getting the update | 21:50 |
| wallyworld | cmars: i just tried it locally and yeah, it now fails for me too, but was passing yesterday i'm sure. i can get it fixed today if you want | 21:51 |
| cmars | wallyworld, thanks, that'd be great | 21:51 |
| wallyworld | cmars: sure, i can't tell you right away why or when it broke | 21:51 |
| wallyworld | cmars: with the skipped metrics related tests still in worker/uniter, what's the ETA on moving those? | 21:52 |
| sinzui | wallyworld: can you review http://reviews.vapour.ws/r/2512/ | 21:53 |
| wallyworld | sure | 21:53 |
| wallyworld | sinzui: lgtm, ty | 21:53 |
| wallyworld | sinzui: do you still use thunderbird? | 21:53 |
| sinzui | No, it is dead to me | 21:54 |
| wallyworld | it just broke for me when i updated :-( | 21:54 |
| wallyworld | sigh | 21:54 |
| sinzui | wallyworld: I just use the canonical gmail. Yes I had an account issue. I have been with Canonical long enough that my identity didn't work with the standard account integration | 21:55 |
| cmars | wallyworld, there's possibly a little bit left to move out of the context tests, checking | 21:55 |
| sinzui | wallyworld: 1.25 branch exists and is open for business. | 21:55 |
| wallyworld | sinzui: well after the update, it won't retrieve my email and asks for a password | 21:56 |
| wallyworld | cmars: yesterday i relabelled the skipped metrics tests to "Skip("maltese-falcon metrics") there were about 7 maybe | 21:56 |
| sinzui | wallyworld: oh, that is what I had issues with. authentication. I coudl use gmail interface though | 21:56 |
| wallyworld | sinzui: so how did you solve it? | 21:57 |
| sinzui | I use gmail | 21:57 |
| wallyworld | damn, i might ask in #is | 21:57 |
| perrito666 | wallyworld: you might need to remove-add your account | 22:00 |
| perrito666 | wallyworld: it requires some love to work | 22:00 |
| cmars | wallyworld, yep, i think we have comparable coverage for all of those & they can be removed. will comment the new tests in the review | 22:02 |
| wallyworld | cmars: awesome, we are really close now i think. actions is the biggest one to finish | 22:02 |
| cmars | wallyworld, that's great to hear. mattyw will be working on actions tmw, can I send him your way in case he gets stuck? | 22:04 |
| wallyworld | cmars: sure, although william might be better as i've not had much to do with actions. but please to try and help | 22:07 |
| cmars | wallyworld, ack, thanks | 22:07 |
| jw4 | cmars, wallyworld fwiw, I still watch this channel and *might* be able to help if there are actions / uniter type questions | 22:08 |
| jw4 | but william is ofc the best option | 22:08 |
| wallyworld | jw4: hey! we are currently rewriting the uniter, so are in the middle of changing how the execution queue works | 22:08 |
| jw4 | yeah I've been noticing that chatter | 22:09 |
| jw4 | I doubt I can contribute much to that, but ... | 22:09 |
| jw4 | :) | 22:09 |
| wallyworld | jw4: np, it's been fun. uniter is now (to me at least) much less complex now | 22:09 |
| jw4 | sweet | 22:09 |
| jw4 | It's long overdue I think | 22:10 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!