Discussion about feature gate

[kerthcet]

For some experimental features or huge changes which touch a lot of codes, we may need some protection mechanisms, the easiest way might be the config flags.

• new introduced, enable via flag
• mature, remove the flag, enable by default.

Or a really feature-gate kit.

[alculquicondor]

We should probably follow the same feature-gate pattern as k/k.

Are you thinking of a particular feature for which we need this?

[kerthcet]

I'm working on the design of #331 , I think it would be more safe if we can provide such a mechanism, but at this point of time, we can have a flag to enable this.

[alculquicondor]

#331 is backed by issue #78, which is currently assigned to @trasc. I believe he's almost done with the design.

[alculquicondor]

Regardless, feature flags might be useful. Would you want to add the framework for it? I wonder how much we can reuse from k/k.

[kerthcet]

I believe he's almost done with the design.

That's great.

Would you want to add the framework for it? I wonder how much we can reuse from k/k.

I may need to take a look.

[trasc]

For #78 I've opened another KEP PR #742, however , at least for the core components the implementation should be based on a optional field, which , if missing should give us the same behavior as before the implementation.

But still we can use a feature gate to stop the jobframework from populating that field.

[alculquicondor]

@kerthcet did you make progress with feature gates?

#771 might benefit from it.

[tenzen-y]

I think linking this issue to #636 would be good.