kubernetes.core: Add turbo mode job

[Akasurde]

Added an additional voting molecule job to test ENABLE_TURBO_MODE=True
and cloud.common.

Signed-off-by: Abhijeet Kasurde [email protected]

[goneri]

The test is failing with:

TASK [assert that task failed with proper message] *****************************
fatal: [localhost]: FAILED! => {"msg": "The conditional check '\"kubernetes >= 17.17.0 is required\" in _result.msg' failed. The error was: error while evaluating conditional (\"kubernetes >= 17.17.0 is required\" in _result.msg): 'dict object' has no attribute 'msg'"}

[gravesm]

@goneri @Akasurde I think what's going on here is:

1. Earlier module in test suite spawns turbo daemon using virtualenv with kubernetes >= 17.17.0 installed.
2. Later module is initially spawned using virtualenv with kubernetes < 17.17.0 installed.
3. Later module then uses turbo daemon spawned by earlier module to actually execute the module.
4. Later module fails because it's assuming kubernetes < 17.17.0 is installed, but this is not true by the time module execution happens.

I'm not sure what the best way to address this is. The only thing I can think of is for that one failing test to just disable turbo mode.

[goneri]

@goneri @Akasurde I think what's going on here is:

1. Earlier module in test suite spawns turbo daemon using virtualenv with kubernetes >= 17.17.0 installed.
2. Later module is initially spawned using virtualenv with kubernetes < 17.17.0 installed.
3. Later module then uses turbo daemon spawned by earlier module to actually execute the module.
4. Later module fails because it's assuming kubernetes < 17.17.0 is installed, but this is not true by the time module execution happens.

I'm not sure what the best way to address this is. The only thing I can think of is for that one failing test to just disable turbo mode.

Agreed, I would also disable turbo mode for the test. I work on a patch for that.

[goneri]

@goneri @Akasurde I think what's going on here is:

1. Earlier module in test suite spawns turbo daemon using virtualenv with kubernetes >= 17.17.0 installed.
2. Later module is initially spawned using virtualenv with kubernetes < 17.17.0 installed.
3. Later module then uses turbo daemon spawned by earlier module to actually execute the module.
4. Later module fails because it's assuming kubernetes < 17.17.0 is installed, but this is not true by the time module execution happens.

I'm not sure what the best way to address this is. The only thing I can think of is for that one failing test to just disable turbo mode.

Agreed, I would also disable turbo mode for the test. I work on a patch for that.

It seems to be unrelated. I can reproduce the problem without the turbo mode.

[goneri]

@goneri @Akasurde I think what's going on here is:

1. Earlier module in test suite spawns turbo daemon using virtualenv with kubernetes >= 17.17.0 installed.
2. Later module is initially spawned using virtualenv with kubernetes < 17.17.0 installed.
3. Later module then uses turbo daemon spawned by earlier module to actually execute the module.
4. Later module fails because it's assuming kubernetes < 17.17.0 is installed, but this is not true by the time module execution happens.

I'm not sure what the best way to address this is. The only thing I can think of is for that one failing test to just disable turbo mode.

Agreed, I would also disable turbo mode for the test. I work on a patch for that.

It seems to be unrelated. I can reproduce the problem without the turbo mode.

We actually always end up running the k8s_info action. The test is broken.

[abikouo]

@goneri @Akasurde I think what's going on here is:

1. Earlier module in test suite spawns turbo daemon using virtualenv with kubernetes >= 17.17.0 installed.
2. Later module is initially spawned using virtualenv with kubernetes < 17.17.0 installed.
3. Later module then uses turbo daemon spawned by earlier module to actually execute the module.
4. Later module fails because it's assuming kubernetes < 17.17.0 is installed, but this is not true by the time module execution happens.

I'm not sure what the best way to address this is. The only thing I can think of is for that one failing test to just disable turbo mode.

Agreed, I would also disable turbo mode for the test. I work on a patch for that.

It seems to be unrelated. I can reproduce the problem without the turbo mode.

We actually always end up running the k8s_info action. The test is broken.

Thats really strange as it was working before (it has been merged so this mean test validated)

[Akasurde]

@goneri Could you please merge this? Thanks in advance.

[ansible-zuul]

LGTM!