►
From YouTube: Argo Contributors Office Hours 23rd Sep 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
All
right
good
morning,
so
let
me
start
from
sharing
the
document
for
today's
meeting,
so
we
have
typical
items
for
every
meeting.
I
guess
you'd
write
it
usually
yeah,
you
can
feedback
so
go
for
it.
B
So
I
think
in
the
last
week
we
have
hong
and
pasha.
So
do
you
want
me
to
share.
C
Yeah
I'm
here
so
I
thought
I'm
answered
on
a
lot
of
github
questions.
Actually
in
this
week
we
hadn't
so
much
new
questions.
We
had
only
four
but
I
tried
to-
and
I
didn't
know
answers
on
them,
but
I
tried
to
answer
on
few
questions
and
strike
and
I
got
success
here
so
actually
this
time
I
helped
somehow.
So
I
answered
a
few
questions,
but
not
in
github
in
github
I
didn't
know
and
yeah.
I
saw
that
the
home
console
on
questions
in
github.
B
I
mean
anything
that
is
noteworthy
to
add
it
to
the
milestone
like
any
feature
or
bug,
or
it
is
just
the
normal
discussions.
C
No,
it
was
just
like
in
my
case,
it
was
mostly
questions
like
it
was
question
about
work,
how
to
work
with
jvt
tokens
that
are
good
generate
first
one.
Second,
it
was
asked
about
explanation
how
our
synchronization
flex
is
working
mainly
about
force
what
it
is
doing.
So
it
was
questions
of
the
answer.
A
Okay,
okay,
it
might
be
that
I
stole
some
of
the
so
the
issues
that
we
reported-
and
I
kind
of
I
think,
didn't
give
a
chance
to
push
our
hog
to
respond,
because
so
we
I
think
we
broke
some
couple
of
ocd
core
functionalities
and
hk
like
in
the
edge
cases.
So
we
introduced
the.
A
So,
basically,
argo
is
trying
to
remember
what
master
branch
means
or
you
know
so
it
doesn't
ping
provider
to
to
frequently
and
two
issues
were
reported.
One
is
fixed,
but
one
is
still
open
and
it's
added
to
2.2
milestone,
and
you
know,
if
you
just
look
for
cherry
peak
into
so
we
have
a
label
that
says
jpeg
2.1
and
basically
you
will
find
eight
of
such
issues
already,
and
one
of
them
is
related
to
commit
caching
yeah.
A
B
Anything
that
needs
to
be
like
discussed
here
like
any
discussion,
any
issues
or
or
any
any
other
bugs
or
features
that
needs
to
be
discussed
as
a
part
of
rising.
D
I
do
have
one
issue:
who
is
sharing?
Could
you
open
up
that
seven,
two,
five,
nine,
the
second
from
the
last
line,
yeah
open
that
issue.
I
want
to
have
a
very
quick
discussion,
so
the
this
this
this
person
is
using
the
operator
and
this
operator
we
are
creating
a
plot.
The
pod
restart
policy
is
actually
never
and
based
on
our
code.
If,
if
it
is
never
so
we
all,
it
will
be
always
marked
as
progressing
so
it's
never
been
said
done
or
finished.
D
So
this
is
actually
she
founded
the
code
which
is
great
and
you
can
see
the
restart
policy.
If
it
is
never
on
failure,
we
will
always
mark
the
part
status
to
be
health
status
progressing
forever.
D
I
think
this
was
designed
more
for
the
job,
maybe
the
job
or
one
time
thing.
However,
I
don't
know
how
to
handle
this
case.
D
So
if
you
scroll
down
more
there's
some
discussion
more
so
basically,
I'm
asking
why
why
they
are
doing
the
never
and-
and
she
actually
posted
is
the
operator
will
be
charging
the
life
cycle
of
that
part
means
that
they
are.
Okay
with
never
but,
however,
that
means
in
our
rlcd
ui
all
the
status
we
will
see.
It's
always
been
progressing,
never
been
finished.
D
I
don't
know,
what's
what
we
can
do
here.
To
be
honest,
so
that's
why
I
want
to
bring
it
out.
E
Hong
hong,
this
is
also
a
case
for
work
workflows
and
for
data
flow
as
well
that
their
pods
they
always
they
never
get
to
a
healthy
state.
Even
though
they
then
you
know
they
are
contain
already
initialized
and
all
the
other
things
and.
E
Because
they
don't,
they
have
a
restart
policy
of
on
failure.
Rather
than
and.
D
F
E
They
they
they're,
not
exiting
with
exit
status.
Zero
is,
is
acceptable
for
them,
because
it
indicates
that
they
they
weren't
actually
long-running
pods.
They
were
short-running
pods,
okay
and
it's
it's
only
when
they
exit,
can
you
say:
they're
a
short-running
pod,
unfortunately
yeah.
I
I
mentioned
this,
but
I
don't
feel
like
it's
an
awful
thing,
because
it's
almost
like
a
usability
thing
rather
than
a.
G
Ra
it,
I
don't
think
this
contributes
to
the
aggregate
health
status
of
the
application,
if
I'm
not
mistaken,
so
in
the
ui
yeah,
you
see
them
with
a
little
blue
spinning
thing,
but
as
application,
because
they're
launched
by
some
other
resource
object,
they
would
still
be.
The
aggregate
side
would
be
whatever
it
is.
D
Our
status
is
fine,
it's
it's
just
like.
I
think
the
user
experience
feeding
thing.
E
F
G
D
F
G
All
right,
I
I'm
inclined
to
say
this-
is
kind
of
by
design,
but.
D
D
A
Maybe
if
we
consider
it
edge
case,
we
can
also
consider
improvement
in
a
health
status
customization.
So
right
now,
users
can
only
choose
between
custom
health
check
or
built-in
health
check,
and
then
I
was
thinking
to
propose
you
know
a
little
bit
of
improvement.
So
what?
If
we
change
our
custom
health
checks
and
support
returning
empty
value
from
a
custom
health
check
and
if
empty
variable
return,
then
argo
will
fall
back
to
built
in
half
check
if
it
exists,
and
that
will
enable
to
create
kind
of
exceptions.
A
G
I
think
they
can
actually
that's
that's
a
good
idea
for
a
workaround
for
them
to
do
right
now,
because
if
they
have
the
pod,
they
can
write
a
health
check
today
for
the
pod.
Look
at
this
ownership.
Reference
just
decide
that
the
owner
of
this
pod
is
some
crd
and
then
return
whatever
they
want.
It's.
A
E
But
I
mean
there's
a
there's
a
the
to
me
right
this.
It
feels
like
there
are
some
conventions,
because
this
is
not
the
only
time
that
this
has
caused
a
problem.
So
in
a
in
a
in
a
pipeline
there
are.
There
are
three
resources
that
that
have
a
relationship,
a
pipeline
which
owns
steps
and
steps
which
own
pods
and
the
pipeline
and
the
step,
even
though
they
have
status,
dot,
phase
and
state
stock
message.
E
Those
aren't
they're
not
surfaced
at
all
in
the
user
interface
they
just
appear
as
just
squares
and
the
pod
is
kind
of
the
same
thing.
It
kind
of
it
self
reports
its
status,
but
that's
kind
of
basically
ignored,
because
I
guess
the
assumption
is
the
code
can't
make
assumptions
about
what
that
means,
and
also
it's
a
breaking
change
to
start
making
assumptions
about
it.
E
Even
though
they
I
was
going
to
say
that
there's
a
third
way
for
those
resources
to
self-report
their
health
status
you
know
by,
but
that
I
mean
that's
kind
of
what
they
already
do.
They
already
report
their
status
by
saying
you
know
here
is
my
you
know.
I
have
status
and
message
and
you
can
use
those
except
because
the
you
know
those
aren't
really
correct
for
a
pod
because
of
historical
reasons.
E
A
E
So,
yes,
I
mean
one
is
a
cosmetic
problem,
so
I
don't
know
how
long
we
should
spend
talking
about
it.
The
other.
The
other
thing
is
that
feature
flag
or
configuration
that
could
be
a
feature
on
the
app
itself
like
an
annotation
yeah.
I
was
thinking
what,
if
we
let
users.
A
G
A
I
was,
I
was
thinking
you
know
what,
if
we
create
some
argo
cd,
health
annotation
and
if
user
put
a
transition
on
the
port
or
any
other
resource,
then
argo
cd,
basically
just
don't
check
for
the
health
and
just
take
the
house.
G
C
E
I
don't
think
it
scales,
particularly
well
as
a
solution,
because
it
rises,
requires
every
single
operator
to
piago
cd
compatible
exactly
yeah.
It's
just.
I
mean
that
there's
obviously
like
scaling
horizontal
vertical
there's,
also
like
kind
of
like
scaling
in
terms
of
lines
of
code.
You
have
to
write
and
that
scales
with
order
n
cost,
basically,
which
is
why
it's
better
to
deal
with
it
here,
because
this
code,
just
not,
I
mean,
there's
two
issues
here,
I'm
complaining
about
the
fact
it
doesn't.
E
E
G
The
well
for
when
we,
I
don't
think
we
can
change
the
default
behavior,
because
people
may
rely
on
on
this
for
things
like
resource
hooks,
but
it
there's
something
that
the
user
could
do
today,
which
is
they
can
write
the
health
check
examination
they
may
have
to
re-implement
the
the
logic
that
we
do
in
the
golang
health
check
for
for
normal
pods,
but
for
their
own
operator
created
pods.
G
A
Oh
and
jc,
what
do
you
think?
I
think
I
mean
you
didn't
explain
it
well.
I
think
the
challenge
with
that
approach
is
that,
as
soon
as
you
introduce
a
health
check
for
a
port
you're
responsible
for
all
pods,
it
doesn't
matter
if
you
only
care
about
some
edge
cases,
and
so
what
I
was
trying
to
explain
is
if
we
improve
existing
health
check.
Constabilization
and
improvement
should
be
if
health
check
returns.
Nothing.
It's
an
indication
to
our
ocd
to
try
and
fall
back
to
building
health
check
right
now.
G
Okay,
because
we
actually
give
that
workaround
for
ingresses
that
are
perpetually
progressing
like
the
ones
that
don't
assign
a
low
bouncer,
ip
or
hostname.
A
G
I
had
to
do
that
for
contour
on
on
on
digitalocean.
G
A
Yeah,
so
this
is
supported
as
well
like
if
you
want
to
override
health
checks,
for
you
know
for
everything
you
just
need.
You
should
like
right
now,
you're
forced
to
return
some
health
and
then,
but
in
this
particular
case,
sometimes
you
know
that
your
body
is
an
exception
and
you
want
to
return
overridden
health,
and
sometimes
you
don't
know.
A
Sometimes
it
can
be
a
normal
pod
and
you
want
to
kind
of
benefit
from
from
that
logic,
which
is
implemented
already
and
I'm
proposing
in
this
case
the
custom
health
check
can
return,
nothing
just
an
empty
string
and
argo
cd
would
fail
at
current
version.
It
would
say:
oh,
I
got
a
bad
response
from
custom
health
check
and
I'm
proposing
to
change
it
and
make
cargo
cd
go
and
try
to
use
built-in
health,
for
you
know
corresponding
built-in
health
check.
I
see.
D
I
D
The
the
last
one
ability
to
ignore
the
entire
resource
from
application
config.
This
is
very
interesting.
Another
idea
is
is
that
they
got
these
additional
resources
which
they
don't
want
to
be
contributed
to
the
health
status
or
the
sync
status.
Basically,
don't
care,
and
currently
I
think
there
are
some
features.
If
you
scroll
down
the
certain
feature
in
the
configure
map
we
can
configure
by
the
cr
together,
you
can
yeah,
but
the
there
is
a
problem
here
is
because
they
don't
control
the
cr
directly.
D
So
like
like
this,
they
are
talking
about
the
the
pipeline,
the
pipeline
from
the
tech
tongue.
If
I'm
not
wrong,
so
tech
time
will
create.
The
pipeline
will
create
additional
pod
on
the
and
other
things
and
they
don't
control.
So
they
cannot
inject
that
label
to
it,
but
they
don't
want
they
don't
care
about
their
status.
They
just
want
to
be
like,
like
filtered
out
about
the
the
house
status
from
there.
If
you
scroll
down,
I
know
you
have
this
feature.
We
have
this
feature
scroll
down
to
the
end.
D
D
This
can
be
excluded,
configuring,
the
argo
city,
the
whole
level,
the
the
root
level.
We
can
ignore
the
whole
cr
crd
from
the
whole
rocd
and,
however,
I
think
what
they
are
asking
for
is
whether
we
need
to
expose
this
feature
in
application.
Level
means
if
they
want
to
do
a
per
application,
ignore
they
can
do
that.
Yeah.
G
G
D
G
It
because
there's
no
owner
relationship
that.
A
Another
fix
is
coming,
and
so
I
suspect
those
ports
inherit.
You
know
application
label,
so
it's
kind
of
put
by
put
there
by
mistake
and
we
are
working
on
changing
our
ocd
track
resources.
Oh
yeah,
the
proposal
already
kind
of
we
agreed
on
how
we
want
to
do
it
and
we
switching
from
label
to
annotation
and
annotation
will
have
annotation
value,
is
going
to
have
self
reference
to
resource
name
and
kind,
basically
to
protect
from
copying
so
yeah.
I
can't
argue
that
okay
answer,
I
think
sure,
so.
A
B
And
yeah,
so
I
think,
as
the
discussion
is
over
for
the
next
week,
we
can
fix
on
primary
and
secondary
for
triaging.
Leo
I
mean
leon
and
I
added.
B
That's
second
to
that.
No
problem,
probably,
I
think
we
need
primary
anyone
interested
in
primary.
A
So,
who
is
in
the
list?
Actually
that
was
jan
he's,
not
in
the
meeting
right
now,
but
I
I
honestly
okay,
we
keep
it's
hard
to
keep
traveling,
maybe.
B
Yeah
I
know
like
we
are
rolling
a
lot,
maybe
chatan
we
can
go
to
the
top
right
again
to
see
like
who
we
have
missed
or
anyone
so
danny.
I
already
did
it
last
time.
I
think,
and
abhishek
is
not
sorry
if
he
is
available
jdp
secondary
secondary.
I
think
so.
If
you
go
to
the
top
anyone
else
who
wants
to
be
primary,
like
maybe
chaitan
or
ishita,
anyone.
I
So
I
was
a
moderator
for
one
time
and
I
did
feel
like
so
I
still
need
some
time
to
be
a
primary,
because
I
was,
I
wasn't
able
to
answer
or
address
a
lot
of
issues
so
maybe
as
a
secondary,
yes,
but
primary.
I
think
we
need
someone
more
experience.
H
B
Okay,
anyone
else
wants
to
be
primary,
I
mean
like
primaries,
also
doesn't
mean
that
you
need
to
have
full
knowledge,
and
so
you
can
still
post
in
the
post
in
the
discussions
and
ask
for
help
in
contributing
meetings.
But
that
is
when
we
can
try
it
one
more
time.
One
one
round
together.
B
Then
the
next
one
is
the
release
status.
I
think
jc
made
a
cut
loss.
I
think
on
monday
or
tuesday
on
1.1
jc.
Do
you
want
to
talk
about
it.
G
The
I
think
I
mean
I
already
presented
the
feature
set.
I
guess
what
we
could
talk
about
this.
How
long
should
we
wait
before
we
feel
comfortable
with
the
ga?
I
guess
I
would
ask,
is:
have
you
guys
rolled
it
out
internally
into
it
at
all.
B
G
Think
so
so
one
one
pre-prod
is
so
far
so
good
yeah.
I
think
so.
Let's
go
okay
yeah!
I
would
let
it
bake
for
a
little
bit
and
then.
B
I
think
yeah,
that's
great,
so
I
think
everyone
in
the
contributors
here
please
try
it
out.
1.1
release
cut
is
out
so
it
would
be
great
if
you
can
provide.
B
In
ebooks
or
anything
you
can
fix
it,
so
please
try
and
let
us
know
and
how?
How
do
you
feel
about
the
new
features?
There's
a
blog
post,
also
jc
posted
yeah.
G
I
didn't
publish
the
blog
post
yet
because
I
thought
I
might
time
that
with
the
ga,
but
I'm
open
to
posting
it
earlier.
B
Mean
like
we
can
post
earlier,
maybe
it's
that
way
like
people
might
try
more
right
and
again,
I
am
open
to
sessions.
People
can
try
to
discard
more
if
you
have
a
blog
with
all
the
features.
G
What
do
you,
what
I
know
alex
you
usually
post
the
blog
when
the
first
rc
is
available.
A
J
Yeah,
so
I
mean
it's,
I
I
don't
really
have
a
strong
opinion
either
way.
I
mean
the
pros
and
cons
with
pros
and
cons
with
with
both
of
things.
I
don't.
I
don't
really
have
a
strength
I
think,
for
minor
releases,
even
though
another
one
1.1
is
a
big
one.
I
think
for
minor
releases.
It's
it's
less
of
a
lesser
concern.
J
I
think
when
you
do
major
release,
I
think
it's
might
be
a
little
bit
better
to
save
some
of
the
powder
for
for
the
j,
but
I
I
don't
have
a
strong
opinion
if
it
works
and
we're
actually
getting
like
like
alex
said
we
get
more
people
testing
it.
Then
I
think
it's
worth
doing
it
early.
If
you're
not
really
getting
much
help
out
of
it,
then
you
know
I'd
rather
wait.
B
So
this
is
to
wait
for
ga
right.
G
Yeah,
I
I
guess
I
would
say
this:
we
can,
we
can
wait.
I
think
the
interested
part
is
known
by
that
through
slack,
but.
G
Actually,
why
don't
we
at
least
tweet
about
it.
G
Yeah,
I
don't
actually
do
the
social
media
who
can
help
me
with
that.
F
Okay,
I'll
work
with
you.
B
All
right
next
is
the
milestone
once
so.
I
think
like
last
week,
we
thought,
like
this,
we'll
discuss
at
least
showcase.
What
are
the
milestones
for
1.2
in
this
meeting?
For
me,
for
a
few
minutes
so
monday
has.
I
think
there
are
several
notable
features.
I
think
alex
and
gc
worked
out
on
some
of
the
milestones
here,
but
we
encouraged
other
contributors
also
to
add
which
are
important
or
which
they
wanted
to
be
part
of
1.2
to
get
added
to.
B
I
think
that
I
added
is
with
respect
to
the
stability
of
the
of
rollouts
and
the
dashboard
improvements
like
ui
improvements,
which
I
think
the
extension
framework
is
coming
up
with
and
also
like
some
of
the
enhancements
with
respect
to
the
aws
clb,
and
also
some
improvements
with
respect
to
the
how
the
max
search
and
max
and
availability
work
in
all
the
cases
for
canary.
G
G
One
thought
I
had
harry:
do
you
remember
the
the
the
feature
that's
been
discussed
about
using
a
ping
pong
style
of
blue
green.
G
It
feels
like
that
might
be
important
for
into
its
use
of
I
and
it'll
be
ingresses,
but
I
thought
it
might
be
a
good
candidate
for
someone
on
the
tour
side
to
to
look
into
that.
B
Yes,
I
added
that
actually
to
1.2.
Oh.
B
Yeah
I
did
that
actually
yeah,
that's
right,
okay,
so
yeah
and
yeah,
I
think
yeah
again.
Just
like
do
you
want
to
talk
about
more
of
them
just
relax
feel
free
to
chime
in,
but
I
think
we
have
a
lot
of
stability,
kind
of
features
and
some
of
the
improvements
we
are
coming
up
with
calyx.
Can
you
scroll
down?
There
are
some.
I
think
we
had
helped
yeah.
There
is.
If
you
go
to
the
end,
there
is
a
counter
support
traffic
support.
B
There
are
some
of
the
the
routing
enhancements
are
being
added
to
1.2,
but
again,
any
help
from
the
computer
should
be
great
for
this
kind
of
stuff
yeah.
I
think
that's
pretty
much
it,
but.
A
Yeah,
it's
like
the
shortest
possible
summary:
it's
mostly
stability
and
two
groups
of
enhancements,
one
for
dashboard
and,
second
for
integrating
with
more
you
know,
traffic
and
service,
more
aggressive,
more
matrix
providers,
yeah
and
then
one
more
other
thing
I
would
add.
I
think
this
milestone
is
friendly
for
first-time
contributors.
It
does
have
like
most
of
the
issues
it
is.
This
seems
to
me
good,
for
if
you
want
to
contribute
for
the
first
time.
B
So
we
will
review
these
milestones
for
next
two
weeks,
but
please
bring
up
if
you
have
anything
that
that
is
part
of
this.
But
we
wanted
to
be
part
of
this
milestone.
I
think
there
are
some
which
are
already
in
line
like
availability
for
rollout,
that
is
contributing
from
the
sales
force,
and
there
is
one
on
supporting
the
multiple
traffic
controllers
from
hbo,
so
that
so
there
are
someone
some
conversations
coming
from
outside,
which
are
already
part
of
1.2,
but
please
feel
free
to
bring
in
more
of
yours.
A
Thanks
this
was
your
last
last
topic,
right
yeah,
that
is
my
okay
last
I
I
spoke
about
it
in
the
beginning
of
a
meeting,
so
I
just
put
it
put
the
link
to
the
issues
in
argo
cd,
2.1
milestone,
so
basically
that
link
will
show
you
list
of
regressions
and
bug
fixes
that
really,
basically,
we
need
help
to
fix
them,
and
unfortunately
I
would
not
call
either
of
them
a
simple
one,
but
you
know
if
you
have
time-
and
you
know
how
to
fix
it,
any
of
them
help
will
be
appreciated.
A
A
D
A
I
think
yeah
anything
before
nine
and
I
mean
if
we
can
do
8
15
to
9
15.
That
would
be
better
as
well.
I
would
choose
8
15,
okay,
and
maybe
anyone
has
strong
kind
of
know
about
it.
Anyone
would
not
be
able
to
make
it
if
we
move
it
to
atm.
A
H
A
H
The
entire
time,
actually
it's
between
eight
eight
o'clock
to
nine
o'clock,
so
yeah
I
I
could
just
get
that
and
message
you
alex
regarding
that.
A
A
Yes,
I
mean
in
the
look
yes
and
I
will
make
sure
to
add
this
topic
to
the
next
meeting,
so
we
can,
I
think,
it's
october
1st.
A
Right
so
we'll
revise
it
again
like
next
next
thursday.
B
Have
actually
one
topping,
maybe
so
again
like
in
earlier,
brought
up
like
two
issues
to
discuss
and
all,
but
I
think
that
is
great,
so
you
want
others
also
to
bring
in
if
there
is
any
contribution
that
you
guys
want
to
make
are
looking
at.
B
I
think
that
will
be
a
great
discussions
to
bring
in
and
maybe
any
pr's
that
you're
working
on
to
discuss,
more
probably
from
the
next
week
onwards
we
can
put
like
10
minutes
or
so
to
discuss
on
some
of
the,
even
if
it
is
a
bug
success
we
can
discuss
for
anyone
who
is
working
on
it.
We
can
just
discuss
for
like
five
to
ten
minutes
and
then
mention
like
how.
E
G
Yeah
also,
I
think
we
earlier
we
talked
about.
We
should
leverage
this
time
as
much
as
possible
to
to
arrive
on
any
decisions
or
blockers
that
people
any
blockers
that
people
are
recent
are
doing.
So
if,
if
there's
a
design,
discussion
or
decision
that
needs
to
be
made,
this
is
the
right
form
or
anything.
That's
you
know
that
keeps
blocking
you.
You
can
always
reach
out
earlier
in
slack
and
stuff
to
discuss
it,
but
then,
if
you
need
more
audience,
then
this
is
the
place.
B
A
Okay,
I
think
maybe
it
concludes
today's
missing,
so
there
is,
if
there's
nothing
else,
I
think
we
can
yeah
and
end
it
earlier
all
right
thanks.
Everyone
see
you
again,
hopefully,
next
week.