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
RFC: Concourse Kubernetes Operator #45
base: master
Are you sure you want to change the base?
Conversation
metadata: | ||
name: hush-house | ||
spec: | ||
replicas: 2 |
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.
Am I correct to infer that this CRD only represents ATC's, and isn't responsible for creating workers? Or is this looking to a point beyond having worker pods, where the cluster itself is a "worker"?
I'm not too familiar with how the k8s worker experiment you created works, but it may be the case that with "k8s workers", the ATC creates pods for steps/resource checks (and there's no dedicated "worker" pods)?
One blocker for this is that the core team has no desire to build or maintain an operator right now. I don't see the team trying to support anything k8s-related besides the chart right now. This talk also got me wondering if writing an operator is even a good idea for Concourse: https://www.youtube.com/watch?v=CwVCfl4qpdg
Postponing for now, we'll see how the k8s landscape changes in the future. |
The k8s runtime for Concourse feels like a natural fit. If a team correctly sizes (resource.limits) a given Sad to see this delayed. |
Agree. I don't see a need for concourse operator right now, There are other proposals that should be prioritized. |
One other way to go about this issue is to use Carvel.dev and its secret-gen-controller. This is the approach that has been taken by the [reusable concourse templates used by the bosh community][https://github.com/cloudfoundry/bosh-community-stemcell-ci-infra/]. |
any news ? |
Rendered