ct dynamic data in systemd units

[dghubble]

Feature Request

Problem

I found a use-case where I wanted a Container Linux Config to contain a systemd unit that refered to coreos-metadata.

[Unit]
Requires=coreos-metadata.service                                                                                                                                                                       
After=coreos-metadata.service
[Service]
EnvironmentFile=/run/metadata/coreos

I thought I'd try ct's "dynamic data" feature where it adds those lines for you based on a {PRIVATE_IPV4} or {PUBLIC_IPV4} reference. I was surprised this didn't work and just wrote the change myself.

Environment

Cloud Providers

Desired Feature

Dynamic data docs that say "In specific sections of a config, users can enter in dynamic data between {} ... Currently, the etcd and flannel sections are the only ones which support this feature."

It would be valuable to support this substitution in the systemd section.

Other Information.

Maybe we just clearly document how to reference coreos-metadata directly, without the magic? I knew this feature existed and I still kinda found it opaque to find and use and read in configs. It also seems a bit odd its specific to certain apps right now and more clusters these days run etcd and flannel as pods anyway. If that's not the desired direction, no worries, just a thought.

cc @dgonyeo

[dghubble]

Pondering this issue further, the dynamic data feature isn't so compelling in my opinion. It saves adding 3 lines to a systemd unit in some cases, but the magic {PRIVATE_IPV4}, etc. is limited.

[Unit]
Requires=coreos-metadata.service                                                                                                                                                                       
After=coreos-metadata.service
[Service]
EnvironmentFile=/run/metadata/coreos

First, a user has to learn that we have this special mapping over the normal metadata values and find this page. Then that it only works in some sections. Then, if you want to reference the 2nd NIC or other metadata values, you end up writing it yourself anyway.

What about a simple paragraph showing the above snippet for how to require coreos-metadata.service and a table that simply lists the fields available on each provider? Or we add aliases PRIVATE_IPV4 and PUBLIC_IPV4 when writing /run/metadata/coroes if having a uniform name is truly a concern?

[crawford]

@dghubble It might be enough to surface the metadata documentation.

[stuart-warren]

We really want to use the same container linux config cross cloud, so this is quite a pain having to pre process services to refer to the correct environment variable name. COREOS_OPENSTACK_IPV4_LOCAL or COREOS_EC2_IPV4_LOCAL

I'd be happy with aliases in /run/metadata/coreos

[crawford]

@dgonyeo Can you take a look at this? It would be great to be able to use these variables.

[nealeu]

Hi,
I'm just getting going on Ignition and CoreOS and have found my way here to the feature I'm looking for: I just want templating to work and for there to be aliases.

Why should there be a difference between local dev with Vagrant vs deployment to vmware or a could provider?

The documentation gives no reason why the environment variables vary by provider rather than just being present or not.

Has something else happened that this feature requirement has gone away?

If not, can you please add aliases in.

Thanks.

[crawford]

The docs should be updated, but the short of it is: what would those cross-platform variables be called? Public and private? Easy enough. But what happens if the platform doesn't have the notion of a private address? What about platforms that have multiple notions of "public" addresses (e.g. Azure's PIP vs VIP)? We decided early on that it was best to be explicit and force the user to make a decision rather than being implicit and potentially getting it wrong.

[nealeu]

Thanks @crawford.

And as this is where people may end up when searching, I'll pop in my little hack, which may get peeps something they want on the mix of platforms they're using :)

    - name: metadata-happiness.service
      enabled: true
      contents: |
        [Unit]
        Description=Publish cleaned up coreos-metadata
        Requires=coreos-metadata.service
        After=coreos-metadata.service

        [Service]
        Type=oneshot
        Environment=OUTPUT=/run/metadata/coreos-common
        ExecStart=/usr/bin/bash -c "cat /run/metadata/coreos | sed -e 's/COREOS_[^_]*_//' | sed -e 's/VIRTUALBOX_//' > ${OUTPUT}"

        [Install]
        WantedBy=multi-user.target