[01:14] wallyworld_: you have a couple moments? What's the best way to expose a controller config to a cmd? (i.e. https://github.com/juju/juju/blob/develop/cmd/juju/application/deploy.go#L248) [01:17] wallyworld_: oh, something along the lines of getting an APIContext which we can then use to communicate with the controller and retrieve the needed info? [02:51] wallyworld_: https://github.com/juju/juju/pull/8888 [02:55] or anyone really... [03:04] thumper:lgtm [03:04] veebers: thanks [03:05] sorry thumper was distracted with #@%#$$#@ k8s storage [03:06] wallyworld_: that's fine, veebers has sorted it [03:17] wallyworld_, thumper: Is this the right direction to head for having a boostrap config for charmstore url and being able to access it in a command context? (i.e. the deploy command creates a charmstore client and needs to know that url) [03:17] oops, and the actual link: http://paste.ubuntu.com/p/nWMGhGff7s/ [03:18] I think we need to be very clear about the behaviour we are expecting [03:19] in the difference between client and server aspects [03:19] I don't think we should be looking at bootstrap config to determine this [03:19] for the client side, I'd much rather just use an environment variable to override the behaviour [03:19] for Juju, it should be controller config [03:20] wallyworld_: thoughts? [03:22] hmm... [03:22] we have a --reset for model-config but not controller-config [03:22] um [03:23] yes controller config server side [03:23] but at bootstrap, it can be passed in to bootstrap command [03:23] using the existing controller config mechanism [03:23] it's not a deploy command thing [03:23] it's set once only at bootstrap [03:24] and for now is immutable [03:24] if you try and mutate itvia reste or whatever, you will get an error, like for api port [03:26] do any client side things need to know or care about this value? [03:26] not sure, but if so they get it via controller config [03:26] no... [03:26] a client wouldn't necessarily have access to it [03:27] all clients can get controller config [03:27] via the controller facade [03:27] we already do that in places [03:27] can't recall where off hand [03:27] do we really want to add another api call to all call sites? [03:27] hmm.. [03:27] * thumper thinks [03:28] we probably don't want a client side environment variable [03:28] no, i don't think so [03:28] if we are thinking about enterprise charm stores [03:28] wallyworld_: I cribbed some of that code from destroy command (i.e. func (c *destroyCommandBase) getControllerEnvironFromStore() ) [03:28] veebers: we can't rely on the store [03:28] because most users won't have it [03:28] the deploy command does go tto store and gets the charm and then uploads to controller [03:28] i think [03:29] deploy and controller should use the same store [03:30] where store here refers to the charmstore [03:30] for enterprise case where store is behind firewall, i think it's reasonable that deploy client has access to that store [03:30] and not the local config store [03:31] yes [03:31] too many things have the same name [03:31] state [03:31] api [03:31] backend [03:31] client [03:31] :) [03:32] veebers: so we don't get store url from bootstrap config since that's only present on that one client used to bootstrap [03:33] veebers: where is the tip of the 2.4 branch going to appear in snaps? [03:33] i think it takes about 4 hours [03:33] edge [03:33] oh wait [03:33] wallyworld_: edge is tip of develop [03:33] 2.5 is current [03:33] misread [03:33] thumper: working with vino to get that job deployed [03:33] * thumper nods [03:34] will it be in candidate? [03:34] or beta? [03:34] * veebers checks the job [03:35] veebers: see the canonical #juju [03:37] thumper: just checking the config. Vino sweet, just getting an answer for Tim ^_^ [03:41] thumper: candidate [03:41] phew that took longer than it should have ^_^ [03:41] veebers: thanks [03:42] wallyworld_: sorry was distracted. Ok, what's the best way to proceed, i.e. I need the cs url to use in the deploy command (and others) but can't (or won't) get it from controller config [03:43] why not from controller config? [03:44] that would be the single source for that info [03:44] wallyworld_: ah sorry, I misread bootstrapconfig. Yeah controller config is fine, in that diff I pasted I'm using a controllerConfig from the bootstrapConfig. Or is that code not doing what I think it is? [03:45] the pastebin is getting stuff from local yaml files [03:46] you need to go to the controller itself to ask for its config [03:47] there's only 1 place i think we currently do that from the cli, which is the controller config (get) command [03:47] wallyworld_: ah is that the ClientStore? a local cache of info? [03:47] wallyworld_: ah right, and that's a ControllerCmd [03:47] right, ClientStore is a local cache of stuff [03:48] bootstrapconfig is stored locally as yaml but it really needs to die with fire [03:48] it's there because reasons. mostly restore -b which we don't even support anymore [03:48] so we should be able to get rid of it [03:49] wallyworld_: ack, I'll not use it then lest you come knocking at my door with matches [03:49] wallyworld_: I'll sort out having a way to hit the controller for that info [03:50] look at the controller/config.go command [03:50] there's an api facade which provides the info [03:52] can do [03:54] wallyworld_: as in check out cmd/juju/controller/configcommand.go? [03:54] yeah [03:55] sweet, did skim that before I'll dig in [04:03] veebers, vino: how soon do you think we'll see 2.4.1 proposed snaps in candidate? [04:05] thumper: I think vino is just about to update the job, we can fire it off anytime from then (or if it's needed *now* we can manually edit the job). Then I'm not sure how long it takes for LP to recognise the updated branch, build and publish> I can't imagine too long though [04:06] (30 min - an hour or so?') [04:06] * thumper nods [04:06] ok, thanks [04:11] thumper: vino is still getting grief from JJB, I can manually edit the job now if you want that process in motion [04:19] thumper: fyi I updated the job and fired it off now, will have to wait for the LP parts to do it's magic [04:19] ack [04:58] congrats on the 2.4 release! :) [05:00] thumper: FYI snap candidate has been published, now 2.4.1+2.4-b5eced6 [05:06] axw_: thanks, hopefully it will work well for folks. how's things with you? [05:22] wallyworld_: pretty good thanks. published the first (beta) release of the APM Go agent recently. nothing very exciting otherwise :) === axw_ is now known as axw [05:23] hey axw o/ Congrats on the release ^_^ [05:23] thanks :) [05:24] one of these days I'd like to hook it up to Juju [05:39] wallyworld_: something more along these lines? http://paste.ubuntu.com/p/GhBPvWcFBB/ [08:02] stickupkid: Going to merge #8882 ? [08:24] manadart: i was having issues with CI yesterday [08:24] manadart: seems it's fixed [08:24] stickupkid: Ja. [08:32] manadart: https://bugs.launchpad.net/juju/+bug/1779897 [08:32] * thumper bugs and leaves [08:32] Bug #1779897: container already exists

[08:36] thumper: Saw it; will look presently. [09:27] Hi all, one of my charm fails in install hook and logs show "DEBUG install FileNotFoundError: [Errno 2] No such file or directory: 'config-get'" I tried to see and this seems to be provided by juju to charms. What could be wrong [13:29] been a while [13:29] for standard charms whats the sanest way to add some apt dependencies to install at build time? [13:29] layer apt or is there some stuff you can stick in layer.yaml i seem to recall [13:30] maaudet: I just assumed folks used the apt layer [13:30] err magicaltrout that is ^ [13:31] magicaltrout: as it handles some cases ok for you like already installed/etc [13:33] I created the bug report about yesterday's issues with MongoDB in an HA context: https://bugs.launchpad.net/juju/+bug/1780086 [13:33] fair enough [13:33] Bug #1780086: MongoDB connection errors after juju enable-ha

[13:49] ty maaudet, I'll replicate it here and check it out. [14:50] stickupkid: Can you review https://github.com/juju/juju/pull/8891 ? It's a tiny one. [14:50] manadart: sure nps [14:53] manadart: done [14:54] stickupkid: Thanks. While you are there, this one backports all the same commits with preamble to 2.4: https://github.com/juju/juju/pull/8889 [15:02] rick_h_: Thanks for looking it up! Do you you think that this warning has it's place since it's basically never going to work, but works through another address? [15:03] maaudet: I've been pondering it. I mean, it's good to know if you're expecting it to work, but of course in this situation I know it won't. However, we've not done things like specify to Juju "your traffic should be on X" so that if it can't/won't do that it knows that's a real error [15:03] maaudet: but on the other hand, warning that all's working ok isn't helpful [15:04] maaudet: so I'm not sure the best way forward. I feel like what it needs is better visibility that HA is up and in a happy state and if that's true...well then ignore these. Maybe they're debug messages vs warning level. [15:04] rick_h_: Yeah, it should probably have something like (1/3 connections successful to the target machine) or something like that appended to the warning [15:04] maaudet: yea, the logging is coming deeper in the code so it's that bubbling/aggregating that would need to be done in some fashion [15:05] maaudet: it's basically the mongo driver code trying to connect, failing, and erroring down there without knowing there is other connections goin [15:05] rick_h_: I see. That explains it. [15:07] maaudet: yea, I mean you're totally right it's just more work :) [15:08] manadart: LGTM - just a question about this really - https://github.com/juju/juju/pull/8889#discussion_r200153837 [15:47] manadart: PR review - https://github.com/juju/juju/pull/8893? [15:47] manadart: this one moves the old logging, to the new container package. [15:52] stickupkid: Looking. [16:44] thanks for landing that stickupkid [16:47] maaudet: so in looking we have this bug on the error notifications: https://bugs.launchpad.net/juju/+bug/1644011 [16:47] Bug #1644011: juju needs improved error messaging when controller has connection issues [16:47] maaudet: so I noted that while we're in there fixing the error UX we should also hit up the warning on regular working since we'll have to be in the same area cleaning that up [17:17] manadart: https://github.com/juju/juju/pull/8894 PR, but I'm not sure this is right - so feedback would be appreciated :D [18:48] i know marco has told me this once before [18:48] if i'm writing a charm and want to save state between runs so I can compare last run to this run [18:48] how do I store it? [18:49] config works, but i'm wanting internal storage not config.yaml hopefully [18:51] magicaltrout: hmm, I'm not sure. Most folks are out with the big US holiday today [18:52] magicaltrout: https://charmsreactive.readthedocs.io/en/latest/charms.reactive.helpers.html#charms.reactive.helpers.data_changed ? [18:53] yeah not that i was poking through the docs trying to remember [18:53] no problem [18:53] data changed just tells you if something changes [18:53] not what [18:53] there is some KV mechanism somewhere IIRC [18:53] magicaltrout: right but you can stick the data you want to track into that can't you? [18:54] magicaltrout: I mean it takes the data to track as an argument? [18:54] magicaltrout: oic, you want the state itself vs arbitrary data [18:54] hello everyone, I'm experiencing some oddities ... trying to figure some things out with basic relations [18:54] as you can see here https://paste.ubuntu.com/p/dRcCF9ygpz/ [18:54] mostly, I'm trying to reconstruct a config file rick_h_ when a relation changes [18:55] but the config is made up from data from a bunch of relations [18:55] (preface I am just testing a redis <-> test charm relation here) [18:55] so its brining the values from a range of relatinos back to a single config [18:56] heckles1000: k, nothing looks odd there so far. What's up? [18:56] magicaltrout: oh hmmm... [18:56] why did you get the short straw rick_h_ ? you secretly wish the british were still in change? ;) [18:56] https://github.com/chrisheckler/layer-redis-test/blob/master/reactive/redis_test.py#L19,L34 [18:57] I'm thinking I can make this handler only execute 1 time by gating with my own custom flag [18:57] magicaltrout: meh, mid-week holiday :( so swapped it out for friday so I can head to the lake earlier [18:58] https://github.com/chrisheckler/layer-redis-test/blob/master/reactive/redis_test.py#L20 - this is the flag [18:58] even though I set it at the end of the handler, it seems the handler still executes 3 times [18:59] heckles1000: right, you can use your own flags and just set it once the method runs and it'll gate future executions of it [18:59] heckles1000: hmm, what's the trigger stuff about? /me looks up the trigger stuff [19:00] oh, I should take that out [19:00] or push my current code [19:00] my b [19:00] I'm trying to eliminate this handler from executing > 1 time [19:00] https://paste.ubuntu.com/p/h8hhP9D2Qz/ [19:01] if I login to the machine and cat the file I'm writing to, you can tell the handler has ran multiple times [19:02] heckles1000: I'd drop some log lines in to help diagnose why it's rerunning. You should be able to add logs to check the status of the flags, etc. I see you unset it in the broken handler. Maybe that got triggered somehow? [19:02] heckles1000: check out the hookenv.log and see if you can narrow it down [19:02] ok [19:02] heckles1000: the trigger thing I think definitely needs to go as that should be global in the file and not rerun on multiple function runs [19:03] ahh, ok, I was reading the trigger docs and it shows ithem in the handlers [19:03] yea, I do see that as well. I don't get why you'd let there be an option to create the trigger several times though. [19:03] maybe it makes sure not to I guess... [19:04] yeah, I'm a bit confused there, I was thinking I might use it to ensure my handler only runs once [19:04] let me see if I can slim this down any [19:09] rick_h_: does this look better https://github.com/chrisheckler/layer-redis-test/blob/master/reactive/redis_test.py [19:10] heckles1000: yea, seems reasonable [19:13] rick_h_: seems to be working as intended now, thanks for the insight [19:13] heckles1000: awesome [20:22] morning team [20:22] morning thumper [20:41] are you guys seeing the goal state errors on unit with remote relations? [20:41] https://paste.ubuntu.com/p/Rpb2R93VgM/ [20:43] I filed this https://bugs.launchpad.net/juju/+bug/1780154 [20:43] Bug #1780154: goal-state error on remote relation [20:43] bdx: not sure about that. I'm not sure how much you can know about the remote end [20:43] bdx: k, I'll bring it up on afternoon calls [20:43] cool, thx [21:11] oh... [21:11] it certainly shouldn't error [21:13] bdx: thanks, thrown it at wallyworld [21:47] np, thank you [23:06] wallyworld: It's probably bad taste to add to ModelCommandBase something like GetControllerConfig, or GetCharmstoreAPIURL right, perhaps I should just add the helpers to the commands that need ti (deploy and upgradecharm so far) [23:06] veebers: still otp, one sec