ds-identify: Improve ds-identify testing flexibility

[holmanb]

ds-identify: Improve ds-identify testing flexibility

- DI_MAIN: if DI_MAIN isn't a builtin function, exec() it
- /usr/libexec/ds-identify-env may be sourced to set variables

The purpose of these changes is to improve ds-identify testing capabilities and to allow testing alternative ds-identify implementations. Use of these capabilities is not supported in cloud-init deployments and therefore generates warnings in the ds-identify log.

Systemd gives generators no ability to run with custom environment variables. To set ds-identify variables at runtime, sourcing an environment file is required.

Example no-op side-loading with env var:

    $ DI_MAIN='echo' ./tools/ds-identify "hello world"
    WARN: side-loading alternate implementation: [echo]
    hello world

Example no-op side-loading with environment variable config:

    $ PATH_ROOT=. ./tools/ds-identify "test"
    WARN: loading environment file [./usr/libexec/ds-identify-env]
    WARN: side-loading alternate implementation: [echo]
    test
    $ cat ./usr/libexec/ds-identify-env
    export DI_MAIN=echo

Example side-loader that can only identify one cloud:

    $ cat nocloud-identifier.sh
    #!/bin/sh
    echo "creating nocloud config"
    echo "datasource_list: [ NoCloud ]" > cloud.cfg
    $ DI_MAIN=./nocloud-identifier.sh ./tools/ds-identify
    WARN: side-loading alternate implementation: [./nocloud-identifier.sh]
    creating nocloud config
    $ cat cloud.cfg
    datasource_list: [ NoCloud ]

Merge type

• Squash merge using "Proposed Commit Message"
• Rebase and merge unique commits. Requires commit messages per-commit each referencing the pull request number (#<PR_NUM>)

[CalvoM]

LGTM.

[CalvoM]

Learnt alot about the power of exec while reviewing.

[TheRealFalcon]

These feel like two unrelated changes. Is the get_environment() part related to the side-loading part? In the side-loading case, main->get_environment() would never get a chance to get called, right?

[holmanb]

These feel like two unrelated changes. Is the get_environment() part related to the side-loading part? In the side-loading case, main->get_environment() would never get a chance to get called, right?

Good point - the code never calls get_environment().

Fixed in the latest commit.

[TheRealFalcon]

LGTM!

[holmanb]

@TheRealFalcon I know you already reviewed this code, but I just updated this PR since DI_MAIN would be referenced before get_environment would be set, so the call wasn't useful.

tested get_environment:

$ cat ./usr/libexec/ds-identify-env
export DI_MAIN=echo
$ PATH_ROOT=. ./tools/ds-identify "test"
WARN: loading environment file [./usr/libexec/ds-identify-env]
WARN: side-loading alternate implementation: [echo]
test

[TheRealFalcon]

Doh. +1