[Yahoo-eng-team] [Bug 1799953] Re: growpart does not work for lvm

2021-05-05 Thread Scott Moser
This is *not* fixed in cloud-init 21.2 as reported.
It was fixed at https://github.com/canonical/cloud-init/pull/721
under commit 74fa008bfcd3263eb691cc0b3f7a055b17569f8b.
but then reverted under https://github.com/canonical/cloud-init/pull/887 .

So... marking this Triaged.


** Changed in: cloud-init
   Status: Fix Released => Triaged

-- 
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/1799953

Title:
  growpart does not work for lvm

Status in cloud-init:
  Triaged
Status in cloud-utils:
  Fix Released

Bug description:
  Similar to bug 1491148, growpart does not support growing a lvm device.
  It would be good if growpart in conjunction with cloud-init could
  recognize that the filesystem was on a volume and grow the underlying
  partition or volume group.

  Related bugs:
   bug 1491148: growpart doesn't work with mdraid devices

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1799953/+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 1402406] Re: Archlinux locale configuration broken

2021-05-05 Thread James Falcon
This bug is believed to be fixed in cloud-init in version 21.2. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   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/1402406

Title:
  Archlinux locale configuration broken

Status in cloud-init:
  Fix Released

Bug description:
  The method for configuring the locale information for Arch is
  incorrect; it's writing "LANG=lang.CP CP" to /etc/locale.gen which
  should just be "lang.CP CP" (no foo=bar) as a naked line. The LANG= is
  to be written to /etc/locale.conf instead.

  http://bazaar.launchpad.net/~cloud-init-dev/cloud-
  init/trunk/view/head:/cloudinit/distros/arch.py#L47

  Provider (Rackspace) generated config value:

  # grep ^locale /etc/cloud/cloud.cfg.d/10_rackspace.cfg 
  locale: en_US.UTF-8 UTF-8

  
  == Existing code ==

  # cat /etc/locale.gen
  # Created by cloud-init v. 0.7.6 on Sun, 14 Dec 2014 15:23:26 +
  LANG="en_US.UTF-8 UTF-8"

  # locale-gen 
  Generating locales...
LANG="en_US.UTF-8"...character map file `UTF-8"' not found: No such file or 
directory
  cannot open locale definition file `LANG="en_US': No such file or directory

  == Manually fixed ==

  # cat /etc/locale.gen 
  # Created by cloud-init v. 0.7.6 on Sun, 14 Dec 2014 15:23:26 +
  en_US.UTF-8 UTF-8

  # locale-gen
  Generating locales...
en_US.UTF-8... done
  Generation complete.

  

  The attached patch takes a stab at correcting arch.py, however I'm not
  a Python coder so YMMV. Based on the existing code, it seems to be
  expected the Provider always specify "lang.CP CP" for 'locale' in the
  cloud.cfg file(s) so this patch is based on that expectation, using
  split() looking for the space and peeling off the first element for
  /etc/locale.conf setup.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1402406/+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 1918303] Re: Randomly set credentials written in cleartext to world-readable file

2021-05-05 Thread James Falcon
This bug is believed to be fixed in cloud-init in version 21.2. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   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/1918303

Title:
  Randomly set credentials written in cleartext to world-readable file

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

Bug description:
  ## Summary

  cloud-init allows administrators to set passwords for user accounts
  via the chpasswd configuration module. Administrators can instruct
  cloud-init to set a random password generated at runtime using the 'R'
  or 'RANDOM' keywords.

  However, cloud-init appears to write all randomly generated passwords
  in cleartext to stderr. Cloud-init's default logging configuration, in
  file /etc/cloud/cloud.cfg.d/05_logging.cfg, redirects both stdout and
  stderr to the log file /var/log/cloud-init-output.log. The file
  /var/log/cloud-init-output.log is world readable. Thus, any
  unprivileged account on the system can view the cleartext password for
  any account which had a random password generated at runtime. The
  credentials are not redacted in the log.

  ## Reproduction

  Pre-requisites: A device with Ubuntu Server 20.04 installed. Ubuntu
  Server comes with cloud-init pre-installed out of the box, but the
  latest release of cloud-init as of this report (21.1) is not available
  in 20.04's apt repositories. You may need to install v21.1 manually.
  You will also need an exsiting admin account with root privileges.

  1. Login as admin.
  2. Create an unprivileged user account, bob, and set a password. We will use 
this account to demonstrate unprivileged account access to generated passwords.
  sudo adduser bob
  3. Create another unprivileged user account, alice, and set a password. We 
will change this account's password with cloud-init.
  sudo adduser alice
  4. Create and open configuration file /etc/cloud/cloud.cfg.d/95_chpasswd.cfg 
using vim or other editor of your choice.
  sudo vim /etc/cloud/cloud.cfg.d/95_chpasswd.cfg
  5. Add the following chpasswd configuration content to the file then save and 
exit.
  chpasswd:
list: |
  alice:RANDOM
  6. cloud-init only runs the chpasswd function on first boot of the OS that 
cloud-init knows about. For proof of concept purposes, we need to simulate a 
new instance. Run:
  sudo cloud-init clean
  to reset cloud-init's state.
  7. Reboot the system.
  sudo reboot
  8. Login as unprivileged user bob.
  9. View the password by runnnig
  cat /var/log/cloud-init-output.log | grep alice
  10. Alice's temporary password should appear on terminal in the form 
alice:
  11. Logout and log back in to the system as alice using the temporary 
password. You should get access and prompted to set a new password, which 
confirms the password bob retrieved from the logs is the actual password for 
alice's account.

  ## Impact

  Any unprivileged user on the system can retrieve all cloud-init
  randomly set credentials. These could potentially be used to access
  other accounts.

  # Notes

  If 'expire: false' is added to the chpasswd config, then leaked
  passwords remain valid until manually changed and increases the risk
  of unauthorized account access. Otherwise, the default behaviour
  prompts accounts to set a new password at next login, reducing the
  time window for unauthorized access.

  Accounts not used for interactive login might not get passwords
  changed or accounts might get a password set but then not authenticate
  for some time. The precise impact and duration of valid exposed
  credentials appears dependent somewhat on each cloud-init customer's
  environment and how they use cloud-init to set credentials.

  I'm not sure the best approach to patch this but perhaps the
  credentials could be written to cloud-init's protected directories or
  files which restrict access to root users only, such as /var/run
  /cloud-init/instance-data-sensitive.json?

  Line 214 of https://github.com/canonical/cloud-
  init/blob/master/cloudinit/config/cc_set_passwords.py checks if any
  random passwords were set and if so prints each one to stderror. This
  might be the root cause.

  Tested on Ubuntu Server 20.04.02, cloud-init latest release 21.1 as of report 
time. If I can provide any further information please let me know. Thanks!
  -Carl

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1918303/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to

[Yahoo-eng-team] [Bug 1922739] Re: AttributeError: 'DataSourceNoCloud' object has no attribute 'vendordata2_raw'

2021-05-05 Thread James Falcon
This bug is believed to be fixed in cloud-init in version 21.2. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   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/1922739

Title:
  AttributeError: 'DataSourceNoCloud' object has no attribute
  'vendordata2_raw'

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]
  In PR #777, we added 'vendordata2' and 'vendordata2_raw' attributes to the 
DataSource class, but didn't use the upgrade framework to deal with an unpickle 
after upgrade. Because of this, anybody upgrading their cloud-init from an 
older version to 21.1 who hasn't also run `cloud-init clean` will have 
cloud-init fail with a traceback.

  The change here should fix that failure.

  [Test Plan]
  Launch an instance or install a cloud-init package using version earlier than 
21.1-19-gbad84ad4-0ubuntu1 (if downgrading also run `cloud-init clean`).

  Upgrade to 21.1-19-gbad84ad4-0ubuntu1 or later, then reboot (without
  running `cloud-init clean`).

  On un-patched versions, `cloud-init status` will show error, and there
  will be a traceback in /var/log/cloud-init.log. Patched versions
  should show no error or traceback.

  [Where problems could occur]
  Any problem here would mean we're continuing to unpickle data incorrectly, 
thus we'd see similar behavior to the bug we're fixing.

  [Other Info]
  Pull request: https://github.com/canonical/cloud-init/pull/869
  Commit: 
https://github.com/canonical/cloud-init/commit/d132356cc361abef2d90d4073438f3ab759d5964

  A test has also been added upstream and to our CI to prevent these
  types of errors from happening in the future:
  https://github.com/canonical/cloud-
  init/blob/master/tests/integration_tests/test_upgrade.py#L107

  == End SRU Template ==

  == Original Description ==

  On a test LXD VM instance, I see:

  2021-04-06 14:05:11,296 - util.py[WARNING]: failed stage init
  2021-04-06 14:05:11,302 - util.py[DEBUG]: failed stage init
  Traceback (most recent call last):
    File "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 652, in 
status_wrapper
  ret = functor(name, args)
    File "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 376, in 
main_init
  init.update()
    File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 371, in 
update
  self._store_raw_vendordata(self.datasource.get_vendordata2_raw(),
    File "/usr/lib/python3/dist-packages/cloudinit/sources/__init__.py", line 
506, in get_vendordata2_raw
  return self.vendordata2_raw
  AttributeError: 'DataSourceNoCloud' object has no attribute 'vendordata2_raw'

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1922739/+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 1916629] Re: pytests: TestApt tests parsing the apt-key output fail on Xenial and Hirsute

2021-05-05 Thread James Falcon
This bug is believed to be fixed in cloud-init in version 21.2. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   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/1916629

Title:
  pytests: TestApt tests parsing the apt-key output fail on Xenial and
  Hirsute

Status in cloud-init:
  Fix Released

Bug description:
  Sample error:

  

  def test_keyserver(self, class_client: IntegrationInstance):
  """Test the apt keyserver functionality.
  
  Ported from
  tests/cloud_tests/testcases/modules/apt_configure_sources_keyserver.py
  """
  test_keyserver_contents = class_client.read_from_file(
  '/etc/apt/sources.list.d/test_keyserver.list'
  )
  
  assert (
  'http://ppa.launchpad.net/cloud-init-raharper/curtin-dev/ubuntu'
  ) in test_keyserver_contents
  
  keys = class_client.execute('apt-key finger')
  >   assert TEST_KEYSERVER_KEY in keys
  E   AssertionError: assert 'pub   rsa1024 2013-12-09 [SC]\n  7260 
0DB1 5B8E 4C8B 1964  B868 038A CC97 C660 A937\nuid   [ unknown] 
Launchpad PPA for Ryan Harper\n' in 
'/etc/apt/trusted.gpg\n\npub   1024D/437D05B5 2004-09-12\n  
Key fingerprint = 6302 39CC 130E 1...erprint = 3552 C902 B4DD F7BD 3842  
1821 015D 28D7 4416 14D8\nuid  Launchpad PPA for 
simplestreams-dev'

  class_client = 
  keys   = '/etc/apt/trusted.gpg\n\npub   
1024D/437D05B5 2004-09-12\n  Key fingerprint = 6302 39CC 130E 1...erprint = 
3552 C902 B4DD F7BD 3842  1821 015D 28D7 4416 14D8\nuid  
Launchpad PPA for simplestreams-dev'
  self   = 
  test_keyserver_contents = 'deb 
http://ppa.launchpad.net/cloud-init-raharper/curtin-dev/ubuntu xenial main'

  

  PR: https://github.com/canonical/cloud-init/pull/823

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1916629/+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 1917875] Re: Change breaks cloud-init on Ali

2021-05-05 Thread James Falcon
This bug is believed to be fixed in cloud-init in version 21.2. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   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/1917875

Title:
  Change breaks cloud-init on Ali

Status in cloud-init:
  Fix Released

Bug description:
  Hi,

  cloud-init change

  https://github.com/canonical/cloud-
  init/commit/70dbccbbb27f7cc3f2decd692d41403f0d745c62

  appears to break cloud-init on Aliyun. We had been using a version
  20.2 or more precisely

  http://ftp.de.debian.org/debian/pool/main/c/cloud-init/cloud-
  init_20.2-2~deb10u1_all.deb

  with no issues. Version 20.4.1 or more precisely

  http://ftp.de.debian.org/debian/pool/main/c/cloud-init/cloud-
  init_20.4.1-1_all.deb

  breaks with the log output shown below. As the key device-number is
  not used in 20.2 this clearly points to the change referenced above.
  It is kind of unclear where that key is supposed to be configured as
  there is no other reference to that in the code.

  This is more or less a standard Debian configuration that we are using from 
the packages referenced above. This appears to cause user and group management 
to be skipped which is causing us headache. Quite interestingly
  it does work find on AWS which appears to use the same code.

  Let me know if you need anything else.

  2021-03-05 16:47:30,866 - util.py[DEBUG]: loaded blob returned None, 
returning default.
  2021-03-05 16:47:30,867 - util.py[DEBUG]: Reading from 
/sys/class/net/lo/address (quiet=False)
  2021-03-05 16:47:30,867 - util.py[DEBUG]: Read 18 bytes from 
/sys/class/net/lo/address
  2021-03-05 16:47:30,867 - util.py[DEBUG]: Reading from 
/sys/class/net/ens5/address (quiet=False)
  2021-03-05 16:47:30,867 - util.py[DEBUG]: Read 18 bytes from 
/sys/class/net/ens5/address
  2021-03-05 16:47:30,868 - util.py[DEBUG]: Reading from 
/sys/class/net/ens5/name_assign_type (quiet=False)
  2021-03-05 16:47:30,868 - util.py[DEBUG]: Read 2 bytes from 
/sys/class/net/ens5/name_assign_type
  2021-03-05 16:47:30,868 - util.py[DEBUG]: Reading from 
/sys/class/net/ens5/carrier (quiet=False)
  2021-03-05 16:47:30,868 - util.py[DEBUG]: Read 2 bytes from 
/sys/class/net/ens5/carrier
  2021-03-05 16:47:30,868 - util.py[DEBUG]: Reading from 
/sys/class/net/ens5/address (quiet=False)
  2021-03-05 16:47:30,868 - util.py[DEBUG]: Read 18 bytes from 
/sys/class/net/ens5/address
  2021-03-05 16:47:30,868 - util.py[DEBUG]: Reading from 
/sys/class/net/lo/addr_assign_type (quiet=False)
  2021-03-05 16:47:30,868 - util.py[DEBUG]: Read 2 bytes from 
/sys/class/net/lo/addr_assign_type
  2021-03-05 16:47:30,868 - util.py[DEBUG]: Reading from 
/sys/class/net/lo/uevent (quiet=False)
  2021-03-05 16:47:30,868 - util.py[DEBUG]: Read 23 bytes from 
/sys/class/net/lo/uevent
  2021-03-05 16:47:30,868 - util.py[DEBUG]: Reading from 
/sys/class/net/lo/address (quiet=False)
  2021-03-05 16:47:30,868 - util.py[DEBUG]: Read 18 bytes from 
/sys/class/net/lo/address
  2021-03-05 16:47:30,868 - util.py[DEBUG]: Reading from 
/sys/class/net/lo/device/device (quiet=False)
  2021-03-05 16:47:30,868 - util.py[DEBUG]: Reading from 
/sys/class/net/ens5/addr_assign_type (quiet=False)
  2021-03-05 16:47:30,868 - util.py[DEBUG]: Read 2 bytes from 
/sys/class/net/ens5/addr_assign_type
  2021-03-05 16:47:30,868 - util.py[DEBUG]: Reading from 
/sys/class/net/ens5/uevent (quiet=False)
  2021-03-05 16:47:30,869 - util.py[DEBUG]: Read 25 bytes from 
/sys/class/net/ens5/uevent
  2021-03-05 16:47:30,869 - util.py[DEBUG]: Reading from 
/sys/class/net/ens5/address (quiet=False)
  2021-03-05 16:47:30,869 - util.py[DEBUG]: Read 18 bytes from 
/sys/class/net/ens5/address
  2021-03-05 16:47:30,869 - util.py[DEBUG]: Reading from 
/sys/class/net/ens5/device/device (quiet=False)
  2021-03-05 16:47:30,869 - util.py[DEBUG]: Read 7 bytes from 
/sys/class/net/ens5/device/device
  2021-03-05 16:47:30,869 - util.py[DEBUG]: Reading from /sys/class/net/lo/type 
(quiet=False)
  2021-03-05 16:47:30,869 - util.py[DEBUG]: Read 4 bytes from 
/sys/class/net/lo/type
  2021-03-05 16:47:30,869 - util.py[DEBUG]: Reading from 
/sys/class/net/ens5/type (quiet=False)
  2021-03-05 16:47:30,869 - util.py[DEBUG]: Read 2 bytes from 
/sys/class/net/ens5/type
  2021-03-05 16:47:30,869 - util.py[WARNING]: failed stage init
  2021-03-05 16:47:30,869 - util.py[DEBUG]: failed stage init
  Traceback (most recent call last):
    File "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 653, in 
status_wrapper
  ret = functor(name, args)
    File "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 362, in 
main_init
  init.apply_network_config(bring_up=bool(mode != sources.DSMODE_LOCAL))
    File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 678, in 
apply_network

[Yahoo-eng-team] [Bug 1922742] Re: Failed: can't get Volume Group information from /dev/sda1

2021-05-05 Thread James Falcon
This bug is believed to be fixed in cloud-init in version 21.2. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   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/1922742

Title:
  Failed: can't get Volume Group information from /dev/sda1

Status in cloud-init:
  Fix Released

Bug description:
  When running tests in LXD VMs (LXD containers don't perform disk
  setup, as they don't have their own disks), I see:

  2021-04-06 14:31:24,084 - helpers.py[DEBUG]: Running config-growpart using 
lock ()
  2021-04-06 14:31:24,084 - cc_growpart.py[DEBUG]: No 'growpart' entry in cfg.  
Using default: {'mode': 'auto', 'devices': ['/'], 'ignore_growroot_disabled': 
False}
  2021-04-06 14:31:24,084 - subp.py[DEBUG]: Running command ['growpart', 
'--help'] with allowed return codes [0] (shell=False, capture=True)
  2021-04-06 14:31:24,092 - util.py[DEBUG]: Reading from /proc/503/mountinfo 
(quiet=False)
  2021-04-06 14:31:24,092 - util.py[DEBUG]: Read 3726 bytes from 
/proc/503/mountinfo
  2021-04-06 14:31:24,093 - subp.py[DEBUG]: Running command ['lvm', 'lvs', 
'/dev/sda1', '--options=vgname', '--noheadings'] with allowed return codes [0] 
(shell=False, capture=True)
  2021-04-06 14:31:24,138 - util.py[WARNING]: Failed: can't get Volume Group 
information from /dev/sda1
  2021-04-06 14:31:24,138 - util.py[DEBUG]: Failed: can't get Volume Group 
information from /dev/sda1
  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
125, in get_pvs_for_lv
  (out, _err) = subp.subp(["lvm", "lvs", devpath, "--options=vgname",
File "/usr/lib/python3/dist-packages/cloudinit/subp.py", line 293, in subp
  raise ProcessExecutionError(stdout=out, stderr=err,
  cloudinit.subp.ProcessExecutionError: Unexpected error while running command.
  Command: ['lvm', 'lvs', '/dev/sda1', '--options=vgname', '--noheadings']
  Exit code: 5
  Reason: -
  Stdout: 
  Stderr:   Volume group "sda1" not found
Cannot process volume group sda1
  2021-04-06 14:31:24,140 - util.py[DEBUG]: resize_devices took 0.048 seconds
  2021-04-06 14:31:24,140 - handlers.py[DEBUG]: finish: 
init-network/config-growpart: FAIL: running config-growpart with frequency 
always
  2021-04-06 14:31:24,140 - util.py[WARNING]: Running module growpart () failed
  2021-04-06 14:31:24,142 - util.py[DEBUG]: Running module growpart () failed
  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
125, in get_pvs_for_lv
  (out, _err) = subp.subp(["lvm", "lvs", devpath, "--options=vgname",
File "/usr/lib/python3/dist-packages/cloudinit/subp.py", line 293, in subp
  raise ProcessExecutionError(stdout=out, stderr=err,
  cloudinit.subp.ProcessExecutionError: Unexpected error while running command.
  Command: ['lvm', 'lvs', '/dev/sda1', '--options=vgname', '--noheadings']
  Exit code: 5
  Reason: -
  Stdout: 
  Stderr:   Volume group "sda1" not found
Cannot process volume group sda1

  The above exception was the direct cause of the following exception:

  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 884, in 
_run_modules
  ran, _r = cc.run(run_name, mod.handle, func_args,
File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run
  return self._runners.run(name, functor, args, freq, clear_on_fail)
File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 185, in run
  results = functor(*args)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
434, in handle
  resized = util.log_time(logfunc=log.debug, msg="resize_devices",
File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2348, in 
log_time
  ret = func(*args, **kwargs)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
358, in resize_devices
  disk, ptnum = device_part_info(blockdev, is_lvm)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
273, in device_part_info
  lvm_rpath = get_pvs_for_lv(devpath)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
132, in get_pvs_for_lv
  raise ResizeFailedException(e) from e
  cloudinit.config.cc_growpart.ResizeFailedException: Unexpected error while 
running command.
  Command: ['lvm', 'lvs', '/dev/sda1', '--options=vgname', '--noheadings']
  Exit code: 5
  Reason: -
  Stdout: 
  Stderr:   Volume group "sda1" not found
Cannot process volume group sda1

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1922742/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-

[Yahoo-eng-team] [Bug 1921004] Re: Add an option to use short hostname in RHEL

2021-05-05 Thread James Falcon
This bug is believed to be fixed in cloud-init in version 21.2. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   Status: Triaged => 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/1921004

Title:
  Add an option to use short hostname in RHEL

Status in cloud-init:
  Fix Released

Bug description:
  cloud init with RHEL always use the FQDN over the hostname even if the 
hostname is sent like below
  #cloud-config
  ---
  hostname: shortname

  the problem with always using the FQDN as hostname is the linux
  constrain on hostname length

  getconf HOST_NAME_MAX
  64

  the FQDN is used for DNS and the DNS servers has no limit on that but
  using as hostname raise an error when cloud init try to set the
  hostname and fail cloud init

  an option should be provided for RHEL like below

  #cloud-config
  ---
  enable_shortname: true 

  to change the default behavior from FQDN to the
  1. hostname if send
  2. short hostname from the FQDN

  and the /etc/resolv.conf
  search 

  so if the hostname is test.domain.com

  the hostname will be *test*
  and the
  /etc/resolv.conf
  search domain.com

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1921004/+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 1799953] Re: growpart does not work for lvm

2021-05-05 Thread James Falcon
This bug is believed to be fixed in cloud-init in version 21.2. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   Status: Triaged => 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/1799953

Title:
  growpart does not work for lvm

Status in cloud-init:
  Fix Released
Status in cloud-utils:
  Fix Released

Bug description:
  Similar to bug 1491148, growpart does not support growing a lvm device.
  It would be good if growpart in conjunction with cloud-init could
  recognize that the filesystem was on a volume and grow the underlying
  partition or volume group.

  Related bugs:
   bug 1491148: growpart doesn't work with mdraid devices

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1799953/+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 1919188] Re: cloud-init: checking cmdline for ip= is too broad

2021-05-05 Thread James Falcon
This bug is believed to be fixed in cloud-init in version 21.2. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   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/1919188

Title:
  cloud-init: checking cmdline for ip= is too broad

Status in cloud-init:
  Fix Released

Bug description:
  klibc initramfs in debian (and I think Ubunutu as well) allows the
  'iscsi_target_ip=' cmdline parameter to specify an iscsi device
  attachment. The cloud-init code to check "whether this system has
  klibc initramfs network config or not" checks if the 'ip=' string is
  present in the cmdline. The python code to do this
  (https://github.com/canonical/cloud-
  init/blob/master/cloudinit/net/cmdline.py#L75) will match any
  parameter in the cmdline that contains 'ip='. For iSCSI volumes, the
  code still works (by accident?) because the next line checks for an
  open-iscsi interface file, which should exist if we are using iSCSI.

  However, it raises the possibility that there are other commandline
  parameters being used out in the wild that contain 'ip=' that may
  erroneously be marked by cloud-init as specifying an initramfs network
  config option. An example fix would be using a regular expression to
  check that either whitespace or beginning of the line precedes 'ip'.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1919188/+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 1920939] Re: blockdev: ioctl error on BLKRRPART: Device or resource busy

2021-05-05 Thread James Falcon
This bug is believed to be fixed in cloud-init in version 21.2. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   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/1920939

Title:
  blockdev: ioctl error on BLKRRPART: Device or resource busy

Status in cloud-init:
  Fix Released

Bug description:
  During disk setup partition table cannot reload and fails with

  blockdev: ioctl error on BLKRRPART: Device or resource busy

  This is caused by `/` being mounted.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1920939/+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 1927254] Re: Release 21.2

2021-05-05 Thread James Falcon
This bug is believed to be fixed in cloud-init in version 21.2. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
   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/1927254

Title:
  Release 21.2

Status in cloud-init:
  Fix Released

Bug description:
  == Release Notes ==

  Cloud-init release 21.2 is now available

  The 21.2 release:
   * spanned about 2 months
   * had 23 contributors from 23 domains
   * fixed 12 Launchpad issues

  Highlights:
   - Azure support for consuming userdata from IMDS
   - Prefer partprobe for reading partition table if available
   - New config option to specify use of short hostname vs fqdn
   - Support BONDING_MODULE_OPTS on SUSE in sysconfig

  == Changelog ==
   - Add \r\n check for SSH keys in Azure (#889)
   - Revert "Add support to resize rootfs if using LVM (#721)" (#887)
     (LP: #1922742)
   - Add Vultaire as contributor (#881) [Paul Goins]
   - Azure: adding support for consuming userdata from IMDS (#884) [Anh Vo]
   - test_upgrade: modify test_upgrade_package to run for more sources (#883)
   - Fix chef module run failure when chef_license is set (#868) [Ben Hughes]
   - Azure: Retry net metadata during nic attach for non-timeout errs (#878)
     [aswinrajamannar]
   - Azure: Retrieve username and hostname from IMDS (#865) [Thomas Stringer]
   - Azure: eject the provisioning iso before reporting ready (#861) [Anh Vo]
   - Use `partprobe` to re-read partition table if available (#856)
     [Nicolas Bock] (LP: #1920939)
   - fix error on upgrade caused by new vendordata2 attributes (#869)
     (LP: #1922739)
   - add prefer_fqdn_over_hostname config option (#859)
     [hamalq] (LP: #1921004)
   - Emit dots on travis to avoid timeout (#867)
   - doc: Replace remaining references to user-scripts as a config module
     (#866) [Ryan Harper]
   - azure: Removing ability to invoke walinuxagent (#799) [Anh Vo]
   - Add Vultr support (#827) [David Dymko]
   - Fix unpickle for source paths missing run_dir (#863)
     [lucasmoura] (LP: #1899299)
   - sysconfig: use BONDING_MODULE_OPTS on SUSE (#831) [Jens Sandmann]
   - bringup_static_routes: fix gateway check (#850) [Petr Fedchenkov]
   - add hamalq user (#860) [hamalq]
   - Add support to resize rootfs if using LVM (#721)
     [Eduardo Otubo] (LP: #1799953)
   - Fix mis-detecting network configuration in initramfs cmdline (#844)
     (LP: #1919188)
   - tools/write-ssh-key-fingerprints: do not display empty header/footer
     (#817) [dermotbradley]
   - Azure helper: Ensure Azure http handler sleeps between retries (#842)
     [Johnson Shi]
   - Fix chef apt source example (#826) [timothegenzmer]
   - .travis.yml: generate an SSH key before running tests (#848)
   - write passwords only to serial console, lock down cloud-init-output.log
     (#847) (LP: #1918303)
   - Fix apt default integration test (#845)
   - integration_tests: bump pycloudlib dependency (#846)
   - Fix stack trace if vendordata_raw contained an array (#837) [eb3095]
   - archlinux: Fix broken locale logic (#841)
     [Kristian Klausen] (LP: #1402406)
   - Integration test for #783 (#832)
   - integration_tests: mount more paths IN_PLACE (#838)
   - Fix requiring device-number on EC2 derivatives (#836) (LP: #1917875)
   - Remove the vi comment from the part-handler example (#835)
   - net: exclude OVS internal interfaces in get_interfaces (#829)
     (LP: #1912844)
   - tox.ini: pass OS_* environment variables to integration tests (#830)
   - integration_tests: add OpenStack as a platform (#804)
   - Add flexibility to IMDS api-version (#793) [Thomas Stringer]
   - Fix the TestApt tests using apt-key on Xenial and Hirsute (#823)
     [Paride Legovini] (LP: #1916629)
   - doc: remove duplicate "it" from nocloud.rst (#825) [V.I. Wood]
   - archlinux: Use hostnamectl to set the transient hostname (#797)
     [Kristian Klausen]
   - cc_keys_to_console.py: Add documentation for recently added config key
     (#824) [dermotbradley]
   - Update cc_set_hostname documentation (#818) [Toshi Aoyama]

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1927254/+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 1927261] [NEW] Support for Angular 1.8.x in Horizon

2021-05-05 Thread Vishal Manchanda
Public bug reported:

Some of the horizon angular panels (keypair and glance) are broken in Debian 
Bullseye distribution.
As of now, we use angular 1.5.8.0 in the horizon [1], [2].
We can try to update angularjs to 1.8.2 maybe that fixes the issue.

[1] https://github.com/openstack/horizon/blob/master/requirements.txt#L44
[2] https://pypi.org/project/XStatic-Angular/

Related thread: http://lists.openstack.org/pipermail/openstack-
discuss/2021-May/022243.html

** Affects: horizon
 Importance: Undecided
 Assignee: Vishal Manchanda (vishalmanchanda)
 Status: New

** Changed in: horizon
 Assignee: (unassigned) => Vishal Manchanda (vishalmanchanda)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1927261

Title:
  Support for Angular 1.8.x in Horizon

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  Some of the horizon angular panels (keypair and glance) are broken in Debian 
Bullseye distribution.
  As of now, we use angular 1.5.8.0 in the horizon [1], [2].
  We can try to update angularjs to 1.8.2 maybe that fixes the issue.

  [1] https://github.com/openstack/horizon/blob/master/requirements.txt#L44
  [2] https://pypi.org/project/XStatic-Angular/

  Related thread: http://lists.openstack.org/pipermail/openstack-
  discuss/2021-May/022243.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1927261/+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 1927254] [NEW] Release 21.2

2021-05-05 Thread James Falcon
Public bug reported:

== Release Notes ==

Cloud-init release 21.2 is now available

The 21.2 release:
 * spanned about 2 months
 * had 23 contributors from 23 domains
 * fixed 12 Launchpad issues

Highlights:
  

== Changelog ==
 - Add \r\n check for SSH keys in Azure (#889)
 - Revert "Add support to resize rootfs if using LVM (#721)" (#887)
   (LP: #1922742)
 - Add Vultaire as contributor (#881) [Paul Goins]
 - Azure: adding support for consuming userdata from IMDS (#884) [Anh Vo]
 - test_upgrade: modify test_upgrade_package to run for more sources (#883)
 - Fix chef module run failure when chef_license is set (#868) [Ben Hughes]
 - Azure: Retry net metadata during nic attach for non-timeout errs (#878)
   [aswinrajamannar]
 - Azure: Retrieve username and hostname from IMDS (#865) [Thomas Stringer]
 - Azure: eject the provisioning iso before reporting ready (#861) [Anh Vo]
 - Use `partprobe` to re-read partition table if available (#856)
   [Nicolas Bock] (LP: #1920939)
 - fix error on upgrade caused by new vendordata2 attributes (#869)
   (LP: #1922739)
 - add prefer_fqdn_over_hostname config option (#859)
   [hamalq] (LP: #1921004)
 - Emit dots on travis to avoid timeout (#867)
 - doc: Replace remaining references to user-scripts as a config module
   (#866) [Ryan Harper]
 - azure: Removing ability to invoke walinuxagent (#799) [Anh Vo]
 - Add Vultr support (#827) [David Dymko]
 - Fix unpickle for source paths missing run_dir (#863)
   [lucasmoura] (LP: #1899299)
 - sysconfig: use BONDING_MODULE_OPTS on SUSE (#831) [Jens Sandmann]
 - bringup_static_routes: fix gateway check (#850) [Petr Fedchenkov]
 - add hamalq user (#860) [hamalq]
 - Add support to resize rootfs if using LVM (#721)
   [Eduardo Otubo] (LP: #1799953)
 - Fix mis-detecting network configuration in initramfs cmdline (#844)
   (LP: #1919188)
 - tools/write-ssh-key-fingerprints: do not display empty header/footer
   (#817) [dermotbradley]
 - Azure helper: Ensure Azure http handler sleeps between retries (#842)
   [Johnson Shi]
 - Fix chef apt source example (#826) [timothegenzmer]
 - .travis.yml: generate an SSH key before running tests (#848)
 - write passwords only to serial console, lock down cloud-init-output.log
   (#847) (LP: #1918303)
 - Fix apt default integration test (#845)
 - integration_tests: bump pycloudlib dependency (#846)
 - Fix stack trace if vendordata_raw contained an array (#837) [eb3095]
 - archlinux: Fix broken locale logic (#841)
   [Kristian Klausen] (LP: #1402406)
 - Integration test for #783 (#832)
 - integration_tests: mount more paths IN_PLACE (#838)
 - Fix requiring device-number on EC2 derivatives (#836) (LP: #1917875)
 - Remove the vi comment from the part-handler example (#835)
 - net: exclude OVS internal interfaces in get_interfaces (#829)
   (LP: #1912844)
 - tox.ini: pass OS_* environment variables to integration tests (#830)
 - integration_tests: add OpenStack as a platform (#804)
 - Add flexibility to IMDS api-version (#793) [Thomas Stringer]
 - Fix the TestApt tests using apt-key on Xenial and Hirsute (#823)
   [Paride Legovini] (LP: #1916629)
 - doc: remove duplicate "it" from nocloud.rst (#825) [V.I. Wood]
 - archlinux: Use hostnamectl to set the transient hostname (#797)
   [Kristian Klausen]
 - cc_keys_to_console.py: Add documentation for recently added config key
   (#824) [dermotbradley]
 - Update cc_set_hostname documentation (#818) [Toshi Aoyama]

** Affects: cloud-init
 Importance: Undecided
 Status: New

-- 
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/1927254

Title:
  Release 21.2

Status in cloud-init:
  New

Bug description:
  == Release Notes ==

  Cloud-init release 21.2 is now available

  The 21.2 release:
   * spanned about 2 months
   * had 23 contributors from 23 domains
   * fixed 12 Launchpad issues

  Highlights:
    

  == Changelog ==
   - Add \r\n check for SSH keys in Azure (#889)
   - Revert "Add support to resize rootfs if using LVM (#721)" (#887)
     (LP: #1922742)
   - Add Vultaire as contributor (#881) [Paul Goins]
   - Azure: adding support for consuming userdata from IMDS (#884) [Anh Vo]
   - test_upgrade: modify test_upgrade_package to run for more sources (#883)
   - Fix chef module run failure when chef_license is set (#868) [Ben Hughes]
   - Azure: Retry net metadata during nic attach for non-timeout errs (#878)
     [aswinrajamannar]
   - Azure: Retrieve username and hostname from IMDS (#865) [Thomas Stringer]
   - Azure: eject the provisioning iso before reporting ready (#861) [Anh Vo]
   - Use `partprobe` to re-read partition table if available (#856)
     [Nicolas Bock] (LP: #1920939)
   - fix error on upgrade caused by new vendordata2 attributes (#869)
     (LP: #1922739)
   - add prefer_fqdn_over_hostname config option (#859)
     [hamalq] (LP: #1921004)
   - Emit dots on travis to avoid timeout (#867)
   - doc: Replace remaining refere

[Yahoo-eng-team] [Bug 1926043] Re: Dashboard / Project / Instances error when role member

2021-05-05 Thread Tatiana Ovchinnikova
*** This bug is a duplicate of bug 1905024 ***
https://bugs.launchpad.net/bugs/1905024

** This bug has been marked a duplicate of bug 1905024
   Error when opening instance detailed view

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1926043

Title:
  Dashboard / Project / Instances error when role member

Status in OpenStack Dashboard (Horizon):
  Incomplete

Bug description:
  From ubuntu cloud-archive install of Victoria horizon.
  User with 'member' role only logs in.
  Go to Project / Instances
  Choose an instance the user created
  Dashboard error page occurs
  Logs show Dashboard attempting to access AttributeError: 
OS-EXT-SRV-ATTR:instance_name
  As a 'member' the user can not view this variable.
  openstack CLI correctly just doesn't return it.

  Proposed fix:
  openstack_dashboard/api/base.py line 142
  raise

  change to

  return ""

  With this modification the instances page correctly loads for the
  user.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1926043/+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 1927077] Re: [OVN] Missing lock check in check_for_mcast_flood_reports

2021-05-05 Thread OpenStack Infra
Reviewed:  https://review.opendev.org/c/openstack/neutron/+/789547
Committed: 
https://opendev.org/openstack/neutron/commit/317407fe61b76b8f0c250ce6fb18d93dd0b667d0
Submitter: "Zuul (22348)"
Branch:master

commit 317407fe61b76b8f0c250ce6fb18d93dd0b667d0
Author: Lucas Alvares Gomes 
Date:   Tue May 4 11:33:20 2021 +0100

[OVN] Check for lock in check_for_mcast_flood_reports

The maintenance method check_for_mcast_flood_reports() was not checking
if that instance of the maintenance task has a valid lock before trying
to execute a transaction.

This patch adds such check so instances of the maintenance task without
a valid lock will just return.

Change-Id: I791026058b37f06d1a19b5fb6823b9dbb2a3eca5
Closes-Bug: #1927077
Signed-off-by: Lucas Alvares Gomes 


** Changed in: neutron
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1927077

Title:
  [OVN] Missing lock check in check_for_mcast_flood_reports

Status in neutron:
  Fix Released

Bug description:
  The maintenance method check_for_mcast_flood_reports() is not checking
  if that instance of the maintenance task has a proper lock before
  trying to execute a transaction. If more than one controller is
  deployed only 1 instance will hold a valid lock the rest will fail
  with:

  2021-05-02 14:23:29.193 599 ERROR futurist.periodics [-] Failed to call 
periodic 
'networking_ovn.common.maintenance.DBInconsistenciesPeriodics.check_for_mcast_flood_reports'
 (it runs every 600.00 seconds): RuntimeError: OVSDB Error: The transaction 
failed because the IDL has been configured to require a database lock but 
didn't get it yet or has already lost it
  2021-05-02 14:23:29.193 599 ERROR futurist.periodics Traceback (most recent 
call last):
  2021-05-02 14:23:29.193 599 ERROR futurist.periodics   File 
"/usr/lib/python3.6/site-packages/ovsdbapp/api.py", line 111, in transaction
  2021-05-02 14:23:29.193 599 ERROR futurist.periodics yield 
self._nested_txns_map[cur_thread_id]
  2021-05-02 14:23:29.193 599 ERROR futurist.periodics KeyError: 139844066981736
  2021-05-02 14:23:29.193 599 ERROR futurist.periodics
  2021-05-02 14:23:29.193 599 ERROR futurist.periodics During handling of the 
above exception, another exception occurred:
  2021-05-02 14:23:29.193 599 ERROR futurist.periodics
  2021-05-02 14:23:29.193 599 ERROR futurist.periodics Traceback (most recent 
call last):
  2021-05-02 14:23:29.193 599 ERROR futurist.periodics   File 
"/usr/lib/python3.6/site-packages/futurist/periodics.py", line 290, in run
  2021-05-02 14:23:29.193 599 ERROR futurist.periodics work()
  2021-05-02 14:23:29.193 599 ERROR futurist.periodics   File 
"/usr/lib/python3.6/site-packages/futurist/periodics.py", line 64, in __call__
  2021-05-02 14:23:29.193 599 ERROR futurist.periodics return 
self.callback(*self.args, **self.kwargs)
  2021-05-02 14:23:29.193 599 ERROR futurist.periodics   File 
"/usr/lib/python3.6/site-packages/futurist/periodics.py", line 178, in decorator
  2021-05-02 14:23:29.193 599 ERROR futurist.periodics return f(*args, 
**kwargs)
  2021-05-02 14:23:29.193 599 ERROR futurist.periodics   File 
"/usr/lib/python3.6/site-packages/networking_ovn/common/maintenance.py", line 
667, in check_for_mcast_flood_reports
  2021-05-02 14:23:29.193 599 ERROR futurist.periodics for port in 
self._nb_idl.lsp_list().execute(check_error=True):
  2021-05-02 14:23:29.193 599 ERROR futurist.periodics   File 
"/usr/lib/python3.6/site-packages/ovsdbapp/backend/ovs_idl/command.py", line 
42, in execute
  2021-05-02 14:23:29.193 599 ERROR futurist.periodics t.add(self)
  2021-05-02 14:23:29.193 599 ERROR futurist.periodics   File 
"/usr/lib64/python3.6/contextlib.py", line 88, in __exit__
  2021-05-02 14:23:29.193 599 ERROR futurist.periodics next(self.gen)
  2021-05-02 14:23:29.193 599 ERROR futurist.periodics   File 
"/usr/lib/python3.6/site-packages/networking_ovn/ovsdb/impl_idl_ovn.py", line 
196, in transaction
  2021-05-02 14:23:29.193 599 ERROR futurist.periodics yield t
  2021-05-02 14:23:29.193 599 ERROR futurist.periodics   File 
"/usr/lib64/python3.6/contextlib.py", line 88, in __exit__
  2021-05-02 14:23:29.193 599 ERROR futurist.periodics next(self.gen)
  2021-05-02 14:23:29.193 599 ERROR futurist.periodics   File 
"/usr/lib/python3.6/site-packages/ovsdbapp/api.py", line 119, in transaction
  2021-05-02 14:23:29.193 599 ERROR futurist.periodics del 
self._nested_txns_map[cur_thread_id]
  2021-05-02 14:23:29.193 599 ERROR futurist.periodics   File 
"/usr/lib/python3.6/site-packages/ovsdbapp/api.py", line 69, in __exit__
  2021-05-02 14:23:29.193 599 ERROR futurist.periodics self.result = 
self.commit()
  2021-05-02 14:23:29.193 599 ERROR futurist.periodics   File 
"/usr/lib/python3.6/site-packages/ovsdbapp/backend/ovs_idl/transaction.p

[Yahoo-eng-team] [Bug 1927213] [NEW] ovn-migration: Ansible SSH user is hardcoded

2021-05-05 Thread Jakub Libosvar
Public bug reported:

Ansible user is hardcoded to heat-admin. There is no way how operator
can migrate when their cloud uses a different user on the overcloud
nodes

** Affects: neutron
 Importance: Medium
 Assignee: Jakub Libosvar (libosvar)
 Status: Fix Released


** Tags: ovn

** Changed in: neutron
   Importance: Undecided => Medium

** Changed in: neutron
   Status: New => Fix Released

** Changed in: neutron
 Assignee: (unassigned) => Jakub Libosvar (libosvar)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1927213

Title:
  ovn-migration: Ansible SSH user is hardcoded

Status in neutron:
  Fix Released

Bug description:
  Ansible user is hardcoded to heat-admin. There is no way how operator
  can migrate when their cloud uses a different user on the overcloud
  nodes

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1927213/+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