June 2019 - openstack-discuss - lists.openstack.org

[masakari] Run masakari-hostmonitor into Docker container
by gaetan.trellu＠incloudus.com 06 Jul '19

06 Jul '19

Hi, I'm integrating Masakari into Kolla and Kolla Ansible projects but I'm facing an issue related to masakari-hostmonitor. Based on masakari-monitors code[1], "systemctl status" command is used to check if pacemaker, pacemaker-remote and corosync are running. Having systemd running into Docker container is not the best solution. Does any of you has been able to run masakari-monitor into Docker container ? Thanks for your help. Gaëtan - [1] https://github.com/openstack/masakari-monitors/blob/26d558333d9731ca06da09b…

3 2

[placement] db query analysis
by Chris Dent 05 Jul '19

05 Jul '19

One of the queries that has come up recently with placement performance is whether there may be opportunities to gain some improvement by making fewer queries to the db. That is: * are there redundant queries * are there places where data is gathered in multiple queries that could be in one (or at least fewer) * are there queries that are not doing what we think to that end I've done some analysis of logs produced when [placement_database]/connection_debug is set to 50 (which dumps SQL queries to the INFO log). The collection of queries made during a single request to GET /allocation_candidates is at http://paste.openstack.org/show/753183/ The data set is a single resource resource provider of the same form as used in the placement-perfload job (where 1000 providers are used). Only 1 is used in this case as several queries use 'IN' statements that list all the resource provider ids currently in play, and that gets dumped to the log making it inscrutable. I've noted in the paste where this happens. Each block of SQL is associated with the method that calls it. The queries are in the order they happen. One query that happens three times (once for each resource class requested) is listed once. Observations: * The way we use IN could be improved using a bindparam: https://docs.sqlalchemy.org/en/13/core/sqlelement.html?highlight=expanding%… * That we use IN in that fashion at all, where we are carrying lists of rp ids around and making multiple queries, instead of one giant one, might be an area worth exploring. * There are a couple of places where get get a trait id (via name) in a separate query from using the trait id. * What can you see? Please have a look to see if anything looks odd, wrong, etc. Basically what we're after is trying to find things that violate our expectations. Note that this is just one of several paths through the database. When there are sharing or nested providers things change. I didn't bother to do a more complex set of queries at this time as it seemed starting simple would help us tease out how best to communicate these sorts of things. Related to that, I've started working on a nested-perfload at https://review.opendev.org/665695 -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent

2 2

[kolla] Proposing yoctozepto as core
by Mark Goddard 05 Jul '19

05 Jul '19

Hi, I would like to propose adding Radosław Piliszek (yoctozepto) to kolla-core and kolla-ansible-core. While he has only recently started working upstream in the project, I feel that he has made some valuable contributions already, particularly around improving and maintaining CI. His reviews generally provide useful feedback, sometimes in advance of Zuul! Core team - please vote, and consider this my +1. I will keep this vote open for a week or until all cores have responded. Cheers, Mark

5 5

[kolla][kayobe] vote: kayobe as a kolla deliverable
by Mark Goddard 05 Jul '19

05 Jul '19

Hi, In the most recent kolla meeting [1] we discussed the possibility of kayobe becoming a deliverable of the kolla project. This follows on from discussion at the PTG and then on here [3]. The two options discussed are: 1. become a deliverable of the Kolla project 2. become an official top level OpenStack project There has been some positive feedback about option 1 and no negative feedback that I am aware of. I would therefore like to ask the kolla community to vote on whether to include kayobe as a deliverable of the kolla project. The electorate is the kolla-core and kolla-ansible core teams, excluding me. The opinion of others in the community is also welcome. If you have questions or feedback, please respond to this email. Once you have made a decision, please respond with your answer to the following question: "Should kayobe become a deliverable of the kolla project?" (yes/no) Thanks, Mark [1] http://eavesdrop.openstack.org/meetings/kolla/2019/kolla.2019-06-19-15.00.l… [2] https://etherpad.openstack.org/p/kolla-train-ptg [3] http://lists.openstack.org/pipermail/openstack-discuss/2019-June/006901.html

4 6

[tc][ops] reviving osops- repos
by Mohammed Naser 02 Jul '19

02 Jul '19

Hi everyone, So we've realized that we have a few operational tools that we keep around that live all over the place and it would probably be the best for the community to have access to them. I did a bit of research and it looks like the openstack/osops-* repos used to exist between operators to maintain things like this, however, they've gone pretty abandoned over time. I'd like to pick up this effort and as part of doing that, I'd like to move them into a GitHub organization and rename them out of x/ to make them not seem so .. 'dead'. I've requested to move x/osops-* to openstack-operators/* in GitHub so that I can setup the appropriate mirroring in post pipeline (and then propose a patch to rename things inside Gerrit as well). There was concern around the idea of using 'openstack' as it's a copyrighted term and a TC discussion was brought up as an idea which makes sense. I'd like to ask if everyone else feels like it's okay so move things into that org and host them there. Thanks, Mohammed -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

9 15

[cinder] Deprecating driver versions
by Erlon Cruz 01 Jul '19

01 Jul '19

Hey folks, Driver versions has being a source of a lot of confusions with costumers. Most of our drivers have a version number and history that are updated as the developers adds new fixes and features. Drivers also have a VERSION variable in the version class that should be bumped by developers. The problem with that is: - sometimes folks from the community just push patches on drivers, and its hard to bump every vendor version correctly; - that relies in the human factor to remember adding it, and usually that fails; - if we create a bugfix and bump the version, the backport to older branches will carry the version, which will not reflect the correct driver code; So, the solution I'm proposing for this is that we use the Cinder versions[1] and remove all version strings for drivers. Every new release we get a version. For stable versions, from time to time the PTL bumps the stable version and we have an accurate ways to describe the code. If we need to backport and send something to the costumer, we can do the backport, poke the PTL, and he will generate another version which can be downloaded on github or via PIP, and present the version to our costumers. So, what are your thought around this? Anyone else has had problems with that? What would be the implications of removing the driver version strings? Erlon [1] https://releases.openstack.org/teams/cinder.html [2] https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/solid…

4 5

glance image upload error [Errno 32] Broken pipe
by Satish Patel 01 Jul '19

01 Jul '19

I have installed opnestack-ansible and integrate glance with ceph storage, first day when i upload image it works but today when i am trying to upload image i am getting this error [root@ostack-infra-2-1-utility-container-c166f549 ~]# openstack image create --file cirros-0.3.4-x86_64-disk.raw --container-format bare --disk-format raw --public cirros-0.3.4-tmp Error finding address for http://172.28.8.9:9292/v2/images/8f3456aa-52fc-4b4a-8b11-dfbadb8e88ca/file: [Errno 32] Broken pipe I do have enough space on ceph storage, i am not seeing any error on glance logs also which help me. [root@ostack-infra-01-ceph-mon-container-692bea95 root]# ceph df detail GLOBAL: SIZE AVAIL RAW USED %RAW USED OBJECTS 9314G 3526G 5787G 62.14 245k POOLS: NAME ID QUOTA OBJECTS QUOTA BYTES USED %USED MAX AVAIL OBJECTS DIRTY READ WRITE RAW USED images 6 95367M N/A 22522M 3.62 584G 2839 2839 2594k 36245 67568M vms 7 N/A N/A 1912G 76.58 584G 248494 242k 6567M 3363M 5738G volumes 8 N/A N/A 0 0 584G 0 0 0 0 0 backups 9 N/A N/A 0 0 584G 0 0 0 0 0 metrics 10 N/A N/A 0 0 584G 0 0 0 0 0

2 1

[kolla] [ceph] Ceph using cluster network for replication
by vladimir franciz blando 30 Jun '19

30 Jun '19

Hi, In my globals.yml file --- cluster_interface: "bond1" --- but after deployment, there's nothing on the ceph.conf file that indicates that it's using the cluster interface --- # docker exec ceph_mon cat /etc/ceph/ceph.conf [global] log file = /var/log/kolla/ceph/$cluster-$name.log log to syslog = false err to syslog = false log to stderr = false err to stderr = false fsid = f8ff1404-bead-422b-9076-21583012ad30 mon initial members = 172.16.43.22, 172.16.43.11, 172.16.43.12 mon host = 172.16.43.22, 172.16.43.11, 172.16.43.12 mon addr = 172.16.43.22:6789, 172.16.43.11:6789, 172.16.43.12:6789 auth cluster required = cephx auth service required = cephx auth client required = cephx setuser match path = /var/lib/ceph/$type/$cluster-$id [mon] mon compact on start = true mon cluster log file = /var/log/kolla/ceph/$cluster.log --- I was expecting cluster network = <cluster_network_cidr>. I even tried making a custom config (/etc/kolla/config/ceph/ceph.conf) which includes the cluster network = <cluster_network_cidr> public network = <public_network_cidr> and run "kolla-ansible -i multinode reconfigure" but it did nothing, was there something missing on what I did? - Vlad ᐧ

2 1

[keystone] Keystone Team Update - Week of 24 June 2019
by Colleen Murphy 28 Jun '19

28 Jun '19

# Keystone Team Update - Week of 24 June 2019 ## News ### Virtual Midcycle Planning We've begun planning our midcycle[1], which we will hold virtually sometime around or after milestone 2. Please participate in suggesting topics and the scheduling poll. [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-June/007344.html ## Open Specs Train specs: https://bit.ly/2uZ2tRl Ongoing specs: https://bit.ly/2OyDLTh ## Recently Merged Changes Search query: https://bit.ly/2pquOwT We merged 13 changes this week, including some advances in the oslo.limit and application credential access rules implementations. ## Changes that need Attention Search query: https://bit.ly/2tymTje There are 45 changes that are passing CI, not in merge conflict, have no negative reviews and aren't proposed by bots. ## Bugs This week we opened 3 new bugs and closed none. Bugs opened (3) Bug #1834294 (keystone:Undecided) opened by Eivinas https://bugs.launchpad.net/keystone/+bug/1834294 Bug #1834304 (keystone:Undecided) opened by Rohit Londhe https://bugs.launchpad.net/keystone/+bug/1834304 Bug #1834342 (keystone:Undecided) opened by Benoît Knecht https://bugs.launchpad.net/keystone/+bug/1834342 ## Milestone Outlook https://releases.openstack.org/train/schedule.html Spec freeze is in 4 weeks. Our midcycle will be held some time around or just after that, and feature proposal freeze closely follows. ## Help with this newsletter Help contribute to this newsletter by editing the etherpad: https://etherpad.openstack.org/p/keystone-team-newsletter

1 0

[nova] API updates week 19-26
by Ghanshyam Mann 28 Jun '19

28 Jun '19

Hello Everyone, Please find the Nova API updates of this week. API Related BP : ============ COMPLETED: 1. Support adding description while locking an instance: - https://blueprints.launchpad.net/nova/+spec/add-locked-reason Code Ready for Review: ------------------------------ 1. Add host and hypervisor_hostname flag to create server - Topic: https://review.opendev.org/#/q/topic:bp/add-host-and-hypervisor-hostname-fl… - Weekly Progress: patch is updated with review comment. ready for re-review. I will re-review it tomorrow. 2. Specifying az when restore shelved server - Topic: https://review.opendev.org/#/q/topic:bp/support-specifying-az-when-restore-… - Weekly Progress: Review comments is fixed and ready to re-review. 3. Nova API cleanup - Topic: https://review.opendev.org/#/c/666889/ - Weekly Progress: Code is up for review. A lot of files changed but should be ok to review. I have pushed a couple of patches for missing tests of previous microversions. 4. Detach and attach boot volumes: - Topic: https://review.openstack.org/#/q/topic:bp/detach-boot-volume+(status:open+O… - Weekly Progress: No Progress Spec Ready for Review: ----------------------------- 1. Nova API policy improvement - Spec: https://review.openstack.org/#/c/547850/ - PoC: https://review.openstack.org/#/q/topic:bp/policy-default-refresh+(status:op… - Weekly Progress: Under review and updates. 2. Support for changing deleted_on_termination after boot -Spec: https://review.openstack.org/#/c/580336/ - Weekly Progress: No update this week. 3. Support delete_on_termination in volume attach api -Spec: https://review.openstack.org/#/c/612949/ - Weekly Progress: No updates this week. 4. Add API ref guideline for body text - ~8 api-ref are left to fix. Previously approved Spec needs to be re-proposed for Train: --------------------------------------------------------------------------- 1. Servers Ips non-unique network names : - https://blueprints.launchpad.net/nova/+spec/servers-ips-non-unique-network-… - https://review.openstack.org/#/q/topic:bp/servers-ips-non-unique-network-na… 2. Volume multiattach enhancements: - https://blueprints.launchpad.net/nova/+spec/volume-multiattach-enhancements - https://review.openstack.org/#/q/topic:bp/volume-multiattach-enhancements+(… Bugs: ==== No progress report in this week too. I will start the bug triage next week. NOTE- There might be some bug which is not tagged as 'api' or 'api-ref', those are not in the above list. Tag such bugs so that we can keep our eyes. -gmann

3 3