►
From YouTube: Argo Contributor Experience Office Hour 22nd Jul 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
A
Because
I'm
sharing,
I
don't
know
who
is
not
muted
but
myself:
okay,
basically
yeah.
We
have
a
new
feature
proposal
about
namespace
applications,
so
idea
is
to
let
users
define
application
in
any
namespace
of
control,
client
control
when
cluster
and
I
wanted
to
just
go
through
2.1
release,
status
and
yeah,
and
then
just
now
topic
showbike
that
I'm
not
talking
about
still
cluster
state.
Yes,
I
guess
we
can
start
from
application.
Cr
do
not
know
if
we
have
young
today.
C
A
C
Yes,
please,
I
think,
let's
give
an
overview
of
the
feature
and
then
I
think,
alex
you
had
an
approach
that
you
recommended
yarn
had
another
approach.
I
think
a
little
different
approach.
I'm
not
sure.
I
think
that
that
was
the
case
right
or
or
do
you
want
to
just
discuss
one
approach
here
or.
C
A
The
problem
that
I'm
aware
of
and
then
we
can
continue,
discussion
yeah,
but
overall
idea
is
that
it
feels
like
we
want
to
let
kind
of
solve
service
ability.
You
know
we
want
to
make
users
empower
users
to
let
them
serve
themselves
and
basically
create
applications
without
asking
admin
to
create
applications
for
them
and-
and
it
feels
like
we
just
want
to
reuse,
kubernetes
or
bug
to
you,
know,
to
make
sure
it's
application
can
be
created
securely
and
yeah
so
and
we
come
up
with
two
approaches.
A
One
approach
is
just
a
crg
with
the
name
we
come
up
with
is
absorb
cld
and
that
basically
cld,
let
users
define
the
source
of
application
and
and
the
source,
as
you
might
know,
it
just
includes
a
repo.
You
know,
folder
in
the
tripo
and
some
parameters
related
to
config
management.
Plugins,
but
user
cannot
specify
destination
cluster
destination
namespace
and
basically
because
it's
inferred
from
the
namespace,
where
appsource
is
created
and
controller
that
manages
absorbs
supposed
to
create
applications
on
the
fly.
A
Basically,
it
should
discover
upsource
crd
instances
and
then
create
applications
in
some
cargo
cd
instance.
So
the
idea
here
is
that
we're
using
kubernetes
are
back
and
we're
kind
of
assuming
that,
if
user
had
permissions
to
create
appsource,
that
means
that
user
has
permissions
to
manage
resources
in
the
namespace,
where
appsource
is
created
using
some
argo
cd.
A
So
this
is
that's
one
approach
to
do
that
and
we
have
kind
of
another
proposal
instead
of
introducing
third
party
cld
or
not
for
patty
additional,
the
idea,
why
don't
we
teach
our
ocd
to
manage
to
discover
applications
in
namespaces
of
control,
plane,
cluster,
and
in
this
case
it
has
advantages.
The
advantage
is
that
it's
easier
to
get
that
to
deliver
that
feature
to
end
user.
Basically,
if
it's
built
in
into
argo
cd
itself,
then
you
can
simply
you
know.
A
User
just
have
to
upgrade
to
new
version
of
argo
cd
and
feature
is
available
plus,
I
think
it's
very
it's
kind
of
attractive
if
you
use
argo
cd,
if
your
control,
plane,
cluster
and
target
cluster
is
the
same
cluster.
Basically,
if
you
use
argo
cd
just
to
manage
the
cluster
and
your
users,
control
name
spaces.
A
A
C
No,
I
think
you
did
a
great
job
with
that.
I
think
this
makes
sense
as
general
overview.
I
think
this
kind
of
diversifies
the
fact
that
the
control
plane
is
one
name
space
and
now,
basically,
we
could
have
smaller
control
planes
in
other
name
spaces
without
compromising
the
security
model.
Yes,
so
I
feel
like.
A
So
you
know
now:
maybe
we
can
go
for
pros
and
cons,
and
it's
kind
of
to
me
the
biggest
disadvantage
of
adding
that
feature
into
argo.
Cd
itself
is
that
it
introduces
complexity
because
you
kind
of
have
to
app
now
with
rbcd
is
supposed
to
operate
in
two
modes,
and
I
wish
yan
was
here
because
I
think
basically,
he
young
created
the
poc.
A
That's
that
was
fun
and
okay,
I
think
yeah
right.
You
know
there
are
pros
and
cons
at
the
same
time.
You
can,
you
know,
come
you
can
argue,
and
you
can
say
that
we
still
need
to
work
on
external
strategy,
and
that
requires
additional
work,
because
you
need
to
bootstrap
whole
new
project
and
you
know
separate
ci
process
separate.
So
it's
kind
of
you
know
you
have
to
let's
do
less
work
in
what
case,
but
another
kind
of
work
in
another
case.
So
and
basically
it's
not
the
strong
argument,
I
think
so.
C
A
C
And
and
if
it's
the
api
is
going
to
be
almost
almost
like
99
same
as
what
the
application
api
is,
which
ideally
it
should
be,
because
you
would
need
to
specify
here's
my
git
rebo,
here's
a
cluster,
it
needs
to
go
to
stuff
like
that.
Then,
if
we
could
use
the
same
api,
but
have
our
controller
be
more
smart
to
understand
this?
This
is
not
coming
from
the
control
plane
name.
Space
is
coming
from
a
username
space.
That'll
be
nicer.
A
Okay-
and
I
think
we
okay,
we
kind
of,
I
think,
we're
repeating
the
discussion
from
one
of
the
previous
meetings.
We,
I
think
we
get
to
a
point
where
we
identified
one
functional
difference
in
two
approaches,
so
in
case
of
applications
in
you
know,
in
in
case
of
application
applications
in
different
time,
spaces
users
have
ability
to
create.
A
C
B
One
pattern
that
a
user
might
use
is
okay.
Well,
if
I'm
deploying
to
this
cluster,
I
might
create
argo
cd
applications
that
are
included
in
a
name
space
that
is,
that
is
designated
for
that
specific
target
cluster.
B
So,
like
you,
can
kind
of
think
of
I'm
not
saying
that
this
is
a
good
pattern
necessarily,
but
I've
only
had
a
few
seconds
to
think
of
it,
but
you
can
imagine
that
there
may
be
patterns
that
will
emerge
once
this
feature
were
implemented,
that
users
would
find
beneficial
in
terms
of
using
namespaces
as
an
organizing
unit,
rather
than
necessarily
something
specific
to
the
resources
in
the
control
plane.
I.
A
See
so,
basically,
we
would
kind
of
replacing
I
mean
not
replacing,
but
in
a
way
in
kind
of
replacing
namespaces
in
the
control
plane
cluster.
This
application
project
right,
so
application
project,
replacing
these
namespaces
from
control
plane
and
from
namespaces,
is
controlled
by
cluster.
So,
basically,
instead
of
creating
projects
we
can
just
have.
We
can
slice
control,
plane,
cluster
into
name
spaces,
give
different
set
of
permissions
to
end
users,
and
then
these
users
can
create
apps
in
these
namespaces
and
yeah.
A
C
A
Yeah,
that's
now
I
understand
the
goal
is
basically:
if
you,
you
can
give
access
to
control,
plane,
cluster
and
let
people
create
things
in
the
cluster
and
you
don't
have
to
invent
your
owner
back
because
you
can
use
kubernetes
server,
but
in
this
case
we
still
need
a
project
associated
with
namespaces,
because
you
still
need
to
control.
You
know
destinations
of
your
apps
and
and
the
sources
and
so
on
right.
That's
right!
C
A
Do
you
mean
speculative
would
be
used
here?
I
feel
like
yes,
you
kind
of
instead
of
using
cargo
cd
token
to
verify
if
user
can
create
application
in
the
project
or
not
you're,
using
kubernetes,
okay,
the
secret
application
in
the
project-
and
you
know
the
mapping-
is
you
know
I
believe
in
this
case
we
must
have
one-to-one
mapping
between
one-to-many
mapping
actually
between
project
and
namespaces
like
somewhere.
A
We
should
say
that
project
a
includes
applications
from
the
namespaces
abc,
and
then
you
just
give
access
to
these
namespaces
to
end
users
and
users
can
create
apps
and
yeah.
This
is
kind
of
it's
like
you.
I
think
yeah
we'll
enforce
this
yeah.
It's
fair,
I
feel
like.
A
I
agree,
it's
a
valuable
feature,
because
I
see
the
value
in
it.
Yeah
and
I
kind
of
my
mind
I
keep
trying
in
the
background.
I
keep
trying
to
think
if
we
can
do
the
same
thing
with
appsource
and
maybe
my
question
is
how
do
you
think?
Okay,
at
least
I
understood
why
we
should
try
to
you,
know,
pursue
that
opportunity
and
basically
make
it
possible
for
end
users
to
create
applications.
A
C
Yeah
I
mean
I,
I
would
say
you
know
we
could
have
a
little
bit
of
both
actually
so
we
could
eventually
like
we
would
have
a
goal
to
make
it
a
first
class
feature.
What
that
means
is
that,
because
this
is
something
that
significantly
provides
more
powers
to
users,
we
can
have
a
gradual
rollout
of
this,
which
means
this
is.
This
could
be
a
feature
flagged
thing
so
that
you
know
we
don't
suddenly
put
in
a
new
feature
and
open
up
a
new
attack,
vector.
C
That
slowly,
but
then
I
would
say
in
general,
like
the
application
cr
of
argo
cd
is
a
very
popular
thing,
and
people
would
want
to
use
that
and
we
should
actually
ensure
that
people
continue
to
focus
on
that,
rather
than
making
them
suddenly
learn
a
new
cr
again,
and
the
main
reason
is.
The
applications
like
like
the
application.
Cr
like
the
application
model
in
kubernetes,
is
an
extremely
overloaded
term.
B
C
Was
an
application
crd
which
I
think
came
in
one
of
the
google-backed
projects
as
well
once,
but
that
was
nothing
as
what
we
have
here
and
this
one
is
actually
useful:
the
application
crd
that
we
have
in
the
argo
project.
So
if
we
could
effectively
use
this
approach
where
we
are
saying
we
don't
introduce
a
new
crd,
we
make
this
available
in
other
name
spaces
and
then
every
time
we
enhance
the
application.
Api,
like
the
whole
ecosystem
benefits
out
of
it.
C
So,
which
is
why
I
would
strongly
say
we
do
not
introduce
a
new
api.
We
use
the
same
one,
but
with
better
checks
and
balances.
One
follow-up
question
too:
sorry:
no
yeah.
A
I
just
want
to
comment
on
that
in
in
the
idea
of
application
source
was
that
it
has
to
be
kind
of
subset
of
application
theory,
basically
app
source
right,
there's
no,
its
own
fields,
so
we
simply
import
source
data
structure
from
the
application
so
from
our
go
cg
code
base
and
basically
it
would
sorry
in
you
know,
every
new
release
of
argo
cd
will
affect
up
source
as
well,
and
you
know
every
time
we
add
a
new
field
into
app
source,
it
so
into
application
crd,
it
will
be
automatically
added
to
upsource
and
users.
C
Yeah
I
mean
I
I
I
just
feel
that
our
gossipy
project
is
way
too
mature
for
us
to
introduce
a
new
crd
for
something
as
core
as
deploying
workloads
like
we
can
introduce
new
workloads
like
new
crds.
That's
fine,
but
deploying
applications
like
deploying
kubernetes
manifest
from
git
is
the
center
of
our
go
cd
project
and
if
we
could
use
the
same
api
that'll
be
awesome
so
yeah.
I
think
I
agree
with
you
that,
irrespective
of
what
we
do,
we
were
using
the
same
golang
apis
in
both
the
crds.
So
that's
that's
good.
C
The
one
other
bit
I'd
like
to
probably
pick
on
a
little
on
this
one
is
that
I
think
you
mentioned
that
you're
going
to
depend
on
the
kubernetes
are
back
right
so
and
again
correct
me.
If
my
understanding
is
wrong
here,
so
if
I'm
not
allowed
to
create
an
application
cr
in
namespace
foo,
then
I
don't
get
to
create
it.
That's
fine,
but
if
I
am
allowed
to
create
an
application
cr,
what
stops
me
from
having
that
application
cr,
deploy
things
that
I
wasn't
otherwise
allowed
to?
A
In
this
proposal,
yes,
it's
our
back
in
the
project.
So
basically
you
still
have
right
project
and
you
still
have
to
maintain
things,
but
you
know
it's
basically
yeah
you
can
just
use.
The
advantage
is
that
you
can
use
kubectl
apply
to
create
that
application.
You
don't
have
to
go
through
argo,
cd
and
right,
and
it's
still,
you
know
safe.
If
you
validate
some
rules
of
a
project,
argo
cd
will
stop
you
still,
but
at
least
you
don't
have
to
go
through.
C
The
august
3
cli
yeah
yeah.
I
think
I
think
that
makes
sense.
I
think
my
general
comment,
and
that
should
be
as
part
of
the
pr
review
process
or
the
design
review
process,
that
we
should
ensure
that
the
initial
like
the
app
project
by
default
that
powers
other
namespace
applications
should
be
very
restrictive.
So.
B
C
A
mistake
in
configuration
should
not
lead
to
you
know:
suddenly,
people
in
user
name
spaces
acting
like
admins,
it
has
to
be
restricted,
which
means
by
default
we
block
out
almost
everything,
and
then
we
allow
people
to
add
things
to
it.
Compared
to
you
know,
opening
up
and
gradually
locking
down
things
just
yeah.
A
A
And
I
feel,
like
maybe
kind
of
too
important
at
least
learning
from
me
so
far,
is
that
before
that
conversation
I
was
thinking
that
we
need
to
either
upsource
or
we
need
namespaced
applications.
But
now
I
feel
like
it's
basically
two
different
use
cases
and
we
just
need.
Maybe
we
need
both
and
then
second
important
point
I
agree
with
you
should
be
that
we
need
to
try
to.
A
Basically
we
need
to
make
sure
that
users
will
not
have
to
learn
a
new
set
of
you
know
new
whole
new
cld
from
scratch
and
the
perfect
scenario,
if
we
just
use,
maybe
the
same
cld,
and
if
it's.
If
that
is
not
possible,
then
we
should
at
least
make
sure
another
cig
is
very
similar
to
applications
idea.
B
C
B
A
Yeah,
so
I
guess
my
proposal
is
to
try
to
at
least
elaborate
if
it's
possible
to
solve
it
through
external
project.
It's
just,
I
feel
like
kind
of
we
all
I
mean
in
both
cases
we
are
trying
to
solve
config
management
problem,
and
I
can
think
I
mean
application,
so
ergo,
cd,
config
management
issue,
so
we
have
upset
and
the
problem
with
upset
is
trying
to
solve,
is
what,
if
you
need
to
create
a
lot
of
applications
and
upset?
A
Is
you
know
helping
you
to
do
that,
and
in
this
case
I
feel
like
problem
is
kind
of
different,
like
we
have
a
lot
of
users
and
each
one
needs
to
create
a
few
applications
and
upsource
crg
is
trying
to
solve
it
in
one
way,
and
this
type
of
this
change
is
trying
to
solve
it
in
another
way.
But
it's
still
kind
of
this
almost
the
same
problem,
and
at
least
just
for
consistency
of
the
subset.
I
would
propose
to.
A
Implement
it
as
a
basically
sidecar
controller
that
manages
something
and
then
create
our
qcd
applications,
and
in
this
case
there
is
no
like
there
is
no
change
in
argo
cd
and
that's
a-
and
this
is
to
me
is
a
big
win,
because
you
know
we
are
not.
Basically,
we
can
deliver
that
feature
and
it
won't
be
tied
to
any
rcd
release.
We
can
trade
quickly
and
all
the
goodness
of
building
it
as
a
side,
project
yeah
and
then
that's
what
I'm
thinking
so
far.
C
I
mean
I
definitely
see
why
you're
you're
saying
that
and
that
it
does
make
sense,
I
think
from
yeah.
I
think
it's
like
my
perspective
is
more
of
to
ensure
that
we
don't
have
a
huge
proliferation
of
crds,
but
I
think,
on
the
other
hand,
having
a
separate
cid,
helps
us
iterate
faster
and
not
have
to
worry
about
how
that
might
impact
something
mainstream,
so
yeah.
I
think
that
makes
sense
as
well.
A
And
to
me
like
a
application
set
has
its
own
crd,
but
it
kind
of
it
also
includes
id.
So
basically,
people
don't
have
to
learn
everything
from.
A
They
still
have
to,
they
can
use
existing
application
theory
and
additional
things
that
make
sense,
for
you
know
for
upset
use
case,
so
maybe
all
right
that
but
yeah.
I
definitely
taking
a
note
that
we
have
an
important
use
case
here
in
that
proposal
and
it
must
be
taken
into
account.
So
basically,
whatever
we
do
should
solve
that.
A
C
Agreed
and
and
like
and
like
the
most
important
thing,
irrespective
of
which
approach
we
take,
is
that
from
a
security
perspective,
we
should
be
extremely
well
positioned
because
we
are
doing
something
we
didn't
do
in
the
past,
which
is
allowing
things
to
be
created
in
non-controlled,
plane,
name
spaces.
So
I
think
that
is
an
extreme
level
of
scrutiny.
The
whole
team,
the
whole
group
here,
should
be
yeah,
irrespective
of
which
approach
we
take.
C
A
problem
yeah
right,
I
mean
in
general,
I
think
the
the
the
the
main
concept
in
both
approaches
is
that
we
are
now
saying
that
users
who
previously
did
not
have
to
worry
about
creating
argo
cd
applications
and
because
they
are
users,
they
are
not
admins
who
had
access
to
the
control,
plane,
name
speakers
or
something
would
have
access
to
creating
these
right.
C
I
think
in
general.
That's
the
only
thing
that
we
need
to
be
aware
of
that
now
now
that
they
are
being
given
an
option
to
create
applications
or
app
sources,
they
need
to
ensure
that
I
mean
somebody
needs
to
ensure
that
app
projects
are
really
well
taken
care
of
just
so.
The
focus
on
them
increases
because
now
it's
no
longer
the
control
plane.
Who
does
everything?
It's
the
other
names
too?
I
think
just
that
yeah,
but
in
general
yeah.
I
agree
like
we
already
have
the
app
projects
framework
in
there.
C
A
Okay,
thank
you,
yeah.
I
think
we
thank
you.
I
will
try
to
you
know
at
least
comment
what
I
learned
in
the
conversation
in
the
poc
and
yeah,
and
just
for
you
know
it's
for
what
context.
Basically,
the
upsource
project
is
kind
of
it's
moving
in
background
as
well,
and
I
guess
we're
going
to
have
another
pc
and
then
we
can.
You
know,
try.
B
C
No
no
go
ahead,
it's
been
a
you
know,
monologue
by
sorry,
not
a
moon
like
it's
kind
of
a.
B
B
Like
you're,
in
the
middle
of
something
but
yeah
I'll
jump
in
will
the
app
source
work
you're
doing
include
enhancements
to
the
argo
cd
ui
so
like
the
ability
to
create
app
sources
within
the
web.
Ui
not.
A
Yet,
no
I
mean
not,
I
mean
yet
is
the
wrong
one.
It
was
just
idea
was
to
only
build
back
end
and
I
feel
like
we
need
to.
You
know
talk
about
ui
changes,
one
more
time.
I
personally,
I
was
thinking
that
we
needed
a
feature
in
argo
cd
to
support
grouping
of
application
by
label
and
then
maybe
upsource
and
upset,
and
even
that
project
you
know
this
particular
enhancements
would
take
advantage
of
it.
A
You
know
basically
yeah.
It
seems
like
we're
going
to
we're
moving
to
a
state
where
we
have
different
ways
to
create
bunch
of
applications
and
the
way
to
create
these
applications
is
so
different.
You
can
use
apple,
apps
pattern,
you
can
use
upset
or
upsource
and
it's
so
difficult
to
support
all
these
sources.
So,
instead
of
supporting
sources,
maybe
we
can
just
let
user
apply
a.
A
B
C
B
A
I
feel
like
would
not
like
application.
Sorry,
namespace
applications,
I
think,
has
to
be
created
in
ui,
or
at
least
it's
desirable-
to
create
applications
in
different
timespaces
and
you
know
being
able
to
specify
the
namespace
but
upsources
kind
of
are
more
for
so.
The
difference
of
upsource
and
namespace
application
is
that
upsource
supposed
to
live
in
a
different
cluster.
A
B
Yeah,
no,
that
that's
fine,
so
yeah,
it
definitely
sounded
like
you
were
thinking
of
it
as
like.
A
back
end
only
feature
so
or
or
at
least
in
terms
of
creation.
So
so
yes
user
would
be
able
to
use
the
web
ui
using
the
grouping
feature
to
see
what
was
created,
or
at
least
the
applications
that
were
created,
but
yeah
not
not
necessarily
be
able
to
create
it
within
the
web.
A
You
know
if
you
have
agreement
that
maybe
we
introduce
created
by
label
something
like
created
by
doterra
google
project
io,
and
this
is
the
default
label
to
indicate
the
source
of
that
application,
meaning
you
know
what
was
created
like
what
or
who
created
that
application,
and
if
there
is
no
such
label
that
we
would
assume
human
created,
the
application,
if
there
is
label
and
value,
is
upset,
then
it
would
be
upset,
and
you
know.
A
All
right,
I
guess
I
think
we're
into
you
yeah.
A
Yes,
thank
you.
Yes,
next
item.
It
was
just
an
update
about
2.1
release
and
it's
kind
of
I
feel
like.
I
just
wanted
to
go
quickly
through
a
list
of
remaining
items
here
and
basically
we
have
two
important
ui
changes
that
must
be
done
before
we
create
release
branch
and
they
are
almost
complete.
Basically,
we
keep
tweaking
so
basically,
remington
is
working
on
application.
Resource
filter
enhancements
that
we
discussed
last
time.
A
Pr
is
already
open
and
I
think
we
will
be
able
to
close
it.
You
know
pretty
quickly
and
the
next
there
was
a
bug.
It
was
related
to
basically
it's
a
game
filter,
but
at
this
time
on
application
list
page
and
already,
I'm
pretty
sure
that
both
of
these
will
be
done
today,
roll
out
health
check
just
waiting
for,
I
think,
jc
to
merge
it
if
I'm
not
mistaking
so.
Basically,
these
two
items
will
be
closed
today
as
well,
and
next
two
items
again
kind
of
maybe
duplicates
of
one
of
each
other.
A
They
are
symptom
of
another
problem,
so
argo
cd
make
a
lot
of
git
requests
and
it
was
causing
issues
and
that
I
believe
that
problem
is
done,
but
we
still
have
to
prove
it
and
basically,
these
two
tickets
sitting
in
that
milestone,
waiting
for
release
candidate
to
be
released.
And
then
I
was
going
to
just
ask
users
to
try
that
release
and
tell
us
if
they
still
see
a
problem
and
yeah.
So
I'm
just
hoping
to
get
some
data
about
it.
B
C
A
We
invalidated
every
like,
so
we
have
it
everything
a
controller
from
day
one
it
had
a
parameter.
I
forgot
the
name
of
this
parameter,
but
basically
it's
a
timeout
of
how
frequently
we
we
supposed
to
detect
new
git
commits,
and
it's
better
for
three
minutes
so
and
yeah.
So
we
use
this
time
to
cache.
Let's
remove
results
so,
basically
every
three
minutes
we
guarantee
to
notice,
commit
and
before.
A
C
A
Not
to
do
it
so
we
still
needed
we
needed
to
get
a
set
of
resources
from
git
more
frequently,
because
basically,
the
goal
was
to
refresh
the
three
of
life
resources
that
belongs
to
application,
but
just
to
know
which
sorry,
which
resources
belongs
to
applications.
You
need
to
know
what
root
resources
are
managed
in
git
and
it
was
kind
of
you
know
just
just
the
implementation
detail.
A
We
could
have
done
it
like
every
time
when
port
goes
up
and
down,
we
could
execute
a
lesser
mode
and
a
long
time
ago
we
introduced
caching,
but
on
application
level,
and
it
was
working
fine
unless
you
have
100
applications
in
in
the
repo.
In
this
case,
you
still,
you
know,
do
100
times
more
ls,
guitars
remote
than
necessary,
and
in
this
release
we
finally
caching
on
on
repo
level,
so
that
even
right
applications.
You
would
still
query
just
once
everything
else.
C
Yeah
and
sorry
last
question
on
this,
so
since
so
so
where
so,
where
does
this
routine
run
like
sorry?
Where
did
this
routine
run
in
the
past,
and
where
does
this
routine
run
now,
because
this
is
clearly
not
an
application
controller.
Sync
thing
like
you
said
this
used
to
be
outside
that
cycle.
It's.
A
A
And
in
order
to
get
it
from,
usually
that
list
is
cached
and
we
just
need
to
decide.
Okay,
is
it
safe
to
use
the
same
cache
or
not
and
before
we
would
do
a
gita
lsa
mode,
and
that
helps
us
to
create
the
caching.
You
know
the
key
that
in
the
cache
that
points
to
cached
resources
and
then
we
would
get
cache
resources,
and
now
we
have
two
level.
A
A
C
Yeah
and
and
then
make
sense
if
it's
a
huge
monorepo
of
a
bunch
of
things.
Yes,.
A
A
Right,
okay,
thank
you,
okay,
all
right,
and
so
next
we
have
two
minor
bugs
that
I
we
didn't
look
into
them
yet,
but
we
just
briefly
looked
and
it
seems
like
a
minor
crash.
I
mean
it's
a
it's
a
crash
in
the
ui,
but
the
change
is
minor
and
this
is
it's
like
a
day,
zero
bug,
but
because
it's
so
cheap
to
fix
it.
We
just
said
that
it
entered
that
release,
but
idea
that
you
know
in
some
in
one
edge
case,
argo
cd.
A
Understanding
that
source
resources
changed,
and
it
correctly
thinks
that
it's
maybe
something
changed
in
a
cluster
and
now
source
of
truth
doesn't
match
to
what
to
the
actual
state
of
the
cluster.
And
basically
it's
keep
running
sync
hooks,
and
it's
really
it's
an
edge
case,
but
it
still
affect
users,
and
it's
really
simple.
The
fix
is
really
simple.
A
That's
why
this
kind
of
two
issues
got
added
like
last
minute
and
technically
it's
perfectly
fine
to
release,
especially
without
fixing
that
issue,
and
we
can
simply
work
on
it
after
2.1
is
released,
and
then
we
can
cherry
pick.
Okay.
So
basically,
I'm
not
really
worried
about
these
two
issues
and
the
last
one:
it's
not
a
bug,
it's
a
it's
a
basically,
it's
a
performance
enhancement
that
was
contributed
by
external
contributor
and
it
it
basically
really
improved
ips
over
performance.
A
C
A
I
mean
none
of
this,
like
I,
I
guess
yeah.
I
need
help
with
that
pr.
I
would
appreciate
help
if
someone
else
basically
jan
already
reviewed
the
pr
and
gave
some
comments,
and
I
think
he
kind
of
asked
me
to
you
know,
do
a
second
look,
because
it's
very
if
you
know
it
touching
a
very
sensitive
part
of
her
cd.
We
might
introduce
vulnerability
and
that's
why
I'm
just
scared
by
but
by
this
change,
but
it
doesn't
look
very
dangerous
in
just
touching
a
sensitive
part
yeah
and
we
need
to
review
it
carefully.
A
Apply
feel
like
it
reduced
number
of
our
bug,
checks
and
it
because
you
can
make
safe
assumption
that
if
some
group
claims
that
user
has
never
mentioned
in
the
policy,
then
you
don't
have
to
check
these
groups
and
yeah.
That's
it's
kind
of
filtering
out
groups
from
jwc
token,
and
in
this
I
feel
like
we
might
break
something
so
that
user,
who
should
have
access,
won't
get
this
access,
and
it's
maybe
okay.
It's
like
this
type
of
bugs
are
not
scary
to
me,
but
much
worse.
It
could
be
worse
if
we
potentially
give
some.
A
A
Okay
and
I
feel
like
once
a
release
branch
is
created.
I
will
so
we
talked
about
it
before
we're
now.
Introducing
this
process
of
you
know
a
new
process
of
testing
and
I'm
going
to
create
one
more
bug
here.
It
will
include
a
bunch
of
check.
Boxes,
like
you
know,
create
a
list
block,
create
milestone
for
the
next
release
and
do
this
due
diligence
and
it
will
have
links
you
know
of.
C
C
A
C
Yeah
we
just
have
10
more
minutes.
Do
you
think
we
should
take
it
for
the
next
week?
Maybe
yes,
yeah,
I'm
good.
If
it's
next
week,
it's
not
an
urgent
one,
but
in
general
I
just
wanted
to
get
a
little
in-depth
understanding
of
how
we
cache
the
cluster
state
for
multiple
clusters
and
then
how
we
invalidate
them
and
in
general,
if
I
had
to
provide
some
advice
to
people
on
tuning
things,
what
are
the
some
of
the
internals?
I
would
need
to
know
so
that's
something
you
could
take
during
the
next
week's
call.
A
And
I
know
basically
I
happy
to
talk
about
it
because
I
feel
like
we
have
a
maybe
low-hanging
fruits
in
cluster
caching.
We
can
reduce.
A
The
amount
of
memory
can
you
know,
controller
uses
by
a
lot
like
this
two
times
and,
and
I
kind
of
created
one
ticket
and
I
was
hoping
to
share
the
ticket,
was
about
investigating
how
we
can
reduce
you
know
memory
consumption
in
a
controller
you
know
we
can.
We
can
start
from
just
talking
about
how
caching
works.
C
Awesome
yeah
and
right,
so
I
think
right
now,
when
the
application
controller
comes
up,
there
is
a
spike
in
the
memory.
That
is
because
we
create
a
cache
of
all
the
cluster
resources
and
if
there
are
multiple
cluster
resources
that
we
had,
we
deal
with
so
multiple
clusters
we
deal
with.
Then
we
cache
everything,
so
that
leads
to
an
initial
spike.
What
that
means
is
that,
if
you
have
resource
limits
set
on
the
application
controller,
it
would
fail
because
there
is
an
initial
spike
and
then
it
flattens
after
that.
Right,
yes,.
A
Kind
of
we
have
different
set
of
optimizations
to
maybe
try
to
smooth
that
spike
a
little
bit
and
that's
why
we
have
set
of
hidden
environment
variables
that
help
doing
that,
and
I
it
would
be
nice
to
you
know
I'm
happy
to
talk
about
it.
I
think
I
will
I
will
you
know
I
will
send
a
talking
topic
to
myself
and
prepare
like
a
short
demonstration
for
next
meeting,
because
I
really
want
to
share
that
knowledge.
And
hopefully
you
know,
maybe
more
people
will
work
on
improving
it.
C
And
yeah,
I
think
I
I
actually
stumbled
upon
those
couple
of
things
that
you
were
mentioning.
I
think
we
did.
I
think
we
did
a
way
to
reduce
the
number
of
concurrent
api
requests
to
the
api
server
with
cubans,
api
server
and
there's
another
thing
I
noticed
in
the
code
that
happened
so
yeah.
I
think
this
would
be
a
great
topic,
because
some
great
changes
have
gone
in.
It
will
be
good
if
more
people
can
maintain
those
so
yeah.
A
Sounds
good.
I
just
wanted
to
share
one
more
thing.
I
recently
found
that
apparently
on
one
of
our
internal
instances
that
uses
like
eight
gigabytes
of
memory,
the
gold
and
key
only
take
is
only
like
two
gigabytes.
So
basically
we
probably
like
go
routines
are
not
as
cheap
as
it
sounds
like
and
then
right.
A
The
good
thing
is
that
we
have
literally
one
go
link
method
that
produces
like
99
percent
of
all
these
go
routines
and
I'm
hoping
that
maybe
we
can
switch
to
you,
know
callbacks
and
basically
in
goal,
and
you
not
necessarily
have
to
use
goal
routine.
It's
for
convenience.
You
can
so
switch
to
callback
yeah
and
it
potentially
can
save
like
50
percent
of
memory.
If
not
more
so
to
me,
it
works.
A
C
Yeah
and
I
think
in
general
I'll
just
give
a
shout
out
to
everyone
in
the
meeting.
If
any
of
you
want
to
add
your
name
to
the
list
of
future
github
discussion.
Moderators
just
add
your
name
to
that
list,
and
through
a
round-robin
fashion
or
something
similar,
you
can
choose
to
be
the
one
in
one
of
the
upcoming
weeks.
It
doesn't
have
to
be
the
five
or
six
people
in
that
list.
B
Activity
this
week
was
pretty
light.
Actually
a
surprising
number
came
in
this
morning
now,
but
yeah
in
general.
It's
been
pretty
light
this
week.
So
it's
not
a
lot
of
work
for
those
that
are
interested.
A
Yes,
thank
you
yeah,
and
I
think
another
proposal
is
to
maybe
please
add
more.
I
feel,
like
we
kind
of
spoke
about
how
we
use
time
during
that
meeting
and
it's
mostly
still
kind
of
show
and
tell,
and
I
think
we
want
to
change
it,
and
we
want
to
talk
about
blocking
issues
and
please
yeah,
add
topics.
Let's
it's
basically
call
to
contributors.
Let's
try
to
use
this
meeting
to
talk.
What
matters
to
you,
not
what
matters
to
you
know
to
maintain
us.
A
A
C
Yeah,
I
I
I
think
in
general,
you
know
I
would
encourage
everyone
to
come
up
with
your
own
topics.
What
that
means
is
you're
looking
at
a
specific
issue,
and
you
see
a
bunch
of
code
which
doesn't
make
any
sense
to
you,
and
you
want
a
bigger
discussion
on
that
piece
of
code.
It's
it's
just
a
great
place
to
put
in
that
topic
and
have
a
discussion
around
it.
Somebody
in
this
group
would
have
written
that
code
in
some
fashion
or
the
other,
so.