January 2019 - openstack-discuss - lists.openstack.org

Patch needs to be re-approved.
by Ni, Qi 21 Jan '19

21 Jan '19

Hi, my patch https://review.openstack.org/#/c/623401/13 has passed the code review but according to Developer's Guide, it will not automatically merged when the dependent change has merged. It now needs another approval or a toggle of the approval. Please take a look at it. Thank you. Best Regards, Nicky.

2 1

[ironic] alidation of image href secreturl failed, reason: Got HTTP code 404 instead of 200 in response to HEAD request
by Zufar Dhiyaulhaq 21 Jan '19

21 Jan '19

Hi, I get some error when trying to create an instance for bare-metal node. Bellow is my troubleshooting. I don't know what is happening. Any suggestions? *Ironic Error Log*: 2019-01-19 15:36:41.232 15780 ERROR ironic.drivers.modules.deploy_utils [req-200dac66-0995-41c4-8c8c-dff053d27e36 499299da0c284a4ba9214ea0d83867cc 62088a869020430392a4fb1a0c5d2863 - default default] Agent deploy supports only HTTP(S) URLs as instance_info['image_source'] or swift temporary URL. Either the specified URL is not a valid HTTP(S) URL or is not reachable for node 6c20755a-e36b-495a-98e1-a40f58e5ac3c. Error: Validation of image href secreturl failed, reason: Got HTTP code 404 instead of 200 in response to HEAD request.: ImageRefValidationFailed: Validation of image href secreturl failed, reason: Got HTTP code 404 instead of 200 in response to HEAD request. 2019-01-19 15:36:41.233 15780 ERROR ironic.conductor.manager [req-200dac66-0995-41c4-8c8c-dff053d27e36 499299da0c284a4ba9214ea0d83867cc 62088a869020430392a4fb1a0c5d2863 - default default] Error while preparing to deploy to node 6c20755a-e36b-495a-98e1-a40f58e5ac3c: Validation of image href secreturl failed, reason: Got HTTP code 404 instead of 200 in response to HEAD request.: ImageRefValidationFailed: Validation of image href secreturl failed, reason: Got HTTP code 404 instead of 200 in response to HEAD request. *Nova Error Log:* 2019-01-19 16:35:52.639 13355 ERROR oslo.service.loopingcall [-] Fixed interval looping call 'nova.virt.ironic.driver.IronicDriver._wait_for_active' failed: InstanceDeployFailure: Failed to provision instance 3$ 2019-01-19 16:35:52.639 13355 ERROR oslo.service.loopingcall Traceback (most recent call last): 2019-01-19 16:35:52.639 13355 ERROR oslo.service.loopingcall File "/usr/lib/python2.7/site-packages/oslo_service/loopingcall.py", line 137, in _run_loop 2019-01-19 16:35:52.639 13355 ERROR oslo.service.loopingcall result = func(*self.args, **self.kw) 2019-01-19 16:35:52.639 13355 ERROR oslo.service.loopingcall File "/usr/lib/python2.7/site-packages/nova/virt/ironic/driver.py", line 505, in _wait_for_active 2019-01-19 16:35:52.639 13355 ERROR oslo.service.loopingcall raise exception.InstanceDeployFailure(msg) 2019-01-19 16:35:52.639 13355 ERROR oslo.service.loopingcall InstanceDeployFailure: Failed to provision instance 38c276b1-b88a-4f4b-924b-8b52377f3145: Failed to prepare to deploy: Validation of image href secre$ 2019-01-19 16:35:52.639 13355 ERROR oslo.service.loopingcall 2019-01-19 16:35:52.640 13355 ERROR nova.virt.ironic.driver [req-e11c3fcc-2066-49c6-b47b-0e3879840ad0 7ad46602ac42417a8c798c69cb3105e5 f3bb39ae2e0946e1bbf812bcde6e08a7 - default default] Error deploying instanc$ 2019-01-19 16:35:52.641 13355 ERROR nova.compute.manager [req-e11c3fcc-2066-49c6-b47b-0e3879840ad0 7ad46602ac42417a8c798c69cb3105e5 f3bb39ae2e0946e1bbf812bcde6e08a7 - default default] [instance: 38c276b1-b88a-4$ 2019-01-19 16:35:52.641 13355 ERROR nova.compute.manager [instance: 38c276b1-b88a-4f4b-924b-8b52377f3145] Traceback (most recent call last): 2019-01-19 16:35:52.641 13355 ERROR nova.compute.manager [instance: 38c276b1-b88a-4f4b-924b-8b52377f3145] File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 2252, in _build_resources 2019-01-19 16:35:52.641 13355 ERROR nova.compute.manager [instance: 38c276b1-b88a-4f4b-924b-8b52377f3145] yield resources 2019-01-19 16:35:52.641 13355 ERROR nova.compute.manager [instance: 38c276b1-b88a-4f4b-924b-8b52377f3145] File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 2032, in _build_and_run_instance 2019-01-19 16:35:52.641 13355 ERROR nova.compute.manager [instance: 38c276b1-b88a-4f4b-924b-8b52377f3145] block_device_info=block_device_info) 2019-01-19 16:35:52.641 13355 ERROR nova.compute.manager [instance: 38c276b1-b88a-4f4b-924b-8b52377f3145] File "/usr/lib/python2.7/site-packages/nova/virt/ironic/driver.py", line 1136, in spawn 2019-01-19 16:35:52.641 13355 ERROR nova.compute.manager [instance: 38c276b1-b88a-4f4b-924b-8b52377f3145] 'node': node_uuid}) 2019-01-19 16:35:52.641 13355 ERROR nova.compute.manager [instance: 38c276b1-b88a-4f4b-924b-8b52377f3145] File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__ 2019-01-19 16:35:52.641 13355 ERROR nova.compute.manager [instance: 38c276b1-b88a-4f4b-924b-8b52377f3145] self.force_reraise() 2019-01-19 16:35:52.641 13355 ERROR nova.compute.manager [instance: 38c276b1-b88a-4f4b-924b-8b52377f3145] File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in force_reraise 2019-01-19 16:35:52.641 13355 ERROR nova.compute.manager [instance: 38c276b1-b88a-4f4b-924b-8b52377f3145] six.reraise(self.type_, self.value, self.tb) 2019-01-19 16:35:52.641 13355 ERROR nova.compute.manager [instance: 38c276b1-b88a-4f4b-924b-8b52377f3145] File "/usr/lib/python2.7/site-packages/nova/virt/ironic/driver.py", line 1128, in spawn 2019-01-19 16:35:52.641 13355 ERROR nova.compute.manager [instance: 38c276b1-b88a-4f4b-924b-8b52377f3145] timer.start(interval=CONF.ironic.api_retry_interval).wait() 2019-01-19 16:35:52.641 13355 ERROR nova.compute.manager [instance: 38c276b1-b88a-4f4b-924b-8b52377f3145] File "/usr/lib/python2.7/site-packages/eventlet/event.py", line 121, in wait 2019-01-19 16:35:52.641 13355 ERROR nova.compute.manager [instance: 38c276b1-b88a-4f4b-924b-8b52377f3145] return hubs.get_hub().switch() 2019-01-19 16:35:52.641 13355 ERROR nova.compute.manager [instance: 38c276b1-b88a-4f4b-924b-8b52377f3145] File "/usr/lib/python2.7/site-packages/eventlet/hubs/hub.py", line 294, in switch 2019-01-19 16:35:52.641 13355 ERROR nova.compute.manager [instance: 38c276b1-b88a-4f4b-924b-8b52377f3145] return self.greenlet.switch() 2019-01-19 16:35:52.641 13355 ERROR nova.compute.manager [instance: 38c276b1-b88a-4f4b-924b-8b52377f3145] File "/usr/lib/python2.7/site-packages/oslo_service/loopingcall.py", line 137, in _run_loop 2019-01-19 16:35:52.641 13355 ERROR nova.compute.manager [instance: 38c276b1-b88a-4f4b-924b-8b52377f3145] result = func(*self.args, ** self.kw) 2019-01-19 16:35:52.641 13355 ERROR nova.compute.manager [instance: 38c276b1-b88a-4f4b-924b-8b52377f3145] File "/usr/lib/python2.7/site-packages/nova/virt/ironic/driver.py", line 505, in _wait_for_active 2019-01-19 16:35:52.641 13355 ERROR nova.compute.manager [instance: 38c276b1-b88a-4f4b-924b-8b52377f3145] raise exception.InstanceDeployFailure(msg) 2019-01-19 16:35:52.641 13355 ERROR nova.compute.manager [instance: 38c276b1-b88a-4f4b-924b-8b52377f3145] InstanceDeployFailure: Failed to provision instance 38c276b1-b88a-4f4b-924b-8b52377f3145: Failed to prep$ 2019-01-19 16:35:52.641 13355 ERROR nova.compute.manager [instance: 38c276b1-b88a-4f4b-924b-8b52377f3145] *Ironic Configuration:* [DEFAULT] enabled_drivers=pxe_ipmitool enabled_hardware_types = ipmi log_dir=/var/log/ironic transport_url=rabbit://guest:guest@10.60.60.10:5672/ auth_strategy=keystone notification_driver = messaging [conductor] send_sensor_data = true automated_clean=true [swift] region_name = RegionOne project_domain_id = default user_domain_id = default project_name = services password = IRONIC_PASSWORD username = ironic auth_url = http://10.60.60.10:5000/v3 auth_type = password [pxe] tftp_root=/tftpboot tftp_server=10.60.60.10 ipxe_enabled=True pxe_bootfile_name=undionly.kpxe uefi_pxe_bootfile_name=ipxe.efi pxe_config_template=$pybasedir/drivers/modules/ipxe_config.template uefi_pxe_config_template=$pybasedir/drivers/modules/ipxe_config.template pxe_append_params=coreos.autologin #ipxe_use_swift=True [agent] image_download_source = http [deploy] http_root=/httpboot http_url=http://10.60.60.10:8088 [service_catalog] insecure = True auth_uri=http://10.60.60.10:5000/v3 auth_type=password auth_url=http://10.60.60.10:35357 project_domain_id = default user_domain_id = default project_name = services username = ironic password = IRONIC_PASSWORD region_name = RegionOne [database] connection=mysql+pymysql:// ironic:IRONIC_DBPASSWORD@10.60.60.10/ironic?charset=utf8 [keystone_authtoken] auth_url=http://10.60.60.10:35357 www_authenticate_uri=http://10.60.60.10:5000 auth_type=password username=ironic password=IRONIC_PASSWORD user_domain_name=Default project_name=services project_domain_name=Default [neutron] www_authenticate_uri=http://10.60.60.10:5000 auth_type=password auth_url=http://10.60.60.10:35357 project_domain_name=Default project_name=services user_domain_name=Default username=ironic password=IRONIC_PASSWORD cleaning_network = 461a6663-e015-4ecf-9076-d1b502c3db25 provisioning_network = 461a6663-e015-4ecf-9076-d1b502c3db25 [glance] region_name = RegionOne project_domain_id = default user_domain_id = default project_name = services password = IRONIC_PASSWORD username = ironic auth_url = http://10.60.60.10:5000/v3 auth_type = password temp_url_endpoint_type = swift swift_endpoint_url = http://10.60.60.10:8080/v1/AUTH_%(tenant_id)s swift_account = AUTH_f3bb39ae2e0946e1bbf812bcde6e08a7 swift_container = glance swift_temp_url_key = secret *Temp-URL enable:* [root@zu-controller0 ~(keystone_admin)]# openstack object store account show +------------+---------------------------------------+ | Field | Value | +------------+---------------------------------------+ | Account | AUTH_f3bb39ae2e0946e1bbf812bcde6e08a7 | | Bytes | 996 | | Containers | 1 | | Objects | 1 | | properties | Temp-Url-Key='secret' | +------------+---------------------------------------+ *Swift Endpoint:* [root@zu-controller0 ~(keystone_admin)]# openstack endpoint list | grep swift | 07e9d544a44241f5b317f651dce5f0a4 | RegionOne | swift | object-store | True | public | http://10.60.60.10:8080/v1/AUTH_%(tenant_id)s | | dadfd168384542b0933fe41df87d9dc8 | RegionOne | swift | object-store | True | internal | http://10.60.60.10:8080/v1/AUTH_%(tenant_id)s | | e53aca9d357542868516d367a0bf13a6 | RegionOne | swift | object-store | True | admin | http://10.60.60.10:8080/v1/AUTH_%(tenant_id)s | Best Regards, Zufar Dhiyaulhaq

2 1

[Nova] [Scheduler] Change Nova weight_multiplier method to accept host_state
by Yikun Jiang 21 Jan '19

21 Jan '19

In blueprint [1], we approved to allow set weights multiplier on host aggregates to have more flexibility when scheduling. In order to make weigher can get the metadata info, we propose to add a new parameter "host_state" in weight_multiplier method [2], just like what we current do in filter host_passes [3]. That means if you implements the custom weigher, you should change your weigher to accept a host_state. Any thoughts or feedback are welcome, thanks! : ) [1] https://blueprints.launchpad.net/nova/+spec/per-aggregate-scheduling-weight [2] https://review.openstack.org/#/c/628163/12/nova/weights.py@79 [3] https://github.com/openstack/nova/blob/master/nova/scheduler/filters/__init… Regards, Yikun ---------------------------------------- Jiang Yikun（Kero） Mail: yikunkero(a)gmail.com

1 0

[releases] Additions to releases-core
by Sean McGinnis 21 Jan '19

21 Jan '19

I'm very happy to announce I have added Kendall Nelson and Jean-Philippe Evrard to the releases-core group. These two have been doing release request reviews and asking questions to learn about the release process, and we feel they are ready for more. Initially we will just be looking at +2's and saving approvals for one of the existing core members until everyone has more confidence. I wouldn't expect this +2-only period to last long though. We will also need to work out reallocation of review days. Right now, the current cores have taken different days for them to be the point person for processing reviews. With the expanded team, I think we should take a look at those days again and get the work divided up amongst us. Thanks Kendall and JP for getting involved and helping with this important piece of the process, and welcome to the releases-core team! Sean

3 2

[nova] review guide for the bandwidth patches
by Balázs Gibizer 21 Jan '19

21 Jan '19

Hi, After discussing generic concerns about the current proposed patch series[1] for the bandwidth-resource-provider bp [2] with Matt, I decided to write a summary that might help other reviewers. Grouping of the pathes ---------------------- The whole nova implementation is one long patch series that can be splitted into smaller logical steps * Already merged patches added the two new standard resource classes and added a field to RequestSpec to store the resource request of each neutron port. * The open patch series start at [3] now and the patches between [3] [4] introduce the ability to boot a server with neutron ports that has resource request. These patches implement handling the extra resources during boot, re-schedule and delete. These patches only work if a server has maximum one neutron port that has resource request. * The patches after [4] until [5] implement the calculation and communiction of the mapping between ports and resource providers that are fulfilling the given port resource request. (The reason why this is done in nova described below.) So these patches allow having more than one neutron port per server having resource request. * the next two patches [6][7] implement rejecting use cases that was decided to out of scope for the feature (interface attach with resource requst, booting with network having resource request) * The next patch [8] add support for removing resource allocation during interface detach if the detached port has resource request * The rest of the series up until [9] implement support for selecting VFs form the same PF that the bandwidth was allocated from. This allows handling bandwidth and VF resources properly even if there are more than one PFs on the same compute connected to the same physnet. What is still missing from the patch series: * Support for any kind of server move operations (resize, migrate, evacuate, live-migrate, unshelve) * Upgrade support: Bound SRIOV ports might already have QoS policy that would need healing resource allocation in placement. * Supporting separation of QoS aware and non aware ports on the same host. This can be done with host aggregates today, but the bp described possible ways to support a better separation. * Supporting multisegment network that has more than one segment having physnet name. For this we would need any-trait support from placement. The spec for it is approved but the implementation is on hold due to placement extraction. Order of the patches -------------------- One comment I got from Matt is that the patches are in wrong order. The current order allows booting server with bandwidth request _before_ every other server operation is supported (or rejected). This could lead to the violation of the resource view of the system. For example booting a server with a QoS aware port will result in bandwidth allocation on the compute host. But then later on migrating that server to another host does not properly handle moving the allocation to the target host. In my view reordering the patches to only allow booting the first server with bandwdith after every other operation is supported is not feasible. The current chain is already 17 patches long and it does not touch server moving operations at all. Also if I cannot boot a server with bandwidth then I cannot test that such server can be moved properly. So all the functional test would end up in the last patch of the series. However I think we can use the feature flag approach. We can implement and verify everything in the current order without the end user seeing or causing any kind of inconsistencies. The nova implementation is only activated if a neutron port has a resource_request field. This field is added to the neutron API as an API extension. We can mark this extension experimental while we are working through the missing pieces of the feature. But we can also turn on that extension in our test envirnoment to verify each and every step during the implementation process. Which RP fulfills the request of a neutron port ----------------------------------------------- Neutron expects a single RP uuid sent by nova in the port binding that tells neutron about which RP providers the resources for that port. This is the famous problem to find which request group is fulfilled by which resource provider in an allocation candidate. There are 3 possible solutions: * Neutron does the mapping. This would require Neutron to see each port binding for a given server as a single request. This is not the case today and not feasible to hack around in neutron. * Placement does the mapping. This is technically feasible and in my oppinion this is the good solution. But placement is in feature freeze so the spec [10] describing this change is put on hold. * Nova does the mapping. This is what pathes after [4] until [5] implement. It is a temporary solution until the placement based solution can be provided. The current patches are structured in a way that all ovo and neutronv2/api impacts in nova are reusable for the placement based solution later without change. There is only one patch [11] that will be thrown away when the placement based solution is available. I hope this mail helps reviewing the series. Cheers, gibi [1] https://review.openstack.org/#/q/topic:bp/bandwidth-resource-provider+(stat… [2] https://blueprints.launchpad.net/nova/+spec/bandwidth-resource-provider [3] https://review.openstack.org/#/c/625941/ [4] https://review.openstack.org/#/c/567268/ [5] https://review.openstack.org/#/c/573317/ [6] https://review.openstack.org/#/c/570078 [7] https://review.openstack.org/#/c/570079 [8] https://review.openstack.org/#/c/622421 [9] https://review.openstack.org/#/c/623543 [10] https://review.openstack.org/#/c/597601 [11] https://review.openstack.org/#/c/616239

7 25

[neutron][python3] Help needed
by Slawomir Kaplonski 21 Jan '19

21 Jan '19

Hi, Since some time we are trying to move our neutron-functional job to be run with python 3 - see patch [1]. Unfortunately we are still hitting same issue, some subunit parser error with message like "Parser Error: {{{Short read - got 4090 bytes, wanted 4376 bytes}}}”. See for example here: [2]. That cause that only around half of tests are executed and our job is failed. We found similar bug in Cinder [3] and we were trying to limit number of output produced by tests but this doesn’t help much. I don’t know how to move forward with this issue. Maybe someone more familiar with ostestr/subunit can take a look at it and help us to make this job finally working :) [1] https://review.openstack.org/#/c/577383/ [2] http://logs.openstack.org/83/577383/28/check/neutron-functional/649ba74/log… [3] https://bugs.launchpad.net/cinder/+bug/1728640 — Slawek Kaplonski Senior software engineer Red Hat

1 0

[all] Come and join us @ FOSDEM 2019, BXL, Belgium (Feb 2-3)
by Jean-Philippe Evrard 21 Jan '19

21 Jan '19

Hello everyone, Like the last year(s), the OpenStack community has a booth during FOSDEM in Brussels! Everyone is welcome to come by, and a little help by taking a shift at our stand would be super appreciated! I've written the event's details in an Etherpad [0]. This year is a little different, as the booth will have more topics than usual: - We are now welcoming distributions to talk about their way to distribute OpenStack. You could see RDO information there, for example. - We will have marketing material for the OpenInfrastructure pilot projects too. I look forward to see you there! Regards, Jean-Philippe Evrard (evrardjp) [0]: https://etherpad.openstack.org/p/fosdem-2019

1 0

Patch needs to be re-approved
by Ni, Qi 21 Jan '19

21 Jan '19

Hey guys, Please take a look at my patch https://review.openstack.org/#/c/626109/. Since there are two code review +2 and workflow +1, why hasn't it been merged yet? Best regards, Nicky.

2 1

Pre-Denver Summit [OFFTOPIC]
by David Medberry 19 Jan '19

19 Jan '19

FYI, There is a Denver traditional sci-fi fest the weekend prior to the Open Infra Summit. It is called "StarFest" and has been running for decades. https://starfestdenver.com/ So, if interested in such things, just come a couple days early. I don't expect this to interest many, but feel it is worthwhile to advertise it a tiny bit. I did bracket tag it offtopic.

1 0

[CFP-Denver] Co-Speaker for Hands-on Session in Denver Summit (Prinz Elvis Noudjeu)
by Prinz Elvis N 19 Jan '19

19 Jan '19

Hi All, Just want to ask if someone needs a Co-Speaker in his team for CFP Denver Summit. For Hands-on Session with Topics around: Kolla, zun, Monitoring, Cinder or HPC. Cheers Elvis from Germany freenode: PrinzElvis tw: @PrinzElvis

1 0