►
From YouTube: GitOps Working Group - January 14, 2021
Description
Notes: https://docs.google.com/document/d/1hxifmCdOV5_FbKloDJRWZQHq0ge-trXJKF-BgV4wHVk/edit#heading=h.f3snsmsnuelu. See https://github.com/gitops-working-group/gitops-working-group for more info
A
Make
something
actually
a
git
ops
solution
or
part
of
a
git
op
solution,
and
so
those
principles
are
outlined
here
on
the
get
ops
working
group,
but
the
definition
is
going
to
lay
it
out
in
a
bit
more
detail.
So
this
is
something
that
we're
we're
working
on
now.
This
will
be
the
this
is
a
document
that
alexis
richardson
at
weaveworks
put
together.
He
was
the
the
person
who
actually
coined
the
term,
get
ops
back
in
2017
and
so
we'll
we'll
use
this
as
a
root.
A
A
So,
if,
if
you
do
want
to
be
want
to
track,
please
please
make
sure
to
check
back
on
the
document
or
add
in
your
your
contact
information
other
folks
in
on
the
maintainer
team.
Anyone
want
to
flesh
out
anything
that
I
just
said
around
the
definition
for
the
manifesto
before
we
open
it
up
to
the
floor.
A
B
A
So
so
that
is
that
that's
something
I
think
we
don't
need
to
lock
down
the
name
until
I
think
at
least
from
from
my
perspective,
the
definition
is
more
important
than
the
name,
but
that
is
a
that
is
a
fun
way
to
do
it
and
say
commitments,
because
it
does
assume
that
every
solution
that
says
it's
going
to
be
get
ops,
conformant
or
follow
the
the
principles
is
making
a
commitment.
So
that
might
be
one
option.
Certainly.
C
C
I
think
that
might
be
a
good
way
of
people
proposing
changes,
voting
up
changes,
voting
down
changes
on
a
github
pr
and
then
at
the
we
can
present
this
at
the
next
working
group
meeting
and
then,
if
we
have
a
consensus
at
the
next
working
group
meeting
around
what
we
have,
then
we
can
merge
that
pr
and
say
we've
kind
of
done.
The
first
work
stream
around
the
manifesto
or
the
commitments.
A
D
I'm
guessing
this
calls
purpose
is
not
to
kind
of
go
in
depth
into
the
various
questions
and
comments
and
whatnot
that
are
in
the
document.
Right,
like
the
idea
is
to
leave
that
offline,
or
do
we
want
to
go
into
more
in-depth
conversation
within
this
group.
As
to
some
of
the
concerns
or
questions
raised
in
the
current
version
of
this
document,.
A
We
have
about
10,
so
I
had
allocated
a
little
more
time
like
up
to
12
to
35
after
to
talk
about
this.
So
if
there
are
a
few
constructive
comments
and
suggestions,
I
think
we
can
certainly
discuss
it
as
a
group
we
are,
we
do
definitely
want
to
take
notes
and
make
sure
to
do
it
out
in
the
open,
but
since
the
folks
here
took
the
time
to
to
to
come,
I
I
think
you
know
discussion
can
be
warranted,
at
least
from
my
perspective,.
C
It's
probably
worth
going
over
any
high
level
comments
now,
but
keep
the
detailed
feedback
like
individual
wording
etc
for
an
offline
discussion.
So
we
don't
take
up
too
much
time
during
this
meeting,
but
I
think
I
I
don't
know
whether
I
speak
for
everybody
on
the
court,
but
I
think
I'd
love
to
hear
what
high
level
comments
people
have
about
this,
but
probably,
as
I
said,
we
don't
want
to
get
into
the
ways
of
the
details.
D
Okay,
well,
in
that
case,
there's
a
couple
of
things
that
I
commented
on.
The
definition
document
that
I
think
are
are
are
food
for
thought,
there's
kind
of
like.
I
think
the
the
concept
of
closed
loop
is
one
of
the
principles
that
require
further
thinking
right
when
we
think
about
in
terms
of
closed
loop
and
and
cornelia
had
spoken
at
some
point
of
the
the.
The
idea
is
that
the
code
in
the
repository
is
reflected
in
the
runtime
environment
right.
The
runtime
is
always
a
reflection
of
the
desired
state.
D
But
what
happens
if
the
desired
state
cannot
be
met
right
if
it
cannot
be
reached?
So
how
is
that
loop
going
to
close
back?
How
is
it
going
to
reflect
that
back
into
the
repository,
and
I,
whenever
I
think
about
that,
I
keep
struggling
with
the
idea
that,
for
instance,
you
may
have
one
single
source
of
truth:
one
single
repository,
one
single
manifest
that
is
being
synced
up
against
numerous
target
clusters
right.
So
how
would
it
work
if
just
one
of
those
clusters
fail
right?
D
A
C
Bruce
you
go
okay,
yeah,
so
I've
we've
actually
so
I
I've
I've
talked
about
this
in
the
past,
actually
about
kind
of
what
ought
to
happen.
If
the.
If
the
software
can't
close
the
loop
basically-
and
I
think
that's
really
a
failure-
condition
that
should
be
treated
as
such
and
we
can
certainly
try
to
converge
towards
desired
state
and
that's
what
you
know
the
ideal
case.
C
Is
it
doesn't
it's
a
transient
failure
and
you
eventually
convert
to
desired
state
which
we
know
is
going
to
happen
pretty
often,
but
the
case
where
you
really
count
and
after
retrying
multiple
times
you
still
can't
converge
feels
like
that
would
be
an
error
and
it's
essentially
where
the
the
software
involvement
in
resolution
stops
and
whether
human
involvement
begins,
because
if
a
failure
to
resolve
and
to
converge
state
keeps
occurring
essentially
there's
an
error
in
your
system
and
the
software
isn't
smart
enough
to
solve.
The
error.
C
C
C
A
F
I
I
I
want
to
add
on
that
that
the
feedback
is
part
that
is
not
talked
about
in
githubs,
and
we
are
talking
about
the
git
as
the
interface
and,
if
that's
the
interface,
we
must
have
some
way
to
get
feedback
back
to
it.
So
it's
right
that
you
can
check
the
logs,
you
can
view
kubernetes,
you
can
understand
what
happens,
but
that's
making
the
feedback
look
bigger
and
we
want
to
keep
it
small.
C
G
G
But
in
my
mind
actually
that
closed
loop
category
is
is
exactly
where
some
of
that
stuff
belongs.
Now
we
haven't
fully
defined
what
closed
loop
means,
but
in
my
mind,
that's
exactly
what
we're
getting
at
with
closed
loop
is
to
say:
okay,
we
and
you
know
when
we
think
about
ooda
loops.
So
we
think
about
these.
You
know
circular
things
all
the
time.
There's
always
the
you
know
act.
What
is
it
uda
is,
you
know,
observe
orient
act
and
so
that
it's
that
observed
part
and
so
I
feel
like
closed
loop.
G
G
What's
a
partial
loop
right
now
and
to
close
it
all
the
way,
and
this
dialogue
has
really
crystallized
that
in
my
mind,
and
so
I
would
assert
that
actually
the
closed
loop
is,
if
you
will
a
placeholder
for
some
of
the
concerns
leonardo
that
exactly
the
ones
that
you
teed
us
up
with
and
that
others
have
chimed
in
with,
and
that's
it,
maybe
the
the
abstraction
that
we
need
to
come
do
further.
Flushing
out
on
as
we
build
the
the
manifesto
or
the
I'm
scrolling
back
the
commitment
that
we
as
we
build
out.
D
H
H
A
A
A
All
right
so
moving
on
to
moving
on
to
the
website,
so
the
idea
is
and
and
where
the
discussions
have
come,
is
it's
great
to
have
a
github
repository,
and
it's
certainly
tremendous
for
the
technical
amongst
us
that
understands
how
it
works,
but
really
we
also
need
to
have
a
website,
that's
more
publicly
digestible,
and
so
we
were
thinking
that
something
lightweight
like
the
12
factor.
App
website
is
probably
you
know
the
appropriate
difference
between
something
lightweight
and
something
with
a
little
more
content
than
a
github
repo.
A
I
think
already
today
we
have
heard
that
you
know
that
maybe
it's
good
to
have
a
press
mention
section
and
and
certainly
for
those
of
us
that
need
to
make
a
living
selling
solutions.
It's
very
helpful
to
have
a
section.
That's
going
to
help.
Customers
understand
end
users,
understand
that
this
is
a
valid
way
to
operate
infrastructure
and
deploy
software,
and
so
that
could
certainly
be
one
component
of
a
website.
A
In
addition
to
what
we
see
on
like
the
12-factor
app,
I
saw
on
the
comments
from
from
mia
that
it'd
be
good
to
have
a
terminology
or
nomenclature
section.
Another
thing
that
I
think
is
super
important
just
because
when
we
get
seeped
into
an
area
we
toss
around
acronyms
like
it's
nobody's
business
and
frequently
those
acronyms
are
not
understandable
to
people
outside
a
community.
I
Ideas
that
were
kind
of
thrown
around
was
if
we
had
something
and
I'm
calling
it
patterns
for
now
and
patterns,
would
be
reference.
Architectures,
like
the
one.
The
engine
is
mentioning
and
it
would
be
like.
Oh
if
you're
doing,
if
you
want
to
do
a
pattern,
you
know
maybe
it's
with
aws
cloud
formation
templates.
I
You
know,
maybe
it's
not
a
kubernetes
thing,
then
you
could
have
this
directory
of
patterns
where
you
could
look
up
like.
Oh,
these
are
the
aws
patterns.
These
are
the
these
are
the
gcp
patterns,
and
I
think
this
could,
while
we
we
want
to
have
some
kind
of
high
level.
Very
generic
patterns
right
that
are
like
this
is
the
very
basic
high
level
one.
I
think
it
would
be
interesting
to
show
reference
architectures,
using
lots
of
different
tools
using
lots
of
different.
I
You
know
flavors
and
combinations,
and
people
could
essentially,
you
know,
submit
those
that
would
invite
a
lot
of
community
participation
where
people
would
be
like.
Oh
yeah.
I
want
to
show
the
pattern
that
uses
our
thing
that
our
customers
are
having
success
with
great.
You
know,
let's
submit
that
pattern
and
we
can
tag
it
with
the
different
technologies
and
people
can
kind
of
look
through
these
patterns
and
have
discussions
on
them.
They
do
pull
requests
on
them.
I
think
that
would
be
really
neat.
A
Yeah,
I
would,
I
would
add,
that
I
think
that
that's
like
super
useful,
especially
if
it
links
back
to
a
a
repo
where
you
can.
You
know,
fork
it
and
actually
create
your
own
reference
implementation,
because
I
think
that
that's
something
that
that
is
definitely
missing.
Is
it
and
helps
with
ease
of
use
right.
It's
kind
of
like
a
recipe
for
putting
together
the
particular
staff
stack
that
works
in
the
get
ops
fashion.
So
that's
a
that's
a
great
one.
Other.
D
D
D
What's
the
word
just
this
document,
where
they,
they
record
the
different
terminology
that
cd
tools
use,
so
they
have
like
jenkins
and
all
these
things
to
basically
get
aligned
as
to
what
the
common
terminologies
are
around
continuous
delivery
right.
I
actually
contributed
with
the
argo
city
terminology,
because
there
is,
you
know
the
concept,
the
concepts
of
pipelines
and
jobs
and
and
whatnot
do
no
longer
really
apply
necessarily
in
the
githubs
world
right,
so
that
type
of
translation.
D
Yeah
like
what,
how
do
you
do
a
pipeline
on
githubs?
You
know
where,
where
do
you
define
the
pipeline
in
flux?
Right
that
doesn't
apply
anymore?
There
is
a
matter
of
fact.
Is
that
that
link
that
kara
shared
is
precisely
the
one
I'm
talking
about
the
argo
cd
doc
section
is
the
one
that
I
added
and-
and
you
can
see
right
there
like,
if
you
go
all
the
way
down
where
there
is
kind
of
like
a
table
of
of
so
keep
going
like
scroll
all
the
way
down.
D
You
can
already
see
that,
for
example,
for
for
jenkins
and
and
the
spinnaker,
and
all
these
things
you
got
the
pipeline,
the
task
and
the
stage,
but
with
argo,
it's
really
different
right.
You
have
your
syncing
stuff,
so
it
doesn't
really
work
in
the
same
way,
and
I
think
this
this
helps
people
understand
the
mindset,
change
that
also
is
implied
by
doing
get
ups.
C
E
Hand
up,
I
think
you
have
something
to
add
to
this
yeah
big
benefit
to
having,
like
the
terminology
section.
Two
can
also
be
to
help
create
kind
of
like
logical
definitions
for
classes
of
projects,
so,
like
people
are
talking
about
kubernetes
a
lot
and
there's
obviously
a
lot
of
people
that
are
not
using
kubernetes
as
well,
and
you
know,
working
against
nomad
or
even
aws,
just
directly
having
that
kind
of
common
terminology
can
help
frame
newcomers
mentalities.
If
they're
bringing
new
platforms.
A
Right
yeah-
and
we
discussed
this
a
little
bit
on
the
initial
meeting.
The
git
ops-
and
this
applies
to
we
should
say
get
ops.
Is
the
terminology
that's
been
adopted,
but
you
could
certainly
implement
a
get
ops
fashion
workflow
using
not
get
right
using
svn
using
you
know
older
types
of
source
code
repositories
engine
you
have
your
hand
up
as
well.
J
J
So
I
hope
it
makes
sense
for
you
and
if
it's
too
high
level
we're
going
to
lose
the
people
because
they
think,
like
oh,
it's
something
for
the
elite
or
it's
something
for
for
not
for
me,
because
that's
what
I
hear
all
the
time
when
I
talk
with
our
projects,
they
are
like
yeah,
maybe
for
other
projects,
but
not
for
me
because
either
inside
now,
special
snowflake
or
we
are
different
and
no
no,
no,
our
customer.
So
in
our
case
thing
inside
the
company,
they
are
not
like
this.
J
I
Yeah,
something
we
actually
talked
about
was
how
this
implementation
shouldn't
be
a
hindrance
like,
oh
well,
we
can't
benefit
from
get
off
because
we
need
to
have
a
butt
and
it's
like.
Well,
you
can,
you
can
do
everything
else
and
have
a
button,
and
you
will
still
be
way
better
off
than
you
probably
were
before,
and
so
I
think
like
what
we
talked
about
is
that
conformance
and
that
kind
of
stuff.
It's
really
about
it's
almost
like
a
spectrum
of
of
stuff
that
you
grab
and
use,
and
it's
like
well
yeah.
I
This
is
the
ideal
work
towards
the
ideal
and
you
know
maybe
you'll
never
get
there.
Maybe
you'll
always
need
this,
that
or
the
other
thing
but
like
there
should
be
enough
in
the
standard
that
you
can
get
benefit
from
and
if
you
decide
to
modify
it
okay,
you
know
we're
not
gonna.
No,
no,
no
get
off
police
are
gonna,
show
up
and
tell
you
that
can't
do
that,
though,
we
should
discuss,
maybe
creating
some
sort
of
law
enforcement
division.
J
Fun
thing
is
people
understood
with
argos,
for
example,
they
understood
the
thing
better
because
it
was
visual.
When
I
tried
the
github's
toolkit,
for
example,
I
completely
lost
the
guys
they
didn't
know
at
all.
Maybe
you
can
blame
this
partly
on
me.
They
have
to
adapt
a
little
bit
more
for
the
kubernetes
way,
but
with
the
github's
toolkit
they
were
like
what's
going
on,
but
when
we
installed
argo,
for
example,
they
had
this.
We
call
this
like
like
a
baton,
you
can
walk
for
old
people
they're
like
yeah,
okay.
J
A
A
Yeah,
no
that's
an
excellent
point
and-
and
I
think,
a
best
practice,
especially
with
more
traditional
organizations
for
production
deployments
right
where
everything
works,
with
the
get
ops
fashion.
What
needs
to
be
merged
to
trigger
the
production
deployment
is
a
merge
of
the
pull
request
that
happens
in
git
right
and
then
then
you
you
continue
to
meet
some
of
these
git
ops
principles
and
at
the
end
and
everything's
automated,
but
you
also
keep
your
compliance
and
your
accountability.
So
great
point:
cornelia.
G
Yep,
I
just
wanted
to
interject
that
this
discussion
that
we
were
having
I
loved
engine,
the
the
the
anecdote
that
you
had
between
argo
cd
and
the
get
ops
toolkit
is
in
fact
I
was
gonna,
say
well.
What
we're
getting
at
here
is
observability
and
and
that's
absolutely.
The
button
is
also
an
element
of
control.
So
there's
that
nuance
that
we
were
talking
about,
but
then
there's
this
observability
people
could
see
what
was
going
on
now.
G
The
data
is
there
through
the
get
ops
toolkit
in
flux,
but
it
just
when
we
talk
about
observability,
it's
making
observability
consumable
by
by
folks
as
well.
So
I
just
wanted
to
call
it
call
out
the
fact
that
we
were
linking
back
to
the
earlier
discussion
around
closed
loop
and
observability
and
how
it
was
showing
up
in
this
very
concrete
case
that
you
were
talking
about.
A
A
You
know
the
use
cases
are
critical
right,
and
so
I
think
that
this
is
another
portion
of
the
or
not.
I
don't
think
we
think
that
the
this
is
another
portion
of
the
website
that
can
be
tremendously
useful
to
the
community
at
large
and
and
really
help
the
end.
Users
that
become
the
advocates
for
get
ops
within
the
organizations
drive
home
how
it
can
be
used
in
their
specific
organization.
E
No,
I
don't
know
so
it's
kind
of
interesting.
We
sit
a
little
on
the
edge
of
get
ops
where
at
least
like
my
company's
product
does
so
a
lot
of
what
we
use
get
ops
today
for
kind
of
more
on
the
consumer.
End
of
things
is
kind
of
deploying
and
managing
our
infrastructure
kind
of
like
our
infrastructure
tooling.
So
if
we
use
like
redash
or
like
any
of
these
third
parties
like
projects
like
we'll
use
githubs
to
do
a
lot
of
those
deployments,
our
dev
team
just
switched
over
to
scaffold
for
app
deployments.
E
They
had,
they
were
coming
from
more
of
an
different
workflow,
so
I
didn't
want
to.
I
don't
want
to
get
too
much
into
that,
but
we
pull
service
metadata
from
files
and
repositories,
so
we
actually
have
kind
of
a
similar
kind
of
git
ops
approach
where,
like
when
people
want
to
kind
of
track
services
within
their
ecosystem,
they
write
metadata
files
to
the
repo
and
then
we
crawl
repos
and
pull
them
all
up
into
our
ecosystem.
So
they
can
like
grab
metadata
about
like
where
their
runbooks
are
located
their
product
dashboards.
E
A
Interesting
cool,
thank
you
for
sharing.
So
that's
definitely
one
one
use
case
on
on
the
the
github
side
of
things
is
the
reaper
reconciliation
right
and
that's
the
most,
the
most
common
use
cases
for
operating
kubernetes
clusters,
and
especially
at
scale
other
interesting
use
cases
that
anyone
would
like
to
to
share
today.
D
What
some
of
the
challenges
are
around
very
much
air-gapped
environments
right
where,
where
basically,
you
need
to
deliver
your
full
getups
platform,
repo
inclusive
into
a
cluster
that
has
no
outside
connectivity
whatsoever,
so
that
that
has
been
really
interesting,
where
the
source
of
truth
lives
within
the
cluster
itself.
Right
you're,
basically
running
your
your
giddy
or
your
git
repo
within
the
cluster,
and
you
have
your
material
you're
using
we're
using
argo
syncing
against
that
one
repo
and
you
have
to
push
changes
in
a
very
controlled
fashion
into
that
in-cluster
repo.
D
So
there's
a
lot
of
challenges
there
as
to
how
to
even
bootstrap
that
cluster
when
there's
nothing
available.
The
other
interesting
challenge
has
been
around
progressive
delivery
of
very
much
mission.
Critical
network
functions
right.
They
have
all
these
different
patterns
where
you
might
have
some
container
running
that
you
just
can't
kill
because
it
might
be
handling
some
call
right
now.
You
know
so
it's
it.
It's
a
it's
been
a
really
interesting
set
of
problems
to
solve
the
multi-tenancy
of
it
as
well.
A
Yeah
and
that's
it's
surprisingly
common
from
that
from
that
use
case,
or
you
know,
delivery
to
air
gap
environments
via
usb
stick
right
where
you
gotta
bring
everything
in
in
one
and
there's.
There
are
very,
very
interesting
use
cases
around
that
and
multi-tenancy
is
something
that
I
think
is
a
hot
topic
across
across
get
offs
that
we've
we've
seen
all
right.
So
that's
you
know.
Air
gap
is,
is
fun
with
infrastructure
all
the
time
right,
whether
it's
for
a
cruise
ship
or
for
a
5g
deployment.
B
Yeah,
so
I'm
thinking
dr
right,
so
this
is
something
we're
looking
at
for
our
product.
Our
product
does
a
lot
of
get
off
c
type
stuff,
not
full
blown
yet
obviously
but
some
stuff,
but
what
I'm
thinking
of
in
our
oms
have
called
this
business
continuity.
So
not
talking
about
the
data,
but
if
something
should
go
wrong,
let's
say
I'm
hosting
this
in
a
region
and
the
region
becomes
unconnected
or
disconnected.
A
L
Yeah,
so
I
would
like
to
add
about
our
new
skins,
so
what
what
was
unique
about
our
ketopsy
use?
We've
been
trying
to
adjust
how
kitops
works
in
in
context
of
model
repository
and
deploying
to
multiple
clusters
from
one
one
repository
and
using
simple,
build
for
entire
mono
repository
again
and
being
able
to
untangle
different
deployment
streams
from
from
from
github's
perspective.
L
L
If
we
preserve
a
depotency
in
our
guitars
output
target,
we
could
actually
run
all
gitobs
targets
from
a
branch
in
parallel
and
normal
request
in
parallel
into
every
environment
and
when
sequence
of
merging
with
pull
request
is
going
to
be
actual
sequence
of
deployment
of
the
different
environments,
and
that
was
unique.
Not
a
lot
of
people
actually
understood
how.
A
All
right,
some
great
use
cases
there
and
and
some
that
come
up
all
the
time
right,
especially
when
you
start
to
scale
lots
and
lots
and
lots
of
clusters
pointing
at
a
single
repo.
So
all
things.
I
think
that
the
that
should
be
highlighted
on
the
website
and
then
maybe
when
we
go
back
to
demonstrating
solutions,
they
the
solutions
can
be
linked
back
or
the
reference
implementations
can
be
linked
back
to
the
to
the
actual
use
cases
for
which
ones
are
solved
by
which
solutions
or
solution
stacks
all
right.
This
is
terrific.
A
We
will
be
posting
the
the
meeting
minutes
and
the
recordings
if
you
have
any
associates
that
are
interested
in
the
discussion
today
up
on
the
the
github
repo
one
last.
One
thing
that
we
will
be
doing
is
putting
also
a
notice
for
creation
of
the
website
up
there
in
the
repo
so
do
sign
up
and
and
submit
issues
against
that
and
we'll
have
instructions
there.
A
I
H
H
I
All
right,
sweet
thanks,
everybody
that
was
awesome.
I
really
enjoyed
hearing
the
use
cases,
and
this
is
like
a
real
powerhouse
group
of
people,
so
the
the
big
challenge
is
now
that
we
are
starting
to
put
together
some
of
these
kind
of
work
streams.
I
think
there's
going
to
be
a
lot
more
opportunity
for
people
to
come
in
and
really
make
a
big
impact,
which
is
great
yeah.