diff --git a/units/user-cloudinit@media-configdrive-openstack-latest-user_data.service b/units/user-cloudinit@media-configdrive-openstack-latest-user_data.service
new file mode 100644
index 0000000..6251821
--- /dev/null
+++ b/units/user-cloudinit@media-configdrive-openstack-latest-user_data.service
@@ -0,0 +1,24 @@
+[Unit]
+Description=Load cloud-config from %f
+Requires=coreos-setup-environment.service
+After=coreos-setup-environment.service
+Before=user-config.target
+ConditionFileNotEmpty=%f
+
+# 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=system-cloudinit@usr-share-oem-cloud\x2dconfig.yml.service
+After=ec2-cloudinit.service
+
+[Service]
+Type=oneshot
+RemainAfterExit=yes
+EnvironmentFile=-/etc/environment
+ExecStart=/usr/bin/coreos-cloudinit --from-file=%f