Task Description

[andre-merzky]

Our current task description focuses on executables, but we move slowly toward including function calls and other call methods. That needs to be eventually reflected in the API, by making sure that task descriptions (TD) covers those.

I see several options:

1. continue to abuse the current TD
   • that will work in the short run, but is probably not a good solution in the long run
2. add keys to the current TD, and choose different sets of keys depending on task type
3. create different task descriptions per task type (possibly inheriting from the same base TD).

Does anybody see other options?

I would currently favour the last approach, somewhat like this:

class TaskDescription(ru.Description):
    _schema = {
       'cpu_processes' : int, 
       'cpu_threads'   : ...,
       'named_env'     : ...,
       'pre_exec'      : ...,
   }
   
class ExecutableTaskDescription(TaskDescription):
    _schema = {
       'executable': str,
       'arguments' : [str],
       ...
   }
   
class FunctionTaskDescription(TaskDescription):
    _schema = {
       'function': ...,
       'args'    : ...,
       'kwargs'  : ...,
       ...
   }

but I also like the simplicity and flexibility of option 2:

 class TaskDescription(ru.Description):
     _schema = {
        'launch_mode'   : enum  # call, function, eval, exec, ...
        'cpu_processes' : int, 
        'cpu_threads'   : ...,
        'named_env'     : ...,
        'pre_exec'      : ...,
        'executable'    : str,
        'arguments'     : [str],
        'function'      : ...,
        'args'          : ...,
        'kwargs'        : ...,
        ...
    }

@iparask @mtitov @mturilli @AymenFJA: let's discuss :-)

[mturilli]

I agree, I do not see other viable approaches.

I am assuming we are going to keep backward compatibility with ComputeUnitDescription() for a while, independent of the approach we decide to use?

I think one of the guiding principles should be to minimize the impact on current users/applications. Ideally, whatever we decide to do, users should change their code only if they need to executed function tasks instead of executable tasks. This would make me think that option 2 would have exec as default for launch_mode when not specified.

[andre-merzky]

I am assuming we are going to keep backward compatibility with ComputeUnitDescription() for a while, independent of the approach we decide to use?

Yes - given how long we used the term, I would expect us to carry it along for quite a while.

I think one of the guiding principles should be to minimize the impact on current users/applications. Ideally, whatever we decide to do, users should change their code only if they need to executed function tasks instead of executable tasks. This would make me think that option 2 would have exec as default for launch_mode when not specified.

I agree with that objective.

[AymenFJA]

I think option 1 is more convenient and more organized, it shows the separation between 2 different types of task perfectly (executable from function ). I understand they both fall under the task category, but at the same time, they have different descriptions. So I would go with option 1.

[andre-merzky]

I think option 1 is more convenient and more organized,

@AymenFJA : Hmm, interesting that you find (1) more convenient - I thought that of (2) :-) Yes, (1) beats (2) in clarity.

[mtitov]

Have a remark for option 1: for now ru.Description (and ru.Munch) doesn't allow to extend _schema in inherited classes, thus ExecutableTaskDescription wouldn't have _schema from TaskDescription + its own _schema, only its own schema.

And just to clarify option 2: schema contains attribute launch_mode, in this case everything that is in attribute executable will be run according to that launch mode (either call'ed or exec'ed or ...), right? Thus we wouldn't need a separate attribute function there? and instead of arguments just to have args or keep one as a synonym for another (-> launch_mode, executable, args, kwargs)

[andre-merzky]

Have a remark for option 1: for now ru.Description (and ru.Munch) doesn't allow to extend _schema in inherited classes, thus ExecutableTaskDescription wouldn't have _schema from TaskDescription + its own _schema, only its own schema.

This can be done with:

class ExecutableTaskDescription(TaskDescription):
    TaskDescription._schema.update({
       'executable': str,
       'arguments' : [str],
       ...
   })

And we probably can create some simplification like

class ExecutableTaskDescription(TaskDescription):
    _schema_extend = {
       'executable': str,
       'arguments' : [str],
       ...
   }

And just to clarify option 2: schema contains attribute launch_mode, in this case everything that is in attribute executable will be run according to that launch mode (either call'ed or exec'ed or ...), right? Thus we wouldn't need a separate attribute function there? and instead of arguments just to have args or keep one as a synonym for another (-> launch_mode, executable, args, kwargs)

Yes, we would basically throw all attributes into the same schema, and use the subset required for the specific launch method. And yes, it probably would make sense to name attributes so that they can be reused by several LMs.

I think this is terribly ugly, really - but also I think that for an end user perspective, this is really convenient. Like, switching from call to eval to function is simple. Hmm, this also points to a third option: using one class type for executable based tasks, and one more generic task type for all others?

[iparask]

I am in favor of the third option.

The following scenario plays into my head strongly with option 2, and I cannot shake it: "Yes, I only have a class to remember, but which is the correct attribute for an executable or function so that it works? Why are there different attributes? Can it not work regardless?". And then, we try to allow different combinations of launch_modes, executable, and function.

On the other hand, option 3 does not create any ambiguity regarding what the task is for. I understand it may be a bit harder to implement, but I think it will make our lives easier in the long run.

I also second @mtitov comments to keep args and kwargs for both types of tasks.

[andre-merzky]

I also second @mtitov comments to keep args and kwargs for both types of tasks.

args I agree with, but kwargs cannot really be applied to executables I think?

The following scenario plays into my head strongly with option 2, and I cannot shake it: "Yes, I only have a class to remember, but which is the correct attribute for an executable or function so that it works? Why are there different attributes? Can it not work regardless?". And then, we try to allow different combinations of launch_modes, executable, and function.

Isn't that a worry with option 3 also? call, method, eval, exec - they all likely need somewhat different attributes. eval for example gets a piece of code, but that attribute would not make sense for call (a function call). I would think your concern points to option 2 rather (specified task types)?

[mtitov]

One more option (no.4) for consideration (at some points it overlaps with earlier proposed options):

1. to have only one task description class
2. BUT different descriptions for exec-object inside (with "dynamic" setup during initialization)

class ExecObjDescription(ru.Munch):
    _schema = {
        'executable': str,
        ...
    }

class FuncObjDescription(ru.Munch):
    _schema = {
        'function': ...,
        ...
    }


class TaskDescription(ru.Munch):
    _schema = {
        'exec_obj': ru.Munch,
        ...
    }

    def __init__(self, from_dict):
        if not isinstance(from_dict['exec_obj'], (dict, ru.Munch)):
            raise ...
        elif  isinstance(from_dict['exec_obj'], dict):
            if 'executable' in from_dict['exec_obj']:
                from_dict['exec_obj'] = ExecObjDescription(from_dict['exec_obj'])
            elif 'function' in from_dict['exec_obj']:
                from_dict['exec_obj'] = FuncObjDescription(from_dict['exec_obj'])
            ...
        super().__init__(from_dict=from_dict)

Also these exec-object descriptions could have their own methods (td.exec_obj.get_...()) update: each such class could have its own implementation of the processing method (e.g., overwrite run/process method)

p.s. and later (according to one of the discussion we've started) ru.Munch could be renamed to ru.TypedDict, but details of it are for another discussion thread

[andre-merzky]

That's kind of neat :-) Wouldn't you worry though that the same class type has then different attributes, depending on how it was constructed? Like, task_a.executable would work, but task_2.executable would not, even though both have the same type?

[mtitov]

with this approach such unique attributes would be hidden inside one "public" attribute - every task description would have such attribute, for example let's call it exec_obj, but the type of this attribute would be different (yet all of them are Munch-based), e.g., either ExecObjDescription or FuncObjDescription, and all these classes would have methods/properties that are with the same names among them

class ExecObjDescription(ru.Munch):
    _schema = {
        'executable': str,
        'arguments': list
    }

   @property
    def launch_string(self):
        return self.executable + ' '.join(self.arguments)

    @property
    def launch_mode(self):
        return 'eval'

class FuncObjDescription(ru.Munch):
    ...
    @property
    def launch_mode(self):
        return 'call'
    ...



task_1 = TaskDescription({
    'exec_obj': {
        'executable': 'hello_rp.sh',
        'arguments': [300]
    },
    'cores': 2
})
print(task_1.exec_obj.launch_mode)

[andre-merzky]

After discussion, we'll opt for version 3, but will add a factory to keep some of the benefits of version 4. Next, we'll have to revise the set of attributes we want to expose for each description type, and document them diligently.