Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Badly named commandline argument --host #1467

Closed
lhupfeldt opened this issue Jul 4, 2020 · 8 comments
Closed

Badly named commandline argument --host #1467

lhupfeldt opened this issue Jul 4, 2020 · 8 comments
Labels
feature request non-critical stale Issue had no activity. Might still be worth fixing, but dont expect someone else to fix it

Comments

@lhupfeldt
Copy link
Contributor

The host argument is confusing and misleading.

  1. What host? There are multiple host involved, the master, the slaves and the host running the application to be tested.
  2. The value is a URL not a hostname!

Better names would be --url, --url-to-test or --test-url, dependig on how verbose you want to be.

@cyberw
Copy link
Collaborator

cyberw commented Jul 4, 2020

Kind of relates to #1262

@cyberw
Copy link
Collaborator

cyberw commented Jul 4, 2020

It would make sense to change it to url (but then we'd need to fix the issues linked, because url kind of implies that you should be able to specify more than just protocol:host, which is currently not the case)

@lhupfeldt
Copy link
Contributor Author

Maybe this is just target. Maybe it is not actually always a URL, e.g. if you are not doing HTTP test. I do think host is misleading, and it is also unfortunate that LOCUST_HOST means the test system, even if you are supposed to mentally strip the LOCUST_ from the environment variable.

@heyman
Copy link
Member

heyman commented Jul 9, 2020

I agree that it's not a very good name, and I think target is better. When/if we change this, I think we should make both options work with a deprecation warning for a few versions before we completely remove --host just to avoid breaking stuff for people.

@mezhaka
Copy link

mezhaka commented Oct 28, 2020

The docs mention the host option:

-H HOST, --host HOST Host to load test in the following format:
http://10.21.32.33

If this is the same thing discussed here, i.e., host actually implies the target of the test (the app under test), than does it mean that the example of docker-compose.yml for testing with multiple workers (below) should be setting --master-bind-host http://master:8089 instead of -H http://master:8089:

version: '3'

services:
  master:
    image: locustio/locust
    ports:
     - "8089:8089"
    volumes:
      - ./:/mnt/locust
    command: -f /mnt/locust/locustfile.py --master -H http://master:8089
  
  worker:
    image: locustio/locust
    volumes:
      - ./:/mnt/locust
    command: -f /mnt/locust/locustfile.py --worker --master-host master

I tried to replace master with my localhost (below) and it results in workers not being able to connect to the master:

version: '3'

services:
  master:
    image: locustio/locust
    ports:
     - "8089:8089"
    volumes:
      - ./:/mnt/locust
    command: -f /mnt/locust/locustfile.py --master -H http://127.0.0.1:8089

  worker:
    image: locustio/locust
    volumes:
      - ./:/mnt/locust
    command: -f /mnt/locust/locustfile.py --worker --master-host 127.0.0.1

@mezhaka
Copy link

mezhaka commented Oct 28, 2020

I have realized a few things about the way docker-compose works -- the names of the services can be used as DNS. With this knowledge the question would be a bit different and consist of two parts:

  1. If -H denotes the service to be tested, then shouldn't the example in the docs be something like:
services:
  web:
     image: myservice
     ports:
      - "8000:8000"
  master:
    image: locustio/locust
    ports:
      - "8089:8089"
    volumes:
      - ./:/mnt/locust
    command: -f /mnt/locust/locustfile.py --master -H http://web:8000
  worker:
    image: locustio/locust
    volumes:
      - ./:/mnt/locust
    command: -f /mnt/locust/locustfile.py --worker --master-host master
  1. Is there a way to docker-compose original example, and run my service outside of the docker-compose context. and point the workers to it (i.e. not adding my service to the compose file as in 1.)?

@github-actions
Copy link

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 10 days.

@github-actions github-actions bot added the stale Issue had no activity. Might still be worth fixing, but dont expect someone else to fix it label Apr 11, 2021
@github-actions
Copy link

This issue was closed because it has been stalled for 10 days with no activity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request non-critical stale Issue had no activity. Might still be worth fixing, but dont expect someone else to fix it
Projects
None yet
Development

No branches or pull requests

4 participants