Open Stack

Option 2 looks like a better idea keeping in mind the data model
consistency with Neutron/Nova.
Could we write something similar to a view which becomes a layer on top if
this data model?


On Wed, Jul 30, 2014 at 3:33 AM, Tim Hinrichs <thinrichs at vmware.com> wrote:

> Hi all,
>
> As I mentioned in a previous IRC, when writing our first few policies I
> had trouble using the tables we currently use to represent external data
> sources like Nova/Neutron.
>
> The main problem is that wide tables (those with many columns) are hard to
> use.  (a) it is hard to remember what all the columns are, (b) it is easy
> to mistakenly use the same variable in two different tables in the body of
> the rule, i.e. to create an accidental join, (c) changes to the datasource
> drivers can require tedious/error-prone modifications to policy.
>
> I see several options.  Once we choose something, I’ll write up a spec and
> include the other options as alternatives.
>
>
> 1) Add a preprocessor to the policy engine that makes it easier to deal
> with large tables via named-argument references.
>
> Instead of writing a rule like
>
> p(port_id, name) :-
>     neutron:ports(port_id, addr_pairs, security_groups, extra_dhcp_opts,
> binding_cap, status, name, admin_state_up, network_id, tenant_id,
> binding_vif, device_owner, mac_address, fixed_ips, router_id, binding_host)
>
> we would write
>
> p(id, nme) :-
>     neutron:ports(port_id=id, name=nme)
>
> The preprocessor would fill in all the missing variables and hand the
> original rule off to the Datalog engine.
>
> Pros: (i) leveraging vanilla database technology under the hood
>       (ii) policy is robust to changes in the fields of the original data
> b/c the Congress data model is different than the Nova/Neutron data models
> Cons: (i) we will need to invert the preprocessor when showing
> rules/traces/etc. to the user
>       (ii) a layer of translation makes debugging difficult
>
> 2) Be disciplined about writing narrow tables and write
> tutorials/recommendations demonstrating how.
>
> Instead of a table like...
> neutron:ports(port_id, addr_pairs, security_groups, extra_dhcp_opts,
> binding_cap, status, name, admin_state_up, network_id, tenant_id,
> binding_vif, device_owner, mac_address, fixed_ips, router_id, binding_host)
>
> we would have many tables...
> neutron:ports(port_id)
> neutron:ports.addr_pairs(port_id, addr_pairs)
> neutron:ports.security_groups(port_id, security_groups)
> neutron:ports.extra_dhcp_opts(port_id, extra_dhcp_opts)
> neutron:ports.name(port_id, name)
> ...
>
> People writing policy would write rules such as ...
>
> p(x) :- neutron:ports.name(port, name), ...
>
> [Here, the period e.g. in ports.name is not an operator--just a
> convenient way to spell the tablename.]
>
> To do this, Congress would need to know which columns in a table are
> sufficient to uniquely identify a row, which in most cases is just the ID.
>
> Pros: (i) this requires only changes in the datasource drivers; everything
> else remains the same
>       (ii) still leveraging database technology under the hood
>       (iii) policy is robust to changes in fields of original data
> Cons: (i) datasource driver can force policy writer to use wide tables
>       (ii) this data model is much different than the original data models
>       (iii) we need primary-key information about tables
>
> 3) Enhance the Congress policy language to handle objects natively.
>
> Instead of writing a rule like the following ...
>
> p(port_id, name, group) :-
>     neutron:ports(port_id, addr_pairs, security_groups, extra_dhcp_opts,
> binding_cap, status, name, admin_state_up, network_id, tenant_id,
> binding_vif, device_owner, mac_address, fixed_ips, router_id, binding_host),
>     neutron:ports.security_groups(security_group, group)
>
> we would write a rule such as
> p(port_id, name) :-
>     neutron:ports(port),
>     port.name(name),
>     port.id(port_id),
>     port.security_groups(group)
>
> The big difference here is that the period (.) is an operator in the
> language, just as in C++/Java.
>
> Pros:
> (i) The data model we use in Congress is almost exactly the same as the
> data model we use in Neutron/Nova.
>
> (ii) Policy is robust to changes in the Neutron/Nova data model as long as
> those changes only ADD fields.
>
> (iii) Programmers may be slightly more comfortable with this language.
>
> Cons:
>
> (i) The obvious implementation (changing the engine to implement the (.)
> operator directly is quite a change from traditional database technology.
>  At this point, that seems risky.
>
> (ii) It is unclear how to implement this via a preprocessor (thereby
> leveraging database technology).  The key problem I see is that we would
> need to translate port.name(...) into something like option (2) above.
>  The difficulty is that TABLE could sometimes be a port, sometimes be a
> network, sometimes be a subnet, etc.
>
> (iii) Requires some extra syntactic restrictions to ensure we don't lose
> decidability.
>
> (iv) Because the Congress and Nova/Neutron models are the same, changes to
> the Nova/Neutron model can require rewriting policy.
>
>
>
> Thoughts?
> Tim
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140801/f3362640/attachment.html>