Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1430511
Summary: | cloud init doesn't setup ssh keys for access | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Kevin Fenzi <kevin> |
Component: | cloud-init | Assignee: | Garrett Holmstrom <gholms> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 26 | CC: | adimania, apevec, awilliam, dustymabe, gholms, Jan.van.Eldik, kevin, lars, mkrizek, mruckman, robatino, shardy, s |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | AcceptedBlocker | ||
Fixed In Version: | cloud-init-0.7.9-4.fc26 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2017-03-20 22:19:49 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 1349184 |
Description
Kevin Fenzi
2017-03-08 19:59:01 UTC
Looks like cloud-init is also not setting other things from the meta-data: launching the instance with testcloud doesn't allow you to log in either. A good way to debug this sort of problem is to create a new image that has a password set on the root account. Assuming you have the image available locally, you can run set the root password to "secret" like this: virt-customize -a Fedora-Cloud-Base-26-20170308.n.0.x86_64.qcow2 --root-password password:secret ...and then upload the image to glance and boot from it. --- I tested this out locally and I can confirm the problem. There is a dependency cycle involving cloud-init.service that is causing systemd to delete the cloud-init.service job: # journalctl -u sysinit.target -b |cat -- Logs begin at Wed 2017-03-08 20:04:27 UTC, end at Wed 2017-03-08 20:07:52 UTC. -- Mar 08 20:06:18 localhost systemd[1]: Reached target System Initialization. Mar 08 20:06:19 localhost systemd[1]: Stopped target System Initialization. Mar 08 20:06:19 localhost.localdomain systemd[1]: sysinit.target: Found ordering cycle on sysinit.target/start Mar 08 20:06:19 localhost.localdomain systemd[1]: sysinit.target: Found dependency on cloud-init.service/start Mar 08 20:06:19 localhost.localdomain systemd[1]: sysinit.target: Found dependency on basic.target/start Mar 08 20:06:19 localhost.localdomain systemd[1]: sysinit.target: Found dependency on sockets.target/start Mar 08 20:06:19 localhost.localdomain systemd[1]: sysinit.target: Found dependency on dbus.socket/start Mar 08 20:06:19 localhost.localdomain systemd[1]: sysinit.target: Found dependency on sysinit.target/start Mar 08 20:06:19 localhost.localdomain systemd[1]: sysinit.target: Breaking ordering cycle by deleting job cloud-init.service/start Mar 08 20:06:21 localhost.localdomain systemd[1]: Reached target System Initialization. I think the best way of resolving this is to remove the cloud-init dependency on Before=sysinit.target. There are simply too many things that want to come *after* that point. You can see the patches I've applied against 0.7.9 for the RedHat package here: https://github.com/larsks/cloud-init/compare/0.7.9...0.7.9-patches Particularly relevant to this bz: https://github.com/larsks/cloud-init/commit/3f8d6dbbbc9ab4679a4820d7cc60265fa67807cd Testing against the 20170313 builds, I don't see this issue. (In reply to Mike Ruckman from comment #4) > Testing against the 20170313 builds, I don't see this issue. This is probably because systemd can pick/choose one of two services to remove in order to clear the dependency loop. This will most likely succeed sometimes and fail others. We need to get this fixed and are hoping to have a new rpm this week to test. I used the wrong image for this. False alarm, sorry for the noise. :( There is a scratch build @ https://koji.fedoraproject.org/koji/taskinfo?taskID=18380550 that should resolve this problem. Please give it a try and let me know if it works for you. I'm not sure I have a handy way to rebuild a cloud image with a scratch build. Will see what I can do, but if anyone else wants to test first, go for it. (In reply to Kevin Fenzi from comment #8) > I'm not sure I have a handy way to rebuild a cloud image with a scratch > build. > > Will see what I can do, but if anyone else wants to test first, go for it. hey kevin. I think the goal is to get gholms to take the srpm from that scratch build and pull the patches out of it and apply them to dist-git and build a new cloud-init for f26. cloud-init-0.7.9-4.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-83671c0fa0 cloud-init-0.7.9-4.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-83671c0fa0 ok. I tried todays rawhde cloud base: http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/CloudImages/x86_64/images/Fedora-Cloud-Base-Rawhide-20170315.n.0.x86_64.qcow2 and it does work, but it takes quite a while to come up... .. [[0;32m OK [0m] Reached target Network (Pre). Starting LSB: Bring up/down networking... [[0;1;39m INFO [0m] Network Service is not active. [[0;1;33mDEPEND[0m] Dependency failed for Wait for Network to be Configured. ... Starting Initial cloud-init job (metadata service crawler)... [ 230.547893] cloud-init[691]: Cloud-init v. 0.7.9 running 'init' at Thu, 16 Mar 2017 01:42:06 +0000. Up 11.79 seconds ... -----END SSH HOST KEY KEYS----- [ 232.955374] cloud-init[796]: Cloud-init v. 0.7.9 running 'modules:final' at Thu, 16 Mar 2017 01:45:47 +0000. Up 232.72 seconds. [ 232.957588] cloud-init[796]: Cloud-init v. 0.7.9 finished at Thu, 16 Mar 2017 01:45:47 +0000. Datasource DataSourceOpenStack [net,ver=2]. Up 232.94 seconds This is in fact probably an Alpha blocker, per criterion "Release-blocking cloud images must allow login with the user authentication configuration requested during instance creation" - https://fedoraproject.org/wiki/Fedora_26_Alpha_Release_Criteria#Expected_image_boot_behavior . https://fedoraproject.org/wiki/Releases/26/ReleaseBlocking still lists two Cloud images as release blocking for the main release cycle, regardless of the existence of two-week Atomic. Yeah, sadly I think that page is not up to date, but we can only go on what we have... so +1 blocker. Yeah, this one fits the criteria. +1 That's three votes, marking as an accepted blocker. cloud-init-0.7.9-4.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report. |