Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Experiment to rearrange resource creation invocation in recocile loop to find best minimal time for overall infra resource creation #1837

Open
Karthik-K-N opened this issue Jun 13, 2024 · 3 comments · May be fixed by #1869
Assignees
Labels
area/provider/ibmcloud Issues or PRs related to ibmcloud provider kind/feature Categorizes issue or PR as related to a new feature.

Comments

@Karthik-K-N
Copy link
Contributor

/kind feature
/area provider/ibmcloud

Describe the solution you'd like
[A clear and concise description of what you want to happen.]

Currently as a part of reconcile while creating infra resources we create loadbalancer as the last resources, Its observed that loadbalancer takes lot more time to become active state.

We want to try and figure out best possible order for infra resource creation so that we can create all resources in minimal time.
example Create all vpc resources prior to power vs resources so on.

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

@k8s-ci-robot k8s-ci-robot added kind/feature Categorizes issue or PR as related to a new feature. area/provider/ibmcloud Issues or PRs related to ibmcloud provider labels Jun 13, 2024
@mkumatag
Copy link
Member

also we need to explore if there is a scope for parallelism like create vpc and powervs resources.

@dharaneeshvrd
Copy link
Contributor

/assign

hamzy added a commit to hamzy/installer that referenced this issue Jun 13, 2024
Query the CAPI provider for the timeouts needed during provisioning.  This is optional to support.

The current default of 15 minutes is sufficient for normal CAPI installations.  However, given how the current PowerVS CAPI provider waits for some resources to be created before creating the load balancers, it is possible that the LBs will not create before the 15 minute timeout. An issue was created to track this [1].

[1] kubernetes-sigs/cluster-api-provider-ibmcloud#1837
hamzy added a commit to hamzy/installer that referenced this issue Jun 13, 2024
Query the CAPI provider for the timeouts needed during provisioning.  This is optional to support.

The current default of 15 minutes is sufficient for normal CAPI installations.  However, given how the current PowerVS CAPI provider waits for some resources to be created before creating the load balancers, it is possible that the LBs will not create before the 15 minute timeout. An issue was created to track this [1].

[1] kubernetes-sigs/cluster-api-provider-ibmcloud#1837
@mjturek
Copy link
Contributor

mjturek commented Jun 17, 2024

I guess the best way to go is making as little as possible before kicking off LB creation? Something like this? I honestly am not sure if this is much different than what is done today

Stage 1:

  • VPC
  • Power VS workspace

Stage 2:

  • VPC subnets
  • TGW

Stage 3:

  • LBs
  • TGW connections
  • DHCP service
  • image
  • etc..

openshift-cherrypick-robot pushed a commit to openshift-cherrypick-robot/installer that referenced this issue Jun 18, 2024
Query the CAPI provider for the timeouts needed during provisioning.  This is optional to support.

The current default of 15 minutes is sufficient for normal CAPI installations.  However, given how the current PowerVS CAPI provider waits for some resources to be created before creating the load balancers, it is possible that the LBs will not create before the 15 minute timeout. An issue was created to track this [1].

[1] kubernetes-sigs/cluster-api-provider-ibmcloud#1837
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/provider/ibmcloud Issues or PRs related to ibmcloud provider kind/feature Categorizes issue or PR as related to a new feature.
Projects
None yet
5 participants