►
From YouTube: Argo CD and Rollouts Community Meeting April 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
A
I
think
two
of
them
are
already
accepted,
I'm
not
sure
about
the
third
one,
but
these
will
be
upcoming
features
on
the
argo
cd
road
map
and
it's
your
chance
to
kind
of
help
shape
that
before
they
come
into
realization,
just
a
reminder
that
these
argo
adheres
to
the
cncf
code
of
conduct,
so
please
be
courteous
and
respectful
during
this
meeting
and
this
meeting
is
being
recorded
and
will
be
uploaded
to
youtube
after.
A
Finally,
if
you
do
have
any
other
agenda
items
or
issues
or
discussion,
topics
feel
free
to
add
them
to
the
suggestion
on
the
google
doc
and
we'll
see
if
we
can
get
to
them.
This
go
around
okay.
So,
let's
see
first,
we
had.
A
Okay,
so
someone
put
on
community
developer
contributor
documentation
is
that
person
online.
B
Hey
good
morning,
everyone
pleasure
to
meet
everybody.
I
had
put
that
I've
been
recently
trying
to
collaborate
a
little
bit.
I
think
I
did
some
documentation
a
few
months
ago
and
I
wanted
a
bump
helm
version
to
the
latest.
B
I
had
a
pr
up,
but
I
I
had
quite
a
difficult
time
setting
up
on
my
mac
m1,
so
I'd
love
to
as
I've
been
kind
of
troubleshooting
and
doing
a
little
bit
of
that
I'd
love
that
somebody
could
help
not
so
much
mentor
me,
but
I've
seen
some
of
the
tooling
that's
missing
in
the
documentation
and
I'd
love
to
maybe
update
that
documentation,
and
maybe
some
of
the
tooling
I've
picked
up
from
alex
mt
has
a
gift
in
some
space
in
his
personal
repo,
and
I
got
some
documentation
from
there
of
some
tooling,
like
the
I
think,
grpc
or
the
proc
tools,
and
I
got
other
stuff
from
the
official
largo
project
repo
and
then
some
other
tool
didn't
work
and
I
just
kind
of
like
went
working
through
it.
B
So
I
think,
as
part
of
maybe
developer
onboarding
somebody
who's
trying
to
help
like
myself,
I'm
already
running
through
some
of
these
pains.
I
still
have
some
of
them
as
I'm
failing
some
integration
tests
that
I
I'll
figure
it
out
eventually,
but
I'd
love
to
maybe
put
this
somewhere
and
maybe
get
a
little
help
of.
Where
should
I
put
this
so
somebody
else
like
myself
doesn't
encounter
it
again.
B
I
think
the
documentation
is
great
and
there's
a
lot
of
things
there,
but
some
other
things
aren't
there
like
some
flags
that
I
that
I
kind
of
slacked
and
hey.
What
do
I
do
in
this
scenario
and
somebody
hey
put
this
flag,
so
I'd
love
to
update
that
documentation,
so
it's
just
easier
for
anybody
else
to
come
in
and
do
that,
but
I'd
love
to
pair
with
somebody
to
kind
of
like
who
can
I
bounce
the
ball?
Yeah.
A
I
I
let
me
do
some
historical
stuff,
so
originally
like
tool
chain
was
a
very
like
environment
dependent,
I
would
say,
in
other
words,
you
have
to
say
brew
and
solve.
This
bruins
saw
that
and
that
was
actually
highly
dependent
on
the
time
point
when
you
executed
that
command,
so
that
didn't
obviously
wasn't
very
portable.
A
And
then
we
went
to
this
containerized
model
where
kind
of
everything
happened
into
inside
the
docker
container,
and
that
was
portable,
but
it
was
really
really
slow
to
build,
and
I
think
I
mean
that
option
is
still,
I
believe,
what's
documented
right
now
and
probably
the
thing
that
we
tell
everyone,
but
in
my
view
the
the
future
state
is
that
we
we
go
back
to
localized,
build
but
with
predictable
or
are
consistently
reproducible
tool
chain,
and
I
did
make
some
strides
on
that
by
making
things
like
produce
c
and
I
think
the
majority
all
the
golang
based
tools
are
now
compiled
under
the
dist
directory
of
argo
cd.
A
So
the
ideal
state
is
that
someone
clones
argo
cd.
I
think
they
run
make
install
local
tool
chain
or
something
like
that,
and
then
at
that
point
they
have
everything
they
need
and
the
dist
path
gets
out.
It
gets
added
to
the
path
so
that
it
prefers
that
when
running
all
the
ede
tests
or
all
the
codrun
and
stuff,
I
don't
think
so-
we're
not
there
yet
and
that
this
this
doesn't
uncover
the
ui
stuff
as
well.
A
So
on
this
topic,
I
think
the
the
right
thing
we
should
be
doing
is
is
kind
of
making
more
steps
towards
portable
local
tool
chains,
and
I
I
I
can.
I
think
I
can
like
help
out
on
that
side.
Like
maybe
point
you
in
the
right
direction
on
how
that
could
be,
we
can
start
going
that
direction.
C
C
Yeah,
and-
and
basically
I
think
I
just
want
to
second
jc-
is
that
right
now
this
documentation,
it
has
only
docker
based
steps
but
looks
like
we
want
to.
It
works
for
everyone
who
is
on
linux,
because
docker
is
much
quicker
on
linux
and
but
mac
users
just
don't
use
it,
because
it's
too
slow
or
you
know
some
people
use
it,
but
it's
just
not
the
best
experience.
C
B
Even
the
docker
experience
I'm
having
issues
with,
but
I
I'll
I'll
ping
you
and
I'll
I'll
ping,
a
couple
of
other
folks
who
kindly
messaged
back
at
me
and
I
will
do
a
pr
against
that
documentation
base.
Maybe
that
can
help
you.
A
Yeah,
that's
the
right
audience,
for
these
are
basically
other
argo
developers.
Then
kind
of
more
developer
focused
discussions.
B
A
Thanks
all
right,
thank
you,
michael
miguel.
Sorry,
okay,
I
think
next
there's
it
looks
like
there's
two
issues
I
think
from
ray
ray.
Are
you
raymond.
A
Yeah,
so
you
you
raised
two
issues.
I
guess
that
are
maybe
getting
ignored,
so
you
want.
D
To
talk
about
that
yeah
sure
the
first
one
is
basically
adding
secrets
for
clusters
that
you
can
use
the
exec
plugin.
You
actually
responded
to
me
like
a
while
back
and
it
was
like
an
issue
with
the
cubeless
and
then
on
the
last
comment.
Someone
was
posting
another
thread
for
gke
authentication
and
there's
workarounds
on
there
and
then
the
last
thing
in
that
thread
was
a
new
authentication
proposal
from
alexander,
oh
yeah.
D
I
was
kind
of
wondering
what
the
best
way
to
handle
this
is
right
now,
because
I
right
now
I'm
doing
like
a
hack
where
I
have
like
a
post
sync
that
will
do
just
like
an
argo
cd
cluster
ad,
which
is
not
really
ideal.
I
would
like
to
use
the.
A
D
A
Oh
okay,
so
wouldn't
you
prefer
to
use
google
iam
to
auth
authenticate
the
next
remote
gke
cluster
to
the
con
argo
city
control
plane?
Rather,
I
think
you're
going
you're
trying
to
get
the
secret
in
a
secure
manner
and
then
and
then
just
use
with
basic
auth
to
connect
to
that
cluster.
D
Basically,
I
try
to
do
like
the
g
cloud
command
like
you
know
how,
when
you
have
gke,
you
click
connect
and
then
it
gives
you
the
gcloud
command
to
to
validate,
and
then
it
will
just
generate
the
effects
and
all
that
so
kind
of
a
programmatic
way
of
handling
this,
but
maintaining
it
maintaining
it
in
the
secret.
C
D
Opposed
to
a
hacky,
postsync
job.
A
Yeah
so.
A
Maybe,
with
a
google
workload
identities,
might
I
ultimately
we
don't
have
good
support
for
gcke.
I
know
that's
why
this
whole.
This
other
issue
exists
in
the
first
place,
but
my
understanding
was
that-
and
maybe
I
could
be
wrong
on
this,
but
I
I
believe
that
the
ultimate
landing
point
was
that
argo
cd
control
plane
would
run
with
a
workload
identity
on
gke
which
somehow
using
google
commands
would
be
able
to
passwordless
authenticate
to
remote
gke
clusters.
D
I
could
try
that,
but
how
does
that
interact
with
the
secret?
Like
do?
I
need
to
put
it
on
which
the
point.
F
B
D
Right,
I
I
can
do
the
the
workload
identity,
but
how
do
I
put
that
into
the
the
secret
so
that
argo
cd
has
the
clusters,
like
all
the
ips
and
certificates.
C
Yeah,
maybe
we
can
take
it
offline,
but
what
the
first
thought
was
that
I
know
that
in
argo
cd
you
can
register
a
cluster
and
don't
give
it
don't
specify
any
keys
there
and
then
argo
cd
will
try
to
use
just
you
know
just
the
board
credentials
to
talk
to
the
cluster
and
then.
C
D
I'm
using
the
argo
cd
cli
in
my
post,
sync.
A
I
I
think
I
forget
what
the
blocker
was
for
this
receipt,
alex
the
blocker.
C
Is
I
failed
to,
I
think
I
just
stuck,
and
maybe
now
I
really
want
to
sync
up.
Is
you
know
sad
because
he
probably
knows
some
details
yeah
and
then
I
I
just
could
not
do
it.
You
know
I
kind
of
unbox
the
problem
and
then
spend
two
hours
and
I
give
up,
but
now
I
want
to
try
again
yeah
and
it
looks
like
what
I
I
really
need.
I
just
need
to
replicate
this
snippet
in
go
link
and
that's
it
yeah,
and
then
it
will
finally
unblock
the
pull
request
and
okay
yeah.
A
But
ray,
I
think
the
ultimate
thing
is
you
shouldn't
I,
I
don't
think
you
should
be
dealing
with
secrets
at
all,
because
if,
if
the
the
right
trust
relationships
are
set
up
the
pod
itself,
google
will
recognize
this
part.
As
someone
who
can
yeah.
C
And
I
I
think
this
this
I
can
help
you
I
can
help
to
you
know
I
can
send
you.
Basically,
you
can
have
a
declarative
secret
definition
and
I
could
help
you
to
get
this
declarative
definition
kind
of
offline.
I
will
just
yeah.
I
will
basically
send
you
a
snippet.
D
Yeah,
okay,
yeah!
Maybe
you
can
respond
also
on
the
github
issue.
C
Let
me
please
copy
the
thing.
C
D
Yeah,
okay
and
then
the
second
issue
was
something
that
popped
up
in
2-3-0
and
then
basically,
if
you
change
to
list
or
summary
view,
the
everything
would
revert
back
to
the
original
view.
So
terry
fixed
that
and
then
I
noticed
in
231.
When
I
tried
to
delete
an
application,
it
would
again
revert
back
to
the
view
that
you
have
there
so
that
that
works
for
deleting
an
app
with
non
cascading
and
then
also,
if
you
don't.
D
C
A
Thanks
alex
yeah,
the
regressions
have
higher
priority
items.
So
if.
A
A
Sure
all
right,
so
second
proposal
was
how
we
will
be
able
to
have
flexible
primarization
of
config
management
plugins,
and
is
that
you
leo
yes,.
F
Actually,
I
work
with
michael,
if
I
don't
know
how
to
answer
something.
Michael
could
please
jump
in
yeah.
We
work
together.
Also
alex
worked
a
lot
on
this
one
so
like.
Let
me
share
my
screen.
F
Okay,
so
if
you're,
not
if
you're
not
familiar
cmp
stands
for
configuration
management
plugin
and
the
idea
is
just
providing
a
little
bit
of
a
background,
the
idea
is
to
be
able
to
do
something
like
what
argo
cd
does
with
customize
and
helm
charts
but
outside
of
of
argo
city
code
base.
So
is
the
plugin
to
allow
argo
cd
to
generate
manifest
for
different
sort
of
manifest
generators?
If
you
will
so,
the
most
famous
ones
today
are
customizing
and
home
charts.
F
So
by
the
time
we
conclude
this
cmp
v2,
because
there
there
was
a
cmp
v1
back
in
the
days,
but
it
was
a
little
bit
limited,
so
we
created
v2
and
the
missing
piece
in
v2
is
because
it
didn't
allow
the
plugin
to
interact
with
the
ui
to
provide
parameters.
So
today,
for
example,
if
you
want
to
sync
a
specific
application,
so
I
have
just
a
very
simplistic
application
here
deployed
locally
and
if
you
want
to
provide
parameters,
values
from
the
from
argo
cd
ui
while
syncing.
F
If
this
is
going
through
a
cmp
provider,
we
we
we
lost
this
ability.
So
the
the
the
the
main
reason
of
why
we
work
in
this
proposal
is
to
bring
back
this
parameterization
functionality
to
the
to
the
cmp
landscape,
so
cmp
developers
could
leverage
this
and
ui
would
dynamically
create
some
panel
here
with
what
the
plugin
developer
defines
right.
F
So
I'm
not
thinking
about
going
in
a
lot
of
details
in
the
in
the
in
the
proposal,
maybe
just
on
the
two
main
aspects
of
it.
So
when
you're
defining
a
a
cmp,
the
idea
is
that
you're
you'll
be
defining
most
of
the
times
two
to
two
files
inside
your
your
cmp
one
is
the
the
config
management
plugin
manifest,
which
is
not
a
rio
crd.
F
F
So
here
you
can
find
things
like
the
title:
the
tooltip,
if
it's
required
or
not
the
item
type
and
the
collection
type.
So
if,
if
this
parameter
is
a
simple
string
or
in
there
are
some
cases
where
we're
gonna
be
accepting
a
map
or
an
array,
so
this
is
one
of
the
pieces
that
we
kind
of
discussed
quite
a
lot,
and
we
came
up
with
this
with
this
format.
F
F
So
that's
that's
the
idea
so
that
that
are
the
possibilities
that
developers
will
be
able
to
use
while
defining
the
cmp
configuration.
Then
the
other
file
is
is,
is
a
bash
script
that
the
cmp
will
be
invoking
for
generating
the
manifest
themselves
and
the
bash
script
will
be
provided
an
environment
variable
that
will
be
having
all
the
values
that
were
passed
by
the
ui
back
to
the
cmp
container
with
the
actual
values
the
user
wants
to
generate
manifests
with.
F
So
that's
the
the
big
the
big
picture
of
the
this
new
new
feature
and
again
I'm
not
it's
a
it's
a
big
proposal.
We
we
discussed
quite
a
few
questions
and,
and
we
challenged
different
ideas,
so
that's
the
current
state,
it's
it's
approved
it's
merged
in
argo,
cd
and
right
now
we
are
in
in
stage
of
planning
the
the
start
of
the
work
and
actually
planning
who's
going
to
be
implementing.
What
so,
that's
about
it.
If
you
have
any
questions,
please
let
us
know.
A
I
have
a
question
yep
did
did.
Was
it
considered
a
lot
to
use
so
right
now,
parameters
looks
like
a
like
a
flat
list
of
key
to
value
where
value
can
be
flexible
in
its
type
like
it
can
be
a
map
or
list
or
string
or
something
is
that.
Is
that
correct?
Yes,
yes,
that's
correct.
Did
you
consider
at
all
using
like
open
api?
So
so
is
it
possible
to
have
more
deeper
nested
structures
like,
for
example,
helm?
A
F
A
So
I
I
think
that
the
problem
I'm
thinking
of
is
that
if
you
have
well-defined
structure
that
are
nested
under
the
parameter,
so
maybe
you
had,
I
think
values.
Values
is
a
bad
example
right
now,
but.
A
I,
okay,
actually,
let's
say
customize
this
example.
So
what
did
what
is
customize
look
like
in
this
cmp
v2?
Is
it
possible
to
capture
all
of
our
customized
parameters
like
the
image
name
prefix?
I
could.
Those
are
actually
easy
too
well.
What
I'm
thinking
of
is,
if
you
have
a
more
complex
structure
of
nested,
structs
yeah,
but
it's
hard
for
me
to
come
up
with
the
example
right
now.
F
Yeah
our
our
idea
on
that
is
that
we
could
leverage
the
map
key
to
provide
the
complex
struct
that
you
you
would
have
in
the
in
that
plugin
and
that
could
be
passed
to
the
to
the
underlying
binary
to
generate
to
provide
that
that
parameter
value,
that
that
was
our
idea.
C
To
be,
maybe
add
a
little
bit
of
at
least
my
perspective,
why
we
didn't
think
about
open
api
in
the
first
place?
I
think
at
least
I
was
thinking
mostly
about
plug-in
developer
experience
so
that
this
design
is
kind
of
as
friendly
as
we
could
get
from
the
developer
perspective.
So
whoever
is
writing
plugin,
most
likely
is
going
to
use
brush
and
it
felt
like
it
would
be
easy
to.
You
know,
use
this
structure
yeah,
and
that
was
the
just
one
reason
why
we
didn't
even
consider
it.
E
We
made
a
point
to
make
sure
we
thought
that
this
structure
would
solve
all
the
use
cases
that
helm
and
customize
currently
present.
Even
if
it
is
a
little
bit
hacky,
I
think
it
will
be
able
to
present
an
on
par
experience
but
yeah.
If
we
get
to
a
point
where
folks
really
want
to
have
rich
parameter
structures,
then
we
could
definitely
consider
like
json
schema
open
api.
C
Do
you
think
I
think
that,
like
two
questions,
you
know
customs
hema
versus
open
api
and
ability
to
have
nested
parameters
in
general?
Would
it
help
jc
if
we
just
keep
the
room
in
the
spec
to
possibly
add
nested
parameters,
yeah.
A
A
I've
been
messing
with
crossplane
recently
a
lot
and
crossplane
has
to
be
very
freeform
in
in
how
they
you
define
the
this,
the
schemas,
and
so
they
expect
you
to
to
have
very
complex,
structured
objects.
But
you
have
to
the
consequences
that
I
have
to
come
up
with
an
open
api
spec
to
define
those
so
that
the
specs
gets
validated
and
and
rejects
like
invalid
schemas,
but
I
don't
it
might
be.
I
think
it
might
be
overkill
for
this.
As
long
as
we
leave
room,
I
think
for
that
possibility
in
the
future.
C
Okay,
I
think
we
we
can
do
it.
I
think
there
is,
it
could
be
just
you
know,
additional
field
items
under
parameters
or
something
like
that.
E
I
think
we'll
actually
need
to
add
an
additional
field,
besides
string
array
and
map,
if
we
want
full
helm
support,
because
someone
has
added
raw
yaml
support
to
the
helm,
values
field.
A
E
I
think
we
could
solve
that
just
by
adding
a
raw
field
and
then,
if
we
wanted
to
validate
it
to
get
some
spec,
the
announcement
could
include.
You
know
something
that
holds
a
json
schema
or
whatever,
and
then
the
ui
can
validate
it
or
even
generate
ui
based
on
it.
E
A
C
A
Yeah
ashita,
I
notice
you're
still
muted,
so
I'm
not
sure
if
you're
trying
to
mess
with
the
microphone
versus
the
zoom.
C
C
A
C
C
Awesome,
thank
you.
So
I
will
start
from.
I
want
to
start
from
use
cases
and
basically,
we
identified
two
main
inconveniences
that
our
users
are
facing,
so
one
of
them
is
related
to
home.
Chart
that's
the
best
example
of
the
use
case.
So
basically
users
have
a
helm
based
application
and
typically
it's
the
off-the-shelf
home
chart
in
the
repository
that
users
don't
have
control
over
and
at
the
same
time,
users
wants
to
use
various
files.
That
is
also
committed
in
git
in
some
other
repository,
and
so
the
use
cases
that
we
have.
C
We
want
to
get
files
from
two
repositories
and
then
generate
manifests
from
only
one
report
and
during
manifest
generation
we
want
to
reference
value
files
committed
in
another
repo.
So
that's
first
use
case
and
second,
sometimes
argus
users
just
want
to
create
application.
That
consists
of
two
charts,
and
maybe
the
typical
example
is
like
two
home
charts.
C
One
includes
crd
definitions
and
second
uses
the
crts,
and
it
just
sometimes
makes
sense
to
combine
those
two
into
one
application
and
right
now,
it's
impossible,
because
argo
cd
application
allows
users
to
specify
only
one
git
depository,
and
so
we
want
to
propose
a
change
and
improve
it.
So
both
use
cases
would
be
solved
natively,
and
so
the
proposal
is
to
introduce
new
field
called
sources,
and
this
is
right
now
on
the
screen.
Let
me
just
make
my
screen
a
little
bigger
so
that
the
sources
is
the
only
difference
between
source
and
sources.
C
Is
that
sources
is
an
array
and
the
structure
of
each
item
in
that
array
is
same
as
structure
of
a
source,
so
it
would
have
ripple
url,
target
revision
and
then
some
config
management,
two
specific
parameters,
and
then
we
want
to
eventually
duplicate
the
source
field
and
the
initially
behavior
would
be
that
you
can
set
only
one
of
those.
C
Actually,
you
can
set
both
fields,
but
if
you
set
sources,
argo
cd
would
just
ignore
the
source
and
maybe
print
a
warning
in
logs,
and
this
this
change
is
already
enough
to
cover
the
second
use
case
that
I
mentioned,
where
you
just
want
to
have
an
application
that
consists
of
two
health
charts,
for
example,
and
so
to
satisfy
that
use
case.
You
would
just
need
to
mention
those
both
home
charts
in
in
in
the
sources,
so
you
would
have
to
create
second
item,
and
at
least
and
that's
it.
C
The
use
case
is
solved
and
the
other
use
case
about
referencing
files
is
a
little
bit
more
complex
because
of
two
things.
First
of
all,
in
this
use
case,
the
second
repository
that
has
files
should
not
produce
any
manifests,
and
somehow
we
need
to
tell
to
argo
cd
that
the
second
source
is
just
source
of
files.
It's
not
really
source
of
real
manifests
and
to
make
it
possible.
We
want
to
make
a
second
change.
C
C
How
do
you
express
in
your
spec
that
you
want
to
get
files
from
another
repo
and
to
make
that
possible?
We
want
to
introduce
a
new
field
on
the
source
called
ref,
and
actually
it's
a
subject
to
change.
I
think
we
want
to
make
it
name
instead
of
ref,
but
I
would
use
ref
because
it's
this
is
what
we
have
in
documentation
right
now.
But
rf
is
basically
a
name
of
that
source
and
you
can
basically
use
environment.
C
Variable
substitution
in
your
second
source
definition,
the
reference
files
from
the
first
source,
and,
let
me
start
from
from
beginning
so.
Basically
I
want
to
render
elasticsearch
home
chart
and
I
want
to
get
values
files
which
is
in
my
personal
repository,
and
so
in
this
case
I
would
have
to
if
define
two
sources.
C
The
first
source
points
to
my
personal
repository.
C
C
I
have
a
pointer
to
the
help
chart
repository.
It
has
a
path,
so
verbosity
knows
it
needs
to
generate
manifests
from
from
here
and
inside
of
the
vario
files.
I
use
the
reference
name
to
resolve
the
location
of
this.
Second
sorry
of
this
first
repository,
and
so
the
targo
cd
knows
that
it
needs
to
it.
Will
argo
cd
will
replace
this
environment?
C
This
reference
is
the
real
path
and
then
value
files.
This
this
second
portion
is
just
a
relative
path
within
my
repository
that
points
to
values.yaml
file,
and
that's
it
that's
the
proposal.
C
When
we
decided
to
use
environment
levels
so
so,
how
is
this
going
to
interact?
I
guess
with
the
cmp
the.
E
C
C
You
know
we
kind
of
have
to
introduce
these
magical
syntaxes
and
the
other
option
that
we
considered
was
to
make
a
let's
say
for
the
helm.
We
could
have
first
class
support
for
sources,
so
we
were
really
thinking
to
duplicate
values,
radio
files,
a
field
and
then
transform
it
into
some
strongly
strongly
typed
array
and
that
each
item
would
have
source,
and
so
it
would
be.
C
You
know,
less
magical
and
kind
of
the
validation
would
work
in
in
the
crg,
but
it
would
not
work
with
config
management
plugins,
because
each
and
every
plugin
would
have
to
have
support
for
for
sources,
and
so
that's
why
we
realized
that
it's
not
the
best
decision
and
but
this
environment
variables
kind
of
help
us
to
support
sources
in
config
management
plugins
transparently,
and
that
the
one
idea
it's
not
like
100
defined
how
we
will
going
to
do
it
exactly.
But
one
idea
is
that
we
can
simply.
C
Change
with
the
contract
so
right
now,
config
management
plugins
receive
a
turbo
and
they
enter
it
into
some
random
location.
And
so
one
idea
I
had
this
that
we
cargo
cg
can.
C
If
this
is
the
case,
argo
cd
is
going
to
know
how
the
value
of
this
my
repo
environment,
variable
basically
algorithm,
is
going
to
know
how
this
variable
should
be
resolved
to
you
know,
to
which
path
it
should
be
resolved
to,
and
so
argo
cd
can
perform
that
substitution
and
so
for
config
management
plugin.
It
would
look
like
it
doesn't
even
know
about.
C
Multiple
sources,
it
would
just
get
a
bunch
of
files
with
a
bunch
of
folders
and
the
tar
would
have
several
hippos
instead
of
one.
It
would
then
turn
it
into
some
predictable
location
and
then
it
would
get
argosy
so
config
management
plugin
would
receive
this
portion,
but
there
is
no
environment
variables
in
it.
It
would
be
resolved
origin.
E
Yeah,
I
think
it
does.
Yes,
thanks.
C
Yeah,
it's
like
it
kind
of
requires
yeah
like
we
need
to
think
about
it.
Like
another
option,
is
to
delegate
there
is
a
you
know,
resolution
of
those
environment
variables
to
the
plugin
itself
right,
and
it
should
not
be
too
difficult
actually
to
implement
because
it's
it
can
be
a
simple
convention
like
so
either
keep
that
knowledge
on
argo
cd,
but
that
would
require
like
argus.
C
You
would
have
to
tell
to
config
management
plugin
where
to
extract
the
files
or
yeah,
or
we
can
just
have
convention
so
that,
and
we
can
tell
that
plugins
must
resolve
those
variables.
But
rule
is
simple
enough.
Maybe
there
is
even
third
option.
We
can
resolve
it
to
relative
process
and
then
the
convention
would
be
run.
Config
management
tool.
C
D
C
A
But
we're,
I
think
the
main
point
is
the
the
the
use
of
this
environment
very
well
seems
at
first
it
it
at
first
glance
it
looks
very
magical
right.
It's
it's
not
a
well-structured
thing,
but
I
think
the
driving
force
behind
it
was
was
because
of
config
management.
Plug-Ins.
We
didn't
want
those
things
to
have
to
deal
with
the
understanding
of
multiple
sources.
It
would
just
have
to
be
told
where
to
find
things
at
precise
locations,
and
I
and
I
think
it's
still
in
the
implementation
like
how
that
will
be
accomplished.
C
C
It's
possible,
like
there
are
a
set
of
environment
variables
that
available
during
config
management
during
manifest
generation,
and
it's
already
possible
to
use
those
environment
variables
in
you
know
in
the
source
spec
and
because
we
already
do
it,
it's
kind
of
makes
it
a
little
less
magical.
So
it's
not
like
we're
inventing
a
new
thing
from
from
scratch.
A
So
miguel
asked
in
chat
with
it
with
a
handle
escaping
the
dollar
sign
for
a
folder.
It
may
be
named
dollar
sign
web.
C
I
mean
the
source
code
that
we
I
mean.
We
already
have
this
environment
variable
substitution
code
written
and
we
support
I'm
escaping.
So
basically,
you
can
have
two
dollars
here:
yeah.
C
Yeah,
the
main
problem
is
that,
like
we,
we
want
to
have
immutable.
Config
management
like
immutable,
manifests
and
that's
why
we,
the
source,
must
have
that
source
have
to
have
a
revision
and
that's
like
config
map
doesn't
have
revision,
so
it's
kind
of
it
can
change
unpredictably
and
we
don't
know
you
know
when
a
change.
C
You
can
certainly
get
a
you
know,
deployment
in
production
or
like
argus
educations
everything,
and
it
uses
this
revision
as
a
key.
Basically,
it
is
always
to
commit
and
knows
that
you
know
if
the
key
is
the
same,
it
will
not
try
to
regenerate
manifests.
So,
even
if
you,
if,
if
we
make
it
possible
to
use
configmap
argo
seed,
you
just
won't
notice
that
configmap
changed.
E
I
think
there
are
a
couple
cons
to
variable
substitution
that
we
should
consider
one
being
certain
tools.
There
may
be
intuitive
places
where
you
would
use
multi-sources,
but
couldn't
because
you
don't
have
access
to
the
environment
variable.
For
example,
if
I
have
a
customized
repo
that
just
applies
a
patch
to
another
source's
base,
I'm
not
sure
how
I
could
reference
that
other
base,
because
you
can't
use
environment
variables
in
a
customized
file.
A
They're
variables
they're,
basically
variables
that
are
pre-substituted
before
any
template
invocation
of
the
the
the
binary,
so
I
guess
they're
yaml
think
about
them
as
ammo
variables
that
either
ideally
is
handled
by
the
repo
server
before
the
plugin
even
knows
about
it.
That,
ideally
that's
where
we
want
to
land,
but
in
the
worst
case
it
would
plugins
would
have
to
know
that
hey
I
might
need
here
are
two
sources,
and
and
this
whenever
you
see
this
dollar
sign
repo,
it
refers
to
the
path
of
the
other
source.
A
That's
the
worst
case,
but
by
the
time
customized
build
happens.
They
won't
have
customized,
build,
won't
know
about
this.
This
dollar
sign
my
repo.
C
But
actually
I
thought
about
the
customize,
like
example:
actually,
customize
won't
really
help
but
like
in
customized
in
general,
the
problem
is,
you
cannot
pass
parameters,
so
that's
why
I
don't
know
how
we
would
resolve
it
for
customize.
But
if
you
use
something
like
jsonnet
jsonnet
can
you
know,
can
read
environment
variables,
real
environment
variables,
so
I
was
thinking
we
can
have
a
convention
like
we
can
have
you
know
if
all
the
source
names
can
be
also
available
in
real
environment
variables,
and
it
could
be.
C
As
environment,
yes,
I
would
wait
for
you
case
because
it
would
not
help
customize
because,
like
in
customize,
you
cannot
use
environment
variable
to
point
to
conditionally
point
to
like
remote
source,
but
you
could
do
it
and
invest
on
it.
I
would
just
I
was
waiting
for
you
know
if
we
get
request
like
this,
for,
for
example,
for
actually
jsonnet
is
not
good
example
too,
because
jsonnet
has
the
similar
parameter.
E
My
other
concern
is
that
the
path
itself,
the
path
itself
as
of
2.3,
is
sensitive
and
I'm
not
sure
we're
going
to
have
good
enough
control
over
where
that
gets
output,
for
example,
into
a
config
map.
For
someone
to
read.
E
C
It
would
know
that
the
real
location
of
them
in
this
example
of
this
repository
right.
So
maybe
I'm
not
following
here,
but
I
kind
of
it
feels
to
me
that
if
you
don't
trust
that
the
tool
itself,
then
it's
kind
of
yeah.
A
Okay,
we
have
one
more
michael
said,
micro
proposal.
E
Yeah,
hopefully
short,
and
if
people
think
it's
a
real
proposal,
I'll
convert
it
into
a
real
proposal,
but
it
seems
simple
enough
to
be
just
an
issue.
E
The
idea
is
currently
if
someone
wants
to
debug
a
broken
application
or
just
kind
of
know,
what's
happening
in
an
app,
they
have
to
dig
into
the
individual
resources,
look
at
events
for,
say
an
individual
pod
and
try
to
figure
out
what's
up,
and
even
when
you
do
that,
you
don't
really
know
what
that
event
looks
like
in
relation
to
other
events
that
have
happened
in
an
application,
so
I've
proposed
adding
this
button
or
putting
a
button
somewhere.
E
I
just
put
it
here
that
pulls
in
all
the
events,
for
the
application
keeps
it
automatically
updated,
puts
them
in
chronological
order.
So
I
can
see
that
there
was
an
error
here,
and
maybe
I
know
what
these
mean
in
relation
to
that.
Maybe
they
were
caused
by
that
error.
E
If
I
want
to
drill
in
and
see
the
event
specific
to
a
certain
resource,
just
click,
it
pulls
up
that
resources.
Events,
tab,
there's
a
slot,
that's
sort
of
up
in
the
air
here
things
that
could
be
improved,
but
the
basic
idea
is
we
want
to
make
it
to
where
folks
can
get
to
the
problematic
event
quickly.
A
Yeah,
we,
I
think
we
had
one
thing:
that's
been
perpetually
on
our
roadmap
about
like
a
timeline
view.
That's
it
would
be
like
adjacent
to
the
the
tree
view
and
the
pod
view
and
the
network
view.
I
was
thinking
that
that
proposal
was
actually
going
a
little
bit
further
in
that
events
was
just
one.
A
I
guess.
Actually
the
timeline
view
would
be
essentially
the
same
thing
as
what
you're
seeing
here
but
presented
like
in
a
timeline.
So
imagine
that
there's
this
kind
of
bar
going
across
the
the
page,
but
with
dots
kind
of
sprinkled
in
the
when
actually
they're,
because
events
are
spanned,
it
would
be
kind
of
spans
of
time
when
the
events
were
happening,
and
I
think,
as
part
of
that
view,
you
could
maybe
look
at
it
in
a
list
view
or
go
back
to
that
time.
View
and
click
on
like
certain.
A
E
A
A
Yeah
yeah,
no,
I
think
that's
probably
the
best
picture
of
it.
I
don't.
C
Know
do
you
always
less
like?
If
I
mean
ui
is
not
like
a
cld
spec,
so
we
can
change
it
like.
No
one
is
going.
C
A
Oh
yeah
yeah,
I
guess
we
could
we
can
do
it
in
stages
so
like
this
is
probably
I
mean
this
is
obviously
already
working.
So
I'm
I'm
sure
people
really
appreciate
this
coming
in
earlier
and
then
you
know
in
a
later
release
having
a
more
sophisticated
view.
C
A
How
michael,
how
do
you
get
all
events,
but
then
also
filter
to
the
application.
E
Yeah
right
now,
I'm
getting
all
events
looping
over
the
resource
nodes
or
the
event
application,
resource
nodes
and
filtering
them.
I'm
considering
maybe
a
more
performant
way
would
be
to
construct
a
filter
before
you
even
go
to
the
kubernetes
api.
C
Yeah,
don't
we
don't
we
it's
it's
not
like
all
events.
It's
events
from
the
target
name,
space
on
the
right.
A
Okay,
yeah,
that
I
think
that
was
that's
the
best
you
can
do
for
name
space,
but
then
as
soon
as
stuff
crosses
name
spaces.
Then,
where
you're
going
to
have
this
somehow
have
to
figure
out
a
performant
way
of
looking
at
events
like
in
many
many
spaces.
E
An
answer
to
chat
filters.
Yes,
just
eventually,
maybe
enough
of
the
initial
release.
A
All
right
so
sounds
like
oh
well,
I
I
was
the
only
one
talking,
but
I
don't
know
if
anyone
had
any
opinions
on
this,
but
personally
I
I
really
been
wanting
this
for
a
while.
So.
A
All
right
so
we're
at
the
hour
thanks
everyone
for
attending
this
month's
community
meeting
and
as
always,
we
have
weekly
contributors
meeting
for
argos
eating
rollouts
on
thursdays
and
then,
if
you're
interested
in
workflows,
we
have
weekly
scrums
on
tuesday
mornings,
as
well
as
the
monthly
workflow
community
meeting
on
this
third
wednesday
of
every
month.