Reforming @requirements Decorator in PTL

@saritakh Can you please confirm that host2-11=MOM syntax (i.e. - char in name) will work as argument in @requirements(), I don’t think - is allowed in name of keyword argument name, AFAIK only [a-zA-Z0-9_] is allowed

You are right @hirenvadalia, I have updated the statement and example accordingly. Thank you.
Please have a look again.

@saritakh I don’t see any changes in document, it still has - char in name.

My mistake @hirenvadalia ; please have a look now.

Thanks @saritakh for changes, design looks good to me.

Thank you @hirenvadalia

@vstumpf @anamika @visheshh @nithinj @sandisamp @bhroam please have a look at the updated design and let me know your views or comments.

Hey @saritakh
Here are a few more comments

  1. Instead of macros in the @requirements() decorator, can we use strings? With macros, people have to remember which order the daemons come in (is it SCHED_MOM or MOM_SCHED?). If we use a string of “mom,sched,comm” then they can come in any order. We can split on the comma and look for the daemons. If you really want to use macros, there is no reason you can’t take the string and turn it into a macro internally.
  2. Since you are using --hosts in interface #1, I’d swap the order of the two interfaces
  3. nit: On the last line, I think it should be “These options will no longer be used.”

Thanks @bhroam for foreseeing the challenge with macro usage. I have replaced the macro with list, which is more easily usable than string.
I have updated the design based your comments; please review and let me know of any more comments.

@hirenvadalia @vstumpf @anamika @visheshh @nithinj @sandisamp I have updated the design by replacing the macro specification with list specification for hosts in requirements decorator. Please review the same and let me know of any comments.

Hey @saritakh
I think it’s pretty good. The only thing I would add to interface 2 is that the point of turning these into a list is the daemons can be put in any order. Could you say that explicitly?

Also, I have a question more about implementation. You say [mom], what is mom? It isn’t a quoted string, so either you have defined them elsewhere, or python will think it is undefined. Are you planning on defining them elsewhere? If you haven’t figured this out yet, then don’t worry about it.


Design still looks good to me (except what @bhroam about saying of order into a list explicitly).

Thanks @bhroam ,
I meant them to be strings in list; but I then realized that input as a single string is more user friendly than as a list specification. The single string can then internally be converted into list.
Please have a re-look and let me know of any comments.

I have updated the design; Please have a look at the latest version and let me know of any comments.

Thanks for making the updates. The document looks good to me.


Thank you very much @bhroam