Service resource validating a config/route with the same name don't previously exist

[cooperneil]

The Service resource is responsible for minting a new Configuration & Route with the same name as the Service. Should we validate in the webhook that there is not a pre-existing/conflicting Configuration/Route with the same name?

I propose the right behavior would be to deliver a 409(conflict) to the user if a conflicting Configuration/Route already exists, and fail Service creation.

The customer would then need to either rename the Service, or delete the conflicting Route/Configuration, and re-POST the Service create request.

thoughts?

/area API
/cc @sixolet @mattmoor @shefaliv @whaught @steren @mikehelmick

[whaught]

Alternative is to create the service as expected with the given intent and set it to a failure status condition on the naming conflict in the controller reconciliation.

[mattmoor]

The webhook validation isn't transactional with the reconciliation that creates those things, so a mechanism for reporting this failure during reconciliation is needed.

/assign @jonjohnsonjr

[jonjohnsonjr]

Thinking out loud before I tackle this (please correct me if I misunderstand the issue).

I believe the current behavior is that a Service will just take over the pre-existing Configuration/Route and reconcile them to match the Service's spec, even if that Service did not create them. E.g. if the user created these Configurations/Routes on their own, then created a Service with the same name, the Service would clobber the pre-existing Configuration/Route.

Instead, we should validate that the Service created the Configuration and Route before we reconcile them. We can do that by checking the owner reference via GetControllerOf, updating the Service's Conditions to indicate a name conflict (if the Service is not the owner), and aborting the reconciliation process.

Does that sound correct?

[whaught]

That's pretty implementation specific, but having the Service take over existing route and configuration sounds a little unexpected - what if that route or config are already owned by another parent Service?

"updating the Service's Conditions to indicate a name conflict (if the Service is not the owner), and aborting the reconciliation process."
Yea that's about what I'd expect.

[jonjohnsonjr]

From the issue text:

The Service resource is responsible for minting a new Configuration & Route with the same name as the Service.

seems to indicate this is impossible:

what if that route or config are already owned by another parent Service?

unless that's what you mean by "implementation specific".

sounds a little unexpected

I agree. I would expect the Service to create a Route and Configuration with randomness appended to its name to guarantee uniqueness, but it seems that we want them to have identical names for a better UX?

[evankanderson]

/kind spec

[cooperneil]

but it seems that we want them to have identical names for a better UX?

More specifically, we want identical names so that serviceName becomes routeName, which impacts Route.status.domainName

[mattmoor]

/unassign

[mattmoor]

I think that where we "get" in our typical pattern (and check things like IsNotFound) we should check IsOwned and if not then fail the RoutesReady or ConfigurationsReady conditions.

/kind good-first-issue