ST2_AUTH_TOKEN env variable set in sensor container but not in action leading to issues

[lakshmi-kannan]

User was following this doc to access key value items instead of datastore services but it looks like we don't set the ST2_AUTH_TOKEN env variable in action runners. This means the same code works in sensor but fails in action complaining about auth.

lkannan@HQ2-LC02QV2NDFVH8 /Volumes/workspace/src/storm/st2 (master●)$ ag "AUTH_TOKEN_ENV_VARIABLE_NAME"       [ruby-2.0.0p648]
st2common/st2common/constants/system.py
22:    'AUTH_TOKEN_ENV_VARIABLE_NAME',
29:AUTH_TOKEN_ENV_VARIABLE_NAME = 'ST2_AUTH_TOKEN'

st2reactor/st2reactor/container/process_container.py
30:from st2common.constants.system import AUTH_TOKEN_ENV_VARIABLE_NAME
297:        env[AUTH_TOKEN_ENV_VARIABLE_NAME] = temporary_token.token
lkannan@HQ2-LC02QV2NDFVH8 /Volumes/workspace/src/storm/st2 (master●)$

Also related: StackStorm/st2docs#156

[Kami]

We do set it for actions, it's called ST2_ACTION_AUTH_TOKEN. All the public variables StackStorm sets and which are available to actions are prefixed with ST2_ACTION_ (that's documented in actions section of the documentation).

The ST2_AUTH_TOKEN variable you are talking about is actually a "private" variable set for the st2client so SensorWrapper can access the datastore via API.

(And yes, I'm not a fan of environment variable approach either, but the reason we do that is because st2client API is less than ideal - client constructor doesn't accept the token).

[Kami]

Actually, please ignore my comment above (I need to stop responding to comments before I have my coffee :P)

Looks like the issue you are talking about is accessing the datastore via the new action_service and not directly. In that case, we need to set that environment variable, yeah (or ideally, make client work with a token which is provided via constructor, but this would require bigger client refactorings).

On a related note - we also need some integration tests for that.