On 06/26/2013 03:39 PM, Jan Synacek wrote:
On 06/21/2013 02:28 PM, Stephen Gallagher wrote:
On 06/12/2013 06:20 AM, Jan Synacek wrote:
On 06/11/2013 10:52 PM, Jan Safranek wrote:
(we were thinking about python functions just scheduling multiple actions and do stuff in parallel massively, but we quickly got into lot of corner cases)
- each high-level function takes a LmiNamespace parameter, which
specifies the WBEM connection + the namespace on which it operates -> i.e. applications/other scripts can run our functions on multiple connections -> if the LmiNamespace is not provided by caller, some 'global' one will be used (so users just connect once and this connection is then used for all high-level functions)
Having two extra parameters for each function sounds like a huge API bloat. I think that having some 'global' one, i.e. some kind of a state object that the underlying layer (lmishell?) would use, would be better.
There's only one parameter, namespace (which encompasses both the connection and namespace on which it operates). There will effectively be a global object that will save the state. The idea is that when we create a connection, we'll set the global variable internally. If you create multiple connections, the last one created will be the default.
Then, if you want to run a routine for a connection *other* than the default, you will need to specify the namespace parameter.
Hmm, I don't think that we really have to pollute the high-level API with this one parameter.
Currently, lmishell doesn't have any internal knowledge of its active connections. What if lmishell established an internal object for every connect() that is called and kept these connection objects in a list, for example? Maybe it would even make sense to have something like an iterator that would point to the currently selected connection, so it can be used as a default for all the high-level calls.
Then, lmishell could also be extended to define something like
def set_global_state(...): # changes the global state ....
def get_global_state(): return _currently_selected_connection
Or perhaps, if it makes sense to have multiple selected connections, those functions could operate with lists/tuples. We could then define our high-level functions like so:
def create_mount(device, mountpoint, options=None, flags=None): c = get_global_state() # use c here to do all the lowlevel stuff # ... pass
Do this sound reasonable? I may be repeating something that has already been written here, but I wanted to be explicit about it.
We expect that admins will build scrips by calling our functions, e.g.:
partition_create(...) vg_create(...) lv_create(...)
Now, if each function automatically iterates over global list of connections, we must stop on the first error.
But if the admin (maybe with some help of lmishell) does the loop manually and even in parallel, some machines can succeed executing the script and possibly only small fraction of them will stop on an error:
for c in m_connections: partition_create(..., ns=c) vg_create(..., ns=c) lv_create(..., ns=c)
Note that it would be nice to add some support for parallel execution of the loop and also nice logging and error reporting so the admin can easily see which machines failed and how.
Jan