From: cncf-toc@... <cncf-toc@...>
Date: Sunday, September 27, 2020 at 2:10 AM
To: gadi@... <gadi@...>
Cc: CNCF TOC <cncf-toc@...>
Subject: Re: [cncf-toc] OPA to graduation

+1 NB

I'm biased here, as one of the maintainers of the Conftest project
which is now part of OPA.

I wanted to address the point above about Rego.

I'm an unashamed DSL nerd. I was a user and contributor to Puppet and
then worked there. I was an early Docker user, gave talks about
Dockerfile and then worked at Docker. I originally built Conftest in
order to provide a better local developer experience to OPA because I
wanted to use Rego.

But, I'm also a fan of Chef. I spent last week putting together a
bunch of demos using Pulumi. I like general purpose programming
languages too.

Oh, and I like data as well. I contributed to Ansible. I wanted to
like Jsonnet, really like CUE, like aspects of YTT.

I can reason about the trade offs between these 3 different approaches
to configuration for what would be an unreasonable length of time for
most people. As a user and contributor I've been through a few
generations of tools in this space as a user and developer, and I
fully expect to see several more generations too. That's maddening to
some, and fun for me. I have strange hobbies.

The reality here is most end users have a strong preference for tools
in one of those groups at any given moment in time.
This isn't a new observation. It's worth reading the Configuration
Complexity Clock from back in 2012 as it's still as relevant here as
when it was written
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmikehadlow.blogspot.com%2F2012%2F05%2Fconfiguration-complexity-clock.html&amp;data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637367946286664027&amp;sdata=Xf4EZ22F0EdT7e3PHtmBQcNVhfZlmpU%2B0MvddJM8BhE%3D&amp;reserved=0

That is to say we'll likely see 3 distinct policy approaches over
time, one DSL, one data and one general purpose language.
In fact we already see projects like k-rail (using Go for authoring
policies https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcruise-automation%2Fk-rail&amp;data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637367946286664027&amp;sdata=S6iscJAvXQfHTLLDi6AIbWVwCi89SU3tjbfcAcM%2BzHI%3D&amp;reserved=0) and Kyverno
(using YAML for authoring https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnirmata%2Fkyverno&amp;data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637367946286664027&amp;sdata=54ow6wTL166eK19uxAi7%2BZZkJ1a3IahR4YKm0RmZGeI%3D&amp;reserved=0)

OPA today focuses on one of these approaches, my experience tells me
there will always be folks who prefer one of the others, and that's
fine. The CNCF shouldn't enforce one approach or another, but look at
usage.

The Open Policy Agent community in general has also been working on
lowering the barrier to learning Rego. The rego playground in
particular is invaluable https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplay.openpolicyagent.org%2F&amp;data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637367946286674021&amp;sdata=aZZEpTkffy3nbwbuz71hBtK42qAQJtLpssRKNuz2PcI%3D&amp;reserved=0. Rego
adoption has been growing rapidly, it's nature means most rego is
written behind private repos but
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgithub%2Flinguist%2Fissues%2F4219&amp;data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637367946286674021&amp;sdata=gbLcPvm0txcoE%2B8QXBl0Tp3cMdL8shHqZML%2FXSk9NbY%3D&amp;reserved=0 shows 296 rego files
publicly on GitHub in January 2019. Today there are more than 6000
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsearch%3Futf8%3D%25E2%259C%2593%26type%3DCode%26ref%3Dsearchresults%26q%3Dextension%3Arego%2Bpackage%2BNOT%2Bnothack&amp;data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637367946286674021&amp;sdata=dq2gMhiDLnfHxlG3MxDWmeq1DzHjckN%2FfAmoaEvfenQ%3D&amp;reserved=0.
There has also been work done around sharing, so many end users can
use Open Policy Agent without needing to write rego. For instance we
were one of the first communities to define OCI Artifact metadata
(https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopen-policy-agent%2Fopa%2Fissues%2F1413&amp;data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637367946286674021&amp;sdata=BZPQBu4p2GzC7XsfDkvWBH4syELw6eoFCHE581CgFYM%3D&amp;reserved=0) which then
powers features like
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Faws.amazon.com%2Fblogs%2Fcontainers%2Foci-artifact-support-in-amazon-ecr%2F&amp;data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637367946286674021&amp;sdata=7zQ7z6Zpz%2BFr0%2FEycFdgOMI5aijqgV7Lk8VHpecewoY%3D&amp;reserved=0.

Hopefully that's a useful viewpoint and addition to the conversation.

Gareth