►
From YouTube: Argo CD and Rollouts Community Meeting Jun 2023
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Cool
looks
like
most
folks
who
are
going
to
be
here.
Are
here
so,
let's
get
started.
Welcome
everyone
to
the
Argo
CD
rollouts
community
meeting.
We've
got
a
couple
of
topics
today,
so
we'll
Dive
Right
In.
Let
me
make
sure
I've
got
a
recording
started
and
looks
like
I
do
cool
Alexander?
Are
you
ready
to
present.
A
Thanks
see,
I
saw
you
on
the
attendee
list,
but
I
don't
see
an
Alexander
in
the
the
list
of
participants,
that's
fine,
they
might
show
up
later.
We
can
go
ahead
and
jump
to
mine
and
ashitosh's
presentation.
Let
me
share
my
other
screen.
A
And
I'll
go
ahead
and
say
we're
we're
presenting
a
feature
that
we
didn't
write.
We
just
helped
validate
it
as
part
of
an
Intuit
internal
sort
of
hackathon.
A
Can
y'all
confirm
you
can
still
see
it.
I
just
went
when
I
went
full
screen.
Yes,
that's
good
sweet!
Thank
you.
So
we
used
a
new
feature
which
would
be
in
Argo
CD
2.8,
called
application
set
plug-in
generator
to
enable
declarative,
Argo
rollouts
configuration
and
deployment
at
Intuit.
A
So
this
was
primarily
worked
on
by
myself
in
ashitosh.
A
couple
other
folks
helped
us
test
and
validate
it
internally
and
work
on
docs.
So
thanks
to
our
modern
theater
for
that
help,
so
the
goal
is
simply
install
the
Argo
rollouts
controller
on
Olive
into
its
clusters,
and
we
have
approaching
300
clusters
and
sort
of
our
own
internal
system
to
manage
all
of
those
and
keep
track
of
what
clusters
we
have
and
attributes
around
them.
A
A
It
has
an
API
that
we
develop
and
maintain
internally
and
we
have
a
Jenkins
job
that
every
day
calls
that
API
and
says
what
are
the
Clusters
that
are
available,
and
you
know
what
some
metadata
about
them
based
on
the
response.
Jenkins
creates
directories
in
a
git
repository
where
we
deploy
a
lot
of
our
Argo
stuff
from,
and
each
of
those
directories
is
populated
with
a
config
file
in
Json
format.
A
So
the
application
portion
is
new-ish.
We
also
have
a
legacy
process
that
we
used
that
just
deployed
a
static
application
directly
to
the
cluster.
So
we
have
about
160
auto-generated
applications
and
about
a
hundred
that
just
live
on
the
cluster.
They
aren't
even
via
git
Ops.
They
just
the
the
cluster
where
we
host
Argo
CD
is
their
only
source
of
Truth.
A
B
Okay,
yeah
thanks
Michael,
so
yeah
with
the
old
architecture.
We
were
facing
few
issues
like
issues
like
when
the
new
cluster
was
on
boarded
and
customers
want
to
use
rollout.
They
have
to
wait
for
24
hours,
so
we
used
a
picture
which
was
contributed
by
Max
and
Sebastian
and
it's
an
awesome
feature.
So
what
we
did?
B
We
we
build
a
plug-in
and
which
application
set
can
directly
then
talk
to
the
iksm
external
data
source,
and
then
it
would
get
the
same
trick:
data
from
iksm
and
then
it
will
Loop
over
and
generate
the
rollout
on
the
target
cluster
Michael.
Can
you
go
to
next
slide?
Yeah.
B
Yeah,
so
this
is
the
plugin
generator.
So
now,
with
the
plugin
generator,
you
can
bring
your
own
plugins
and
you
can
write
it
in
any
language.
This
is
it
supports
our
piece,
RPC
or
HTTP
request.
It
can
leave
it
as
a
sidecar
or
it
can
be
Standalone
deployment.
In
our
case,
we
we
did
a
standalone
deployment,
it's
a
rest
service,
running
from
where
we
fetch
the
cluster
data
and
yeah
you.
You
don't
need
to
wait
for
for
your
PR
to
get
reviewed,
so
you
can
write
your
own
plugins
you.
B
B
So
this
is
the
application
set
plug-in
config.
So
if
you
see
there's
a
plug-in
generator
in
our
case
it
calls
my
plugin
and
then
config
map.
So
we
have
all
the
like
the
data
in
our
config
map,
the
endpoint
of
the
API,
so
it
would
in
our
key,
is
application
set
plugin,
iksm
and
then
the
token
so,
where
application
set
connects
to
the
endpoint,
it
requires
the
token
to
authenticate.
B
So
the
token
would
live
in
in
the
in
the
Argo
CD
cluster
and
it
will
make
a
API
call
and
get
the
cluster
information,
and
then
it
would
iterate
through
all
the
information
which
it
gets
from
the
plugin
and
then
and
generate
the
rollout
on
the
target
cluster
Michael.
Can
you
go
to
the
next
slide?
Thank
you.
B
So
what
is
the
advantage
of
new
solution?
So,
first
of
all
like
we,
we
saw
a
benefit.
Is
our
speed
has
increased
when
the
new
cluster
is
onboarded
and
as
Intuit
is
growing,
we
are
onboarding
a
new
cluster
very,
very
often
so
now,
instead
of
waiting
users
to
wait
for
entire
24
hour,
they
can
they
can
have
the
Argo
rollout
installed
in.
In
less
than
two
hours,
so
again
that
can
be
configurable.
For
now
we
just
set
up
as
to
our
maintenance.
B
Again
there
is
no
manually
created
apps,
it
would
be.
The
group
application
set
security
was
one
primary
thing:
Jenkin
was
pushing
some
bunch
of
config
files
to
the
deployment
repo
which
we
didn't
like
that
repo
is,
is
pretty
sensitive
and
as
application
set
get
adopted
by
other
teams,
we
don't
want
the
this
deployment
triple
to
be
like
so
between
the
files
could
get
pushed
to
this
hurry
post
again.
We
we
wanted
to
validate
the
application.
B
Set
Michael
did
an
awesome
job
in
reviewing
that
feature
and
I
I
think
we
got
it
much
so
yeah
I
guess
just
pretty
much
any
questions.
Probably
you
can
answer.
A
I
think
that's
the
last
slide.
I
do
see
a
hand
up
Christian.
C
Yeah,
so
does
this
potentially
remove
the
need
to
like
add
generators
in
the
future
so
like
the
idea
being
is
like
if
you
need
a
specific
generator
just
like
write
one
using
the
plugin
method
versus
you
know,
spending
the
time
to
try
to
write
it
in
tree.
A
Yeah,
it
does
which
I
think
will
be
a
huge
win,
because
a
lot
of
folks
want
to
add
support
for
different
scms.
So
with
Argo
CD
core,
like
all
we
really
have
to
support,
is
git
and
everyone
implements
something
that
is
get
compliant,
but
with
scms
they
have
all
kinds
of
different
apis
like
they
have
different
meanings
of
PRS
labels,
tags
Etc
and
that's
all
knowledge
that
the
core
Dev
team
either
needs
to
learn
or
just
trust
and
smash.
A
Cool,
so
this
feature
will
be
available
in
2.8
if
you
have
questions
or
excited
about
a
particular
use
case,
for
it
definitely
reach
out
to
me
or
to
us
we'd
love
to
hear
about
them.
So
with
that
I'll
turn
it
over
to
Alexander.
D
Hello:
everyone
thanks
for
joining
that
meeting.
Of
course,
it's
only
the
second
time
I
joined
one
of
these
meetings.
First
time
as
a
speaker,
I'm
going
to
talk
about
structuring
directories
in
negative
repository,
I
wrote
a
blog
post
where
I
summarized
ideas
from
the
community
and
sort
of
combine
them
into
into
one
and
I
wanted
to
share
with
with
you
to
get
feedback
and
essentially
help
propagate
these
ideas
among
the
community.
So
let
me
share.
D
Okay,
let's
let
me
just
ask:
do
you
see
the
slide?
Can
you
confirm?
Okay,
thanks
great,
so
just
briefly
about
me,
Alexander
Kozinski
I've
held
systems,
engineering
role
since
2007,
currently
contractor,
but
representing
my
own
views
here,
not
any
of
the
clients
now
this
is.
This
is
an
idea
ahead.
D
If
you
I'm,
really
curious
where
people
are
from
I
was
going
to
do
that
for
myself
as
well,
so
in
in
the
chat
when
you
zoom
name,
if
you
could,
let
me
know:
I'd
be
they're,
really
great,
all
right
so
agenda,
I'm
gonna
talk
a
little
bit
about
the
sale
of
the
art,
so
I've
been
doing
some
research
on
what
people
recommend
when
it
comes
to
the
directory
structure,
how
you
essentially,
how
you,
where
do
you
put
the
files
in
your
GitHub
repository
and
I'm,
trying
to
combine
it
together
and
the
blog
post
is
here?
D
If
you
want
to
see
it,
I
will
post
it
maybe
later
on
in
the
chat
as
well.
This
is
a
short
URL
to
the
blog
post,
so
here's
the
center
of
the
art,
so
there
are
various
Alters-
have
proposed
different
directory
structures,
but
there's
no
established
standard
and
the
current
approach
seems
to
be
that
different
organizations
create
their
own
structures
depending
on
their
needs.
D
But
I
see
a
bit
of
a
problem
with
that,
because
users,
especially
when
they
join
a
new
organization,
they
need
to
learn
the
github's
directory
structure
at
their
organization
and
I'm
thinking
that
it
would
benefit
the
community
if
there
was
a
standard
that
was,
let's
say,
abstract
enough
and
powerful
enough
to
encapsulate
the
various
use
cases.
The
various
needs
that
different
organizations
have-
and
this
is
the
sort
of
attempt
that
I
made
at
this
based
on
the
various
ideas
that
people
suggested.
D
If
it's
not
powerful
enough,
then
of
course
it
needs
to
be
changed.
So
this
is
why
I'm
looking
for
feedback,
but
this
is
basically
the
problem
statement
here.
D
I
think
such
a
such
a
structure,
standard
structure
would
be
something
useful
for
the
community,
so
I'm
first
going
to
talk
about
the
approach
by
Costas
capilonis,
and
this
is
the
the
structure
that
he
described
in
his
article.
So,
first
of
all
that
the
recommendation
is
not
to
use
branches
to
store
information
about
different
environments.
D
This
seems
to
be
the
standard
at
in
the
community,
because
this
makes
it
makes
a
case
in
his
blog
article
about
it.
So
if
you
want
to
read
the
full
argument,
if
you're
not
familiar
with
it,
then
you
can
find
it
there,
but
the
it
boils
down
to
saying
that
promoting
from
one
environment
to
another
is
not
just
as
simple
as
merging
two
branches
together.
D
So
instead
of
keeping
different
environment
data
in
different
branches,
there
are
different
directories
for
different
environments,
and
this
is
fairly
standard
and,
since
you
know,
I'm
talking
here,
I'm
kind
of
preaching
to
the
choir
here,
I'm
pretty
sure
that
people
in
this
call
already
are
familiar
with
many
of
these
principles,
just
as
a
recap,
in
a
sense.
So
what
is
here
is
a
base
directory.
There
are.
There
are
environments,
and
there
are
variants
and
variance
is
an
interesting
concept,
because
these
are
what
developers
call
mixins.
D
So
these
are
the
classes
that
don't
necessarily
follow
a
hierarchy.
So
there
is
no
fraud,
which
is
one
class.
There
is
also
EU,
which
is
another
class,
and
they
are,
you
know
somewhat
overlapping.
They
are
not
they're,
not
hierarchies,
and
if
you
want
to
promote
something
from
one
environment
to
another,
you
would
copy
the
files
from
one
of
the
directors
in
EnV
from
one
say
from
from
say
QA
to
prod
U
right,
but
you
wouldn't
copy
the
stuff
in
variants,
so
anything
that
isn't
supposed
to
be
promoted
goes
to
variants.
D
As
an
example
replica
count,
you
don't
normally
copy
their
application
configuration
between
environments,
it's
specific
tidally,
tied
to
an
environment,
so
keep
it
in
a
separate
directory.
So
that's
what
variants
are
for
environment
is
what
you
can
copy
now
other
than
other
also
propose
an
approach.
This
is
primarily
for
infrastructure
as
code
repositories.
There
is
an
idea
here
to
use
a
workspace
directory,
which
you
will
find
at
the
very
bottom
and
the
I.
The
workspace
directory
is
meant
to
attract
a
user,
because
this
is
one
of
the
problems
I'm
trying
to
solve.
D
Okay,
so
a
new
developer
starts
at
the
company
or
actually
a
different
use
case.
Some
of
the
introduces
githubs
into
an
organization,
and
everybody
is
new
to
it
right.
So
where
are
they
supposed
to
make
the
changes?
This
is
a
common
question
and
like
what
is
this
structure
like?
What
are
all
these
things?
Where
do
I
make
my
change
so
the
the
name
workspace
I
like
that,
because
it
it's
meant
to
attract
the
user.
D
So
in
this
structure
a
developer
makes
change
to
the
workspace
which
has
a
list
of
components
component,
a
b
and
c
which
could
be
applications.
There
could
be
other
things
and
there
is
a
separate
file
that
defines
okay
if
it
goes
to
workspace,
it's
supposed
to
get
deployed
say
to
staging
then
from
staging
it's
supposed
to
get
deployed
to
say
well.
That
was
actually
wrong
wrong
order.
But
let's
say
it's
supposed
to
first:
go
to
Dev:
that's
then
supposed
to
go
to
staging,
and
then
it's
supposed
to
go
with
prod.
D
So,
there's
a
file
that
describes
this
pattern
of
deploying
for
promoting
from
one
environment
to
another,
but
you
start
with
workspace.
You
always
start
with
workspace
here
and
there's
also
some
automation
around
this
a
project
called
telephonisca
which
creates
vrs
that
promote
from
one
environment
to
another.
So
that's
that
is
again
a
similar
concept,
similar
ideas,
but
there's
this
this
edition
of
this
workspace
idea.
That's
that's
meant
to
attract
users
now
Christian
who's
in
the
call
and
I
have
Matthew
Christian.
By
the
way
we
need
to.
D
We
need
to
make
Sunday
I
really
enjoyed
reading
your
articles
as
the
other
ones
and
I'm
cycling
in
the
article.
Here's
a
structure
and
correct
me
if
I'm
wrong
by
the
way
Kristen
if
you're
here.
So
this
is
one
of
the
structures
that
Christian
suggested
in
his
article
and
this
one
combines
infrastructures
code
with
applications
right,
so
you
don't
necessarily
have
to
keep
them
in
one
right.
D
There's
you
could
split
them,
but
this
this
particular
case
we
put
them
together,
so
apps
go
to
the
apps
directory
and
again
we
have
these
different
directories
per
application.
We
have
the
base
so
there's
a
separate
base
here
per
application
and
there
are
overlays
right.
This
works
really
well
with
customized,
so
you
have
over
overlay
for
Dev,
Broad
and
stage
and,
of
course,
with
customize.
You
can
then
say
Oh
in
your
order,
like
Define
you
on
the
specific,
say
image
to
be
deployed
where
it's
in
your
base.
D
You
keep
everything,
that's
common,
so
that's
briefly
the
the
idea.
So
how
is
what
I'm
suggesting
different
it?
Really
there
isn't
much
I,
don't
think
there
really
is
an
innovation
here.
It's
really
just
combining
these
ideas
together.
So
let's,
let's
go
to
the
top
level
and
I'm
kind
of
basing
this
on
what
I've
seen
at
other
Enterprises
that
the
diamonds
are
Contracting
to.
There
are
different
organizations.
So
there
is,
there
are
product
teams,
there
are
infrastructure
organization
and
they
tend
to
have.
Maybe
you
know
different
policies,
maybe
for
approval.
D
So
if
we're
going
to
with
the
monoripa
approach-
and
this
is
what
I'm
suggesting
here
at
the
top
level
I'm
suggesting
having
different
directories
for
the
organizations-
so
maybe
product
teams,
every
product
team
has
applications.
So
this
is
the
top
level.
It's
kind
of
simple,
and
so
what
goes
to
an
application
and
here's
where
I'm
sort
of
trying
to
take
this
idea
further.
The
idea
is
further
that
I
saw,
which
is
okay,
so
I
like
the
idea
of
a
workspace.
D
D
You
wanna,
you
wanna,
actually
fix
it
in
staging
and
then
maybe
Port
these
these
changes
back
to
Dev,
but
you
want
to
start
in
staging
so
in
in
my
case,
there
are
workspace
and
I'll
show
later
what
that
means,
and
there
are
unpromotables
and-
and
these
are
kind
of
similar
to
variants,
but
I'm
gonna
describe
it
later.
So
I'll
start
with
workspaces,
because
that's
where
developer
normally
starts
and
I
have
these
different
environments
here
so
product
QA
staging
right.
This
is
fairly
standard
as
expected.
Now
what
do
I
have
inside?
D
And
there
are
a
couple
of
ideas
here,
so
one
is
first,
I
have
multiple
files
by
the
way
I've
been
I
mean
it's
a
good
moment
to
mention
this
I've
been
designing
this
with
Helm
in
mind,
so
some
of
the
so
these
ideas
are
well
tested
and
well
fitting.
If
you're
using
Helm
for
customized
I
haven't
really
created
a
working
implementation.
D
I
believe
this
is
this:
is
this
still
can
be
applied
to
to
customize
I
just
haven't
figured
out
all
the
details,
but
for
Helm
I
suggest
multiple
files
here
so
say:
image
version
based
version
settings
where
you
keep
most
of
the
stuff
image
version
where
you
say,
keep
the
tag
of
the
application
image
and
base
version
where
you
keep
keep
like
a
pointer
to
a
git
repository
and
a
git
ref
that
points
to
the
location
of
the
base
template.
D
So
what
I
wanted
to
achieve
here
is
to
have
shared
base
templates
so
not
to
have
a
copy
in
different
application,
but
have
it
have
them
in
a
different
repo
and
then
in
the
gitos
repo?
You
just
refer
to
a
specific
git
ref
and
a
git
repo
in
the
in
of
the
templates.
So
let
me
just
show
you
briefly
what
that
might
look
like.
This
is
an
implementation,
that's
really
tailored
to
helm,
but
this
we
can
customize.
D
This
yaml
may
look
a
little
bit
different,
but
this
is
an
image
version
right
and
the
idea
here
is
this
is
all
it
contains.
Why
is
it
so
simple,
because
one
of
the
problems
that
you
often
have
is
well,
you
want
to
update
a
tag
automatically
and
one
of
the
problems
that
you
often
have.
Okay,
how
do
you
do
it?
You
have
to
parse
your
yaml
file
if
your
ml
file,
the
order,
may
change
of
the
other
date
and
the
yaml
file.
So
maybe
you
don't
use
a
parasis.
D
Maybe
you
just
use
a
regular
Expressions
substitution
and
just
you
know,
look
for
the
tag
name
prices
you
can,
but
that's
ugly.
So
the
idea
here
is
I
have
this
very
short
file
if
I
want
to
automatically
update
this
tag,
I
literally
generate
a
whole
new
file
like
this
and
I
override
this
one,
because
this
is
only
two
lines:
I
can
just
overwrite
it,
and
it's
only
the
time.
So
this
helps
with
automated
updating
attacks.
This
is
why
it's
a
short
file
with
base
version.
D
Again
this
is
so
that
could
recommendation
this
is
for
help.
The
idea
here
is
okay,
I,
say
I
want
this
specific
chart.
The
name
of
the
chart
is
actually
defined
in
the
settings
file,
but
in
this
base
version
I
say
this:
is
the
version
of
the
Helm
chart
I
want
this
is
a
ref
in
the
git
ripper,
where
this
chart
is
stored.
It
will
actually
require
completely
separate
talk
to
discuss
this
in
more
detail
how
this
works,
because
this
works.
D
This
is
not,
let's
say
something
that
is
available
with
Helm
right
away,
but
let's
abstract
away
from
helmet
a
little
bit.
The
idea
here
is
whether
you
use
customize
Helm
or
anything
else
that
you
have
a
file
where
you
define
I
want
the
base
from
a
given
git
repository
or
at
the
given
ref.
So
this
could
be
a
tag.
This
could
be
typically.
I
would
suggest
an
attack
that
doesn't
move
or
or
a
gitsha
right,
but
not
something
that
moves
like
a
branch
unless
you're
just
experimenting.
D
So
so,
how
do
you
promote
a
release
between
environments
in
a
very
simple
way?
All
you
do
is
run
these
three
commands,
so
you
remove,
let's
say
staging
you
want
to
promote
for
qasis
staging,
so
remove
staging
you
copy
from
QA
to
staging,
and
then
you
add
it
again.
So
that's
where
everything
that
was
installation
is
gone,
all
the
files
and
then
you
added
and
everything
was
in
QA
is
now
in
staging.
So
that's
what
the
promotion
looks
like
so
now
somebody
may
ask
okay.
D
So
what
do
we
do
about
things
that
can
be
promoted
like
I
mentioned?
So
that's
what
unpromotables
is
for
actually
before
I
talk
about
unpromotables,
just
brief
mention,
if
you,
if
you
have
multiple
regions,
what
I
suggest
is
you
create
more
directories
inside
workspaces,
not
subdirectories,
because
then
promotion
is
going
to
be
too
complicated
and
I
suggest
the
ads
character
as
a
separator,
because
that
way
it
kind
of
sends
out
even
you
have
dashes
or
underscores
in
the
sort
of-
let's
say
your
environment
classes
like
EOS
2..
D
So
this
way
you
have
the
different
workspaces
for
different
regions
and
and
different
environments,
but
unpromotables.
This
is
what
I
wanted
to
talk
about,
because
that's
very
much
the
same
idea
as
variants
I
discussed
previously,
but
it's
specifically
called
out.
This
is
the
stuff
that
you
cannot
promote.
So
anything
like
a
replica
count
as
an
example,
all
horizontal
pulled
out,
Auto
scaling
things
that
is
tightly
tightly.
Let's
say
a
very
specific
to
a
given
environment
goes
here
and
in
here
you
can
have
subdirectories,
that's
not
the
problem.
D
This
is
in
fact
it's
easier
that
way,
because
you
can
have
a
file
inside
prod.
You
can
have
a
file
inside
Us
West
and
you
can
so
you
can
have
some
settings
come
on
to
all
of
prod
some
setting.
Let's
come
onto
a
region,
there's
no
problem.
I
probably
would
say
we
shouldn't
have
too
many
layers
of
subdirectory.
So
if
you
need
another
layer,
I
would
just
say
use
the
add
character,
because
the
developer
experience
may
actually
suffer
if
you
create
too
many
layers.
D
So
non-pci
is
an
example
like
if
you
have,
if
you're
a
regulated
business
and
you
process
payment
card
information,
you
may
keep
that
in
a
separate
cluster
and
you
may
have
a
non-pci
cluster
for
stuff
that
doesn't
process
payment
card
information,
the
PCA
cluster
for
everything
else.
So
so
you
may
have
essentially
a
separate
cluster
called
EOS,
2
non-pci.
So
I
would
suggest
you
you
you,
you
don't
create
too
many
levels,
you
just
add
character,
but
in
a
sense
you
can,
if
you
won't,
have
multiple
levels.
D
If
you
want
to
deploy
to
multiple
namespaces
at
once
rare
case,
but
can
happen
with
some
infrastructure
level.
Applications
again,
I
suggest
multiple
sort
of
directories
here,
the
I.
The
idea
is
that
you
can
also
have
mixins
here
so
at
the
bottom.
You
see
the
any
thing,
so
this
directory
very
strictly
defines
hey.
You
know
this
is
these
are
going
to
be
mixing,
so
everything
that
that's
EOS
2
is
is
defined
the
us2
directory.
D
So
that's
the
idea
of
un
promotables
and
none
of
this
stuff
gets
promoted,
just
just
environment,
specific
the
configuration.
So
now
we
are
kind
of
zooming
out
and
I'm
nearing
the
end
of
the
talk.
So
this
is
the
entire
application
directory
sort
of
at
the
birds
of
view.
D
D
D
So
that's
it
that
that
was
my
case.
This
is
what
I
wanted
to
share
and
I'd
like
to
move
on
to
q.
A
and
I
wanted
to
ask
you
if
this
was
intriguing.
If
this,
if
you
find
that
there
was
something
that
you
could
apply
from
this
and
then
I
would
be
curious
also
to
find
out
if
you
have
any
other
questions
comments
in
our
suggestions,
how
this
can
be
improved.
That
will
be
great.
D
A
Dennis
has
his
hand
up
yeah
I.
Think
Chad
didn't
have
any
questions.
D
D
E
Hi
sorry
Hi
by
the
way,
my
kids-
that's
fine,
north
right,
so
I
I,
don't
have
a
lot
to
comment
here
and
so
I'm
gonna
try
and
make
it
as
short
and
sweet
as
possible.
I
think
so.
First
thing
is
I.
Think
having
a
or
more
than
one
standard
directory
organization
is,
is
a
very
novel
goal.
E
That
being
said,
I
don't
think
a
single
one
can
cover
all
use
cases.
There's
there's
different
requirements
in
in
different
places.
One
one
aspect
I
didn't
see:
I
didn't
hear
about
it
in
in
your
proposal-
was
security
considerations,
for
example
in
security
requirements
considerations,
for
example
the
company
I
work
for
which
is
Sony
PlayStation.
We
we
have
a
very
paranoid,
Security,
Group
and,
and
they
enforce
we
work
in
certain
ways
which
translates
differently
depending
on
on
what
we're
working
on
right.
E
But,
for
example,
we
have
I,
don't
know
30
40
clusters
and
ramping
up
very
quickly
right
now,
they're
massive
clusters
and
they're
very
complicated
places
as
in
their
their
hybrid.
You
know
Cloud
environmental,
individual,
bare
mineral
runs
your
regular
servers
and,
and
some
of
the
hardware
Is
Not
Unusual
hardware
and
I'm,
going
to
leave
it
at
that.
I
can
talk
about
it,
but
and
some
of
these
clusters
are
accessible
to
some
of
the
personals.
E
Some
of
these
questions
will
not,
and
we
need
to
you
know
for
for
practical
reasons.
We
need
to
put
them
in
different
directories
at
the
top
of
the
monologue.
B
E
We
do
use
the
monories,
so
so
yes,
I
agree
with
the
fact
that
I'm
going
to
approach
I'm
going
to
replace
the
right
way
to
go.
I
agree
with
the
fact
it
took
us
months
to
figure
out
and
discuss
a
proper
structure
for
R1
repo.
We
also
agreed
that
well,
not
everybody
did
but
most
of
us
that
that
branches
were
obfuscating
too
much
to
be
workable,
practically,
and
but
we
we
couldn't
use
the
the
structure.
E
E
We
have
multiple
teams
with
with
different
levels
of
access
to
the
to
the
monarito,
and
another
thing
we
do
is
each
team
gets
access
to
a
certain
number
of
namespaces
in
virus
clusters,
not
always
the
same
species
you
know
in
in
all
the
Clusters
and
they
are
not
allowed
to
deploy
to
other
name
species,
and
we
manage
that
with
our
back
and
we
also
have
with
gitlab
as
I
get
as
a
get
host,
and
we
also
have
a
Mr
sorry.
E
It's
called
Mrs
in
the
lab
and
the
pipeline
actually
supplements
the
code
owner
stuff
and
and
then
provides
more
barriers
to
to
to
accessing
other
parts
of
the
monorail
so
again,
I,
think
and
and
what
I
want
to
comment
is
like
based
on
your
structure.
Ours
is
mostly
reverted
in
Parts.
It's
right,
like
you
know,
it's
more
like
bottom
level,
top
top
down,
depending
on
how
you
look
at
yours.
E
So
again,
my
point
here
was
that,
rather
that
a
standard
I
would
prefer
that
we
have
a
set
of
maybe
examples
or
or
recommended
structures,
or
something
like
that,
because
one
is
certainly
not
going
to
cover
all
use
cases.
It
doesn't
cover
results
and
I'm
sure
we're
not
the
only
company
and
and
that
that
have
different
requirements
and
not
even
our
you
know,
structure
would
cover
theirs
and
I.
Think
we
need
more
than
one
recommended
structure.
D
D
We've
also
found
that,
for
example,
code
owners
in
GitHub
has
not
been
sufficient
for,
let's
say
restricting
access
to
different
directories,
so
we
would
need
to
use
either
one
of
the
let's
say
third-party
extensions
or
develop
our
own
and
we're
probably
going
to
go
towards
the
last
option,
which
is
develop
our
own
method
for
essentially
deciding
who
can
modify
what,
because
code
number
CS
was
was
too
Limited
in
that.
In
that
extent,
so
I
totally
understand
that
yeah
yeah.
E
So
what
we
do
is
we
still
use
code
owners
and
it's
used
for
the
UI
and
it
kind
of
does
a
kind
of
you
know
rough.
You
know
how
to
say
it
blocking
of
all
barriers
to
to
you
know
to
to
committing,
but
the
actual
authorization
to
authorization
to
to
access
a
part
of
the
monorepo
is
done
by
a
guitar
pipeline.
So
we
have
marathore
Mars
to
come
into
the
monoripo
and
every
time
you
submit
an
MR,
a
python
is
normally
triggered
and
this
this
virus
jobs
that
say,
okay,
this
is
valid.
E
This
is
valid.
No,
you
can't
hear,
or
you
need
approval
from
there
so
and,
and
that
happens
using
the
gitlab
UI,
so
you
serve
in
the
gitlab
UI
so
that
we
use
the
gitlab
UI
for
Gathering
the
approvals
and
then
I
when
the
pipeline
executes.
We
check
Who
provided
an
approval,
what
team
they're
from
and
what
their
approvals
can
cover
out
of
the
out
of
the
changes
in
that
Mr
and
and
and
and
often
the
needs
more
than
one
approval.
D
Okay,
cool
yeah,
definitely
all
right
so
I
think
Chris
and
your
first
yeah.
C
Yeah
on
and
I'll
try
to
be
succinct
as
Denny.
Hopefully,
I
said
that
right
said,
but
I
kind
of
just
kind
of
want
to
Echo
what
he
said.
It
is
when
I
first
started
out
writing
about
like
directory
structures
and
get
Ops
record
structures.
I
was
I
had
the
same
goal
as
you
did
and
then
quickly
found
out
that
there
there
isn't
one
for
all
or
they're
and
and
actually
wrote
in
the
blog.
C
C
You
would
run
into
issues
because
their
communication
structure
just
wouldn't
allow
for
the
one
we
were
proposing.
So
we
would
have
to
change
it
up
and
so
I
think
running,
I
think
focusing
the
conversation
more
on
best
practices
versus
like
trying
to
templatize
someone
right.
C
So,
like
kind
of
what
in
and
I
read
in
costas's
blog
post
right,
it's
like
don't
use
branches
right,
use,
directory
structures
like
that's
the
kind
of
stuff,
I
think
I
think
is
more
useful
or
like
what
do
you
call
it
at
case
studies
like
this
presentation,
you
had
like
kind
of
felt
like
a
case
study
a
little
bit
more
than
anything
else
which
a
lot
of
people
are
gonna
like
read
it
and
like
pick
parts
of
it
that
fits
into
their
own
workflow,
so
in
general,
I
found
the
unpromotables
thing
very
interesting,
like
I.
C
So,
like
that's
kind
of
like
something
you
know
posting
something
like
this
is
great
because
it
kind
of
gives
me
ideas
and,
like
others,
I'm
pretty
sure,
it'll
give
them
ideas,
but
just
I
guess
that's
the
only
feedback
I
have
is
that
trying
to
go
with
a
one-size-fits
all
it's
just
it's
just
hard
right.
It's
just
I,
think
I.
Think
a
lot
of
us
have
been
down
that
path.
Not
just
you
know
not
not
just
myself,
not
just
others,
but
I.
C
Think,
like
a
lot
of
us,
have
tried
to
go
down
that
path,
even
even
when,
like
using
flux
right
like
flux,
is
kind
of
very
it'll,
give
you
a
directory
structure,
but
it's
very
very
loose
right,
like
you
can
do
a
lot
with
it.
You
can
change
it
up.
You
don't
have
to
like
use
their
proposed
ones
out
of
the
box,
so
so
yeah,
that's
that's
kind
of
it.
I,
don't
think,
there's
one
to
rule
them
all.
I!
C
Think
really
it's
it's
very
specific,
and
it's
very
not
only
to
the
use
cases.
Just
kind
of
the
organization
like
you
know,
kind
of
ways
all
organizations
communication
structure
may
not
allow
for
a
lot
of
the
things
that
you
propose.
So
that's
just
kind
of
yeah,
okay,
yeah.
F
Yeah,
thanks
for
the
presentation
for
sharing
the
discussion,
I
think
kind
of
like
Christian's
comments
where
it's.
This
is
a
great
kind
of
place
to
facilitate
more
discussions,
and
these
designs.
I,
was
thinking
about
another
one
of
costas's,
blog
posts
and
I.
Think
like
Michael's
talked
about
this
as
well
we're
taking
what
you've
put
together
here
and
using
like
Helm
as
the
example.
Where
would
you
have
the
same
structure
or
would
this
be
a
reason
to
bring
in
branches
when
you
want
to
say
the
render?
F
All
of
your
templates
render
like
all
of
your
charts
and
commit
that
back
into
the
repo,
and
would
you
then
like
want
to
do
that
in
the
same
folder
structure
or
something
like
that?
Is
that
I
have
a
lot
of
use
cases
kind
of
similar
to
I?
Think
mothers
have
talked
about
like
oh,
we
need
we
need
to
render
the
the
charts
out
or
something
and
commit
that
back
in
yeah
under
yeah,
see
the
dev,
but
also
just
managing
things.
That
way.
D
D
When
you
merge
the
repo
when
developer
merges
the
repo
where
they
made
the
change
automatically
on
the
other
PR
will
also
get
merged
so
Yes
program.
The
ring
is
something
that
has
been
taken
into
consideration
here.
It
has
its
pros
and
cons
worse,
which
is
probably
a
weather
subject
on
its
own.
But
yeah.
That's
that's
the
approach.
That's
the
approach
here.
I
hope
that
answers
the
question.
F
Yeah
yeah
that
helps
I
was
just
gonna,
also
make
it
a
tongue-in-cheek
comment
that
some
of
these
discussions
feel,
like
the
debates
of
git
flow,
whether
to
do
that
versus
flat
structure
stuff.
But.
D
Yeah
very
much
so
you
know,
and
then
this
was
a
very
good
invention
at
the
time
and
I
think
it
still
is
I.
Think
I
did
read
in
some
of
the
blog
posts.
Also
some
really
good
case.
Why
it
doesn't
apply
here,
why?
You
know
gizo
introduce
idea,
hey,
you
know,
use
different
branches
for
for
different
environments
right
and
we
are
not
using
that
here.
There
are
good
reasons
why
right
it's
just!
Maybe
it
is
indeed
for
code
for
for
application
code.
D
A
Sweet
thank
you
Alexander
other
questions
for
Alexander
for
me
and
Ash
Josh
in
general
for
new
topics.
A
If
not
we'll
wrap
it
up,
thank
you.
Everybody
for
attending
and
we'll
see
you
at
the
next
one.
G
Okay,
that's
all
right!
You.
G
I
I
want
to
take
a
small
opportunity,
since
we
have,
since
a
lot
of
the
subject
matter
expert
here,
asking
a
question
we
do
get
in
this
question
every
now
and
then
about
the
helm.
The
native
support
of
the
helm
I
want
to
see
your
guys
opinion
about
those
hooks
and
what's
the
other
functionality
they
have.
They
have
this.
How
do
they?
They
can
query
for
the
live
data,
to
do
something
when
you're
using
the
helm
like
those
functionality,
I
won't
see
you
guys.
G
The
opinion
about
those
things
is
in
general.
Do
you
get
a
little
Club?
Yes,
the
cloud:
do
you
guys
thinking
that
kind
of
like
oh
I,
it's
I'm
dying
for
it
because
I
really
want
to
have
it?
Do
you
guys
think
it
because
GitHub
is
coming,
you
wanted
more
practice
in
the
pure
githubs.
You
want
the
source
of
truth
actually
more
in
the
gate,
rather
than
you
have
kind
of
the
runtime
information
which
that
could
be
keep
changing.
D
Yeah
I
mean
that
could
I
could
start
I
I,
so
we're
not
using
that
mainly
because
we
are
pre-rendering
in
manifest,
but
I
assume
that
I
would
say
for
organization
that
doesn't
need
to
pre-render
them.
Lookup
is
great
and
I
think
it's
a
lot
easier
to
set
up
as
well.
Then,
then,
all
this
complexity
with
having
to
prevent
the
Manifest
so
I
think
it's
it's
very
useful
for
someone
who
wants
to
get
started
with
our
group
quickly.
D
Do
you
think
the
bigger
you
grow
as
an
organization?
The
more
you
want
to
move
these
render
rendering
to
git
and
then
also
the
comparison
to
git?
And
so
this
is.
This
is
my
take
on
this.
E
Yeah,
so
so
I
think
we're
pretty
happy
with
Helm
being
only
used
for
rendering
charts
in
Argo
City
and
living
it
at
that,
the
idea
being
we
we
want
to
leverage
as
much
as
possible
from
get
because
the
big
advantages
with
see
with
Git
are
that
it's
self-documented
and
self
history
and
if
Helm
starts
messing
with
that,
it's
just
just
makes
things
more
complicated
to
track.
G
Cool
airing
everyone
have
I
mean
I
seem
to
have.
People
are
if
I'm
summarized,
based
on
what
you
guys
saying.
That
means
it's.
The
general
knowledge
is
when
you
go
to
more
bigger
production
when
you're.
Using
these
things
more
seriously,
it
seems
that
you
don't
want
to
use
that
functionality,
because
you
want
it
to
be
more
declarative,
more
like
like
a
source
of
Truth
in
the
game,
but
I
won't
see
whether
anyone
else
has
a
different
opinion
about
you.
You
think
it
should
be
another
way
around.
C
So
what
what
I
like
about
the
helm
lookup
is
that
you
can
stamp
out
generic
get
Ops
repositories
to
potentially
right
so,
like
I,
have
an
application
I
want
to
deploy
and
I
want
to
deploy
it
to
like
I,
don't
know
50
clusters,
for
example-
and
you
know
all
of
them
are
generally
the
same,
except
for
you
know
a
few
things.
The
most
common
use
case
is
like
the
Ingress
host
name.
That's
another
application
on
the
cluster
may
or
may
not
need
right.
C
So,
instead
of
having
an
overlay
for
each
one
of
those
clusters
and
deploying
that
overlay,
I
just
have
kind
of
like
one
generic
deployment
and
then
use
the
lookup
feature
to
then
populate
things
that
I
need
for
that
application
other
than
that
I'm,
not
sure
I,
don't
know
what
other
use
cases
are
there
for
for
the
lookup.
That
makes
that
useful,
but
I
think
for
me
the
big
one
I
think
is
being
able
to
like
rubber
stamp.
C
You
know
a
lot
of
clusters
and
if
they
are
kind
of
like
trading
clusters
as
cattle
right,
like
I'm,
just
deploying
a
bunch
of
clusters
deploying
my
workload
and
then
kind
of
use.
Some
of
those
features
like
look
up
to
then
populate
things
that
I
may
need.
G
E
Considering
the
use
case
you
were
talking
about,
which
is
you
want,
clusters
that
mirror
recharges,
but
not
completely
or
or
or
you
know,
parts
of
it
are
the
same
in
parts
of
it
or
not.
We
have
a
feature
that
we
use
here,
which
We
call
we
don't
have.
We
haven't
settled
on
on
a
real
name,
but
cluster
links
or
whatever
you
want
to
call
it
and
where
we
can
use
a
yaml
file.
That's
picked
up
by
an
application
set
and
it's
adjacent
to
what.
E
Where
would
be
the
directory
where,
with
the
whole
Helm
chart
and
when
the
application
set
finds
that
yellow
file
it
will
copy
the
app
from
from
the
cluster?
That's
that's
in
in
the
yaml
file
and
and
just
like
replicate
it
entirely
accept
the
values
of
yaml
will
be
picked
up
for
for
that
particular
cluster,
and
we
can
do
that
at
the
application
Level.
E
We
can
do
that
at
the
namespace
level
and
we
can
do
that
at
the
entire
cluster
level,
and
that
thing
I
want
to
say
is
that
we
can
point
to
either
in
either
actual
cluster.
But
we
also
have
like
virtual
clusters,
which
are
like
the
same
organization
as
a
real
cluster,
but
it
the
only
difference,
is
they're
not
deployed
anywhere.
It's
just
there
to
be
used
as
a
kind
of
a
framework
type
of
clusters,
and
you
can
copy
an
entire
namespace
from
there
in
your
cluster
and
done.
E
G
Okay,
yeah
I
mean
I
I
just
want
to
get
some
idea,
but
thank
you.
Thank
you
for
you,
guys
sharing
so
I
think
that's
concluded.
A
And
Hong
we
do
have
two
different
attempts
to
get
look
up
like
features
in
Argo
CD
one
requires
an
upstream
Helm
change,
which
seems
to
have
stalled,
but
there
was
some
action
about
a
month
ago.
The
other
is
a
proposal
from
yawn
to
introduce
Dynamic
parameters
to
Argo
CD
and
Jan
and
I
have
slight
disagreements
about
the
implementation
but
I.
Think
overall,
the
idea
is
a
good
one.
So
if
you
want
to
hop
in
and
leave
your
thoughts
on
that
proposal,
that
would
be
helpful.
A
Cool
with
10
minutes
left
anyone
else
have
any
topics
or
thoughts
or
questions.