kubermatic / kubermatic/machine-controller

Openstack provider clean-up

Open
#691 3 comments 0 reactions 0 assignees View on GitHub
kind/cleanup priority/low sig/cluster-management
Dominant language
Go
Stars
326
Forks
138
Avg merge
2d 46m
Merged PRs (30d)
12

Description

This issue is to do some clean-up in the openstack provider logic, that in some cases is not very clear or optimal. A few examples:

In order to get a network by name or ID we iterate through all networks instead of getting it directly with the proper API call:
https://github.com/kubermatic/machine-controller/blob/master/pkg/cloudprovider/provider/openstack/helper.go#L217

Same applies for security groups:
https://github.com/kubermatic/machine-controller/blob/master/pkg/cloudprovider/provider/openstack/helper.go#L184

The logic we use to get the default subset is a bit obscure: if we have just one subnet in the network provided in input we return it otherwise we obtain the subnets from the API and we return the first if any or we throw an error. If there is a reason behind that, I have some doubts, we should at least comment it properly.
https://github.com/kubermatic/machine-controller/blob/master/pkg/cloudprovider/provider/openstack/helper.go#L416

Contributor guide

Open the contributing guide

Research direction

Start in pkg/cloudprovider/provider/openstack/helper.go at the network lookup around line 217, security-group lookup around line 184, and default-subnet logic around line 416. Trace the OpenStack API usage and the reasoning behind the subnet behavior. Done means the lookup paths are clear and efficient, and the default-subnet behavior is either justified in comments or made consistent with the intended provider behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
backend, cloud
Issue type
Refactor
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.