May 2019 - openstack-discuss - lists.openstack.org

Gerrit Downtime May 31, 2019 beginning 1500UTC
by Clark Boylan 29 May '19

29 May '19

Hello everyone, We'll be taking a short (hopefully no longer than an hour) Gerrit downtime so that we can rename some projects this Friday, May 31, 2019 beginning at 1500UTC. Some of these renames are cleanups after the great OpenDev git migration and others aren't, but all of them require us to stop Gerrit to update the database and contents on disk. If you'd like specifics on what repos are being renamed or what the process looks like, you can follow along at: https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Upcoming_Project_… https://etherpad.openstack.org/p/project-renames-2019-05-31 As always feel free to bring up questions or concerns and we'll do our best to answer/address them. Thank you for your patience and sorry for the interruption, Clark

1 0

[tripleo] Configuration Management without Puppet
by Emilien Macchi 29 May '19

29 May '19

(First of all: thanks to Alex Schultz who initiated the discussion during the last PTG). Context: With the containerization of the services in TripleO, our usage of Puppet is pretty much limited to laying down parameters into configuration files. Our long term goal is to reduce our number of tools in TripleO and converge toward more Ansible and we are currently investigating how to make it happen for Configuration Management, in a backward compatible and non-disruptive way. Problems: - Our current interface to configure things is very tight to Puppet and Hiera, which would make it complicated to bind it with Hiera. Some of us have tried (to create some Hiera module in Ansible) but clearly this is not the path we want to take as far I know. - We don't use the logic (generally) in the Puppet modules and again only care about the configuration providers (in puppet-openstacklib and for some services, templates files), so the Puppet modules now do too much for what we need in TripleO. Proposals: - Create an interface in THT that will define what the configuration looks like for each service. The format will be simple and easy to consume from any tool (Puppet to start for backward compatibility but also Ansible and why not etcd one day). Example with Glance in deployment/glance/glance-api-container-puppet.yaml: param_config: map_merge: - glance_api_config: DEFAULT: enable_v2_api: true log_dir: /var/log/glance oslo_middleware: enable_proxy_headers_parsing: true - glance_image_import_config: image_import_opts: image_import_plugins: {get_param: GlanceImageImportPlugins} https://review.opendev.org/#/c/660791/29/deployment/glance/glance-api-conta… It's not tight to Hiera and it's generating param_config which is JSON and consumable by Ansible or etcd later. Here, glance_api_config and glance_image_import_config are the Puppet providers which configure a specific file for Glance but we could imagine a binding for Ansible like: glance_api_config: /etc/glance/glance-api.conf - Move the services to use this new interface and I think it'll take multiple cycles to do that due to our amount of services. Things I haven't figured out (yet): - I'm still working on figuring out how we will handle ExtraConfig, service_config_settings and all the Hiera datafiles that we support in puppet/role.role.j2.yaml (ideas welcome). I can only imagine something like: ExtraConfig: - glance_api_config: DEFAULT: log_dir: /var/log/glance-2 Which somehow would override a previous hash. The blocker I found is that map_merge doesn't do deep merges, so if you merge glance_api_config, you overrides all keys... which is problematic if you only want to update one key. I'll investigate that further. - Backward compatibility for things like "ExtraConfig: glance::api::workers". Since we wouldn't rely on the classes anymore, our users calling the parameters from the classes will be broken. This also needs to be investigated. - non Puppet OpenStack modules like mysql, apache, etc, mostly use erb templates. This is, for now, out of scope and the plan is to look at OpenStack services first. But ideas welcome here as well. Of course we would prefer to consume upstream roles if they are well tested & maintained. If you want to review the ongoing work, here are the links: https://review.opendev.org/#/c/660726 https://review.opendev.org/#/c/661377 https://review.opendev.org/#/c/661093 https://review.opendev.org/#/c/660791 Thanks for reading that far, feel free to comment and contribute. I plan to continue this work and evaluate if all of this is actually worth it. -- Emilien Macchi

6 9

[neutron] set/find dhcp-server address
by Volodymyr Litovka 29 May '19

29 May '19

Dear colleagues, is there way to explicitly assign DHCP address when creating subnet? The issue is that it isn't always first address from allocation pool, e.g. $ openstack port list +--------------------------------------+-------+-------------------+------------------------------------------------------------------------------+--------+ | ID | Name | MAC Address | Fixed IP Addresses | Status | +--------------------------------------+-------+-------------------+------------------------------------------------------------------------------+--------+ | 0897bcc4-6cad-479c-8743-ca7cc5a57271 | | 72:d0:1c:d1:6b:51 | ip_address='172.16.53.3', subnet_id='20329549-124c-484d-8278-edca9829e262' | ACTIVE | | | | | ip_address='172.16.54.2', subnet_id='07249cd3-11a9-4da7-a4db-bd838aa8c4e7' | | both subnet have similar configuration of allocation pool (172.16.xx.2-254/24) and there are two different addresses for DHCP in every subnet. This makes a trouble during project generation with pre-assigned addresses for servers if the pre-assigned address is same as [surprisigly, non-first] address of DHCP namespace. And, may be, there is a way to determine this address in more simple way than looking into 'openstack port list' output, searching for port (a) without name and (b) with multiple addresses from all belonging subnets :) At the moment, 'openstack subnet show' say nothing about assigned DHCP-address. Thank you! -- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

3 4

[requirements][tooz] uncap grpcio
by Matthew Thode 29 May '19

29 May '19

Hi all, Requirements is looking to raise the version of grpcio to 1.21.1. grpcio has been uncapped in requirements for six months now and currently only tooz is blocking the usage of newer versions. Following the unblocking we'd need a release in order to actually unblock things in gate. It looks like it was fixed in 1.18.0, if you need to mask version between (and including) 1.16.0 and 1.17.x feel free to submit the patches to global-requirements. https://bugs.launchpad.net/python-tooz/+bug/1808046 70f144abde14e07d7f9620a2abb563ed16ef8c63 (in openstack/tooz) Thanks, -- Matthew Thode

2 2

[ops] last weeks meetups team meeting minutes
by Chris Morgan 28 May '19

28 May '19

Minutes for last weeks brief openstack ops meetups team meeting are here: Minutes: http://eavesdrop.openstack.org/meetings/ops_meetup_team/2019/ops_meetup_tea… 10:24 AM Minutes (text): http://eavesdrop.openstack.org/meetings/ops_meetup_team/2019/ops_meetup_tea… 10:24 AM Log: http://eavesdrop.openstack.org/meetings/ops_meetup_team/2019/ops_meetup_tea… Also please note: detailed planning has started for the NYC meetup in September, please add your ideas for sessions topics and +1 ones already there that you would like to attend, see https://etherpad.openstack.org/p/NYC19-OPS-MEETUP our next meeting is in just under an hour on #openstack-operators, see you there! Chris -- Chris Morgan <mihalis68(a)gmail.com>

1 0

[kolla][neutron] Python3 issue: "TypeError: Unicode-objects must be encoded before hashing"
by Marcin Juszkiewicz 28 May '19

28 May '19

I am working on making Kolla images Python 3 only. So far images are py3 but then there are issues during deployment phase which I do not know how to solve. https://review.opendev.org/#/c/642375/ is a patch. 'kolla-ansible-ubuntu-source' CI job deploys using Ubuntu 18.04 based images. And fails. Log [1] shows something which looks like 'works in py2, not tested with py3' code: 1. http://logs.openstack.org/75/642375/19/check/kolla-ansible-ubuntu-source/40… "+++ neutron-db-manage --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugins/ml2/ml2_conf.ini upgrade head", "INFO [alembic.runtime.migration] Context impl MySQLImpl.", "INFO [alembic.runtime.migration] Will assume non-transactional DDL.", "INFO [alembic.runtime.migration] Context impl MySQLImpl.", "INFO [alembic.runtime.migration] Will assume non-transactional DDL.", "INFO [alembic.runtime.migration] Running upgrade -> kilo", "INFO [alembic.runtime.migration] Running upgrade kilo -> 354db87e3225", "INFO [alembic.runtime.migration] Running upgrade 354db87e3225 -> 599c6a226151", "INFO [alembic.runtime.migration] Running upgrade 599c6a226151 -> 52c5312f6baf", "INFO [alembic.runtime.migration] Running upgrade 52c5312f6baf -> 313373c0ffee", "INFO [alembic.runtime.migration] Running upgrade 313373c0ffee -> 8675309a5c4f", "INFO [alembic.runtime.migration] Running upgrade 8675309a5c4f -> 45f955889773", "INFO [alembic.runtime.migration] Running upgrade 45f955889773 -> 26c371498592", "INFO [alembic.runtime.migration] Running upgrade 26c371498592 -> 1c844d1677f7", "INFO [alembic.runtime.migration] Running upgrade 1c844d1677f7 -> 1b4c6e320f79", "INFO [alembic.runtime.migration] Running upgrade 1b4c6e320f79 -> 48153cb5f051", "INFO [alembic.runtime.migration] Running upgrade 48153cb5f051 -> 9859ac9c136", "INFO [alembic.runtime.migration] Running upgrade 9859ac9c136 -> 34af2b5c5a59", "INFO [alembic.runtime.migration] Running upgrade 34af2b5c5a59 -> 59cb5b6cf4d", "INFO [alembic.runtime.migration] Running upgrade 59cb5b6cf4d -> 13cfb89f881a", "INFO [alembic.runtime.migration] Running upgrade 13cfb89f881a -> 32e5974ada25", "INFO [alembic.runtime.migration] Running upgrade 32e5974ada25 -> ec7fcfbf72ee", "INFO [alembic.runtime.migration] Running upgrade ec7fcfbf72ee -> dce3ec7a25c9", "INFO [alembic.runtime.migration] Running upgrade dce3ec7a25c9 -> c3a73f615e4", "INFO [alembic.runtime.migration] Running upgrade c3a73f615e4 -> 659bf3d90664", "INFO [alembic.runtime.migration] Running upgrade 659bf3d90664 -> 1df244e556f5", "INFO [alembic.runtime.migration] Running upgrade 1df244e556f5 -> 19f26505c74f", "INFO [alembic.runtime.migration] Running upgrade 19f26505c74f -> 15be73214821", "INFO [alembic.runtime.migration] Running upgrade 15be73214821 -> b4caf27aae4", "INFO [alembic.runtime.migration] Running upgrade b4caf27aae4 -> 15e43b934f81", "INFO [alembic.runtime.migration] Running upgrade 15e43b934f81 -> 31ed664953e6", "INFO [alembic.runtime.migration] Running upgrade 31ed664953e6 -> 2f9e956e7532", "INFO [alembic.runtime.migration] Running upgrade 2f9e956e7532 -> 3894bccad37f", "INFO [alembic.runtime.migration] Running upgrade 3894bccad37f -> 0e66c5227a8a", "INFO [alembic.runtime.migration] Running upgrade 0e66c5227a8a -> 45f8dd33480b", "INFO [alembic.runtime.migration] Running upgrade 45f8dd33480b -> 5abc0278ca73", "INFO [alembic.runtime.migration] Running upgrade 5abc0278ca73 -> d3435b514502", "INFO [alembic.runtime.migration] Running upgrade d3435b514502 -> 30107ab6a3ee", "INFO [alembic.runtime.migration] Running upgrade 30107ab6a3ee -> c415aab1c048", "INFO [alembic.runtime.migration] Running upgrade c415aab1c048 -> a963b38d82f4", "INFO [alembic.runtime.migration] Running upgrade kilo -> 30018084ec99", "INFO [alembic.runtime.migration] Running upgrade 30018084ec99 -> 4ffceebfada", "INFO [alembic.runtime.migration] Running upgrade 4ffceebfada -> 5498d17be016", "INFO [alembic.runtime.migration] Running upgrade 5498d17be016 -> 2a16083502f3", "INFO [alembic.runtime.migration] Running upgrade 2a16083502f3 -> 2e5352a0ad4d", "INFO [alembic.runtime.migration] Running upgrade 2e5352a0ad4d -> 11926bcfe72d", "INFO [alembic.runtime.migration] Running upgrade 11926bcfe72d -> 4af11ca47297", "INFO [alembic.runtime.migration] Running upgrade 4af11ca47297 -> 1b294093239c", "INFO [alembic.runtime.migration] Running upgrade 1b294093239c -> 8a6d8bdae39", "INFO [alembic.runtime.migration] Running upgrade 8a6d8bdae39 -> 2b4c2465d44b", "INFO [alembic.runtime.migration] Running upgrade 2b4c2465d44b -> e3278ee65050", "INFO [alembic.runtime.migration] Running upgrade e3278ee65050 -> c6c112992c9", "INFO [alembic.runtime.migration] Running upgrade c6c112992c9 -> 5ffceebfada", "INFO [alembic.runtime.migration] Running upgrade 5ffceebfada -> 4ffceebfcdc", "INFO [alembic.runtime.migration] Running upgrade 4ffceebfcdc -> 7bbb25278f53", "INFO [alembic.runtime.migration] Running upgrade 7bbb25278f53 -> 89ab9a816d70", "INFO [alembic.runtime.migration] Running upgrade 89ab9a816d70 -> c879c5e1ee90", "INFO [alembic.runtime.migration] Running upgrade c879c5e1ee90 -> 8fd3918ef6f4", "INFO [alembic.runtime.migration] Running upgrade 8fd3918ef6f4 -> 4bcd4df1f426", "INFO [alembic.runtime.migration] Running upgrade 4bcd4df1f426 -> b67e765a3524", "INFO [alembic.runtime.migration] Running upgrade a963b38d82f4 -> 3d0e74aa7d37", "INFO [alembic.runtime.migration] Running upgrade 3d0e74aa7d37 -> 030a959ceafa", "INFO [alembic.runtime.migration] Running upgrade 030a959ceafa -> a5648cfeeadf", "INFO [alembic.runtime.migration] Running upgrade a5648cfeeadf -> 0f5bef0f87d4", "INFO [alembic.runtime.migration] Running upgrade 0f5bef0f87d4 -> 67daae611b6e", "INFO [alembic.runtime.migration] Running upgrade 67daae611b6e -> 6b461a21bcfc", "INFO [alembic.runtime.migration] Running upgrade 6b461a21bcfc -> 5cd92597d11d", "INFO [alembic.runtime.migration] Running upgrade 5cd92597d11d -> 929c968efe70", "INFO [alembic.runtime.migration] Running upgrade 929c968efe70 -> a9c43481023c", "INFO [alembic.runtime.migration] Running upgrade a9c43481023c -> 804a3c76314c", "INFO [alembic.runtime.migration] Running upgrade 804a3c76314c -> 2b42d90729da", "INFO [alembic.runtime.migration] Running upgrade 2b42d90729da -> 62c781cb6192", "INFO [alembic.runtime.migration] Running upgrade 62c781cb6192 -> c8c222d42aa9", "INFO [alembic.runtime.migration] Running upgrade c8c222d42aa9 -> 349b6fd605a6", "INFO [alembic.runtime.migration] Running upgrade 349b6fd605a6 -> 7d32f979895f", "INFO [alembic.runtime.migration] Running upgrade 7d32f979895f -> 594422d373ee", "INFO [alembic.runtime.migration] Running upgrade 594422d373ee -> 61663558142c", "INFO [alembic.runtime.migration] Running upgrade 61663558142c -> 867d39095bf4, port forwarding", "INFO [alembic.runtime.migration] Running upgrade 867d39095bf4 -> d72db3e25539, modify uniq port forwarding", "INFO [alembic.runtime.migration] Running upgrade d72db3e25539 -> cada2437bf41", "INFO [alembic.runtime.migration] Running upgrade cada2437bf41 -> 195176fb410d, router gateway IP QoS", "INFO [alembic.runtime.migration] Running upgrade 195176fb410d -> fb0167bd9639", "INFO [alembic.runtime.migration] Running upgrade fb0167bd9639 -> 0ff9e3881597", "INFO [alembic.runtime.migration] Running upgrade 0ff9e3881597 -> 9bfad3f1e780", "INFO [alembic.runtime.migration] Running upgrade b67e765a3524 -> a84ccf28f06a", "INFO [alembic.runtime.migration] Running upgrade a84ccf28f06a -> 7d9d8eeec6ad", "INFO [alembic.runtime.migration] Running upgrade 7d9d8eeec6ad -> a8b517cff8ab", "INFO [alembic.runtime.migration] Running upgrade a8b517cff8ab -> 3b935b28e7a0", "INFO [alembic.runtime.migration] Running upgrade 3b935b28e7a0 -> b12a3ef66e62", "INFO [alembic.runtime.migration] Running upgrade b12a3ef66e62 -> 97c25b0d2353", "INFO [alembic.runtime.migration] Running upgrade 97c25b0d2353 -> 2e0d7a8a1586", "INFO [alembic.runtime.migration] Running upgrade 2e0d7a8a1586 -> 5c85685d616d", "INFO [alembic.runtime.migration] Context impl MySQLImpl.", "INFO [alembic.runtime.migration] Will assume non-transactional DDL.", "Traceback (most recent call last):", " File \"/var/lib/kolla/venv/bin/neutron-db-manage\", line 10, in <module>", " sys.exit(main())", " File \"/var/lib/kolla/venv/lib/python3.6/site-packages/neutron/db/migration/cli.py\", line 657, in main", " return_val |= bool(CONF.command.func(config, CONF.command.name))", " File \"/var/lib/kolla/venv/lib/python3.6/site-packages/neutron/db/migration/cli.py\", line 179, in do_upgrade", " run_sanity_checks(config, revision)", " File \"/var/lib/kolla/venv/lib/python3.6/site-packages/neutron/db/migration/cli.py\", line 641, in run_sanity_checks", " script_dir.run_env()", " File \"/var/lib/kolla/venv/lib/python3.6/site-packages/alembic/script/base.py\", line 475, in run_env", " util.load_python_file(self.dir, \"env.py\")", " File \"/var/lib/kolla/venv/lib/python3.6/site-packages/alembic/util/pyfiles.py\", line 90, in load_python_file", " module = load_module_py(module_id, path)", " File \"/var/lib/kolla/venv/lib/python3.6/site-packages/alembic/util/compat.py\", line 156, in load_module_py", " spec.loader.exec_module(module)", " File \"<frozen importlib._bootstrap_external>\", line 678, in exec_module", " File \"<frozen importlib._bootstrap>\", line 219, in _call_with_frames_removed", " File \"/var/lib/kolla/venv/lib/python3.6/site-packages/networking_infoblox/neutron/db/migration/alembic_migrations/env.py\", line 88, in <module>", " run_migrations_online()", " File \"/var/lib/kolla/venv/lib/python3.6/site-packages/networking_infoblox/neutron/db/migration/alembic_migrations/env.py\", line 79, in run_migrations_online", " context.run_migrations()", " File \"<string>\", line 8, in run_migrations", " File \"/var/lib/kolla/venv/lib/python3.6/site-packages/alembic/runtime/environment.py\", line 839, in run_migrations", " self.get_context().run_migrations(**kw)", " File \"/var/lib/kolla/venv/lib/python3.6/site-packages/alembic/runtime/migration.py\", line 350, in run_migrations", " for step in self._migrations_fn(heads, self):", " File \"/var/lib/kolla/venv/lib/python3.6/site-packages/neutron/db/migration/cli.py\", line 632, in check_sanity", " revision, rev, implicit_base=True):", " File \"/var/lib/kolla/venv/lib/python3.6/site-packages/alembic/script/revision.py\", line 767, in _iterate_revisions", " uppers = util.dedupe_tuple(self.get_revisions(upper))", " File \"/var/lib/kolla/venv/lib/python3.6/site-packages/alembic/script/revision.py\", line 321, in get_revisions", " resolved_id, branch_label = self._resolve_revision_number(id_)", " File \"/var/lib/kolla/venv/lib/python3.6/site-packages/alembic/script/revision.py\", line 491, in _resolve_revision_number", " self._revision_map", " File \"/var/lib/kolla/venv/lib/python3.6/site-packages/alembic/util/langhelpers.py\", line 230, in __get__", " obj.__dict__[self.__name__] = result = self.fget(obj)", " File \"/var/lib/kolla/venv/lib/python3.6/site-packages/alembic/script/revision.py\", line 123, in _revision_map", " for revision in self._generator():", " File \"/var/lib/kolla/venv/lib/python3.6/site-packages/alembic/script/base.py\", line 109, in _load_revisions", " script = Script._from_filename(self, vers, file_)", " File \"/var/lib/kolla/venv/lib/python3.6/site-packages/alembic/script/base.py\", line 887, in _from_filename", " module = util.load_python_file(dir_, filename)", " File \"/var/lib/kolla/venv/lib/python3.6/site-packages/alembic/util/pyfiles.py\", line 90, in load_python_file", " module = load_module_py(module_id, path)", " File \"/var/lib/kolla/venv/lib/python3.6/site-packages/alembic/util/compat.py\", line 156, in load_module_py", " spec.loader.exec_module(module)", " File \"<frozen importlib._bootstrap_external>\", line 678, in exec_module", " File \"<frozen importlib._bootstrap>\", line 219, in _call_with_frames_removed", " File \"/var/lib/kolla/venv/lib/python3.6/site-packages/networking_infoblox/neutron/db/migration/alembic_migrations/versions/4d0bb1d080f8_member_sync_improvement.py\", line 43, in <module>", " default=utils.get_hash()))", " File \"/var/lib/kolla/venv/lib/python3.6/site-packages/networking_infoblox/neutron/common/utils.py\", line 374, in get_hash", " return hashlib.md5(str(time.time())).hexdigest()", "TypeError: Unicode-objects must be encoded before hashing" ], Any ideas which project goes wrong? And how/where to fix it?

2 3

About the constraints url.
by Natal Ngétal 28 May '19

28 May '19

Hi everyone, I'm little lost or totally lost, actually. Sorry if a mail have already sent, I have not find it. If I have understood correctly, the url to use for the constraints is: https://releases.openstack.org/constraints/upper/master One question, this rule is the same for all projects? I'm also bit confused, I know the oslo projects must be use this url, and I have a patch is blocked for this reason: https://review.opendev.org/#/c/658296/ The url is not good in master also, so I have make a patch for it: https://review.opendev.org/#/c/661100/ So why I'm confused, because in the same project, few patches with the bad url was validate or merge: https://review.opendev.org/#/c/655650/ https://review.opendev.org/#/c/655649/ https://review.opendev.org/#/c/655648/ https://review.opendev.org/#/c/655640/ So which url must be used for constraints and this a global for all openstack projects? Then can we be careful, when we review a patch about this and not mixed up both url.

5 9

[sigs][publiccloud][publiccloud-wg][publiccloud-sig][billing] Meeting tomorrow continues discussions billing initiative
by Tobias Rydberg 28 May '19

28 May '19

Hi all, Thanks for a good meeting last Thursday! As decided during last meeting, we will try to keep up the pace here and have meeting every week before summer vacations. Tomorrow at 1400 UTC in IRC #openstack-publiccloud we will continue where we left last week. Please read the meeting logs from last meeting [0] and the etherpad regarding this topic and initiative [1]. Talk to you all tomorrow! Cheers, Tobias [0] http://eavesdrop.openstack.org/meetings/publiccloud_wg/2019/publiccloud_wg.… [1] https://etherpad.openstack.org/p/publiccloud-sig-billing-implementation-pro… -- Tobias Rydberg Senior Developer Twitter & IRC: tobberydberg www.citynetwork.eu | www.citycloud.com INNOVATION THROUGH OPEN IT INFRASTRUCTURE ISO 9001, 14001, 27001, 27015 & 27018 CERTIFIED

1 0

[qa][ptg][patrole] RBAC testing improvement ideas for Patrole
by Ghanshyam Mann 27 May '19

27 May '19

Patrole is emerging as a good tool for RBAC testing. AT&T already running it on their production cloud and we have got a good amount of interest/feedback from other operators. We had few discussions regarding the Patrole testing improvement during PTG among QA, Nova, Keystone team. I am writing the summary of those discussions below and would like to get the opinion from Felipe & Sergey also. 1. How to improve the Patrole testing time: Currently Patrole test perform the complete API operaion which takes time and make Patrole testing very long. Patrole is responsible to test the policies only so does not need to wait for API complete operation to be completed. John has a good idea to handle that via flag. If that flag is enabled (per service and disabled by default) then oslo.policy can return some different error code on success (other than 403). The API can return the response with that error code which can be treated as pass case in Patrole. Morgan raises a good point on making it per API call than global. We can do that as next step and let's start with the global flag per service as of now? - https://etherpad.openstack.org/p/ptg-train-xproj-nova-keystone Another thing we should improve in current Patrole jobs is to separate the jobs per service. Currently, all 5 services are installed and run in a single job. Running all on Patrole gate is good but the project side gate does not need to run any other service tests. For example, patrole-keystone which can install the only keystone and run only keystone tests. This way project can reuse the patrole jobs only and does not need to prepare a separate job. 2. How to run patrole tests with all negative, positive combination for all scope + defaults roles combinations: - Current jobs patrole-admin/member/reader are able to test the negative pattern. For example: patrole-member job tests the admin APIs in a negative way and make sure test is passed only if member role gets 403. - As we have scope_type support also we need to extend the jobs to run for all 9 combinations of 3 scopes (system, project, domain) and 3 roles(admin, member, reader). - option1: running 9 different jobs with each combination as we do have currently for admin, member, reader role. The issue with this approach is gate will take a lot of time to run these 9 jobs separately. - option2: Run all the 9 combinations in a single job with running the tests in the loop with different combination of scope_roles. This might require the current config option [role] to convert to list type and per service so that the user can configure what all default roles are available for corresponding service. This option can save a lot of time to avoid devstack installation time as compared to 9 different jobs option. -gmann

2 2

[placement] reminder: no meeting today May 27
by Chris Dent 27 May '19

27 May '19

There will be no Placement/Scheduler meeting today (May 27th) for two reasons: * It's a holiday in a few different places. * The poll to see what to do with the meeting has resulted in switching to office hours: https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_9599a2647c319fd4 I'll set up a doodle or similar so we can figure out when to schedule the office hours. They will not be at at the same time as the meeting as "meeting at a different time" was the second most popular choice. Thanks. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent

1 0