Skip to content

Add support for per Release policy validation

Summary

From: #66 (comment 526328459)

Current state

  • The user can configure non-default policy rules to be used for each os component and these policy rules are also (as soon as #129 (closed) i.e., !250 (merged) has been merged) validated with the default policy file from each os component as a basis.
  • Static files (located in yaook/op/$component/static/default_policies.yaml) are used from the queens release (keystone, nova and cinder), from the stein release (neutron) and victoria release (which is a superset of the queens release) (glance).

Desired state

  • The version of the default policy files that are used should match the os release.
  • When upgrades are being implemented, care should be taken so that the default policy files from the correct release are used.
  • The default policy files should be generated using the script generate_default_policies.py which is in the main directory of the yaook/operator git.
    • This script is already built-in into docs/getting_started/dev_setup.sh, Dockerfile, and ci/mr-master.yml but commented out.
    • Also the MANIFEST.in must be changed so that the yaml files in yaook/op/$component/generated instead of yaook/op/$component/static are being installed.

Known issues

To generate the default policy files we use oslopolicy-policy-generator (in generate_default_policies.py). There are known problems which prevent this to be used to generate the policy files for glance and neutron queens and rocky releases. Also queens uses python2 which will complicate things the way oslopolicy-policy-generator (i.e. generate_default_policies.py) is currently used together with buildcue.py and python3.

Use Cases

  • We need appropriate policies for each openstack release at it might otherwise cause issues

Proposal

Bake the default policy into each service image. Make it part of the image "API" where the default policy is placed (comments have ideas on that). That way, we can have per-release files without extra work.

Let the operator fetch the policy from an image at runtime, using a helper Pod. Cache the default policies in-process (keyed off the image) to avoid having to spawn a pod and wait for it to be ready on reconcile iteration.

Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this section are to be interpreted as described in RFC 2119.

  • MUST validate policies (as it does currently) before initiating an OpenStack upgrade against the new version as their validity may now change between versions and refuse to proceed with the update on conflict.
  • MUST NOT bake default policies into operator images (service images only)
  • SHOULD NOT have fallback code for images without default policies

Services:

  • Keystone
  • Cinder
  • Nova
  • Neutron
  • Glance
  • Barbican
  • Heat
  • Ironic
  • Gnocchi
Edited by Stefan Hoffmann
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information