- openstack-discuss - lists.openstack.org

[glance] functional-py35 job fails due to subunit.praser error
by Abhishek Kekane 14 Dec '18

14 Dec '18

Hi All, >From 7th December 2018, all of sudden functional-py35 check job is failing on current master. Earlier this job was failing intermittently (2-3 times from 100). I have tried to dig into the issue and find out that it is failing obly for ubuntu and working fine with Fedora, centos etc. Below are some of the findings: 1. Even if I add failure tests [1] in black-list file every time other tests reported as failure. 2. When I compared failed tests results [1] with passed tests results [2] I have found that passing tests shows 'Pass 741 Skip 7' whereas failing tests shows 'Pass 627 Failure 9 Skip 5' (it does not execute all the tests in case of failure) 3. I have compared version of subunit, oslo.service, oslo.log, tox with failed [3] and passed [4] logs and they are same. 4. I came across a bug in cinder [5] which talks about excessive logs might cause this error and I have tried to ignore the deprecation warning in tox.ini by adding 'PYTHONWARNINGS=ignore::DeprecationWarning' but it still shows DeprecationWarning in the logs. 5. I have tried executing tests by setting '--concurrency' to 1 but still the error persists. 6. Whenver subunit.parser error occurs the tests remains 'inprogress' state and sometimes time-outs. I have no clues so far to tackle this issue, kindly provide your inputs for the same. [1] http://logs.openstack.org/89/617889/4/check/openstack-tox-functional-py35/4… [2] http://logs.openstack.org/89/617889/4/check/openstack-tox-functional-py35/3… [3] http://logs.openstack.org/89/617889/4/check/openstack-tox-functional-py35/4… [4] http://logs.openstack.org/89/617889/4/check/openstack-tox-functional-py35/3… [5] https://bugs.launchpad.net/cinder/+bug/1728640 Thanks & Best Regards, Abhishek Kekane

6 6

[goals][upgrade-checkers] Week R-17 Update
by Matt Riedemann 14 Dec '18

14 Dec '18

A few updates this week. * Some more projects have merged the base framework patch (tricircle, vitrage and zaqar). Open changes are here [1]. * Neutron has a change up to add support for loading upgrade checkers via extension point for stadium projects [2]. * There are two projects for which it may or may not make sense to add the upgrade check CLI: 1. mistral [3] - there seems to be concern about how useful the upgrade checker tool could be for mistral. I can't say I know enough about mistral or how it works, but if it is more like horizon and is stateless then maybe it's not a good fit, but I assume mistral has state (it tracks workflows right? So if it gets a start event, presumably it's tracking that to wait for an end event). When I looked over the mistral release notes I had a hard time finding anything worth adding automated checks during an upgrade. However, there is a deprecation note from queens which says, "The YAQL/jinja2 expression function json_pp has been deprecated and will be removed in the S cycle. json_dump should be used instead." I would think that when removing that function, if it's possible to determine it is being used somehow (can that be determined from the database?), then an upgrade check would be useful for that. 2. swift [4] - John has concerns that adding this to swift will expand the scope of the project to provide management functionality which the project has avoided thus far. Again, when I was looking over swift release notes for this goal I never found anything that looked like an obvious upgrade impact so if it's not useful and would set a bad precedent for the project, then I'd be OK with omitting this goal for swift. [1] https://review.openstack.org/#/q/topic:upgrade-checkers+status:open [2] https://review.openstack.org/#/c/615196/ [3] https://review.openstack.org/#/c/611513/ [4] https://review.openstack.org/#/c/611634/ -- Thanks, Matt

1 0

Nova live migration fails - InvalidCPUInfo: Unacceptable CPU info: CPU doesn't have compatibility.
by Torin Woltjer 14 Dec '18

14 Dec '18

Having issues getting live migrations to functions between two compute nodes. One is an Opteron G4 and the other is an Opteron G5. I can migrate from the G4 to the G5 just fine. When I try to migrate an instance from the G5 node to the G4 node I get an error message: InvalidCPUInfo: Unacceptable CPU info: CPU doesn't have compatibility. This is despite having the following setting in my /etc/nova/nova.conf on the G5 machine. [libvirt] cpu_mode = custom cpu_model = Opteron_G4 Is this not the setting I'm looking for? What can I do to make this work? Torin Woltjer Grand Dial Communications - A ZK Tech Inc. Company 616.776.1066 ext. 2006 www.granddial.com

5 4

Re: Nova live migration fails - InvalidCPUInfo: Unacceptable CPU info: CPU doesn't have compatibility.
by Torin Woltjer 14 Dec '18

14 Dec '18

I've restarted the instances that I'm using to test but no luck. I have the setting set on just the highest compute node; I tried setting it on one of my older gen compute nodes as well but because there is production load on it, I am anxious about restarting services; I did restart the nova-compute service after making the change and there was no change in behavior. Should the setting also be set on the controllers? When I look at virsh capabilities there is certainly a difference between the two 7c7 < <model>Opteron_G5</model> --- > <model>Opteron_G4</model> 9c9 < <microcode version='100665426'/> --- > <microcode version='100664894'/> 15d14 < <feature name='bmi1'/> 25c24 < <feature name='tce'/> --- > <feature name='lwp'/> I look at the test instance on the compute node with the G5 opteron and this is in the XML <cpu mode='custom' match='exact' check='full'> <model fallback='forbid'>Opteron_G4</model> <topology sockets='1' cores='1' threads='1'/> <feature policy='require' name='vme'/> <feature policy='require' name='x2apic'/> <feature policy='require' name='hypervisor'/> <feature policy='disable' name='rdtscp'/> </cpu> This looks like it is correctly taking the CPU model that I have specified in nova.conf, yet it does not want to migrate to the Opteron_G4 node.

3 2

[dev][keystone] Keystone Team Update - Week of 10 December 2018
by Colleen Murphy 14 Dec '18

14 Dec '18

# Keystone Team Update - Week of 10 December 2018 ## News ### Policy questions We had some topics related to RBAC and policy come up in discussions this week. We had an exchange over whether the reader role is really sufficient to describe the ability to read resources currently restricted to admins as well as resources currently restricted to members, or if those are really two different kinds of read levels[1][2]. We also discussed our current work on default roles with the cinder team[3] in light of their work on documenting some best practices for policy configuration in cinder[4]. Finally, in our efforts to convert our own policies to use the default roles[5], we're starting to deep-dive into the APIs to uncover their intentions, their current protections, and the most sensible default policies for them. [1] http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000888… [2] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-k… [3] http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000875… [4] https://review.openstack.org/624424 [5] https://review.openstack.org/#/q/status:open+topic:implement-default-roles ### Cleaning up old specs At the weekly meeting we tangented from another topic to note that we've been doing a bad job of pruning the specs backlog and that we should organize some process around regularly reevaluating and prioritizing things in it[6]. [6] http://eavesdrop.openstack.org/meetings/keystone/2018/keystone.2018-12-11-1… ### Immutable Roles and Resource Options for All Morgan proposed a new spec[7] to lay the ground work for implementing resource options for most or all resources in keystone, similar to the user options we have now that lets us control MFA rights and PCI-DSS restrictions. We'd then like to build on this to make some resources, especially roles, immutable[8] or locked in order to prevent accidentally deleting deployment-critical resources, which we know has happened to more than one person. [7] https://review.openstack.org/624692 [8] https://review.openstack.org/624162 ## Open Specs Stein specs: https://bit.ly/2Pi6dGj Ongoing specs: https://bit.ly/2OyDLTh We merged the JWT spec[9] and the domain limits spec[10]. Morgan proposed a new spec for Stein[11] although we are past the spec proposal freeze date. We may decide to push it to Train, but that will also delay starting on the new immutable resources spec[12]. [9] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/stein/js… [10] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/stein/do… [11] https://review.openstack.org/624162 [12] https://review.openstack.org/624692 ## Recently Merged Changes Search query: https://bit.ly/2pquOwT We merged 38 changes this week. These included cleanup work to finish the documentation consolidation that we started a while ago, as well as several patches for default roles policy updates. ## Changes that need Attention Search query: https://bit.ly/2RLApdA There are 98 changes that are passing CI, not in merge conflict, have no negative reviews and aren't proposed by bots. These are mainly still the default roles policy changes from Lance. ## Bugs This week we opened 5 new bugs and closed 5. Bugs opened (5) Bug #1807751 (keystone:Wishlist) opened by Morgan Fainberg https://bugs.launchpad.net/keystone/+bug/1807751 Bug #1807697 (keystone:Undecided) opened by Yang Youseok https://bugs.launchpad.net/keystone/+bug/1807697 Bug #1807805 (keystone:Undecided) opened by Zhongcheng Lao https://bugs.launchpad.net/keystone/+bug/1807805 Bug #1808059 (keystone:Undecided) opened by David Vallee Delisle https://bugs.launchpad.net/keystone/+bug/1808059 Bug #1808305 (python-keystoneclient:Undecided) opened by Neha Alhat https://bugs.launchpad.net/python-keystoneclient/+bug/1808305 Bugs closed (2) Bug #1802136 (keystone:Undecided) https://bugs.launchpad.net/keystone/+bug/1802136 Bug #1808059 (keystone:Undecided) https://bugs.launchpad.net/keystone/+bug/1808059 Bugs fixed (3) Bug #1794376 (keystone:High) fixed by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1794376 Bug #1803780 (keystone:Low) fixed by Adam Young https://bugs.launchpad.net/keystone/+bug/1803780 Bug #1803940 (keystonemiddleware:Wishlist) fixed by Artem Vasilyev https://bugs.launchpad.net/keystonemiddleware/+bug/1803940 ## Milestone Outlook https://releases.openstack.org/stein/schedule.html ## Help with this newsletter Help contribute to this newsletter by editing the etherpad: https://etherpad.openstack.org/p/keystone-team-newsletter Dashboard generated using gerrit-dash-creator and https://gist.github.com/lbragstad/9b0477289177743d1ebfc276d1697b67

1 0

[tc] Creation of OSF project confirmation guidelines
by Thierry Carrez 14 Dec '18

14 Dec '18

Hi everyone, As you may know, a sub group of the OSF Board of Directors has recently kicked off an effort to draft guidelines on how to confirm OSF pilot projects as full, top-level, open infrastructure projects of the Foundation. The current pilot projects that will be eligible for confirmation review in 2019-2020 are Airship, Kata Containers, StarlingX and Zuul. Currently the OpenStack project is the only confirmed project. The discussion about drafting these guidelines is just getting started, but everyone can participate in this effort by reviewing the context and working draft on this etherpad and adding feedback and thoughts at the bottom: https://etherpad.openstack.org/p/BrainstormingOSFProjectConfirmationGuideli… There will most likely be some open call scheduled in early 2019 where additional feedback will also be gathered. The goal is to come up with a set of points that the Board can use when reviewing pilot projects for confirmation. This topic has previously been discussed at a very high-level at previous Board meetings, including the September 18th meeting[1] (starting around slide 38). [1] https://docs.google.com/presentation/d/10UyCpxkjPqC3kT-dYRpBxzNT39i2OhlggJv… -- Thierry Carrez (ttx)

1 0

[tosca-parser] Need new release of tosca-parser library
by Singh, Niraj 14 Dec '18

14 Dec '18

Hi Team, Heat-translator patch [1] is dependent on tosca-parser changes that is already merged in patch [2]. We need new tosco-parser release so that we can add the new release version in heat-translator and proceed further with the review. And tacker patch [3] is dependent on heat-translator [1]. So we also need new release of heat-translator after merging the new changes so that it can be used by tacker changes to successfully work with new functionality. Please let me know the plan when you will release tosco-parse library. [1] https://review.openstack.org/#/c/619154/ heat-translator [2] https://review.openstack.org/#/c/612973/ tosco-parser [3] https://review.openstack.org/#/c/622888/ tacker Best Regards, Niraj Singh | System Analyst| NTT DATA Global Delivery Services Ltd.| w. +91.20.6604.1500 x 403|m.8055861633| Niraj.Singh(a)nttdata.com<mailto:Niraj.Singh@nttdata.com> Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding.

4 6

deploy compute node failed
by Lior Fellus 14 Dec '18

14 Dec '18

Hi All while trying to add compute to my environment i get error and this message in log: (/Stage[main]/Main/Exec[sync_time_shell]/returns) change from notrun to 0 failed: /bin/bash "/etc/puppet/shell_manifests/sync_time_command.sh" returned 1 instead of one of [0] there is connection between the fuel and the node and ntp service is up on fuel i am using Mirantis openstack mitaka. any suggestions? Thanks, Lior

1 0

can't login to baremetal deploid with ironic
by Manuel Sopena Ballesteros 14 Dec '18

14 Dec '18

3 4

Re: Fwd: openstack queens magnum error
by Feilong Wang 14 Dec '18

14 Dec '18

Seems your master node can't talk to your keystone, can you confirm that? On 13/12/18 11:08 AM, Ignazio Cassano wrote: > Hello Feilong, this forwarding contains logs. > Thanks > > ---------- Forwarded message --------- > From: *Ignazio Cassano* <ignaziocassano(a)gmail.com > <mailto:ignaziocassano@gmail.com>> > Date: Mer 12 Dic 2018 10:06 > Subject: openstack queens magnum error > To: OpenStack Operators <openstack-operators(a)lists.openstack.org > <mailto:openstack-operators@lists.openstack.org>> > > > Hello Everyone, > > I installed queens on centos with magnum and I am trying to create a > swarm cluster with one muster and one node. The image I used is > fedora-atomic 27 update 04 > > The stack generated end with an error and magnum conductor reports: > ec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 09:51:17.304 > 17964 WARNING magnum.drivers.heat.template_def > [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] stack does not > have output_key api_address > Dec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 > 09:51:17.305 17964 WARNING magnum.drivers.heat.template_def > [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] stack does not > have output_key swarm_masters > Dec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 > 09:51:17.306 17964 WARNING magnum.drivers.heat.template_def > [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] stack does not > have output_key swarm_nodes > Dec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 > 09:51:17.306 17964 WARNING magnum.drivers.heat.template_def > [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] stack does not > have output_key discovery_url > Dec 12 09:51:17 tst2-osctrl01 magnum-conductor: 2018-12-12 > 09:51:17.317 17964 ERROR magnum.drivers.heat.driver > [req-bfa19294-5671-47a0-b0ac-9e544f0e5e38 - - - - -] Cluster error, > stack status: CREATE_FAILED, stack_id: > 306bd83a-7878-4d94-8ed0-1d297eec9768, reason: Resource CREATE failed: > WaitConditionFailure: > resources.swarm_nodes.resources[0].resources.node_wait_condition: > swarm-agent service failed to start. > > > > I connected to the master node for verifyng if swarm agent is running. > In the cloud init log I found: > requests.exceptions.ConnectionError: > HTTPConnectionPool(host='10.102.184.190', port=5000): Max retries > exceeded with url: /v3//auth/tokens (Caused by > NewConnectionError('<urllib3.connection.HTTPConnection object at > 0x7f0814d4d250>: Failed to establish a new connection: [Errno 110] > Connection timed out',)) > Cloud-init v. 0.7.9 running 'modules:final' at Wed, 12 Dec 2018 > 08:45:31 +0000. Up 55.54 seconds. > 2018-12-12 08:47:45,858 - util.py[WARNING]: Failed running > /var/lib/cloud/instance/scripts/part-005 [1] > /var/lib/cloud/instance/scripts/part-006: line 13: > /etc/etcd/etcd.conf: No such file or directory > /var/lib/cloud/instance/scripts/part-006: line 26: > /etc/etcd/etcd.conf: No such file or directory > /var/lib/cloud/instance/scripts/part-006: line 38: > /etc/etcd/etcd.conf: No such file or directory > 2018-12-12 08:47:45,870 - util.py[WARNING]: Failed running > /var/lib/cloud/instance/scripts/part-006 [1] > Configuring docker network ... > Configuring docker network service ... > Removed > /etc/systemd/system/multi-user.target.wants/docker-storage-setup.service. > New size given (1280 extents) not larger than existing size (4863 > extents) > ERROR: There is not enough free space in volume group atomicos to > create data volume of size MIN_DATA_SIZE=2G. > 2018-12-12 08:47:46,206 - util.py[WARNING]: Failed running > /var/lib/cloud/instance/scripts/part-010 [1] > + systemctl stop docker > + echo 'starting services' > starting services > + systemctl daemon-reload > + for service in etcd docker.socket docker swarm-manager > + echo 'activating service etcd' > activating service etcd > + systemctl enable etcd > Failed to enable unit: Unit file etcd.service does not exist. > + systemctl --no-block start etcd > Failed to start etcd.service: Unit etcd.service not found. > + for service in etcd docker.socket docker swarm-manager > + echo 'activating service docker.socket' > activating service docker.socket > + systemctl enable docker.socket > > > 1) Seems etcd service is not installed , > > 2) the instance required to contact controller on port 5000 (is it > correct ?) > > > Please help me. > > Regards > Ignazio > > -- Cheers & Best regards, Feilong Wang (王飞龙) -------------------------------------------------------------------------- Senior Cloud Software Engineer Tel: +64-48032246 Email: flwang(a)catalyst.net.nz Catalyst IT Limited Level 6, Catalyst House, 150 Willis Street, Wellington --------------------------------------------------------------------------

3 5