A violation against the OSS Rules of Play has been detected.

Rule ID: rl-reuse_tool-1
Explanation: Does README mention REUSE? No

Find more information at: https://sap.github.io/fosstars-rating-core/oss_rules_of_play_rating.html

Summary

Currently the sample ProviderSpec in the internal package https://github.com/onmetal/machine-controller-manager-provider-onmetal/blob/main/pkg/internal/providerspec.go is defined as a string byte slice. We should rename it to SampleProviderSpec and use a map[string]interface{}instead. When used in the test cases we should then marshal the object into a JSON byte slice wherever it is used.

Summary

We need to bump the onmetal-api and Kubernetes dependencies to use the latest v1.26 version.

In this context we need to fix the testing setup/imports as the onmetal-api structure has changed.

Summary

Currently our MCM provider spec is basically a copy of the onmetal-api Machine spec. That will be not sufficient moving forward as we need an effective provide spec from which the following resources can be created:

• Machine matching the required machine type
• Volume containing the correct image and resource requirements
• NetworkInterface containing the correct Network ref and IP allocation using a present Prefix

Definition of done

All of the above resources are correctly created by the driver. A suite test ensuring the correct behaviour.

A violation against the OSS Rules of Play has been detected.

Rule ID: rl-assigned_teams-1
Explanation: Does it have enough teams on GitHub? No

Find more information at: https://sap.github.io/fosstars-rating-core/oss_rules_of_play_rating.html

A violation against the OSS Rules of Play has been detected.

Rule ID: rl-assigned_teams-1
Explanation: Does it have enough teams on GitHub? No

Find more information at: https://sap.github.io/fosstars-rating-core/oss_rules_of_play_rating.html

Summary

Currently we are using a replace dependency of the MCM (https://github.com/onmetal/machine-controller-manager-provider-onmetal/blob/main/go.mod#L30). This should be changed and we should switch to the upstream version.

Summary

Add a breaking category to release drafter configuration in the .github folder similar to: https://github.com/ironcore-dev/ironcore/blob/main/.github/release-drafter.yml#L4-L6

Release drafter should categories PRs which have a breaking label and group them accordingly in the release notes.

Summary

Extend the existing ProviderSpec with a dnsServers field which allows the configuration of custom DNS servers. The result of this should be rendered into the Machine ignition to configure the resolvd:

    - path: /etc/systemd/resolved.conf.d/dns.conf
      mode: 0644
      contents:
        inline: |
          [Resolve]
          DNS=x.x.x.x
          DNS=y.y.y.y

Definition of done

• Extend the ProviderSpec with a dnsServers field
• Add validation to ensure the list of DNS servers are valid IP addresses
• Ensure the correct behaviour by providing the corresponding unit tests

Summary

The GetVolumeIDs method in the MCM driver returns a list of Volumes for which the provider (onmetal) is responsible. Here is the example description which is part of the GCP MCM implementation:

// GetVolumeIDs returns a list of Volume IDs for all PV Specs for whom an provider volume was found
//
// REQUEST PARAMETERS (driver.GetVolumeIDsRequest)
// PVSpecList            bytes(blob)         PVSpecsList is a list PV specs for whom volume-IDs are required. Plugin should parse this raw data into pre-defined list of PVSpecs.
//
// RESPONSE PARAMETERS (driver.GetVolumeIDsResponse)
// VolumeIDs             repeated string     VolumeIDs is a repeated list of VolumeIDs.
//

https://github.com/gardener/machine-controller-manager-provider-gcp/blob/master/pkg/gcp/machine_controller.go#L216

In our case we need a similar functionality which returns all relevant Volumes derived from a given list of PVCs.

Definiton of done

Implement the corresponding GetVolumeIDs method. A suite test should cover the correct behaviour by creating a corresponding set of Volumes and PVCs.

/ref @Rohit-0505

Describe the bug

We are checking for the wrong CSI driver name in the MCM: https://github.com/ironcore-dev/machine-controller-manager-provider-ironcore/blob/main/pkg/ironcore/get_volume_ids.go#L26

We should use here the correct CSI driver name as defined in the CSI project: https://github.com/ironcore-dev/ironcore-csi-driver/blob/main/pkg/driver/constants.go#L48

A violation against the OSS Rules of Play has been detected.

Rule ID: rl-reuse_tool-2
Explanation: Does it have LICENSES directory with licenses? No

Find more information at: https://sap.github.io/fosstars-rating-core/oss_rules_of_play_rating.html

Summary

Renaming tasks after project move:

• Ensure all build artefacts are prefixed with ironcore
• Ensure that all deployment yamls have the ironcore naming scheme
• Ensure that github.com/ironcore-dev/controller-utils is used and all imports are changed accordingly
• Ensure that github.com/ironcore-dev/ironcore is used and all imports are changed accordingly
• Ensure that ironcore is used in the Makefile
• Ensure that ironcore is used in all docs and README files

Summary

Currently the project relies on golangci-lint to be installed on the host in order to run the linting checks on the code base. To make the project more self-contained we should add a Makefile directive like here: https://github.com/ironcore-dev/ironcore/blob/main/Makefile#L485-L488 and install the golangci-lint tool into the tools bin folder and run the make lint using that binary.

Summary

In order to ensure the correct behaviour of the MCM driver, the ProviderSpec validation needs to be implemented. Here the corresponding implementation (https://github.com/onmetal/machine-controller-manager-provider-onmetal/blob/main/api/validation/validation.go) needs to be improved.

Definition of done

Ensure the correct ProviderSpec and ensure the behaviour by providing corresponding unit tests.

A violation against the OSS Rules of Play has been detected.

Rule ID: rl-vulnerability_alerts-1
Explanation: Are vulnerability alerts enabled? No

Find more information at: https://sap.github.io/fosstars-rating-core/oss_rules_of_play_rating.html

A violation against the OSS Rules of Play has been detected.

Rule ID: rl-assigned_teams-1
Explanation: Does it have enough teams on GitHub? No

Find more information at: https://sap.github.io/fosstars-rating-core/oss_rules_of_play_rating.html

A violation against the OSS Rules of Play has been detected.

Rule ID: rl-reuse_tool-3
Explanation: Is it registered in REUSE? No

Find more information at: https://sap.github.io/fosstars-rating-core/oss_rules_of_play_rating.html

Summary

Move the SampleIgnition in the create machine method (https://github.com/onmetal/machine-controller-manager-provider-onmetal/blob/main/pkg/onmetal/create_machine_test.go#L40) and move it to the internal package.

Also use here a map[string]interface{} and serialize it whenever it is needed. This will keep the code clean and more readable. Also extending the SampleIgnition will be more intuitive as we don't have to render it first via butane or fiddle around in the []byte slice.

A violation against the OSS Rules of Play has been detected.

Rule ID: rl-reuse_tool-4
Explanation: Is it compliant with REUSE rules? No

Find more information at: https://sap.github.io/fosstars-rating-core/oss_rules_of_play_rating.html

A violation against the OSS Rules of Play has been detected.

Rule ID: rl-vulnerability_alerts-1
Explanation: Are vulnerability alerts enabled? No

Find more information at: https://sap.github.io/fosstars-rating-core/oss_rules_of_play_rating.html