►
From YouTube: Argo Contributors Office Hours July 28th 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
Hi
everyone
welcome
to
the
contributor
meeting,
I'm
going
to
be
your
host
today,
I'm
leo
and
starting
off
with
re-edge
and
discussion.
As
usual,
we
had
alex
and
remington
for
reviewers
for
the
previous
week.
Is
anybody
of
you
present
today?
A
Somebody
who
who
was
looking
at
the
tickets
this
week
had
any
thing
to
mention,
if
not
we're
just
going
to
move
forward
with
electing
the
next
person
for
next
week,.
A
Of
argos
cd
issues
is
anybody
able
to
be
secondary
for
next
week.
A
A
Thank
you
all
right.
So,
let's
move
with
discussion
topics
and
we
have
three
topics
for
today:
matt
groot.
Sorry,
if
I'm
not
pronouncing
your
name
correctly
matt,
but
you
have
a
topic
you
wanted
to
present.
You
want
to
take
it
from
from
here.
C
Yeah,
this
is
the
first
time
I've
contributed
anything
or
attempted
to
contribute
anything
to
the
argo
project,
but
we've
been
working
on
a
pr
to
implement
like
a
a
progressive
rollout
feature
for
the
application
set
controller,
and
this
is
basically
to
address
like
being
able
to
control
how
applications
are
updated
in
order.
C
Cool
yeah,
I
was
hoping
to
get
like
some
kind
of
feedback.
I
guess
like
while
we
were
working
on
this,
but
we're
now
mostly
done
with
it
and
have
yet
to
receive
any
feedback
on
it.
So
I
guess
I'm
asking
like
what
are
the
appropriate
next
steps.
A
Yeah,
I
look
at
your
proposal
this
morning.
Is
this
the
one
right.
B
D
A
B
A
C
Yeah,
so
I
guess
it's
easiest
to
talk
about
the
example
spec
that's
further
down
but
yeah.
C
Basically,
the
goal
is
for
us
to
be
able
to
have
some
kind
of
declarative
syntax
for
structuring
what
applications
are
going
to
roll
out
in
what
order
effectively
like
just
like
a
it's
like
some
kind
of
loose
dependency
tree,
and
so
what
we're
proposing
is
using
label
selectors
on
the
applications
themselves
and
using
these
match
expressions
listed
in
a
in
a
list
of
steps
to
list
or
to
select
a
certain
number
of
applications
for
the
first
step,
a
certain
number
of
applications
for
the
second
step
and
so
on,
and
this
would
effectively
block
anything.
C
That's
in
the
first
step
needs
to
complete
or
like
its
application,
needs
to
sync
and
be
healthy
before
the
second
steps.
Applications
would
begin
progressing
or
it
would
yeah
the
application
controller
effectively.
Just
blocks
updates
to
the
applications
that
are
in
that
second
bucket,
for
example,
until
the
first
is
complete.
C
So
it
also
has
a
support
for
like
an
extra
max
update
parameter
that
can
be
provided
to
limit
the
number
of
applications
in
the
current
step
group
that
can
update
simultaneously.
A
Let's
see
okay,
I
was
discussing
with
michael
a
little
bit
about
this,
and
he
also
mentioned
about.
There
was
a
previous
idea
of
having
dag
implemented
as
part
of
application
set.
Isn't
it
this
sort
of
implementing
that
as
well.
D
So
it's
similar
to
you
know
how
a
deployment
needs
update
pods,
but
deployment
benefit
from
an
intermediate
object.
The
replica
set
to
to
basically
upgrade
the
thing.
I'm
wondering
the
lack
of
that
in
in
the
application
set
producing
applications.
Whether
have
you
thought
about
what
we
might
be
losing
out
on
from
from
some
intermediate
object,.
C
Yeah,
I
thought
about
that
a
bit
and
I
think
the
the
thing
that
I
considered
was
number
one.
The
spec
is
still
defined
on
the
deployment
resource
so
like
the
update
strategy
and
all
that
is
still
there
in
the
deployment
resource
effectively.
The
replica
controller
replica
set
controller
is
kind
of
an
implementation
detail
that
the
user
often
doesn't
interface
with,
and
so
I
would
say
that
like
there's
nothing
stopping
us
from
inserting
like
an
intermediate
controller
using
the
same
spec
later,
if
desired,
and
the
other
thing
I
forgot.
C
But
that
was
my
my
primer.
Oh.
The
other
thing
is
that
the
the
control
for
this
kind
of
a
rollout
is
also
simpler
than
that
of
a
deployment
or
pod
replica.
So,
for
example,
we
don't
have
like
health
checks
to
find
or
like
readiness,
probes
and
all
those
other
things
that
I
think
that
the
replication
set
controller
is
somewhat
responsible
for
so
and
that's
simply
because
we
can
rely
on
those
details
being
implemented
at
the
that's
still
at
the
deployment
layer
so
like
we
can
use
home
hooks.
C
We
can
use
readiness,
probes
and
all
those
things
that
are
encompassed
by
the
health
of
the
application
resource
itself.
So.
D
I
see
one
of
the
biggest
challenges
we
had
with
rolling
update,
I'm
sorry,
roll
outs
and
updating
was
interrupted
updates.
So
basically
you
you
change
the
spec
of
the
rollout,
or
in
this
case
the
application
set.
E
D
Before
it
starts
the
update
and
then
in
what
it
hasn't
yet
completed
the
update,
and
then
you
like
change
the
spec
again.
A
D
You
have
kind
of
like
a
midway
where
half
of
the
things
are
updated.
You
need
to
reset
and
start
over
from
the
beginning
that
that's
actually
one
of
the
benefits
of
having
this
intermediate
object
of
the
replica,
because
you
actually
deploy
me,
creates
a
new
replica
set
here.
The
absence
of
that
intermediate
object
requires
a
lot
more
bookkeeping.
C
Yeah
today,
so
the
the
way
it
handles
that
case
today.
So
if
you
have
like
three
applications,
the
first
two
out
of
three
have
been
rolled
out
and
all
three
are
supposed
to
be
changed
and
you
push
another
change.
C
It's
going
to
start
over
start
rolling
changes
to
the
first
second
and
third
again,
assuming
all
three
are
dependent
on
each
other,
then
the
third
one
is
going
to
jump
straight
from
revision,
one
to
revision,
three
and
skipping
revision,
two
in
that
situation,
because
it
is
simply
trying
to
get
to
the
intended
end
state,
that's
defined
in
the
application
set
specification,
and
I
think
that
behavior
makes
sense
to
me,
but
I'm
definitely
open
to
hear
kind
of
alternative.
I.
C
It's
it's
tracking
the
generation
of
the
application
set,
and
then
it
is
tracking
the
observed
generation
of
the
application
resources
in
a
state
field
on
the
application.
Second
resource
itself.
D
C
C
So
we
scroll
down,
so
this
right
here
is
an
example
of
how
the
state
or
how
the
status
field
of
the
application
set
itself
changes
as
the
research
as
each
application
is
updated,
yeah
and
so
effectively.
We're
tracking
the
observed
generation,
and
that
is
that
observed
generation
actually
has
nothing
to
do
with
what
the
actual
application
resource
itself
looks
like
all.
That
state
is
tracked
on
the
application
set
controller
side,
because
I
didn't
want
to
like
balloon
this
into
making
a
bunch
of
changes
to
the
application
resource
itself.
D
Yeah
this
the
observed
generation
that
we
have
seen
recorded
here
is
that
metadata
generation
of
the
application.
It's
the.
C
C
It's
tracking
the
state
inside
the
status
field
of
the
application
set.
So
we
don't.
We
don't
care
about
the
application
resources
themselves,
we're
just
controlling
whether
or
not
we
update
the
we
care
about
them
in
terms
of
if
they're,
healthy
or
not,
okay
and
if
they've
been
updated.
So
we
have
to
watch
them
to
see
if
they've
gone
through
a
progressing
state
and
actually
applied
resources
to
know
if,
if
they've
become
healthy,
but
we
we
basically
set
them
to
say,
like
okay,
we're
they're
on
the
new
generation.
C
Now
we're
going
to
assume
that
they've
been
applied
and
then
we're
gonna
watch
to
see
if
they
start
progressing
and
then
assuming
they
do
now.
Everything's
good
and
up
to
date,.
F
F
It's
yeah,
it's
really
interesting,
so
the
and
there
there
would
be
right
now
in
the
pr
that
that
you
did
your
draft
in
there's,
not
any
modifications
to
the
cli,
but
presumably
we
would
add
a
feature
to
the
cli.
So
you
could
check
on
the
the
application.
C
It
wouldn't
be
sorry,
what's
the
thing,
what's
the
feature
that
you
would
want
in
cli.
F
C
D
Yeah,
so
for
me
it,
I
think
I
do
agree
with
the
use
case
rolling
out,
but
I
I
think,
having
experience
with
rollouts
the
that
it
kind
of
scares
me
the
amount
of
complexity
that
could
be
there
yeah
exactly
I'm
curious.
What
jonathan
is
jonathan
here,
what
he
might
think
of
in
the
future,
because
he,
you
know,
worked
mostly
with
the
upset.
C
I'm
also
happy
to
open
up
a
thread
on
like
the
computer
contributor
channel
and
we
can
just
like
deep
dive
into
this.
If
you
like,.
B
I'm
here
yeah,
I'm
a
bit
out
of
touch
when
it
comes
to
what's
up
to
date
and
the
new
hotness
in
what's
happening
in
with
application
set
controllers
so
yeah,
I
would
probably
defer
to
other
folks
but
yeah.
Mostly
it's
a
matter
of
whether
or
not
the
workflow
that
the
feature
prescribes
is
one
that
other
folks,
like
other
organizations.
Other
projects
would
find
beneficial
and
yeah.
F
I
definitely
know
that
I've
heard
from
several
organizations
who
want
to
do
stuff
like
this
and
right
now.
They
they
basically
combine
in
other
tools
to
achieve
this,
so
like
rancher
fleet
plus
argo
cd
to
kind
of
manage
the
configuration
of
many
instances
of
argo
cd,
but
being
able
to
do
with
an
application
set.
F
I
feel
like
would
give
you
a
lot
more
flexibility
and
make
it
easier
to
centrally
manage
and
and
make
each
individual
argo
cd
instance
more
powerful.
D
Okay,
I
was
just
seeing.
A
D
C
It
doesn't
it's
basically
item
potent
and
determines
whether
or
not
we
should
be
progressing.
The
current
step,
based
on
the
evaluation
of
the
previous
step.
D
C
E
C
Right,
you
can
definitely
run
into
that.
The
the
other
thing
to
note
is
that
this
is
it's
basically
polling
the
current
health
of
the
application
whenever
they
can,
the
app
set
reconceller
loop
runs.
That's
when
it
checks
the
health
of
the
applications,
so
you
may
or
may
not
hit
that
case
depending
on,
if
it
flaps
between
loops
or
not
so,
improvements
to
this
would
definitely
be
like
implementing
some
kind
of
watch
system
to
know
like
what
an
application
updated
and
also
potentially
adding
in
some
kind
of
guard
around
that.
D
Where
does
the
max
update
represent?
Is
it
like
a
kind
of
like
a
mini
max
surge,
but
within
the
step
exactly.
C
C
A
So
my
question
is:
is
this
proposal
also
dealing
with
exceptional
scenarios?
Some
things
things
like
timeouts
or
something
go
wrong,
goes
wrong
with
one
specific
step
and
how
to
deal
with
the
errors.
C
D
Can
I
see
the
improvements
you
made
to
the
status
that
facilitate
this
aside
from
the
the
generation
bookkeeping
like
what
about
the
aggregated
status
of
like
how
doesn't
one
understand,
like
the
aggregate
status
of
a
application
set.
C
So
when
you
talk
about
the
aggregate
status,
I
guess
what
do?
What
do
you
mean.
D
So
an
application.
C
C
C
Okay,
that's
not
tracked
at
all.
You'd
have
to
infer
that
by
looking
at
the
each
of
the
application
status.
C
D
Yeah,
because
I
imagine
now
that
we
have
a
state
essentially
we're
introducing
essentially
state
into
the
application
set
so
application
set
suddenly
is
either
in
the
middle
of
an
update,
so
it's
it
can
be.
I
guess
you
can
consider
it
progressing
yeah.
Typically,
you
will
need
to
introduce
conditions
to
represent
like.
C
D
D
So
so
in
general,
I
I
think
I
like
the
idea
I
I'm
again.
My
main
concern
is
the
what
we're
scoping
in
we
didn't
previously,
and
I
agree
with
the
use
case,
so
my
my
feeling
is
it's.
I
think
it's
a
good
direction.
D
We
just
should
tread
carefully
with
the
and
maybe
flag
this
behind.
You
know
some
future
flag
until
it
I
mean
not
just
basically
indicate
the
beta
quality
or
something
until
like
it's
been
proven
out,
so
it
bakes
yeah,
yeah.
G
Yeah,
I
think,
shopkir
I
do
like
what
this
does
as
well.
I
just
read
through
the
proposal,
while
you
folks
are
talking,
I
think
you-
and
I
have
heard
about
this
use
case
a
few
times
yeah.
So
this
definitely
is
something
that's
solving
a
problem
about
being
able
to
specify
the
order
in
which
we
roll
things
out.
This
does
look
good.
The
only
thing
in
my
mind
is
that
it
took
me
about
five
minutes
to
confirm
this
has
nothing
to
do
with
argo
cd
rollout,
but
does
it.
C
That's
correct
the
only
thing
that
it
would
the
only
way
it
intersects
with
rollouts
is,
if
you,
if
you're,
using
a
rollout
as
part
of
the
applications
that
are
managed
by
this
application
set,
the
rollout
itself
is
going
to
cause
the
application
to
be
in
a
progressive
state
until
the
pullout's,
complete
right,
right
and
so
effectively.
The
application
controller
rollout
here
would
wait
on
that
application
until
it
proceeds
to
the
next.
C
G
D
Yeah,
but
I
think
when
we,
if
we
start
down
this
thing,
it's
gonna
get
more
requests
like
like
dan
mentioned
the
pause,
I
think
that's
absolutely
going
to
be
in
the
next
request
that,
like
oh
I'd,
like
environment,
a
b
c
to
go
automatically
but
then
like
and.
B
D
Someone
says
like
oh,
but
produce
needs
like
a
little
extra
approval,
stuff
yeah.
So.
C
D
D
C
Like
this
allows
you
to
leverage
all
the
features
of
rollouts
also,
so
if
you
wanted
to
have
like
the
pause
step
and
a
prod
roll
it,
then
that
would
be
possible.
However,
for
things
that
you
can't
use
an
argo
rollout
for
so
for
running,
like
diamond
sets.
Using
this
thing,
yeah.
D
F
D
Happen
with
a
feature
like
this
inside
the
app
spec
applications
that
spec
so,
for
example,
analysis
templates
could
be
a
step,
in
fact
with
rollouts.
We
have
steps
right
and
then
one
of
the
steps
can
be
like.
Okay,
before
I
increase
traffic
weight
run
this
analysis
template
and
make
sure
it
passes.
So
so
I
imagine
someone's
like
oh
can
we
run
the
announce,
kickoff
analysis
as
part
of
update,
so
it's
my
step
number
three
would
be
run
a
job
or
run
a
template,
and
then
that
must
pass
before
I
go
to
the
next
one.
D
So,
like
those
are
all
things
like,
I
wish
we
can
do
with
applications
today,
like
I
I
do.
There's
people
want
to.
C
I
think
you
can
with
this
exactly
as
it
is
the
way
that
we're
planning
to
do.
It
is
basically
so,
for
example,
like
the
use
case
or
one
of
the
use
cases
we're
talking
about,
is
rolling
out
cluster
updates
using
cluster
api
yeah,
and
so
we
have
like
an
application
set
that
manages
a
bunch
of
clusters
and
we
want
to
be
able
to
push
like
a
kubernetes
upgrade
and
then
also
verify
that
pods
are
still
able
to
start
up
correctly
in
that
cluster.
After
the
upgrade.
C
What
we're
planning
to
do
is
in
the
helm,
chart
that
we
have
that's
that's
putting
all
the
cappy
resources
together,
we're
planning
to
add
a
helm
hook
to
it.
That
will
basically
like
verify
it'll
do
like
that
small
smoke
test,
okay,
verifying
that
a
pod
will
come
up
successfully
in
the
given
cluster.
So
that's!
I
think
one.
D
Way
to
solve
like
an
application
as
a
proxy
for
performing,
I
guess
smoke
tests
or-
and
you
can.
B
D
D
C
No
we're
what
I'm
basically
saying
is
that
so,
if
we're
looking
at
like
one
of
these
match,
expressions
here,
like
unlike
the
dev
environment,
that
application
that
is
tied
with
that,
that
has
that
dev
label
on
it
has
a
an
associated
helm,
chart
that's
being
applied
by
the
application
resource
and
that
helm
chart
provides
the
ability
to
use
like
home
hooks
that
our
city
already
supports.
For
example,
so
you
can
do
like
a
pre-upgrade
hook
or
post
upgrade
hook,
and
you
can
have
whatever
logic
you
want
inside
those
hooks.
E
C
D
Okay,
I
I
think
it
might
be
worth
calling
out
the
the
other
scope
stuff
like
this
will
basically
only
ever
deal
with
applications.
Correct
yeah,.
D
Okay,
but
in
general
I
think
I
feel
good
and
a
lot
better
about
this.
A
All
right
thanks,
everybody,
okay,
so
we'll
be
forward
with
the
next
topic.
For
today's
agenda
we
have
samaya.
Are
you
in
the
call?
Yes,
I
see
you
there.
B
Hi,
so
this
is
a
front-end
topic
and
it's
something
that
I
we've
not
been
having
sick
meetings.
I
just
put
it
here.
I
was
just
looking
for
a
few
reviews
and
you
know
if
it
could
possibly
be
able
to
watch
this
one.
It's
for
adding
dark
mode
to
our
existing
ui.
A
A
If
not,
let's
move
forward
with
the
last
topic
of
the
day,
zach
want
to
talk
about
smp
support
for
all
argo
projects.
Zach
want
to
take
it
from
here.
E
Yeah,
so
I
guess
I
just
kind
of
wanted
to
I
kind
of
posted
a
thread
and
the
contributors
general
about
this
as
well,
and
the
idea
is
that
for
argo,
rollouts
I've
been
working
on
getting
having
the
rollout
spec
be
able
to
be
patched
by
customized
like
via
strategic,
merge
patches,
which
mainly
affects
the
lists
and
talking
to
just
the
other
community.
It
kind
of
sounds
like
it's
going
to
make
sense
to
do
this
for
all
argo
projects
as
a
whole.
E
And
so
I've
I
have
a
like
a
poc
people
there
under
my
own
github
org
there
that
basically
would
become
a
tool
that
generates
a
schema
file
that
we
can
use
to
configure
customized
to
know
about
the
all
the
argo
project
types
so
that
customize
can
then
properly
merge
arrays
and
things
like
that.
So
that's
kind
of
the
overall
idea.
E
I
did
open
up
a
pr
again,
so
argo
cd
is
the
only
project
that
doesn't
have
merge
keys
defined
within
their
within
the
crds
or
their
goaling
types,
and
so
that's
what
the
pr
is
for
against
argo
cd,
but
I
just
kind
of
wanted
to
you
know,
get
this
a
little
bit
more
out
in
the
open,
see
if
anybody
had
any
tops,
etcetera.
E
Yeah
correctly
correct,
so
there's
a
really
bad
ui
behavior
within
rollouts
that
roll
or
not
within
customize,
that
customize
it
lets.
You
define
an
open
api
schema
for
your
types,
but
it's
only
a
replacement.
So,
basically
you
can't
do
additions,
and
by
default
they
bundle
a
native
like
all
the
native
kubernetes
types
within
customize
when
you
just
use
it,
so
it
works
for
all
native
kubernetes
objects
right.
E
E
So
yep
so
that
that's
the
one
that
has
all
of
them
and
then
I
generated
ones
for
each
individual
project
as
well.
Customized
has
been
talking
about
making
the
open
api
field
in
addition
where
they
will
then
do
the
merging
and
there's
also
talks
in
kubernetes
upstream
to
allow
metadata
on
crds
for
merge.
Key
types,
merge
key
information.
E
Obviously
that's
going
to
move
really
slow,
so
this
is
just
kind
of
a
work
around
for
the
time
being.
E
Of
yeah
it's
been
sitting
around
for
a
long
time,
so
I
don't
know
how
serious
or
when
that's
gonna
happen.
But
there's
discussions
going
on
around
that.
I
see
something
at
the
beginning
of
this
year.
There
was
some
comments
about
someone
working
on
something
so
yeah.
So
it's
you
know.
Timelines
on
that
are
probably
unreliable.
E
D
Yeah,
can
you
remind
me
again
the
limitations
of
the
the
crd
field
in
the
customization
that
yama
versus
the
opening
play?
I
feel
the.
E
Hey
elf,
just
oh
yeah,
so
yeah,
so
the
crd
field.
Customize
also
has
a
crd
config
section
that
you
can
use
to
provide.
What's
it
called
transformations.
E
Basically,
so
you
can
provide
a
c
or
d
there
and
then
not
have
to
provide
within
your
crd.
You
can
provide
some
extra
metadata
common
things
tags
again
that
will
allow
it
to
generate
basically
transformation,
so
it
knows
how
to
find
like
images
and
things
like
that
for
those
replacements
rollouts
today
does
that
through
another
config
option
that
customize
had
before
that
that's,
but
that's
kind
of
the
difference
between
the
two
of
them.
E
There's
talks
about
changing
those
and
merging
in
the
same
issue
thread
under
customize,
where
they
were
talking
about
the
open
api
field,
making.
It
addition
there's
going
to
be
some
changes
around
crd
stuff
as
well,
because
it's
confusing
and
overlapping.
D
Okay,
so
the
crd
section
and
the
customization
only
helps
with
the
things
like
name
referencing,
yep
name
yep,
exactly
but
not.
B
A
Yep,
okay
cool,
so
this
is
a
proposal
to
have
this
as
a
workaround.
If
I'm
not
yeah,.
E
Yep,
so
the
idea
would
be
that,
like
this,
this
project
would
live
in.
So
we
would
basically
move
this
repo
into
like
an
argo,
proj,
repo
right
and
then
all
of
the
projects
would
be
able
to
have
documentation
around
how
to
use
customize
with
their
project
and
then
link
to
the
generated
files
in
this
new
repo
that
doesn't
exist.
Yet.
G
I'm
sorry
I'm
a
little
confused.
What
what
would
be
the
use
case
for
this
and
then
which
place
would
this
get
plugged
in
so.
E
This
will
work
across
all
argo
argo
projects,
so
basically,
argo,
cd,
argo
events,
argo
workflows,
argo
rollouts
and
it's
mainly
a
documentation,
less
user
benefit,
so
any
users
that
are
using
customize
today
we're
going
to
have
problems
using
customizes,
catch,
strategic,
merge
or-
and
this
allows
them
to
use
strategic,
merge,
patching
with
argo
project
types
and
native
kubernetes
types.
E
Yeah,
there's
a
there's
actually
a
documentation
page
on
the
rollout
stocks
that
talks
about
how
rollout
supports
customize,
but
it's
it's
actually
kind
of
incorrect
because
it
supports
it,
but
it
only
supports
it.
If
you
don't
need
to
merge
any
other
type
within
your
customized
application,
which
is
unrealistic.
I
think.
E
Yep
exactly
they
wouldn't
have
to
do.
Customize
the
ports,
like
jason,
16
6.
I
don't
even
know
what
it
is
to
904
patching
or
something
like
that
which
is
real
fragile,
because
you
have
to
basically
give
like
array
indexes
and
things
like
that,
and
this
allows
those
users
to
be
able
to
use
the
patch
strategic
merges
within
customize
got.
A
Yeah,
I
think,
without
this
everything
that
is
a
list
inside
any
of
resource
provided
by
argo,
will
be
replaced
and
replaced
yep
and
by
defining
the
schema,
then
customize
is
able
to
identify
specific
items
and
identify
things
that
are
added
to
the
to
the
state
and
behave
accordingly.
Instead
of
just
replacing
the
entire
array,
yep.
B
E
Yeah,
so
so
how
it
how
it
works.
All
the
projects
would
share
this
these.
These
would
share
these
that
the
output
of
this
it's
tied.
So
it's
a
little
interesting.
So
it's
tied
to
api
versions
of
each
project
which
shouldn't
have
breaking
changes
right.
It
would
be
interesting
to
try
to
automate
the
running
of
this
on
changes
to
all
the
projects
types.
I
don't
know
if
that's
necessary
at
right
away,
because
I
think
types
generally
change
relatively
slow,
but
that
is
probably
something
that
should
be
thought
about.
E
E
And
it's
only
in
regards
to
arrays
within
those
crds
as
well,
so
adding
a
new
non-arrayed
isn't
gonna
provide
any
benefit
to
meeting
a
new
schema
file.
So
you
know
I
guess
I
don't
see
that
as
a
blocker
for
like
getting
this
out
and
communicated
within
documentation,
but
if
you
know
customize
never
gets
their
stuff
together
with
additions.
You
know,
and
this
gets
annoying
to
have
to
update
over
and
over
again
I
do
think
it
probably
makes
sense
to
somehow
trigger
a
run
of
this
upon.
G
F
G
I
mean,
I
don't
know
every
pr,
sorry
right
right
so
I
mean
I
think,
as
a
next
step.
This
looks
like,
like
we've,
we've
had
a
decent
amount
of
conversation
on
this
now
and
I
think
that
has
raised
some
great
points
should
probably
have
a
tiny
enhancement
proposal,
because
this
does
go
across
projects
to
be
able
to
yeah
what
this
does
and
the
title.
When
I
came
up
with
you
in
case
you
wanted
or
customizable,
but
then
in
short,
it'll,
be
nice
to
explain.
E
I
think
that's
fair.
I
do
plan
on.
I
I
missed
the
meeting
for
the
workflows
and
events
contributors
meeting,
but
next
week
I
do
plan
on
just
kind
of
bringing
this
up
over
in
that
meeting
as
well
just
to
give
them
an
idea
of
it.
I
don't
really
know
about
any
of
it
yet,
but
yeah,
I
think,
having
a
little,
I
don't
know
where
that
proposal
would
live,
maybe
under
argo
put
to
an
issue
or
something.
G
G
A
G
A
Okay,
thanks
thanks
everybody
we're
two
minutes
over
hey.
Does
anybody
have
any
other
last
minute
topic
you
wanted
to
bring
up?
If
not
I'm
gonna
conclude
this
for
today.
Thank
you,
everybody
for
joining
and
see
you
next
week,
bye.