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

Supply config at runtime #259

Open
Nintorac opened this issue Mar 4, 2022 · 3 comments
Open

Supply config at runtime #259

Nintorac opened this issue Mar 4, 2022 · 3 comments
Assignees
Labels
enhancement New feature or request

Comments

@Nintorac
Copy link
Contributor

Nintorac commented Mar 4, 2022

It would be useful to allow specifying configuration files to use at runtime.

The use case I have in mind here is to help with hyperparameter tuning. I want to be able to dynamically generate configurations in a script and then send those directly via the APIRunner API, eg something like

client = FLAdminAPIRunner(
    host = SERVER,
    port = 8003,
    poc = True,
    username="admin",
    admin_dir=os.environ.get('ADMIN_DIR', '/admin')
)

for i, config in enumerate(config_generator):
    client.run(i, APP_NAME, config, restart_all_first=False, shutdown_at_end=False, shutdown_on_error=False)

This could also be useful even for one off experiments as it would allow the use of config management libs (eg hydra).

The closest example I could find is in the cifar example where each app folder only contains the config, I couldn't follow where the app code is actually copied over though.

I think this approach might help to define a differentiation between a run and an app. eg a run is an app + config

@holgerroth holgerroth added the enhancement New feature or request label Mar 7, 2022
@yanchengnv
Copy link
Collaborator

We are redesigning the whole RUN management system to make it more like "job scheduling". Basically you will be able to create jobs (app configs) either statically or dynamically, and then upload them to the system. It is up to the system to schedule and run these jobs one by one or in parallel (if resources permit). Once a job is submitted, you will get a unique Job ID (JID), and you can use this JID to query or cancel the job.

In your example, the "config_generator" will need to be able to dynamically generate the job configs in file system, and then upload the generated jobs to the system via the API.

@Nintorac
Copy link
Contributor Author

Nintorac commented Mar 9, 2022

We are redesigning the whole RUN management system

Cool, do you have any docs on the plans that I could look at?

In your example, the "config_generator" will need to be able to dynamically generate the job configs in file system, and then upload the generated jobs to the system via the API.

Yes this is what I'm doing. It just feels a little clunky. eg what is the difference between an app and a run atm? ---but if I understand your first paragraph correctly that this will be deprecated then cool :)

@pdogra89
Copy link

pdogra89 commented Mar 9, 2022

@Nintorac - Thank you for your interest and contributions to Nvidia FLARE - I am Prerna and I am responsible for Product Management. I would like to get on a call with you to learn about your use-case and understand how we can help - please feel free to email me at [email protected] and we can take it from there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

6 participants