Expose loaded config files, make load idempotent #522
Conversation
This change enables applications to implement periodic reloads of updated configuration files without requiring restarts. This is intended for long-running, service-oriented, applications that cannot afford to be shutdown yet may need to have their configurations updated. This change exposes the _loaded_config_files list on the application class instance via a property. This was done so as to not allow side-affects to creep in from clients. More importantly, is the prevention of duplicate config file entries that can occur when load_config_file is called multiple times. This i enables the method's idempotency - otherwise the list of loaded config files increased on each (periodic) call.
|
@minrk I haven't looked at the config system in quite a while. I'd like to have you give this a once over. |
|
@Carreau can you review this? It seems like a useful feature, however I haven't looked at the config system in a long time. |
|
@rmorshea @minrk @Carreau - I just realized that master is for If it changes things, the same was meant for the (now defunct) #521. Seems like Jupyter Hub could use this and I later noticed it doesn't derive from JupyterApp, but Application directly. Please advise. |
|
@takluyver help on this? |
|
In looking into adding this to Since there hasn't been a minor release in over 2 years, it would be great if this could happen soon - it's long overdue. The capability to periodically reload config files for long-running server applications strikes me as a no-brainer. @rmorshea - thank you for your help on this. I'm adding @rgbkrk to this since he was excited about #341 as well. |
|
Restarting the failed jobs to see if it's just flaky (I didn't look at the results... 😬 ) |
|
Hi @Carreau - could you please review these changes? I'd like to push for a 4.3.3 release so Enterprise Gateway could implement dynamic configurations in our pending 2.0 release. Thank you. |
|
@kevin-bates I'm gonna move this forward since it's a relatively minor change that clearly alleviates an immediate issue. |
|
Thank you Ryan. Now the next question is how to get a 4.3.3 release produced that minimally includes this and #341? 🙂 |
|
@kevin-bates I'll be meeting up with a couple core devs next week so we might be able to make a release then. Might even be a 5.0 release. |
|
Thanks y'all |
|
No ETA on the next release right now, however I now have access to the PyPI repo so I can help facilitate it. That said, we need to create an issue which compiles the PRs that should be included so @minrk can review. If you have time to help create that issue it would speed up the process a lot. |
|
Just noticed that you said 4.3.x - I could try to put together a release with just this PR for 4.3.3. However it would be nice to get help compiling an issue to help get 4.4 out since master has diverged a lot from what’s currently out there. |
|
Thanks Ryan. Per my comment above, #341 will be required since that's the change that introduces the tracking of which config files are currently loaded. I'm happy to help with a release although my knowledge of traitlets is strictly limited to the change I made - so I'm not sure where I can be of assistance. |
|
Ok I thought you were more familiar with Traitlets. In that case I wouldn’t worry about compiling PRs for a 4.4 release. I think I just need to take make time on a weekend to just sit down for a 4.4 review session. Given that, here’s what I need to do and what you can do to get a release with these changes:
How does that sound? |
|
Fantastic - thank you! |
|
@kevin-bates added a 4.3.x branch and created this issue to track progress: |
Carreau
added
5.0-re-review
Carreau
removed
the
5.0-re-review
This change enables applications to implement periodic reloads of
updated configuration files without requiring restarts. This is
intended for long-running, service-oriented, applications that
cannot afford to be shutdown yet may need to have their configurations
updated.
This change exposes the _loaded_config_files list on the application
class instance via a property. This was done so as to not allow
side-affects to creep in from clients.
More importantly, is the prevention of duplicate config file entries
that can occur when load_config_file is called multiple times. This
enables the method's idempotency - otherwise the list of loaded config
files increased on each (periodic) call.
This PR stems from the discussion of (now closed) PR #521.