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

Machinefile nonuniform install locations #23

Closed
dahlend opened this issue Mar 11, 2015 · 11 comments
Closed

Machinefile nonuniform install locations #23

dahlend opened this issue Mar 11, 2015 · 11 comments

Comments

@dahlend
Copy link

dahlend commented Mar 11, 2015

There is little documentation for the format of machinefiles (not that it is very complex).

Currently machinefiles take number of procs, host, and ssh flags only, and assumes that the install location is conserved across systems (not the case for some of my work). The only real way to solve the problem is to not use a host file. It doesn't seem unreasonable to add some sort of option to the machinefile (I could do it pretty easily after trying to track this thing down).

It's just a little more string parsing, just a "dir=" and "exename=" option.

@amitmurthy
Copy link
Contributor

Will be great to have a PR.

For starters, handling dir / exename is good - you will need to call addprocs separately for each unique dir / exename combination in client.jl.

If you are upto it, handling exeflags and sshflags would be a bonus. Note that these flags may have spaces and = symbols in them.

@dahlend
Copy link
Author

dahlend commented Mar 12, 2015

I see someone attempted this before.

JuliaLang/julia#9347

The question then comes down to an acceptable format for the machinefile

[n*] [user@]host [bind_addr][:port] [*dir=PATH] [*exename=EXE] [*exeflags=FLAGS] [*sshflags=FLAGS]

The n remaining in place to allow for backwards compatibility, no particular order to everything after, * for easy separation. Thoughts?

This means editing the SSHManager Manager and adding some additional parsing.

@dahlend
Copy link
Author

dahlend commented Mar 12, 2015

Ah yes I missed your comment about the spaces and =, I need to think about this a bit more maybe.

@rened
Copy link
Member

rened commented Mar 12, 2015

Just a thought, but what about a Dict literal?

Dict(n => 10, host => "server", username => "abc", bind_addr => ... etc)

We wouldn't need to come up with a new syntax and parser, and the literals could also be easily programmaticaly created (via repr) if necessary. You even get syntax highlighting for free! ;-)
In case parsing (simply via eval(parse(one_line))) of the file fails we could still try to see whether it is in the current (then old) format, and show a deprecation warning.

@dahlend
Copy link
Author

dahlend commented Mar 12, 2015

JuliaLang/julia#7616
JuliaLang/julia#7589

These discussions are relevant.

OpenMPI hostfile standard is limited, doesn't allow for the bells and whistles I'm suggesting.

@amitmurthy
Copy link
Contributor

Practically speaking, both exeflags and sshflags would probably be the same across all hosts. They can thus be specified individually on separate lines. exeflags and sshflags can be only global definitions.

dir and exename can be specified both globally as well as per host definition. If defined at the host level, it will override the global value for that particular line.

bind_addr can be supported as bind_addr=host:<port>. And also make bind_addr a keyword arg in ssh addprocs

@dahlend
Copy link
Author

dahlend commented Mar 13, 2015

Something along the lines of

[exeflags FLAGS]
[sshflags FLAGS]
[dir PATH]
[exename EXE]
[n*] [user@]host1 [bind_addr][:port] [*dir PATH] [*exename EXE] 
[n*] [user@]host2 [bind_addr][:port] [*dir PATH] [*exename EXE] 
...

This doesn't seem unreasonable.

@rened
Copy link
Member

rened commented Mar 13, 2015

In my setting the sshflags could easily be different for the different hosts. What about not assuming anything about what is constant, but allow to specify each and every flag at the top as default, and each host-line may override whatever it wants?
As we are changing the format because it is too inflexible, rather not impose new restrictions?

@dahlend
Copy link
Author

dahlend commented Mar 13, 2015

Ok, Now to implement...

[exeflags FLAGS]
[sshflags FLAGS]
[dir PATH]
[exename EXE]
[n*] [user@]host1 [bind_addr][:port] [*dir PATH] [*exename EXE] [*sshflags FLAGS] [*exeflags FLAGS]
[n*] [user@]host2 [bind_addr][:port] [*dir PATH] [*exename EXE] [*sshflags FLAGS] [*exeflags FLAGS]
...

Wanted a fixed format before I spent time on it.

@amitmurthy
Copy link
Contributor

How about trying to mimic Julian code syntax, as well as the addprocs call, as much as possible? For example, using backticks for exeflags and sshflags .

[exeflags=`FLAGS`]
[sshflags=`FLAGS`]
[dir="PATH"]
[exename="EXE"]
[n*] [user@]host1 [bind_addr="bind_addr[:port]"] [dir="PATH"] [exename="EXE"] [sshflags=`FLAGS`] [exeflags=`FLAGS`]
[n*] [user@]host2 [bind_addr="bind_addr[:port]"] [dir="PATH"] [exename="EXE"] [sshflags=`FLAGS`] [exeflags=`FLAGS`]
...

@vtjnash vtjnash transferred this issue from JuliaLang/julia Feb 10, 2024
@vtjnash
Copy link
Member

vtjnash commented Feb 10, 2024

I think the decision was that addprocs in a julia script is already more flexible than this would be, which makes it simpler than inventing a new format

@vtjnash vtjnash closed this as not planned Won't fix, can't repro, duplicate, stale Feb 10, 2024
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

4 participants