May 2019 - openstack-discuss - lists.openstack.org

[placement][nova][ptg] resource provider affinity
by Chris Dent 09 May '19

09 May '19

Spec: https://review.openstack.org/650476 >From the commit message: To support NUMA and similar concepts, this proposes the ability to request resources from different providers nested under a common subtree (below the root provider). There's much in the feature described by the spec and the surrounding context that is frequently a source of contention in the placement group, so working through this spec is probably going to require some robust discussion. Doing most of that before the PTG will help make sure we're not going in circles in person.k Some of the areas of potential contention: * Adequate for limited but maybe not all use case solutions * Strict trait constructionism * Evolving the complexity of placement solely for the satisfaction of hardware representation in Nova * Inventory-less resource providers * Developing new features in placement before existing features are fully used in client services * Others? I list this not because they are deal breakers or the only thing that matters, but because they have presented stumbling blocks in the past and we may as well work to address them (or make an agreement to punt them until later) otherwise there will be lingering dread. And, beyond all that squishy stuff, there is the necessary discussion over the solution described in the spec. There are several alternatives listed in the spec, and a few more in the comments. We'd like to figure out the best solution that can actually be done in a reasonable amount of time, not the best solution in the absolute. Discuss! -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

10 37

[nova][neutron][ptg] Summary: Leaking resources when ports are deleted out-of-band
by Eric Fried 09 May '19

09 May '19

Summary: When a port is deleted out of band (while still attached to an instance), any associated QoS bandwidth resources are orphaned in placement. Consensus: - Neutron to block deleting a port whose "owner" field is set. - If you really want to do this, null the "owner" field first. - Nova still needs a way to delete the port during destroy. To be discussed. Possibilities: - Nova can null the "owner" field first. - The operation can be permitted with a certain policy role, which Nova would have to be granted. - Other? efried .

5 9

[tripleo][openstack-ansible] collaboration on os_tempest role update 21 - May 09, 2019
by Chandan kumar 09 May '19

09 May '19

Hello, Here is the 21th update (Apr 24 to May 09, 2019) on collaboration on os_tempest[1] role between TripleO and OpenStack-Ansible projects. Due to Denver Train PTG, we have skipped the last week report. Highlights of Update 21: * We removed install_test_requirements flag in os_tempest as all the tempest plugins have their requirements specified in requirements.txt, so let's use that instead of using test_requirements.txt also. * All the upstream TripleO CI standalone base, scenario1-4 and puppet standalone jobs are running tempest using os_tempest. Thanks to Arx for porting jobs to os_tempest and odyssey4me for bring back the gate alive. >From Denver Train PTG: Wes made a nice os_tempest tripleo asci video: https://asciinema.org/a/rm7LDAs6RAR1xh7oQrp07LaeR OSA project update from summit: https://www.youtube.com/watch?v=JZet1uNAr_o&t=868s Things got merged: os_tempest: * Remove install_test_requirements flag - https://review.opendev.org/657778 * Temporarily set bionic job to non-voting - https://review.opendev.org/657833 os_cinder: * Set glance_api_version=2 in cinder.conf - https://review.opendev.org/653308 Tripleo: * Enable os_tempest in baremetal-full-overcloud-validate playbook - https://review.opendev.org/652983 * Set gather_facts to false while calling tempest playbook - https://review.opendev.org/653702 * Port tripleo-ci-centos-7-scenario001-standalone to os_tempest - https://review.opendev.org/655870 * Port scenario002-standalone-master to os_tempest - https://review.opendev.org/656259 * Port puppet-keystone-tripleo-standalone to os_tempest - https://review.opendev.org/656474 * Port puppet-swift-tripleo-standalone to os_tempest - https://review.opendev.org/656481 * Port puppet-nova-tripleo-standalone to os_tempest - https://review.opendev.org/656480 * Port puppet-neutron-tripleo-standalone job to os_tempest - https://review.opendev.org/656479 * Switch scenario003-standalone job to use os_tempest - https://review.opendev.org/656290 * Port scenario004-standalone-master to os_tempest - https://review.opendev.org/656291 * Port puppet-horizon-tripleo-standalone to os_tempest - https://review.opendev.org/656758 * Port puppet-cinder-tripleo-standalone to os_tempest - https://review.opendev.org/656752 * Port puppet-glance-tripleo-standalone to os_tempest - https://review.opendev.org/656753 * Port standalone job to os_tempest - https://review.opendev.org/656748 Things in progress: os_tempest: * Replace tempestconf job with aio_distro_metal-tempestconf job - https://review.opendev.org/657359 * Update openstack.org -> opendev.org - https://review.opendev.org/654942 * Make smoke tests as a default whitelist tests - https://review.opendev.org/652060 on TripleO/OSA side, we will be working on enabling heat tempest plugin support. Here is the 20th update [2]. Have queries, Feel free to ping us on #tripleo or #openstack-ansible channel. Links: [1.] http://opendev.org/openstack/openstack-ansible-os_tempest [2.] http://lists.openstack.org/pipermail/openstack-discuss/2019-April/005563.ht… Thanks, Chandan Kumar

1 0

kolla-ansible pike - nova_compute containers not starting
by Shyam Biradar 09 May '19

09 May '19

Hi, I am setting up all-in-one ubuntu based kolla-ansible pike openstack. Deployment is failing at following ansible task: TASK [nova : include_tasks] ********************************************************************************************************************** included: /root/virtnev/share/kolla-ansible/ansible/roles/nova/tasks/discover_computes.yml for localhost TASK [nova : Waiting for nova-compute service up] ************************************************************************************************ FAILED - RETRYING: Waiting for nova-compute service up (20 retries left). FAILED - RETRYING: Waiting for nova-compute service up (19 retries left). FAILED - RETRYING: Waiting for nova-compute service up (18 retries left). FAILED - RETRYING: Waiting for nova-compute service up (17 retries left). FAILED - RETRYING: Waiting for nova-compute service up (16 retries left). FAILED - RETRYING: Waiting for nova-compute service up (15 retries left). FAILED - RETRYING: Waiting for nova-compute service up (14 retries left). FAILED - RETRYING: Waiting for nova-compute service up (13 retries left). FAILED - RETRYING: Waiting for nova-compute service up (12 retries left). FAILED - RETRYING: Waiting for nova-compute service up (11 retries left). FAILED - RETRYING: Waiting for nova-compute service up (10 retries left). FAILED - RETRYING: Waiting for nova-compute service up (9 retries left). FAILED - RETRYING: Waiting for nova-compute service up (8 retries left). FAILED - RETRYING: Waiting for nova-compute service up (7 retries left). FAILED - RETRYING: Waiting for nova-compute service up (6 retries left). FAILED - RETRYING: Waiting for nova-compute service up (5 retries left). FAILED - RETRYING: Waiting for nova-compute service up (4 retries left). FAILED - RETRYING: Waiting for nova-compute service up (3 retries left). FAILED - RETRYING: Waiting for nova-compute service up (2 retries left). FAILED - RETRYING: Waiting for nova-compute service up (1 retries left). fatal: [localhost -> localhost]: FAILED! => {"attempts": 20, "changed": false, "cmd": ["docker", "exec", "kolla_toolbox", "openstack", "--os-interface", "internal", "--os-auth-url", "http://192.168.122.151:35357", "--os-identity-api-version", "3", "--os-project-domain-name", "default", "--os-tenant-name", "admin", "--os-username", "admin", "--os-password", "ivpu1km8qxnVQESvAF4cyTFstOvrbxGUHjFF15gZ", "--os-user-domain-name", "default", "compute", "service", "list", "-f", "json", "--service", "nova-compute"], "delta": "0:00:02.555356", "end": "2019-05-02 09:24:45.485786", "rc": 0, "start": "2019-05-02 09:24:42.930430", "stderr": "", "stderr_lines": [], "stdout": "[]", "stdout_lines": ["[]"]} -------------------------------------------------------------------- I can see following stack trace in nova-compute container log 4. 2019-05-02 08:21:30.522 7 INFO nova.service [-] Starting compute node (version 16.1.7) 2019-05-02 08:21:30.524 7 ERROR oslo_service.service [-] Error starting thread.: PlacementNotConfigured: This compute is not configured to talk to the placement service. Configure the [placement] section of nova.conf and restart the service. 2019-05-02 08:21:30.524 7 ERROR oslo_service.service Traceback (most recent call last): 2019-05-02 08:21:30.524 7 ERROR oslo_service.service File "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_service/service.py", line 721, in run_service 2019-05-02 08:21:30.524 7 ERROR oslo_service.service service.start() 2019-05-02 08:21:30.524 7 ERROR oslo_service.service File "/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/service.py", line 156, in start 2019-05-02 08:21:30.524 7 ERROR oslo_service.service self.manager.init_host() 2019-05-02 08:21:30.524 7 ERROR oslo_service.service File "/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/compute/manager.py", line 1155, in init_host 2019-05-02 08:21:30.524 7 ERROR oslo_service.service raise exception.PlacementNotConfigured() 2019-05-02 08:21:30.524 7 ERROR oslo_service.service PlacementNotConfigured: This compute is not configured to talk to the placement service. Configure the [placement] section of nova.conf and restart the service. 2019-05-02 08:21:30.524 7 ERROR oslo_service.service 2019-05-02 08:21:59.229 7 INFO os_vif [-] Loaded VIF plugins: ovs, linux_bridge --------------------------------------------------------------------- I saw nova-compute nova.conf has [placement] section configured well and it's same as nova_api's placement section. Other nova containers are started well. Any thoughts? [image: logo] *Shyam Biradar* * Software Engineer | DevOps* M <M%20617.308.9017>+91 8600266938 | shyam.biradar(a)trilio.io | trilio.io

2 1

[tc] Proposal: restrict TC activities
by Emmet Hikory 09 May '19

09 May '19

All, I’ve spent the last few years watching the activities of the technical committee , and in recent cycles, I’m seeing a significant increase in both members of our community asking the TC to take action on things, and the TC volunteering to take action on things in the course of internal discussions (meetings, #openstack-tc, etc.). In combination, these trends appear to have significantly increased the amount of time that members of the technical committee spend on “TC work”, and decreased the time that they spend on other activities in OpenStack. As such, I suggest that the Technical Committee be restricted from actually doing anything beyond approval of merges to the governance repository. Firstly, we select members of the technical committee from amongst those of us who have some of the deepest understanding of the entire project and frequently those actively involved in multiple projects and engaged in cross-project coordination on a regular basis. Anything less than this fails to produce enough name recognition for election. As such, when asking the TC to be responsible for activities, we should equally ask whether we wish the very people responsible for the efficiency of our collaboration to cease doing so in favor of whatever we may have assigned to the TC. Secondly, in order to ensure continuity, we need to provide a means for rotation of the TC: this is both to allow folk on the TC to pursue other activities, and to allow folk not on the TC to join the TC and help with governance and coordination. If we wish to increase the number of folk who might be eligible for the TC, we do this best by encouraging them to take on activities that involve many projects or affect activities over all of OpenStack. These activities must necessarily be taken by those not current TC members in order to provide a platform for visibility to allow those doing them to later become TC members. Solutions to both of these issues have been suggested involving changing the size of the TC. If we decrease the size of the TC, it becomes less important to provide mechanisms for new people to develop reputation over the entire project, but this ends up concentrating the work of the TC to a smaller number of hands, and likely reduces the volume of work overall accomplished. If we increase the size of the TC, it becomes less burdensome for the TC to take on these activities, but this ends up foundering against the question of who in our community has sufficient experience with all aspects of OpenStack to fill the remaining seats (and how to maintain a suitable set of folk to provide TC continuity). If we instead simply assert that the TC is explicitly not responsible for any activities beyond governance approvals, we both reduce the impact that being elected to the TC has on the ability of our most prolific contributors to continue their activities and provide a means for folk who have expressed interest and initiative to broadly contribute and demonstrate their suitability for nomination in a future TC election Feedback encouraged -- Emmet HIKORY

5 5

[sigs][publiccloud][publiccloud-wg] Reminder meeting this afternoon for Public Cloud WG/SIG
by Tobias Rydberg 09 May '19

09 May '19

Hi all, This is a reminder for todays meeting for the Public Cloud WG/SIG - 1400 UTC in #openstack-publiccloud. Agenda at: https://etherpad.openstack.org/p/publiccloud-wg See you all later! 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

[Glance] No team meeting today
by Erno Kuvaja 09 May '19

09 May '19

Hi all, There is no agenda items proposed for todays meeting and I'm still traveling after the Summit/PTG so we will not have weekly meeting today. Lets resume to the normal from next week onwards. Thanks all! Best, Erno "jokke_" Kuvaja

1 0

[tripleo] CI RED fyi.. something is causing both overcloud network configuration issues atm
by Wesley Hayutin 08 May '19

08 May '19

Seem the jobs go red at midnight May 9th UTC. What I'm mainly seeing is the overcloud hang after the ssh keys are created, it seems the overcloud nodes do not have network connectivity. http://logs.openstack.org/47/657547/5/check/tripleo-ci-centos-7-containers-… http://logs.openstack.org/47/657547/5/check/tripleo-ci-centos-7-containers-… This looks normal eth0, eth1 come up http://logs.openstack.org/47/657547/5/check/tripleo-ci-centos-7-containers-… I'm not 100% if this related to some of the latest patches, or if this impacts all jobs atm. Looking into it.

1 1

[telemetry] Team meeting agenda for tomorrow
by Trinh Nguyen 08 May '19

08 May '19

Hi team, As planned, we will have a team meeting at 02:00 UTC, May 9th on #openstack-telemetry to discuss what we gonna do for the next milestone (Train-1) and continue what we left off from the last meeting. I put here [1] the agenda thinking that it should be fine for an hour meeting. If you have anything to talk about, please put it there too. [1] https://etherpad.openstack.org/p/telemetry-meeting-agenda Bests, -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

2 4

[cinder] Python3 requirements for Train
by Walter Boring 08 May '19

08 May '19

Hello Cinder folks, The train release is going to be the last release of OpenStack with python 2 support. Train also is going to require supporting python 3.6 and 3.7. This means that we should be enabling and or switching over all of our 3rd party CI runs to python 3 to ensure that our drivers and all of their required libraries run properly in a python 3.6/3.7 environment. This will help driver maintainers discover any python3 incompatibilities with their driver as well as any required libraries. At the PTG in Denver, the cinder team agreed that we wanted driver CI systems to start using python3 by milestone 2 for Train. This would be the July 22-26th time frame [1]. We are also working on adding driver library requirements to the OpenStack global requirements project [2] [3]. This effort will provide native install primitives for driver libraries in cinder. This process also requires the driver libraries to run in python3.6/3.7. The Cinder team wants to maintain it's high quality of driver support in the train release. By enabling python 3.6 and python 3.7 in CI tests, this will help everyone ship Cinder with the required support in Train and the following releases. Walt [1] https://releases.openstack.org/train/schedule.html [2] https://review.opendev.org/#/c/656724/ [3] https://review.opendev.org/#/c/657395/

3 2