- openstack-discuss - lists.openstack.org

Openstack Magnum
by Alfredo De Luca 18 Dec '18

18 Dec '18

Hi all. Just installed *openstack* and *magnum* with *ansible-openstack AIO.* All works well except magnum itself. When I click on the dashboard on* Container Infra *then C*lusters or clusters templates *I get the following errors: *Error: *Unable to retrieve the clusters. *Error: *Unable to retrieve the stats. - Not sure why. Any clue? Cheers -- *Alfredo*

3 8

[publiccloud]Choice of deployment tools
by Cody 18 Dec '18

18 Dec '18

Hello stackers, What deployment tools would be of your choice for deploying a public IaaS with an initial size of 200~300 nodes? Would TripleO be suitable for this cluster size? Thank you very much. Wish you all a happy holiday season! Best regards, Cody

5 7

[neutron][qos] IRC meeting Jan 1, 2019
by Rodolfo Alonso 18 Dec '18

18 Dec '18

Hello: Next meeting on January 1, 2019, is canceled. The next meeting of the Neutron QoS subteam will be on January 15, 2019. Regards.

1 0

Denver Open Infrastructure Summit CFP Open
by Ashlee Ferguson 18 Dec '18

18 Dec '18

Hi everyone, The OpenStack Summit has a new name! To reflect our evolving community, the first Open Infrastructure Summit <https://www.openstack.org/summit/denver-2019/> will be held in Denver, Colorado April 29 - May 1, 2019. The Call for Presentations (CFP) is now open, and the deadline to submit your presentations, panels, and workshops <https://www.openstack.org/summit/denver-2019/call-for-presentations> is Wednesday, January 23 at 11:59pm PT (January 24 at 7:59am UTC). Here are the Summit Tracks <https://www.openstack.org/summit/denver-2019/summit-categories> as well as the Programming Committee nomination form <https://openstackfoundation.formstack.com/forms/openstackdenver2019_program…> if you are interested in helping shape the content of the Summit. The content submission process for the Forum and Project Teams Gathering will be managed separately in the upcoming months. SUBMIT YOUR PRESENTATION <https://www.openstack.org/summit/denver-2019/call-for-presentations> New for the Denver Summit: Based on previous track chair and attendee feedback, we have added / updated three Tracks: Security, Getting Started, Open Development. You can find the Track descriptions here <https://www.openstack.org/summit/denver-2019/summit-categories>. In addition to OpenStack, you’ll see the OSF pilot projects —Airship, Kata Containers, StarlingX and Zuul —front and center alongside Ansible, Cloud Foundry, Docker, Kubernetes, and many more. The Open Infrastructure Summit, has evolved to recognize our diverse audience, and to signal to the market that the event is relevant for all IT infrastructure decision makers. We are working with the Programming Committee members to share the topics they’re looking for within each Track. Stay tuned on Superuser as we post these recommendations. If you’re interested in influencing the Summit content, apply to be a Programming Committee member <https://openstackfoundation.formstack.com/forms/openstackdenver2019_program…>*, where you can also find a full list of time requirements and expectations. Nominations will close on January 4, 2019. *OSF Staff will serve as the Programming Committee for the Getting Started Track. Denver Summit registration and sponsor sales are currently open. Learn more <https://www.openstack.org/summit/denver-2019> Please email speakersupport(a)openstack.org <mailto:speakersupport@openstack.org> with any questions or feedback. Cheers, Ashlee Ashlee Ferguson OpenStack Foundation ashlee(a)openstack.org

1 0

Firefox context search text across openstack related websites like codesearch, logstash, launchpad
by Sorin Sbarnea 18 Dec '18

18 Dec '18

As many of us have to search for pieces of text on many places, like codesearch, logstash,.... I invested some time in making this possible with a right-click. Warning: requires Firefox extension. Details https://github.com/openstack/coats#context-search-for-firefox <https://github.com/openstack/coats#context-search-for-firefox> I hope it would make your life easier. PS. Improvements on the search engines definition files are welcomed, on Gerrit :) Cheers, Sorin Sbarnea

1 0

[TripleO] flattening tripleo-heat-templates: what about pacemaker?
by Cédric Jeanneret 18 Dec '18

18 Dec '18

Hello folks, While working on the service flattening in t-h-t, I have some question regarding the pacemaker things. If we take rabbitmq: - we have rabbitmq things in docker/services - we have rabbitmq things in puppet/services - we have rabbitmq things in docker/services/pacemaker - we have rabbitmq things in puppet/services/pacemaker If the plain services are easy to flatten, the pacemaker part is more annoying, at least on the naming/location. I see the following possibilities: - create a deployment/pacemaker and move all pacemaker-related things in there - name files something like rabbitmq-pacemaker-foo.yaml and push them in deployment/rabbitmq Both look valid. And both might have their downsides. Any advice, idea, feeling on that? Also, regarding the workflow: do we do that flattening in one, or two passes? i.e. we can move all rabbitmq related code at once, or only the plain service, and do a second patch for the pacemaker things. Here again, both look valid, but I'm more in the "2 passes" idea. So... yeah, I'd like to get some feedback on that in order to do things right, and avoid monkey-patching because paths/naming aren't good ;). Thanks! Cheers, C. -- Cédric Jeanneret Software Engineer DFG:DF

2 1

can't login to a compute node deployed using ironic
by Manuel Sopena Ballesteros 18 Dec '18

18 Dec '18

3 2

Meaning of role name: auditor versus reader
by Adam Young 18 Dec '18

18 Dec '18

We've recently come to accept reader as one of the default roles. However, one thing that is not clear to me is the intention: is this designed to be the readonly set of operations that an admin can do, or the read only set of operations that a member can do? Should we really have two read-only roles, one for each case? Perhaps the admin-read-only should be called auditor, and then reader is for member only operations?

4 4

[KOLLA][MONASCA] monasca containers not running
by Manuel Sopena Ballesteros 18 Dec '18

18 Dec '18

Dear Openstack and Kolla community, I am trying to deploy monasca using kolla-ansible 7.0.0 and realised a couple of containers are not working Container monasca_log_persister See: 'bin/logstash --help' + sudo -E kolla_set_configs INFO:__main__:Loading config file at /var/lib/kolla/config_files/config.json INFO:__main__:Validating config file INFO:__main__:Kolla config strategy set to: COPY_ALWAYS INFO:__main__:Copying service configuration files INFO:__main__:Deleting /etc/logstash/conf.d/log-persister.conf INFO:__main__:Copying /var/lib/kolla/config_files/log-persister.conf to /etc/logstash/conf.d/log-persister.conf INFO:__main__:Setting permission for /etc/logstash/conf.d/log-persister.conf INFO:__main__:Deleting /etc/logstash/elasticsearch-template.json INFO:__main__:Copying /var/lib/kolla/config_files/elasticsearch-template.json to /etc/logstash/elasticsearch-template.json INFO:__main__:Setting permission for /etc/logstash/elasticsearch-template.json INFO:__main__:Writing out command to execute INFO:__main__:Setting permission for /var/log/kolla/monasca INFO:__main__:Setting permission for /var/log/kolla/monasca/monasca-api-error.log INFO:__main__:Setting permission for /var/log/kolla/monasca/monasca-api-access.log INFO:__main__:Setting permission for /var/log/kolla/monasca/monasca-log-api-error.log INFO:__main__:Setting permission for /var/log/kolla/monasca/monasca-log-api-access.log ++ cat /run_command + CMD='/usr/share/logstash/bin/logstash --log-in-json --log /var/log/kolla/monasca/monasca-log-persister.log -f /etc/logstash/conf.d/log-persister.conf' + ARGS= + [[ ! -n '' ]] + . kolla_extend_start ++ [[ ! -d /var/log/kolla/logstash ]] +++ stat -c %a /var/log/kolla/logstash ++ [[ 755 != \7\5\5 ]] + echo 'Running command: '\''/usr/share/logstash/bin/logstash --log-in-json --log /var/log/kolla/monasca/monasca-log-persister.log -f /etc/logstash/conf.d/log-persister.conf'\''' Running command: '/usr/share/logstash/bin/logstash --log-in-json --log /var/log/kolla/monasca/monasca-log-persister.log -f /etc/logstash/conf.d/log-persister.conf' + exec /usr/share/logstash/bin/logstash --log-in-json --log /var/log/kolla/monasca/monasca-log-persister.log -f /etc/logstash/conf.d/log-persister.conf WARNING: Could not find logstash.yml which is typically located in $LS_HOME/config or /etc/logstash. You can specify the path using --path.settings. Continuing using the defaults ERROR: Unrecognised option '--log-in-json' Container monasca_log_transformer See: 'bin/logstash --help' + sudo -E kolla_set_configs INFO:__main__:Loading config file at /var/lib/kolla/config_files/config.json INFO:__main__:Validating config file INFO:__main__:Kolla config strategy set to: COPY_ALWAYS INFO:__main__:Copying service configuration files INFO:__main__:Deleting /etc/logstash/conf.d/log-transformer.conf INFO:__main__:Copying /var/lib/kolla/config_files/log-transformer.conf to /etc/logstash/conf.d/log-transformer.conf INFO:__main__:Setting permission for /etc/logstash/conf.d/log-transformer.conf INFO:__main__:Writing out command to execute INFO:__main__:Setting permission for /var/log/kolla/logstash ++ cat /run_command + CMD='/usr/share/logstash/bin/logstash --log-in-json --log /var/log/kolla/logstash/monasca-log-transformer.log -f /etc/logstash/conf.d/log-transformer.conf' + ARGS= + [[ ! -n '' ]] + . kolla_extend_start ++ [[ ! -d /var/log/kolla/logstash ]] +++ stat -c %a /var/log/kolla/logstash ++ [[ 755 != \7\5\5 ]] + echo 'Running command: '\''/usr/share/logstash/bin/logstash --log-in-json --log /var/log/kolla/logstash/monasca-log-transformer.log -f /etc/logstash/conf.d/log-transformer.conf'\''' Running command: '/usr/share/logstash/bin/logstash --log-in-json --log /var/log/kolla/logstash/monasca-log-transformer.log -f /etc/logstash/conf.d/log-transformer.conf' + exec /usr/share/logstash/bin/logstash --log-in-json --log /var/log/kolla/logstash/monasca-log-transformer.log -f /etc/logstash/conf.d/log-transformer.conf WARNING: Could not find logstash.yml which is typically located in $LS_HOME/config or /etc/logstash. You can specify the path using --path.settings. Continuing using the defaults ERROR: Unrecognised option '--log-in-json' Any thoughts? Thank you very much Manuel Sopena Ballesteros | Big data Engineer Garvan Institute of Medical Research The Kinghorn Cancer Centre, 370 Victoria Street, Darlinghurst, NSW 2010 T: + 61 (0)2 9355 5760 | F: +61 (0)2 9295 8507 | E: manuel.sb(a)garvan.org.au<mailto:manuel.sb@garvan.org.au> NOTICE Please consider the environment before printing this email. This message and any attachments are intended for the addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this message in error please notify us at once by return email and then delete both messages. We accept no liability for the distribution of viruses or similar in electronic communications. This notice should not be removed.

2 1

Instance Unable to connect to Data/Management Network
by Zufar Dhiyaulhaq 18 Dec '18

18 Dec '18

Hi, I have OpenStack cluster with this following network environment. Global Configuration : Data & Management Network : 10.60.60.0/24 External Network: 10.61.61.0/24 - All my endpoint is created in the Data & Management Network - Instance get floating IP from External Network IP Address Allocation : Controller: 10.60.60.10 | 10.61.61.10 Compute0: 10.60.60.20 | 10.61.61.20 Compute1: 10.60.60.30 | 10.61.61.30 Floating IP range : 10.61.61.100 - 10.61.61.200 My problem is the Instance cannot connect (ping, ssh, all connection) into the data/management network. I am running a magnum cluster but the instance needs to communicate with the endpoint. How to allow an Instance to connect to the data/management network? Best Regards, Zufar Dhiyaulhaq

2 1

[dev] [tc][all] TC office hours is started now on #openstack-tc
by Ghanshyam Mann 18 Dec '18

18 Dec '18

Hello everyone, TC office hour is started on #openstack-tc channel. Feel free to reach to us for anything you want discuss/input/feedback/help from TC. - gmann & TC

1 0

[cyborg] IRC meeting for Dec 18th
by Li Liu 17 Dec '18

17 Dec '18

The IRC meeting will be held tomorrow at 0300 UTC, which is 10:00 pm est(Tuesday) / 7:00 pm pst(Tuesday) /11 am Beijing time (Wednesday) This week's agenda: 1. Try to merge https://review.openstack.org/#/c/615462/ 2. Review https://review.openstack.org/#/c/625630/ from CoCo 3. Review https://review.openstack.org/#/c/596691/ from Zhenghao 4. Track status updates. -- Thank you Regards Li

1 0

[all] Service-specific configuration options
by Stephen Finucane 17 Dec '18

17 Dec '18

I proposed a WIP change for oslo.config [1] last week that would allow us to specify what services (e.g. nova-compute, nova-scheduler, nova- api, etc.) an option applies to. This came about because of comments on another issue where we found no one could say with surety what services needed an option in their configuration option (which in turn brought up questions about why those services needed the option). It was suggested I bring the idea up on the mailing list before we proceeded any further with it so here I am. I'm interested in two things. Firstly, I'd like to know whether generation of per-service configuration files is actually something others find problematic? I'm imagining this is annoying for operators and those working on deployment tooling but I've never got any hard data to back up that assumption. Secondly, I didn't see anything in the likes of cinder, nova or neutron but has anyone else already worked on something like this? For what it's worth, I did explain why I've gone with the approach I have in the commit message, but that doesn't mean there aren't other options I could be missing. Stephen [1] https://review.openstack.org/#/c/625011/ PS: I've tagged this [all] as enumerating the projects this actually affected left me with at least a dozen tags before I was even done. Sorry for any possible noise.

3 2

[tosca-parser] Failing to get functions from capabilities
by Michael Still 17 Dec '18

17 Dec '18

Hi, I'm trying to use tosca-parser to parse CSAR files. Its working quite well, until I hit a wall with capabilities today. Specifically I am testing with the single instance wordpress example CSAR, which uses a get_input for the num_cpus argument for host capabilities for the server. Based on how properties work, I would expect to get a function back for anything which requires referencing another value, but in the case of capabilities I either get the hardcoded value (strings, ints etc), or a None for values which would be functions if we were talking about prototypes. Here's a snippet of example code: #!/usr/bin/python import sys from jinja2 import Template import toscaparser.functions from toscaparser.tosca_template import ToscaTemplate tosca = ToscaTemplate(sys.argv[1]) for nodetemplate in tosca.nodetemplates: print print('Processing node template %s'% nodetemplate.name) capabilities = nodetemplate.get_capabilities_objects() for cap in capabilities: propobjs = cap.get_properties_objects() if not propobjs: continue for po in propobjs: print(' %s: %s' %(po.name, po.value)) Which returns this: $ python _capabilities.py csar_wordpress.zip No handlers could be found for logger "tosca.model" Processing node template wordpress network_name: PRIVATE initiator: source protocol: tcp secure: False Processing node template webserver network_name: PRIVATE initiator: source protocol: tcp secure: False secure: True Processing node template mysql_dbms Processing node template mysql_database Processing node template server secure: True min_instances: 1 max_instances: 1 mem_size: 4096 MB num_cpus: None disk_size: 10 GB distribution: Fedora version: 18.0 type: Linux architecture: x86_64 I would expect num_cpus for the "server" node_template to be a GetInput() function based on its definition in the CSAR, but instead I get None. Is there an example somewhere of how to correctly access functions for capabilities? Thanks, Michael

2 7

Gate fracas (status) update
by Matt Riedemann 17 Dec '18

17 Dec '18

I wanted to follow up from Clark's last gate status update [1]. Lots of work has been going on the last few weeks to try and get the gate under control since it's hard to merge code when you can't merge code. Most of my update is specific to nova, but some of it might be interesting to others as well for general QA/infra FYI. I'll group this into a few categories of issue. Optimize node usage / reduce blast radius ----------------------------------------- * The nova-cells-1 job has been moved to the experimental queue [2] so that we can still test that environment but do it on-demand. This helps us avoid latent cellsv1-specific race failures which might reset the gate. * I'm trying to drop the nova-multiattach job which is partially redundant with tempest-full except it only runs tempest.compute.api tests and it also runs slow tests [3]. What is blocking this is test_volume_swap_with_multiattach in the tempest-slow job intermittently failing during volume cleanup [4]. I have put a lot of debug details into that bug and have a debug logging patch up as well to see if I can recreate the failure and sort out what is going wrong. The main difference between this test in the tempest-slow job and the nova-multiattach job is simply that the tempest-slow job is multinode and nova-multiattach is single node, and the single node aspect might have been hiding some weird race bugs when it came to disconnecting the volume to cleanup if the servers are all on the same host. Help debugging that would be appreciated. Zuul queuing changes -------------------- An infra thread [5] prompted some discussion in IRC which led to changes in how tripleo changes will be queued by zuul [6][7]. The idea here is to isolate tripleo changes into their own queue so failures in tripleo changes don't disrupt (or starve) changes in openstack projects (in general) from getting queued up for test nodes. tl;dr: nova changes should enqueue more like they used to before [5]. Gate bugs --------- * http://status.openstack.org/elastic-recheck/#1807518 A fix for devstack was merged on both master and stable/rocky but we're still seeing this, so it probably needs more investigation. * http://status.openstack.org/elastic-recheck/#1783405 We need another deep dive on tempest tests which aren't marked as slow but which might be slow and contributing to overall job timeouts. * http://status.openstack.org/elastic-recheck/#1808171 This is relatively new. Debug notes are in the launchpad bug. In this test, a server is being created with 7 ports and times out waiting to get the network-vif-plugged event from neutron on the first port only, the other 6 events are received. Regarding the port that doesn't get the event, there are some weird messages in the neutron agent logs so there could be a race there but we likely need help from the neutron team to investigate. I'm not sure what might have prompted this, but maybe the recent change to use Ubuntu Bionic nodes and a new version of OVS is buggy? * http://status.openstack.org/elastic-recheck/#1800472 The fix for this [8] merged a couple of hours ago and we're seeing it drop off the e-r graph. * http://status.openstack.org/elastic-recheck/#1806912 There are a couple of separate nova bugs for this [9][10]. The fixes for both changes are approved and should reduce the amount of time it takes to start nova-api which will help avoid timeouts on slower test nodes. The fix for [10] also fixes a long-standing rolling upgrade issue so we'll be backporting that one. * http://status.openstack.org/elastic-recheck/#1798688 There is a nova fix up for this [11] and has a +2, it's very simple and just needs another nova core (efried would get it but he's out until January). * http://status.openstack.org/elastic-recheck/#1807520 This has been fixed on all grenade branches [12] and was very latent (goes back to pike) but only showed up on slower test nodes. * http://status.openstack.org/elastic-recheck/#1808010 This is a real snowball issue where the cirros filesystem fills up so config drive fails, falling back to use the metadata API to get networking information but the metadata API response is too slow and cloud-init times out. I've got a related fix [13] but we likely need someone to help profile where our other inefficiencies are in responding the metadata API requests. * http://status.openstack.org/elastic-recheck/#1808063 This one is also relatively new and I'm not sure what might be causing it. ---- There are other bugs in the e-r page but the hits are low enough, or they are latent enough, that I won't bother trying to detail them here. [1] http://lists.openstack.org/pipermail/openstack-discuss/2018-December/thread… [2] https://review.openstack.org/#/c/623538/ [3] https://review.openstack.org/#/q/topic:drop-multiattach-job [4] https://bugs.launchpad.net/tempest/+bug/1807723 [5] http://lists.openstack.org/pipermail/openstack-discuss/2018-December/thread… [6] https://review.openstack.org/#/c/623595/ - this is the zuul feature [7] https://review.openstack.org/#/c/624246/ - the tripleo-ci change [8] https://review.openstack.org/#/c/615347/ [9] https://bugs.launchpad.net/nova/+bug/1807219 [10] https://bugs.launchpad.net/nova/+bug/1807044 [11] https://review.openstack.org/#/c/623596 [12] https://review.openstack.org/#/q/I833d79ecc97ddc844bf156ab64477c7c77424f20 [13] https://review.openstack.org/#/c/624778 -- Thanks, Matt

2 1

[sdk] Establishing SDK Validation Baseline
by Melvin Hillsman 17 Dec '18

17 Dec '18

Hi everyone, We have spent some time working to get an idea of what official SDKs would look like. We had some sessions during the Berlin summit[0][1] and there was a lot of great feedback. Currently the following SDKs are generally considered usable for their respective language; there are others of course: openstacksdk (Python) gophercloud (Go) pkgcloud (JavaScript) openstack4j (Java) rust-openstack (Rust) fog-openstack (Ruby) php-opencloud (PHP) After many discussions it seems SDK validation essentially should be about confirming cloud state pre/post SDK interaction rather than API support. An example is that when I use pkgcloud and ask that a VM be created, does the VM exist, in the way I asked it exist, rather than are there specific API calls that are being hit along the way to creating my VM. I am putting this email out to keep the community informed of what has been discussed in this space but also and most importantly to get feedback and support for this work. It would be great to get a set of official and community SDKs, get them setup with CI testing for validation (not changing their current CI for unit/functional/acceptance testing; unless asked to help do this), and connect the results to the updated project navigator SDK section. A list of scenarios has been provided as a good starting point for cloud state checks.[2] Essentially the proposal is to deploy OpenStack from upstream (devstack or other), stand up a VM within the cloud, grab all the SDKs, run acceptance tests, report pass/fail results, update project navigator. Of course there are details to be worked out and I do have a few questions that I hope would help get everyone interested on the same page via this thread. 1. Does this make sense? 1. Would folks be interested in a SDK SIG or does it make more sense to request an item on the API SIG's agenda? 1. Bi-weekly discussions a good cadence? 1. Who is interested in tackling this together? [0] https://etherpad.openstack.org/p/BER-better-expose-what-we-produce [1] https://etherpad.openstack.org/p/BER-sdk-certification [2] https://docs.google.com/spreadsheets/d/1cdzFeV5I4Wk9FK57yqQmp5JJdGfKzEOdB3V… -- Kind regards, Melvin Hillsman mrhillsman(a)gmail.com mobile: (832) 264-2646

6 15

[ptl] [user survey] Cinder Superuser Article Addressing User Survey Feedback
by Allison Price 17 Dec '18

17 Dec '18

Hi everyone, I wanted to share a really helpful article [1] that Jay Bryant wrote for Superuser after receiving the Cinder feedback from the 2018 OpenStack User Survey. This is really valuable content for the users that are expressing challenges and feedback in the survey. I would like to encourage any PTLs that have the bandwidth to directly address some of the feedback they received from the user survey to draft something similar. With the publication of this article, we will reach out to users who expressed that they are running Cinder to show how their feedback has had a direct impact on the development of OpenStack. If anyone is interested, please email me directly, and we can get the process started. We have also made the 2019 OpenStack User Survey [2] live. We will be reaching out to all PTLs in the next month to make updates to the project-specific questions. If you have any questions in the meantime, please let me know. Thanks! Allison [1] http://superuser.openstack.org/articles/how-your-feedback-sparked-whats-nex… [2] https://www.openstack.org/user-survey/survey-2019 Allison Price OpenStack Foundation allison(a)openstack.org

1 0

[Oslo] End of year schedule and plans
by Ben Nemec 17 Dec '18

17 Dec '18

Hi Norwegians, As we discussed in the meeting today, there will be no Oslo meetings for the next two weeks due to the holidays. We'll resume Jan. 7. Releases will happen as normal this week, but after that I wouldn't expect any more until 2019. We generally try to avoid releasing when people aren't going to be around to deal with any fallout. Finally, I believe most of the Oslo cores will be unavailable after this week, so expect review activity to slow significantly until the new year too. I will be around for the rest of the week, so if you have any Oslo-related stuff that needs to happen in 2018 let me know. After that all bets are off for my availability. Thanks and Happy New Year in advance! -Ben

1 0

[dev] [horizon] [tc] [release] [PTI] is tox a requirement even if tox is not used?
by Akihiro Motoki 17 Dec '18

17 Dec '18

Hi, # I am not sure [tc] and [release] tags are appropriate. Horizon team maintains xstatic-* repositories [1]. We have a question on the need for tox.ini. Can we drop tox.ini completely considering the situation below? These repositories do not depend on 'tox' on testing from their nature of re-packaging JS module in a python way. In addition, there is no document provided. The current PTI mentions only "tox -e docs". # Previously PTI required "venv" tox ini but it is no longer mentioned. [1] http://git.openstack.org/cgit/?q=xstatic- Best Regards, Akihiro Motoki (IRC: amotoki)

4 3

[oslo] How to use library "oslo.messaging"
by Thành Nguyễn Bá 17 Dec '18

17 Dec '18

Dear all, I have a question about "library oslo.messaging". How can i use this librabry to write simple program listen event on Openstack (like Nova, Cinder)? I had read on docs, nova support "oslo_messaging_notifications" to send message via RabbitMQ, so I’m try to use this library but it seem very hard for me. *Nguyễn Bá Thành* *Mobile*: 0128 748 0391 *Email*: bathanhtlu(a)gmail.com

3 4

[dev] lower-constraints job moving to py36
by Chris Dent 17 Dec '18

17 Dec '18

There is a review in progress to change the lower-constraints CI job to explicitly use python 3.6 [1]. This is part of an ongoing migration to 3.6 throughout all the jobs. This has some small potential to break some projects, so in the review it was decided that making an announcement here would be best so that projects that run the lower-constraints job could have a chance to try it out before we make the switch: When we do, it will switch everyone, all at once. If you would like to try it out, please submit a null-change that depends-on the review [1]. [1] https://review.openstack.org/#/c/623229/ -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

1 0

[tripleo] undercloud / standalone have switched to podman by default
by Emilien Macchi 17 Dec '18

17 Dec '18

For your information, default deployment of Undercloud and Standalone are now using Podman instead of Docker by default. The switch doesn't affect the Overcloud yet but we also aim to change the default before the end of Stein release. If you still want to use docker: * For Undercloud: undercloud.conf : container_cli = docker * For Standalone: in your environment: ContainerCli: docker Please let us know any problem regarding that change. -- Emilien Macchi

2 1

[neutron] Bug deputy report, December 10 - December 16
by Bernard Cafarelli 17 Dec '18

17 Dec '18

Hi neutron folks, we started a new rotation of bug deputies, which means it was my turn to watch over new bugs. Here is the list of reported bugs, I highlighted those worth another look (other high bugs already have pending patches) *Undecided* * https://bugs.launchpad.net/neutron/+bug/1808731 - Needs the method to stop metadata proxy Latest bug, discussion in progress - feedback welcome *High* * https://bugs.launchpad.net/neutron/+bug/1808136 - l2 pop doesn't always provide the whole list of fdb entries on OVS restart A follow-up to https://bugs.launchpad.net/neutron/+bug/1804842, patch proposed at https://review.openstack.org/#/c/624669/ * https://bugs.launchpad.net/neutron/+bug/1808595 - fullstack test neutron.tests.fullstack.test_l3_agent.TestHAL3Agent.test_gateway_ip_changed failed intermittently Gate failure with patch proposed at https://review.openstack.org/#/c/625359/ * https://bugs.launchpad.net/neutron/+bug/1808541 - Openflow entries are not totally removed for stopped VM OVS flows issue (possible race condition?) - Has reproducer, details and logs but needs another pair of eyes *Medium* * https://bugs.launchpad.net/neutron/+bug/1808112 - rule:shared is not respected in port/subnet create waiting for feedback from policy experts * https://bugs.launchpad.net/neutron/+bug/1808171 - TaggedBootDevicesTest.test_tagged_boot_devices intermittently fails waiting for network-vif-plugged event which neutron does not send Intermittent gate failure in nova * https://bugs.launchpad.net/python-neutronclient/+bug/1808451 - Add Support for Querying Quotas with Usage CLI support for quotas detail, patch proposed at https://review.openstack.org/#/c/621507/ *RFE* * https://bugs.launchpad.net/neutron/+bug/1808062 - Limit VXLAN to within Neutron availability zones * https://bugs.launchpad.net/neutron/+bug/1808594 - Limit Geneve to within Neutron availability zones Clone of the previous one, for OVN (I added networking-ovn in affected projects) *Low* * https://bugs.launchpad.net/neutron/+bug/1807673 - Networking (neutron) concepts in neutron Easy doc fix ("facets" term use explanation) *Incomplete* * https://bugs.launchpad.net/neutron/+bug/1807483 - networksegments table in neutron can not be cleared automatically * https://bugs.launchpad.net/bugs/1808504 - the ip of port which device type is dhcp is null -- Bernard Cafarelli

1 0

[mistral] Standing down as PTL
by Dougal Matthews 17 Dec '18

17 Dec '18

Hey everyone, I am announcing that I am going to stand down as Mistral PTL. Due to a change in priorities I am no longer able to give the project the time it needs and deserves. This change will come into effect immediately. Being PTL has been a pleasure and a great learning experience for me. I have had the chance to work with a number of great folks and I am saddened to hang up the hat, particularly mid-cycle. However, I don't plan on going anywhere, I'll still be around and hope to remain an active member of the core team. Renat Akhmerov will be taking the role on again[1]. It is likely you will all know him as the previous Mistral PTL and therefore know the project will be in safe hands. Thanks everyone, Dougal [1]: https://review.openstack.org/#/c/625537/

2 1

[dev] [neutron] policy-in-code status update
by Akihiro Motoki 17 Dec '18

17 Dec '18

Hi neutrinos, I am working on policy-in-code support in neutron and have a good progress these weeks. [Progress] - The basic policy-in-code in neutron repo was merged. Several follow-up improvements and cleanup will be coming in the neutron repo. - policy-in-code support in several neutron related projects are proposed. There are found at https://review.openstack.org/#/q/topic:bp/neutron-policy-in-code+(status:op… [Request to neutron related project maintainers] neutron-dynamic-routing, neutron-fwaas,neutron-vpnaas, networking-bgpvpn, networking-sfc and vmware-nsx: I proposed patches. Review and testing from each team would be appreciated. networking-midonet and networking-cisco In my understanding, they defines its own resources and attributes, so their own policies exists. My bandwidth cannot cover them. Could you take over policy-in-code support? I belileve the above gerrit link would provide good examples. networking-ovn, networking-odl and networking-bagpipe In my understanding, they defines no extra resources and attributes, so there is no policies specific to them and policy-in-code support is unnecessary. Could you confirm my understanding is correct. If you need some policy definition, it means you need some work on policy-in-code. If you have questions, feel free to ask me. Best Regards, Akihiro Motoki (IRC: amotoki)

1 0

[magnum] Core reviewers update
by Spyros Trigazis 17 Dec '18

17 Dec '18

Hello list, During 2018 magnum's repos became more active with notable contributions, in alphabetical order, from Blizzard, Catalyst Cloud and StackHPC. At the same time part of the core reviewers group was inactive. Adrian Otto, Eli Qiao, Jaycen Grant, Madhuri Kumari and Ton Ngo have agreed to step down and make room for new contributors. Thank you for all your contributions! I would like to encourage current core reviewers to participate in the project. Let's evaluate the status of the core team in three months (end of March 2019). Cheers, Spyros

1 0

Magnum queens requirements
by Ignazio Cassano 16 Dec '18

16 Dec '18

Hi All, Does magnum require etcd installed on controller and computes nodes? Which opentack services require etcd on controllers and computes? Recards ignazio

2 3

[dev][openstacksdk] openstacksdk and dogpile 0.7.0+ cache errors
by Ian Wienand 16 Dec '18

16 Dec '18

Hi, Just a heads up that the latest version of dogpile (0.7.0 onwards) have become incompatible with openstacksdk. This is causing a few issues for jobs. As usual, it's a little complex :) The error you will see is something like user_func.set = set_ AttributeError: 'method' object has no attribute 'set' The following are related: https://review.openstack.org/624697 : requirements change to pin https://review.openstack.org/624485 : openstacksdk pin https://review.openstack.org/624855 : fixes a nodepool job that openstacksdk depends on (note 624485 turns the job non-voting to break the circular dependency). The issue is being tracked in: https://storyboard.openstack.org/#!/story/2004605 : related story https://github.com/sqlalchemy/dogpile.cache/issues/140 : upstream github issue Thanks, -i

4 11

[Devstack][Freezer] ElasticSearch installation fails
by Trinh Nguyen 16 Dec '18

16 Dec '18

Dear devstack team, Recently, the ElasticSearch installation fails and that makes Freezer (e.g., [1]) or any other services that depend on ElasticSearch fail the CI tests. A preliminary investigation suggests that it may cause by the test environment was switched to Ubuntu 18.04 (i.e., bionic). I made some modifications to the installation script in [2] hopefully will fix the problem. If someone in the Devstack team can have look at [2], it would be great. [1] http://logs.openstack.org/49/624549/3/check/freezer-tempest-agent/d0a52d0/j… [2] https://review.openstack.org/#/c/625174/ Many thanks, -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

1 0

[Searchlight] Team meeting today at 13:30 UTC
by Trinh Nguyen 16 Dec '18

16 Dec '18

Hi team, We will have a team meeting today at 13:30 UTC on the #openstack-searchlight channel. Please join me for updates and discussion about the next steps of Searchlight. Bests, -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

1 0

Re: [vitrage][monasca] Monasca datasource for Vitrage
by Joseph Davis 16 Dec '18

16 Dec '18

I left Bartosz some comments on his review, and I'll add a few things below. joseph On 12/13/18 12:52 AM, openstack-discuss-request(a)lists.openstack.org wrote > From: Ifat Afek <ifatafekn(a)gmail.com> > Message-ID: > <CALxdkcxxrtYYv+f4-enZ2uuA88qJdPuze732Ufg6MLMADBcOtg(a)mail.gmail.com> > > Hi Witek, > > On Wed, Dec 12, 2018 at 5:04 PM Bedyk, Witold <witold.bedyk(a)est.fujitsu.com> > wrote: > > >>> There is one issue that we need to close though – how to connect the >>> Monasca alarms to the resources in Vitrage. >>> In order to connect an alarm to a resource, Vitrage should be able to >>> identify that resource in its entity graph using the dimensions coming from >>> Monasca. I understood that these dimensions are configurable and not >>> pre-defined. >> Correct. To make the picture complete: every alarm contains an associated >> `metric name` and a set of dimensions which identify the monitored >> resource. Both metric name and dimensions could potentially be used in >> Vitrage. >> >> >> >> 1. For OpenStack services we typically use dimension keys `hostname` and >> `service`. Examples would be: >> >> `name`: `http_status`, `dimensions`: {`hostname`: `node1`, >> `service`: `keystone`, `url`: `http://node1/identity` >> <http://node1/identity>} >> >> >> >> Libvirt metrics all have the dimension keys `hostname`, >> `service`=`compute`, `resource_id`=instance_id >> > > By instance_id do you mean the libvirt id or the OpenStack UUID? In order > to correlate the id with the vm that exists in Vitrage, we need the Nova > UUID. > Another question: are these dimensions names always the same? Is it > possible to change their names? > I believe it is the OpenStack id in each case. Dimension names are always the same per type of metric, but different metrics can define different dimensions. For example, the http_status metric has a 'url' but disk.space_used_perc has a 'device' and cpu.idle_perc has neither. All metrics have 'hostname', 'service', and a few other dimensions in common. >> 2. For other resources I’m not sure if we can define a general rule for >> assignments. As you have said, the unique information may be included in >> more the one dimension. >> >> >> >> For Prometheus, we use labels on each metric as dimensions. Additional >> dimensions can be configured in agent per Prometheus endpoint. >> We also have a monasca-ceilometer component (aka. Ceilosca) that can send metrics from Ceilometer to Monasca. These metrics include the OpenStack resource_id of the source of the metric. Any alarms created from Ceilometer data can carry through that resource_id. From what I've seen we don't currently include a resource_type, but that should be something we can configure in the metric. If nothing else, we may be able to statically define the resource_type as part of the metric definition (each alarm will be specific to the type of resource anyway). But don't hold me to that - I have some more reading to do to understand the nuances. :) The dimensions from the metrics are carried over to the alarms. > <snip> > Can you give us some more examples of Monasca dimensions? As Witek said, the metric dimensions are pretty flexible. You can see some of the dimensions mentioned in my answer above. I can try to pull a list of some standard alarm definitions and associated metrics from a SUSE install, or if we have a particular few alarms we want to start with then we can focus on those.

2 1

[magnum] cluster node fail to establish connection (wrong IP address)
by Zufar Dhiyaulhaq 15 Dec '18

15 Dec '18

Hi I am creating a swarm cluster with this command : - openstack coe cluster template create swarm-cluster-template --image fedora-atomic-latest --external-network external --dns-nameserver 8.8.8.8 --master-flavor m1.small --flavor m1.small --coe swarm-mode --docker-volume-size 4 --docker-storage-driver=devicemapper - openstack coe cluster create swarm-cluster --cluster-template swarm-cluster-template --master-count 1 --node-count 1 --keypair mykey but its stack on *swarm_primary_master *heat with *CREATE_IN_PROGRESS*. I try to login into swarm VM and see the log. I get this : - requests.exceptions.ConnectionError: HTTPConnectionPool(host='10.60.60.10', port=5000): Max retries exceeded with url: /v3/auth/tokens (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f02f57321d0>: Failed to establish a new connection: [Errno 110] Connection timed out',)) - Cloud-init v. 0.7.9 running 'modules:final' at Sat, 15 Dec 2018 17:36:44 +0000. Up 33.29 seconds. Swarm Instance try to open connection to 10.60.60.10 which is my management ip address on OpenStack. But it cannot (by design it cannot, I try to curl manual to 10.60.60.10 and error). When curl to 10.61.61.10 which is my floating IP and external IP for OpenStack cluster, it works. Anyone know how to change the cloud-init to curl into 10.61.61.10? Best Regards, Zufar Dhiyaulhaq

2 10

[magnum] region_name needs to be configured in magnum.conf
by Zufar Dhiyaulhaq 15 Dec '18

15 Dec '18

I am following installation guide from magnum documentation. but I get an error when trying to create kubernetes cluster. *region_name needs to be configured in magnum.conf* this is my full log : [root@zu-bssn-controller1 opt]# openstack coe cluster create kubernetes-cluster --cluster-template kubernetes-cluster-template --master-count 1 --node-count 1 --keypair mykeyRequest to create cluster bfdf76df-8b43-44e3-a094-90a76189610a accepted [root@zu-bssn-controller1 opt]# openstack coe cluster list +--------------------------------------+--------------------+---------+------------+--------------+---------------+ | uuid | name | keypair | node_count | master_count | status | +--------------------------------------+--------------------+---------+------------+--------------+---------------+ | bfdf76df-8b43-44e3-a094-90a76189610a | kubernetes-cluster | mykey | 1 | 1 | CREATE_FAILED | +--------------------------------------+--------------------+---------+------------+--------------+---------------+ [root@zu-bssn-controller1 opt]# openstack coe cluster show kubernetes-cluster +---------------------+---------------------------------------------------+ | Field | Value | +---------------------+---------------------------------------------------+ | status | CREATE_FAILED | | cluster_template_id | 560f72a9-d6ac-4404-ad9e-3cd129496022 | | node_addresses | [] | | uuid | bfdf76df-8b43-44e3-a094-90a76189610a | | stack_id | None | | status_reason | region_name needs to be configured in magnum.conf | | created_at | 2018-12-14T11:25:37+00:00 | | updated_at | 2018-12-14T11:25:40+00:00 | | coe_version | None | | labels | {} | | faults | {} | | keypair | mykey | | api_address | None | | master_addresses | [] | | create_timeout | 60 | | node_count | 1 | | discovery_url | None | | master_count | 1 | | container_version | None | | name | kubernetes-cluster | | master_flavor_id | amphora | | flavor_id | amphora | +---------------------+---------------------------------------------------+ [root@zu-bssn-controller1 opt]# Anyone know what is happening? Best Regards, Zufar Dhiyaulhaq

2 8

Re: [openstack-community] Asking for suggestion of video conference tool for team and webinar
by Trinh Nguyen 15 Dec '18

15 Dec '18

I just tried Jitsi and the experience was amazing! Thank everyone for the suggestion! :) On Sat, Nov 17, 2018 at 9:59 AM Trinh Nguyen <dangtrinhnt(a)gmail.com> wrote: > Thank Thierry, Arun, and everybody for all the suggestions. My team will > try these tools. > > On Thu, Nov 8, 2018 at 3:23 AM Arun Kumar Khan <arun.k.khan(a)gmail.com> > wrote: > >> >> On Tue, Nov 6, 2018 at 5:36 AM Trinh Nguyen <dangtrinhnt(a)gmail.com> >> wrote: >> >>> Hi, >>> >>> I tried several free tools for team meetings, vPTG, and webinars but >>> there are always drawbacks ( because it's free, of course). For example: >>> >>> - Google Hangout: only allow a maximum of 10 people to do the video >>> calls >>> - Zoom: limits about 45m per meeting. So for a webinar or conference >>> call takes more than 45m we have to splits into 2 sessions or so. >>> >>> If anyone in the community can suggest some better video conferencing >>> tools, that would be great. So we can organize better communication for our >>> team and the community's webinars. >>> >> >> All good suggestions. >> >> A couple of other options: >> >> 1. https://hubl.in -- open source i.e. you can host your own or use the >> hosted version at https://hubl.in/ >> 2. Wire.com -- open source with mobile apps. >> >> Let us know which solution works out for you. >> >> -- Arun Khan >> > > > -- > *Trinh Nguyen* > *www.edlab.xyz <https://www.edlab.xyz>* > > -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

1 0

[OpenStack][RabbitMQ] nove-compute running on controller node can not connect to rabbitmq
by Soheil Pourbafrani 14 Dec '18

14 Dec '18

Hi, I have 2 nodes on my OpenStack cluster. One act as both the controller node and the compute node and the other act as the compute node. All services were running well for days until I activate a new NIC interface to the controller node. Now the problem is the nova-compute service of the compute node can connect to the RabittMQ server but the nova-compute service of the controller node connecting to the RabiitMQ server got an error and fails. Here are the RabbitMQ logs when I start nova-compute service on the controller node: =INFO REPORT==== 15-Dec-2018::11:02:15 === Connection <0.3414.0> (192.168.0.31:35254 -> 192.168.0.31:5672) has a client-provided name: nova-compute:7425:5fb041db-c884-4c5a-86a5-6c7a490c2471 =INFO REPORT==== 15-Dec-2018::11:02:15 === accepting AMQP connection <0.3431.0> (192.168.0.31:35256 -> 192.168.0.31:5672) =INFO REPORT==== 15-Dec-2018::11:02:15 === Connection <0.3431.0> (192.168.0.31:35256 -> 192.168.0.31:5672) has a client-provided name: nova-compute:7425:911fbbc4-1cfa-45f2-a65b-23c7fb0a4aee =WARNING REPORT==== 15-Dec-2018::11:02:15 === closing AMQP connection <0.3414.0> (192.168.0.31:35254 -> 192.168.0.31:5672 - nova-compute:7425:5fb041db-c884-4c5a-86a5-6c7a490c2471): client unexpectedly closed TCP connection =WARNING REPORT==== 15-Dec-2018::11:02:15 === closing AMQP connection <0.3431.0> (192.168.0.31:35256 -> 192.168.0.31:5672 - nova-compute:7425:911fbbc4-1cfa-45f2-a65b-23c7fb0a4aee): client unexpectedly closed TCP connection =INFO REPORT==== 15-Dec-2018::11:02:21 === accepting AMQP connection <0.3446.0> (192.168.0.31:35316 -> 192.168.0.31:5672) =INFO REPORT==== 15-Dec-2018::11:02:21 === Connection <0.3446.0> (192.168.0.31:35316 -> 192.168.0.31:5672) has a client-provided name: nova-compute:7438:cac8d67b-6f5a-426d-8d03-a18c8d5a7e5a =INFO REPORT==== 15-Dec-2018::11:02:21 === accepting AMQP connection <0.3463.0> (192.168.0.31:35318 -> 192.168.0.31:5672) =INFO REPORT==== 15-Dec-2018::11:02:21 === Connection <0.3463.0> (192.168.0.31:35318 -> 192.168.0.31:5672) has a client-provided name: nova-compute:7438:b06139fd-8294-4c21-a5c3-6e1ccb45fe6f =WARNING REPORT==== 15-Dec-2018::11:02:21 === closing AMQP connection <0.3446.0> (192.168.0.31:35316 -> 192.168.0.31:5672 - nova-compute:7438:cac8d67b-6f5a-426d-8d03-a18c8d5a7e5a): client unexpectedly closed TCP connection =WARNING REPORT==== 15-Dec-2018::11:02:21 === closing AMQP connection <0.3463.0> (192.168.0.31:35318 -> 192.168.0.31:5672 - nova-compute:7438:b06139fd-8294-4c21-a5c3-6e1ccb45fe6f): client unexpectedly closed TCP connection What is the problem?

1 0

[openlab] Maintenance Notification
by Melvin Hillsman 14 Dec '18

14 Dec '18

Hi everyone, Maintenance will be happening 12/19/2018 and 12/20/2018 so if you experience any issues we do apologize. Not everyone will be affected but it is just good to know these things even if you are not. Additionally we will not be able to onboard any new requests/projects/individuals during this time more than likely but please do fill out any requests and we will proceed as normal. If there is an issue we will work through as much as we can to fulfill requests. Kind regards, OpenLab

1 0

bug openstack queens magnum
by Ignazio Cassano 14 Dec '18

14 Dec '18

Hi All, I am facing the same issue wrote at this link: https://ask.openstack.org/en/question/116465/magnum-kubernetes-cluster-stuc… It happens for swarm and kubernets but works in swarm-mode. Please, help me Regards Ignazio

1 0

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

14 Dec '18

Looks like putting the same option on the other compute nodes did the trick. Originally I did that and it made no difference, but that must've been me not rebooting the test instances that were on that node during the change. Doing a cold migrate correctly updates the XML, so I'll have to cold migrate all of the production instances before I can live migrate them.

1 0

[neutron][stadium] Switch from ryu to os-ken
by Hongbin Lu 14 Dec '18

14 Dec '18

Hi all, Due to the advice that Ryu library won't be maintained at the end of 2018, the neutron team decided to fork the Ryu library and maintain the fork, which is called os-ken [1], from now on. Right now, both neutron [2] and neutron-dynamic-routing [3] is switching over to os-ken. If other projects want to do the same, please feel free to handout to the openstack-neutron channel for helps or information. You can also find more in here: https://blueprints.launchpad.net/neutron/+spec/ryu-framework-maintenace-tra… . [1] https://github.com/openstack/os-ken [2] https://review.openstack.org/#/c/607008/ [3] https://review.openstack.org/#/c/608357/ Best regards, Hongbin

2 1

Open Infrastructure Summit Denver Contributor Discount Information
by Kendall Waters 14 Dec '18

14 Dec '18

Hi everyone, There have been a lot of questions about discounts for the upcoming Open Infrastructure Summit so I have outlined the contributor discounts that we will be giving out below. Contributor Discount (formally known as ATC or AUC discount) 50% off any 1 ticket type until online sales close (please note ticket prices are tiered so the earlier you use your discount code, the cheaper the ticket will be) - To qualify for this discount, you will need to either have contributed at least one commit which merged to an official governed OSF project or pilot project in the last 6 months as of January 1, 2019 or qualify as an AUC: http://superuser.openstack.org/articles/auc-community/ <http://superuser.openstack.org/articles/auc-community/> - Discount codes will be sent by the end of January Denver 2018 PTG Attendees 82% off the early bird price of the Summit + PTG combo ticket until early bird ends - To qualify for this discount, you must have attended the Denver PTG in September 2018 - Discount codes will be sent by the end of January Please let me know if you have any questions. Cheers, Kendall Kendall Waters OpenStack Marketing & Events kendall(a)openstack.org

2 2

[TripleO] OVB 2.0 Update
by Ben Nemec 14 Dec '18

14 Dec '18

Just wanted to give everyone a heads up that there's a 2.0 development branch for OVB available. I wrote up a blog post about it http://blog.nemebean.com/content/openstack-virtual-baremetal-20-update that covers the details of what changed and where you can find it. We definitely need to make sure TripleO CI will be happy with the changes, but if anyone else is using it please also give the new branch a try and let me know how it works. -Ben

1 0

[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