►
From YouTube: Discussion: Open Policy Agent for Compliance in GitLab
Description
We discussed how OPA could be used within GitLab to provide better visibility for developers about compliance requirements, supplement the merge request as an evidence artifact, and enable customers to build agnostic compliance checks into their workflows.
A
So
cool
so
philippe
and
dan
thanks
for
taking
time
out
of
your
day,
I
wanted
to
have
sort
of
a
re-education
about
open
policy
agent
because
philippe,
I
know
you
had
brought
it
up
several
months
back
and
I've
had
a
few
enterprise
customers
bring
it
up.
It
hasn't
been
a
highly
demanded
feature,
but
I
can
certainly
see
the
value
in
it,
and
so
I
think
that
it
probably
makes
sense
to
restart
those
discussions
about
how
we
can
maybe
start
iterating
towards
an
experience
that
leverages
opa.
A
So
I
think
what
would
be
helpful
is
if,
if
you
could
give
us
maybe
kind
of
a
high
level
overview
and
then
we
can
maybe
ask
some
questions
around
it
and
kind
of
go
from
there.
Does
that
sound
good.
B
B
This
is
extremely
far
from
what
you
can
do
within
the
pipeline,
for
example,
to
get
something
that
is
not
fulfilling
your
requirements
or
your
policies.
So
I
guess
we
need
to
narrow
down
the
scope
of
that
meeting
to
this,
the
second
the
ladder
part.
So
what
can
happen
in
the
in
the
pipeline?
For
example,
we
can
always
run
the
scope
later
on,
but
I
think
we
should
start
with
that
sounds
good.
B
I
think
dan
and
I
are
just
sending
up
on
notes
all
right
thanks
thanks
for
taking
the
notes,
I've
been
doing
that
for
the
last
two
weeks
and
I
can't
feel
my
fingers
anymore.
A
Yeah,
so
I
I
I
think
I
understood
your
point
you're
saying
that
we
should
try
to
narrow
the
focus
of
this
discussion
to
like
what
type
of
use
case
are
we
trying
to
solve
for
with
it
is
that
right.
B
Yeah,
absolutely
because
opa
is
absolutely
agnostic
and
if
you
take
a
look
at
the
documentation,
for
example,
there
is
a
path
with.
Where
is
that
integrating
opda
there?
There's?
Let
me
find
this
page
for
you,
the
ecosystem.
That
will
give
you
a
good
overview.
So
I'm
going
to
share
my
screen.
Now
that's
going
to
be
easier
to
talk
to
my
point.
B
Hopefully
you
can
see
the
opia
oppa
sorry
ecosystem
on
my
screen.
You
can
see
that
we
have
a
very,
very
large
variety
of
integrations,
so
it's
ranging
from
darker,
for
example,
where
you
can
define
what
kind
of
image
you
want
to
build
or
it
could
be
in
kubernetes.
It
can
be
in
it's
it's
most
of
the
time
related
to
kubernetes,
but
it
doesn't
have
to
be
that
it's
very
agnostic
and
you
can
do
a
lot
of
different
things
with
opa.
B
So
the
things
that
I
have
in
mind,
for
example,
when,
when
it
comes
to
compliance
and
especially
what
we
do
at
gitlab,
is
having
a
kind
of
gate
in
the
pipeline
that
would
be
very
agnostic,
so
being
able
to
define
the
rules
that
I
want
to
enforce
within
my
workflow
in
the
sdlc,
with
something
that
would
write
programmatically
so
with
a
kind
of
code,
because
oppa
is
using
rego
under
the
under
the
hood
and
rigo
is
kind
of
it's,
not
a
programming
language,
it's
more
of
a
query
language.
B
So
with
that
you
can
think
of
free
go
as
a
kind
of
sql.
It's
it's
not
too
far
from
sql,
but
you
can
define
what
you
want
to
do
with
the
input
and
what
the
output
is
going
to
be.
The
output
is
always
a
decision.
It's
regal
r
e
and
the
beauty
of
that
is
with
rigo.
You
can
do
a
lot.
It's
an
e!
Sorry
ready!
Go
there,
you
go
cool!
Thank
you.
B
The
beauty
behind
this
is:
it's
limitless
compared
to
a
ui
where
you
want
to
define
the
policy
where
you
need
to
follow
exactly
what
the
ui
is
going
to
to
constraint.
You
to
rego
is
very
powerful
and
and
and
very
flexible
compared
to
that,
because
you
can
define
functions
that
you
can
reuse
in
many
different
contexts.
B
For
example,
if
you
want
to
say,
I
want
to
make
sure
that
an
admin
is
doing
this
or
that
when
we
say
admin,
it
could
be
a
lot
of
things,
but
with
rico
you
can
define
admin
based
on
some
input
and
I'm
not
sure
by
the
way,
if
you're
aware
of
oh
opa
is,
is
working.
So
I'm
going
to
share
my
screen
again
so
that
we
can
make
that
very
clear.
B
So
that's
the
basic
principle
of
oppa.
You
can
have
two
different
ways
of
using
oppa,
but
this
one
is
the
main
one
where
you
have
a
service
and
the
service
is
going
to
query
oppa
for
a
decision.
It
could
be
a
query
on
the
live
service
or
it
could
be
something
directly
in
the
pipeline.
Don't
you
don't
have
to
have
opa,
for
example,
up
and
running
in
the
pipeline
to
take
a
decision?
It
can
be
something
very
standard
and
opa
is
going
to
take
decision
based
on
two
things.
B
First
of
all,
the
the
policy
that
you
define
so
rigo
is
the
language
that
I've
been
mentioning.
So
this
is
how
you
define
actually
the
policies
that
you
want
to
enforce
and
you
can
have
some
data,
and
I
don't
like
this
schema
that
we
have
here,
because
you
have
two
source
of
data
in
in
opa.
B
You
have
the
data
that
you
provide
as
a
query
like,
for
example,
if
I
want
to
create
an
image
and
deploy
that
image
in
my
pipeline,
I
want
to
make
sure
that
this
image
doesn't
have
any
critical
vulnerabilities,
for
example,
that's
something
that
you
can
do
very
easily
with
opa.
That's
that's
the
input,
that's
one
side
of
the
data
that
you
you
can
use
with
opa,
but
there
is
another
side
of
of
the
data
that
you
can
use.
B
Oppa
is
also
able
to
use
some
contextual
data
like,
for
example,
if
you
are
in
the
context
of
a
kubernetes
cluster
and
you
are
using
oppa
as
a
gatekeeper,
so
you
have
an
admission
controller
that
is
controlled
by
oppa,
and
you
want
to
make
sure
that
you
don't
have
two
controllers
or
two
parts
of
one
kind.
This
is
something
that
you
can
do
with
oppa.
B
So
the
query
in
this
case
is,
I
want
to
create
this
new
port,
so
it's
actually
the
manifest
of
the
pod
that
you
will
provide
to
apa
as
an
input.
The
policy
that
you
want
to
enforce
is
I
don't
want
to
have
two
types
of
this
of
this
spot,
so
I
want
to
block
if
I
have
another
creation
of
this
portal
curing
in
kubernetes.
B
So
I
understand
with
just
that
you're
not
able
to
take
the
decision,
because
you
don't
know
if
there's
a
port
running
with
the
same
characteristics
and
that's
the
other
side
of
the
of
the
data
that
I
was
mentioning.
That
is
not
part
of
the
of
the
schema
that
we
see
on
my
screen.
So
oppa
is
also
able
to
query
some
external
data
like,
for
example,
there
is
an
integration
with
kubernetes
was
where
opa
is
able
to
query
the
deployed
pods,
for
example,
and
compare
that
with
what
we
want
to
enforce
what
we
want
to
deploy.
B
A
Okay,
so
to
interject
for
clarity,
so
I
think
at
a
high
level.
What
I'm
understanding
is
that
opa
sort
of
sits
in
the
middle
and
so
the
middle
being.
A
I
is
the
organization
I'm
going
to
define
an
open
policy
and
we'll
call
it,
and
it's
done
with
this
rego
language
and
I'm
gonna
say
I
don't
want
cat
gifts
to
exist
in
my
in
this
project
or
like
in
my
production
environment.
So
in
order
to
enforce
that
what
happens
is
in
the
pipeline.
We'll
have
this
agent
this.
A
This
policy
that
we've
defined
and
as
the
pipeline
runs
it
can,
we
can
have
it
call
out
to
whatever
systems
or
tooling,
is
involved
in
this
development
process
or
this
pipeline
process,
and
if
a
cat
gif
is
found,
it
will
measure
against
that
policy.
We've
defined
and
returned
some
data.
That
says
no
there's
a
violation
here,
which
we
can
then
action
on
as
an
output
from
that
job.
Is
that
right
so
far,.
B
That
is
absolutely
right.
I'm
going
to
pass
in
the
chat
url,
that's
the
the
oppa
docker
image
that
you
can
use
directly
in
the
background,
so
you
don't
even
have
to
use
a
kind
of
opa
service
in
this
case.
If
you
want
to
to
create
this
kind
of
workflow.
B
So
why
would
you
want
to
have
oppa
in
your
in
your
pipeline
because
that's
something
that
you
can
do
with
ruby
or
you
can
do
with
python
or
any
programming
language?
The
thing
is
oppa
is
built
on
top
of
rigo
and
it's
not
built
on
top
of
it.
It's
using
rigo
as
the
query
language.
It's
built
on
top
of
go
actually,
but
rigo
is
again
a
query
language.
It's
not
a
programming
language
person,
so
the
adoption
of
that
language
is
a
lot
easier
than
trying
to
say
I'm
going
to
enforce
everything
with
python.
B
For
example,
I've
been
discussing
with
some
customers
that
we're
doing
that.
The
problem
is,
it
doesn't
scale
at
the
company
level
if
you
have
multiple
teams
using
multiple
languages
as
soon
as
you
are
hitting
the
limits
of
your
the
perimeter
of
your
teams,
and
you
have
one
team
using
python
and
the
other
game
is
using
ruby
or
cypress
press
or
any
other
technology.
B
It's
not
going
to
to
work
and
introducing
a
new
language
in
in
the
team
is
extremely
painful.
It's
extremely
cost
full
and
that
they
will
never
do
that.
So
we
have
a
lot
of
friction.
A
lot
of
pushback
with
adopting
new
languages.
But
again
rigo
is
not
a
new
programming
language,
so
the
adoption
is
very
easy
and
you
can
define
things
in
a
way
that
is
extremely
readable
for
someone
who
doesn't
know
anything
about
rego
once
you
start
reading
the
policies,
if
you
don't
have
too
many
functions,
it's
pretty
straightforward
to
understand.
B
What's
going
on
and
what
you
want
to
enforce
in
there
and
you
can
reuse
again
this
code
in
multiple
places
like
you
can
define
something
at
the
company
level.
For
example,
we
can
say
we
never
want,
because
we
have
some
regulations
in
place
in
the
company.
We
never
want
anything
to
go
through
the
pipeline
with
a
critical
severity
vulnerability.
B
B
Gate
in
place-
and
in
any
case,
if
you
have
regulations
in
place,
even
if
it's
a
full
specific
you're
not
allowed
to
to
deploy
that
until
you
say
okay,
I
have
assessed
the
problem
and
it
supports
positive.
So
it's
it's
good
to
go,
so
you
can
define
that
at
the
the
company
level
and
you
can
refine
all
the
policies
at
the
groups
and
maybe
at
the
project
level
to
have
something
that
is
very
specific
to
the
project.
B
I
I
don't
want
any
gift
card
in
this
in
this
project
because
we
had
that
in
the
past
and
that
can't
happen
anymore.
So
you
don't
know
to
you,
don't
need
to
know
the
project.
You
don't
need
to
understand
the
technology
in
the
project.
You
can
define
that
we
go
directly
and
again
it's
it's
a
language,
so
you
can
define
whatever
you
want.
It's
very
flexible.
A
So
do
kind
of
in
your
mind,
you
know,
certainly
subject
to
change
right,
but
in
your
mind,
how
do
you
see
this
manifesting
like
if
we
say
that
oh
this
job
sits
in
the
pipeline?
Is
it
really
just
a
job
and
the
customer
defines
it
and
they're
maintaining
it
like
they
would
a
yaml
configuration
or
any
other
job
rather
or
is
this
some
like
native
experience?
We
build
in
to
provide
this
compatibility
because
why
can't
they
use
this
today?
Is,
I
guess
what
I
would
like
to
understand.
B
They
can
definitely
use
that
today
and
actually
that's
something
that
we
consider
for
the
security
team.
They
we
wanted
the
security
team
to
be
able
to
get
new
dependencies,
not
because
we
want
to
control
everything,
but
new
dependencies
come
with
a
lot
of
new
questions
and
then
it's
going
to
change
completely
the
perimeter
of
the
application.
So
we
want
to
ensure
that
the
dependency
is
well
maintained.
There
is
no
back
door.
We
want
to
ensure
a
lot
of
things,
so
we're
working
on
that
and
we
can
use
oop
here
for
that.
B
We
can
have,
for
example,
list
of
dependencies
that
that's
the
current
list
of
of
the
gitlab
project,
for
example,
and
we
can
put
that
list
and
rego
directly
and
say
if
we
have
anything
new
that
is
detected
by
the
the
dependency
scanning
job,
for
example,
we
can
compare
the
result
with
with
the
list
that
we
have
and
if
we
have
something
that
is
not
in
the
list,
we
know
we
have
a
new
dependency.
B
At
that
point
we
can
block
and
say:
okay,
we
have
something
that
is
not
whitelisted,
so
we
need
to
take
the
decision
either.
We
accept
that
or
we
don't
accept
that,
but
at
least
we
involve
the
security
team.
At
some
point
we
say
we
have
something
blocking
the
pipeline.
We
can
go
any
further
than
that.
The
merge
request
is
blocking
because
of
this.
What
can
we
do
and
the
answer
can
be
directly
in
the
the
job
output?
We
have
a
new
dependency
there.
B
B
At
least
you
have
a
way
to
block
that
at
the
merge
request
and
it's
in
the
form
of
a
ci
job,
very
simply
using
the
the
op,
the
oppa
docker
image
that
I
shared
in
the
chat
going
to
share
my
screen
all
again
to
make
that
very
clear.
B
So
that's
the
kind
of
image
that
you
can
use
and
with
gitlab
ci.
You
can
use
darker
images
directly,
so
you
can
just
specify
okay,
I
want
to
use
this
image.
It's
going
to
run
opa
you
can
have
a
regal
file
directly
in
your
project.
That
trigger
file
can
maybe
include
some
other
files
that
would
be
at
the
group
or
the
company
level,
or
that
kind
of
things,
and
just
by
doing
that,
the
output
of
the
job
will
be
a
go
or
a
no-go.
B
If
it's
a
no-go
and
we
can
provide
an
output,
the
output
is
again
extremely
flexible.
We
can
provide
the
json
file.
For
example,
we
can
provide
text
in
the
road
put
to
explain
the
decision,
but
based
on
that,
we
can
use
this
json
output
file,
also
as
an
input
for
something
that
we
would
have
in
github.
That's
something
that
we
have
discussed
together.
B
I
guess
six
months
ago,
where
gitlab
would
be
able
to
pass
this
file
and
have
something
very
agnostic
in
the
in
the
in
place
of
this,
the
current
security
widget,
for
example,
we
could
have
something
very
similar,
then,
okay,
you
have
two
three
violations
of
your
policies:
here's
the
result,
here's
what
what
you
need
to
do
to
make
your
merge
request
pass
right
now!
It's!
B
If
you
do
that
you,
you
will
have
obviously
a
job
that
is
failing.
You
will
have
that
in
the
output,
but
it's
I
think
it's
a
bit
hard
today
to
explain
to
the
you
to
the
user
to
the
developer.
What
is
the
next
step
in
the
merge
request?
That
is
not
passing.
A
B
It
could
be
the
pipeline,
it
could
be
a
security
gate,
it
could
be
a
license
gate.
We
have
multiple
gates
at
different
levels,
different
places
in
the
merge
request,
and
we
don't
have
okay,
you,
you
did
90
percent
good,
but
you
still
need
to
do
this
action.
This
section
in
this
section
to
get
through
your
your
merge
request,
and
if
you
see
exactly
this
path
in
the
future,
you
can
anticipate
a
bit
and
you
can
see.
B
Oh
the
last
action
is
actually
I
need
to
involve
someone
from
the
security
team,
so
you
can
start
thinking
right
away,
someone
from
the
security
team
to
say
I'm
going
to
need
you
for
this
last
step,
because
right
now,
what
we
do
is
it's
blocking,
so
you
unblock
and
then
you
block
again
on
the
next
point.
You
have
no
visibility
on
the
the
number
of
remaining
points
most
of
the
time.
So
that's
right.
A
A
Okay,
so
I
think
what
I'm
understanding
then
is
you
know,
customers
can
use
this
today
and
they
are-
and
I
think,
we're
even
using
it
as
what
I
think
I
took
away
from
that.
But
I
think,
what's
missing
is
the
experience
where
git
lab
provides
some
mechanism
by
which
to
say
give
us
that
that
rego
policy
that
you've
defined
so
that
we
can
ingest
that
information
to
both
provide
a
list?
A
Maybe
four
things
like
you've
described
for
developers
say
hey
like
for
this
merger
quest
here
are
the
things
that
have
to
happen
for
this
to
succeed
and
then
also
show
how
that
list
is
being
progressed
through,
as
certain
requirements
are
met,
so
maybe
some
sort
of
like
as
policy
as
the
output
is
occurring
from
that
regal
policy
in
just
that
to
then
update
this
widget
in
the
merge
request
view
to
show
them
that
data
does.
That
I
mean
that's
a
rough
idea.
Is
that
some
right
yeah,
absolutely
okay,.
B
There's
one
last
thing
that
we
haven't
covered
one
use
case
and
again
I'm
going
to
share
my
screen
a
bit
easier
to
explain
the
title
is
very
generic,
I'm
sorry
for
that,
but
you
will
get
the
id
very
soon.
There
is
something
that
we
could
do
as
well.
I
don't
know
yet
if
we
have
some
use
cases,
but
talking
to
some
customers,
I
had
to
think
that
it
it
could
be
useful
for
them.
B
We
could
have
a
notepad
server
running
within
gitlab,
so
we've
seen
that
we
can
have
oppa
running
in
kubernetes
to
get
things
we
can
have
oppa
running
in
the
pipeline.
So
it's
not
really
running
it's
not
a
server
that
is
running.
The
job
is
spun
off,
it's
going
to
run
and
it's
going
to
die
and
you
have
the
results
and
nothing
exists
anymore.
B
There
is
this
third
option
where
you
would
have
in
the
notepad
integration
within
gitlab,
with
a
server
running
that
you
can
query
and
you
can
fit
this
server
with
some
inputs
of
any
kind,
like
your
application
would
be
able
to
query
gitlab
to
see
if
this
user,
for
example,
is
able
to
do
this
or
that
and
that
that's
a
very
common
scenario.
With
with
open
the
open
policy
agent,
we're
just
facilitating
that.
B
In
the
shape
of
something
that
would
be
in
gitlab,
so
you
would
have
an
integration
where
you
could
say:
okay,
my
server
is
running
here
is
the
rules
that
I
want
to
enforce,
maybe
the
course
or
something
like
like.
We
have
the
registry,
the
docker
rich
history,
completely
integrated
into
that.
This
is
something
that
is
running
on
the
side,
but
it's
it's
very
well
integrated.
B
You
have
the
page,
you
can
see
all
the
images,
so
we
can
imagine
that
we
will
have
something
similar
and
that
would
be
useful
at
the
application
level,
so
the
applications
that
the
users
are
deploying
if
they
deploy
their
application
to
the
github.
They
have
this
oppa
up
and
running
and
immediately
available
that
they
can
query
instantly
to
take
their
decisions.
A
Yeah,
that's
that's
a
great
point.
I
agree
yeah
certainly
far
into
the
future,
but
valuable
and-
and
I
can
think
of
what
I
hope
are
accurate
ways
in
which
we
can
apply
that
not
just
to
merge
requests
but
other
applications
as
well.
A
When
it
comes
to
you
know,
the
common
use
case
of
I
want
to
know
if
my
project
is
compliant
so
being
able
to
maybe
define
project
level
policies
where
we're
not
just
looking
at
a
pipeline,
but
like
could
we
define
what
a
compliant
project
looks
like
with
opa
and
provide
a
mechanism
to
then
report
on
that
and
give
customers
the
ability
to
pull
that
policy
against
a
certain
project?
To
say:
is
this
compliant
based
on
some
standard
we've
defined?
B
Yes,
yeah,
absolutely
and
again,
I
think
the
the
main
advantage
of
using
oppa
is
this
agnostic
layer
that
you
would
add
to
anything
related
to
policies
in
your
projects.
You
have
to
keep
that
in
mind.
You
can
share
a
lot
of
things
and
define
everything
without
going
very
deep
in
the
projects
technologies
like
again.
If
I
I
want
to
ensure-
because
my
regulation
is
asking
me
to
make
sure
that
an
admin
can
do
this
or
that
and
that
the
way
you
define
an
admin
is
not
tied
to
the
way
defined
entity
applications.
B
B
You
you
defer
that
responsibility
to
the
developers
to
the
projects
directly
and
you
can
stay
at
your
compliance
level
very
high
and
say:
okay,
give
me
that
and
that's
like,
for
example,
the
dependencies,
the
dependency
gate.
If
I
have
the
list
of
dependencies,
I
have.
I
can't
just
query
the
new
dependencies
with
dopa.
There
is
no
way
I
can
do
that,
but
what
I
can
do
is
just
feed
oppa
with
the
results
of
the
dependency
scanning
job,
which
is
a
json
file.
B
B
Now
you
just
say
in
opera,
just
give
me
the
raw
data.
I
want
data
and
that's
it.
I
want
json
and
that's
it.
I
can't
query
anything,
that's
why
it's
also
so
super
popular,
because
you
have
this
abstraction
layer
where
you
can
define
things
in
the
same
way.
Whatever
technology
you
are
using.
So
if
you
have
a
python
project
on
the
ribri
project,
the
opera
rules
are
going
to
be
exactly
the
same.
A
Right,
okay,
yeah,
that
makes
sense.
I
I
feel
we'll
yeah
get
into
those
granular
details.
You
know
in
that
future
state,
but
I
really
like
at
least
this
shorter
term
goal
being
able
to
to
leverage
it
to
provide
primarily
the
visibility
for
developers,
but
then
also
this
checklist
and
the
merger
quest
view,
because
I
mean
that's
a
great
evidence
artifact,
if
nothing
else,
but
I
I
see
we're
at
time,
were
there
any
last
comments
or
questions.
Maybe
dan
you've
been
very
diligent
and
helpful
with
the
note.
So
thank
you
for
that.
C
Yeah,
definitely
I
am
kind
of
interested
in
and
like
maybe
we
can.
Maybe
philip
you
can
just
give
a
real
quick
answer
to
this.
Does
this
reggo
query
language?
Does
that
effectively
end
up
being
pseudo
code
like
how
do
we
translate
that
to
you
know
like,
let's
use
a
very
specific
example,
this
project
is
compliant
based
on
one
policy
rule,
which
is
our
merger
request.
Approval
setup
we're
mergers,
approval
on
this
merge
request.
C
You
know,
then
it
passes.
I
I
just
I'm
sure
we
could
define
that
in
rego,
but
I'm
wondering
how
we
translate
that
to
actually
you
know
sort
of
retrieving
that
data
from
the
gitlab
context,
specifically
like
how
easy-
or
I
guess
do
you
have
like
sort
of
a
conception
already
of
what
that
would
look
like.
B
So
if
you
want
to
query
git
lab
to
get
any
data
about
the
merge
requests
like,
for
example,
you
don't
allow
developers
with
within
the
certain
group
to
create
certain
merge
requests.
For
example,
that's
that's
the
kind
of
policy
that
you
could
have.
You
have
a
portion
of
code
that
you
never
want
to
be
touched
by
any
team
other
than
this
super
high
level
team.
B
The
team
a
for
example.
So
oppa
is
not
able
to
do
that
directly.
You
will
have
to
provide
oppa
with
the
json
file
that
is
presenting
the
data
that
will
say:
okay,
here's
the
merge
request
and
that
merge
request
that
could
be
the
representation
could
be
exactly
what
the
gitlab
api
is
providing
to
you.
For
example,
when
you
query
the
gitlab
api,
you
get
a
json
file
in
results,
and
you
can
query
this
json
file
pretty
much
like
you
would
do
with
jq.
B
If
you
know
the
json
query
this
cli
tool,
you
know
with
the
dots
and
everything.
That's
exactly
what
you
would
do
with
the
with
rego,
so
you
need
to
query
this
data,
but
you
need
to
provide
this
data
in
the
first
place,
you
need
a
script
that
will
digest
the
the
the
api
and
everything
that
you
want
to
to
fit
to
to
oppa.
In
the
first
place,
again,
we
defer
the
responsibility
to
the
to
the
project
developers
to
the
any
developers.
B
A
So
it
I
I
imagine,
we'll
have
some
some
follow-ups
to
this,
but
now
we're
at
real
time.
So
philippe
thanks
as
always.
This
is
a
very
insightful
and
helpful
conversation
dan,
and
I
will
sync
up
and
be
sure
to
follow
up
with
you
with
what
I'm
sure
will
be
more
questions
of.