►
From YouTube: Argo Contributors Office Hours Oct 28th 2021
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
Resume
the
recording
good
morning,
everyone
welcome
back
to
the
contributor
experience
meeting.
So
let's
take
a
look
at
the
agenda
for
today
we
can
get
started
with
triggering
and
discussion
for
the
the
issue
triage
this
week.
Harley,
do
you
want
to
take
over.
B
Yeah
sure
yeah
thanks,
I
think
the
last
week
can
you
actually?
Can
you
please
scroll
up
the
last
week?
Who
is
the
transformer
okay?
I
think
it's
william
and
dan
william,
then
anything
that
you
guys
want
to
share
or
discuss
here
on
the
last
week's
triathlon
or
any
issues
or
any
discussions
that
needs
to
be
discussed
here.
C
Do
we
have
either
of
them?
I.
B
Well,
that's
that's
why
I
think
next,
I
think,
for
the
week
can
we
actually
fix
the
at
least
the
prime
date?
Second,.
B
A
Okay
and
then
do
we
have
any
volunteers
for
primary.
A
I
don't
think
jan
is
john
here
no
jana's
in
china,
yeah
yeah,
hong
or
pasha.
Do
you
wanna
volunteers,
primary
or
anybody
else.
A
Yeah
all
right
so
discussion
about
the
servers
that
apply
you
can
you
can
take
over
if
you'd
like.
E
Sure
yeah
hi
everyone,
as
mentioned
in
a
previous
contributors
meetings.
E
There
was
an
intention
to
do
some
exploration
about
servers
that
apply
and
how
that
could
be
used
to
to
address
different
issues
in
argo
city,
and
I
did
some
work
investigating
and
providing
a
draft
proposed
proposal
and
well,
I
wrote
down
the
proposal
here
and
the
idea
of
this
draft
proposal.
I
don't
think
this
is
near
to
be
final,
is
mainly
to
start
discussion.
E
E
Yeah,
so
a
little
bit
of
background,
so
there
was
this
issue
open
a
while
back
and
it
has
a
lot
of
votes,
and
this
is
about
how
we
could
improve
our
ocd
to
deal
with
conflicts
in
in
field
updates
right.
E
So,
for
example,
we
have
the
desire
state
express
and
git
for
number
of
replicas,
for
example,
and
then
we
have
the
the
horizontal
bottom,
auto
scaler
controller
that
will
come
up
and
and
update
that
number,
the
number
of
replicas
for
for
deployment,
for
example,
and
that
will
make
argo
cd
to
be
to
become
auto
sync
and
depending
on
how
you
have
argo
cd
application
configured
that
will
revert
to
the
previous
state.
E
So
this
is
this
is
what
this
ticket
is
about.
This
is
what
this
issue
is
about,
how
we
could
improve
our
ocd
to
better
handle
those
situations.
E
Those
cases
where
multiple
entities
are
updating
fields
in
the
same
resource,
so
argo
city
has
some
sort
of
rights
to
update
some
some
and
handle
the
state
of
all
resources
that
are
referred,
that
are
associated
to
a
specific
application
and
then
other
actors
who
could
also
modified
fields
in
any
of
those
resources-
and
this
could
make
cargo
city
behave
in
sometimes
undesirable
ways.
So
this
is
the
the
background
and
then
hong
suggested.
I
guess
it
was
in
the
previous
meeting.
E
I
don't
remember
the
the
investigate
about
about
argo.
Sorry
about
server-side
apply
as
a
possible
way
to
address
this
problem.
If
that
feature
could
be
leveraged
to
address
this,
so
is
it
okay?
Thank
you
very
much.
It's
very
good
cool.
E
So
that's
the
the
the
work
so
in
this
in
this
issue
there
was
already
one
suggestion
which
was
to
leverage
the
ignore
difference
in
the
argo
city
application
so
ignore
differences.
It's
an
attribute
already
there,
and
today
this
is
used
to
to
guide
how
the
diff
is
is
applied.
So
the
suggestion
is
to
add
an
additional
attribute
to
it,
respect
existing
value
to
our
files,
and
this
would
guide
how
the
sync
would
would
would
behave
in
this
specific
field.
E
So
I
I
gave
it
a
thought-
and
I
I
at
the
beginning
here
on
the
proposal-
I'm
listing
three
downsides
on
this
in
this
approach,
so
the
first
one
is
because
this
approach
seems
to
me
like
a
reactive
one,
so
you
have
to
go
in
field
by
field
update
in
the
every
apple
argo
city
application,
the
ones
you
want.
You
want
it
to
be
ignored
right.
E
So
maybe
you
don't
know
what
are
the
fields?
So
it's
a
reactive
in
a
way
that
every
new
field
you
discover
you
have
to
go
and
update
all
your
argo
cd
back
to
to
ignore
those
fields.
It
seems
to
be
a
lot
of
manual
and
automation
works
for
for
ops
teams
to
to
deal
with,
and
also
something
that
is
a
little
bit
counter-intuitive
in
terms
of
how
the
argo
city
application
is,
is
structured
because
ignore
difference
and
correctly
correct
me
if
I'm
wrong.
E
If
you
have
more
experience
about
how
about
the
history
of
this
attribute,
but
by
reading
the
docs
and
the
source
code,
it
seems
to
me
ignore
differences,
basically
something
that
was
designed
to
be
used
at
a
diff
state,
not
at
the
sync
state.
So
adding
an
attribute
there.
That
will
also
impact
how
the
sync
is
is
progressed
is
is
actually
being
well
well.
E
How
the
sink
will
behave
seems
to
be
not
going
in
the
direction
this
attribute
was
originally
designed
for
also
because
in
the
in
the
argo
application,
we
already
have
the
sync
policy,
which
is
the
attribute
that
deals
with
syncs
right.
How
how
I
want
to
configure
things
in
him
for
this
for
resources
related
to
this
application.
E
So
that's,
that's
the
that's
the
background
of
the
current
proposal
that
are
already
there.
I
gave
my
my
my
yeah
some
downsides
on
that
one
so
and
then
I'm
bringing
some
overview
on
server
side
apply
and
how
that
could
be
probably
be
leveraged.
So
I
think
it
is
a
possible
way
to
to
to
provide
a
simpler
and
easier
user
experience
user
experience
to
to
argo
cd.
E
So,
for
example,
here
we
have
a
deployment
resource
and
it
has
I'm
displaying
here
the
the
new
managed
field
attribute
in
the
metadata
and,
as
you
can
see,
we
have
this
concept
of
managers
right.
We
have
a
list
of
managers
and
kubernetes
will
kind
of
save
all
the
fields
that
specific
manage
specific
manager
updated
at
a
given
moment
in
time
based
on
this
managed
fields,
for
example,
argo.
E
So
this
is
a
this
is
a
reality
right
now,
so
every
r,
every
field,
the
argo
city,
will
manipulate
for
specific
resources.
It's
already
there,
so
rgo
city
application
controller
will
be
listed
as
a
manager
and,
for
example,
cube
controller
manager
is,
is
the
one
that
for
deployment.
So
this
is
a
deployment
example.
So
cube
controller
manager
is
the
one
that
will
be
actually
be
updating
the
status
of
this.
E
Of
this
resource
right
so
here
we
have
already
a
shared
responsibility
on
the
same
resource,
but
because
queue
controller
manager
is
updating
the
status.
This
is
not
really
impacting
how
argo
city
deals
with
the
deployments,
because
argo
city,
the
status,
is
not
part
of
the
state
that
people
usually
provide
and
get
right.
So
there
is
no
conflict,
but
we
could
have
a
situation
where
another
actor,
for
example,
ctl,
updates
a
field
that
is
managed
by
argo
city
desire,
state
and
git.
E
So
this,
if
we
enable
server
side,
apply
on
argo
cd
syncs.
What
would
happen
in
this
case
is
that
the
server
will
raise
an
error,
a
conflicting
error,
okay,
so
and
if
you
follow
kubernetes
documentation,
there
are
three
possible
ways
to
to
for
for
that.
For
that
point
in
time
for
for
the
actor
to
to
decide
how
to
to
to
deal
with
that
to
that
with
that
conflict.
So
there
are
three
possible
ways.
E
E
Conflict
strategy
to
use
and,
for
example,
we
could
have
application
level
conflict
strategy
inside
sync
policy,
when
it's
server-side
enabled
to
decide
per
manager
what
to
do
so.
The
idea
is,
for
example,
if
I'm
I'm
if
the
conflict
is
made
by
cube
controller
manager,
actor
then
respect
that
so
argo
cd
would
kind
of
play
nicely
with
that
specific
manager.
E
But
if
manager
is
cube,
ctl
then
always
override,
because
some
someone
just
updated
something
manually
in
the
cluster,
and
in
this
case
I
want
the
desired
state,
indeed
to
always
overwrite
what
is
in
there.
So
this
is
a
thing
that
maybe
is
possible
to
do.
I'm
not
100
sure,
but
this
is
a
possible
way
right.
So,
and
the
idea
here
is
just
to
raise
the
awareness
of
what
could
be
some
interesting
ways
to
go
and
then
having
a.
E
Yeah
a
definition
which
direction
to
go
for
for
going
forward
with
going
forward
with
this
this
issue.
So
that's
about
it.
I
just
wanted
to
present
the
proposal
and
hopefully
get
some
feedback
from
from
the
contributors
and
from
the
community.
C
Thanks
bill,
so
I
have
some
questions
and
then
I
want
to
get
in
ask
about
the
the
original
problem
why
we
followed
this
issue,
so
this
the
first
one
is
about
server-side
supply
in
general.
So
I'm
trying
to
understand
if
server
side
apply,
you
know
how
we
have
a
last
applied
configuration
annotation
on
the
objects,
so
is
that
eventually
going
to
go
away,
do
you
know.
E
I
I
read
in
the
docs
that
is
already
the
case.
If,
for
for
resources
that
are
having
the
manage
fields,
the
last
applied
config
is
not
it's
not
there
anymore,
so
I
would
have
to
double
check
that,
but
that's
what
I've
seen.
Let
me
see:
okay,.
C
I
see
well,
I
don't
know
I'm
reading
the
opposite,
because
it
says
downgrading
still
works,
because
q
ctl
server
side
apply,
keeps
the
last
applied
configuration
annotation
up
to
date.
If
you
use
keepsu
to
apply.
C
The
first
reason
I
bring
this
up
is
because
my
first
concern
is
that
if
we
rely
heavily
on
last
supply
configuration
to
maintain
to
calculate
the
diff
of
resources,
they
said
we,
we
calculate
the
three-way
diff
between.
So
we
understand
like
what
is
the
user
managing
and
what
is
got
defaulted
by
some
random
controller
and
then
what
is
the
live
object?
C
C
E
I
I
remember
I
remember,
reading
this
somewhere,
I
I'll
double
check
and
I'll
update
in
the
in
the
in
the
issue,
the
exact
place
where
I
read
something
mentioning
about
the
last:
let's
apply
configs,
but
I
remember
reading
something
about
it.
Okay,
tell
for
sure
the
the
behavior
at
this
point.
C
Okay,
yeah,
I
guess
whenever
I
think
of
server-side
play,
that's
the
the
first
concern
I
have
with
that
feature
is
that
we
might
lose
the
ability
to
div
properly.
C
C
So
originally,
I
don't
think
I
commented
in
this,
but
I
felt
like
there
should
be
a
separate
setting
that
would
control
whether
or
not
the
differences
are
preserved
or
or
ignored.
So
I
agree
we
shouldn't
overload
ignore
differences.
C
C
So
you
have
to
specify
values
for
the
weights
that
say
like
zero
to
stable,
exact,
zero,
the
canary
100
to
stable,
but
when,
when
the
rollout
controller
goes
and
updates
the
weight
during
an
update,
it
then
adjusts
those
weights
temporarily.
During
the
update,
so
then
during
the
update,
it's
gonna,
you
know
change
from
zero
to
five
percent
canary
then
ten
and
then.
Finally,
when
it
finishes
it
goes
back
down
to
zero
percent
canary
and
then
we're
back
like
in
sync
with
no
diff.
C
E
Yeah
so
I
just
wanted,
I
would
have
to
understand
the
use
case
a
little
bit
better
because
so
for
sure,
from
what
we
described,
we
have
another
actor.
So
it's
a
manager
called.
So
it's
going
to
be
another
controller
that
will
be
updating
that
field,
but
that
field
is
expressed
in
in
in
the
desires
taking
it
or
not.
Yeah.
C
C
Actually,
every
time
so
because
it's
in
git
every
time
we
apply
it,
it'll
be
zero
percent.
Canary's
100
yeah,
stable
yeah.
Meanwhile,
the
the
rollout
controller
is
just
playing
with
those
values.
So
there's
going
to
be
a
difference
in
during
the
course
of
an
update,
there'll
be
a
diff
caused
by
the
rollout
controller.
E
Okay,
so
sorry,
I
think
my
network
went
down
for
a
minute.
E
C
Okay,
yeah;
no,
I
think
you
got
it
so
so
that's
the
problem
statement
which
why
daniel
originally
filed
the
issue,
and
it's
like
it's
our
current
situation
today
and
then
I'm
wondering
how
this
approach
will
address
the
original
reason
use
case
for
following
this
issue.
E
Yeah
yeah,
so
I
think
it
it
is
it
is.
It
is
one
possible
way
to
it
is
it
is
a
valid
use
case
to
to
to
have
it
with
server
side
applied
for
so,
for
example,
in
this
case,
we
could
configure
like
the
manager
that
argo
rollouts
will
be
updating
in
the
manage
fields
to
become
so,
for
example,
the
conf
the
conflict
strategy
for
manager
either
rule
out
controller
to
be
overwrite
files,
so
in
this
case
anything
that
that
controller
would
update.
E
Argo
city
would
respect
as
the
the
state
to
kid
not
trying
to
to
to
bring
what
is
in
in
git
back
to
the
resource.
E
So
that's
that's
what
the
proposal
would
do
by
configuring
this
conflict
strategy,
but
for
that
server
side
apply,
needs
to
be
enabled
during
the
sync
process
right
so
during
the
sync
process,
with
argo
cd
would
try
to
to
sync
with
with
kubernetes
so
kubernetes
checks.
E
The
conflict
returns
back
an
error
to
argo
cd
and
then
argo
cd
would
have
to
to
to
deal
with
that
that
condition
so
in
ireland
city
code
would,
we
would
have
to
say,
hey,
we'll,
have
to
check
the
the
the
the
manage
fields
and
see
if
that
is,
the
conflict
is
being
caused
by
a
specific
manager.
So,
in
this
case
is
the
argo
roll
outs
controller,
and
if
we
have
the
configuration
as
our
rollouts
controller
override
files,
then
we
respect
the
controller
to
update
the
state
on
those
fields.
C
So
if
I
understand
the
what
server
side
pi
would
do,
then
the
the
ply
will
the
ply
will
still
go
through
but
not
affect
the
fields
that
are
also
managed
by
the
rollout.
So
the
roll-up
only
is
wanting
to
touch
the
seo
virtual
service
weights,
but.
C
But
the
the
the
get
off
should
be
managing
everything
else
about
the
virtual
servers
like
the
annotations
and
other
other
fields,
and
so
server
side
apply
actually
merges
those
rights
in
in
an
expected
way.
Is
that
what
happens.
E
C
E
The
correct
the
correct
behavior
is
to
only
apply
the
fields
that
are
not
owned
by
that
specific
manager.
So
if
the
fields
are
owned
by
the
manager,
don't
do
anything,
but
for
all
the
fields
that
are
part
of
the
of
this
of
the
div,
then
he
should.
It
should
update.
C
Okay:
okay,
so
so
with
server
side,
apply,
it'll,
apply
the
thing
and
get
subtract
the
stuff
that
is
managed
by
the
rollout
controller
and.
E
This,
I
don't
think
by
the
way.
I
don't
think
this
is
something
that
server
side
applied
does
out
of
the
box.
This
is
some
some
some
sort
of
some
sort
of
logic
that
we
would
have
to
implement
inside
out
of
the
cd.
If
I'm
not
mistaken,
I
don't
think
this.
You
know
from
the
patch
and
and
submitting
it
again.
It's
it's
it's
it's
done
out
of
the
box
for
for
service.
E
I
apply,
I
think,
from
what
I
read
and
from
my
understanding
is
that
it
will
just
return
a
conflict,
and
then
you
decide
what
to
do
right
and
then
you
have
the
three
possibilities:
overwrite.
It
anyway
give
up
and
continue
yeah
the
three.
E
Maybe
I'm
wrong,
but
yeah
I
would.
We
would
have
to
do
some
more
exercise
on
that.
Okay,
because
I
saw.
C
E
Yeah
the
example
in
the
docs
is
related
to
hpa,
but
no,
I
don't.
I
don't
recall
how
it
behaves
exactly
behind
the
scenes.
Okay,.
C
All
right,
I
don't
want
to
spend
the
rest
of
the
thing
talking
about
this,
but
I
I
think
overall,
it's
something
that
might
work
I
have.
I
think
I'd
like
to
noodle
on
it
a
little
bit,
but
it
could
be
a
cleaner
way
to
handle
it.
I
I
didn't
even
consider
this
direction.
C
Originally,
I
was
thinking
we
would
introduce
a
specific
field
called
preserve
differences
and
users
would
say
I
for
these
this
field.
I
want
it
to
be
preserved
when
applying
so
in.
Instead
of
that,
what
you're
proposing
is
is,
instead
of
explicitly
specifying
paths
that
need
to
be
preserved,
you're,
specifying
a
whole
manager
saying
preserve.
C
Manager
is
doing,
and
so
the
difference
between
what
you're,
proposing
what
I'm
proposing
is
you'd
say:
let
rollout
controller
have
a
priority
and
I
will
preserve
or
I'll
apply
everything
except
that
that
manager,
correct
okay.
That
does
seem
attractive,
so
I
just
wanted
to
one
make
sure
that
the
original
use
case
is
addressed.
C
C
Server
side
apply
a
little
bit
because
they
have
to
understand
the
concept
of
managers
and
but.
D
I
think
there
are
some
I
mean
I'm
not
talking
about
backhand.
I
think
backhand
looks
reasonable
to
me,
I'm
not
talking
about
on
the
ui.
Somehow,
if
you
can
highlight
those
information
say
we
don't
show
the
diff,
we
don't
think
it
has,
because
this
is,
it
has
the
server
side
apply,
enabled
and
also
we
can't
highlight
this
field
has
been
managed
by
a
different
controller
already.
D
C
Yeah-
and
it's
also,
the
bigger
decision
here-
is
actually
the
use
of
server
side
apply
in
the
first
place.
I
think
that's
I
mean
outside
of
this.
You
know
preserving
the
differences,
it's
like
that's
a
big
decision
for
an
operator
to
say.
Okay,
I
want
to
use
server
side
instead
of
client-side
apply
because
it
seems
like
it
comes
with
a
lot
of
side
effects.
D
Oh
one
more
use
case
we
data
here
from
qcon
is-
is
more
about
the
it's
just.
I
think
the
similar
thing
not
big
difference
is
about.
We
talked
about
that
opa
policy
mutation
workbook,
like
they
added
those
like
security
policy
to
say,
hey,
they
don't
allow
run
as
root.
It's
not
a
validation
of
web
hook.
They
basically
change
your
spec.
D
I
mean,
I
don't
think
it's
a
good
behavior,
but
they
do
that
then,
for
those
field,
I
assuming
they
will
override
it,
and
hopefully
the
management
field
will
reflect
that,
but
in
the
yamo
is
still
saying
wrong
rule
to
be
true
and
people
will
basically
still
like
asking
like.
Who
is
imagine
what
I
think
back
to
my
question
back
to
my
point
is
that
if
you
can
highlight
those
things
like
that
would
be
how
very
helpful.
C
D
C
Opt
in
to
that
there's
two
there's
two
things:
there's
preserving
the
difference
and
there's
ignoring
sorry,
there's:
preserving
a
manager's
ability
to
manage
that
field
and
there's
also
present
presentation
of
a
difference
in
in
the
system.
Both
are
separate
decisions;
okay,
so
they
could.
C
They
could
want
to
ignore
it
and
also
preserve
it,
or
only
one
of
the
two.
If
they
only
want
one
of
the
two,
they
either
use
this
this
feature
to
for
conflict
resolution
or
or
they
you
use
our
existing
mechanism
to
ignore
the
difference.
But
the
default
should
be
that
if
they're
only
using
this
feature,
this
new
feature
to
preserve
differences,
the
diff
will
still
be
shown.
A
All
right,
I
think
we
can
move
on
to
the
next
topic.
We
probably
only
have
time
for
one
or
two
more,
but
we'll
get
them
what
we
can
so
harry.
Do
you
want
to
discuss
the
2.2
release
status.
B
Yeah
yeah
sure
I
think
alex
is
not
that
you're
not
discussing,
but
I
just
want
to
highlight
on
2.2
status
like
if
anyone
has
any
features
still
pending
for
review.
So
now
it
is
posted
here
and
also
like.
There
are
some
features
I
think,
still
under
review.
So
please
wrap
the
reviews
faster
so
that
you
can
have
at
least
cut
by
next
week.
B
Not
yet,
I
think
so
we
are,
we
still
have
some
of
the
reviews
spending.
So
we
once
the
reviews
are
reviewed.
B
B
Yeah,
I
think
we
have
a
milestone
label.
So,
okay,
if
let
me
I
remember,
if
you
want
to
go
to
the
orgo
city,
we
can
just
say
2.2
milestone,
so
if
anyone
has
a
thing
that
needs
to
go
in
2.2
just
tag
it
with
two
dot
or
post
it
here,
we
will
tag
it.
B
B
So
a
lot
of
them
are
actually
bugs.
I
think
some
of
them
are
not
reproducible,
so
they
won't
go
into
two
or
two,
but
at
least
the
features
they
will
go,
but
the
prs
who
are
ever
raised
and
which
are
corresponding
to
this
one.
Then
they
will
get
repeat
anyway,
but
if
it
are
not
tagged
with
2.2,
please
tag
it.
Okay,.
A
All
right
awesome,
thank
you,
looks
good,
okay,
great,
so
leo.
Do
you
want
to
talk
about
metrics
for
application
labels.
E
Yeah,
so
this
is
mainly
to
showcase
something
that
I
worked
a
few
few
weeks
back,
so
I
I
revamped
the
metric
stock
a
little
bit
so
it
wasn't.
It
wasn't
displaying
all
the
metrics
that
we
have
so
this
is
now
there.
So
ops
can
just
take
a
look
and
see,
and
it
was
there
are
two
new
metrics
added
to
the
application
controller.
E
So
the
first
one
is
the
argo
cd
app
label.
So
there
was
a
ticket
where
users
were
asking
to
the
possibility
to
route
alerts,
to
specific
teams
that
have
their
application
out
of
sync
or
in
a
degraded
state,
and
they
had
labels
in
their
applications
right
so
and
they
wanted
to
do
this
with
prometheus.
This
is
some
sort
of
a
standard
way
to
do
with
prometheus,
so
cube,
state
matrix
provide
a
similar
approach.
E
So
what
I
did
here
is
implementing
it
as
a
separate
metric,
so
we
have
our
go
cd
app
info
and
then
there
is
argo
cd,
app
labels
as
a
separate
metric,
so
users
can
can
join
those
two
and
and
get
the
the
the
proper
query.
The
communities
query
to
throughout
alerts
specific
to
to
those
teams,
so
this
is
a
optional.
It's
not
enabled
by
default
metric
and
there's
a
documentation
here
where
I'm
explaining
what
users
have
to
do
to
to
enable
this
metric.
E
So
because
the
label
is
not
something
that
we
can
predict
and
when
we're
designing
prometheus
metrics,
you
need
to
know
what
are
the
prometheus
labels
you,
you
want
to
to
be
exposing
in
your
metrics,
so
so
as
there's
no
way
for
us
to
know
the
label,
the
label
name
of
every
user,
so
this
is
exposed
as
a
application
controller
a
flag.
E
So
it's
it's
a
list
flag,
so
this
can
be
provided
multiple
times,
and
this
is
an
example
of
how
argos
the
application
controller
can
be
configured,
and
this
is
the
resulting
metric
how
it's
gonna
look
like
so,
for
example,
this
one
has
the
the
the
users
the
the
opt
in
up
up
in
in
that
is
responsible
for
configuring.
E
Argos
cd
is
defining
that
their
application
control,
their
application
resource
will
have
a
label
called
team
name
and
another
label
called
business
unit,
and
when
the
metric
is
enabled
by
looking
at
those
attributes
here,
it
will
create
and
expose
those
labels
following
the
same
standard
as
found
in
cube
state
metrics,
obtaining
this
prefix
label
and
then
having
underscores
instead
of
hyphens
and
dashes
and
providing
the
the
the
the
value
of
those
labels
there
in
the
metric
and
then
the
three
other
main
fuse
that
can
be
used
as
a
join
in
queries,
which
are
the
name,
the
name
space
in
the
project
that
could
be
used
to
join
with,
with
with
the
yeah
app
handles
info
and
better
route
alerts.
E
Informations.
So
that's
that's
a
new
feature.
I
it
was
just
showcasing
it
and
and
making
sure
everybody's
aware
of
it.
E
E
They
have
to
to
define
one
by
one
because
yeah
we
don't
want
to
to
explode
the
metric
yeah
yeah
good
point.
No,
they
have
to
define
one
by
one
here
so
metric
application
labels.
So
it's
a
it's.
This
will
convert
whatever
they
define
here
in
a
into
a
slice
single
and
then
only
those
will
be
inspected
by
by
the
code.
C
Yeah
and
I'm
not
suggesting
we
do
it
just
like-
maybe
it's
better
to
start
with
people
being
intentional
about
this,
because
they
may
not
understand
the
the
cardinality
characteristics
or
the
consequences
of
doing
this
so
yeah
all
right,
cool,
I
oh,
I
do
have
a
question
like
so
does
this?
Is
this
configured
through
the
config
parameter,
config
map,
or
only
just
as
cli
flags,
to
the
controller.
E
C
It's
not
that
big
we
have.
We
have
we
doing
we're
doing
this
with
kind
of
this
thing
where
every
configurable
is
like
a
config
mam
projected
environment
variable,
I
don't
know
if
this
should
fall
into
that
or
not
I
just.
It
was
a
question.
C
I
I
think
it's
fine
it
also
it's.
I
don't
know
that
you
can
express
that
in
the
config
map
anyways,
because
this
is
a
repeated
list
flag.
So
unless
we
make
this
except
like
a
comma
delimited
set
of
labels,
then
it's
not
really
possible
to
put
it
into
the
configmap
which
which
could
have
been
another
option
too.
If
you
wanted
to,
but.
E
A
E
Done
as
I'm
finding
topics
to
discuss
in
this
meeting,
I'm
jumping
in
there
yeah,
let
me
know
if
it's
too
much
or
I
can
come
somewhere
else,
but.
C
Awesome
did
anyone
else
have
issues
because,
like
I
feel
like
we
all
like
dominated
the
conversation.
A
All
right:
well,
thanks
everyone
good
meeting,
and
we
will
see
you
next
week.