Make EX_APP_CONTAINER_PREFIX configurable

[small1]

Describe why it is important and where it will be useful

If you have several Nextcloud instances on the same host. It would be good to be able to run several proxys that has its own prefix configured on the same host.

Right now it is nc_apps and it make it impossible to register two proxies on the same host (for development puproses, testing and simpler hosted solutions)

Describe your proposed solution

Either have this as a variable within the web interface or as an occ setting. Create a prefix for the current instance.

Describe alternatives you've considered, if relevant

No response

Additional context

No response

[oleksandr-nc]

This has been added to the roadmap, with no exact timeframe yet.

[christianlupus]

@oleksandr-nc is there any news?
I might need it soon and I might give it a try to fix it myself (would open a PR if I solve it) but do not want to interfere with upstream work.

[small1]

Would this work?

In app_api/lib/DeployActions/DockerActions.php

 public function buildExAppContainerName(string $appId): string {
	$domainprefix = $this->appConfig->getValueString(Application::APP_ID, 'domainprefix', self::EX_APP_CONTAINER_PREFIX);
	return $domainprefix . $appId;
}

public function buildExAppVolumeName(string $appId): string {
	$domainprefix = $this->appConfig->getValueString(Application::APP_ID, 'domainprefix', self::EX_APP_CONTAINER_PREFIX);
	return $domainprefix . $appId . '_data';
}

Set the domainprefix with occ config:app:set app_api domainprefix --value= And if its not set use the constant with a fixed name.

This could if one is not carefull still break stuff if one has two instances with the same domainprefix. So probably needs to be a bit safer. But this could be a start.

[christianlupus]

More or less yes, this is what I had partially in mind. I wanted make the configuration in the admin settings. But yeah. Plus some testing on a dev instance 😉.

[small1]

I have done tests on two hosts so far. I have no clue on how to make it for the ui. I know enough for backend stuff but not more :)

[oleksandr-nc]

The idea is generally good, even excellent.

It's not guaranteed that we'll be able to backport it, as it is a new feature and not a bugfix, but we can include it in Nextcloud 33.
A UI isn't required for this; simple occ commands will suffice, in my opinion.

The DSP will have problems with rules, but we expect that by Nextcloud 33 everyone will be using HaRP, and adding support for it should be easy:

1. Uncomment this line:

   app_api/lib/DeployActions/DockerActions.php

   Line 138 in 83d5152

   $instanceId = ''; // $this->config->getSystemValue('instanceid', '');

2. Test what is broken or not-working, fix it.
3. Add boolean config value to the appConfig that enables that uncommented line when it is set(by default the behaviour should be as it is commented)

[street1983nk]

While writing up #1021 (cross-instance deletion, deliberately not a naming ticket) I read the code around this and noticed two things the plan above does not cover yet.

The commented-out $instanceId = ''; // $this->config->getSystemValue('instanceid', ''); exists six times in DockerActions.php (main: lines 136, 250, 905, 944, 983, 1030), and line 1030 sits in the removal path. Enabling only the deploy site would create nc_app_<instanceid>_<appid> but keep removing nc_app_<appid>, so containers and volumes would be orphaned instead of removed. buildExAppContainerName/buildExAppVolumeName (1349/1353) would need to move along too, since Unregister.php, ExAppsPageController.php and AppAPIService.php all build names through them.

Good news on the HaRP side: it has been ready since v0.2.0. haproxy_agent.py declares instance_id (line 199) and already builds nc_app_<instance_id>_<name> plus the matching _data volume name whenever the field is non-empty (lines 205 and 214). So on that path the remaining work really is just filling the field consistently on the server side.