Environment and Portal CRD are creating VirtualServices with the same name

[jmunozro]

Describe the bug Both Environment and Portal CRD are creating VirtualServices following the same naming strategy ->which produces conflicts

If you create an environment and a portal with the same name in the same namespace they try to create a VS with the same name The first who create the VS won and the second VS will never be created

To Reproduce Steps to reproduce the behavior:

1. Create an Environment in default namespace
2. Create a Portal in default namespace (it doesn't have to be default, just the same as step1)
3. Observe there is no new VirtualService for the Portal, indicating a naming conflict
4. Delete the Portal
5. Observe the original VirtualService is deleted, confirming the name conflict

Expected behavior Environments and Portal generate VS with a different name

Additional context Tested with gloo 1.7.3

[bewebi]

I've opened solo-io/dev-portal#1738 which aims to resolve this issue by appending a prefix representing the owning resource type to the names of generated VirtualServices.

We've identified that this could be a breaking change in a couple of ways:

• Users (or their jobs/scripts/etc) may make an assumption that generated VirtualServices will have the same name as the owning resources, in which case adding a suffix would break the assumption
• We think (though haven't confirmed) that when upgrading to the version that introduces this change, Portal will create a new VS with the suffic name but not be smart enough to clean up the old one, so we'd have multiple VirtualServices with identical domains which breaks the gateway

The options here would be:

• Explicitly document that we do not support Environments and Portals sharing names
• Add a flag to opt-in to the appended-suffix behavior, documenting the ways in which this may constitute a breaking change

Looking for guidance from @jmunozro based on customer requirements