From: Tony Asleson <tasleson@re...> - 2012-03-20 17:47:00
One of the features of libStorageMgmt is that long running operations
can return a job id which can then be used to periodically check on the
status of the operation. In its current form the job id is an integer.
However, this doesn't work if we want a command line interface tool to
return before the operation is done, because the association between a
job ID number and the work in progress is lost when the plug-in is
destroyed. It does work for those users that use the API and keep the
library open until the operation completes as the associating state is
I'm proposing to replace the job id as a numeric with a job id as a
string. The string could have any form depending on plug-in
implementation and thus be constructed in such a way so that plug-in
writers could associate a status inquiry with the correct long running
operation. An opaque type would be better as we could change the
implementation without changing the ABI, but the end result is we need
something that can be used with stdout and an exit code to be scriptable
on the shell.
The lsmcli command line tool today blocks until the user requested
operation completes. This prevents a user written script from doing
other meaningful work while some long running operation completes. As
part of this change I would add an option to lsmcli for async. operation
so that the tool would return the job id to stdout with an exit code
indicating job in progress. The user could then use lsmcli to query on
the state of the operation given the job string identifier.
Does this sound reasonable? Other ideas?
From: Tony Asleson <tasleson@re...> - 2012-03-22 00:02:20
On 03/20/2012 12:46 PM, Tony Asleson wrote:
> Does this sound reasonable? Other ideas?
Checked in this change today (job id as string, not integer), tests OK.
However, some of the job ids can get pretty interesting. For smi-s I
am using the job path in the provider which results in stuff that looks
The nice thing about this is I can index directly into the SMI-S
provider to check status. I can certainly shorten this up by hashing
etc., but that will add a little overhead.
I need to make changes to the smispy plugin for this too, otherwise I
believe the rest of the code base is done to accommodate this change.
* The ability to restore a FS or individual files from a snapshot
* Delete an initiator when using the smis plug-in (already present in