Add description of standard hooks

[elezar]

This change adds a description of standard hooks to the CDI specification. These hooks can be used to update the LDCache in the container or to create symlinks.

[elezar]

I'm not 100% happy with the target::link-path format here. Are there other suggestions on how we would do this?

Something like --link source=foo,target=bar instead?

[klihub]

Cannot we use an ln:ish syntax of --link $existing_target $new_link_name ?

[elezar]

My concern here would be that this would make argument parsing quite brittle. If you could provide reference implementations using urfave and/or cobra then that's something that we could consider.

[reidpr]

I agree with @elezar's initial concern. The way I'd frame it is, because the hook arguments is a JSON list, more syntax within those list elements introduces a new DSL.

The foo::bar notation is new to me. I'm guessing it's more standard in golang world, but in Python or C it would require a second stage of argument parsing.

My suggestions would be:

• Adopt a general principle of one value per argument (i.e., no :: operator).
• Specifically, use @klihub's suggestion of separate target and source arguments.
• Remove --link because it's redundant with the hook definition. This would also make argument parsing in Python or C easier because the target and source become positional arguments rather than options for --link. (Also yes, an argument that takes multiple options is hard to parse in my world too.) nvidia-ctk-hook could simply ignore --link to be backwards compatible.
• Make at least one target and one source required.
• Clarify whether the hook takes multiple target/source pairs or just one.

[elezar]

One thing that's not in the syntax above is that --link can be repeated meaning that one can create multiple links with a single invocation of the create-symlink command.

[reidpr]

Thanks for requesting my opinion.

I think this is a big step forward for the standard.

It does still seem roundabout to me. That is, with the introduction of standard hooks, we now have prescribed behavior, which is great, but it's indirected through the constraints and syntax of command-line programs. To me it would be simpler to just introduce new updateLDCache and createSymlinks fields.

Further suggestions in-line. I hope this is helpful.

[reidpr]

I'd suggest:

• Remove --folder because it's redundant.
• Require at least one folder argument.

[reidpr]

I think it would be good to say more about libc variations. E.g. what happens if you are running a musl container on a glibc host or vice versa? What about libc version differences?

I'm guessing the nVidia hooks assume glibc throughout?

[reidpr]

I like that this leaves unspecified host vs. container ldconfig(8).

[klihub]

@elezar One question related to this... Is the idea with this document addendum, that we describe known 'de-facto' hooks and their normative behavior (including their command line options and expected behavior) ? Also, is the [command prefix] $named_hook syntax to allow for an implementation, where a single binary implements all the de-facto hooks (and an extra 1st $hook_name argument is used to pick which hook to run from that binary) ?

If it is so, and the CDI specification provides such a detailed description of expected availability, syntax and behavior, then wouldn't it make sense to also provide a default implementation for these hooks within the CDI repository ?

[github-actions]

This PR is stale because it has been open 90 days with no activity. This PR will be closed in 30 days unless new comments are made or the stale label is removed. To skip these checks, apply the "lifecycle/frozen" label.