PP-527 Mom should log her type


Hi @iestockdale, message format will be like:

03/10/2017 01:40:47;0002;pbs_mom;Svr;pbs_mom;Mom type = standard
03/10/2017 01:40:47;0002;pbs_mom;Svr;pbs_mom;Mom type = cpuset
03/10/2017 01:40:47;0002;pbs_mom;Svr;pbs_mom;Mom type = cray

and i will use standard,cpuset and cray as a token.



Cray does offer other systems besides Cray XC. They have Cray CS systems, too. I would avoid generalizing the value (cray) and potentially confusing admins. My suggestion would be to use cray_alps

03/10/2017 01:40:47;0002;pbs_mom;Svr;pbs_mom;Mom type = cray_alps

I am not suggesting changes to the other values, because these have existed for a long time and I don’t want to break backward compatibility (I can image admins have monitoring scripts, which may depend on the type value)


What about “cray_login” to match how we automatically populate the resources_available.vntype value for such hosts? Yes, sites can and some do change that value, but it is a token we already use that has the desired meaning.


I don’t believe it’s compulsory for PBS Pro to provide the MoM type independent of the configure parameters since it can be derived. The advantage of providing the configure parameters is that you can see ALL of the parameters passed to the build.


I would avoid using the value “cray_login” because the pbs_mom does not necessarily need to be on the Login node for it to work. I would prefer to reference the interface we are relying on for the special capability.

For instance, type = cpuset makes sense because the pbs_mom has special code to interface with cpusets.
type = cray_alps would be clear to say it has special code to interface with Cray ALPS.

Besides, looking at my crystal ball… what would we call the type if/when we support pbs_mom natively on the Cray Compute Nodes? It would not make sense to call it cray_login anymore… Likely the interface will still be ALPS, so referring to cray_alps may still be a good choice.


I agree with @scott. And it would line up with the #define used within our code to create the binary, which is “MOM_ALPS”.


Could we also print the arguments to configure as part of this work, as indicated in an earlier response to the design review?