kubernetes-sigs / kubernetes-sigs/cluster-api-provider-openstack
Future plans for v1alpha1 APIs
- Dominant language
- Go
- Stars
- 369
- Forks
- 315
- Avg merge
- 1d 14h
- Merged PRs (30d)
- 33
Description
CAPO has a few [v1alpha1 types](https://github.com/kubernetes-sigs/cluster-api-provider-openstack/tree/main/api/v1alpha1):
- OpenStackClusterIdentity
- OpenStackFloatingIPPool
- OpenStackServer
We should plan for what to do with these in the future. Ideally they should either evolve and be promoted to beta or be deprecated and dropped before too much time has passed.
I am creating this issue to track the plans for them.
**OpenStackServer**
This one is quite "easy". The goal should be to migrate to the OpenStackServer from ORC and we already have an issue for this: https://github.com/kubernetes-sigs/cluster-api-provider-openstack/issues/2814
**OpenStackClusterIdentity**
We test this API in the [e2e tests](https://github.com/kubernetes-sigs/cluster-api-provider-openstack/blob/00a5a0e54389b6cff20426370f86ba9a4af7edfe/test/e2e/suites/e2e/e2e_test.go#L353). It has already been with us for a few release cycles and similar patterns are used by other infrastructure providers. I think we should simply promote this up to beta and include it with the other "core" types.
**OpenStackFloatingIPPool**
This is the hardest. We do not use them in the e2e tests, so we don't have a good signal for if they are "working". CAPI has introduced an [IPAM contract](https://cluster-api.sigs.k8s.io/developer/providers/contracts/ipam), but we do not implement that so we are on our own here. ORC has some floating IP features but not something equivalent to this.
I think our options are basically:
1. Switch over to a proper IPAM contract implementation, or
2. Document why we cannot/won't implement the IPAM contract and promote the API to beta instead, or
3. Deprecate and drop the API.
Contributor guide
Research direction
Start by reviewing the types under api/v1alpha1 and the OpenStackClusterIdentity coverage in test/e2e/suites/e2e/e2e_test.go. Read issue #2814 and the CAPI IPAM contract to understand the proposed OpenStackServer migration and FloatingIPPool options. Done means documenting and implementing an agreed lifecycle plan for all three APIs.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- api, infrastructure
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100