Skip to content
This repository has been archived by the owner on Jun 20, 2024. It is now read-only.

Enabling TLS removes proxy from weave status output #876

Closed
paulbellamy opened this issue Jun 8, 2015 · 6 comments
Closed

Enabling TLS removes proxy from weave status output #876

paulbellamy opened this issue Jun 8, 2015 · 6 comments
Labels
bug [component/proxy]
Milestone
1.0.0

Comments

@paulbellamy
Copy link
Contributor

Because curl cannot connect to the proxy over TLS.
@rade rade added this to the next milestone Jun 8, 2015
@paulbellamy
Copy link
Contributor Author

I'm not really sure the best way to fix this. We could:
A) Have a separate port (or unix socket) for status queries.
B) Get the certs from the proxy and configure curl with them.

@paulbellamy
Copy link
Contributor Author

I'm leaning towards having a unix socket for status queries.

@rade
Copy link
Member

rade commented Jun 8, 2015

Let's just ditch the proxy from weave status.

@rade rade mentioned this issue Jun 8, 2015
Closed
@rade
Copy link
Member

rade commented Jun 8, 2015

Umm. how does launch-proxy work? It calls wait_for_status_ip, which in turn calls http_call_ip, just like weave status.

rade added a commit to rade/weave that referenced this issue Jun 8, 2015
@rade
remove proxy status
3dd679c 
There are two problems with obtaining the proxy status via the normal
proxy endpoint...

1. when TLS is enabled, this requires using TLS at the client end

2. the status URL is mixed in with the docker remote API, which is
rather unclean

There is limited value to having some status output from the proxy,
since all the output is constant.

So instead we log the version and command line args.

We still want a way to wait for the proxy to start up, and log a nice
error if it dies. We do this by polling the docker logs for a startup
message.

Fixes weaveworks#877. Fixes weaveworks#876.

Undoes weaveworks#756, weaveworks#800, weaveworks#854.
@rade rade mentioned this issue Jun 8, 2015
Merged
@rade
Copy link
Member

rade commented Jun 8, 2015

how does launch-proxy work?

I'm guessing it 'works' because it can establish a connection, post something, and receive some tls nonsense.

I'm leaning towards having a unix socket for status queries.

Speaking to unix sockets from the command line is a pain. There is no single, widely installed command for it. And status is a rather important command, so we want it to work with weave --local w/o users having to install exotic packages.

We could listen on 127.0.0.1:some_port, but listening on a fixed port is problematic, and making it configurable is a pain.

rade added a commit to rade/weave that referenced this issue Jun 9, 2015
@rade
remove proxy status
1fb2115 
There are two problems with obtaining the proxy status via the normal
proxy endpoint...

1. when TLS is enabled, this requires using TLS at the client end

2. the status URL is mixed in with the docker remote API, which is
rather unclean

There is limited value to having some status output from the proxy,
since all the output is constant.

So instead we log the version and command line args.

We still want a way to wait for the proxy to start up, and log a nice
error if it dies. We do this by polling the docker logs for a startup
message.

Fixes weaveworks#877. Fixes weaveworks#876.

Undoes weaveworks#756, weaveworks#800, weaveworks#854.
rade added a commit to rade/weave that referenced this issue Jun 9, 2015
@rade
remove proxy status
6e30c9c 
There are two problems with obtaining the proxy status via the normal
proxy endpoint...

1. when TLS is enabled, this requires using TLS at the client end

2. the status URL is mixed in with the docker remote API, which is
rather unclean

There is limited value to having some status output from the proxy,
since all the output is constant.

So instead we log the version and command line args.

We still want a way to wait for the proxy to start up, and log a nice
error if it dies. We do this by polling the docker logs for a startup
message.

Fixes weaveworks#877. Fixes weaveworks#876.

Undoes weaveworks#756, weaveworks#800, weaveworks#854.
@paulbellamy
Copy link
Contributor Author

Yep. The http_call_ip doesn't care what the response says, just that it can connect.

rade added a commit to rade/weave that referenced this issue Jun 9, 2015
@rade
remove proxy status
19a13c6 
There are two problems with obtaining the proxy status via the normal
proxy endpoint...

1. when TLS is enabled, this requires using TLS at the client end

2. the status URL is mixed in with the docker remote API, which is
rather unclean

There is limited value to having some status output from the proxy,
since all the output is constant.

So instead we log the version and command line args.

We still want a way to wait for the proxy to start up, and log a nice
error if it dies. We do this by polling the docker logs for a startup
message.

Fixes weaveworks#877. Fixes weaveworks#876.

Undoes weaveworks#756, weaveworks#800, weaveworks#854.
rade added a commit to rade/weave that referenced this issue Jun 9, 2015
@rade
remove detailed proxy status
989be4a 
There are two problems with obtaining the proxy status via the normal
proxy endpoint...

1. when TLS is enabled, this requires using TLS at the client end

2. the status URL is mixed in with the docker remote API, which is
rather unclean

There is limited value to having some status output from the proxy,
since all the output is constant.

So instead we log the version and command line args, and in `weave
status` only report whether the proxy is running.

We still want a way to wait for the proxy to start up, and log a nice
error if it dies. We do this by polling the docker logs for a startup
message.

Fixes weaveworks#877. Fixes weaveworks#876.

Undoes most of weaveworks#756, weaveworks#800, weaveworks#854.
rade added a commit to rade/weave that referenced this issue Jun 9, 2015
@rade
remove detailed proxy status
fee2898 
There are two problems with obtaining the proxy status via the normal
proxy endpoint...

1. when TLS is enabled, this requires using TLS at the client end

2. the status URL is mixed in with the docker remote API, which is
rather unclean

There is limited value to having some status output from the proxy,
since all the output is constant.

So instead we log the version and command line args, and in `weave
status` only report whether the proxy is running.

We still want a way to wait for the proxy to start up, and log a nice
error if it dies. We do this by polling the docker logs for a startup
message.

Fixes weaveworks#877. Fixes weaveworks#876.

Undoes most of weaveworks#756, weaveworks#800, weaveworks#854.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
bug [component/proxy]
Projects
None yet
Milestone
1.0.0
Development

No branches or pull requests
2 participants
@rade @paulbellamy