<div dir="ltr">Option 2 looks like a better idea keeping in mind the data model consistency with Neutron/Nova.<div>Could we write something similar to a view which becomes a layer on top if this data model?</div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Wed, Jul 30, 2014 at 3:33 AM, Tim Hinrichs <span dir="ltr"><<a href="mailto:thinrichs@vmware.com" target="_blank">thinrichs@vmware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi all,<br>
<br>
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.<br>
<br>
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.<br>
<br>
I see several options. Once we choose something, I’ll write up a spec and include the other options as alternatives.<br>
<br>
<br>
1) Add a preprocessor to the policy engine that makes it easier to deal with large tables via named-argument references.<br>
<br>
Instead of writing a rule like<br>
<br>
p(port_id, name) :-<br>
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)<br>
<br>
we would write<br>
<br>
p(id, nme) :-<br>
neutron:ports(port_id=id, name=nme)<br>
<br>
The preprocessor would fill in all the missing variables and hand the original rule off to the Datalog engine.<br>
<br>
Pros: (i) leveraging vanilla database technology under the hood<br>
(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<br>
Cons: (i) we will need to invert the preprocessor when showing rules/traces/etc. to the user<br>
(ii) a layer of translation makes debugging difficult<br>
<br>
2) Be disciplined about writing narrow tables and write tutorials/recommendations demonstrating how.<br>
<br>
Instead of a table like...<br>
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)<br>
<br>
we would have many tables...<br>
neutron:ports(port_id)<br>
neutron:ports.addr_pairs(port_id, addr_pairs)<br>
neutron:ports.security_groups(port_id, security_groups)<br>
neutron:ports.extra_dhcp_opts(port_id, extra_dhcp_opts)<br>
neutron:<a href="http://ports.name" target="_blank">ports.name</a>(port_id, name)<br>
...<br>
<br>
People writing policy would write rules such as ...<br>
<br>
p(x) :- neutron:<a href="http://ports.name" target="_blank">ports.name</a>(port, name), ...<br>
<br>
[Here, the period e.g. in <a href="http://ports.name" target="_blank">ports.name</a> is not an operator--just a convenient way to spell the tablename.]<br>
<br>
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.<br>
<br>
Pros: (i) this requires only changes in the datasource drivers; everything else remains the same<br>
(ii) still leveraging database technology under the hood<br>
(iii) policy is robust to changes in fields of original data<br>
Cons: (i) datasource driver can force policy writer to use wide tables<br>
(ii) this data model is much different than the original data models<br>
(iii) we need primary-key information about tables<br>
<br>
3) Enhance the Congress policy language to handle objects natively.<br>
<br>
Instead of writing a rule like the following ...<br>
<br>
p(port_id, name, group) :-<br>
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),<br>
neutron:ports.security_groups(security_group, group)<br>
<br>
we would write a rule such as<br>
p(port_id, name) :-<br>
neutron:ports(port),<br>
<a href="http://port.name" target="_blank">port.name</a>(name),<br>
<a href="http://port.id" target="_blank">port.id</a>(port_id),<br>
port.security_groups(group)<br>
<br>
The big difference here is that the period (.) is an operator in the language, just as in C++/Java.<br>
<br>
Pros:<br>
(i) The data model we use in Congress is almost exactly the same as the data model we use in Neutron/Nova.<br>
<br>
(ii) Policy is robust to changes in the Neutron/Nova data model as long as those changes only ADD fields.<br>
<br>
(iii) Programmers may be slightly more comfortable with this language.<br>
<br>
Cons:<br>
<br>
(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.<br>
<br>
(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 <a href="http://port.name" target="_blank">port.name</a>(...) 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.<br>
<br>
(iii) Requires some extra syntactic restrictions to ensure we don't lose decidability.<br>
<br>
(iv) Because the Congress and Nova/Neutron models are the same, changes to the Nova/Neutron model can require rewriting policy.<br>
<br>
<br>
<br>
Thoughts?<br>
Tim<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div>