- openstack-discuss - lists.openstack.org

[congress] nominating Akhil Jain for core reviewer
by Eric K 21 Jan '19

21 Jan '19

Hi all, I'm writing to nominate Akhil Jain as a Congress core reviewer. He has been an active and consistent contributor in code, reviews, and community interactions for Rocky and Stein cycles. Some of his key contributions include data source drivers, working with other projects to drive key integrations, thorough code reviews, and many important nuts-and-bolts patches. He has been especially valuable to the project and the community through his technical designs informed by his gathering and understanding of operator requirements. Akhil: I look forward to continuing working together! Eric

2 1

Read Only FS after ceph issue
by Grant Morley 21 Jan '19

21 Jan '19

Hi all, We are in the process of retiring one of our old platforms and last night our ceph cluster went into an "Error" state briefly because 1 of the OSDs went close to full. The data got re-balanced fine and the health of ceph is now "OK" - however we have about 40% of our instances that now have corrupt disks which is a bit odd. Even more strange is that we cannot get them into rescue mode. As soon as we try we the instances seem to hang during the bootup process when they are trying to mount "/dev/vdb1" and we eventually get a kernel timeout error as below: Warning: fsck not present, so skipping root file system [ 5.644526] EXT4-fs (vdb1): INFO: recovery required on readonly filesystem [ 5.645583] EXT4-fs (vdb1): write access will be enabled during recovery [ 240.504873] INFO: task exe:332 blocked for more than 120 seconds. [ 240.506986] Not tainted 4.4.0-66-generic #87-Ubuntu [ 240.508782] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 240.511438] exe D ffff88003714b878 0 332 1 0x00000000 [ 240.513809] ffff88003714b878 ffff88007c18e358 ffffffff81e11500 ffff88007be81c00 [ 240.516665] ffff88003714c000 ffff88007fc16dc0 7fffffffffffffff ffffffff81838cd0 [ 240.519546] ffff88003714b9d0 ffff88003714b890 ffffffff818384d5 0000000000000000 [ 240.522399] Call Trace: I have even tried using a different image for nova rescue and we are getting the same results. Has anyone come across this before? This system is running OpenStack Mitaka with Ceph Jewel. Any help or suggestions will be much appreciated. Regards, -- Grant Morley Cloud Lead Absolute DevOps Ltd Units H, J & K, Gateway 1000, Whittle Way, Stevenage, Herts, SG1 2FP www.absolutedevops.io <http://www.absolutedevops.io/> grant(a)absolutedevops.io <mailto:grant@absolutedevops.io> 0845 874 0580

2 2

[manila-ui][queens] cannot create share snapshot
by Ignazio Cassano 21 Jan '19

21 Jan '19

Hello, I installed manila on centos queens but it is not possible creating share snapshot from ui: Danger: An error occurred. Please try again later. It works from command line . Regards Ignazio

2 2

[Diversity] [OffTOPIC] OpenStack Diversity Survey - ends Feb 28
by Amy Marrich 21 Jan '19

21 Jan '19

This is the last time the Diversity and Inclusion WG is asking for your assistance for our current survey in collecting data in regards to diversity. We will be closing the survey on February 28th, 2019 in order to start compiling the data. We revised the Diversity Survey that was originally distributed to the Community in the Fall of 2015 and reached out in August with our new survey. We are looking to update our view of the OpenStack community and it's diversity. We are pleased to be working with members of the CHAOSS project who have signed confidentiality agreements in order to assist us in the following ways: 1) Assistance in analyzing the results 2) And feeding the results into the CHAOSS software and metrics development work so that we can help other Open Source projects Please take the time to fill out the survey and share it with others in the community. The survey can be found at: https://www.surveymonkey.com/r/OpenStackDiversity Thank you for assisting us in this important task! Please feel free to reach out to me via email, in Berlin, or to myself or any WG member in #openstack-diversity! Amy Marrich (spotz) Diversity and Inclusion Working Group Chair

1 0

[tc] [all] Please help verify the role of the TC
by Chris Dent 21 Jan '19

21 Jan '19

Recently Thierry, with the help of other TC members, wrote down the perceived role of the TC [1]. This was inspired by the work on the "Vision for OpenStack Clouds" [2]. If we think we should have that document to help validate and direct our software development, we should have something similar to validate governance. Now we need to make sure the document reflects not just how things are but also how they should be. We (the TC) would like feedback from the community on the following general questions (upon which you should feel free to expand as necessary). * Does the document accurately reflect what you see the TC doing? * What's in the list that shouldn't be? * What's not in the list that should be? * Should something that is listed be done more or less? Discussions like these are sometimes perceived as pointless navel gazing. That's a fair complaint when they result in nothing changing (if it should). In this case however, it is fair to say that the composition of the OpenStack community is changing and we _may_ need some adjustments in governance to effectively adapt. We can't know if any changes should be big or little until we talk about them. We have several weeks before the next TC election, so now seems an appropriate time. Note that the TC was chartered with a mission [3]: The Technical Committee (“TC”) is tasked with providing the technical leadership for OpenStack as a whole (all official projects, as defined below). It enforces OpenStack ideals (Openness, Transparency, Commonality, Integration, Quality…), decides on issues affecting multiple projects, forms an ultimate appeals board for technical decisions, and generally has technical oversight over all of OpenStack. Thanks for your participation and help. [1] https://governance.openstack.org/tc/reference/role-of-the-tc.html [2] https://governance.openstack.org/tc/reference/technical-vision.html [3] https://governance.openstack.org/tc/reference/charter.html#mission -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

15 52

[dev][tc][ptl] Evaluating projects in relation to OpenStack cloud vision
by Julia Kreger 21 Jan '19

21 Jan '19

As some of you may or may not have heard, recently the Technical Committee approved a technical vision document [1]. The goal of the technical vision document is to try to provide a reference point for cloud infrastructure software in an ideal universe. It is naturally recognized that not all items will apply to all projects. With that in mind, we want to encourage projects to leverage the vision by performing a realistic self-evaluation to determine how their individual project compares to the technical vision: What gaps exist in the project that could be closed to be more in alignment with the vision? Are there aspects of the vision which are inappropriate for the project to such a degree that the vision itself should change, not the project? We envision the results of the evaluation to be added to each project's primary contributor documentation tree (/doc/source/contributor/vision-reflection.rst) as a list of bullet points detailing areas where a project feels they need adjustment to better align with the technical vision, and if the project already has visibility into a path forward, that as well. As with all things of this nature, we anticipate projects to treat the document as a living document and update it as each project's contributors feel necessary. If an individual project community feels something in the overall OpenStack community technical vision does not apply, that is okay. If the project community feels that something in the vision is wrong for the whole of OpenStack, please feel free to submit a revision to gerrit in order to start that discussion. Once projects have performed a realistic self-evaluation, we ask each project to then consider those items they identified in their future planning as areas that could use the attention of contributors. To be very explicit about this, the intent is to help enable projects to identify areas for improved alignment with the rest of OpenStack using a short, concise, easily consumable list that can be referenced in planning, or even by drive-by contributors if they are intrigued by a specific problem. Thanks, Julia Kreger & Chris Dent [1] https://governance.openstack.org/tc/reference/technical-vision.html

3 4

[heystone][nova][cinder] netapp queens trust scoped token
by Ignazio Cassano 21 Jan '19

21 Jan '19

Hello Everyone, I am using a client for backupping openstack virtual machine. The crux of the problem is the client uses trust based authentication for scheduling backup jobs on behalf of user. When a trust scoped token is passed to cinder client to take a snapshot, I expect the client use the token to authenticate and perform the operation which cinder client does. However cinder volume service invokes novaclient as part of cinder nfs backend snapshot operation and novaclient tries to re-authenticate. Since keystone does not allow re-authentication using trust based tokens, cinder snapshot operation fails. So I get the following error: 2018-12-12 04:07:14.759 2859 ERROR cinder.volume.drivers. remotefs [req-61d977c1-eef3-4309-ac02-aaa0eb880925 ab1bdb5dadc54312891f3a6410fef04d 6d1bffb04e3b4cdda30dc17aa96bfffc - default default] Call to Nova to create snapshot failed: Forbidden: You are not authorized to perform the requested action: Using trust-scoped token to create another token. Create a new trust-scoped token instead. (HTTP 403) (Request-ID: req-f55b682a-001b-4952-bfb1-abf4dd6bf459) > 2018-12-12 04:07:14.759 2859 ERROR cinder.volume.drivers. remotefs Traceback (most recent call last): > 2018-12-12 04:07:14.759 2859 ERROR cinder.volume.drivers. remotefs File "/usr/lib/python2.7/site-packages/cinder/volume/drivers/ remotefs.py", line 1452, in _create_snapshot_online > 2018-12-12 04:07:14.759 2859 ERROR cinder.volume.drivers. remotefs connection_info) > 2018-12-12 04:07:14.759 2859 ERROR cinder.volume.drivers. remotefs File "/usr/lib/python2.7/site-packages/cinder/compute/nova.py", line 188, in create_volume_snapshot > 2018-12-12 04:07:14.759 2859 ERROR cinder.volume.drivers. remotefs create_info=create_info) > 2018-12-12 04:07:14.759 2859 ERROR cinder.volume.drivers. remotefs File "/usr/lib/python2.7/site-packages/novaclient/v2/assisted_volume_snapshots.py", line 43, in create > 2018-12-12 04:07:14.759 2859 ERROR cinder.volume.drivers. remotefs return self._create('/os-assisted-volume-snapshots', body, 'snapshot') > 2018-12-12 04:07:14.759 2859 ERROR cinder.volume.drivers. remotefs File "/usr/lib/python2.7/site-packages/novaclient/base.py", line 361, in _create > 2018-12-12 04:07:14.759 2859 ERROR cinder.volume.drivers. remotefs resp, body = self.api.client.post(url, body=body) > 2018-12-12 04:07:14.759 2859 ERROR cinder.volume.drivers. remotefs File "/usr/lib/python2.7/site-packages/keystoneauth1/adapter.py", line 310, in post > 2018-12-12 04:07:14.759 2859 ERROR cinder.volume.drivers. remotefs return self.request(url, 'POST', **kwargs) My cinder volume are non netapp fas8040 via nfs. Anyone can help me ? Regards Ignazio

2 4

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

[neutron]How to ease congestion at neutron server nodes?
by Cody 18 Jan '19

18 Jan '19

Hi Stackers, What solution(s) other than DVR could I use to avoid north-south traffic congestion at the neutron server nodes? Basically, I wish to let VMs with floating IPs to route directly from their respective hypervisor hosts to the Internet. Thank you very much. Regards, Cody

5 5

[ironic] Mid-cycle call times
by Julia Kreger 18 Jan '19

18 Jan '19

Greetings everyone, During our ironic team meeting in December, we discussed if we should go ahead and have a "mid-cycle" call in order to try sync up on where we are at during this cycle, and the next steps for us to take as a team. With that said, I have created a doodle poll[1] in an attempt to identify some days that might work. Largely the days available on the poll are geared around my availability this month. Ideally, I would like to find three days where we can schedule some 2-4 hour blocks of time. I've gone ahead and started an etherpad[2] to get us started on brainstorming. Once we have some ideas, we will be able to form a schedule and attempt to identify the amount of time required. -Julia [1]: https://doodle.com/poll/uqwywaxuxsiu7zde [2]: https://etherpad.openstack.org/p/ironic-stein-midcycle

2 5

Retiring openstack-infra/puppet-storyboard
by Andreas Jaeger 18 Jan '19

18 Jan '19

The repo openstack-infra/puppet-storyboard has been created with the intent to host storyboard by the OpenStack Infra team - and this did not happen. We will therefore retire the repository, I'm proposing patches now with topic retire-puppet-storyboard, Andreas -- Andreas Jaeger aj(a){suse.com,opensuse.org} Twitter: jaegerandi SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

1 1

[placement] update 19-02
by Chris Dent 18 Jan '19

18 Jan '19

HTML: https://anticdent.org/placement-update-19-02.html Hi! It's a placement update! The main excitement this week is we had a meeting to check in on the state of extraction and figure out the areas that need the most attention. More on that in the extraction section within. # Most Important Work to complete and review changes to deployment to support extracted placement is the main thing that matters. # What's Changed * Placement is now able to publish release notes. * Placement is running python 3.7 unit tests in the gate, but not functional (yet). * We had that meeting and [Matt made some notes](http://lists.openstack.org/pipermail/openstack-discuss/2019-January/…. # Bugs * Placement related [bugs not yet in progress](https://goo.gl/TgiPXb): 15. +1. * [In progress placement bugs](https://goo.gl/vzGGDQ) 16. Stable. # Specs Last week was spec freeze so I'll not list all the specs here, but for reference, there were 16 specs listed last week and all 16 of them are neither merged nor abandoned. # Main Themes The reshaper work was restarted after discussion at the meeting surfaced its stalled nature. The libvirt side of things is due some refactoring while the xenapi side is waiting for a new owner to come up to speed. Gibi has proposed a related functional test. All of that at: * <https://review.openstack.org/#/q/topic:bp/reshape-provider-tree+status:open> Also making use of nested is this spectacular stack of code at bandwidth-resource-provider: * <https://review.openstack.org/#/q/topic:bp/bandwidth-resource-provider> Eric's in the process of doing lots of cleanups to how often the ProviderTree in the resource tracker is checked against placement, and a variety of other "let's make this more right" changes in the same neighborhood: * Stack at: <https://review.openstack.org/#/c/615677> That stuff is very close to ready and will make lots of people happy when it merges. One of the main areas of concern is making sure it doesn't break things for Ironic. ## Extraction As noted above, there was a meeting which resulted in [Matt's Notes](http://lists.openstack.org/pipermail/openstack-discuss/2019-January/…, an updated [extraction etherpad](https://etherpad.openstack.org/p/placement-extract-stein-5), and an improved understanding of where things stand. The critical work to ensure a healthy extraction is with getting deployment tools working. Here are _some_ of the links to that work: * [TripleO](https://review.openstack.org/#/q/topic:tripleo-placement-extractio… * [OpenStack Ansible](https://review.openstack.org/#/q/project:openstack/openstack-ansib… * [Kolla and Kolla Ansible](https://review.openstack.org/#/q/topic:split-placement) and [kolla upgrade](https://review.openstack.org/#/q/topic:upgrade-placement) We also worked out that getting the online database migrations happening on the placement side of the world would help: * [in placement](https://review.openstack.org/#/c/624942/) * [use in grenade](https://review.openstack.org/#/c/631614/) Documentation is mostly in-progress, but needs some review from packagers. A change to [openstack-manuals](https://review.openstack.org/#/c/628324/) depends on the [initial placement install docs](https://review.openstack.org/628220). There is a patch to [delete placement](https://review.openstack.org/#/c/618215/) from nova on which we've put an administrative -2 until it is safe to do the delete. # Other There are 13 [open changes](https://review.openstack.org/#/q/project:openstack/placement+statu… in placement itself. Several of those are easy win cleanups. Of those placement changes, the [online-migration-related](https://review.openstack.org/#/q/topic:bug/180392… ones are the most important. Outside of placement (I've decided to trim this list to just stuff that's seen a commit in the last two months): * <https://review.openstack.org/#/q/topic:minimum-bandwidth-allocation-placeme…> Neutron minimum bandwidth implementation * <https://review.openstack.org/#/c/621645/> WIP: add Placement aggregates tests (in tempest) * <https://review.openstack.org/627326> blazar: Consider the number of reservation inventory * <https://review.openstack.org/622316> Add placement client for basic GET operations (to tempest) # End Because I wanted to see what it might look like, I made a toy VM scheduler and placer, using etcd and placement. Then I wrote a [blog post](https://anticdent.org/etcd-placement-virt-install-compute.html). I wish there was more time for this kind of educational and exploratory playing. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

1 0

[sig][upgrades] 2019 reboot/irc meeting on Monday
by James Page 18 Jan '19

18 Jan '19

Hi All During the PTG in Denver we agreed to move the Upgrades SIG IRC meeting to a 4 week cadence. I completed the re-scheduling shortly after the PTG, but we've failed to actually hold a meeting to date! The next scheduled meetings are 0900 and 1600 UTC this coming Monday; we'll go with the standing agenda that we had before: https://etherpad.openstack.org/p/upgrades-sig-meeting Have a great weekend and look forward to chatting with interested parties on Monday! Cheers James

1 0

[dev] [infra] [devstack] [qa] [kuryr] DevStack's etcd performance on gate VM's
by Michał Dulko 18 Jan '19

18 Jan '19

Hi, In Kuryr-Kubernetes we're using the DevStack-installed etcd as a backend store for Kubernetes that we run on our gates. For some time we can see its degraded performance manifesting like this [1] in the logs. Later on this leads to various K8s errors [2], [3], up to missing notifications from the API, which causes failures in Kuryr-Kubernetes tempest tests. From what I've seen those etcd warnings normally mean that disk latency is high. This seems to be mostly happening on OVH and RAX hosts. I've looked at this with OVH folks and there isn't anything immediately alarming about their hosts running gate VM's. Upgrading the etcd version doesn't seem to help, as well as patch [4] which increases IO priority for etcd process. Any ideas of what I can try next? I think we're the only project that puts so much pressure on the DevStack's etcd. Help would really be welcomed, getting rid of this issue will greatly increase our gates stability. Thanks, Michał [1] http://logs.openstack.org/49/624749/1/check/kuryr-kubernetes-tempest-daemon… [2] http://logs.openstack.org/49/624749/1/check/kuryr-kubernetes-tempest-daemon… [3] http://logs.openstack.org/49/624749/1/check/kuryr-kubernetes-tempest-daemon… [4] https://review.openstack.org/#/c/624730/

3 5

[tripleo] LP bug bash
by Juan Antonio Osorio Robles 17 Jan '19

17 Jan '19

Hello folks! It has come to our attention that our Launchpad bug list has been growing and some bugs have gone stale. We have decided to go through the list weekly and triage or update bugs as needed in order to address this. This would be done one hour before our weekly meeting (so Tuesday at 13:00 UTC). Volunteers or people interested are welcome! There will be more details on the medium (video or IRC) on that day in the #tripleo channel. Best regards!

2 2

Neutron tagging
by cmnfths 17 Jan '19

17 Jan '19

Hi everyone! Recently I've encountered a neutron issue related to port tagging mechanism, and wonder if anyone else ever did. The initial source of the issue was, as it seems, identical numeration of external VLANs' tags and OVS (exactly br-int) port tags. The VLAN tagged 222 was added to bridge br-ex and everything worked, but at some point firewall reported unusual traffic. Thus I'd found that there was a loop and 2 qr-* ports with the same tag 222 attached to br-int. After that I deleted them and the loop was gone. So the question is what exactly these tags are? The same ethernet frame bits as 802.1Q tags? Where is a pool or something they're taken from? Is there any possibility to form such pool via configs or patches? Has anyone ever encountered such situation? Thanks, Andrew Th.

2 1

[oslo] Parallel Privsep is Proposed for Release
by Ben Nemec 17 Jan '19

17 Jan '19

Yay alliteration! :-) I wanted to draw attention to this release[1] in particular because it includes the parallel privsep change[2]. While it shouldn't have any effect on the public API of the library, it does significantly affect how privsep will process calls on the back end. Specifically, multiple calls can now be processed at the same time, so if any privileged code is not reentrant it's possible that new race bugs could pop up. While this sounds scary, it's a necessary change to allow use of privsep in situations where a privileged call may take a non-trivial amount of time. Cinder in particular has some privileged calls that are long-running and can't afford to block all other privileged calls on them. So if you're a consumer of oslo.privsep please keep your eyes open for issues related to this new release and contact the Oslo team if you find any. Thanks. -Ben 1: https://review.openstack.org/628019 2: https://review.openstack.org/#/c/593556/

5 14

Infra team upgrading review.openstack.org Gerrit from 2.13.9 to 2.13.12 January 18 at about 1700UTC
by Clark Boylan 17 Jan '19

17 Jan '19

We will be performing a minor Gerrit upgrade to version 2.13.12 tomorrow (January 18, 2019) at 1700UTC. We've tested this upgrade on our dev server, https://review-dev.openstack.org, and expect it to be a quick upgrade. Any outage shouldn't last more than 10 minutes. We will let our configuration management tooling manage the upgrade so we won't have an exact time, but will try to get it as close to 1700UTC as possible. Feel free to test out the new version on the dev server. We are happy to answer any questions you might have as well. Sorry for the short notice and the cross post, Clark

1 0

[ALL] Train TC Election Season (Yes, TC not PTL)
by Kendall Nelson 17 Jan '19

17 Jan '19

Hello All! TC and not PTL you might ask? Yes! Due to the timing of the summit and release and optimizing timing so that they don't overlap, the technical elections this cycle will trade places and we will have the TC election first and then the PTL election. If you're curious about how this decision was made, feel free to check out the conversation during TC office hours here[1]. Election details: https://governance.openstack.org/election/ Please read the stipulations and timelines for candidates and electorate contained in this governance documentation. There will be further announcements posted to the mailing list as action is required from the electorate or candidates. This email is for information purposes only. If you have any questions which you feel affect others please reply to this email thread. If you have any questions that you which to discuss in private please email any of the election officials[2] so that we may address your concerns. Thank you, -Kendall (diablo_rojo) [1] http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2019… [2] https://governance.openstack.org/election/#election-officials

1 0

[ironic] boot.ipxe input/output error
by Zufar Dhiyaulhaq 17 Jan '19

17 Jan '19

Hi, I try to install ironic but get error boot.ipxe input/output error when trying to cleaning the node (error image: https://ibb.co/mhN5GYc) This is my ironic configuration : *[DEFAULT]enabled_drivers=pxe_ipmitoolenabled_hardware_types = ipmilog_dir=/var/log/ironictransport_url=rabbit://guest:guest@10.60.60.10:5672/ <http://guest:guest@10.60.60.10:5672/>auth_strategy=keystonenotification_driver = messaging[conductor]send_sensor_data = trueautomated_clean=true[swift]region_name = RegionOneproject_domain_id = defaultuser_domain_id = defaultproject_name = servicespassword = IRONIC_PASSWORDusername = ironicauth_url = http://10.60.60.10:5000/v3 <http://10.60.60.10:5000/v3>auth_type = password[pxe]tftp_root=/tftpboottftp_server=10.60.60.10ipxe_enabled=Truepxe_bootfile_name=undionly.kpxeuefi_pxe_bootfile_name=ipxe.efipxe_config_template=$pybasedir/drivers/modules/ipxe_config.templateuefi_pxe_config_template=$pybasedir/drivers/modules/ipxe_config.templateipxe_use_swift=True[deploy]http_root=/httpboothttp_url=http://10.60.60.10:8080 <http://10.60.60.10:8080>[service_catalog]insecure = Trueauth_uri=http://10.60.60.10:5000/v3 <http://10.60.60.10:5000/v3>auth_type=passwordauth_url=http://10.60.60.10:35357 <http://10.60.60.10:35357>project_domain_id = defaultuser_domain_id = defaultproject_name = servicesusername = ironicpassword = IRONIC_PASSWORDregion_name = RegionOne[database]connection=mysql+pymysql://ironic:IRONIC_DBPASSWORD@10.60.60.10/ironic?charset=utf8 <http://ironic:IRONIC_DBPASSWORD@10.60.60.10/ironic?charset=utf8>[keystone_authtoken]auth_url=http://10.60.60.10:35357 <http://10.60.60.10:35357>www_authenticate_uri=http://10.60.60.10:5000 <http://10.60.60.10:5000>auth_type=passwordusername=ironicpassword=IRONIC_PASSWORDuser_domain_name=Defaultproject_name=servicesproject_domain_name=Default[neutron]www_authenticate_uri=http://10.60.60.10:5000 <http://10.60.60.10:5000>auth_type=passwordauth_url=http://10.60.60.10:35357 <http://10.60.60.10:35357>project_domain_name=Defaultproject_name=servicesuser_domain_name=Defaultusername=ironicpassword=IRONIC_PASSWORDcleaning_network = 461a6663-e015-4ecf-9076-d1b502c3db25provisioning_network = 461a6663-e015-4ecf-9076-d1b502c3db25[glance]region_name = RegionOneproject_domain_id = defaultuser_domain_id = defaultproject_name = servicespassword = IRONIC_PASSWORDusername = ironicauth_url = http://10.60.60.10:5000/v3 <http://10.60.60.10:5000/v3>auth_type = passwordswift_endpoint_url = http://10.60.60.10:8080/v1/AUTH_%(tenant_id)sswift_account = AUTH_f3bb39ae2e0946e1bbf812bcde6e08a7swift_container = glanceswift_temp_url_key = secret* I try to open the URL which is http://10.60.60.10:8080/boot.ipxe but always get BAD URL error. Are the Baremetal node cannot download the boot.ipxe? are my swift is broken? Thank you. Best Regards, Zufar Dhiyaulhaq

1 0

[release] Release countdown for week R-11, January 21-25
by Sean McGinnis 17 Jan '19

17 Jan '19

Welcome to the weekly countdown email. Development Focus ----------------- Teams should be focused on implementing planned work for the cycle. It is also a good time to review those plans and reprioritize anything if needed based on the what progress has been made and what looks realistic to complete in the next few weeks. General Information ------------------- Looking ahead to Stein-3, please be aware of the various freeze dates. This varies for deliverable type, starting with non-client libraries, then client libraries, then finally services. This is to ensure we have time for requirements updates and resolving any issues prior to RC. Just as a reminder, we have freeze dates ahead of the first RC in order to stabilize our requirements. Updating global requirements close to overall code freeze increases the risk of an unforeseen side effect being introduced too late in the cycle to properly fix. For this reason, we first freeze the non-client libraries that may be used by service and client libraries, followed a week later by the client libraries. This minimizes the ripple effects that have caused projects to scamble to fix last minute issues. Please keep these deadlines in mind as you work towards wrapping up feature work that may require library changes to complete. Upcoming Deadlines & Dates -------------------------- Non-client library freeze: February 28 Client library freeze: March 7 Stein-3 milestone: March 7 -- Sean McGinnis (smcginnis)

1 0

[all] Etcd as DLM
by Ben Nemec 17 Jan '19

17 Jan '19

Hi, I wanted to revisit this topic because it has come up in some downstream discussions around Cinder A/A HA and the last time we talked about it upstream was a year and a half ago[1]. There have certainly been changes since then so I think it's worth another look. For context, the conclusion of that session was: "Let's use etcd 3.x in the devstack CI, projects that are eventlet based an use the etcd v3 http experimental API and those that don't can use the etcd v3 gRPC API. Dims will submit a patch to tooz for the new driver with v3 http experimental API. Projects should feel free to use the DLM based on tooz+etcd3 from now on. Others projects can figure out other use cases for etcd3." The main question that has come up is whether this is still the best practice or if we should revisit the preferred drivers for etcd. Gorka has gotten the grpc-based driver working in a Cinder driver that needs etcd[2], so there's a question as to whether we still need the HTTP etcd-gateway or if everything should use grpc. I will admit I'm nervous about trying to juggle eventlet and grpc, but if it works then my only argument is general misgivings about doing anything clever that involves eventlet. :-) It looks like the HTTP API for etcd has moved out of experimental status[3] at this point, so that's no longer an issue. There was some vague concern from a downstream packaging perspective that the grpc library might use a funky build system, whereas the etcd3-gateway library only depends on existing OpenStack requirements. On the other hand, I don't know how much of a hassle it is to deploy and manage a grpc-gateway. I'm kind of hoping someone has already been down this road and can advise about what they found. Thanks. -Ben 1: https://etherpad.openstack.org/p/BOS-etcd-base-service 2: https://github.com/embercsi/ember-csi/blob/5bd4dffe9107bc906d14a45cd819d9a6… 3: https://github.com/grpc-ecosystem/grpc-gateway

11 20

[tripleo] OVB is now on Gerrit
by Ben Nemec 17 Jan '19

17 Jan '19

Just a heads up that the import of OVB to Gerrit is complete. If you're using OVB you should switch your clones from the Github repo to https://git.openstack.org/cgit/openstack/openstack-virtual-baremetal I've marked the Github repo deprecated so please don't submit issues or PRs there anymore. For the moment the approval process won't meaningfully change. I'll still be reviewing and single-approving patches, and the core reviewer list for OVB is the same as it was on Github, with the addition of Juan (as TripleO PTL) and Harald (as someone who has recently done a ton of good work in OVB). See the full list here: https://review.openstack.org/#/admin/groups/1993,members Once we have E2E testing set up on the repo (that isn't me manually testing changes against my local cloud) I expect we'll open that list up more and can discuss moving to a more typical 2 +2 model. Thanks. -Ben

2 2

[TripleO] Scaling TripleO for Edge Computing
by James Slagle 17 Jan '19

17 Jan '19

Within the TripleO Edge squad, we've been collecting ideas and looking at other current in progress work as it relates to scaling TripleO. The high level goal is brainstorm about how we can scale to manage deployments that are of a order of magnitude larger than we do today (thousands of nodes instead of hundreds). We've been collecting these ideas in this google doc: https://docs.google.com/document/d/12tPc4NC5fo8ytGuFZ4DSZXXyzes1x3U7oYz9nea… As always, any feedback or other ideas are welcome. It should be open to view/comment/edit without any account required. Or, feel free to reply on the ML. Thanks! -- -- James Slagle --

1 0

[neutron] [upgrade] No meeting on Jan. 17th
by Lujin Luo 16 Jan '19

16 Jan '19

Hi team, I will not be able to chair the meeting tomorrow. And since from the review list, we do not have many updates. Let's resume next week. Sorry for any inconvenience caused. Best regards, Lujin

1 0

[bifrost][ironic-inspector] how could i use bifrost to inspector the server
by 谭明宵 16 Jan '19

16 Jan '19

Hi all: I use the bifrost to deploy ironic standalone，but I don’t know how to use it for ironic-inspector，Thanks for your help

1 0

[nova][placement][tripleo] Extracted Placement enablement status update #1
by Lee Yarwood 16 Jan '19

16 Jan '19

Hello, This is a brief status progress report on my work to enable the deployment of the extracted Placement service within TripleO ahead of the extraction check-in call later today. tl;dr TripleO isn't ready to switch to an extracted Placement service or for code to be removed from openstack/nova. # RDO (packaging) https://review.rdoproject.org/#/q/topic:placement-add This was started at the PTG in Denver and mostly completed some time ago now. I do however have a single change outstanding that includes the puppet-placement package as a dependency of puppet-tripleo but aside from that this is complete: puppet-tripleo: Require puppet-placement https://review.rdoproject.org/r/18330 FWIW in the context of the extraction check-in call, both RDO and TripleO are not ready to deal with the original placement code being deleted from the openstack/nova project at this point. This will continue to be the case until the following work is completed to enable deployments using the extracted project in TripleO. # Kolla (containers) https://review.openstack.org/#/q/topic:split-placement+OR+topic:upgrade-pla… The initial Kolla change to produce a placement-api container landed some time ago after some small delays due to the Stein UCA not being used for the Ubuntu binary jobs: Split placement-api from nova https://review.openstack.org/#/c/613589/ FWIW an additional change to copy across the DB migration script has also been posted and is pending a package promotion in RDO: Copy placement database migration script https://review.openstack.org/#/c/626382/ The above change isn't required by TripleO, I just wanted to highlight that kolla-ansible are looking to use the script during upgrades. Unfortunately due various issues with TripleO promotions the TripleO container for the placement-api was only uploaded yesterday after I manually built it: https://hub.docker.com/r/tripleomaster/centos-binary-placement-api # Puppet https://review.openstack.org/#/q/topic:tripleo-placement-extraction The initial and massive puppet-placement cookiecutter change has landed: Initial cookiecutter run and import from puppet-nova https://review.openstack.org/#/c/604182/ This is currently only tested on CentOS7 by the following POI or puppet-openstack-integration change that has itself been stuck behind a raft of Ubuntu py3 and Stein UCA issues: placement: Extract the service from Nova https://review.openstack.org/#/c/615568/ I'm attempting to unblock this by working my way through the following changes to support py3 and the Stein UCA within the Ubuntu jobs: https://review.openstack.org/#/q/status:open+topic:ubuntu-py3 https://review.openstack.org/#/q/status:open+topic:inherit_pyvers Help with these changes from any openstack-puppet Ubuntu users would obviously be appreciated here! Finally I'm currently working on the following puppet-tripleo change that makes this all usable within TripleO itself: WIP placement: Initial extraction of the Placement service from Nova https://review.openstack.org/#/c/624335/ # TripleO https://review.openstack.org/#/q/topic:tripleo-placement-extraction On the TripleO front I almost have undercloud deployment completing in a reproducer environment with various local hacks to workaround changes not being merged yet. The main tripleo-heat-template change can be found below: WIP placement: Extract the service from Nova https://review.openstack.org/#/c/630644/ # TODO Obviously there's still a lot to do here but to begin with I'll be focusing on the following tasks: - Landing the puppet-openstack-integration and puppet-tripleo changes. - Moving the tripleo-heat-templates change out of WIP. - Posting draft upgrade_tasks in a new change using the db migration script. Hopefully this is of some use to folks in the Placement and TripleO teams! Cheers, -- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76

3 2

[nova][glance] Granting image member access for snapshots (bug 1675791)
by Matt Riedemann 16 Jan '19

16 Jan '19

I have a fix proposed for a pretty old bug (1675791 [1]). This originally came up because of a scenario where an admin shelves a server and then the owner of the shelved server cannot unshelve it since they do not have access to the shelve snapshot image. The same is true for normal snapshot and backup operations though, see this proposed spec for Stein [2]. It also came up during the cross-cell resize spec review [3] since that solution depends on snapshot to get the root disk from one cell to another. In a nutshell, when creating a snapshot now, the compute API will check if the project creating the snapshot is the same as the project owner of the server. If not, the image is created with visibility=shared and the project owner of the instance is granted member access to the image, which allows them to GET the image directly via the ID, but not list it by default (the tenant user has to accept the pending membership for that). I have tested this out in devstack today and everything seems to work well. I am posting this to (a) raise awareness of the bug and proposed fix since it is sort of a behavior change in the createImage/createBackup/shelve APIs and (b) to make sure the glance team is aware and acknowledges this is an OK thing to do, i.e. are there any kind of unforeseen side effects of automatically granting image membership like this (I would think not since the owner of the instance has access to the root disk of the server anyway - it is their data). Also note that some really crusty legacy code in most of the in-tree virt drivers had to be removed (some virt drivers would change the image visibility back to private during the actual data upload to glance) which could mean out of tree drivers have the same issue. [1] https://bugs.launchpad.net/nova/+bug/1675791 [2] https://review.openstack.org/#/c/616843/ [3] https://review.openstack.org/#/c/616037/3/specs/stein/approved/cross-cell-r… -- Thanks, Matt

4 6

[dev][puppet] Register PTG team attendance
by Tobias Urdin 16 Jan '19

16 Jan '19

Dear Puppeteers, The foundation would like all projects to report if they will be attending the PTG and I'm in charge of reporting that for the Puppet OpenStack project. I'm now reaching out to hear if you are attending and would like the Puppet OpenStack project to have an official attendance and therefore possible requirements of rooms etc? I personally is not sure that I will attend the PTG even though it's directly after the Summit which I'm hoping to be able to attend this year. Earlier years we haven't had any real reasons to have dedicated rooms or events from what I know but please let me know if you have any plans. I don't think not placing our team as attending prevents anybody from actually being at the PTG, I hope not atleast (maybe somebody can shine in on that part). I need to fill in the survey by January 20th, 2019 at 7:00 UTC so please let me know urgently, sorry for the short timespan, it's entirely my fault on that part. Please get back to me if you will be attending and need to register the Puppet OpenStack team. Best regards Tobias

1 0

[openstack-discuss] [stackalytics] Stackalytics facelift
by Boris Renski 16 Jan '19

16 Jan '19

Folks, Happy New Year! We wanted to start the year by giving a facelift to stackalytics.com (based on stackalytics openstack project). Brief summary of updates: - We have new look and feel at stackalytics.com - We did away with DriverLog <http://stackalytics.com/report/driverlog> and Member Directory <http://stackalytics.com/report/members>, which were not very actively used or maintained. Those are still available via direct links, but not in the menu on the top - BIGGEST CHANGE: You can now track some of the CNCF and Unaffiliated project commits via a separate subsection accessible via top menu. Before this was all bunched up in Project Type -> Complimentary Happy to hear comments or feedback. -Boris

9 12

[publiccloud-wg][sigs] Reminder weekly meeting Public Cloud WG
by Tobias Rydberg 16 Jan '19

16 Jan '19

Hi everyone, Time for a new meeting for Public Cloud WG - tomorrow 1400 UTC in #openstack-publiccloud! Agenda found at https://etherpad.openstack.org/p/publiccloud-wg Cheers, Tobias -- Tobias Rydberg Senior Developer Twitter & IRC: tobberydberg www.citynetwork.eu | www.citycloud.com INNOVATION THROUGH OPEN IT INFRASTRUCTURE ISO 9001, 14001, 27001, 27015 & 27018 CERTIFIED

1 0

Re: [Release-job-failures] Release of openstack/puppet-* failed
by Thierry Carrez 16 Jan '19

16 Jan '19

Puppet-OpenStack Stein M2 release job (triggered after https://review.openstack.org/#/c/629753/ merged) failed for all modules with errors similar to: zuul(a)openstack.org wrote: > Build failed. > > - release-openstack-puppet http://logs.openstack.org/b1/b1434f41935eb5c4cb50fc5aea2b6406a6d0f63d/relea… : POST_FAILURE in 2m 58s > - announce-release announce-release : SKIPPED This is due to the recent introduction of a puppetforge upload job: https://review.openstack.org/#/c/627573/5/zuul.d/jobs.yaml That job tries to install a few gems and that fails because the ruby header files are not available (missing ruby-dev / ruby-devel package). Tarball upload jobs are then skipped, as well as announcement or releases.o.o documentation. Solution is probably to add that missing package to the "build" bindep.txt profile (for every affected puppet-* repository) that is loaded in pre-run of that publication job. Currently that profile only contains "puppet" and that stops short of installing the ruby development header package (at least on Ubuntu hosts). Once that's done, I recommend pushing a new Stein release for Puppet-OpenStack (similar to https://review.openstack.org/#/c/629753/, bumping .Z for all packages) so that we can test that it properly works before end-of-release crush. -- Thierry Carrez (ttx)

2 2

[neutron]
by Masha Atakova 16 Jan '19

16 Jan '19

1 0

[neutron] Patch fails to build after rechecking.
by Ni, Qi 16 Jan '19

16 Jan '19

Hello guys, I've been working on a patch of neutron https://review.openstack.org/#/c/626109/11 and it keeps failing when building. I'm sure my code is bug free and I found Liu Yulong's patch has a similar condition like mine. https://review.openstack.org/#/c/627285/. He rechecks many times and fails every time. His code is nearly the same as previous except a line of comment. I'm not sure if there's any bug on this checking system and please take a look at our issue, thank you.

2 1

[pctavia][heat] queens loadbalancer issue
by Ignazio Cassano 16 Jan '19

16 Jan '19

Hello All, I am facing an issue with octavia loadbalancer on queens. Attached here there is the heat stack I am using for frating a loadbalancer between 2 virtual machines. I launched the stack 4 times. First, second and third work fine. The forth gives a lot of errors in octavia worker log attached here. It seems to loop . Please help me. Ignazio

1 1

[heat]meeting cancelled this week
by Rico Lin 15 Jan '19

15 Jan '19

Dear team, due to some personal stuff, I will not join meeting today. Let’s resume meeting next week. -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin

1 0

[meta-sig][docs] new section for SIG documentation on docs.o.o
by Adam Spiers 15 Jan '19

15 Jan '19

For the Stein release there is now a new section for SIGs on the documentation home page: https://docs.openstack.org/stein/ Currently only the self-healing SIG has a link but if other SIGs have links to add, it won't feel so lonely ;-)

2 3

[placement] update 19-01
by Chris Dent 15 Jan '19

15 Jan '19

HTML: https://anticdent.org/placement-update-19-01.html Hello! Here's placement update 19-01. Not a ton to report this week, so this will mostly be updating the lists provided last week. # Most Important As mentioned last week, there will be a meeting next week to discuss what is left before we can pull the trigger on [deleting the placement code from nova](https://review.openstack.org/618215). Wednesday is looking like a good day, perhaps at 1700UTC, but we'll need to confirm that on Monday when more people are around. Feel free to respond on this thread if that won't work for you (and suggest an alternative). Since deleting the code is dependent on deployment tooling being able to handle extracted placement (and upgrades to it), reviewing that work is important (see below). # What's Changed * It was nova's spec freeze this week, so a lot of effort was spent getting some specs reviewed and merged. That's reflected in the shorter specs section, below. * Placement had a release and was published to [pypi](https://pypi.org/project/openstack-placement/). This was a good excuse to write (yet another) blog post on [how easy it is to play with](https://anticdent.org/placement-from-pypi.html). # Bugs * Placement related [bugs not yet in progress](https://goo.gl/TgiPXb): 14. -1. * [In progress placement bugs](https://goo.gl/vzGGDQ) 16. +1 # Specs With spec freeze this week, this will be the last time we'll see this section until near the end of this cycle. Only one of the specs listed last week merged (placement for counting quota). * <https://review.openstack.org/#/c/544683/> Account for host agg allocation ratio in placement (Still in rocky/) * <https://review.openstack.org/#/c/595236/> Add subtree filter for GET /resource_providers * <https://review.openstack.org/#/c/597601/> Resource provider - request group mapping in allocation candidate * <https://review.openstack.org/#/c/549067/> VMware: place instances on resource pool (still in rocky/) * <https://review.openstack.org/#/c/555081/> Standardize CPU resource tracking * <https://review.openstack.org/#/c/599957/> Allow overcommit of dedicated CPU (Has an alternative which changes allocations to a float) * <https://review.openstack.org/#/c/591037/> Modelling passthrough devices for report to placement * <https://review.openstack.org/#/c/603955/> Nova Cyborg interaction specification. * <https://review.openstack.org/#/c/601596/> supporting virtual NVDIMM devices * <https://review.openstack.org/#/c/552924/> Proposes NUMA topology with RPs * <https://review.openstack.org/#/c/569011/> Count quota based on resource class * <https://review.openstack.org/#/c/141219/> Adds spec for instance live resize * <https://review.openstack.org/#/c/612497/> Provider config YAML file * <https://review.openstack.org/603545> Resource modeling in cyborg. * <https://review.openstack.org/#/c/609960/> Support filtering of allocation_candidates by forbidden aggregates * <https://review.openstack.org/601596> support virtual persistent memory # Main Themes ## Making Nested Useful I've been saying for a few weeks that "progress continues on gpu-reshaping for libvirt and xen" but it looks like the work at: * <https://review.openstack.org/#/q/topic:bp/reshape-provider-tree+status:open> is actually stalled. Anyone have some insight on the status of that work? Also making use of nested is bandwidth-resource-provider: * <https://review.openstack.org/#/q/topic:bp/bandwidth-resource-provider> There's a [review guide](http://lists.openstack.org/pipermail/openstack-discuss/2018-December… for those patches. Eric's in the process of doing lots of cleanups to how often the ProviderTree in the resource tracker is checked against placement, and a variety of other "let's make this more right" changes in the same neighborhood: * Stack at: <https://review.openstack.org/#/c/615677> ## Extraction Besides the meeting mentioned above, I've refactored the extraction etherpad to make a [new version](https://etherpad.openstack.org/p/placement-extract-stein-5) that has less noise in it so the required actions are a bit more clear. The tasks remain much the same as mentioned last week: the reshaper work mentioned above and the work to get deployment tools operating with an extracted placement: * [TripleO](https://review.openstack.org/#/q/topic:tripleo-placement-extractio… * [OpenStack Ansible](https://review.openstack.org/#/q/project:openstack/openstack-ansib… * [Kolla and Kolla Ansible](https://review.openstack.org/#/q/topic:split-placement) Loci's change to have an extracted placement has merged. Kolla has a patch to [include the upgrade script](https://review.openstack.org/#/q/topic:upgrade-placement). It raises the question of how or if the `mysql-migrate-db.sh` should be distributed. Should it maybe end up in the pypi distribution? (The rest of this section is duplicated from last week.) Documentation tuneups: * Release-notes: <https://review.openstack.org/#/c/618708/> This is blocked until we refactor the release notes to reflect _now_ better. * The main remaining task here is participating in [openstack-manuals](https://docs.openstack.org/doc-contrib-guide/doc-index.h…, to that end: * <https://review.openstack.org/#/c/628183/> A stack of changes to nova to remove placement from the install docs. * <https://review.openstack.org/#/c/628220/> Install docs in placement. I wrote to the [mailing list](http://lists.openstack.org/pipermail/openstack-discuss/2019-January/0… asking for input on making sure these things are close to correct, especially with regard to distro-specific things like package names. * <https://review.openstack.org/#/c/628324> Change to openstack-manuals to assert that placement is publishing install docs. Depends on the above. * There is a patch to [delete placement](https://review.openstack.org/#/c/618215/) from nova that we've put an administrative -2 on while we determine where things are (see about the meeting above). * There's a pending patch to support [online data migrations](https://review.openstack.org/#/c/624942/). This is important to make sure that fixup commands like `create_incomplete_consumers` can be safely removed from nova and implemented in placement. # Other There are still 13 [open changes](https://review.openstack.org/#/q/project:openstack/placement+statu… in placement itself. Most of the time critical work is happening elsewhere (notably the deployment tool changes listed above). Of those placement changes, the [database-related](https://review.openstack.org/#/q/owner:nakamura.tetsuro%2… ones from Tetsuro are the most important. Outside of placement: * <https://review.openstack.org/#/q/topic:minimum-bandwidth-allocation-placeme…> Neutron minimum bandwidth implementation * <https://review.openstack.org/#/c/586960/> zun: Use placement for unified resource management * <https://review.openstack.org/#/c/621645/> WIP: add Placement aggregates tests (in tempest) * <https://review.openstack.org/627326> blazar: Consider the number of reservation inventory * <https://review.openstack.org/622316> Add placement client for basic GET operations (to tempest) # End If anyone has submitted, or is planning to, a proposal for summit that is placement-related, it would be great to hear about it. I had thought about doing a resilient placement in kubernetes with cockroachdb for the edge sort of thing, but then realized my motivations were suspect and I have enough to do otherwise. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

2 1

[neutron][qos][dpdk] is QoS supported with DPDK
by cristian.calin＠orange.com 15 Jan '19

15 Jan '19

Hi all, Is QoS supported when DPDK is leveraged on the openvswitch? >From what I can tell the two are incompatible but I'm hoping someone has some information otherwise. Thanks, Cristian Calin _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.

2 1

[self-healing-sig] best practices for haproxy health checking
by Dirk Müller 15 Jan '19

15 Jan '19

Hi, Does anyone have a good pointer for good healthchecks to be used by the frontend api haproxy loadbalancer? in one case that I am looking at right now, the entry haproxy loadbalancer was not able to detect a particular backend being not responding to api requests, so it flipped up and down repeatedly, causing intermittend spurious 503 errors. The backend was able to respond to connections and to basic HTTP GET requests (e.g. / or even /v3 as path), but when it got a "real" query it hung. the reason for that was, as it turned out, the configured caching backend memcached on that machine being locked up (due to some other bug). I wonder if there is a better way to check if a backend is "working" and what the best practices around this are. A potential thought I had was to do the backend check via some other healthcheck specific port that runs a custom daemon that does more sophisticated checks like checking for system wide errors (like memcache, database, rabbitmq) being unavailable on that node, and hence not accepting any api traffic until that is being resolved. Any pointers to read upon / best practices appreciated. Thanks, Dirk

3 2

Training
by Alfredo De Luca 15 Jan '19

15 Jan '19

Hi all. I am looking for openstack training both basic and advanced here in Italy or Europe. Possibly instructor led on site. Any suggestions? -- *Alfredo*

2 2