[Yahoo-eng-team] [Bug 1840843] Re: user with admin role get's logged out when trying to list images
*** This bug is a duplicate of bug 1840844 ***
https://bugs.launchpad.net/bugs/1840844
This bug is duplicate of https://bugs.launchpad.net/horizon/+bug/1840844
and fixes for this is already released.
** This bug has been marked a duplicate of bug 1840844
user with admin role gets logged out when trying to list images
--
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/1840843
Title:
user with admin role get's logged out when trying to list images
Status in OpenStack Dashboard (Horizon):
Confirmed
Bug description:
When admin user tries to access project-> compute -> images, if the
user failed on the identity: get_project policy, user will get logged
out.
code that failed is in
openstack_dashboard/static/app/core/images/images.module.js
.tableColumns
.append(
{ id: 'owner', priority: 1, filters:
[$memoize(keystone.getProjectName)], policies: [
{rules: [['identity', 'identity:get_project']]}
]
})
it didn't happen in default Horizon. In our production cloud
environment, keystone policy is "identity:get_project":
"rule:cloud_admin or rule:admin_and_matching_target_project_domain_id
or project_id:%(target.project.id)s". If user is not a cloud_admin,
the admin user of a project, need to be member of the domain to
satisfies the rule.
The problem here is the admin user should not get logged out.
It is probably caused by horizon/static/framework/framework.module.js
if (error.status === 403) {
var msg2 = gettext('Forbidden. Redirecting to login');
handleRedirectMessage(msg2, $rootScope, $window, frameworkEvents,
toastService);
}
To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1840843/+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 1833041] Re: importing a keypair when keypair limit is reached will logout user
Fixed in https://review.opendev.org/#/c/677580/ ** Changed in: horizon Status: Confirmed => 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/1833041 Title: importing a keypair when keypair limit is reached will logout user Status in OpenStack Dashboard (Horizon): Fix Released Bug description: when importing a keypair via horizon gui while the corresponding project quota limit is reached will automatically logout the current user and redirect him to the login screen. this has been testet with version openstack rocky on ubuntu 18 with the cloud archive repository. exact package: 3:14.0.2-0ubuntu2~cloud0 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1833041/+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 1861469] [NEW] [VPNaaS]: functional gate failed
Public bug reported: Currently, neutron-vpnaas functional gate failed after [1] merged. 2020-01-30 08:19:38.308343 | primary | + /opt/stack/new/neutron/tools/configure_for_func_testing.sh:_install_base_deps:110 : OVS_BRANCH=v2.12.0 2020-01-30 08:19:38.310217 | primary | + /opt/stack/new/neutron/tools/configure_for_func_testing.sh:_install_base_deps:111 : compile_ovs False /usr /var 2020-01-30 08:19:38.312140 | primary | + /opt/stack/new/neutron/devstack/lib/ovs:compile_ovs:113 : local _pwd=/home/zuul/workspace 2020-01-30 08:19:38.313981 | primary | + /opt/stack/new/neutron/devstack/lib/ovs:compile_ovs:114 : local build_modules=False 2020-01-30 08:19:38.315741 | primary | + /opt/stack/new/neutron/devstack/lib/ovs:compile_ovs:115 : local prefix=/usr 2020-01-30 08:19:38.317353 | primary | + /opt/stack/new/neutron/devstack/lib/ovs:compile_ovs:116 : local localstatedir=/var 2020-01-30 08:19:38.318879 | primary | + /opt/stack/new/neutron/devstack/lib/ovs:compile_ovs:118 : '[' -n /usr ']' 2020-01-30 08:19:38.320441 | primary | + /opt/stack/new/neutron/devstack/lib/ovs:compile_ovs:119 : prefix=--prefix=/usr 2020-01-30 08:19:38.322006 | primary | + /opt/stack/new/neutron/devstack/lib/ovs:compile_ovs:122 : '[' -n /var ']' 2020-01-30 08:19:38.323614 | primary | + /opt/stack/new/neutron/devstack/lib/ovs:compile_ovs:123 : localstatedir=--localstatedir=/var 2020-01-30 08:19:38.325395 | primary | + /opt/stack/new/neutron/devstack/lib/ovs:compile_ovs:126 : prepare_for_compilation False 2020-01-30 08:19:38.327128 | primary | + /opt/stack/new/neutron/devstack/lib/ovs:prepare_for_compilation:37 : local build_modules=False 2020-01-30 08:19:38.328890 | primary | + /opt/stack/new/neutron/devstack/lib/ovs:prepare_for_compilation:38 : OVS_DIR=/opt/stack/new/ovs 2020-01-30 08:19:38.330435 | primary | + /opt/stack/new/neutron/devstack/lib/ovs:prepare_for_compilation:40 : '[' '!' -d /opt/stack/new/ovs ']' 2020-01-30 08:19:38.332150 | primary | + /opt/stack/new/neutron/devstack/lib/ovs:prepare_for_compilation:42 : git_timed clone https://github.com/openvswitch/ovs.git /opt/stack/new/ovs 2020-01-30 08:19:38.333894 | primary | + functions-common:git_timed:616 : local count=0 2020-01-30 08:19:38.335601 | primary | + functions-common:git_timed:617 : local timeout=0 2020-01-30 08:19:38.337175 | primary | + functions-common:git_timed:619 : [[ -n 0 ]] 2020-01-30 08:19:38.338806 | primary | + functions-common:git_timed:620 : timeout=0 2020-01-30 08:19:38.340764 | primary | + functions-common:git_timed:623 : time_start git_timed 2020-01-30 08:19:38.343034 | primary | + functions-common:time_start:2316 : local name=git_timed 2020-01-30 08:19:38.344722 | primary | + functions-common:time_start:2317 : local start_time= 2020-01-30 08:19:38.346523 | primary | + functions-common:time_start:2318 : [[ -n '' ]] 2020-01-30 08:19:38.349859 | primary | ++ functions-common:time_start:2321 : date +%s%3N 2020-01-30 08:19:38.351868 | primary | + functions-common:time_start:2321 : _TIME_START[$name]=1580372378349 2020-01-30 08:19:38.353573 | primary | + functions-common:git_timed:624 : timeout -s SIGINT 0 git clone https://github.com/openvswitch/ovs.git /opt/stack/new/ovs 2020-01-30 08:19:38.356044 | primary | fatal: could not create work tree dir '/opt/stack/new/ovs': Permission denied 2020-01-30 08:19:38.358795 | primary | + functions-common:git_timed:627 : [[ 128 -ne 124 ]] 2020-01-30 08:19:38.360353 | primary | + functions-common:git_timed:628 : die 628 'git call failed: [git clone' https://github.com/openvswitch/ovs.git '/opt/stack/new/ovs]' 2020-01-30 08:19:38.361878 | primary | + functions-common:die:193 : local exitcode=0 2020-01-30 08:19:38.364694 | primary | + functions-common:die:194 : set +o xtrace 2020-01-30 08:19:38.364740 | primary | [Call Trace] 2020-01-30 08:19:38.364790 | primary | /opt/stack/new/neutron-vpnaas/neutron_vpnaas/tests/contrib/gate_hook.sh:28:configure_host_for_vpn_func_testing 2020-01-30 08:19:38.364815 | primary | /opt/stack/new/neutron-vpnaas/tools/configure_for_vpn_func_testing.sh:46:configure_host_for_func_testing 2020-01-30 08:19:38.364835 | primary | /opt/stack/new/neutron/tools/configure_for_func_testing.sh:298:_install_base_deps 2020-01-30 08:19:38.364860 | primary | /opt/stack/new/neutron/tools/configure_for_func_testing.sh:111:compile_ovs 2020-01-30 08:19:38.364880 | primary | /opt/stack/new/neutron/devstack/lib/ovs:126:prepare_for_compilation 2020-01-30 08:19:38.364899 | primary | /opt/stack/new/neutron/devstack/lib/ovs:42:git_timed 2020-01-30 08:19:38.364919 | primary | /opt/stack/new/devstack/functions-common:628:die 2020-01-30 08:19:38.367493 | primary | [ERROR] /opt/stack/new/devstack/functions-common:628 git call failed: [git clone
[Yahoo-eng-team] [Bug 1861397] Re: Needed mechanism to differentiate pings sent in tempest tests
Reviewed: https://review.opendev.org/704940 Committed: https://git.openstack.org/cgit/openstack/neutron-tempest-plugin/commit/?id=f2b60545a585169f4d17653c024320f499cc8026 Submitter: Zuul Branch:master commit f2b60545a585169f4d17653c024320f499cc8026 Author: Eduardo Olivares Date: Thu Jan 30 09:37:22 2020 +0100 Adding pattern to check_remote_connectivity function Ping messages sent by this function will include a pattern of bytes that are repeated until message size is completed. Input format required is a string with hex digits. This is useful when these messages are captured, in order to identify and differentiate clearly messages from different tests. It can be used to validate that traffic routing is not affected by packet data as well. Closes-Bug: #1861397 Change-Id: Ib94518597bdf3d9f3049643d3242db632769de6b ** 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/1861397 Title: Needed mechanism to differentiate pings sent in tempest tests Status in neutron: Fix Released Bug description: Tempest Neutron plugin includes function check_remote_connectivity. It sends ping messages from VM instances to validate connectivity. There could be problems to correctly identify/filter those messages when several tests are running in parallel. One simple way to be able to filter those messages is using ping option "-p ". That pattern is included in the ping messages and can be filtered out when packets are captured. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1861397/+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 1861464] [NEW] os-attach-interfaces API policy is allowed for everyone even policy defaults is admin_or_owner
Public bug reported: os-attach-interfaces APi policy is default to admin_or_owner[1] but API is allowed for everyone. We can see the test trying with other project context can access the API - https://review.opendev.org/#/c/705126/1 This is because API does not pass the server project_id in policy target - https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/api/openstack/compute/attach_interfaces.py#L70 and if no target is passed then, policy.py add the default targets which is nothing but context.project_id (allow for everyone try to access) - https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/policy.py#L191 [1] - https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/policies/attach_interfaces.py#L28 ** Affects: nova 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/1861464 Title: os-attach-interfaces API policy is allowed for everyone even policy defaults is admin_or_owner Status in OpenStack Compute (nova): New Bug description: os-attach-interfaces APi policy is default to admin_or_owner[1] but API is allowed for everyone. We can see the test trying with other project context can access the API - https://review.opendev.org/#/c/705126/1 This is because API does not pass the server project_id in policy target - https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/api/openstack/compute/attach_interfaces.py#L70 and if no target is passed then, policy.py add the default targets which is nothing but context.project_id (allow for everyone try to access) - https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/policy.py#L191 [1] - https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/policies/attach_interfaces.py#L28 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1861464/+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 1861460] [NEW] cloud-init should parse initramfs rendered netplan if present
Public bug reported: initramfs-tools used to only execute klibc based networking with some resolvconf hooks. In recent releases, it has been greatly improved to use isc-dhcp-client instead of klibc, support vlan= key (like in dracut-network), bring up Z devices using chzdev, and generate netplan yaml from all of the above. Above improvements were driven in part by Oracle Cloud and in part by Subiquity netbooting on Z. Thus these days, instead of trying to reparse klibc files in /run/net-*, cloud-init should simply import /run/netplan/$device.yaml files as the ip=* provided networking information on the command line. I do not currently see cloud-init doing that in e.g. /cloudinit/net/cmdline.py ** Affects: cloud-init Importance: Wishlist Status: Triaged ** Changed in: cloud-init Importance: Undecided => Wishlist ** Changed in: cloud-init Status: New => 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/1861460 Title: cloud-init should parse initramfs rendered netplan if present Status in cloud-init: Triaged Bug description: initramfs-tools used to only execute klibc based networking with some resolvconf hooks. In recent releases, it has been greatly improved to use isc-dhcp-client instead of klibc, support vlan= key (like in dracut-network), bring up Z devices using chzdev, and generate netplan yaml from all of the above. Above improvements were driven in part by Oracle Cloud and in part by Subiquity netbooting on Z. Thus these days, instead of trying to reparse klibc files in /run/net-*, cloud-init should simply import /run/netplan/$device.yaml files as the ip=* provided networking information on the command line. I do not currently see cloud-init doing that in e.g. /cloudinit/net/cmdline.py To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1861460/+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 1861282] Re: [Tempest] Floating IP and static IP should be in different CIDRs
Reviewed: https://review.opendev.org/704768 Committed: https://git.openstack.org/cgit/openstack/neutron-tempest-plugin/commit/?id=3e1921b48ad485669b3ab42002d08eb49f34f468 Submitter: Zuul Branch:master commit 3e1921b48ad485669b3ab42002d08eb49f34f468 Author: ccamposr Date: Wed Jan 29 11:10:05 2020 +0100 Use different CIDRs for private and public subnets In test "test_connectivity_dvr_and_no_dvr_routers_in_same_subnet", as reported in the bug, the public IP (floating IP) and the private IP are in the same CIDR. This breaks the isolation between networks. Co-Authored-By: Rodolfo Alonso Hernandez Closes-Bug: #1861282 Change-Id: I39ca6474068d2e169dff1b81d2a0c71a8361c01f ** 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/1861282 Title: [Tempest] Floating IP and static IP should be in different CIDRs Status in neutron: Fix Released Bug description: In "test_connectivity_dvr_and_no_dvr_routers_in_same_subnet", both the floating IP and the static IP are in the same CIDR. This implies the GW for both subnets is the same and the traffic can't be router properly. We should check first the external network CIDR and assign a non overlapping one to the private subnet. Logs: http://paste.openstack.org/show/788916/ BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1795638 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1861282/+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 1748697] Re: Cold migration fails when the filter only returns the host where the vm is located and the vm status is set to ERROR
Reviewed: https://review.opendev.org/695220 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=4921e822e73383af0c8da4c5e3acfaa021eafe68 Submitter: Zuul Branch:master commit 4921e822e73383af0c8da4c5e3acfaa021eafe68 Author: Matt Riedemann Date: Wed Nov 20 10:27:18 2019 -0500 Use COMPUTE_SAME_HOST_COLD_MIGRATE trait during migrate This uses the COMPUTE_SAME_HOST_COLD_MIGRATE trait in the API during a cold migration to filter out hosts that cannot support same-host cold migration, which is all of them except for the hosts using the vCenter driver. For any nodes that do not report the trait, we won't know if they don't because they don't support it or if they are not new enough to report it, so the API has a service version check and will fallback to old behavior using the config if the node is old. That compat code can be removed in the next release. As a result of this the FakeDriver capabilities are updated so the FakeDriver no longer supports same-host cold migration and a new fake driver is added to support that scenario for any tests that need it. Change-Id: I7a4b951f3ab324c666ab924e6003d24cc8e539f5 Closes-Bug: #1748697 Related-Bug: #1811235 ** Changed in: nova Status: In Progress => Fix Released -- 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/1748697 Title: Cold migration fails when the filter only returns the host where the vm is located and the vm status is set to ERROR Status in OpenStack Compute (nova): Fix Released Bug description: Description === The configuration: allow_resize_to_same_host=True. Cold migration fails when the filter only returns the host where the vm is located and the vm status is set to ERROR. Steps to reproduce == 1、create a vm 2、disable all hosts except the host which the vm is located 3、cold migrate the vm, you can see the exception.UnableToMigrateToSelf in compute log, and the vm status is set to ERROR while it still running Expected result === cold migrate failed, and user should see HTTP400 NovaildHost from console output, because cold migrate to same host is meaningless. The vm status still keep Active. Actual result = cold migrate failed, nothing returns from console, and vm status is set to ERROR. Environment === nova16.0.4 KVM $ libvirt Logs & Configs == allow_resize_to_same_host=True PS: If the host which the vm located is particularly resource-rich, filters return this host each time when user executes cold migration. Even if the resources of other hosts can meet the requirements of the virtual machine, the vm can never be cold-migrated. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1748697/+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 1861442] [NEW] QOS minimum bandwidth rejection of non-physnet network and updates should be driver specific
Public bug reported: When adding a qos policy to a network or port, there is the following check in the qos_plugin: # minimum-bandwidth rule is only supported (independently of # drivers) on networks whose first segment is backed by a physnet if rule.rule_type == qos_consts.RULE_TYPE_MINIMUM_BANDWIDTH: net = network_object.Network.get_object( context, id=port.network_id) physnet = net.segments[0].physical_network if physnet is None: raise qos_exc.QosRuleNotSupported(rule_type=rule.rule_type, port_id=port['id']) To my knowledge this statement is simply untrue as it is precisly the reference drivers which have this problem, not necessarily all drivers. This blocks me from creating a qos_driver that does support mimimum bandwidth without a physnet. The same goes for min_bw_rule_updates when the port is bound. I propose we move those checks to the qos_drivers themselves. ** 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/1861442 Title: QOS minimum bandwidth rejection of non-physnet network and updates should be driver specific Status in neutron: New Bug description: When adding a qos policy to a network or port, there is the following check in the qos_plugin: # minimum-bandwidth rule is only supported (independently of # drivers) on networks whose first segment is backed by a physnet if rule.rule_type == qos_consts.RULE_TYPE_MINIMUM_BANDWIDTH: net = network_object.Network.get_object( context, id=port.network_id) physnet = net.segments[0].physical_network if physnet is None: raise qos_exc.QosRuleNotSupported(rule_type=rule.rule_type, port_id=port['id']) To my knowledge this statement is simply untrue as it is precisly the reference drivers which have this problem, not necessarily all drivers. This blocks me from creating a qos_driver that does support mimimum bandwidth without a physnet. The same goes for min_bw_rule_updates when the port is bound. I propose we move those checks to the qos_drivers themselves. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1861442/+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 1861412] Re: cloud-init crashes with static network configuration
** Also affects: cloud-init Importance: Undecided Status: New ** No longer affects: cloud-init ** Also affects: ubuntu-z-systems 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/1861412 Title: cloud-init crashes with static network configuration Status in Ubuntu on IBM z Systems: New Status in cloud-init package in Ubuntu: New Bug description: I am booting an s390x VM with vlan & static ip= configuration on the kernel command line. It appears that cloudinit is trying to parse the ipconfig results, and is failing. Attaching: cmdline - /proc/cmdline net-encc000.2653.conf - the /run/net-encc000.2653.conf klibc ipconfig state file encc000.2653.yaml - /run/netplan/encc000.2653.yaml which initramfs-tools generates, but cloud-init is not using cloud-init-output.log & cloud-init.log - showing a crash traceback To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1861412/+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 1849518] Re: oslopolicy-list-redundant loses cli args when used with keystone
Reviewed: https://review.opendev.org/690628 Committed: https://git.openstack.org/cgit/openstack/oslo.policy/commit/?id=686aa238f921e8b6dff814d001690e15fa8ccea6 Submitter: Zuul Branch:master commit 686aa238f921e8b6dff814d001690e15fa8ccea6 Author: Ben Nemec Date: Wed Oct 23 15:36:42 2019 + Initialize global config object in cli tools Currently, passing --config-file to a tool like oslopolicy-list-redundant is ineffective because the projects pass an empty cli arg list to the conf object when they initialize it. By registering our cli args on the global conf object, the projects can safely parse cli args in their call to the conf object so things like --config-file won't be ignored. This didn't work before because oslo.policy recognizes cli args like --namespace that aren't recognized by the consuming projects. This will require followup changes in each project to stop passing an empty cli arg list to the conf object initialization. In the meantime, everything should continue to work as it did before. Change-Id: Iacd257fc6c351582de45476768e3fd1775317d3c Closes-Bug: 1849518 ** Changed in: oslo.policy Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1849518 Title: oslopolicy-list-redundant loses cli args when used with keystone Status in OpenStack Identity (keystone): In Progress Status in oslo.policy: Fix Released Bug description: There is an issue with the configuration handling in oslo.policy and keystone that causes cli args like --config-file to be ignored in the keystone enforcer when running oslopolicy-list-redundant. Specifically, because keystone re-initializes the global config object when creating the enforcer[0], and doesn't pass any cli args to it, those cli args get ignored. This can cause problems if, for example, the policy file is not in the default location and is instead specified in the config file passed via --config-file. Since --config- file gets ignored by the enforcer, it just looks in the default location and doesn't find a file. One solution would be to have oslo.policy initialize the global config object itself (switching [1] to use the global object instead of a local one) and remove the initialization from the enforcer entirely. One potential downside of this is that if a project's enforcer needs project-specific config setup it wouldn't be possible for that to happen (oslo.policy wouldn't know about it), but since that doesn't apply to keystone and would only really be an issue if a project's enforcer had a dependency on a cli arg (cli args are the only thing that need to be registered before calling the conf object), I think it's a worthwhile tradeoff. 0: https://github.com/openstack/keystone/blob/1ef56e58ec63f19eff25a1044c8831ba8f97e26a/keystone/common/rbac_enforcer/policy.py#L43 1: https://github.com/openstack/oslo.policy/blob/0f7e144d013155f27f74b0eb91b7ae0f1530a86b/oslo_policy/generator.py#L399 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1849518/+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 1861401] [NEW] Renaming instance brokes DNS integration
Public bug reported: Colleagues, Description === Renaming instance (e.g. using "openstack server set --name") brokes DNS integration, since it makes it impossible to bind port with new instance's name. So, if user renamed instance and want to access it using name, he can not. Steps to reproduce == 1) You have an instance with some name (e.g. "web01") 2) You rename it using "openstack server set --name web02 web01" 3) You create port with instance's new name (e.g. web02) in order to attach it to the instance $ openstack port create --network e-net --fixed-ip subnet=e-subnet --dns-name web02 test_port 4) You're trying to attach the port to the instance: $ nova interface-attach --port-id web02 Expected result === Port binds to the instance and instance can be accessed using hostname "web02" Actual result = Last command in steps above fails with the following message: ERROR (ClientException): Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. Nova log says the following: 2020-01-30 11:43:32.652 17476 ERROR nova.api.openstack.wsgi PortNotUsableDNS: Port 0425701f-d958-4c81-931a-9594fba7d7d2 not usable for instance 2d49b781-cef5-4cdd-a310-e74eb98aa514. Value web02 assigned to dns_name attribute does not match instance's hostname web01 MySQL content show that renaming instance changed column "display_name", but "hostname" remained with old name: mysql> select hostname, display_name from instances where uuid='2d49b781-cef5-4cdd-a310-e74eb98aa514'; +--+--+ | hostname | display_name | +--+--+ | web01| web02| +--+--+ Thus, DNS integration compares port's dns_name to "hostname" not the "display_name", which makes it unusable after renaming instance. Either renaming instance need to change both "hostname" and "display_name" columns or DNS integration need compare port's dns_name with "display_name". Environment === Host OS: Ubuntu 18.04 LTS Openstack: Rocky $ dpkg -l |grep nova ii nova-api 2:18.2.3-0ubuntu1~cloud0 ii nova-common2:18.2.3-0ubuntu1~cloud0 ii nova-conductor 2:18.2.3-0ubuntu1~cloud0 ii nova-novncproxy2:18.2.3-0ubuntu1~cloud0 ii nova-placement-api 2:18.2.3-0ubuntu1~cloud0 ii nova-scheduler 2:18.2.3-0ubuntu1~cloud0 ii python-nova2:18.2.3-0ubuntu1~cloud0 ii python-novaclient 2:11.0.0-0ubuntu1~cloud0 Thank you. ** Affects: nova 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/1861401 Title: Renaming instance brokes DNS integration Status in OpenStack Compute (nova): New Bug description: Colleagues, Description === Renaming instance (e.g. using "openstack server set --name") brokes DNS integration, since it makes it impossible to bind port with new instance's name. So, if user renamed instance and want to access it using name, he can not. Steps to reproduce == 1) You have an instance with some name (e.g. "web01") 2) You rename it using "openstack server set --name web02 web01" 3) You create port with instance's new name (e.g. web02) in order to attach it to the instance $ openstack port create --network e-net --fixed-ip subnet=e-subnet --dns-name web02 test_port 4) You're trying to attach the port to the instance: $ nova interface-attach --port-id web02 Expected result === Port binds to the instance and instance can be accessed using hostname "web02" Actual result = Last command in steps above fails with the following message: ERROR (ClientException): Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. Nova log says the following: 2020-01-30 11:43:32.652 17476 ERROR nova.api.openstack.wsgi PortNotUsableDNS: Port 0425701f-d958-4c81-931a-9594fba7d7d2 not usable for instance 2d49b781-cef5-4cdd-a310-e74eb98aa514. Value web02 assigned to dns_name attribute does not match instance's hostname web01 MySQL content show that renaming instance changed column "display_name", but "hostname" remained with old name: mysql> select hostname, display_name from instances where uuid='2d49b781-cef5-4cdd-a310-e74eb98aa514'; +--+--+ | hostname | display_name | +--+--+ | web01| web02| +--+--+ Thus, DNS integration compares port's dns_name to "hostname" not the "display_name", which makes it unusable after renaming instance. Either renaming instance need to change both "hostname" and "display_name" columns or DNS integration need compare port's dns_name with "display_name". Environment === Host OS: Ubuntu
[Yahoo-eng-team] [Bug 1861397] [NEW] Needed mechanism to differentiate pings sent in tempest tests
Public bug reported: Tempest Neutron plugin includes function check_remote_connectivity. It sends ping messages from VM instances to validate connectivity. There could be problems to correctly identify/filter those messages when several tests are running in parallel. One simple way to be able to filter those messages is using ping option "-p ". That pattern is included in the ping messages and can be filtered out when packets are captured. ** Affects: neutron Importance: Undecided Assignee: Eduardo Olivares (eolivare) Status: In Progress ** Tags: tempest -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1861397 Title: Needed mechanism to differentiate pings sent in tempest tests Status in neutron: In Progress Bug description: Tempest Neutron plugin includes function check_remote_connectivity. It sends ping messages from VM instances to validate connectivity. There could be problems to correctly identify/filter those messages when several tests are running in parallel. One simple way to be able to filter those messages is using ping option "-p ". That pattern is included in the ping messages and can be filtered out when packets are captured. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1861397/+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
