Skip to content

Conversation

@dlaw4608
Copy link
Contributor

Add a controller for managing roles.
Closes issue: #582

@github-actions github-actions bot added the semver:major Breaking change label Dec 10, 2025
Copy link
Contributor

@winiciusallan winiciusallan left a comment

Choose a reason for hiding this comment

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

To me, it is very close to a merge state. Really well done, Daniel. Thanks!

Comment on lines 56 to 57
// TODO(scaffolding): add all of the fields supported in the GroupResourceStatus struct
// If a zero-value isn't expected in the response, place it behind a conditional
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe you have forgot? If you're still working, ignore it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I missed that one, Thanks @winiciusallan 👍

ref: group
assertAll:
- celExpr: "group.status.id != ''"
- celExpr: "!has(group.status.resource.description)"
Copy link
Contributor

Choose a reason for hiding this comment

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

Just to confirm, KUTTL does not catch if a property is not present just matching with the declared status, right? Is that why you added this expression?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

- celExpr: "!has(group.status.resource.description)" will explicitly check that the description field does not exist in the actual resource, since leaving it out of the expected state alone is not enough. So yes because KUTTL doesn't catch if a field is missing, is exactly the reason this CEL assertion is needed.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ack. Thanks for the explanation.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Indeed, this is a common pattern we're already using in our tests.

kind: Group
metadata:
name: group-dependency-no-domain
status:
Copy link
Contributor

Choose a reason for hiding this comment

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

What do you think of checking this after dependency creation?

assertAll:
    - celExpr: "group.status.resource.domainID == domain.status.id"

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sounds good 👍 will add it in to verify that the Group resource picks up the real domain.status.id

@github-actions github-actions bot removed the semver:major Breaking change label Dec 11, 2025
@github-actions
Copy link

Failed to assess the semver bump. See logs for details.

@github-actions
Copy link

Failed to assess the semver bump. See logs for details.

CLI Command:
go run ./cmd/scaffold-controller -interactive=false \
 -kind Group \
 -gophercloud-client NewIdentityV3 \
 -gophercloud-module github.com/gophercloud/gophercloud/v2/openstack/identity/v3/groups \
 -import-dependency Domain \
 -optional-create-dependency Domain

Signed-off-by: Daniel Lawton <dlawton@redhat.com>
@github-actions github-actions bot added the semver:major Breaking change label Dec 11, 2025
@@ -1,28 +1,23 @@

Copy link
Collaborator

Choose a reason for hiding this comment

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

Just curious, was this empty line generated by the scaffolding tool? If so we'll want to fix the template because this will generate an obscure warning when running the kuttl tests. See #580.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Tested it out and yep! the scaffold is the culprit, will look more into why at a later time 👍

ref: group
assertAll:
- celExpr: "group.status.id != ''"
- celExpr: "!has(group.status.resource.description)"
Copy link
Collaborator

Choose a reason for hiding this comment

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

Indeed, this is a common pattern we're already using in our tests.

kind: Domain
name: group-dependency
ref: domain
- apiVersion: v1
Copy link
Collaborator

Choose a reason for hiding this comment

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

Just a nit: we do not need to get the secret anymore in this step.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

removed 👍

@@ -0,0 +1,8 @@
---
apiVersion: openstack.k-orc.cloud/v1alpha1
Copy link
Collaborator

Choose a reason for hiding this comment

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

Have you considered disabling this domain at the same time as the other one? This would make the operation run in parallel rather than sequentially.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good idea, changes made 👍

Copy link
Collaborator

Choose a reason for hiding this comment

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

Why was the import-dependency test removed? Was it not relevant? If so you should explain in the commit message why.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added it back in there 👍

- E2E tests included (except group-import-dependency)
- API configured
- Controller
@mandre mandre added this pull request to the merge queue Dec 17, 2025
Merged via the queue into k-orc:main with commit fde73b7 Dec 17, 2025
9 checks passed
This was referenced Dec 17, 2025
@mandre mandre added this to the Release 2.4 milestone Dec 17, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

semver:major Breaking change

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants