Hello,
Unlike other entities, for locations the ownership relations are not emitted when spec.owner is set. I'd like to ask if this omission was intentional? So far I don't experience any issues when testing an extended model. We need those relations so that the owners are permitted to refresh their locations.
#Location ownership relations
latent plover
sharp horizon
Emitting relations (and performing validation) is the job of catalog processors. So adding custom fields typically involves making a processor.
Because the catalog has no idea what semantics you want with your new field
It doesn't intrinsically know anything, really. Either a processor exists that handles a field, or there doesn't. Beyond that the catalog basically just stores blobs (that you ascribe meaning to).
https://backstage.io/docs/features/software-catalog/descriptor-format is the authority of what exists in the default model (which you can even opt out of). Beyond that, the rest is custom
I'll also add, your use case sounds unfortunate. I'm not sure it will work. These things are being refreshed all the time for any number of reasons, including by automated batch processes without user interaction. And the Location type is more of a low level artifact than actual owned data. What are you trying to achieve?
latent plover
We have a permission policy that allows admins and owners to trigger a refresh of an entity. It's not a problem if it's refreshed in other situations, the goal is to allow the owner of the location file to schedule a refresh on demand.
sharp horizon
Why is it locked down in the first place?
strange falcon
Hey @sharp horizon , I know that the refresh of an entity is nothing security relevant. But in our company, we always try to have the Least Privilge concept - allowing actions to users only if they really need it. That's why in our Backstage only the owners of an entity can do all the actions, including refreshing.
We also know, that Backstage can refresh entities anytime - and thats fine. But we sometimes have the use case, that owners want to refresh a location now, because they changed something. So our question is, if there was a reason to not include owner relations to Locations. Do you know something, we have missed?
We added it by ourself and it is working fine. It's also optional, so that it does not break any Locations (like the generated).
cc: @latent plover
sharp horizon
As I alluded to above it's just a somewhat internal detail. We'll want to remove the usage of locations in that manner in the future.
Typically a user should be refreshing their own entity instead. Which under the hood happens to actually trigger the location behind the scenes (even in today's implementation)
In essence, my mindset is that the locations should not exist, and nobody should have to think about them
latent plover
Thanks for the clarification. The change is small, we'll keep it until it's no longer needed.
strange falcon
@sharp horizon Just to be sure, do you mean, that you will remove the Support for Kind "location" in general?
sharp horizon
@strange falcon Ah no, thanks for clarifying that. No the Template kind is fine as-is, some like to use it as a "softlink" type thing at the root of the repo etc. That will likely not ever go away. It's just the forced creation of these generated-XXX locations that the builtin config+location providers make, that should ideally just go away and be a hidden internal concern.