[Yahoo-eng-team] [Bug 1910408] Re: Cubic appends characters to /etc/os-release and /etc/lsb-release breaking the new automated installation method for Ubuntu
Sounds like there's nothing for cloud-init here; thanks all! ** Changed in: cloud-init Status: New => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1910408 Title: Cubic appends characters to /etc/os-release and /etc/lsb-release breaking the new automated installation method for Ubuntu Status in cloud-init: Won't Fix Status in Cubic: Fix Released Bug description: During the automated installation of an iso, if cloud-init uses the DataSourceNoCloud, then it will check for block devices and read the /etc/os-release and /etc/lsb-release files, parsing them for distribution specific information. However, Cubic appends its own information onto the PRETTY_NAME and DISTRIB_DESCRIPTION lines for those two files, causing cloud-init to break, and any automated provisioning to fail. This can be fixed in cloud-init by using proper os.path.join, or os.sep, etc., but this is unlikely to happen soon. Cubic should provided better documentation about any cute characters it writes into the distribution. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1910408/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1910835] Re: Azure IMDS publicKeys contain \r\n which prevents ssh access to vms using cloud-generated ssh keys.
** Changed in: cloud-init
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1910835
Title:
Azure IMDS publicKeys contain \r\n which prevents ssh access to vms
using cloud-generated ssh keys.
Status in cloud-init:
Fix Released
Status in cloud-init package in Ubuntu:
Fix Released
Status in cloud-init source package in Xenial:
Fix Released
Status in cloud-init source package in Bionic:
Fix Released
Status in cloud-init source package in Focal:
Fix Released
Status in cloud-init source package in Groovy:
Fix Released
Status in cloud-init source package in Hirsute:
Fix Released
Bug description:
== Begin SRU Template ==
[Impact]
The previous version of cloud-init used OpenSSL to process the SSH keys
provided by the Azure platform. cloud-init 20.4 replaced that code with a more
efficient implementation, but one which did not use OpenSSL: this meant that
users passing certificates to instances, or users generating SSH keys in
Azure's web UI (which inserts \r\n sequences into the public key content), were
regressed: their certificates and malformed SSH keys were no longer handled, so
they could fail to gain access to newly-launched instances.
This release is only a single functional cherry-pick which solely
affects Azure platform. It is a critical bug we wish to release as
soon as possible
* Azure: cherry-pick 4f62ae8d: Fix regression with handling of IMDS ssh keys
(#760) (LP: #1910835)
The functional changeset here introduces a raise KeyError exception
which forces cloud-init to revert to previous released logic of the
previous cloud-init public release 20.3.
[Test Case]
As this is a single commit backport, the cloud-init SRU exception need
not apply. An upstream integration test has been written for this
issue (https://github.com/canonical/cloud-
init/blob/master/tests/integration_tests/bugs/test_lp1910835.py).
A full run of the upstream test suite on Azure will therefore
regression test the update generally and test this issue specifically:
a log of a test run for each suite will be attached.
[Regression Potential]
The proposed change only modifies code paths used on Azure,
specifically to revert to a previous behaviour: users unaffected by
the bug should see no change (their keys will get to their instance
via a different route), and users affected by the bug would have been
unable to access their instances before (so cannot be relying on this
behaviour in a way which we could break by fixing it).
[Discussion]
This should only affect public Azure VM launched which use Azure to
--generate-ssh-keys either from the dashboard or from the `az cli`
Any other cloud-platform is not affected by this change.
== End SRU Template ==
* cherry-pick 4f62ae8d: Fix regression with handling of IMDS ssh keys
(#760) (LP: #1910835)
== Original Description ==
cloud-init 20.4 or later will incorrectly add Azure publicKeys to
.ssh/authorized_keys preventing ssh access for cloud-generated keys.
To reproduce: launch an ubuntu VM from the portal.azure.com choosing
to generate new ssh key.
When the instance is launched you can see that the ssh-rsa content
provided in the metadata publicKeys value contains CRLF characters
(\r\n) thus splitting the content of the pubkey onto multiple lines
when it is rendered into .ssh/authorized_keys.
the solution is either for IMDS to stop adding the CRLF characters or
cloud-init to strip them out.
Here is the IMDS value provided to cloud-init
cloud-init query --format '{{ds.meta_data.imds.compute.publicKeys}}'
[{'keyData': 'ssh-rsa
B3NzaC1yc2EDAQABAAABgQCllNnyHXFWlMb9EKD9LZrOxt1d\r\nk/QxYwQ0HYEP8n6TUWoUsN3mv/Qk/qWH76Pa6f33hefzTFRiom7Ls/tJMcr/ki8R\r\n9FqyYOu0xxHmpXTUWFoZQCZtGRMtvDl/s76Wr1sCsE/ez+EcAPeGGm/B7jHtDAUW\r\nlkINfuPVBDfRtSfmnlCKS+sIf1XOqvRASGWi05zAW921T4OkiattyXyhaOimJOwq\r\n4jAXmydwtNCN2iGGKWS8YeXbtgveReqZVVKtcDKevgWdNyqZa69uq9tRujobjCh7\r\n6xxCkQcdCLospgqX79GBbdRys6mVxVgc349RIWjQwglRQpJwNzkeOG5Q+La2MEhu\r\niKqKJMvYVhil3khzMuZwzmTrGbRx0E8AS+Cm064RBgbcdjCW8dDYGLuk2eQ2v9Ht\r\n6eERfxMBNg3udv1jmiKpjjHIg99HDU4VqhL3aHmg+TSrxByd0cAgFBV+H0CiUVC9\r\nS2mLJ6Peu/HDwd88E8Wqiv3eAsjcaCRH3QiQVaU=
generated-by-azure\r\n', 'path': '/home/ubuntu/.ssh/authorized_keys'}]
cloud-init renders this directly to .ssh/authorized_keys without
processing the string, resulting in an invalid keyline:
ssh-rsa B3NzaC1yc2EDAQABAAABgQCllNnyHXFWlMb9EKD9LZrOxt1d
k/QxYwQ0HYEP8n6TUWoUsN3mv/Qk/qWH76Pa6f33hefzTFRiom7Ls/tJMcr/ki8R^M
9FqyYOu0xxHmpXTUWFoZQCZtGRMtvDl/s76Wr1sCsE/ez+EcAPeGGm/B7jHtDAUW^M
lkINfuPVBDfRtSfmnlCKS+sIf1XOqvRASGWi05zAW921T4OkiattyXyhaOimJOwq^M
4jAXmydwtNCN2iGGKWS8YeXbtgveReqZVVKtcDKevgWdNyqZa69uq9tRujobjCh7^M
6xxCkQcdCLospgqX79GBbdRys6mVxVgc349RIWjQwglRQpJwNzkeOG5Q+La2MEhu^M
[Yahoo-eng-team] [Bug 1910835] Re: Azure IMDS publicKeys contain \r\n which prevents ssh access to vms using cloud-generated ssh keys.
This bug was fixed in the package cloud-init - 20.4-0ubuntu1~18.04.2
---
cloud-init (20.4-0ubuntu1~18.04.2) bionic; urgency=medium
* cherry-pick 4f62ae8d: Fix regression with handling of IMDS ssh keys
(#760) (LP: #1910835)
-- Daniel Watkins Mon, 11 Jan 2021 17:31:19
-0500
** Changed in: cloud-init (Ubuntu Xenial)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1910835
Title:
Azure IMDS publicKeys contain \r\n which prevents ssh access to vms
using cloud-generated ssh keys.
Status in cloud-init:
Confirmed
Status in cloud-init package in Ubuntu:
Fix Released
Status in cloud-init source package in Xenial:
Fix Released
Status in cloud-init source package in Bionic:
Fix Released
Status in cloud-init source package in Focal:
Fix Released
Status in cloud-init source package in Groovy:
Fix Released
Status in cloud-init source package in Hirsute:
Fix Released
Bug description:
== Begin SRU Template ==
[Impact]
The previous version of cloud-init used OpenSSL to process the SSH keys
provided by the Azure platform. cloud-init 20.4 replaced that code with a more
efficient implementation, but one which did not use OpenSSL: this meant that
users passing certificates to instances, or users generating SSH keys in
Azure's web UI (which inserts \r\n sequences into the public key content), were
regressed: their certificates and malformed SSH keys were no longer handled, so
they could fail to gain access to newly-launched instances.
This release is only a single functional cherry-pick which solely
affects Azure platform. It is a critical bug we wish to release as
soon as possible
* Azure: cherry-pick 4f62ae8d: Fix regression with handling of IMDS ssh keys
(#760) (LP: #1910835)
The functional changeset here introduces a raise KeyError exception
which forces cloud-init to revert to previous released logic of the
previous cloud-init public release 20.3.
[Test Case]
As this is a single commit backport, the cloud-init SRU exception need
not apply. An upstream integration test has been written for this
issue (https://github.com/canonical/cloud-
init/blob/master/tests/integration_tests/bugs/test_lp1910835.py).
A full run of the upstream test suite on Azure will therefore
regression test the update generally and test this issue specifically:
a log of a test run for each suite will be attached.
[Regression Potential]
The proposed change only modifies code paths used on Azure,
specifically to revert to a previous behaviour: users unaffected by
the bug should see no change (their keys will get to their instance
via a different route), and users affected by the bug would have been
unable to access their instances before (so cannot be relying on this
behaviour in a way which we could break by fixing it).
[Discussion]
This should only affect public Azure VM launched which use Azure to
--generate-ssh-keys either from the dashboard or from the `az cli`
Any other cloud-platform is not affected by this change.
== End SRU Template ==
* cherry-pick 4f62ae8d: Fix regression with handling of IMDS ssh keys
(#760) (LP: #1910835)
== Original Description ==
cloud-init 20.4 or later will incorrectly add Azure publicKeys to
.ssh/authorized_keys preventing ssh access for cloud-generated keys.
To reproduce: launch an ubuntu VM from the portal.azure.com choosing
to generate new ssh key.
When the instance is launched you can see that the ssh-rsa content
provided in the metadata publicKeys value contains CRLF characters
(\r\n) thus splitting the content of the pubkey onto multiple lines
when it is rendered into .ssh/authorized_keys.
the solution is either for IMDS to stop adding the CRLF characters or
cloud-init to strip them out.
Here is the IMDS value provided to cloud-init
cloud-init query --format '{{ds.meta_data.imds.compute.publicKeys}}'
[{'keyData': 'ssh-rsa
B3NzaC1yc2EDAQABAAABgQCllNnyHXFWlMb9EKD9LZrOxt1d\r\nk/QxYwQ0HYEP8n6TUWoUsN3mv/Qk/qWH76Pa6f33hefzTFRiom7Ls/tJMcr/ki8R\r\n9FqyYOu0xxHmpXTUWFoZQCZtGRMtvDl/s76Wr1sCsE/ez+EcAPeGGm/B7jHtDAUW\r\nlkINfuPVBDfRtSfmnlCKS+sIf1XOqvRASGWi05zAW921T4OkiattyXyhaOimJOwq\r\n4jAXmydwtNCN2iGGKWS8YeXbtgveReqZVVKtcDKevgWdNyqZa69uq9tRujobjCh7\r\n6xxCkQcdCLospgqX79GBbdRys6mVxVgc349RIWjQwglRQpJwNzkeOG5Q+La2MEhu\r\niKqKJMvYVhil3khzMuZwzmTrGbRx0E8AS+Cm064RBgbcdjCW8dDYGLuk2eQ2v9Ht\r\n6eERfxMBNg3udv1jmiKpjjHIg99HDU4VqhL3aHmg+TSrxByd0cAgFBV+H0CiUVC9\r\nS2mLJ6Peu/HDwd88E8Wqiv3eAsjcaCRH3QiQVaU=
generated-by-azure\r\n', 'path': '/home/ubuntu/.ssh/authorized_keys'}]
cloud-init renders this directly to .ssh/authorized_keys without
processing the string, resulting in an invalid keyline:
ssh-rsa B3NzaC1yc2EDAQABAAABgQCllNnyHXFWlMb9EKD9LZrOxt1d
[Yahoo-eng-team] [Bug 1910835] Re: Azure IMDS publicKeys contain \r\n which prevents ssh access to vms using cloud-generated ssh keys.
This bug was fixed in the package cloud-init - 20.4-0ubuntu1~20.04.2
---
cloud-init (20.4-0ubuntu1~20.04.2) focal; urgency=medium
* cherry-pick 4f62ae8d: Fix regression with handling of IMDS ssh keys
(#760) (LP: #1910835)
-- Chad Smith Mon, 11 Jan 2021 15:25:31
-0700
** Changed in: cloud-init (Ubuntu Focal)
Status: Fix Committed => Fix Released
** Changed in: cloud-init (Ubuntu Bionic)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1910835
Title:
Azure IMDS publicKeys contain \r\n which prevents ssh access to vms
using cloud-generated ssh keys.
Status in cloud-init:
Confirmed
Status in cloud-init package in Ubuntu:
Fix Released
Status in cloud-init source package in Xenial:
Fix Released
Status in cloud-init source package in Bionic:
Fix Released
Status in cloud-init source package in Focal:
Fix Released
Status in cloud-init source package in Groovy:
Fix Released
Status in cloud-init source package in Hirsute:
Fix Released
Bug description:
== Begin SRU Template ==
[Impact]
The previous version of cloud-init used OpenSSL to process the SSH keys
provided by the Azure platform. cloud-init 20.4 replaced that code with a more
efficient implementation, but one which did not use OpenSSL: this meant that
users passing certificates to instances, or users generating SSH keys in
Azure's web UI (which inserts \r\n sequences into the public key content), were
regressed: their certificates and malformed SSH keys were no longer handled, so
they could fail to gain access to newly-launched instances.
This release is only a single functional cherry-pick which solely
affects Azure platform. It is a critical bug we wish to release as
soon as possible
* Azure: cherry-pick 4f62ae8d: Fix regression with handling of IMDS ssh keys
(#760) (LP: #1910835)
The functional changeset here introduces a raise KeyError exception
which forces cloud-init to revert to previous released logic of the
previous cloud-init public release 20.3.
[Test Case]
As this is a single commit backport, the cloud-init SRU exception need
not apply. An upstream integration test has been written for this
issue (https://github.com/canonical/cloud-
init/blob/master/tests/integration_tests/bugs/test_lp1910835.py).
A full run of the upstream test suite on Azure will therefore
regression test the update generally and test this issue specifically:
a log of a test run for each suite will be attached.
[Regression Potential]
The proposed change only modifies code paths used on Azure,
specifically to revert to a previous behaviour: users unaffected by
the bug should see no change (their keys will get to their instance
via a different route), and users affected by the bug would have been
unable to access their instances before (so cannot be relying on this
behaviour in a way which we could break by fixing it).
[Discussion]
This should only affect public Azure VM launched which use Azure to
--generate-ssh-keys either from the dashboard or from the `az cli`
Any other cloud-platform is not affected by this change.
== End SRU Template ==
* cherry-pick 4f62ae8d: Fix regression with handling of IMDS ssh keys
(#760) (LP: #1910835)
== Original Description ==
cloud-init 20.4 or later will incorrectly add Azure publicKeys to
.ssh/authorized_keys preventing ssh access for cloud-generated keys.
To reproduce: launch an ubuntu VM from the portal.azure.com choosing
to generate new ssh key.
When the instance is launched you can see that the ssh-rsa content
provided in the metadata publicKeys value contains CRLF characters
(\r\n) thus splitting the content of the pubkey onto multiple lines
when it is rendered into .ssh/authorized_keys.
the solution is either for IMDS to stop adding the CRLF characters or
cloud-init to strip them out.
Here is the IMDS value provided to cloud-init
cloud-init query --format '{{ds.meta_data.imds.compute.publicKeys}}'
[{'keyData': 'ssh-rsa
B3NzaC1yc2EDAQABAAABgQCllNnyHXFWlMb9EKD9LZrOxt1d\r\nk/QxYwQ0HYEP8n6TUWoUsN3mv/Qk/qWH76Pa6f33hefzTFRiom7Ls/tJMcr/ki8R\r\n9FqyYOu0xxHmpXTUWFoZQCZtGRMtvDl/s76Wr1sCsE/ez+EcAPeGGm/B7jHtDAUW\r\nlkINfuPVBDfRtSfmnlCKS+sIf1XOqvRASGWi05zAW921T4OkiattyXyhaOimJOwq\r\n4jAXmydwtNCN2iGGKWS8YeXbtgveReqZVVKtcDKevgWdNyqZa69uq9tRujobjCh7\r\n6xxCkQcdCLospgqX79GBbdRys6mVxVgc349RIWjQwglRQpJwNzkeOG5Q+La2MEhu\r\niKqKJMvYVhil3khzMuZwzmTrGbRx0E8AS+Cm064RBgbcdjCW8dDYGLuk2eQ2v9Ht\r\n6eERfxMBNg3udv1jmiKpjjHIg99HDU4VqhL3aHmg+TSrxByd0cAgFBV+H0CiUVC9\r\nS2mLJ6Peu/HDwd88E8Wqiv3eAsjcaCRH3QiQVaU=
generated-by-azure\r\n', 'path': '/home/ubuntu/.ssh/authorized_keys'}]
cloud-init renders this directly to .ssh/authorized_keys without
processing the string, resulting in an invalid keyline:
ssh-rsa
[Yahoo-eng-team] [Bug 1910835] Re: Azure IMDS publicKeys contain \r\n which prevents ssh access to vms using cloud-generated ssh keys.
This bug was fixed in the package cloud-init - 20.4-0ubuntu1~20.10.2
---
cloud-init (20.4-0ubuntu1~20.10.2) groovy; urgency=medium
* cherry-pick 4f62ae8d: Fix regression with handling of IMDS ssh keys
(#760) (LP: #1910835)
-- Daniel Watkins Mon, 11 Jan 2021 17:10:13
-0500
** Changed in: cloud-init (Ubuntu Groovy)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1910835
Title:
Azure IMDS publicKeys contain \r\n which prevents ssh access to vms
using cloud-generated ssh keys.
Status in cloud-init:
Confirmed
Status in cloud-init package in Ubuntu:
Fix Released
Status in cloud-init source package in Xenial:
Fix Released
Status in cloud-init source package in Bionic:
Fix Released
Status in cloud-init source package in Focal:
Fix Released
Status in cloud-init source package in Groovy:
Fix Released
Status in cloud-init source package in Hirsute:
Fix Released
Bug description:
== Begin SRU Template ==
[Impact]
The previous version of cloud-init used OpenSSL to process the SSH keys
provided by the Azure platform. cloud-init 20.4 replaced that code with a more
efficient implementation, but one which did not use OpenSSL: this meant that
users passing certificates to instances, or users generating SSH keys in
Azure's web UI (which inserts \r\n sequences into the public key content), were
regressed: their certificates and malformed SSH keys were no longer handled, so
they could fail to gain access to newly-launched instances.
This release is only a single functional cherry-pick which solely
affects Azure platform. It is a critical bug we wish to release as
soon as possible
* Azure: cherry-pick 4f62ae8d: Fix regression with handling of IMDS ssh keys
(#760) (LP: #1910835)
The functional changeset here introduces a raise KeyError exception
which forces cloud-init to revert to previous released logic of the
previous cloud-init public release 20.3.
[Test Case]
As this is a single commit backport, the cloud-init SRU exception need
not apply. An upstream integration test has been written for this
issue (https://github.com/canonical/cloud-
init/blob/master/tests/integration_tests/bugs/test_lp1910835.py).
A full run of the upstream test suite on Azure will therefore
regression test the update generally and test this issue specifically:
a log of a test run for each suite will be attached.
[Regression Potential]
The proposed change only modifies code paths used on Azure,
specifically to revert to a previous behaviour: users unaffected by
the bug should see no change (their keys will get to their instance
via a different route), and users affected by the bug would have been
unable to access their instances before (so cannot be relying on this
behaviour in a way which we could break by fixing it).
[Discussion]
This should only affect public Azure VM launched which use Azure to
--generate-ssh-keys either from the dashboard or from the `az cli`
Any other cloud-platform is not affected by this change.
== End SRU Template ==
* cherry-pick 4f62ae8d: Fix regression with handling of IMDS ssh keys
(#760) (LP: #1910835)
== Original Description ==
cloud-init 20.4 or later will incorrectly add Azure publicKeys to
.ssh/authorized_keys preventing ssh access for cloud-generated keys.
To reproduce: launch an ubuntu VM from the portal.azure.com choosing
to generate new ssh key.
When the instance is launched you can see that the ssh-rsa content
provided in the metadata publicKeys value contains CRLF characters
(\r\n) thus splitting the content of the pubkey onto multiple lines
when it is rendered into .ssh/authorized_keys.
the solution is either for IMDS to stop adding the CRLF characters or
cloud-init to strip them out.
Here is the IMDS value provided to cloud-init
cloud-init query --format '{{ds.meta_data.imds.compute.publicKeys}}'
[{'keyData': 'ssh-rsa
B3NzaC1yc2EDAQABAAABgQCllNnyHXFWlMb9EKD9LZrOxt1d\r\nk/QxYwQ0HYEP8n6TUWoUsN3mv/Qk/qWH76Pa6f33hefzTFRiom7Ls/tJMcr/ki8R\r\n9FqyYOu0xxHmpXTUWFoZQCZtGRMtvDl/s76Wr1sCsE/ez+EcAPeGGm/B7jHtDAUW\r\nlkINfuPVBDfRtSfmnlCKS+sIf1XOqvRASGWi05zAW921T4OkiattyXyhaOimJOwq\r\n4jAXmydwtNCN2iGGKWS8YeXbtgveReqZVVKtcDKevgWdNyqZa69uq9tRujobjCh7\r\n6xxCkQcdCLospgqX79GBbdRys6mVxVgc349RIWjQwglRQpJwNzkeOG5Q+La2MEhu\r\niKqKJMvYVhil3khzMuZwzmTrGbRx0E8AS+Cm064RBgbcdjCW8dDYGLuk2eQ2v9Ht\r\n6eERfxMBNg3udv1jmiKpjjHIg99HDU4VqhL3aHmg+TSrxByd0cAgFBV+H0CiUVC9\r\nS2mLJ6Peu/HDwd88E8Wqiv3eAsjcaCRH3QiQVaU=
generated-by-azure\r\n', 'path': '/home/ubuntu/.ssh/authorized_keys'}]
cloud-init renders this directly to .ssh/authorized_keys without
processing the string, resulting in an invalid keyline:
ssh-rsa B3NzaC1yc2EDAQABAAABgQCllNnyHXFWlMb9EKD9LZrOxt1d
[Yahoo-eng-team] [Bug 1911230] Re: `test_datasource_rbx_no_stacktrace` incorrectly runs on all clouds
Fixed in https://github.com/canonical/cloud-init/pull/770 (and as this is a testing change, no need to wait for a release to Fix Released it). ** Changed in: cloud-init Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1911230 Title: `test_datasource_rbx_no_stacktrace` incorrectly runs on all clouds Status in cloud-init: Fix Released Bug description: It makes assumptions about the platform it's testing on, so should be limited to platforms where we expect it to work. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1911230/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1911227] [NEW] cc_seed_random: unexpectedly appends cloud's random_seed to specified seed data
Public bug reported: The test_seed_random_data test specifies this user-data: #cloud-config random_seed: data: 'MYUb34023nD:LFDK10913jk;dfnk:Df' encoding: raw file: /root/seed and asserts that that is the exact content of /root/seed. If we're using a datasource which sets random_seed in its metadata (i.e. Azure and OpenStack, at least), this test fails: cc_seed_random will _append_ the cloud's random_seed to the given data before writing it out. To be clear, the bug here is that this is unexpected: we do not document this behaviour. I can't think of a compelling case for not behaving in this way: more entropy is good, and we have write_files if users really do want to write out exact content to a path. The TestSeedRandomData.test_seed_random_data integration test assumes the "exact writing" behaviour, so will also need to be updated. ** Affects: cloud-init Importance: Medium Assignee: Dan Watkins (oddbloke) Status: Triaged ** Tags: docs ** Changed in: cloud-init Status: New => Triaged ** Changed in: cloud-init Importance: Undecided => Medium ** Summary changed: - cc_seed_random: unexpectedly appends cloud's random_seed to specified seed + cc_seed_random: unexpectedly appends cloud's random_seed to specified seed data ** Description changed: The test_seed_random_data test specifies this user-data: #cloud-config random_seed: - data: 'MYUb34023nD:LFDK10913jk;dfnk:Df' - encoding: raw - file: /root/seed + data: 'MYUb34023nD:LFDK10913jk;dfnk:Df' + encoding: raw + file: /root/seed and asserts that that is the exact content of /root/seed. If we're using a datasource which sets random_seed in its metadata (i.e. Azure and OpenStack, at least), this test fails: cc_seed_random will _append_ the cloud's random_seed to the given data before writing it out. To be clear, the bug here is that this is unexpected: we do not document this behaviour. I can't think of a compelling case for not behaving in this way: more entropy is good, and we have write_files if users really do want to write out exact content to a path. + + The TestSeedRandomData.test_seed_random_data integration test assumes + the "exact writing" behaviour, so will also need to be updated. -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1911227 Title: cc_seed_random: unexpectedly appends cloud's random_seed to specified seed data Status in cloud-init: Triaged Bug description: The test_seed_random_data test specifies this user-data: #cloud-config random_seed: data: 'MYUb34023nD:LFDK10913jk;dfnk:Df' encoding: raw file: /root/seed and asserts that that is the exact content of /root/seed. If we're using a datasource which sets random_seed in its metadata (i.e. Azure and OpenStack, at least), this test fails: cc_seed_random will _append_ the cloud's random_seed to the given data before writing it out. To be clear, the bug here is that this is unexpected: we do not document this behaviour. I can't think of a compelling case for not behaving in this way: more entropy is good, and we have write_files if users really do want to write out exact content to a path. The TestSeedRandomData.test_seed_random_data integration test assumes the "exact writing" behaviour, so will also need to be updated. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1911227/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1911230] [NEW] `test_datasource_rbx_no_stacktrace` incorrectly runs on all clouds
Public bug reported: It makes assumptions about the platform it's testing on, so should be limited to platforms where we expect it to work. ** Affects: cloud-init Importance: Medium Assignee: James Falcon (falcojr) Status: In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1911230 Title: `test_datasource_rbx_no_stacktrace` incorrectly runs on all clouds Status in cloud-init: In Progress Bug description: It makes assumptions about the platform it's testing on, so should be limited to platforms where we expect it to work. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1911230/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1910835] Re: Azure IMDS publicKeys contain \r\n which prevents ssh access to vms using cloud-generated ssh keys.
** Changed in: cloud-init (Ubuntu Hirsute)
Status: New => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1910835
Title:
Azure IMDS publicKeys contain \r\n which prevents ssh access to vms
using cloud-generated ssh keys.
Status in cloud-init:
Confirmed
Status in cloud-init package in Ubuntu:
Fix Released
Status in cloud-init source package in Xenial:
Fix Committed
Status in cloud-init source package in Bionic:
Fix Committed
Status in cloud-init source package in Focal:
Fix Committed
Status in cloud-init source package in Groovy:
Fix Committed
Status in cloud-init source package in Hirsute:
Fix Released
Bug description:
== Begin SRU Template ==
[Impact]
The previous version of cloud-init used OpenSSL to process the SSH keys
provided by the Azure platform. cloud-init 20.4 replaced that code with a more
efficient implementation, but one which did not use OpenSSL: this meant that
users passing certificates to instances, or users generating SSH keys in
Azure's web UI (which inserts \r\n sequences into the public key content), were
regressed: their certificates and malformed SSH keys were no longer handled, so
they could fail to gain access to newly-launched instances.
This release is only a single functional cherry-pick which solely
affects Azure platform. It is a critical bug we wish to release as
soon as possible
* Azure: cherry-pick 4f62ae8d: Fix regression with handling of IMDS ssh keys
(#760) (LP: #1910835)
The functional changeset here introduces a raise KeyError exception
which forces cloud-init to revert to previous released logic of the
previous cloud-init public release 20.3.
[Test Case]
As this is a single commit backport, the cloud-init SRU exception need
not apply. An upstream integration test has been written for this
issue (https://github.com/canonical/cloud-
init/blob/master/tests/integration_tests/bugs/test_lp1910835.py).
A full run of the upstream test suite on Azure will therefore
regression test the update generally and test this issue specifically:
a log of a test run for each suite will be attached.
[Regression Potential]
The proposed change only modifies code paths used on Azure,
specifically to revert to a previous behaviour: users unaffected by
the bug should see no change (their keys will get to their instance
via a different route), and users affected by the bug would have been
unable to access their instances before (so cannot be relying on this
behaviour in a way which we could break by fixing it).
[Discussion]
This should only affect public Azure VM launched which use Azure to
--generate-ssh-keys either from the dashboard or from the `az cli`
Any other cloud-platform is not affected by this change.
== End SRU Template ==
* cherry-pick 4f62ae8d: Fix regression with handling of IMDS ssh keys
(#760) (LP: #1910835)
== Original Description ==
cloud-init 20.4 or later will incorrectly add Azure publicKeys to
.ssh/authorized_keys preventing ssh access for cloud-generated keys.
To reproduce: launch an ubuntu VM from the portal.azure.com choosing
to generate new ssh key.
When the instance is launched you can see that the ssh-rsa content
provided in the metadata publicKeys value contains CRLF characters
(\r\n) thus splitting the content of the pubkey onto multiple lines
when it is rendered into .ssh/authorized_keys.
the solution is either for IMDS to stop adding the CRLF characters or
cloud-init to strip them out.
Here is the IMDS value provided to cloud-init
cloud-init query --format '{{ds.meta_data.imds.compute.publicKeys}}'
[{'keyData': 'ssh-rsa
B3NzaC1yc2EDAQABAAABgQCllNnyHXFWlMb9EKD9LZrOxt1d\r\nk/QxYwQ0HYEP8n6TUWoUsN3mv/Qk/qWH76Pa6f33hefzTFRiom7Ls/tJMcr/ki8R\r\n9FqyYOu0xxHmpXTUWFoZQCZtGRMtvDl/s76Wr1sCsE/ez+EcAPeGGm/B7jHtDAUW\r\nlkINfuPVBDfRtSfmnlCKS+sIf1XOqvRASGWi05zAW921T4OkiattyXyhaOimJOwq\r\n4jAXmydwtNCN2iGGKWS8YeXbtgveReqZVVKtcDKevgWdNyqZa69uq9tRujobjCh7\r\n6xxCkQcdCLospgqX79GBbdRys6mVxVgc349RIWjQwglRQpJwNzkeOG5Q+La2MEhu\r\niKqKJMvYVhil3khzMuZwzmTrGbRx0E8AS+Cm064RBgbcdjCW8dDYGLuk2eQ2v9Ht\r\n6eERfxMBNg3udv1jmiKpjjHIg99HDU4VqhL3aHmg+TSrxByd0cAgFBV+H0CiUVC9\r\nS2mLJ6Peu/HDwd88E8Wqiv3eAsjcaCRH3QiQVaU=
generated-by-azure\r\n', 'path': '/home/ubuntu/.ssh/authorized_keys'}]
cloud-init renders this directly to .ssh/authorized_keys without
processing the string, resulting in an invalid keyline:
ssh-rsa B3NzaC1yc2EDAQABAAABgQCllNnyHXFWlMb9EKD9LZrOxt1d
k/QxYwQ0HYEP8n6TUWoUsN3mv/Qk/qWH76Pa6f33hefzTFRiom7Ls/tJMcr/ki8R^M
9FqyYOu0xxHmpXTUWFoZQCZtGRMtvDl/s76Wr1sCsE/ez+EcAPeGGm/B7jHtDAUW^M
lkINfuPVBDfRtSfmnlCKS+sIf1XOqvRASGWi05zAW921T4OkiattyXyhaOimJOwq^M
4jAXmydwtNCN2iGGKWS8YeXbtgveReqZVVKtcDKevgWdNyqZa69uq9tRujobjCh7^M
[Yahoo-eng-team] [Bug 1911214] [NEW] Scenario test test_multiple_ports_secgroup_inheritance fails in ovn scenario job
Public bug reported: Failure: Traceback (most recent call last): File "/opt/stack/tempest/.tox/tempest/lib/python3.8/site-packages/neutron_tempest_plugin/scenario/test_security_groups.py", line 341, in test_multiple_ports_secgroup_inheritance self.ping_ip_address(fip['floating_ip_address']) File "/opt/stack/tempest/.tox/tempest/lib/python3.8/site-packages/neutron_tempest_plugin/scenario/base.py", line 449, in ping_ip_address self.assertTrue(result) File "/opt/stack/tempest/.tox/tempest/lib/python3.8/site-packages/unittest2/case.py", line 702, in assertTrue raise self.failureException(msg) AssertionError: False is not true Logs: https://bfc2304b36c89dd5efde- d71f4126f88f4263fd488933444cea49.ssl.cf1.rackcdn.com/740569/2/check /neutron-tempest-plugin-scenario-ovn/026535a/testr_results.html ** Affects: neutron Importance: Medium Status: Confirmed ** Tags: gate-failure ovn -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1911214 Title: Scenario test test_multiple_ports_secgroup_inheritance fails in ovn scenario job Status in neutron: Confirmed Bug description: Failure: Traceback (most recent call last): File "/opt/stack/tempest/.tox/tempest/lib/python3.8/site-packages/neutron_tempest_plugin/scenario/test_security_groups.py", line 341, in test_multiple_ports_secgroup_inheritance self.ping_ip_address(fip['floating_ip_address']) File "/opt/stack/tempest/.tox/tempest/lib/python3.8/site-packages/neutron_tempest_plugin/scenario/base.py", line 449, in ping_ip_address self.assertTrue(result) File "/opt/stack/tempest/.tox/tempest/lib/python3.8/site-packages/unittest2/case.py", line 702, in assertTrue raise self.failureException(msg) AssertionError: False is not true Logs: https://bfc2304b36c89dd5efde- d71f4126f88f4263fd488933444cea49.ssl.cf1.rackcdn.com/740569/2/check /neutron-tempest-plugin-scenario-ovn/026535a/testr_results.html To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1911214/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1892361] Re: SRIOV instance gets type-PF interface, libvirt kvm fails
** Changed in: nova (Ubuntu Hirsute) Status: New => Fix Released ** Changed in: nova (Ubuntu Groovy) Status: New => Fix Released ** Changed in: cloud-archive/victoria Importance: Undecided => Medium ** Changed in: cloud-archive/victoria Status: New => Fix Released ** Changed in: nova (Ubuntu Hirsute) Importance: Undecided => Medium ** Changed in: nova (Ubuntu Groovy) Importance: Undecided => Medium -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1892361 Title: SRIOV instance gets type-PF interface, libvirt kvm fails Status in Ubuntu Cloud Archive: Fix Released Status in Ubuntu Cloud Archive queens series: New Status in Ubuntu Cloud Archive rocky series: New Status in Ubuntu Cloud Archive stein series: New Status in Ubuntu Cloud Archive train series: New Status in Ubuntu Cloud Archive ussuri series: New Status in Ubuntu Cloud Archive victoria series: Fix Released Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) queens series: In Progress Status in OpenStack Compute (nova) rocky series: In Progress Status in OpenStack Compute (nova) stein series: In Progress Status in OpenStack Compute (nova) train series: In Progress Status in OpenStack Compute (nova) ussuri series: In Progress Status in OpenStack Compute (nova) victoria series: Fix Released Status in nova package in Ubuntu: Fix Released Status in nova source package in Bionic: New Status in nova source package in Focal: New Status in nova source package in Groovy: Fix Released Status in nova source package in Hirsute: Fix Released Bug description: When spawning an SR-IOV enabled instance on a newly deployed host, nova attempts to spawn it with an type-PF pci device. This fails with the below stack trace. After restarting neutron-sriov-agent and nova-compute services on the compute node and spawning an SR-IOV instance again, a type-VF pci device is selected, and instance spawning succeeds. Stack trace: 2020-08-20 08:29:09.558 7624 DEBUG oslo_messaging._drivers.amqpdriver [-] received reply msg_id: 6db8011e6ecd4fd0aaa53c8f89f08b1b __call__ /usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py:400 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [req-e3e49d07-24c6-4c62-916e-f830f70983a2 ddcfb3640535428798aa3c8545362bd4 dd99e7950a5b46b5b924ccd1720b6257 - 015e4fd7db304665ab5378caa691bb8b 015e4fd7db304665ab5378caa691bb8b] [insta nce: 9498ea75-fe88-4020-9a9e-f4c437c6de11] Instance failed to spawn: libvirtError: unsupported configuration: Interface type hostdev is currently supported on SR-IOV Virtual Functions only 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] Traceback (most recent call last): 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 2274, in _build_resources 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] yield resources 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 2054, in _build_and_run_instance 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] block_device_info=block_device_info) 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] File "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py", line 3147, in spawn 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] destroy_disks_on_failure=True) 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] File "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py", line 5651, in _create_domain_and_network 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] destroy_disks_on_failure) 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] File "/usr/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__ 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] self.force_reraise() 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] File "/usr/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11]
[Yahoo-eng-team] [Bug 1892361] Re: SRIOV instance gets type-PF interface, libvirt kvm fails
** Also affects: nova (Ubuntu) Importance: Undecided Status: New ** Also affects: nova (Ubuntu Groovy) Importance: Undecided Status: New ** Also affects: nova (Ubuntu Hirsute) Importance: Undecided Status: New ** Also affects: nova (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: nova (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: cloud-archive Importance: Undecided Status: New ** Also affects: cloud-archive/rocky Importance: Undecided Status: New ** Also affects: cloud-archive/train Importance: Undecided Status: New ** Also affects: cloud-archive/queens Importance: Undecided Status: New ** Also affects: cloud-archive/stein Importance: Undecided Status: New ** Also affects: cloud-archive/ussuri Importance: Undecided Status: New ** Also affects: cloud-archive/victoria Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1892361 Title: SRIOV instance gets type-PF interface, libvirt kvm fails Status in Ubuntu Cloud Archive: New Status in Ubuntu Cloud Archive queens series: New Status in Ubuntu Cloud Archive rocky series: New Status in Ubuntu Cloud Archive stein series: New Status in Ubuntu Cloud Archive train series: New Status in Ubuntu Cloud Archive ussuri series: New Status in Ubuntu Cloud Archive victoria series: New Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) queens series: In Progress Status in OpenStack Compute (nova) rocky series: In Progress Status in OpenStack Compute (nova) stein series: In Progress Status in OpenStack Compute (nova) train series: In Progress Status in OpenStack Compute (nova) ussuri series: In Progress Status in OpenStack Compute (nova) victoria series: Fix Released Status in nova package in Ubuntu: New Status in nova source package in Bionic: New Status in nova source package in Focal: New Status in nova source package in Groovy: New Status in nova source package in Hirsute: New Bug description: When spawning an SR-IOV enabled instance on a newly deployed host, nova attempts to spawn it with an type-PF pci device. This fails with the below stack trace. After restarting neutron-sriov-agent and nova-compute services on the compute node and spawning an SR-IOV instance again, a type-VF pci device is selected, and instance spawning succeeds. Stack trace: 2020-08-20 08:29:09.558 7624 DEBUG oslo_messaging._drivers.amqpdriver [-] received reply msg_id: 6db8011e6ecd4fd0aaa53c8f89f08b1b __call__ /usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py:400 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [req-e3e49d07-24c6-4c62-916e-f830f70983a2 ddcfb3640535428798aa3c8545362bd4 dd99e7950a5b46b5b924ccd1720b6257 - 015e4fd7db304665ab5378caa691bb8b 015e4fd7db304665ab5378caa691bb8b] [insta nce: 9498ea75-fe88-4020-9a9e-f4c437c6de11] Instance failed to spawn: libvirtError: unsupported configuration: Interface type hostdev is currently supported on SR-IOV Virtual Functions only 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] Traceback (most recent call last): 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 2274, in _build_resources 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] yield resources 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 2054, in _build_and_run_instance 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] block_device_info=block_device_info) 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] File "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py", line 3147, in spawn 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] destroy_disks_on_failure=True) 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] File "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py", line 5651, in _create_domain_and_network 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] destroy_disks_on_failure) 2020-08-20 08:29:09.561 7624 ERROR nova.compute.manager [instance: 9498ea75-fe88-4020-9a9e-f4c437c6de11] File
[Yahoo-eng-team] [Bug 1910623] Re: neutron api worker process can not display "desc" like "neutron-server: api wokers"
https://review.opendev.org/c/openstack/neutron-lib/+/769861 (neutron- lib) and https://review.opendev.org/c/openstack/neutron/+/769660 (neutron) have been merged. ** Tags removed: api-ref ** Tags added: api ** Changed in: neutron Status: New => Fix Released ** Changed in: neutron Importance: Undecided => Low -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1910623 Title: neutron api worker process can not display "desc" like "neutron- server: api wokers" Status in neutron: Fix Released Bug description: According to the description of the patch(https://review.opendev.org/c/openstack/neutron/+/637019), every neutron-server process should names to their role, like: 25355 ?Ss 0:26 /usr/bin/python /usr/local/bin/neutron-server \ --config-file /etc/neutron/neutron.conf \ --config-file /etc/neutron/plugins/ml2/ml2_conf.ini 25368 ?S 0:00 neutron-server: api worker 25369 ?S 0:00 neutron-server: api worker 25370 ?S 0:00 neutron-server: api worker 25371 ?S 0:00 neutron-server: api worker 25372 ?S 0:02 neutron-server: rpc worker 25373 ?S 0:02 neutron-server: rpc worker 25374 ?S 0:02 neutron-server: services worker but my devstack environment is: root@ubuntu:~# ps aux|grep neutron-server stack 615922 0.0 0.3 160508 71640 ?Ss2020 4:32 /usr/bin/python3.8 /usr/local/bin/neutron-server --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugins/ml2/ml2_conf.ini stack 615940 0.2 0.6 268616 126284 ? Sl2020 53:14 /usr/bin/python3.8 /usr/local/bin/neutron-server --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugins/ml2/ml2_conf.ini stack 615941 0.2 0.5 262176 119792 ? Sl2020 45:56 /usr/bin/python3.8 /usr/local/bin/neutron-server --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugins/ml2/ml2_conf.ini stack 615942 0.5 0.5 408828 114948 ? Sl2020 124:27 neutron-server: rpc worker (/usr/bin/python3.8 /usr/local/bin/neutron-server --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugins/ml2/ml2_conf.ini) stack 615943 0.2 0.5 262628 106540 ? Sl2020 63:14 neutron-server: rpc worker (/usr/bin/python3.8 /usr/local/bin/neutron-server --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugins/ml2/ml2_conf.ini) rpc workers process can display the name normally, api workers process does not display the process name. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1910623/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1911153] [NEW] [FT] DB migration "test_walk_versions" failing frequently
Public bug reported: Error log: https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_63b/769390/3/check /neutron-functional-with-uwsgi/63b3a7f/testr_results.html Snippet: http://paste.openstack.org/show/801553/ ** Affects: neutron Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1911153 Title: [FT] DB migration "test_walk_versions" failing frequently Status in neutron: New Bug description: Error log: https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_63b/769390/3/check /neutron-functional-with-uwsgi/63b3a7f/testr_results.html Snippet: http://paste.openstack.org/show/801553/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1911153/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1911132] [NEW] OVN mech driver - can't find Logical_Router errors
Public bug reported: I saw such errors in the CI job's logs. Traceback: Jan 07 15:32:40.720920 ubuntu-focal-ovh-bhs1-0022432336 neutron- server[68561]: ERROR ovsdbapp.backend.ovs_idl.command [None req- c0d71b7e-d2a9-4528-9e1a-22437c79fbf1 admin admin] Error executing command: ovsdbapp.backend.ovs_idl.idlutils.RowNotFound: Cannot find Logical_Router with name=neutron-99840546-2921-4f59-a540-aee4e964b3f2 Jan 07 15:32:40.720920 ubuntu-focal-ovh-bhs1-0022432336 neutron- server[68561]: ERROR ovsdbapp.backend.ovs_idl.command Traceback (most recent call last): Jan 07 15:32:40.720920 ubuntu-focal-ovh-bhs1-0022432336 neutron- server[68561]: ERROR ovsdbapp.backend.ovs_idl.command File "/usr/local/lib/python3.8/dist- packages/ovsdbapp/backend/ovs_idl/command.py", line 39, in execute Jan 07 15:32:40.720920 ubuntu-focal-ovh-bhs1-0022432336 neutron- server[68561]: ERROR ovsdbapp.backend.ovs_idl.command self.run_idl(None) Jan 07 15:32:40.720920 ubuntu-focal-ovh-bhs1-0022432336 neutron- server[68561]: ERROR ovsdbapp.backend.ovs_idl.command File "/usr/local/lib/python3.8/dist- packages/ovsdbapp/backend/ovs_idl/command.py", line 328, in run_idl Jan 07 15:32:40.720920 ubuntu-focal-ovh-bhs1-0022432336 neutron- server[68561]: ERROR ovsdbapp.backend.ovs_idl.command self.result = self.api.lookup(self.table, self.record) Jan 07 15:32:40.720920 ubuntu-focal-ovh-bhs1-0022432336 neutron- server[68561]: ERROR ovsdbapp.backend.ovs_idl.command File "/usr/local/lib/python3.8/dist- packages/ovsdbapp/backend/ovs_idl/__init__.py", line 177, in lookup Jan 07 15:32:40.720920 ubuntu-focal-ovh-bhs1-0022432336 neutron- server[68561]: ERROR ovsdbapp.backend.ovs_idl.command return self._lookup(table, record) Jan 07 15:32:40.720920 ubuntu-focal-ovh-bhs1-0022432336 neutron- server[68561]: ERROR ovsdbapp.backend.ovs_idl.command File "/usr/local/lib/python3.8/dist- packages/ovsdbapp/backend/ovs_idl/__init__.py", line 224, in _lookup Jan 07 15:32:40.720920 ubuntu-focal-ovh-bhs1-0022432336 neutron- server[68561]: ERROR ovsdbapp.backend.ovs_idl.command row = idlutils.row_by_value(self, rl.table, rl.column, record) Jan 07 15:32:40.720920 ubuntu-focal-ovh-bhs1-0022432336 neutron- server[68561]: ERROR ovsdbapp.backend.ovs_idl.command File "/usr/local/lib/python3.8/dist- packages/ovsdbapp/backend/ovs_idl/idlutils.py", line 114, in row_by_value Jan 07 15:32:40.720920 ubuntu-focal-ovh-bhs1-0022432336 neutron- server[68561]: ERROR ovsdbapp.backend.ovs_idl.command raise RowNotFound(table=table, col=column, match=match) Jan 07 15:32:40.720920 ubuntu-focal-ovh-bhs1-0022432336 neutron- server[68561]: ERROR ovsdbapp.backend.ovs_idl.command ovsdbapp.backend.ovs_idl.idlutils.RowNotFound: Cannot find Logical_Router with name=neutron-99840546-2921-4f59-a540-aee4e964b3f2 Logs: https://zuul.opendev.org/t/openstack/build/4b30c213380c4bbc8b910047b1c26797/logs ** Affects: neutron Importance: Undecided Status: New ** Tags: ovn -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1911132 Title: OVN mech driver - can't find Logical_Router errors Status in neutron: New Bug description: I saw such errors in the CI job's logs. Traceback: Jan 07 15:32:40.720920 ubuntu-focal-ovh-bhs1-0022432336 neutron- server[68561]: ERROR ovsdbapp.backend.ovs_idl.command [None req- c0d71b7e-d2a9-4528-9e1a-22437c79fbf1 admin admin] Error executing command: ovsdbapp.backend.ovs_idl.idlutils.RowNotFound: Cannot find Logical_Router with name=neutron-99840546-2921-4f59-a540-aee4e964b3f2 Jan 07 15:32:40.720920 ubuntu-focal-ovh-bhs1-0022432336 neutron- server[68561]: ERROR ovsdbapp.backend.ovs_idl.command Traceback (most recent call last): Jan 07 15:32:40.720920 ubuntu-focal-ovh-bhs1-0022432336 neutron- server[68561]: ERROR ovsdbapp.backend.ovs_idl.command File "/usr/local/lib/python3.8/dist- packages/ovsdbapp/backend/ovs_idl/command.py", line 39, in execute Jan 07 15:32:40.720920 ubuntu-focal-ovh-bhs1-0022432336 neutron- server[68561]: ERROR ovsdbapp.backend.ovs_idl.command self.run_idl(None) Jan 07 15:32:40.720920 ubuntu-focal-ovh-bhs1-0022432336 neutron- server[68561]: ERROR ovsdbapp.backend.ovs_idl.command File "/usr/local/lib/python3.8/dist- packages/ovsdbapp/backend/ovs_idl/command.py", line 328, in run_idl Jan 07 15:32:40.720920 ubuntu-focal-ovh-bhs1-0022432336 neutron- server[68561]: ERROR ovsdbapp.backend.ovs_idl.command self.result = self.api.lookup(self.table, self.record) Jan 07 15:32:40.720920 ubuntu-focal-ovh-bhs1-0022432336 neutron- server[68561]: ERROR ovsdbapp.backend.ovs_idl.command File "/usr/local/lib/python3.8/dist- packages/ovsdbapp/backend/ovs_idl/__init__.py", line 177, in lookup Jan 07 15:32:40.720920 ubuntu-focal-ovh-bhs1-0022432336 neutron- server[68561]: ERROR ovsdbapp.backend.ovs_idl.command return self._lookup(table,
[Yahoo-eng-team] [Bug 1911128] [NEW] Neutron with ovn driver failed to start on Fedora
Public bug reported:
Our periodic job neutron-ovn-tempest-ovs-master-fedora is failing since
some time 100% of times. It fails due to failed neutron-server start.
Error in the neutron logs is like below:
Jan 11 06:30:42.031451 fedora-32-limestone-regionone-0022468210
neutron-server[88725]:
/usr/local/lib64/python3.8/site-packages/sqlalchemy/orm/relationships.py:1994:
SAWarning: Setting backref / back_populates on relationship
QosNetworkPolicyBinding.port to refer to viewonly relationship
Port.qos_network_policy_binding should include sync_backref=False set on the
QosNetworkPolicyBinding.port relationship. (this warning may be suppressed
after 10 occurrences)
Jan 11 06:30:42.031451 fedora-32-limestone-regionone-0022468210
neutron-server[88725]: util.warn_limited(
Jan 11 06:30:42.032081 fedora-32-limestone-regionone-0022468210
neutron-server[89301]: ERROR neutron_lib.callbacks.manager [-] Error during
notification for
neutron.plugins.ml2.drivers.ovn.mech_driver.mech_driver.OVNMechanismDriver.post_fork_initialize-627086
process, after_init: Exception: Could not retrieve schema from
ssl:10.4.70.225:6641
Jan 11 06:30:42.032081 fedora-32-limestone-regionone-0022468210
neutron-server[89301]: ERROR neutron_lib.callbacks.manager Traceback (most
recent call last):
Jan 11 06:30:42.032081 fedora-32-limestone-regionone-0022468210
neutron-server[89301]: ERROR neutron_lib.callbacks.manager File
"/usr/local/lib/python3.8/site-packages/neutron_lib/callbacks/manager.py", line
197, in _notify_loop
Jan 11 06:30:42.032081 fedora-32-limestone-regionone-0022468210
neutron-server[89301]: ERROR neutron_lib.callbacks.manager
callback(resource, event, trigger, **kwargs)
Jan 11 06:30:42.032081 fedora-32-limestone-regionone-0022468210
neutron-server[89301]: ERROR neutron_lib.callbacks.manager File
"/opt/stack/neutron/neutron/plugins/ml2/drivers/ovn/mech_driver/mech_driver.py",
line 272, in post_fork_initialize
Jan 11 06:30:42.032081 fedora-32-limestone-regionone-0022468210
neutron-server[89301]: ERROR neutron_lib.callbacks.manager
self._wait_for_pg_drop_event()
Jan 11 06:30:42.032081 fedora-32-limestone-regionone-0022468210
neutron-server[89301]: ERROR neutron_lib.callbacks.manager File
"/opt/stack/neutron/neutron/plugins/ml2/drivers/ovn/mech_driver/mech_driver.py",
line 340, in _wait_for_pg_drop_event
Jan 11 06:30:42.032081 fedora-32-limestone-regionone-0022468210
neutron-server[89301]: ERROR neutron_lib.callbacks.manager idl =
ovsdb_monitor.OvnInitPGNbIdl.from_server(
Jan 11 06:30:42.032081 fedora-32-limestone-regionone-0022468210
neutron-server[89301]: ERROR neutron_lib.callbacks.manager File
"/opt/stack/neutron/neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/ovsdb_monitor.py",
line 582, in from_server
Jan 11 06:30:42.032081 fedora-32-limestone-regionone-0022468210
neutron-server[89301]: ERROR neutron_lib.callbacks.manager helper =
idlutils.get_schema_helper(connection_string, schema_name)
Jan 11 06:30:42.032081 fedora-32-limestone-regionone-0022468210
neutron-server[89301]: ERROR neutron_lib.callbacks.manager File
"/usr/local/lib/python3.8/site-packages/ovsdbapp/backend/ovs_idl/idlutils.py",
line 204, in get_schema_helper
Jan 11 06:30:42.032081 fedora-32-limestone-regionone-0022468210
neutron-server[89301]: ERROR neutron_lib.callbacks.manager raise
Exception("Could not retrieve schema from %s" % connection)
Jan 11 06:30:42.032081 fedora-32-limestone-regionone-0022468210
neutron-server[89301]: ERROR neutron_lib.callbacks.manager Exception: Could not
retrieve schema from ssl:10.4.70.225:6641
Jan 11 06:30:42.032081 fedora-32-limestone-regionone-0022468210
neutron-server[89301]: ERROR neutron_lib.callbacks.manager
Jan 11 06:30:42.033155 fedora-32-limestone-regionone-0022468210
neutron-server[89302]: ERROR neutron_lib.callbacks.manager [-] Error during
notification for
neutron.plugins.ml2.drivers.ovn.mech_driver.mech_driver.OVNMechanismDriver.post_fork_initialize-627086
process, after_init: Exception: Could not retrieve schema from
ssl:10.4.70.225:6641
Jan 11 06:30:42.033155 fedora-32-limestone-regionone-0022468210
neutron-server[89302]: ERROR neutron_lib.callbacks.manager Traceback (most
recent call last):
Jan 11 06:30:42.033155 fedora-32-limestone-regionone-0022468210
neutron-server[89302]: ERROR neutron_lib.callbacks.manager File
"/usr/local/lib/python3.8/site-packages/neutron_lib/callbacks/manager.py", line
197, in _notify_loop
Jan 11 06:30:42.033155 fedora-32-limestone-regionone-0022468210
neutron-server[89302]: ERROR neutron_lib.callbacks.manager
callback(resource, event, trigger, **kwargs)
Jan 11 06:30:42.033155 fedora-32-limestone-regionone-0022468210
neutron-server[89302]: ERROR neutron_lib.callbacks.manager File
"/opt/stack/neutron/neutron/plugins/ml2/drivers/ovn/mech_driver/mech_driver.py",
line 272, in post_fork_initialize
Jan 11 06:30:42.033155 fedora-32-limestone-regionone-0022468210
neutron-server[89302]: ERROR
[Yahoo-eng-team] [Bug 1911126] [NEW] [RFE][L3] add ability to control router SNAT more granularly
Public bug reported: Neutron router now supports SNAT when the attribute ``enable_snat`` of the gateway is set to True. This will enable all the VMs which has no binding floating IP to access the public world. But, generally the DataCenter bandwidths for cloud providers are not free. And some users may want to buy a higher SNAT bandwidth for one of their VMs, a CIDR, or a subnet. So for Neutron, it should support these scenarios: 1. enable/disable SNAT once for all (supported, controlled by ``enable_snat``) 2. enable/disable SNAT for one internal IP (of VM) 3. enable/disable SNAT for a range CIDR of IPs 4. enable/disable SNAT for a subnet For 2., 3. and 4. scenario should have QoS support. So I would like to add a new mechanism for Neutron to support these: 1. An new API extension to add specific SNAT type 2. An new L3 agent extension to install SNAT iptables rules. Ideas? ** Affects: neutron Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1911126 Title: [RFE][L3] add ability to control router SNAT more granularly Status in neutron: New Bug description: Neutron router now supports SNAT when the attribute ``enable_snat`` of the gateway is set to True. This will enable all the VMs which has no binding floating IP to access the public world. But, generally the DataCenter bandwidths for cloud providers are not free. And some users may want to buy a higher SNAT bandwidth for one of their VMs, a CIDR, or a subnet. So for Neutron, it should support these scenarios: 1. enable/disable SNAT once for all (supported, controlled by ``enable_snat``) 2. enable/disable SNAT for one internal IP (of VM) 3. enable/disable SNAT for a range CIDR of IPs 4. enable/disable SNAT for a subnet For 2., 3. and 4. scenario should have QoS support. So I would like to add a new mechanism for Neutron to support these: 1. An new API extension to add specific SNAT type 2. An new L3 agent extension to install SNAT iptables rules. Ideas? To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1911126/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
