From 96370ac5b9bab147c0bd307de288a07a0117b35c Mon Sep 17 00:00:00 2001 From: Rob Szumski Date: Mon, 14 Jul 2014 16:16:14 -0700 Subject: [PATCH] feat(docs): add syntax highlighting --- Documentation/cloud-config-oem.md | 4 ++-- Documentation/cloud-config.md | 30 +++++++++++++++--------------- Documentation/config-drive.md | 20 ++++++++++++-------- 3 files changed, 29 insertions(+), 25 deletions(-) diff --git a/Documentation/cloud-config-oem.md b/Documentation/cloud-config-oem.md index 09fc626..f5eb241 100644 --- a/Documentation/cloud-config-oem.md +++ b/Documentation/cloud-config-oem.md @@ -13,7 +13,7 @@ If no **id** field is provided, coreos-cloudinit will ignore this section. For example, the following cloud-config document... -``` +```yaml #cloud-config coreos: oem: @@ -26,7 +26,7 @@ coreos: ...would be rendered to the following `/etc/oem-release`: -``` +```yaml ID=rackspace NAME="Rackspace Cloud Servers" VERSION_ID=168.0.0 diff --git a/Documentation/cloud-config.md b/Documentation/cloud-config.md index c4531c6..5dab25c 100644 --- a/Documentation/cloud-config.md +++ b/Documentation/cloud-config.md @@ -42,7 +42,7 @@ CoreOS tries to conform to each platform's native method to provide user data. E The `coreos.etcd.*` parameters will be translated to a partial systemd unit acting as an etcd configuration file. We can use the templating feature of coreos-cloudinit to automate etcd configuration with the `$private_ipv4` and `$public_ipv4` fields. For example, the following cloud-config document... -``` +```yaml #cloud-config coreos: @@ -57,7 +57,7 @@ coreos: ...will generate a systemd unit drop-in like this: -``` +```yaml [Service] Environment="ETCD_NAME=node001" Environment="ETCD_DISCOVERY=https://discovery.etcd.io/" @@ -74,7 +74,7 @@ Note that hyphens in the coreos.etcd.* keys are mapped to underscores. The `coreos.fleet.*` parameters work very similarly to `coreos.etcd.*`, and allow for the configuration of fleet through environment variables. For example, the following cloud-config document... -``` +```yaml #cloud-config coreos: @@ -85,7 +85,7 @@ coreos: ...will generate a systemd unit drop-in like this: -``` +```yaml [Service] Environment="FLEET_PUBLIC_IP=203.0.113.29" Environment="FLEET_METADATA=region=us-west" @@ -114,7 +114,7 @@ The `reboot-strategy` parameter also affects the behaviour of [locksmith](https: ##### Example -``` +```yaml #cloud-config coreos: update: @@ -138,7 +138,7 @@ The `coreos.units.*` parameters define a list of arbitrary systemd units to star Write a unit to disk, automatically starting it. -``` +```yaml #cloud-config coreos: @@ -159,7 +159,7 @@ coreos: Start the built-in `etcd` and `fleet` services: -``` +```yaml #cloud-config coreos: @@ -177,7 +177,7 @@ The `ssh_authorized_keys` parameter adds public SSH keys which will be authorize The keys will be named "coreos-cloudinit" by default. Override this by using the `--ssh-key-name` flag when calling `coreos-cloudinit`. -``` +```yaml #cloud-config ssh_authorized_keys: @@ -189,7 +189,7 @@ ssh_authorized_keys: The `hostname` parameter defines the system's hostname. This is the local part of a fully-qualified domain name (i.e. `foo` in `foo.example.com`). -``` +```yaml #cloud-config hostname: coreos1 @@ -222,7 +222,7 @@ The following fields are not yet implemented: - **selinux-user**: Corresponding SELinux user - **ssh-import-id**: Import SSH keys by ID from Launchpad. -``` +```yaml #cloud-config users: @@ -261,7 +261,7 @@ Using a higher number of rounds will help create more secure passwords, but give Using the `coreos-ssh-import-github` field, we can import public SSH keys from a GitHub user to use as authorized keys to a server. -``` +```yaml #cloud-config users: @@ -274,7 +274,7 @@ users: We can also pull public SSH keys from any HTTP endpoint which matches [GitHub's API response format](https://developer.github.com/v3/users/keys/#list-public-keys-for-a-user). For example, if you have an installation of GitHub Enterprise, you can provide a complete URL with an authentication token: -``` +```yaml #cloud-config users: @@ -284,7 +284,7 @@ users: You can also specify any URL whose response matches the JSON format for public keys: -``` +```yaml #cloud-config users: @@ -304,7 +304,7 @@ The `write-file` parameter defines a list of files to create on the local filesy Explicitly not implemented is the **encoding** attribute. The **content** field must represent exactly what should be written to disk. -``` +```yaml #cloud-config write_files: - path: /etc/fleet/fleet.conf @@ -321,7 +321,7 @@ Currently, the only supported value is "localhost" which will cause your system' to resolve to "127.0.0.1". This is helpful when the host does not have DNS infrastructure in place to resolve its own hostname, for example, when using Vagrant. -``` +```yaml #cloud-config manage_etc_hosts: localhost diff --git a/Documentation/config-drive.md b/Documentation/config-drive.md index ef4c9bf..2c7995f 100644 --- a/Documentation/config-drive.md +++ b/Documentation/config-drive.md @@ -14,17 +14,21 @@ The image should be a single FAT or ISO9660 file system with the label For example, to wrap up a config named `user_data` in a config drive image: - mkdir -p /tmp/new-drive/openstack/latest - cp user_data /tmp/new-drive/openstack/latest/user_data - mkisofs -R -V config-2 -o configdrive.iso /tmp/new-drive - rm -r /tmp/new-drive +```sh +mkdir -p /tmp/new-drive/openstack/latest +cp user_data /tmp/new-drive/openstack/latest/user_data +mkisofs -R -V config-2 -o configdrive.iso /tmp/new-drive +rm -r /tmp/new-drive +``` ## QEMU virtfs One exception to the above, when using QEMU it is possible to skip creating an image and use a plain directory containing the same contents: - qemu-system-x86_64 \ - -fsdev local,id=conf,security_model=none,readonly,path=/tmp/new-drive \ - -device virtio-9p-pci,fsdev=conf,mount_tag=config-2 \ - [usual qemu options here...] +```sh +qemu-system-x86_64 \ + -fsdev local,id=conf,security_model=none,readonly,path=/tmp/new-drive \ + -device virtio-9p-pci,fsdev=conf,mount_tag=config-2 \ + [usual qemu options here...] +```