April 2019 - openstack-discuss - lists.openstack.org

[tripleo] Stein RC1 is out (with stable/stein branch)
by Emilien Macchi 18 Apr '19

18 Apr '19

We decided to branch stable/stein and release our first Stein release candidate this week. The main action that is being asked to our dear community is to think about backporting patches landing in master that you want to see in Stein. As usual some of us will watch things which land on master but really any help on that is very welcome. Also I've produced some stats about the evolution of TripleO since Newton. https://docs.google.com/presentation/d/1RV30OVxmXv1y_z33LuXMVB56TA54Urp7oHI… A few highlights: - Bug fixing is pretty consistent since Pike, no major change - Stein is the release with the less implemented blueprints since before Newton - Our core contributors number keep growing - Number of LOC & reviews keep growing since Queens Thanks everyone for your hard work during this cycle, I'm looking forward to seeing you in Denver and work on "Train". -- Emilien Macchi

1 0

[Neutron][QoS] No meeting on April 23
by Rodolfo Alonso 18 Apr '19

18 Apr '19

Hello folks: Because of an agenda problem, I won't chair the QoS meeting on April 23. I talked to Miguel and there is no problem to postpone this meeting until May 7, after the PTG. Regards.

1 0

[tripleo] [Release-job-failures] Release of openstack/puppet-tripleo failed
by Sean McGinnis 18 Apr '19

18 Apr '19

There was a failure in the post-release job for puppet-tripleo that I think we will need someone from TripleO and or someone with Puppet knowledge to address. The error received was: Forge API failed to upload tarball with code: 400 errors: The dependency 'sensu/sensu' in metadata.json is empty. All dependencies must have a 'version_requirement'.,The dependency 'yelp/uchiwa' in metadata.json is empty. All dependencies must have a 'version_requirement'. http://logs.openstack.org/75/75c09955854b142fd08c843bebcb8ee90d951b4d/relea… I'm guessing that's something in the puppet-tripleo repo, but really have no idea how this part works. If someone from the team could look into this, we can then do a follow up release if needed to correct any issues. ----- Forwarded message from zuul(a)openstack.org ----- Date: Thu, 18 Apr 2019 15:04:39 +0000 From: zuul(a)openstack.org To: release-job-failures(a)lists.openstack.org Subject: [Release-job-failures] Release of openstack/puppet-tripleo failed Reply-To: openstack-discuss(a)lists.openstack.org Build failed. - release-openstack-puppet http://logs.openstack.org/75/75c09955854b142fd08c843bebcb8ee90d951b4d/relea… : POST_FAILURE in 3m 18s - announce-release announce-release : SKIPPED _______________________________________________ Release-job-failures mailing list Release-job-failures(a)lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures ----- End forwarded message -----

2 1

[neutron] RFE Decouple placement reporting service plugin from ML2
by Bence Romsics 18 Apr '19

18 Apr '19

Hi Neutrinos, I'm wondering if we have a use case for the following RFE: https://bugs.launchpad.net/neutron/+bug/1818479 Decouple placement reporting service plugin from ML2 Very close to the Stein rc1 deadline we merged a change with a review comment we agreed to tackle in a followup RFE - the one above. Here's the original comment from Slawek: https://review.openstack.org/#/c/580672/30/neutron/services/placement_repor… I see why Slawek left the comment, the placement reporter service plugin's dependency on ML2 does hurt my aestethic sense too. But now starting to work out the details of the followup work I'm not sure if we have a use case here. I would like to understand if we have a use case or not, because the change we talked about would increase code complexity. So it needs justification. If we don't have a use case we better do nothing and leave the complexity as it is. But if we do have a use case I'm still happy to work on that. In short: What concrete problems does it mean if the placement reporter service plugin depends on the ML2 core plugin? When eliminating that dependency what use case(s) are we generalizing the code for? I see the following options: 1) There may be an agent reporting its resource information in a different format - unlike ovs-agent and sriov-agent. 2) There may be an agentless mechanism driver needing to sync to Placement. 3) There may be a non-ML2 core plugin needing to sync to Placement. For (1) we standardized the format included in the agent's configurations attribute. An agent newly implementing support for reporting resource information should only deviate from that format if that format cannot express the resource information. Do we have an agent like that? The format is basically a 2-layer mapping from physnets to the list of their backing physical devices (whatever that is for an agent: bridges, sriov PFs, etc) and further mapping to the backing devices' inventory numbers. For the exact format please see this piece of the docs: https://docs.openstack.org/neutron/stein/admin/config-qos-min-bw.html#neutr… Case (2) may be a realistic use case, but I'm not much familiar with agentless mechanism drivers. IIUC some agentless mechanism drivers actually maintain fake agent entries in the neutron db. Those drivers can utilize the current service plugin via the fake agent entries as if they were real. For really agentless mechanism drivers (not even fake agent records) and for (3) I'm inclined to say: Don't load this placement reporter service plugin but write your own. To summarize on a high level: Slawek's original comment on the implicit dependency detects a real design smell, but I don't see how refactoring the service plugin to a driver architecture would improve the situation. What could nicely make this plugin more generic is subscribing to another interface: create/update_host_resources() instead of create/update_agent() because agents today are an implementation detail of the ML2 drivers. But the host (instead of an agent) is an abstraction we never had in neutron. What do you think? Sorry for the long mail, Bence irc: rubasov

1 0

[ironic] Stepping down from core
by shiina.hironori＠fujitsu.com 18 Apr '19

18 Apr '19

Hi ironic folks, I'm sorry for my long absence. My job responsibility changed last November. Since it, I have been trying to spend some time on the core activity. But, I couldn't. So, I'm stepping down from the ironic core team. Thank you for accepting me to the team even though I didn't often appear in IRC due to the time difference. I hope I will work with you again someday. Best regards, Hironori

4 3

[placement][ptg] pre-ptg checkpoint
by Chris Dent 18 Apr '19

18 Apr '19

Since I'm going to be out of touch next week, I thought it best to provide a checkpoint summarizing where things are with the virtual pre-PTG process so that we go into the PTG in reasonable shape. For reference, the pre-PTG has been a series of email threads discussion topics raised in the two placement-related PTG etherpads: * https://etherpad.openstack.org/p/placement-ptg-train * https://etherpad.openstack.org/p/ptg-train-xproj-nova-placement Each thread is linked from its topic in the etherpad. Any thread which reached some resolution is marked with a boldface "ACTION", often with a link to a story or review associated with the next step. Overall I think the process has been useful. We've figured out some plans of action for resource provider partitioning and consumer types, worked out better testing for osc-placement, and have some ideas on better container manager and performance testing. These things are reflected in worklists on storyboard [1, 2]. We've also managed to uncover some more ideas, challenges, and benefits with nested resource providers. We have a planned Saturday morning session at the PTG with Ironic, Blazar and anyone else who is thinking about using placement outside of nova. Where we've made less progress is getting owners on the new features [3] and reaching some resolution or plan with the several nested provider related threads (aggregate spanning, subtree "affinity", json body, NUMA in placement, request group mapping, resource trait filters). We've shared some ideas and managed to dismiss some things that won't work, but at least so far a solid plan is yet to emerge. Part of the latter may be my fault. I'm compelled to fully understand what's going on and for things to make as much sense to as many people as possible and I believed we had the time and space to have a wide-open discussion in that direction in the weeks prior to the PTG. There's still next week, so perhaps that's still the case, but maybe a different approach is required. If you've got ideas, please share. Please carry on with the threads if there's more to add. I'll incorporate them early in the week before the PTG and extract some kind of schedule for our time at the PTG. As I've said before there may not be much opportunity, we've only got Friday and Saturday and it is mostly consumed. Friday will mostly be taken up with Nova, Saturday morning will be talking with Ironic and Blazar. By Saturday afternoon we will probably be exhausted and I suspect the best use of our time will be talking without agenda about making sure working on Placement is pleasant and useful for everyone [4]. We don't need to actively seek more work: We've already defined got a lot, especially when we account for work in other projects. Thanks. [1] Cleanups: https://storyboard.openstack.org/#!/worklist/575 [2] Features: https://storyboard.openstack.org/#!/worklist/594 [3] However, thanks very much to Surya for stepping up to make a spec for the consumer type feature: https://storyboard.openstack.org/#!/story/2005473 [4] To that end, please make sure you have added your thoughts to the retrospective etherpad: https://etherpad.openstack.org/p/placement-ptg-train-retrospective -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

1 0

[neutron] neutron-metering-agent track router and floating IP traffic
by Florian Engelmann 18 Apr '19

18 Apr '19

Hi, I configured our neutron meters like: labels: openstack network meter create --description "shared bandwidth-public-out" --share bandwidth-public-out openstack network meter create --description "shared bandwidth-public-in" --share bandwidth-public-in rules: openstack network meter rule create --egress --remote-ip-prefix 0.0.0.0/0 bandwidth-public-out openstack network meter rule create --ingress --remote-ip-prefix 0.0.0.0/0 bandwidth-public-in This created the iptables rules in all namespaces and collects data: openstack metric measures show bc6c670f-cbb5-4fe1-974c-10455448fa27 +---------------------------+-------------+---------------+ | timestamp | granularity | value | +---------------------------+-------------+---------------+ | 2019-04-15T16:00:00+02:00 | 3600.0 | 581854.954545 | | 2019-04-15T17:00:00+02:00 | 3600.0 | 23169398.5625 | | 2019-04-15T18:00:00+02:00 | 3600.0 | 586508.9 | | 2019-04-15T19:00:00+02:00 | 3600.0 | 1276372.84375 | | 2019-04-15T20:00:00+02:00 | 3600.0 | 507482.911765 | [...] But how to know which project caused which amount of traffic? It looks like only one metric is created for each label? openstack metric list | grep bandwidth | 0f9f20a4-1c60-442f-81cb-48285e3f70da | ceilometer-ew-low | bandwidth | B | efae8040-85d7-455a-958d-213a81ef98ef | | 1a058a79-965f-4a0a-a9ee-d482f57892ab | ceilometer-ew-low | bandwidth | B | 837ed34a-65d2-42ef-924e-fd3c7e5aaed6 | What does "shared" mean? I was not able to find any relevant documentation. Do I have to create a meter for each project or a rule or both? Is it possible to define a "default" meter and rule for every existing project and all future projects? All the best, Flo

1 1

[tripleo] Nominate Cédric Jeanneret (Tengu) for tripleo-validations core
by Gaël Chamoulaud 18 Apr '19

18 Apr '19

Hi TripleO devs, The new Validation Framework is a big step further for the tripleo-validations project. In many ways, it improves the way of detecting & reporting potential issues during a TripleO deployment. As the mastermind of this new framework, Cédric brought a new lease of life to the tripleo-validations project. That's why we would highly benefit from his addition to the core reviewer team. Assuming that there are no objections, we will add Cédric to the core team next week. Thanks, Cédric, for your excellent work! =Gaël

2 1

[sahara] Sahara meeting April 18 - volunteer chair? (or cancel?)
by Jeremy Freudberg 18 Apr '19

18 Apr '19

I have a personal conflict and will not be around to run the Sahara meeting on April 18 (tomorrow). There isn't too much to discuss, so I'm comfortable letting it be cancelled. But if there is any volunteer chair, the meeting can still run. Thanks, Jeremy

2 1

[murano] Galera Table package_to_tag has no PRIMARY_KEY
by Marc Vorwerk 18 Apr '19

18 Apr '19

Hello, uploading an application to Murano fails after upgrading "percona-xtradb-cluster-common-5.6" to "percona-xtradb-cluster-common-5.7": Importing package io.murano Error {"explanation": "The server has either erred or is incapable of performing the requested operation.", "code": 500, "error": {"message": "(pymysql.err.InternalError) (1105, u'Percona-XtraDB-Cluster prohibits use of DML command on a table (murano.package_to_tag) without an explicit primary key with pxc_strict_mode = ENFORCING or MASTER') [SQL: u'INSERT INTO package_to_tag (package_id, tag_id) VALUES (%(package_id)s, %(tag_id)s)'] [parameters: {'package_id': 'a345ab1fe4924aaf8ed32f954a6fe32d', 'tag_id': '0cb3765d7fe1486ba9741f4eb9b2a437'}]", "traceback": null, "type": "DBError"}, "title": "Internal Server Error"} (HTTP 500) occurred while installing package io.murano If i looks on the galera table, i get the following information: $ mysql -u murano -p mysql> Use murano; mysql> INSERT INTO package_to_tag (package_id, tag_id) VALUES (a345ab1fe4924aaf8ed32f954a6fe32d, 0cb3765d7fe1486ba9741f4eb9b2a437); ERROR 1105 (HY000): Percona-XtraDB-Cluster prohibits use of DML command on a table (murano.package_to_tag) without an explicit primary key with pxc_strict_mode = ENFORCING or MASTER mysql> SHOW KEYS FROM package_to_tag WHERE Key_name = 'PRIMARY'; Empty set (0.00 sec) My package list: $pkg -l | grep -e mysql -e percona root@control02ve:~# dpkg -l | grep -e mysql -e percona ii libdbd-mysql-perl 4.033-1ubuntu0.1 amd64 Perl5 database interface to the MySQL database ii libmysqlclient20:amd64 5.7.25-0ubuntu0.16.04.2 amd64 MySQL database client library ii mysql-common 5.7.25-0ubuntu0.16.04.2 all MySQL database common files, e.g. /etc/mysql/my.cnf ii percona-release 1.0-11.generic all Package to install Percona gpg key and APT repos ii percona-xtrabackup-24 2.4.13-1.xenial amd64 Open source backup tool for InnoDB and XtraDB ii percona-xtradb-cluster-client-5.7 5.7.25-31.35-1.xenial amd64 Percona XtraDB Cluster database client binaries ii percona-xtradb-cluster-common-5.7 5.7.25-31.35-1.xenial amd64 Percona XtraDB Cluster database common files (e.g. /etc/mysql/my.cnf) ii percona-xtradb-cluster-galera-3.x 3.32-1.xenial amd64 Galera components of Percona XtraDB Cluster ii percona-xtradb-cluster-server-5.7 5.7.25-31.35-1.xenial amd64 Percona XtraDB Cluster database server binaries ii python-mysqldb 1.3.7-1build2 amd64 Python interface to MySQL ii python-pymysql 0.7.11-1~cloud0 all Pure-Python MySQL driver - Python 2.x Murano is installed in the latest version of queens (https://github.com/openstack/murano/tree/stable/queens) Has anyone an idea? Best Regards, Marc

2 2