Description

Implement configuration file support for Klient. By issue we should:

• move /etc/kite/kite.key to the configuration file (~/.config/koding/klient.toml)
• move variables from /Library//LaunchDaemons/klient.plist to the configuration file
• move variables from /opt/kite/klient/klient.sh to the configuration file
• remove /opt/kite/klient/klient.sh and use the klient binary directly
• add generating configuration file to kontrol and update klient -register implementation to fetch configuration file instead of only kite.key
• replace every sed-hack in kloud/userdata and install*.sh scripts with writing the configuration file instead

Discussion

Continuation of the discussion here.

The aim of this task is to refactor hardcoded klient configuration in order to help solving #8920. Refactoring means to move any compile-time configuration like endpoint URLs and alike to runtime configuration. The runtime configuration ideally should be a separate configuration file, e.g. ~/config/koding/klient.cfg. Additionally, but not essential, is to have kite endpoint with crud ops on configuration, that'd allow kd or kloudctl to configure klient remotely without a need to restart it (to preserve mounts etc.).

Currently klient contains default configuration for resources like kontrol URL, tunnelserver URL or klient URL.

The hardcoded URLs are then replaced during compile-time via linker flags.

For environments other than production, the defaults are overwritten by exporting environmental variables like:

export KONTROLURL=http://54.82.228.61:8090/kontrol/kite; curl -sL https://kodi.ng/c/p/kd | bash -s ead1daa4

And then written by the install script here and here.

In order to only solve #8920 we would need to add another variable TUNNELURL to:

• fronted (to the install KD dialog)
• klient/kd
• install script
• /opt/kite/klient/klient.sh

Which can get cumbersome when we'd want to move other variables, like recent keygen endpoint URL for klient logging.

Moreover due to complexity of current configuration there still exists unsolvable bug, that during update kd loses information about custom kontrolURL, since kontrolURL was set during installation via environment variable, and this environment variable is not available during update. The best-effort solution to read kontrolURL from kite.key does not work, since kite.key generated by kontrol has kontrolURL always set to default (http://127.0.0.1:3000/kite), since it's designed to be overwritten by environment variable during installation.

Another issue the configuration v2 is trying to solve is unification of the installation methods for klient:

Currently the are numerous ways to configure klient:

1. kloud uses *.deb and overwrites the configuration
2. connected-vm feature uses klient install script
3. kd installation uses kd install script
4. softlayer uses metadata mode of provisionklient
5. vagrant uses command line mode of provisionklient

Each of the method uses different ways of configuring klient. This makes troubleshooting hard, when klient misbehaves in certain environment it's hard to e.g. ask user for enabling debug mode, since it can be enabled in 5 different places, depending on the environment. This is what #8936 is trying to solve.

Having single place to configure klient would make it possible to unify installation methods, ease troubleshooting and development of new features. And, of course, will help to solve the main goal - #8920.

A number of concerns raised in the other issue:

This sounds like leaking our abstraction into a bigger component, other users of kontrol/kite wont have klient

Kontrol has not enough information to create full configuration for klient, it was my bad to suggest it initially. It should be responsibility of kloud, since klouds generates data needed by klient.

a nice feature that could be implemented later, i don't see it as a necessity right before unifying them
&
What kind of configuration do we store in BoltDB ATM? When we first implemented it was only used for session based, best-effort durable storage medium

If we use a simple yaml/toml/json configuration file instead of BoltDB we will solve both concerns - no need for kd config list, since the user can modify the file manually. Moreover no configuration will be lost if user decides to reset state of klient by removing ~/.config/koding/klient.bolt.

/cc @cihangir @leeola @szkl

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.