June 2020 - openstack-discuss - lists.openstack.org

UC meeting this week
by Mohamed Elsakhawy 01 Jun '20

01 Jun '20

Hi All, The UC meeting this week will be held as part of the PTG in the Bexar room on June 4th, 13-15 UTC Thanks Mohamed

1 0

[tc] changing meeting time
by Mohammed Naser 01 Jun '20

01 Jun '20

Hello everyone, The PTG is happening online next week, on the same day as our TC monthly meeting. Since the PTG is only every six months, and we will meet the month after, how does everyone feel about skipping this month's meeting and considering the PTG as our meeting instead? Your comments are appreciated, Thanks, -- Mohammed Naser VEXXHOST, Inc.

5 4

[nova][ptg] Documentation in nova
by Stephen Finucane 01 Jun '20

01 Jun '20

Hi, [This is a topic from the PTG etherpad [0]. As the PTG time is intentionally kept short, let's try to discuss it or even conclude it before the PTG] Our documentation in nova is suffering from bit rot, the ongoing effects of the documentation migration during Pike (I think), and general lack of attention. I've been working to tackle this but progress has been very slow. I suggested this a couple of PTGs ago, but once again I'd like to explore going on a solo run with these by writing and self-approving (perhaps after a agreed interval) *multiple* large doc refactors. I've left some notes below, copied from the Etherpad, but in summary I believe this is the only realistic way we will ever be able to fix our documentation. Cheers, Stephen [0] https://etherpad.opendev.org/p/nova-victoria-ptg --- Documentation reviews are appreciated but are generally seen as low priority. See: * https://review.opendev.org/667165 (docs: Rewrite quotas documentation) * https://review.opendev.org/667133 (docs: Rewrite host aggregate, availability zone docs) * https://review.opendev.org/664396 (docs: Document how to revert, confirm a cold migration) * https://review.opendev.org/635243 (docs: Rework the PCI passthrough guides) * https://review.opendev.org/640730 (docs: Rework all things metadata'y) * https://review.opendev.org/625878 (doc: Rework 'resize' user doc) * ... I (stephenfin) want permission to iterate on documentation and merge unilaterally unless someone expresses a clear interest Pros: * Documentation gets better * I can iterate *much* faster Cons: * Possibility of mistakes or "bad documentation is worse than no documentation" * Counterpoint: Our documentation is already bad/wrong and is getting worse due to bitrot. * Better is subjective * Counterpoints: The general structure of the patches I listed above was accepted in each case, I have other projects I have authored to point to (e.g. patchwork.readthedocs.io/) * Merge conflicts * Counterpoint: It's docs. Just drop these (non-functional) hunks if it's awkward.

4 4

[neutron] Drivers meeting on Friday 5.06.2020 cancelled
by Slawek Kaplonski 01 Jun '20

01 Jun '20

Hi, It's PTG time so lets cancel this week meeting. -- Slawek Kaplonski Senior software engineer Red Hat

1 0

[neutron] CI meeting on Wednesday 03.06.2020 cancelled
by Slawek Kaplonski 01 Jun '20

01 Jun '20

Hi, It's PTG time so lets cancel this week CI meeting. -- Slawek Kaplonski Senior software engineer Red Hat

1 0

[neutron] Team meeting on Tuesday 02.06.2020 cancelled
by Slawek Kaplonski 01 Jun '20

01 Jun '20

Hi, We have PTG sessions in same time, so lets cancel IRC meeting this week. See You all on the PTG sessions :) -- Slawek Kaplonski Senior software engineer Red Hat

1 0

[keystone] is_admin_project=true although no admin project configured
by Bernd Bausch 01 Jun '20

01 Jun '20

This is on a stable/ussuri Devstack that I spun up about ten days ago. The documentation for Keystone config option admin_project_name says [1] "If left unset, then there is no admin project". It is not set in my cloud, as evidenced by this: $ sudo journalctl -u devstack@keystone |grep admin_project_name Jun 01 11:49:55 ussuri devstack(a)keystone.service[806]: DEBUG uwsgi [-] *resource.admin_project_name = None *{{(pid=2063) log_opt_values /usr/local/lib/python3.6/dist-packages/oslo_config/cfg.py:2589}} However, when authenticating with any project, I see 'is_admin_project': True in the log, for example here user /linda /with a project-scoped token for project /moon/: Jun 01 13:55:09 ussuri devstack(a)keystone.service[806]: DEBUG keystone.server.flask.request_processing.middleware.auth_context [None req-4d730134-9544-4475-a72f-b2394863345e *moon linda*] RBAC: auth_context: {'token': <TokenModel (audit_id=1Ie2AyIdRb2WUkaSjSzDoQ, audit_chain_id=['1Ie2AyIdRb2WUkaSjSzDoQ']) at 0x7fca69b75c88>, 'domain_id': None, 'trust_id': None, 'trustor_id': None, 'trustee_id': None, 'domain_name': None, 'group_ids': [], 'user_id': 'a8c3559f67094f38a5f0d2d0b581f159', 'user_domain_id': 'default', 'system_scope': None, 'project_id': '163b41b499aa4ac78f2ed968e7fe2a0d', 'project_domain_id': 'default', 'roles': ['admin', 'reader', 'member'], *'is_admin_project': True*, 'service_user_id': None, 'service_user_domain_id': None, 'service_project_id': None, 'service_project_domain_id': None, 'service_roles': []} {{(pid=2062) fill_context /opt/stack/keystone/keystone/server/flask/request_processing/middleware/auth_context.py:478}} It gets worse. When I configure admin_project_name=admin and admin_project_domain_name=Default, I do see is_admin_project: false in the log, as expected. Still, /linda/, who has the admin role in the /moon /project,//seems to have cloud admin powers. I tested this by creating a Cinder volume type and by listing all instances in the cloud. So it seems to me that Keystone's old behaviour is in effect: I have admin powers if I have the /admin /role in any project. To me, this looks like a clash between reality and documentation. Am I missing something? Thanks for comments. Bernd [1] https://docs.openstack.org/keystone/latest/configuration/config-options.htm…

1 1