►
From YouTube: Argo Contributors Office Hours Feb 3rd 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
So
today
we
have
one
topic
edited
by
michael
to
talk
about
multi-source
application
proposal
and
before
we
go
there,
we
need
to
decide
who
is
going
to
be
answering
discussions
next
and
and
if
there
is
any
feedback,
see
my
pasha
feel
free
to
share
about
the
previous.
B
Okay,
so
there
were,
there
was
some
issue.
I
think
chetan
has
bringed
you
about
it,
but
it
was
more
of
I
can
send
you
the
link
as
well
in
the
chat
box,
so
it
it
was
that
that
you
know
we
don't
have
feature
for
github
books
when
we
do
argo
cd
code
installation,
we
do
have
it
for
application
set
controllers,
but
we
do
not
have
it
for
repo
server.
So
so,
if
that's
something
that
we
can
work
on
so
like
that's,
why
I
didn't
answer
the
discussion.
I
just
wanted.
A
A
A
You
have
a
flag
for
a
pay
server
to
only
expose.
I
think
I
think
it's
kind
of
it
in
my
mind,
it's
not
too
much
of
maintenance
work.
Basically,
if
we
build
it
that
there
is
a
lot
of
changes
because
we
would
need
to,
I
mean
not
a
lot
of
changes,
lots
of
manifest
changes
we
would
have
to
think
about.
I
don't
think
everyone
would
actually
no
it's
yeah
all
right,
the
more
I
think
about
it.
A
And
I
I
don't
I
feel
like
if
possible,
I
would
try
to
just
avoid
introducing
new
binary
just
for
webhook
server,
and
maybe
if
we
just,
we
could
have
a
flag
for
existing
ips
server
and
you
know
the
the
flag.
If
it's
set
to
true,
then
api
server
would
only
expose
the
hook
and
no
additional
apis.
So
it
would
be
safe
to
expose
it
to
the
world,
because
yeah.
A
That
makes
sense,
that's
my
you
know
my
opinion,
so
yeah.
If
anyone
thinks
differently,
please
suggest.
A
C
A
And
so
I
just
saw
a
message
from
chat.
You
know
like
five
minutes
ago
in
so
basically,
and
I
was
saying
that
maybe
maybe
it's
not
so
difficult
to
just-
we
literally
can
have
a
cli
flag
in
api
server
and
if
it
said,
if
the
flag
is
set
to
true,
then
server
is
going
to
have
just
have
a
hook
handler
and
nothing
else,
and
and
we
can
make
it
generic
like
we
can.
Basically
maybe
the
flag
name
can
be.
A
A
Okay,
I
think,
since
we
discussed
that
I
will
try
to
you,
know
I
will
publish,
I
will
write
a
short
summary
into
the
discussion
and
hopefully
someone
can
pick
it
up.
I
think
it's
not
maybe
not
super
critical,
but
good.
If,
if
we
have
clear
you
know
if
we're.
C
C
A
A
Someone
else:
okay:
now
we
need
someone
who
will
trade
and
answer
discussions
for
next
week.
I'm
I
hope.
Maybe
someone
from
you
know
who
joined
today,
wants
to
do
it
next
week.
If
not,
I
will
just
move
to
may
and
enter.
A
B
A
All
right,
thank
you
and
we
need,
and
I
think
basically
you
can
be
primary
and
we
need
secondary
anyone
wants
to
help.
I.
B
A
A
F
So
background
for
folks
there's
an
issue
with
a
lot
of
upvotes
asking
for
an
enhancement
to
add
external
values,
files
to
helm,
repo
applications.
F
So
it's
a
big
big
long
thread
and
a
lot
of
ideas
have
been
thrown
around
about
how
to
fix
it.
At
one
point,
we
were
thinking
at
the
ability
to
pull
in
just
multiple
sources.
Whatever
sources
you
want
for
one
application,
I
think
there
is
a
discussion
and
ishita
wrote
up
a
proposal
basically
describing
that
solution.
F
But
I
understand
there's
been
other
discussion
about
how
that
would
add
some
complexity
that
isn't
necessary
yet
so
just
wanted
to
get
a
summary
of
where
we
currently
think
we
want
to
go
that
way.
It
can
work
on
the
proposal.
A
Thank
you.
I
also,
I
feel,
like
I
kind
of
I.
What
I
remember
remember
is
blurry.
I
think
what
we
talked
about
last
conversation
was
that
so
we
have
this
request
to
support
helm
value
files
in
a
different
source
in
a
different
report,
and
then
I
I
think
I
was
talking
about
supporting
multiple
sources,
because
if
we
support
multiple
sources,
then
you
can
kind
of
specify
to
two
repos
and
you
can
point
help
chart
in
one
repo
to
file
in
another
repo,
and
then
there
was
a
kind
of
pushback.
A
That's
yeah
and
I
to
be
honest.
I
I
do
not
know
if
we,
I
don't
remember
if
we
decided
to
don't
do
it
at
all,
or
we
just
decided
to
prioritize
helm
value
files
in
a
different
repo
and
differ
like
delay.
Multi-Source
application
source,
that's
okay!
This
is
what
I
remember.
I
think
the
conversation
happened
like
a
month
ago.
I.
D
Just
wanted
to
add
one
thing
so
in
the
pr
which
we
were
looking
before
the
hem
chat.
One
like
I
had
gone
through
that
one
too,
where
jesse
had
mentioned
that
we
want
to
incorporate
multiple
sources,
so
I've
linked
that
comment
here
like
there
was
a
lot
of
things
to
go
through
for
this
one
proposal.
I
think
I
at
a
point.
I
was
even
confused
how
many
docs,
or
how
many
pr's
I'm
going
through
or
a
show,
because
there
were
a
lot
of.
I
think
the
discussion
is
on
from
okay.
D
Yeah
yeah,
like
I
remember
in
the
issue
he
mentioned,
that
we
don't
want
to
go
ahead,
but
then
I
saw
this
comment
when
I
changed
my
proposal
from
just
helm,
supporting
even
multiple
sources,
so
yeah.
F
I
think
the
number
of
people
who
want
full-on
multi-source
applications
is
pretty
small
compared
to
the
number
of
people
who
want
helm,
plus
values,
and
I
think
the
level
of
complexity
that
multi-source
would
introduce
would
make
it
you
know,
take
longer
to
implement
more
bugs,
more
documentation,
etc.
F
A
I
kind
of
I
don't
have
strong
opinion,
but
I
know
I
have
a
feeling
that
internally,
the
amount
of
code
changes
internally
would
be
the
same
and
then
so
basically
we
would
have
to
do
the
same
amount
of
work
to
clone
multiple
repos
and
then
so.
In
order
to
convert
it
into
multi-source,
we
would
have
to
change
api
and
expose
a
bunch
of
settings
to
user.
A
So
what
I'm
trying
to
say
is,
I
think
we
can
build
helm
value
files
and
that
once
it's
there
aging
multiple
multiple
sources
would
be
built
on
top
of
it.
So
yeah
and
it's
not
like
we
win,
we
build
one
or
another.
We
can
start
from
home
value
files
and
and
basically
once
it's
supported
the
rest
will
be
to
you.
C
Know
define
it
also
also,
I
think,
the
beauty
in
when
when
we
so,
you
said
at
the
beginning,
probably
or
I
don't
know
who
said
it,
I
think
he
was
it.
You
mentioned
that
jesse
said
that
the
he
was.
C
He
was
kind
of
opposing
that
because
the
only
use
case
was
harm
values
from
git
right,
but
I
I
see
other
use
cases
as
well,
so
I
I
have
heard
people
asking,
for
example:
is
it
possible
to
run
two
plugins
right
so
or,
for
example,
so
say
you
have
like
the
aggro
city
vault
plug-in
right?
So,
but
you
you
have
a
hum
chart
and
you
want
to
store
that
only
the
the
secret
involved
right
and
would
have
like
a
vault
plug-in
render
that
secret.
D
C
C
C
A
Yeah
that
we
would
need
to
kind
of
change
all
components
like
ui.
C
D
C
All
the
reconciliation
logic
would
have
to
consider
more
than
than
one
source
as
well
right.
So.
A
But
I
think
to
to
be
honest.
I
like
it
I
mean
I
like
multi-source
proposal
and
I
felt
like
I
was
convinced
it's
too
too.
A
Too,
you
know
difficult,
but
how
do
okay-
let's
say-
let's
say
everyone
that
is
in
the
I
mean
some
people
here
in
that
meeting
like
it
like
to
do.
But
do
you
think
what
should
be?
Is
it
still
fair
to
say
that
we
should
attack
film
value
files
in
a
separate
depot?
You
know
first
and
then
work
on
multi-source
support,
or
is
it
better
to
try
to
do
multi-source
and
kind
of
helm
would
be
just
subsets.
You
know
home.
Very
files
would
be
just
yet
another
use
case
so
by
the
future.
D
D
A
F
Yeah,
given
the
sheer
volume
of
people
wanting
the
the
helm
plus
git
specific
feature,
I
think
it
makes
sense
to
do
phases
and
start
with
that.
One.
I
think
we'll
have
to
keep
in
mind
like
the
spec.
Will
change
and
we'll
have
this
sort
of
weird
artifact
of
there's
something
within
a
helm
source
that
specifies
the
external
gear
repo
and
then
we're
going
to
ask
people
to
shift
over
to
start
using
multiple
sources
instead
or
support
those.
At
the
same
time,
I.
A
A
D
A
I
I
will
ping
jc
offline,
so
in
you
know
like
after
the
meeting
just
just
slack
him
and
and
see
if
he
objects
and
if
because
I
think,
pretty
much
everyone
who
was
who
cared
about
this
feature
recently,
I
think
in
that
call
except
jc.
We
just
need
to
maybe
update
him.
A
A
All
right,
I
think
we
can
move
on.
We
have
25
minutes
left
next.
Topic
is
stale
prs
label.
I
know
that
pasha
edits
that
topic
yeah.
H
Yeah,
I
didn't
describe
it
so
much,
but
I
would
cover
it
in
few
words.
So,
actually,
last
week
I
have
worked
on
review,
pull
requests
that
style
that
stay
here
for
few
years
and
like
my
question,
I
discussed
it
already
with
alex,
but
my
question:
if
we
can
mark
them
somehow,
because
in
most
of
them
contributor
not
responding
or
it's
candidates
to
be
closed,
so
my
assumption,
maybe
we
can
bring
some
labels
that
we
can
mark
like.
Okay,
we
will
close
this
pull
request
soon.
H
A
I
yeah
I
like
it.
I
like
the
proposal.
The
reason
is,
I
I
mean
we.
I
don't
think
we
can
all
have
a
meeting
and
triage
these
issues
together,
3
pr's
together.
I
know
that
pasha
was
doing
it,
but
we
can
do
it
asynchronously
offline.
Let's
say:
if
pasha
applied
that
label
to
a
bunch
of
pr's
that
he
wants,
he
thinks
should
be
closed
and
then
can
not
available.
E
A
few
days
ago,
I
did
some
investigation
on
using
a
stale
boat
for
that,
and
I
remember
seeing
a
lot
of
possibilities
on
how
to
configure
it.
I
just
wanted
to
understand
if
stale
bot
is
it
was
considered.
I
see
that
we
have
a
file
in
our
project,
but
it's
not
really
running.
I
think
there's
a
misconfiguration
somewhere,
but
stable
book
can
be
used
to
to
help
us
to
to
to.
H
H
A
Do
you
know,
is
it
possible
to
configure
stillboard
to
only
worry
about
pr's
that
have
a
label,
so
I
I
was
thinking
basically.
Maybe
it
can
do
what
we
are
trying
to
do
right
now,
but
we
were
thinking
that
humans
would
do
it.
You.
E
One
thing
I
I
I
remember
seeing
is
the
ability
to
configure
steel
but
to
just
apply
labels
on
specific
situations
that
we
configure,
and
then
we
can
filter
out
those
labels
and
do
human
interaction
for
actually
closing
the
things
we
want.
We
we.
D
D
E
I'm
saying
is:
stale
boat
needs
looks
like
a
real
good
tool
and
it
provides
a
lot
of
configuration
for
us
to
tweak
and
make
it
behave
as
we
want.
So
why
not
just
making
usage
of
it
yeah?
I
think.
A
I
would
do
it
as
you
know,
like
second
step
right
now.
We
just
need
to
clean
up
first,
it's
just,
we
have
130
appears
and
they
are
open
because
we
failed
to
configure
sailboat
long
time
ago,
and
so
we
just
kept
accumulating,
and
now
I
I
don't
feel
confident
to
close
all
of
them
in
bulk.
It
feels
like
we,
you
know,
need
to
at
least
take
a
look.
H
G
C
Yeah,
while
we're
discussing
about
stairbot,
I
I
we,
we
had
it
working
once
for
issues
right.
C
I
think
it
stopped
it
stopped
working
at
some
point
in
time,
because
I
have
not
seen
stable
around
for
like
a
long
time
and
we,
if
you
look
at
the
issues,
we
have
a
thousand
issues
open,
yeah
and
somehow
stay
about
when
bonkers
somewhere,
but
maybe
so
I
think
leo
has
suggested
maybe
putting
a
label
on
those
stories
and
going
over
the
menu.
But
steroid
can
also
comment
on
issues
right.
C
So
maybe
maybe
maybe
this
this
would
be
a
great
place
to
to
have
stay
aboard
like
commenting
on
the
pr
like
hello,
dear
contributors,
sorry
that
we
have
not
been
taking
a
look
at
this
for
so
long
or
that
it's
for
some
reason
got
so
stale,
and
is
there
still
interest
from
your
side
to
have
this
merged
or
something
like
that,
so
that
we
don't
have
to
do
it
manually?
C
H
Yeah,
I
I
think
stillbot
is
good,
just
not
in
first
touch.
Maybe
we
should
refine
them
first
time
we
should
handle
it
manually
and
after
we
can
use
this
bot
for
future
pull
request.
Something
like
this.
I
already
create
documents
with
where
I
like
described
all
the
problems
and
what
can
be
done
here.
I
go
over
all
the
requests,
so
I
I
already
see
that
a
good
bunch
of
them
can
be
nourished.
Just
it's
just
require
like
some
additional
re-opening
them
by
by
active
contributors
and
finish
small
steps
here.
A
A
Let's
say
we
have
a
label
and
then
whoever
is
doing
pr
triaging
like
pasha
was
doing
it
last
week
can
apply
that
label
to
pr's
that
he
thinks
should
be
closed
because
they
are,
you
know,
no
longer
irrelevant,
and
then
we
have
one
week
of
grace
period
and
any
one
of
us
can
use
that
label
to
find
peers.
A
And
then
you
know,
comment
review
whenever
it's
convenient
to
us
and
maybe
request
to
keep
them
open.
Some
keep
open
some
of
them
and
if
no
one
comments,
the
prs
will
be
closed
either
by
sailboat
or
manually
after
like
one
week
does
it
sounds
fair,
I'm
just
looking
trying
to
find
some
way
for
us
to
get
rid
of
100
pairs
in
a
good
way.
A
I
was
just
saying:
let's
say:
if,
if
paschal
spend
next
week
and
basically
apply
a
label
to
pull
requests
from
that
list
yeah,
he
would
apply
that
label
to
prs
that
he
thinks
should
be
closed
and
then
and
then
we
have
one
week
to
react.
We
can
you
know,
review
that
labeled
list
and
maybe
remove
the
label
or
comments.
I
A
C
E
The
label
name,
so
you
mean
you're
gonna,
go
over
133
prs
next
for
the
next
week.
Meeting
pasha
is
that
what
you're.
A
Cool
should
we
create
label
right
now,
just
so
that
we
all
know
what
the
label
name
is.
Maybe
just
stay
like
stale.
C
Let's
think
for
a
moment,
I'm
trying
to
browse
is.
Is
it
is
it
so
I
mean
what's
what's
the
purpose
of
the
label?
It's
it's
like
a
candidate
for
closing
right.
Yes,.
C
A
Let's
look
for
it,
we
have
need
help
and
we
use
it
for
bugs
kind
of
that
label
is
to
attract
ex.
You
know,
contributors
who
wants
to
looking
for
work.
Sorry.
C
C
C
A
A
C
A
Yeah,
oh,
it
looks
like
looks
like
they're
still.
Boat
is
looking
for
that
label
and
and
closes
it.
So
maybe
humans
applied
it
and
then
the
boat
kind
of.
C
Yeah,
no,
I
think
it's
used,
so
the
the
label
is
also
applied
by
sailboat
and
and
and
then
probably
it
goes
and
looks
when
this
label
was
applied
and
then
and
closes
it.
A
I,
like
it,
it's
you
know
whatever
people
in
kubernetes
repository
doing
usually
it's
well
tested
and
and
that's
what
is.
A
D
A
All
right,
10
minutes
left
and
one
more
pr
from
yeah
one
more
proposal:
sorry
for
publishing
about
controller
charging.
D
Actually,
I
just
wanted
to
get
that
up
like
if
anyone
gets
time
would
go
through
the
proposal.
Talk
for
sharding
application
controller
so
like
if
anyone
gets
time
after
2.3
like
it
will
be
great.
I've
just
got
up
the
dock.
D
The
proposal
dog
just
tells
you
regarding
either
we
want
our
leader
election
for
the
application
controller
like,
or
we
want
to
create
different
processes,
a
separate
process
for
the
for
this.
D
It's
just
a
refrigerator
like
the
main
idea
behind
this
is
I
wanted
a
little
bit
discussion
like?
Is
the
community
even
interested
in
working
or
do
they
want
this
feature.
A
I
know
that
a
lot
of
people
ask
about-
and
I
know
that
I
personally
feel
like
I'm
with
this.
I
made
a
mistake.
I
I
changed
controller
from
deployment
to
stateful
set
and
it
was
done
kind
of
to
get
cheap
to
implement
controller
charging
in
a
cheap
way.
A
So
basically,
I
would
just
work
on
on
on
improving
this,
just
to
switch
away
from
stateful
setback
to
deployment
and
along
the
way
I
would
work
on,
maybe
adding
aging
achieve
so
yeah.
So
what
I
was
trying
to
say
there
is
already
a
pain,
even
you
know,
just
because
we
use
stateful
set
it.
It's
really
not
great.
D
A
And
I
think,
then,
later
after
we
released
the
changes,
some
users
told
us
that,
oh
just
because
you
switch
to
stateful
set
that
makes
it
more
difficult
to
you
know
to
make
to
run
controller
now
and
and
then
basically,
I
think
we
were
looking
for,
like
some
additional
reasons
to
switch
back
to
deployment,
because
it
was
like
kind
of
still
acceptable,
not
great,
but
not
not
too
bad
if
we
yeah.
So
I
think
I'm
looking
for
like
reasons
to.
A
You
know
doesn't
very
exciting
to
just
switch
back
to
deployment
for
the
sake
of
keep
using
deployment
and
and
then,
but
if
we
work
on
something
bigger
like
we
could
say.
Yes,
now
we're
switching
back
from
from
stateful
set
to
deployment
and
we're
introducing
aj
that
make
more
sense
kind
of.
D
Yeah
I
there
was
like
the
main
reason
was:
I
saw
in
rollouts
we
have
moved
to
leader
election,
like
I
had
seen
a
change
there.
So
previously
I
was
just
thinking
about
adding
processes,
but
just
saw
the
change
in
leader
election,
so
I
thought
either.
I
have
given
two
proposals
out
here
like
we
like
I've,
just
been
the
previous
proposal,
which
was
there
in
one
of
the
issues
in
argo
cd
for
proposal
two
and
the
first
one
was
creating
a
different
process.
D
J
J
A
J
My
I
mean
my
take
on
this
proposal
is
that
using
a
leader
election
would
be
sufficient
in
majority
of
the
use
cases
going
with
the
sharding
approach,
it
might
make
the
application
controller
manager
a
little
bit
more
complex
to
manage,
but
it
will
be
able
to
scale
the
number
of
applications
really
high.
A
Problem
is
that
we
already
have
shouting
it's
there
already
and
it
makes
it
more
difficult
to
implement
he,
and
I
think
we
like.
We
cannot
just
drop
shading
because
we
like
we
use
it,
and
it
just
makes
it
more
difficult.
To
be
honest,
I
I
don't
I
I
cannot
tell
on
the
top
of
my
head,
how
how
exactly
it
could
be
implemented
and
charging,
so
you
would
have
to
run
like
let's
say
if
you
have
five
shards,
you
would
need
to
around
10
and
10
replicas,
like
10.
D
A
We
really
want
it,
but
we
need
to.
I
think
we
need
to
discuss
if
we
have
bandwidth
to
work
on
it
in
you
know,
in
in
the
next
release
or
not
yeah,
I
don't
know
how
like
typically
okay,
maybe
we
are
doing
it
wrong,
but
so
far
I
feel
like
we
usually
we
would
jump
on
a
proposal
finalize
it
and
immediately
jump
and
work
on
implementation,
and
that's
why
I
think
a
lot
of
proposals
like
we
have
this.
A
You
know
namespace
mode
proposal
and
I
think
we
keep
delaying
it
because
we
already
have
things
to
do
in
the
next
next
release
and
I
have
a
feeling
once
we
agreed
that
okay
in
the
next
release,
we
should
work
on
implementing
the
name
spacing.
Then
we
will
jump
on
namespace
namespace,
mod
proposal,
polish
it
and
implement
immediately,
and
maybe
it's
not
the
right
way
to
to
to
you
know,
go
ahead,
go
about
proposals
so
and
then
same
thing
might
happen
with
this
one.
I
think
it's
to
be
honest.
A
G
They
are
done
by
2.3,
it's
2.4
and
then
I
I
at.
A
Least
I
use
roadmap
talk
a
lot
just
to
you
know
refresh
myself
about
what
we
agreed
to
work
on
in
next
release.
I
I
really
want
to
add
this
topic.
You
know
that
you
know
basically
the
link
to
your
proposal
and
one
you
know
couple
lines,
couple
sentences
interrupt
map
document
and
that
will
be
you
know.
If
we
have
it
there,
it
will
be
a
continuous
reminder
and
it
kind
of
makes
a
feature
a
candidate
for
for
like
for
common
release.
A
A
J
I
have
one
issue
that
I
just
bring
in
the
chat.
This
is
regarding
the
bearing
child
internship
in
the
alpha
cd
application.
J
I
just
wanted
to
know
if
it
you
know
if
there
is
any
consensus
on
whether
the
approach
or
the
proposal
that
is
already
given
is
good
there
or
I
don't
see
any
comments
on
that
issue.
A
We
we
can
discuss
it
really
quick,
I
think
we
spoke
about
it
and
we
maybe
just
met,
didn't
miss.
We
maybe
didn't
notice
the
recent
updates,
but
I
think
we
agreed
that
we
want
to
build
it.
Basically,
we
spoke
about
that
feature.
We
added
it
into
roadmap
and
we
had
quick
discussion
and
yeah.
So
I
think
we
even
okay,
we
are
planning
to
to
have
it
in
2.4.
A
Thank
you
yeah,
but
it's
just
not
like
no
one
was
actively
working
on
it
because
it's
not
part
of
truth,
t
and
probably
not
part
of
2.4,
but.