March 2021 - openstack-discuss - lists.openstack.org

[telemetry][ptg] Telemetry PTG planning
by Matthias Runge 17 Mar '21

17 Mar '21

Hi there, for Telemetry, we had a short planning meeting after PTG last year. If you are interested in Telemetry, or have something Telemetry related to talk about, please add yourself and the topic to the planning etherpad [1]. Matthias [1] https://etherpad.opendev.org/p/telemetry-xena-ptg

1 0

[manila][requirements] FFE requested for python-manilaclient
by Goutham Pacha Ravi 17 Mar '21

17 Mar '21

Hello, We were tracking one last feature inclusion into python-manilaclient for the wallaby release: https://review.opendev.org/c/openstack/python-manilaclient/+/775020 The change does not introduce any new requirements, but adds new SDK methods and shell implementations for end users to harness a feature addition in manila to be able to update their security services. The release team was very gracious in allowing us to wrap up code reviews pertaining to the above change over the weekend; however, the gate was uncooperative this morning by pointing us to lingering sporadic failures that are a combination of bad test case logic as well as occasional test environment setup issues. (Zuul is awesome, but it has a way to call out our procrastinations) No projects that depend on python-manilaclient need this change in their current form because it is net new feature functionality (existing SDK/CLI functionality is unaltered). However, I thought i should check here before requesting a re-release of python-manilaclient under the Wallaby cycle. Thanks, Goutham

3 5

[cinder] Bug deputy report for week of 2021-03-08
by Sofia Enriquez 17 Mar '21

17 Mar '21

Hello, This is a bug report from 2021-03-09 to 2021-03-16. Critical: - https://bugs.launchpad.net/cinder/+bug/1832164: "SADeprecationWarning: The joinedload_all() function is deprecated, and will be removed in a future release. Please use method chaining with joinedload() instead". Assigned to Gorka Eguileor. High: - https://bugs.launchpad.net/cinder/+bug/1919161: "Automatic quota refresh counting temporary volumes". Assigned to Gorka Eguileor. Medium: - https://bugs.launchpad.net/cinder/+bug/1918229: "Nimble free space calculation". Unassigned but looks like Ajitha Robert may be working on this. Low: - https://bugs.launchpad.net/cinder/+bug/1918932: "volume delete rejection message doesn't include awaiting-transfer state". (low-hanging-fruit) Unassigned. - https://bugs.launchpad.net/cinder/+bug/1918307: " api-ref: Make documentation of HTTP 403 consistent". Unassigned. Incomplete: - https://bugs.launchpad.net/cinder/+bug/1918449: " ensure_export model_update ignored ". Unassigned. - https://bugs.launchpad.net/cinder/+bug/1918879: "id of encryption for volume type not verified". Unassigned. Not a bug:- Feel free to reply/reach me if I missed something. Regards Sofi -- L. Sofía Enriquez she/her Software Engineer Red Hat PnT <https://www.redhat.com> IRC: @enriquetaso @RedHat <https://twitter.com/redhat> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/RedHatInc> <https://www.redhat.com>

1 0

[charms] Trilio Charms 21.03 release is now available
by Peter Matulis 17 Mar '21

17 Mar '21

The 21.03 release of the Trilio charms is now available. Please see the Release Notes for full details: https://docs.openstack.org/charm-guide/latest/2103_Trilio.html == Highlights == * TrilioVault 4.1 The charms now support TrilioVault release 4.1. * OpenStack Ussuri The charms add support for OpenStack Ussuri on both Ubuntu 18.04 LTS (Bionic) and Ubuntu 20.04 LTS (Focal). This is in addition to current Bionic support for OpenStack Queens, Stein, and Train. == Thank you == Lots of thanks to the following people who contributed to this release via code changes, documentation updates and testing efforts. Alex Kavanagh Aurelien Lourot Chris MacNaughton David Ames Liam Young Marian Gasparovic Peter Matulis -- OpenStack Charms Team

1 0

[cinder] New Cinder Bug Squad Meeting
by Sofia Enriquez 17 Mar '21

17 Mar '21

Hello, As discussed in the last meeting, Cinder will have an additional mini meeting to discuss bugs. [1] Cinder Bug Squad Meeting - Weekly on Wednesday at 1500 UTC <http://www.timeanddate.com/worldclock/fixedtime.html?hour=15&min=00&sec=0> in #openstack-cinder (IRC webclient <https://webchat.freenode.net/?randomnick=1&channels=%23openstack-cinder&pro…>) - Agenda: https://etherpad.opendev.org/p/cinder-bug-squad-meeting Feel free to add your bugs to the Agenda if I haven't done so already. Cheers, Sofi [1] http://eavesdrop.openstack.org/#Cinder_Bug_Squad_Meeting -- L. Sofía Enriquez she/her Software Engineer Red Hat PnT <https://www.redhat.com> IRC: @enriquetaso @RedHat <https://twitter.com/redhat> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/RedHatInc> <https://www.redhat.com>

1 0

[Horizon][Victoria][ops] - Scope based policies in Horizon not working
by Luke Camilleri 17 Mar '21

17 Mar '21

Hi Everyone, we had sent an email to this mailing list last week on an issue that we are having which we thought was being generated by keystone but on closer inspection it seems that this is coming actually from Horizon policy files. We would like to implement OpenStack using the scope based approach (v3) so that we could keep the main roles (reader,member and Admin) and use the scopes to differentiate the targets. We have implemented the below settings in /etc/keystone/keystone.conf: enforce_scope = true enforce_new_defaults = true All works well with the cli and the scopes except Horizon. We constantly receive errors in /var/log/keystone.log like: 2021-03-15 23:15:55.772 1611435 WARNING keystone.server.flask.application [req-a89277a2-8fb2-4fcb-b337-e76a73bb3af9 1405ecf1ff7f4e4188648dbd1fb84c07 c584121f9d1a4334a3853c61bb5b9d93 - default default] You are not authorized to perform the requested action: identity:validate_token.: keystone.exception.ForbiddenAction: You are not authorized to perform the requested action: identity:validate_token but the same command (for example an "openstack domain list") works well from the CLI. We could identify the issue coming from the policy files shipped with the dashboard at /etc/openstack-dashboard/<policies.json> as the rules within these policies are not scope based and in json format while according to the roadmap it seems that yaml is being used for the policy files and they should be scope based. When we try to convert the files to json to then upgrade them (to use the scope syntax) we receive the following errors: #oslopolicy-convert-json-to-yaml --config-file /etc/keystone/keystone.conf --namespace keystone --output-file keystone_policy.yaml --policy-file keystone_policy.json Traceback (most recent call last): File "/bin/oslopolicy-convert-json-to-yaml", line 10, in <module> sys.exit(convert_policy_json_to_yaml()) File "/usr/lib/python3.6/site-packages/oslo_policy/generator.py", line 599, in convert_policy_json_to_yaml conf.output_file) File "/usr/lib/python3.6/site-packages/oslo_policy/generator.py", line 451, in _convert_policy_json_to_yaml scope_types=default_rule.scope_types) File "/usr/lib/python3.6/site-packages/oslo_policy/policy.py", line 1239, in __init__ scope_types=scope_types File "/usr/lib/python3.6/site-packages/oslo_policy/policy.py", line 1154, in __init__ self.description = description File "/usr/lib/python3.6/site-packages/oslo_policy/policy.py", line 1251, in description raise InvalidRuleDefault('Description is required') oslo_policy.policy.InvalidRuleDefault: Invalid policy rule default: Description is required. We believe that converting such files to yaml and then upgrading them for scope based access (v3) should solve our issues based on the fact that if we disable the enforce _scope and enforce_new_defaults we can have a fully functional setup (but not scope based) which defies the initial objective Thanks in advance for anyone that may be able to assist with this issue

2 2

Properly consuming system-scope and operator workflows
by Lance Bragstad 16 Mar '21

16 Mar '21

Hey all, Several projects have made significant progress adopting default roles and system-scope during the Wallaby cycle. One part of that work is obviously testing and we've been stringing together various tempest jobs with the new policies enabled to see what falls out. Ironic was working on some of this last week and it led to an interesting discussion on Friday about how we should handle system-scope with the current assumptions about administrator (e.g., project-admin) workflows. The majority of the discussion took place in IRC, but I tried to consolidate as much of the context as I could into an etherpad [0]. I'm socializing the overall discussion so we can get feedback from users, operators, and developers, as well as summarize some comparisons to other systems. Today, by default system administrators are anyone with the 'admin' role on a project. These users are allowed to do things on behalf of users, like rebooting an instance. This mostly works because the administrator's token is project-scoped and the resource they're interacting with is owned by a project. This assumption isn't true in the new default policies. The question is, should system administrators, or users with system-scoped tokens, be allowed to use those tokens to make changes to project-specific resources (e.g., creating a private image in a project, rebooting an instance, deleting a snapshot, etc)? The general feeling was that, yes, system administrators should have the ability to interact with resources owned by projects in their deployment. The discussion then focused on how we actually make that happen. We came up with three different solutions, all of which are detailed in the etherpad [0], but I'll summarize them below. Option 1: Let system-administrators exchange system-scoped (god-mode) tokens for tokens scoped to a specific project without an explicit role assignment on the project Option 2: Require system-administrators to grant themselves authorization on the project, obtain a new token, and perform the operation Option 3: Allow system-administrators to use system-scoped tokens to operate on project-specific resources We're iterating through the pros and cons of each approach in the etherpad. If you haven't taken a look, please do so and add your thoughts. If you're an operator with an existing workflow, we want to hear your feedback. My request for additional feedback aside, several people in the discussion brought up comparison to other identity systems and frameworks (e.g., how do kerberos admins usually handle this sort of thing? how would we fix this if we were using OAuth 2.0/OIDC?) I spent some time Friday thinking through what an OAuth 2.0 flow would look like in OpenStack [1][2]. I don't think my findings were earth-shattering, and I'm sure there are other ways we could implement OAuth 2.0 flows. While adhering to a standard offers guidance and makes some things easier (like integrating with other systems), I don't think it would be the silver bullet for fixing our RBAC woes (at least not this late in the game). OpenStack APIs are massive, complex, and operate at different parts of the technology stack. Some of those APIs are meant for typical users just requesting resources. Others are written with the system administrator as the end user. OpenStack's explosive API and functionality growth out-paced its authorization tools to protect it, allowing project_id to bake itself into resources, services, and components (API code, middleware, database layers). Relaxing the assumption of an always-present project ID in every token is going to be hard and given OpenStack's distributed approach to policy enforcement, truly fixing it would require consistency across the entire ecosystem, regardless of the authentication or authorization framework. Either way, I thought that was an interesting exercise, and I'm curious if others have different opinions or perspectives on those findings. Thanks for reading, Lance [0] https://etherpad.opendev.org/p/consuming-system-scope [1] https://bit.ly/3cjUu6o My first few attempts at mapping this out were wrong, but I left links to the early drafts in the etherpad [2] I ignored a lot of assumptions about how clients interact with OpenStack, or how middleware works. This was purely a thought-experiment.

1 0

[cinder] docs job failures
by Brian Rosmaita 16 Mar '21

16 Mar '21

Note to reviewers, since all FFE patches need to be reviewed and merged by friday: Don't let a Zuul -1 for openstack-tox-docs stop you from reviewing patches. Gorka has a fix posted that we believe will address this: https://review.opendev.org/c/openstack/cinder/+/780907 but it needs to make its way through check and gate first, so it may be awhile. An example of the docs failure is: https://zuul.opendev.org/t/openstack/build/28c1d829e2d4469d82128a4f295f4dad It happens very early in the job, so even if there's a problem with the docs on a patch you're looking at, you aren't going to see it. If you want to check the docs on your patch locally, the change in this patch works for me, but YMMV: https://review.opendev.org/c/openstack/cinder/+/780696

1 1

[oslo] Xena PTG Etherpad
by Ben Nemec 16 Mar '21

16 Mar '21

Daniel created an etherpad for the Xena PTG[0]. If you have any topics to discuss please add them so we know whether we need to reserve a time. Thanks. -Ben 0: https://etherpad.opendev.org/p/oslo-xena-topics

1 0

[openstack-ansible] vPTG April 2021
by Dmitriy Rabotyagov 16 Mar '21

16 Mar '21

1 0