Michael,

I am not sure writing to /etc/environment is the right thing to do in all cases.

After working with isolated environments for some time I am more inclined to giving as much granularity as possible because there are distinct use-cases:

1) proxy servers for package-management purposes or image downloads only (snapd, apt, lxd, MAAS, Juju tools etc.);
2) application-specific proxy server configuration (either explicit options in software or drop-in unit files);
3) global proxy server settings for all applications.

OpenStack is a good example because it has http services and can easily hit no_proxy stack memory scalability issues.

- most of the OpenStack services expose an HTTP API;
- some OpenStack services talk to each other by utilizing those HTTP APIs (e.g. Keystone);
- if you use a proxy server to install packages or get cloud images for MAAS or LXD it doesn't mean http clients of deployed services should use http(s)_proxy and no_proxy variables. However, they will try to if /etc/environment will be used.

I think there should be two sets of core options:

* snap-global proxy settings - all snaps should get those variables, not the whole system because the setting is quite significant for a classic system;
  - this might get messy because classic snaps on a classic system do not get a separate mount namespace AFAIR, and hence would read /etc/environment directly from rootfs which we wouldn't be able to control separately;
* snapd-specific proxy settings (searching for snaps, snap downloads and other daemon-specific operations only).
  - this would potentially affect an ability to access the enterprise snap store. I would assume that if you specify this option and a snap store one, accessing a local snap store would go through that proxy server (it's a strange but valid scenario).

Maybe snap-specific options could also be implemented for cases where a snap author has not provided their own - haven't looked deep enough but if snapcraft.yaml allows to declare daemons then creating drop-in directories automatically might be possible. If an application runtime or a library parses those options then it would allow granular control.

I think that using Environment or EnvironmentFile directives on a per-service basis is something to utilize here for snapd-related operations (the config I used in the original description):

https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Description
"Along with a unit file foo.service, a "drop-in" directory foo.service.d/ may exist."
https://www.freedesktop.org/software/systemd/man/systemd.exec.html#Environment
https://www.freedesktop.org/software/systemd/man/systemd.exec.html#EnvironmentFile=

What I am trying to avoid is using a global setting for everything that would require passing a huge blob for no_proxy in case of large subnets. Deployed services would normally need to talk to each other in an isolated environment which would not require any proxy configuration at all so we need to separate out package delivery options from the rest of the configuration.

To sum up: using proxy settings *only* for artifact retrieval (packages and images downloads) is the main field use-case I am targeting.