-
Notifications
You must be signed in to change notification settings - Fork 431
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
Enhancement Proposal: Break out cloud resource reconciliation #416
Comments
@devigned: The label(s) In response to this:
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. |
You'll need to PR github.com/kubernetes/test-infra to add the |
It might be valuable for this YTBNC to be a separate project similar to: https://github.com/GoogleCloudPlatform/k8s-config-connector |
@detiber, precisely what we have been thinking about. One worry is governance of such a project. Having CAPZ take a core / critical dependency on a project outside of K8s doesn’t feel right. As a prototype / optional thing, I think it would be ok, but not as a requirement. What do you think? Am I being too cautious? |
I think it largely depends... I don't think the dependency is really much greater than the one we already have on the various cloud provider SDKs. That said, I do have concerns with Google's k8s-config-connector in particular:
Of course it would be great if the project was underneath the k8s or cncf umbrella to help afford some assurances that we could resolve the above issues using the governance mechanisms in place, but I don't think that is a strict requirement to solving the problem. |
I agree with that, and +1 on having that component be open source be a requirement for dependency. |
/kind proposal |
@devigned - i'd love to see an open source equivalent to google's config connector but for Azure. This is something that people would use outside of capz, especially with gitops. Most of our customers ask for a way to treat their cloud infra in a declarative way like their k8s resources. AWS had somthing similar to config connector: https://github.com/amazon-archives/aws-service-operator that i believe is being ressurected: https://github.com/aws/aws-service-operator-k8sg |
We are actively looking into this. Will update with more information as organizationally possible. |
/assign |
I would agree that it would be preferable that a project like this stays inside of k8s. One thing from the top of my head is that it could be easier to participate and contribute to a project where you can join k8s/CAPI/CAPZ Slack and community meetings. |
Hi @devigned, if I understood correctly, you mentioned at the last CAPZ meeting that there will be some news about this. Is it me failing to find it, or there is nothing out there yet? |
Hi @nprokopic, I was hoping to drop a link on Friday, but was slightly delayed. The prototype we are working on is over here: https://github.com/Azure/k8s-infra. Warnings... the project is nascent. We are experimenting with some different ideas, breaking some stuff and might end up rolling these ideas into another project. |
Awesome, thank you! It looks quite interesting, I definitely like the approach. |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-contributor-experience at kubernetes/community. |
/remove-lifecycle stale |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-contributor-experience at kubernetes/community. |
/remove-lifecycle stale |
Update on this issue: |
Proposal for using this approach with CAPZ: |
This is moving forward; the proposal is merged 🙌, so closing this out. The larger epic for implementation work is here #3402 |
Goals
Non-Goals/Future Work
User Story
As a CAPZ developer I would like to only need to interact with the API server and Custom Resource Definitions of Azure types rather than having to deal with the impedance of interacting with the Azure APIs. This would enable me to focus more on the core value of CAPZ, transforming Cluster-API specs to Azure resource specs.
Detailed Description
CAPZ currently has 2 major concerns.
I think it would help to speed development in CAPZ if the two concerns were broken out into separate controller / reconcilers.
With this enhancement CAPZ could be verified to produce the correct specifications for Azure resources given an input without needing to have a dependency on the Azure API. The vast amount of verification could be done via API server and determining if a given input, Cluster API model, gets translated into the proper Azure resource specifications. At the same time, the concern on reconciling Azure resources could be focused and tested within its own component.
YTBNC (yet to be named controller)
Should have the following characteristics:
Example of a ResourceGroup
Currently
Azure Custom Resource
Contract changes [optional]
None.
Data model changes [optional]
The CAPZ CRDs may want to keep a reference to the underlying Azure custom resources which they own.
/kind proposal
The text was updated successfully, but these errors were encountered: