►
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Panel Discussion: OpenGitOps and the GitOps Working Group - Cornelia Davis, Amazon; Dan Garfield, Codefresh; Christian Hernandez, Red Hat; Chris Sanders, Microsoft; Leonardo Murillo, Weaveworks
Hundreds of organizations today are leveraging GitOps to successfully run and manage complex software systems, benefitting from its inherent modern development best practices as well as the tools that implement its responsive continuous deployments. GitOps adoption has seen dozens of companies innovate to offer solutions, and inspired several open source projects including Argo and Flux, both CNCF projects. With innovation accelerating and the number of stakeholders increasing, the time has come for a clear, vendor-neutral definition of GitOps. Inspired by increased interest and informed by years of working toward solutions, a CNCF GitOps Working Group was formed in 2020 to discover and standardize the definition of GitOps and its principles. This group will also focus on interoperability between tools, conformance, and certification. Join us for a panel discussion with members from several of the founding organizations to learn about GitOps, OpenGitOps, and future work.
A
Okay,
hi
everyone.
I
think
we're
ready
to
get
started
so
come
on
in
and
welcome
also
to
everybody
who's
joining
us
online.
We
are
going
to
do
our
best
to
try
to
get
everybody's
questions
answered,
including
the
online
questions
so
hi,
I'm
lisa
marie
anamphia,
I'm
a
cncf
ambassador,
and
I
would
like
to
welcome
you
to
the
getups
working
group
session.
Please
do
not
be
shy.
There
will
be
someone
running
around
the
room
with
a
microphone
to
make
sure
we
get
all
of
you
heard.
A
B
Thank
you,
lisa
thanks,
lisa
awesome,
so
yeah
we're
the
we're.
The
get-offs
working
group,
which
is
a
working
group
established
underneath
the
cncf
last
year
in
a
partnership
between
github,
azure,
aws,
red
hat,
weave
works
and
code
fresh
and
the
goal
of
the
get
ops
working
group
was
essentially
to
come
together
and
work
out
a
standard
for
how
git
ops
should
work,
what
the
principles
should
be.
C
Yeah
hi
everyone,
I'm
cornelia
davis,
I
have
spent
the
last
10
years
or
so.
Working
on
developer
platforms
worked
on
cloud.
Foundry
worked
on
some
kubernetes
platforms
with
pivotal
and
vmware
as
well,
and
then
I
was
at
via
at
weaveworks
when
we
created
the
the
get
ops
working
group
and
we'll
talk
about
the
open,
git
ops
project
as
well
to
clarify
that
and
just
recently
moved
over
to
amazon.
D
B
Fantastic
thanks
everybody,
so
the
format
of
this
is
pretty
open.
We
basically
wanted
to
have
a
discussion
talking
about
the
new
principles.
We
just
released
open,
get
ops
1.0,
and
we
also
want
to
invite
people
to
ask
questions
and
we'll
have
kind
of
an
open
field.
It's
open
format.
We
were
all
able
to
commit
to
that
because
it
required
minimal
preparation.
C
So
those
were
projects
that
had
reached
incubation
and
reached
graduation
where
the
some
of
the
projects
that
they
talked
to
about,
and
then
I
talked
about
the
technical
advisory
groups
that
support
kind
of
that
that
overall
agenda
and
when
we
started
the
get
ops
working
group,
we
put
it
forth
as
a
project
and
we
were
we
made
sandbox.
So
it
was
a
sandbox
project,
but
it
was
a
bit
confusing
for
everyone
because
they
were
like
wait.
C
Some
of
those
artifacts
dan
just
alluded
to
the
fact
that
there's
these
principles,
but
there's
other
artifacts
that
we'll
be
creating.
So
that's
the
home
of
all
of
the
artifacts,
just
like
other
projects,
might
have
code,
artifacts
and
documentation
artifacts,
it's
the
same
thing
here
and
we
may
generate
some
sample
code
and
those
types
of
things
as
well,
so
think
of
the
open,
get
ops
as
the
project.
It's
a
sandbox
project.
B
Yeah
perfect,
I
mean,
I
think
I
hope
that
clears
up
any
confusion
about
it
and,
like
cornelia
mentioned,
we
just
released
open,
get
ops
1.0
as
a
set
of
principles
and
as
a
set
of
standards.
This
isn't
something
that
you
know
the
the
group
here
on
the
stage
we
all
just
said:
let's
get
together
and
we're
going
to
pass
down
from
on
high
the
correct
principles
and
we'll
expect
the
community
to
embrace
it.
Actually,
it
was
a
very
collaborative
process.
We
had,
I
think,
over
80
or
90
different
participants.
B
D
So
I
think-
and
this
is
also
relevant
to
all
the
people
that
that's
joining
us
today,
both
here
as
well
as
virtually
right-
the
process
has
been
fully
driven
through
community
collaboration
right.
What
we're
looking
to
define
is
how
this
principles,
how
git
ups
is
implemented,
how
it's
it's
actionable
and
real
right
to
the
community
and
ecosystem.
D
So
in
order
for
us
to
do
that,
we
we
really
needed
to
hear
from
the
community.
So
we
we
started
by
creating
committees,
okay,
so
anybody
can
join
the
working
group.
We
have
monthly
meetings
where
anybody
can
participate
and
we
started
to
create
committees
where
people
could
meet
up
and
collaborate
and
share
their
ideas
as
to
what
really
get
ups
meant
for
them
and
for
their
organizations,
and
it
was
a.
I
think
it
was
a
very
enriching
process
right.
D
I
think
it
was
phenomenal
the
level
of
depth
of
the
conversations
and
the
commitment
of
everybody
that
participated
kind
of
looking
to
to
really
extract
the
truth.
Out
of
all
these
concepts
that
we
have
been
looking
to
develop,
so
we
meet
every
month.
There
is,
of
course,
as
cornelia
mentioned,
it
is
an
open
source
project.
There
are
repositories
where
there's
discussions
that
are
ongoing
and
we've
just
released
version
1.0
right.
D
This
is
just
the
tip
of
the
iceberg,
there's
all
sorts
of
debate
and
discussion
that
still
needs
to
happen
as
to
how
the
things
are
implemented.
What's
how?
How
is
it
actionable
in
the
in
the
actual
ecosystem?
So
I
really
encourage
everybody
to
to
participate
right
in
this
debates,
keep
track
of
what
we're
doing
in
our
repository
in
github
and
and
and
be
active,
because
after
all,
these
artifacts
that
we're
producing
are
really
the
reflection
of
what
the
the
industry
and
what
the
ecosystem
are
looking
to
accomplish
right
through
through
this
principles,.
D
B
Yeah,
you
said
it
was
really
you
you
put.
It
sounded
so
positive
when
you
said
it,
and
I
was
thinking
about
all
of
the
painful
discussions
and
debates-
and
I
was
like-
is
this
going
to
become
a
flame
war?
Where
you
know
it's
like
things
like?
What
does
synchronize
mean?
What
does
apply
mean?
What
you
know
like
you
know,
if
you're
going
to
put
these
things
down,
it's
going
to
be
in
black
and
white,
it's
going
to
be
hardcore.
B
If
you,
if
you
haven't
seen
the
principles
up
on
the
screen,
it
says
opengitops.dev,
that's
the
site,
so
I
would
encourage
you
to
pull
it
up
and
and
check
out
the
four
principles
that
are
there
and
and
look
through
them
because
they
might
sound
simple
by
themselves,
but
it
actually
represents
a
lot
of
experience
and
thought
and
people
people
have
been
doing
some
of
these
things
for
15
20
years.
I
think
cornelia
and
I
talked
a
little
bit
about
how
this
is
not
there.
C
It
just
doesn't
take
you
all
the
way
to
a
new
way
of
managing
your
systems,
and
that,
I
think,
is
one
of
the
things
that
that's
one
of
the
things.
That's
not
as
well
understood
about
the
whole
get-ups
movement
is
that
it
does.
The
principles
do
represent
something
very
foundational
that
hasn't
been
ubiquitous.
C
F
This
isn't
a
yeah.
Well,
it's
it's
funny
that
that
leo
put
it
so
so
eloquently
but
like
it
almost
did
feel
like
a
lot
of
blood.
So
when
tears
went
into
us
because
it
there
was
a
lot
of
you
know,
they
do
seem
simple,
but
there
was
a
lot
of
passion
you
know
in
in
defining
these
principles
and
and
and
making
it
open
and
vendor
neutral.
I
think
it
was.
It
was
powerful
that
it
was
brought
forth
in
that
aspect.
Right
like
it
wasn't.
F
You
know
there
there's
there
was
members
from
from
weave
works.
There
was,
you
know
from
code
fresh
from
red
hat
right,
so
this
wasn't
like
a
a
vim
versus
emac
sort
of
thing
like
there
was
a
completely
opposite
of
like
we
actually
came
together
and
try
to
make
make
those
principles,
and
it's
now
really
something
that
I
can
refer
to.
As
cornelia
was
saying
you
know,
a
lot
of
people
are
saying.
F
Well,
you
know
I'm
already
doing
some
of
this
infrastructure
as
code
things
like
well,
that's
just
one
piece
of
actually
doing
get
ops
and,
and
now
it's
great
to
be
able
to
refer
to
something.
It's
like
no!
No,
if
you
really
want
to
do
get
ops,
what
you're
doing
goes
against
you
know
one
and
two
or
you're.
You
know
you're
doing.
H
F
D
It
was
fascinating
to
to
see
the
dynamics
of
that
interaction
right
because,
particularly
coming
from
from
kind
of
more
structured
decision-making
processes
right,
like
within
organizations,
there's
usually
a
hierarchy
that
defines
a
lot
of
the
decisions
that
need
to
be
made.
But
with
the
working
group
it
was
such
a
process
of
reconciliation
right
of
ideas.
B
Today,
then
he
gave
a
talk
on
get
ops
and
he
said
how
many
of
you
are
doing
get
ups
today,
and
five
percent
of
the
audience
was
like
we're
doing
it
ups
today,
so
there's
definitely
a
delta,
and
I
think
we
should
actually
talk,
maybe
a
little
bit
about
like
this
delta
of
like
what
the
perception
is.
I
think
sometimes
people
think
it
just
is
well,
I
make
a
commit
and
things
happen-
that's
git
ops
and
it's
actually
like
well
how
the
how
that
commit
makes
it
from
point.
B
E
But
then
you
know
that
what
I
see
as
interesting
about
the
open
getups
project
is
then
the
community
comes
in
and
starts
giving
examples
of
how
to
apply
these
principles
and
there's
going
to
be
many,
many
different
scenarios
out
there.
You
talk
to
customers
and
they're,
we're
all
over
the
place
and
how
to
do
it
they're.
Looking
for
how
do
I
do
this?
E
What's
the
best
way
to
do
it,
and
that's
where
I
see
the
open
git
ups
project
coming
in
as
a
way
to
put
this
information
in
there
so
that
folks
know
how
to
do
it?
They
know
how
to
create
tools
that
work
together
and
all
of
that,
but
as
far
as
the
principles
go
that
are
very
interesting
as
far
as
a
tool
set
for
kubernetes
management.
You
know
the
fact
that
of
course,
declarative
is
is
huge.
You
know
you're
not
putting
your
business
logic
into
code
anymore.
E
The
business
logic
is
in
is
in
yaml
files
that
anyone
can
look
at
they're
starting
to
get
repo,
that's
versioned,
so
you
can
see
what
change
one
version
to
the
next
and
then
your
commit
to
your
repo
becomes.
Basically
that's
your
operation
as
an
application
developer
as
a
kubernetes
manager,
and
you
don't
worry
about
the
actual
ci
into
or
the
cd
into
the
into
the
cluster
itself
right.
E
You
worry
about
your
ci
part
and
I
think
that's
huge,
because
it
takes
a
big
part
of
the
loop
out
of
places
where
actually
you
and
I
can
cause
problems
if
we
go
in
there
and
try
to
do
the
cpcd
part
ourselves.
So
I
see
the
whole
principles
of
how
git
ops
works
as
a
very
clean
way
to
manage
kubernetes,
and
that's
one
of
the
reasons
why
azure
was
very
interested
in
making
you
know
being
part
of
this
and
and
seeing
it
go
forward
with
the
community
and
using
the
community
tools.
F
Yeah,
I
think
I
think
actually
my
my
favorite,
I
guess
piece
of
of
the
principles
is
the
whole
discussion
we've
had
and
you
guys
can
see
the
discussion
on
github
right.
We've.
Everything
I
think
mostly
was
done.
Asynchronously
on
github
is
the
it's
essentially
the
kind
of
the
concept
of
the
control
loop
and
I
think
that's
like
the
defining
thing
about
about
get
ops
versus
doing
something
like
with
web
hooks
or
doing
something
with
like
ci.
Is
that
reconciliation
loop
that
control
loop
versus
triggering
something
to
happen?
F
There
is
the
the
get
ops
controller
right,
whatever
you're
using
flux
or
argo,
is
constantly
checking,
and
that's
that
that
that
loop-
that's
the,
I
think,
that's
that's!
That's
one
of
the
one
of
my
favorite
principles,
because
it
kind
of
drives
home
the
fact
that
we're
leveraging
the
platform
of
kubernetes
we're
leveraging
that
that
that
that
that
control
loop
right
from
from
each
one
of
those
domains-
and
I
think
that
is
one
of
the
defining
factors
of
using
get
ops
versus
what
we
sometimes
call
ci
ops
right.
F
B
Yeah
this
is
this
is
a
feature
of
control
theory
and
by
the
way,
we're
monitoring
questions
on
the
platform
and
we're
gonna.
I
think
we're
gonna
come
to
those
in
a
moment
and
if
people
have
things
from
the
audience,
you
wanna
raise
your
hand
and
lisa
will
run
around
and
it
looks
like
we
have
one
over
here,
but
while
you're
running
over
the
the
control
loop
aspect,
we
we
talked
about
some
analogies
and
the
classic
analogy
is
a
thermostat
versus
a
radiator
and
in
an
open
loop.
B
You
have
a
radiator
it's
just
on
and
it
provides
heat
and
a
thermostat
you
set.
This
is
the
temperature
I
want
and
there's
adjustments
and
there's
feedback
and
it's
checking
to
see
what
the
temperature
actually
is.
As
it
turns
the
heater
on
and
applies
it
and
get
ops
is
meant
to
operate
in
sort
of
the
same
way
where
we
say
this
is
a
state
that
we
want,
but
there's
also
a
a
checking
mechanism
within
the
operator
within
the
agent.
That's
actually
saying
was
this
actually
applied.
Wait.
B
H
Hey,
thank
you.
I
I
have
a
a
combination
of
practical
philosophical
question
right,
so
I
I
mean
our
work
is
adopting
get
ups
previous
work
as
well,
very
happy
that
solves
the
obvious
problems
and
so
on
so
forth,
right
up
to
a
certain
level
right
as
our
company
grows
in
size
and
this
may
be
applicable
to
subset
of
companies.
H
H
Now
we
can
use
git
as
a
back
end
for
that
right,
there's
obviously,
patterns
right.
You
check
out
you
command
to
create
pull
requests
right,
I
mean,
but
at
that
point,
are
we
just
not
like
making
get
the
database
and
like
reinventing
a
database
and
get
then?
Is
there
not
like
a
contradiction
at
that
point?
Right,
like
I
mean
generally,
we
can
all
like
hack
it
and
write
golden
that.
Does
that
but
like
at
that
point,
we
just
created
the
database
essentially
right.
So
I
I'm
curious
here
are
your
thoughts
on
that.
C
I
I
would
love
to
chime
in
because
I
think
you
said
something
really
important
there,
because
git
plays.
If
you
will,
I
like
to
think
of
it
as
a
dual
role
in
the
whole
getups
agenda.
One
is
that
it
can
be
used
as
the
user
interface
as
the
collaboration
mechanism
where
everybody
can
come
together.
You
can
have
many
different
eyes
sets
of
eyes
that
go
on
a
commit.
You
can
validate
that.
That's
the
right
commit
before
you
commit
it,
and
once
you
commit
it,
then
you
have
this
convergent
automation.
That
happens.
That's
one
element.
C
The
other
element
is
exactly
as
you
said,
it
is,
if
we
think
of
it,
as
the
data
store
now
you're
right
at
one
level.
It's
like
wait
a
minute.
Why
would
we
use
git
as
a
database?
Aren't
there
other
database
technologies,
but
git
has
some
semantics
baked
into
that
database
that
are
really
crucial
to
the
git
ops
agenda.
C
C
Well,
it
turns
out
that
what
you
can
do
is
you,
because
git
is
inherently
distributed.
All
you
need
to
do
is
do
a
git
clone
to
some
edge
location
and
now
you've
got
and
you
can
have
a
convergent
loop.
That's
constantly
updating
that
so
that,
if
you
have
a
network
outage
no
problem,
when
the
network
comes
back,
you've
got
a
clone,
so
it's
a
distributed
database.
C
C
B
Yeah,
we
were
actually
very
careful
in
the
principles.
It
does
not
say
you
have
to
use
git.
In
fact,
the
principles
don't
it's.
I
know
it's
called
get
ups
right,
but
but
the
principles
actually
don't
matter
the
principles,
don't
actually
mention
git.
They
mention
that
you
need
to
be
using
aversion
and
immutable
storage
for
your
desired
state.
Now
you
could
be
doing
that
with
perforce.
B
You
could
be
we
we
actually
debated
if
you
could
potentially
implement
it
and
be
conformed
with
google
sheets,
and
you
could
potentially
do
that
and
also
you
could
be
using
git
and
not
be
conformant.
So,
for
example
like
in
in
kubernetes,
everybody
knows
don't
use
the
latest
tag
right.
Well,
if
you
were
you're
actually
not
using
versioned
immutable
storage,
because
this
is
an
end
run
around
versioning,
because
now
you
can
no
longer
say
this
is
my
desired
state,
because
in
fact
the
artifact
that
you're
using
isn't
versioned.
B
D
Yeah-
and
I
think
that
type
of
feedback
is
exactly
what's
going
to
keep
this
paradigm
evolving
right
yeah,
because
we
were
really
focused
on
not
talking
about
implementation,
specifics
right
rather
objectives
that
should
be
satisfied
by
a
certain
architecture,
tooling
right.
So
as
as
the
paradigm
evolves
and
it's
adopted
by
larger
scale
and
different
type
of
use
cases,
I
think
we
will
start
seeing
new
technologies
that
are
going
to
be
used
for
for
for
storing
state.
D
What
we're
trying
to
define
is
what
are
these
fundamental
principle
characteristics
like
kanila
was
pointing
out
right.
That
should
be
satisfied,
and
yes,
git
is
the
one
that
satisfies
them
at
this
point
in
time,
but
as
as
it
evolves,
there
likely
will
be
other
repositories
that
will
satisfy
those
those
requirements.
A
G
Thank
you.
So
you
mentioned
the
principles
you
were
that
you
derived
and
that
you
started
from
complexity
and
kind
of
narrowed
it
down
to
more
straightforward
ones.
I'm
curious
if
you
found
some
common
anti-patterns
that
you
found
in
multiple
places
and
that
once
they
set
the
root,
it
made
it
hard
to
move
to
to
the
system
that
works
adheres
to
your
principle.
Yeah.
D
E
Well,
I've
thought
about
this.
A
lot
too
because
get
ups
at
one
point
says
single
source
of
truth
right
and
I
think
there's
going
to
be
a
spread
that
you're
going
to
have
to
decide
on
yourself
right
you
can.
The
perfect
would
be
the
single
source
of
truth.
Everything
goes
through
get
and
you
know
exactly
what's
going
on,
but
I
can
just
give
an
example
from
from
azure.
That
is
a
managed
service
there.
We're
also
offering
the
ability
to
bring
in
services
from
azure
that
are
delivered
through
azure
and
agents
on
the
on
the
clusters.
E
Right
suddenly,
there's
multiple
sources
of
truth.
I
don't
know
what
to
say
to
that
except
to
say:
well,
there
is
a
benefit
perhaps
to
have
multiple
sources
of
truth
instead
of
just
a
single
one,
but
you
can
have
you
can
decide
so
that
I
think
that's
an
example
of
this
sort
of
of
conflict
that
that
can
happen.
F
Yeah
to
leo's,
you
know
just
expanding
a
little
bit.
What
leo
was
saying
is
that
a
lot
of
people
do
think
that
it's
like,
oh
no
like
I,
I
have
a
backup
in
git
right
and
thinking
they're
doing
it
like.
No,
it
has
it's
not
it's
not
a
backup
per
se.
In
that
aspect,
right,
it
can
function
as
a
backup.
It's
like!
No,
it's
not
a
reflection.
It's
actually
what's
in.
Was
it
your
actual
state
and
that's
kind
of
one
of
the.
F
You
know
one
of
the
things
we
saw
and
and
maybe
not
necessarily
an
anti-pattern
there's
there's
some
things.
I
think
that
are
still
left
up
in
the
air
that
that
came
up,
that
we
kind
of
just
maybe
just
brushed
aside
a
little
bit
for
this
first
go-around,
because
it's
like
wow.
This
is
a
really
complex
problem.
Right,
like
one
of
the
problems
is
like
secret
management.
F
You
know
there
is
the,
I
think,
there's
the
concept
of
you
know,
encrypting
your
secret
and
then
storing
that
in
get
because
you
don't
never
want
to.
You
know,
store
that
in
in
encoded,
but
then
is
that
an
actual
is.
Is
that
the
actual
state
like
technically
like
philosophically,
is
that
the
actual
state
and
then
there's
some
people
that
don't
want
to
do
that
and
they
use
something
like
a
management
system
like
vault
is
probably
like
the
most
popular
one
it's
like.
F
F
B
B
Yeah,
I
I
would
say
the
two
one
or
two
biggest
anti-patterns
I
see
are
people
who
are
like.
Oh
I'm,
totally
on
board
for
git
ops
and
then
I'll
apply
the
changes
and
you're
like
whoa.
That's
what
you're?
Not
you
can't
be
the
software
agent.
You
can't
be
the
reconciler,
that's
checking
the
the
actual
state,
so
that
doesn't
work
and
often
I've
had
people,
and
even
today
I
had
several
people
ask
me
they
said
well.
What?
If?
What?
B
If
I
want
to
put
something
in
git-
and
I
I
don't
want
it
deployed
and
I
was
like
well,
no,
you
said
that
you
wanted
it
deployed
when
you
put
it
again,
that
was
the
statement
of
intention.
So
if
you
don't
want
it
deployed,
you
probably
shouldn't
have
stuck
it
in
your
main
branch
or
you
know
the
branch.
That's
that
you've
declared
as
your
desired
state.
B
You
need
to
have
the
checks
on
the
pull
request
or
before
that,
so
that
you're,
not
applying
something
as
your
desired
state
and
desired
state
is,
is
also
a
little
bit
of
a
meta
concept
too,
because
you
can
do
something
like
say.
My
desired
state
is
to
deploy
this
blue
container
and
to
check
to
see
if
it
meets
these
metrics
and
if
it
doesn't
meet
these
metrics.
I
want
the
yellow
container
that
was
there
before
to
be
deployed
and
that's
sort
of,
if
you
think
about
it,
that
is
a
desired
state.
A
B
There
actually
hasn't
been
discussions
within
the
working
group
of.
Should
there
be
a
single
tool,
I
think
as
a
standard
we
said
a
standard
should
be
tool
agnostic
and
it
should
be
something
that
flux
is
compliant
with
and
argos
seed
is
compliant
with,
and
potentially
infrastructure
can
be
compliant
with,
or
other
tools
can
be
compliant
with.
D
Yeah,
I
think
I
think,
as
a
working
group
and
as
an
open
source
community,
there's
there's
a
lot
of
value
in
diversity
right
and
there's
a
lot
of
value
in
in
different
approaches
to
solving
similar
problems.
So
we
have
not
discussed,
I
mean,
and
really
it's
not
our
precision
right.
We
have
nothing
directly
to
do
with
other
than
kind
of
representing
our
different
tools
to
make
that
type
of
decision
within
the
working
group.
H
F
I
think
it's
it's
more
to
do
with
you
know,
having
something
be
compliant
right
like
oh
yeah,
argo
is
compliant,
flux
is,
is
compliant
or
the
next
great
tool
is
compliant
because
they
conform
to
the
to
the
tools
and
we're
less.
The
reason
I
I
like
the
working
group
is
we're
more
about
the
process
more
about.
Like
the
ideals
versus
you
know,
the
hammer
right
like
we
were
more
about.
You
know,
building
something
versus
focusing
on
the
tool,
so.
B
B
You
know
the,
I
don't
think
the
projects
have
that
on
their
roadmap
and
there's
not
really
any
intention
that
I've
heard
of
to
do
that
with
another
project,
but
hey
it's
open
source,
so
you
can
go
and
do
that
and
you
could
throw
it
up
and
argo
cd
also
has
like
an
extensions
library.
So
you
could
add
in
a
ui
element
for
flagger
and
there
are
people
that
use
flagger
with
argo
cd.
So
it's
certainly,
I
would
say
like
not
something
that
I've.
B
I
One
more
question,
so
I
work
with
a
lot
of
mid-sized
large-sized
enterprises
and
we
can
implement
git
ops
and
it
works
great
from
a
technology
perspective,
but
then
there's
always
the
like
the
old-school
itil.
You
know
they
want
to
do
releases.
They
want
to
know
what's
happening
when
it's
happening,
all
those
things
giving
you
recommendations
on
how
to
bridge
the
gap
between
this.
You
know
very
fast-paced.
I
D
D
It's
a
matter
of
understanding
how
these
different
patterns
apply
to
satisfy
those
requirements,
and-
and
I
think
it's
it's
a
matter
of
of
education
and
kind
of
thinking
a
little
bit
outside
of
the
usual
realm
of
of
technology
right.
You
can
use
git
as
your
interface
and
and
you
you
can
satisfy
all
those
different
check
lists
with.
C
I'd
love
to
just
add
one
thing,
and
it's
a
really
kind
of
pragmatic.
I
think
tip
that
I
would
give
you
and
it's
not
specific
to
git
ops,
but
when
it
comes
to
any
of
these
major
transformations
that
happen
within
an
enterprise,
one
technique
that
I've
seen
that
works
really
well
is
you've
established
that
get
ops
practice,
invite
your
compliance
and
your
security.
Folks
in
say
we
are
going
to
do
a
deploy
today,
clear
your
calendar.
C
And
so
it's
that
it's
this
brilliant
like
moment
of.
Oh,
my
gosh,
we
just
spent
a
whole
day
doing
something,
and
you
just
showed
me
how
all
of
these
gates
are.
All
of
these
things
are
are
implemented
into
the
system,
and
now
we
just
did
the
same
exercise.
We
did
yesterday
in
eight
hours
we're
doing
it
in
two
minutes
and
you've
shown
me
how
my
requirements
are
satisfied.
That's
a
very
it
just
invite
them
to
the
party.
Don't
fight
him.
Invite
him
to
the
party.
F
B
Yeah-
and
I
this
kind
of
reminds
me
of
we
had
some
people
asking
yesterday,
and
I
don't
want
to
belittle
this
question,
but
someone
was
saying
well
how
do
you?
How
can
you
adopt
git
ops
if
you
know
that
git
could
potentially
go
down
and
if
your
git
availability
isn't
100,
but
you
needed
to
make
a
change
when
git
wasn't
available?
What
would
you
do,
and
I
thought
well,
that's
a
good.
B
So,
let's,
let's
play
the
other
way,
you're
not
doing
git
ops
and
your
process
is
what
someone
logging
onto
the
server
and
applying
it
or
and
then,
if,
if
it's
inbounds
to
say
what,
if
git
is
down,
then
it's
inbounds
to
say
what,
if
that
person
is
out
sick,
what
if
this
person
is
on
vacation
like
you're,
establishing
this
process
and
to
cornelia's
point
when
you
actually
see
it
in
action
and
people
are
like?
Oh,
is
there
really
any
visibility
to
this?
B
Oh,
my
gosh
is
that
ever
important
when
it
comes
to
delivering
software
and
how
many
times
there
are
so
many
places,
especially
in
the
past,
where
that
chain
of
custody
has
not
been
clear
and
it
leads
companies
into
situations
where
they're
shipping
vulnerabilities,
where
there's
code
that
they
don't
know
what's
running
on
production,
they
have
no
idea-
and
it's
a
very,
very
scary,
place
to
be
so.
Giving
that
chain
of
custody
with
git
with
get
ops
is
super
powerful.
D
And
you
know
just
kind
of
like
a
side
note
that
cornelius
was
referring
to
right.
Get
cannot
be
down,
get
this
distributed
and
there's
a
bunch
of
copies
get
up.
Maybe
down
get
lab,
maybe
down.
So
that's
kind
of
also
very
important
to
understand
as
to
why
get
ups
is
so
relevant
and
valuable
right,
because
the
the
source
of
truth
can
live
beyond
the
provider
that
has
given
access
to
it
right.
So
I
think
that's
that's
important.
A
B
Yeah,
there's
there's
a
lot
of
things
kind
of
in
the
works.
There
are
some
additional
updates
to
the
principles
in
the
glossary
that
are
in
discussion,
but
one
of
the
things
we
want
to
start
working
on
are
best
practices
which
we
envisioned
sort
of
taking
the
form
of
like
white
papers,
or
things
like
that,
where
you
can
say
what
does
an
implementation
of
git
ops,
look
like
using
xyz
tools
and
we
envisioned
this.
B
This
is
all
still
in
the
works
and
discussion,
but
this
idea
that
I
want
to
go
and
look
and
see
if
I
want
to
use
aws
or
if
I
want
to
use
azure
or-
and
I
want
to
use
this
tool
or
that
tool.
The
other
tool
has
somebody
made
a
reference
architecture
for
this,
for
how
they've
done
git,
ops
and-
and
we
can
say
you
can
submit
it-
and
you
can
basically
say
like
this
thing-
is
get
ops
compliant.
D
D
D
We
really
want
to
reach
out
there's
I
don't
know
how
many
interactive
parties
that
kind
of
expressed
interest
in
the
working
group
want
to
reach
out
to
all
of
them,
keep
working
with
the
hyperscalers
and
kind
of
increase,
the
adoption
of
of
get
ups
by
the
cloud
providers
and
there's
there's
a
lot
of
work.
As
I
mentioned
right,
this
is
where
we
are
is
just
the
tip
of
the
iceberg,
and-
and
we
really
want
to
encourage
community
involvement
to
produce
all
these
artifacts
right
that
are
gonna
move
move
the
the
paradigm
forward.
D
J
J
F
So
I've
done
a
little
work
around
this
there's
definitely
a
place
for
it
right,
and
I
think
I
think,
an
early
version
of
the
principal
said
that
we,
it
said
something
that
I
may
be
butchering
us.
So
sorry,
we've
done
so
many
iterations
that
the
the
the
versioning
can
be
mutated,
either
by
a
human
or
a
machine
right
or
something
to
that
to
that
effect
right,
and
so
this
something
that's
writing
to
get,
doesn't
necessarily
have
to
be
a
human
right.
F
It
can
be
part
of
a
ci
process
right,
something
as
simple
as
running
a
jq
right
on
or
or
yq
on,
on
a
yaml
file.
When
you
update,
you
know
an
image
right,
I'm
sure
there's
tools
out
there,
that'll
unlock
update
image,
but
I'm
choosing
a
simple
example
that
can
be,
and
then
that
does
a
pull
request
for
you
right.
So,
like
there's
an
automated
process
that
that
that's
the
stop
gap
right
that
someone,
the
human
needs
to
actually
go
and
click
merge
to
actually
happen.
F
B
Well
there
it's
open-ended
what
metrics
you
could
put
on
there
and
you
could
potentially
have
a
manual
intervention
saying:
oh
no,
we
caught
a
problem
we
want
to.
We
want
to
no
longer
have
this
move
forward,
so
there
and
there's
maybe
a
little
bit
more
fuzziness
within
that,
but
I
I
definitely
think
that
there
is
and
and
actually
to
take,
take
it
another
way.
Get
ops
is
a
set
of
principles
to
things
to
implement.
If
you
feel
like
you're
90,
that's
certainly
better
than
being
50.
B
B
Ups,
police
won't
come
and
be
like
hey
that
thing
actually
isn't
there
now.
I
think
we
should
strive
for
it.
I
mean
we
put
these
principles
together
because
we
strive
for
them,
but
I
think
that
to
your
point
I
think
there
are
lots
of
ways
you
could
potentially
implement
approvals
in
a
very
get-ops-friendly
way.
There
are
some
less
get-ups-friendly
ways
you
could
implement
approvals
as
well
that
fair.
G
A
Okay,
I
think
that's
probably
all
the
time
we
have,
because
we're
going
to
need
to
give
the
room
to
the
next
people.
There
were
some
online
questions
that
didn't
get
answered,
and
so
will
you
do
you
mind,
jumping
in
the
chat
and
the
slack
okay,
I
saved
the
questions
I'll.
Let
you
know
what
they
are.
Can
we
give
our
panelists
the
big
round
of
applause
thanks.