[01:23] <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:24] <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:25] <wallyworld> i think polling update status should be a uniter responsbility
[01:26] <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:27] <wallyworld> but seems kinda othogonal to goal state to me
[01:28] <axw_> wallyworld: I just don't want there to be a lot of concurrency spread around again
[01:29] <wallyworld> yeah, i was mulling over the same thought
[01:30] <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:31] <rick_h_> wallyworld: sure thing https://plus.google.com/hangouts/_/canonical.com/daily-standup?authuser=1 adjust authuser
[01:32] <mup> Bug #1489215 opened: Output from metadata generate-image looks bad <juju-core:New> <https://launchpad.net/bugs/1489215>
[01:37] <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:38] <sinzui> davechen1y: I think someone renamed ir disbaled the project!
[01:38] <mwhudson> davechen1y: gomassapi or gomaasapi?
[01:39] <davechen1y> good point
[01:40] <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:56] <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:57] <wallyworld> davechen1y: oh, just read backscroll. ooops
[02:00] <davechen1y> wallyworld: what do to
[02:00] <davechen1y> ?
[02:01] <davechen1y> something is screwed with that repo in a way we cannot detect with the build bot
[02:02] <wallyworld> not sure, i'll ask in the lauchpad channel if i can reporoduce
[02:08] <menn0> waigani: review please: http://reviews.vapour.ws/r/2496/
[02:22] <wallyworld> davechen1y: so it's only a go 1.5 thing? i'm still on 1.4 and it's fine for me
[02:23] <wallyworld> so what would there be to fix in launchpad
[02:26] <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:32] <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:35] <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:38] <waigani> menn0: done. I replied to your review also.
[02:58] <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:59] <wallyworld> so Go needs to be fixed, not launchpad
[03:38] <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:39] <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:40] <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:42] <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
[04:16] <davechen1y> https://github.com/juju/juju/pull/3119
[04:16] <davechen1y> anyone ?
[05:23] <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:24] <dimitern> wallyworld, oh :) no worries at all
[05:24] <dimitern> wallyworld, the backport didn't happen, but it should today I hope
[05:25] <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:26] <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:27] <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:28] <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:29] <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:30] <dimitern> but generate-tools will need already built arm binaries, right? could they be simply in $PATH?
[05:31] <wallyworld> generate tools will build the tools from source if there's no binary in the path
[05:31] <wallyworld> i think
[05:32] <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:42] <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:43] <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:44] <wallyworld> yup
[05:50] <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:52] <axw_> wallyworld: sure
[06:43] <wallyworld> axw_: thanks for landing. what bit you working on now?
[06:44] <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:53] <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:54] <ashipika> axw_: ack!
[06:55] <axw_> wallyworld: UniterSuite.TestUniterUpgradeGitConflicts works with my branch, with a trivial change to expect leader-settings-changed
[06:56] <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:57] <wallyworld> sounds good, i'm hoping they may work of the changes to make them work are trivial
[06:58] <axw_> yeah the other one is fixed too
[06:58] <axw_> wallyworld: I'll just update my current PR
[06:58] <wallyworld> yup
[07:17] <ashipika> axw, wallyworld: can you assign/move corresponding cards on the uniter sprint board, as well?
[07:17] <wallyworld> ashipika: we are :-)
[07:18] <ashipika> wallyworld: excellent! :)
[07:18] <wallyworld> getting there slowly
[07:18] <wallyworld> and sometimes quickly
[07:21] <wallyworld> axw_: i had a couple of questions on the review
[07:37] <axw_> wallyworld: thanks for the review. please see my replies, let me know if they make sense
[07:37] <wallyworld> looking
[07:41] <wallyworld> axw_: let's get it landed
[07:41] <axw_> wallyworld: ta
[07:42] <axw_> wallyworld: any idea why we run actions in ModeTerminating?
[07:43] <wallyworld> nope. i didn't realise we did. i'm curious as to why
[07:45] <dimitern> dooferlad, morning
[07:45] <dooferlad> hi
[07:46] <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:48] <dooferlad> dimitern: great. Just dealing with email then will take a look. I spotted that you had done something in that area.
[07:49] <dimitern> dooferlad, ok
[08:42] <voidspace> dimitern: I don't know if you saw my message yesterday
[08:42] <voidspace> dimitern: that forward port is already on trunk
[08:43] <voidspace> dimitern: is there an issue for me to close related to it?
[08:45] <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:46] <voidspace> dimitern: hah!
[08:46] <voidspace> dimitern: ok, that's easy to do :-)
[08:46] <dimitern> voidspace, yep ;)
[08:47] <voidspace> dimitern: and for the IP address bug I'm targetting 1.24 and will forward port when it's done
[08:48] <dimitern> voidspace, sounds good
[08:52] <voidspace> dimitern: PR created, just running tests
[08:53] <dimitern> voidspace, awesome!
[09:01] <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:02] <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:03] <dimitern> voidspace, have you tried make check?
[09:04] <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:05] <dooferlad> dimitern: having sound issues
[09:05] <dooferlad> dimitern: hopefully there in a second
[09:05] <wallyworld> axw_: ty
[09:06] <fwereade> mattyw, pong, I observe I ought to be in my standup
[09:07] <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:10] <fwereade> mattyw, I don't think all the recent hooks have been added
[09:11] <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:12] <mattyw> fwereade, ok, I'm drawing one - we can see how useful it is after its been drawn
[09:14] <fwereade> mattyw, cool
[09:30] <wallyworld> mattyw: or fwereade: a trivial one if you have a moment http://reviews.vapour.ws/r/2503/
[09:32] <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:33] <wallyworld> oh, a lgtm
[09:33] <wallyworld> ty
[10:02] <wallyworld> dimitern: have you seen this failure before? https://pastebin.canonical.com/138582/
[10:03] <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:04] <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:05] <wallyworld> dimitern: okay, we'll look into it - i thought we had the latest master
[10:06] <wallyworld> fwereade: can you join us in the uniter meeting?
[10:06] <wallyworld> https://plus.google.com/hangouts/_/canonical.com/discuss-missing
[10:45] <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:50] <TheMue> dimitern: tia, just added 2nd card for the client side and CLI
[12:02] <dimitern> TheMue, you've got a review
[12:02] <TheMue> dimitern: thx
[13:10]  * TheMue is afk for a moment, visiting daughter in hospital and bring some sweets. bbiab
[13:13] <perrito666> omg I hope she is ok
[13:20] <wwitzel3> marcoceppi: how's things? any more core issues last night?
[13:21] <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:22] <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:24] <natefinch> ideally, if you use instance-type as a constraint, we don't check it and just try it with amazon :/
[13:25] <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:27] <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:28] <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:29] <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:30] <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:31] <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:32] <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:33] <natefinch> katco: yeah, I saw waigani's oracle integration... couldn't get it to work either
[13:34] <perrito666> natefinch: I think I saw a sublime-go thing around
[13:35] <natefinch> perrito666: there's a couple
[13:37] <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:39] <katco> lazyPower: there's only a few user-facing things that have changed this iteration. what are you interested in?
[13:40] <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:41] <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:42] <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:43] <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:44] <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:45] <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:46] <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:47] <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:48]  * 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:49] <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:50] <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:51] <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:53] <natefinch> wow... that's um.  Something.
[13:54] <natefinch> do you have a page written for idiots?
[13:55]  * katco always shudders at the site of php
[13:56] <perrito666> o cmon, php in itself its not that bad (after 10 years) it just has tolerance for bad programmers
[13:57] <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:59] <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
[14:01] <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:11] <mgz> version bump review please: http://reviews.vapour.ws/r/2505/
[14:11] <mattyw> mgz, lgtm
[14:12] <mgz> mattyw: ta!
[14:19] <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:34] <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:40] <frobware> dimitern, do you have some (HO) time to talk about network spaces...?
[14:42] <dimitern> frobware, sure
[14:42] <dimitern> frobware, standup HO ?
[14:42] <frobware> dimitern, yep
[14:46] <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:49] <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
[15:21] <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:22] <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:23] <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:37] <natefinch> ericsnow: you around?
[15:37] <ericsnow> natefinch: yep
[15:39] <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:40] <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:44] <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:46] <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:53] <fwereade> https://github.com/juju/juju/wiki/Managing-complexity -- comments and edits accepted gratefully
[15:55] <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!
[16:44] <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
[18:02] <katco> perrito666: core team call
[18:24] <perrito666> well connection sucks, I tried to join but saw people move a bit then lost all
[19:33] <wwitzel3> oh yay, my internet is back
[19:34] <katco> wwitzel3: welcome back. juju is now rewritten in emacs lisp.
[19:34] <Makyo> C-m C-x juju-mode
[19:35] <wwitzel3> rewritten/assimilated
[19:36] <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:37] <perrito666> katco: lol
[19:37]  * katco is also wondering if Makyo has a notification set up for emacs mentions
[19:38] <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:43] <wwitzel3> "emacs at least it isn't acme"
[19:44] <perrito666> to each its editor, I know people that work in either mcedit or gedit
[19:45] <katco> wwitzel3: haha
[19:46] <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:51] <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:52] <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:53] <cmars> ericsnow, what do the workload workers need of the uniter?
[19:54] <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:55] <ericsnow> cmars: from what I can tell, the uniter is the worker that handles all the work of a unit
[19:56] <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:57] <cmars> ericsnow, right.. but it sounds like there's a worker associated with each process.. what does that worker need to do exactly?
[19:58] <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:59] <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
[20:00] <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:02] <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:03] <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:04]  * 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:05] <ericsnow> cmars: actions are tied into the uniter?
[20:06] <cmars> ericsnow, currently, yes. they have their own operations & remote/local state resolver.
[21:44] <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:45] <wallyworld> ok
[21:46] <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:47] <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:49] <cmars> wallyworld, here's a paste of what i'm seeing: http://paste.ubuntu.com/12209761/
[21:50] <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:51] <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:52] <wallyworld> cmars: with the skipped metrics related tests still in worker/uniter, what's the ETA on moving those?
[21:53] <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:54] <sinzui> No, it is dead to me
[21:54] <wallyworld> it just broke for me when i updated :-(
[21:54] <wallyworld> sigh
[21:55] <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:56] <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:57] <wallyworld> sinzui: so how did you solve it?
[21:57] <sinzui> I use gmail
[21:57] <wallyworld> damn, i might ask in #is
[22:00] <perrito666> wallyworld: you might need to remove-add your account
[22:00] <perrito666> wallyworld: it requires some love to work
[22:02] <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:04] <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:07] <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:08] <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:09] <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:10] <jw4> It's long overdue I think