►
Description
What's the best structure for a repository? Buckle up, because we’re about to take on a very controversial subject. GitOps repo directory structures! There are many things to consider when deciding on ways to set up your directory structures, and in this episode, we’ll go over general best practices. So tune in and join the argument over how to set up your GitOps directory structure!
Follow us:
Christian Hernandez https://twitter.com/christianh814
Chris Short https://twitter.com/ChrisShort
What is GitOps Guide to the Galaxy?
Every other Thursday at 3pm ET hosts Christian Hernandez and Chris Short sit down to discuss everything in the GitOps universe, from end-to-end CICD pipelines to creating Git workflows.
Subscribe to Red Hat's YouTube channel: https://www.youtube.com/redhat/?sub_confirmation=1
About OpenShift:
Red Hat OpenShift is an open source container application platform based on the Kubernetes container orchestrator for enterprise application development and deployment.
Openshift.com https://red.ht/33Fh6uV
OpenShift on github https://github.com/openshift/
OpenShift on redhat.com https://red.ht/2o4ccDk
#RedHat #GitOps #Kubernetes
A
A
A
B
B
A
B
B
To
me,
I
may
not
say
hi
back
because
well
I'll
say
a
generic
high
right
to
the
camera
because
we'll
be
it'll
be
a
hybrid
event,
as,
as
most
of
you
probably
already
know
so
so
yeah.
So
today's
as
I
was
preparing
for
today's
topic,
today's
topic
directory
structures
right.
It's
been
it's
kind
of
an
interesting,
a
topic
because
yeah
there's
it's
a
hotly
debated
topic
and
it's.
A
B
B
But
I
we
did
talk
about
a
little
bit,
and
so
I
figured
I'll
I'll
do
a
a
show,
a
stream
about
best
practices
right
so
not
necessarily
like
hey.
This
is
what
you
need
to
do,
but
more
like
hey,
there's,
a
suggestion
here
are
some
suggestions
and
some
of
the
things
to
look
out
for
because
again,
just
like
everything
else,
it's
an
answer.
You
absolutely
hate.
It
really
depends
on
what
you're
doing
everyone.
B
B
B
B
B
B
B
To
get
ups,
here's
a
pamphlet
to
help
you
out
right,
so
so
for
those
for
those
of
you
who
have
been
following
the
get
ops
working
group,
I'm
gonna
put
the
the
link
in
the
chat.
We
have
the
get
ops
principles.
You
know
the
beta
release
came
out.
We
have
a
release
candidate,
also
out
right.
Just
follow
that
link
open
getups.dev.
B
All
the
information
is
there
and
the
reason
I'm
dropping
you
that
in
is
because
the
one
of
the
getups
principles
is
you
have
a
single
source
of
truth
right
right.
So
so
you
know
much
like
everyone
else.
When
I
started
with
get
ops,
I
basically
was
like
all
right
cool
so,
like
I'm
gonna
dump
all
my
ammo
in
the
directory
and
like
and
then
I'll
sync
that,
with
my
repository.
B
Great
right,
profit
right
and
it
actually
does
work,
and
it
actually
is
pretty
simple,
but
much
like
everything
else
is
as
easy
to
get
started
difficult
to
master
sort
of
thing,
and
now
you
know
you
probably
ran
into
things
like
I
did
where
you're
running
into
issues
is
like
okay.
Well,
that's
probably
not
a
good
idea
right
so
like
how
do
I
deploy
this?
B
Yeah,
how
do
I
not
break
this
right
like
how
do
I
have
this
dump
of
yaml
in
a
directory,
and
how
do
I
apply
it
to
multiple
clusters?
And
how
do
I
apply
this
to
multiple
environments?
I
don't
apply
this
to
multiple
clusters
in
those
environments.
Right,
like
you
start
getting
into
this
like
okay,
well,.
B
Of
things
it's
like
okay,
well
having
a
directory
with
all
your
yaml
is
probably
not
a
good
idea,
and
you
started
running
to
these
things
like
okay.
Well,
how
do
I
you
know?
How
do
I
organize
my
directory
structure
right?
It's
like
all
right.
You
did
a
poc
right,
hey!
This
works
pretty
well!
It's
like
the
first
question
is
like
okay.
Well,
then,
how
do
I
that's
literally?
The
first
like
first
question
is
what
is
get
ops
and,
second,
all
right.
What
git
ups
controllers
are
there
and
third
is
like
okay,
this
works.
B
Well,
how
do
I,
how
do
I
configure
my
direct
structure?
It's
like
one
of
the
like
early
questions
right
and
a
lot
of
the
tools
built
around
get
ups.
You
know
they've
already
they
already
faced
these
similar
questions
right
and
and
they're
like
okay,
like
anyone,
starting
with
get
ups
automatically.
That's
like
the
first
thing
right
and
so
people
building
tools
around
it
have
kind
of
have
an
opinionated
approach
right.
So
I'm
gonna
go
over
some
of
the
tools,
it's
kind
of
like
hey.
B
Yeah
yeah
so
gerald
if
you're,
if
you're,
watching
that
yeah
you'll
you'll
see
this
here
pretty
soon
here.
So
there's
I'll
drop.
This
I'll
drop
this
blog
here.
So
I
have
there's
argo
city.
There's
argo
autopilot
right
and
argo
autopilot
is
in
the
argo
cd
project
right.
Sorry,
in
the
argo
project
right,
the
argo
project
has
argo
cd,
argo
workflows
and
this
one
here,
argo,
autopilot
and-
and
it's
basically
kind
of
like
a
as
the
graphic
suggests,
it's
a
hands-free
argo.
B
A
A
B
A
B
So
argo
autopilot
creates
those
directory
structures
for
you,
so
you
don't
have
to
like
you
just
it
creates
it
for
you
and
you
just
need
to
know
where
to
put
your
yaml.
That's
that's
one
thing:
red
hat
has
our
own.
We
have
something
we
spoke
about
before
and
I
swear
one
day
I'll
get
bose
to
come
on
and
talk
about
cam
cam's.
Another.
A
B
Yeah
exactly
and
basically
see
with
with
cam.
They
do
have
the
the
concept
of
environments
and
configurations
and
stuff
like
that.
So
this
is
kind
of
what
you
get
the
directory
structure
and
then
flux
cd
flux
doesn't
actually
have
a
directory
structure,
but
they
actually
have
a
pretty
good
article.
Flux
has
like
guidelines
like
what
to
do,
and
I
actually
read
this:
it's
actually
really
good.
I
actually
do
a
lot
of
this
and
I
think,
as
we
talk
about
later,
most
people
start
around
this
kind
of
path.
B
A
as
an
architect
here
at
red
hat-
and
you
know
he's
he
started
with
the
get
ops
thing
right
around
the
same
time
I
did,
and
he
actually
has.
He
actually
went
and
documented
the
crap
out
of
this.
So
he
has
directory
structure
and
he
has
you
know
you
know
what
level
it
is.
You
know
the
name
of
the
folder
and
like
what
what
it's
for,
and
he
actually
goes
down
into
the
weeds
here.
B
B
Looking
at
something
like
what
gerald
or
the
the
the
the
community
of
flux
has
done
that
they
actually
just
kind
of
say,
like
you
know,
here's
an
explanation
if
you're
kind
of
like
hey,
I
don't
really
care
just
give
me
a
directory
structure
that
I
can
work
with.
Something
like
argo,
autopilot
or
or
cam
could
be
something
that
that
you
can
use
so.
B
B
There
is
like
I
put
in
the
chat
and
like
we
have
in
the
presentation,
there's
loads
of
information
out
there.
If
you
really
really
want
someone
to
tell
you
what
to
do,
there's
there's
plenty
of
opinions.
There's
there's
lots
of
opinions
out
there,
100
opinions
so
grab
a
pencil
right.
I
imagine
this.
Is
you
right
looking
at
it
at
the
computer
screen,
grab
a
pencil
and
and
take
some
notes
right,
because
I'm
going
to
go
over
my
best
practices
and
some
of
the
best
practices
that
I've
read
out
there.
B
So
the
first
thing
is
dry
right,
just
like
with
coding
infrastructure
as
code
get
ups.
It's
all
the
same
thing.
We're
all
talking
about
code
and
we're
all
talking
about.
Don't
repeat
yourself
right
and
you
know
basically
is
avoid
duplicating
your
yaml.
So
you
know
like
how
do
I
essentially,
the
question
is
like
well:
how
do
I
deploy
all
this
yaml
across
multiple
clusters
without
copying
and
pasting
yaml
everywhere
right?
So
it's
it's
like
a
it's
a
trap
right.
It's
like.
B
So
it's
like
so
again
with
my
example.
Right
I
dumped
everything
in
one
one
yaml
right,
it's
like
well!
If
I
want
to
deploy
this
deployment
to
another
cluster,
and
I
just
want
to
change
the
the
scale
right
instead
of
replicas
one
replicas
equals
two.
Do
I
just
copy
that
directory
and
just
change
one
line
right?
It
seems
like
a
big
waste
right.
B
A
B
A
little
bit,
it's
been
there
for
a
while
right
and
what
customize
is
is
a
patching
framework
right.
So
you
it's
it's
essentially
it's
like
okay!
Well,
I
want
to
take
this
yaml
and
I
want
to
patch
it
right.
So
so
you
can
do
environment
specific
changes
by
using
the
same
same
yaml
right.
So
it's
not
a
templating
per
se
right,
although
you
can
use
it
like
templates
it.
Essentially
it
produces
raw
yaml.
B
So
the
idea
is
that
it
just
gives
you
raw
yaml
and
you
can
directly
apply
it
so,
and
the
basic
concepts
of
customize
is
that
you
have
a
series
of
bases
and
overlays
and
the
base
is
essentially
what's
common
amongst
all
clusters
right,
so
the
so.
If,
if
you,
if
you
think
about
it
right,
you're,
you
know
what's
coming
across
deployment,
the
differences
between
the
deployments
from
one
environment
to
another
can
be
it's
actually
very
minimal
right.
It
could
be
like
the
secrets
you
use.
B
The
image
you
use,
and
maybe
the
scale
but
like
the
rest
of
it
like
in
in
terms
of
like
a
skeleton,
is
essentially
the
same
right.
So
you
don't
you
know
you.
Don't
want
to
be
copying
all
that
just
to
change
a
few
things
right,
so
this
is
the
concept
of
an
overlay.
Essentially,
I
want
to
overlay
my
changes
on
top
of
the
base
configurations.
A
B
It's
just
yaml,
so
the
thing
about
customize
is
that
you,
just
you
just
use
raw
yaml
for
everything.
So
and
then
the
overlay
is
essentially
just
a
series
of
patches
against
that.
So
how
that
looks
like
is
here's
an
example
here.
So
you
have,
you
know
your
application
and
you
have
the
base.
So
you
have
things
like
service
route
deployment,
common
things.
B
Basic
kubernetes
objects
and
then
there's
a
special
file
here
called
customization,
which
basically
says
hey
when
customize
run,
read
these
resources
right
and
so
basically
it's
kind
of
saying:
read
these
resources
anytime,
someone
calls
customize
and
just
displays
blanky,
I'm
like
and
then
in
overlays,
essentially
you're
like
okay.
This
is
the
diff.
This
is
the
difference
right,
so
this
customizes
saying
all
right.
B
So,
as
my
base
use,
you
know,
go
up
to
directories
and
use
the
space
and
in
the
dev
environment,
I'm
going
to
change
my
route
and
then
I'll,
probably
in
a
different
name
space,
and
this
is
what
the
patches
are
here.
So,
like
you,
basically
patch
the
resource
and
the
patches
could
be
like
a
json
patch
json
patch
json.
Was
it
six
something
I
know
what's
that?
What's
that.
B
Yeah
6902
so
69.,
it's
just!
If
you
don't
know
what
what
that
is,
is
I'll
find
it's
just
yeah
common
kubernetes
patching
right
like
if
you're,
if
you're
doing
cube,
ctl
patching
you'll
you'll
fit
right
in
that
it's
not
it's,
there's
nothing
crazy
right
and
then
so.
Why
do
we
use
customize
right?
So
I
use
customize
for.
B
A
B
Create
a
hierarchy
right,
and
so
that
gives
you
kind
of
some
flexibility.
It
could
introduce
a
big
complexity
with
that
flexibility.
It's
kind
of
like
one
of
those
things
is
like
it's
really
really
flexible,
but,
like
you
can
really
it's
like
a
like
a
ball
of
twine
right,
like
you're,
trying
to
follow
things,
but
it's
kind
of
it's
one
of
those
things
like
to
an
outsider
like
if
you
don't
know,
customizers
you're
like
how
do
you
know
what
that
is,
but
someone
who's
been
using
customize
a
lot
you're
like
hey
yeah.
B
Oh,
I
know
that
goes
to
here
that
goes
to
there.
So
it's
one
of
those
things
like
you
really
have
to
do
it
a
few
times
it's
easy,
but
it's
it's
also
easy
to
mess
yourself
up
a
little
bit.
What
I
really
like
is
overlays
can
reference
remote
repositories
right?
So
here
you
know
going
back
to
the
using
customize,
I'm
like
referencing
like
the
base.
I
have
to
go
up
two
directories.
I
have
to
copy
that
directory
there,
but
you
can
actually
reference
remote
repositories.
B
So
here's
an
example
here
I
have
this
is
red
hat
community
of
practice.
Another
gerald
noon
special
where
he
had
the
what
we
call
the
get
ops
catalog.
Basically,
here
what
you
can
do
is
you
can
say
my
bases:
oh
hey!
My
base
actually
exists
on
that
git
repo
over
there.
So,
like
you,
don't
really
have
to
copy
the
yaml
right.
A
B
A
B
A
B
B
B
Well,
I'm
like
fine,
fine
I'll,
let
it
validate
right
and
what's
really
cool,
it's
agnostic
right,
just
customizes,
just
right
since
it's
raw
yaml,
it
works
with
argo
cd
with
flux,
with
acm
right
with
whatever,
whatever
tool
you
want
right,
and
so
you
know
you
keeping
your
repos
agnostic
gives
you
ultimate
flexibility.
So
that's
what
I
really
like
about
customize
you
can
use
it
with
pretty
much
any
tool
that
interfaces
with
kubernetes.
So
I
can't
talk
about
templating
and
patching
without
talking
about
helm,
right
helms,
another
helms
another
way
of
doing
things.
B
A
B
Helm
works
but
kind
of
like
review
kind
of
you
have
the
idea
of
a
chart
right,
which
is
a
template
and
your
values,
and
then
it
generates
your
yaml
based
on
those
right.
So
essentially
it's
a
a
templating
engine,
essentially
where
customized
patching
framework
is
a
templating
framework,
and
so,
if
you
know
kind
of
have
like
the
ideas
like
you
have,
you
know
your
template
and
then
you
pass
parameters
to
it
and
then
it
just
produces
a
yaml
file
right.
So
who.
B
Yeah
yeah
yeah
words,
words
are
hard
right
yeah,
so
you
have
you
know
again,
like
I
said
you
know
you
just
private
parameters
and
it'll
can
do
that
as
well.
Some
things
to
look
out
for
right
when
using
either
helm
or
customize
right.
So
I
have
a
blog
there's
two
ways
to
use
helm
so
I'll
put
that
blog
in
the
chat
yeah.
B
I
wrote
a
blog
about
helm
and
argo
cd,
so
there's
two
ways
to
use
argo
cd
and
both
of
them
are
right,
and
but
just
one
of
them
isn't
get
ops
friendly.
So
if
you,
if
you're,
if
you're
doing
if
you're
doing
get
ops-
and
you
want
to
do
things
to
get
ops
away,
there's
a
specific
way
to
use
that
in
inargo
city.
So
it's
just
kind
of
like
things
to
look
out
for
right
because
remember
get
ups
is
declarative,
so
doing
things
imperatively
then
use
the.
B
Then
you,
then
you
have
a
different
source
of
truth
right.
So
then
you
think
you
break
the
the
principle
of
get
off,
so
you
have
a
single
source
of
truth.
So
the
thing
you
have
two
instead
of
one
so
so
remember.
If
you're
going
down
the
path
of
helm,
which
is
fine,
I
use
helm
a
lot.
I
love
helm.
I
have
a
shirt,
I
wear
it.
B
Sometimes
I
love
them,
but
just
just
remember,
there's
there's,
there's
a
there's
a
way
to
use
it
that
he
that
keeps
it
get
off
friendly
so
and
to
keep
it
as
a
single
source
of
truth
right
with
customize.
There's
gonna
be
a
lot
of
customization.yaml
files.
So
I
worked
with
a
with
a
customer
of
ours
and
they're.
Like
man
there's
you
know
the
customization.yml
files
like
yeah.
B
B
They're,
like
they're
like
red
droppings
right
so
like
you'll,
have
a
situation
where
you
have
a
folder
that
just
has
one
customization.yaml
file
and
it
references
like
eight
things,
and
you
know
it
like
I
said
before
you
know
you
can
mess
yourself
up
a
little
bit
so
just
look
out
for
there
could
be
a
lot
of
customization.yaml
files.
Also
there's
not
a
either
or
right.
You
don't
have
to
use
customized
or
helm.
You
can
use
both
of
them
in
conjunction
right
and
most
tools
are
flexible
with
that.
B
B
I
have
a
known
good
values.yaml
file.
I
just
use
the
home
chart,
so
let
that
and
last
point
right,
the
very
very
at
the
bottom,
using
customize
will
dictate
your
get
ops,
repo
structure.
So
if
you
remember
right
here
right
so
like
if
this
is
customized,
if
you're
using
customize
to
not
repeat
yourself,
that's
gonna
dictate
a
lot
of
what
you
write
into
your
into
your
git
ops,
repo.
B
So
so
that's
just
kind
of
like
one
one
thing
to
kind
of
look
out
for
right,
and
maybe
if
we
have
time
I'll,
show
you
kind
of
like
this
little
project,
I'm
working
on
to
kind
of
show
you
the
directory
structure
that
I've
been
coming
up
with
heavily
customized
influence
as
you'll
see
but
but
yeah.
So
that's
kind
of
like
the
point
there,
if
you're
using
customize.
B
If
you
start
the
path
down,
customize
you're
like
you're
like
halfway
there,
I
think
right
so
you're,
okay
in
your
directory
structure,
let's
say
okay!
Well,
at
least
I
know
how
to
you
know
not
duplicate
yaml
and
like
create
environments
for
myself,
and
you
know
all
that's
really.
I
just
saw
that
comment.
That's
that's
all
really
good.
Artisanal
yamo
goes
well
with
avocado
toast.
Yes,
it
does
by
the
way
in
l.a,
I'm
in
l.a
right
we're
like
the
whole.
B
Yes,
exactly
exactly
now,
if
you're
on
the
north,
so
so
cool,
so
you
know
that's
kind
of
like
one
of
the
best
practices
here.
Okay,
so
now
you
kind
of
figured
out
the
repost
structure,
but
so
like
now
what
right
so
like?
What's
what's
where
I
go
from
there
right
now
that
I'm
using
customize,
you
know
I
kind
of
have
an
idea
of
how
to
you
know.
B
Customize
makes
me
use
a
particular
structure,
so
I'm
already
kind
of
halfway
there.
Where
do
I
go
now
right?
So
it's
not
all
unicorns
and
rainbows
right
once
you
start
using
customize,
as
as
some
of
you
have
might
known
here,
gerald
if
you,
if
you're
watching
this,
I'm
sure
as
some
gerald,
and
I
have
discovered
about
structures
right
so
so
there's
different
ways
all
right.
So
now
that
I
have
a
structure
like
what
do
I
do
with
my
repos
right?
B
Do
I
have
like
a
mod
what
we
call
mono
repo?
Do
I
have
a
single
repository
with
everything
in
there
right
like,
like
my
whole,
just
dump
everything
in
a
single
repository.
Do
I
have
separate
repos
for
environments
to
have
a
repos
specific
for
clusters
like
like
now
the
question
becomes.
Do
I
do
monorevo?
Do
I
do
poly
repo?
Do
I
do
a
hybrid
of
the
two
so
just
kind
of
some
of
the
things
to
keep
in
mind?
Originally
argo
cd,
I
mean,
I
guess,
even
still
today
they
realized.
B
B
Well,
what's
funny
is
william
who's
actually
on
the
chat
right
now,
one
once
once
showed
me.
He
goes
here,
take
a
look
at
this
video
and
he-
and
he
showed
me
the
repo
and
like
the
first
five
minutes,
was
him
scrolling
and
like
I'm
like,
and
I
went
back
to
chat,
I'm
like
hey
the
first
five
minutes
is
just
you
scrolling,
the
eagles.
Actually,
the
whole
video
is
just
me
scrolling.
This
is
how
long
it
is
how
big
the
repo
is
so
yeah.
So
to
do
so.
B
This
is
a
good
question
from
from
william
here
to
decide
between
monorepo
versus
polyrepo.
Should
it
start
with
the
operations
team.
What
the
operation
team
looks
like
is
it
distributed?
Is
it
one
team
these
other
questions
so
like
these
are
some
of
the
questions
that
and
that's
kind
of
like
one
of
one
of
the
bullet
points
is
here.
The
way
your
organization
is
laid
out
is
going
to
come
into
play
and
will
kind
of
dictate
a
lot
of
this
for
you
right.
So
you
kind
of
have
to
ask
these
questions
right.
B
You
have
to
say,
okay,
you
know
what
does
my
operations
team?
Look
like:
where
are
those
demarcations
right?
What
is
operations
team,
sre
teams,
development
team?
What
are
those
teams
look
like
and
where
are
those
responsibilities
marked
in
so
gotta?
Ask
those
questions
to
kind
of
come
to
a
conclusion
of
whether
you're
doing
a
monorepo
or
separate
repo
polyrepo
and
then
so
again,
multiple
repositories,
you
kind
of
get
into
the
the
idea
of
having
a.
B
I
wouldn't
do
it
this
way,
but
I
think
this
illustrates
this
point
is
that
you
have
a
repo
like
per
environment
for,
for
instance,
or
a
repo
like
if
you're
using
micro
services
right.
Maybe
you
have
a
repo
per
service,
not
necessarily
one
repo
with
all
services
in
it
right.
Maybe
you
have
a
repo
with
all
that
that's
kind
of
one
way
to
do
it,
that's
kind
of
the
way
I
do
it.
I
actually
see
things
the
way.
The
question
that
I
ask
is
that
is
the
cluster
I'm
on.
B
Yeah,
how
many
teams
right
like
so
like,
if
I'm,
if
I'm
an
admin,
maybe
I'll
control
the
cluster
in
my
repo,
but
then
I'll
have
a
multi-tenant
system
where
it's
like?
Okay,
you
know
these
developers
have
their
own
instance
of
argo
cd
that
then
they
you
know,
deploy
their
application
using
a
specific
namespace.
A
B
Exactly
100,
so
this
is
kind
of
like
what
the
multiple
repositories
come
into
play
and
how
your
organization
is
laid
out.
You
can
also
go
full
devops
is
what
I
like
to
call
full
full
devops
right
and
have
a
single
repository
and
and
like
single
repository,
meaning
like
all
right
like
I
have
a
one-to-one
relationship
between
a
repository
and
a
cluster,
and
so
I
have
my
whole
definition
of
a
cluster
in
a
git
repo
and
that
just
might
be
devops
style
right.
B
Just
one
big
repository
for
a
cluster
and
changes
and
all
that
go
into
one
get
ops
work
get
workflow
for
your
get
ups
environment,
so
so
yeah.
So
you
have
this
single
repository,
which
is
fine
right
and
remember.
I
I'll
put
this
in
the
in
the
in
the
chat
if
you're
using
argo
cd.
Just
remember,
there
is
scaling
considerations
if
you're
gonna
do
a
mono
repo
right.
So
if
you
guys
again,
if
you
haven't
seen
past
episodes,
the
intuit
guys
came
in
the
guys
who
actually
wrote.
B
Argo
city
and
they've
actually
said
like
hey
yeah
like
we
know
this
issues
here
and
you
know
we're
working
on
it.
So
they
they
they
already
know
right
so,
but
just
something
to
keep
in
mind
see
here.
I
only
have
a
few
slides
left
here.
Let's
talk
about
questions
to
ask
yourself
right,
and
I
didn't
realize
this.
I
thought.
B
A
B
Some
of
the
questions
here
is
about
so
some
of
the
tips
so
utilize,
customize
and
utilize
to
refer
to
other
git
repos
right.
So
if
you're
not
doing
a
mono
repo,
if
you're
doing
poly
repo,
you
can
aggregate
a
lot
of
those
repositories
in
a
single
repository,
so
you
can
do
something
like
hey
for
this
deployment.
I'm
taking
these
get
re,
get
ops,
repos
and
you
know
making
one
and
I'm
deploying
that
to
a
cluster.
You
can
do
something
like
that,
make
sure
it's
easily
repeatable.
B
I
have
a
cool
workflow,
it's
like
hey.
I
have
another
cluster.
I
just
copy
my
overlay
to
another
name,
change,
one
or
two
things,
and
then
off
I
go
so
so
make
sure
you're
you're
it's
easily
repeatable
right,
and
then
I
didn't
say
this
before
it's
one
of
the
first
things
I
always
say
when
people
starting
off
in
this
journey
keep
your
application.
Repo
separate.
Keep
your
code,
repo,
separate
from
your
deployment,
rebound.
A
B
B
Yeah
yeah,
so
there's
there's
a
they're
just
different
life
cycles.
It's
just
not
you
know,
that's
just
it
just
makes
your
life
easier.
So
things
to
ask
yourself
right.
I
think
one
of
the
questions,
one
of
the
things
william
says:
do
you
want
job
security?
Is
one
of
the
questions?
Do
you
want
job
security
get
get
into
get
ops,
so
I
thought
that
was
funny.
B
So
you
know,
do
you
have
an
environment,
specific
configuration
or
do
you
have
a
cluster
specific
configuration?
You
have
a
mixture
of
both
me
and
gerald.
We
were
butting
heads
for
a
long
time.
I
for
the
longest
for
the
longest
time,
have
the
opinion
that
you
have
cluster
specific
consideration
configurations
or
you
have
environment,
but
you
never
have
both,
because
one
is
a
subset
of
another
right.
B
So
you
know,
if
you
have
two
clusters
in
a
dev
environment
and
one
of
them
slightly
different
welding,
you
actually
have
a
cluster
specific
configuration
and
not
a
environment,
specific
consider
configuration,
but
there
is
so,
after
speaking
to
a
lot
of
customers
and
after
you
know,
going
over
a
lot
of
use
cases
going
on
this
get
ops
journey
right,
we're
going
to
the
galaxy
right.
There
are
some
some
instances
where
you're
going
to
mix
both
where
it's
and
my
I
guess
my
last
tip
or
last
thing.
A
B
So
so,
william,
very
good
point
in
in
when,
when
gerald
noon
watches
this
later
he's
gonna
he's
gonna
chat
me
he
goes,
I
would
argue,
it's
is
you
have
three?
You
have
cluster
environment
and
team
right
and
gerald?
Actually.
So
if
you,
if
you
look
at
gerald's
repo,
he
actually
has
a
concept
of
tenants
right
and
that's
what
a
team
is
right.
So,
like
a
team
within
a
so
you
actually
do
have
like
three.
So
there
is
so
I
actually
acquiesce.
B
B
Yeah
seems
to
be
working
okay
for
me,
so
another
way
to
approach
this,
and
this
is
something
that
I
kind
of
did
with
one
of
the
customers
I
was
working
with.
Is
that
you
kind
of
have
a
fan
out
or
a
cascada
approach
right
so
for
you,
engineers
fan
out
right
or
case
cascade
same
same
idea
right
the
you
have
a
there
is
such
a
thing
as
especially,
if
you're
working
with
your
security
teams,
which
you
should
be
working
with
security
teams,
a
lot,
especially
with
literally.
B
A
B
He
and
he
kind
of
says
if
you
look
at
his
repo,
he
kind
of
mentions
it
as
well.
When
I
think
of
tenants,
I
think,
of
name
spaces,
so
I
actually
say
teams
right
instead
of
cluster
environment
team,
so
kind
of
like
what
william
put
in
the
chat,
that's
kind
of
what
you
mean
when
he
says
tenant.
He
actually
means
teams.
So
so,
yes,
so.
B
B
B
Yeah,
the
only
one
way
to
get
ups
is
cat,
so
so
you
have
a
so
like
if
your
security
team
or
operations
team,
you're
gonna,
have
a
base
configuration
right
so
no
matter,
especially
in
an
organization,
no
matter
what
cluster
I
install.
It's
gonna
have
to
have
these
basic
sets
of
cluster
configuration
right
and,
like
I
mentioned
before,
in
the
other,
you
can
reference
other
repos
from
customize.
B
Then
you
can
branch
out
to
say.
Okay
and
now
I
have
a
dev
stage
of
production
right
within
that
dev.
I
have
yet
another
repo
of
cluster
one
cluster,
two
cluster
three
ad
nauseam
and
then
that
eventually
makes
it
onto
a
cluster
right
and
the
same
for
stage
and
prod
right
where
it
fans
out
in
this
particular
way.
I
so
you're
talking
about
you
know
three,
four,
five
repo's
deep.
B
So
if
you
have
a
change
that
needs
to
go
to
this
one
particular
cluster,
you
just
change
this
repo
and
you
know
it
makes
it
in
there.
If
you
are,
if
there's
a
security
patch
that
needs
to
happen,
you
can
do
it
in
this
repo
right,
the
the
base
configuration
repo
and
then
it
just
basically
cascades
out
to
all
the
other
ones
same
for
the
environment.
You,
you
kind
of
get
the
idea
here
so
so
here
the
question
good
question
here.
B
So
basically,
is
it
better
to
have
different
repos
on
an
application
level
or
an
environment
level
like
pod
and
or
like
prod
and
dev?
So
you
have
different
yeah
great
question
right.
So
this
is
another
one
of
those
one
of
those
things
where
it's
again
it
depends
right.
So
I
think
the
application
level
would
be
like
in
the
environment
layer.
I
would,
I
would
say
I
agree
with
that.
B
That's
where
I
think
I
think
most
of
that,
where
that
stuff
would
go
so
and
then
someone
said
again,
the
follow-up
question
was
what's
the
meaning
of
cluster
repo,
so
cluster
repo
is
the
repository
where
your
cluster-specific
configurations
go
so
for
things
like
like
security
policies,
would
go
in
a
cluster
repo
or
things
like
you
know,
connecting
to
an
identity
provider
right.
Your
login
information
would
go
into
that
repo,
so
I
like
the
the
com
I'm
holding
for
dev
third
ops
right,
so
it's
wait.
A
B
B
B
Get
that
power
under
you,
because
that's
going
to
dictate
a
lot.
Ask
yourself
questions
like
you
know,
you
know
what
does
my
environment
look
like?
What
does
my
organization
look
like
who's
controlling
what
that
will
then
be
on
customize,
then
we'll
tell
you
what
what
kind
of
repos
are
you
going
to
be
using?
So
so
one
of
the
to
be
solved
issues
is
one
of
the
things
that
coming
out
from
william
here,
one
of
the
to
be
solved
issues
we
have
in
telco.
B
If
I
update
the
base
on
a
on
a
cascade
or
layered
setup
how
to
prevent
immediate
remediation
to
make
sure
remediation
happens
on
authorized
maintenance
windows,
but
that's
well,
that's
all,
but
also
that's
an
old
versus
new
mentality,
correct
right,
so
you
you
never
commit
so
the
the
so
there's
there's
kind
of
multiple
layers.
Here
you
never
commit
to
something
that
you
don't
want
live
right
away.
So
right
just
you
know
like
if
it
you
know
think
think
again.
A
B
Cronjob
format:
it's
like
hey
only
sync
this
at
this
time
or
during
this
windows
right
like
sundays,
at
8pm
or
whatever,
so
you
can
do
that
as
as
as
well
right,
so
you
have
a
sync
window
to
set
up
on
argo
cd.
So
that's
another
way
of
doing
it.
But
again,
I
kind
of
I
kind
of
agree
with
with
william
here
it's
kind
of
like
the
old
hat
versus
new
hat
mentality.
It's
just
like!
B
Well,
you
know,
if,
if
you
kind
of
have
to
change
switch
the
mentalities
like,
if,
if
I
don't
want
it
in
production
right
now,
then
don't
merge
it,
because
that
branch,
you're
tracking,
is
your
source
of
truth
right.
Think
of
it
as
a
database
of
the
live
or
what's
what's
going
on
right
now,
so
so
yeah
so
so.
A
A
B
Yeah
yeah
now
we're
doing
both
right
so
like
if
you're
doing
where's
that
oh
wait.
It
was
in
my
my
slide
right
here.
So
that's
on
the
application
level
right,
so
you
can
have
it
pretty
much
on
any
level
of
where
you
want
it
right
so
on
the
right
on
the
cluster
first.
So
essentially,
it's
like
hey
for
this
application.
You
know,
sync
it
saturday
at
midnight
or
whatever.
Oh.
A
B
B
B
B
B
A
B
B
A
B
B
B
B
B
A
A
B
B
On
the
seventh-
and
I
think
that's
when
oh
okay
cool
so
next
show
so
october,
7th
right,
so
it's
the
show
right
before
q.
Con
we'll
have
michael
foster
on
so
michael
foster
is
the
tmm
for
acs.
So
for
those
of
you
who
are
using,
who
are
using
stack,
rocks
or
now
that
you
guys
are
using,
you
know
red
hat
customers.
B
Security,
advanced
cluster
security,
so
we'll
be
talking
about
the
the
application
delivery
pipeline
right,
so
it's
kind
of
like
that,
the
the
idea
of
building
security
into
your
delivery
system.
So
that's
kind
of
I
like
talking
about
some
of
these
things
that
are
kind
of
like
acm.
The
cluster
management,
where,
like
git
ops,
is
kind
of
like
the
core
of
something
bigger
acs
is
kind
of
like
the
same
same
idea.
He'll
be
on
talk
about
that,
so
that'd
be
a
good
show
yeah.
So
how
do
I
stop
sharing.