Support for units and write_files

[rosskukulinski]

Cloud config files support two additional parameters that are useful for customizing systems:

• coreos.units
• write_files

The coreos.units.* parameters define a list of arbitrary systemd units to start after booting. This feature is intended to help you start essential services required to mount storage and configure networking in order to join the CoreOS cluster.

The write_files directive defines a set of files to create on the local filesystem.

We should support passing in this data -- I'm just not sure the preferred format. I guess JSON object like you've done elsewhere, @kenperkins?

[kenperkins]

Good question. Should write_files be pointed at base64 encoded file contents? or pointers to fs paths? or both? Optionally point to web available files that does the work for you?

I'm going to need a refresher on a unit example.

[rosskukulinski]

@kenperkins here's an example of write_files and units: https://gist.github.com/rosskukulinski/69fb3a66c53d08c587b9

I think pointer to fs paths or just json string w/ newlines. We could start simple and just be fs path

[kenperkins]

how do the units get on the machine tho?

[rosskukulinski]

This is how the fixup_etc.sh script gets put onto the file system

write_files:
  - path: /root/bin/fixup_etc.sh
    permissions: 0755
    content: |
      #!/bin/bash -e
      source /etc/environment
      mkdir -p /etc/systemd/system/etcd.service.d
      cat > /etc/systemd/system/etcd.service.d/50-speakit.conf <<EOF
      [Service]
      Environment="ETCD_ADDR=${RAX_PRIVATENET_IPV4}:4001"
      Environment="ETCD_PEER_ADDR=${RAX_PRIVATENET_IPV4}:7001"
      EOF
      systemctl daemon-reload
      systemctl restart etcd.service

and then this is how the service (unit) that runs fixup_etc.sh gets loaded into systemd:

 units:
    - name: etcd.service
      command: start
    - name: fleet.service
      command: start

    - name: rax_ip_env.service
      command: start
      content: |
        [Unit]
        Description=Configure /etc/environment variables for Rackspace networks on etcd
        After=network-online.target
        Requires=ntpd.service network-online.target

        [Service]
        Type=oneshot
        RemainAfterExit=yes
        ExecStart=/root/bin/rax_ips.sh
        ExecStart=/root/bin/fixup_etc.sh

[kenperkins]

OK so it's assumed (enforced) that write_files happens first, and then you can define units with the results of that.

[rosskukulinski]

that is accurate

[kenperkins]

How often do you create a unit without a file?

[rosskukulinski]

often enough that they shouldn't be tied together. In a related tangent, upon further reading of the docs, I see that they've added a 'drop_ins' option to units:

#cloud-config

coreos:
  units:
    - name: docker.service
      drop-ins:
        - name: 50-insecure-registry.conf
          content: |
            [Service]
            Environment=DOCKER_OPTS='--insecure-registry="10.0.1.0/24"'

Originally from this Issue: https://github.com/coreos/coreos-cloudinit/issues/108

What's odd to me is that most of the advanced file options are missing :confused:

[kenperkins]

So, we could introduce a File model and a Unit model that allows you to define them before creating your cluster.

[rosskukulinski]

After talking with with bcwaldon from CoreOS team, we should use write_files & unit. drop-ins are used when you want to extend a unit file that already exists on the filesystem

[osterman]

I think it would be adequate to have a --cloud-init-file parameter that would let you append arbitrary [cloud-init] sytax to end of the cloud-init contents automatically generated by coreos-cluster library and submitted to the API.

[kenperkins]

@osterman Are you advocating for what the interface could be in https://github.com/kenperkins/coreos-cluster-cli?

[osterman]

@kenperkins yes, thanks for clarifying. What I'm describing is how I'd envision the coreos-cluster-cli working.