- openstack-discuss - lists.openstack.org

[all][tc] Modernize Python Stack
by Niklas Schwarz 11 Apr '24

11 Apr '24

Hello, I have just ran over the mailing listing post OpenStack 2024.2 testing runtime by Ganshyam Mann [1] on dropping support for python3.8 for the upcoming Openstack 2024.2 release. This post and some small contributions to some openstack components have lead me to write this post. What I would like to suggest to modernize the Python-Stack used for OpenStack. Such a modernization includes: - A current python version - A modern and up to date static code analysis - Introduce type annotations Let me explain what I mean: A current python version: The current supported Python versions are Python 3.8 to Python 3.11 [2]. As of writing, OpenStack Yoga was just moved to unmaintained. To install this release, e.g. on an Ubuntu Jammy operating system the packages are included in the Ubuntu-Packages. The default Python version on an Ubuntu 22.04 operating system is Python3.10. And looking at the support of the Python versions [3] Python 3.8 to 3.10 only receive security updates but the end is near for Python 3.8 to be out of support. The policy defined which Python version should be used for testing [4] will result that Python 3.8 is still used for the OpenStack 2024.1 release [5]. And this will also result in required support for Python3.8 in the upcoming releases of OpenStack. I my opinion the policy should be reworked and the OpenStack releases should be more aggressive on dropping support for older Python versions. Modern features of the language cannot be otherwise be used, therefor improvements in speed, security and general toolchain/ecosystem cannot be fully leveraged. By defining the lower bound of the Python Version we are limiting ourself to this version but we might also reduce the features we can use because of deprecations of the newer versions . A modern and up to date static code analysis: Currently flake8 and pylint are used both of which are modern analysis tools. But their configuration is in my opinion not up to date. Lets have a look at the configuration of the neutron-lib [6]. As seen a lot of rules are disabled by the configuration and are needed at the current moment at the state of the project. In addition some rules need to be adjusted such as the line length (80 characters is a very aggressive limit and on most modern displays a line length of 100 to 120 can fit without any problems, personal opinion). The adjustment of the static code analysis besides opinionated rules will lead me to my third point to modernize the Python stack used Introduce type annotations Python type annotations are well supported in the current Python versions and through the typing package additional types are added. The introduction of type annotations will improve the developer experience. This is also motivated by the Python foundation in pep-484 [7]. Because of the type annotation all modern IDEs can provide (more precise) type hints. The type hints can and in in my experience will reduce the introduction of bugs (accessing members or calling methods, no logical bugs) and will shorten the time to develop a new feature or fix a logical bug and do not run in runtime exceptions. The datatypes passed to a method are clear and we do not need to dig down a rabbithole to find out what is passed to a method. The name of a variable does not always tell the truth. As an example I want to look at a patch [8] for the neutron-vpnaas component. Christian Rohmann and I worked on this patch for the component together (this has also lead me to write this email) to improve the reconciling for VPNaaS. It took as along time to find out that a RouterInformation object is passed in to a method instead of a router but the variable was named router. We both agreed on that in the first place the naming of the variable was wrong but type annotations would have saved us a good amount of time. This does not mean that the naming is not important and that type annotations will save the world, the context which includes the name of variables is important and type annotations will add additional information to the context. And I have just touched the surface on what is possible with the introduction of type annotations, thinking of automatic document generation, test generation, even code generation,... As a reference to my point modernizing the static analysis this can then also include the introduction of mypy to check the types used. Of course such a change cannot be done in one big commit and needs time but I suggest to start adding type annotations and improve the overall code quality of the OpenStack services, starting with the oslo packages as they are used by mostly all OpenStack components. Of course such changes cannot be done for such a huge project in one day. It took a long time to remove support for Python 2. So I do not expect such changes to happen immediately. But it would be nice to have a discussion about it and maybe create a road map and adjust some policy on supported Python versions and create new policies how to write Python code and what additional tools should be used. I can also understand if not everything is possible but the last two points need to be addressed in my opinion. These changes will lead overall to better code quality but most important the introduction to the big code base will be easier for new developers and reviewers will also have a better time. Best regards Niklas [1] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [2] https://docs.openstack.org/tempest/latest/supported_version.html [3] https://devguide.python.org/versions/ [4] https://governance.openstack.org/tc/resolutions/20181024-python-update-proc… [5] https://governance.openstack.org/tc/reference/runtimes/2024.1.html [6] https://github.com/openstack/neutron-lib/blob/master/.pylintrc [7] https://peps.python.org/pep-0484/#rationale-and-goals [8] https://review.opendev.org/c/openstack/neutron-vpnaas/+/875745

15 27

[manila] Cancelling Apr 11th and Apr 18 weekly meetings
by Carlos Silva 11 Apr '24

11 Apr '24

Hello, zorillas! As this is PTG week, let's cancel this week's upstream meeting and also next week's meeting as we usually do. Thank you! carloss

1 0

[kolla-ansible][horizon]Create instance default parameters
by Franck VEDEL 11 Apr '24

11 Apr '24

Hi, With horizon, is it possible de have this default parameter when you create an instance: in source, create a new volume: « No ». And.. if it’s possible, how configure this with kolla-ansible ? Thank’s for your help. Franck

2 4

[keystone] Weekly meeting canceled 10-April-2024
by Dave Wilde 10 Apr '24

10 Apr '24

Hello all, I'm canceling this weeks keystone meeting in lieu of the PTG sessions we're holding today and tomorrow. Hope to see you there! /Dave

1 0

[kolla][kolla-ansible] How to debug container crashing or restarting
by Satish Patel 10 Apr '24

10 Apr '24

Folks, As soon as I deployed opensearch on the Zed release of openstack and found the opensearch_dashborad container kept restarting. So my question is how do I troubleshoot this kind of container crashing issue. Are there any guides to follow like stop container restart tasks and then get inside container check logs etc? I have checked docker logs <container_name> but didn't find any strange issue and logs are empty in /var/log/kolla/opensearch_dashborad/ In short I am clueless and I would like to change restart policy in docker so I can manually restart daemon to debug my issue. This is what logs showing in docker logs opensearch_dashboard INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/refs/json-schema-2020-12/index.js INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/refs/json-schema-2020-12/meta/meta-data.json INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/refs/json-schema-2020-12/meta/core.json INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/refs/json-schema-2020-12/meta/unevaluated.json INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/refs/json-schema-2020-12/meta/content.json INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/refs/json-schema-2020-12/meta/applicator.json INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/refs/json-schema-2020-12/meta/format-annotation.json INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/refs/json-schema-2020-12/meta/validation.json INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/refs/json-schema-2019-09/meta INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/refs/json-schema-2019-09/schema.json INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/refs/json-schema-2019-09/index.js INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/refs/json-schema-2019-09/meta/meta-data.json INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/refs/json-schema-2019-09/meta/core.json INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/refs/json-schema-2019-09/meta/content.json INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/refs/json-schema-2019-09/meta/applicator.json INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/refs/json-schema-2019-09/meta/validation.json INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/refs/json-schema-2019-09/meta/format.json INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/vocabularies/core INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/vocabularies/format INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/vocabularies/discriminator INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/vocabularies/jtd INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/vocabularies/validation INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/vocabularies/applicator INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/vocabularies/dynamic INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_mo

2 1

[ironic] PTG schedula
by Riccardo Pittau 10 Apr '24

10 Apr '24

Hello ironicers! A quick reminder on the Ironic PTG schedule for this week: Tuesday 09/04 13-17 UTC Wednesday 10/04 13-17 UTC Thursday 11/04 13-16 UTC You can find the full schedule and topics here https://etherpad.opendev.org/p/ironic-ptg-april-2024 Ciao Riccardo

1 2

[Glance] Cancelling Weekly Meeting for this Week
by Pranali Deore 09 Apr '24

09 Apr '24

Hello, As discussed during last week's meeting, cancelling the meeting for this week(11th April) since we all are meeting in PTG. See you all at PTG ! Thanks & Regards, Pranali

1 0

[Octavia] weekly meeting cancelled
by Gregory Thiemonge 09 Apr '24

09 Apr '24

Hi Folks, Tomorrow's weekly meeting is cancelled because of the PTG. Thanks, Greg

1 0

[kolla] cancelling weekly meeting on 10th April
by Michał Nasiadka 09 Apr '24

09 Apr '24

Hello, Since we all met on PTG sessions - let’s cancel weekly meeting this week. See you on 17th April Michał Nasiadka mnasiadka(a)gmail.com

1 0

[all] Package reproducibility: shall we hard-wire our CI to avoid it in the future?
by Thomas Goirand 09 Apr '24

09 Apr '24

Hi, It used to be that a number of packages were not reproducible. If you do not know why reproducibility of packages is important, please read on: https://reproducible-builds.org/ This has been patched numerous times in numerous packages. However, it looks like the community is still not aware of the problem, and how to avoid it. One of the very common pitfall, is adding a default in an oslo.config string, that leaks properties of the build host, like for example the hostname, the number of CPU cores, and so on. Here's a very common example that was commited last summer: https://review.opendev.org/c/openstack/oslo.messaging/+/889425/9/oslo_messa… Yet the fix is super simple, thanks to oslo.messaging sample_default: https://review.opendev.org/c/openstack/oslo.messaging/+/915314 If I'm writing this, it is *not* to point at anyone, especially *not* the commiter of the above patch. it just happen to be the latest occurrence I noticed thanks to the Debian bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068377 This message is only to raise awareness of the problem, and avoid having it happen again. I also wonder: would it be possible to have our CI avoid this type of mistake? It wouldn't be so hard to have the doc build twice, with different hostname, CPUs, etc. configuration, would it? (note: I'm not volunteering, just pushing for the idea...) Cheers, Thomas Goirand (zigo)

2 1

[openstack-helm] PTG schedule
by Vladimir Kozhukalov 09 Apr '24

09 Apr '24

Hey team, This is just a reminder that we booked two hours on Wednesday 04/10/2024 at 13:00 UTC and 14:00 UTC in the Cactus meeting room. Etherpad is here [1]. Feel free to add your topics for the discussion. Booking table is here [2]. [1] https://etherpad.opendev.org/p/apr2024-ptg-os-helm [2] https://ptg.opendev.org/ptg.html -- Best regards, Kozhukalov Vladimir

1 0

OpenStack OVN add secondary external network
by damage.alders-0j＠icloud.com 09 Apr '24

09 Apr '24

I've setup OpenStack version 2023.2 with with devstack on a Ubuntu 22.04 baremetal. I originally had one NIC (eth1, 192.XX.XX.XX) that works fine. Now I added a second NIC (eth2, 10.XX.XX.XX) to my machine and tried to add a secondary external network through: sudo ovs-vsctl add-br br-ex2 sudo ovs-vsctl add-port br-ex2 eth2 sudo ovs-vsctl set open . external-ids:ovn-bridge-mappings=public2:br-ex2 sudo ovs-vsctl set open . external-ids:ovn-cms-options="enable-chassis-as-gw" then my whole machine (including host and all instances) lost dns service, I can only ping ip addresses such as 8.8.8.8 instead of google.com. To be precise, I found out I lose dns service after `sudo ovs-vsctl add-port br-ex2 eth2` command. (Yes, I've moved ip from eth2 to br-ex2, but didn't help) I kept on creating a network and a router: openstack network create public2 --provider-network-type flat --provider-physical-network public2 --external openstack subnet create public2-subnet --network public2 --subnet-range 10.XX.XX.0/24 --no-dhcp --gateway 10.XX.XX.1 --allocation-pool start=10.XX.XX.10,end=10.XX.XX.30 openstack router create bridge-router --external-gateway public2 openstack router add subnet bridge-router shared-public2-subnet At this point, the router is accessible from eth2 after `sudo ovs-vsctl set open . external-ids:ovn-bridge-mappings=public2:br-ex2` command, but after I tried to allocate a floating ip from public2 to any instance, the instance is just not accessible from that ip. My ultimate goal is to be able to allocate floating ip to instances from eth2, so I can access instances from both eth1 and eth2 networks, but now I lost dns service and I'm unable to access instances from the allocated eth2 floating ip. Any suggestions?

1 0

[kolla] Dalmatian vPTG reminder
by Michał Nasiadka 09 Apr '24

09 Apr '24

Hello Koalas, This year the PTG slots are following: Kolla/Kolla-Ansible: Monday, 8th April, 13:00 - 17:00 UTC Kayobe: Tuesday, 9th April, 13:00 - 15:00 UTC You can check the slots always on the PTG website - https://ptg.opendev.org/ Etherpad link: https://etherpad.opendev.org/p/kolla-dalmatian-ptg See you on Monday!

2 1

[neutron] CI Meeting cancelled this week
by Yatin Karel 08 Apr '24

08 Apr '24

Hello Neutron Team !! As discussed over the previous meeting cancelling this week CI meeting for vPTG. -- Thanks and Regards Yatin Karel

1 0

Nova filter based on VM metadata?
by Ken D'Ambrosio 08 Apr '24

08 Apr '24

Hey, all. I'm looking for a way to to filter to a particular aggregate based on arbitrary VM metadata. (E.g., maybe FACTER facts from Puppet that we pass to the VM as metadata.) Could someone point me toward documentation that might outline how to accomplish that? As I see it, there's really one thing I need to understand -- the rest I can probably glean from extant filters: how (or if) a filter could access a given VM's metadata from the API creation request (if that's even possible). Thanks! -Ken

3 3

[nova][ptg] Nova at the Dalmatian vPTG
by Sylvain Bauza 08 Apr '24

08 Apr '24

Hey folks, During this week, the Nova community will discuss on their own topics in between Tuesday-Friday 1300-1700UTC, all of the slots being in the Diablo room. You can find the related connection details and the proposed schedule in the etherpad [1] but here's a rough schedule for people interested in attending our sessions : - *Tuesday* *13:00 UTC - 17:00 UTC* - Nova sessions - retro + dalmatian schedule - nova above k8s - unified limits - *Wednesday 13:00 UTC - 17:00 UTC*: Nova sessions - vmware discussions about scheduling and metadata api - cleaning old microversions ? - ephemeral encryption status and next steps - memory encryption next steps - *Thursday 13:00 UTC - 17:00 UTC* - Nova sessions - stateless firmware support - vTPM detection by libvirt - Gap between legacy deprecated live migration options vs new live migration options - event actions missing in our API - OpenAPI schemas support - *Friday 13:00 UTC - 17:00 UTC* - Nova sessions - SPICE-direct console support + remote-consoles problem - userdata update - volume-backed instance migration requiring SSH conn - can we push removal of tunnelled libvirt migrations in dalmatian or do we need to wait for next slurp? - no validation if queued oslo.messaging messages are targeted for this specific nova-compute (based on hostname) As also said in the etherpad, you're free to add your own topics to the etherpad (at the bottom please) so I can schedule them, but fwiw our sessions will already be pretty packed with a lot of things to discuss so maybe some of the topics will be on a temptative effort. [1] https://etherpad.opendev.org/p/nova-dalmatian-ptg Thanks, -Sylvain

1 1

Fix for arguments for subnet module for Ansible
by George Shuklin 08 Apr '24

08 Apr '24

Hello everyone. I wrote a small fix for subnet Ansible module to allow use of cidr together with subnet_pool, with tests and so on. I got an approval, it passed CI, but it is not merged. What steps are required to have it merged? https://review.opendev.org/c/openstack/ansible-collections-openstack/+/9073… Sorry for nagging.

1 2

[kolla] [Wallaby] Openstack operations 2x slower after rebuilding from RHEL8/Train to RHEL9/Wallaby
by Albert Braden 08 Apr '24

08 Apr '24

After rebuilding a couple of our clusters, moving from Train on RHEL8 to Wallaby on RHEL9, we see all openstack operations taking 2x longer. Even simple database reads such as "openstack user show" average 1.5 seconds on old regions and 3 seconds on rebuilt regions. I enabled debug and poked around in the logs but nothing is jumping out at me. I was thinking maybe mariadb needed to be tuned differently from RHEL8->9 but if I log into the mariadb container and query the database it seems equally fast; I can do 100 simple queries in a second. Where should I be looking for the source of this delay?

5 10

Re:[skyline] Running a Skyline in "subdirectory"
by 吴文相 08 Apr '24

08 Apr '24

Hello, Dmitriy Rabotyagov Sorry for late response, dev team will raise a ticket and update the conclusion later. Thanks Best Regrads Wu Wenxiang Original: From：Dmitriy Rabotyagov <noonedeadpunk(a)gmail.com>Date：2024-03-16 02:45:49(中国 (GMT+08:00))To：openstack-discuss <openstack-discuss(a)lists.openstack.org>Cc：Subject：[skyline] Running a Skyline in "subdirectory"Hey folks, I was looking into a way to make both Horizon and Skyline work at the same time, and found out that I'm not really able to make Skyline to run in sub-URL. So for instance the plan was to place Horizon under /horizon (which is easily doable) and then Skyline under /skyline. However so far I haven't found any setting or anything that would allow me to do so. Basically, I've realized that static content is _really_ static, which means it does have hardcoded URIs: https://opendev.org/openstack/skyline-console/src/branch/master/skyline_con… So either I'm just not realizing the very simple technique which allows to overcome hardcoded in static files URIs (like some rewrite?), or just serving Skyline from a subdirectory is not possible by design... Would be great if someone could share their experience about Skyline and if anyone managed to do what I'm looking for. Thanks in advance

2 1

[neutron][zun] Container not able to communicate via dummy interface
by James Leong 08 Apr '24

08 Apr '24

Hi all, Using the OpenStack dashboard, we have launched two containers, Container-1 and Container-2, on two different hosts, Host-1 and Host-2. We attached both containers to a virtual network called VirtualNet (10.10.20.0/24). During container creation, both of them get an IP address via DHCP, as provided in the figure attached. Container-1 can successfully ping to 10.10.20.176 (Container-2 eth0 address) and Container-2 can successfully ping to 10.10.20.113 (Container-1 eth0 address). After this, we created a dummy interface (dummy0) on Container-1 and assigned an IP address (192.168.20.113). We want to ping 192.168.20.113 from Container-2. Therefore, we added a route in Container-2 using the command "ip add route 192.168.20.113 via 10.10.20.113 dev eth0." The ping is not successful. We captured the packets in Container-1 using tcpdump command on eth0, and we were able to observe that the icmp echo requests are received and the icmp echo replies are generated. However, the responses are not reaching back to Container-2. The screenshot of the tcpdump on eth0 for Container-1 is attached herewith. In the security groups, we added a rule allowing all ICMP traffic (ingress and egress) to 0.0.0.0/0. Any recommendations or suggestions are greatly appreciated. Best, James

1 0

[security-sig] PTG schedule
by Jeremy Stanley 08 Apr '24

08 Apr '24

Quick reminder that the Security SIG has a couple of sessions scheduled at the PTG this week: * Thursday, 2024-04-11, 21:00-22:00 UTC * Friday, 2024-04-12, 13:00-14:00 UTC There are no particular items on the agenda; feel free to join if you have something OpenStack security-related you want to talk about. The relevant Meetpad and Etherpad URLs can be found on https://ptg.opendev.org/ as usual. -- Jeremy Stanley

1 0

[neutron] Bug Deputy Report April 1 - April 7
by Miro Tomaska 08 Apr '24

08 Apr '24

Hello All Below is the bug deputy report for the week of April 1 High: - https://bugs.launchpad.net/neutron/+bug/2060163 - Partially confirmed, making it high since sporadically affects CI Medium: - https://bugs.launchpad.net/neutron/+bug/206005 - Owner: iulhaq RFE: - https://bugs.launchpad.net/neutron/+bug/2059897 - I don't see this being a bug, maybe an RFE? Undecided: - https://bugs.launchpad.net/neutron/+bug/2059902 - Waiting on more validation using filter-validation extension -- Miro Tomaska Senior Software Engineer

1 0

[all] Review dependencies without update for long time
by Takashi Kajinami 07 Apr '24

07 Apr '24

Hello, I recently spent some time reviewing the packages currently in the requirements repo and found some packages which haven't been updated for multiple years. This is a good indication that we have to review the features dependent on these packages to determine if the features should be re-implemented by a different package or dropped. Keeping such features with unmaintained library may likely cause problems in future maintenance (Python 3.12 support is a good example). Ideally we should have done this during 2024.1 cycle because of SLURP, but the sooner is always the better. I'd suggest that all projects spend some time to review the packages which haven't get updated for long time. I quickly grepped the packages which haven't get any bump in 202X and got the list which shows number of libraries. $ git blame -e upper-constraints.txt | grep -e '201[0-9]-' | sed -e 's/.* 201/201/' | sort 2015-06-08 22:09:46 +1200 500) simplegeneric===0.8.1 2016-05-19 06:30:24 +0000 169) extras===1.0.0 2016-11-14 17:07:49 +0000 69) XStatic-Font-Awesome===4.7.0.0 2016-12-18 07:20:50 +0000 583) xvfbwrapper===0.2.9 2017-02-21 14:05:54 -0600 118) pyinotify===0.9.6 2017-02-21 14:05:54 -0600 146) jsonpath-rw===1.4.0 2017-02-21 14:05:54 -0600 150) traceback2===1.4.0 2017-02-21 14:05:54 -0600 163) XStatic-roboto-fontface===0.5.0.0 2017-02-21 14:05:54 -0600 208) unittest2===1.1.0 2017-02-21 14:05:54 -0600 226) XStatic-objectpath===1.2.1.0 2017-02-21 14:05:54 -0600 256) dib-utils===0.0.11 2017-02-21 14:05:54 -0600 283) XStatic-Angular-Schema-Form===0.8.13.0 2017-02-21 14:05:54 -0600 287) XStatic-bootswatch===3.3.7.0 2017-02-21 14:05:54 -0600 290) XStatic-term.js===0.0.7.0 2017-02-21 14:05:54 -0600 317) pydotplus===2.0.2 2017-02-21 14:05:54 -0600 332) murano-pkg-check===0.3.0 2017-02-21 14:05:54 -0600 347) testscenarios===0.5.0 2017-02-21 14:05:54 -0600 354) nose-exclude===0.5.0 2017-02-21 14:05:54 -0600 357) elasticsearch===2.4.1 2017-02-21 14:05:54 -0600 366) XStatic-tv4===1.2.7.0 2017-02-21 14:05:54 -0600 367) XStatic-JSEncrypt===2.3.1.1 2017-02-21 14:05:54 -0600 380) linecache2===1.0.0 2017-02-21 14:05:54 -0600 390) openstack.nose-plugin===0.11 2017-02-21 14:05:54 -0600 403) testrepository===0.0.20 2017-02-21 14:05:54 -0600 41) requests-aws===0.1.8 2017-02-21 14:05:54 -0600 420) zake===0.2.2 2017-02-21 14:05:54 -0600 448) proboscis===1.2.6.0 2017-02-21 14:05:54 -0600 465) XStatic-smart-table===1.4.13.2 2017-02-21 14:05:54 -0600 487) testresources===2.0.1 2017-02-21 14:05:54 -0600 60) pysendfile===2.0.1 2017-02-21 14:05:54 -0600 613) XStatic-D3===3.5.17.0 2017-02-21 14:05:54 -0600 70) nose===1.3.7 2017-02-21 14:05:54 -0600 88) nosexcover===1.0.11 2017-02-21 14:05:54 -0600 96) Tempita===0.5.2 2017-06-28 10:13:14 +0000 576) logutils===0.3.5 2017-09-10 10:31:03 +0000 514) repoze.lru===0.7 2017-11-22 13:05:07 +0000 184) whereto===0.4.0 2017-11-24 06:19:46 +0000 501) python-pcre===0.7 2018-01-08 14:19:08 +0000 203) oslosphinx===4.18.0 2018-01-30 00:00:05 +0000 486) requestsexceptions===1.4.0 2018-03-01 06:25:09 +0000 537) CouchDB===1.2 2018-03-01 06:25:09 +0000 540) ws4py===0.5.1 2018-03-01 06:25:09 +0000 97) ply===3.11 2018-03-28 06:24:01 +0000 349) sadisplay===0.4.9 2018-05-11 06:33:27 +0000 236) threadloop===1.0.2 2018-05-13 06:27:38 +0000 289) XStatic-JS-Yaml===3.8.1.0 2018-05-13 06:27:38 +0000 309) XStatic-Angular-UUID===0.0.4.0 2018-05-13 06:27:38 +0000 524) XStatic-Json2yaml===0.1.1.0 2018-05-13 06:27:38 +0000 579) XStatic-Angular-Vis===4.16.0.0 2018-05-13 06:27:38 +0000 64) XStatic-FileSaver===1.3.2.0 2018-06-02 06:29:39 +0000 262) lockfile===0.12.2 2018-07-09 06:36:15 +0000 408) python-consul===1.1.0 2018-07-14 06:36:14 +0000 525) boto===2.49.0 2018-09-11 06:22:11 +0000 381) oauth2client===4.1.3 2019-01-01 06:10:54 +0000 471) cotyledon===1.7.3 2019-02-14 06:49:02 +0000 299) XStatic-mdi===1.6.50.2 2019-02-14 06:51:11 +0000 113) XStatic-Jasmine===2.4.1.2 2019-04-15 06:20:25 +0000 362) pysmi===0.3.4 2019-04-23 13:47:12 +0100 572) sphinx-testing===1.0.1 2019-05-12 12:14:16 +0000 343) os-service-types===1.7.0 2019-05-14 06:11:31 +0000 275) retryz===0.1.9 2019-05-14 06:11:31 +0000 400) bitmath===1.3.3.1 2019-05-14 06:11:31 +0000 535) cachez===0.1.2 2019-05-26 06:27:47 +0000 195) URLObject===2.4.3 2019-05-26 06:27:47 +0000 215) pact===1.12.0 2019-05-26 06:27:47 +0000 30) vintage===0.4.1 2019-05-26 06:27:47 +0000 313) capacity===1.3.14 2019-05-26 06:27:47 +0000 365) infi.dtypes.iqn===0.4.0 2019-05-26 06:27:47 +0000 422) flux===1.3.5 2019-05-26 06:27:47 +0000 442) api-object-schema===2.0.0 2019-05-26 06:27:47 +0000 46) waiting===1.4.1 2019-05-26 06:27:47 +0000 481) sentinels===1.0.0 2019-05-26 06:27:47 +0000 609) confetti===2.5.3 2019-05-26 06:27:47 +0000 84) infi.dtypes.wwn===0.1.1 2019-07-13 06:50:09 +0000 53) jsonpath-rw-ext===1.2.2 2019-08-15 06:36:56 +0000 528) mitba===1.1.1 2019-09-05 07:13:47 +0000 293) gossip===2.4.0 2019-10-07 06:11:48 +0000 112) rsd-lib===1.2.0 2019-10-07 06:11:48 +0000 74) pysnmp===4.4.12 2019-10-22 21:19:25 +0000 336) sqlalchemy-migrate===0.13.0 2019-11-01 17:20:28 +0200 71) nosehtmloutput===0.0.7 2019-11-30 06:10:48 +0000 513) ndg-httpsclient===0.5.1 -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

3 3

[openstack][cinder-backup] How check backup retain size.
by Nguyễn Hữu Khôi 07 Apr '24

07 Apr '24

Hello. I use s3 as cinder backup driver. My volume size is 2TB and It runs forever. I would like to know if we can check how many mb retain in this job. Thank you. Regards Nguyen Huu Khoi

1 0

[openstack][cinder][backup] ransomware with cinder volume
by Nguyễn Hữu Khôi 07 Apr '24

07 Apr '24

Hello, I would like to know if volumes which were attached to compute nodes and they will be impacted by ransomware. Could I have some sharing in this scenario? Currently, I just backup configure instance configure and create a new one with this configuration. Thank you. Nguyen Huu Khoi

2 2