multiple components within the same app have route creation conflict

[yangcao77]

/kind bug

What versions of software are you using?

Operating System:

Output of odo version: odo v2.2.3 (b2ca2a8) - latest main branch

How did you run odo exactly?

odo create nodejs component-a
odo push

odo create nodejs component-b
odo push

Actual behavior

component-a created a route http-3000-app, and component-b is trying to create another http-3000-app, but failure since the route/URL already exist within the same namespace

Expected behavior

the routes odo create should be unique for each component. should append component name instead of app name. one app can have multiple components, and this will result into potential conflicts if I have multiple components under a single app contain the same endpoint name

Any logs, error output, etc?

release v2.2.3 works fine for me, since the route name was <endpointName>-<CmpName>
URL/route name now is <endpointName>-<AppName>
this is a regression introduced by: https://github.com/openshift/odo/pull/4858/files, at line https://github.com/mik-dass/odo/blob/e1391b26245af7a4d93e7a3fbb9a3c67a7b566b6/pkg/url/kubernetes.go#L280

which previously was :

routeName, err := util.NamespaceOpenShiftObject(url.Name, k.componentName)

[yangcao77]

/area url

[dharmit]

@mik-dass can you PTAL?

[mik-dass]

the routes odo create should be unique for each component. should append component name instead of app name. one app can have multiple components, and this will result into potential conflicts if I have multiple components under a single app contain the same endpoint name

We cannot use only the combination of url name and component name as the name of the route due to conflicts when the user creates two URLs with the same name in two different components with the same name belonging to two different apps.

This was the reason behind #4550.

We also cannot use the combination of url name, component name and app name as on openshift clusters the host is decided by appending the namespace's name to the route's name (in this case url-name+component-name+app-name). This in many cases, (even on the CI) causes the host name to be longer than the max 63 characters allowed and thus the routes fail to work.

Thus we dropped support for same route names in the same app (similar to s2i) for now to provide better support for app. We will need to find a better solution in the future.

[yangcao77]

Thus we dropped support for same route names in the same app (similar to s2i) for now to provide better support for app. We will need to find a better solution in the future.

This may work for a single component application, but is not expected for microservices architecture. especially worse user experience for any uses of parent reference, as you cannot change endpoint name from parent devfile.

[mik-dass]

This may work for a single component application, but is not expected for microservices architecture. especially worse user experience for any uses of parent reference, as you cannot change endpoint name from parent devfile.

Yes but switching back to endpoint-name+component-name won't solve the problem as it might cause interference/conflicts between resources belonging to different apps due to the reasons and situations mentioned previously. It was one of the reasons behind #4550.

We will need to find a better solution than switching back to the previous way. We can use random names for routes or figure out a way to detect and manually select the host name. @kadel wdyt?

[kadel]

Shouldn't the naming decisions be ideally handled by devfile/library?
odo is using its own naming patterns for k8s resources. This will result in different naming batters between odo and other tools consuming Devfiles (like Che).

[yangcao77]

devfile/library currently does not generate the name, as it has no information on the project, including component name, app name or namespace.
odo needs to pass in the resource name, namespace, label and annotations for it to generate the ObjectMeta, for instance: https://github.com/mik-dass/odo/blob/b2ca2a81a03d076cf1c6d24c3991363d6f1124e4/pkg/occlient/routes.go#L34

We can discuss this issue on cabal call.

[elsony]

Information on how devWorkspace does the route name generation (extracted from notes on Aug. 3 devfile cable call):
The DevWorkspace operator chooses semi-random names for Routes in the format “-, as our requirements are 1) no collisions in a namespace, and 2) we always generate the same name for the same DevWorkspace CR. Routes used for a DevWorkspace managed by the DevWorkspace operator look like, e.g.:
NAME HOST/PORT PATH
workspacecf7bfa3acbcc44ee-mini-browser workspacecf7bfa3acbcc44ee.apps-crc.testing /mini-browser/
workspacecf7bfa3acbcc44ee-terminal workspacecf7bfa3acbcc44ee.apps-crc.testing /terminal/
workspacecf7bfa3acbcc44ee-theia workspacecf7bfa3acbcc44ee.apps-crc.testing /theia/
workspacecf7bfa3acbcc44ee-theia-dev workspacecf7bfa3acbcc44ee.apps-crc.testing /theia-dev/
workspacecf7bfa3acbcc44ee-theia-redirect-1 workspacecf7bfa3acbcc44ee.apps-crc.testing /theia-redirect-1/
workspacecf7bfa3acbcc44ee-theia-redirect-2 workspacecf7bfa3acbcc44ee.apps-crc.testing /theia-redirect-2/
workspacecf7bfa3acbcc44ee-theia-redirect-3 workspacecf7bfa3acbcc44ee.apps-crc.testing /theia-redirect-3/
workspacecf7bfa3acbcc44ee-webviews workspacecf7bfa3acbcc44ee.apps-crc.testing /webviews/
Note: “workspacecf7bfa3acbcc44ee” is the workspace ID (UID)

[feloy]

It should be possible to use a hash (MD5, adler32, etc) to get a value with a constant length (32 characters for MD5, 8 for adler32), for example url-name + adler32(url-name + component-name + app-name). And url-name should be less than 40 chars long.