thumperCongruatulations on the point release01:36
pmatuliso/ thumper01:49
jamhi thumper, good to see you around01:55
thumperI'm still lurking02:29
thumperpmatulis: been dragged back to juju?02:29
flxfoohi wallyworld08:48
flxfooto let you know, the RPC problem with pylibjuju (2.8.0) is link to max_frame_size, default value is 4194304, doubling it yesterday, remove the issue.08:49
flxfoobut the issue is back this morning, to remove it again i needed to add 49696o more.08:50
flxfooI am trying to see how fast that is growing...08:50
flxfooany idea what would grow?08:50
flxfoopetevg:hi there, I did open this RPC post/ticket09:10
flxfoopetevg:as ctrl is 2.8.0, would you suggest to migrate to 2.8.2 or newer?09:11
flxfoowallyworld:does the model related fixes that you point out yesterday could be involved in the is RPC "growing" frame? if yes it would sound that I need to move to v2.8.2 or newer?09:12
wallyworldflxfoo: from what little i've seen of your issue, it does appear something is bloating the model whether due to incomplete cleanup or something else. without a lot mre info, it will be almost impossible to fully diagnose. but > 4M for get_model() seems extreme. migrating to a 2.8.2 controller might be a good option to try, but if there are orphaned entries or issues with the current model it may fail. but this is all a guess as09:41
wallyworld there's not enough to go on. i haven't got the pylibjuju code in front of me to see what get_model() is doing internally and exactly what it is querying. it's well into my evening so i win't get to look tonight09:41
flxfoowallyworld:no worries, I do not recall all details of what happened with this model, for sure add/remove model (with same name) and then apps and units (with sometime same name for apps).09:59
flxfooIt sounds that model is not in a good shape, and might be beneficial to create something fresh if possible.10:00
flxfooin any case that might be beneficial to find out why this is happening...10:00
stickupkidmanadart, I've updated the pylibjuju PR to add a test10:00
manadartstickupkid: Nice. Looks good.10:01
flxfooas a little info I gathered today, is that the first error realted to mgo-txn-resumer started from end of june... after I think removing the model and recreating the model.10:03
flxfoobb in a few minutes10:03
stickupkidflxfoo, are you able to share what type of model you have, machine/unit/app count?10:03
flxfoostickupkid:what type of data you would like?10:04
stickupkidflxfoo, well, I've just been testing with pylibjuju and not hit this, so I'd need some more steps to try and recreate it if possible10:04
stickupkidflxfoo, any sort of repro steps would be great10:05
flxfoostickupkid: there is 11 machines10:05
flxfoo13 units10:05
flxfoo7 apps10:05
flxfooapp/charms are10:05
flxfoopercona cluster10:05
flxfooand a "homemade" charm, which is more or less an nginx10:06
flxfoosorry need to move10:06
flxfoobb in a few minutes10:06
stickupkidsure, nps10:06
stickupkidflxfoo might be worth a bug so we can track it10:06
Chipacawhat could cause config-changed to run over and over?10:07
stickupkidflxfoo, essentially when we connect, we get all the data via an all watcher (it provides model information into a pylibjuju cache) and the model info. It doesn't look like model info has changed in sometime, but we may have changed how much we send for the all watcher...10:10
stickupkidlet me see what deploying kubernetes does, always a good test10:12
stickupkidso deploying `juju deploy cs:bundle/canonical-kubernetes-954` seems like it's ok to connect, I'll leave it running to see if that is the cause10:15
flxfoostickupkid:some things I do remember, is that I needed to test some charm changes, so I might have done a few upgrade-charm with force-units for sure10:32
flxfooand some changes were causing some breakage, that would be fixed on a next iteration... etc...10:32
jamChipaca, other than the hook exiting with error causing juju to retry config-changed?12:55
stickupkidanyone see this failure before FAIL: apiaddressupdater_test.go:107: APIAddressUpdaterSuite.TestAddressChange12:58
stickupkidhml, https://github.com/juju/juju/pull/1200314:06
stickupkidhml, handle the error list correctly for info responses14:06
hmlstickupkid:  lookging14:11
achilleasastickupkid: you bumped the application facade to v13 (add CharmOrigin) on develop, right?14:13
stickupkidachilleasa, yeap14:14
achilleasanice :-) less work for me then!14:14
stickupkidhml, I'm still getting empty metadata though14:19
hmlstickupkid:  added a comment on the PR - checking a few things out.14:23
stickupkidhml, https://github.com/juju/juju/pull/1200414:57
hmlstickupkid:  will look at it after lunch14:57
stickupkidhml, sure, I'm unsure if we should obliterate "upgrade-charm" from the repo and use "refresh" instead14:58
stickupkidhml, I'm open to options14:58
achilleasahml: can you take a look at https://github.com/juju/juju/pull/12005 ?15:37
hmlachilleasa:  ack, will add to my queue15:38
hmlfor toay15:38
achilleasahml: not in a hurry15:38
hmlstickupkid:  found where Update() is used… and it shouldn’t be. there are 2 different api calls to update a charm config depending on how the change is done.  :-(. https://github.com/juju/juju/blob/9a321b67d6413169caffb445399ff8a3a50f3ec8/cmd/juju/application/config.go#L41615:48
hmlshould be fixable15:49
stickupkidhml, fixed https://github.com/juju/juju/pull/1200316:04
hmlstickupkid:  HO?16:05
achilleasajam: the output of 'juju diff-bundle' looks suspiciously like a bundle even though the cli uses its own internal structures for marshaling the diff into yaml. Is the intent to be able to 'juju deploy' the diff and have it work?16:16
jamachilleasa, I don't think so (I haven't heard of requests to do something along those lines). bundles are meant to be self consistent (eg, not refer to applications that it isn't deploying)16:19
achilleasagreat, that means I don't need to mess with overlays for adding the exposed endpoints to diff-bundle (I guess there is always the export-bundle command if you want to capture the model state in a deployable way)16:20
hpidcockwallyworld: https://github.com/juju/worker/pull/1422:53
wallyworldhpidcock: lgtm with a question22:58
ec0@jam, we had discussed this many moon ago I think, I'm not sure if it ever made it to the roadmap, but being able to have a bundle that creates relations to services not in the bundle allows for easy deployment of things like logging & monitoring tools, for example22:58
hpidcockwallyworld: added a response to your question22:59
ec0for example, if you deploy OpenStack with a supported bundle, and then want to deploy the LMA stack (Nagios, Graylog, Grafana, etc), a lot of those services rely on relations to various OpenStack services, not having to duplicate those application definitions in the bundle would be nice, but given the way bundles are handled now, you thankfully can just duplicate the application names usually and have the23:00
ec0relations work, and the existing deployed apps aren't touched beyond relating to them23:00
=== ec0[m] is now known as ec0

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!