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

Remove weave launch-dns and weave stop-dns #840

Closed
awh opened this issue Jun 3, 2015 · 2 comments
Closed

Remove weave launch-dns and weave stop-dns #840

awh opened this issue Jun 3, 2015 · 2 comments

Comments

@awh
Copy link
Contributor

awh commented Jun 3, 2015

  • Remove weave launch-dns and weave stop-dns
  • Add --dns <cidr> option to weave launch that starts weaveDNS if specified

Requires changes to script, tests, docs.

@awh awh changed the title Deprecate weave launch-dns and weave stop-dns Remove weave launch-dns and weave stop-dns Jun 3, 2015
@rade rade mentioned this issue Jun 3, 2015
4 tasks
@rade rade modified the milestone: next Jun 3, 2015
@rade
Copy link
Member

rade commented Jun 6, 2015

One challenge here is what to do with all the DNS options; the script needs to somehow recognise them so it can pass them to weavedns and not weaver.

Suggestion: prefix all DNS options with dns-. The prefix would be stripped by the script, so weavedns would see its current, non-prefixed options.

And perhaps the CIDR should be supplied with dns-net <cidr>.

Another thing to figure out is error handling...

  • What should happen when one (but not the other) of weave or weavedns is already running? This normally shouldn't happen, in this new scheme, since both should be started and stopped together. But of course one of them may have died, or the user started one of them in some exotic way. I reckon we should not start the other, report "already running" and exit with an error. Other options: a) start the other but still exit with an error (weird), b) start the other but don't exit with an error (dangerous since the supplied options may be completely different to what is running, and imo success should mean 'launched with the supplied options'), c) kill the running one and then start both (surprising, imo, to kill something in 'launch').
  • Similar considerations apply to stop. We should stop whichever is running, report a "not running" for the other, and exit successfully (stop is idempotent).
  • What should happen when starting one fails? I reckon we should kill the other and exit with an error.

@rade rade modified the milestone: next Jun 8, 2015
@rade
Copy link
Member

rade commented Jun 18, 2015

Replaced by #962.

@rade rade closed this as completed Jun 18, 2015
@rade rade added this to the n/a milestone Jun 18, 2015
marccarre added a commit that referenced this issue Jan 9, 2017
Reason: test is periodically failing because of the timeout being too aggressive, especially when using Google Cloud Platform together with Terraform and Ansible.
marccarre added a commit that referenced this issue Jan 9, 2017
Reason: test is periodically failing because of the timeout being too aggressive, especially when using Google Cloud Platform together with Terraform and Ansible.
marccarre added a commit that referenced this issue Jan 9, 2017
Reason: test is periodically failing because of the timeout being too aggressive, especially when using Google Cloud Platform together with Terraform and Ansible.
marccarre added a commit that referenced this issue Jan 10, 2017
Reason: test is periodically failing because of the timeout being too aggressive, especially when using Google Cloud Platform together with Terraform and Ansible.
marccarre added a commit that referenced this issue Jan 10, 2017
Reason: test is periodically failing because of the timeout being too aggressive, especially when using Google Cloud Platform together with Terraform and Ansible.
marccarre added a commit that referenced this issue Jan 10, 2017
Reason: test is periodically failing because of the timeout being too aggressive, especially when using Google Cloud Platform together with Terraform and Ansible.
marccarre added a commit that referenced this issue Jan 17, 2017
Reason: test is periodically failing because of the timeout being too aggressive, especially when using Google Cloud Platform together with Terraform and Ansible.
marccarre added a commit that referenced this issue Jan 17, 2017
Reason: test is periodically failing because of the timeout being too aggressive, especially when using Google Cloud Platform together with Terraform and Ansible.
marccarre added a commit that referenced this issue Jan 17, 2017
Reason: test is periodically failing because of the timeout being too aggressive, especially when using Google Cloud Platform together with Terraform and Ansible.
marccarre added a commit that referenced this issue Jan 20, 2017
Reason: test is periodically failing because of the timeout being too aggressive, especially when using Google Cloud Platform together with Terraform and Ansible.
marccarre added a commit that referenced this issue Jan 23, 2017
Reason: test is periodically failing because of the timeout being too aggressive, especially when using Google Cloud Platform together with Terraform and Ansible.
marccarre added a commit that referenced this issue Jan 23, 2017
Reason: test is periodically failing because of the timeout being too aggressive, especially when using Google Cloud Platform together with Terraform and Ansible.
marccarre added a commit that referenced this issue Jan 26, 2017
Reason: test is periodically failing because of the timeout being too aggressive, especially when using Google Cloud Platform together with Terraform and Ansible.
marccarre added a commit that referenced this issue Jan 26, 2017
Reason: test is periodically failing because of the timeout being too aggressive, especially when using Google Cloud Platform together with Terraform and Ansible.
marccarre added a commit that referenced this issue Jan 30, 2017
Reason: test is periodically failing because of the timeout being too aggressive, especially when using Google Cloud Platform together with Terraform and Ansible.
marccarre added a commit that referenced this issue Jan 30, 2017
Reason: test is periodically failing because of the timeout being too aggressive, especially when using Google Cloud Platform together with Terraform and Ansible.
marccarre added a commit that referenced this issue Jan 31, 2017
Reason: test is periodically failing because of the timeout being too aggressive, especially when using Google Cloud Platform together with Terraform and Ansible.
marccarre added a commit that referenced this issue Feb 1, 2017
Reason: test is periodically failing because of the timeout being too aggressive, especially when using Google Cloud Platform together with Terraform and Ansible.
marccarre added a commit that referenced this issue Feb 1, 2017
Reason: test is periodically failing because of the timeout being too aggressive, especially when using Google Cloud Platform together with Terraform and Ansible.
marccarre added a commit that referenced this issue Feb 6, 2017
Reason: test is periodically failing because of the timeout being too aggressive, especially when using Google Cloud Platform together with Terraform and Ansible.
marccarre added a commit that referenced this issue Feb 8, 2017
Reason: test is periodically failing because of the timeout being too aggressive, especially when using Google Cloud Platform together with Terraform and Ansible.
marccarre added a commit that referenced this issue May 8, 2017
marccarre added a commit that referenced this issue May 8, 2017
marccarre added a commit that referenced this issue May 8, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants