-
Notifications
You must be signed in to change notification settings - Fork 19
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
Decompose the provisioner #109
Merged
Vicente-Cheng
merged 4 commits into
harvester:master
from
Vicente-Cheng:wip-decompose-NDM
Aug 21, 2024
Merged
Changes from all commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
d1b5f52
CRD: add Provisioner field
Vicente-Cheng c8d0bec
controller: decompose the LH provisioner
Vicente-Cheng 02a2d8d
vendor: bump wrangler v3 and k8s v0.30.3
Vicente-Cheng b1e3382
common: move to wrangler v3 and update the generated codes
Vicente-Cheng File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
The table of contents is too big for display.
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
A general question about NDM which I've only thought to ask just now while reviewing this PR: Why do we have both
spec.DevPath
andstatus.deviceStatus.devPath
? Can these two values ever be different? If not, should we remove one of them?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.
The
spec.DevPath
means the dev path when we create the blockdevice CRD (means the first time and fixed)The
status.deviceStatus.devPath
means the current dev path.So I thought showing the
status.deviceStatus.devPath
seems more useful for us.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 showing the actual current path makes sense.
I've just realised this (kinda) explains harvester/harvester#6224 where there were discrepancies between
spec.DevPath
andstatus.deviceStatus.devPath
. I mean, there never should have been three BDs that all had the samestatus.deviceStatus.devPath
, and I assume that was (somehow) caused by multiple dodgy devices with the same WWN, but the fact that one is the path when the device was added, and one is the current path, at least sheds some light on the discrepancies I noticed in that issue.Thinking aloud: Maybe we should just drop
spec.DevPath
? Does it help at all to know what the path was originally? Note: I'm not suggesting we make any further changes to this PR in this area. Just an item for thought/consideration later.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.
+1, it's a redundant field for me with the current design.
We can do more cleanup for these fields. I plan to introduce a new naming mechanism to replace the current one in the next release (means v1.5). That we would be good at some devices w/o wwn. Maybe we could redesign these fields at that time.
We still need to check the WWN duplicated. But we could have better handling with those devices w/o wwn.
UPDATE
I am also curious about that part. We should make sure the duplicated wwn is not added, but somehow, it was added. Maybe there still is a corner case on the wwn checking mechanism.
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.
Yes. If you have a device file like
/dev/disk/by-path/pci-0000:00:10.0-scsi-0:0:0:0
this can change when the PCI slots are reordered, e.g. by adding new hardware. Therefore/dev/disk/by-id/
should be used because they are predictable due the fact that these device files contains the WWN or serial number of the disk for example.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.
Thanks @votdev,
Yeah, if we would like to keep the spec.devPath field. We should use a meaningful path like the above instead of the
/dev/sdx
. As I mentioned above, we could redesign the field and naming mechanism on v1.5.