Vc/incoming device api #38
Conversation
Currently alloy creates the server component types on startup if they haven't been populated previously. This change imports bmc-toolbox's component slugs and uses them to populate the server_component_types table using an upsert. This should be able to capture changes to known component types on an upgrade too.
| */ | ||
|
|
||
| var ( | ||
| // historically these values were determined/set by alloy, even though they are |
There was a problem hiding this comment.
There was a problem hiding this comment.
Good point. Depending on the direction I take with versioned_attribute namespaces I can make that change or keep things in-repo and private to FleetDB. That "keeping database internal things private" has been a major motivating factor for me.
There was a problem hiding this comment.
In the end, I decided to keep this internal to FleetDB.
There was a problem hiding this comment.
If its still going to be the same namespace then lets use the consts, that way its easier to find and replace these.
There was a problem hiding this comment.
I tried to do this and found another way where FleetDB is more fragile than expected. https://equinixjira.atlassian.net/browse/FS-1393
|
|
||
| vendorAttrRecord := &models.Attribute{ | ||
| ServerID: null.StringFrom(FixtureInventoryServer.ID), | ||
| Namespace: "sh.hollow.alloy.server_vendor_attributes", // alloyVendorNamespace |
There was a problem hiding this comment.
can we use the rivets constants here https://github.com/metal-toolbox/rivets/blob/main/fleetdb/consts.go
There was a problem hiding this comment.
See my comment above, but right now this is way more work than just a string substitution: https://equinixjira.atlassian.net/browse/FS-1393
| */ | ||
|
|
||
| var ( | ||
| // historically these values were determined/set by alloy, even though they are |
There was a problem hiding this comment.
If its still going to be the same namespace then lets use the consts, that way its easier to find and replace these.
No description provided.