►
Description
Join Fatih Degirmenci, Co-Chair CDF Interoperability SIG, on an introduction to using standard policies across the DevOps pipeline. Fatih explains the need for standard policies and introduces the concept of a standard policy framework to improve the management of policies in the CI/CD process. Links to more information and how to get involved in the discussion can be found at: https://docs.google.com/presentation/d/1aJbdTRV7LxjsL7ptBViUSRWxK7qTD2UQSR0LawOKgnE/edit#slide=id.gc7a0ab3b04_1_268
A
Okay,
everybody
welcome
to
the
march
2021
continuous
delivery
foundation
meetup.
I
am
tracy
reagan,
the
organizers
of
this
meetup
and
I'm
pretty
excited
today
to
have
fatih
digraminsi
speaking
today
on
a
on
a
topic
that
is
sort
of
new
fati's
got
some
very
interesting
background
here.
He
has
been
working
for
erickson
and
is
really
a
very
accomplished.
Developer
and
devops
engineer.
A
A
A
I
consider
him
a
thought
leader
in
this
area,
even
though
he
doesn't
like
to
be
called
that,
but
he
is.
We
know
that
there
are
open
policy
there's.
You
know,
there's
open
policy
discussions
around
many
aspects
of
of
devops,
but
this
is
specific
to
the
continuous
delivery
pipeline.
A
So
I'm
super
happy
to
have
fati
here
today,
and
I
think
that
on
that
note,
I.
B
B
A
Just
one
other
one
other
thing
we
do
have
april
15th
as
our
next
meetup
and
we'll
have
chris
reilly.
He
will
be
talking
about
pipeline
analytics,
I
think,
he's
starting
to
think
about
sort
of
door
metrics
and
how
those
are
changing
so
join
us
in
april
for
pipeline
analytics
and
don't
forget,
we
have
the
cd
con
in
june,
so
if
you
haven't
registered
for
cdcon,
go
to
the
cd
foundation
website
and
do
so
and
fati.
Thank
you.
Thank
you.
So
much
for
coming.
B
As
you
summarize,
this
topic
is
spread
critical
and,
as
you
also
mentioned
like
we
start
talking
about
this
topic
within
continues
their
foundation
and
it's
important
to
get
more
participation
to
the
work
we
are
doing
in
hong
kong
foundation
and
in
different
special
test
groups,
and
hopefully
this
discussion
will
help
us
find
like-minded
people
from
various
industries.
So
we
can
push
for
this
together
in
a
collaborative
manner.
B
Okay,
so
tracy
already
introduced
me,
so
I'm
not
going
to
repeat
everything
you
said
tracy,
but
as
it
is
written
on
this
slide
as
well.
I
am
working
as
a
developer
in
ericsson,
software
technology
and,
as
you
all
know,
exxon
is
a
company
active
in
telecommunications
industry
and
I'm
also
a
co-chairing
cdf
speaking
periscope,
together
with
cara
delamar
from
cloudbase
and
trying
to
highlight
the
challenges
of
end
users,
get
conversations
started
between
end
users,
projects
and
act.
B
Vendors
to
address
those
challenges
in
a
collaborative
manner,
and
as
I
noted
policy
is
a
topic
we
started
working
on
recently,
and
even
though
this
discussion
will
focus
on
continuity
of
aspects
of
policy.
There
are
lots
of
things
you
can
find
online
to
see
how
far
this
topic
could
be
taken.
So
today
we
will
focus
on
content,
theory
and
devops
aspects.
B
I
will
highlight
few
future
looking
things
as
well,
especially
from
telecom
industry,
because
there
is
tremendous
work
happening
with
within
tech,
communications
industry,
like
other
industries,
and
you
can
look
for
those
to
get
yourselves
into
position,
which
is,
I
think,
which
is
pretty
fun
topic,
but
not
just
critical,
but
also
fun.
To
deal
with
so
as
usual,
we
all
know
the
transformation,
multitude
of
multiple
technologies,
different
technologies
or
multi.
B
Multiple
different
industries
are
going
through
now
and
I
just
took
off
two
three
of
those
industries
as
examples
here:
finance,
medicine
and
telecommunications
and,
as
you
can
guess-
and
you
probably
are
into
one
of
these
industries
all
these
new
technologies
and
methodologies-
delivering
tremendous
advances
in
these
different
industries
like
cloud
native
virtualization
containers.
B
These
are
new
technologies.
They
are
changing
how
the
new
features
new
services
to
end
users
are
developed
and
introduced.
Apart
from
the
technology
stem
cells,
the
methodologies
are
also
critical
to
achieve
the
agility
and
speed
to
enable
innovation
and
finally,
give
businesses
more.
You
know
share
in
the
pipe.
If
I
must
that
way,
and,
for
example,
financial
services,
you
all
probably
use
certain
banks,
they
are
established
banks
100
years
old.
B
But
if
you
look
at
the
banking
industry
financial
services,
you
will
see
lots
of
new
companies
coming
into
the
industry.
You
just
install
one
app
and
everything
just
works.
You
don't
have
to
go
and
deal
with
lots
of
things.
You
just
get
that
app
on
your
phone
and
you
are
good
to
go
and
with
medicine
or
healthcare.
B
We
are
all
going
through
this
covet
situation,
as
you
all
know,
and
we
all
can
see
lots
of
case
studies
coming
from
healthcare
medicine
industry-
to
highlight
the
importance
of
speed
of
developing
development,
of
new
cures,
for
example,
and
especially
the
cure
developed
for
colleagues.
If
you
read
some
blog
posts
shared
by
the
people,
you
will
see
their
approach
taken
from
software
development
as
well
to
analyze,
rna
and
other
type
of
stuff,
and
when
it
comes
to
community,
as
you
well
know,
telecom
industry
is
a
pretty
closed
industry.
B
It
is
not
have
say
easy
for
new
entrants
to
you,
know,
come
and
bring
in
their
business
to
this
industry.
But
with
all
this
openness
happening
last
couple
of
years,
taekwondo
is
opening
as
well
like
linux
foundation.
Hosts
multiple
networking
projects
and
open
run
is
another
thing.
Vendors
and
operators
are
talking
about
and
they
all
go
back
to
igt
and
pace
of
innovation,
and
if
you
continue
doing
things
in
traditional
way,
you
may
lag
behind
the
competition,
because
all
these
new
grid
of
companies
startups,
they
are
very
fast.
They
innovate
fast.
B
So
everyone
is
moving
towards
this
new
age
of
doing
things
and
technology
transformation
is
happening
everywhere
and
one
of
the
frequencies
or
enablers
of
this
technology
transformation
is
continuous.
Delivery
like
it
is
one
of
the
key
pieces
in
the
various
different
methodologies.
We
follow
and
apply
to
our
software
development
life
cycle,
and
this
is
critical
for
all
types
of
players,
regardless
of
the
industry,
regardless
of
their
size
and
history.
B
You
could
very
well
be
hundred
year
old
company,
but
you
have
to
go,
and
you
know,
challenge
the
startups
because
they
will
be
challenging
you
on
a
daily
basis
in
order
to
keep
the
pace
in
order
to
keep
your
business.
You
know
viable,
you
have
to
adapt
to
these
new
methodologies
and
we
are
kind
of
in
a
like
from
continuous
theory
perspective.
B
It
is
also
challenging
because
the
exploration
in
number
of
tools
and
technologies
is
like
without
their
challenges
like
if
you
want
to
establish
a
continuous
data
pipeline.
For
example,
we
have
like
10
15
20
different
technologies
to
achieve
that
and
similar
to
software
configuration
management.
You
can
use
various
different
tools
and
technologies
to
do
your
coding
and
code
reviews
and
so
on
and
similar
to
artifact
management.
B
This
ecosystem
contains
their
ecosystem
and
try
to
address
those
challenges
together
and
intervals,
is
one
of
those
challenges
and
specific
to
policy
policy
has
similar
challenges
to
interoperability
itself,
like
for
interoperability,
for
example,
you
need
to
have
clear
interfaces
across
different
tools
in
order
to
ensure
like
they
all,
adhere
to
that
those
interfaces.
They
all
use
the
interfaces
and
they
all
adhere
to
certain
standards.
B
And
if
you
look
at
the
policy
topic,
policy
topic
is
suffering
from
the
same
issue.
Even
though
there
are
some
efforts
to
streamline
how
policy
is
approached
by
different
communities,
there
are
still
things
to
do
within
policy
area
to
deal
with
durability
aspects,
but
interoperability
or
technology
aspects
is
not
just
only
problem
with
policy.
There
are
other
aspects
which
I
am
going
to
talk
about
coming
minutes
and
again,
this
topic
policy
should
be
worked
on.
Like
any
other
topic,
we
are
working
on
within
context
their
foundation
together.
B
So
before
starting
to
talk
about
policy
itself,
I
want
to
walk
you
through
a
sample
pipeline,
and
I
am
sure
this
pipeline
will
look
pretty
familiar
to
you,
because
you
all
have
more
or
less
same
type
of
pipeline.
You
may
be
using
microservices.
You
may
be
using
monolithic
approach
to
develop
your
application,
but
regardless
of
type
of
the
application
you
are
developing,
you
have
some
kind
of
pipeline,
and
in
this
example
I
take
microservice
as
an
example
and
walk
you
through
this,
because
microservices
gives
us
better.
B
I
would
say
ways
to
explain
the
challenges
with
policy.
So,
on
the
left
hand,
side
we
have
multiple
teams
and
all
those
teams
are
developing
specific
microservices.
As
usual.
Their
development
is
happening
on
some
software
compact
management
system.
Let's
take
github
as
an
example.
B
Here
all
those
teams
are
dropping
their
code
and
they
are
sending
that
code
contribution
as
a
full
quest
github
and
when
that
contribution
ends
up
on
github,
your
pull
request,
verification
stage
within
your
pipeline
starts
running
and
depending
on
on
your
setup,
these
activities
within
premerge
stage
could
be
checking
various
things
like
static
analysis
like
linting
or
like
yaml.
B
Lint
or
shell
check
or
go
static
analysis
apart
from
static
analysis,
you
may
be
doing
unit
tests,
you
may
be
trying
to
build
your
container
image
and
you
may
also
be
doing
dependency
scanning
to
see
if
the
dependencies
you
are
using
within
your
microservice
are
actually
in
a
low
list
and
depending
on
the
outcome
of
these
different
activities
within
your
premarch
stage
in
your
service
pipeline,
you
may
either
block
that
cool
cast
from
merged
to
master
branch
or
you
may
say
yeah.
B
So
this
is
again
a
typical
pre
merge
stage
in
a
pipeline
and
when
your
code
got
merged
to
the
master
branch,
next
step
could
be
some
kind
of
staging
and
testing
and
staging
the
environment,
and
in
that
case
again,
you
may
be
doing
builds.
You
may
be
doing
more
extensive
testing
than
premerge
stage
and
you
may
be
doing
like
smoke,
test
performance
tests
and
security
analysis.
B
Again,
all
these
things
could
result
in
a
patch
saying
that,
okay,
it
is
great
this
past
all
those
things
this
could
be.
You
know
push
to
register
as
a
release
version
which
can
then
go
to
production,
and
in
this
example,
in
production
we
have
rollouts
different
regions
like
americas
and
eu
and
in
production
we
may
be
doing
further
test
like
activities
like
canal
deployment
and
av
testing,
and
again
this
is
nothing
magic.
We
all
know
this,
but
these
are
actually
critical
things.
Do
we
need
critical
things?
B
So
if
we
take
few
of
these
things
from
different
activities
within
our
pipeline,
on
the
left
hand
side,
we
have
more
developer
near
activities
such
as
quality
checks
like
you
need.
A
test
developers
are
familiar
with
unit
tests
and
they
are
comfortable
with
working
with
those
units
and
they
can
go
and
manage
those
like
things
themselves
without
getting
external
hard.
B
Developers
should
be
comfortable
to
you
know,
configure
those
things
within
their
pipelines
and
ensure
they
don't
include
old
versions
of
dependencies
or
they
don't
try
to
move
to
latest
version
without
getting
those
versions
wet
at
first
and
in
post-merge
stage
again,
developers
are
pretty
familiar
with
privileges,
like
is:
are
your
processes
running
in
sudo
mode,
for
example,
exposing
yourself
your
campaign
to
risks
or
are
using
default
sports
again
developers
can
ensure
those
policies
are
adhered
to
within
their
microservices,
but
when
you
go
to
the
right
most
side
of
the
pipeline
and
when
you
come
to
rollout
things
get
a
bit
tricky
because,
essentially,
we
developers
are
doing
making
critical
business
decisions
with
all
the
activities
we
are
making
during
our
development
process.
B
B
Yes,
we
should
trust
developers
and
we
know
they
will
do
their
best
to
ensure
whatever
they
push.
To
you
know:
production
via
the
pipeline
will
not
put
the
company
or
business
in
risk,
but
it
is
also
not
fair
to
expect
all
the
developers
to
know
the
business
objectives
of
company
or
the
domain
or
the
industry.
The
company
is
operating
in,
for
example,
if
you
talk
about
business
and
if
you
look
at
the
date
time
and
date
example
here,
let's
assume
you
are
working
for
a
company
who
is
which
is
active
in
sales
business.
B
B
It
doesn't
have
any
security
issues,
but
you
did
this
work
just
before
black
friday
and
it
may
not
be
the
best
idea
in
the
world
to
roll
this
change
out
to
production
on
thursday
evening,
because
tomorrow
is
black
friday
and
you
have
to
ensure
that
your
site
stays
up
and
you
can
serve
your
users.
So
that
is
a
consideration
that
is
actually
coming
from
business
side
of
things.
Obviously,
developers
know
tomorrow
is
black
friday,
but
same
time.
B
Usually,
and
new
changes
don't
go
into
production
just
before
black
friday,
and
that
is
actually
driven
by
the
policy
coming
from
business
side
of
the
organization.
Another
example
is
daytime.
Perhaps
the
business
has
a
policy
saying
that
no
one
can
push
anything
on
friday
afternoon
production
because
everyone
is
going
to
weekend
and
they
will
have
time
with
their
family
and
their
friends,
and
they
may
not
want
to
deal
with
issues
that
may
occur
during
the
weekend.
B
B
B
You
are
rolling
out
to
the
telco
network
shouldn't
you
know,
be
putting
your
company
list
from
gdpr
point
of
view
and
in
finance
you
have
other
regulations
and,
as
an
example,
the
company
might
have
a
policy
saying
that
okay,
we
have
this
microservice
with
these
features,
but
some
of
these
features
are
not
really
attained
to
gdpr,
so
this
version
must
not
be
rolled
up
to
european
union,
because
if
we
roll
this
version
out,
we
may
be
you
know,
collecting
data
of
users
which
we
are
not
supposed
to
collect
and
that
policy
could
actually
block
roll
out
of
that
version,
or
that
policy
could
actually
turn
off
a
feature
flag,
saying
that
this
feature
is
not
activated
within
eu
and
again,
if
we
go
back
to
the
beginning
of
the
pipeline,
on
the
left
hand
side,
it
is
relatively
easy
for
developers
to
get
to
know
many
things
about
credit
checks
or
security
checks.
B
But
if
you
go
to
the
right
and
it
becomes
more
tricky
because
you
need
to
know
different
laws
where
your
company
is
operating
in
or
different
traditions,
for
example,
in
u.s
black
friday
is
big
thing,
but
in
europe
there
might
be
some
other
day.
That
is
important,
so
your
company
operating
in
europe
might
have
different
policies
when
it
comes
to
pulling
out
changes
to
production
on
a
date.
B
Basis,
I
already
mentioned
few
considerations
while
walking
through
the
pipeline,
so
few
of
these
things
are
like
functionality
or
features
or
new
services.
That
is
a
consideration.
You
always
want
to
bring
new
features
or
new
service
to
end
users,
because
you
want
to
get
the
new
business
opportunities
before
the
competition.
B
But
while
you
are
doing
the
development
of
those
new
features
or
services,
you
must
ensure
that
it
has
good
quality.
So
it
doesn't.
You
know,
crash
all
the
time
when
users
attempt
to
use
or
when
users
attempt
to
access
your
website,
and
while
you
are
getting
new
features
and
users
and
in
a
quality
way,
you
may
expose
themselves
to
security
risk
or
you
may
expose
the
company
to
security
risks.
B
So
we
have
to
ensure
that
we
don't
break
things
when
we
are
pushing
things
in
a
faster
speed
and
regulations
is
another
thing
I
already
talked
about
during
the
sample
pipeline
and,
on
the
other
hand,
doing
all
these
type
of
checks.
Like
you
have
unit
tests,
you
have
smoke
smoke
test,
you
have
quality
checks.
Obviously,
you
have
secure
checks,
you
have
regulations
checks,
but
these
these
things,
these
checks
or
these
guard
days
shouldn't
slow
down
the
pace
of
innovation
as
well.
That
needs
to
have
balance.
There
needs
to
be
a
balance
there.
B
They,
like
you,
know,
dealing
with
technical
things,
and
sometimes
some
of
these
things,
like
regulations
or
secret
type
of
issues.
B
They
may
hurt
the
worker
experience
if
I
have
to
run
after
people
to
get
answers
to
my
questions
with
regards
to
rules
and
regulations,
then
I
may
you
know,
lose
my
ambition,
because
I
am
just
on
some
idea,
which
is
great
idea.
I
want
that
idea
to
be.
You
know,
realized
and
pushed
to
production,
but
if
I
need
to
deal
with
tons
of
people
and
spend
days
and
weeks
to
get
that
idea
giving
permission,
then
that
may
actually
hurt
my
experience
as
a
developer.
B
And
finally,
the
businesses
are
there
to
make
money.
You
know
we
we
have
to
ensure
like
these
checks,
are
there
viable
and
they
don't?
Actually,
you
know,
endanger
the
business
like.
If
you
keep
the
bar
very
low,
when
it
comes
to
enforcing
your
policies,
then
you
may
put
the
business
in
risk
and
then
that
could
cause
losses
for
the
business.
B
Again,
policies
are
business
decisions
and
they
must
be
clearly
defined
document
and
government,
like
you,
can't
just
expect
people
to
remember
some
conversation
from
some
meeting
and
remember
that
thing
when
they
are
actually
pushing
something
to
production.
They
must
be
clearly
defined
documented
by
government
by
the
business,
and
some
of
those
policies
could
relate
to
quality
and
security,
and
others
could
relate
to
rules
and
regulations.
So
it's
vast,
it's
very
different
types
of
policies
the
business
could
employ
within
their
organizations,
and
another
important
aspect
aspect
about
policies
is
that
they
must
be
enforceable.
B
B
Apart
from
that,
you
must
be
able
to
measure
how
the
organization
is
doing
when
they
are
developing
software
and
pushing
new
features
or
service
to
end
users.
If
the
policies
are
violated
continuously,
then
you
may
need
to
take
a
look
at
that
policy
and
see
why
developers
are
violating
that
policy
again
and
again,
there
might
be
something
to
be
done.
There
so
the
policy
could
be,
perhaps
you
know
a
bit
softened
or
developers
could
be
trained
better.
Why?
That
policy
is
that
and
why
it
is
as
it
is
now.
B
Another
thing
is
that
we
have
to
go
and
be
able
to
audit
those
policies,
because
our
companies,
they
are
audited
all
time
depending
on
industry
and
those
things
go
back
to
actually
development
organization.
Development
organization
should
be
audited
from
this
point
of
view,
and
my
policies
are
in
place
or
guard
rails
are
in
place.
B
Another
type
of
policy
could
be
secured
related
for
the
policy
to
ensure
the
developers
build
security
into
application.
Rather
than
you
know,
depending
security
like
an
afterthought,
because
it's
again,
it
becomes
very
costly
and
risky
to
put
security
into
your
application
after
you
actually
develop.
Your
application
and
developers
must
make
trade-offs
that
potentially
end
and
then
your
reliable
time
performance
and
obviously
like
software
development
or
software
architecture,
is
all
about
trade-offs.
B
B
We
can't
maintain
trade-offs
for
those
things
and
finally,
the
developers
get
benefits
from
policy
during
approach
in
trace
rate
and
audit
ability
as
well
and
the
other
thing.
When
I
was
reading
some
articles,
people
generally
talk
about
guidelines
and
policies,
so
they
sound
similar
in
some
contexts.
But
if
you
think
that
in
policy
context
they
are
pretty
different.
Actually
the
guidelines
are
suggested
behavior.
They
talk
about
suggested
behavior,
for
example,
when
you
are
walking
on
a
road
and
you
want
to
pass
to
the
other
side
of
the
road.
B
B
You
continue
with
life
with
your
life,
but
when
it
comes
to
policies,
it's
actually
expected
behavior,
like
you
describe
what
the
behavior
of
the
system,
your
policies,
you
enforce
your
expected
behavior
using
your
policies
and
that's
why
it
is
important
that
policies
must
be
enforceable
and
measurable,
because
if
you
can't
enforce
those
behaviors
in
an
expected
way,
then
you
are
essentially
having
some
guidelines.
If
you
don't
block
a
change
going
to
production,
for
example,
based
on
your
policy,
your
next,
you
are
not
actually
stating
an
expected
behavior.
B
And
another
thing
that
I
noticed
when
I
was
looking
at
this
topic:
people
talk
about
policy
in
technology
context,
again
developers
like
working
with
new
technologies
or
like
solving
problems,
but
it
is
important
that
we
all
know
that
there's
a
clear
distinction
between
policy
and
technology,
for
example,
open
policy
agent.
That
is
a
technology
that
helps
you.
B
Well,
this
is
a
critical
thing
because
again
it
goes
back
to
continuous
view
actually,
because
people
generally
mix
content
integration
with
changes
when
you,
when
people
talk
about
context
regulation,
they
use
jenkins,
like
as
a
replacement
word,
but
jenkins
is
one
of
the
many
tools
that
you
can
implement,
continue
integration
and
continues
there
with
new
organizations.
So
this
separation
between
actual
concern
and
the
technologies
you
actually
can
use
to
implement
those
things.
There
are
two
different
things.
B
Now,
if
we
go
back
to
our
sample
pipeline
and
in
our
sample
pipeline,
we
had
developers,
they
are
dealing
with
all
these
type
of
different
checks
and
guardrails
and
policies
like
call
checks,
blueprints
privileges
course
daytime
date
and
regulations,
types
of
policies
and
when
we
think
about
the
constellations
we
just
have
seen
and
notice
about
policy.
B
The
development
of
these
policies
are
actually
business
or
organization
wide
responsibility.
Everyone
shouldn't
must
take
part
in
developing
enforcing
auditing
and
measuring
these
policies,
because,
on
the
left
hand,
side
developers
are
pretty
competent
in
like
functional
type
of
things
or
security
type
of
things.
On
the
right-hand
side,
you
may
have
sales
people
who
know
what
kind
of
implications
the
business
or
organization
could
have.
B
So
the
development
of
policies
and
enforcing
them
are
a
collaborative
thing
with
an
organization
and
if
we
employ
something
like
police
framework,
that
could
actually
help
the
entire
organization
to
contribute
to
development
of
policies
and
enforcement
of
them,
and
this
actually
kind
of
abstracts
away
actual
implementation
type
of
things
from
your
software
development
to
actually
business
level
type
of
requirements.
And
if
you
abstract
those
things
away
from
your
actual
technology
or
technical
or
development
activities,
then
you
essentially
allow
others
within
organization
within
your
organization
to
contribute
to
development
of
policies.
B
Now,
if
you
look
at
the
things
today
again,
this
is
another
example
of
sample
pipeline
and
I'm
sure
you
all
use
it
one
or
more
tools
within
your
organization
to
establish
pipelines
and
a
typical
example
for
this
could
be
like
using
jenkins
and
spinnaker,
because
jenkins
and
spinnaker
are
integrated
with
each
other,
pretty
well
by
the
communities.
So
you
can
use
jenkins
for
your
constitution
type
of
things
and
you
can
use
as
finger
for
your
context
there
and
deployment
type
of
activities,
and
there
are
multiple
challenges
with
this
type
of
setup.
B
Okay
in
jenkins
and
sprinkler
case,
the
integration
achieved
by
the
communities
may
hide
those
changes
from
you.
But
if
you
look
at
the
continental
ecosystem
in
a
broader
sense,
you
will
see
not
all
the
techniques
are.
You
know
working
well
with
each
other
good
in
a
good
way,
because
in
continuous
daily
domain
there
is
clearly
like
of
some
harmonization
and
standardization,
because
there
is
no
standardized
development
organization
within
continuous.
B
The
ecosystem,
like
how
telecom
industry
has
like
3gb,
hc
and
so
on,
and
this
lack
of
standards
cause
interoperability
challenges
within
the
ecosystem
and
those
internality
challenges
actually
hurts
policy
work
as
well,
because,
again,
based
on
the
work
we
start
with
in
special
telescope
interability
in
consciousness
foundation,
we
start
collecting
approaches
from
different
communities
for
the
projects
they
are
developing
and
they
got
input
from
various
committees
like
jenkins,
nikkor,
cacton,
ortelius
and
so
on,
and
their
take
of
policy
differs
between
themselves.
Yes,
there
are
commonalities
as
well,
but
there
are
differences
too.
B
So
those
projects
dealing
with
police
frameworks
will
have
difficulties
when
it
comes
to
bringing
police
support
to
these
different
crcd
technologies,
and
then
that
actually
hits
the
users.
Because
then
those
users
may
not
be
able
to
use
the
latest
and
greatest
quality
framework
that
is
available
within
the
domain
or
within
the
ecosystem.
B
So
if
you
want
to
do
a
canary
rollout,
for
example,
canal
deployment
within
your
production-
and
you
want
to
roll
out
new
version
of
microservice
to
see
if
it
works
well
and
then
that
actually
is
driven
by
oss
systems
and
not
by
ci
cd
technology,
cic
technologies
becomes
the
thing
that
actually
rolls
out
new
versions
to
the
production,
but
actually
that
input
is
given
by
such
external
systems
and
policy.
Parts
of
the
policy
logic
is
located
within
those
systems
and
because
there
is
lack
of
standardization
within
domain
and
within
policy
area.
B
It
is
very
difficult
for
the
actors
within
telecom
industry
to
achieve
desired
interviews
between
external
systems
and
cic
technologies,
and
then
again
it
goes
back
to
operators
of
those
techcom
networks
and
when
they
want
to
enforce
new
policies
within
their
networks,
then
they
need
to.
You
know
somehow
give
get
new
versions
of
certain
telecom
network
functions
to
get
those
policies
enforced
and
that
is
unmanageable
and
another
example
to
external
system
could
be
open
policy
agent,
that's
also
an
external
system,
and
that
could
actually
help.
B
You
know
the
users
of
various
cic
technologies
to
use
openplace
agent
or
on
up
post
framework
as
a
system
to
enforce
policies.
But
again
there
is
no
standardization
in
the
place
in
the
domain.
It
is
very
difficult
to
achieve
that,
so
you
bring
in
a
police
agent
to
your
organization.
B
You
integrate
open
police
agent
with
jenkins
in
one
way,
and
then
you
integrate
your
open
policy
agent
with
tecton
in
another
way,
and
then
you
have
to
keep
maintaining
that
thing
over
and
over
and
your
production
system.
May
you
know,
stop
working
suddenly,
because
the
community
changed
something
some
interface
changed
and
your
glucose
or
workout
doesn't
work
anymore.
B
B
Like
we
all
know,
developers
are
creative,
but
it
is
not
fair
to
expect
them
to
grasp
the
business
side
of
things
fully,
so
we
have
to
ensure
the
developers
are
trained,
but
at
the
same
time
we
have
to
ensure
we
provide
paved
roads
for
them
to.
You
know,
become
productive
as
fast
as
possible,
and
that
can
be
done
by
putting
standardized.
You
know,
policies
in
place
in
our
pipeline,
so
the
developers
when
they
develop
a
new
feature
and
push
it
through
your
pipeline.
Those
checks
are
enforced
automatically
without
actually
developers.
B
Talking
to
you
know
trying
to
find
who
to
talk
to,
because
there
is
a
system,
then
that
system
can
actually
enforce
those
policies
and
also
those
policies
could
be
documented,
like
policy
as
code,
and
then
developers
can
look
at
those
policies.
In
your
repository
and
see
what
they
actually
do
and
the
other
thing
is
like
common,
shared
understanding
again
the
objectives
behind
the
policies
why
they
are
there
and
why
they
are
important,
is
something
we
all
need
to
learn
more
about.
B
Other
issue
with
the
understanding
is
like
people
generally
mix
policies
versus
rules
like
policies
are
again
business
objectives
rules
you
can
see
them
as
like
technology
choice,
because
you
can
use
rule
engine
to
enforce
policies
and
they
actually
becomes
your
part
of
your
technologies
like,
rather
than
coming,
part
of
your
business
and
terminology.
B
B
We,
you
know,
can't
help
others
to
push
towards
the
making
things
even
better
and
finally
focus,
and
if
you
put
a
query
on
your
favorite
search
engine
like
policy
driven
development
policy
on
contents,
like
polystyrene,
contains
deaf
tournament,
most
soft
or
90
of
the
hits
you
will
get
there.
They
all
focus
on
security,
like
everyone
seems
to
be
focused
on
security.
Obvious
security
is
important,
but
security
is
not
the
only
thing
we
can
actually
achieve
by
applying
or
standardizing
standardizing
policies,
regulations,
rules,
they're,
also
important,
and
perhaps
security.
B
B
You
can't
you
know,
roll
out
new
versions
of
your
services
to
door
systems
just
update
a
policy,
so
your
policy
should
be
adaptive
and
it
should
no
be
possible
to
update
your
policies
without
actually
pushing
new
versions
of
your
microservices.
So
rather
than
having
your
policies,
statically
defined
having
your
policies
to
find
an
adaptive
manner,
so
they
can
actually
control
the
behavior
of
system
that
is
in
operation,
and
there
are
no
different
approaches
to
achieve
this.
B
It
is
like
in
telecom
industry,
there
are
self-organizing
networks,
for
example,
like
you,
don't
push
new
versions
to
your
network,
but
actually
your
network
actually
takes
certain
decisions
itself
and
tries
to
achieve
desired
state
based
on
the
policies
enforced
within
the
network,
and
you
don't
rule
out
new
versions
to
achieve
that
state
generally
and
autonomous
systems.
They
follow,
made
type
of
approach,
monitor
analyze,
plan
and
execute
approach,
so
the
system
contains
the
monitors
analyzes.
B
Another
challenge
is
how
the
policies
are
developed
and
how
their
life
cycle
is
managed,
and
this
automation
or
adaptator
autonomous
systems
position
in
such
systems
and
their
life
cycle
is
like
this
one.
But
when
it
comes
to
developing
policies
like
should
we
take
a
declarative
approach
or
imperative
approach?
This
is
something
important
to
discuss.
B
That
is
not
actually
a
ci
cd
technology,
but
it's
actually
driving
what
cic
technologies
are
doing,
how
I
can
integrate
or
how
I
can
ensure
my
third
party
systems
can
integrate
with
the
cicd
technologies.
So
I
can
push
policies
to
my
pipelines
without
actually
putting
workloads
in
place
just
to
be
able
to
push
them.
B
So
antenna
we
talked
about
challenges
or
the
police
topic
and
challenges.
What
are
we
doing
about
these
challenges?
As
trish
tracy
mentioned
at
the
beginning?
We
recently
started
discussions
around
post
topic
within
the
country's
very
foundation,
and
this
conversation
actually
started
in
two
places
within
context
of
their
foundation.
One
of
those
places
is
patient.
Telescope
interval
ability
because
of
the
reasons
isomerized
like
interval,
challenges
between
cic
technologies
and
policy
frameworks
of
policy
systems
and
in
part
that
cdf
and
user
console
actually
start
talking
about
governance
topics
so
within
cdf.
B
This
topic
is
actively
discussed
at
the
moment
within
these
two
groups
specialized
group
and
interviewed
and
user
council,
but,
as
I
also
noted
like,
sharing
best
practices
is
important
as
well
in
policy
area
and
the
other
special
interest
group
within
cdf
best
practice.
Special
telescope
best
practices
is
actually
after
collecting
these
best
practices.
B
So
we
have
technology
issues
which
we
can
look
at
them
as
part
of
our
interoperability
work.
We
have
best
practices
challenges.
We
can
look
at
them
as
part
of
best
practices
work.
We
also
have
end
users
which
they
can
join
and
bring
up
their
needs
to
broader
discussion
and
how
those
policies
enforce
or
how
those
policies
are
transferred
to
systems.
They
can
be
done
in
different
ways
like
you
can
use
the
rest
api
and
push
your
queries
to
the
system
or
you
can
use.
B
Events
to
you
know,
pass
your
policies
and
that
could
be
worked
under
special
terrorist
group
urines
and
why
I
am
talking
about
these
different
groups
in
cdf
is
that
cdf
is
a
great
community
that
actually
gives
people
an
open
and
neutral
form
to
discuss
these
things.
As
you
all
know,
it
hosts
many
different
city
tools
and
technologies,
and
it
hosts
all
these
different
groups.
So
you
can
go
there.
You
can
work
with
different
communities.
You
can
work
with
the
people,
like-minded
people
within
different
groups,
and
you
can
actually
tackle
with
these
challenges
together.
B
So
if
we
can
bring
end
users
developers
into
context
derive
foundation,
we
can
get
communication
established
between
end
users,
cicd
projects
and
the
police
projects.
They
are
dealing
that
are
dealing
with
police
topic.
In
this
case,
it
is
open
policy,
agent
and
or
not,
because
these
projects
are
not
hosted
by
cd
foundation.
B
Even
though
we
are
working
open
source,
it
is
important
to
collect
input
from
our
enterprise
versions
of
different
cic
technologies,
for
example,
in
sprinkler
case
it
is
armory
and
harness
is
also
an
enterprise
offering.
So
we
can
compare
and
contrast
the
approaches
of
different
organizations
and
find
ways
to
streamline
those
things
in
addition
to
communities,
we
are
collecting
input
from
users.
Currently,
we
have
input
from
ebay
and
ericsson
and
finally,
we
are
collecting
challenges
from
within
user
organizations
or
from
projects.
B
So
what
I
want
to
what
I
want
to
summarize
during
last
r
is
that
policy
is
critical
for
all
organizations,
regardless
of
the
size
like
you
may
be
working
with
a
nice
startup.
You
may
be
working
within
an
established
organization.
It
doesn't
matter
how
big
your
organization
is
or
how
you
know
all
your
organization
is.
You
have
to
ensure
you
enforce
your
policies
within
your
pipeline,
so
you
don't
put
the
business
in
risk
again.
Industry
is
not
different,
obviously,
all
the
industries,
they
are
bound
with
different
law
laws.
B
They
follow
different
rules
and
regulations,
but
there
must
be
a
common
way
to
enforce
those
policies
depending
on
the
industry.
Organization,
is
operating
in,
and
policies
critical
for
all
these
different
industries
and
type
like
are
you
operating
in
highly
regulated
industry
like
healthcare
or
you
are
just
you
have
a
simple
you
know
tool
which
helps
users
to
do
what
they
like,
which
is
like
not
very
highly
regulated.
You
regulate
your
you
know,
service
yourself
and
in
order
to
you,
know,
establish
such
policies
within
organizations.
B
We
need
to.
You
know
define
standardized
approach
to
defining
and
enforcing
those
things,
and
that
is
something
we
I
think
we
can
push
together
and
in
order
for
us
to
push
those
things,
we
need
to
address
the
challenges
together,
and
that
could
only
happen
if
we
get
broader
participation
from
various
communities,
projects
and
users
and
continues
their
foundation
is
like
a
like
great
place
to
start
a
new
conversation
or
take
part
on
take
part
in
an
ongoing
conversation
such
as
policy,
and
that
is
like
this
page.
B
A
Thank
you
fatih.
I
just
have
we're
off
the
top
of
the
hour,
but
I
do
want
to
if
somebody
out
there
would
like
to
get
involved
in
this
conversation
that
they're
working
on
policies
for
their
organization.
They
want
to
add
to
this.
How
can
they
reach
you?
How
can
they
what
should
be
their
next
step
if
they
want
to
get
involved
in
this
discussion.
B
Yes,
so
I
put
the
links
to
the
slides
and
I
hope
you
can
still
see
the
slides
or
my
screen,
at
least
so.
On
the
last
page
of
the
presentation,
let
me
start
presenting
again.
I
put
the
links.
Sorry,
these
things,
I
put
the
links
to
all
those
things
I
talked
about
like
if
you
want
to
deal
with
the
technological
aspects
of
the
policy.
Please
join
sid
interval
because
our
focus
is
mostly
technology.
B
If
you
want
to
work
with
best
practices,
aspects
of
policy
join
the
six
express
practices.
If
you
want
to
contribute
a
use
case
from
your
organization,
you
can
directly
go
and
update
this
document
which
we
are
working
on.
So
these
are
the
links
where
you
can
find
all
the
information
how
to
contribute
how
to
join.
A
So
what
we'll
do
is,
if
you
can
be
sure
and
send
this
to
me,
and
what
I'll
do
is
when
I
extend
the
recording
out,
I
will
also
send
with
it
a
link
to
this
particular
doc,
so
that
they'll
have
these
links,
because
I
you
know,
as
as
fatigue
pointed
out,
this
is
a
discussion,
that's
broad
and,
having
more
end
users,
input
and
tools
that
are
in
the
the
commercial
area
of
the
cicd
pipeline.
We
need
those
that
we
need
that
information.
A
B
Actually,
it's
I
wouldn't
say
we
are
looking
to
build
a
police
framework.
I
think
we.
What
we
can
do
is
to
reach
out
to
different
projects
who
are
active
in
policy
domain
like
open
policy
agent
or
on
a
policy
framework
and
bring
those
committees
into
discussions
within
cdf,
so
we
can
actually
work
with
those
communities
to
get
such
false
framework
in
place
rather
than
ourselves
developing
it.
In
addition
to
that,
like
sharing
best
practices
is
another
thing
we
can
do
both
with
an
internal
physique
or
in
best
practices,
but
I
am
not.
A
Is
watch
the
space
I
think
policies
and
events
in
ci
cd
are
both
really
going
to
be
really
important
as
we
move
forward
and
we
and
we,
you
know,
try
to
accomplish
the
goal.
The
cdf,
which
is
to
create
help,
create
a
ci
cd
pipeline
that
allows
people
to
move
through
that
with
you
know,
security
and
speed
and,
as
you
indicated,
policies
can
potentially
get
in
the
way.
But
if
we
do
it
right,
policies
are
simply
the
guard
rails
for
the
cd
pipeline
so
that
we
can
go
faster
exactly
well.
Thank
you.
A
It's
the
top
of
the
hour.
Thank
you
so
very
much.
I
appreciate
this
and
this
will
be
sent
in
and
recording
within
the
next
12
hours.
Okay,.