Test migration to openstack afterburn provider#2009

alejandro-ripoll · 2024-05-27T14:32:42Z

Test migration to openstack afterburn provider

Test migration to openstack afterburn provider.
Closes: flatcar/Flatcar#1445

How to use

[ describe what reviewers need to do in order to validate this PR ]

Testing done

CI: http://jenkins.infra.kinvolk.io:8080/job/container/job/packages_all_arches/4058/cldsv/

Changelog entries added in the respective changelog/ directory (user-facing change, bug fix, security fix, update)
Inspected CI output for image differences: /boot and /usr size, packages, list files for any missing binaries, kernel modules, config files, kernel modules, etc.

tormath1

I started a build to see how it goes and for you to test. We also need a changelog entry. Something like:

OpenStack: Fixed ...

tormath1 · 2024-05-27T14:43:40Z

sdk_container/src/third_party/coreos-overlay/sys-kernel/bootengine/bootengine-9999.ebuild

You might have noticed that this file is actually linked:

$ ls -l total 12 lrwxrwxrwx 1 tormath1 tormath1 22 May 22 11:52 bootengine-0.0.38-r30.ebuild -> bootengine-9999.ebuild -rw-r--r-- 1 tormath1 tormath1 1775 May 22 13:50 bootengine-9999.ebuild -rw-r--r-- 1 tormath1 tormath1 139 Oct 26 2023 metadata.xml

We usually bump the linked ebuild when we do a modification (example: e2f6180)

Done. Thanks

Hi, the changelog entry should be added to bootengine repository as part of flatcar/bootengine#96, right?
Thanks

That's ok to have it here: https://github.com/flatcar/scripts/tree/main/changelog/changes. What do you think about considering this as a change rather than a bugfixe ?
Something like:

OpenStack: Changed metadata hostname source order. The service first try with the config drive then fallback on the metadata service. (scripts#2009)

The changelog should be added in the changes section, as the source of the metadata changes in a way that we should inform the users. Should be good to go once the changelog is added.

Also, please squash the commits into one, with a clear commit message and description refering to the upstream change from the bootengine and coreos/afterburn#462.

Usually, on a new release, users read the flatcar/scripts changelog and not the bootengine part.

tormath1 · 2024-05-28T07:39:16Z

Hello @andrejro, CI is 🟢

Checking the logs, I see this:

May 27 18:27:49.026041 coreos-metadata[746]: May 27 18:27:49.025 WARN failed to locate config-drive, using the metadata service API instead
May 27 18:27:49.066829 coreos-metadata[746]: May 27 18:27:49.066 INFO Fetching http://169.254.169.254/latest/meta-data/hostname: Attempt #1
May 27 18:27:49.086081 coreos-metadata[746]: May 27 18:27:49.085 INFO Fetch successful
May 27 18:27:49.087884 coreos-metadata[746]: May 27 18:27:49.087 INFO wrote hostname ci-9999-0-1-t-ab370a5df6.novalocal to /sysroot/etc/hostname

while the current behavior is:

May 28 05:18:13.018810 coreos-metadata[748]: May 28 05:18:13.018 INFO Fetching http://169.254.169.254/latest/meta-data/hostname: Attempt #1
May 28 05:18:13.037701 coreos-metadata[748]: May 28 05:18:13.037 INFO Fetch successful
May 28 05:18:13.040184 coreos-metadata[748]: May 28 05:18:13.040 INFO wrote hostname ci-3983-0-0-n-ebad85c034.novalocal to /sysroot/etc/hostname

so it looks good - the metadata service first tries to use config-drive then it fallbacks on the metadata service. Can I ask you to test in your case? The image is available here: http://bincache.flatcar-linux.net/images/amd64/9999.0.1+tormath1-pr-2009-openstack/flatcar_production_openstack_image.img

Thanks!

github-actions · 2024-05-28T07:39:30Z

Build action triggered: https://github.com/flatcar/scripts/actions/runs/9269465483

ader1990 · 2024-05-28T08:10:56Z

Hello, we need to be careful with this breaking change, as the OpenStack config drive is created ONCE when the instance is first provisioned and the metadata inside will never change afterwards, while the HTTP metadata is changing everytime the instance properties change.

For example, the metadata contains network interfaces information - in this case, the config drive ISO gets created with the network interface information from the initial instance create and will not change if a new network interface is added to the VM.

Whereas the HTTP network metadata will change whenever such OpenStack instance (VM) network adapter is added / removed.

tormath1 · 2024-05-28T08:27:08Z

Hello, we need to be careful with this breaking change, as the OpenStack config drive is created ONCE when the instance is first provisioned and the metadata inside will never change afterwards, while the HTTP metadata is changing everytime the instance properties change.

For example, the metadata contains network interfaces information - in this case, the config drive ISO gets created with the network interface information from the initial instance create and will not change if a new network interface is added to the VM.

Whereas the HTTP network metadata will change whenever such OpenStack instance (VM) network adapter is added / removed.

Interesting. Thanks for this input! To me one will decide to use whether the config-drive whether the instance metadata service (for example in the case of @alejandro-ripoll where the HTTP metadata service is not available / reachable) - so if the user relies on the instance metadata service this one should not be impacted by this change?

ader1990 · 2024-05-28T08:31:26Z

@tormath1 This change gives precedence to the config drive, this is why it is a breaking change.

In most scenarios, it should not be an issue (other than the mentioned above, when during the lifecycle of the VM, the config drive contents diverge - are not updated vs the HTTP metadata).

Maybe we can get some input from OpenStack Flatcar users before we get this merge?

I think at this moment, the change is okay as long as it gets a proper changelog changes entry.

tormath1 · 2024-05-28T08:34:23Z

Maybe we can get some input from OpenStack Flatcar users before we get this merge?

@ader1990 yes of course, I was thinking merging this to Alpha / Beta to get feedback from Beta users before it hits Stable in a few releases from now.

tormath1 · 2024-05-28T11:59:37Z

changelog/changes/2024-05-28-openstack-configdrive.md

@@ -0,0 +1 @@
+- OpenStack: Changed metadata hostname source order. The service first try with the config drive then fallback on the metadata service. ([scripts#2009](https://github.com/flatcar/scripts/pull/2009))


Suggested change

- OpenStack: Changed metadata hostname source order. The service first try with the config drive then fallback on the metadata service. ([scripts#2009](https://github.com/flatcar/scripts/pull/2009))

- OpenStack: Changed metadata hostname source order. The service first tries with the config drive then fallback on the metadata service. ([scripts#2009](https://github.com/flatcar/scripts/pull/2009))

tormath1 · 2024-05-28T12:00:26Z

sdk_container/src/third_party/coreos-overlay/sys-kernel/bootengine/bootengine-9999.ebuild

 	KEYWORDS="~amd64 ~arm ~arm64 ~x86"
 else
-	CROS_WORKON_COMMIT="8da532c809c89a9c434ada0fa9532a1c1bf49f4c" # flatcar-master
+	CROS_WORKON_COMMIT="26f6147ef9388048edcecedba931621874f3d448" # flatcar-master


Suggested change

CROS_WORKON_COMMIT="26f6147ef9388048edcecedba931621874f3d448" # flatcar-master

CROS_WORKON_COMMIT="fb2631ce5e6a21d044c8dca73f59db01f9d5abcf" # flatcar-master

It's now merged - we can use the commit ID from the flatcar-master branch.

tormath1 · 2024-05-28T12:00:50Z

sdk_container/src/third_party/coreos-overlay/sys-kernel/bootengine/bootengine-9999.ebuild


 EAPI=7
-CROS_WORKON_PROJECT="flatcar/bootengine"
+CROS_WORKON_PROJECT="alejandro-ripoll/bootengine"


Suggested change

CROS_WORKON_PROJECT="alejandro-ripoll/bootengine"

CROS_WORKON_PROJECT="flatcar/bootengine"

It's now merged, we can switch back to the Flatcar repo.

tormath1 · 2024-05-28T12:01:34Z

changelog/updates/2024-05-26-linux-6.6.32-update.md

The Linux changes should not be there. You can update your branch then rebase your commit on it.

alejandro-ripoll · 2024-05-28T12:34:46Z

Raised #2010 including only changelog entry.
Thanks

tormath1 · 2024-05-28T12:39:31Z

Raised #2010 including only changelog entry. Thanks

@alejandro-ripoll I'm sorry, maybe I've been unclear but this PR is good. No need to close it and to open a new one with only the changelog entry.
You just need to address these comments:

alejandro-ripoll · 2024-05-29T07:03:03Z

@tormath1, sorry but I think I messed the PR up since I recreated my flatcar/scripts fork.
Now it won't let me reopen the PR since the repository that submitted it initially has been deleted.

alejandro-ripoll · 2024-05-29T12:21:53Z

Hello @andrejro, CI is 🟢

Checking the logs, I see this:
May 27 18:27:49.026041 coreos-metadata[746]: May 27 18:27:49.025 WARN failed to locate config-drive, using the metadata service API instead
May 27 18:27:49.066829 coreos-metadata[746]: May 27 18:27:49.066 INFO Fetching http://169.254.169.254/latest/meta-data/hostname: Attempt #1
May 27 18:27:49.086081 coreos-metadata[746]: May 27 18:27:49.085 INFO Fetch successful
May 27 18:27:49.087884 coreos-metadata[746]: May 27 18:27:49.087 INFO wrote hostname ci-9999-0-1-t-ab370a5df6.novalocal to /sysroot/etc/hostname
while the current behavior is:
May 28 05:18:13.018810 coreos-metadata[748]: May 28 05:18:13.018 INFO Fetching http://169.254.169.254/latest/meta-data/hostname: Attempt #1
May 28 05:18:13.037701 coreos-metadata[748]: May 28 05:18:13.037 INFO Fetch successful
May 28 05:18:13.040184 coreos-metadata[748]: May 28 05:18:13.040 INFO wrote hostname ci-3983-0-0-n-ebad85c034.novalocal to /sysroot/etc/hostname
so it looks good - the metadata service first tries to use config-drive then it fallbacks on the metadata service. Can I ask you to test in your case? The image is available here: http://bincache.flatcar-linux.net/images/amd64/9999.0.1+tormath1-pr-2009-openstack/flatcar_production_openstack_image.img

Thanks!

Tested this image on my environment and seems to be working as expected. Thanks

May 29 12:19:09 localhost systemd[1]: Starting flatcar-openstack-hostname.service - Flatcar OpenStack Metadata Hostname Agent...
May 29 12:19:09 localhost coreos-metadata[886]: May 29 12:19:09.477 INFO wrote hostname REDACTED to /sysroot/etc/hostname
May 29 12:19:09 localhost systemd[1]: flatcar-openstack-hostname.service: Deactivated successfully.
May 29 12:19:09 localhost systemd[1]: Finished flatcar-openstack-hostname.service - Flatcar OpenStack Metadata Hostname Agent.

This was referenced May 27, 2024

OpenStack: Use config-drive by default and metadata API as fallback flatcar/bootengine#96

Merged

flatcar-openstack-hostname.service not using config-drive as default for scraping metadata flatcar/Flatcar#1445

Closed

tormath1 reviewed May 27, 2024

View reviewed changes

tormath1 added the main label May 27, 2024

tormath1 reviewed May 28, 2024

View reviewed changes

tormath1 added the alpha label May 28, 2024

alejandro-ripoll closed this May 28, 2024

alejandro-ripoll mentioned this pull request May 28, 2024

OpenStack: Changed metadata hostname source order #2010

Merged

2 tasks

github-actions bot mentioned this pull request Jun 22, 2024

Monthly contributions report 2024-05-22 - 2024-06-21 flatcar/Flatcar#1477

Closed

		@@ -0,0 +1 @@
		- OpenStack: Changed metadata hostname source order. The service first try with the config drive then fallback on the metadata service. ([scripts#2009](https://github.com/flatcar/scripts/pull/2009))

	CROS_WORKON_COMMIT="26f6147ef9388048edcecedba931621874f3d448" # flatcar-master
	CROS_WORKON_COMMIT="fb2631ce5e6a21d044c8dca73f59db01f9d5abcf" # flatcar-master

	CROS_WORKON_PROJECT="alejandro-ripoll/bootengine"
	CROS_WORKON_PROJECT="flatcar/bootengine"

Comments

Conversation

alejandro-ripoll commented May 27, 2024 • edited by tormath1 Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Test migration to openstack afterburn provider

How to use

Testing done

Uh oh!

tormath1 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tormath1 commented May 28, 2024

Uh oh!

github-actions bot commented May 28, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ader1990 commented May 28, 2024

Uh oh!

tormath1 commented May 28, 2024

Uh oh!

ader1990 commented May 28, 2024

Uh oh!

tormath1 commented May 28, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alejandro-ripoll commented May 28, 2024

Uh oh!

tormath1 commented May 28, 2024

Uh oh!

alejandro-ripoll commented May 29, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

alejandro-ripoll commented May 29, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

alejandro-ripoll commented May 27, 2024 •

edited by tormath1

Loading

github-actions bot commented May 28, 2024 •

edited

Loading

alejandro-ripoll commented May 29, 2024 •

edited

Loading

alejandro-ripoll commented May 29, 2024 •

edited

Loading