Open neo954 opened 8 years ago
whowutwut
commented
8 years ago I don't think we should make this kind of change in the product at this time. It would break all existing postscripts that are not aware of the XCAT_ and customer scripts as well.
samveen
commented
8 years ago @whowutwut Can a whole 2nd set of variables with the XCAT_ prefix be added as an interim step, instead of replacing the variable names. This should allow an upgrade path to fixing this problem later, while not breaking existing scripts. Adding a note to that effect in the relevant user doc would atleast help new customer scripts avoid parts of this problem.
whowutwut
commented
8 years ago @samveen Yes, I think that might be a good interim step.
neo954
commented
8 years ago The point of the bug/issue is not provide another set of environment variables to postbootscripts/postscripts. The point is, avoid pollute environment variables randomly to 3rd party scripts by default. It costs days to debug such a problem, which should be avoid essentially.
zet809
commented
8 years ago There is a little risk to modify this in 2.11, so move to 2.12. And before modifying ENV param name, we need to send note in maillist to let customer know.
whowutwut
commented
8 years ago What about just documenting a way for users to run a script in a clean environment? For example
_/install/postscripts/executeclean
which could look something like... .
#!/bin/sh
echo "=== $0:Running script in clean shell..."
SCRIPT=${1}
env -i ${SCRIPT} ${@:2}
RC=$?
echo "=== $0: Completed running ${SCRIPT}, RC=${RC}"
Hi, @whowutwut , 'env -i' will start a script with an empty environment, but if user need to read xCAT exported environment variables, nothing can be got.
So, I think the correct method is renamed the name of those variables by:
whowutwut
commented
7 years ago Can we create a staggered approach, where we start take the existing variables that we are exporting that we plan to change and echo out a WARN message into the logs so users will see it in their /var/log/xcat/xcat.log .... then export the new variable, For example...
export ARCH='ppc64le'
echo "WARN: ARCH is to be deprecated, use XCAT_ARCH"
export XCAT_ARCH='ppc64le'
....
export DHCPINTERFACES='enP2p1s0f0,enP2p1s0f2'
echo "WARN: DHCPINTERFACES is to be deprecated, use XCAT_DHCPINTERFACES"
export XCAT_DHCPINTERFACES='enP2p1s0f0,enP2p1s0f2' Once this is in place, we can send a note out to the xcat-users email distribution and start mentioning it in the release notes.
Also, in the xcatprobe utility, add a check that would look at the scripts under /install/postscripts directory and look for the deprecated VARIABLES and also print a warning msg there to help users detect potential scripts that are using the VARIABLES.
This will take some time to implement but I think we should at least start putting the pieces in place.
zet809
commented
7 years ago @whowutwut I agree with you, and if we can add them before the 2.13.1 release, it will be better.
zet809
commented
7 years ago I think we need to add the notifications as @whowutwut suggested in next release.
whowutwut
commented
7 years ago Doesn't seem like this item is being tracked correctly and probably will not get around to it, So removing the milestone and sprint label until we can re-assess.
xCAT pass over one hundred environment variables to its child processes while running postbootscripts and postscripts. In some case, it will pollute the runtime environment of the child process.
I suggest, all the xCAT environments should begin with
XCAT_Here is the code for printing all the environment variables.