Implementations of Power VS Provider for the OpenShift machine-api

Machine API Provider Power VS

This repository contains implementations of Power VS Provider for the OpenShift machine-api.

This provider runs as a machine-controller deployed by the machine-api-operator

How to build the images in the RH infrastructure

The Dockerfiles use as builder in the FROM instruction which is not currently supported by the RH's docker fork (see https://github.com/kubernetes-sigs/kubebuilder/issues/268). One needs to run the imagebuilder command instead of the docker build.

Note: this info is RH only, it needs to be backported every time the README.md is synced with the upstream one.

Deploy machine API plane with kubernetes cluster

  1. Deploying the cluster

    Use any existing mechanism for deploying the kubernetes cluster, e.g: kubeadm https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/

  2. Deploying machine API controllers

    For development purposes the powervs machine controller itself will run out of the machine API stack. Otherwise, docker images needs to be built, pushed into a docker registry and deployed within the stack.

    To deploy the stack:

    kustomize build config | kubectl apply -f -
    
  3. Deploy secret with Power VS credentials

    Power VS nodeupdate controller assumes existence of a secret file:

    apiVersion: v1
    kind: Secret
    metadata:
      name: powervs-credentials
      namespace: openshift-machine-api
    type: Opaque
    data:
      ibmcloud_api_key: FILLIN

    You can use examples/render-powervs-secrets.sh script to generate the secret:

    # Set the IBMCLOUD_API_KEY with a proper IBM Cloud API Key
    $ IBMCLOUD_API_KEY=<API_KEY> ./examples/render-powervs-secrets.sh examples/addons.yaml | kubectl apply -f -

    Go to How to create IBM Cloud API Key for creating API Key

  4. Test by creating example machine

    # Update the relevant fields like serviceInstanceID, imageID, subnets, keyName etc.. 
    $ kubectl create -f examples/machine-with-user-data.yaml
    $ kubectl create -f examples/userdata.yml

Test locally built powervs actuator

  1. Tear down machine-controller

    Deployed machine API plane (machine-api-controllers deployment) is (among other controllers) running machine-controller. In order to run locally built one, simply edit machine-api-controllers deployment and remove machine-controller container from it.

  2. Build and run powervs actuator from outside the cluster

    $ go build -o bin/machine-controller-manager github.com/openshift/cluster-api-provider-powervs/cmd/manager
    $ .bin/machine-controller-manager --kubeconfig ~/.kube/config --logtostderr -v 5 -alsologtostderr

    If running in container with podman, or locally without docker installed, and encountering issues, see hacking-guide.

How to create IBM Cloud API Key

Method 1: Create an API Key via IAM

https://cloud.ibm.com/docs/account?topic=account-userapikey&locale=en#create_user_key

Method 2: Create an API Key via Service Account

Owner
OpenShift
The developer and operations friendly Kubernetes distro
OpenShift
Comments
  • Bug 2100033: Fetch VM IP from DHCP server to set NodeInternalIP

    Bug 2100033: Fetch VM IP from DHCP server to set NodeInternalIP

    Main intention of this PR is to set the NodeInternalIP for machine so that the cluster auto approver will approve the server csr requests

    1. With DHCP server in place , The IP of the machine needs to fetched from dhcp server lease using the VM mac address
    2. Also a cache implementation is added to avoid frequent calls to DHCP server
    • [x] Add unit test cases
  • allow user to pass in regex for resource lookup

    allow user to pass in regex for resource lookup

    dhcp networks are given a name at create-time by the dhcp service, so we won't know network name -OR- ID until after it's created. we'll have to settle for this, which will create a one-DHCP-nw-per-cloud-instance restriction until we can get a feature request accepted and implemented by powervs

    Signed-off-by: Christy Norman [email protected]

  • Updating ose-powervs-machine-controllers images to be consistent with ART

    Updating ose-powervs-machine-controllers images to be consistent with ART

    Updating ose-powervs-machine-controllers images to be consistent with ART TLDR: Component owners, please ensure that this PR merges as it impacts the fidelity of your CI signal. Patch-manager / leads, this PR is a no-op from a product perspective -- feel free to manually apply any labels (e.g. bugzilla/valid-bug) to help the PR merge as long as tests are passing. If the PR is labeled "needs-ok-to-test", this is to limit costs for re-testing these PRs while they wait for review. Issue /ok-to-test to remove this tag and help the PR to merge.

    Detail: This repository is out of sync with the downstream product builds for this component. One or more images differ from those being used by ART to create product builds. This should be addressed to ensure that the component's CI testing is accurately reflecting what customers will experience.

    The information within the following ART component metadata is driving this alignment request: ose-powervs-machine-controllers.yml.

    The vast majority of these PRs are opened because a different Golang version is being used to build the downstream component. ART compiles most components with the version of Golang being used by the control plane for a given OpenShift release. Exceptions to this convention (i.e. you believe your component must be compiled with a Golang version independent from the control plane) must be granted by the OpenShift architecture team and communicated to the ART team.

    Roles & Responsibilities:

    • Component owners are responsible for ensuring these alignment PRs merge with passing tests OR that necessary metadata changes are reported to the ART team: @release-artists in #aos-art on Slack. If necessary, the changes required by this pull request can be introduced with a separate PR opened by the component team. Once the repository is aligned, this PR will be closed automatically.
    • Patch-manager or those with sufficient privileges within this repository may add any required labels to ensure the PR merges once tests are passing. Downstream builds are already being built with these changes. Merging this PR only improves the fidelity of our CI.

    If you have any questions about this pull request, please reach out to @art-team in the #aos-art coreos slack channel.

  • Add infrastructure sync controller for custom service endpoints

    Add infrastructure sync controller for custom service endpoints

    Controller to sync the custom service endpoints from spec field of infrastructure object to status field.

    • [x] Add Unit Testcases
    • [x] Basic integration testing on real IPI Power VS Cluster

    openshift/api PR to add ServiceEndpoints: https://github.com/openshift/api/pull/1025 Its originally started from https://github.com/openshift/cluster-config-operator/pull/256

  • Bug 2089563: Use PowerVS api types from openshift/api

    Bug 2089563: Use PowerVS api types from openshift/api

    Recently Power VS providerconfig has been added into openshift/api: https://github.com/openshift/api/pull/1159, This PR contains the changes to utiize those apis.

  • Bug 2082667: Bump MAPI dependency. Separate node drain controller.

    Bug 2082667: Bump MAPI dependency. Separate node drain controller.

    Update mapi-operator dependency for supply separate node drain controller. For additional context see: https://github.com/openshift/machine-api-operator/pull/1023

  • Bug 2111467: Set the node internal dns address for machine

    Bug 2111467: Set the node internal dns address for machine

    This PR contains the change to atleset set the node internal dns address even if failed to set the internal ip.

    More context: Recently while testing i found that in some instances its not able to find a IP from dhcp server as there was no lease exist which leading it not to set any address for machine, Later once the machine is provisioned without any address being set, the client csr was never approved and machine never became a node.

  • Set zone, region labels to machines

    Set zone, region labels to machines

    Currently the zone, region and instance type labels are not set to the machines so the information is not displayed when we are querying for machine resources in cluster

    karthikkn@Karthiks-MacBook-Pro cluster-api % oc get machine -A
    NAMESPACE               NAME                                     PHASE     TYPE   REGION   ZONE   AGE
    openshift-machine-api   powervs-actuator-testing-machine-dwbnj   Running                          30m
    openshift-machine-api   rdr-kabhat-mrl5n-master-0                Running                          5d5h
    openshift-machine-api   rdr-kabhat-mrl5n-master-1                Running                          5d5h
    openshift-machine-api   rdr-kabhat-mrl5n-master-2                Running                          5d5h
    openshift-machine-api   rdr-kabhat-mrl5n-worker-dbggh            Running                          5d4h
    openshift-machine-api   rdr-kabhat-mrl5n-worker-dqtcz            Running                          5d4h
    openshift-machine-api   rdr-kabhat-mrl5n-worker-rcllh            Running                          5d4h
    

    After this change the machine resource is displayed as below

    karthikkn@Karthiks-MacBook-Pro nodelink-controller % oc get machine -A
    NAMESPACE               NAME                            PHASE     TYPE   REGION   ZONE    AGE
    openshift-machine-api   rdr-kabhat-mrl5n-master-0       Running   s922   lon      lon04   5d6h
    openshift-machine-api   rdr-kabhat-mrl5n-master-1       Running   s922   lon      lon04   5d6h
    openshift-machine-api   rdr-kabhat-mrl5n-master-2       Running   s922   lon      lon04   5d6h
    openshift-machine-api   rdr-kabhat-mrl5n-worker-dbggh   Running   s922   lon      lon04   5d6h
    openshift-machine-api   rdr-kabhat-mrl5n-worker-dqtcz   Running   s922   lon      lon04   5d6h
    openshift-machine-api   rdr-kabhat-mrl5n-worker-rcllh   Running   s922   lon      lon04   5d6h
    
  • Updating ose-powervs-machine-controllers images to be consistent with ART

    Updating ose-powervs-machine-controllers images to be consistent with ART

    Updating ose-powervs-machine-controllers images to be consistent with ART TLDR: Component owners, please ensure that this PR merges as it impacts the fidelity of your CI signal. Patch-manager / leads, this PR is a no-op from a product perspective -- feel free to manually apply any labels (e.g. bugzilla/valid-bug) to help the PR merge as long as tests are passing. If the PR is labeled "needs-ok-to-test", this is to limit costs for re-testing these PRs while they wait for review. Issue /ok-to-test to remove this tag and help the PR to merge.

    Detail: This repository is out of sync with the downstream product builds for this component. One or more images differ from those being used by ART to create product builds. This should be addressed to ensure that the component's CI testing is accurately reflecting what customers will experience.

    The information within the following ART component metadata is driving this alignment request: ose-powervs-machine-controllers.yml.

    The vast majority of these PRs are opened because a different Golang version is being used to build the downstream component. ART compiles most components with the version of Golang being used by the control plane for a given OpenShift release. Exceptions to this convention (i.e. you believe your component must be compiled with a Golang version independent from the control plane) must be granted by the OpenShift architecture team and communicated to the ART team.

    Roles & Responsibilities:

    • Component owners are responsible for ensuring these alignment PRs merge with passing tests OR that necessary metadata changes are reported to the ART team: @release-artists in #aos-art on Slack. If necessary, the changes required by this pull request can be introduced with a separate PR opened by the component team. Once the repository is aligned, this PR will be closed automatically.
    • Patch-manager or those with sufficient privileges within this repository may add any required labels to ensure the PR merges once tests are passing. Downstream builds are already being built with these changes. Merging this PR only improves the fidelity of our CI.

    ART has been configured to reconcile your CI build root image (see https://docs.ci.openshift.org/docs/architecture/ci-operator/#build-root-image). In order for your upstream .ci-operator.yaml configuration to be honored, you must set the following in your openshift/release ci-operator configuration file:

    build_root:
      from_repository: true
    

    If you have any questions about this pull request, please reach out to @art-team in the #aos-art coreos slack channel.

  • Updating ose-powervs-machine-controllers images to be consistent with ART

    Updating ose-powervs-machine-controllers images to be consistent with ART

    Updating ose-powervs-machine-controllers images to be consistent with ART TLDR: Component owners, please ensure that this PR merges as it impacts the fidelity of your CI signal. Patch-manager / leads, this PR is a no-op from a product perspective -- feel free to manually apply any labels (e.g. bugzilla/valid-bug) to help the PR merge as long as tests are passing. If the PR is labeled "needs-ok-to-test", this is to limit costs for re-testing these PRs while they wait for review. Issue /ok-to-test to remove this tag and help the PR to merge.

    Detail: This repository is out of sync with the downstream product builds for this component. One or more images differ from those being used by ART to create product builds. This should be addressed to ensure that the component's CI testing is accurately reflecting what customers will experience.

    The information within the following ART component metadata is driving this alignment request: ose-powervs-machine-controllers.yml.

    The vast majority of these PRs are opened because a different Golang version is being used to build the downstream component. ART compiles most components with the version of Golang being used by the control plane for a given OpenShift release. Exceptions to this convention (i.e. you believe your component must be compiled with a Golang version independent from the control plane) must be granted by the OpenShift architecture team and communicated to the ART team.

    Roles & Responsibilities:

    • Component owners are responsible for ensuring these alignment PRs merge with passing tests OR that necessary metadata changes are reported to the ART team: @release-artists in #aos-art on Slack. If necessary, the changes required by this pull request can be introduced with a separate PR opened by the component team. Once the repository is aligned, this PR will be closed automatically.
    • Patch-manager or those with sufficient privileges within this repository may add any required labels to ensure the PR merges once tests are passing. Downstream builds are already being built with these changes. Merging this PR only improves the fidelity of our CI.

    If you have any questions about this pull request, please reach out to @art-team in the #aos-art coreos slack channel.

  • Fixed Provider ID format

    Fixed Provider ID format

    This PR contains following changes

    1. To fix the ProviderID format when ServiceInstance.ID or ServiceInstance.Name is passed in spec
    2. Storing the ServiceInstanceID in machine status so that it can be easily fetched against making a query to Power Cloud
    3. Storing the ServiceInstanceID in status field so that user will not edit

    Fixes: 15

  • Implement paging mechanism for PowerVS API calls

    Implement paging mechanism for PowerVS API calls

    Currently we are using which has a default limit of 100 per call, We need to implement a paging mechanism to query for all the instances

    IBM Cloud Doc: https://cloud.ibm.com/apidocs/power-cloud#pcloud-cloudinstances-get

    Reference: https://github.com/openshift/machine-api-provider-powervs/pull/10#discussion_r834368145

  • Future Release Branches Frozen For Merging | branch:release-4.13 branch:release-4.14

    Future Release Branches Frozen For Merging | branch:release-4.13 branch:release-4.14

    The following branches are being fast-forwarded from the current development branch (main) as placeholders for future releases. No merging is allowed into these release branches until they are unfrozen for production release.

    • release-4.13
    • release-4.14

    For more information, see the branching documentation.

Addon Operator coordinates the lifecycle of Add-ons in managed OpenShift
Addon Operator coordinates the lifecycle of Add-ons in managed OpenShift

Addon Operator Addon Operator coordinates the lifecycle of Addons in managed OpenShift. dev tools setup pre-commit hooks: make pre-commit-install glob

Dec 29, 2022
A controller to create K8s Ingresses for Openshift routes.

route-to-ingress-operator A controller to create corresponding ingress.networking.k8s.io/v1 resources for route.openshift.io/v1 TODO int port string p

Jan 7, 2022
a small form factor OpenShift/Kubernetes optimized for edge computing

Microshift Microshift is OpenShift1 Kubernetes in a small form factor and optimized for edge computing. Edge devices deployed out in the field pose ve

Dec 29, 2022
A TUI interface to navigate and view OpenShift 4 must-gather logs
A TUI interface to navigate and view OpenShift 4 must-gather logs

MGR "Must Gather Reader" MGR "not the final name" is a simple TUI interface to navigate and view OpenShift 4 must-gather files. How to run it: Downloa

Dec 21, 2022
A helper tool for getting OpenShift/Kubernetes data directly from Etcd.

Etcd helper A helper tool for getting OpenShift/Kubernetes data directly from Etcd. How to build $ go build . Basic Usage This requires setting the f

Dec 10, 2021
Openshift's hpessa-exporter allows users to export SMART information of local storage devices as Prometheus metrics, by using HPE Smart Storage Administrator tool

hpessa-exporter Overview Openshift's hpessa-exporter allows users to export SMART information of local storage devices as Prometheus metrics, by using

Jan 17, 2022
Oc-clusteroperator - OpenShift CLI plugin to change the state of ClusterOperators from managed to unmanaged and back again

oc-clusteroperator OpenShift CLI plugin to change the state of ClusterOperators

Feb 15, 2022
NovelAI Research Tool and API implementations in Golang

NovelAI Research Tool - nrt A golang based client with: Minimum Viable Product implementation of a NovelAI service API client covering: /user/login -

Dec 14, 2022
Machine controller manager provider local

Out of tree (controller-based) implementation for local as a new provider. The local out-of-tree provider implements the interface defined at MCM OOT driver.

Feb 20, 2022
Power-ups for the daily DevOps life

DevOps Loop Power-Ups Requirements Connected Kubernetes cluster. Some features need support for LoadBalancer services Permission to list, create and d

Nov 3, 2022
How to build production-level services in Go leveraging the power of Kubernetes

Ultimate Service Copyright 2018, 2019, 2020, 2021, Ardan Labs [email protected] Ultimate Service 3.0 Classes This class teaches how to build producti

Oct 22, 2021
Automatically power off system when network interface is down

passer A tiny tool can automatically power off system when network interface is

Apr 23, 2022
Kepler (Kubernetes-based Efficient Power Level Exporter) uses eBPF to probe energy related system stats and exports as Prometheus metrics
Kepler (Kubernetes-based Efficient Power Level Exporter) uses eBPF to probe energy related system stats and exports as Prometheus metrics

kepler Kepler (Kubernetes Efficient Power Level Exporter) uses eBPF to probe energy related system stats and exports as Prometheus metrics Architectur

Dec 26, 2022
OpenAPI Terraform Provider that configures itself at runtime with the resources exposed by the service provider (defined in a swagger file)
OpenAPI Terraform Provider that configures itself at runtime with the resources exposed by the service provider (defined in a swagger file)

Terraform Provider OpenAPI This terraform provider aims to minimise as much as possible the efforts needed from service providers to create and mainta

Dec 26, 2022
Terraform provider to help with various AWS automation tasks (mostly all that stuff we cannot accomplish with the official AWS terraform provider)
Terraform provider to help with various AWS automation tasks (mostly all that stuff we cannot accomplish with the official AWS terraform provider)

terraform-provider-awsutils Terraform provider for performing various tasks that cannot be performed with the official AWS Terraform Provider from Has

Dec 8, 2022
Terraform Provider for Azure (Resource Manager)Terraform Provider for Azure (Resource Manager)
Terraform Provider for Azure (Resource Manager)Terraform Provider for Azure (Resource Manager)

Terraform Provider for Azure (Resource Manager) Version 2.x of the AzureRM Provider requires Terraform 0.12.x and later, but 1.0 is recommended. Terra

Oct 16, 2021
provider-kubernetes is a Crossplane Provider that enables deployment and management of arbitrary Kubernetes objects on clusters

provider-kubernetes provider-kubernetes is a Crossplane Provider that enables deployment and management of arbitrary Kubernetes objects on clusters ty

Dec 14, 2022
Terraform-provider-mailcow - Terraform provider for Mailcow

Terraform Provider Scaffolding (Terraform Plugin SDK) This template repository i

Dec 31, 2021
Provider-generic-workflows - A generic provider which uses argo workflows to define the backend actions.

provider-generic-workflows provider-generic-workflows is a generic provider which uses argo workflows for managing the external resource. This will re

Jan 1, 2022