add to cinder_driver encryption and attachment info

[Eric K]

Add to cinder_driver encryption and attachment info in order to support a policy similar to

unencrypted(volume_id, name) :-
  cinder:attachment(server=server_id, volume=volume_id),
  cinder:encryption(volume=volume_id, encrypted=’No’),
  cinder:volumes(id=volume_id, name=name)
# the attachment and the encryption informations are currently missing from congress drivers
https://docs.google.com/document/d/12f1VciulhT9yCYOc7jiulGiLT-tFpffLxNOpr-2QX2I/edit#heading=h.17037zo2vy3t

An issue to consider is how to add new information without breaking backward compatibility with existing policy rules. Adding additional columns to existing tables (say 'encrypted' to the 'volumes' table) break existing rules that refer to that table with positional arguments. There are several options:

A. Add new information only as new tables (as shown in the above example). This option preserves backward compatibility, but it can quickly make the schema very complex and unnatural.

B. Change Congress to allow too few positional arguments provided in a policy rule, simply filling in anonymous variables for the remaining positions. This option preserves backward compatibility, but has the (minor?) disadvantage of reducing error-checking in rule authoring. I believe it's minor because rules typically use named arguments anyway.

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/448828

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/448828
Committed: https://git.openstack.org/cgit/openstack/congress/commit/?id=9f52ebbf68dbfab1bd018fb22ca1fd4dd57f944b
Submitter: Jenkins
Branch: master

commit 9f52ebbf68dbfab1bd018fb22ca1fd4dd57f944b
Author: Eric Kao <email address hidden>
Date: Wed Mar 22 16:34:11 2017 -0700

    Pad positional args up to required number

    Pad positional args in rules up to number required by schema.

    The eliminate_column_references methods are slightly extended
    to also pad positional arguments even when no column refs
    are present.

    The change makes it so that adding new data columns (to the right
    of existing ones) in datasource drivers do not break existing
    policy rules.

    For example,
    nova:flavors(x) is automatically expanded to something like
    nova:flavors(x, _x1, _x2, _x3), just like if the input was
    nova:flavors(id=x). The behavior is consistent with that of
    optional parameters Python and C++.

    We discussed on IRC how to keep backward compatibility with existing
    policy rules when we add new information to data source drivers.

    There was some agreement that versioning the schema was the most
    complete solution, as it allows for the removal of tables/columns as
    well as additions.

    But even with the adoption explicit versioning, the allowance for too
    few positional arguments is still a great convenience for deployers
    because it makes the adding of data columns a backward compatible
    version change rather than a backward incompatible version change.
    That is, the deployer can take advantage of the new data columns in
    new policy, without having to rewrite all the existing policy.

    Related-Bug: 1674537

    Change-Id: Iac817f0a5c6dbb8c94804097d84f9541e1f22b1e

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/447784
Committed: https://git.openstack.org/cgit/openstack/congress/commit/?id=13a58362b51abfe80ce262e8c0251ea37898dde0
Submitter: Jenkins
Branch: master

commit 13a58362b51abfe80ce262e8c0251ea37898dde0
Author: Eric Kao <email address hidden>
Date: Mon Mar 20 21:14:01 2017 -0700

    Add fields to cinder:volumes and new attachments table

    The following information is added: encrypted, availability_zone,
    replication_status, multiattach, snapshot_id, source_volid,
    consistencygroup_id, migration_status, attachments.

    We discussed on IRC how to deal with changes to the data schema. There
    was some agreement that versioning the schema was the most complete
    solution.

    But at the moment and in the medium term, we do not have much need for
    understanding the different versions in code (ie. a version parameter
    gets passed to the driver when creating a datasource). So in this
    patch, I propose to document the cinder driver schema version as 2.1
    (and the original version 2.0 to coincide with the cinder client
    version used.) Rules written for 2.0 is compatible with 2.1 driver.
    But rules written for 2.1 schema may not be compatible with the 2.0
    driver.

    The schema version is helpful so that when a policy is documented
    with the schema version it is based on, users can figure out whether
    it is compatible with a particular install of congress drivers.

    At the same time, we avoid some implementation and maintenance
    complexity by maintaining only the latest minor version of each major
    version.

    Note: the backward compatibility of this change would be achieved with
    positional argument padding under review here:
    https://review.openstack.org/#/c/448828/

    Closes-bug: 1674537

    Change-Id: Ia0f2f17b4e25f70600175ababb35805fbcdd3142

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/congress 6.0.0.0b1 development milestone.