How to Use CoreOS on OpenStack

[Jon A]

Hello,

How do you configure an ssh key for CoreOS when it's being used in OpenStack.  Unfortunately, we don't have any CLI tools as we are using the VMware Integrated Openstack flavor.  However, it provides all the same endpoints, so it should be able to work from the VIO GUI.

I found two guides on how to do this:

  - http://blog.scottlowe.org/2014/08/13/deploying-coreos-on-openstack-using-heat/

  - http://lollyrock.com/articles/coreos-openstack/

However, neither of these solutions seem to work.

I've tried selecting the user key on the "Access and Security" input page when creating the instance which is the same as specifying the ssh key parameter in the HEAT template and I have tried creating a "user data" section equal to:

ssh_authorized_keys:

  - ssh-rsa <my ssh key> my-ssh-key-commnet

Finally, I tried creating a HEAT template and set my ssh key both as the ssh_key parameter and then in the User Data section.

Unfortunately, as there is no way to login, I can't login to see if the key has been uploaded but is being somehow malformed...

Is there a way to boot into single user mode and set a password?

Why does CoreOS not honor the SSH key parameter from HEAT templates?

Any suggestions would be greatly appreciated.

Thanks,

Jon A

[Rob Szumski]

Your user-data must contain “#cloud-config” as the first line for it to be processed as cloud-config. Did you omit this?

Side note: there is a validator at https://coreos.com/validate/

 - Rob

[Jon]

Hi Rob,

Thanks for your reply.  It's always the simple things! :)  Thanks to the link to the validator.  That's a big help.

I did omit this in my inital testing, unfortunately adding that line, while allowing it to pass the validation, does not upload the key to my OpenStack instance.  I've tried both "core" and "root" users.

My UserData is now:

#cloud-config

ssh_authorized_keys:

  - ssh-rsa <ssh key> my-coreos-sshkey

Is there any way to troubleshoot an instance?

Why does CoreOS not honor the ssh_key parameter?

Thanks again for the quick reply!

Best Regards,

Jon A

[Jon]

Hello,

I was able to login to CoreOS by getting into grub and setting "coreos.autologin=tty1".

I can now confirm that there is a /home/core/.ssh directory created but the authorized_keys file is definitely not being set.

Are there any cloud-config logs that might be able to provide some insight as to why I'm not pulling the SSH keys?

Thanks,

Jon A

[Rob Szumski]

A frequent problem with Openstack is how the metadata service is configured, which CoreOS uses to grab your cloud-config. I’m not sure how the VMware flavor affects this...

The two locations that are checked are:

/media/configvirtfs/openstack/latest/user_data

/media/configdrive/openstack/latest/user_data

If you’re using EC2-compatible metadata it is:

http://169.254.169.254/metadata/v1/user-data

Can you curl those locations and see if you are returned user-data? Additionally, you can view the cloudinit log with `sudo journalctl _EXE=/usr/bin/coreos-cloudinit`. That will probably highlight the failure.

More docs: https://coreos.com/os/docs/latest/cloud-config-locations.html

--
You received this message because you are subscribed to the Google Groups "CoreOS User" group.
To unsubscribe from this group and stop receiving emails from it, send an email to coreos-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alex Crawford]

On 02/18, Jon wrote:
> I can now confirm that there is a /home/core/.ssh directory created but the
> authorized_keys file is definitely not being set.

You _might_ be running into a recent coreos-cloudinit regression [1]. It might
be worth trying the Beta image temporarily (I'm not sure which version you are
using).

> Are there any cloud-config logs that might be able to provide some insight
> as to why I'm not pulling the SSH keys?

Try this:

journalctl -b -t coreos-cloudinit --no-pager

-Alex

[1]: https://github.com/coreos/bugs/issues/1120

[Jon]

Hello All,

Thanks for the tips in troubleshooting.  So it looks like CoreOS is never calling out to get the data from the metadata service.  Though, I'm at a loss to explain why.  

My meta data is definitely available:

>> localhost ~ # wget http://169.254.169.254/2009-04-04/user-data

>> --2016-02-22 18:43:55--  http://169.254.169.254/2009-04-04/user-data

>> Connecting to 169.254.169.254:80... connected.

>> HTTP request sent, awaiting response... 200 OK

>> Length: 438 [text/plain]

>> Saving to: 'user-data'

>> 

>> user-data                     100%[===================================================>]     438  --.-KB/s   in 0s

>> 

>> 2016-02-22 18:43:56 (37.5 MB/s) - 'user-data' saved [438/438]

>> 

>> localhost ~ # cat user-data

>> #cloud-config

>> 

>> ssh_authorized_keys:

>>   - ssh-rsa <ssh key> opnestack-userdata

I believe I'm using the current stable version:

>> localhost ~ # cat /etc/oem-release

>> ID=vmware

>> VERSION_ID=9.10.0-r3

>> NAME="VMWare"

>> HOME_URL=""

>> BUG_REPORT_URL="https://github.com/coreos/bugs/issues"

For the purposes of testing I can try the Beta image, but the issue Alex linked seems to deal with iPXE.

This is my cloud-config.yaml...  Should there be some kind of stanza that tells it to pull openstack data, or does cloud-config magically know to do this already?

>> localhost ~ # cat /usr/share/oem/cloud-config.yml

>> #cloud-config

>> 

>> coreos:

>>   units:

>>     - name: vmtoolsd.service

>>       command: start

>>       content: |

>>         [Unit]

>>         Description=VMware Tools Agent

>>         Documentation=http://open-vm-tools.sourceforge.net/

>>         ConditionVirtualization=vmware

>> 

>>         [Service]

>>         ExecStartPre=/usr/bin/ln -sfT /usr/share/oem/vmware-tools /etc/vmware-tools

>>         ExecStart=/usr/share/oem/bin/vmtoolsd

>>         TimeoutStopSec=5

>> 

>>     - name: oem-cloudinit.service

>>       command: restart

>>       runtime: yes

>>       content: |

>>         [Unit]

>>         Description=Cloudinit from VMware Backdoor

>> 

>>         [Service]

>>         Type=oneshot

>>         ExecStart=/usr/bin/coreos-cloudinit --oem=vmware

>> 

>>   oem:

>>     bug-report-url: "https://github.com/coreos/bugs/issues"

>>     id: vmware

>>     name: VMWare

>>     version-id: "9.10.0-r3"

It definitely appears to be working correctly, save the lack of openstack data...

>> localhost ~ # coreos-cloudinit --from-file=/usr/share/oem/cloud-config.yml

>> 2016/02/22 18:46:17 Checking availability of "local-file"

>> 2016/02/22 18:46:17 Fetching user-data from datasource of type "local-file"

>> 2016/02/22 18:46:17 Fetching meta-data from datasource of type "local-file"

>> 2016/02/22 18:46:17 Parsing user-data as cloud-config

>> 2016/02/22 18:46:17 Merging cloud-config from meta-data and user-data

>> 2016/02/22 18:46:17 Writing file to "/etc/oem-release"

>> 2016/02/22 18:46:17 Wrote file to "/etc/oem-release"

>> 2016/02/22 18:46:17 Wrote file /etc/oem-release to filesystem

>> 2016/02/22 18:46:17 Writing unit "vmtoolsd.service" to filesystem

>> 2016/02/22 18:46:17 Writing file to "/etc/systemd/system/vmtoolsd.service"

>> 2016/02/22 18:46:17 Wrote file to "/etc/systemd/system/vmtoolsd.service"

>> 2016/02/22 18:46:17 Wrote unit "vmtoolsd.service"

>> 2016/02/22 18:46:17 Writing unit "oem-cloudinit.service" to filesystem

>> 2016/02/22 18:46:17 Writing file to "/run/systemd/system/oem-cloudinit.service"

>> 2016/02/22 18:46:17 Wrote file to "/run/systemd/system/oem-cloudinit.service"

>> 2016/02/22 18:46:17 Wrote unit "oem-cloudinit.service"

>> 2016/02/22 18:46:17 Ensuring runtime unit file "oem-cloudinit.service" is unmasked

>> 2016/02/22 18:46:17 /run/systemd/system/oem-cloudinit.service is not null or empty, refusing to unmask

>> 2016/02/22 18:46:17 Ensuring runtime unit file "etcd.service" is unmasked

>> 2016/02/22 18:46:17 Ensuring runtime unit file "etcd2.service" is unmasked

>> 2016/02/22 18:46:17 Ensuring runtime unit file "fleet.service" is unmasked

>> 2016/02/22 18:46:17 Ensuring runtime unit file "locksmithd.service" is unmasked

>> 2016/02/22 18:46:17 Calling unit command "start" on "vmtoolsd.service"'

>> 2016/02/22 18:46:17 Result of "start" on "vmtoolsd.service": done

>> 2016/02/22 18:46:17 Calling unit command "restart" on "oem-cloudinit.service"'

>> 2016/02/22 18:46:17 Result of "restart" on "oem-cloudinit.service": done

I tried googling "coreos openstack cloud-config yaml" but that only takes me to the "cloud-config file locations" page...  I tried using the OpenStack CoreOS image, but I get a "500 error" from OpenStack when instantiating instances...  (trying to troubleshoot that, but I can literally think of nothing more painful...)

I appreciate any help.

Thanks,

Jon A

[Alex Crawford]

On 02/22, Jon wrote:
> I believe I'm using the current stable version:
> >> localhost ~ # cat /etc/oem-release
> >> ID=vmware
> >> VERSION_ID=9.10.0-r3
> >> NAME="VMWare"
> >> HOME_URL=""
> >> BUG_REPORT_URL="https://github.com/coreos/bugs/issues"

You actually want the OpenStack image. This will load from the correct sources.

http://stable.release.core-os.net/amd64-usr/current/

-Alex

[Jon]

Hi Alex,

Just to clarify: you're confirming my suspicion that cloud-config is not set to pull from OpenStack data sources and you're saying there's no way to configure the VMware image to pull OpenStack data sources?

What if I wanted to build my own image from the ISO? (e.g. security and compliance reasons, which I think will be a requirement if we move to production with CoreOS)

Thanks,

Jon A

[Jon]

Hello All,

Can anyone confirm, does the image located at http://stable.release.core-os.net/amd64-usr/current/coreos_production_openstack_image.img.bz2 actually boot?

I've been getting an error that no OS is found and I was thinking it was an error with my OpenStack infrastructure, however, I downloaded the image, converted it to a vdi using vboxmanage, and tried to boot the image in VirtualBox, and I get the same error.

Is there something specific I need to do to be able to boot from the OpenStack Image or is it just broken?

Thanks,

Jon A

[Alex Crawford]

On 02/22, Jon wrote:
> I've been getting an error that no OS is found and I was thinking it was an
> error with my OpenStack infrastructure, however, I downloaded the image,
> converted it to a vdi using vboxmanage, and tried to boot the image in
> VirtualBox, and I get the same error.

That doesn't sound right. Would you mind filing a bug [1] so we don't forget to
look into it?

-Alex

[1]: https://github.com/coreos/bugs/issues

[Alex Crawford]

On 02/22, Jon wrote:
> Just to clarify: you're confirming my suspicion that cloud-config is not
> set to pull from OpenStack data sources and you're saying there's no way to
> configure the VMware image to pull OpenStack data sources?

Not with coreos-cloudinit, no. It will be trivial with Ignition once it supports
OpenStack (patches more than welcome).

> What if I wanted to build my own image from the ISO? (e.g. security and
> compliance reasons, which I think will be a requirement if we move to
> production with CoreOS)

What do you mean when you say "build my own image from the ISO"?

-Alex