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

Improved API and clush Worker selection #421

Open
thiell opened this issue Sep 30, 2019 · 5 comments
Open

Improved API and clush Worker selection #421

thiell opened this issue Sep 30, 2019 · 5 comments
Milestone

Comments

@thiell
Copy link
Collaborator

thiell commented Sep 30, 2019

Currently, there is a mismatch between the API (eg. local/distant worker selection) and the options offered by clush. It's not great. The API could be improved for a better worker selection: at the moment task.shell() offers options like tree=None|False|True and remote=False|True but not a direct worker selection, so it's not easy for clush itself simply to control the worker selection in command line.

From an end-user point of view, it would be great to allow something as simple as this:

  • clush --worker=tree
  • clush --worker=ssh
  • clush --worker=exec

But it's not that simple. First, note that --worker=tree is not recognized at the moment. Also the Tree worker is used only if topology.conf is available (otherwise, it's useless). Then, there is a notion of local and distant worker that can be used by the tree worker (depending on remote=yes|no).

Note that clush --worker=ssh should definitely be a way to disable the tree mode, but this doesn't work, so I'm going to submit a patch for this.

@thiell thiell added this to the 1.9 milestone Sep 30, 2019
@thiell
Copy link
Collaborator Author

thiell commented Sep 30, 2019

Also related to #291

thiell added a commit that referenced this issue Oct 6, 2019
A way to disable the tree mode is to use --worker=ssh. This is
currently broken and this patch fixes it. But this is a quick
fix until we rework the API for worker selection (#421).

Closes #386.

Change-Id: I969ebfb453bddef0e845f6668642b4016838014b
@mattaezell
Copy link
Contributor

I think that most end users (those who invoke clush directly) only care about what the last worker (distant worker) actually is. That is, I might like to say --worker=ssh or --worker=rsh and not care if it uses the tree topology or not (default to use the tree if topology.conf exists even if --worker=rsh).

@degremont
Copy link
Collaborator

That's a very interesting comment. We don't have enough feedback on that part as I was always working in environment where ssh was the official way to connect to any node.

I can understand that some other environments/clusters uses mrsh or other tools as the main way to connect and execute remote commands on other nodes. In that case, I can imagine that the way to reach Gateways should be the same than the way to reach last nodes from the gateways themselves.
Is your setup different?

@mattaezell
Copy link
Contributor

In that case, I can imagine that the way to reach Gateways should be the same than the way to reach last nodes from the gateways themselves.
Is your setup different?

No, but that's not really what I'm talking about.

The fact that tree mode is implemented as a worker is an implementation detail that is not obvious/relevant for the casual end-user. The questions "should I use gateway nodes" and "what protocol do I use to talk to the end node" don't necessarily need to be related.

Note that clush --worker=ssh should definitely be a way to disable the tree mode, but this doesn't work, so I'm going to submit a patch for this.

This doesn't seem obvious to me. I think that something like clush --worker=ssh --tree=true should be valid.

@degremont
Copy link
Collaborator

There is likely room for improvements in this area.

That's not easy to manage all possible use cases and keep that simple enough for sysadmins. Your case is even adding a new use case where you want to control the worker selection on the final gateways.

@thiell thiell modified the milestones: 1.9, 2.0 Jun 26, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants