Add non-functional application requirements

[cristiklein]

⚠️ IMPORTANT ⚠️: This is a public repository. Make sure to not disclose:

• [x] personal data beyond what is necessary for interacting with this Pull Request;
• [x] business confidential information, such as customer names.

Quality gates:

• [x] I'm aware of the Contributor Guide and did my best to follow the guidelines.
• [x] I'm aware of the Glossary and did my best to use those terms.

Screenshot below:

[llarsson]

I am not sure about this.

All make sense. Some make great sense within certain contexts. Not all are truly requirements of Compliant Kubernetes.

For the first such point, R1.2 REQUIRES versioned APIs. This makes great sense in all contexts, but is not truly a requirement of Compliant Kubernetes, in the same sense that "the software must be packaged in the OCI container format" is.

I see the idea and appreciate the effort, but I think that this table ought to stick to what is truly required for Compliant Kubernetes.

[cristiklein]

I am not sure about this.

All make sense. Some make great sense within certain contexts. Not all are truly requirements of Compliant Kubernetes.

For the first such point, R1.2 REQUIRES versioned APIs. This makes great sense in all contexts, but is not truly a requirement of Compliant Kubernetes, in the same sense that "the software must be packaged in the OCI container format" is.

I see the idea and appreciate the effort, but I think that this table ought to stick to what is truly required for Compliant Kubernetes.

This sounds like the beginning of a very useful debate. I really appreciate it.

I see what you mean, but let me challenge it a bit. :smile: I'd like this list not to be "minimum requirements" for Compliant Kubernetes, but all things you should consider in order to draw the greatest benefit from Compliant Kubernetes. Don't like a requirements, no problem: Just make sure to fill the "justification for exclusion" column.

Zooming in on R1.2 REQUIRES versioned APIs: I agree that this requirement is way above the "minimum requirement" threshold. However, in order to take advantage of Kubernetes's rolling update Deployment strategy, wouldn't the application need to be loosely coupled via versioned API? So, although I might have been leaning towards the more generous side, I expect each requirement to make the application benefit more from the platform, directly or indirectly.

I see a few options on how to move forward:

1. We focus on "minimum requirements".
   • Good, because we will converge on these a lot easier.
   • Bad, because these already feel covered towards the top of the page, hence this table would add little value.
2. We keep it as-is and add a sentence clarifying that the list of requirements is merely an example which needs to be adjusted for each context.
   • Good, because the list becomes both "strong" and flexible.
   • Bad, because it will be hard for us to converge on these.
3. We convert the list from "requirements" to "considerations".
   • Good, because we will converge on these rather fast.
   • Bad, because I really like "requirement" more than "consideration". The former demands a justification for exclusion, whereas the latter may easily be discarded as spam. :smile:

I'd prefer 2. What do you think?

[llarsson]

As in many of these cases, I agree with you technically (and indeed, you wrote why I am a big proponent of versioned APIs myself), but I don't want to make anyone think that Compliant Kubernetes itself cannot be used unless you fulfill all of these requirements. Because they aren't truly "Compliant Kubernetes" requirements, they are more like "good software practices that you learn the hard way" lessons.

Compliant Kubernetes requirements are such things as Linux containers, since we don't support Windows or non-containerized workloads. But there's no safeguard or other prevention from running software that doesn't version APIs or carry out asynchronous maintenance tasks inside of a Pod instead of a Kubernetes Job -- there just isn't.

So in my mind, it's probably also Option 2, but with the possibility for us to perhaps add a note or two about why something is a very good idea (even if not a hard and firm requirement)? 🤔

[cristiklein]

@llarsson I think this is ready for another review. See updated screenshot in the description.

[cristiklein]

@llarsson Thanks for the feedback!