odo: Can't create two services of the same type

It is not possible to create two services of the same type in one project 😦

▶ odo service create postgresql-persistent
Service 'postgresql-persistent' was created.

▶ odo service list
NAME                      TYPE                      STATUS
postgresql-persistent     postgresql-persistent     ProvisionedSuccessfully



▶ odo service create postgresql-persistent mypost
Service 'mypost' was created.

▶ odo service list
NAME                      TYPE                      STATUS
mypost                    postgresql-persistent     ProvisionRequestInFlight
postgresql-persistent     postgresql-persistent     ProvisionedSuccessfully

▶ odo service list
NAME                      TYPE                      STATUS
mypost                    postgresql-persistent     Provisioning
postgresql-persistent     postgresql-persistent     ProvisionedSuccessfully

▶ odo service list
NAME                      TYPE                      STATUS
mypost                    postgresql-persistent     DeprovisionBlockedByExistingCredentials
postgresql-persistent     postgresql-persistent     ProvisionedSuccessfully

It looks like this is caused by Secret. Every new postgress service creates a secret that is called postgresql (similarly for mysql there is a mysql secret). This is probably causing conflicts during the second instance provisioning.

▶ oc get secrets
NAME                                   TYPE                                  DATA      AGE
96fb37ba-d214-11e8-a200-0242ac110007   Opaque                                0         23m
builder-dockercfg-7k5g5                kubernetes.io/dockercfg               1         2h
builder-token-b4lqx                    kubernetes.io/service-account-token   4         2h
builder-token-cq8mq                    kubernetes.io/service-account-token   4         2h
d2078e6e-d20e-11e8-a200-0242ac110007   Opaque                                0         1h
default-dockercfg-tbc5p                kubernetes.io/dockercfg               1         2h
default-token-fp4jw                    kubernetes.io/service-account-token   4         2h
default-token-z4tk5                    kubernetes.io/service-account-token   4         2h
deployer-dockercfg-4vfn5               kubernetes.io/dockercfg               1         2h
deployer-token-trqpj                   kubernetes.io/service-account-token   4         2h
deployer-token-xq766                   kubernetes.io/service-account-token   4         2h
postgresql                             Opaque                                3         1h
postgresql-persistent                  Opaque

I’m adding it here just for the record.

This is not something that we have to address in this PR. I think that we can live with this for now 😉 I’ll convert this to the Issue and we can look at this later.

_Originally posted by @kadel in https://github.com/redhat-developer/odo/pull/723#issuecomment-430649256_

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Comments: 34 (31 by maintainers)

Most upvoted comments

maybe involve @bparees

Hey, Ben, quick recap of the issue: When we instantiate services from the service catalog, the name of the service/dc …can be provided if the service is provisioned by the automationbroker but when it’s provisioned by the TSB it needs to be provided via a parameter (usually templates use a parameter for the service names). This causes that if we programmatically instantiate two services via the catalog API, if the service is provided by the ASB, they deploy correctly, as each gets a randomly generated name (if not explicitly provided). When the service comes from the TSB, the second service fails, as the resources will have the same name for both instances (unless the param is explicitly provided).

We would like to have a consistent way of invoking the API so that no matter where the service comes from, two services of the same type can be instantiated.

Can you provide us any guidance or point us to the right people to get this answer?

Thanks

@geoand I have tried to create 2 services of the same type, and the second one is not provisioned:

NAME                    TYPE                  STATUS
nationalparks-db        mongodb-ephemeral     ProvisionedSuccessfully
nationalparks-py-db     mongodb-ephemeral     DeprovisionBlockedByExistingCredentials

The name of the resources created are dependant on a parameter called DATABASE_SERVICE_NAME, so if I do create the service with this parameter and different value, I can deploy both services:

$ odo service create mongodb-ephemeral nationalparks-db
$ odo service create mongodb-ephemeral nationalparks-py-db -p DATABASE_SERVICE_NAME=nationalparks-py-db

$ odo service list
NAME                    TYPE                  STATUS
nationalparks-db        mongodb-ephemeral     ProvisionedSuccessfully
nationalparks-py-db     mongodb-ephemeral     ProvisionedSuccessfully

@geoand This service name is part of the template and it’s not uniform amongst services created via a template 😦 so not sure how easy is to provide an easy fix for this, in non-interactive mode.

@kadel FYI