You should be fine. We really don't change the SPANK APIs. What would
get you into trouble is if your SPANK plugin used other SLURM APIs
(e.g. to get configuration information, and the format of that
information changes).
Quoting Bob Moench <r...@cray.com>:
Well, it is a plugin, so it implements:
slurm_spank_local_user_init
slurm_spank_exit
and uses:
slurm_debug
slurm_error
spank_get_item
spank_context // perhaps unnessarily
Is that still simple enough?
Bob
On Fri, 1 May 2015, Moe Jette wrote:
If your plugin is as simple as you describe, then you probably
don't need to worry about rebuilding it with new releases of Slurm.
We have seen a few examples of SPANK plugins which do break due to
dependencies on Slurm data structures and/or functions, so we're
being conservative advising a rebuild.
Slurm preserves existing configuration files across updates. In
terms of automatically editing a file rather than telling an admin
to do so seems like a judgement call. I'd be inclined to leave it
to a sys admin. Heck, the data might be in a Cray DVS file system
and require node reboots to clear old cache data and take effect.
Good luck automating that ;)
Quoting Bob Moench <r...@cray.com>:
Hi,
Long story short (see long story below), I want to deliver and
install a SPANK plugin along with a tool of mine. Does it seem
reasonable to deliver an rpm who's install builds that plugin
and automatically edits the plug stack configuration file to
enable the plugin?
Thanks,
Bob
------------------- Long Story ----------------
I have written a SPANK plugin for srun. Its purpose is to
automatically launch a debugging tool whenever srun starts up
a multi-process, parallel programming application, on Cray
systems. At this point I am exploring ways to deliver the
plugin. Has anyone come up with something they find
satisfying?
When the dust settles, the debug tool and the plugin needs to
have been installed on the system and a plug stack configuration
file needs to have a line that points at the plugin (a DSO).
Our customers pull down the various tools as rpm packages
and a generic script uses rpm to install the latest batch of
tools. This gets the tool installed. Assuming that an rpm was
built for each major SLURM release, a binary plugin could be
part of the debug tool package. The tool is put in a default
location, though users could override that location.
An admin would make sure that the plug stack configuration file
existed and add a line to point at the default (or overridden)
location.
There are a number of things that are clunky and unsatisfying
about what I outlined above.
Needing to have an rpm for each major SLURM release seems
like overkill. My tools have never needed such in the past.
The plugin is quite simple. A glorified hello world with
a fork/exec. I am using very little of the SPANK API. It is
pretty easy for me to imagine the my plugin could be backwards
compatible to older versions of SLURM and the most recent could
always be used. (Perhaps I am naive about what the future
holds...). Addressing the need to recompile with each major
release of SLURM could be handled by having my rpm install,
trigger a compile and link of this simple plugin. The only
thing that might be tricky is finding spank.h.
Burdening the admin with the edit of the plug stack
configuration file is another clunky item. I believe it could be
a one time event, at most once per SLURM update, or even a zero
times event. The admin would be able to put in a location/name
that is a constant from release to release of the tool (again,
using the most recent plugin). Even cleaner, for the admin,
would be for the rpm install to create the file, if absent,
adding or modifying the need line if necessary.
Updating to new releases of SLURM would probably destroy the
plug stack configuration file, breaking the plugin until a new
tool install occurred. This breakage won't be immediately
obvious and the extra awareness and work for the admin is
unfortunate. Personally, I wish that installing a new
release of SLURM promoted any existing plug stack configuration
file, thereby avoiding this problem. Does anyone know if it
does this? I also wish that the plug stack configuration file
existed from the initial SLURM build/install with identifier
and format comments and a commented out example line, but
otherwise empty.
--
Bob Moench Voice: (651) 605-9034
Programming Environment -- Debugger Dev. FAX: (651) 605-8972
Cray Inc.
380 Jackson St. Suite 210 Email: r...@cray.com
St. Paul, MN 55101 URL: http://www.cray.com/
--
Morris "Moe" Jette
CTO, SchedMD LLC
Commercial Slurm Development and Support
--
Bob Moench (rwm); PE Debugger Development; 605-9034; 354-7895; SP 24227
--
Morris "Moe" Jette
CTO, SchedMD LLC
Commercial Slurm Development and Support
