-
Notifications
You must be signed in to change notification settings - Fork 6
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
Conversation
d4cff9f
to
f79520c
Compare
side note: I really don't like how the
|
logger = setup_logger(__name__) | ||
|
||
|
||
REDFISH_DISKS_PATH = "/redfish/v1/Systems/System.Embedded.1/Storage/RAID.SL.1-1" |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
0fb3cd1
to
93a3caa
Compare
93a3caa
to
262ab1f
Compare
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.
262ab1f
to
b6565af
Compare
Merge when the https://github.com/RSS-Engineering/undercloud-deploy/pull/222/ is reviewed and approved |
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:
enroll-server
workflow.Closes https://rackspace.atlassian.net/browse/PUC-591