Hello all,
I have posted an EDD (Mom should log her type) for the mom to log her type (standard Mom or CPUSET Mom) each time when log file gets opened so that user can know easily which type of mom is this.Please review and provide feedback.
Thanks
Bhagat
Hi Bhagat,
There is another EDD on mom logging, which also states that the hostname and interfaces will get displayed after the line ;pbs_mom;pbs_build=mach=N/A:security=N/A:configure_args=N/A. I think mom type should come before that. Can you kindly update the EDD with hostname and interface details to have clarity on this?
i have updated the EDD .Thanks
Hi @Bhagat,
Please add a link to the design page that refers this page.
Also, would it be possible to mention the values that the type will take. Just saying “standard Mom, CPUset mom, etc” looks incomplete.
Thanks,
Prakash
Once cgroups goes in, cpusets will be somewhat obsolete. The cgroup hook will be used with the standard mom. Is printing what type of mom we are worthwhile? I foresee the cpuset mom going away at some point in the future.
PBS today has three types of Mom: standard, CPUset, and Cray. This seems a generally useful addition for the future.
Ian,
This RFE talks only about standard mom and cpuset mom. If these are the only two types we will be printing, I don’t see the point of it. I don’t see the cpuset mom sticking around long because not only go cgroups do what cpusets do, the cgroup hook can create cpusets if requested.
If we add in cray, then I might see a reason.
Bhroam
It may still take some time before all users migrate from the cpuset mom to the cgroup hook. Some may hold out until the cpuset mom is officially deprecated, which is at least one year from now, probably closer to two.
I understand the deprecation process takes time. I just don’t think we should be putting in enhancements on a feature which will likely be deprecated soon.
Bhroam
First, adding support for Cray moms would be more consistent than not with the summary of this enhancement (“Mom should log her type”).
Second, even if for some reason that is deemed out of scope, the CPUset enhancement would be very useful as the deprecation process has not started. Support for the CPUset mom will continue after deprecation, so this utiilty will continue for several years.
Rereading the design, I see the following:
“Interface-As an admin, I would like to have the mom log what type of mom she is each time the log file gets opened.”
That is a generic user story, and requires including the Cray Mom type as well as any other that might be present.
That being said, there is an easier way to accomplish this by examining the arguments to the configure script. They will contain flags like --enable-alps and --enable-cpuset. We’re not currently printing the arguments in the log, but it’s fairly easy to do so.
Add the following line to m4/pbs_version.m4 just after AC_SUBST(PBS_VERSION):
AC_SUBST([PBS_CONFIGURE_ARGS], ["$ac_configure_args"])
Then edit src/include/pbs_version.h.in and change the follwoing line:
#define PBS_BUILD “mach=N/A:security=N/A:configure_args=N/A”
to this:
#define PBS_BUILD “mach=N/A:security=N/A:configure_args=”@PBS_CONFIGURE_ARGS@""
The mom logs will contain the following lines when mom starts:
03/13/2017 15:07:04;0002;pbs_mom;Svr;pbs_mom;pbs_version=14.0.1
03/13/2017 15:07:04;0002;pbs_mom;Svr;pbs_mom;pbs_build=mach=N/A:security=N/A:configure_args=" ‘PBS_VERSION=14.0.1’ ‘–prefix=/opt/pbs’ ‘–with-pbs-server-home=/var/spool/pbs’ ‘–with-database-user=postgres’ ‘PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig’"
I see a number of different things being discussed here, because “mom type” is ambiguous. The general cases I see discussed so far are:
Only the cpuset mom is actually a “special” pbs_mom binary. The “Cray” mom is in actuality an otherwise standard pbs_mom that has $alps_client set in her config file. A pbs_mom using cgroups is of course just a standard pbs_mom using a specific hook.
Maybe the most useful thing here is for pbs_mom to dump the contents of her config file to the log upon log open/HUP, and also list all hook names, enabled, user, and event attributes after the server and mom have made contact (since what is available to the mom at literal daemon startup/log open time may not actually be correct)?
That DOES NOT cover the cpuset case, but as has already been covered, the plan is for the cpuset case to go away eventually and I believe we would actively avoid any new “special binary” feature implementation analogous to a special binary like pbs_mom.cpuset. Adding special code and a new log message interface specific to the cpuset mom case does not make sense to me at this point in time.
Hi @scc, I think our posts were submitted at about the same time. Please take a look at my response.
The Cray mom is compiled using the --enable-alps flag which enables certain functionality that a “standard” mom does not include. The cpuset mom will show the --enable-cpuset flag. A standard mom will show neither of these. You can determine if the cgroups hook is enabled based on whether log messages are present from the hook.
Ok, thanks for this correction on that. It looks like we agree that there are better and more flexible/generic ways forward available.
Is the conclusion then that this RFE provides support for these three moms:
That’s correct. Whether the cgroup hook is running is independent of which type of mom is running. All moms are capable of running hooks, cgroups or otherwise. There are four total possibilities, though we never build a mom that supports both ALPS and cpusets. The three mom types you mentioned are the ones we support.
Hi all,
I have updated the EDD based on the suggestions.Please review
Thanks
Thanks, Bhagat. Please specify exactly what is the message format. Also, please specify the three tokens that you will use for the three different mom types.