►
From YouTube: Argo Contributors Office Hours Jan 6th 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
All
right,
hi,
everyone
welcome
to
the
argo
contributors
meeting
happy
new
year.
This
is
the
first
contributors
meeting
for
2022
and
let's
get
started
so
I'll,
be
your
host
today
and
starting
off
with
triage
as
usual.
How
do
you
to.
B
B
B
So
maybe
we
can
start
from
first
starting
so
jonathan,
do
you
want
to
be
primary
for
the
week.
B
Probably
michael,
my
is
michael,
there.
B
D
It
went
well,
I
I
felt
a
little
spoiled
because
there
weren't
tons
of
issues
you
know
going
into
the
break,
so
it
wasn't
too
bad.
A
No
actually,
okay,
okay,
sorry,
but
I
heard
something:
okay
cool,
so
let's
move
forward.
So
the
next
topic
of
the
day
is
from
alex
to
add
support
for
secrets
in
application
parameters
so
alex
with
you
right.
C
And
if
you
don't
mind,
can
you
maybe
open
the
url
of
this
yeah
yeah?
So
this
the
title
of
this
topic
is
just
the
issue
title
and
I
basically
in
you
know
in
that
meeting.
I
wanted
to
propose
to
consider
adding
it
to
roadmap
again
and
just
a
reminder.
It.
Okay,
it's
it
was
created.
The
issue
was
created
two
years
ago
and
the
idea
of
the
issue
is
to
support
referencing
secrets
in
application
parameters
so
and
the
yellow
on
the
screen
right
now.
C
C
I
think
we
even
landed
on
only
design
that
we
like
and
the
ticket
was
not
completed
because
we
as
we
were
brainstorming.
We
realized
that
it
will
require
a
lot
of
work.
The
support
of
secrets
will
require
a
lot
of
work
because
it's
not
enough
to
just
resolve
secret
videos.
We
also
need
to
store
those
values.
C
For
example,
if
someone
sync
an
application
using
some
values
that
were
retrieved
from
secrets,
we
need
to
store
it
in
history,
and
that
means
we
need
to
start
protecting
history
because
it's
not
okay
to
reveal
secret
values.
And
so,
even
though
we
like
the
idea,
because
we
decided
not
to
do
it
because
of
we
didn't
have
people
to
do
it
and
I
have
a
feeling
now.
C
A
Okay,
one
thing
I
didn't
understand
alex
is
the
latest
proposal
for
this
one,
where
it
is.
C
Yes,
actually
I
I
was
sure
it's
here
in
the
ticket,
but
apparently
there
is
also
a
pull
request
and
oh
okay,
never
mind
yeah,
it's
right.
There
yeah.
This
is
the
it's
the
final
at
least
yaml
structure
that
okay,
it
was
even
for
me.
D
C
So
we
we
just
agreed
to
support
like
all
kind
of
parameters,
whether
it's
helm
or
you
know
just
json
that
case
on
it.
Typically,
we
have
a
field
value
and
I
think
we're
suggesting
here
to,
in
addition
to
value,
support
value
from
just
like
kubernetes
and
and
support
referencing
secrets
here:
yeah,
that's
it
and
so,
and
then,
and
that
this
you
know
this
comment
kind
of
have
a
little
bit
of
implementation
details,
but
basically
we
can
on
the
fly.
C
We
can
resolve
value
from
and
replace
it
with
the
real
value
and
then
what's
not
covered
here
is
once
we
resolve
secret
value,
it's
not
clear.
How
do
we
make
sure?
No
one
else
see
it,
because
those
values
will
show
up
in
in
some
in
logs,
because
we
need
to
send
values
from
controller
to
repo
server
and
then
once
someone's
use
those
values
to
sync
application.
They
will
end
up
in
sync
history,
which
is
not
desirable,
desirable
as
well.
So
basically,
the
first
step
is
easy.
C
C
If
the
user
wants
to
yeah
right
now,
people
have
to
come
up
with.
You
know
creative
solutions
like
some
like
either
we
did
it
right.
We
at
intuit,
we
have
a
case
to
resolve
a
secret
and
what
we
did
we,
what
you
mounted
a
secret
as
the
environment,
variable
into
reaper
server,
and
then
we,
you
know,
use
config
management
tool
to
to
reference
that
environment
variable
and
this
one.
This
is
the
way
we
can
inject
secret
into.
C
C
D
C
Think
that's
the
point.
There
is
no
good
solution,
it's
possible,
but
it
requires
some
scripting
or
something
like
some.
A
And
having
it
mounted
as
a
volume
would
require
the
the
application
to
be
to
get
restarted
if
we
change
something
yeah
so,
and
this
approach
would
allow
values
to
be
dynamically
defined
at
the
application
level.
Yes,
oh
yeah,
it's.
C
Okay-
and
I
think
we
we
can-
you
know
this-
we
supposed
to
get
a
real
proposal
for
it.
I
think
I
wanted
to
get
heads
up
from
from
people
or
hear
anyone
have
objections
to
work
on
that
proposal,
but
yeah.
I
think
in
that
comment
we're
proposing
to
use
you
know
reference
secrets
in
argus
genome
space,
using
this
value
from
sleeping
yeah,
and
I
guess
it's
up
to
admin,
how
the
secrets
get
into
our
cd.
C
Actually
I
mean
we
can,
if
you
keep
thinking
about
it
like
we
could
have
a
user
interface
for
end
users
to
create
such
secrets
and
maybe
even
like
it
depends
how
much
we
want
to
invest
in
it,
but
we
can
stop
here
and
just
support
referencing
secrets
or
we
can
build
in
secret
management,
and
I
don't
know
to
be
honest,
I
I
would
not.
I
think
it's
it's
a
slippery
slope.
C
If
we
start
building
secret
management
in
our
city,
I
would
rather
just
just
support
referencing
secrets
that
are
already
there
and
then
and
make
sure
that
there
is
at
least
one
good
solution
that
help
people
to
get
those
secrets
into
the
rbc
inner
space.
C
And
then
yeah
another
reason
to
have
it
is
because
other
projects
have
it
basically,
flux,
has
secret
management
and
and
that
the
reason
people
sometimes
choose
flux
over
rcg
is
lack
of
secret
management.
So
it's
okay.
I
think
it's
everyone
agrees
like
so
far.
I
haven't
heard
from
anyone
that
it's
not
important
and
we
don't
want
it.
The
main
argument
not
to
do
it
was
just
lack
of
I
mean
not
even
lack
of
time.
We
had
other
things
to
do
and.
C
B
There
are
back
also
added
as
a
part
of
it
like
so
who,
who
will
have?
The
control
is
only
they've
been.
C
Screwed
yeah,
I
think
it's
yeah.
I
don't
have
answer
right
now,
but
you're
right.
I
think
it's
not
okay
to
let
anyone
in
their
application
reference
any
kind
of
secret
it.
Maybe
they
have
to
be
tied
to
a
project
like
you
know.
The
secret
has
to
have
a
has
to
belong
to
project,
and
maybe
you
know
we
can
just
have
a
label
on
a
secret
or
not
even
label.
We
already
have
pattern.
We
have
projects
called
clusters
and
repositories
and
we're
just
using
project
field
in
secret
data
to
identify
its
part
of
project.
C
So
we
could
do
the
same
here.
We
could
say
yeah,
so
basically
we
can
have
a
way
to
link
a
secret
to
a
project
and-
and
then
in
this
way
our
back
problem
will
be
solved
like
and
then
controller
can
make
sure
that
user
referencing
secret
and
it
will
resolve
secret,
where
you
only
if
secret
is
part
of
a
project.
D
I
I
kind
of
favor
using
something
like
sealed
secrets
right
or
even
like
a
vault
or
something
like
one
of
the
one
of
the
sort
of
deficiencies
of
vault.
Is
it
doesn't
necessarily
monitor
like
state
in
the
way
that,
like
argo,
cd
does
so
if
something
changes
in
the
values
in
production
or
something
like
that,
so
there
I
don't
know,
I
I
kind
of
think,
maybe
an
alternative
approach
to
have
better
support
for
these
things,
because
if
we're
just
grabbing
a
secret
and
saying
you
can
reference
it,
I
don't
know.
D
C
D
C
D
C
Yes,
and
and
and
volts
still
can
be
used
to
some
like.
Basically,
there
is
integration
rate
for
for
kubernetes
involved,
and
people
can
use
that
integration
and
use
vault
to
manage
secrets,
and
arguably
is
just
going
to
basically
in
this
case,
kubernetes
secrets
are
just
a
simple
api,
too.
A
Okay,
thank
you
alex
all
right
that
wraps
up
the
topics
that
we
had
planned
for
today.
Anybody
else
has
anything
like
last
minute.
Topic
wanted
to
discuss,
feel
free
to
do
so,
because
we
have
some
extra
time
today.
A
No
well,
if
not,
maybe
we
should
make
a
shorter
meeting
today.
A
Okay,
so
thanks
everyone
and
see
you
again
next
week.