[Yahoo-eng-team] [Bug 1525472] [NEW] Taking into account the exception with status_code
Public bug reported: When an exception occurs in ajax[1], we get status code from only two kinds of exceptions: exception with property 'http_status' or 'code'. To make it easier to distinguish between different error, we should take into account the exception with 'status_code', such as NotAuthorized[2]. [1]: https://github.com/openstack/horizon/blob/master/openstack_dashboard/api/rest/utils.py#L136 [2]: https://github.com/openstack/horizon/blob/master/horizon/exceptions.py#L119 ** Affects: horizon Importance: Undecided Assignee: javeme (javaloveme) Status: In Progress ** Description changed: - - When an exception occurs in ajax[1], we get status code from only two kinds of - exceptions: exception with property 'http_status' or 'code'. + When an exception occurs in ajax[1], we get status code from only two + kinds of exceptions: exception with property 'http_status' or 'code'. To make it easier to distinguish between different error, we should take into account the exception with 'status_code', such as NotAuthorized[2]. - [1]: https://github.com/openstack/horizon/blob/master/openstack_dashboard/api/rest/utils.py#L136 [2]: https://github.com/openstack/horizon/blob/master/horizon/exceptions.py#L119 ** Changed in: horizon Assignee: (unassigned) => javeme (javaloveme) -- 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/1525472 Title: Taking into account the exception with status_code Status in OpenStack Dashboard (Horizon): In Progress Bug description: When an exception occurs in ajax[1], we get status code from only two kinds of exceptions: exception with property 'http_status' or 'code'. To make it easier to distinguish between different error, we should take into account the exception with 'status_code', such as NotAuthorized[2]. [1]: https://github.com/openstack/horizon/blob/master/openstack_dashboard/api/rest/utils.py#L136 [2]: https://github.com/openstack/horizon/blob/master/horizon/exceptions.py#L119 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1525472/+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 1334226] Re: Lock wait timeout updating ipavailabilityranges
[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/1334226 Title: Lock wait timeout updating ipavailabilityranges Status in neutron: Expired Bug description: Note that this is different from bug https://bugs.launchpad.net/neutron/+bug/1330638 Traceback: neutron.api.v2.resource Traceback (most recent call last): neutron.api.v2.resource File "/opt/stack/new/neutron/neutron/api/v2/resource.py", line 87, in resource neutron.api.v2.resource result = method(request=request, **args) neutron.api.v2.resource File "/opt/stack/new/neutron/neutron/api/v2/base.py", line 447, in create neutron.api.v2.resource obj = obj_creator(request.context, **kwargs) neutron.api.v2.resource File "/opt/stack/new/neutron/neutron/db/l3_db.py", line 148, in create_router neutron.api.v2.resource self._update_router_gw_info(context, router_db['id'], gw_info) neutron.api.v2.resource File "/opt/stack/new/neutron/neutron/db/l3_gwmode_db.py", line 58, in _update_router_gw_info neutron.api.v2.resource context, router_id, info, router=router) neutron.api.v2.resource File "/opt/stack/new/neutron/neutron/db/l3_db.py", line 316, in _update_router_gw_info neutron.api.v2.resource self._create_gw_port(context, router_id, router, network_id) neutron.api.v2.resource File "/opt/stack/new/neutron/neutron/db/l3_db.py", line 306, in _create_gw_port neutron.api.v2.resource self._create_router_gw_port(context, router, new_network) neutron.api.v2.resource File "/opt/stack/new/neutron/neutron/db/l3_db.py", line 255, in _create_router_gw_port neutron.api.v2.resource 'name': ''}}) neutron.api.v2.resource File "/opt/stack/new/neutron/neutron/plugins/ml2/plugin.py", line 644, in create_port neutron.api.v2.resource result = super(Ml2Plugin, self).create_port(context, port) neutron.api.v2.resource File "/opt/stack/new/neutron/neutron/db/db_base_plugin_v2.py", line 1464, in create_port neutron.api.v2.resource context.session.add(allocated) neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/session.py", line 463, in __exit__ neutron.api.v2.resource self.rollback() neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/util/langhelpers.py", line 57, in __exit__ neutron.api.v2.resource compat.reraise(exc_type, exc_value, exc_tb) neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/session.py", line 460, in __exit__ neutron.api.v2.resource self.commit() neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/session.py", line 370, in commit neutron.api.v2.resource self._prepare_impl() neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/session.py", line 350, in _prepare_impl neutron.api.v2.resource self.session.flush() neutron.api.v2.resource File "/opt/stack/new/neutron/neutron/openstack/common/db/sqlalchemy/session.py", line 439, in _wrap neutron.api.v2.resource return f(self, *args, **kwargs) neutron.api.v2.resource File "/opt/stack/new/neutron/neutron/openstack/common/db/sqlalchemy/session.py", line 705, in flush neutron.api.v2.resource return super(Session, self).flush(*args, **kwargs) neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/session.py", line 1907, in flush neutron.api.v2.resource self._flush(objects) neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/session.py", line 2025, in _flush neutron.api.v2.resource transaction.rollback(_capture_exception=True) neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/util/langhelpers.py", line 57, in __exit__ neutron.api.v2.resource compat.reraise(exc_type, exc_value, exc_tb) neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/session.py", line 1989, in _flush neutron.api.v2.resource flush_context.execute() neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/unitofwork.py", line 371, in execute neutron.api.v2.resource rec.execute(self) neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/unitofwork.py", line 524, in execute neutron.api.v2.resource uow neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/persistence.py", line 59, in save_obj neutron.api.v2.resource mapper, table, update) neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/persistence.py", li
[Yahoo-eng-team] [Bug 1504939] Re: Instance failed to spawn with qemu
[Expired for OpenStack Compute (nova) because there has been no activity for 60 days.] ** Changed in: nova Status: Incomplete => Expired -- 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/1504939 Title: Instance failed to spawn with qemu Status in OpenStack Compute (nova): Expired Bug description: I installed Kilo following the instructions on http://docs.openstack.org/kilo/install-guide/install/apt/content/ It failed to spawn an instance with qemu. The nova.conf on compute node was as following: root@cmp1:~# cat /etc/nova/nova.conf [DEFAULT] dhcpbridge_flagfile=/etc/nova/nova.conf dhcpbridge=/usr/bin/nova-dhcpbridge log_dir=/var/log/nova state_path=/var/lib/nova lock_path=/var/lock/nova force_dhcp_release=True libvirt_use_virtio_for_bridges=True verbose=True ec2_private_dns_show_ip=True api_paste_config=/etc/nova/api-paste.ini enabled_apis=ec2,osapi_compute,metadata rpc_backend=rabbit auth_strategy = keystone my_ip = 192.168.201.102 vnc_enabled = True vncserver_listen = 0.0.0.0 vncserver_proxyclient_address = 192.168.201.102 novncproxy_base_url = http://ctl:6080/vnc_auto.html network_api_class = nova.network.neutronv2.api.API security_group_api = neutron linuxnet_interface_driver = nova.network.linux_net.LinuxOVSInterfaceDriver firewall_driver = nova.virt.firewall.NoopFirewallDriver compute_driver = libvirt.LibvirtDriver [glance] host = ctl [oslo_concurrency] lock_path = /var/lib/nova/tmp [keystone_authtoken] auth_uri = http://ctl:5000 auth_url = http://ctl:35357 auth_plugin = password project_domain_id = default user_domain_id = default project_name = service username = nova password = 1 [oslo_messaging_rabbit] rabbit_host = ctl rabbit_userid = openstack rabbit_password = 1 [libvirt] virt_type = qemu [neutron] url = http://ctl:9696 auth_strategy = keystone admin_auth_url = http://ctl:35357/v2.0 admin_tenant_name = service admin_username = neutron admin_password = 1 The error logs were as following: 2015-10-11 20:58:13.239 31702 ERROR nova.virt.libvirt.driver [req-5e9ccf17-f58a-4d4b-82ba-e028da6daff2 311571301159432787db5e3ed1078ee8 8fab0e9be9164f69a2d14ac383175cdc - - -] Error defining a domain with XML: f530cc86-ee2e-4ef4-8655-83f60bfed7fa instance-0006 65536 1 http://openstack.org/xmlns/libvirt/nova/1.0";> an-instance 2015-10-11 12:58:12 64 0 0 0 1 administrator training OpenStack Foundation OpenStack Nova 2015.1.1 564db6eb-b1e8-9c2d-85a4-f5fdc0775533 f530cc86-ee2e-4ef4-8655-83f60bfed7fa hvm 1024 2015-10-11 20:58:13.240 31702 ERROR nova.compute.manager [req-5e9ccf17-f58a-4d4b-82ba-e028da6daff2 311571301159432787db5e3ed1078ee8 8fab0e9be9164f69a2d14ac383175cdc - - -] [instance: f530cc86-ee2e-4ef4-8655-83f60bfed7fa] Instance failed to spawn 2015-10-11 20:58:13.240 31702 TRACE nova.compute.manager [instance: f530cc86-ee2e-4ef4-8655-83f60bfed7fa] Traceback (most recent call last): 2015-10-11 20:58:13.240 31702 TRACE nova.compute.manager [instance: f530cc86-ee2e-4ef4-8655-83f60bfed7fa] File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 2461, in _build_resources 2015-10-11 20:58:13.240 31702 TRACE nova.compute.manager [instance: f530cc86-ee2e-4ef4-8655-83f60bfed7fa] yield resources 2015-10-11 20:58:13.240 31702 TRACE nova.compute.manager [instance: f530cc86-ee2e-4ef4-8655-83f60bfed7fa] File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 2333, in _build_and_run_instance 2015-10-11 20:58:13.240 31702 TRACE nova.compute.manager [instance: f530cc86-ee2e-4ef4-8655-83f60bfed7fa] block_device_info=block_device_info) 2015-10-11 20:58:13.240 31702 TRACE nova.compute.manager [instance: f530cc86-ee2e-4ef4-8655-83f60bfed7fa] File "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py", line 2385, in spawn 2015-10-11 20:58:13.240 31702 TRACE nova.compute.manager [instance: f530cc86-ee2e-4ef4-8655-83f60bfed7fa] block_device_info=block_device_info) 2015-10-11 20:58:13.240 31702 TRACE nova.compute.manager [instance: f530cc86-ee2e-4ef4-8655-83f60bfed7fa] File "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py", line 4403, in _create_domain_and_network 2015-10-11 20:58:13.240 31702 TRACE nova.
[Yahoo-eng-team] [Bug 1525464] [NEW] Release request of networking-cisco and creation of stable/liberty 2.0.0
Public bug reported: networking-cisco has NOT yet been branched for stable/liberty this needs to be done alone with tagging the first release at 2.0.0 Branch and tag at hash: cccaa1d12b81e17756dbef216048d76d008df54d ** Affects: networking-cisco Importance: High Status: New ** Affects: neutron Importance: Undecided Status: New ** Tags: release-subproject ** Changed in: networking-cisco Milestone: None => 2.0.0 ** Also 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/1525464 Title: Release request of networking-cisco and creation of stable/liberty 2.0.0 Status in networking-cisco: New Status in neutron: New Bug description: networking-cisco has NOT yet been branched for stable/liberty this needs to be done alone with tagging the first release at 2.0.0 Branch and tag at hash: cccaa1d12b81e17756dbef216048d76d008df54d To manage notifications about this bug go to: https://bugs.launchpad.net/networking-cisco/+bug/1525464/+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 1458541] Re: Decomposite DVR router compute node and network node functionallity to two classes
I'd be ok not to track a sequence of minor refactoring without a bug report ** Changed in: neutron Status: In Progress => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1458541 Title: Decomposite DVR router compute node and network node functionallity to two classes Status in neutron: Invalid Bug description: Currently the same dvr router class is used both by the L3 Agent in the compute nodes that is responsible for the virtual routers namespace and the fip namespace and also used by the centralized SNAT L3 Agent in the network node. This bug address splitting the above functionality into two different classes To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1458541/+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 1501597] Re: Adding Brocade Vyatta 5600 support in Neutron-Fwaas
FWaaS is being rebooted. ** Changed in: neutron Status: In Progress => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1501597 Title: Adding Brocade Vyatta 5600 support in Neutron-Fwaas Status in neutron: Invalid Bug description: Currently Brocade support only vyatta 5400. Changes are required in Neutron-Fwaas to support Vyatta 5600 image To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1501597/+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 1515069] Re: VXLAN is too slow due because gro does't work
Needs a new owner. ** Tags added: needs-attention ** Changed in: neutron Status: In Progress => Invalid ** Changed in: neutron Status: Invalid => Incomplete ** Changed in: neutron Assignee: okamototk (toraneko) => (unassigned) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1515069 Title: VXLAN is too slow due because gro does't work Status in neutron: Incomplete Bug description: VXLAN + Linux Bridge is too slow because VXLAN outer header check sum is zero and gro is not work on the reciever. This make VXLAN slow. Adding udp checksum in outer header resolve this problem. Open vSwitch agent already resolved by #1492111. Linux Bridge should support outer udp checksum. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1515069/+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 1525424] Re: Automatically generate neutron VPNaaS configuration files
** Also affects: openstack-manuals Importance: Undecided Status: New ** Changed in: neutron Status: New => 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/1525424 Title: Automatically generate neutron VPNaaS configuration files Status in neutron: Fix Released Status in openstack-manuals: New Bug description: https://review.openstack.org/253399 Dear bug triager. This bug was created since a commit was marked with DOCIMPACT. commit 5c8941eeed6dabc9c467c8b9b11df79a25dd2c71 Author: Martin Hickey Date: Fri Dec 4 09:10:04 2015 + Automatically generate neutron VPNaaS configuration files This adds a new tox environment, genconfig, which generates sample neutron VPNaaS configuration file using oslo-config-generator. Updates to some configuration option help messages to reflect useful details that were missing in the code but were present in config files. DocImpact: Update the docs that VPNaaS no longer includes static example configuration files. Instead, use tools/generate_config_file_samples.sh to generate them and the files generated now end with .sample extension. Partially-Implements: blueprint autogen-neutron-conf-file Change-Id: I4a6094b8218dfd320d05bfb1e3bc121e8930c551 Partial-bug: #1199963 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1525424/+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 1464259] Re: Volumes tests fails often with rbd backend
Reviewed: https://review.openstack.org/254428 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=4f2a46987cf705d5dea84e97ef2006342cc5d9c4 Submitter: Jenkins Branch:master commit 4f2a46987cf705d5dea84e97ef2006342cc5d9c4 Author: Matt Riedemann Date: Mon Dec 7 14:49:18 2015 -0800 Make sure bdm.volume_id is set after auto-creating volumes The test_create_ebs_image_and_check_boot test in Tempest does the following: 1. create volume1 from an image 2. boot server1 from volume1 with delete_on_termination=True and wait for the server to be ACTIVE 3. create snapshot from server1 (creates image and volume snapshots) 4. delete server1 5. create server2 from the image snapshot (don't wait for it to be ACTIVE - this auto-creates volume2 from the volume snapshot in cinder and attaches server2 to it) 6. delete server2 (could still be building/attaching volumes in the background) 7. cleanup There is a race when booting server2, which creates and attaches volume2, and deleting server2 before it's active. The volume attach completes and updates the bdm.volume_id in the DB before we get to _shutdown_instance, but after the delete request is in the API. The compute API gets potentially stale BDMs and passes those over RPC to the compute. So we add a check in _shutdown_instance to see if we have potentially stale volume BDMs and refresh that list if so. The instance.uuid locks in build_and_run_instance and terminate_instance create the mutex on the compute host such that the bdm.volume_id should be set in the database after the volume attach and before terminate_instance gets the lock. The bdm.volume_id could still be None in _shutdown_instance if the volume create fails, but we don't have anything to teardown in cinder in that case anyway. In the case of the race bug, deleting the volume snapshot in cinder fails because volume2 was never deleted by nova, so the test fails in teardown. Note that there is still potential for a race here, this does not eliminate it, but should narrow the race window. This also cleans up the logging in attach_block_devices since there may not be a volume_id at that point (depending on bdm.source_type). Closes-Bug: #1464259 Change-Id: Ib60d60a5af35be89ad8afbcf44fcffe0b0ce2876 ** 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/1464259 Title: Volumes tests fails often with rbd backend Status in Cinder: Triaged Status in OpenStack Compute (nova): Fix Released Status in tempest: Invalid Bug description: http://logs.openstack.org/02/173802/5/check/check-tempest-dsvm-full- ceph/a72aac1/logs/screen-n-api.txt.gz?level=TRACE#_2015-06-11_09_04_19_511 2015-06-11 09:04:19.511 ERROR nova.api.ec2 [req-0ac81d78-2717-4dd2-80e2-d94363b55ac8 EC2VolumesTest-442487008 EC2VolumesTest-1066393631] Unexpected InvalidInput raised: Invalid input received: Invalid volume: Volume still has 1 dependent snapshots. (HTTP 400) (Request-ID: req-4586b5d2-7212-4ddd-af79-43ad8ba7ea58) 2015-06-11 09:04:19.511 ERROR nova.api.ec2 [req-0ac81d78-2717-4dd2-80e2-d94363b55ac8 EC2VolumesTest-442487008 EC2VolumesTest-1066393631] Environment: {"HTTP_AUTHORIZATION": "AWS4-HMAC-SHA256 Credential=a5e9253350ce4a249ddce8b7c1c798c2/20150611/0/127/aws4_request,SignedHeaders=host;x-amz-date,Signature=304830ed947f7fba3143887b08d1e47faa18d4b59782c0992727cb7593f586b4", "SCRIPT_NAME": "", "REQUEST_METHOD": "POST", "HTTP_X_AMZ_DATE": "20150611T090418Z", "PATH_INFO": "/", "SERVER_PROTOCOL": "HTTP/1.0", "CONTENT_LENGTH": "60", "HTTP_USER_AGENT": "Boto/2.38.0 Python/2.7.6 Linux/3.13.0-53-generic", "RAW_PATH_INFO": "/", "REMOTE_ADDR": "127.0.0.1", "wsgi.url_scheme": "http", "SERVER_PORT": "8773", "CONTENT_TYPE": "application/x-www-form-urlencoded; charset=UTF-8", "HTTP_HOST": "127.0.0.1:8773", "SERVER_NAME": "127.0.0.1", "GATEWAY_INTERFACE": "CGI/1.1", "REMOTE_PORT": "45819", "HTTP_ACCEPT_ENCODING": "identity"} http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiRUMyVm9sdW1lc1Rlc3RcIiBBTkQgbWVzc2FnZTpcIlVuZXhwZWN0ZWQgSW52YWxpZElucHV0IHJhaXNlZDogSW52YWxpZCBpbnB1dCByZWNlaXZlZDogSW52YWxpZCB2b2x1bWU6IFZvbHVtZSBzdGlsbCBoYXMgMSBkZXBlbmRlbnQgc25hcHNob3RzXCIgQU5EIHRhZ3M6XCJzY3JlZW4tbi1hcGkudHh0XCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjYwNDgwMCIsImdyYXBobW9kZSI6ImNvdW50IiwidGltZSI6eyJ1c2VyX2ludGVydmFsIjowfSwic3RhbXAiOjE0MzQwMzAyMTUwODd9 10 hits in 7 days, check and gate, hitting on the ceph and glusterfs jobs. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1464259/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@
[Yahoo-eng-team] [Bug 1525439] [NEW] Glance V2 API is not backwards compatible and breaks Cinder solidfire driver
Public bug reported: In stable/kilo Glance API V2 change of image-metadata is_public flag to visibility = Public breaks the SolidFire (and maybe other, NetApp?) drivers that depend on is_public flag. Specifically this breaks the ability efficiently handle images by caching images in the SolidFire cluster. Changing the API back to V1 through the cinder.conf file then breaks Ceph which depends on V2 and the image-metadata direct_url and locations to determine if it can clone a image to a volume. So this breaks Ceph's ability to efficiently handle images This version mismatch does not allow for SolidFire and Ceph to both be used efficiently in the same OpenStack cloud. NOTE: openstack/puppet-cinder defaults to glance-api-version = 2 which allows Ceph efficientcy to work and not SolidFire (and others). Mainly Opening this Bug to document this problem since no changes are allowed to Kilo there is probably no way to fix this. Code locations: cinder/cinder/image/glance.py line 250-256 cinder/cinder/volume/drivers/rbd.py line 827 cinder/cinder/volume/drivers/solidfire.py line 647 puppet-cinder/manifests/glance.pp line 59 ** Affects: cinder Importance: Undecided Assignee: John Griffith (john-griffith) Status: Triaged ** Affects: glance Importance: Undecided Status: New ** Affects: puppet-cinder Importance: Undecided Status: New ** Tags: cinder puppet ** Also affects: cinder Importance: Undecided Status: New ** Also affects: puppet-cinder Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1525439 Title: Glance V2 API is not backwards compatible and breaks Cinder solidfire driver Status in Cinder: Triaged Status in Glance: New Status in puppet-cinder: New Bug description: In stable/kilo Glance API V2 change of image-metadata is_public flag to visibility = Public breaks the SolidFire (and maybe other, NetApp?) drivers that depend on is_public flag. Specifically this breaks the ability efficiently handle images by caching images in the SolidFire cluster. Changing the API back to V1 through the cinder.conf file then breaks Ceph which depends on V2 and the image-metadata direct_url and locations to determine if it can clone a image to a volume. So this breaks Ceph's ability to efficiently handle images This version mismatch does not allow for SolidFire and Ceph to both be used efficiently in the same OpenStack cloud. NOTE: openstack/puppet-cinder defaults to glance-api-version = 2 which allows Ceph efficientcy to work and not SolidFire (and others). Mainly Opening this Bug to document this problem since no changes are allowed to Kilo there is probably no way to fix this. Code locations: cinder/cinder/image/glance.py line 250-256 cinder/cinder/volume/drivers/rbd.py line 827 cinder/cinder/volume/drivers/solidfire.py line 647 puppet-cinder/manifests/glance.pp line 59 To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1525439/+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 1525430] [NEW] neutron-lbaas tempest v2 api tests not passing config to serviceclient
Public bug reported: Current lbaas tempest v2 api tests do not pass on certain configuration information to the underlyiing ServiceClient used to make a connection, so tests do not work if values like the endpoint_type or region for the network are changed in the tempest.conf. Similarly cannot change control values like the build_timeout. For example, run tempest tests from the neuton_lbaas tree via OS_TEST_PATH with TEMPEST_CONFIG_DIR set to a tempest.conf that has modified network values: endpoint_type = internalURL The existing code will not honor this endpoint_type for the client. Fix is to pass on the info. I.e. instead of the current code: client_args = [auth_provider, 'network', 'regionOne'] cls.load_balancers_client = ( load_balancers_client.LoadBalancersClientJSON(*client_args)) Read configuration and pass on the parameters if they exist thru to the ServiceClient base class underling the client connection with method signature: def __init__(self, auth_provider, service, region, endpoint_type=None, build_interval=None, build_timeout=None, disable_ssl_certificate_validation=None, ca_certs=None, trace_requests=None): ** Affects: neutron Importance: Undecided Assignee: James Arendt (james-arendt-7) Status: New ** Changed in: neutron Assignee: (unassigned) => James Arendt (james-arendt-7) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1525430 Title: neutron-lbaas tempest v2 api tests not passing config to serviceclient Status in neutron: New Bug description: Current lbaas tempest v2 api tests do not pass on certain configuration information to the underlyiing ServiceClient used to make a connection, so tests do not work if values like the endpoint_type or region for the network are changed in the tempest.conf. Similarly cannot change control values like the build_timeout. For example, run tempest tests from the neuton_lbaas tree via OS_TEST_PATH with TEMPEST_CONFIG_DIR set to a tempest.conf that has modified network values: endpoint_type = internalURL The existing code will not honor this endpoint_type for the client. Fix is to pass on the info. I.e. instead of the current code: client_args = [auth_provider, 'network', 'regionOne'] cls.load_balancers_client = ( load_balancers_client.LoadBalancersClientJSON(*client_args)) Read configuration and pass on the parameters if they exist thru to the ServiceClient base class underling the client connection with method signature: def __init__(self, auth_provider, service, region, endpoint_type=None, build_interval=None, build_timeout=None, disable_ssl_certificate_validation=None, ca_certs=None, trace_requests=None): To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1525430/+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 1303856] Re: please mark a volume as read-only
** Changed in: python-cinderclient Status: In Progress => Won't Fix -- 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/1303856 Title: please mark a volume as read-only Status in OpenStack Dashboard (Horizon): In Progress Status in python-cinderclient: Won't Fix Bug description: currently, once I update a volume to read-only its only shown in the metadata. however, I think a read-only change (could be worse when we change from read-only to read/write) is really important and should be very visible to the user. as you can see, we can only see that the volume is read-only in the metadata: [root@host ~(keystone_admin)]# cinder create --display-name dafna 10 +-+--+ | Property |Value | +-+--+ | attachments | [] | | availability_zone | nova | | bootable |false | | created_at | 2014-04-03T13:16:03.137237 | | display_description | None | | display_name|dafna | | encrypted |False | | id | 51c841ec-24a5-49fe-8441-01593b39b2f7 | | metadata | {} | | size| 10 | | snapshot_id | None | | source_volid| None | |status | creating | | volume_type | None | +-+--+ [root@host ~(keystone_admin)]# cinder list +--+---+--+--+-+--+-+ | ID | Status | Display Name | Size | Volume Type | Bootable | Attached to | +--+---+--+--+-+--+-+ | 51c841ec-24a5-49fe-8441-01593b39b2f7 | available |dafna | 10 | None| false | | | 54d28f61-2f0f-4be4-8e27-855a50a50c33 | available | emptyVol | 1 | None| false | | | 82a7a825-6106-4139-9bc8-4334ccc38e85 | available | volFromImage | 1 | None| true | | +--+---+--+--+-+--+-+ [root@host ~(keystone_admin)]# cinder readonly-mode-update 51c841ec-24a5-49fe-8441-01593b39b2f7 true [root@host ~(keystone_admin)]# cinder list +--+---+--+--+-+--+-+ | ID | Status | Display Name | Size | Volume Type | Bootable | Attached to | +--+---+--+--+-+--+-+ | 51c841ec-24a5-49fe-8441-01593b39b2f7 | available |dafna | 10 | None| false | | | 54d28f61-2f0f-4be4-8e27-855a50a50c33 | available | emptyVol | 1 | None| false | | | 82a7a825-6106-4139-9bc8-4334ccc38e85 | available | volFromImage | 1 | None| true | | +--+---+--+--+-+--+-+ [root@host ~(keystone_admin)]# cinder show 51c841ec-24a5-49fe-8441-01593b39b2f7 ++--+ |Property|Value | ++--+ | attachments | [] | | availability_zone| nova | |bootable|false | | created_at | 2014-04-03T13:16:03.00 | | display_description | None | | display_name |dafna | | encrypted|False | | id | 51c841ec-24a5-49fe-8441-01593b39b2f7 | |metadata|{u'readonly': u'True'}| | os-vol-host-attr:host | orange-vdsf.qa.lab.tlv.redhat.com | | os-vol-mig-status-attr:migstat | None | | os-vol-mig-status-at
[Yahoo-eng-team] [Bug 1525423] [NEW] get_networks performance hindered by segment lookups
Public bug reported: During the get_networks method of ML2, we iterate over each network and do a database call to lookup the segments for that network. This scales the number of database calls linearly with the number of retrieved networks. ** Affects: neutron Importance: Undecided Assignee: Kevin Benton (kevinbenton) Status: In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1525423 Title: get_networks performance hindered by segment lookups Status in neutron: In Progress Bug description: During the get_networks method of ML2, we iterate over each network and do a database call to lookup the segments for that network. This scales the number of database calls linearly with the number of retrieved networks. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1525423/+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 1525424] [NEW] Automatically generate neutron VPNaaS configuration files
Public bug reported: https://review.openstack.org/253399 Dear bug triager. This bug was created since a commit was marked with DOCIMPACT. commit 5c8941eeed6dabc9c467c8b9b11df79a25dd2c71 Author: Martin Hickey Date: Fri Dec 4 09:10:04 2015 + Automatically generate neutron VPNaaS configuration files This adds a new tox environment, genconfig, which generates sample neutron VPNaaS configuration file using oslo-config-generator. Updates to some configuration option help messages to reflect useful details that were missing in the code but were present in config files. DocImpact: Update the docs that VPNaaS no longer includes static example configuration files. Instead, use tools/generate_config_file_samples.sh to generate them and the files generated now end with .sample extension. Partially-Implements: blueprint autogen-neutron-conf-file Change-Id: I4a6094b8218dfd320d05bfb1e3bc121e8930c551 Partial-bug: #1199963 ** Affects: neutron Importance: Undecided Status: New ** Tags: neutron-vpnaas -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1525424 Title: Automatically generate neutron VPNaaS configuration files Status in neutron: New Bug description: https://review.openstack.org/253399 Dear bug triager. This bug was created since a commit was marked with DOCIMPACT. commit 5c8941eeed6dabc9c467c8b9b11df79a25dd2c71 Author: Martin Hickey Date: Fri Dec 4 09:10:04 2015 + Automatically generate neutron VPNaaS configuration files This adds a new tox environment, genconfig, which generates sample neutron VPNaaS configuration file using oslo-config-generator. Updates to some configuration option help messages to reflect useful details that were missing in the code but were present in config files. DocImpact: Update the docs that VPNaaS no longer includes static example configuration files. Instead, use tools/generate_config_file_samples.sh to generate them and the files generated now end with .sample extension. Partially-Implements: blueprint autogen-neutron-conf-file Change-Id: I4a6094b8218dfd320d05bfb1e3bc121e8930c551 Partial-bug: #1199963 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1525424/+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 1524164] Re: Decompose OFAgent mechanism driver from neutron tree completely
Reviewed: https://review.openstack.org/255579 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=ee78b063c7652d52be81fcc8eb41dbf24d459ecc Submitter: Jenkins Branch:master commit ee78b063c7652d52be81fcc8eb41dbf24d459ecc Author: fumihiko kakuma Date: Wed Dec 9 13:00:39 2015 +0900 Decompose OFAgent mechanism driver from neutron tree completely All 3rd-party code is required to be removed from the neutron tree. This change removes definition for ofagent mechanism driver from neutron repository. Change-Id: Ia21387eeaed71f38822356e22e4adbd237c1e64c Closes-Bug: #1524164 Depends-On: I04c741daf12e7628e2c1e2d1b81b2b2ce1310542 ** 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/1524164 Title: Decompose OFAgent mechanism driver from neutron tree completely Status in networking-ofagent: Fix Released Status in neutron: Fix Released Bug description: All 3rd-party code is required to be removed from the neutron tree[1]. We move the definition for ofagent mechanism driver to networking-ofagent from neutron tree. [1] http://docs.openstack.org/developer/neutron/devref/contribute.html To manage notifications about this bug go to: https://bugs.launchpad.net/networking-ofagent/+bug/1524164/+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 1525410] [NEW] Volume Manage QoS Specs table is too small
Public bug reported: The table should stretch across the size of the browser window. ** Affects: horizon Importance: Undecided Status: New ** Attachment added: "Screen Shot 2015-12-11 at 1.27.10 PM.png" https://bugs.launchpad.net/bugs/1525410/+attachment/4533420/+files/Screen%20Shot%202015-12-11%20at%201.27.10%20PM.png -- 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/1525410 Title: Volume Manage QoS Specs table is too small Status in OpenStack Dashboard (Horizon): New Bug description: The table should stretch across the size of the browser window. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1525410/+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 1525408] [NEW] form error background color not showing
Public bug reported: How to reproduce: - Open up the Create Instance model - Leave fields blank - Click on create user - See errors show up The error message shows up but the usual red background is gone. Possibly caused by the refactoring of CSS. ** 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/1525408 Title: form error background color not showing Status in OpenStack Dashboard (Horizon): New Bug description: How to reproduce: - Open up the Create Instance model - Leave fields blank - Click on create user - See errors show up The error message shows up but the usual red background is gone. Possibly caused by the refactoring of CSS. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1525408/+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 1450658] Re: VolumeBackendAPIException during _shutdown_instance are not handled
** No longer affects: python-cinderclient -- 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/1450658 Title: VolumeBackendAPIException during _shutdown_instance are not handled Status in OpenStack Compute (nova): Fix Released Bug description: Use rally for cinder boot from voume test, after test completed, found a lot of VMs were deleted failed with error status, manual retry a few times to delete VM, but can't work. [root@abba-n04 home]# nova list --all-tenants +--+---+--+++-+--+ | ID | Name | Tenant ID| Status | Task State | Power State | Networks | +--+---+--+++-+--+ | 335f2ca0-a86d-45a5-b4a6-4d4ea1930e89 | rally_novaserver_aftvfqejftusyflf | 3e87ac6d12264286a10ac68eb913dacb | ERROR | - | NOSTATE | | | 888aa512-07f0-42ad-ae5e-255bbca6fe34 | rally_novaserver_ajqhjxjxnjojelgm | 7e05339543e743c3b023cee8128e | ERROR | - | NOSTATE | | | 84b32483-2997-4a2a-8d75-236395b4ef2f | rally_novaserver_arycquunqovvyxnl | 3e87ac6d12264286a10ac68eb913dacb | ERROR | - | NOSTATE | | | 535f1ce1-63fe-4681-b215-e21d38f77fbb | rally_novaserver_arzjesynagiqfjgt | 3e87ac6d12264286a10ac68eb913dacb | ERROR | - | NOSTATE | | | 6ef3fa37-e5a9-4a21-8996-d291070c246a | rally_novaserver_aufevkgzvynumwwo | d37e8219a3de4e5b985828a0b959f1d6 | ERROR | - | NOSTATE | | | e5d2dc5f-6e86-43e2-8f1f-1a3f6d4951bc | rally_novaserver_ayzjeqcplouwcaht | d37e8219a3de4e5b985828a0b959f1d6 | ERROR | - | NOSTATE | | | 2dcb294a-e2cc-4989-9e87-74081f1567db | rally_novaserver_bbphsjrexkcgcjtt | 7e05339543e743c3b023cee8128e | ERROR | - | NOSTATE | | | 88053991-2fab-4442-86c7-7825ed47ff0a | rally_novaserver_beveqwdokixwdbgi | 3e87ac6d12264286a10ac68eb913dacb | ERROR | - | NOSTATE | | | 1e109862-34ea-4686-a099-28f5840244cf | rally_novaserver_bimlwsfkndjbrczv | d37e8219a3de4e5b985828a0b959f1d6 | ERROR | - | NOSTATE | | | 6143bbb2-d3eb-4635-9554-85b30fbb5aa5 | rally_novaserver_bmycsptyoicymdmb | 3e87ac6d12264286a10ac68eb913dacb | ERROR | - | NOSTATE | | | 5e9308ae-9736-485f-92b7-e6783c613ba1 | rally_novaserver_bsvcnsqeyawcnbgp | d37e8219a3de4e5b985828a0b959f1d6 | ERROR | - | NOSTATE | | | 13fb2413-15b6-41a3-a8a0-a0b775747261 | rally_novaserver_bvfyfnnixwgisbkk | d37e8219a3de4e5b985828a0b959f1d6 | ERROR | - | NOSTATE | | | d5ce6fa3-99b5-4d61-ac7c-4b5bc13d1c27 | rally_novaserver_cpbevhulxylepvql | 3e87ac6d12264286a10ac68eb913dacb | ERROR | - | NOSTATE | | | 23ce9007-ab43-4b57-8686-4aa1ce336f09 | rally_novaserver_cswudaopawepnmms | 7e05339543e743c3b023cee8128e | ERROR | - | NOSTATE | | [root@abba-n04 home]# nova delete 335f2ca0-a86d-45a5-b4a6-4d4ea1930e89 Request to delete server 335f2ca0-a86d-45a5-b4a6-4d4ea1930e89 has been accepted. [root@abba-n04 home]# nova list --all | grep 335f2ca0-a86d-45a5-b4a6-4d4ea1930e89 | 335f2ca0-a86d-45a5-b4a6-4d4ea1930e89 | rally_novaserver_aftvfqejftusyflf | 3e87ac6d12264286a10ac68eb913dacb | ERROR | - | NOSTATE | | [root@abba-n04 home]# The system is using local LVM volumes attached via iSCSI. It appears that something is going wrong when the attempt to detach the volume is being made: 2015-04-29 07:26:02.680 21775 DEBUG oslo_concurrency.processutils [req-fec5ff89-5465-4e76-b573-6a5afc0d4ee2 a9d0160b91f2412d84972a615b7547dc 828348052e494d76a401f669f85829f3 - - -] Running cmd (subprocess): sudo cinder-rootwrap /etc/cinder/rootwrap.conf cinder-rtstool delete-initiator iqn.2010-10.org.openstack:volume-a2907017-dda6-4243-bc50-85fe2164f05f iqn.1994-05.com.redhat:734fb33285d0 execute /usr/lib/python2.7/site-packages/oslo_concurrency/processutils.py:199 2015-04-29 07:26:02.813 21775 DEBUG oslo_concurrency.processutils [req-fec5ff89-5465-4e76-b573-6a5afc0d4ee2 a9d0160b91f2412d84972a615b7547dc 828348052e494d76a401f669f85829f3 - - -] CMD "sudo cinder-rootwrap /etc/cinder/rootwrap.conf cinder-rtstool delete-initiator iqn.2010-10.org.openstack:volume-a2907017-dda6-4243-bc50-85fe2164f05f iqn.1994-05.com.redhat:734fb33285d0" returned: 1 in 0.133s execute /usr/lib/python2.7/site-packages/oslo_concurrency/processutils.py:225 2015-04-29 07:26:02.814 21775 DEBUG oslo_concurrency.processutils [req-fe
[Yahoo-eng-team] [Bug 1525397] [NEW] Integration tests (both tempest and selenium) don't respect Depends-On: Zuul feature
Public bug reported: Here are 2 patches https://review.openstack.org/#/c/224759/ for Horizon and its django-openstack-auth dependency https://review.openstack.org/#/c/224756/ Although dependency is explicitly mentioned in Horizon patch, integration tests of all kinds still fail to use django-openstack-commit while testing Horizon patch. ** 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/1525397 Title: Integration tests (both tempest and selenium) don't respect Depends- On: Zuul feature Status in OpenStack Dashboard (Horizon): New Bug description: Here are 2 patches https://review.openstack.org/#/c/224759/ for Horizon and its django-openstack-auth dependency https://review.openstack.org/#/c/224756/ Although dependency is explicitly mentioned in Horizon patch, integration tests of all kinds still fail to use django-openstack- commit while testing Horizon patch. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1525397/+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 1525387] [NEW] Wrong naming of nova extension
Public bug reported: I use Heat for creating VMs, and one part of new Heat code (in stable/liberty and in master) uses nova extensions: https://github.com/openstack/heat/blob/master/heat/engine/resources/openstack/nova/server_network_mixin.py#L188 I wanted to find this extension, but faced with following issue: 1. All nova documentation tells about "os-interface" extension instead of "os-attach-interfaces" 2. Also I founded, that nova code has some misunderstanding between alias and name: https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/legacy_v2/contrib/attach_interfaces.py#L196 it has: alias = "os-attach-interfaces" But in the same time uses different key for creating extension: https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/legacy_v2/contrib/attach_interfaces.py#L203 os-interface The same issue is in name option - it's AttachInterfaces It looks like bug in naming, because another nova extension has clear naming without such confusion: https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/legacy_v2/contrib/server_password.py#L54-L64 I'm not sure where it should be fixed: doc vs nova code. P.s. if you will fix it in code, don't forget to backport it in stable/liberty too, please. ** Affects: nova Importance: Undecided Status: New ** Tags: liberty-backport-potential -- 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/1525387 Title: Wrong naming of nova extension Status in OpenStack Compute (nova): New Bug description: I use Heat for creating VMs, and one part of new Heat code (in stable/liberty and in master) uses nova extensions: https://github.com/openstack/heat/blob/master/heat/engine/resources/openstack/nova/server_network_mixin.py#L188 I wanted to find this extension, but faced with following issue: 1. All nova documentation tells about "os-interface" extension instead of "os-attach-interfaces" 2. Also I founded, that nova code has some misunderstanding between alias and name: https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/legacy_v2/contrib/attach_interfaces.py#L196 it has: alias = "os-attach-interfaces" But in the same time uses different key for creating extension: https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/legacy_v2/contrib/attach_interfaces.py#L203 os-interface The same issue is in name option - it's AttachInterfaces It looks like bug in naming, because another nova extension has clear naming without such confusion: https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/legacy_v2/contrib/server_password.py#L54-L64 I'm not sure where it should be fixed: doc vs nova code. P.s. if you will fix it in code, don't forget to backport it in stable/liberty too, please. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1525387/+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 1525375] [NEW] Horizon-liberty in a mixed version env throws 'TypeError at /admin/networks/'
Public bug reported: I'm implementing Horizon (Liberty) in a mixed environment cloud so we can switch to v3 Identity API. I have the following components: Horizon : Liberty Keystone : Kilo Everything Else: Icehouse I have pretty good results until I click the Admin->System->Networks link, after which I get a very prominent error: TypeError at /admin/networks/ ... followed by lots of other cruft. The cruft from my browser screen can be found here: http://paste.openstack.org/show/481701/ -(sorry... its poorly formatted. Just a copy and paste from the browser, no formatting preserved) The stacktrace from /var/log/apache2/error.log is found here: http://paste.openstack.org/show/481700/ Thanks ** Affects: horizon Importance: Medium Status: New ** Tags: sweetjeebus -- 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/1525375 Title: Horizon-liberty in a mixed version env throws 'TypeError at /admin/networks/' Status in OpenStack Dashboard (Horizon): New Bug description: I'm implementing Horizon (Liberty) in a mixed environment cloud so we can switch to v3 Identity API. I have the following components: Horizon : Liberty Keystone : Kilo Everything Else: Icehouse I have pretty good results until I click the Admin->System->Networks link, after which I get a very prominent error: TypeError at /admin/networks/ ... followed by lots of other cruft. The cruft from my browser screen can be found here: http://paste.openstack.org/show/481701/ -(sorry... its poorly formatted. Just a copy and paste from the browser, no formatting preserved) The stacktrace from /var/log/apache2/error.log is found here: http://paste.openstack.org/show/481700/ Thanks To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1525375/+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 1380787] Re: remove XML support
Reviewed: https://review.openstack.org/144439 Committed: https://git.openstack.org/cgit/openstack/python-neutronclient/commit/?id=54a4aea969fe06422f64005652ce23ac7b616d98 Submitter: Jenkins Branch:master commit 54a4aea969fe06422f64005652ce23ac7b616d98 Author: Elena Ezhova Date: Fri Dec 4 16:45:47 2015 +0300 Remove XML support As XML support has been removed from neutron, there is no need to keep it in client. Dropped XML serializer and deserializer and deprecated "request-format" CLI option, making JSON the default and the only supported request format. DocImpact Change-Id: I88b0fdd65a649694252d5ff43a174e75026df5b1 Closes-Bug: #1380787 ** Changed in: python-neutronclient 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/1380787 Title: remove XML support Status in neutron: Fix Released Status in python-neutronclient: Fix Released Bug description: XML support has been deprecated for Icehouse[1] and Juno[2]. It is time to remove it in Kilo. [1] https://wiki.openstack.org/wiki/ReleaseNotes/Icehouse#Upgrade_Notes_6 [2] https://wiki.openstack.org/wiki/ReleaseNotes/Juno#Upgrade_Notes_6 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1380787/+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 1525317] Re: IdP doesn't support field based DB filtering
** Project changed: python-openstackclient => keystone -- 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/1525317 Title: IdP doesn't support field based DB filtering Status in OpenStack Identity (keystone): New Bug description: Currently, IdP doesn't support to filter the DB records based on the field, for example, If configure the DB like this, mysql> select * from identity_provider; +--+-+-+ | id | enabled | description | +--+-+-+ | idp1 | 1 | NULL| | idp2 | 1 | NULL| +--+-+-+ 2 rows in set (0.00 sec) And I query the IdP by this curl, I get all of the records from DB, curl -g -i -X GET http://127.0.0.1:35357/v3/OS- FEDERATION/identity_providers?id=idontexist -H "User-Agent: python- keystoneclient" -H "Accept: application/json" -H "X-Auth-Token: f74ac35177cb4720891a9cfed5ea1b9c" { "links": { "self": "http://10.239.48.36:35357/v3/OS-FEDERATION/identity_providers?id=idp1";, "previous": null, "next": null }, "identity_providers": [{ "remote_ids": [], "enabled": true, "id": "idp1", "links": { "self": "http://10.239.48.36:35357/v3/OS-FEDERATION/identity_providers/idp1";, "protocols": "http://10.239.48.36:35357/v3/OS-FEDERATION/identity_providers/idp1/protocols"; }, "description": null }, { "remote_ids": [], "enabled": true, "id": "idp2", "links": { "self": "http://10.239.48.36:35357/v3/OS-FEDERATION/identity_providers/idp2";, "protocols": "http://10.239.48.36:35357/v3/OS-FEDERATION/identity_providers/idp2/protocols"; }, "description": null }] } This feature should be supported since OSC depends on this to filter the DB records wanted. Noted: Open this bug since it's different with https://bugs.launchpad.net/python-openstackclient/+bug/1479837, they are two different things, and I think this more sound like a feature that keystone should support. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1525317/+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 1525317] [NEW] IdP doesn't support field based DB filtering
You have been subscribed to a public bug: Currently, IdP doesn't support to filter the DB records based on the field, for example, If configure the DB like this, mysql> select * from identity_provider; +--+-+-+ | id | enabled | description | +--+-+-+ | idp1 | 1 | NULL| | idp2 | 1 | NULL| +--+-+-+ 2 rows in set (0.00 sec) And I query the IdP by this curl, I get all of the records from DB, curl -g -i -X GET http://127.0.0.1:35357/v3/OS- FEDERATION/identity_providers?id=idontexist -H "User-Agent: python- keystoneclient" -H "Accept: application/json" -H "X-Auth-Token: f74ac35177cb4720891a9cfed5ea1b9c" { "links": { "self": "http://10.239.48.36:35357/v3/OS-FEDERATION/identity_providers?id=idp1";, "previous": null, "next": null }, "identity_providers": [{ "remote_ids": [], "enabled": true, "id": "idp1", "links": { "self": "http://10.239.48.36:35357/v3/OS-FEDERATION/identity_providers/idp1";, "protocols": "http://10.239.48.36:35357/v3/OS-FEDERATION/identity_providers/idp1/protocols"; }, "description": null }, { "remote_ids": [], "enabled": true, "id": "idp2", "links": { "self": "http://10.239.48.36:35357/v3/OS-FEDERATION/identity_providers/idp2";, "protocols": "http://10.239.48.36:35357/v3/OS-FEDERATION/identity_providers/idp2/protocols"; }, "description": null }] } This feature should be supported since OSC depends on this to filter the DB records wanted. Noted: Open this bug since it's different with https://bugs.launchpad.net/python-openstackclient/+bug/1479837, they are two different things, and I think this more sound like a feature that keystone should support. ** Affects: keystone Importance: Undecided Assignee: Dave Chen (wei-d-chen) Status: New -- IdP doesn't support field based DB filtering https://bugs.launchpad.net/bugs/1525317 You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). -- 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 1525319] [NEW] Cisco apic router_id field length incorrectly changed for Mitaka
Public bug reported: Bug #1465678 was intended to be included in Liberty but it did not make it into the Liberty release. The neutron patch must be reverted and instead the field size change must be done in the vendor repo for the Mitaka release. ** Affects: networking-cisco Importance: Undecided Assignee: Henry Gessau (gessau) Status: New ** Affects: neutron Importance: Undecided Assignee: Henry Gessau (gessau) Status: In Progress ** Tags: cisco db ** Tags added: cisco ** Tags added: db ** Also affects: networking-cisco Importance: Undecided Status: New ** Changed in: neutron Assignee: (unassigned) => Henry Gessau (gessau) ** Changed in: networking-cisco Assignee: (unassigned) => Henry Gessau (gessau) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1525319 Title: Cisco apic router_id field length incorrectly changed for Mitaka Status in networking-cisco: New Status in neutron: In Progress Bug description: Bug #1465678 was intended to be included in Liberty but it did not make it into the Liberty release. The neutron patch must be reverted and instead the field size change must be done in the vendor repo for the Mitaka release. To manage notifications about this bug go to: https://bugs.launchpad.net/networking-cisco/+bug/1525319/+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 1525074] Re: test for submit
** Changed in: nova Status: New => Invalid -- 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/1525074 Title: test for submit Status in OpenStack Compute (nova): Invalid Bug description: just test for submit a bug report To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1525074/+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 1525309] [NEW] action_present and action_past attributes have to be deprecated in favor of action_present and action_past methods
Public bug reported: actions.BatchAction subclasses need to use action_present and action_past methodes and triger a deprecation warning when using attributes If we don't do so, attributes will ever come back and are not translatable. ** Affects: horizon Importance: Undecided Assignee: Yves-Gwenael Bourhis (yves-gwenael-bourhis) Status: 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/1525309 Title: action_present and action_past attributes have to be deprecated in favor of action_present and action_past methods Status in OpenStack Dashboard (Horizon): In Progress Bug description: actions.BatchAction subclasses need to use action_present and action_past methodes and triger a deprecation warning when using attributes If we don't do so, attributes will ever come back and are not translatable. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1525309/+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 1524476] Re: Compute API in Compute API Guide
** Changed in: openstack-manuals 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/1524476 Title: Compute API in Compute API Guide Status in OpenStack Compute (nova): Fix Released Status in openstack-manuals: Fix Released Bug description: The conf.py for the project has what I thought is the right configuration, but even so the Log a Bug link on the Compute API guide and the OpenStack SDK docs on developer.openstack.org are going to log bugs in OpenStack-manuals. Source link is correct, bug tag is correct, but the launchpad link is incorrect. --- Release: 2.1.0 on 2015-12-09 11:33 SHA: b5890b3c36613919338f83c4f59225f424c99cb1 Source: http://git.openstack.org/cgit/openstack/nova/tree/api-guide/source/index.rst URL: http://developer.openstack.org/api-guide/compute/ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1524476/+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 1525275] Re: Loading configuration items from keystoneauth is causing warnings
** Also affects: keystoneauth Importance: Undecided Status: New ** No longer affects: keystone -- 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/1525275 Title: Loading configuration items from keystoneauth is causing warnings Status in keystoneauth: New Bug description: Neutron uses the oslo-config-generator to automatically generate configuration files. Some configuration items are authentication items retrieved from keystone like 'domain-id', 'password' etc. These items are retrieved in https://github.com/openstack/neutron/blob/master/neutron/opts.py#L275. The following warnings are now been output when you run the tox target to generate config items (tox -e genconfig) or pep8 as it also generates the config files: /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option auth_type should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option auth_section should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option auth-url should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option default-domain-id should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option default-domain-name should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option domain-id should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option domain-name should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option password should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option project-domain-id should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option project-domain-name should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option project-id should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option project-name should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option tenant-id should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option tenant-name should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option trust-id should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option user-domain-id should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option user-domain-name should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option user-id should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option user-name should have a type derived from types.ConfigType instead of warnings.warn(msg) These warnings may
[Yahoo-eng-team] [Bug 1525295] [NEW] subnet listing is too slow with rbac
Public bug reported: subnet listing of 100 subnets takes about 2 seconds on a powerfull hardware. 60% of the time is consumed by the calculation of 'shared' attribute of the subnet which involves rbac rules. This makes horizon barely usable as number of networks grow. ** Affects: neutron Importance: Undecided Status: New ** Description changed: subnet listing of 100 subnets takes about 2 seconds on a powerfull hardware. - 60% of the time is consumed by the calculation of 'shared' attribute of the subnet. + 60% of the time is consumed by the calculation of 'shared' attribute of the subnet which involves rbac rules. This makes horizon barely usable as number of networks grow. -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1525295 Title: subnet listing is too slow with rbac Status in neutron: New Bug description: subnet listing of 100 subnets takes about 2 seconds on a powerfull hardware. 60% of the time is consumed by the calculation of 'shared' attribute of the subnet which involves rbac rules. This makes horizon barely usable as number of networks grow. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1525295/+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 1524476] Re: Compute API in Compute API Guide
Reviewed: https://review.openstack.org/255729 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=a54834df23e26f2255578dffb16fdac023fd495e Submitter: Jenkins Branch:master commit a54834df23e26f2255578dffb16fdac023fd495e Author: Andreas Jaeger Date: Thu Dec 10 09:34:04 2015 +0100 Report compute-api bugs against nova For compute-api set the launchpad project users report bugs against to "nova". Users can report bugs using the "bug icon" that will directly link to the launchpad project, it currently goes to "openstack-manuals" which is wrong for this content. This variable is used by openstackdocstheme 1.2.6. Closes-Bug: #1524476 Change-Id: I08ba11bb1c5388bc4611cea581274ac5d724c8d9 ** 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/1524476 Title: Compute API in Compute API Guide Status in OpenStack Compute (nova): Fix Released Status in openstack-manuals: In Progress Bug description: The conf.py for the project has what I thought is the right configuration, but even so the Log a Bug link on the Compute API guide and the OpenStack SDK docs on developer.openstack.org are going to log bugs in OpenStack-manuals. Source link is correct, bug tag is correct, but the launchpad link is incorrect. --- Release: 2.1.0 on 2015-12-09 11:33 SHA: b5890b3c36613919338f83c4f59225f424c99cb1 Source: http://git.openstack.org/cgit/openstack/nova/tree/api-guide/source/index.rst URL: http://developer.openstack.org/api-guide/compute/ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1524476/+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 1525282] [NEW] wrap_exception decorator does not grab arguments properly for decorated methods
Public bug reported: The wrap_exception decorator, which pulls the wrapped method arguments and sends a notification if there is an exception raised from the method, is not pulling the full list of arguments. This is because of a combination of relying on safe_utils.getcallargs which doesn't pull arguments when the called method uses *args or **kwargs and not using get_wrapped_function to get the call args for the decorated method. What is currently happening is getcallargs is passed a decorated method and pulls the argument list for the decorator, and most decorators are defined with *args and **kwargs. Instead get_wrapped_function should be called first and the result should be passed to getcallargs. ** Affects: nova Importance: Low Assignee: Andrew Laski (alaski) Status: In Progress -- 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/1525282 Title: wrap_exception decorator does not grab arguments properly for decorated methods Status in OpenStack Compute (nova): In Progress Bug description: The wrap_exception decorator, which pulls the wrapped method arguments and sends a notification if there is an exception raised from the method, is not pulling the full list of arguments. This is because of a combination of relying on safe_utils.getcallargs which doesn't pull arguments when the called method uses *args or **kwargs and not using get_wrapped_function to get the call args for the decorated method. What is currently happening is getcallargs is passed a decorated method and pulls the argument list for the decorator, and most decorators are defined with *args and **kwargs. Instead get_wrapped_function should be called first and the result should be passed to getcallargs. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1525282/+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 1489059] Re: "db type could not be determined" running py34
Reviewed: https://review.openstack.org/252164 Committed: https://git.openstack.org/cgit/openstack/tempest/commit/?id=768c80765717ce3c4ce224a35389b337c43591ef Submitter: Jenkins Branch:master commit 768c80765717ce3c4ce224a35389b337c43591ef Author: lvdongbing Date: Tue Dec 1 22:38:57 2015 -0500 Put py34 first in the env order of tox To solve the problem of "db type could not be determined" on py34 we have to run first the py34 env to, then, run py27. This patch puts py34 first in the tox.ini list of envs to avoid this problem to happen. Closes-bug: #1489059 Change-Id: Ia11ecf7bd147e35b7c8ad3db0eaad17f893e78ba ** Changed in: tempest 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/1489059 Title: "db type could not be determined" running py34 Status in Aodh: Fix Released Status in Barbican: Fix Released Status in cloudkitty: Fix Committed Status in Glance: Fix Committed Status in glance_store: Fix Committed Status in heat: Fix Released Status in OpenStack Dashboard (Horizon): In Progress Status in Ironic: Fix Released Status in ironic-lib: In Progress Status in OpenStack Identity (keystone): Fix Committed Status in keystoneauth: Fix Released Status in keystonemiddleware: Fix Committed Status in Manila: Fix Released Status in networking-midonet: In Progress Status in networking-ofagent: New Status in neutron: Fix Released Status in python-glanceclient: Fix Released Status in python-keystoneclient: Fix Committed Status in Sahara: Fix Released Status in senlin: Fix Committed Status in tap-as-a-service: New Status in tempest: Fix Released Status in zaqar: In Progress Bug description: When running tox for the first time, the py34 execution fails with an error saying "db type could not be determined". This issue is know to be caused when the run of py27 preceeds py34 and can be solved erasing the .testrepository and running "tox -e py34" first of all. To manage notifications about this bug go to: https://bugs.launchpad.net/aodh/+bug/1489059/+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 1525279] [NEW] Request Liberty release for networking-bgpvpn
Public bug reported: The networking-bgpvpn project is now ready to have its first release. We'd like to create a dedicated branch to backport needed patches in the future. Release Info : Current branch : master Commit-Id : 157f73d3f248f1e1008e1e7f908dd616762325bc New Tag: 3.0.0 ** Affects: bgpvpn Importance: Undecided Status: New ** Affects: neutron Importance: Undecided Status: New ** Tags: release-subproject ** Also 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/1525279 Title: Request Liberty release for networking-bgpvpn Status in bgpvpn: New Status in neutron: New Bug description: The networking-bgpvpn project is now ready to have its first release. We'd like to create a dedicated branch to backport needed patches in the future. Release Info : Current branch : master Commit-Id : 157f73d3f248f1e1008e1e7f908dd616762325bc New Tag: 3.0.0 To manage notifications about this bug go to: https://bugs.launchpad.net/bgpvpn/+bug/1525279/+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 1525275] [NEW] Loading configuration items from keystoneauth is causing warnings
Public bug reported: Neutron uses the oslo-config-generator to automatically generate configuration files. Some configuration items are authentication items retrieved from keystone like 'domain-id', 'password' etc. These items are retrieved in https://github.com/openstack/neutron/blob/master/neutron/opts.py#L275. The following warnings are now been output when you run the tox target to generate config items (tox -e genconfig) or pep8 as it also generates the config files: /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option auth_type should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option auth_section should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option auth-url should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option default-domain-id should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option default-domain-name should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option domain-id should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option domain-name should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option password should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option project-domain-id should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option project-domain-name should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option project-id should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option project-name should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option tenant-id should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option tenant-name should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option trust-id should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option user-domain-id should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option user-domain-name should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option user-id should have a type derived from types.ConfigType instead of warnings.warn(msg) /opt/stack/neutron/.tox/pep8/local/lib/python2.7/site-packages/oslo_config/generator.py:204: UserWarning: Option user-name should have a type derived from types.ConfigType instead of warnings.warn(msg) These warnings may have been introduced with the following change: https://github.com/openstack/neutron/commit/a37e11f637b21785307e14e9725de3db14a1d37b ** Affects: keystone Importance: Undecided Status: New ** Description changed: Neutron uses the oslo-config-generator to automatically generate configuration files. Some configuration items are authentication items retrieved from keystone like 'domain-id', 'password' etc. These items are retrieved in https://github.com/openstack/neutron/blob/mast
[Yahoo-eng-team] [Bug 1525259] [NEW] Add request_ids attribute to v2 schemas
Public bug reported: We are adding support for returning ‘x-openstack-request-id’ to the caller as per the design proposed in cross-project specs: http://specs.openstack.org/openstack/openstack-specs/specs/return-request-id.html Problem Description: Cannot add a new property of list type to the warlock.model object. The requirement we are trying to meet is to make the request id available to the user of the client library [3]. The user typically doesn't have access to the headers, so the request id needs to be part of the payload returned from each method. In other clients that work with simple data types, we've subclassed dict, list, etc. to add the extra property. This adds the request id to the return value without making a breaking change to the API of the client library. How is a model object created: Let’s take an example of glanceclient.api.v2.images.get() call [1]: Here after getting the response we call model() method. This model() does the job of creating a warlock.model object(essentially a dict) based on the schema given as argument (image schema retrieved from glance in this case). Inside model() the raw() method simply return the image schema as JSON object. The advantage of this warlock.model object over a simple dict is that it validates any changes to object based on the rules specified in the reference schema. The keys of this model object are available as object properties to the caller. Underlying reason: The schema for different sub APIs is returned a bit differently. For images, metadef APIs glance.schema.Schema.raw() is used which returns a schema containing “additionalProperties”: {“type”: “string”}. Whereas for members and tasks APIs glance.schema.Schema.minimal() is used to return schema object which does not contain “additionalProperties”. So we can add extra properties of any type to the model object returned from members or tasks API but for images and metadef APIs we can only add properties which can be of type string. Also for the latter case we depend on the glance configuration to allow additional properties. As per our analysis we have come up with two approaches for resolving this issue: Approach #1: Inject request_ids property in the warlock model object in glance client Here we do the following: 1. Inject the ‘request_ids’ as additional property into the model object(returned from model()) 2. Return the model object which now contains request_ids property Limitations: 1. Because the glance schemas for images and metadef only allows additional properties of type string, so even though natural type of request_ids should be list we have to make it as a comma separated ‘string’ of request ids as a compromise. 2. Lot of extra code is needed to wrap objects returned from the client API so that the caller can get request ids. For example we need to write wrapper classes for dict, list, str, tuple, generator. 3. Not a good design as we are adding a property which should actually be a base property but added as additional property as a compromise. 4. There is a dependency on glance whether to allow custom/additional properties or not. [2] Approach #2: Add ‘request_ids’ property to all schema definitions in glance Here we add ‘request_ids’ property as follows to the various APIs (schema): “request_ids”: { "type": "array", "items": { "type": "string" } } Doing this will make changes in glance client very simple as compared to approach#1. This also looks a better design as it will be consistent. We simply need to modify the request_ids property in various API calls for example glanceclient.v2.images.get(). [1] https://github.com/openstack/python-glanceclient/blob/master/glanceclient/v2/images.py#L179 [2] https://github.com/openstack/glance/blob/master/glance/api/v2/images.py#L944 [3] http://specs.openstack.org/openstack/openstack-specs/specs/return-request-id.html ** Affects: glance Importance: Wishlist Assignee: Abhishek Kekane (abhishek-kekane) Status: New ** Tags: lite-spec -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1525259 Title: Add request_ids attribute to v2 schemas Status in Glance: New Bug description: We are adding support for returning ‘x-openstack-request-id’ to the caller as per the design proposed in cross-project specs: http://specs.openstack.org/openstack/openstack-specs/specs/return-request-id.html Problem Description: Cannot add a new property of list type to the warlock.model object. The requirement we are trying to meet is to make the request id available to the user of the client library [3]. The user typically doesn't have access to the headers, so the request id needs to be part of the payload returned from each method. In other clients that work with simple data types, we've subclassed dict, list, etc. to add the extra property. This adds the
[Yahoo-eng-team] [Bug 1524418] Re: gate-grenade-dsvm-multinode fails with "AttributeError: 'LocalManager' object has no attribute 'l3driver'"
This was not a Nova problem ** Changed in: nova Status: Confirmed => Invalid -- 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/1524418 Title: gate-grenade-dsvm-multinode fails with "AttributeError: 'LocalManager' object has no attribute 'l3driver'" Status in OpenStack Compute (nova): Invalid Status in oslo.messaging: Fix Released Bug description: Seen here: http://logs.openstack.org/38/249138/9/check/gate-grenade-dsvm- multinode/5b991dc/logs/new/screen-n-api.txt.gz?level=TRACE 2015-12-09 12:44:56.998 ERROR nova.api.openstack.extensions [req-e2625ff8-3f5c-494c-8d84-a91d6d9c862b cinder_grenade cinder_grenade] Unexpected exception in API method 2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions Traceback (most recent call last): 2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions File "/opt/stack/new/nova/nova/api/openstack/extensions.py", line 478, in wrapped 2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions return f(*args, **kwargs) 2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions File "/opt/stack/new/nova/nova/api/validation/__init__.py", line 73, in wrapper 2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions return func(*args, **kwargs) 2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions File "/opt/stack/new/nova/nova/api/openstack/compute/floating_ips.py", line 291, in _remove_floating_ip 2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions disassociate_floating_ip(self, context, instance, address) 2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions File "/opt/stack/new/nova/nova/api/openstack/compute/floating_ips.py", line 79, in disassociate_floating_ip 2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions self.network_api.disassociate_floating_ip(context, instance, address) 2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions File "/opt/stack/new/nova/nova/network/api.py", line 49, in wrapped 2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions return func(self, context, *args, **kwargs) 2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions File "/opt/stack/new/nova/nova/network/base_api.py", line 77, in wrapper 2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions res = f(self, context, *args, **kwargs) 2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions File "/opt/stack/new/nova/nova/network/api.py", line 240, in disassociate_floating_ip 2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions affect_auto_assigned) 2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions File "/opt/stack/new/nova/nova/utils.py", line 1100, in wrapper 2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions return func(*args, **kwargs) 2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/server.py", line 150, in inner 2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions return func(*args, **kwargs) 2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions File "/opt/stack/new/nova/nova/network/floating_ips.py", line 456, in disassociate_floating_ip 2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions fixed_ip.instance_uuid) 2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions File "/opt/stack/new/nova/nova/network/floating_ips.py", line 490, in _disassociate_floating_ip 2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions do_disassociate() 2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions File "/usr/local/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py", line 271, in inner 2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions return f(*args, **kwargs) 2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions File "/opt/stack/new/nova/nova/network/floating_ips.py", line 483, in do_disassociate 2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions self.l3driver.remove_floating_ip(address, fixed.address, 2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions AttributeError: 'LocalManager' object has no attribute 'l3driver' 2015-12-09 12:44:56.998 15804 ERROR nova.api.openstack.extensions Started in the last 24 hours: http://logstash.openstack.org/#dashboard/file/logstash.json?query=message:%5C%22AttributeError:%20'LocalManager'%20object%20has%20no%20attribute%20'l3driver'%5C%22%20AND%20tags:%5C%22screen-n-api.txt%5C%22 Thinking it's something in oslo.messaging 3.1.0 that was merged into upper-constraints on 12/8: https://review.openstack.org/#/c/254571/ To manage no
[Yahoo-eng-team] [Bug 1525250] [NEW] Failure when federated user name contains non ascii characters
Public bug reported: When logging in with openid-connect, I get '{"error": {"message": "An unexpected error prevented the server from fulfilling your request: 'ascii' codec can't decode byte 0xc3 in position 5: ordinal not in range(128) (Disable debug mode to suppress these details.)", "code": 500, "title": "Internal Server Error"}}' My name has an 'å'. I suspect there is a connection. Coincidentally(?), if I do the following in python shell: >>> unicode('Jon Kåre Hellan') I get 'UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 5: ordinal not in range(128)' This is on liberty, using federation in contrib. On master, federation has been moved up from contrib, but I couldn't see any code changes that would help. Stack trace: Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/keystone/common/wsgi.py", line 248, in __call__ result = method(context, **params) File "/usr/lib/python2.7/site-packages/keystone/contrib/federation/controllers.py", line 315, in federated_sso_auth protocol_id) File "/usr/lib/python2.7/site-packages/keystone/contrib/federation/controllers.py", line 297, in federated_authentication return self.authenticate_for_token(context, auth=auth) File "/usr/lib/python2.7/site-packages/keystone/auth/controllers.py", line 385, in authenticate_for_token self.authenticate(context, auth_info, auth_context) File "/usr/lib/python2.7/site-packages/keystone/auth/controllers.py", line 510, in authenticate auth_context) File "/usr/lib/python2.7/site-packages/keystone/auth/plugins/mapped.py", line 69, in authenticate self.identity_api) File "/usr/lib/python2.7/site-packages/keystone/auth/plugins/mapped.py", line 144, in handle_unscoped_token federation_api, identity_api) File "/usr/lib/python2.7/site-packages/keystone/auth/plugins/mapped.py", line 188, in apply_mapping_filter identity_provider, protocol, assertion) File "/usr/lib/python2.7/site-packages/keystone/contrib/federation/core.py", line 90, in evaluate mapped_properties = rule_processor.process(assertion_data) File "/usr/lib/python2.7/site-packages/keystone/contrib/federation/utils.py", line 470, in process new_local = self._update_local_mapping(local, direct_maps) File "/usr/lib/python2.7/site-packages/keystone/contrib/federation/utils.py", line 611, in _update_local_mapping new_value = self._update_local_mapping(v, direct_maps) File "/usr/lib/python2.7/site-packages/keystone/contrib/federation/utils.py", line 613, in _update_local_mapping new_value = v.format(*direct_maps) UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 5: ordinal not in range(128) ** Affects: keystone Importance: Undecided Status: New -- 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/1525250 Title: Failure when federated user name contains non ascii characters Status in OpenStack Identity (keystone): New Bug description: When logging in with openid-connect, I get '{"error": {"message": "An unexpected error prevented the server from fulfilling your request: 'ascii' codec can't decode byte 0xc3 in position 5: ordinal not in range(128) (Disable debug mode to suppress these details.)", "code": 500, "title": "Internal Server Error"}}' My name has an 'å'. I suspect there is a connection. Coincidentally(?), if I do the following in python shell: >>> unicode('Jon Kåre Hellan') I get 'UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 5: ordinal not in range(128)' This is on liberty, using federation in contrib. On master, federation has been moved up from contrib, but I couldn't see any code changes that would help. Stack trace: Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/keystone/common/wsgi.py", line 248, in __call__ result = method(context, **params) File "/usr/lib/python2.7/site-packages/keystone/contrib/federation/controllers.py", line 315, in federated_sso_auth protocol_id) File "/usr/lib/python2.7/site-packages/keystone/contrib/federation/controllers.py", line 297, in federated_authentication return self.authenticate_for_token(context, auth=auth) File "/usr/lib/python2.7/site-packages/keystone/auth/controllers.py", line 385, in authenticate_for_token self.authenticate(context, auth_info, auth_context) File "/usr/lib/python2.7/site-packages/keystone/auth/controllers.py", line 510, in authenticate auth_context) File "/usr/lib/python2.7/site-packages/keystone/auth/plugins/mapped.py", line 69, in authenticate self.identity_api) File "/usr/lib/python2.7/site-packages/keystone/auth/plugins/mapped.py", line 144, in handle_unscoped_token federation_api, identity_api) File "/usr/lib/python2.7/site-packages/keystone/a
[Yahoo-eng-team] [Bug 1456439] Re: Disable Disassociate Floating IP to an instance in error state
*** This bug is a duplicate of bug 1441088 *** https://bugs.launchpad.net/bugs/1441088 ** This bug has been marked a duplicate of bug 1441088 hide disassociate floating ip when no floating ip attached -- 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/1456439 Title: Disable Disassociate Floating IP to an instance in error state Status in OpenStack Dashboard (Horizon): In Progress Bug description: "Disassociate Floating IP" button should be disabled for instances in error state. As per the following bug, it has disabled only Associate Floating IP. https://bugs.launchpad.net/horizon/+bug/1374576 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1456439/+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 1525226] [NEW] Write an integration test for joint behavior of inline cell edit & confirmation of entity deletion
Public bug reported: While fix bug 1481850 keeps entity names shown in Confirm Delete/whatever modal dialog up to date, we should provide a test for this regression. Since it's very hard to write a simple python/js unit test on a border of python and js functionality (see the fix at https://review.openstack.org/256362), the simplest approach is to test this by means of Selenium integration tests. The natural candidate here is Identity->Projects table, since it was the table the original bug was filed for. ** Affects: horizon Importance: Wishlist Status: New ** Tags: integration-tests ** Description changed: While fix bug 1481850 keeps entity names shown in Confirm Delete/whatever modal dialog up to date, we should provide a test for this regression. Since it's very hard to write a simple python/js unit test on a border of python and js functionality (see the fix at https://review.openstack.org/256362), the simplest approach is to test this by means of Selenium integration tests. + + The natural candidate here is Identity->Projects table, since it was the + table the original bug was filed for. -- 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/1525226 Title: Write an integration test for joint behavior of inline cell edit & confirmation of entity deletion Status in OpenStack Dashboard (Horizon): New Bug description: While fix bug 1481850 keeps entity names shown in Confirm Delete/whatever modal dialog up to date, we should provide a test for this regression. Since it's very hard to write a simple python/js unit test on a border of python and js functionality (see the fix at https://review.openstack.org/256362), the simplest approach is to test this by means of Selenium integration tests. The natural candidate here is Identity->Projects table, since it was the table the original bug was filed for. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1525226/+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 1509121] Re: [UI] job_binaries Exception Value: too many values to unpack
** 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/1509121 Title: [UI] job_binaries Exception Value: too many values to unpack Status in OpenStack Dashboard (Horizon): New Status in Sahara: Fix Released Bug description: I accidentally created a Sahara EDP Job Binary, in RDO Kilo, with the following properties: Name Binary ID c1fa1a5b-2458-43cc-9fbc-52a54fe74009 URL swift://swift://container.sahara/Test-Private-Container/ Description None When I try to "Delete the Job Binary" the Dashboard displays a full- page exception. Here is the Traceback: Environment: Request Method: POST Request URL: https://my.org/dashboard/project/data_processing/job_binaries/ Django Version: 1.8.3 Python Version: 2.7.5 Installed Applications: ['openstack_dashboard.dashboards.project', 'openstack_dashboard.dashboards.admin', 'openstack_dashboard.dashboards.identity', 'openstack_dashboard.dashboards.settings', 'openstack_dashboard', 'django.contrib.contenttypes', 'django.contrib.auth', 'django.contrib.sessions', 'django.contrib.messages', 'django.contrib.staticfiles', 'django.contrib.humanize', 'django_pyscss', 'openstack_dashboard.django_pyscss_fix', 'compressor', 'horizon', 'openstack_auth'] Installed Middleware: ('django.middleware.common.CommonMiddleware', 'django.middleware.csrf.CsrfViewMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', 'django.contrib.messages.middleware.MessageMiddleware', 'django.contrib.auth.middleware.SessionAuthenticationMiddleware', 'horizon.middleware.HorizonMiddleware', 'django.middleware.locale.LocaleMiddleware', 'django.middleware.clickjacking.XFrameOptionsMiddleware') Traceback: File "/usr/lib/python2.7/site-packages/django/core/handlers/base.py" in get_response 132. response = wrapped_callback(request, *callback_args, **callback_kwargs) File "/usr/lib/python2.7/site-packages/horizon/decorators.py" in dec 36. return view_func(request, *args, **kwargs) File "/usr/lib/python2.7/site-packages/horizon/decorators.py" in dec 52. return view_func(request, *args, **kwargs) File "/usr/lib/python2.7/site-packages/horizon/decorators.py" in dec 36. return view_func(request, *args, **kwargs) File "/usr/lib/python2.7/site-packages/horizon/decorators.py" in dec 84. return view_func(request, *args, **kwargs) File "/usr/lib/python2.7/site-packages/django/views/generic/base.py" in view 71. return self.dispatch(request, *args, **kwargs) File "/usr/lib/python2.7/site-packages/django/views/generic/base.py" in dispatch 89. return handler(request, *args, **kwargs) File "/usr/lib/python2.7/site-packages/horizon/tables/views.py" in post 223. return self.get(request, *args, **kwargs) File "/usr/lib/python2.7/site-packages/horizon/tables/views.py" in get 159. handled = self.construct_tables() File "/usr/lib/python2.7/site-packages/horizon/tables/views.py" in construct_tables 150. handled = self.handle_table(table) File "/usr/lib/python2.7/site-packages/horizon/tables/views.py" in handle_table 125. handled = self._tables[name].maybe_handle() File "/usr/lib/python2.7/site-packages/horizon/tables/base.py" in maybe_handle 1640. return self.take_action(action_name, obj_id) File "/usr/lib/python2.7/site-packages/horizon/tables/base.py" in take_action 1482. response = action.multiple(self, self.request, obj_ids) File "/usr/lib/python2.7/site-packages/horizon/tables/actions.py" in multiple 302. return self.handle(data_table, request, object_ids) File "/usr/lib/python2.7/site-packages/horizon/tables/actions.py" in handle 827. exceptions.handle(request, ignore=ignore) File "/usr/lib/python2.7/site-packages/horizon/exceptions.py" in handle 364. six.reraise(exc_type, exc_value, exc_traceback) File "/usr/lib/python2.7/site-packages/horizon/tables/actions.py" in handle 811. self.action(request, datum_id) File "/usr/lib/python2.7/site-packages/horizon/tables/actions.py" in action 926. return self.delete(request, obj_id) File "/usr/share/openstack-dashboard/openstack_dashboard/wsgi/../../openstack_dashboard/dashboards/project/data_processing/job_binaries/tables.py" in delete 56. (jb_type, jb_internal_id) = jb.url.split("://") Exception Type: ValueError at /project/data_processing/job_binaries/ Exception Value: too many values to unpack To manage notifications about this bug go to: https://b
[Yahoo-eng-team] [Bug 1525219] [NEW] Trust-scoped user requests failed while using fernet tokens
Public bug reported: 1. Enable reauthentication in heat: add reauthentication_auth_method = trusts in heat.conf 2. Enable fernet tokens in keystone. 3. Create stack with the following template: heat_template_version: 2013-05-23 parameters: key_name: type: string default: default flavor: type: string default: m1.tiny image: type: string default: fedora-heat-test-image resources: server: type: OS::Nova::Server properties: image: {get_param: image} flavor: {get_param: flavor} heat stack-create abc -f Creation stack failed. Found this in heat logs: 2015-12-11 14:56:52.992 INFO heat.engine.resource [-] CREATE: Server "server" Stack "abc" [b1957493-41b6-437d-87af-64ebe166e6dd] 2015-12-11 14:56:52.992 TRACE heat.engine.resource Traceback (most recent call last): 2015-12-11 14:56:52.992 TRACE heat.engine.resource File "/opt/stack/heat/heat/engine/resource.py", line 636, in _action_recorder 2015-12-11 14:56:52.992 TRACE heat.engine.resource yield 2015-12-11 14:56:52.992 TRACE heat.engine.resource File "/opt/stack/heat/heat/engine/resource.py", line 703, in _do_action 2015-12-11 14:56:52.992 TRACE heat.engine.resource pre_func() 2015-12-11 14:56:52.992 TRACE heat.engine.resource File "/opt/stack/heat/heat/engine/properties.py", line 410, in validate 2015-12-11 14:56:52.992 TRACE heat.engine.resource message=ex.error_message 2015-12-11 14:56:52.992 TRACE heat.engine.resource StackValidationFailed: Property error: server.Properties.image: Error retrieving image list from glance: 503 Service Unavailable: The server is currently unavailable. Please try again at a later time. (HTTP 503) Found in glance log: 380cf351a6a29fbe971e3a1b32" -H "User-Agent: python-keystoneclient" -H "Accept: application/json" -H "X-Auth-Token: {SHA1}15a31c1b48e559620d731e3756fb882eb3796ef3" from (pid=3209) _http_log_request /usr/local/lib/python2.7/dist-packages/keystoneclient/session.py:198 2015-12-11 14:56:52.987 DEBUG keystoneclient.session [-] RESP: [403] Content-Length: 131 Vary: X-Auth-Token Keep-Alive: timeout=5, max=99 Server: Apache/2.4.7 (Ubuntu) Connection: Keep-Alive Date: Fri, 11 Dec 2015 12:56:52 GMT Content-Type: application/json x-openstack-request-id: req-cb5a4c23-85fc-4e02-a7d6-e138ae7f6ff8 RESP BODY: {"error": {"message": "User is not a trustee. (Disable debug mode to suppress these details.)", "code": 403, "title": "Forbidden"}} from (pid=3209) _http_log_response /usr/local/lib/python2.7/dist-packages/keystoneclient/session.py:216 2015-12-11 14:56:52.987 DEBUG keystoneclient.session [-] Request returned failure status: 403 from (pid=3209) request /usr/local/lib/python2.7/dist-packages/keystoneclient/session.py:401 2015-12-11 14:56:52.989 ERROR keystonemiddleware.auth_token [-] Bad response code while validating token: 403 2015-12-11 14:56:52.989 WARNING keystonemiddleware.auth_token [-] Identity response: {"error": {"message": "User is not a trustee. (Disable debug mode to suppress these details.)", "code": 403, "title": "Forbidden"}} 2015-12-11 14:56:52.989 CRITICAL keystonemiddleware.auth_token [-] Unable to validate token: Failed to fetch token data from identity server Keystone logs: 2015-12-11 14:56:52.975204 10268 DEBUG keystone.middleware.auth [req-cb5a4c23-85fc-4e02-a7d6-e138ae7f6ff8 be1cc1b5290a4e8c9e54abea7d247d77 4eb9350e276f49ddbea4c7d2e6f0a013 - default default] RBAC: auth_context: {'is_delegated_auth': False, 'access_token_id': None, 'user_id': u'be1cc1b5290a4e8c9e54abea7d247d77', 'roles': [u'service'], 'user_domain_id': u'default', 'trustee_id': None, 'trustor_id': None, 'consumer_id': None, 'token': , 'project_id': u'4eb9350e276f49ddbea4c7d2e6f0a013', 'trust_id': None, 'project_domain_id': u'default'} process_request /opt/stack/keystone/keystone/middleware/auth.py:187 2015-12-11 14:56:52.975976 10268 INFO keystone.common.wsgi [req-cb5a4c23-85fc-4e02-a7d6-e138ae7f6ff8 be1cc1b5290a4e8c9e54abea7d247d77 4eb9350e276f49ddbea4c7d2e6f0a013 - default default] GET http://192.168.122.82:35357/v3/auth/tokens 2015-12-11 14:56:52.976121 10268 DEBUG keystone.common.controller [req-cb5a4c23-85fc-4e02-a7d6-e138ae7f6ff8 be1cc1b5290a4e8c9e54abea7d247d77 4eb9350e276f49ddbea4c7d2e6f0a013 - default default] RBAC: Authorizing identity:validate_token() _build_policy_check_credentials /opt/stack/keystone/keystone/common/controller.py:62 2015-12-11 14:56:52.976227 10268 DEBUG keystone.common.controller [req-cb5a4c23-85fc-4e02-a7d6-e138ae7f6ff8 be1cc1b5290a4e8c9e54abea7d247d77 4eb9350e276f49ddbea4c7d2e6f0a013 - default default] RBAC: using auth context from the request environment _build_policy_check_credentials /opt/stack/keystone/keystone/common/controller.py:67 2015-12-11 14:56:52.976640 10268 WARNING keystone.token.providers.fernet.utils [req-cb5a4c23-85fc-4e02-a7d6-e138ae7f6ff8 be1cc1b5290a4e8c9e54abea7d247d77 4eb9350e276f49ddbea4c7d2e6f0a013 - default default] [fernet_tokens] key_repository is world read
[Yahoo-eng-team] [Bug 1525209] [NEW] Windows interface polling manager doesn't use ovsdb client monitor
Public bug reported: In Linux the OVS agent uses the class InterfacePollingMinimizer that notifies the agent when a new port is plugged or unplugged and passes the related events (port added or deleted). For Windows it uses the class AlwaysPoll that doesn't notify any specific event, it returns always true. The OVS agent in Windows is forced to rescan the devices currently in the machine to infer which were added. This is because the current Windows implementation of the interface polling manager doesn't use ovsdb client monitor. Fix this by using ovsdb client monitor also for Windows and make sure that the events are passed correctly to the OVS agent. ** Affects: neutron Importance: Undecided Assignee: Sayali Lunkad (sayalilunkad) Status: In Progress ** Changed in: neutron Assignee: (unassigned) => Sayali Lunkad (sayalilunkad) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1525209 Title: Windows interface polling manager doesn't use ovsdb client monitor Status in neutron: In Progress Bug description: In Linux the OVS agent uses the class InterfacePollingMinimizer that notifies the agent when a new port is plugged or unplugged and passes the related events (port added or deleted). For Windows it uses the class AlwaysPoll that doesn't notify any specific event, it returns always true. The OVS agent in Windows is forced to rescan the devices currently in the machine to infer which were added. This is because the current Windows implementation of the interface polling manager doesn't use ovsdb client monitor. Fix this by using ovsdb client monitor also for Windows and make sure that the events are passed correctly to the OVS agent. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1525209/+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 1525196] [NEW] change default policy for password and resetstate
Public bug reported: all cases from devstack, git head commit 4474dce9e6b847a7691fc3f01d0c594061570d73 I created an instance with admin tenant then use set-password with demo user, it make the instance ERROR this kind of operations should not disabled by default jichen@devstack1:~$ export OS_USERNAME=demo jichen@devstack1:~$ nova set-password t5 New password: Again: ERROR (Conflict): Failed to set admin password on d3485187-779c-441f-8394-4e3d31234a9f because error setting admin password (HTTP 409) (Request-ID: req-96b69164-e353-44f8-82a1-ecd20200173b) jichen@devstack1:~$ nova list +--+--+++-+---+ | ID | Name | Status | Task State | Power State | Networks | +--+--+++-+---+ | d3485187-779c-441f-8394-4e3d31234a9f | t5 | ERROR | - | Running | private=10.0.0.10 | +--+--+++-+---+ Also, after the instance become ERROR state, I can't change it to ACTIVE state even if I am the owner of the instance jichen@devstack1:~$ nova list +--++-++-+--+ | ID | Name | Status | Task State | Power State | Networks | +--++-++-+--+ | 380e55e3-9726-4928-a44c-a206bc656f48 | t2 | ERROR | - | Running | private=10.0.0.8 | | c426c3d0-a981-4839-969a-50d828e05459 | t4 é | SHUTOFF | - | Shutdown| private=10.0.0.2 || +--++-++-+--+ jichen@devstack1:~$ nova reset-state --active t2 Reset state for server t2 failed: Policy doesn't allow os_compute_api:os-admin-actions:reset_state to be performed. (HTTP 403) (Request-ID: req-e7669a3c-3075-4a63-a7a6-f646013a5428) ERROR (CommandError): Unable to reset the state for the specified server(s) ** Affects: nova Importance: Undecided Assignee: jichenjc (jichenjc) Status: New ** Changed in: nova Assignee: (unassigned) => jichenjc (jichenjc) -- 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/1525196 Title: change default policy for password and resetstate Status in OpenStack Compute (nova): New Bug description: all cases from devstack, git head commit 4474dce9e6b847a7691fc3f01d0c594061570d73 I created an instance with admin tenant then use set-password with demo user, it make the instance ERROR this kind of operations should not disabled by default jichen@devstack1:~$ export OS_USERNAME=demo jichen@devstack1:~$ nova set-password t5 New password: Again: ERROR (Conflict): Failed to set admin password on d3485187-779c-441f-8394-4e3d31234a9f because error setting admin password (HTTP 409) (Request-ID: req-96b69164-e353-44f8-82a1-ecd20200173b) jichen@devstack1:~$ nova list +--+--+++-+---+ | ID | Name | Status | Task State | Power State | Networks | +--+--+++-+---+ | d3485187-779c-441f-8394-4e3d31234a9f | t5 | ERROR | - | Running | private=10.0.0.10 | +--+--+++-+---+ Also, after the instance become ERROR state, I can't change it to ACTIVE state even if I am the owner of the instance jichen@devstack1:~$ nova list +--++-++-+--+ | ID | Name | Status | Task State | Power State | Networks | +--++-++-+--+ | 380e55e3-9726-4928-a44c-a206bc656f48 | t2 | ERROR | - | Running | private=10.0.0.8 | | c426c3d0-a981-4839-969a-50d828e05459 | t4 é | SHUTOFF | - | Shutdown| private=10.0.0.2 || +--++-++-+--+ jichen@devstack1:~$ nova reset-state --active t2 Reset state for server t2 failed: Policy doesn't allow os_compute_api:os-admin-actions:reset_state to be performed. (HTTP 403) (Request-ID: req-e7669a3c-3075-4a63-a7a6-f646013a5428) ERROR (CommandError): Unable to reset the state for the specified server(s) To manage notifications about this bug go to: http
[Yahoo-eng-team] [Bug 1525002] Re: The ironic driver needs to scale back how many errors it traces out
Actually it's even more interesting: traceback comes from ironic as part of message instead of details. Investigating on... ** Also affects: ironic Importance: Undecided Status: New ** Changed in: ironic Status: New => Confirmed ** Changed in: ironic Importance: Undecided => Low ** Changed in: ironic Assignee: (unassigned) => Dmitry Tantsur (divius) -- 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/1525002 Title: The ironic driver needs to scale back how many errors it traces out Status in Ironic: Confirmed Status in OpenStack Compute (nova): Confirmed Status in python-ironicclient: Triaged Bug description: The amount of tracing in this n-cpu log is a bit much: http://logs.openstack.org/93/255793/3/gate/gate-tempest-dsvm-ironic- agent_ssh/25175ed/logs/screen-n-cpu.txt.gz?level=TRACE Like these warnings: http://logs.openstack.org/93/255793/3/gate/gate-tempest-dsvm-ironic- agent_ssh/25175ed/logs/screen-n-cpu.txt.gz?level=TRACE#_2015-12-10_16_11_48_799 2015-12-10 16:11:48.798 WARNING ironicclient.common.http [req-94077ab9-5adf-4720-9fb8-2e027dde9b72 tempest-BaremetalBasicOps-1285004585 tempest-BaremetalBasicOps-1966762451] Request returned failure status. 2015-12-10 16:11:48.799 WARNING ironicclient.common.http [req-94077ab9-5adf-4720-9fb8-2e027dde9b72 tempest-BaremetalBasicOps-1285004585 tempest-BaremetalBasicOps-1966762451] Error contacting Ironic server: Node 1 is locked by host localhost, please retry after the current operation is completed. Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/server.py", line 150, in inner return func(*args, **kwargs) File "/opt/stack/new/ironic/ironic/conductor/manager.py", line 1519, in update_port purpose='port update') as task: File "/opt/stack/new/ironic/ironic/conductor/task_manager.py", line 152, in acquire driver_name=driver_name, purpose=purpose) File "/opt/stack/new/ironic/ironic/conductor/task_manager.py", line 222, in __init__ self.release_resources() File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 204, in __exit__ six.reraise(self.type_, self.value, self.tb) File "/opt/stack/new/ironic/ironic/conductor/task_manager.py", line 203, in __init__ self._lock() File "/opt/stack/new/ironic/ironic/conductor/task_manager.py", line 243, in _lock reserve_node() File "/usr/local/lib/python2.7/dist-packages/retrying.py", line 49, in wrapped_f return Retrying(*dargs, **dkw).call(f, *args, **kw) File "/usr/local/lib/python2.7/dist-packages/retrying.py", line 212, in call raise attempt.get() File "/usr/local/lib/python2.7/dist-packages/retrying.py", line 247, in get six.reraise(self.value[0], self.value[1], self.value[2]) File "/usr/local/lib/python2.7/dist-packages/retrying.py", line 200, in call attempt = Attempt(fn(*args, **kwargs), attempt_number, False) File "/opt/stack/new/ironic/ironic/conductor/task_manager.py", line 236, in reserve_node self.node_id) File "/opt/stack/new/ironic/ironic/objects/node.py", line 260, in reserve db_node = cls.dbapi.reserve_node(tag, node_id) File "/opt/stack/new/ironic/ironic/db/sqlalchemy/api.py", line 226, in reserve_node host=node['reservation']) NodeLocked: Node 1 is locked by host localhost, please retry after the current operation is completed. (HTTP 409). Attempt 1 of 61 To manage notifications about this bug go to: https://bugs.launchpad.net/ironic/+bug/1525002/+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 1525163] [NEW] add-router-interface can not recover when failing create_port_post_commit
Public bug reported: When the following situation, a port created that no one can delete it: 1. Configure ML2 plugin. 2. Execute router-interface-add with subnet_id and failed in create_port_post_commit After that, undeletable port is created. Even if the admin tries to delete the port, he cannot delete it. case1: delete-port with port_id => Port {port_id} cannot be deleted directly via the port API: has device owner network:router_interface. case2: router-interface-delete with subnet_id or port_id => Router {router_id} has no interface on subnet {subnet_id} => Router {router_id} does not have an interface with id {port_id} [How to fix] create_port_post_commit has a recovery process. When failed, then calls delete_port. However, in this case, 'device_owner' and 'device_id' have already registered at port's DB. Therefore, delete_port fails due to device_owner check. Hence, I'll add 'l3_port_check=False' into delete_port's argument. [Environment] trunk(devstack all-in-one with ML2 plugin(openvswitch)) [How to reproduce] * You have to arrange create_port_post_commit shuld be failed. source devstack/openrc admin admin export TOKEN=`openstack token issue | grep ' id ' | get_field 2` curl -s -X GET -H "x-auth-token:$TOKEN" 192.168.122.253:9696/v2.0/ports | jq "." { "ports": [] } curl -i -X PUT -d '{"subnet_id":"214ebeb5-2d08-4ae5-9d60-3c7a76d56746"}' -H "x-auth-token:$TOKEN" 192.168.122.253:9696/v2.0/routers/7d1561d1-71f9-4355-9248-5ac313de8ee3/add_router_interface HTTP/1.1 409 Conflict Content-Type: application/json; charset=UTF-8 Content-Length: 204 X-Openstack-Request-Id: req-ec3bad1f-84a2-4865-9cac-e63723c0a3bb Date: Fri, 11 Dec 2015 10:11:11 GMT {"NeutronError": {"message": "Port 570a4166-d463-4ee6-894b-f8aab6cc63b2 cannot be deleted directly via the port API: has device owner network:router_interface.", "type": "ServicePortInUse", "detail": ""}} $ curl -s -X GET -H "x-auth-token:$TOKEN" 192.168.122.253:9696/v2.0/ports/570a4166-d463-4ee6-894b-f8aab6cc63b2 | jq "." { "port": { "mac_address": "fa:16:3e:c3:1c:8d", "tenant_id": "4c0b8881d3e24a1cb1afe9ea6b07d946", "binding:vif_type": "unbound", "binding:vnic_type": "normal", "binding:vif_details": {}, "binding:profile": {}, "port_security_enabled": false, "device_owner": "network:router_interface", "dns_assignment": [ { "fqdn": "host-172-16-1-1.openstacklocal.", "ip_address": "172.16.1.1", "hostname": "host-172-16-1-1" } ], "extra_dhcp_opts": [], "allowed_address_pairs": [], "binding:host_id": "", "status": "DOWN", "fixed_ips": [ { "ip_address": "172.16.1.1", "subnet_id": "214ebeb5-2d08-4ae5-9d60-3c7a76d56746" } ], "id": "570a4166-d463-4ee6-894b-f8aab6cc63b2", "security_groups": [], "device_id": "7d1561d1-71f9-4355-9248-5ac313de8ee3", "name": "", "admin_state_up": true, "network_id": "11515598-c20e-4e8a-94d0-1fef56f4607d", "dns_name": "" } } ** Affects: neutron Importance: Undecided Assignee: Yushiro FURUKAWA (y-furukawa-2) Status: New ** Tags: neutron ** Changed in: neutron Assignee: (unassigned) => Yushiro FURUKAWA (y-furukawa-2) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1525163 Title: add-router-interface can not recover when failing create_port_post_commit Status in neutron: New Bug description: When the following situation, a port created that no one can delete it: 1. Configure ML2 plugin. 2. Execute router-interface-add with subnet_id and failed in create_port_post_commit After that, undeletable port is created. Even if the admin tries to delete the port, he cannot delete it. case1: delete-port with port_id => Port {port_id} cannot be deleted directly via the port API: has device owner network:router_interface. case2: router-interface-delete with subnet_id or port_id => Router {router_id} has no interface on subnet {subnet_id} => Router {router_id} does not have an interface with id {port_id} [How to fix] create_port_post_commit has a recovery process. When failed, then calls delete_port. However, in this case, 'device_owner' and 'device_id' have already registered at port's DB. Therefore, delete_port fails due to device_owner check. Hence, I'll add 'l3_port_check=False' into delete_port's argument. [Environment] trunk(devstack all-in-one with ML2 plugin(openvswitch)) [How to reproduce] * You have to arrange create_port_post_commit shuld be failed. source devstack/openrc admin admin export TOKEN=`openstack token issue | grep ' id ' | get_field 2` curl -s -X GET -H "x-auth-token:$TOKEN" 192.168.122.253:9696/v2.0/ports | jq "." { "ports": [] } curl -i -X PUT -d
[Yahoo-eng-team] [Bug 1368661] Re: Unit tests sometimes fail because of stale pyc files
** Changed in: oslo.cache Status: In Progress => Invalid ** Changed in: oslo.concurrency Status: In Progress => Invalid ** Changed in: oslo.log Status: In Progress => Invalid -- 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/1368661 Title: Unit tests sometimes fail because of stale pyc files Status in congress: Fix Released Status in Gnocchi: Invalid Status in Ironic: Fix Released Status in Magnum: Fix Released Status in Mistral: Fix Released Status in Monasca: Fix Committed Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) icehouse series: Fix Released Status in oslo.cache: Invalid Status in oslo.concurrency: Invalid Status in oslo.log: Invalid Status in oslo.service: Fix Committed Status in python-cinderclient: Fix Released Status in python-congressclient: In Progress Status in python-cueclient: In Progress Status in python-glanceclient: In Progress Status in python-heatclient: Fix Committed Status in python-keystoneclient: Fix Committed Status in python-magnumclient: Fix Released Status in python-mistralclient: Fix Committed Status in python-neutronclient: In Progress Status in Python client library for Sahara: Fix Committed Status in python-solumclient: In Progress Status in python-swiftclient: In Progress Status in python-troveclient: Fix Committed Status in Python client library for Zaqar: Fix Committed Status in Solum: In Progress Status in OpenStack Object Storage (swift): New Status in Trove: Fix Released Status in zaqar: In Progress Bug description: Because python creates pyc files during tox runs, certain changes in the tree, like deletes of files, or switching branches, can create spurious errors. This can be suppressed by PYTHONDONTWRITEBYTECODE=1 in the tox.ini. To manage notifications about this bug go to: https://bugs.launchpad.net/congress/+bug/1368661/+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 1461406] Re: libvirt: missing iotune parse for LibvirtConfigGuestDisk
** Changed in: nova Status: Expired => In Progress ** Changed in: nova Assignee: (unassigned) => ChangBo Guo(gcb) (glongwave) -- 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/1461406 Title: libvirt: missing iotune parse for LibvirtConfigGuestDisk Status in OpenStack Compute (nova): In Progress Bug description: We support instance disk IO control with iotune like : 102400 we set iotune in class LibvirtConfigGuestDisk in libvirt/config.py . The method parse_dom doesn't parse iotue options now. Need fix that. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1461406/+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 1525137] Re: doc wrong about BAK extensions of injection
commit 4474dce9e6b847a7691fc3f01d0c594061570d73 of nova master is same ** Also affects: nova Importance: Undecided Status: New ** Changed in: nova Assignee: (unassigned) => jichenjc (jichenjc) -- 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/1525137 Title: doc wrong about BAK extensions of injection Status in OpenStack Compute (nova): New Status in openstack-api-site: New Bug description: I cat following contents into a.pwd , note the '1' at /bin/sh1 of ssh line it's on purpose after following opreations, I didn't see fllowing mechanism talked in doc For example, if the /etc/passwd file exists, it is backed up as /etc/passwd.bak.1246036261.5785. https://github.com/openstack/nova/blob/master/api-guide/source/server_concepts.rst http://developer.openstack.org/api-ref-compute-v2.1.html $ sudo cat passwd root:x:0:0:root:/root:/bin/sh daemon:x:1:1:daemon:/usr/sbin:/bin/sh bin:x:2:2:bin:/bin:/bin/sh sys:x:3:3:sys:/dev:/bin/sh sync:x:4:100:sync:/bin:/bin/sync mail:x:8:8:mail:/var/spool/mail:/bin/sh proxy:x:13:13:proxy:/bin:/bin/sh www-data:x:33:33:www-data:/var/www:/bin/sh backup:x:34:34:backup:/var/backups:/bin/sh operator:x:37:37:Operator:/var:/bin/sh haldaemon:x:68:68:hald:/:/bin/sh dbus:x:81:81:dbus:/var/run/dbus:/bin/sh ftp:x:83:83:ftp:/home/ftp:/bin/sh nobody:x:99:99:nobody:/home:/bin/sh sshd:x:103:99:Operator:/var:/bin/sh1 cirros:x:1000:1000:non-root user:/home/cirros:/bin/sh do the following jichen@devstack1:/opt/stack/nova$ nova boot --file /etc/passwd=/home/jichen/a.pwd --image 9eee793a-25e5-4f42-bd9e-b869e60d3dbd --flavor m1.micro t6 +--++ | Property | Value | +--++ | OS-DCF:diskConfig| MANUAL | | OS-EXT-AZ:availability_zone | | | OS-EXT-STS:power_state | 0 | | OS-EXT-STS:task_state| scheduling | | OS-EXT-STS:vm_state | building | | OS-SRV-USG:launched_at | - | | OS-SRV-USG:terminated_at | - | | accessIPv4 | | | accessIPv6 | | | adminPass| 9VUVZY53nbFb | | config_drive | | | created | 2015-12-11T09:19:28Z | | flavor | m1.micro (84) | | hostId | | | id | 80f24559-2bd9-4709-b1a2-36709cfb3b50 | | image| cirros-0.3.4-x86_64-uec (9eee793a-25e5-4f42-bd9e-b869e60d3dbd) | jichen@devstack1:/opt/stack/nova$ ssh cirros@10.0.0.17 The authenticity of host '10.0.0.17 (10.0.0.17)' can't be established. RSA key fingerprint is c2:44:7a:4f:61:cb:1b:95:b4:3a:49:fe:ce:dc:1e:20. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '10.0.0.17' (RSA) to the list of known hosts. cirros@10.0.0.17's password: $ cd /etc $ ls TZ cirros fstab init.d ld.so.conf mtab profileresolv.confshadow acpi cirros-initgroup inittabld.so.conf.d networkprotocols screenrc ssl blkid.tab defaulthostname inputrcmke2fs.conf os-release random-seedsecuretty sudoers blkid.tab.old dropbear hosts issue modules passwd rc3.d services sudoers.d $ suco cat passwd -sh: suco: not found $ sudo cat passwd root:x:0:0:root:/root:/bin/sh daemon:x:1:1:daemon:/usr/sbin:/bin/sh bin:x:2:2:bin:/bin:/bin/sh sys:x:3:3:sys:/dev:/bin/sh sync:x:4:100:sync:/bin:/bin/sync
[Yahoo-eng-team] [Bug 1525132] [NEW] doc error about inject files to new build
Public bug reported: we tell user 'You cannot inject binary or zip files into a new build' in following https://github.com/openstack/nova/blob/master/api-guide/source/server_concepts.rst http://developer.openstack.org/api-ref-compute-v2.1.html ichen@devstack1:/opt/stack/nova$ nova boot --file /abc.tgz=/home/jichen/cert.tgz --image 9eee793a-25e5-4f42-bd9e-b869e60d3dbd --flavor m1.micro t5 +--++ | Property | Value | +--++ | OS-DCF:diskConfig| MANUAL | | OS-EXT-AZ:availability_zone | | | OS-EXT-STS:power_state | 0 | | OS-EXT-STS:task_state| scheduling | | OS-EXT-STS:vm_state | building | | OS-SRV-USG:launched_at | - | | OS-SRV-USG:terminated_at | - | | accessIPv4 | | | accessIPv6 | | | adminPass| KcGDaWG7SdFZ | | config_drive | | | created | 2015-12-11T09:04:33Z | | flavor | m1.micro (84) | | hostId | | | id | ec9b463d-0670-4bb0-8e1b-494007fc5cfc | | image| cirros-0.3.4-x86_64-uec (9eee793a-25e5-4f42-bd9e-b869e60d3dbd) | | key_name | - | | metadata | {} | | name | t5 | | os-extended-volumes:volumes_attached | [] | | os-pci:pci_devices | [] | | progress | 0 | | security_groups | default | | status | BUILD | | tenant_id| d1c5aa58af6c426492c642eb649017be | | updated | 2015-12-11T09:04:33Z | | user_id | 53a9e08a52eb4486aa4457f325e62b8a | +--++ jichen@devstack1:/opt/stack/nova$ nova list +--+--+++-+--+ | ID | Name | Status | Task State | Power State | Networks | +--+--+++-+--+ | ec9b463d-0670-4bb0-8e1b-494007fc5cfc | t5 | BUILD | spawning | NOSTATE | | +--+--+++-+--+ jichen@devstack1:/opt/stack/nova$ nova list +--+--+++-+---+ | ID | Name | Status | Task State | Power State | Networks | +--+--+++-+---+ | ec9b463d-0670-4bb0-8e1b-494007fc5cfc | t5 | ACTIVE | - | Running | private=10.0.0.13 | jichen@devstack1:/opt/stack/nova$ ssh cirros@10.0.0.13 The authenticity of host '10.0.0.13 (10.0.0.13)' can't be established. RSA key fingerprint is 8f:11:52:54:88:d6:40:7b:95:90:2f:bb:44:c6:36:16. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '10.0.0.13' (RSA)
[Yahoo-eng-team] [Bug 1525124] [NEW] attach port when VM is down,port status is active
Public bug reported: 1 Create a OVS port. 2 Attach this port to a vm,whic is shutdown. 3 Use nova interface-list ,we found the status of this port is 'ACTIVE' if fact this should be 'DOWN' ** 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/1525124 Title: attach port when VM is down,port status is active Status in neutron: New Bug description: 1 Create a OVS port. 2 Attach this port to a vm,whic is shutdown. 3 Use nova interface-list ,we found the status of this port is 'ACTIVE' if fact this should be 'DOWN' To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1525124/+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