Comment 5 for bug 1439447

Revision history for this message
David Britton (dpb) wrote : Re: [Bug 1439447] Re: tools download in cloud-init should not go through http[s]_proxy

On Fri, Apr 03, 2015 at 03:24:33PM -0000, Cheryl Jennings wrote:
> I talked with Eric about this and we had a couple thoughts:
>
> 1 - If the user goes through the trouble to specify an http proxy, I'm
> not sure it's appropriate for juju to "override" that setting, even for
> the bootstrap node. It should be up to the user to set up the proxy to
> handle private addresses. I believe this was Nate's thought on this
> too.
>

In this particular case (getting tools from the bootstrap node), I'm
not sure what you have said makes sense.

1) An http proxy is generally (in every case I've seen) configured and
set up for talking to external networks. Not for proxying traffic on
the local subnet. That would seem like a weird use case to me -- not
something to optimize for. It would unecessarily create traffic on the
local net, and bottleneck on a proxy server for no real technical
benefit.

2) At least with openstack, and the way that Canonical is recommending
installing it, the addresses that is being tried here is the nodes
internal address. Those IPs are not routable outside of the neutron
network. Of course as a network admin you could do all kinds of things
to make those addresses routable, but by default they are not.

3) Theoretically speaking, even if juju were trying the bootstrap node's
externally reachable address, I would need to reconfigure the proxy
server -- which I don't have access to, it's a corporate controlled
thing, and getting them to add my local ip range to that server also
feels weird. If I were a network admin, I would probably not go for
that. I'm thinking they would tell me: "The proxy server exists to let
me reach the internet. Not to cache local network traffic."

4) I'm not a network admin, so this is just how I've used proxy servers
in the past. Might be good to ask someone in the know about this, like
elmo. I *do* at least know that the address you are trying for the
bootstrap node will not work to proxy as it's internal to the cloud
(point #2).

> 2 - If we decide that we want juju to override the proxy settings for
> the bootstrap node, it might be better to add it to the no_proxy list so
> that any future communication to the bootstrap node that happens doesn't
> also run into this problem.

I think adding internal ip addresses to no_proxy is a valid approach,
however I would caution about what happens if they change. Especially
with HA state, and those being able to move. I really don't know, but
it's what was in the back of my head when I called it "flaky" in the
original request.

--
David Britton <email address hidden>