-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add non-functional application requirements #962
Conversation
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. 😄 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:
I'd prefer 2. What do you think? |
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)? 🤔 |
1e00fe0
to
b720aa6
Compare
@llarsson I think this is ready for another review. See updated screenshot in the description. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like it! :) Well done with the explanations and such as well, it does a lot to add context and understanding, and therefore also adds tons of value.
@llarsson Thanks for the feedback! |
Quality gates:
Screenshot below: