Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

checking existance before creating certs #147

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

s0rc3r3r01
Copy link

added logic that checks for the availability of the files on s3 before recreating them. If they are on S3 it simply downloads them, without recreation.

…e recreating them. If they are on S3 it simply downloads them, without recreation.
@wellsie
Copy link
Member

wellsie commented Apr 27, 2017

not working for me

Apr 27 13:20:40 localhost systemd[1]: Starting Cloudinit from EC2-style metadata...
Apr 27 13:20:40 localhost coreos-cloudinit[875]: 2017/04/27 13:20:40 Checking availability of "cloud-drive"
Apr 27 13:20:40 localhost coreos-cloudinit[875]: 2017/04/27 13:20:40 Checking availability of "ec2-metadata-service"
Apr 27 13:20:40 localhost coreos-cloudinit[875]: 2017/04/27 13:20:40 Fetching user-data from datasource of type "ec2-metadata-service"
Apr 27 13:20:40 localhost coreos-cloudinit[875]: 2017/04/27 13:20:40 Fetching data from http://169.254.169.254/2009-04-04/user-data. Attempt #1
Apr 27 13:20:40 localhost coreos-cloudinit[875]: 2017/04/27 13:20:40 line 43: error: did not find expected key
Apr 27 13:20:40 localhost coreos-cloudinit[875]: 2017/04/27 13:20:40 line 0: warning: incorrect type for "" (want struct)
Apr 27 13:20:40 localhost coreos-cloudinit[875]: 2017/04/27 13:20:40 Fetching meta-data from datasource of type "ec2-metadata-service"
Apr 27 13:20:40 localhost coreos-cloudinit[875]: 2017/04/27 13:20:40 Fetching data from http://169.254.169.254/2009-04-04/meta-data/public-keys. Attempt #1
Apr 27 13:20:40 localhost coreos-cloudinit[875]: 2017/04/27 13:20:40 Fetching data from http://169.254.169.254/2009-04-04/meta-data/public-keys/0/openssh-key. Attempt #1
Apr 27 13:20:40 localhost coreos-cloudinit[875]: 2017/04/27 13:20:40 Found SSH key for "kz8s-test"
Apr 27 13:20:40 localhost coreos-cloudinit[875]: 2017/04/27 13:20:40 Fetching data from http://169.254.169.254/2009-04-04/meta-data/hostname. Attempt #1
Apr 27 13:20:40 localhost coreos-cloudinit[875]: 2017/04/27 13:20:40 Fetching data from http://169.254.169.254/2009-04-04/meta-data/local-ipv4. Attempt #1
Apr 27 13:20:40 localhost coreos-cloudinit[875]: 2017/04/27 13:20:40 Fetching data from http://169.254.169.254/2009-04-04/meta-data/public-ipv4. Attempt #1
Apr 27 13:20:40 localhost coreos-cloudinit[875]: 2017/04/27 13:20:40 Parsing user-data as cloud-config
Apr 27 13:20:40 localhost coreos-cloudinit[875]: Failed to parse user-data: YAML error: line 43: did not find expected key
Apr 27 13:20:40 localhost coreos-cloudinit[875]: Continuing...
Apr 27 13:20:40 localhost coreos-cloudinit[875]: 2017/04/27 13:20:40 Merging cloud-config from meta-data and user-data
Apr 27 13:20:40 ip-10-0-10-68.us-west-2.compute.internal coreos-cloudinit[875]: 2017/04/27 13:20:40 Set hostname to ip-10-0-10-68.us-west-2.compute.internal
Apr 27 13:20:41 ip-10-0-10-68.us-west-2.compute.internal coreos-cloudinit[875]: 2017/04/27 13:20:41 Authorized SSH keys for core user
Apr 27 13:20:41 ip-10-0-10-68.us-west-2.compute.internal coreos-cloudinit[875]: 2017/04/27 13:20:41 Writing file to "/etc/environment"
Apr 27 13:20:41 ip-10-0-10-68.us-west-2.compute.internal coreos-cloudinit[875]: 2017/04/27 13:20:41 Wrote file to "/etc/environment"
Apr 27 13:20:41 ip-10-0-10-68.us-west-2.compute.internal coreos-cloudinit[875]: 2017/04/27 13:20:41 Updated /etc/environment
Apr 27 13:20:41 ip-10-0-10-68.us-west-2.compute.internal coreos-cloudinit[875]: 2017/04/27 13:20:41 Ensuring runtime unit file "etcd.service" is unmasked
Apr 27 13:20:41 ip-10-0-10-68.us-west-2.compute.internal coreos-cloudinit[875]: 2017/04/27 13:20:41 Ensuring runtime unit file "etcd2.service" is unmasked
Apr 27 13:20:41 ip-10-0-10-68.us-west-2.compute.internal coreos-cloudinit[875]: 2017/04/27 13:20:41 Ensuring runtime unit file "fleet.service" is unmasked
Apr 27 13:20:41 ip-10-0-10-68.us-west-2.compute.internal coreos-cloudinit[875]: 2017/04/27 13:20:41 Ensuring runtime unit file "locksmithd.service" is unmasked
Apr 27 13:20:41 ip-10-0-10-68.us-west-2.compute.internal systemd[1]: oem-cloudinit.service: Main process exited, code=exited, status=1/FAILURE
Apr 27 13:20:41 ip-10-0-10-68.us-west-2.compute.internal systemd[1]: Failed to start Cloudinit from EC2-style metadata.
Apr 27 13:20:41 ip-10-0-10-68.us-west-2.compute.internal systemd[1]: oem-cloudinit.service: Unit entered failed state.
Apr 27 13:20:41 ip-10-0-10-68.us-west-2.compute.internal systemd[1]: oem-cloudinit.service: Failed with result 'exit-code'.

@s0rc3r3r01
Copy link
Author

I've fixed the yaml indentation and tested it. It now works. The "issue" is that even if "it works" as expected some units fail on the first boot, the ones that get the files from s3 this is kind of expected behaviour even if not nice to see. Does anyone have any idea on how to fix it ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants