►
From YouTube: Argo Contributors Office Hours Jan 27th 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
Hi
everyone
welcome
to
this
contributor
meeting
today,
I'm
gonna
be
your
host
and
starting
off
with
triage
is
hottie
on
this
call.
I
don't
see
him
but
yeah.
Let's
go
up
with.
A
B
Yeah
so
previous
week,
I
didn't
there's
nothing
in
particular
with
respect
to
github
discussions,
but
there
was
a
github
issue
though,
and
many
people
have
reported
this
issue
that
talks
about
ago
city,
not
using
the
credentials
for
private
health
chart
dependencies.
So
yeah
that's.
So
I
wanted
to
highlight
this
because
I've
seen
many
similar
issues
on
github
related
to
this.
So
yeah,
that's
the
only
one.
That's
the
only
issue
that
I
wanted
to
highlight.
C
I
think
I
I
was
not
a
moderator,
but
I
also
noticed
you
know
periodically
people
comment
in
the
issue.
Do
you
know?
Is
it
basically?
I
had
one
theory:
we
quietly
changed
the
behavior
in
the
previous
release.
I
think
basically,
we
noticed
that
there
was
a
security
security
back
where
creeper
server
was
sending
all
possible
health
credentials
while
generating
all
possible
credentials
for
home
repositories
and
and
then
we
fixed
it
so
now,
repo
server
gets
helm
credentials.
C
B
Actually,
I
tried
to
reproduce
that
reproduce.
This
issue
I
assigned
myself
to
one
of
the
issues,
but
I
couldn't
reproduce
it
so
yeah.
I
I
think
I'll
have
to
investigate
more.
As
you
said,
alex,
it
might
be
something
related
to
documentation.
C
But
basically,
there
is
no
easy
way
for
people
to
receive
so
controllers
supposed
to
send
credentials
to
all
our
whole
home
repositories
to
the
ripple
server
and
it
filters
out
all
the
all
the
ripples
which
are
not
listed
in
a
project,
and
it's
all
just
you
know,
done
in
the
background
and
you
have
no
way
to
see
which
credentials
were
sent
which
was
not
yeah
so
but
think
so.
C
B
Thanks
alex,
I
think
one
of
the
you
have
already
assigned
one
of
the
issues
to
2.4
okay,
so
this
might
be
duplicate.
We
can
verify
once
and
close
it.
A
Okay,
thanks
chitan,
so
going
forward.
Let's
select
the
the
next
primary
and
secondary
for
next
week,
any
volunteers
for
primary
next
week.
D
E
Timer
there's
a
first-timer
in
chat
willing
to
be
secondary
if
you're
willing
to
give
it
up.
D
F
F
A
A
Alex
you
have
a
topic
here:
it's
about
the
release
candidate
for
argo
cd
2.3.
You
want
to
take
a
lead
on
this
one.
C
All
right,
so
I
just
wanted
to
double
check
with
people
that
no
one
is
working
on
any
anything
critical
that
you
want
to
get
into
to
the
three
degrees
right
now.
There
is
two.
C
Is
looks
like
we
did
some
working,
you
know
breaking
changes
in
in
slug.
Basically,
there
is
a
bug
that
is,
reproducible
and
already,
I
think
pasha
is
working
on
fixing
it
and
there
is
also
a
pull
request
that
should
be.
I
want
to
try
to
merge
it.
Basically,
it's
a
it's
a
pr,
that's
supposed
to
let
people
simplify
using
cargo
cd.
C
These
tools
like
get
it
yeah
and
that's
so
to
basically
we're
working
on
two
of
those
things,
and
then
I
was
thinking
to
create
release
candidate
branch,
and
let
me
know
please
I
guess,
before
the
end
of
today,
if
you
want
to
get
something
to
see,
we
still,
I
mean
it's
not
going
to
be
released,
it's
just
going
to
be
a
branch,
so
we
still
can
cherry
pick
whatever
we
like.
A
Okay,
thanks
alex
any
questions
about
this
one,
anyone,
no
okay,
so
moving
forward.
We
have
a
question
from
hong
scheduled
for
the
very
next
rollouts
release.
Hunk
want
to
elaborate
a
little
bit
better
better
than
this.
G
I
I
know
I
can
talk
with
jesse.
Jesse
is
not
here,
but
I
do
answer.
I
have
several
people
asking
me
about.
When
will
be
the
next
round
release,
I
think
the
milestone
is
talking
about
the
january.
The
31st
there
just
like
trying
to
get
idea
like
where
we
are
like
does
alex
so
andrew.
Like
do
you
guys,
have
some
ideas,
so
I
can
like
reply
to
the
community.
C
Had
an
idea,
oh
harry,
has
it
he's
not
here,
but
I
know
that
we
spoke
about
it
recently.
I
don't
remember
the
date.
My
impression
was
that
it's
supposed
to
be
very
soon.
Basically
it's
in
the
week.
A
Okay,
thanks
hong
all
right
that
wraps
up
for
our
topics
any
last
minute
topic.
Somebody
wants
to
bring
it
up.
H
I
just
had
one
topic,
so
this
is
regarding
the
stale
prs.
So
last
week
I
was
just
going
through
the
pr's.
There
are
a
few
pr's
like,
which
are
one
year
old,
just
wanted
to
know
like
how
we
want
to
deal
with
those
pr's,
because
we
have
around
100
pr's,
which
are
outstanding,
so
one
thought
I
had
was
requesting
the
user
if
he
or
she
is
still
interested
in
working.
If
not,
we
could
just
give
one
or
two.
C
C
You
know,
try
to
do
triaging
both
again
and
pasha
was
going
through
prs
one
by
one.
I
think
he
was
going
to
just
come
up
with
a
dog
to
at
least
find
easy,
easy
ones
that
can
be
closed
just
because
they're
all
too
absolute,
and
I
think
we
didn't
at
least
one
idea
was
not
too
close.
C
C
We
can
have
another
discussion
and
maybe
look
for
volunteers
who
wants
to
bring
them
back
to
life
and
but
basically
I
feel
like
it
was
my
new
year
resolution
to
try
to
clean
up
issues
again
and
npr's.
I
know
that
jan
was
going
to
participate
as
well.
We
spoke
about
it.
We
wanted
to
basically
do
the
same
thing
with
issues
look
for
ones
which
definitely
should
be
closed.
Try
to
get
rid
of
duplicates
then
hopefully
deduce
number
of
things
like
number
of
issues
in
general.
D
Yeah,
thank
you.
Yes,
I
I
I
have
plans
to
spend
actually
next
week
for
at
least
categorize
all
these
pull
requests
and
after
we
can
review
it
here
and
definitely
we
all
can
participate
to
close
them
or
manage
them
and
whatever
we
want.
But
actually
my
plan
was
somehow
to
group
them
and
see
what
we
can
do.
H
I
had
one
more
thing
here,
so
there
are
a
few
pr's
which
are
like,
pending
with
the
ci
jobs
because
of
the
first
time
contributors.
So
are
we
planning
to
like?
Are
we
planning
to
create
a
list
for
that,
and
just
I
don't
know
like
started
ci
jobs,
at
least
for
those
pr's
or
I
think
or
categorizing
them,
and
then.
C
It
will
take,
I
know,
15
20
minutes
to
to
do
it,
so
I
can
do
it
and
okay,
what
will
really
help
like
if,
if
we
have
reviewers
who
are
going
to
look
into
those
pull
requests,
maybe
if
you,
if
you
comment
and
then
I
will
get
github
notification,
so
I
will
know
at
least
which
pair
makes
sense.
To
kind
of
you
know
to
approve
this
yeah.
I
I
want
to
discuss
on
notification
engine
pr
that
I
mentioned
in
the
chat.
This
is
essentially
to
come
up
with
a
solution
where
we
can
have
a
common
notification
channel
for
multiple
triggers.
I
C
Okay,
I
think
so
I
think
the
short
summary
for
everyone
is.
We
have
a
problem
in
in
notification
engine
I
mean
it's
not
a
problem.
Basically,
when
there
is
a
feature,
request
or
improvement
request
right
now,
users
have
to
create
multiple
notations
one
per
subscription
and
it's
just
kind
of
redundant
and
annoying,
and
the
suggestion
is
to
improve
it
a
little
bit
and
one
way
to
improve
it
was
to
kind
of
put
more
data
into
notification
insert
into
annotation
name.
C
But
this
approach
has
an
issue
because
annotation
name
is
very
limited,
I
mean
basically,
it
cannot
be
very
long
and
so
only
other
way
to
solve
it,
at
least
in
my
opinion,
was
to
put
more
data
into
annotation
value
and
it's
really
difficult
to
represent
complex
data
as
a
form
of
just
string.
So
instead
I
said,
let's,
let's
switch
just
to
yaml
and
and
then
consider
introducing
first
class
fields
into
the
application,
crd
or
low
crd.
It
can
be
done
independently,
yeah.
C
That
was
the
proposal,
and
then
I
saw
your
response
already,
but
I
just
didn't
get
time
to
reply,
so
I
think
you're
suggesting
an
improvement
right.
You
want
a
little
bit
more
compact
kind
of
way.
I
Just
to
avoid
you
know,
duplicating
the
destinations
with
the
different
set
of
triggers
if
we
can
combine
the
triggers
and
have
a
common
destination
that
will
optimize
the
amount
of
content
that
goes
into
the
annotation.
C
Okay,
so
the
biggest
changes
that
you
want,
your
triggers
and
do
you
mind
if
we,
because
it's
yeah
it's
already
structured,
is
it
okay?
If
we
change
trigger
fields
into
a
list
array,
so
would
you
be
friendly?
Basically,
if
we
just
have
square
brackets
around
this,
so
it
so
it
would
not
be
just
a
string,
it
would
be
all
right.
C
I
think
I
I
like
it
here.
I
think
I
proposed
the
first
very
end,
but
it
I
was
not
like
married
to
it.
I
think
yours
is
better
if
this
is
less
less
typing.
C
Okay-
and
I
ask
I
I
remember-
I
asked
jc
what
he
thinks
about
it,
so
I
think
he's
asking
like:
why
didn't
we
do
it
from
beginning?
I
will
reply
to
him,
but
I
guess
the
reason
was
that
initially
the
structure
we
had
was
for
just
argus
identifications,
which
were
a
separate
project,
so
it
was
impossible
to.
It
would
be
strange
to
have
a
field
for,
for
example,
in
argo,
cd
application,
and
then
only
third
party
project
uses
it
now
when
we
merged
you
know
engine
and
rcd.
C
That's
why
I
was
proposing
to
support
first
class
field,
but
I
guess
I
would
do
it
in
steps.
I
would
do
what
you
have
here
already
like
this
annotation
stuff
and
then
maybe
in
the
next
pr
or
even
like.
Basically,
the
annotation
would
be
enough
and
we
can
decide
when
to
introduce
the
first
field.
So
first
class
field
later.
C
Okay,
then,
I
will
just
in
case
you
reply
here,
so
we
don't
forget
so
basically,
I'm
kind
of
agreeing
with
your
suggestion,
yeah
the
only
changes
to
instead
of
a
string.
A
Thank
you,
javi.
Anyone
else
with
a
last
minute
topic,
wanna
bring
it
up.
F
Oh
great
yeah
alex
I
just
I've
sent
off
br
lincoln.
I
think
we
would
like
to
have
this
feature
in
if
you
had
time
to
review
it.
It's
a
front-end
feature.
A
F
A
F
C
I
think
it's
basically,
this
is
probably
one
of
the
things
that
we
wanted
before
we
created
really
right.
That's
what
I
was.
I
think
I
was
looking
for.
This
type
of
you
know
changes.
So
if
it's
kind
of
pretty
much
done
already,
it
would
be
a
shame
to
don't
get
it
into
okay.
Thank
you.
So
I'm
adding
it
to
my
list
and.
F
A
Should
we
should
we
target
this
for
2.3
alex
here?
I
think
it's.
C
C
Before
yeah,
I
forgot
to
ask
about
it,
but
basically
I
think
it
would
be
last
time
pasha
and
kostias
helped
with
you
know,
release
blog
if
it
helped
a
lot
so
yeah.
Maybe
we
can.
D
C
C
Okay,
so
yeah,
and
I
guess
you
know
it
like
the
people
who
here
at
least
we
should
make
sure
that
features
that
you
want
to
be
mentioned
in
release
blog
should
be
there
yeah.
If
you
add
a
paragraph
of
your
future
and
then
you
know
just
keep
it
empty,
but
at
least
we
won't
forget
to
have
a
depth,
and
I
think
I'm
going
to
create
the
doc
right
now
and
I
will
send
link
with
you
a
little,
so
you
can
have
it
in
so.
C
A
A
All
right
anything
else.
A
Okay,
so
if
we
don't
have
any
other
topic
I'll
give
you
back
this
15
minutes
or
so
in
your
day
and
we'll
see
you
next
week
thanks
everybody.