June 2021 - openstack-discuss - lists.openstack.org

[all]Introduction to venus which is the project of log management and has been contributed to the OpenStack community
by Liye Pang(逄立业) 10 Sep '21

10 Sep '21

Hello everyone, after feedback from a large number of operations and maintenance personnel in InCloud OpenStack, we developed the log management project “Venus” for the OpenStack projects and that has contributed to the OpenStack community. The following is an introduction to “Venus”. If there is interest in the community, we are interested in proposing it to become an official OpenStack project in the future. Background In the day-to-day operation and maintenance of large-scale cloud platform, the following problems are encountered： l Time-consuming for log querying while the server increasing to thousands. l Difficult to retrieve logs, since there are many modules in the platform, e.g. systems service, compute, storage, network and other platform services. l The large amount and dispersion of log make faults are difficult to be discovered. l Because of distributed and interaction between components of the cloud platform, and scattered logs between components, it will take more time to locate problems. About Venus According to the key requirements of OpenStack in log storage, retrieval, analysis and so on, we introduced Venus project, a unified log management module. This module can provide a one-stop solution to log collection, cleaning, indexing, analysis, alarm, visualization, report generation and other needs, which involves helping operator or maintainer to quickly solve retrieve problems, grasp the operational health of the platform, and improve the management capabilities of the cloud platform. Additionally, this module plans to use machine learning algorithms to quickly locate IT failures and root causes, and improve operation and maintenance efficiency. Application scenario Venus played a key role in the following scenarios： l Retrieval: Provide a simple and easy-to-use way to retrieve all log and the context. l Analysis: Realize log association, field value statistics, and provide multi-scene and multi-dimensional visual analysis reports. l Alerts：Convert retrieval into active alerts to realize the error finding in massive logs. l Issue location: Establish a chain relationship and knowledge graphs to quickly locate problems. Overall structure The architecture of log management system based on Venus and elastic search is as follows: Diagram 0: Architecture of Venus venus_api: API module，provide API、rest-api service. venus_manager: Internal timing task module to realize the core functions of the log system. Current progress The current progress of the Venus project is as follows: l Collection：Develop fluentd collection tasks based on collectd to read, filter, format and send plug-ins for OpenStack, operating systems, and platform services, etc. l Index：Dealing with multi-dimensional index data in elasticsearch, and provide more concise and comprehensive authentication interface to return query results. l Analysis：Analyzing and display the related module errors, Mariadb connection errors, and Rabbitmq connection errors. l Alerts：Develop alarm task code to set threshold for the number of error logs of different modules at different times, and provides alarm services and notification services. l Location：Develop the call chain analysis function based on global_requested series, which can show the execution sequence, time and error information, etc., and provide the export operation. l Management：Develop configuration management functions in the log system, such as alarm threshold setting, timing task management, and log saving time setting, etc. Application examples Two examples of Venus application scenarios are as follows. 1. The virtual machine creation operation was performed on the cloud platform and it was found that the virtual machine was not created successfully. First, we can find the request id of the operation and jump to the virtual machine creation call chain page. Then, we can query the calling process, view and download the details of the log of the call. 2. In the cloud platform, the error log of each module can be converted into alarms to remind the users. Further, we can retrieve the details of the error log and error log statistics. Next step The next step of the Venus project is as follows: * Collection：In addition to fluent, other collection plugins such as logstash will be integrated. * Analysis: Explore more operation and maintenance scenarios, and conduct statistical analysis and alarm on key data. * display: The configuration, analysis and alarm of Venus will be integrated into horizon in the form of plugin. * location: Form clustering log and construct knowledge map, and integrate algorithm class library to locate the root cause of the fault. Venus Project Registry Venus library: https://opendev.org/inspur/venus You can grab the source code using the following git command: git clone https://opendev.org/inspur/venus.git Venus Demo Youtu.be: <https://youtu.be/mE2MoEx3awM> https://youtu.be/mE2MoEx3awM

7 15

[masakari] Deprecating process monitor - querying the community in this thread
by Radosław Piliszek 23 Aug '21

23 Aug '21

Hello users of Masakari, As the Masakari core team, we have discussed the deprecation/retirement of one of the monitors - the process monitor. The reason is simple - we consider its mission is better handled by other software such as Kubernetes, Docker, or systemd, depending on how you deploy your OpenStack cluster. I believe the process monitor might have made sense in the pre-containerisation, pre-systemd world but it does not seem to any longer. Please let us know, by replying to this mail, if you have a use case for the process monitor that cannot be handled by the aforementioned software. -yoctozepto

1 1

[tripleo] Changing TripleO's release model
by Wesley Hayutin 20 Aug '21

20 Aug '21

Greetings TripleO community! At the most recent TripleO community meetings we have discussed formally changing the OpenStack release model for TripleO [1]. The previous released projects can be found here [2]. TripleO has previously released with release-type[‘trailing’, ‘cycle-with-intermediary’]. To quote the release model doc: ‘Trailing deliverables trail the release, so they cannot, by definition, be independent. They need to pick between cycle-with-rc <https://releases.openstack.org/reference/release_models.html#cycle-with-rc> or cycle-with-intermediary <https://releases.openstack.org/reference/release_models.html#cycle-with-int…> models.’ We are proposing to update the release-model to ‘independent’. This would give the TripleO community more flexibility in when we choose to cut a release. In turn this would mean less backporting, less upstream and 3rd party resources used by potentially some future releases. To quote the release model doc: ‘Some projects opt to completely bypass the 6-month cycle and release independently. For example, that is the case of projects that support the development infrastructure. The “independent” model describes such projects.’ The discussion here is to merely inform the greater community with regards to the proposal and conversations regarding the release model. This thread is NOT meant to discuss previous releases or their supported status, merely changing the release model here [3] [0] https://etherpad.opendev.org/p/tripleo-meeting-items [1] https://releases.openstack.org/reference/release_models.html [2] https://releases.openstack.org/teams/tripleo.html [3] https://opendev.org/openstack/releases/src/branch/master/deliverables/xena

9 17

It's time to submit your OpenStack User Survey
by Allison Price 19 Aug '21

19 Aug '21

Hi everyone, Here’s my annual email requesting you complete the OpenStack User Survey [1] and share with your local communities / community friends who are operating OpenStack. Anonymous reposes and aggregated data from the User Survey are shared with the OPenStack PTLs and overall community to help understand operator software requirements. If you have never taken it before, please do! We welcome your feedback and I am happy to answer any questions you may have. If you are one of the many who have, all of your previous information should be stored, so you will just need to provide updates where relevant and re-save. Thank you all! Cheers, Allison [1] https://www.openstack.org/user-survey/survey-2021 <https://www.openstack.org/user-survey/survey-2021> Allison Price Director of Marketing & Community OpenInfra Foundation e: allison(a)openstack.org <mailto:allison@openstack.org>

1 1

[masakari] Compute service with name XXXXX not found.
by at 19 Aug '21

19 Aug '21

Hi, I have some problem with masakari. I can create segment (from CLI and Horizon), but can't create host (the same result from Horizon and CLI). openstack segment host create XXXXX COMPUTE SSH segment_id returns BadRequest: Compute service with name XXXXX could not be found. XXXXX is the name which Horizon suggest, and it's a name of compute host. openstack compute service list returns proper list with state up/enabled on compute hosts (zone nova) Maybe I misunderstood some parameters of host create? As "type" I use COMPUTE, what value should it be? From "Binary" column of openstack compute service list? What is "control_attributes" field, because documentation lacks preceise information what value should be there and what is it use for. Tried to found some info on this error but I haven't found anything... Thanks in advance for any help. Best regards Adam Tomas

4 7

[interop][cinder] review of next.json (part 2)
by Brian Rosmaita 09 Aug '21

09 Aug '21

Hello Interop WG, The Cinder team completed its discussion of what capabilities should be added as advisory in next.json at yesterday's weekly cinder meeting [0]. The tldr; is that we don't have anything to propose for inclusion in next.json at the present time. The team does have some general questions that would help us determine the suitability of some proposed capabilities. We'd like to invite someone from the Interop WG to the cinder xena R-9 virtual midcycle (Wednesday 4 August 2021, 1400-1600 UTC) so we can discuss this "live". So if someone could put 1400 UTC 4 August on their schedule for a 20 minute discussion, that would be very helpful. cheers, brian [0] http://eavesdrop.openstack.org/meetings/cinder/2021/cinder.2021-05-12-14.00…

3 8

Re: [neutron-vpnaas][kolla-ansible][victoria] Growing memory consumption with only one VPN connection
by at 09 Aug '21

09 Aug '21

Hi, 1. There is only one, bidirectional vpn connection between project networks in two regions 2. there is no (or almost no) traffic on this vpn link 3. second region is on one host (kolla all-in-one) and situation looks the same- with vpn service enabled there is excessive Memory use (growing also about 5-6MB/ minute and forcing the system to use swapfile) there is no big cpu usage (ofcourse also due to no traffic inside VPN) It's the same case even if there's no vpn connection configured. Best regards Adam Tomas Wysłane z iPhone'a > Wiadomość napisana przez Vinh Nguyen Duc <vinhducnguyen1708(a)gmail.com> w dniu 29.06.2021, o godz. 11:04: > > > Hi Adam, > Do you think the VPN connection is use CPU and memory to encrypt the VPN traffic? > > On Mon, Jun 28, 2021 at 14:30 Adam Tomas <bkslash(a)poczta.onet.pl <mailto:bkslash@poczta.onet.pl>> wrote: > Hi, > I have problem with neutron vpnaas - after enabling vpnaas plugin everything was ok at first. I was able to create VPN connection and communication is correct. But after a week of running vpnaas (only one VPN connection created/working!) I’ve noticed, that neutron-vpnaas takes more and more memory. I have 5 processes on each controller (there should be always five? Or it is changing dynamically?): > > 42435 1545384 0.6 8.6 5802516 5712412 ? S Jun15 110:50 /var/lib/kolla/venv/bin/python3.8 /var/lib/kolla/venv/bin/neutron-server --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugins/ml2/ml2_conf.ini --config-file /etc/neutron/neutron_vpnaas.conf > 42435 1545389 0.6 8.5 5735832 5645856 ? S Jun15 112:16 /var/lib/kolla/venv/bin/python3.8 /var/lib/kolla/venv/bin/neutron-server --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugins/ml2/ml2_conf.ini --config-file /etc/neutron/neutron_vpnaas.conf > 42435 1545378 0.5 8.5 5734192 5643620 ? S Jun15 108:09 /var/lib/kolla/venv/bin/python3.8 /var/lib/kolla/venv/bin/neutron-server --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugins/ml2/ml2_conf.ini --config-file /etc/neutron/neutron_vpnaas.conf > 42435 1545372 0.5 8.5 5731128 5641436 ? S Jun15 109:07 /var/lib/kolla/venv/bin/python3.8 /var/lib/kolla/venv/bin/neutron-server --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugins/ml2/ml2_conf.ini --config-file /etc/neutron/neutron_vpnaas.conf > 42435 1545369 0.6 8.4 5637084 5547392 ? S Jun15 114:21 /var/lib/kolla/venv/bin/python3.8 /var/lib/kolla/venv/bin/neutron-server --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugins/ml2/ml2_conf.ini --config-file /etc/neutron/neutron_vpnaas.conf > > now neutron_server takes over 27G of RAM on each controller: > > neutron_server running 10.2 27.2G > > After stopping all neutron containers and starting it again neutron takes a lot less memory: > > neutron_server running 0.5 583M > > but memory usage keeps growing (about 5-6 M every minute). > What’s wrong? When I disable vpnaas globally there’s no problem with excessive memory usage, so it’s vpnaas for sure… > > Best regards > Adam Tomas

3 2

[nova][neutron][deployment-projects] Re secbug #1734320
by Radosław Piliszek 04 Aug '21

04 Aug '21

Hello Folks! I am writing this because a recent patch proposed to DevStack [1] mentioned "when using ml2/ovs vif isolation should always be used to prevent cross tenant traffic during a live migration" which is related to secbug #1734320 "Eavesdropping private traffic" [2]. However, I've found that none of the publicly-available deployment projects seem to be using ``isolate_vif``. [3] [4] Should this be corrected? PS: I used the deployment-projects tag as a collective tag to avoid mentioning all the projects (as it is too long to write :-) ). I hope that relevant people see this if need be or someone passes the information to them. For now, I am curious whether this should actually be enforced by default with ML2/OVS. [1] https://review.opendev.org/c/openstack/devstack/+/796826 [2] https://bugs.launchpad.net/neutron/+bug/1734320 [3] https://codesearch.opendev.org/?q=%5Cbisolate_vif%5Cb&i=nope&files=&exclude… [4] https://github.com/search?p=1&q=isolate_vif&type=Code -yoctozepto

3 2

[horizon][stable] [release] Proposal to make stable/queen as EOL
by vishal manchanda 16 Jul '21

16 Jul '21

Hi all, As discussed in the last horizon weekly meeting[1] on 2021-06-23, I would like to announce that the horizon team decided to make stable/queen branch as EOL. Consider this mail as an official announcement for that. I would like to know if anyone still would like to keep this branch to be open otherwise, I will purpose an EOL patch for this branch. Thanks & Regards, Vishal Manchanda [1] https://meetings.opendev.org/meetings/horizon/2021/horizon.2021-06-23-15.00…

3 4

[nova][stable] Adding nova-core to nova stable branches
by Stephen Finucane 13 Jul '21

13 Jul '21

Happy Friday (again), Following on from my earlier email regarding os-vif stable branch permissions, I'd like to once again propose that we add nova-core to the list of teams with +2 rights on nova stable branches. Unlike the os-vif change, this has been discussed extensively in the past, most recently during the Victoria PTG [1] (search for "Can we add nova-core to nova-stable-maint") and therefore carries a little more baggage with it. Last time we discussed this, there were concerns from some existing stable cores that not all of nova-core were sufficiently well acquainted with stable branch policy and it was suggested that review velocity was sufficient. However, the stable team has remained pretty stable (heh) over the last couple of cycles and is staffed with developers with ample experience of both nova itself and the backport policies of nova and OpenStack as a whole. In addition, we continue to have a long tail of open stable reviews [2] from various people. The stable branches are increasingly important for users and organizations alike, and a faster, smoother backport policy encourages people to have an upstream-first mentality when it comes to maintaining a product built on these branches. The alternative is to handle these backports in a downstream-first or downstream- only manner, which results in duplication of effort and, over the long-term, potential difficulties keeping downstream and upstream in-sync. I think the time has long since passed where we should remove the artificial barrier that exists here. I expect all nova cores will have the maturity and sensibility to ask questions where uncertainty exists and only approve backports that they are confident and knowledgeable about. I do not expect existing stable cores will be sidelined either. Far from it, in fact. Existing stable cores will continue to be valuable both for their reviews and knowledge of the intricacies of stable policy. I proposed a waiting period of one week before making changes to os-vif permissions, but given the history around changes to nova stable core, I think we would benefit from some additional time to assuage any concerns that may still exist. I propose that we come to a decision by 09-Aug, or two weeks from now. If necessary, we can discuss this in real-time during the nova team meeting next Tuesday. Cheers, Stephen [1] https://etherpad.opendev.org/p/nova-victoria-ptg [2] https://review.opendev.org/q/project:openstack/nova+NOT+branch:master+is:op…

2 2