AICoE-CI integration

[goern]

Hey @ALL, please think about jobs you want the AICoE CI to run on this repo, yamllinting? What else?

Cc: @durandom

[tumido]

1. Kustomization manifests are buildable
2. Resulting Kubernetes resource validation (kubectl create --dry-run --validate or something)
3. Kustomization files maintain the same standard:
   • Use commonLabels as described in document some labeling good practice aicoe-cd#29
   • Don't use deprecated syntax like bases keyword etc.
4. Markdown linting for runbooks (?)

[goern]

oh, btw, what about: https://github.com/thoth-station/thoth-application/blob/9cbd30aed172aff33ecf5f7e21e6f558493c8694/README.md#policy-based-control-of-resources

[tumido]

@goern newer worked with OPA, so.. does it use any generic testsuite, you're referring to in your README? Or do you have any Thoth specific one that we can maybe take a look at? I couldn't find any...

I like the possibility to really test the manifests a lot!

[goern]

Ja, there is https://github.com/thoth-station/thoth-application/tree/master/policy which contains the policies we want to enforce for the thoth-application. It is just testing around, I have had no deep thoughts on it...

[tumido]

I like that. That implements a good portion of my comment above. 🙂 👍

[anishasthana]

I think @tumido hit a lot of the initial ones we'd want to be covering. ++ to what has been said so far.

[durandom]

@HumairAK you looked into https://github.com/app-sre/qontract-validator before we went with argo-cd. Is this something we could do to validate a PR?

[HumairAK]

@durandom -- It's been some time, but my guess is no, as its probably coupled with their qontract-server and not generalized. From their description in the ReadME:

This project contains the tools necessary to bundle data into the format used by qontract-server and to JSON validate it's schema.

Schema Validation would actually be something useful for the aicoe-cd repository, and I think it's worth looking into.

[HumairAK]

+1 to ensuring Kustomizations build successfully on all overlays.

[tumido]

Another cool thing would be if the bots can diff the resources (after kustomize build) from before the PR and after and check if there are new CRDs or cluster wide resources added by the PR. This way we can know if we need to ticket PSI before merging the PR or not.

[HumairAK]

+1 @tumido --- If this can be somehow adjustable to not only CRDs but other apigroups/kinds that we can add onto some sort of a list, that would be even better.

[tumido]

And what about we can take it one step further. If such clusterwide resources are found and approved, can we automate opening of a Service Now ticket to PSI?

[goern]

Yes we can :)

We just need some coding power to help us with that... First of all I'll turn this into a card...

[tumido]

Btw, I've started using the https://github.com/Agilicus/yaml_filter suggested in kubernetes-sigs/kustomize#821 (comment) and It's so easy to populate the psi ticket attachments now. 😄

kustomize build applications/argo/overlays/dh-dev-argo | yaml_filter -i CustomResourceDefinition,ClusterRole > psi_ticket.yaml
kustomize build applications/argo-events/overlays/dh-dev-argo | yaml_filter -i CustomResourceDefinition,ClusterRole >> psi_ticket.yaml

the yaml_filter is a pretty short yet clever script, can we integrate some variation of it (that may be reading the included and excluded resources from a config file instead of args?

[sesheta]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[sesheta]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

/lifecycle rotten

[sesheta]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

/close

[sesheta]

@sesheta: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.