Verify deploy validation for missing secrets #49
Conversation
**What** - Check that function deployment is rejected when it requires a function that is not available Resolves openfaas#26 Signed-off-by: Lucas Roesler <[email protected]>
| @@ -125,6 +125,22 @@ func Test_Deploy_WithAnnotations(t *testing.T) { | |||
| } | |||
| } | |||
|
|
|||
| func Test_Deploy_RejectsFunctionWithMissingRequiredSecret(t *testing.T) { | |||
There was a problem hiding this comment.
FYI this won't work with the Operator which is declarative, it does no validation at deployment time of related secrets.
There was a problem hiding this comment.
Is that the behavior we want to allow for certification? If so, then we can just remove this. I don't think we should add a feature flag for every possible behavior but instead decide what the core behavior is and cover that.
There was a problem hiding this comment.
To be fair, we could check the info endpoint first and only execute this against faas-netes, swarm and potentially faasd. The info endpoint gives back a name of the provider.
There was a problem hiding this comment.
My thought is that the certifier should define the baseline integration tests required to say something is an OpenFaaS provider. I don't think it is good for us to add several different switches for each endpoint to handle the differences between swarm/netes/operator/containerd/rancher/etc
In this case, I think we say that this is not specified behavior and leave it to the provider to have its own tests for this kind of behavior. Adding this kind of validation unit test to swarm/netes is straightforward and easily fits within their existing test suites.
In general, we should not treat certifier as an e2e test for the entire project, we will end up with too many flags and code branches to cover everything. Or we say this is the e2e for the project and this means the Operator is out of spec and has a bug.
There was a problem hiding this comment.
We will need some divergence for faasd where scaling is capped at 1/1. I think this test is useful to include, but should be ignored for the operator. Can you think of or suggest any ways that might be done and not fall into the pitfall you mentioned?
we will end up with too many flags and code branches to cover everything
What
that is not available
Resolves #26