This adds a blueprint PHID to Drydock logs, so that logs can be associated against Drydock logs. This is useful for tracking down issues when the Drydock allocator is choosing what blueprint to use, and can be used to log information about why blueprints were included or excluded from the available blueprints.
Details
Details
- Reviewers
hach-que - Group Reviewers
Blessed Reviewers
Brought this forward from D10506. Rebased on upstream and allocated a lease against a preallocated resource blueprint.
Diff Detail
Diff Detail
- Repository
- rP Phabricator
- Branch
- hachque-reconstructed
- Lint
Lint Passed Severity Location Code Message Advice src/applications/drydock/blueprint/DrydockPreallocatedHostBlueprintImplementation.php:148 XHP16 TODO Comment Advice src/applications/drydock/blueprint/DrydockWorkingCopyBlueprintImplementation.php:139 XHP16 TODO Comment Advice src/applications/drydock/worker/DrydockAllocatorWorker.php:257 XHP16 TODO Comment Advice src/applications/drydock/worker/DrydockAllocatorWorker.php:308 XHP16 TODO Comment - Unit
Tests Passed - Build Status
Buildable 7774 Build 8580: [Placeholder Plan] Wait for 30 Seconds Build 8579: arc lint + arc unit
Event Timeline
Comment Actions
This doesn't actually seem like it solves the stated problem. Particularly, in the screenshot, all of the blueprint IDs are strictly functions of their resources: no new information is available.
For leases which make it past the allocation phase, the blueprint is strictly a function of the resource. For leases which don't, it seems like we could solve this problem more cleanly by making the diagnostic messages around allocation more clear?
It seems like the right place to provide diagnostics is "1 Blueprint Enabled" -> "1 Blueprint Enabled: Blueprint 234 Name of Blueprint"?
Comment Actions
For implementations which log during lease allocation, where the resource isn't yet allocated to the lease, the blueprint can't yet be determined from the lease because the resource isn't assigned yet.
The problem with just including the blueprint name is that it doesn't provide a mechanism to click through to the blueprint, and also goes out of date if the blueprint is renamed.
Comment Actions
I'm going to pursue some flavor of this. Plans are roughly:
- Swap IDs for PHIDs.
- Add BlueprintPHIDs.
- Make logs more clearly a sub-object of blueprints, resources and leases, and get the SearchEngine stuff accommodating that.
- Move logs a bit more structured so they can be translated and contain things like PHIDs that get linked on display (basically, follow the pattern used by modern Herald actions).