[00:47] O/ [00:52] hi redir [00:53] dnegreira: hi there [00:53] dnegreira: juju already has a lxd provider [01:04] wallyworld: back [01:06] axw: i'm just testing abother iteration - i may have found the issue, i'll ping in a bit if needed [01:07] okey dokey [01:07] I'll finish up my PR then [01:07] sgtm [02:32] wallyworld: is your PR ready for review again? did you sort out the test failure? [02:33] wallyworld: well... watchers based on a single tailer is working in my controller [02:33] needs more testing [02:33] and some real tests added [02:33] but good start [02:33] I need to make sure it is robust in failure cases [02:34] thumper: tailable iterator? [02:34] axw: not at this stage [02:34] kept the basic implementation [02:34] cool cool, just curious what you meant [02:34] but now with how it is separated [02:34] it would be easier to change to use that [02:34] great [02:34] axw: I've added a worker to the state pool that does the tailing [02:35] it publishes to a pubsub.SimpleHub owned by the state pool [02:35] and the other state objects the pool creates just use a watcher that listens to the hub [02:35] so a slow state won't slow down a fast state [02:35] thumper: sounds good [02:36] axw: how would you feel if we put a pool attribute on the state instance? [02:36] there are places where we are creating pools just to iterate models [02:36] which seems ungood [02:36] even if they are rare code paths [02:38] thumper: I would rather we didn't. do you have an example on hand [02:38] ? [02:38] that's ok, they are pretty rare [02:38] thumper: IMO we should just pass a pool into the callers instead [02:38] hmm... [02:38] one is in state/cleanups.go [02:38] another when destroying a controller [02:38] also in state [02:40] thumper: hmmmm actually, lemme think on it [02:40] it isn't urgent [02:41] but areas where we should clean up I bit [02:41] thumper: I think I mentioned this before, but what I want to have is a state.Manager which essentially does what StatePool does now, but it will be the one and only place where you can obtain a State object [02:42] thumper: i.e. no more state.Open [02:42] right [02:42] perhaps the pool becomes that thing [02:42] thumper: if we do that, then a State could reasonably internally have a Manager reference [02:42] * thumper nods [02:42] atm the controller State doesn't come from a StatePool, so feels a bit awkward [02:43] and I really don't want the controller model's State to create or own the StatePool, that feels backwards to me [02:43] thumper: also, I want to remove the State's Close method. they should just be accessible from the manager/pool, and that should take care of closing its mongo session and workers internally [02:44] axw: yeah, ready for another look [02:45] wallyworld: I take it the worker wasn't running hooks and such because of the missing ":latest" ? [02:49] axw: not that reason - it was because cmd/jujud/main was specially looking for a rpc service listening for "Jujuc.Main" and i had renamed the struct for the hook commands from Jujuc to HookCmmnd [02:50] wallyworld: ahhh [02:50] i wanted to get rid of jujuc [02:50] yay reflection magic [02:50] as it doesn't make sense anymore [02:50] * axw nods [02:50] wallyworld: can you please add a NOTE comment on the Jujuc struct [02:50] axw: i just finished deploying my gitlab charm - app status is set to active as it should be so it all works end-end [02:50] wallyworld: sweet :) [02:51] will add comment [03:00] axw: understood [03:42] axw: i added juju-log hook command, just a simple port. not urgent https://github.com/juju/juju/pull/8172 [03:44] wallyworld: LGTM [03:44] ta [04:09] wallyworld: might be a silly question: but can the API server send requests to the agents? [04:10] babbageclunk: it's all one way from agent -> api server [04:10] agents do start watchers which are long running connections [04:12] wallyworld: ah - I was confused by the code in rpc/conn.loop that handled the header being a request or a response. But I think that's shared between the client and server, isn't it/ [04:12] ? [04:12] in rpc/server.go [04:12] maybe, not sure. i'm not 100% across that code [04:13] i could guess but that would be bad [04:14] ok, I think I get it. [04:15] ok [05:09] axw: this adds some more needed apis, no rush https://github.com/juju/juju/pull/8173 [06:50] axw: thanks for review, i replied to comment [07:19] axw: i'll need to debug a bit - it seems when we invoke the config-get hook tool, we always get empty config - the tool runs without error so it may be that the config is not being recorded in state. have you seen that behaviour at all? [07:21] wallyworld: nope, but I had logging in there which I tested [07:21] wallyworld: i.e. the "application config changed" log message [07:21] axw: yeah, in a hook, i call hookenv.config() and it's empty sadly [07:24] debug time === frankban|afk is now known as frankban [07:36] wallyworld: hookenv.config() is showing the config for me [07:36] axw: a reactive charm? [07:36] wallyworld: I dpeloyed gitlab, then ran "juju config gitlab gitlab_image=foo" [07:37] wallyworld: yup, not that it should matter [07:37] hmmm [07:37] for me hookenv.config() is empty [07:37] i'm not setting ny config explicitly [07:38] i'm relying on defaults [07:38] which i thought were sent as config values [07:38] wallyworld: ah. it does appear to be empty by default, which seems like a bug [07:38] maybe not [07:38] axw: yeah, i'm thinking a bug in caas models [07:38] wallyworld: I suspect we're not populating the application's settings properly [07:39] axw: there's also an issue with container-spec-set that i'm seeing [07:39] fixing that one first [07:39] wallyworld: fixed in my PR [07:39] wallyworld: assuming you mean the order being reversed [07:39] wallyworld: https://github.com/juju/juju/pull/8174 [07:39] let me look [07:42] axw: yeah, ooops, that's the bug [07:49] axw: lgtm. i've got a charm which should hopefully work (once we get the config stuff fixed) [08:12] wallyworld: cool [08:12] wallyworld: can't add units yet, that's the next step [08:12] wallyworld: starting to look into that === frankban is now known as frankban|afk [09:21] axw: we can debug tomorrow - when i deploy my charm, it is setting the spec now, but the container spec watcher is not notifying, so the unit worker is not creating the pod [09:54] wallyworld: probably because you have no units? [09:54] wallyworld: I have it working here [09:54] wallyworld: I had to make changes in state so that units can be added to a CAAS app [09:54] axw: ah right, i forgot about that; i thought we created one but forgot we don't [09:55] so it's just the config issue [10:01] axw: also, i'm mulling over whether we should provide the reactive key value store via a hook tool (similar semantics to model-config where a single CLI cmd is used to set or reset values). that way we get caching via the context and also the connection boilerplate back to the controller all taken care of easily [10:10] wallyworld: yeah, that does sound like a good reason to use a hook tool. or at least going through the operator agent as an intermediary; it could still be an API [10:11] CLI is probably fine tho [10:12] CLI is easiest to hook up at the moment i think [10:12] less messing about with python etc === frankban|afk is now known as frankban [11:36] Bug #1727507 changed: [2.3] rationalize offer commands [12:00] Bug #1721555 changed: juju run tries to reach manually added machines through private IPs instead of public [13:30] Bug #1733968 changed: virtual IP addresses should not be registered

=== frankban is now known as frankban|afk [21:28] wallyworld: i have a pr up - just ignore for now, it’s going to change :-) [23:12] hml: is your PR ready for review? [23:13] wallyworld: pushing the updates now [23:13] ok