[SO Migration] support migrating from "global" to "isolated" types

[jportner]

Some consumers may have "global" saved object types (namespaceType: 'agnostic') that they would like to convert to an "isolated" type (namespaceType: 'single') to become space-aware.

For example, as of Kibana 8.1, APM provides a saved object to persist APM indices settings, and they wanted to start allowing users to set this on a per-space basis in 8.2+. They had to write a custom on-start "migration" to do this: #126176, #126378

If other consumers find themselves in the same position in the future, we should consider adding Core-level support for this. It's not a very technically difficult thing to do, we just have to have a list of all existing spaces before the migration function is called. We already have prior art for "core"-defined migration functions which convert from "isolated" types to "share-capable" types (namespaceType: 'multiple-isolated') -- see convertToMultiNamespaceTypeVersion for more details.

[elasticmachine]

Pinging @elastic/kibana-core (Team:Core)

[pgayvallet]

As a side note, depending on where we goes regarding zero downtime migrations, migrations that would be rewriting a SO document's ID may no longer be permitted. And I think switching from agnostic to specifically single would require to do that?

[rudolf]

We would need to make sure we preserve references so that anything that pointed to the old agnostic object now points to the new space-specific object.

If there's no references we could use the document splitting migration idea from #87900

[jportner]

Let me clarify: I'm talking about converting from namespaceType: 'agnostic' to namespaceType: 'single'. Not any of the other namespace types 😄

As a side note, depending on where we goes regarding zero downtime migrations, migrations that would be rewriting a SO document's ID may no longer be permitted. And I think switching from agnostic to specifically single would require to do that?

Actually no, we wouldn't need to rewrite the ID. The global global object previously existed outside of spaces and it didn't have a namespace prefix. It would need to be "split" into multiple new objects for each non-Default spacde.

Example for a Kibana instance that the following spaces: Default, Alpha, and Bravo

Before migration:
{ _id: 'my-obj-type:my-obj-id', type: 'my-obj-type', attributes: {...} } <- global object

After migration:
{ _id: 'my-obj-type:my-obj-id', type: 'my-obj-type', attributes: {...} }
{ _id: 'alpha:my-obj-type:my-obj-id', type: 'my-obj-type', namespace: 'alpha', attributes: {...} }
{ _id: 'bravo:my-obj-type:my-obj-id', type: 'my-obj-type', namespace: 'bravo', attributes: {...} }

We would need to make sure we preserve references so that anything that pointed to the old agnostic object now points to the new space-specific object.

Since the object ID isn't changing in this case, we wouldn't need to do anything special to preserve references.

[pgayvallet]

It would need to be "split" into multiple new objects for each non-Default space

Well, then FWIW I can say for sure that this is something that will not be supported for rolling upgrades (not that it necessarily matters).

[pgayvallet]

I'm going to close this - we did not receive any concrete requests for such conversion, and the implication for ZDT are complex.