November 2020 - openstack-discuss

[barbican] Stable Branch Liaison Update
by Douglas Mendizabal 03 Nov '20

03 Nov '20

Hi openstack-discuss, I've updated the Cross Project Liaison Wiki [1] to revert our Stable Branch liaison to myself as current Barbican PTL. I am wondering what the process is to get myself added to the barbican-stable-maint group in gerrit? [2] Unfortunately, our only team member on that team has not been very active the last few months and we have a growing list of patches to the stable branches that we have been unable to merge. Any pointers would be greatly appreciated. Thanks - Douglas Mendizábal [1] https://wiki.openstack.org/wiki/CrossProjectLiaisons#Stable_Branch [2] https://review.opendev.org/#/admin/groups/1097

2 1

[masakari] Wallaby PTG Summary
by Radosław Piliszek 03 Nov '20

03 Nov '20

Hello Everyone! Masakari had 3 2-hour sessions and we managed to discuss a broad range of proposals and assign tasks to interested parties. (And this was my first time chairing a PTG as PTL). Thank you, everyone who participated! Here is a summary of the PTG discussions. The whole discussion has been written down in the etherpad. [1] We acknowledged that the project has lost its momentum during the last cycle (Victoria) and we hope to restore it now. To this end, we are reviving interesting old blueprints and specs. Some of these are already at the implementation stage, ready for reviews. Some of the discussed proposals fall into the 'low code impact, high (positive) usability impact' category, the most prominent being ways to have more flexibility in disabling/enabling the HA scope as well as generally more friendly approach towards user errors (not evacuating 'pinned' instances). On the other hand, some proposals involve deeper architectural changes to Masakari, such as the shift from reliance on Pacemaker/Corosync stack to Consul and/or etcd (possibly also for coordination), as well as making Masakari inspect the host status via both inbound and outbound means (including power management for checks and fencing). To this end, we plan to investigate a possible integration with Ironic as our gate to the baremetal world. Another proposal worth noting is the Masakari 'restore previous state' workflow, meant to help operators move instances back to their original location once the local problem is solved. Yet another proposal is increasing the resilience under the current scope (Pacemaker/Corosync) by retrying host checks (several sampled observations rather than one) and implementing adaptive rules to consider large-scale failures. We also discussed general maintenance tasks. We decided to give some love to the documentation and make sure it's not self-contradictory and also in agreement with the actual code, as well as include general recommendation on how Masakari is supposed to be deployed to have it work optimally. Finally, we discussed a few miscellaneous proposals such as making Masakari a better container world citizen by removing the reliance on systemd. [1] https://etherpad.opendev.org/p/masakari-wallaby-vptg Kind regards, -yoctozepto

1 0

[openstack-helm] No OSH meeting today
by Gage Hugo 03 Nov '20

03 Nov '20

Hello, the meeting for today has been cancelled, we will meet next week.

1 0

[keystone] No keystone team meeting Nov 3
by Nikolla, Kristi 03 Nov '20

03 Nov '20

Hi all, There will be no keystone team meeting on IRC today, on November 3rd. Best, Kristi

1 0

[cinder] reminder: weekly meeting wednesday 4 nov at 1400utc
by Brian Rosmaita 03 Nov '20

03 Nov '20

After two weeks of not having meetings due to summit/forum/ptg, the cinder team will be holding its weekly meeting at the usual time (1400 UTC) and location (#openstack-meeting-alt) tomorrow (wednesday 4 november). People who had been following daylight saving (or summer) time until recently, keep in mind that although the UTC time of the meeting has not changed, it may be an hour earlier for you in your local time. cheers, brian

1 0

[neutron] Team meeting
by Slawek Kaplonski 03 Nov '20

03 Nov '20

Hi, Just a quick reminder. Today at 14:00 UTC we will have neutron team meeting in the #openstack-meeting-3 room @freenode. Meeting's agenda is available in [1]. If You have any topics which You want to discuss, please add them to the "On demand" section. See You all at the meeting :) [1] https://wiki.openstack.org/wiki/Network/Meetings -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[placement][nova][cinder][neutron][blazar] Placement governance switch(back)
by Stephen Finucane 03 Nov '20

03 Nov '20

Placement has been a separate project with its own governance since Stein [1]. Since then, the main drivers behind the separation have moved onto pastures new and with Tetsuro sadly declaring his non- candidacy for the PTL position for Wallaby [2], we're left in the unenviable position of potentially not having a PTL for the Wallaby cycle. As such, it's probably time to discuss the future of Placement governance. Assuming no one steps forward for the Placement PTL role, it would appear to me that we have two options. Either we look at transitioning Placement to a PTL-less project, or we move it back under nova governance. To be honest, given how important placement is to nova and other projects now, I'm uncomfortable with the idea of not having a point person who is ultimately responsible for things like cutting a release (yes, delegation is encouraged but someone needs to herd the cats). At the same time, I do realize that placement is used by more that nova now so nova cores and what's left of the separate placement core team shouldn't be the only ones making this decision. So, assuming the worst happens and placement is left without a PTL for Victoria, what do we want to do? Stephen PS: Apologies if I missed other projects with an interest in placement. I did try to catch them all /o\ [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-February/002575… [2] http://lists.openstack.org/pipermail/openstack-discuss/2020-September/01749…

8 10

[neutron][core team] (Re)adding Oleg Bondarev to the Neutron core team
by Slawek Kaplonski 03 Nov '20

03 Nov '20

Hi, I'm glad to announce that I just fast-tracked back Oleg to the Neutron core team. Oleg was Neutron core in the past and now, since few months he is again one of the most active Neutron reviewers [1]. Welcome back in the core team Oleg :) [1] https://www.stackalytics.com/report/contribution/neutron-group/90 -- Slawek Kaplonski Principal Software Engineer Red Hat

3 2

[cyborg] PTG Summary and Wallaby Release Schedule
by yumeng bao 03 Nov '20

03 Nov '20

Hi all, Thank you all for the PTG participation! All our agreements and decisions are marked in the etherpad[1] with AGREED word. And I have proposed the Wallaby_Release_Schedule[2] on Cyborg wiki page to track features with milestone. [1]https://etherpad.opendev.org/p/cyborg-wallaby-goals [2]https://wiki.openstack.org/wiki/Cyborg/Wallaby_Release_Schedule Regards, Yumeng

1 0

[neutron] bug deputy report for week of 2020-10-26
by Bence Romsics 03 Nov '20

03 Nov '20

Hi Team, We had the following new bugs on the week of the PTG. Sorry for sending the report a bit late. Critical: * https://bugs.launchpad.net/neutron/+bug/1901534 Neutron fail to create networks because of MTU value changes proposed: https://review.opendev.org/#/q/topic:bug/1901534 Medium: * https://bugs.launchpad.net/neutron/+bug/1901527 Agent API gets broken if OVN DB is upgraded to the one introducing chassis_private change series proposed: https://review.opendev.org/#/q/topic:bug/1901527 * https://bugs.launchpad.net/neutron/+bug/1901992 Original default route in DVR SNAT namespace is not recovered after creating and deleting /0 extraroute The first fix proposed won't work since it would have been an API change. No fix proposed for the re-stated problem (bug comments #4 and #7) at the moment. * https://bugs.launchpad.net/neutron/+bug/1902512 neutron-ovn-tripleo-ci-centos-8-containers-multinode fails on private networ creation (mtu size) unassigned Low: * https://bugs.launchpad.net/neutron/+bug/1901936 [OVN Octavia Provider] OVN provider loadbalancer failover should fail as unsupported fix proposed: https://review.opendev.org/760209 Incomplete: * https://bugs.launchpad.net/neutron/+bug/1902211 Router State standby on all l3 agent when create Looks vpnaas related. The reporter is asking for help in debugging a lock that's never released. Not reproducible at will at the moment. * https://bugs.launchpad.net/neutron/+bug/1901707 race condition on port binding vs instance being resumed for live-migrations Broken out of https://bugs.launchpad.net/neutron/+bug/1815989. * https://bugs.launchpad.net/neutron/+bug/1463631 60_nova/resources.sh:106:ping_check_public fails intermittently Sporadic re-appearance of an ages old bug, with hardly enough information to reproduce at will. Cheers, Bence

1 0

[tripleo] please avoid creating ansible playbooks that call modules for trivial tasks
by Bogdan Dobrelya 02 Nov '20

02 Nov '20

Hi, In today TripleO client development we invoke ansible playbooks instead of Mistral workflows. I believe this may only be justified for non-trivial things. Otherwise please just import python modules into the client command actions without introducing additional moving parts in the form of ansible modules (that import the same python modules as well). Ansible brings declarative DSL that sometimes can better and simpler and faster describes things to do and shape inputs data, than if the same would be done in python, in the client. What should be the trivial thing and non-trivial then? Well, I think that example [0] illustrates such a trivial thing. A new playbook [1] would only install a few packages then "returns" back into python and calls a new ansible module [2]. And that new module only wraps [3] the same code being removed from the client: from tripleo_common.image import build ... manager = build.ImageBuildManager(<args>) I see no point of adding a new playbook and a new module for that trivial example. Those 4 packages could (and should) be as well installed from the client caller code without any ansible involved in the middle IMO. [0] https://review.opendev.org/#/c/759954/ [1] https://review.opendev.org/#/c/759953/3/tripleo_ansible/playbooks/cli-overc… [2] https://review.opendev.org/#/c/759953/3/tripleo_ansible/ansible_plugins/mod… -- Best regards, Bogdan Dobrelya, Irc #bogdando

6 9

[charms] OpenStack Charms 20.10 release is now available
by Peter Matulis 02 Nov '20

02 Nov '20

The 20.10 release of the OpenStack Charms is now available. This release brings several new features to the existing OpenStack Charms deployments for Queens, Rocky, Stein, Train, Ussuri, Victoria and many stable combinations of Ubuntu + OpenStack. Please see the Release Notes for full details: https://docs.openstack.org/charm-guide/latest/2010.html == Highlights == * OpenStack Victoria OpenStack Victoria is now supported on Ubuntu 20.10 (natively) and Ubuntu 20.04 LTS (via UCA). * Gnocchi and external root CA for S3 The gnocchi charm now supports the configuration of an external root CA in the gnocchi units. This is useful when an encrypted S3 (storage backend) endpoint uses certificates that are not managed by Vault. * Arista - Supported releases The neutron-api-plugin-arista charm now supports all OpenStack releases starting with Queens. * Neutron Gateway and additional data on ports and bridges The neutron-gateway charm now marks the openvswitch ports and bridges it creates as managed by the charm. This allows for less riskier cleanup mechanisms to be implemented. * cinder charm: Allow specifying the default volume type The cinder charm can now set the default volume type. This is to support scenarios where multiple storage backends are being used with Cinder. * Action based migration from Neutron ML2+OVS to ML2+OVN New actions have been introduced to enable migration of a Neutron ML2+OVS based deployment to ML2+OVN. * New charm: ceph-iscsi The ceph-iscsi charm has been promoted to supported status. This charm implements the Ceph iSCSI gateway, which provides iSCSI targets backed by a Ceph cluster. == OpenStack Charms team == The OpenStack Charms team can be contacted on the #openstack-charms IRC channel on Freenode. == Thank you == Lots of thanks to the below 30 charm contributors who squashed 45 bugs, enabled support for a new release of OpenStack, improved documentation, and added exciting new functionality! Alex Kavanagh Andrea Ieri Andreas Jaeger Aurelien Lourot Chris MacNaughton Corey Bryant Dan Ardelean David Ames Dmitrii Shcherbakov Edin Sarajlic Edward Hope-Morley Felipe Reyes Frode Nordahl Gabriel Adrian Hemanth Nakkina James Page Jorge Niedbalski Liam Young Martin Kalcok Martin Kopec Marton Kiss Michael Quiniola Nobuto Murata Pedro Guimaraes Peter Matulis Ponnuvel Palaniyappan Rodrigo Barbieri Xav Paice camille.rodriguez zhhuabj -- OpenStack Charms Team

1 0

Re: [keystone][policy] user read-only role not working
by melanie witt 02 Nov '20

02 Nov '20

Adding back the mailing list +openstack-discuss@ On 11/1/20 23:15, its-openstack(a)zohocorp.com wrote: > Dear Openstack, > > we are implementing this reader role through kolla-ansible. Need > help in understanding the policy file for adding custom role both in > nova and keystone. You can learn how to use the policy file directly by reading the docs I linked earlier: * https://docs.openstack.org/security-guide/identity/policies.html * https://docs.openstack.org/oslo.policy/train/admin/policy-json-file.html And then the APIs you can control access to in nova are shown in this sample file: * https://docs.openstack.org/nova/train/configuration/sample-policy.html APIs in keystone are shown in this sample file: * https://docs.openstack.org/keystone/train/configuration/samples/policy-yaml… I'm afraid I don't know anything about how to adjust the policy file through kolla-ansible though. Cheers, -melanie > ---- On Fri, 02 Oct 2020 02:12:39 +0530 *melanie witt > <melwittt(a)gmail.com>* wrote ---- > > On 9/25/20 07:25, Ben Nemec wrote: > > I don't believe that the reader role was respected by most > projects in > > Train. Moving every project to support it is still a work in > progress. > > This is true and for nova, we have added support for the reader role > beginning in the Ussuri release as part of this spec work: > > https://specs.openstack.org/openstack/nova-specs/specs/ussuri/implemented/p… > <https://specs.openstack.org/openstack/nova-specs/specs/ussuri/implemented/p…> > > > Documentation: > > https://docs.openstack.org/nova/latest/configuration/policy-concepts.html > <https://docs.openstack.org/nova/latest/configuration/policy-concepts.html> > > > To accomplish a read-only user in the Train release for nova, you can > DIY to a limited extent by creating custom roles and adjusting your > policy.json file [1][2] accordingly. There are separate policies for > GET/POST/PUT/DELETE in many cases so if you were to create a role > ReadWriteUser you could specify that for POST/PUT/DELETE APIs and > create > another role ReadOnlyUser and specify that for GET APIs. > > Hope this helps, > -melanie > > [1] > https://docs.openstack.org/nova/train/configuration/sample-policy.html > <https://docs.openstack.org/nova/train/configuration/sample-policy.html> > > [2] https://docs.openstack.org/security-guide/identity/policies.html > <https://docs.openstack.org/security-guide/identity/policies.html> > > > On 9/24/20 11:58 PM, its-openstack(a)zohocorp.com > <mailto:its-openstack@zohocorp.com> wrote: > >> Dear Openstack, > >> > >> We have deployed openstack train branch. > >> > >> This mail is in regards to the default role in openstack. we are > >> trying to create a read-only user i.e, the said user can only > view in > >> the web portal(horizon)/using cli commands. > >> the user cannot create an instance or delete an instance , the same > >> with any resource. > >> > >> we created a user in a project test with reader role, but in > >> horizon/cli able to create and delete instance and similar to other > >> access also > >> if you so kindly help us fix this issue would be grateful. > >> > >> the commands used for creation > >> > >> > >> > >> $ openstack user create --domain default --password-prompt > >> test-reader(a)test.com <mailto:test-reader@test.com> > <mailto:test-reader@test.com <mailto:test-reader@test.com>> > >> $ openstack role add --project test --user test-reader(a)test.com > <mailto:test-reader@test.com> > >> <mailto:gowtham.sankar@zohocorp.com > <mailto:gowtham.sankar@zohocorp.com>> reader > >> > >> > >> > >> Thanks and Regards > >> sysadmin > >> > >> > >> > >> > >> > > > > >

1 0

[tripleo] stable/victoria for tripleo repos
by Marios Andreou 02 Nov '20

02 Nov '20

Hello all, I got some pings about tripleo stable/victoria so here is an update. The tripleo-ci team is busy preparing and we are almost ready. Basically we've blocked branching until we have adequate CI coverage. This means check & gate jobs but also promotion jobs so that check & gate aren't running with stale content. tl;dr We are aiming to branch victoria tripleoclient & common today and everything else next week - with more details below but please note: PLEASE AVOID MERGING to the stable/victoria tripleoclient/common that will appear after [4] until we are confident that our ci coverage is working well. Status: Most of our 'core' (standalone/scenarios/undercloud etc) check/gate jobs match on branch like [1] so we expect those to run OK once there is a stable/victoria available. There is ongoing work for branchful, upgrade, 3rd party and ovb jobs but we will not block branching on those. The victoria integration pipeline [2] (which produces current-tripleo) is in good shape. It was blocked on a nit in the component pipeline but it is resolved with [3]. Once we have a victoria promotion then we should be all clear to branch stable/victoria. Actions: A). today: make stable/victoria for python-tripleoclient & tripleo-common. The change at [4] will do this once merged. We will use this to see our check/gate jobs run against victoria & fix issues. B). next week: once we are happy with A). AND we've had a promotion, we release and make stable/victoria for everything else. Hopefully B). will happen end of next week but that depends on how well the above goes (plus inevitable delays cos PTG), I'll repeat this cos it's important: PLEASE AVOID MERGING to stable/victoria tripleoclient/common for now until we are confident that our jobs are doing the right thing! As always grateful for a sanity check or any thoughts about any of the above - I'm pretty new to this (weshay has been a great help so far thank you weshay++), thanks, marios [1] https://opendev.org/openstack/tripleo-ci/src/commit/d5514028452f9d427949f5a… [2] https://review.rdoproject.org/zuul/builds?pipeline=openstack-periodic-integ… [3] https://review.rdoproject.org/r/#/c/30654/ [4] https://review.opendev.org/#/c/759449/

1 2

[nova] python3.9 support
by Balázs Gibizer 02 Nov '20

02 Nov '20

Hi, I run unit and functional tests (where applicable) for nova, python-novaclient, os-vif, placement, osc-placement, os-traits, os-resource-classes with python 3.9 and everything is green. I've proposed some tox.ini targets where it was needed [1][2][3] Cheers, gibi [1]https://review.opendev.org/#/c/760884/ [2]https://review.opendev.org/#/c/760890/ [3]https://review.opendev.org/#/c/760912/

2 1

Python 3.9 is here in Debian Sid
by Thomas Goirand 02 Nov '20

02 Nov '20

Hi there! Matthias Klose decided that uploading Python 3.9 on the 14th of this month (yes, the same day of the OpenStack release) would be fun. I am now really having fun ... fixing bugs! :) What's not so funny for me, is that some key packages like Greenlet or lxml aren't built yet for Python 3.9, even though they should. As a consequence, I just need to wait to be able to upload to Unstable. So this will delay my usual announcement for the release GA in Debian (even though the unofficial Victoria repo for Buster is ready and I could spawn VMs on Buster + Victoria). Anyways, all of this will settle slowly. Though Python 3.9 is here to stay, and to soon reach Ubuntu as well (it's planned for the next release). It'd be nice if projects were starting to investigate gating on Python 3.9 as early as possible. As much as I can tell, there's not so many issues to fix. The first one I fixed is here: https://review.opendev.org/758237 but I don't expect much more, and hopefully, I'll be able to propose more patch as I find the issues. Must we wait until Python 3.9 reaches Ubuntu to enable gating in the OpenStack projects? FYI, I do expect Victoria to run over Python 3.9 in Bullseye. Please don't reply with the usual "Victoria doesn't support it", because that's irrelevant. I'm fine with backporting patches, as long as they also exist in Wallaby. Cheers, Thomas Goirand (zigo)

7 9

[magnum] hyperkube deprecation situation
by Ionut Biru 02 Nov '20

02 Nov '20

Hi guys, I was hoping that in Victoria there will be a decision regarding this topic. Currently, if I use vanilla magnum, I'm stuck on 1.18.6 being the latest version, even so 1.18.10 was released. We are kinda stuck on a version that maybe in the near future is pruned to security issues. How do other operators are using magnum (vanilla) and keeping their kubernetes up to date? Are operators using a forked version of https://review.opendev.org/#/c/752254/ ? -- Ionut Biru - https://fleio.com

2 2

[openstack-ansible] Wallaby PTG results
by Dmitriy Rabotyagov 02 Nov '20

02 Nov '20

Hi, Bellow you may find summarization of descisions that were taken during PTG discussion. Victoria retrospective ---------------------------- 1. We're pretty far from dropping resource creation code out of the tempest, as we should respect TripleO needs here. So leaving as is during this cycle but adding option to be possible to omit resource creation. 2. We decided to postpone prometheus integration (as well as libvirtd exporter) as we don't have enough resource to implement and moreover support it in the future. 3. Decided to leave ELK stack in ops repo as for now. 4. Adjusting bootstrap-ansible to pick up gerrit patches idea was also postponed as has super low prio and we have a lot of more useful things on our hands 5. We didn't have much progress in tempest coverage of existing roles, we should proceed with it during W. Same is applicable to the roles overall speedup topic. Descisions taken for Wallaby -------------------------------------- 1. Remove nspawn from docs, and set it to unmaintained state in V. Remove code in W. 2. Document how upgrade paths for distro installs are difficult, and may/may not align with OSA releases 3. Check through the logs what roles are we covering with tempest, and what not 4. extract deprecation messages from journal files to the separate log 5. Continue working on speeding up OSA runtime: - Fight with skipped tasks (ie by moving them to separate files that would be included) - most valid for systemd service, systemd_networkd and python_venv_build roles - Try to split up variables by group_vars - Try to use include instead of imports again 6. Set TRANSFORM_INVALID_GROUP_CHARS to ignore in V and replace invalid chars in groups later. For octavia we can temporary add 2 groups (old style and new style) for migration process. 7. Try to speedup zuul required projects clone process and talk to zuul folks 8. Finally do Integrated repo deploy for Zun and sync deployment process with service docs 9. Installation of ara for deployer needs - ARA deploy on localhost, configured by variables - Option for remote ARA - Option for UI server locally 10. Create Root CA on deploy host and overall SSL approach refactoring. Futher discussion in SPEC: https://review.opendev.org/#/c/758805/ Original etherpad for the reference https://etherpad.opendev.org/p/osa-certificates-refactor 11. For ansible 2.11 (which requires py3.8 on deploy host) we can use pyenv for ansible venv to workaround this, and leave hosts themselves on their native python 12. Move neutron-server to standalone group in env.d 13. Add Senlin tempest test - Add plugins (source only) to os_tempest https://review.opendev.org/754044 - Upstream senlin endpoints fix https://review.opendev.org/74987 - Enable senlin tempest plugin in integrated repo https://review.opendev.org/#/c/754105/ - Test patch for senlin/tempest https://review.opendev.org/754045 14 Document in os_nova defaults way to manage ratios via api (ie set cpu_allocation_ratio to 0.0) (regarding https://review.opendev.org/#/c/758029/) 15. Add support for zookeeper deployment for services coordination (low priority) 16. Check where we don't use uwsgi role and see if we can use it there now (like designate, neutron-api) (low priority) -- Kind Regards, Dmitriy Rabotyagov

1 0

[undercloud][train]Fatal error during train undercloud deployment
by dangerzone ar 02 Nov '20

02 Nov '20

Hi all, I keep getting the same fatal error below during undercloud deployment. My environment is VMware VM Centos7 undercloud (openstack train) and refers to the official openstack guideline. TASK [tripleo_container_manage : Print failing containers] ********************* Monday 02 November 2020 19:55:07 +0800 (0:00:00.182) 0:17:50.677 ******* fatal: [undercloud]: FAILED! => changed=false msg: 'Container(s) with bad ExitCode: [u''container-puppet-ironic'', u''container-puppet-zaqar''], check logs in /var/log/containers/stdouts/' I even tried with clean different VM and all give me same error. Appreciate some help please. Thank you.

2 2

[Cloudkitty][ptg] CloudKitty Wallaby PTG outcome
by Rafael Weingärtner 02 Nov '20

02 Nov '20

Hey people, Thanks to everyone who attended the CloudKitty PTG sessions, we covered a lot during the meeting. The Etherpad is available at [1]. In Etherpad [1], I added the notation "TODO(XXX):" in the topics we discussed, that require effort from someone. The work can be either writing a use case story, developing extensions/features, or creating test cases. Therefore, if you are interested in working with that item, do not hesitate and put your name there. Anyone in the community is welcome. [1] https://etherpad.opendev.org/p/cloudkitty-ptg-wallaby -- Rafael Weingärtner

1 0

[nova] PTG
by Balázs Gibizer 02 Nov '20

02 Nov '20

Hi, Thank you all for the PTG participation! All our agreements and decisions are marked in the etherpad[1] with AGREED word. To avoid loosing this information I made a dump of the etherpad on Friday at the end of the PTG and attached to this mail Cheers, gibi [1] https://etherpad.opendev.org/p/nova-wallaby-ptg

1 0

[Glance] Wallaby PTG summary
by Abhishek Kekane 01 Nov '20

01 Nov '20

Hi All, We had our second virtual PTG last week from 26th October to 30th October 2020. Thanks to everyone who joined the virtual PTG sessions. Using bluejeans app we had lots of discussion around different topics for glance, glance + cinder and glance + tempest. I have created etherpad [1] with Notes from session and which also includes the recordings of each discussion. The same etherpad includes milestone wise priorities at the bottom. Below topics we discussed during PTG: 1. Victoria retrospection 2. Image encryption (progress) 3. Remove single store configuration from glance_store 4. Cache-API 5. Duplicate downloads 6. Extend issue when using nfs cinder backend (with cinder team) 7. Multi-format images 8. Cluster awareness 9. Improve performance of ceph/rbd store of glance (multi-threaded rbd driver) 10. Task API's for general users 11. Tempest enhancement/bridge gap between glance and tempest 12. Code cleanup, enhancements 13. Wallaby priorities Kindly let me know if you have any questions about the same. [1] https://etherpad.opendev.org/p/glance-wallaby-ptg Thank you, Abhishek

1 0

Fwd: [MURANO] DevStack Murano "yaql_function" Error
by İzzettin Erdem 01 Nov '20

01 Nov '20

Thanks Andy. Regards. Forwarded Conversation Subject: [MURANO] DevStack Murano "yaql_function" Error ------------------------ Gönderen: Andy Botting <andy(a)andybotting.com> Date: 30 Nis 2020 Per, 14:13 To: İzzettin Erdem <root.mch(a)gmail.com> Cc: Rong Zhu <aaronzhu1121(a)gmail.com>, < openstack-discuss(a)lists.openstack.org> Hi İzzettin, Thanks for your interest. Complete log link is at below. It is happening > when i try to deploy or update an environment. > > http://paste.openstack.org/show/792444/ > I've encountered the error AttributeError: 'method' object has no attribute '__yaql_function__' in our environment recently. I believe it started after we upgraded to the Stein release. I haven't tracked it down yet, but calls to the YAQL function: std:Project.getEnvironmentOwner() in a Murano app seem to generate it. It's good to know that at least someone else has reproduced this. cheers, Andy ---------- Gönderen: İzzettin Erdem <root.mch(a)gmail.com> Date: 2 May 2020 Cmt, 16:08 To: Andy Botting <andy(a)andybotting.com> Hi Andy, I solved this problem, it is happening when you try to create or update an environment on existing network. If you change the network with "create new" parameter, it stuck on "creating -or updating- environment" state and after that throws connection error. So i searched Murano network errors and i found this: https://docs.oracle.com/cd/E73172_01/E73173/html/issue-21976631.html. I applied these steps and i created successfully an environment just only with "create new" network parameter. After all these, i realized my devstack environment has no internet connection and because of this murano-agent could not install. So i tried to install Murano on my OSA stable/train test environment and i came with success until last step. Murano-agent installed but this time agent could not connect to rabbitmq instance. I discussed this with OSA IRC channel and i think i have to struggle with this for a long time. Apologize for this long mail but i wanted to inform you. Thanks. Regards. ---------- Gönderen: Andy Botting <andy(a)andybotting.com> Date: 3 May 2020 Paz, 14:24 To: İzzettin Erdem <root.mch(a)gmail.com> Hi İzzettin, Glad you got it sorted. I think you've probably just worked around the issue. Using your new method, you're probably just avoiding the std:Project.getEnvironmentOwner YAQL call now. I've also worked around it in our environment, but I'd like to solve it properly. When I get some time to look into it properly, I'll let you know. cheers, Andy

3 3

Weird iptables problem
by Florian Rommel 01 Nov '20

01 Nov '20

Hi, so we deployed a test cluster with 8 total nodes. Openstack ussuri, Ubuntu 20.04 , opevswitch, octavia. Everything works more or less as it should , however when deploying a loadbalancer (which works perfectly), instances on the same node as the amphora deployment loose all access via public up after open switch logs a message : modified security group “long uuid”, which is a sec group belonging to octavia. What effect does that have with the rest? Questions: Should ufw be on and started? How can we troubleshoot this more in depth? Why does the lb work perfectly whole instance with floating up loos all access from the internet but the lb works fine passing thru the web services. One more thing. Does anyone have a recommended sysctl.conf Settings list for Ubuntu/ openstack ussuri? Thanks already and have a nice weekend, //f

1 0