unistack-org/cloudinit
4
0
Fork 0
Code Issues 1 Pull Requests Packages Projects Releases Wiki Activity

Merge pull request #186 from robszumski/add-highlighting

Browse Source 
feat(docs): add syntax highlighting
This commit is contained in:
Michael Marineau 2014-07-15 15:26:33 -07:00
commit 10838e001d
3 changed files with 29 additions and 25 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
Documentation/cloud-config-oem.md
View File

@ -13,7 +13,7 @@ If no **id** field is provided, coreos-cloudinit will ignore this section.
For example, the following cloud-config document... For example, the following cloud-config document...
``` ```yaml
#cloud-config #cloud-config
coreos: coreos:
oem: oem:
@ -26,7 +26,7 @@ coreos:
...would be rendered to the following `/etc/oem-release`: ...would be rendered to the following `/etc/oem-release`:
``` ```yaml
ID=rackspace ID=rackspace
NAME="Rackspace Cloud Servers" NAME="Rackspace Cloud Servers"
VERSION_ID=168.0.0 VERSION_ID=168.0.0

30
Documentation/cloud-config.md
View File

@ -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. 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... 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 #cloud-config
coreos: coreos:
@ -57,7 +57,7 @@ coreos:
...will generate a systemd unit drop-in like this: ...will generate a systemd unit drop-in like this:
``` ```yaml
[Service] [Service]
Environment="ETCD_NAME=node001" Environment="ETCD_NAME=node001"
Environment="ETCD_DISCOVERY=https://discovery.etcd.io/<token>" Environment="ETCD_DISCOVERY=https://discovery.etcd.io/<token>"
@ -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... 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 #cloud-config
coreos: coreos:
@ -85,7 +85,7 @@ coreos:
...will generate a systemd unit drop-in like this: ...will generate a systemd unit drop-in like this:
``` ```yaml
[Service] [Service]
Environment="FLEET_PUBLIC_IP=203.0.113.29" Environment="FLEET_PUBLIC_IP=203.0.113.29"
Environment="FLEET_METADATA=region=us-west" Environment="FLEET_METADATA=region=us-west"
@ -114,7 +114,7 @@ The `reboot-strategy` parameter also affects the behaviour of [locksmith](https:
##### Example ##### Example
``` ```yaml
#cloud-config #cloud-config
coreos: coreos:
update: 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. Write a unit to disk, automatically starting it.
``` ```yaml
#cloud-config #cloud-config
coreos: coreos:
@ -159,7 +159,7 @@ coreos:
Start the built-in `etcd` and `fleet` services: Start the built-in `etcd` and `fleet` services:
``` ```yaml
#cloud-config #cloud-config
coreos: 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. The keys will be named "coreos-cloudinit" by default.
Override this by using the `--ssh-key-name` flag when calling `coreos-cloudinit`. Override this by using the `--ssh-key-name` flag when calling `coreos-cloudinit`.
``` ```yaml
#cloud-config #cloud-config
ssh_authorized_keys: ssh_authorized_keys:
@ -189,7 +189,7 @@ ssh_authorized_keys:
The `hostname` parameter defines the system's hostname. 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`). This is the local part of a fully-qualified domain name (i.e. `foo` in `foo.example.com`).
``` ```yaml
#cloud-config #cloud-config
hostname: coreos1 hostname: coreos1
@ -222,7 +222,7 @@ The following fields are not yet implemented:
- **selinux-user**: Corresponding SELinux user - **selinux-user**: Corresponding SELinux user
- **ssh-import-id**: Import SSH keys by ID from Launchpad. - **ssh-import-id**: Import SSH keys by ID from Launchpad.
``` ```yaml
#cloud-config #cloud-config
users: 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. 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 #cloud-config
users: 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). 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: For example, if you have an installation of GitHub Enterprise, you can provide a complete URL with an authentication token:
``` ```yaml
#cloud-config #cloud-config
users: users:
@ -284,7 +284,7 @@ users:
You can also specify any URL whose response matches the JSON format for public keys: You can also specify any URL whose response matches the JSON format for public keys:
``` ```yaml
#cloud-config #cloud-config
users: 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. Explicitly not implemented is the **encoding** attribute.
The **content** field must represent exactly what should be written to disk. The **content** field must represent exactly what should be written to disk.
``` ```yaml
#cloud-config #cloud-config
write_files: write_files:
- path: /etc/fleet/fleet.conf - 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 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. infrastructure in place to resolve its own hostname, for example, when using Vagrant.
``` ```yaml
#cloud-config #cloud-config
manage_etc_hosts: localhost manage_etc_hosts: localhost

4
Documentation/config-drive.md
View File

@ -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: For example, to wrap up a config named `user_data` in a config drive image:
```sh
mkdir -p /tmp/new-drive/openstack/latest mkdir -p /tmp/new-drive/openstack/latest
cp user_data /tmp/new-drive/openstack/latest/user_data cp user_data /tmp/new-drive/openstack/latest/user_data
mkisofs -R -V config-2 -o configdrive.iso /tmp/new-drive mkisofs -R -V config-2 -o configdrive.iso /tmp/new-drive
rm -r /tmp/new-drive rm -r /tmp/new-drive
```
## QEMU virtfs ## QEMU virtfs
One exception to the above, when using QEMU it is possible to skip creating an 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: image and use a plain directory containing the same contents:
```sh
qemu-system-x86_64 \ qemu-system-x86_64 \
-fsdev local,id=conf,security_model=none,readonly,path=/tmp/new-drive \ -fsdev local,id=conf,security_model=none,readonly,path=/tmp/new-drive \
-device virtio-9p-pci,fsdev=conf,mount_tag=config-2 \ -device virtio-9p-pci,fsdev=conf,mount_tag=config-2 \
[usual qemu options here...] [usual qemu options here...]
```