Rockon custom_config section explained

Horatio · May 24, 2019, 1:05pm

I noticed the “custom_config” section in the owncloud rockon in the official registry.

The bellow snippet is what I’m looking at:
“custom_config”: {
“db_pw”: {
“description”: “Choose a secure password for the database admin user”,
“label”: “DB Password”
},
“db_user”: {
“description”: “Choose a administrator username for the OwnCloud database.”,
“label”: “DB User”
}

It’s from the following Rockon:

github.com

rockstor/rockon-registry/blob/master/owncloud.json

{
    "OwnCloud": {
        "container_links": {
            "owncloud": [
                {
                    "name": "db",
                    "source_container": "owncloud-postgres"
                }
            ]
        },
        "containers": {
            "owncloud": {
                "image": "pschmitt/owncloud",
		"tag": "8.2.1",
                "launch_order": 2,
                "ports": {
                    "443": {
                        "description": "OwnCloud WebUI port. Suggested default: 8080",
                        "host_default": 8080,
                        "label": "WebUI port",

This file has been truncated. show original

So, I understand that this sets some variables for the docker containers. I didn’t see any documentation on this section. Is there any documentation? I’m wondering how the custom_config variables work? For example, does one need to setup some specific variables to match in the docker file or a script with a specific name in the docker container that runs during it’s initial start?

Thx

vesper1978 · May 24, 2019, 3:57pm

Hi @Horatio,

The custom_config section is for specifying environment variables for that specific docker image.

If you take a look at: https://hub.docker.com/r/pschmitt/owncloud

You’ll see what environment variables that docker image itself expects.

Flox · May 24, 2019, 6:03pm

Yeah, the custom_config object is a little bit of a special one.
The short answer to your questions–to the best of my knowledge–is that this object is dedicated only to two specific rock-ons: owncloud and openvpn. As a result, it doesn’t have any effect on other rock-ons.

To the best of my understanding of this part of Rockstor’s code and its evolution with time, I believe the custom_config object appeared in the early stages of the rock-on system in order to deal with “special” settings that these two rock-ons listed above required (such as db password and user-name, etc…). The related parts of the code is shown below:

github.com

rockstor/rockstor-core/blob/1102e2805a9290704ed6f3fd8963dbab37674c5e/src/rockstor/storageadmin/views/rockon_helpers.py#L266-L272


      
          # initialize vol container data
          cco = DCustomConfig.objects.get(rockon=rockon)
          oc = DContainer.objects.get(rockon=rockon, launch_order=2)
          dinit_cmd = list(DCMD) + ['--rm', ]
          dinit_cmd.extend(container_ops(oc))
          dinit_cmd.extend([oc.dimage.name, 'ovpn_genconfig', '-u',
                            'udp://%s' % cco.val, ])

and

github.com

rockstor/rockstor-core/blob/1102e2805a9290704ed6f3fd8963dbab37674c5e/src/rockstor/storageadmin/views/rockon_helpers.py#L282-L294


      
          def owncloud_install(rockon):
              for c in DContainer.objects.filter(rockon=rockon).order_by('launch_order'):
                  rm_container(c.name)
                  cmd = list(DCMD2) + ['--name', c.name, ]
                  db_user = DCustomConfig.objects.get(rockon=rockon, key='db_user').val
                  db_pw = DCustomConfig.objects.get(rockon=rockon, key='db_pw').val
                  if (c.dimage.name == 'postgres'):
                      # change permissions on the db volume to 700
                      vo = DVolume.objects.get(container=c)
                      share_mnt = ('%s%s' % (settings.MNT_PT, vo.share.name))
                      run_command(['/usr/bin/chmod', '700', share_mnt])
                      cmd.extend(['-e', 'POSTGRES_USER=%s' % db_user, '-e',
                                  'POSTGRES_PASSWORD=%s' % db_pw])

As you can see, these are parts of custom logic to install and run these two rock-ons, and this may explain why there is no further documentation (as this object is limited to these two rock-ons).

As the rock-ons system grew, however, a lot more became possible with other, more specific objects such as options, environment, devices, cmd_arguments, and labels. As a result, you should be able to customize a rock-on definition a lot better with these objects now; further customization is on the way.

These objects are all documented in the repository README file in case you haven’t seen it:

If you are trying to write your own rock-on, please don’t hesitate to share your ideas and needs here… a lot of us should be able to help, and I myself would be very interested in hearing your needs as I’m currently working on further improving the rock-on system.

Hope this helps!

Horatio · May 24, 2019, 11:29pm

Thank you for the replies @vesper1978 and @Flox. I have received way more insight than ever expected. The reason for the custom_config has been lingering in the back of my mind for a while. I can now rest easy