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

Mount the PyFluent working directory to Docker containers by default #2867

Closed
raph-luc opened this issue May 24, 2024 · 3 comments · Fixed by #2874
Closed

Mount the PyFluent working directory to Docker containers by default #2867

raph-luc opened this issue May 24, 2024 · 3 comments · Fixed by #2874
Assignees
Labels
discussion enhancement New feature or request. Feature work invariably requires testing-team involvement

Comments

@raph-luc
Copy link
Member

Ever since #359 we have been working with Fluent containers mounted to pyfluent.EXAMPLES_PATH in the host system. This was apparently fine as until recently, PyFluent with Fluent containers was mainly being used for the PyFluent CI and not many people external to the PyFluent team were using PyFluent with Fluent containers as well.

Evidently, as seen in the recent uptick in user questions and bug reports related to Fluent containers, more and more people are using PyFluent with Fluent containers.

I do not believe that mounting the pyfluent.EXAMPLES_PATH to the Fluent container by default is useful or intuitive to users. I would suggest that this be reconsidered, and changed so that the current PyFluent working directory is mounted to the Fluent container working directory. In this way, both PyFluent and Fluent would be working in the exact same working directory (though each one sees it with a different absolute path). Note that currently PyFluent launches standalone Fluent by default also in the current PyFluent working directory, so this would mean the docker and standalone launchers would have behavior that is more similar to each other.

For the CI, I believe this means changes would also need to be made to the examples.download_file() method to make things seamless, as it is currently downloading to pyfluent.EXAMPLES_PATH by default, and it should then download to the current working directory (which is also more intuitive IMO).

This would also break scripts from the users that may already be relying on this (odd) behavior of PyFluent mounting containers to the absolute path of pyfluent.EXAMPLES_PATH (and downloading example files to there as well).

Overall, I believe this would be a lot more intuitive to users. This change, with the changes for #2865, should make using PyFluent with Fluent containers a lot more user friendly.

In addition, making the example configuring launch_fluent() with host_mount_path more prominent would probably also be helpful (maybe adding more examples like that as well, now that Fluent containers seems to be a more common use-case).

@mkundu1 @hpohekar @prmukherj @seanpearsonuk

@raph-luc raph-luc added enhancement New feature or request. Feature work invariably requires testing-team involvement discussion labels May 24, 2024
@mkundu1
Copy link
Contributor

mkundu1 commented May 24, 2024

Very good point, synchronizing the working directory will give a more intuitive behaviour. And if we make the default mount path configurable, we don't have to make much adjustments for the CIs.

@seanpearsonuk
Copy link
Collaborator

@raph-luc @mkundu1 @prmukherj @hpohekar I feel that it is important to expedite this work. Any of you may self-assign.

@raph-luc
Copy link
Member Author

raph-luc commented Jun 3, 2024

Similar to the requests by Martijn Hoeijmakers, an idea is to consider automatically processing paths when we notice that they are specified using the host's absolute file path system, to transform them into the absolute paths as appropriate for Fluent running inside the container. I think we should create a separate issue tracker for that, but just wanted to share this idea here as it is relevant to this topic.

If we decide to go ahead with something like this, we'd probably be using an infrastructure similar to that of the file transfer service we have. I think this would possibly be like an extension to that service.

Edit: moved to #2903

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion enhancement New feature or request. Feature work invariably requires testing-team involvement
Projects
Status: 2021-2024
Development

Successfully merging a pull request may close this issue.

4 participants