April 2022 - openstack-discuss - lists.openstack.org

[Ceph Rados Gateway] 403 when using S3 client
by Taltavull Jean-François 26 Jun '22

26 Jun '22

Hi All, I get an http 403 error code when I try to get the bucket list with Ubuntu (Focal) S3 client (awscli). S3 api has been activated in radosgw config file and EC2 credentials have been created and put in S3 client config file. Otherwise, everything is working fine with OpenStack client. My deployment: - OSA 23.2.0 - OpenStack Wallaby - Ceph and Rados GW Octopus Has any of you already experienced this kind of behaviour ? Many thanks, Jean-Francois

3 6

[oslo] Propose to EOL stable/queens, stable/rocky on all the oslo scope
by Herve Beraud 24 Jun '22

24 Jun '22

Hi, On our last meeting of the oslo team we discussed the problem with broken stable branches (rocky and older) in oslo's projects [1]. Indeed, almost all these branches are broken. Előd Illés kindly generated a list of periodic-stable errors on Oslo's stable branches [2]. Given the lack of active maintainers on Oslo and given the current status of the CI in those branches, I propose to make them End Of Life. I will wait until the end of month for anyone who would like to maybe step up as maintainer of those branches and who would at least try to fix CI of them. If no one will volunteer for that, I'll EOLing those branches for all the projects under the oslo umbrella. Let us know your thoughts. Thank you for your attention. [1] https://meetings.opendev.org/meetings/oslo/2021/oslo.2021-10-04-15.00.log.t… [2] http://lists.openstack.org/pipermail/openstack-discuss/2021-July/023939.html -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud

5 5

R: R: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve metrics using ceilometer and gnocchi
by Molka Gharbaoui 22 Jun '22

22 Jun '22

3 4

[all][tc] Change OpenStack release naming policy proposal
by Slawek Kaplonski 03 Jun '22

03 Jun '22

Hi, During the last PTG in April 2022 in the TC meeting we were discussing our release naming policy [1]. It seems that choosing appropriate name for every releases is very hard and time consuming. There is many factors which needs to be taken into consideration there like legal but also meaning of the chosen name in many different languages. Finally we decided that now, after Zed release, when we will go all round through alphabet it is very good time to change this policy and use only numeric version with "year"."release in the year". It is proposed in [2]. This is also good timing for such change because in the same release we are going to start our "Tick Tock" release cadence which means that every Tick release will be release with .1 (like 2023.1, 2024.1, etc.) and every Tock release will be one with .2 (2023.2, 2024.2, etc.). [1] https://etherpad.opendev.org/p/tc-zed-ptg#L265[1] [2] https://review.opendev.org/c/openstack/governance/+/839897[2] -- Slawek Kaplonski Principal Software Engineer Red Hat -------- [1] https://etherpad.opendev.org/p/tc-zed-ptg#L265 [2] https://review.opendev.org/c/openstack/governance/+/839897

16 42

[Neutron][neutron-vpnaas] proposing Mohammed Naser for neutron-vpnaas core reviewer
by Lajos Katona 12 May '22

12 May '22

Hi, I would like to propose Mohammed Naser (mnaser) as a core reviewer to neutron-vpnaas. He and his company uses neutron-vpnaas in production and volunteered to help in the maintenance of it. You can vote/feedback in this email thread. If there is no objection by 6th of May, we will add Mohammed to the core list. Thanks Lajos

6 6

[all][tc][policy][heat][cinder] Continuing the RBAC PTG discussion + policy pop-up meeting new time
by Ghanshyam Mann 10 May '22

10 May '22

Hello Everyone, As we said in PTG about continuing the RBAC discussion on open questions (currently from Heat and Cinder), we are scheduling the call on April 26 Tuesday from 14:30-15:00 UTC. And we will use the same time for the policy-popup team meeting every alternate Tuesday to answer RBAC queries from any projects. Meeting Details: - https://wiki.openstack.org/wiki/Consistent_and_Secure_Default_Policies_Popu… Agenda (you can add for this or coming meetings) - https://etherpad.opendev.org/p/rbac-zed-ptg#L97 -gmann

1 2

[TripleO] Tear down of Train centOS 7 check jobs and integration line
by Ronelle Landy 09 May '22

09 May '22

Hello All, We have been running check/gate testing and integration lines for the Train release on both CentOS7 and CentOS 8. Following the work on CentOS 9 and the longevity of the Train release, we proposed removing the CentOS 7 Train jobs and building/testing changes to this release on CentOS 8 only. We floated this proposal with some interested parties and received no objections so we are beginning work on this tear down. We anticipate that removing the CentOS 7 jobs will allow patches to merge quicker and will free up resources for future work. Please respond if you have any questions or concerns. Thanks, Ronelle (for the TripleO CI team)

2 2

[manila] Zed cycle bug squash
by Carlos Silva 06 May '22

06 May '22

Greetings Zorillas and interested stackers! As mentioned in the previous weekly meetings, we will soon be meeting for the first bugsquash of the Zed release! The event will be held from May 2nd to May 6th, providing an extended contribution window. May 2nd 15:00 - 16:00 UTC - Kick off May 5th 15:00 - 16:00 UTC - Mid term checkpoint (we won't have our regular Manila meeting on this day) May 6th 15:00 - 15:30 UTC - Wrap Up We will use a meetpad for these meetings [1]. The main idea of this event is to go over the list of stale bugs and act on them, either seeing if they are incomplete or invalid at this point or working on them. The stale bugs list will be available on [2]. [1] https://meetpad.opendev.org/ManilaZed1Bugsquash [2] https://ethercalc.openstack.org/1nesczgjufb9 See you next week! Thank you, carloss

1 1

[all][tc][Release Management] Improvements in project governance
by Slawek Kaplonski 05 May '22

05 May '22

Hi, During the Zed PTG sessions in the TC room we were discussing some ideas how we can improve project governance. One of the topics was related to the projects which don't really have any changes in the cycle. Currently we are forcing to do new release of basically the same code when it comes to the end of the cycle. Can/Should we maybe change that and e.g. instead of forcing new release use last released version of the of the repo for new release too? If yes, should we then automatically propose change of the release model to the "independent" maybe? What would be the best way how Release Management team can maybe notify TC about such less active projects which don't needs any new release in the cycle? That could be one of the potential conditions to check project's health by the TC team. Another question is related to the projects which aren't really active and are broken during the final release time. We had such problem in the last cycle, see [1] for details. Should we still force pushing fixes for them to be able to release or maybe should we consider deprecation of such projects and not to release it at all? [1] http://lists.openstack.org/pipermail/openstack-discuss/2022-March/027864.ht… -- Slawek Kaplonski Principal Software Engineer Red Hat -------- [1] http://lists.openstack.org/pipermail/openstack-discuss/2022-March/027864.ht…

4 4

[api=sig][i18n][infra][tc] Cleaning up more defunct mailing lists
by Jeremy Stanley 04 May '22

04 May '22

A quick audit of the mailing lists we host at lists.openstack.org turned up the following 11 which have had no new posts for at least three years now: * openstack-api-consumers * openstack-de * openstack-el * openstack-i18n-fr * openstack-ir * openstack-personas * openstack-ru * openstack-sos * openstack-tw * openstack-vi * third-party-announce I'd like to clean them up by removing their list configurations, but leaving any public archives intact. Are there any objections? Should any of the above have future messages redirected to a different list (though since they haven't had any for years, that's probably unnecessary)? -- Jeremy Stanley

5 8