- openstack-discuss - lists.openstack.org

[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 08 Apr '24

08 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 08 Apr '24

08 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

[Diversity] PTG Schedule
by Amy Marrich 06 Apr '24

06 Apr '24

The Diversity and Inclusion working group will hold a session Tuesday, April 9th at 14:00 UTC in the Cactus room. Agenda is available[0], please add any topics. Amy 0 - https://etherpad.opendev.org/p/apr2024-ptg-diversity

1 0

Re: [all] Review dependencies without update for long time
by Sean McGinnis 06 Apr '24

06 Apr '24

> Subject: Re: [all] Review dependencies without update for long time In case it's not known, there is a script in the repo that was created to help find some of this information: https://opendev.org/openstack/requirements/src/branch/master/tools/get-heal… > > > > 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). > > > > > > $ 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

1 0

[ptg][openstack-ansible] OpenStack-Ansible vPTG time and date
by Dmitriy Rabotyagov 06 Apr '24

06 Apr '24

Hi folks, Sorry for the late scheduling of vPTG this time. I've booked an Icehouse room for Tuesday, April 9 from 16:00 (4PM) till 18:00 (6PM) UTC. You can find the meeting link below [1]. An etherpad with some agenda is here: [2] [1] https://meetpad.opendev.org/apr2024-ptg-os-ansible [2] https://etherpad.opendev.org/p/osa-dalmatian-ptg

1 0

[opnestack][kolla-ansible]Mix compute inventory
by Nguyễn Hữu Khôi 06 Apr '24

06 Apr '24

Hello. I am reading about Kolla Ansible Inventory https://docs.openstack.org/kolla-ansible/latest/user/multinode.html In my environment, Controllers and Compute01>>>03 have same network interfaces But from compute04>>06 have different interface neutron_external_interface=*eth0.1 *api_interface=*eth0.2 *tunnel_interface= *eth0.3* Which is the best group for my case? [compute-custom] compute04 neutron_external_interface=*eth0.1 *api_interface=*eth0.2 * tunnel_interface=*eth0.3* compute05 neutron_external_interface=*eth0.1 *api_interface=*eth0.2 * tunnel_interface=*eth0.3* compute06 neutron_external_interface=*eth0.1 *api_interface=*eth0.2 * tunnel_interface=*eth0.3* Then put them to same block services which have Nova? I see the we prefer to use host_vars or*group_vars. *Do we have some examples about it? Thank you. Nguyen Huu Khoi

1 0

[Nova][Kolla][VDI] Introducing Kerbside delivery of VDI console sessions
by Michael Still 06 Apr '24

06 Apr '24

Hi all, for the longest time I've thought it was super cool that you could do something like this with Google Cloud: `gcloud compute ssh ...instance...` This causes a SSH session to run in your terminal that transparently proxies you through to the instance. It even orchestrates SSH authentication using a CA, but that's a story for another day. Aptira had a similar business need, but with more of a focus on virtual desktop environments, and therefore kindly supported my development work on a SPICE protocol native proxy I've called Kerbside [1][2]. The proxy works by scraping various clouds' REST APIs for "VDI capable" instances, and then making those available via short lived session tokens. The intention is that a service like Horizon or Skyline could request a session token for a specific instance, which is returned to the user as a `.vv` style virt-viewer configuration file. The user then opens the configuration file and a connection to the console on the relevant hypervisor is provided by Kerbside. Kerbside can do more than that of course. It has a simple management UI and API, which allows for things like forced termination of a console session once setup, logging and audit history, TLS support, and so forth. Kerbside and all associated work is licensed under the Apache 2 license, just the same as OpenStack, and positions clouds to offer Citrix-like virtual desktops to their users in a seamless manner. Why a SPICE proxy? As best as I can tell, SPICE still provides the richest virtual desktop experience. It supports high resolution desktops, multi-screen desktops, USB device passthrough, sound, multiple user connections to a single console, and so forth. Why not the current HTML5 transcoding proxy as used by Horizon? Unfortunately, the current HTML5 SPICE client does not support most of the features listed in the previous paragraph. While originally intended for the purposes of my personal Shaken Fist project, Kerbside now supports OpenStack and oVirt as well. In the case of OpenStack, this required a number of patches to OpenStack projects to get working [3]. Specifically I'd like to propose a new Nova API microversion to support a new "spice-direct" console type. I intend to work through the Nova specs process for the Nova related changes, and have created a blueprint [4] to track that work. I am working on a draft spec at the moment [5], but do not see the required changes to Nova as particularly invasive. You can of course assess that yourself by reading the proof of concept patches in the kerbside-patches repository. This raises some questions for me. Specifically: - is this functionality interesting to others? Or is it just me? - what is the process of proposing changes like this for Kolla and Kolla-Ansible? I chose to build my proof of concept on that platform, so I also have a number of aligned deployment patches there. - I've been out of the OpenStack universe for a while now. Is it too late to propose this work for Dalmation? Thanks, Michael 1: https://github.com/shakenfist/kerbside and https://github.com/shakenfist/kerbside-client 2: Why Kerbside? Well because Horizon and Skyline are distant things, whereas I wanted to create something closer... Like Kerbside pickup from a shop. 3: https://github.com/shakenfist/kerbside-patches 4: https://blueprints.launchpad.net/nova/+spec/libvirt-spice-direct-consoles 5: https://github.com/shakenfist/kerbside-patches/blob/develop/nova-specs/patc…

3 3

[blazar][ptg] Dalmatian PTG schedule
by Pierre Riteau 05 Apr '24

05 Apr '24

Hello, I have booked a PTG slot on Thursday, April 11 from 1500 to 1700 UTC for the Blazar project. The meeting will be held in the Bexar room. The initial agenda can be found here: https://etherpad.opendev.org/p/apr2024-ptg-blazar Please add any topics you would like to discuss. Anyone interested in Blazar is welcome to join. Cheers, Pierre Riteau (priteau)

1 0

[ptg][tacker]Dalmatian vPTG Planning
by Yasufumi Ogawa 05 Apr '24

05 Apr '24

Hi all, I've booked the slots[1] from Apr 9th to 11th, 6-8 UTC all the days, and setup the etherpad[2] for Tacker team. Please feel free to add your topics. [1] https://ptg.opendev.org/ptg.html [2] https://etherpad.opendev.org/p/apr2024-ptg-tacker Thanks, Yasufumi

1 0

[swift][ptg] Ops Feedback Session - 10th April at 1300 UTC
by Matthew Oliver 05 Apr '24

05 Apr '24

As we've done in PTGs past, we're getting devs and ops together to talk about Swift: what's working, what isn't, and what would be most helpful to improve. We're meeting in the dalmation swift meetpad room ( https://meetpad.opendev.org/swift-ptg-dalmatian) on Wednesday at 13:00UTC -- if you run a Swift cluster, we hope to see you there! Even if you can't make it, we'd appreciate it if you can offer some feedback on the etherpad ( https://etherpad.opendev.org/p/swift-dalmation-ops-feedback) This has always been a highlight at every PTG for us swift devs. Have your say and help make Swift even better! Matt

1 0