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

feat: set Flavor on enroll #481

Merged
merged 11 commits into from
Nov 18, 2024
Merged

feat: set Flavor on enroll #481

merged 11 commits into from
Nov 18, 2024

Conversation

skrobul
Copy link
Collaborator

@skrobul skrobul commented Nov 14, 2024

This PR enhances the "enroll-server" workflow with a capability of setting the baremetal node's flavour. We have previously attempted to do this through Ironic inspection hooks, but found that running Ironic's inspection has some undesired side effects (i.e. modifying the baremetal node ports for no reason). As a result, we cannot match the node's hardware specs to a given flavor during the inspection.

What we do instead is retrieve all the required inputs through Redfish interface as part of the 'enroll' workflow, then feed this information to the flavor matching code. The resulting flavor is set immediately when the Ironic node is created or updated.

In order to facilitate this, some additional changes were required:

  • the flavor matching code has been extracted into separate, independent module in case we want to later move this functionality back to Ironic. For now this is not possible until inspection issues are addressed upstream.
  • flavor-sync has been moved to a separate Deployment backed by a PVC that is shared with instances of the enroll-server workflow.
  • when the flavors are matched, we now strip first chunk from the name (i.e. 'prod')

Closes https://rackspace.atlassian.net/browse/PUC-591

@skrobul skrobul force-pushed the flavor-on-enroll branch 15 times, most recently from d4cff9f to f79520c Compare November 18, 2024 14:01
@skrobul skrobul changed the title WIP: set Flavor on enroll feat: set Flavor on enroll Nov 18, 2024
@skrobul skrobul marked this pull request as ready for review November 18, 2024 14:12
@skrobul skrobul requested a review from a team November 18, 2024 14:13
@skrobul
Copy link
Collaborator Author

skrobul commented Nov 18, 2024

side note: I really don't like how the pre-commit/pyright setup is done when it comes to installing a "local" package, but this was the only way I could get it to work. Open to any suggestions how to do this better.
The pyright-python page suggests that we should either:

  • tell pre-commit to install those dependencies, which is great for published modules, but it intentionally does not work for modules/packages included in the source code.

  • explicitly tell pyright which virtual environment to use by updating your pyright configuration file - this may work, but I was hesitant to manipulate this because each user will have different configuration settings with very different paths to their virtualenvs. We may be able to inject ephemeral pyrightconfig.json into a workspace, but that would also require us to create a virtualenv earlier and install our packages there. Feels like a hack, hence looking for better options.

logger = setup_logger(__name__)


REDFISH_DISKS_PATH = "/redfish/v1/Systems/System.Embedded.1/Storage/RAID.SL.1-1"
Copy link
Contributor

Choose a reason for hiding this comment

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

It seems like this would be different on boxes with a different raid controller, but I think this is okay given our strictly heterogeneous target hardware models right now.

Copy link
Collaborator Author

@skrobul skrobul Nov 18, 2024

Choose a reason for hiding this comment

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

Yeah, that can be different even when the disks are connected different way (some of the Dell's examples list RAID.Mezzanine.1-1 for example. As we discussed in the other PR, I went with hardcoded paths that we can differentiate on later.

edit: note for future me - SL stands for "slimline cable", not "slot"

cpu="Non-Existent CPU Model",
disk_gb=500,
model="Dell XPS1319",
)
assert all(flavor.score_machine(machine) for flavor in flavors) == 0
Copy link
Contributor

Choose a reason for hiding this comment

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

Are these asserts doing what it looks like they should be doing? all() answers a boolean, which == compares as a truthy/falsey, so I think this is asserting that at least ONE of the scores is zero, which is all mighty confusing.

Copy link
Collaborator Author

@skrobul skrobul Nov 18, 2024

Choose a reason for hiding this comment

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

You are absolutely right - they were indeed matching incorrectly - it was meant to be

assert all(flavor.score_machine(machine) == 0 for flavor in flavors)

addressed in 93a3caa

This will allow us to reuse the same code betwen the custom Argo
workflows for enrollment as well as Ironic hooks/inspection interfaces.
Eventually when we fully migrate to using ironic hooks, this can be
inlined again.
The responsibility of providing that volume with fresh  data is
delegated to the undercloud-deploy repo as it may be different for each
deployments.
Up till now we ignored the 'chassis model' because there was low risk of
the overlap between the flavors, but turns out this is actually needed
to distinguish between for example gp1.small and gp2.small.
There are no any tests there anymore.
@skrobul
Copy link
Collaborator Author

skrobul commented Nov 18, 2024

Merge when the https://github.com/RSS-Engineering/undercloud-deploy/pull/222/ is reviewed and approved

@skrobul skrobul added this pull request to the merge queue Nov 18, 2024
Merged via the queue into main with commit b5a7302 Nov 18, 2024
24 checks passed
@skrobul skrobul deleted the flavor-on-enroll branch November 18, 2024 17:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants