[Yahoo-eng-team] [Bug 884451] Re: End User Has No "Forgot Password" Option
[Expired for Keystone because there has been no activity for 60 days.] ** Changed in: keystone Status: Incomplete => Expired -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/884451 Title: End User Has No "Forgot Password" Option Status in Django OpenStack Auth: Incomplete Status in OpenStack Dashboard (Horizon): Expired Status in OpenStack Identity (Keystone): Expired Bug description: Related to blueprint: improve-user-experience. To manage notifications about this bug go to: https://bugs.launchpad.net/django-openstack-auth/+bug/884451/+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 884451] Re: End User Has No "Forgot Password" Option
[Expired for OpenStack Dashboard (Horizon) because there has been no activity for 60 days.] ** Changed in: horizon Status: Incomplete => Expired -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/884451 Title: End User Has No "Forgot Password" Option Status in Django OpenStack Auth: Incomplete Status in OpenStack Dashboard (Horizon): Expired Status in OpenStack Identity (Keystone): Expired Bug description: Related to blueprint: improve-user-experience. To manage notifications about this bug go to: https://bugs.launchpad.net/django-openstack-auth/+bug/884451/+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 1354354] Re: No network after live-migration
[Expired for neutron because there has been no activity for 60 days.] ** Changed in: neutron Status: Incomplete => Expired -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1354354 Title: No network after live-migration Status in OpenStack Neutron (virtual network service): Expired Status in OpenStack Compute (Nova): Incomplete Bug description: During live-migration port-update is send to neutron after plug_vifs is executed. In a setup with neutron ml2 plugin where two nodes require different VIF_TYPE, migrating a VM from one node to the other will result in VM having no network connectivity. vif bindings should be updated before plug_vifs is called. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1354354/+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 1388305] [NEW] When using DVR, port list for floating IP is empy
Public bug reported: The port list doesn't get updated correctly when using DVR. see https://ask.openstack.org/en/question/51634/juno-dvr-associate- floating-ip-reported-no-ports-available/ for detail ** Affects: horizon Importance: Undecided Status: New ** Tags: dvr -- 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/1388305 Title: When using DVR, port list for floating IP is empy Status in OpenStack Dashboard (Horizon): New Bug description: The port list doesn't get updated correctly when using DVR. see https://ask.openstack.org/en/question/51634/juno-dvr-associate- floating-ip-reported-no-ports-available/ for detail To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1388305/+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 1388237] [NEW] "cannot import name fields" after update from icehouse
Public bug reported: Hi, I have an issue when upgrading from icehouse to juno. I got a 500 for every request with that trace : https://gist.github.com/ttwthomas/35b155ba0f7781c4e98e ** Affects: horizon Importance: Undecided Status: New -- 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/1388237 Title: "cannot import name fields" after update from icehouse Status in OpenStack Dashboard (Horizon): New Bug description: Hi, I have an issue when upgrading from icehouse to juno. I got a 500 for every request with that trace : https://gist.github.com/ttwthomas/35b155ba0f7781c4e98e To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1388237/+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 1388230] [NEW] Checks for DB models and migrations sync not working
Public bug reported: I noticed a couple of issues, which might be related. 1. "db-manage revision --autogenerate" on master with no code changes generates: def upgrade(): op.drop_index('idx_autoinc_vr_id', table_name='ha_router_vrid_allocations') 2. With the following change to the IPAllocation() model, the revision is not detected. Also, the unit tests for model/migration sync do not give an error. diff --git a/neutron/db/models_v2.py b/neutron/db/models_v2.py --- a/neutron/db/models_v2.py +++ b/neutron/db/models_v2.py @@ -98,8 +98,8 @@ class IPAllocation(model_base.BASEV2): port_id = sa.Column(sa.String(36), sa.ForeignKey('ports.id', ondelete="CASCADE"), -nullable=True) -ip_address = sa.Column(sa.String(64), nullable=False, primary_key=True) +nullable=True, primary_key=True) +ip_address = sa.Column(sa.String(64), nullable=False) subnet_id = sa.Column(sa.String(36), sa.ForeignKey('subnets.id', ondelete="CASCADE"), nullable=False, primary_key=True) ** Affects: neutron Importance: Undecided Status: New ** Tags: db ** Tags added: db -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1388230 Title: Checks for DB models and migrations sync not working Status in OpenStack Neutron (virtual network service): New Bug description: I noticed a couple of issues, which might be related. 1. "db-manage revision --autogenerate" on master with no code changes generates: def upgrade(): op.drop_index('idx_autoinc_vr_id', table_name='ha_router_vrid_allocations') 2. With the following change to the IPAllocation() model, the revision is not detected. Also, the unit tests for model/migration sync do not give an error. diff --git a/neutron/db/models_v2.py b/neutron/db/models_v2.py --- a/neutron/db/models_v2.py +++ b/neutron/db/models_v2.py @@ -98,8 +98,8 @@ class IPAllocation(model_base.BASEV2): port_id = sa.Column(sa.String(36), sa.ForeignKey('ports.id', ondelete="CASCADE"), -nullable=True) -ip_address = sa.Column(sa.String(64), nullable=False, primary_key=True) +nullable=True, primary_key=True) +ip_address = sa.Column(sa.String(64), nullable=False) subnet_id = sa.Column(sa.String(36), sa.ForeignKey('subnets.id', ondelete="CASCADE"), nullable=False, primary_key=True) To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1388230/+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 1388213] [NEW] Possible to crash nova compute node via deletion of a resizing instance (timing bug)
Public bug reported: NOTE: tests run against devstack install on Ubuntu 14.04 tests conducted via randomized testing, no definitive test case produced yet, but have repeated this several times. It appears that deleting a resizing instance can cause the nova compute node to crash with the following error / traceback: (more detailed output below) screen-n-cpu.2014-10-31-08.log:354289:2014-10-31 11:01:58.093 TRACE oslo.messaging.rpc.dispatcher File "/usr/lib/python2.7/dist-packages/libvirt.py", line 896, in createWithFlags screen-n-cpu.2014-10-31-08.log:354290:2014-10-31 11:01:58.093 TRACE oslo.messaging.rpc.dispatcher if ret == -1: raise libvirtError ('virDomainCreateWithFlags() failed', dom=self) screen-n-cpu.2014-10-31-08.log:354291:2014-10-31 11:01:58.093 TRACE oslo.messaging.rpc.dispatcher libvirtError: Domain not found: no domain with matching uuid '2aadc976-951e-47d6-bb20-9e071a6a89a9' (instance-0360) When this is triggered, the compute node will crash and all instances will end up in ERROR state. Have not perfected the timing parameters, but will provide output from two runs below. ** 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/1388213 Title: Possible to crash nova compute node via deletion of a resizing instance (timing bug) Status in OpenStack Compute (Nova): New Bug description: NOTE: tests run against devstack install on Ubuntu 14.04 tests conducted via randomized testing, no definitive test case produced yet, but have repeated this several times. It appears that deleting a resizing instance can cause the nova compute node to crash with the following error / traceback: (more detailed output below) screen-n-cpu.2014-10-31-08.log:354289:2014-10-31 11:01:58.093 TRACE oslo.messaging.rpc.dispatcher File "/usr/lib/python2.7/dist-packages/libvirt.py", line 896, in createWithFlags screen-n-cpu.2014-10-31-08.log:354290:2014-10-31 11:01:58.093 TRACE oslo.messaging.rpc.dispatcher if ret == -1: raise libvirtError ('virDomainCreateWithFlags() failed', dom=self) screen-n-cpu.2014-10-31-08.log:354291:2014-10-31 11:01:58.093 TRACE oslo.messaging.rpc.dispatcher libvirtError: Domain not found: no domain with matching uuid '2aadc976-951e-47d6-bb20-9e071a6a89a9' (instance-0360) When this is triggered, the compute node will crash and all instances will end up in ERROR state. Have not perfected the timing parameters, but will provide output from two runs below. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1388213/+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 1388162] [NEW] Duplicate ensure_remove_chain method in iptables_manager
Public bug reported: ensure_remove_chain method in iptables_manager duplicates remove_chain method and should be removed. ** Affects: neutron Importance: Undecided Assignee: Elena Ezhova (eezhova) Status: New ** Tags: low-hanging-fruit ** Changed in: neutron Assignee: (unassigned) => Elena Ezhova (eezhova) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1388162 Title: Duplicate ensure_remove_chain method in iptables_manager Status in OpenStack Neutron (virtual network service): New Bug description: ensure_remove_chain method in iptables_manager duplicates remove_chain method and should be removed. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1388162/+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 1383433] Re: please package the cloud-init ci-tool
** Also affects: cloud-init (Ubuntu) Importance: Undecided Status: New ** Changed in: cloud-init (Ubuntu) Assignee: (unassigned) => James Hunt (jamesodhunt) -- 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/1383433 Title: please package the cloud-init ci-tool Status in Init scripts for use on cloud images: New Status in “cloud-init” package in Ubuntu: New Bug description: The ci-tool [1] is a useful utility that allows a host to be configured to use cloud-init (amongst other things). It would be great if we could get this into a package, either cloud- init itself or maybe a cloud-init-{tools|utils} package. [1] - http://bazaar.launchpad.net/~smoser/cloud-init/ci-tool/view/head :/ci-tool To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1383433/+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 1388143] [NEW] [sahara] Quickstart guide is missing definition for SAHARA_URL
Public bug reported: The quickstart document http://docs.openstack.org/developer/sahara/devref/quickstart.html uses $SAHARA_URL without defining it. From looking at what the cli client does, it should be set to: SAHARA_URL=http://127.0.0.1:8386/v1.0/$TENANT_ID and the installation for me seems to work after that. ** 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/1388143 Title: [sahara] Quickstart guide is missing definition for SAHARA_URL Status in OpenStack Compute (Nova): New Bug description: The quickstart document http://docs.openstack.org/developer/sahara/devref/quickstart.html uses $SAHARA_URL without defining it. From looking at what the cli client does, it should be set to: SAHARA_URL=http://127.0.0.1:8386/v1.0/$TENANT_ID and the installation for me seems to work after that. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1388143/+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 1388132] [NEW] [compute] Ceph client key missing in libvirt apparmor profile
Public bug reported: This happens when booting an instance while nova has ceph backend enabled: Oct 31 14:06:59 vagrant-ubuntu-trusty-64 kernel: [ 8264.770442] type=1400 audit(1414764419.818:29): apparmor="DENIED" operation="open" profile="libvirt-1550f42a-1b8b-4db5-9458-d5b9f496cc0c" name="/tmp/" pid=25660 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=112 ouid=0 Oct 31 14:06:59 vagrant-ubuntu-trusty-64 kernel: [ 8264.770454] type=1400 audit(1414764419.818:30): apparmor="DENIED" operation="open" profile="libvirt-1550f42a-1b8b-4db5-9458-d5b9f496cc0c" name="/var/tmp/" pid=25660 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=112 ouid=0 Oct 31 14:06:59 vagrant-ubuntu-trusty-64 kernel: [ 8264.776679] type=1400 audit(1414764419.826:31): apparmor="DENIED" operation="open" profile="libvirt-1550f42a-1b8b-4db5-9458-d5b9f496cc0c" name="/etc/ceph/ceph.client.cindy.keyring" pid=25660 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=112 ouid=1000 The keyring should not be used at all, since the secret is defined as virsh secret. ** 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/1388132 Title: [compute] Ceph client key missing in libvirt apparmor profile Status in OpenStack Compute (Nova): New Bug description: This happens when booting an instance while nova has ceph backend enabled: Oct 31 14:06:59 vagrant-ubuntu-trusty-64 kernel: [ 8264.770442] type=1400 audit(1414764419.818:29): apparmor="DENIED" operation="open" profile="libvirt-1550f42a-1b8b-4db5-9458-d5b9f496cc0c" name="/tmp/" pid=25660 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=112 ouid=0 Oct 31 14:06:59 vagrant-ubuntu-trusty-64 kernel: [ 8264.770454] type=1400 audit(1414764419.818:30): apparmor="DENIED" operation="open" profile="libvirt-1550f42a-1b8b-4db5-9458-d5b9f496cc0c" name="/var/tmp/" pid=25660 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=112 ouid=0 Oct 31 14:06:59 vagrant-ubuntu-trusty-64 kernel: [ 8264.776679] type=1400 audit(1414764419.826:31): apparmor="DENIED" operation="open" profile="libvirt-1550f42a-1b8b-4db5-9458-d5b9f496cc0c" name="/etc/ceph/ceph.client.cindy.keyring" pid=25660 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=112 ouid=1000 The keyring should not be used at all, since the secret is defined as virsh secret. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1388132/+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 1384555] Re: SQL error during alembic.migration when populating Neutron database on MariaDB 10.0
Fix proposed to branch: master Review: https://review.openstack.org/132273 ** Changed in: neutron Status: Won't Fix => In Progress ** Changed in: neutron Assignee: Ann Kamyshnikova (akamyshnikova) => 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/1384555 Title: SQL error during alembic.migration when populating Neutron database on MariaDB 10.0 Status in OpenStack Neutron (virtual network service): In Progress Status in “neutron” package in Ubuntu: New Bug description: On a fresh installation of Juno, it seems that that the database is not being populated correctly on a fresh install. This is the output of the log (I also demonstrated the DB had no tables to begin with): MariaDB [(none)]> use neutron Database changed MariaDB [neutron]> show tables; Empty set (0.00 sec) MariaDB [neutron]> quit Bye root@vm-1:~# neutron-db-manage --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugin.ini current INFO [alembic.migration] Context impl MySQLImpl. INFO [alembic.migration] Will assume non-transactional DDL. Current revision for mysql://neutron:X@10.10.10.1/neutron: None root@vm-1:~# neutron-db-manage --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugin.ini upgrade head INFO [alembic.migration] Context impl MySQLImpl. INFO [alembic.migration] Will assume non-transactional DDL. INFO [alembic.migration] Running upgrade None -> havana, havana_initial INFO [alembic.migration] Running upgrade havana -> e197124d4b9, add unique constraint to members INFO [alembic.migration] Running upgrade e197124d4b9 -> 1fcfc149aca4, Add a unique constraint on (agent_type, host) columns to prevent a race condition when an agent entry is 'upserted'. INFO [alembic.migration] Running upgrade 1fcfc149aca4 -> 50e86cb2637a, nsx_mappings INFO [alembic.migration] Running upgrade 50e86cb2637a -> 1421183d533f, NSX DHCP/metadata support INFO [alembic.migration] Running upgrade 1421183d533f -> 3d3cb89d84ee, nsx_switch_mappings INFO [alembic.migration] Running upgrade 3d3cb89d84ee -> 4ca36cfc898c, nsx_router_mappings INFO [alembic.migration] Running upgrade 4ca36cfc898c -> 27cc183af192, ml2_vnic_type INFO [alembic.migration] Running upgrade 27cc183af192 -> 50d5ba354c23, ml2 binding:vif_details INFO [alembic.migration] Running upgrade 50d5ba354c23 -> 157a5d299379, ml2 binding:profile INFO [alembic.migration] Running upgrade 157a5d299379 -> 3d2585038b95, VMware NSX rebranding INFO [alembic.migration] Running upgrade 3d2585038b95 -> abc88c33f74f, lb stats INFO [alembic.migration] Running upgrade abc88c33f74f -> 1b2580001654, nsx_sec_group_mapping INFO [alembic.migration] Running upgrade 1b2580001654 -> e766b19a3bb, nuage_initial INFO [alembic.migration] Running upgrade e766b19a3bb -> 2eeaf963a447, floatingip_status INFO [alembic.migration] Running upgrade 2eeaf963a447 -> 492a106273f8, Brocade ML2 Mech. Driver INFO [alembic.migration] Running upgrade 492a106273f8 -> 24c7ea5160d7, Cisco CSR VPNaaS INFO [alembic.migration] Running upgrade 24c7ea5160d7 -> 81c553f3776c, bsn_consistencyhashes INFO [alembic.migration] Running upgrade 81c553f3776c -> 117643811bca, nec: delete old ofc mapping tables INFO [alembic.migration] Running upgrade 117643811bca -> 19180cf98af6, nsx_gw_devices INFO [alembic.migration] Running upgrade 19180cf98af6 -> 33dd0a9fa487, embrane_lbaas_driver INFO [alembic.migration] Running upgrade 33dd0a9fa487 -> 2447ad0e9585, Add IPv6 Subnet properties INFO [alembic.migration] Running upgrade 2447ad0e9585 -> 538732fa21e1, NEC Rename quantum_id to neutron_id INFO [alembic.migration] Running upgrade 538732fa21e1 -> 5ac1c354a051, n1kv segment allocs for cisco n1kv plugin INFO [alembic.migration] Running upgrade 5ac1c354a051 -> icehouse, icehouse INFO [alembic.migration] Running upgrade icehouse -> 54f7549a0e5f, set_not_null_peer_address INFO [alembic.migration] Running upgrade 54f7549a0e5f -> 1e5dd1d09b22, set_not_null_fields_lb_stats INFO [alembic.migration] Running upgrade 1e5dd1d09b22 -> b65aa907aec, set_length_of_protocol_field INFO [alembic.migration] Running upgrade b65aa907aec -> 33c3db036fe4, set_length_of_description_field_metering INFO [alembic.migration] Running upgrade 33c3db036fe4 -> 4eca4a84f08a, Remove ML2 Cisco Credentials DB INFO [alembic.migration] Running upgrade 4eca4a84f08a -> d06e871c0d5, set_admin_state_up_not_null_ml2 INFO [alembic.migration] Running upgrade d06e871c0d5 -> 6be312499f9, set_not_null_vlan_id_cisco INFO [alembic.migration] Running upgrade 6be312499f9 -> 1b837a7125a9, Cisco APIC Mechanism Driver INFO [alembic.migration] Running upgrade 1b837a7125a9 -> 10cd28e692e9, nuage_extraroute INFO [alembic.migration] Running upgrade 10cd28e692e9 -
[Yahoo-eng-team] [Bug 1386687] Re: Overview page: OverflowError when cinder limits are negative
** Also affects: horizon/icehouse Importance: Undecided Status: New ** Also affects: horizon/juno Importance: Undecided Status: New ** Changed in: horizon/icehouse Assignee: (unassigned) => Julie Pichon (jpichon) ** Changed in: horizon/icehouse Status: New => In Progress ** Changed in: horizon/juno Assignee: (unassigned) => Julie Pichon (jpichon) ** Changed in: horizon/icehouse Importance: Undecided => Medium ** Changed in: horizon/juno Importance: Undecided => Medium ** Changed in: horizon/juno Status: New => In Progress -- 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/1386687 Title: Overview page: OverflowError when cinder limits are negative Status in OpenStack Dashboard (Horizon): Fix Committed Status in OpenStack Dashboard (Horizon) icehouse series: In Progress Status in OpenStack Dashboard (Horizon) juno series: In Progress Bug description: This is the Cinder twin to bug 1370869 which was resolved for Nova. For some yet-to-be-fully-debugged reasons, after deleting multiple instances the quota_usages table for Cinder ended up with negative values for several of the "in use" limits, causing the Overview Page to fail with an error 500: OverflowError at /project/ cannot convert float infinity to integer Even if this is (probably?) a rare occurrence, it would make sense to also add guards for the cinder limits and make the overview page more resilient. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1386687/+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 1370869] Re: Cannot display project overview page due to "cannot convert float infinity to integer" error
** Also affects: horizon/icehouse Importance: Undecided Status: New ** Changed in: horizon/icehouse Status: New => In Progress ** Changed in: horizon/icehouse Importance: Undecided => Medium ** Changed in: horizon/icehouse Assignee: (unassigned) => Julie Pichon (jpichon) -- 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/1370869 Title: Cannot display project overview page due to "cannot convert float infinity to integer" error Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Dashboard (Horizon) icehouse series: In Progress Bug description: Due to nova bug 1370867, nova absolute-limits sometimes returns -1 for *Used fields rather than 0. If this happens, the project overview page cannot be displayed with "cannot convert float infinity to integer" error. Users cannot use the dashboard without specifying URL directly, so it is better the dashboard guards this situation. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1370869/+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 1387945] Re: "nova volume-attach" is giving wrong device ID
This is a VERY old and long running issue with how things work on the Nova side of the house. The volumes are going to get attached to the next available drive mapping (vdb, vdc, vdd) based on the Block Device Mapping table in Nova. The specification you provide to attach-volume is really more of a hint than anything else. Anyway, over the past the answer has been "just use 'auto'" and save yourself the false sense of control here. Not acceptable for some, regardless this is a Nova operation and Cinder actually has no control or input here. Marking invalid for Cinder and adding Nova. ** Changed in: cinder Status: New => Invalid ** Also 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/1387945 Title: "nova volume-attach" is giving wrong device ID Status in Cinder: Invalid Status in OpenStack Compute (Nova): New Bug description: Sometimes while attaching volume to the instance using "nova volume- attach" it is giving wrong device ID (mountpoint : /dev/vdb). root@techpatron:~# nova volume-attach VM1 201b2fe8-7f77-446d-a6e4-5d077914329c +--+--+ | Property | Value| +--+--+ | device | /dev/vdd | | id | 201b2fe8-7f77-446d-a6e4-5d077914329c | | serverId | 2f319155-06d2-4aca-9f0f-49b415112568 | | volumeId | 201b2fe8-7f77-446d-a6e4-5d077914329c | +--+--+ Here it is showing "/dev/vdd", but volume actually attached as "/dev/vdc" to the instance "VM1". Because of this when I am running some automation scripts (which will perform operations on the attached device with in the instance) facing problem. From the output that script taking the device id as "/dev/vdd" but device is attached to some other mount point. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1387945/+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 1388095] [NEW] VMware fake driver returns invalid search results due to incorrect use of lstrip()
Public bug reported: _search_ds in the fake driver does: path = file.lstrip(dname).split('/') The intention is to remove a prefix of dname from the beginning of file, but this actually removes all instances of all characters in dname from the left of file. ** Affects: nova Importance: Undecided Status: New ** Tags: vmware -- 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/1388095 Title: VMware fake driver returns invalid search results due to incorrect use of lstrip() Status in OpenStack Compute (Nova): New Bug description: _search_ds in the fake driver does: path = file.lstrip(dname).split('/') The intention is to remove a prefix of dname from the beginning of file, but this actually removes all instances of all characters in dname from the left of file. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1388095/+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 1388077] [NEW] Parallel periodic instance power state reporting from compute nodes has high impact on conductors and message broker
Public bug reported: Environment: OpenStack Juno release/Ubuntu 14.04/480 compute nodes/8 cloud controllers/40,000 instances + The change made in: https://github.com/openstack/nova/commit/baabab45e0ae0e9e35872cae77eb04bdb5ee0545 switches power state reporting from being a serial process for each instance on a hypervisor to being a parallel thread for every instance; for clouds running high instance counts, this has quite an impact on the conductor processes as they try to deal with N instance refresh calls in parallel where N is the number of instances running on the cloud. It might be better to throttle this to a configurable parallel level so that period RPC load can be managed effectively in a larger cloud, or to continue todo this process in series but outside of the main thread. The net result of this activity is that it places increase demands on the message broker, which has to deal with more parallel connections, and the conductors as they try to consume all of the RPC requests; if the message broker hits its memory high water mark it will stop publishers publishing any more messages until the memory usage drops below the high water mark again - this might not be achievable if all conductor processes are tied up with existing RPC calls try to send replies, resulting in a message broker lockup and collapse of all RPC in the cloud. ** Affects: nova Importance: Undecided Status: New ** Affects: nova (Ubuntu) Importance: Undecided Status: New ** Description changed: The change made in: https://github.com/openstack/nova/commit/baabab45e0ae0e9e35872cae77eb04bdb5ee0545 Switches power state reporting from being a serial process on each instance on a hypervisor to being a parallel thread for every instance; for clouds running high instance densities, this has quite an impact on the conductor processes as they try to deal with N instance refresh calls in parallel where N is the number of instances running on the cloud. It might be better to throttle this to a configurable parallel level so that period RPC load can be managed effectively in a larger cloud, or to continue todo this process in series but outside of the main thread. + + The net result of this activity is that it places increase demands on + the message broker, which has to deal with more parallel connections, + and the conductors as they try to consume all of the RPC requests; if + the message broker hits its memory high water mark it will stop + publishers publishing any more messages until the memory usage drops + below the high water mark again - this might not be achievable if all + conductor processes are tied up with existing RPC calls try to send + replies, resulting in a message broker lockup and collapse of all RPC in + the cloud. ** Description changed: The change made in: https://github.com/openstack/nova/commit/baabab45e0ae0e9e35872cae77eb04bdb5ee0545 - Switches power state reporting from being a serial process on each + Switches power state reporting from being a serial process for each instance on a hypervisor to being a parallel thread for every instance; for clouds running high instance densities, this has quite an impact on the conductor processes as they try to deal with N instance refresh calls in parallel where N is the number of instances running on the cloud. It might be better to throttle this to a configurable parallel level so that period RPC load can be managed effectively in a larger cloud, or to continue todo this process in series but outside of the main thread. The net result of this activity is that it places increase demands on the message broker, which has to deal with more parallel connections, and the conductors as they try to consume all of the RPC requests; if the message broker hits its memory high water mark it will stop publishers publishing any more messages until the memory usage drops below the high water mark again - this might not be achievable if all conductor processes are tied up with existing RPC calls try to send replies, resulting in a message broker lockup and collapse of all RPC in the cloud. ** Also affects: nova Importance: Undecided Status: New ** Summary changed: - Parallel periodic power state reporting from compute nodes has high impact on conductors + Parallel periodic power state reporting from compute nodes has high impact on conductors and message broker ** Description changed: + Environment: OpenStack Juno release/Ubuntu 14.04/480 compute nodes/8 + cloud controllers/40,000 instances + + The change made in: https://github.com/openstack/nova/commit/baabab45e0ae0e9e35872cae77eb04bdb5ee0545 - Switches power state reporting from being a serial process for each + switches power state reporting from being a serial process for each instance on a hypervisor to being a parallel thread for every instance; for clouds running high instance d
[Yahoo-eng-team] [Bug 1388069] [NEW] Review documentation change for trust redelegation
Public bug reported: https://review.openstack.org/#/c/131541/ needs a tech. writer review. ** Affects: keystone Importance: Undecided Assignee: Irina (ipovolotskaya) Status: New ** Tags: documentation -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1388069 Title: Review documentation change for trust redelegation Status in OpenStack Identity (Keystone): New Bug description: https://review.openstack.org/#/c/131541/ needs a tech. writer review. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1388069/+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 1388062] [NEW] Flag in keystone.conf to remove password panel when using ldap for authentication
Public bug reported: When using ldap for authentication, the password panel still is visible in Horizon. Therefore I suggest it would be good to have the ability to set a flag in the keystone.conf that if you're using LDAP for auth it disables the password panel. Generally most companies have their own portal where users change their password. ** Affects: horizon Importance: Undecided Status: New ** Tags: keystone ** Description changed: - When using ldap for authentication, the password panel still is visible. - If a user tries to change their password it will fail. Therefore I - suggest it would be good to have the ability to set a flag in the - keystone.conf that if you're using LDAP for auth it disabled the - password panel. Generally most companies have their own portal where - users change their password. + When using ldap for authentication, the password panel still is visible + in Horizon. Therefore I suggest it would be good to have the ability to + set a flag in the keystone.conf that if you're using LDAP for auth it + disables the password panel. Generally most companies have their own + portal where users change their password. -- 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/1388062 Title: Flag in keystone.conf to remove password panel when using ldap for authentication Status in OpenStack Dashboard (Horizon): New Bug description: When using ldap for authentication, the password panel still is visible in Horizon. Therefore I suggest it would be good to have the ability to set a flag in the keystone.conf that if you're using LDAP for auth it disables the password panel. Generally most companies have their own portal where users change their password. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1388062/+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 1372049] Re: Launching multiple VMs fails over 63 instances
Automatic expansion of thread pool in oslo.messaging is not an option since we should have some limit applied to avoid other problems due to too high parallelism. If we will ever consider expansion of the pool beyond the hardcoded value from the configuration file, we'll need to apply some non-obvious heuristics to determine whether higher parallelism will be beneficial for the whole system. We may change the default value for oslo.messaging eventlet executor, though it will influence all the services that use the library, not just this specific case, and it's not obvious whether it won't introduce other issues. The safest option is to backport the Nova fix to stable branches. I've requested juno and icehouse backports for the Nova patch: - https://review.openstack.org/132202 (Juno) - https://review.openstack.org/132218 (Icehouse) ** Changed in: oslo.messaging Status: Confirmed => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1372049 Title: Launching multiple VMs fails over 63 instances Status in OpenStack Neutron (virtual network service): Invalid Status in OpenStack Compute (Nova): Fix Committed Status in Messaging API for OpenStack: Won't Fix Bug description: RHEL-7.0 Icehouse All-In-One Booting 63 VMs at once (with "num-instances" attribute) works fine. Setup is able to support up to 100 VMs booted in ~50 bulks. Booting 100 VMs at once, without Neutron network, so no network for the VMs, works fine. Booting 64 (and more) VMs boots only 63 VMs. any of the VMs over 63 are booted in ERROR state with details: VirtualInterfaceCreateException: Virtual Interface creation failed Failed VM's port at DOWN state Details: After the initial boot commands goes through, all CPU usage goes down (no neutron/nova CPU consumption) untll nova's vif_plugging_timeout is reached. at which point 1 (= #num_instances - 63) VM is set to ERROR, and the rest of the VMs reach active state. Guess: seems like neutron is going into some deadlock until some of the load is reduced by vif_plugging_timeout disabling neutorn-nova port notifications allows all VMs to be created. Notes: this is recreated also with multiple Compute nodes, and also multiple neutron RPC/API workers Recreate: set nova/neutron quota's to "-1" make sure neutorn-nova port notifications is ON on both neutron and nova conf files create a network in your tenant boot more than 64 VMs nova boot --flavor 42 test_VM --image cirros --num-instances 64 [yfried@yfried-mobl-rh ~(keystone_demo)]$ nova list +--+--+++-+-+ | ID | Name | Status | Task State | Power State | Networks| +--+--+++-+-+ | 02d7b680-efd8-4291-8d56-78b43c9451cb | test_VM-02d7b680-efd8-4291-8d56-78b43c9451cb | ACTIVE | - | Running | demo_private=10.0.0.156 | | 05fd6dd2-6b0e-4801-9219-ae4a77a53cfd | test_VM-05fd6dd2-6b0e-4801-9219-ae4a77a53cfd | ACTIVE | - | Running | demo_private=10.0.0.150 | | 09131f19-5e83-4a40-a900-ffca24a8c775 | test_VM-09131f19-5e83-4a40-a900-ffca24a8c775 | ACTIVE | - | Running | demo_private=10.0.0.160 | | 0d3be93b-73d3-4995-913c-03a4b80ad37e | test_VM-0d3be93b-73d3-4995-913c-03a4b80ad37e | ACTIVE | - | Running | demo_private=10.0.0.164 | | 0fcadae4-768c-44a1-9e1c-ac371d1803f9 | test_VM-0fcadae4-768c-44a1-9e1c-ac371d1803f9 | ACTIVE | - | Running | demo_private=10.0.0.202 | | 11a87db1-5b15-4cad-a749-5d53e2fd8194 | test_VM-11a87db1-5b15-4cad-a749-5d53e2fd8194 | ACTIVE | - | Running | demo_private=10.0.0.201 | | 147e4a6b-a77c-46ef-b8fd-d65479ccb8ca | test_VM-147e4a6b-a77c-46ef-b8fd-d65479ccb8ca | ACTIVE | - | Running | demo_private=10.0.0.147 | | 1c5b5f40-d2f3-4cc7-9f80-f5df8de918b9 | test_VM-1c5b5f40-d2f3-4cc7-9f80-f5df8de918b9 | ACTIVE | - | Running | demo_private=10.0.0.187 | | 1d0b7210-f5a0-4827-b338-2014e8f21341 | test_VM-1d0b7210-f5a0-4827-b338-2014e8f21341 | ACTIVE | - | Running | demo_private=10.0.0.165 | | 1df564f6-5aac-4ac8-8361-bd44c305332b | test_VM-1df564f6-5aac-4ac8-8361-bd44c305332b | ACTIVE | - | Running | demo_private=10.0.0.145 | | 2031945f-6305-4cdc-939f-5f02171f82b2 | test_VM-2031945f-6305-4cdc-939f-5f02171f82b2 | ACTIVE | - | Running | demo_private=10.0.0.149 | | 256ff0ed-0e56-47e3-8b69-68006d658ad6 | test_VM-256ff0ed-0e56-47e3-8b69-68006d658ad6 | ACTIVE | - | Running | demo_private=10.0.0.177 |
[Yahoo-eng-team] [Bug 1374519] Re: Orphaned queues are not auto-deleted for Qpid
** Changed in: neutron Status: Confirmed => 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/1374519 Title: Orphaned queues are not auto-deleted for Qpid Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: In Progress Status in Messaging API for OpenStack: Fix Committed Bug description: The following patch incorrectly set auto-delete for Qpid to False: https://github.com/openstack/oslo-incubator/commit/5ff534d1#diff- 372094c4bfc6319d22875a970aa6b730R190 While for RabbitMQ, it's True. This results in queues left on the broker if client dies and does not return back. Red Hat bug for reference: https://bugzilla.redhat.com/show_bug.cgi?id=1099657 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1374519/+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 1386562] Re: keystone did not start (ImportError: Class TemplatedCatalog cannot be found)
Reviewed: https://review.openstack.org/131394 Committed: https://git.openstack.org/cgit/openstack-dev/devstack/commit/?id=7fb5082c5c7abff95eb46dd9a92c5fd8fc63ddd2 Submitter: Jenkins Branch:master commit 7fb5082c5c7abff95eb46dd9a92c5fd8fc63ddd2 Author: wanghong Date: Tue Oct 28 19:09:04 2014 +0800 correct templated catalog driver class Now the templated catalog driver class "TemplatedCatalog" is removed in this patch https://review.openstack.org/#/c/125708/2 use "keystone.catalog.backends.templated.Catalog" instead. Change-Id: Ib9c8ea557e7171ff0c78a1e10d752ed564aff9e7 Closes-Bug: #1386562 ** Changed in: devstack Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1386562 Title: keystone did not start (ImportError: Class TemplatedCatalog cannot be found) Status in devstack - openstack dev environments: Fix Released Status in OpenStack Identity (Keystone): Invalid Bug description: After the commit ID 1ea9d50a2c828a3eb976e458659008a5461b1418 of Steve Martinelli (made on Thu Oct 2 12:57:20 2014 -0400), keystone service can no longer be started. Root cause: - At that commit ID, the class "TemplatedCatalog" is removed from the module keystone.catalog.backends.templated. Another class named "Catalog" also in that module is used. - However, DevStack script is not updated accordingly. Consequently, the file "devstack/lib/keystone" still points to the removed class "TemplatedCatalog". Proposal: - Change the file "devstack/lib/keystone" so that it points to the right class that is the "Catalog" Excerpt of the file "devstack/lib/keystone": # Configure ``keystone.conf`` to use templates iniset $KEYSTONE_CONF catalog driver "keystone.catalog.backends.templated.TemplatedCatalog" iniset $KEYSTONE_CONF catalog template_file "$KEYSTONE_CATALOG" Excerpt of the commit ID 1ea9d50a2c828a3eb976e458659008a5461b1418: commit 1ea9d50a2c828a3eb976e458659008a5461b1418 Author: Steve Martinelli Date: Thu Oct 2 12:57:20 2014 -0400 Remove deprecated TemplatedCatalog class Use keystone.catalog.backends.templated.Catalog instead implements bp removed-as-of-kilo Change-Id: I0415852991e504677d1d1a81740c72f0bd8fc8bb To manage notifications about this bug go to: https://bugs.launchpad.net/devstack/+bug/1386562/+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 1387372] Re: double check admin password when update user password
** Also affects: horizon Importance: Undecided Status: New -- 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/1387372 Title: double check admin password when update user password Status in OpenStack Dashboard (Horizon): New Status in Python client library for Keystone: New Bug description: As an Admin, you can change User passwords (see attached screenshot for Horizon's Edit User modal). However, it is a security issue that the Admin is not asked for his OWN password when making changes. This issue surfaces when using the Horizon dashboard. For example if the logged in admin leaves an unattended computer, someone can change the password of the logged in user successfully. We should add an almost identical method here: https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/v3/users.py#L145 with add added admin password verification before changing password. Then in Horizon, we can add a new field "Admin Password" as a verification that the person changing the password is *really* the logged in user. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1387372/+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 1387989] [NEW] VMware: uploading snapshot to glance_vsphere is too slow
Public bug reported: uploading snapshot to glance datastore is too slow in vSphere env. This have to be done by vSphere API not HTTP transfer if glance_store is vsphere. ** Affects: nova Importance: Undecided Assignee: Koichi Yoshigoe (degdoo) Status: New ** Changed in: nova Assignee: (unassigned) => Koichi Yoshigoe (degdoo) -- 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/1387989 Title: VMware: uploading snapshot to glance_vsphere is too slow Status in OpenStack Compute (Nova): New Bug description: uploading snapshot to glance datastore is too slow in vSphere env. This have to be done by vSphere API not HTTP transfer if glance_store is vsphere. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1387989/+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 1387973] [NEW] Normal user not able to download image if protected property is not associated with the image with restrict-download policy
Public bug reported: If restrict download rule is configured in policy.json, and image is added without protected property mentioned in "restricted" rule, then normal users (other than admin) not able to download the image. Steps to reproduce: 1. Create normal_user with _member_ role using horizon 2. Configure download rule in policy.json "download_image": "role:admin or rule:restricted", "restricted": "not ('test_1234':%(test_key)s and role:_member_)", 3. Restart glance-api service 4. create image without property 'test_key' with admin user i. source devstack/openrc admin admin ii. glance image-create iii. glance image-update --name non_protected --disk-format qcow2 --container-format bare --is-public True --file /home/openstack/api.log 5. Try to download the newly created image with normal_user. i. source devstack/openrc normal_user admin ii. glance image-download It returns 403 Forbidden response to the user, where as admin user can download the image successfully. Expected behavior is all users can download the images if restricted property is not added. Note: With the current oslo-incubator policy module, this issue is not reproducible. ** Affects: glance Importance: Undecided Status: New ** Tags: ntt -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1387973 Title: Normal user not able to download image if protected property is not associated with the image with restrict-download policy Status in OpenStack Image Registry and Delivery Service (Glance): New Bug description: If restrict download rule is configured in policy.json, and image is added without protected property mentioned in "restricted" rule, then normal users (other than admin) not able to download the image. Steps to reproduce: 1. Create normal_user with _member_ role using horizon 2. Configure download rule in policy.json "download_image": "role:admin or rule:restricted", "restricted": "not ('test_1234':%(test_key)s and role:_member_)", 3. Restart glance-api service 4. create image without property 'test_key' with admin user i. source devstack/openrc admin admin ii. glance image-create iii. glance image-update --name non_protected --disk-format qcow2 --container-format bare --is-public True --file /home/openstack/api.log 5. Try to download the newly created image with normal_user. i. source devstack/openrc normal_user admin ii. glance image-download It returns 403 Forbidden response to the user, where as admin user can download the image successfully. Expected behavior is all users can download the images if restricted property is not added. Note: With the current oslo-incubator policy module, this issue is not reproducible. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1387973/+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