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

[nova] indices on shadow-able fields
by Mohammed Naser 11 Apr '19

11 Apr '19

Hi everyone. In continuing with the trend of interesting database issues, I've found the following interesting thing. It looks like we don't have indices for all of our tables that can be large on the deleted field. I think it would be beneficial *especially* for cases when the archiving code runs. The big ones that are huge users in terms of rows without index are `instance_system_metadata` and `instance_extra`. `instance_action_events` and `instance_actions` don't have any either. I believe without this, it results in doing a full table scan during the clean up which can become pretty resource intensive. I'll defer to the Nova team on the best practice about this (or if this is even a bug), but I just wanted to bring the attention to this as I've had mild success trying to tame a large database and leveraging the archive DB tooling. Thanks, Mohammed -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

4 4

[placement] Virtual Pre-PTG
by Chris Dent 11 Apr '19

11 Apr '19

We decided in today's placement meeting [1] that because of limited time and space at the PTG and conflicting responsibilities of the participants we'd like to prepare ourselves to only talk about things at the PTG that we weren't otherwise able to decide beforehand, in email. I've committed to orchestrating and then summarizing several conversations through a series of email threads based on the topics we choose. To do that, we need to make sure that the etherpads [2,3] reflect the important topics a few weeks before the PTG, so we can have enough time to talk. I propose we start the process the week of the 8th, giving us 3 weeks of discussion prior to the PTG, with the caveat that the week of the 22nd my availability will be limited. Between now and then make sure you topics get on the etherpads, along with as much additional info as you would normally put there. Don't fret if you think of something after the 8th, just put it on the etherpad as normal, and we'll figure it out. If the 8th is too soon or too late, please propose an alternative. If there's no need to change, I'll get things rolling on the 8th. This way the time at the PTG can be spent more oriented to reviewing our progress thus far and talking about how we can best achieve our goals in the future. Thanks [1] http://eavesdrop.openstack.org/meetings/placement/2019/placement.2019-03-25… [2] https://etherpad.openstack.org/p/placement-ptg-train [3] https://etherpad.openstack.org/p/ptg-train-xproj-nova-placement -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

2 4

[telemetry][gnocchi] Gnocchi alternatives
by Trinh Nguyen 11 Apr '19

11 Apr '19

Hi team, Yesterday, we talk about Gnocchi and how it is embedded in many parts of Telemetry these days [1]. Since we many things in Ceilometer have been replaced by Gnocchi which is an external project, we need the project to be sustainable at some point. I'm not sure about that since the Gnocchi's cores change jobs recently (?). So, I continue here the discussion on whether or not to find alternatives for Gnocchi. People have suggested: - Prometheus: we then can get rid of AODH and use Prometheus's Alert Manager - InfluxDB (part of Monasca): and because many parts of Monasca can do what Ceilometer/AODH doing we can possibly replace Telemetry completely (?) Correct me if I'm missing something. All ideas are welcomed. Yours, [1] https://etherpad.openstack.org/p/telemetry-train [2] http://eavesdrop.openstack.org/irclogs/%23openstack-telemetry/%23openstack-… -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

4 3

[sdk][ansible][inventory] Server-side filtering capability for nova API
by Игорь Тиунов 11 Apr '19

11 Apr '19

Hi. I saw that there some work regarding filtering in the inventory module. Also, I looked at how it will be used in future versions of ansible (os_server_facts module). I am worried about client-side nature of this filtering. The large deployments can have thousands of vms in one openstack project and such an environment can be very dynamic (vms are created/deleted frequently). The inventory collection can be done from multiple ansible management nodes and all these facts can lead to significant performance impact not only on the client side but on the server side also - a large amount of data will be requested from nova api servers. I want to propose the usage of server-side filtering capability for nova API: https://developer.openstack.org/api-ref/compute/?expanded=list-servers-deta… These filters are used at database level and will add a significant performance boost during inventory collection. I want to propose the usage of filters in ansible openstack inventory plugin but first, such filters should be implemented in openstacksdk level. I suggest splitting filters into two parts - the api_filters and metadata_filters. The api_filters will be used for server-side filtering and metadata_filters for client-side filtering. I have created the snippet with prototype code. There a _split_filters method and related changes for list_hosts and search_hosts methods: https://gist.github.com/ITD27M01/01bc73120bb97b237f53fa418dc83629 What do you think?

2 2

[telemetry] Procedure for merging patches
by Trinh Nguyen 11 Apr '19

11 Apr '19

Hi team, One of the thing that has been brought up in the last meeting is what is the process of merging a patch. So, let's try this first: - For small patches (e.g., change strings, fix typos, update docs): any core can approve for merging. - For a patch that implements a new feature, removes a feature, patch that has huge changes (in the number of changed files and loc, etc.) or any patch that is in doubt: we need at least 2 cores to give a +2 and then the PTL will merge it. Of course, we can change the procedure when we see issues. For now, this should be a guideline for the team. Please feel free to comment. Yours, -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

2 3

[auto scaling sig][ptg][senlin][heat]
by Duc Truong 11 Apr '19

11 Apr '19

Everyone, Since the summit and PTG are coming up, I have updated the auto scaling SIG etherpad [1] with some topics. Please fill in if you are planning to participate and any other topics you would like to discuss. Duc (dtruong) [1] https://etherpad.openstack.org/p/DEN-auto-scaling-SIG

1 0

[nova] Pre-PTG spec review day(s)
by Eric Fried 11 Apr '19

11 Apr '19

Dear Nova spec authors and reviewers- Since our PTG time is shorter than usual this cycle, and we usually run out of time before we finish our agenda anyway, I would like to try to get as much spec review work wrapped up as possible before Denver. To that end, I would like to propose at least one spec review day over the next couple of weeks. This will be a chance for authors and reviewers to interact in a more synchronous fashion and hopefully let us close on some of the more significant issues. Can we do this next Tuesday, April 9th; and if necessary (and seeming productive) the following Tuesday, April 16th? If folks are amenable, I'll follow up with some logistics by the end of this week. Thanks, efried .

5 7

[dev][cinder][stable-maint] final os_brick release from stable/pike
by Brian Rosmaita 11 Apr '19

11 Apr '19

I just discovered that there was a bug in the dashboard I posted on today's Cinder meeting agenda, and this unmerged backport to stable/pike os_brick was left off: https://review.openstack.org/647809 The dashboard link, https://tiny.cc/cinder-stable-pike , now points to a correct dashboard (sorry about that, hemna!) Current status is: 2 backports +W and currently in recheck 2 backports with only one +2 - https://review.openstack.org/647745 - https://review.openstack.org/647743 1 backport without negative feedback - https://review.openstack.org/647809 There's one review not listed on the dashboard because it has a -W from its author, which I'm taking to mean it's not ready. But here's the link in case anyone wants to look: https://review.openstack.org/539359 We need to release the final pike os_brick soon, so prompt positive (or negative) attention from stable cores to the above will be appreciated. cheers, brian

1 0

[nova] Rebuild from cell0 limitation for personality files
by Matt Riedemann 11 Apr '19

11 Apr '19

I wanted to get some wider attention on what I think will be a limitation in the rebuild from cell0 spec [1]. The main idea in that spec is the user tries to create a server which fails during scheduling to find a host and puts the instance into ERROR state and "buries" it in cell0. With a new microversion, the user can attempt to rebuild the server from cell0 and go through scheduling again. This is part of a bigger effort to support pre-emptible instances where scheduling fails during server create, an external reaper service tries to make room by destroying some pre-emptible instances, and then the server gets rebuilt. The issue I've found is that if the server was created with personality files using microversion 2.1, fails, and then the user goes to rebuild it, their personality files will be lost because (1) we don't persist personality files anywhere, not even the RequestSpec and (2) microversion 2.57 deprecated the personality files parameter from the rebuild API [2]. Since you'll have to use a newer microversion > 2.57 to rebuild from cell0, you can't specify the personality files again. Are we OK with this? We deprecated personality files for a reason [3] so this is a natural extension of that deprecation saying "going forward you should not be using these things and if you do there could be limitations". The user has an obvious recourse: delete the server and re-create it rather than rebuild from cell0. I don't want to consider un-deprecating personality files in the rebuild API just for this new microversion to rebuild from cell0. Another alternative is persisting personality files in the RequestSpec but I'm not sure how much people would support that - although it would fix some other known limitations with personality files, like the fact that if you create a server with files and then shelve offload, the files are gone when you unshelve. I have a similar issue with cross-cell resize [4]. [1] https://review.openstack.org/#/c/648686/1/specs/train/approved/enable-rebui… [2] https://docs.openstack.org/nova/latest/reference/api-microversion-history.h… [3] https://specs.openstack.org/openstack/nova-specs/specs/queens/implemented/d… [4] https://review.openstack.org/#/c/642807/3/specs/train/approved/cross-cell-r… -- Thanks, Matt

3 2

OpenStack Stein is officially released!
by Sean McGinnis 10 Apr '19

10 Apr '19

The official OpenStack Stein release announcement has been sent out: http://lists.openstack.org/pipermail/openstack-announce/2019-April/002019.h… Thanks to all who were part of making the stein series a success. Really great to see how much the community was able to accomplish over this last cycle. This marks the official opening of the releases repo for Train. Stein is now a full stable branch. Thanks! Sean

2 1