►
From YouTube: Argo Contributor Experience Office Hour 22nd Apr 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
Yeah,
so
we
today
we
didn't
have
much
topics
there
was.
I
wanted
to
go
quickly
from
milestone,
2.1
and
just
maybe
highlight
you
know
the
kind
of
corner
features
of
next
release,
and
there
was
one
other
feature
that
has
a
proposal
already,
which
is
projects
called
repositories
and
clusters,
and
I
I'm
not
sure
how
much
time
we
want
to
spend
on
2.1
release.
So
maybe
let
me
go
through
top
level
ones,
and
then
we
can.
You
know
if
anyone
has
any
questions
about,
not
the
most
visible
tickets,
we
can
discuss
them.
A
Okay,
the
first
one-
this
is
already
kind
of
work
in
progress,
so
we
really
want
to
get
roll
out
visualization
in
argo
cdoi
and
for
those
who
uses
argor
loud,
maybe
you're
familiar
with
a
rollout
cli.
So
it
provides
kind
of
rich
information
about
what
is
happening
with
rollout
and
ui
is
far
less
sophisticated.
A
So
and
basically,
the
goal
is
to
bring
exact
same
ui
into
argo
cd
and
the
way
we
want
to
do
it
is
we
want
to
kind
of
build
just
the
standalone
ui
follow
out
first,
and
this
is
already
kind
of
almost
complete.
It's
getting
crazy
for
for
release
and
then
next
step
is
to
try
to
make
it
possible
to
extend
argo,
cdui
and
support
all
kind
of
uis
and
start
from
a
lot.
And
for
that
we
still
need
a
proposal,
and
basically
that's
so
we're
going
to
start
from
proposal.
A
Yes,
that
makes
awesome
all
right.
So
next
is
the
proposal
that
I'm
going
to
present
today,
which
is
shared
repositories
and
clusters
and
along
the
way,
I
kind
of
renamed
them
to
project
scope,
repositories
and
clusters.
So
the
idea
here
we
want
to
help
users
to
self
and
we
want
to
simplify
end
users
onboarding
process.
A
So
currently,
users
must
talk
to
rbcd
admin
and
ask
him
to
add
a
repository
or
cluster,
but
in
many
cases
end
users
already
have
credentials
of
repos
and
clusters
and
admin
don't
have
that
credential
don't
have
admin
access
to
the
cluster
admin
is
basically
only
argo
cd
admin
and
that
creates
friction.
It's
hard
to.
Basically,
users
somehow
have
to
talk
to
admin
first
and
then
share
credentials
and
then
so
basically
spend
time.
A
Instead
of
just
do
it,
you
know
without
help
from
admin,
and
I
will
discuss
proposal
in
after
after
we've
done
this
2.1
okay.
So
next
we
have,
I
think,
two
or
three
tickets
related
to
rcd
settings.
So
one
was
to
split
rvcd
config
map
kind
of
big
keys
into
sub
keys,
to
make
it
possible
to
just
separate
our
vcd
config
map
into
set
of
patches
and
then
maybe
use
tool
like
customize
to
merge
them
back
into
one
carbon
cd
config
map.
A
A
And
so
basically,
this
way
is
you
can
keep
using
config
map
know
nothing
about
cid,
but
clds
can
insert
additional
keys
into
our
vcg
configmap
so
and
then
and
kind
of
side
by
side
with
it.
There
is
second
config
that
we're
going
to
improve,
which
is
cargo,
cd
secret
so
and
oh
sorry,
my
bad
yeah,
so
our
obviously
secret
and
configmap.
A
So
basically,
we
also
we
store
some
of
repository
related
configuration
in
argo,
cd
configmap
and
it's
kind
of
it's
redundant
and
in
2.0
release
we
attempted
to
kind
of
have
very
smooth
experience
for
declarative
management
of
arbor
city
using
cargo
city
util,
but
because
of
we
store
and
some
keys
of
related
to
repositories
in
aguacity
configment.
That
experience
was
not
as
smooth
as
we
expected
and
we
want
to
get
rid
of
those
keys
and
basically
get
to
a
state
where
we
store
clusters
and
repos
only
in
secrets
and
applications
and
projects
in
cids.
A
A
C
D
A
C
Just
I'm
just
asking,
because
so
managing
managing
secrets
is
like
peter.
So
it's
it's
like
you
know,
working
with
all
the
base,
64
stuff
and.
A
A
I
was
proposing
to
move
non-sensitive
stuff
into
annotations
and
then
sensitive
into
base64,
because
you're
not
supposed
to
manage
you
know
sensitive,
it's
okay,
it's
to
make
it
not
very
convenient
and
non-sensitive
can
go
in
argument
was
that
you
can
use
string
data
as
well
and
don't
mess
with.
C
Yeah,
that's
for
for
editing,
but
once
you
want
to
look
at
some
values,
you
have
to
always
base
64
decode
right.
So
I
I
think
that
would
not
be
a
great
experience
and,
and
so
something
else.
So
if
if
we
could
like
move
this
stuff
to
like
repositories
to
become,
for
example,
their
own
custom
resources.
A
C
We
could
just
refer
the
same
secret
for
various
for
various
repositories,
right.
A
Yeah,
how
about
what,
if
we
add
this
topic
like
in
the
agenda
and
then
and
talk
about
it,.
A
Kind
of
agreed
already
in
the
ticket,
but
I
think
it's
never
late
to
you-
know,
work
on
improvements,
and
I
know
that
john
he
started
working
on
it.
I
don't
know
how
much
he
how
much
progress
he
made.
D
B
Yeah,
I
I
think
in
general,
I
think,
in
a
different
issue
also.
I
think
we
discussed,
I
think
in
general.
The
idea
is,
you
know
we
can
have.
You
know
non-primitive
types
that
we
are
using
now,
but
eventually,
if
it
feels
good
that
we
need
a
strongly
typed
thing,
we
just
go
for
it.
I
think
this
is
one
of
those
situations
where
you
know
and
you've
got
to.
You
probably
brought
up
a
good
point
around
having.
A
B
A
Okay,
next
one
I
forgot
to
edit
here
and
we
don't
have
a
ticket,
but
it's
so
you,
maybe
oh
you
remember
a
proposal
that
xiamen
presented
the
config
management
tools,
improved
asset,
yeah,
conflict
management,
plugin
improvements.
So
it's
here
and
I
sorry
I
forgot
to
edit
in
the
list
so
and
basically
we
want
to
work
on
2.1
on
config
management,
plugins
improvements
and
then
the
rest
of
the
tickets
are
kind
of
bug,
fixes
and
carryovers
from
from
the
previous
release
and
kind
of.
A
Basically,
I
feel
like
bugs
are
still
priority,
but
other
config
management
enhancements
maybe
has
almost
the
same
priority,
but
I
just
listed
once
that
our
team,
you
know
team
at
intuit
care
about,
and
I
it's
not
necessary.
You
know
set
in
stone,
we
can
change
or
remove
or
substitute.
You
know
these
enhancements
with
something
else
yeah
and
then
in
that
meeting
I
remember,
I
think
we
will
we
wanted
to
kind
of
see.
You
know
what
each
maintainer
wants
to
work
on,
and
basically
I'm
just
trying
to
say
that
feel
free
to
add
anything
here.
A
Anything
else
here,
if
you
you
know,
don't
like
some.
Some
of
these
tickets.
A
Sounds
like
any
comments,
okay
and
right.
I
think
it
will
just
take
too
much
time
if
we
try
to
go
through
all
of
them
and
yeah,
maybe
one
other
ticket
I
wanted
to
highlight.
I
really
want
to
try
to
one
more
time
try
to
fix
the
bug
that
no
one
can
reproduce
the
sink
waves
and
up
of
apps.
So,
no
matter
how
many
times
I
tried,
I
still
unable
to
reproduce
it
and
we
have
long
covered
you
performance,
optimization.
A
Basically,
argo
cd
still
sends
a
ton
of
git
ls
remote
requests
every
time
and
it's
kind
of
okay,
but
users
don't
like
it,
especially
github
gitlab
admins.
A
They
don't
like
it
and
recently
we've
got
a
new
kind
of
user.
Complaining
that
in
if
argo
cd
is
trying
to
deploy,
manifests
from
hand
repository
directly
without
the
git
repository,
then
it
might
produce
a
lot
of
traffic
because
argo
cd
kind
of
tries
to
load
index.tml
file
from
home
repo
as
frequently
as
it
sends
ls
github
as
remote
requests,
and
basically
it
results
in
like
gigabytes
of
traffic
every
day,
so
yeah
basically
couple
important
performance,
optimizations.
A
Yeah,
so
I
sent
the
documentation
and
it's
there
in
in
github,
so
sorry
feel
free
to
add
comments
to
it.
But
yeah
here
is,
I
kind
of
already
explained
the
use
case,
but
let
me
repeat
it
so
we
have
typical,
typically
argo
cds
used
by
multiple
teams.
They
not
necessarily
know
about
about
each
other,
so
we
have
to
protect
them.
We
have
kind
of
admins
and
admin
configure
projects
and.
A
One
type
is
when
administrator
is
basically
argo
city
administrator,
as
well
as
admin
of
clusters
and
has
admin
access
to
git
repositories,
and
in
this
case,
what
we
have
now
is
working
just
fine.
So
the
other
case
is
when
admin
just
run.
Argo
cd
for
organization
and
developers
have
credentials
to
the
repositories
and
clusters,
and
this
is
what
I'm
trying
to
improve
here.
A
So,
instead
of
developers
asking
admin
to
add
cluster
and
repository,
I
want
to
make
it
possible
to
developers
just
do
it
themselves
without
asking
him
from
admin
and
the
way
I
want
to
do
it
is
in
the
proposal.
A
So
I'm
just
proposing
to
introduce
a
new
field
in
repository
and
a
cluster,
and
here
I'm
already
referring
to
you,
know
I'm
kind
of
providing
secret
as
an
example,
and
basically
this
proposal
is
kind
of
blocked
by
by
the
changes
that
we're
about
to
discuss
next,
but
imagine
if
we
have,
if
we
store
repository
in
secret,
we
would
introduce
new
field
project,
and
that
would
mean
that
that
repository
or
cluster
kind
of
belongs
to
a
project
and
it's
automatically
white
listed
in
the
project.
A
So
this
is
that's
step
number
one
and
next
step
is.
We
need
to
make
it.
We
need
to
basically
introduce
our
bug
changes
and
we
could.
The
next
section
describes
kind
of
changes
we
want
to
make
so
I'm
proposing
to
introduce
a
new
set
of
rules
so-
and
this
is
example
of
the
rules.
So
if,
if
you
are
go
cd
admin,
you
can
just
create
this,
this
sample
rule.
A
Basically,
you
can
enable
you
can
give
someone
permission
to
manage
repositories
under
specific
project,
and
and
so
we
would
have
to
make
code
changes
to
to
check,
not
sure
how
to
phrase
it.
So
basically,
if,
if
repository
belongs
to
a
project,
then
argo
cd
code
should
check
access
to
it
and
prefix
it
with
the
project
name
so
and
together
that
kind
of
solves
the
problem.
A
C
I
I
actually,
I
actually
like
the
proposal
yeah,
that
there
are
a
few
things
we
still
need
to
work
out,
but
yeah
it's
it's.
D
A
And
one
debate
I
had
before
I
wrote
it
so
we
could
maybe
took
the
same
route
it's
here
in
alternatives
like
we
could
kind
of
treat
repos
and
clusters
as
a
you
know,
like
just
machinery
and
then
maybe
create
a
crd
that
help
users
to
manage
it.
But
because
changes
are
so
kind
of
lightweight,
we
would
not
have
to
change
much.
It's
like
extremely
small
changes
and
it
seems
like
a
good
fit
into
existing
design.
A
Yeah.
That's
why
I'm
proposing
to
kind
of
support
it
first
class
and
then
yeah
couple
other
things.
So
everyone
who
looked
at
this
proposal
noted
that
if
you
let
users
add
clusters
without
any
control
to
argo
cd.
Eventually,
you
might
just
kill
application
controller
and
I'm
kind
of
I'm
proposing
to
mitigate
it.
But
so
we
have
you,
can
you
can
improve
it
in
multiple
ways?
For
now,
I'm
just
proposing
to
make
sure
we
have
good
metrics
for
administrator,
and
we
have
all
the
data
in
the
system,
so
administrator
can
kind
of
quickly
catch.
A
That
project
suddenly
go
to
a
lot
of
clusters
and
it
manages
a
lot
of
kubernetes
resources,
plus
I'm
proposing
to
add
owner,
fill
in
owner
field
into
the
cluster
and
repository
just
for
consistency.
So
basically,
admir
admin
could
quickly
catch
that
someone
just
added
too
many
clusters
and
admin
can
use.
Parameters
to
set
up
while
using
and
owner
field
will
help
to
figure
out
who
added
the
cluster
and.
A
Yeah
so
kind
of
I
thought
about
maybe
try
to
implement
limiting
in
the
project
itself,
but
I'm
kind
of
hesitating
to
do
it.
One
reason
is:
clusters
can
grow
so,
basically,
even
if
you
have
limit
your
existing
clusters
can
increase
in
size
and
then
exceed
that
limit.
So
like
one
way
or
another,
admins
must
monitor.
C
C
C
A
C
C
Could
also
add
to
to
something
like
if
you
say
it's
like
you
have
internal
customers
that
pay
per
cluster,
and
maybe
you
can
you
can
just
limit
them
to
the
to
their
contingent
or
something
like
that.
I
I'm
not
sure,
but
I
feel
that
we
should.
We
should
impose
some
kind
of
maximum
that
each
each
project
could
add
it's.
It's
just
a
gut
feeling,
but
I
think
do.
A
A
Yes
and
and
watches
as
well,
so
it's
kind
of
yeah.
That's
what
confuses
me
I
can.
I
do
not
know
what,
like
what
user
might
want
to
restrict.
I
think
it's
combination
of
all
like
number
of
clusters,
number
of
resources
in
the
cluster
and
number
of
objects
in
the
cluster,
and
that's
why
it's?
If
we
that's
why
I,
the
first
idea
was
to
simply
give
metrics
and
then
prometheus
rules
are
flexible
enough
to
come
up
with
any
rule
parameters.
A
D
One
thought
I
had
is
that
maybe
we
can
utilize
our
sharding
on
the
controller
so
that
projects
can
get
onto
like
its
own
shards.
That.
D
Then
yeah,
then
the
tenancy
is
more
isolated
for
so
I
think
one
option
is
to
to
provide
that
isolation.
B
D
B
A
B
I
mean
when
I
mean
what
comes
to
us.
You
know
new,
I
think
newer
shards
wouldn't
get
created
because
it
has
reached
the
limit,
which
probably
will
not
be
a
very
bad
thing.
The
existing
shads
would
be
performance
to
an
optimum
level.
Only
and
not
beyond
that.
I
think
yeah
I
think
chessy.
I
I
like
that,
but.
B
A
I
feel
like
if
we
really
make
it
kind
of
we
can
keep
moving.
You
know
go
on
and
go
on
and
build
on
top
of
it
and
always
almost
going
to
build
kind
of
sus.
You
know
like
machinery
to
run
size
version
of.
Obviously
I
think
it's
out
of
scope
for
project,
but
if
we
you
know,
if
someone
really
needs
that
they
can
manipulate
projects-
and
you
know
on
on
the
fly
kind
of
create
new
charts,
assign.
B
A
quick,
quick
question
on
this
in
general.
I
think
it's
a
slightly
different
question,
what
we
are
discussing,
but
on
the
same
proposal,
you
said
that
you
know
folks
would
be
creating
the
secrets
referring
to
the
project
and
I
think
in
general,
the
our
back
is
going
to
ensure
whether
that
thing
would
be
honored
in
the
first
place
in
which
namespace
would
this
secret
live?
Are
you
referring
to.
B
A
A
What
is
it
a
repo
ad
or
clustered
as
normal,
so
user
not
supposed
to
have
access
to
argo,
cd,
namespace
and
then,
but
the
difference
is
that
user
would
have
to
supply
field
project
and
if
project
field
is
supplied,
then
our
bug
should
check
against
this
policy.
Basically
it
should.
It
should
make
sure
that
you
have
a
permission
to
create
under
specific
project
and
only
admins
has
access
to
creating
star
like
any
and
under
any
projects
and
end
users
kind
of
limited
to
projects.
A
B
I
think
yeah
I
mean
if,
if
I
had
to
put
and
just
for
the
and
probably
just
just
so
that
we
write
it
there
and
it's
well
acknowledged
for
somebody
in
the
future
to
come
and
mention
it
that
this
potentially
does
let
the
does
let
users
to
create
secrets
in
the
argo,
cd
control,
plane,
name
space.
I'm
not
sure
I
mean
that's,
that's
somewhere,
not
saying
that
it's
bad,
but
I
think
if
something
goes
wrong,
they
do
have
a
way
to
create
secrets.
A
Okay,
I
think
it's
already
kind
of
taking
care
of
it
like
we
admins
create
secrets
all
the
time
and
we
want
to-
and
we
have
you
know
all
applications
in
code
to
make
sure
the
secrets
don't
leak
but
yeah.
I
think
I
will
mention
it
too.
So
basically,
this
way
user
end
user
is
going
to
upload
his
secrets
into
argo
cd,
and
I
think
we
should
make
it
explicit
that
it's
going
to
be
available
to
admin.
Admin
can
easily
read
the
secrets
and
you
kind
of
trust
admin
in
this
case,
but
right.
B
A
Can
update
it
but
ipi
do
not
return
secrets,
so
you
can
get,
but
you
would
get
only
a
list
of
registered
repositories,
urls
and
clusters,
but
not
the
secret
part
of
it.
A
B
Yeah
I
mean
my
question
would
be,
let's
say:
let's
say
you
know
alex
you
add
a
secret
or
like
you,
you
using
the
cli.
Add
this
one
and
then
can
I
inevitably
update
yours.
A
Okay,
if
you
admin,
then
you
can,
if
you
someone
else,
if
you
another
user
from
another
project,
you
cannot
but
admins
can
do
anything.
Admin
can
basically.
B
B
A
And
this
is
basically
we,
of
course
we
can
have
you
kind
of
can
split
project
into
you
know
like
sub
projects
using
airbag
as
well.
You
can
say
admin
one
admin,
two
here
and
then
here's
example
of
kind
of
more
complicated
arbuck,
so
you
can,
if
it's
not
necessary
start
here,
you
can
say
this
particular
admin
role
give
access
to
manage
credentials
only
of
repositories
under
github.com.mycompany.com,
or
it
can
be
just
a
full
repository
url
here.
B
Got
it
got
it
okay,
so
so
in
that
case,
I
think
you
will
do
proj
myproj
that
would
have
applied
for
non-admin
users
as
well
right,
so
proj
myproj,
alex
repository,
updated
update
and
then
a
url
that
would
also
work
right.
Yes,
yeah.
Okay,
all
right!
Thank.
A
You
okay,
so
basically
the
open
question
is,
I
think
we
yeah.
I
need
to
add
more
details
about
this
idea
to
add
charts
and
hopefully,
I'm
kind
of
trying
to
find
a
way
not
to
reinvent
some
limiting.
You
know
some
way
to
specify
limits
and
I
will
try
to
do
first
step
and
add
in
document
idea
about
assigning
charts
to
cluster
and
it
feels
like.
Maybe
we
need
some
way
to
kind
of,
let
users
specify
trading
function
and
include
projects
into
it.
A
F
If
you
have
you
know,
two
is
the
same
as
as
a
user,
I
can
have
the
create
the
same
repo
in
different
project
scope
and
there
and
then
so
so
I'm
allowed
to
have
just
create
the
same
people
in
different
under
different
projects.
Right
so
that's,
I
think,
that's
all
the
whole
point
of
providing
the
scope
provided
kind
of
isolation.
A
Yeah-
and
I-
and
I
was
talking
about
you-
know
limits
for,
I
feel
like
everything
is
fine
with
kind
of
projects
is
the
late
teams
from
each
other,
but
because,
no
matter
how
many
projects
you
have,
you
still
have
one
shared
controller
and
that
controller
uses
resources,
and
if
one
project
has
too
many
clusters,
then
you
kind
of
affect
all
other
projects
and
yeah,
and
then
this
limiting
mechanism
can
can
kind
of
can
protect
projects
from
from
one.
You
know
one
from
another.
A
A
A
Yeah
so
I
first
I
was
proposing
to
have
these
couple
things
in
annotations,
and
then
I
was
convinced
that
it's
just
okay
to
have
it
in
string
data,
but
I
agree
with
your
argument
that
it
will
be
hard
to
read
and
kind
of
the
only
reason
to
keep
it
like
this.
Is
we
already
have
clusters
and
clusters
exactly
like
that,
so
clusters
kind
of
have
just
everything
in
string
data?
A
No
everyone
hates
them.
It's
almost
impossible
to
come
up
with
a
cluster
secret
by
hand,
and
I
know
that
people
spend
a
lot
of
time
to
kind
of
at
least
we
get
a
lot
of
questions
about
it
and
we
can
only
make
it
simpler
by
keep
working
on
argo,
cd,
youtube
and
argus
util
kind
of
I
think
it's
it's
makes
it
simple
enough
and
I'm
not
sure
if
he
understood
in
in
this
music.
A
So
yes
and
okay
personally,
I
kind
of
I
like
this
idea
at
least
because
I'm
so
passionate
about
rbcd
youtube
and
I
have
big,
you
know
hopes
for
the
tool.
It's
I
added
it
into
ocd
homebrew.
So
it's
easy
to
install
it
now
and
basically
argus
youtube.
Just
provides
you
a
convenience
command
generate
spec
and
it
takes
this
all
these
arguments
as
a
command
line,
flux
and
then
it
produces
secret.
So
it's
kind
of
okay.
Now
it's
possible
to
generate
that
secret.
A
F
His
porn
is
about
reading
what
the
secret!
Because!
Because!
Because
it's
the
basics
for
encoding,
that
to
read.
A
A
Another
option:
I
mean
another
kind
of
contra
argument
that
you
still
have
argo
cd,
cli
and
you
can
just
say:
argosy
dcli
get
repos
and
it
would
show
you
all
the
ripples
and
I
think
it's
like
it's
not
very
common.
If
you
need
to
get
password
because,
usually
you
know
your
password
not
supposed
to
be
turret
very
easily.
A
Okay
and
yeah,
we
didn't
basically
we'll
have
to
continue
discussing
it
offline,
maybe
jc.
You
have
some
awesome
idea
to
to
make
it
simple.
Suddenly.
D
I
think
it's.
I
was
about
to
point
out
that
your
balance,
so
if
you
split
it
to
crds,
you
have
a
different
inconvenience,
which
is
your
data
is
split
into
two
different
objects,
yeah,
which
is
I
mean,
which
is
why
we
originally
went
with
the
secret
approach,
because
really
the
only
non-sensitive
thing
was
the
name
of
it
and
the
url.
I
think
that's
right.
A
Secrets
so
it's
like
I
mean
it's,
it
may
be
more
work
to
manage
that
cid
because
you
have
to
start
typing
instead
of
just
type
the
key
and
value
you're
supposed
to
type
something
like
value
from
secret,
key
name,
x
and
and
yeah.
So
it's
way
more
yeah.
D
Yeah,
I
I
I
I
think
that
it
went
in
and
we
had
the
ap
for
people
who
want
us.
Actually,
the
api
server
doesn't
return
secrets.
I
was
about
to
say
that
api
server
can
put
it
in
the
convenient.
I
think.
A
A
D
But,
on
the
other
hand,
an
argument
that
we
for
a
crd
is
that
you
know
how
we
started:
keeping
track
of
status
of
clusters
and
status
of
yeah
repositories
right
now,
it's
in
in
in
regis.
A
Agree
that
you
know
if
it's
in
status
then
potentially
someone
else
can
I
don't
know
you
can
maybe
use
some
some
kind
of
side
project
to
send
alerts
about
status
changes.
So
you
can
use.
You
know
kubernetes
cid,
as
api.
D
A
We
also
like
I,
I
was
thinking
that
it
would
be
nice
to
have
status
for
repositories
too
yeah,
but
so
remember
we
have
this
one
of
the
performance
optimization
optimizations
we
have
is,
we
want
to
store,
we
want
to
cash
resolved
revisions
for
repository
and
that
will
go
into
cash,
but
that
information
is
kind
of
useful.
You
know
it
would
be
nice
to
have
one
day,
repo
profile
page,
you
open
it,
and
then
you
see
what
revisions
circuit
cd
discovered,
and
you
know
when
the
refresh
happened
last
time
and
maybe
refresh
button.
D
A
Okay,
yeah,
but
kind
of
just
a
heads
up
that
work
on
it
is
in
progress
right
now.
D
A
I
think
we
will
soon
we'll
get
pr
that
implements
this
approach
and
we
can
maybe
continue
discussion
in
pr.
I
I
doubt
we
can
easily
kind
of
introduce
crd,
because
I
think
if
you
decide
to
go
through
cid,
you
should
have
already
planned
to
use
it
really.
You
know
like
use
status
and
maybe
build
ui
on
top
of
that
status.
Otherwise
it's
a
it's.
D
Like
yeah,
I
agree:
it's,
the
crd
approach
is
a
much
much
bigger
change,
so
this
is,
I
think,
how
we
should
resolve
this
near
near
term,
because
anyways
you,
you
want
it
in
a
separate
secret,
like
at
the
end
of
the
day,
no
matter
what
you
need
a
secret
to
back
the.