| === frankban|afk is now known as frankban | ||
| 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:10 |
| 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:11 |
| 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:12 |
| stub | There is a branch in flight adding support for the snap-proxy too, but that doesn't touch the traditional proxy stuff. | 10:13 |
| 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:14 |
| 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:15 |
| kjackal | stub I do not think this will fix the issue, let me find the opened issue | 10:16 |
| kjackal | stub: https://github.com/juju-solutions/bundle-canonical-kubernetes/issues/413 | 10:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:24 |
| 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:27 |
| stub | probably a 2.30 thing, which is the version adam needs to force for the snap-proxy support | 10:28 |
| kjackal | yes... but there is nothing for noproxy there | 10:29 |
| 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:30 |
| kjackal | There is this: https://github.com/snapcore/snapd/pull/3594 | 10:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| kjackal | doing it now, thanks | 10:37 |
| stub | In other news, systemd's opinion of what makes a valid environment variable is different to the OS's opinion. | 10:39 |
| kjackal | stub: true, especialy since it is doing this silent fail | 10:43 |
| kjackal | "I will skip this config and pry noonw notices" :) | 10:44 |
| 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:16 |
| rick_h | pmatulis: https://api.jujucharms.com/charmstore/v5/search?series=centos7 | 16:31 |
| 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:40 |
| pmatulis | rick_h, i did a manual launch. i didn't see any signing option | 16:41 |
| 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> | 17:05 |
| === frankban is now known as frankban|afk | ||
| 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? | 18:56 |
| zeestrat | bobeo: do you want to target just units within an application or all units in a model? | 19:06 |
| zeestrat | juju run has --application which does the first and also --all which should do the latter | 19:07 |
| 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:05 |
| wallyworld | rick_h: doing an interview atm | 21:07 |
| rick_h | wallyworld: rgr | 21:07 |
| zeestrat | Thanks rick_h. Much appreciated. | 21:51 |
| 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:53 |
| 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. | 21:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!