Sample datasets with objects namespaceType: multiple or multiple-isolated fail to install on multiple namespaces

[pgayvallet]

The sample datasets are using static IDs for their objects, meaning that objects installed via the sample datasets got the same ids on each namespace it has been installed on.

With the new namespaceType: multiple/multiple-isolated mode, we can't no longer have the same ID on objects being on different namespaces, as the IDs must be globally uniques.

Currently, datasets containing such objects can only be installed on a single namespace. When trying to install them on an additional one, the installation will fail with a conflict error during the create stage

e.g

{"id":"workpad-e08b9bdb-ec14-4339-94c4-063bddfd610e","type":"canvas-workpad","error":{"statusCode":409,"error":"Conflict","message":"Saved object [canvas-workpad/workpad-e08b9bdb-ec14-4339-94c4-063bddfd610e] conflict","metadata":{"isNotOverwritable":true}}}

I guess the only solution for this is to stop using static IDs for our datasets.

This is far from trivial though, because:

• There are references between the dataset's objects
• Some objects needs to be retrieved somehow (currently via this static ID) to be modified by other consumers

kibana/src/plugins/home/server/services/sample_data/sample_data_registry.ts

Lines 117 to 124 in 1061835

	replacePanelInSampleDatasetDashboard: ({
	sampleDataId,
	dashboardId,
	oldEmbeddableId,
	embeddableId,
	embeddableType,
	embeddableConfig,
	}: SampleDatasetDashboardPanel) => {

NOTE: I think this is only impacting 8.0 because we shouldn't have any namespaceType: multiple/multiple-isolated in the 7.x branch. However, this is probably a blocker for 8.0 as the feature is plain broken.

cc @jportner

[elasticmachine]

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

[jportner]

I had an issue open for this: #114693
I was intending to address it by changing the sample data creation process to use import instead of bulkCreate. That fixes the worst part of this problem (ensures that "at most one copy of sample data objects can be created in each space").

However, anything else that relies on these hardcoded IDs (UI elements with links?) would need to look up the object by its origin ID.

[pgayvallet]

I was intending to address it by changing the sample data creation process to use import instead of bulkCreate

Hum... we would still need to keep track of the actual IDs that were generated during the import process to be able to perform the uninstall action of the dataset. Also, those ids needs to be persisted, as we can uninstall the datasets after a restart.

Maybe an option would be to add an additional 'meta' property containing the id of the dataset when persisting the objects, to be able to retrieve/identify them this way during the delete?

However, anything else that relies on these hardcoded IDs (UI elements with links?) would need to look up the object by its origin ID.

As long as the part about uninstalling is addressed, this is imho acceptable.

[jportner]

Hum... we would still need to keep track of the actual IDs that were generated during the import process to be able to perform the uninstall action of the dataset. Also, those ids needs to be persisted, as we can uninstall the datasets after a restart.

Can't we use the origin ID as a lookup as well?

Uninstall steps would be:

1. Lookup objects based on origin ID
2. Delete each object

Edit: this has the advantage of working for pre-8.0 sample data that was migrated, too.

[pgayvallet]

Can't we use the origin ID as a lookup as well?

Spoke too fast. Yea, we can lookup by originId during uninstall. It should work.

[elasticmachine]

Pinging @elastic/kibana-security (Team:Security)