EPIC - Introduce new API Specs and infra creation flow

[Prajyot-Parab]

/kind feature
/area provider/ibmcloud

Describe the solution you'd like
This epic covers all the task items involved as part of the process to complete the entire PowerVS infra creation via CAPIBM.

Completed

• API changes to support infra creation #1485
• Add proposal for Power VS infra creation #1488
• Update api specs #1592
• Update cloud-provider-powervs commit to create latest ccm image #1605
• Handle create workflow of newly proposed Power VS cluster creation method #1599
• Handle delete workflow of newly proposed Power VS cluster creation method #1600

TO-DO

• Explore LoadBalancer integration with capibm PowerVS K8s cluster #1451
• Enhance packer plugin for the powervs dhcp network #1607
• Avoid returning error during infra creation and handle status in a better way #1647

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]

[Prajyot-Parab]

/assign @Karthik-K-N @Amulyam24 @Prajyot-Parab

[Karthik-K-N]

Some of the review comments which needs to be addressed

• Have proper resource state handling and avoid returning error
  PR: Avoid returning error when resource creation and deletion is in progress #1693
• Revisit logs messages
  • Refactor logging #1755
• reconcileNetwork - reconcile DHCP server and network separately
• Check about how to test in staging environment as machine types are different
• Fix gocyclo measure and avoid //nollint
• Reconcile VPC - separate the security group from it and handle it outside
  • Support VPC security group for PowerVS clusters #1738
• Check on how to use and handle exisitng TG and connections
  • Attach connections to existing transit gateway when its not there #1901
  • Refactor transit gateway status #1961
• Revisit when the IBMPowerVSMachine should be set as ready after updating Machine IP in LB and all operations are done or before
• Rewrite LB pool memeber addition -- revisit the logic, it looks complicated
• Optmise checking and setting status for resources
  • Refactor reconcilation of resources #1937
• Have defined types for recurring errors
  - Improve IBMPowerVSCluster deletion #1825
• Validate a case when invalid ID is passed while getting a resource — check how API behaves
  - Refactor reconcilation of resources #1937
• optimise LB pool member creation
• Add a check before importing or using IBMPowerVSImage and execute only if IBMPowerVSCluster is ready
• How to handle if machine has multiple internal IPs
• Revisit adding/setting/updating listeners in LB creation

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[Karthik-K-N]

/remove-lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[mkumatag]

/remove-lifecycle stale