[Ingest Manager] Data source names should be unique

[mostlyjason]

Each data source should have a unique name in an Agent configuration. However, we can have multiple with matching names.

[elasticmachine]

Pinging @elastic/ingest-management (Team:Ingest Management)

[ruflin]

The data source name is not our unique identifier. This is especially important as the name can change. This is the reason I would not consider this a bug. But having unique data source names could be especially beneficial for our users, especially in case data sources can be reused at one stage.

Should the data source name be unique per config or on a global level?

[jen-huang]

I think data source names should be unique per config, as data source can only be used by one config atm.

[EricDavisX]

From a usability point of view enforcing this can really help users.

Do we want a separate issue about Configuration names too? Or can we handle it here, likely the same arguments apply.

[EricDavisX]

Its a different API that would need to be fixed to enforce this so I will log it separately I guess unless its easier and ok to fix and test them together and I hear back

[ruflin]

If we think of a future where we have reusable data source, the name should probably be unique globally? It might become awkward if with RBAC we get into a situation that we tell a user you can't use foo because it is already used but you can't see it. At the same time, that should be fine.

@EricDavisX ++ on separate issue.

[EricDavisX]

logged as here: #68275

[mostlyjason]

@ph this could be a breaking change to implement later. I thought we were trying to get breaking changes in 7.9?

[ph]

I have discussed with @ruflin we were not sure we would consider this a bug but more like a feature, this is why we removed the bug label to that issue.

[ph]

@paul-tavares @kevinlog Are you using the integration config name as the policy name?

[mostlyjason]

It looks like I can have two policies both named "endpoint-1". It seems to work but is confusing from an UX perspective. I'm worried if we launch and users create a bunch of policies that we won't have an easy way to rename them later.

[jen-huang]

this could be a breaking change to implement later. I thought we were trying to get breaking changes in 7.9?

It wouldn't be a breaking change when this is implemented. If a user has the same name for multiple package configs previously, the configs would still remain in place if they do nothing. If they choose to edit one of those configs, we would then surface an error on saving.

BTW it's currently not very easy to get a package config with the same names. By default it is populated with {packageName}-{incrementedNumber}, the user would have to manually edit the name to match an existing one. Also with the change done in #70542, multiple Endpoint package configs are not possible now.

[paul-tavares]

@ph yes, we use the name as the "Policy Name"

@jen-huang
Implementing this in the future would be a breaking change for Endpoint that would require transition. We currently make updates to the Package Configs (still trying to get used to this naming change 😬 ) via API to store some data that is not driven by a UI interaction. So in the case that you detail above (where the error would surface on Update), it would actually break Endpoint.

[ph]

Oh, I didn't know you were using a 1:1 match here.

For breaking changes we are in beta so we could do it?

[jen-huang]

@paul-tavares We already implemented functionality for beta to not allow more than one Endpoint package config per agent config, so I don't think we can run into a naming conflict error on update for Endpoint any more?

In any case, I'm working on #70030 right now and plan to squash some related bugs while I'm in that code, so I'll add this bug to my list :) @ph

[paul-tavares]

Oh - wait. I just realized this is uniqueness per Agent Config so yes @jen-huang, I agree. Not an issue for us based on the change that enforces a cardinal of 0-1 for endpoint package configs that is already in master. _(In endpoint Policy list we may want to do something more than just display the policy name on the list because the user there could see duplicates and be confused (ex: we could show the agent config name along with it, but we don’t have that info currently. @kevinlog - FYI)_

…

--

___ *Paul Tavares *| Sr. Software Engineer | Elastic / www.elastic.co | Durham, NC, USA