=== frankban|afk is now known as frankban [10:10] hey stub I am trying to work on a fix to layer-snap [10:10] is this layer on lp or gh? [10:10] either or [10:10] awesome [10:11] lp is canonical I guess, but I accept either [10:11] so I can submit a pr to gh [10:11] yup [10:11] great, thanks [10:12] kjackal: what is the fix? [10:12] has to do with no_proxy [10:12] ok. I think newer versions of snapd have a better way of setting the proxy now too, but I haven't investigated. [10:13] There is a branch in flight adding support for the snap-proxy too, but that doesn't touch the traditional proxy stuff. [10:14] remember how the snap layer gets the no_proxy settings from juju (I guess) and then places them to /etc/systemd/system/snapd.service.d/snap_layer_proxy.conf . There is the case where no_proxy settings have a sull subnet and this large string is larger than 2048 chars so it gets skipped [10:15] actually it gets trimmed to 2048 and the rest of proxy settings are skipped [10:15] https://code.launchpad.net/~adam-collard/layer-snap/+git/layer-snap/+merge/336289 [10:16] stub I do not think this will fix the issue, let me find the opened issue [10:17] stub: https://github.com/juju-solutions/bundle-canonical-kubernetes/issues/413 [10:18] the no_proxy line is too long and the parsing of the snap_layer_proxy.conf stops [10:18] No, that is a different issue. I understand it is the preferred way of accessing the snap store via proxy now [10:18] It does include the 'snap set core' command down the bottom, which I think is similar to the blessed way of setting http proxies [10:19] (so rather than create a systemd override file, with the 2048k limit, it might be possible to run 'snap set core proxy.something=' and make it snapd's problem [10:20] But I don't know where the core settings are documented, nor do I know if the setting has been backported to Trusty yet. [10:21] my problem is not with the proxy, it is with no_proxy we grab here: https://github.com/stub42/layer-snap/blob/master/reactive/snap.py#L112 [10:22] I was thinking we could have a no_proxy config variable and not get the full list from hwatever juju model-config has [10:22] Yes. I'm just saying that I expect to stop creating systemd override files and start using snapd's proxy setting mechanism. [10:24] I'd like to avoid new config items, as it pollutes every snap built with the layer. Insanely large no_proxy lists is not a common problem, so I'd like a less intrusive fix. [10:27] I am trying to find this snapd proxy setting that goes through snap core but dont seem to be that successful.. [10:27] It isn't documented at https://docs.ubuntu.com/core/en/reference/core-configuration , so it is either very new or yay documentation [10:28] probably a 2.30 thing, which is the version adam needs to force for the snap-proxy support [10:29] yes... but there is nothing for noproxy there [10:30] ok, might be the case. The bug requesting actual proxy settings is still open (I don't consider the systemd override approach a particularly stable workaround) [10:32] There is this: https://github.com/snapcore/snapd/pull/3594 [10:33] kjackal: Would it be good enough for the snap layer to truncate the NO_PROXY environment variable before stuffing it in the systemd override file? [10:34] stub, I am not sure when/why the no_proxy is needed by snapd [10:34] yes, trucating it is good enough for me now [10:35] ok. [10:35] usualy in network restricted environments snapd does not need to reach other services internal [10:35] I'm not aware of anyone who needs no_proxy. I just pulled it from the environment with the other env variables because it seemed like a good idea at the time. [10:36] So truncate or don't propagate no_proxy at all. [10:36] I would prefer to remove no_rpoxy rather than having it half in snapd config [10:36] ok. [10:36] cool, even easier [10:37] doing it now, thanks [10:39] In other news, systemd's opinion of what makes a valid environment variable is different to the OS's opinion. [10:43] stub: true, especialy since it is doing this silent fail [10:44] "I will skip this config and pry noonw notices" :) [16:16] i heard there are CentOS-based charms in the store but this comes back empty: https://jujucharms.com/q/centos - how do i find these charms? [16:31] pmatulis: https://api.jujucharms.com/charmstore/v5/search?series=centos7 [16:40] rick_h, thanks. so just one then? i actually tried this and it failed. some kind of image authorization problem [16:40] https://pastebin.canonical.com/208767/ [16:40] pmatulis: so yea, you have to sign a thing in amz to get the centos image that's used [16:40] pmatulis: it's something I did a long time ago tbh, and appears to only be one atm. We always wanted/hoped for me [16:41] rick_h, i did a manual launch. i didn't see any signing option [17:05] So, any tips for recovering an unresponsive juju environment that borked itself during upgrade-juju? https://bugs.launchpad.net/juju/+bug/1746265 [17:05] Bug #1746265: juju-upgrade from 2.2.9 to 2.3.2 fails with state changing too quickly === frankban is now known as frankban|afk [18:56] hey everyone! I hope your day is going well! [18:56] Is there a way to do: juju run --unit "select all units" "command" ; E.G. juju run --unit * ifconfig [18:56] is that possible tod o with juju? [19:06] bobeo: do you want to target just units within an application or all units in a model? [19:07] juju run has --application which does the first and also --all which should do the latter [21:05] wallyworld: do we have anyone that can look at zeestrat's issue there? I recall some chatter around that but I don't know the results/etc exactly [21:07] rick_h: doing an interview atm [21:07] wallyworld: rgr [21:51] Thanks rick_h. Much appreciated. [21:53] zeestrat: rick_h: if you want all units of a given application, you can do juju run --aplication foo [21:53] zeestrat: I more meant his issue with the upgraded juju model during upgrade and bug #1746265 [21:53] Bug #1746265: juju-upgrade from 2.2.9 to 2.3.2 fails with state changing too quickly [21:53] but you want all units in a model? --all will do all machines [21:53] wallyworld: sorry ^ [21:55] rick_h: oh, i see. i don't have any clue off hand. i'll need to look into it [21:55] wallyworld: ok sorry, the error there rang a bell but I couldn't find what I thought I'd seen go by in conversations before.