[00:59] axw: running a minute late, otp with tim [00:59] okey dokey [01:34] babbageclunk: I think you're right, we should invest in a perf testing scaffold [01:35] babbageclunk: I'm thinking we could just write something that would add a bunch of units and spread them over a few lxd containers [01:35] just something that'll cause a bunch of connections and load on mongo [01:36] we could do microtests, but the closer to reality the better [01:38] axw: yeah, makes sense. [02:04] wallyworld: BTW these might be useful: https://prometheus.io/docs/instrumenting/writing_exporters/, https://prometheus.io/docs/practices/instrumentation/, https://prometheus.io/docs/practices/naming/ [02:05] thanks [03:20] Anyone able to explain why I can't deploy to azure? http://pastebin.ubuntu.com/24838522/ [03:20] s/deploy to/create a new model on/ [03:22] If I retry with just the cloud name, I get: http://pastebin.ubuntu.com/24838529/ [03:22] wallyworld: are we meeting today? I know Tim is traveling [03:23] jam: we could, de debrief on what's the next steps on site perhaps [03:23] see you in ~30 then [03:24] hey jam - can I pick your brains about bug 1696509 quickly? [03:24] Bug #1696509: status-history-pruner fails under load [03:25] blahdeblah: a controller can only support one cloud [03:25] looks like you are trying to an an azure model to an openstack controller [03:25] wallyworld: orly? [03:26] since forever [03:26] Wow - OK; never realised that was a limitation [03:26] thanks [03:26] jaas of course is different [03:26] o.O [03:27] in juju 1, cloud and creds were art of environment.yaml [03:27] and only single model [03:27] this is not juju 1 [03:27] xright [03:27] just giving you background [03:27] ah, ok [03:28] we evolved to support multi-model, but still only on one cloud [03:28] and mukti-creds also [03:29] I might log a bug about the error message it gives, then [03:29] Because it gives the impression you can just throw creds, give it the cloud, and expect it to work [03:48] babbageclunk: i'm happy to talk about it, but I haven't really started my day yet [03:48] jam: oh sorry - let's do it after you've started. [03:49] jam: I'm just going to try something anyway [03:49] babbageclunk: my quick thought on it was to say "I need to delete everything before X, what is approximately 10,000 records should be Y, lets slowly increment up to X" [03:50] instead of issuing a single db delete that will take 3hrs to complete, and gives no feedbakc in the mean time [03:50] axw, wallyworld: you guys have 10 mins to discuss mgo session handling? [03:50] ok [03:50] hey menn0, good to see you around [03:51] jam: sure - I have something that gets ids back and issues a delete for those, but rereading you're suggesting doing it by time instead. [03:51] jam: howdy jam [03:51] babbageclunk: more that I don't think we actually want to grab 1M ids and then slowly walks through them [03:51] babbageclunk: we want to be doing big batch deletes, just not everything-all-at-once [03:51] babbageclunk: if what you have doesn't slow it down a lot, then I'm fine with it [03:52] wallyworld, axw : https://hangouts.google.com/hangouts/_/canonical.com/mgo-sessions [03:52] jam: ok cool - I'm just checking that now. It shouldn't be getting all of the ids at once. [03:53] babbageclunk: as always, its more about "how does it handle when things are bad, vs happy case its greate" [03:54] jam: want to join https://hangouts.google.com/hangouts/_/canonical.com/mgo-sessions [03:55] * jam screams nooooooo! and runs away and hides [04:01] weird, 'my connection was lost', rejoining [04:01] ah, 2fa kicked in [04:07] Anyone able to explain why deploy via path no longer works on 2.1.3? Worked for me last time I tried this (2.1.2, IIRC). http://pastebin.ubuntu.com/24838818/ [04:24] blahdeblah: I'm pretty sure that is should just be the path to the charm, so should be: juju deploy ./ntp [04:25] veebers: . is the path to the charm. If I deploy with full path, I get the same result [04:25] blahdeblah: ah, I see [04:25] blahdeblah: what's the 'ntp' part? [04:26] service name [04:28] blahdeblah: ah ok, I'm totally barking up the wrong tree, looking at the error again I see "Bad Gateway" as the request error, I'm not sure about that sorry. I'm sure someone around here would have an idea though [04:28] veebers: no worries - thanks for looking [04:48] menn0: sorry I went to the shops, eating now... did you already talk? [04:48] axw: still going [05:10] wallyworld: it looks fine to me, can you try using "juju-introspect metrics" and grep for one? maybe the UI has cached the keys [05:11] ok [05:11] axw: just got to deal with something here so will do it soon [05:11] wallyworld: and also, are you sure it's running your code? did you set the version to 2.2-rc2? if it is, it would have picked up the released binary if you didn't --build-agent [05:11] wallyworld: sure [05:12] it's rc3 [05:12] and i added logging [05:32] blahdeblah: IP:17070/model/6dec752c-5d00-4947-8dff-17b66ef22833/charms?revision=0&schema=local&series=xenial: Bad Gateway [05:32] axw: yeah, must have been browser caching, wotks from cli [05:32] blahdeblah: that isn't a "cannot deploy the local directory" [05:33] blahdeblah: that is "cannot talk to the controller to upload the local charm" [05:33] wallyworld: cool [05:33] jam: Except that I can talk to the controller just fine [05:34] If I push exactly that directory to my charmstore account, it deploys OK as well. [05:34] blahdeblah: I can't say for sure. I can say that we do a different operation on upload (instead of connecting and upgrading to a websocket, we just do a POST of the content) [05:34] 502 Bad Gateway seems odd [05:34] as it seems to indicate you have a reverse proxy inbetween you and Juju [05:35] seems 502 is for when you talk to a proxy, and the proxy forwards your request but gets a bad response from the target [05:35] a forward proxy is possible [05:35] (i.e. my local squid) [05:36] * blahdeblah looks for errors there [05:36] both 'juju status' and 'juju deploy' will talk to 17070, but maybe the local squid tries to inspect POST in a way that it doesn't try to mess with UPGRADE to websocket [05:42] seems like https_proxy is being used for one, but not the other [05:44] anyhow, found the squid acl stopping it; hopefully it will work next time [05:44] thanks jam [06:16] axw: here's that metrics PR https://github.com/juju/juju/pull/7487 [06:16] wallyworld: looking [06:30] wallyworld: left a few comments [06:30] ok, ta [06:31] axw: also, with agents dialing the controller, it seems to me that we don't use last successful connection - we try all the addresses concurrently, first wins. and this will have an effect of picking the least busy controller as it will be likely to respond first [06:32] func dialAPI(info *Info, opts0 DialOpts) (*dialResult, error) { [06:32] wallyworld: yes, but I think there's a delay before we dial the [1:] addrs? [06:32] * axw checks [06:33] wallyworld: yep, see DialAddressInterval [06:34] axw: oh right, i just read the method doc [06:34] it should make that bit clear [06:44] axw: i wonder what happens when a counter rolls over [06:44] i guess it is so far off it won't happen in practice [06:45] wallyworld: it's 64 bit, so not going to happen [06:45] well, not any time soon :-) [06:45] heat death and all that... :) [07:00] axw: could you PTAL? [07:00] looking [07:01] i guess i should make it a uint64 [07:01] wallyworld: I meant drop connection_rate in favour of a total. no need for both is there? [07:02] well, i like the idea of not need to use any extra prometnius config to get the rate [07:02] just having the raw number served seems a good thing if you are using juju-introspect [07:03] you can eyeball it [07:05] wallyworld: gtg get charlotte, bbs then will finish [07:09] ok [07:26] axw: and another when you are back https://github.com/juju/juju/pull/7488 [07:35] wallyworld: reviewed [07:36] ta. i was thinking clients would benefit too, but maybe not [07:36] we can restrict for now [07:36] s/clients/CLI [07:37] wallyworld: the controller *might* benefit, but the clients might also be slowed down by connecting to things that aren't known to previously be good [07:37] I think it makes sense to optimise for UX for the client [07:37] CLI [07:37] axw: maybe this needs to be config option [07:37] wallyworld: what kind of config option? [07:38] in agent.conf or something [07:38] i guess only apiservers have that though [07:38] wallyworld: I don't think it's necessary, it's only going to slow down connections a little bit [07:38] if at all [07:39] ok, i'll move to workers then [08:06] axw: the shuffle code is now in apicaller [08:06] looking === frankban|afk is now known as frankban [08:16] axw: agree about rand, but was too big a change to set it all up in the manifolds [08:16] i think it will be ok for now [08:16] wallyworld: yeah, no big deal if it's not particularly random anyway [08:16] yep [08:17] axw: going afk for a bit for dinner. if your findings today are worth sharing, can you email tim, me, john etc? even just to add some extra context to what tim might see on site tomorrow [08:18] wallyworld: I don't have anything much to share today [08:18] ok, np [08:18] hard slog through unpicking watcher code atm [08:18] bbiab [08:18] later [14:21] o/ === frankban is now known as frankban|afk [16:22] is there any juju hello world for local provider [16:23] charm? [16:23] I'd go with mediawiki-single [16:24] pogi: just juju deploy ubuntu [16:27] Can I use Ansible base with local provider any example [16:27] ansible hook [21:58] menn0: ping? [22:20] * babbageclunk goes to the doctor