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

Modify Afterburn openstack defaults to try config-drive, then metadata service #422

Closed
jamescassell opened this issue Mar 13, 2020 · 6 comments · Fixed by coreos/afterburn#462

Comments

@jamescassell
Copy link
Collaborator

The afterburn folks think this is "not a bug": coreos/afterburn#373

We should work around it here, and attempt to get SSH keys from MD service, especially if no IGN is provided.

See also about hostname: openshift/machine-config-operator#964 (comment)

State: idle
AutomaticUpdates: disabled
Deployments:
* ostree://fedora:fedora/x86_64/coreos/testing
                   Version: 31.20200310.2.0 (2020-03-12T01:21:36Z)
                    Commit: fef0f5a226ebf0e9915d8ee03a3bc70d3cc0593f0c22841264b3bc906dff0957
              GPGSignature: Valid signature by 7D22D5867F2A4236474BF7B850CB390B3C3359C4
@dustymabe
Copy link
Member

We discussed this in the meeting today:

13:54:19     dustymabe | #agreed modify afterburn to only know about `openstack` and in that mode, read from the config drive first
                       | then fallback to fetch from metadata server

@dustymabe dustymabe changed the title Booting on OpenStack does not retrieve SSH keys from MD service Modify Afterburn defaults to try config-drive, then metadata service without configuration Apr 1, 2020
@dustymabe dustymabe added jira for syncing to jira and removed meeting topics for meetings labels Apr 1, 2020
@dustymabe dustymabe changed the title Modify Afterburn defaults to try config-drive, then metadata service without configuration Modify Afterburn defaults to try config-drive, then metadata service Apr 1, 2020
@dustymabe dustymabe changed the title Modify Afterburn defaults to try config-drive, then metadata service Modify Afterburn openstack defaults to try config-drive, then metadata service Apr 1, 2020
@stamak
Copy link

stamak commented May 29, 2020

@dustymabe any update on this?
thx

@dustymabe
Copy link
Member

@stamak - not currently. It's decided what the path forward is but we haven't had time to implement it yet. Stay tuned

zonggen pushed a commit to zonggen/afterburn that referenced this issue Jul 22, 2020
This changes afterburn to use config-drive as default for scraping
metadata and then try metadata API if config-drive is not available.
Also changes the name of the platform from `openstack-metadata` to
`openstack`.

Closes: coreos/fedora-coreos-tracker#422
Signed-off-by: Allen Bai <abai@redhat.com>
zonggen pushed a commit to zonggen/afterburn that referenced this issue Jul 22, 2020
This changes afterburn to use config-drive as default for scraping
metadata and then try metadata API if config-drive is not available.
Also changes the name of the platform from `openstack-metadata` to
`openstack`.

Closes: coreos/fedora-coreos-tracker#422
Signed-off-by: Allen Bai <abai@redhat.com>
zonggen pushed a commit to zonggen/afterburn that referenced this issue Jul 29, 2020
This changes afterburn to use config-drive as default for scraping
metadata and then try metadata API if config-drive is not available.
Previously supported platform id 'openstack-metadata' will continue
to be supported.

Closes: coreos/fedora-coreos-tracker#422
Signed-off-by: Allen Bai <abai@redhat.com>
zonggen pushed a commit to zonggen/afterburn that referenced this issue Jul 30, 2020
This changes afterburn to use config-drive as default for scraping
metadata and then try metadata API if config-drive is not available.
Previously supported platform id 'openstack-metadata' will continue
to be supported.

Closes: coreos/fedora-coreos-tracker#422
Signed-off-by: Allen Bai <abai@redhat.com>
zonggen pushed a commit to zonggen/afterburn that referenced this issue Jul 30, 2020
This changes afterburn to use config-drive as default for scraping
metadata and then try metadata API if config-drive is not available.
Previously supported platform id 'openstack-metadata' will continue
to be supported.

Closes: coreos/fedora-coreos-tracker#422
Signed-off-by: Allen Bai <abai@redhat.com>
zonggen pushed a commit to zonggen/afterburn that referenced this issue Jul 31, 2020
This changes afterburn to use config-drive as default for scraping
metadata and then try metadata API if config-drive is not available.
Previously supported platform id 'openstack-metadata' will continue
to be supported.

Closes: coreos/fedora-coreos-tracker#422
Signed-off-by: Allen Bai <abai@redhat.com>
@dustymabe dustymabe added the status/pending-upstream-release Fixed upstream. Waiting on an upstream component source code release. label Aug 3, 2020
erlarese pushed a commit to erlarese/afterburn that referenced this issue Aug 5, 2020
This changes afterburn to use config-drive as default for scraping
metadata and then try metadata API if config-drive is not available.
Previously supported platform id 'openstack-metadata' will continue
to be supported.

Closes: coreos/fedora-coreos-tracker#422
Signed-off-by: Allen Bai <abai@redhat.com>
@lucab
Copy link
Contributor

lucab commented Aug 12, 2020

This has been implemented by @zonggen in coreos/afterburn#462 and released as part of Afterburn 4.5.0.

@lucab lucab removed the status/pending-upstream-release Fixed upstream. Waiting on an upstream component source code release. label Aug 12, 2020
@dustymabe dustymabe added the status/pending-testing-release Fixed upstream. Waiting on a testing release. label Aug 12, 2020
@dustymabe
Copy link
Member

The fix for this went into testing stream release 32.20200824.2.0. Please try out the new release and report issues.

@dustymabe dustymabe added status/pending-stable-release Fixed upstream and in testing. Waiting on stable release. and removed status/pending-testing-release Fixed upstream. Waiting on a testing release. labels Aug 30, 2020
@dustymabe
Copy link
Member

The fix for this went into stable stream release 32.20200824.3.0. Please try out the new release and report issues.

@dustymabe dustymabe removed the status/pending-stable-release Fixed upstream and in testing. Waiting on stable release. label Sep 9, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants