[00:02] waigani: the parseTag method is only used in the annotator [00:02] waigani: and it is doing a doc exists check [00:02] so the id has to be the docID, not a local ID [00:25] when I bootstrap and deply mysql with trunk I get the following in juju status: agent-state-info: 'hook failed: "install"' [00:26] waigani_: what did you deploy it with? [00:27] waigani_: the gui or cli? [00:27] rick_h_: cli [00:27] waigani_: k, nvm then. There was a known gui bug [00:28] okay, anyone else hit this with trunk or am I a special snowflake? [00:28] waigani_: knowing what's in the unit log would be helpful [00:29] waigani_: juju ssh mysql/0 and then check the end of /var/log/juju/unit- [00:29] rick_h_: ugh I just destroyed the env. Let me repeat my steps and I'll check out the log [00:29] waigani_: rgr [00:35] rick_h_: http://pastebin.ubuntu.com/8407234/ [00:38] waigani_: what series is this? [00:45] waigani: curious what series that is? [00:47] rick_h_: https://bugs.launchpad.net/juju-core/+bug/1372699 [00:47] Bug #1372699: juju status reports: agent-state-info: 'hook failed: "install"' [00:49] waigani: gotcha, interesting. [00:49] waigani: last bit of info I'd include is where you were doing this at, lxc, ec2, etc [00:49] rick_h_: ah right, thanks [00:49] since the issue is around a package install wonder if there's some mirror thing going on there [00:52] rick_h_: Using trunk (daee198586afe412948b23d68f58592c625de08f) with LXC containers on my machine (amd64 14.04) ? [01:06] waigani: hmm, you know what. I wonder if this is any part of the apt-get upgrade by default stuff [01:07] waigani: is that env still up? [01:08] rick_h_: sorry, I moved on. I had to test a different branch. [01:09] rick_h_: what did you want me to check? [01:09] waigani: understood, still trying to get an lxc env up to test something out [01:09] waigani: so I'm wondering if you could manually apt-get install python-jinja2 [01:09] waigani: and if not, if an apt-get update && apt-get install python-jinja2 would work [01:10] waigani: just trying to figure out why that install would fail to run and pondering [01:10] rick_h_: Setting up python-jinja2 (2.7.2-2) ... [01:10] waigani: :/ [01:10] installed no problem [01:11] a could flaky Internet connection have anything to do with it? [01:12] waigani: yes, if that apt-get install failed to work then it would die and cause the non-0 exit [01:12] waigani: in which case it would be a temp issue I'd imagine [01:12] assuming flaky means it works some of the time :) [01:13] rick_h_: right, my guess is that is it. [01:13] waigani: ah ok [01:14] rick_h_: begs the question, if there is a better way to handle this situation? [01:14] waigani: well the tough part is that the charm is doing it in the script. If it doesn't really check/handle that I'm not sure what juju can do. [01:14] right, got ya [01:15] waigani: there is talk of juju proviing a way for defining package deps before the charm even gets going, which might help as juj then can watch/manage that [01:15] rick_h_: +1 from me [01:15] waigani: not sure where that is in the pain point list currently. [01:15] davechen1y: any idea? ^ [01:15] top of my list today ;) [01:16] looks like wallyworld is afk today [01:18] rick_h_: hold up,reading the backscroll [01:19] davechen1y: is there anything on the charms listing system deps as part of the charm vs in the hook itself on the pain point list for the nearish future? [01:20] thumper: is there a topic doc for the sprint? [01:20] rick_h_: nothing [01:20] axw: one got started today [01:20] rick_h_: what is the context [01:20] ie, what doesn't the install hook provide you that you need ? [01:20] rick_h_: okey dokey, can you link me please? [01:21] davechen1y: k, sorry waigani. [01:21] axw: sent [01:21] cheers [01:21] davechen1y: well the idea is that it would run pre-hook and in this case the charm doesn't do a good job of helping identity the issue when install failed [01:22] davechen1y: where as if it was something more juju controlled it could do better, make sure deps are there before the install hook (python deps used in the python based single hook), etc [01:22] davechen1y: so I know it was brought up but wasn't sure where it landed on plans/measure of pain [01:22] rick_h_: what is a pre-hook ? [01:22] rick_h_: i'm having trouble filtering out the bits you wish juju had from the problem you've hit [01:23] davechen1y: so one problem is the new single hook stuff. If it's a python script, and I need python deps (python-jinja2) [01:23] how can the install hook run? [01:23] rick_h_: is teh default hook stuff going in ? [01:23] i thought that it had many problems [01:24] davechen1y: or let's say my hook is py2 but utopic is py3 out of the box, I need to have py2 available available [01:24] davechen1y: my understanding is that it's waiting on charm feature flags in some form or other [01:24] davechen1y: and that's the only blockers [01:24] rick_h_: i strongly recommend always writing the install hook in shello [01:24] 'cos you can't depend on anyting [01:24] davechen1y: right, well that's the point :) [01:24] rick_h_: default hook wasn't my suggestion [01:25] i think it sounds good in theory [01:25] but fails in practice [01:25] davechen1y: ok, well anyway. I was just curious. It's come up as an idea but guess it didn't have as much traction as it seemed [01:25] default hook is a large hammer to solve very specific problem, no symlink support on windows [01:25] but windows chamrs by definition are indepdent of unix charms [01:26] so they should adopt a different pattern [01:26] for unix charms, you symlinks [01:26] well the other problem is that so many charms find a single script easier to write/maintain. That's regardless of platform [01:26] davechen1y: but all good, thanks for the sanity check on the idea [01:43] axw: yep [01:59] waigani: 1372699 [01:59] do you still have this machine up ? [01:59] you'd missing the crucial bit of the log [01:59] it appears above the python stack trace [02:00] davechen1y: ah no, sorry [02:00] davechen1y: I can try to reproduce, though I had a bad Internet connection at the time - pretty sure that was it [02:00] davechen1y: sorry, was going to update that. In chatting we assume a flaky network connection was to blame [02:00] rick_h_: waigani which provider ? [02:01] my money is on another process holding the apt lock [02:01] or apt failing [02:01] davechen1y: lxc [02:01] davechen1y: a manual apt-get install worked in debugging after the fact [02:02] waigani: rick_h_ yup, that matche sboth scenaruios [02:02] ie, if the apt lock was held by another process running apt-get afterwards won't fail because the other process has finished [02:02] also, if your network crapped out, same [02:02] antoher common charm bug is not running apt-get update in the install hook [02:03] because of 'reasons' the apt mirrors will 404 debs taht are not current [02:03] so if you have an old apt index on disk [02:03] davechen1y: ok, I couldn't dupe it locally in my lxc but also not running trunk but 1.20.7 [02:03] and go to apt-get install some pacakge, if that pacakge has been replaced by a newer one in the archive [02:03] you get a 404 and apt returns status 1 [02:03] and then your day is ruined [02:03] rick_h_: i'd be very surprised if this was related to any version of juju [02:04] this is most likely a charm bug [02:04] well [02:04] that isn't true [02:04] older versions of juju would force apt-get update/upgrade on bootup [02:04] now we don't do this [02:04] davechen1y: just stating the diff in my attempt to replicate vs reported bug [02:04] it shows up the charms that expect this to happen [02:58] does anyone have time for a quick review? fixes a critical bug that I'd like to backport to 1.20 ASAP: http://reviews.vapour.ws/r/75/diff/# [02:59] * thumper looks [03:02] axw: done [03:02] thanks thumper [03:23] anyone about who can help with a juju deploy --to question? I want to have some charms deployed to lxc on a specific unit, as in openstack-ha/0 - I know you can do things like lxc:25, but is there a way to say lxc:openstack-ha/0 ? [03:23] (where openstack-ha is just a cs:ubuntu unit) [03:30] looks like juju-deployer supposed lxc:openstack-ha=0 style of deployment, if I'm reading the docs right [03:35] bradm: no, I don't think you can say that [03:36] thumper: thats a pity, we're using it quite extensively [03:51] menn0: got a minute for a hangout? [03:56] thumper: yep [03:56] thumper: where? [03:56] here -> https://plus.google.com/hangouts/_/g2ozjdukkzbchwadejkjpa5e2ma?hl=en [04:08] waigani: would you please find some time today to review http://reviews.vapour.ws/r/66/ [04:08] davechen1y: I'll try, probably this evening [04:09] ta [04:11] menn0, thumper: on trunk I get disconnected from the API if I upgrade AND specify the version e.g: juju --show-log upgrade-juju -e local --version 1.21-alpha2 --upload-tools [04:12] menn0: your script did not test with specifying the version [04:13] menn0: could you run that upgrade step (with the version) from 1.20 to verify? [04:13] you mean the test case I used before [04:13] ? [04:13] menn0: yep [04:14] menn0: so for me, on trunk this works: juju upgrade-juju --upload-tools [04:14] menn0: this does not: juju --show-log upgrade-juju -e local --version 1.21-alpha2 --upload-tools [04:14] the latter is taking from the original CI blocking bug [04:15] *taken [04:15] waigani: I'll try it out on my machine [04:18] waigani: works for me [04:19] waigani: with master [04:19] waigani: although I did see the "invalid entity name or password" error once [04:19] waigani: the next attempt at juju status worked [04:19] menn0: yeah that's what I get [04:19] waigani: I suspect that could be before once of the DB migration steps has run [04:20] menn0: that would be a bug woudn't it? [04:20] waigani: I don't think so [04:20] menn0: I upgraded twice and got that error message both times [04:21] waigani: that's just because you're trying juju status before the upgrade steps have run [04:21] if you had waited slightly longer it would have been ok [04:21] menn0: yeah I get that, but from the user's point of view it does not look like that [04:21] menn0: it looks like it's broken [04:21] waigani: well we could try and add more hacks like the one I did [04:22] waigani: so that more stuff works even without the migration has run [04:22] menn0: or change the message [04:22] "upgrade in progress" [04:23] except we want status to work during upgrades if possible [04:24] and if not possible? [04:25] I guess if the login fails during an upgrade we could return "upgrade in progress" [04:25] that's probably a good idea [04:25] lets write up a ticket for that. [04:25] okay [04:25] waigani: will you or should I? [04:26] menn0: I've got to finish testing this branch so i can land it and you can use it [04:26] I'm already using it :) [04:26] but I'll write up that ticket [04:26] oh - right well then [04:26] okay, I'm easy [04:31] axw: slight problem with the lastest branches you have landed with upgrade steps [04:31] axw: should have checked it earlier [04:31] I have waigani adding in upgrade steps for 1.21-alpha2 [04:31] which is where any upgrade steps should go since the lastest version was tagged [04:32] will not impact anyone going from release to release [04:32] ah... [04:32] but will if someone tries upgrading from 1.21-alpha1 to 1.21-alpha2 [04:32] which is supported but I'm not sure how formally [04:32] thumper: I didn't think we bothered with that [04:32] can fix though, not a big deal [04:32] I think we should bother [04:33] axw: very minor change, and can be done after waigani's branch lands [04:33] small tweak [04:33] okey dokey, no problems [04:33] cheers [04:33] waigani: here's bug 1372752 [04:33] Bug #1372752: juju status fails with "invalid entity name or password" before DB migrations have run [04:33] menn0: thanks :) [04:36] thumper: talking of which, completed live testing [04:36] and... [04:36] thumper: replied to your rb comment [04:36] all good [04:36] cool [04:37] waigani: \o/ [04:37] * thumper feels ever so slight amount of terror getting this in [04:37] but someone has to be first [04:37] haha [04:37] like a lamb to the slaughter [04:37] waigani: done [04:38] waigani: I suggest the machine collection next [04:38] waigani: nothing like getting the big ones done first [04:39] thumper: yeah, sorry I took a wrong turn or two. I *think* I've got a pretty good idea how to do the rest now (famous last words) [04:42] thumper, right machinesC next? menn0 what are you doing? [04:42] waigani: units [04:42] waigani: ack [04:42] okay cool [04:48] thumper, waigani: I think we need to discuss these env UUID changes a little more on a hangout. now or tomorrow? [04:49] thumper: won't the 1.21 upgrade steps always run in alpha versions? i.e. they'd run from 1.20 -> 1.21-alpha1, and also from 1.21alpha1->1.21-alpha2... up until 1.21 (non-alpha) [04:50] thumper, waigani: I'm seeing a lot of places where we need to worry about filtering and I'm thinking the "minimal change" approach we're going with is going to be the less safe approach [04:50] (I can test, but if you know the answer...) [04:50] menn0: now is fine [04:50] menn0: yep [04:50] axw: it collects all from where it is, to the version going to [04:50] hangout channel? [04:50] thumper, waigani: yep, hangout channel [04:50] axw: so you are right for migrating from 1.20 to 1.21 [04:51] it collects all the 1.21-alpha1 and 1.21-alpha2 steps along the way === urulama-afk is now known as urulama [06:05] ugh, this cloud-tools ppa being pinned lower is causing me issues === Spads_ is now known as Spads [09:47] fwereade, ping [09:47] dimitern, pong [09:48] fwereade, I've updated the firewaller PR: https://github.com/juju/juju/pull/799 and I'd appreciate if you have a look [09:48] dimitern, will do [09:49] fwereade, it turned out surprisingly hard to get to the unexported environTag inside *api.State from *apifirewaller.State [09:54] dimitern, hmm, that's surprising, I could have sworn I'd seen a simple EnvironTag method [09:55] dimitern, yeah, api.State.EnvironTag() [09:55] fwereade, yes, in *api.State, but what you get in api/firewaller/New** is a base.FacadeCaller [09:56] fwereade, so I added EnvironTag to the base.APICaller interface and exposed it as firewaller.State.EnvironTag by internally calling st.RawAPICaller().EnvironTag() [09:56] dimitern, cool [09:56] dimitern, sent a couple of quick responses to your responses, looking from the start again now [09:57] fwereade, cheers [09:57] jam, re exposing EnvironTag() from *api.State to facade callers ^^ I'd like to hear your thoughts as well [09:58] dimitern: is there a Reviewboard version? [09:58] jam, nope, when I proposed it, I forgot :/ [09:58] dimitern: well, you can always add it at any time :) [09:58] I guess the discussion is already here [09:59] jam, indeed, but it will loose a bit of context after some comments were added on the PR [10:03] * jam really dislikes the "everything is State" because then it is confusing which foo.EnvironTag() you're actually calling. [10:03] davechen1y: http://reviews.vapour.ws/r/66 reviewed as requested [10:04] waigani: ta [10:06] dimitern: so is Tag.Id() a tag-thing or an id "thing" ? [10:06] (envTag.Id() returns environ-UUID or just UUID ? [10:08] jam, envTag.Id() == UUID, envTag.String() == "environment-" [10:08] dimitern: k, because there are lines like: https://github.com/juju/juju/pull/799/files#diff-06b44def560ee3d858becda14c28ba17L201 [10:08] jam, that's one of rogpeppe's :) calling most facades *State or *API [10:08] where it looks like it used to take something called a Tag, and it is now taking the UUID [10:09] it may be that st.EnvironTag() returned the UUID, which was a bad name [10:09] jam, yes it did - it was string [10:09] dimitern: it was a string, but was it "environ-uuid" or "uuid" ? [10:09] In which case, you should be passing .String() and not .Id() [10:10] /me hears his name taken in vain :-) [10:10] :) [10:10] i don't understand the issue here [10:10] jam, hmm, you're right in that case - it should be envTag.String(), I'll fix it (looking deeper the string is parsed as a tag in cacheChangedAPIInfo) [10:10] * rogpeppe probably doesn't need to [10:11] dimitern: k, it would appear we are lacking test coverage if you were able to change it without something breaking [10:11] rogpeppe, it's about how naming a whole lot of things State in the api that's gets confusing [10:11] state.State, api.State, uniter.State [10:11] jam, I haven't run the full test suite yet, but I'm doing it now to see if anything will break [10:11] United States of Juju [10:12] TheMue: :) [10:12] jam: given you've got always got the package prefix there, why is it confusing? [10:12] dimitern: I'm going to need a bit longer to digest your proposal, I have to take my dog out before standup. [10:12] rogpeppe: because you often don't have the package prefix [10:12] like in all the packages [10:12] and when looking at a diff [10:12] all you see is "State" objects [10:12] and you have to carefully reread what file you're currently in [10:13] jam: but then you don't have the "State" name either, right? [10:13] jam, sure, np [10:13] rogpeppe: everything is just a State there [10:13] jam: oh i see, in the package itself [10:13] rogpeppe: and the bigger shortcomming is that then everyone abreviates their variable as "st" [10:13] jam: but you should surely be aware of what file you're looking at? [10:14] and you don't have a clue what "self.st" is [10:14] rogpeppe: so the information is there, but it is 20 lines away past the line boundary (again, when looking at a diff) [10:14] jam: if you're just looking at a diff without surrounding context, i can see [10:16] jam: the idea behind it is that actually they're all windows onto the same underlying state. [10:16] jam: a given package is only going to be using a single facade throughout, right? [10:21] fwereade, re https://github.com/juju/juju/pull/799#discussion_r17899691 - do you mean the api watcher should return 0:juju-public changes (not the state watcher - it should still return global keys as changes I think, and the api watcher will convert them) [10:21] dimitern, no [10:21] dimitern, globalKeys should not leak out of state [10:21] dimitern, they're meant to be purely internal [10:21] dimitern, so fix the state watcher soon [10:22] dimitern, and one day we'll fix the api watchers by inserting an id->tag translation thingy in a consistent place/way [10:22] fwereade, ideally, we should have a PortsWatcher instead of StringsWatcher, which returns changes like []{MachineId: 0, NetworkName: "juju-public"} [10:23] dimitern, yeah, that'd probably be nicer [10:23] fwereade, ok, I'll do a follow-up for that [10:23] dimitern, great, thanks [10:45] jam, i can't hear you btw [10:45] dimitern: my browser crashed [10:45] dimitern: and after restarting it... it crashed again, I think I have to reboot after the last updated, bbiab [10:46] TheMue, standup? [10:47] dimitern: omw [10:54] fwereade: dimitern: so we should have a discussion about how we want to handle Agents in a MESS scenario [10:54] because so far, the MESS design was that the Environ was implicit to the connection [10:55] jam, is this about the firewallers/provisioners for the various envs? [10:55] It may be that for Agent's we'll want them to be multi-environment aware, but that wasn't the MESS design (As I understand it), because Login takes the environ-uuid, and not the rest of the system. [10:56] fwereade: so this is brought up in the context of Dimiter's changes, but I'd like us to have a plan for what we're going to be doing so that we can work towards consistency. [10:56] jam, I *think* it's doable without conflict -- ok, an environ is implicit to a connection, because the agents are running in the initial environment; but I don't think that prevents us from explicitly using tags for other environs, for those environs' workers [10:57] jam, at the moment we pull the environ uuid out of the connection [10:57] jam, but we are explicitly referencing environs in api calls [10:57] jam, and I think it's relatively simple to move that awareness down a level, directly into the workers, without mucking with the actual API [10:58] jam, ie without mucking with the wire format [10:58] jam, there will still be code changes ofc :) [10:58] jam, any places where we depend on the implicit environment will be problems [10:58] jam, but I hope there aren't many of them [10:59] jam, I've tried to spot them and block them [10:59] fwereade: so Dimiter is needing EnvironTag from his api.Client object in order to pass it back into the api.Networker facade [10:59] which means changing api.FacadeCaller to also include EnvironTag, etc [10:59] which is why his changes are large-ish [10:59] but if you're getting your context from your context, it doesn't make a ton of sense. [11:00] jam, well, yes, I think I have a comment along those lines -- that there's no need for explicit knowledge of environ tag at the firewaller level at the moment, because the client can put it into the calls directly [11:00] jam, dimitern: I waffled on that comment though [11:01] fwereade: some of it would be "do you want to run a multi-environment firewaller" as in, 1 Firewaller worker for N environs [11:01] jam, I do not want to do that [11:01] fwereade, we're finishing standup, will respond shortly [11:01] jam, both provisioner and firewaller are bloated enough [11:01] jam, layering multi-environment-icity on top will be horrible [11:02] jam, isn't it "just" a matter of having a parent worker that keeps track of the list of environs, and starts appropriate workers for each? [11:03] jam, a provisioner-deployer, if you will === fabrice is now known as fabrice|lunch [11:03] fwereade: well the question is, do these things Login separately (and thus all have their own state connection), or is it all a shared connection and the Environ they are operating on needs to be explicit in the API [11:04] I *thought* the plan was that the apiserver's State root object would know what environment you were working in. [11:04] certainly if you are then talking about some *other* environment you'd have a tag for it [11:04] But do we need the API to be "StartInstance(environTag, constraints, etc)" [11:05] jam, different example please? StartInstance isn't our API ;p [11:05] fwereade: AddMachine(environtag) ? [11:05] that is at the Client level, though [11:05] jam, WatchPorts(environTag)? [11:05] jam, yes, I think it should be [11:06] jam, implicit args have seemed to cause us more trouble than they're worth [11:06] fwereade: so, we just did Login(environTag) for that worker, right? [11:06] jam, but I think there's no conflict in being connected to the initial environment, and asking about some hosted environment [11:07] jam, yes [11:07] fwereade: I don't view environments as things that can be nested. Do you mean connected to the initial state server? [11:08] jam, where are the workers for the hosted envs running, if not in the initial env? [11:08] jam, blast, brb, keep talking [11:11] a fair point. though the workers for the hosted environs could have their own connections [11:11] fwereade: it feels like, if we want to be explicit about Environ, we pretty much need to add it to *every* request, which then means that we might as well make it common to every request [11:11] and it should just go back to implicit [11:13] jam, mmm, I'm not sure we really want N connections, one for each hosted env, from a single agent in a MESS [11:15] jam, I think there's some additional distinction too but I'm having some trouble articulating it [11:15] fwereade, jam, I'll make the environ tag argument to WatchOpenedPorts client-side firewaller facade implicit, but the server-side will still take Entities [11:15] fwereade, jam, is that OK? [11:15] jam, there's something worse about operate-on-nothing getting an implicit context than operate-on-something having it [11:16] dimitern, yeah, that's what I'd favour here [11:16] fwereade, cheers [11:16] dimitern, with the expectation that we do add environ-awareness to FW and P at some point in the not-too-distant future [11:16] dimitern, but that we don't want or need it this minute# [11:16] * jam is making some coffee, but I feel this is probably hangout worthy [11:17] dimitern, and that all we'd need to do to accommodate that is to tweak the client code on one side, and the auth on the other [11:17] jam, just a sec, let me see [11:17] fwereade: so if you are WatchPorts(environTag), then surely anything you then do because of that watch [11:17] needs to take an environTag [11:17] fwereade, by "don't want or need it this minute" do you also mean making WatchOpenedPorts at server-side not taking Entities as well? [11:17] You can't do WatchPorts(envTag), => OpenPort() [11:18] fwereade: and as for multiple "Conns", it could be as simple as a different logical connectiion, it wouldn't have to be a separate TLS /TCP session. [11:19] jam, ha, yes, you're completely right [11:19] dimitern, server-side we do want it [11:20] dimitern, jam: I still *think* that this consideration is specific to provisioner/firewaller (maybe some others?) [11:20] fwereade, ok [11:20] jam, separating out logical connections would be nice, yeah [11:20] fwereade: so I'm fine enough that we'll have some "things" that are actually aware of multiple environments (cross environ relationship manager), but I'd like to be cautious about adding EnvironTag to any API that isn't ever going to take 2 different ones [11:21] jam, I'm still worried that every time we do a no-args thing we end up with problems [11:24] fwereade: I think mixing noargs and args is going to be worse in the general case [11:24] now, if we actually went all the way to stateless... then you have always-args [11:24] which I'm actually happy with, but hasn't been the design we went for [11:25] jam, heh, I just realised OpenPort doesn't apply -- but asking which ports are open still does [11:27] fwereade: well, there is an "actually implement this change in the Provider" which at this point may be just a direct callout, but the logical "if I have an API that takes an environTag, then whatever I call as a result of that first API call then also needs an environTag" [11:28] and I feel like, 90% ? of what we are going to do needs to then take an EnvironTag, which is why we made it implicit in the first place [11:31] jam, I guess that may be the main point of difference? I feel like the firewaller/provisioner are relatively rare and special [11:31] fwereade: so I think there is a definite case for different "rings" of agents [11:31] There is the Client API for "juju" [11:31] there is the Agent API for machine-10/unit-mysql-5 [11:32] and there is the EnvironmentManager API for Provisioner/Firewaller/etc. [11:32] It would be good to actually separate those out in code. [11:32] jam, that does sound sane, yeah [11:32] jam, certainly different forces apply to the different categories [11:32] (and then there is the API server which is obviously underneath that) [11:34] jam, I'm not wholly clear on how that separation would work though -- purely as an organisational thing? [11:35] fwereade, re https://github.com/juju/juju/pull/799#discussion_r17900095 - do you think it's better to change "case changes ,ok := <-in:" to "case changes := <-in:" as it was? [11:36] dimitern, no, I'd prefer to be explicit about checking for channel closes, they can happen [11:36] fwereade, ok [11:36] fwereade: right, just different directories (apiserver/RING0/provisioner) [11:36] tasdomas, ping [11:37] dimitern, it's the fact that MustErr can panic [11:37] fwereade: given that is the whole point of Must, right? [11:37] jam, sure [11:38] jam, it's really the usage/existence of MustErr [11:38] fwereade: I certainly think we would benefit from "Agent" vs "Client" apis, especially as we split up Client into many Facades [11:38] tasdomas, re https://github.com/juju/juju/commit/7694614984932598535639e09129820f15b9d58d - changing dependencies.tsv to bump a revision of a versioned import path like gopkg.in/juju/charm.v3 instead of "releasing" a new version gopkg.in/juju/charm.v4 is BAD, let's not do that please [11:38] jam, I feel like it should be more GiveMeSomeErrorIndicatingEitherTheWatcherErrOrTheFactThatThereIsntOne [11:39] tasdomas, the whole point of having versioned import paths is to rely on "vX" meaning the same thing as the package evolves [11:40] fwereade: EnsureErr ? (EnsureThatIHaveSomeSortOfError) [11:40] jam, good idea [11:40] most Must* mean panic [11:40] jam, agree [11:40] jam, and yes I think splitting the API up like that would be smart too [11:41]