►
From YouTube: Argo Contributors Office Hours Jun 9th 2022
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
All
right,
good
morning,
everyone
welcome
back
to
the
contributor
experience
meeting,
I'm
your
host
for
today.
So
let's
jump
into
it.
So
it
looks
like
on
the
agenda
for
today.
As
usual,
we
have
the
trials
and
discussion
primary
secondary,
so
alex
it
looks
like
you
were
primary
this
past
week.
Are
you
on
the
call.
A
Okay
looks
like
alex:
isn't
here,
maybe
he'll
join
soon
rashaab?
Are
you
on
the
call,
as
well.
B
Yeah
I'm
on
the
call,
so
that
was
not
much
into
github
discussion,
but
there
is
one
discussion
which
ask
for
oauth
for
the
user
management.
I
bring
that
in
chat.
D
A
Rashad,
would
you
mind
responding
to
them
to
yep,
okay,.
A
Okay,
thank
you
all
right,
so
moving
on,
I
think
we
should
decide
who's
going
to
be
primary
secondary
for
next
week.
So
first,
do
we
have
any
volunteers
for
either.
A
Okay,
then,
I
think
we
can
go
ahead
and
move
down
the
list,
so
it
looks
like
dan.
Are
you
on
the
call
you're
next
for
primary.
A
Dan
is
not
here,
I
I
will.
I
will
volunteer.
Oh
thank
you.
John.
Let's
see
where's
your
name
on
here.
A
And
then
for
secondary,
I
can
take
secondary
next
on
the
list.
A
All
right,
thank
you
guys,
so
moving
on
looks
like
we
have
an
issue
on
the
agenda.
The
rwc
metrics
tab,
okay,
so
it's
a
proposal,
so
it
looks
like
dan
and
bala.
Is
this?
Yes?
Yes,
we
are
here.
Okay,
would
you
guys
like
to
talk
about
this
yeah.
F
Can
you
share
the
screen
yeah?
Of
course,
let
me
stop
my
share.
Okay,
so
just
I
will
do
the
introduction.
Hi
everybody,
I'm
bala,
I'm
a
software
engineering
intuit,
I'm
leading
the
cargo
workflow
and
working
with
the
observability
team
to
bring
that
all
the
observability
features
to
that
all
the
tools,
and
I
have
a
dan
who
is
working
on
that
at
the
ux
side
of
the
observability
dan.
Do
you
like
to
introduce
yourself.
G
Yeah,
so
I'm
dan
smith
software
engineer
at
intuit.
I
work
on
the
observability
team
and
we're
trying
to
help
bring
some
observability
functionality
into
argo
cd.
F
G
Cool,
so
it
only
takes
a
second
to
demo,
really.
What
we've
done
is
basically
inside
of
each
object
type.
You
can
go
into
you
can
go
into
here
and
you
have
we
added
a
metrics
tab,
and
so
I
guess
just
backing
up
just
a
second,
you
know:
argo
cd.
G
Its
goal
is
really
to
make
deployments
clear
and
understandable,
and
so
we
do
feel
like
some
basic
metrics
at
least
are
are
key
to
that
right.
Now,
a
lot
of
users
go
to
tools
that
are
outside
of
argo,
like
grafana
or
prometheus
ui
or
wavefront
or
splunk
other
places.
Basically,
when
they're
doing
a
rollout
or
just
doing
even
basic
monitoring,
they
go
to
those
extra
tools
which
is
fine,
but
I
think
that
there
could
be
some
simple
functionality.
G
We
add
here
just
to
make
it
clear
for
the
users
and
especially
for
just
the
general
use
case.
So
what
we've
done?
Is
you
added
this
metrics
tab
and
if
you
go
there
right
now,
we're
just
showing
cpu
and
memory
utilization,
but
we're
doing
it
at
basically
all
the
different
levels,
so
containers
images,
pods
instances
and
jobs,
and
this
this
list
of
different
types
can
be
we
can
we
can
customize
it
as
well.
As
you
know,
we
can
also
just
remove
some
of
the
stuff
by
default.
G
If
it's
not
meaningful
so
right
now
you
can
see
there's
just
one
container
running
here.
I've
got
one
image
running,
which
is
my
v1
or
I'm
sorry,
my
v2
for
this
particular
image,
and
you
can
see
here
the
different
pods
that
are
running.
We
can
also
select
different
pods
if
we
want
to
just
compare
them
and
then
this
this
graph
here
is
basically
the
average
utilization
for
those
different
pods
or
images.
Whatever
the
thing
is,
and
then
you
also
have.
G
I
also
added
events,
so
you
can
hover
over
this
lightning
bolt
and
you
can
see
okay
this
during
this
minute
there
was
a
resource
that
was
deleted,
as
well
as
two
resources
that
were
updated
and
and
basically
we
just
persist
the
same
model
through.
So
the
user
is
really
easy
for
them
to
just
kind
of
understand.
Just
like
logs.
Just
like
events,
you
can
go
down
into
roll
outs,
you
can
look
at
metrics
here.
G
You
can
see
the
same
thing
now
if
I
had,
if
I
had
a
larger
application
and
pods
falling
under
different
rollouts
and
pods
falling
under
different
replica
sets,
we
could
also
see
so
this
replica
set
obviously
shows
all
my
pods,
but
if
it,
if
I
had
two
replica
sets,
then
this
would
just
show
the
pods
for
this
particular
replica
set,
and
so
I
can
go
in
here
and
kind
of
mimic
a
scaling
event.
If
I
go
into
my
rollout
object
here,.
G
I've
got
my
pods
rolling
out
and
obviously
this
adds
these
events
in
here,
and
so,
if
you
go
here
now,
you
can
see
that
is
successfully
created.
This
is
on
the
replica
set
item,
it's
showing
what
was
created
there
and
you
can
kind
of
just
monitor
going
forward.
You
know
whatever
whatever's
happening
on
the
particular
within
your
application.
If
I
go
to
the
rollout
itself,
I
can
see
this.
This
scaling
event
happen,
so
I
can
keep
an
eye
on
the
utilization
after
that
scaling
event.
G
We
also
can
add
other
metrics
in
here,
so
we
want.
We
want
to
make
it
customizable
so
that
the
user
basically
can
add
a
configuration,
and
maybe
they
have
http
requests
for
their
services.
They
want
to
be
able
to
see
or
other
other
types
of
metrics
that
would
be
either
readily
available
in
prometheus
or
metrics
that
their
application
is
pushing
to
prometheus.
F
Currently
they
need
to
go
to
the
grafana
or
something
to
compare
like
how
is
the
response
time
all
the
things
so,
instead
of
that,
they
we
can
give
that
this
is
not
competiting
with
the
grafana
or
something
it's
giving
like
a
very
important
matrix
graph
here,
so
that
the
user
no
need
to
go
to
that
other
tools
to
decide
whether
they
can
promote
it
or
revert
it
back.
So
that's
the
main
objective
of
this
effort,
and
basically
we
did.
F
We
did
with
the
initially
with
the
extension,
but
extension
has
a
lot
of
some
limitations.
So
that's
why
we
are
proposing
like
a
native
support
in
ui
side,
so
that
we
can
have
like
a
separate
tab
called
matrix
which
will
be
enabled
and
disabled
based
on
the
feature
flag,
so
that
default
it
will
be
like
a
disable,
and
if
the
user
want
the
orgo
cd
user
wanted,
they
can
enable
it,
and
we
will
this
entire
graph
and
the
layouts
are
fully
configurable
like
it's
all,
are
coming
from
the
conflict
map.
F
So
the
user
can
define
what
are
the
graph
they
want
to
see
in
the
targo
cd
itself.
Then
anything
else
we
need
to
show.
Otherwise.
I
can
go
into
the
proposal.
E
E
Very
easy
to
compare
the
new
row
out
versus
the
over
rollout
right
and
yes
and
in
general,
I
think
dan
was
also
saying
if
you
click
on
any
kubernetes
resource,
and
it
has
metrics,
one
could
see
those
metrics,
correct
and
and
so
like.
If
they
have
labels
and
things
would
one
be
able
to
like
graph
metrics
like
different
lines
based
on
labels.
Things
like
that.
G
Right
yeah,
we
would
add
a
configuration
so
that
they
can
basically,
we
could
show
yeah.
The
different
labels
are
different,
metrics
that
they're
pushing
the
prometheus.
G
Does
yeah,
but
it
yeah
so
ones
that
have
ones
that
have
a
state
of
so
like
these
ones,
don't
have
any
pods
underneath
them,
but
we
could.
We
could
look
at
some
of
those
things
like
I'm
not
sure,
met
this
endpoints
some
points.
Maybe
there
are
metrics
for
this.
We
can
explore.
F
E
F
F
Yeah,
let
me
let
me
take
the
screen
from
dan,
okay
and.
F
So
so
mainly
the
meeting
here,
we
are
kind
of
proposing,
like
our
architecture
change,
so,
as
I
told
to
ed,
so
this
is
the
sample
configuration
which
will
which
will
which
will
be
in
that
conflict
map
which
will
render
that
entire
page.
So
basically,
this
is
the
primitive
system,
one
of
the
provider
currently,
but
we
can.
We
can
write
like
a
wavefront
or
something
else
for
the
metric
provider,
and
this
will
be
like
application
specific.
F
So
one
we
can
have
like
a
default
which
will
be
like
if
that
particular
application
doesn't
have
a
any
any
dashboard,
then
it
will
come
from
the
default
suppose
some
of
the
application
they
want
a
specific
specific
dashboard.
Then
they
can.
The
user
can
easily
configure
the
specific
dashboard
for
the
application
and
each
dashboard
will
have
like
a
resource
kind,
so
the
user
can
define
like
a
for
the
pod.
I
want
to
show
these
are
my
dashboards
and
for
the
replica
set.
I
want
a
different
and
those
kind
of
different
graphs.
F
They
can
define
it
in
the
graph
side.
Actually,
they
can
easily
configure
like
the
the
query
for
the
data
and
they
can
define
like
a
title
and
what
duration
they
want
it.
What
is
the
graph
type
like
a
pi,
pi
type,
or
line
graphs
and
under
suppose,
if
it
is
a
multi,
multi-cluster
environment,
then
they
can,
they
can
configure
it
like
each
cluster
cluster,
the
primitives
access
url
then
based
on
the
the
api
call,
it
will
get
the
cluster
information
and
it
will
automatically
fetch
that
the
primitives
access
point
and
it
will
query
from
that.
F
Okay,
this,
let
me
take
into
that
how
how
how
we
are
pulling
that
matrix
to
the
targo
cd
ui,
so
the
problem
statement
is
everybody
knows
what
is
the
context
we
are
addressing
and
what
is
the
problem
statement?
We
are
trying
to
solve
it
so
so
here
I
have
like
a
two
proposals,
because
this
all
the
proposals
are
based
on,
like
initially
that
alex
c
alex
colin
was
proposed
to
that
argo
cd
extension
v2
from
that
this
is
this.
One
is
inspired
from
that.
So
basically
he
proposed
like
a
proxy
that
argo
cd.
F
Proxy,
the
targo
cd
to
access
the
external
service
to
get
that
external
service
can
do
that
functionality
of
coding
anything
and
return
back
to
that
ui,
and
there
was
a
few
discussion
went
through
that.
Then
we
took
that
another
route
like
ingress
proxy
ingress,
will
segregate
the
segregate
the
apa
call
from
that
argos
or
ui
to
go
to
that
external
service.
F
The
external
services
they're
responsible
for
quoting
that
any
any
information
from
the
prometheus
or
multiple
primitives
are
wavefront
based
on
that
conflict
map
and
return
back
to
that
argo
ui.
F
This
is
the
one
of
the
proposal
in
this
proposal.
Basically,
we
need
to
do
that.
We
need
to
patch
the
ingress
to
divert
the
apa
calls
to
that
new
service
and
another
one
think
we
need
to
authenticate
every
service,
so
we
need
to.
We
need
to
change
the
argo
cd
to
validate
that
each
request
tokens
whether
the
token
is
valid
or
not
through
that
argo
cd.
F
And
basically,
metric
server
is,
as
I
explained
like
it
will,
it
will
read
the
conflict
map
and
query
the
configuration
from
the
primitives
as
well
as
it.
It
will
expose
the
two
two
apis.
One
is
like
returning
like
a
dashboard
for
that
particular
kind
for
the
application
and
another
one
is
like
a
coding
getting
the
matrix
data
for
that
graph.
That
are
the
two
api
that
so
ui
will
call
this
two
to
render
the
page,
but
this
was
this
proposal
was
assumption
of,
like
a
all.
F
F
That's
the
main
advantage.
I
can
see
that
and
it
can
be
really
separately
like.
We
now
need
to
tie
it
with
argo,
cd
server
side.
There's
a
two
things
I
can
see
for
the
pros
of
this
one
but
convice
to
enabling
and
enabling
this
feature
is
a
little
bit
complex
like
we
need
to
patch
patch
the
multiple
resource
specs
and
do
that
and
the
second
one
is.
We
need
to
force
the
user
to
install
that
ingress
and
another
one
thing
we
need.
We
need
to
expose
the
targo
cd
for
authenticate
that
every
request.
F
This
is
the
one
proposal
that
another
proposal,
this
one
is
like
a
really.
I
like
it,
it's
a
very
simple
and
it's
a
very
clean
way,
because
everybody
was
in
even
intuit
side
and
open
source
side.
Everybody
want
like
a
simple
important
matrix
on
the
argo
cd
side.
So
this
is
the
one
proposal
like
we
can.
F
So
we
no
need
any
authentications
because
argo
cd
itself,
we
have
authentication
and
defining
a
matrix.
The
pages
are
every
everything
is
fully
configurable
and
it
will
come
from
the
config
map
and
enabling
disabling
that
feature.
Basically,
the
matrix
puller
can
return
back
like
a
405.
If
the
config
map
is
not
present,
if
the
configment
is
present,
then
the
feature
is
enabled,
then
it
will
return
back
that
200
with
response.
F
F
F
F
I
am
currently
looking
for
you
to
like
give
a
feedback
so,
okay,
which
one
is
good.
What
is
the
what
you
guys
are
thinking
about.
A
I
think
for
me
personally,
my
thoughts
are
that
the
I
prefer
the
second
approach
I
think
you
touched
on
it
before,
but
I
don't
think
I
I
think
argo
cd
tries
to
be
as
unopinionated
as
possible
and
by
introducing
an
ingress
object
to
enable
this
feature.
I
think
that
it
kind
of
it
forces
too
much
opinionation
on
the
user
if,
if
they
want
to
take
advantage
of
this,
so
I
think
that
I
I
lean
towards
the
second
approach.
J
Yeah
same
same
here
I
mean,
if
we
consider
that
we
also
have
the
the
core
mode
right,
core
installation,
that
the
user
will
never
use
an
ingress
for
for
those
installations,
and
they
have
the
dashboard
that
they
can
port
forward
so
also
yeah.
I
also
feel
that
like
having
having
some
magic
ingress,
rerouting
at
the
front
end
that
that
just
feels
not
right
so
yeah.
J
Yeah,
it's
it's
okay,
for
for,
if
it's,
if
it's
your
environment
right,
so
if
you
choose
to
yeah,
implement
that
at
your
environment
to
enforce
it
on
the
users
that
feels
strange
always
so
I
yeah
I
I
I
do
like
that
proposal.
I
think,
having
some
kind
of
simple
metrics
is
quite
quite
a
nice
thing
to
have
and
yeah.
C
A
I
think
this
is
what
we
take
advantage
of
for
the
very
simple
metrics
that
we
display
in
the
pod
view,
yeah.
That
would
make
sense
yeah.
So
I
think
I
mean
we
could
maybe
leverage
that
more
to
display
some
more
interesting
data,
but
I
think
that,
like
you
said
it's
going
to
be
very
limited
on
what
we
can
do
with
it,
but
we
could.
We
could
certainly
try
to
take
advantage
of
it
more
maybe
yeah,
like.
A
C
K
C
Those
things
displayed
at
like
I
I
I
don't
know
super
well
what
matrix
api
has
available
to
us.
I
know
cpu
and
memory.
I
don't
know
how
much
history
et
cetera,
but
having
you
know
the
base
graphs
be
based
off
of
that,
since
that's
kind
of
standardized
would
be
not
requiring
any.
You
know,
users
to
set
up
prometheus
and
other
things
like
that.
To
define
these
dashboards,
I
think,
might
make
sense.
C
C
F
D
That's
fair,
I
think
in
option
two.
We
could
mitigate
leo's
performance
concerns
by
externalizing
the
metric
server
to
its
own
pod,
not
behind
ingress,
but
just
making
the
grpc
service
that
the
api
server
communicates
with
similar
to
repo
server.
That
way,
if
you
manage
to
dos
the
metric
server,
you
haven't
taken
down
the
whole
api.
D
D
Let's
see
the
other
item
is,
we
might
want
to
introduce
new
metrics
are
back
rather
than
just
relying
on
the
current
applications
are
back
I.e.
You
know,
just
because
you
have
get
on
an
application,
doesn't
mean
you
get
metrics
too
you'd
have
to
have
that
line
in
our
back
as
well.
F
Doing
because
of
the
matrix
here
is
like
all,
are
read-only
like
do
we
do.
We
need
like
that,
our
bug,
as
long
as,
if
that
the
user
is
able
to
access
that
application?
F
That's
a
that's
the
same
thing
like
a
log
right,
the
metrics.
Do
we
need
to
separate
our
box,
I'm
just
trying
to
understand
what
is
the
use
case.
The
user
really
need
a
or
back
for
the
metric
side.
Well,.
D
To
be
fair,
we
introduced
new
are
back
for
the
logs
as
well,
but
those
are
does
have
the
possibility
of
being
more
sensitive.
I
guess
if
I
really
just
wanted
to
let
a
user
sync
their
app
and
that's
it
I
might
not
want
to
let
them
have
the
opportunity
to
tell
how
that
app
is
behaving
in
terms
of
performance.
D
F
But
mike
michael,
I
will
sync
with
you
offline,
like
your
proposal
like
the
grpc
one,
I
will
talk
to
you
on
the
offline
to
get
more
information,
but
currently
we
are
kind
of
going
with
the
argo
cd
change,
because
this
won't
have
like
more
iterations.
F
Probably
we
are.
We
are
aligned
with
our
good
cd
side
release.
So
that's
what
I'm
also
kind
of
thinking
because
go
with
the
separate
installation
and
other
things.
Then
again
we
are
going
back
to
that
the
option,
one
kind
of
complexity.
F
L
And
all
the
results
yeah,
you
can
get
the
latest
metrics
from
what
is
the
latest
update
that
you
have
in
cache
and
for
longer
term
like
for
the
interim
data?
You
still
have
it
in
cache.
You
don't
have
to
pull
it
always
from
the
endpoints,
which
are
usually
slow.
F
F
L
Ideally,
having
a
separate
deployment
for
cash
would
be
better
because
the
the
amount
of
data
that
you
would
be
collecting
for
a
single
instance
of
argo
cd
and
having
multiple
apps
that
you
might
want
to
query
for
it
may
be
more
so.
Instead
of
having
a
sidecar,
I
think
having
a
separate,
our
installation
will
be
good.
J
Can
I
can
I
maybe
suggest
to
like
I
mean
we
for
this
change.
We
will
need
an
official
proposal
anyway
right
so.
I
And
yes,
I
agree,
I
agree
with
jan,
and
so
I
guess
moving
forward
with
this
proposal
and
by
the
way
thanks,
bala
and
daniel
for
presenting
this.
So
I
guess
everybody
agrees
that
option
two
is
more
of
a
viable
one
and
we
want
to
move
forward
with
that.
So,
but
regardless
of
the
option
we
choose,
we
still
have
to
agree
on
that
contract
for
the
for
the
config
map.
I
I
Okay
and
the
next
thing
is
really
providing
a
proposal
for
the
architecture
for
the
back
end
because
yeah
as
comments
were
made,
there
are
quite
a
few
performance
concerns
here
and
we
need
to
to
to
yeah
have
that
documented
somewhere
and
have
an
agreement
on
how
this
this
is
going
to
be
implemented.
I
But
I
think
we're
good.
F
Okay,
so
can
you
forward
that?
Is
there
any
template?
I
can
put
a
formal
proposal
with
the
suggested
one.
I
Yes,
second,
I
can
provide
that
all
that
to
you,
the
problem.
Okay,.
F
Perfect
then
I
can,
I
can
put
a
like
the
architecture
proposal
as
well
as
that.
What
is
the
contract
of
the
config
map
format.
A
Yeah,
thank
you
guys
that
looked
great
yeah,
so
I
think
we
can
move
on
to
the
next
agenda
item.
I
think
we
might
not
be
able
to
get
to
the
rest
of
the
agenda.
It's
pretty
jam-packed
today,
but
for
now,
let's
it
looks
like
yon.
You
wanted
to
demo
a
new
feature
or
oh.
J
A
new
exception
yeah,
it's
not
me
who
who
wants
to
demo.
I
was.
I
was
having
a
conversation
with
some
colleagues
recently
so
with
nicholas
and
his
team,
and
they
have
yeah.
I
I,
I
think
nicholas
you
can
introduce
what
you've
done.
So
that's
pretty
interesting
and
I
thought
are
we
we
could
show
off
in
the
contributors
meeting.
So
I
was
hoping
that
alex
would
be
here,
but
he
apparently
isn't,
but
it
looks.
A
Like
he
is
not,
I
can
sort.
J
Of
relay
yeah,
you
were
involved
in
our
the
extensions
as
well
right,
so
yeah.
H
In
the
meantime,
I
work
with
niklas,
so
I
can
give
a
little
bit
backgrounds
on
on
this
feature.
So,
oh
my
name
is
yi
and
I'm
from
ibm
automation,
sas
platform
team.
We
we
use
argo
cd
as
our
main
mechanism
to
deliver
our
services
into
our
cloud
environments
and
our
argo
cd
is
shared
by
multiple
teams.
H
So
we
run
into
some
limitation,
as
we
know,
and
another
thing
we
are
heavily
relying
on
is
kubernetes
customer
resources,
different
team
have
different
customer
resources
and
we
build
a
lot
of
different
team,
build
a
lot
of
their
own
custom,
health
checks
and
right
now,
argo
cd
is
using
a
centralized
config
map
to
load
all
those
custom,
health
checks
for
different
custom
resources
and
because
we
are
sharing
by
different
teams.
That
means
different
team
have
to
commits
or
pr
into
the
same
conflict
map
to
get
all
the
customer
resource.
H
Health
check
working
that
sort
of
run
have
us
run
into
some
limitations.
So
we
searched
about
how
we
can
split
the
duty
around
those
to
make
sure
different
team
can
manage
their
own
argo,
cd,
custom,
health
checks
and
we
found
the
argo
cd
extension
proposal
is
supposed
to
do
exactly
what
we
are
thinking
of
to
do
so
we
add
some
code
changes.
We
add
some
implementation
to
the
argo
cd
extension
and
nucleus
is
ready,
so
we
can
look
at
how
it
works
here.
We
go.
M
Thanks
for
the
background,
so
can
everyone
see
my
terminal
and
browser
yep?
Okay,
so
just
for
the
sake
of
example,
I
have
a
pretty
simple
custom
resource
setup
because
of
the
fact
that
we're
trying
to
avoid
using
the
central
config
map
there's
nothing
set
in
there
right
now.
M
My
test
resources
here
are
pretty
simple:
they
have
a
color.
If
the
color
is
green,
we
consider
them
good.
Otherwise
we
consider
them
unhealthy.
So
since
there's
no
definition
loaded
for
the
health
check
right
now,
we
can
see
that
they
don't
have
a
health
status
like
we
would
see
for
standard
resources.
M
M
And
if
I
look
at
the
extension
itself,
we
can
see
that
it's
successfully
processed
one
extension
source,
so
what
we
actually
have
as
part
of
this
extension
here
is
the
same
as
I
mentioned
before.
We
consider
green,
healthy,
otherwise,
we're
not
healthy
right
now,
and
if
I
go
in
refreshing
argo
cd,
you
can
see
that
it
picks
up.
Green
is
healthy,
blue
and
red
is
not,
and
that's
what
we'd
expect
from
the
health
check.
M
So,
along
with
that,
we
are
able
to,
of
course,
then
immediately
remove
this
health
check.
If
we
feel
that
we
don't
want
to
use
it
anymore,.
M
It
will
pick
up
these
changes
on
reconciliation
deleting
and
applying
just
means.
We
don't
have
to
wait
for
that
to
happen.
There
are
some
other
things
that
we
also
had
to
put
in
stuff
like
resolving
conflicts.
If
two
tried
to
modify
the
same
resource,
the
first
one
will
apply
and
then
the
second
one
to
try
to
touch
that
resource
will
be
denied.
These
were
so
that
we
could
prevent
health
check
conflicts
and
I'm
happy
to
show
how
that
works.
A
I
think
I
don't
have
any
questions,
but
this
looks
this
looks
great.
This
is
something
that
we
wanted
to
do
with
extensions
from
the
beginning.
So
thank
you
guys
for
for
working
on
this.
M
Glad
to
hear
we've
focused
mostly
on
modifications
in
the
extensions
themselves.
As
far
as
what
actually
touches
argo
cd,
we
use
an
additional
config
map
so
that
it's
fully
auto-generated
and
there's
no
confusion
of.
Does
a
user
use
this
or
do
the
extension's
useless?
So
we
just
load
an
additional
conflict
map.
If
it's
not
there,
we
move
on.
If
it
is
there,
we
try
to
use
its
health
checks.
I
see
okay.
A
Okay,
that
makes
sense.
I
know
that
there
was
at
one
point
we
had
maybe
had
some
discussion,
so
I
guess
first,
I
think
that
this
is
great
and
that,
regardless
of
what
we,
what
improvements
we
make
in
the
future,
I
think
that
this
is
something
that
we
want
to
retain,
because
it's
very
simple
works.
Well,
the
implementation
seems
like
it's
pretty
straightforward.
A
I
think
we
had
talked
about
at
one
point,
maybe
doing
sort
of
inline
health
checks
in
the
extensions
crs
and
then
additionally,
maybe
even
adding
support
for
other
health
checks
or
sorry
for
defining
health
checks
in
other
languages
besides
lua.
So,
like
you
know,
using
an
arbitrary
language,
these
are
just
future
enhancements
that
could
be
introduced,
but
just
to
give
you
an
idea
of
where
we
were
thinking
it
might
be
able
to
go,
but
for
for
now
this
is
great
yeah.
I
Just
for
me
to
understand
that,
because
we
already
have
the
the
similar
feature
for
custom
health
checks
in
the
in
the
standard-
argo
cd
config
map-
so
this
what
what
this
brings
additionally
to
what
we
currently
have.
Besides
the
fact
that
it
allows
different
programming
languages
besides
lua,
to
be
used.
A
Right
now,
this
does
not
correct
me
if
I'm
wrong,
but
this
does
not
allow
other
languages
besides
lua
to
be
used
actually.
So
I
think
the
main
benefit
is
that
you
can
store
this
elsewhere
from
your
main
argosd
config
map,
and
so,
like
nicholas
mentioned
you,
you
can
have
different
teams
using
different
health
checks
and,
and
it
simplifies
yeah
it
basically
detaches
your
health
checks
from
the
rest
of
the
argus
eco
configuration.
A
M
H
Okay,
cool,
thank
you
and,
and
we
also
prioritize
the
conflict
map
in
the
central
conflict
map.
I,
like
the
customer
health
check,
means
central
comfort
map
if
they
are
already
defined
in
the
centralized
content
map.
This
will
not
override
those
and
conflicts
between
different,
like
help.
Customer
health
check
in
different
locations
also
have
the
ability
to
resolve
the
conflicts
yeah.
A
M
M
Yes,
so
if
we
add
the
extension
and
that
extension
is
trying
to
modify
a
health
check
already
in
the
central
conflict
map,
we
would
have
to
choose
either
to
respect
a
health
check
from
the
central
conflict
map
or
the
health
check
from
the
extension
right.
We
favor
the
central
conflict
map
so
that
someone
can't
overwrite
a
health
check
for
other
teams.
M
M
L
The
other
approach
on
this
one
is:
we
can
define
this
per
cr
independently
right
for
the
resource,
customization.
L
So
so
argo
cd
config
map
supports
something
called
resource,
customizations
with
which
you
can
do
this
right,
like
the
declare,
the
status
of
the
object
healthy
or
not,
based
on
the
lua
script
that
you
have,
and
you
can
extend
that
to
a
particular
custom
resource
as
well
right.
Can
we
do
that
here
like
if,
if
in
a
given
app,
if
I
have
multiple
custom
resources,
can
I
edit
this
per
custom
resource.
M
Yes,
I
if
I
understand
the
question
right
you
could,
you
would
define
each
of
the
custom
resources
that
are
part
of
it
under
this
list
here
and
all
of
them
would
be
used.
Okay,.
A
Great
any
more
questions
on
that.
K
No
questions,
but
if
it
looks
great,
then
we
would
like
to
contribute
it
back
and
like
nicolas
should
we
we
are
using
with
the
full
code.
So
we
would
like
to
contribute
back
and
then
use
it.
A
Yeah
yeah,
that
sounds
great.
I
will,
if
you
guys
do
you
have
a
pr
open.
H
Yeah,
that's
our
next
spec
we're
gonna,
be
cleaning
up
our
codes
and
the
read
more
comments
and
things
to
make
it
more
reviewable
and
then
submit
the
pr
into
the
argo,
cd
and
rcd
extension
projects.
Awesome.
A
Yeah
sounds
good
I'll,
be
sure
to
take
a
look
at
that
when,
when
you
guys
open
the
pr-
and
I
think
alex
will
want
to
take
a
look
as
well,
but
this
is
great,
so
thanks
guys
great
thanks.
Thanks
awesome
all
right.
So
if
there's
no
more
questions
on
that,
I
think
we're
over
time.
So
I
just
want
to
make
sure
with
it
looks
like
zach
and
michael
you
guys
had
some
topics.
Are
you?
Okay?
If
we
push
those
to
next
week
since
we're
running
a
little
over.
A
Okay,
yeah,
are
you
sure,
yep
that'll
work
thanks
and
then
zach?
How
about
you
yeah
that
that's
okay
with
me,
okay,
sounds
good
thanks,
guys,
sorry
about
that,
all
right!
Thank
you
guys
for
attending
and
have
a
good
rest
of
your
day.