[discussion] app_name variable results in too long a name for some situations

[leifmadsen]

So while playing around with the mediawiki-apb, I realized that if you're using GlusterFS via Heketi, that it will fail to deploy due to a name length greater than 63 chars while creating a Service object. Unfortunately, this isn't part of the APB deployment, but rather part of the GlusterFS/Heketi service within Kubernetes generating a Service object which results in too long of a name.

The problem is that Kubernetes creates the Service object by prepending glusterfs-dynamic- to the front of the app_name value from the Provisioned Service / Deployment. This then results in a name which is much longer than 63 chars, and results in the application failing to deploy.

Instead of the current default value of app_name which looks like this:

app_name: "mediawiki-{{ _apb_service_instance_id }}"

I'd like to suggest we create a shorter version of that same thing. The solution I've been using is this:

app_name: "mediawiki-{{ _apb_service_instance_id.split('-')[0] }}"

I'm not sure what the impact of this would be long term, or in practice. I'm not sure if this would cause issues with people creating a lot of these applications programmatically in the same namespace, or if that is really even a situation we need to worry about? Obviously we could get conflicts since we're lobbing off a bunch of data on the end. We could still add another label to the deployments with the full service_instance_id attached to it if that seemed necessary.

Looking for thoughts, as I think this is a problem across a lot of the applications. The mariadb-apb seems to be ok, which means the alternate solution is that all APB names need to be 11 chars or less (not ideal).

CC: @mhrivnak @dymurray

[mhrivnak]

We need just enough of the ID to make the name unique within the namespace, and I don't think we need to expect a crazy number of deployments in a single namespace. The first 8 or so characters of the ID should suffice.

These are all example APBs anyway that are intended to be customized if someone wants to use them in production. So if someone did have a problem with collisions, they could adjust accordingly.

👍

[leifmadsen]

@mhrivnak cool... so should I submit a lot of PRs? :)