[01:23] 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] wallyworld: and that updating status should move into there [01:24] 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] name change sounds good. not sure about adding in update status though [01:25] i think polling update status should be a uniter responsbility [01:26] 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] but seems kinda othogonal to goal state to me [01:28] wallyworld: I just don't want there to be a lot of concurrency spread around again [01:29] yeah, i was mulling over the same thought [01:30] wallyworld: and I'd like to keep as much business logic out of the loop as possible [01:30] wallyworld: got a sec to chat? can you ping when you do? [01:30] rick_h_: sure, now? [01:31] wallyworld: sure thing https://plus.google.com/hangouts/_/canonical.com/daily-standup?authuser=1 adjust authuser [01:32] Bug #1489215 opened: Output from metadata generate-image looks bad [01:37] sinzui: wallyworld anyone https://bugs.launchpad.net/juju-core/+bug/1489218 [01:37] Bug #1489218: go get cannot fetch launchpad.net/gomassapi [01:37] can you reproduce this issue ? [01:37] mwhudson: https://bugs.launchpad.net/juju-core/+bug/1489218 [01:37] is this related to the launchpad change that happened recently ? [01:38] davechen1y: I think someone renamed ir disbaled the project! [01:38] davechen1y: gomassapi or gomaasapi? [01:39] good point [01:40] i think i fat fingered it trying to investigate https://bugs.launchpad.net/juju-core/+bug/1489217 [01:40] Bug #1489217: godeps -u dependencies.tsv from scratch fails with Go 1.5 [01:40] :) [01:40] oh good [01:40] message is plenty confusing though [01:40] * mwhudson disappears [01:56] Bug #1489217 opened: godeps -u dependencies.tsv from scratch fails with Go 1.5 [01:56] davechen1y: looking, was otp [01:57] davechen1y: oh, just read backscroll. ooops [02:00] wallyworld: what do to [02:00] ? [02:01] something is screwed with that repo in a way we cannot detect with the build bot [02:02] not sure, i'll ask in the lauchpad channel if i can reporoduce [02:08] waigani: review please: http://reviews.vapour.ws/r/2496/ [02:22] davechen1y: so it's only a go 1.5 thing? i'm still on 1.4 and it's fine for me [02:23] so what would there be to fix in launchpad [02:26] Bug #1489131 changed: BootstrapSuite.TestRunTests fails on non-amd64 archs

[02:32] Bug #1489131 opened: BootstrapSuite.TestRunTests fails on non-amd64 archs

[02:35] Bug #1489131 changed: BootstrapSuite.TestRunTests fails on non-amd64 archs

[02:38] menn0: done. I replied to your review also. [02:58] wallyworld: i believe mwhudson made (or asked) for a change to happen in the Go tool that made launchpad less special [02:58] so depdency resolution for lp repos has changed [02:58] i don't know the details [02:58] ah ok [02:58] but the change was made in Go [02:59] so Go needs to be fixed, not launchpad [03:38] 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] wallyworld: seems that previously we would run another config-changed after start, even if we resolved without retry a previous config-changed [03:39] wallyworld: seems wrong to me. what do you think? [03:40] 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] wallyworld: sounds good, thanks [03:42] wallyworld: also fixing a bug in storage resolver, it's running storage-attached for unattached (but "alive") storage attachments [04:16] https://github.com/juju/juju/pull/3119 [04:16] anyone ? [05:23] wallyworld, hey, still about? [05:23] dimitern: hey. thanks for taking up those bugs, sorry for not saying good morning in the email :-) [05:24] wallyworld, oh :) no worries at all [05:24] wallyworld, the backport didn't happen, but it should today I hope [05:25] no hurry with that - we are concentrating on 1.25 right at the moment [05:25] wallyworld, the other armhf issue - I have access to the lab and their maas, but need to investigate today [05:25] was meant to go out today but there was a regression [05:25] wallyworld, oh? which one this time.. [05:25] a test failure due to arch != amd64 [05:26] wallyworld, and btw you're perhaps the perfect person to ask - how to set up armhf tools/images/metadata/etc. locally? [05:26] use juju metadata generate-images [05:27] that will put metadata in a directory [05:27] you specify the directory with -d [05:27] 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] or else i think it uses ~/.juju [05:27] wallyworld, ah, ok will try this [05:28] wallyworld, so far istm to debug the issue I need to start another armhf node to build juju from source on it :) [05:28] you can't geneate arm tools though unless you're on arm of course [05:28] assuming use used -d mydir [05:28] then you bootstrap with [05:28] yeah [05:29] juju bootstrap --metadata-source mydir [05:29] the tools command is juju metadata generate-tools [05:29] it was asking if my agent-tools-url is set correctly btw [05:29] it will do that if it can't find tools [05:29] right [05:30] but generate-tools will need already built arm binaries, right? could they be simply in $PATH? [05:31] generate tools will build the tools from source if there's no binary in the path [05:31] i think [05:32] wallyworld: would you please review the final commit on https://github.com/juju/juju/pull/3105/commits? [05:32] sure [05:32] 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] wallyworld: various bugs cropped up when I made my sweeping change for upgrades [05:32] that's what tests are for :-) [05:42] 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] 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] yup [05:50] axw_: school pickup time, but here's a trivial http://reviews.vapour.ws/r/2499/ [05:50] axw_: could you ltgm and merge for me while i'm out, ty [05:52] wallyworld: sure [06:43] axw_: thanks for landing. what bit you working on now? [06:44] wallyworld: TestUniterUpgradeConflicts [06:44] just as the board says, doh [06:44] wallyworld: just about ready to land [06:44] I mean propose [06:44] i wonder if that will fix any of the other upgrade ones, maybenot [06:53] 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] ashipika: I didn't uncomment the unit test you're working on though, cos it still fails for some other reason [06:54] axw_: ack! [06:55] wallyworld: UniterSuite.TestUniterUpgradeGitConflicts works with my branch, with a trivial change to expect leader-settings-changed [06:56] axw_: great :-) assign yourself to the card [06:56] luckily i had just phone my niece for her birthday so hadn't started yet [06:56] wallyworld: I'll check the other upgrade tests before sending a change [06:56] cool [06:57] sounds good, i'm hoping they may work of the changes to make them work are trivial [06:58] yeah the other one is fixed too [06:58] wallyworld: I'll just update my current PR [06:58] yup [07:17] axw, wallyworld: can you assign/move corresponding cards on the uniter sprint board, as well? [07:17] ashipika: we are :-) [07:18] wallyworld: excellent! :) [07:18] getting there slowly [07:18] and sometimes quickly [07:21] axw_: i had a couple of questions on the review [07:37] wallyworld: thanks for the review. please see my replies, let me know if they make sense [07:37] looking [07:41] axw_: let's get it landed [07:41] wallyworld: ta [07:42] wallyworld: any idea why we run actions in ModeTerminating? [07:43] nope. i didn't realise we did. i'm curious as to why [07:45] dooferlad, morning [07:45] hi [07:46] 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] dooferlad, so, slight change of plans, hopefully simplifying what's left [07:48] dimitern: great. Just dealing with email then will take a look. I spotted that you had done something in that area. [07:49] dooferlad, ok [08:42] dimitern: I don't know if you saw my message yesterday [08:42] dimitern: that forward port is already on trunk [08:43] dimitern: is there an issue for me to close related to it? [08:45] voidspace, yeah, I've updated the card [08:45] voidspace, it's a backport to 1.24, not forward port to master [08:45] voidspace, sorry, my bad :/ [08:46] dimitern: hah! [08:46] dimitern: ok, that's easy to do :-) [08:46] voidspace, yep ;) [08:47] dimitern: and for the IP address bug I'm targetting 1.24 and will forward port when it's done [08:48] voidspace, sounds good [08:52] dimitern: PR created, just running tests [08:53] voidspace, awesome! [09:01] Bug #1489346 opened: /var/lib/juju/db taking lots of disk space [09:01] 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] dimitern: thanks for the LGTM [09:02] dimitern: I still have the problem that running all cmd/juju tests times out on my main box [09:02] dimitern: going to run just the upgrade tests [09:03] voidspace, have you tried make check? [09:04] voidspace, dooferlad, standup [09:04] dimitern: ah, that does a full test run [09:04] dimitern: just kicked it off [09:04] omw [09:04] fwereade, ping? [09:05] dimitern: having sound issues [09:05] dimitern: hopefully there in a second [09:05] axw_: ty [09:06] mattyw, pong, I observe I ought to be in my standup [09:07] 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] fwereade, asking if you knew of one [09:10] mattyw, I don't think all the recent hooks have been added [09:11] mattyw, but https://jujucharms.com/docs/devel/authors-charm-hooks should still be accurate for the hooks it references [09:11] mattyw, not a flowchart [09:12] fwereade, ok, I'm drawing one - we can see how useful it is after its been drawn [09:14] mattyw, cool [09:30] mattyw: or fwereade: a trivial one if you have a moment http://reviews.vapour.ws/r/2503/ [09:32] wallyworld, I think that's the one I just did [09:32] oh joy [09:32] wallyworld, yep - posted 6 minutes from now [09:32] you did the same work? [09:33] oh, a lgtm [09:33] ty [10:02] dimitern: have you seen this failure before? https://pastebin.canonical.com/138582/ [10:03] wallyworld, yes [10:03] wallyworld, is it on master? [10:03] dimitern: we are seeing that in our feature branch [10:03] we merged master about 12 houra ago [10:03] wallyworld, yeah, dooferlad fixed it on master [10:03] dimitern: ty, we will remerge master [10:03] wallyworld, it needed a bump of deps.tsv for amz.v3 [10:04] dimitern: ah, ty [10:04] 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] dimitern: okay, we'll look into it - i thought we had the latest master [10:06] fwereade: can you join us in the uniter meeting? [10:06] https://plus.google.com/hangouts/_/canonical.com/discuss-missing [10:45] 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] TheMue, ok, will look in a bit [10:50] dimitern: tia, just added 2nd card for the client side and CLI [12:02] TheMue, you've got a review [12:02] dimitern: thx === revagomes_ is now known as revagomes [13:10] * TheMue is afk for a moment, visiting daughter in hospital and bring some sweets. bbiab [13:13] omg I hope she is ok [13:20] marcoceppi: how's things? any more core issues last night? [13:21] wwitzel3: m4.xlarge is not a "valid" instance-type on aws for 1.24.5 [13:21] other than that, demo is setup [13:22] marcoceppi: doesn't appear to be a type in master either, glad to hear the demo is up and going [13:22] wwitzel3: I'll file a bu [13:22] g [13:22] ty [13:24] ideally, if you use instance-type as a constraint, we don't check it and just try it with amazon :/ [13:25] marcoceppi: of all the people I know with the last name Ceppi, you're my favorite. [13:25] it doesn't matter if *juju* knows what the instance type means [13:27] man, all this indirection and layering is killing me [13:27] wwitzel3: natefinch: ty both for helping marco et. al. get the demo running [13:27] ericsnow, wwitzel3: where's the concrete type that implements Component? [13:28] natefinch: https://godoc.org/golang.org/x/tools/cmd/oracle [13:28] natefinch: know thy programming toolchain [13:28] no one knows their whole programming toolchain [13:29] natefinch: it is in component/all/workload.go [13:29] perrito666: you should at least be aware of the pointers into interesting spaces :) [13:29] katco: I am they have all been nicely integrated into go-vim :p [13:29] 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] perrito666: haha, same here for emacs [13:29] natefinch: alan is a heavy emacs user, for sure [13:30] natefinch: https://github.com/waigani/GoOracle [13:30] 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] perrito666: clearly you just need to move to an OS that is also an editor ;p [13:31] lol [13:31] I concede, you won this round [13:32] no, perrito666. emacs has won. it always wins. PLEASE HELP I CAN ONLY CONTROL MY EDITOR ONCE EVERY but emacs is great [13:32] loooolo [13:33] katco: yeah, I saw waigani's oracle integration... couldn't get it to work either [13:34] natefinch: I think I saw a sublime-go thing around [13:35] perrito666: there's a couple [13:37] 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] lazyPower: there's only a few user-facing things that have changed this iteration. what are you interested in? [13:40] lazyPower: yep, when we end this current iteration (Friday) we will have landed all of the major changes [13:40] lazyPower: there are still some features that we need to implement, but the interface for your will stop being a moving target [13:40] katco: if I can fully test it without embedding the plugin bins in my charms :) [13:40] end to end from a user perspective. I've got some new iteration charms that leverage charm composition and the reactive framework [13:41] 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] 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] lazyPower: from a charmer perspective, i think wwitzel3 is correct. you should see much more stability :) [13:42] lazyPower: yeah, that's my personal goal too is to have something beta-able for the summit [13:42] lazyPower: there are still a few commands to be hashed out [13:42] yep ^ [13:42] 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] <3 [13:43] has core taken a look at the reactive framework example cory_fu wrote up using vanilla as an example? [13:44] I have, Cory had me do a proof of the docs before he talked about it on the last office hours. [13:44] lazyPower: i've talked to ben about it and given it a cursory look. looks awesome [13:45] 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] 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] I'm pretty sure there is reactive hooks for bash too [13:45] 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] but yeah, reactive works in python and bash [13:46] and looks strikingly similar [13:46] yeah, not sure what form of hand wavey black magic happened to get them in to bash, but they are there [13:46] haha [13:46] that's interesting [13:46] what's this reactive stuff? [13:46] teh future [13:47] natefinch: its a pattern to surface events and handling events in charms outside of just hook context. [13:47] natefinch: one way to look at it - is a state machine in a state machine [13:47] https://www.youtube.com/watch?v=Vm8S331kUPQ [13:47] lazyPower: and its power is only exceeded by its mystery? [13:47] natefinch: i think thats a byproduct of how new it is :) [13:48] * perrito666 approves of quoting that movie [13:48] let me fish up the docs. that video link is our office hours though and cory gives a pretty good walktrhough [13:48] perrito666: heh, wondered who would get that. Love that movie. [13:48] and my pop culture reference gland is on vacation today [13:49] natefinch, lazyPower: http://52.0.202.26:8000/en/authors-charm-composing.html [13:49] thanks cory_fu [13:49] lazyPower: it is a really bad movie that manages to drive the entire plot around a very cheap literrary resource [13:49] dangit! I was looking for that exact link [13:49] thanks a lot cory_fu [13:50] 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] 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] wow... that's um. Something. [13:54] do you have a page written for idiots? [13:55] * katco always shudders at the site of php [13:56] o cmon, php in itself its not that bad (after 10 years) it just has tolerance for bad programmers [13:57] 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] 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] 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] version bump review please: http://reviews.vapour.ws/r/2505/ [14:11] mgz, lgtm [14:12] mattyw: ta! [14:19] Bug #1489477 opened: m4 instance types not supported on AWS [14:19] Bug #1489484 opened: Juju should support passing an AMI to deploy === mgz is now known as mgz_ [14:34] Bug # changed: 1174610, 1265871, 1401368, 1447899, 1449210, 1450737, 1452649, 1455260, 1456265, 1456343, 1457122, 1459093, 1459775, 1464237, 1464392, 1467037, 1467379, [14:34] 1468153, 1468579, 1471771, 1472632, 1474614, 1475779, 1476895, 1477263, 1479546, 1481500, 1483082, 1483083, 1483086, 1484403, 1484789, 1486074, 1486640, 1486749 [14:40] dimitern, do you have some (HO) time to talk about network spaces...? [14:42] frobware, sure [14:42] frobware, standup HO ? [14:42] dimitern, yep [14:46] Bug # opened: 1174610, 1265871, 1401368, 1447899, 1449210, 1450737, 1452649, 1455260, 1456265, 1456343, 1457122, 1459093, 1459775, 1464237, 1464392, 1467037, 1467379, [14:46] 1468153, 1468579, 1471771, 1472632, 1474614, 1475779, 1476895, 1477263, 1479546, 1481500, 1483082, 1483083, 1483086, 1484403, 1484789, 1486074, 1486640, 1486749 [14:49] Bug # changed: 1174610, 1265871, 1401368, 1447899, 1449210, 1450737, 1452649, 1455260, 1456265, 1456343, 1457122, 1459093, 1459775, 1464237, 1464392, 1467037, 1467379, [14:49] 1468153, 1468579, 1471771, 1472632, 1474614, 1475779, 1476895, 1477263, 1479546, 1481500, 1483082, 1483083, 1483086, 1484403, 1484789, 1486074, 1486640, 1486749 [15:21] fwereade, ping? [15:21] mattyw, hey, am indeed back [15:21] mattyw, sorry I couldn't get back online [15:21] mattyw, I feel like we'd covered most of the high ground there though? [15:21] fwereade, no problem at all, I think we're ok [15:22] 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] we decided to make them specific [15:22] mattyw, excellent :) [15:23] fwereade, I'm just carrying on with the action resolver [15:23] mattyw, cool [15:23] fwereade, and the reason I'm pinging [15:23] mattyw, I still haven't sent you any comments, have I :( [15:23] fwereade, to have a sort of nebulous chat about it [15:23] fwereade, I'm fine for the moment but will hassle you later I think [15:23] mattyw, ok, cool [15:37] ericsnow: you around? [15:37] natefinch: yep [15:39] 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] natefinch: I was referring to the method, not the command [15:40] natefinch: at some point a bare name must be converted to a full ID [15:44] 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] (er fail if the lookup fails) [15:44] natefinch: that sounds like what we've already been doing :) [15:46] ericsnow: maybe I didn't understand the code that was doing it, then. [15:46] natefinch: well, I could be misunderstanding too :) [15:53] https://github.com/juju/juju/wiki/Managing-complexity -- comments and edits accepted gratefully [15:55] (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] fwereade: thanks! [16:44] 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] perrito666: core team call [18:24] well connection sucks, I tried to join but saw people move a bit then lost all === akhavr1 is now known as akhavr [19:33] oh yay, my internet is back [19:34] wwitzel3: welcome back. juju is now rewritten in emacs lisp. [19:34] C-m C-x juju-mode [19:35] rewritten/assimilated [19:36] emacs will be skynet, when it decides the time is right [19:36] boy the emacs jokes are running heavy today. i had not intended that. [19:37] katco: lol [19:37] * katco is also wondering if Makyo has a notification set up for emacs mentions [19:38] 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] "emacs at least it isn't acme" [19:44] to each its editor, I know people that work in either mcedit or gedit [19:45] wwitzel3: haha [19:46] without the banter about ones choice in editor, I'm lost .. don't ruin this for me perrito666 [19:46] wwitzel3: all i'm saying is vimscript is awesome! [19:46] wwitzel3: life is about choices, you can bash people about their choice on about anything [19:46] perrito666: umm, but it is only fun to do it about choices that don't have any real impact or meaning [19:51] cmars: does the uniter currently run any "subordinate" workers [19:51] ericsnow, checking.. [19:51] cmars: as far as I can tell, it doesn't [19:52] ericsnow, doesn't look like it [19:52] cmars: I've realized that the workers we're running for workloads should be running under the uniter [19:52] cmars: not directly under the unit agent [19:52] cmars: maybe [19:53] ericsnow, what do the workload workers need of the uniter? [19:54] cmars: per the doc comment, "Uniter implements the capabilities of the unit agent." [19:54] ericsnow, doc comment might be wrong now :) [19:54] cmars: ha [19:55] cmars: from what I can tell, the uniter is the worker that handles all the work of a unit [19:56] cmars: workload [processes] are a part of that [19:56] ericsnow, how? [19:56] cmars: they are a part of the workload dictated by a charm [19:57] ericsnow, right.. but it sounds like there's a worker associated with each process.. what does that worker need to do exactly? [19:58] cmars: API calls and possibly persist some data locally [19:58] cmars: plus, of course, interact with the workloads (e.g. docker) [19:59] 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] 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] cmars: per the uniter's manifold doc comment: "...We expect to break it up further in the coming weeks" [20:02] 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] cmars: under a consolidated (unit+machine) agent there will be multiple uniters per agent, right? [20:03] 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] cmars: good point [20:03] cmars: I definitely don't want to get involved in that :) [20:04] * ericsnow shudders [20:04] 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] cmars: yay [20:04]