2014-04-24 01:38:54 +04:00
|
|
|
[Unit]
|
2014-05-23 02:06:10 +04:00
|
|
|
Description=Load cloud-config from /media/configdrive
|
2014-04-24 01:38:54 +04:00
|
|
|
Requires=coreos-setup-environment.service
|
2014-06-28 01:25:07 +04:00
|
|
|
After=coreos-setup-environment.service system-config.target
|
2014-04-24 01:38:54 +04:00
|
|
|
Before=user-config.target
|
|
|
|
|
|
|
|
|
|
# HACK: work around ordering between config drive and ec2 metadata It is
|
|
|
|
|
# possible for OpenStack style systems to provide both the metadata service
|
|
|
|
|
# and config drive, to prevent the two from stomping on eachother force
|
|
|
|
|
# this to run after OEM and after metadata (if it exsts). I'm doing this
|
|
|
|
|
# here instead of in the ec2 service because the ec2 unit is not written
|
|
|
|
|
# to disk until the OEM cloud config is evaluated and I want to make sure
|
|
|
|
|
# systemd knows about the ordering as early as possible.
|
|
|
|
|
# coreos-cloudinit could implement a simple lock but that cannot be used
|
|
|
|
|
# until after the systemd dbus calls are made non-blocking.
|
|
|
|
|
After=ec2-cloudinit.service
|
|
|
|
|
|
|
|
|
|
[Service]
|
|
|
|
|
Type=oneshot
|
|
|
|
|
RemainAfterExit=yes
|
|
|
|
|
EnvironmentFile=-/etc/environment
|
2014-05-23 02:06:10 +04:00
|
|
|
ExecStart=/usr/bin/coreos-cloudinit --from-configdrive=/media/configdrive
|
