►
From YouTube: Argo Contributors Office Hours Jan 13rd 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
Right,
I
just
restarted.
Recording
so
good
morning,
good
evening,
everyone
I'm
going
to
start
from
showing
my
screen
just
to
show
our
agenda
to
everyone
and
yeah.
We
traditionally
start
from
you
know,
sharing
feedback
from
triage.
If
anything,
you
know
unexpected
was
reported
and
we
need
to
choose
who
is
going
to
be
moderator
next
week.
B
Yeah,
so
shall
I
go
ahead.
Look
at
this
okay,
awesome,
yeah,
so
pretty
straightforward
week,
triaging
issues
the
both
the
bugs
and
the
enhancements
were
reasonably
well
defined.
B
As
for
questions
in
a
few
cases
and
likewise
answering
the
discussions
that
came
up
in
the
question
side
of
the
argo
cd
repository,
the
one
bug
that
I
wanted
to
bring
up
with
this
one
just
because
I
didn't
really
have
an
answer
for
it
and
it
kind
of
seemed
like
we
were,
that
that
it
was
kind
of
just
inherent
to
the
way
that
the
argos,
cd
architect
architecture
was
set
up.
So
argo
cd
bug
8113,
the
user
was
hitting
issues
with
synchronizing
their
application.
B
B
So
the
resources
that
were
being
generated
were
so
large
as
to
generate
when
argo
cd
goes
to
update
the
status
field
and,
of
course,
the
status
field
represents
each
of
the
resources
that
are
contained
within
the
application.
It's
just
too
much
for
the
status
field
to
handle,
so
it
sounds
like
we're
overflowing
the
capacity
of
the
etcd
server
to
contain
all
that
data.
B
Do
we
have
any
suggestions
for
how
someone
could
handle
this
case?
My
suggestion
was
to
refactor
their
application,
but
like
has
anyone
else
encountered?
B
A
We
could
suggest
them,
so
we
we're
not
storing
the
full
resource,
but
we
store
the
whole
list
and
kind
of
high
level
statuses,
and
I
I
know
that
we
store
it
in
status
and-
and
we
have
sync
history
and
think
history
will
have
the
same
list
of
600
resources.
So
I
think
they
can
change
and
there
is
a
way
they
can
overwrite
thing
history
limits
and
basically
they
can
just
reduce
it
to.
A
B
Right
yeah,
you
reminded
me
that
that
exists.
I
think
at
one
point
I
had
known,
but
when
scanning
through
the
documentation
again,
I
had
set
my
mind
but
yeah
I'll
I'll,
find
that,
because
you've
reminded
me
that
it
exists.
C
A
Simplest
way
to
find
is
to
basically
they
can
change
it.
Even
in
the
ui
they
can
click
application,
details,
tab
and,
and
it
has
revision
history,
but
in
general
it
seems
like
it's
like
it's
a
limitation.
Basically,
we
maybe
we
need
to
rethink
again
where
to
store
the
history
like
the
deployment
history.
That's
what
causes
this
type
of
issues,
because
we
yeah
it's
usually
okay
to
store.
I
think
we
store
only
10
most
decent
things,
but
basically
every
thing
include
all
resources.
A
D
True
right,
the
I
thought
one
operation
will
store
the
sync
result,
so
I
think
we
double
it,
but
we
don't
oh,
but
this
is.
D
Never
that's
better,
I
mean
I
mean
unless
we
switch
to
like
a
sync
job
or
some
task
model.
As
of
now,
operations
will
store
the
most
recent
sync
result,
which
does
include
all
the
resources
and
like
what
happens
in
messages
and
stuff.
But
the
history
is
nothing
but
revision,
so
I
don't
think
it
will
help
them
at
all
to
reduce
that
that
limit.
D
Yeah,
so
it's
more
of
a
fundamental
problem
that
I
don't
know
that
we
can
address,
because
600
resources
have
to
one
has
to
be
like
the
status
health
status
and
sync
status.
Two
will
be
in
the
operator.
I'm
actually
surprised,
though,
that
we
do
exceed
one
megabyte
just
with
600.
B
It
wasn't
clear
from
the
way
the
user
phrased
it
if
it
was
600
per
helm,
chart
or
600
in
total,
I'm
assuming
it's
total.
Otherwise
it
would
be
like
I
don't
know
tens
of
thousands
of
resources
or
something
like
that.
600
yeah,
like
you
said,
did
seem
a
bit
low,
but
they
didn't
really
give
any
additional
detail
into
like
what
kind
of
resources
they
were
dealing
with,
and
I
didn't
ask.
D
Yeah,
I
thought
okay,
so
I
mean
I,
I
think,
the
the
recommendation
that
we
should
have,
because
I
I
don't
know
that
this
can
be
fixed.
I
I
have
a
feeling
based
on
the
sentence.
It
says:
30
35,
helm,
charts
and
these
charts
create
approximately
more
than
600
resources.
So
it's
a
multiplier.
B
More
generous
with
my
interpretation
but
yeah,
it's
ambiguous.
D
Yeah,
so
I
think
for
this
user,
like
the
apps,
that
might
be
the
best
way
to
get
out
of
this.
So
then
you
create
a
app
set
that
iterates
to
helm,
charts
somehow
and
then
creates
apps
from
that
yeah.
B
Sounds
good
yeah.
I
was
just
curious
if
you
all
had
dealt
with
applications
that
were
large
enough
to
start
hitting
this
limit.
It
sounds
like.
Maybe
it's
just
because
we're
representing
all
of
those
resources
within
the
status
field,
there
will
naturally
be
an
upper
limit,
so
it's
up
to
users
of
argo
cd
to
ensure
that
their
applications
don't
get
close
to
that
limit.
Yeah
I'll
take
a
look
at
the
field
that
did
alex
suggested,
although
it
sounds
like.
B
Maybe
it's
not
gonna
do
what
we
need,
but
yeah
I'll
I'll,
try
that
out
just
regardless
and
yeah
I'll
reply
on
the
issue
but
yeah,
I
just
thought
I'd
bring
this
one
up
in
case.
This
was
something
that
other
folks
had
hit.
Whether
this
was
just
the
app
the
application
the
user
was
generating
was
just
so
large
as
to
be
unrealistic
for
any
any
deployment
tool,
or
if
this
was
something
that
we
wanted
to
think
a
bit
more
about
so
yeah.
That's
it
for
me.
E
On
the
thinking
a
bit
more
about
it,
I
know
argo
workflows,
compresses
node
statuses
if
it
starts
to
get
too
large,
but
it
is
a
bit
of
a
band-aid.
A
We
can
talk
about
it,
you
know,
but
basically
we
there
was
another
request
that
we
were
just
discussing
it
offline,
I
think,
is
why
but
user
asked
to
store
divs
of
synced
resources
in
the
history,
so
basically
when,
when
we
think
we
need
to
we,
we
have
this
the
list
of
patches
that
we
apply
and
that's
nice
to
have
it
in
history,
but
we
obviously
cannot
store
it.
So
maybe
like
should
we
consider
introducing
a
database
or
using
maybe
radius
more?
D
I
would
I
wouldn't
go
that
far.
I
do
think
there's
a
there's.
We've
always
talked
about
diffing
across
revisions
just
but
by
using,
because
if
they're
we
have
to
commit
shaw
of
what
they.
F
D
And
if
what
is
in
git
is
truly
immutable,
then
it
doesn't
really
matter
if
we
cache
it
in
in
redis
or
or
post
request.
The
problem
occurs
if
that
hash
changes,
meaning
over
time.
A
D
But
I
I
consider
that
a
feature,
a
lot
of
limitations,
this
lack
of
storage
but
yeah,
it's
a,
but
it's
a
big
decision
to
go
that
route.
A
Okay,
one
last
maybe
a
question
like:
do
you
think
it
does?
It
makes
sense
to
file
an
issue
too.
I
feel
like
it
would
be
better
user
experience.
If
argo
cd
is
self-protected,
I
saw
the
ticket
and
right
now
what
happens
is
application
kind
of
freezes,
because
it
can
no
longer
update
its
own
status
and
that's
it
and
it's
kind
of
you
know
using
no
clear.
A
Yeah,
so
the
better
behavior
would
be
to,
I
don't
know,
create
an
error
message
here
and
explicitly
say
that
hey
you
have
too
many
resources.
We
cannot
proceed.
G
D
That
that
would
be
yeah
if
we
write
if
we
try
to
save
the
app
and
we
encounter
like
the
size
limit.
That's
a
specific
error
where
we
can
yeah.
A
D
A
D
D
F
D
D
Okay,
so
the
I
guess
the
follow-up
issue
for
this
is
so
we
need
to
when
x,
when
we
try
to
save
an
app
as
part
of
our
operation
and
we
encountered
a
size
or
actually
any
time
we
tried
to
save
the
map
and
the
size
is
too
big.
Then
we
can
drop
the
operation
status,
stuff
with
error
and
then
and
then
have
a
warning
condition.
I
guess.
D
A
Yeah,
I
think
it's
better
yeah
right.
We
need
more.
We
said
we
need
to
select
next
moderator
for
the
next
week,
so
it's
no
longer
jonathan
and
michael.
A
Pasha,
I
don't
think
he's
in
the
meeting.
I
know
he's
on
location,
I
think
yeah.
So,
basically
all
right
if.
F
A
No
I'm
scanning
for
a
list
of
people
right
now.
I
don't
see
him
all
right.
If
there
are
no
volunteers,
I'm
going
to
just
make
sure
the
primary
she's
here
and
she
didn't
say
no,
maybe
some
connection
issues
and
then
just
follow
up
offline
and
and
the
the
primary
or
the
secondary.
Actually
I
can
do
secondary,
I
don't
mind
to
be
secondary
as
well
yeah
and
then
I'm
on
at
least
you
know.
F
A
A
Basically
the
choice
we
have
is
to
release
right
now,
release
what
we
have
or
keep
working.
I
think
we
agreed
that
we
want
to
release
no
matter
what,
and
so
this
is
the
plan,
so
we
were
planning
to
work
on
on
following
features
and
so
far
we've
got
merged
identifications
compact
resource
tree
and
maintain
difference
in
in
the
cluster
and
git
values,
plus
a
ton
of
kind
of
smaller
enhancements
that
are
not
on
the
list,
but
this
is
where
we
are,
and
I
think
almost
no
chance.
A
We
can
get
home
values,
maybe
small
chance.
There
is
web
shell
coming
because
I
know
that
guys
from
by
dance
was
working
on
it.
A
Oh,
and
I
forget
to
mention-
or
probably
I
mentioned,
but
we
were
planning
to
release
by
end
of
january,
so
we
have
two
more
weeks
to
get.
It
done
definitely
enough
time
to
polish
already
completed
features,
and
you
know
close
all
the
bugs.
I
don't
think
like
definitely
not
enough
time
to
complete
everything.
A
My
proposal
is
to
actually
to
try
to
release
you
know
by
end
of
january,
and
I
don't
think
like
the
only
disadvantage
is
that
maybe
users
who
looked
into
that
roadmap,
you
know
will
be
disappointed.
They
will
not
get
everything,
but
we
have
good
explanati
the
excuse
we
have
is
holidays.
We
can
tell
that
yeah
holidays
usually
affect
plans.
I
But
I
I
think
that's
fine.
I
I
mean
that's
that's
what
we
agreed
yupo
when
we
said
we
release
every
quarter
right.
What's
what's
not
finished,
it's
it's
not
finished
and.
A
Yeah,
so
I'm
pretty
sure
that
you
know
if
we
talk
in
details,
we
can
like
there
will
be
some
explanation.
At
least
I
know
about
some
history
about
every
feature
why
it
was
maybe
not
even
started
or
like
postponed
and
yeah.
A
Okay,
any
anyone
has
strong
objections
or-
and
I
think
what
happens
if
we
decide
to
do
it,
then
maybe
we
should
be
more
careful
with
you
know
like
now.
I
would
not
be.
I
wouldn't
create
release
branch
right
now.
I
would
try
to
you
know
test
it
a
little
bit
more
and
then
we
have
some
things
that
we
want
to
finish.
I
guess
before
we
create
release
branch,
and
that
means
we
have
to
be
more
careful.
We
should
not
introduce
big
breaking
changes
right
now,.
F
Or
whatever
the
match
upgrade
controller,
can
it
be
included
or
directly
or
we
actually.
A
A
F
B
Yeah,
for
that
one,
the
next
step
is
ishita
has
provided
the
pr.
I
need
to
go
and
take
a
look.
It
looks
like
everything's
building,
okay,
so
I
need
to
dive
in
and
review.
What's
changed.
A
If
not,
then
we
can
just
say:
okay
wait
for
the
next
application,
so
I
think
it's
it's
going
to
be
similar
to
argus
identifications,
and
this
was
not
that
it
was
not
very
bad.
It
was
kind
of
we
just
moved
some
code
from
one
repo
to
another
repo,
and
then
we
had
few
for
bug
fixes,
but
nothing
terribly
bad
happened,
no
big
redesigns
so,
and
I
hope
application
set
is
same
because
it's
similar.
A
A
Okay,
that's
that's
my
update
about
three
release
and
next
we
have
20
more
minutes.
So,
michael,
if
you
want
to
talk
about
the
cmp
proposal
that
you
worked
on,
that
you're
working
on
yeah.
E
E
So
this
proposal
talks
about
how
we
are
going
to
communicate
parameterization
from
an
application
up
to
the
ui
and
allow
users
to
to
edit
it
just
like
they
would
with
the
helm
interface
or
the
customized
parameters.
Interface,
yeah,
it's
a
bit
long.
So
I
would
appreciate
comments.
Yeah
general
thoughts
on
the
design.
A
A
F
I'll
give
the
same
update
as
the
serious
one
we
als
argo
roads
also
wants
to
do
the
release
in
two
to
three
weeks.
So
right
now,
we
kind
of
whatever
the
rehearsal
that
are
currently
in
the
review.
We'll
try
to
get
him
and
no
more
enhancements
from
now
on,
so
for
the
next
two
to
three
weeks,
we'll
be
focusing
on
bugs
and
if
anyone
has
any
priority
items
or
anything,
please
let
us
know
now,
so
that
will
try
to
get
them
in.
F
Otherwise
I
think
the
next
few
two
weeks
will
be
focused
on
the
bus
and
as
every
time
I
say
that
help
will
be
needed.
So
anyone
wants
to
contribute.
Please
come
forward.
E
I
can
share
the
screens,
I'm
probably
going
to
jump
around
this
document.
A
lot
yeah
go
ahead.
Let's
see.
E
Cool
I'm
going
to
start
with,
basically
what
we're
trying
to
achieve
with
plugins
that
already
exist
for
native
config
management
tools,
so
in
helm,
if
you
have
an
application,
that's
pulling
from
a
helm,
repo,
argo
cd
will
do
the
work
for
you
to
go,
find
all
of
the
parameters
which
are
available
in
the
values.yaml
file.
It'll,
give
you
a
nice
interface
for
all
of
them.
E
So
the
question
is:
how
do
we
make
it
possible
for
config
management
plugins,
which
currently
are
pretty
simplistic
sidecar
living
alongside
the
repo
server?
How
do
we
allow
them
to
communicate
up
to
argo
cd
here
are
the
parameters
that
I
can
accept
for
a
given
application
and
designing.
This
have
tried
to
maintain
a
balance
between
being
as
flexible
as
possible,
so
that
the
things
that
we
don't
think
about
right
away
about
how
users
might
want
to
communicate
parameters
or
cmps
communicate
parameters
to
the
ui.
E
We
can
accommodate
those
changes
in
the
future,
but
it
also
needs
to
be
a
strict
enough
definition
that
we
can
actually
do
this
and
present
a
ui
that
has
like
sections
and
potentially
different
input
types
like
values
here
is
multi-line
text
field
for
customize.
It
needs
to
accept
images
which
I
think
are
three
text
boxes
for
the
different
parts
of
an
image.
E
So
what
I've
come
up
with,
I
should
say:
we've
come
up
with
because
I've
bounced
ideas
off
a
number
of
people.
For
this
we
want
to
provide
a
new
section
in
the
config
management,
plug-in
configuration
called
parameters
or
whatever,
but
basically
the
user
is
going
to
have
a
command
and
that
command
is
going
to
produce
something
to
standard
out
that
the
ui
continues
to
present
present
the
parameters
to
the
user
and
then
in
turn,
this
command
will
get
access
to
a
new.
E
I
think
we'll
use
an
environment
variable,
I'm
a
little
bit
worried
about
size
constraints,
but
I
don't
think
it'll
be
a
big
deal,
but
the
environment
variable
would
hold
some
sort
of
data
about
what
parameters
have
been
set
and
so
far
I'm
thinking
json
communication,
both
from
the
standard
out
of
the
parameters
and
into
the
environment
variable
for
the
generate
command.
E
So
for
communicating
parameters
in
I'm
thinking
make
it
look
basically
like
the
ui
have
a
section
either
called
main
or
maybe
helm
name
it
after
the
cmp,
I'm
not
sure.
Yet.
I
don't
know
if
I
want
this
to
be
magic
word
or
not,
but
anyway
there
will
be
sections
of
parameters.
E
Sections
both
allow
us
to
break
up
this
manifest
in
a
way,
that's
easy
to
read
and
also
disambiguate
between
parameters
that
just
so
happen
to
have
the
same
name.
So
if
I
added
values,
files,
helm
parameter
for
a
particular
chart,
it
wouldn't
conflict
with
the
top
level
values
information.
E
So
that's
what
it
looks
like
going
in
this
would
just
be
converted
to
json
before
being
read
by
your
manifest
generation
code,
it's
a
little
bit
more
complex
communicating
information
out
of
your
cmp
to
the
ui,
a
few
more
fields.
So
I'm
thinking
you
need
a
parameter
name.
Obviously
you
need
a
section
to
disambiguate
from
say
top
level
in
helm
parameters.
E
These
two
I'm
a
little
bit
fuzzier
on.
I
think
that
we
should
probably
have
some
way
of
communicating
at
the
type
like
this
is
a
string
versus
an
image
or
say
a
number
if
we
wanted
to
start
accepting
numbers
and
then
an
arbitrary
json
object
which
can
communicate
just
whatever
other
information,
you
might
want,
say
whether
a
field
is
required.
E
E
So
for
someone
who
is
trying
to
generate
what
I'm
calling
a
parameters
announcement,
just
a
list
of
these
objects,
this
is
what
they
have
to
produce
just
a
json
object
with
either
leaving
defaults
like
this
one
defaults
to
the
main
section
and
this
one
defaults
to
uiconfig
or
specifying
explicitly
what
you
want.
E
E
E
D
I
have
a
question
so
with
parameters
to
put
config
management
plugins,
so
I
would
there's
kind
of
two
categories
of
parameters.
I
think
so
you
I'll
give
customize
is
one
example.
So
customize
has
very
well
known.
D
Parameters
like
image
tag
is
an
example
of
that
so
and
it's
the
same
for
any
type
of
customization.
Everyone
can
have
like
an
image
thing
or
name
prefix,
and
these
are
just
well-known
things.
Helm
is
like
a
different
category
because,
depending
on
the
values,
it's
different
for
every
chart
and
you
might
present
different
it's
dynamic
in
nature,
it
depends
on
the
specific
chart
in
question.
D
So
on
the
customize
things
I
want
to
predefine,
like
name
prefix
and
image
tag,
and
these
are
well
known-
that's
going
to
be
same
for
everyone
and
then
like
is
that
addressed
somehow.
E
That's
what
this
line
is
attempting
to
accomplish,
so
the
first
line
of
this
snippet
generates
your
dynamic
helm,
parameter
descriptions,
and
this
is
your
hard-coded.
You
know
this
cmp
or
config
management
tool
always
has
these
parameters.
Okay,
so
for
customize
it
could
be
super
simple.
You
could
just
have
echo
the
json
for
the
parameters
that
you
always
expect
for
customize.
A
To
I
just
had
a
proposal
to
maybe
even
make
it
more
friendly
for
such
type
of
parameters.
You
know
the
hardcoded
ones
if
we
can
just
define
them
in
a
json.
You
know
like,
in
addition
to
comment.
We
can
just
have
just
a
list
of
parameters
and
then
the
generate
command
in
the
generate
command.
We
can
have
explicit
mapping
between
input,
parameter
value
and
the
cli
flux
it
should
translate
to
so
you'll
kind
of
just
have
a
support.
Both
support.
Your
comments
for
complex
cases
and
support
very
well
known
cases
by
you
know
configuration.
D
Yeah
I,
as
can
I
say
it
would
be,
I
think,
if
you
scroll
up
just
slightly
yeah,
I
think
if
they're
well
known
well
defined
parameters
for
the
management
plugin,
they
would
belong
up
there
in
in
this
configuration,
because
to
me
it
doesn't
make
sense,
actually
the
command
produ
to
produce
static
inputs
things.
E
E
So
one
option
would
be,
I
add,
a
new
field,
maybe
called
announcement,
and
then
that
type
could
be
string,
and
I
could
just
ask
the
user
to
dump
in
you
know
a
json
blob
or
it
could
all
be
proper
yaml
and
proper
crd
fields
like
parameters
announcement
and
then
it
would
be
an
array
of
the
actual
announcement
objects.
A
A
D
Right
is
this
question
kind
of
suggesting,
as
an
alternative
for
just
using
a
raw
field
or
something
so
it's
a
free
free
form,
yaml
that.
D
Know
the
structure
ahead
of
time
is
that
the
alternative
approach.
E
The
alternative
would
be
technically
free
form,
but
we
would
expect
a
json
object
and
the
only
reason
I
suggest
that
is
for
consistency
like
if
we're
going
to
have
a
bunch
of
docs
we're
saying
you
know,
write
a
command
to
output,
a
stringify
json
object
describing
your
parameters.
It
might
be
a
bit
jarring
to
see.
Now
you
can
write
it
in.
You
know
in
yaml
here,
but
I
think
that's
a
pretty
small
concern.
D
Oh
yeah,
I
would
avoid
inline
strings
if
that's,
if
it's
that
that's
on
the
table
like,
let's
not,
let's
try
to
avoid
as
much
as
possible
inline
strings
in
the
streaks
of
json
or
inline
strings
of
yeah,
because
yeah.
A
D
Yeah,
actually,
the
the
dynamic
advertisement
of
available
parameters
at
the
app
level
or
at
the
chart
level
or
something
I
feel
like.
That's
probably
more.
The
10
case,
like
calm,
is
probably
the
only
example
I
can
think
of
where
you
you
have
to
show
dynamically.
What
is
what
parameters
are
available
even.
D
Oh
okay,
yeah
you're
right,
but
it's
it's
also.
That
was
like
a
convenience
that
we
did
just
for
the
actually.
Both
both
are
considered
convenience.
Things
like
in
both
cases
you
could
just
say
you
can
have
a
list
of
image
tags.
You
want
to
overwrite
many
of
them
might
not.
If
you
don't,
if
you
have
a
typo,
you
might
have
inputted
the
wrong
image
and
you
don't.
If
you
don't
know
your
app,
you
might
not
know
what
images
you
can
override.
D
The
same
is
true
with
helm
like.
If
you
don't
know
the
parameters,
you
can
blindly
just
say:
oh
foo
equals
y,
and
maybe
that's
a
values
file
that
you
can
set,
and
maybe
not,
but
I
guess
the
convenience
that
we're
providing
with
the
dynamic
thing
is
is
discovering
like.
Oh
here
are
the
things
I
discovered
and
then
we
should
show
it
in
the
ui
to
say
these
are
the
ones
you
might
want
configure.
D
Okay,
I
get
it
yeah
you're
right,
it's
not
just
home.
It's
it's
custom
right,
but
even
customize
would
be
benefit
from
it.
E
Should
we
define
interaction
between
the
announcement
and
command
field
and
say
either
like
concatenate
the
output
of
announcement
with
the
output
of
command?
If
someone
uses
both
or
throw
an
error,
if
someone
tries
to
use
both.
D
I
would
say
we
should
allow
for
both
like
helm.
I
think,
has
dynamics
f,
plus,
I
think
home
probably
has
like
an
option
that
includes
crds
or
I
don't
know
like
some
of
those
static
ones
that
are
in
the
command
line.
J
Also
for
the
the
non
parameters
example
like
customize-
I
guess
my
concern
is
that
if
we
set
this,
if
we
predefine
this
somewhere,
I'm
questioning
myself,
if
you're
defeating
defeating
the
purpose
of
the
plug-in
mechanism,
because
if
the
idea
is
to
externalize
things
out
of
argo
city
and
if
we
have
this
predefined,
some
somewhere
inside
argo
city
code
base,
if
we're
actually
yeah
defeating
the
purpose
of
the
the
what
we're
trying
to
achieve
here
with
with
the
plug-in
mechanism
with
the
new
plug-in
mechanism.
J
So
I'm
questioning
if
we
should
make
everything
dynamic
instead
of
having
predefined
code
somewhere
living
inside
the
cargo
city
code
base.
I
think.
J
D
I
think
everything
is
with
this
proposal
is
still
user
control.
It's
like
this
highlighted
thing
is
actually
a
user
control
thing
that
lives
inside
the
image.
So
it's
really
like.
Do
I
place
that
configuration
in
this
highlighted
text,
which
is
still
there
or
do
I
put
it
in
a
shell
script?
That
is
there,
but
it's
still
under
the
author's
control.
D
E
I
skimmed
over
something
that
alex
says.
I
don't
think
I
understood
it
at
first,
but
I
think
what
you're
suggesting
alex
is
one
option
would
be
allowing
this
declarative
block.
Someone
to
say
set,
I
think,
set
file
is
a
helm
command,
so
I'll
just
use
that
as
an
example
and
then
somehow
indicate
that
that
should
be
interpreted
as
an
argument
that
will
be
added
to
the
command
before
it's
executed.
A
Right
now
I
just
I
mean
basically,
there
are
definitely
like
two
parts.
You
know
the
parameter
name
and
then
some
additional
metadata
about
what
kind
of
type
it
has
and
so
on
and
then
and
if
user
put
some
value
into
the
parameter,
we
need
some
declarative
way
to
translate
it
back
to
you
know
to
the
bar
script.
E
A
A
D
Think
well
can
we
can
we
make
them
as
environment
variables
that
the
generate
command
can
trust
is
so
we
could
have
a
convention
on
the
parameters
becoming
environment
variables
that
they
can
then
leverage
as
part
of
the.
D
But
then
there
is
a
issue
about
conditional
like
oh:
if
it's
applied,
then
yeah,
then
you
add
dash
dash
like
release
name
equals.
You
know
the
release
name
parameter
so
yeah.
G
D
Think
I
mean,
if
you,
I
think,
github
actions
if
you've
written.
I
just
started
looking
at
github
actions
myself,
but
github
actions
has
inputs,
they
call
them
inputs
and
then
your
action
that
you
write
is
supposed
to
you
know
may
leverage
those
inputs
to
define.
I
I
think
we
can
look
at
like
what
they
do,
as
I
think
they
just
provide
everything
as
like,
ver
environment
variables,
it's
up
to
your
generic
script,
to
interpret
them.
D
So
it's
you
probably
your
generate
command,
probably
can't
accept
them
directly
as
arguments.
You
probably
have
to
write
a
gen
like
a
generate
command
that
then
looks
into
the
environment
variables
and
decides
whether
or
not
to
append
dash
release
name
to
the
ultimate
like
column
command.
E
My
hesitation
with
environment
variables
would
be
translation
because
I've
been
treating
parameter
names
as
if
they
can
be
arbitrary
strings,
so
you
could
run
into
conflicts
depending
or
collisions.
Depending
on
how
you
do
the
translation,
you
have
to
explain
that
translation
to
the
user.
It's
super
easy
for
things
like
set
file,
but
it
could
get
more
complex.
D
Yeah,
you
have
the
the
the
proposal,
so
we
can
work
offline,
so
I
think
we
should
continue
there
before
we
drop.
I
would
if
I
so.
I
realized
that
the
bug
that
the
user
hit
could
be
affected
by
sync
history
if
they
are
using
inline
values,
so
every
sink
could
could
record
in
the
cr
like.
Oh,
these
were
the
values
that
were
used
and
that
could
be
a
contributor
to
the
the
the
size
of
the
cr.
So
the
setting
that
we
talked
about
actually
might
get
him
out
of
that
situation.