[Yahoo-eng-team] [Bug 1920214] Re: User role assignments and groups tabs visible but don't work for non-admins

2021-04-11 Thread Vishal Manchanda
It is fixed by https://review.opendev.org/c/openstack/horizon/+/785123.

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

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

Title:
  User role assignments and groups tabs visible but don't work for non-
  admins

Status in OpenStack Dashboard (Horizon):
  Fix Released

Bug description:
  # Steps to reproduce

  As a non admin user, navigate to Identity -> Users. Then click on the
  username of your user to go to the detail page.

  # Expected results

  Only the allowed Overview tab is visible.

  # Actual results

  The view shows three tabs: Overview, Role assignments, Groups. Click
  on either Role assignments or Groups. An error will appear, showing
  that the API call is unauthorised, and the table content will fail to
  load.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1920214/+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 1920010] Re: Validation on fails on the Associate Floating IP when too many instances exist

2021-04-11 Thread Vishal Manchanda
It is fixed by https://review.opendev.org/c/openstack/horizon/+/780925.

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

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

Title:
  Validation on fails on the Associate Floating IP when too many
  instances exist

Status in OpenStack Dashboard (Horizon):
  Fix Released

Bug description:
  If there are more than Nova's pagination limit instances, and one
  tries to associate a floating IP with a new instance, the form's
  validation will fail.

  This is because that form populates the drop-down field for
  association target differently on initial display of the form (where
  it takes the instance_id from the URL) than on submitting of that form
  (when the information from the URL is lost). The latter attempts to
  get all eligible ports, but is limited by Nova's pagination.

  You can also observe weird behavior when that form has any error (for
  instance, because the floating IP wasn't selected) — after submitting,
  it will re-display the form with the error, but now the target drop-
  down will be populated with all possible ports, instead of only ones
  on the instance, like on the initial display.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1920010/+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 1383580] Re: API calls in openstack_dashboard.usage.quotas should be wrapped with try/except

2021-04-11 Thread Vishal Manchanda
It is fixed by https://review.opendev.org/c/openstack/horizon/+/765144.

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

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

Title:
  API calls in openstack_dashboard.usage.quotas should be wrapped with
  try/except

Status in OpenStack Dashboard (Horizon):
  Fix Released

Bug description:
  API calls in openstack_dashboard.usage.quotas should be wrapped with
  try/except.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1383580/+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 1923198] Re: custom kill scripts don't works after migration to privsep

2021-04-11 Thread Slawek Kaplonski
Fix merged

** 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/1923198

Title:
  custom kill scripts don't works after migration to privsep

Status in neutron:
  Fix Released

Bug description:
  It seems that custom kill scripts aren't working properly if they are in the 
PATH which isn't in the standard PATH now.
  When we were using rootwrap to run such scripts it was fine when scripts were 
e.g. in default path which is /etc/neutron/kill_scripts/ as this directory is 
added in the rootwrap's exec_dirs: 
https://github.com/openstack/neutron/blob/07b7da2251fbb607d599d48e80e4a701fa6b394e/etc/rootwrap.conf#L13
 and rootwrap is looking for binary to execute in the directories from that 
config option.

  But now we moved to privsep and we have errors like:

  2021-04-09 12:01:19.348 176680 DEBUG oslo.privsep.daemon [-] privsep: 
Exception during request[140575473731280]: [Errno 2] No such file or directory: 
'dnsmasq-kill': 'dnsmasq-kill' _process_cmd 
/usr/lib/python3.6/site-packages/oslo_privsep/daemon.py:490
  Traceback (most recent call last):
File "/usr/lib/python3.6/site-packages/oslo_privsep/daemon.py", line 485, 
in _process_cmd
  ret = func(*f_args, **f_kwargs)
File "/usr/lib/python3.6/site-packages/oslo_privsep/priv_context.py", line 
249, in _wrap
  return func(*args, **kwargs)
File 
"/usr/lib/python3.6/site-packages/neutron/privileged/agent/linux/utils.py", 
line 56, in execute_process
  obj, cmd = _create_process(cmd, addl_env=addl_env)
File 
"/usr/lib/python3.6/site-packages/neutron/privileged/agent/linux/utils.py", 
line 83, in _create_process
  stdout=subprocess.PIPE, stderr=subprocess.PIPE)
File "/usr/lib/python3.6/site-packages/eventlet/green/subprocess.py", line 
58, in __init__
  subprocess_orig.Popen.__init__(self, args, 0, *argss, **kwds)
File "/usr/lib64/python3.6/subprocess.py", line 729, in __init__
  restore_signals, start_new_session)
File "/usr/lib64/python3.6/subprocess.py", line 1364, in _execute_child
  raise child_exception_type(errno_num, err_msg, err_filename)
  FileNotFoundError: [Errno 2] No such file or directory: 'dnsmasq-kill': 
'dnsmasq-kill'

  
  Even if dnsmasq-kill script is in the /etc/neutron/kill_scripts directory.

  We didn't spot it in our CI jobs as we don't run any job with those
  custom kill scripts. But it is used e.g. by Tripleo and they spot it
  in their jobs.

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