-
Notifications
You must be signed in to change notification settings - Fork 51
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
python: support relative and absolute path-like targets in jobid URI resolver #6562
Conversation
Neat!
Heh, I kind of like that idea. It's not the fully cooked resolver and the user is specifying strings that would not be valid URIs so it's pretty clear what they want. We can just say it takes a native URI or those special strings. |
Ok, maybe I'll try to prototype something along those lines. |
Removed WIP here. This will probably be nice to have paired with the ancestor paths proposed in #6573 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For some reason this brings me joy.
LGTM and worked perfectly when I started a hierarchy of instances and used this to visit all the levels.
Thanks! Setting MWP. |
Problem: When an instance of the flux.job.uri.JobURI class is initialized with a local URI and it is converted to a remote URI, the local hostname is always used. However, sometimes this may not be appropriate. Add an optional `remote_hostname` arg to the JobURI initializer. If set, use that hostname instead of the local hostname.
Problem: There's no tests of the `remote_hostname` parameter to the JobURI class initializer. Add a test to t/python/t0025-uri.py.
Problem: There is currently no way to easily obtain the URI of a parent Flux instance, the root instance, etc. The `jobid` URI scheme already supports jobid "paths" like `id1/id2` to obtain the URI of a job `id2` running in instance `id1`. Extend this support with familiar syntax for "relative" jobid paths such as `/` for the top-level (or root) instance, or `..` for the local parent, or `/jobid` for a jobid running within in the root instance (no matter the current instance level at which the query is made) While not as useful, `jobid/..` is also supported, where the hostname part of the URI for jobid is then inherited by the URI returned from its parent (by default all relative URIs are resolved as local URIs)
Problem: Support for relative jobid URIs is not tested in the testsuite. Add some tests to t2802-uri-cmd.t.
Problem: The documentation of the jobid scheme in flux-uri(1) does not cover relative elements like `/`, `.`, and `..`. Reword the documentation and add examples to cover this feature.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #6562 +/- ##
==========================================
+ Coverage 79.45% 79.46% +0.01%
==========================================
Files 531 531
Lines 88400 88421 +21
==========================================
+ Hits 70236 70268 +32
+ Misses 18164 18153 -11
|
This PR adds support for path-like expressions in the
jobid
URI resolver. Notably,/
now refers to the root instance,..
refers to the parent of the current instance, and for completeness.
indicates the current instance. These special targets can be combined with a slash as expected, e.g.../..
refers to the parent of the current instance's parent, and/f1234
would refer directly to jobf1234
in the root instance, and so on.This gives users of
flux-uri(1)
, theFluxURIResolver
class, and the internaluri_resolve()
function (flux proxy
,flux top
andflux shutdown
) an easy way to refer to the root instance or parent instances from within a batch/alloc job.I've made this PR a WIP because other folks may not agree with the approach.
One other idea I had was to directly support
/
and..
influx_open(3)
, but that kind of breaks the abstraction thatflux_open()
only takes a native URI. The approach in this PR does have the drawback that it only helps shell and Python users, not necessarily users of the C API.So just throwing this out there for consideration.