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.

Sign up for GitHub

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

Jump to bottom

Add a values.yaml for OpenStackDataPlaneDeployment #158

Merged
merged 1 commit into from
Apr 3, 2024
Merged

Add a values.yaml for OpenStackDataPlaneDeployment #158

merged 1 commit into from
Apr 3, 2024

Conversation

fao89
Copy link
Contributor

@fao89 fao89 commented Apr 3, 2024

No description provided.

@fao89 fao89 force-pushed the deployment_values branch 5 times, most recently from 84ea1f7 to 3c2bba8 Compare April 3, 2024 15:47
@fao89 fao89 requested review from abays and cjeanner April 3, 2024 15:48
@fao89 fao89 force-pushed the deployment_values branch 2 times, most recently from ebb6498 to 2b57a07 Compare April 3, 2024 15:52
cjeanner
cjeanner reviewed Apr 3, 2024
View reviewed changes
Copy link
Contributor

@cjeanner cjeanner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

GIving a try right now with a scale-out scenario:

  • first deploy will happen with "vanilla" name
  • second deploy will add a compute and update the deployment name via a user provided "kustomization" in the ci-framework.

@fao89
Add a values.yaml for OpenStackDataPlaneDeployment
bc35fd1 
Signed-off-by: Fabricio Aguiar <fabricio.aguiar@gmail.com>
@fao89 fao89 marked this pull request as ready for review April 3, 2024 17:54
@cjeanner
Copy link
Contributor

cjeanner commented Apr 3, 2024

++ It works as expected.

Note that the CI Framework needs to inject a custom wait_conditions to catch the new name, buuut... it's a thing, and that change makes automated scaling-out possible!

abays
abays approved these changes Apr 3, 2024
View reviewed changes
Copy link
Contributor

@abays abays left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm

@fao89 fao89 merged commit fa47a11 into openstack-k8s-operators:main Apr 3, 2024
1 check passed
cjeanner added a commit to openstack-k8s-operators/ci-framework that referenced this pull request Apr 3, 2024
@cjeanner
Allow to inject custom wait_conditions during stages
b4c6314 
This feature is needed, especially in HCI scenario, when we want to
scale-out the deployment:
in order to do so, we have to create a new OpenStackDataPlaneDeployment
resource, with a new name to trigger the deployment of the new
compute(s).

In such a use-case, using [1] and the following parameters, we're able
to wait for the right resource to be ready:

```YAML
cifmw_architecture_user_kustomize:
  stage_2:
    edpm-values:
      data:
        deployment:
          name: edpm-scale-out
cifmw_architecture_wait_condition:
  stage_2:
    - >-
      oc -n openstack wait
      osdpd edpm-scale-out --for condition=Ready
      --timeout=1500s
```

In this example, the first snippet will inject a user kustomization in
the ci_gen_kustomize_values role in order to override the resource name.
The second snippet will then inject a new wait_condition to the existing
one.
When the deployment hits the wait_conditions loop, it will pass over the
first one (since it's already done), and run the second condition until
it ends.

[1] openstack-k8s-operators/architecture#158
@cjeanner cjeanner mentioned this pull request Apr 3, 2024
Merged
3 tasks
cjeanner added a commit to openstack-k8s-operators/ci-framework that referenced this pull request Apr 4, 2024
@cjeanner
Allow to inject custom wait_conditions during stages
7dbc6b1 
This feature is needed, especially in HCI scenario, when we want to
scale-out the deployment:
in order to do so, we have to create a new OpenStackDataPlaneDeployment
resource, with a new name to trigger the deployment of the new
compute(s).

In such a use-case, using [1] and the following parameters, we're able
to wait for the right resource to be ready:

```YAML
cifmw_architecture_user_kustomize:
  stage_2:
    edpm-values:
      data:
        deployment:
          name: edpm-scale-out
cifmw_architecture_wait_condition:
  stage_2:
    - >-
      oc -n openstack wait
      osdpd edpm-scale-out --for condition=Ready
      --timeout=1500s
```

In this example, the first snippet will inject a user kustomization in
the ci_gen_kustomize_values role in order to override the resource name.
The second snippet will then inject a new wait_condition to the existing
one.
When the deployment hits the wait_conditions loop, it will pass over the
first one (since it's already done), and run the second condition until
it ends.

[1] openstack-k8s-operators/architecture#158
cjeanner added a commit to openstack-k8s-operators/ci-framework that referenced this pull request Apr 4, 2024
@cjeanner
Allow to inject custom wait_conditions during stages
31ba93a 
This feature is needed, especially in HCI scenario, when we want to
scale-out the deployment:
in order to do so, we have to create a new OpenStackDataPlaneDeployment
resource, with a new name to trigger the deployment of the new
compute(s).

In such a use-case, using [1] and the following parameters, we're able
to wait for the right resource to be ready:

```YAML
cifmw_architecture_user_kustomize:
  stage_2:
    edpm-values:
      data:
        deployment:
          name: edpm-scale-out
cifmw_architecture_wait_condition:
  stage_2:
    - >-
      oc -n openstack wait
      osdpd edpm-scale-out --for condition=Ready
      --timeout=1500s
```

In this example, the first snippet will inject a user kustomization in
the ci_gen_kustomize_values role in order to override the resource name.
The second snippet will then inject a new wait_condition to the existing
one.
When the deployment hits the wait_conditions loop, it will pass over the
first one (since it's already done), and run the second condition until
it ends.

[1] openstack-k8s-operators/architecture#158
openshift-merge-bot bot pushed a commit to openstack-k8s-operators/ci-framework that referenced this pull request Apr 4, 2024
@cjeanner @openshift-merge-bot
Allow to inject custom wait_conditions during stages
1632065 
This feature is needed, especially in HCI scenario, when we want to
scale-out the deployment:
in order to do so, we have to create a new OpenStackDataPlaneDeployment
resource, with a new name to trigger the deployment of the new
compute(s).

In such a use-case, using [1] and the following parameters, we're able
to wait for the right resource to be ready:

```YAML
cifmw_architecture_user_kustomize:
  stage_2:
    edpm-values:
      data:
        deployment:
          name: edpm-scale-out
cifmw_architecture_wait_condition:
  stage_2:
    - >-
      oc -n openstack wait
      osdpd edpm-scale-out --for condition=Ready
      --timeout=1500s
```

In this example, the first snippet will inject a user kustomization in
the ci_gen_kustomize_values role in order to override the resource name.
The second snippet will then inject a new wait_condition to the existing
one.
When the deployment hits the wait_conditions loop, it will pass over the
first one (since it's already done), and run the second condition until
it ends.

[1] openstack-k8s-operators/architecture#158
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@cjeanner cjeanner cjeanner left review comments

@abays abays abays approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@fao89 @cjeanner @abays