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.
Regards
Bhagat
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?