[10:10] <kjackal> hey stub I am trying to work on a fix to layer-snap
[10:10] <kjackal> is this layer on lp or gh?
[10:10] <stub> either or
[10:10] <kjackal> awesome
[10:11] <stub> lp is canonical I guess, but I accept either
[10:11] <kjackal> so I can submit a pr to gh
[10:11] <stub> yup
[10:11] <kjackal> great, thanks
[10:12] <stub> kjackal: what is the fix?
[10:12] <kjackal> has to do with no_proxy
[10:12] <stub> ok. I think newer versions of snapd have a better way of setting the proxy now too, but I haven't investigated.
[10:13] <stub> There is a branch in flight adding support for the snap-proxy too, but that doesn't touch the traditional proxy stuff.
[10:14] <kjackal> 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] <kjackal> actually it gets trimmed to 2048 and the rest of proxy settings are skipped
[10:15] <stub> https://code.launchpad.net/~adam-collard/layer-snap/+git/layer-snap/+merge/336289
[10:16] <kjackal> stub I do not think this will fix the issue, let me find the opened issue
[10:17] <kjackal> stub: https://github.com/juju-solutions/bundle-canonical-kubernetes/issues/413
[10:18] <kjackal> the no_proxy line is too long and the parsing of the snap_layer_proxy.conf stops
[10:18] <stub> No, that is a different issue. I understand it is the preferred way of accessing the snap store via proxy now
[10:18] <stub> 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] <stub> (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] <stub> 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] <kjackal> 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] <kjackal> 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] <stub> Yes. I'm just saying that I expect to stop creating systemd override files and start using snapd's proxy setting mechanism.
[10:24] <stub> 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] <kjackal> I am trying to find this snapd proxy setting that goes through snap core but dont seem to be that successful..
[10:27] <stub> 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] <stub> probably a 2.30 thing, which is the version adam needs to force for the snap-proxy support
[10:29] <kjackal> yes... but there is nothing for noproxy there
[10:30] <stub> 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] <kjackal> There is this: https://github.com/snapcore/snapd/pull/3594
[10:33] <stub> 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] <kjackal> stub, I am not sure when/why the no_proxy is needed by snapd
[10:34] <kjackal> yes, trucating it is good enough for me now
[10:35] <stub> ok.
[10:35] <kjackal> usualy in network restricted environments snapd does not need to reach other services internal
[10:35] <stub> 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] <stub> So truncate or don't propagate no_proxy at all.
[10:36] <kjackal> I would prefer to remove no_rpoxy rather than having it half in snapd config
[10:36] <stub> ok.
[10:36] <kjackal> cool, even easier
[10:37] <kjackal> doing it now, thanks
[10:39] <stub> In other news, systemd's opinion of what makes a valid environment variable is different to the OS's opinion.
[10:43] <kjackal> stub: true, especialy since it is doing this silent fail
[10:44] <kjackal> "I will skip this config and pry noonw notices" :)
[16:16] <pmatulis> 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] <rick_h> pmatulis: https://api.jujucharms.com/charmstore/v5/search?series=centos7
[16:40] <pmatulis> rick_h, thanks. so just one then? i actually tried this and it failed. some kind of image authorization problem
[16:40] <pmatulis> https://pastebin.canonical.com/208767/
[16:40] <rick_h> pmatulis: so yea, you have to sign a thing in amz to get the centos image that's used
[16:40] <rick_h> 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] <pmatulis> rick_h, i did a manual launch. i didn't see any signing option
[17:05] <zeestrat> So, any tips for recovering an unresponsive juju environment that borked itself during upgrade-juju?  https://bugs.launchpad.net/juju/+bug/1746265
[17:05] <mup> Bug #1746265: juju-upgrade from 2.2.9 to 2.3.2 fails with state changing too quickly <juju:New> <https://launchpad.net/bugs/1746265>
[18:56] <bobeo> hey everyone! I hope your day is going well!
[18:56] <bobeo> Is there a way to do: juju run --unit "select all units" "command" ; E.G. juju run --unit * ifconfig
[18:56] <bobeo> is that possible tod o with juju?
[19:06] <zeestrat> bobeo: do you want to target just units within an application or all units in a model?
[19:07] <zeestrat> juju run has --application which does the first and also --all which should do the latter
[21:05] <rick_h> 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] <wallyworld> rick_h: doing an interview atm
[21:07] <rick_h> wallyworld: rgr
[21:51] <zeestrat> Thanks rick_h. Much appreciated.
[21:53] <wallyworld> zeestrat: rick_h: if you want all units of a given application, you can do juju run --aplication foo
[21:53] <rick_h> zeestrat: I more meant his issue with the upgraded juju model during upgrade and bug #1746265
[21:53] <mup> Bug #1746265: juju-upgrade from 2.2.9 to 2.3.2 fails with state changing too quickly <juju:New> <https://launchpad.net/bugs/1746265>
[21:53] <wallyworld> but you want all units in a model? --all will do all machines
[21:53] <rick_h> wallyworld: sorry ^
[21:55] <wallyworld> rick_h: oh, i see. i don't have any clue off hand. i'll need to look into it
[21:55] <rick_h> 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.