►
From YouTube: Argo Contributors Office Hours Jan 5th 2023
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
Okay,
starting
with
three
agent
discussion
for
last
week
of
2022,
we
had
William
and
Remington
I,
saw
William
online,
anything
to
add
during
holidays
William
any
highlights
no,
unfortunately,
I
haven't
really
been
able
to
do
much
with
it.
A
Okay,
no
problem
and
Remington.
Isn't
here
so
I
guess
we're
gonna
be
moving
so
next
section
where
we
need
to
elect
the
next
personal
Duty
for
next
week's
triage.
Any
volunteers
I
can
take
primary
I'll.
A
Cool
yeah,
just
I'm,
just
questioning
myself,
if
you're
not
gonna,
be
here
how
we're
gonna
be
receiving
your
feedback
from.
A
B
A
We
have
done
as
primary
thanks
Dan
any
volunteers
for
secondary.
C
A
All
right
thanks,
everybody
right.
So,
let's
move
forward
and
we
have
two
topics
in
the
agenda.
First,
one
from
Michael
is
a
proposal.
Yes,
it's
a
it's
an
issue.
Maybe
Michael
wants
to
highlight
this.
I
saw
Michael
in
the
call
Michael.
We
wanna
say
a
few
words
about
this.
B
Yeah
so
I
don't
remember
many
of
the
details
of
the
issue,
but
basically
there's
a
Prometheus
related
resource
and
I
guess.
It
may
just
be
called
Prometheus
that
the
health
check
is.
It
doesn't
support
two
different
versions
of
the
Prometheus
resource
and
there's
no
way
for
the
health
check
to
differentiate
between
those
two
resources.
B
So
if
you're
using
one
cluster
that
has
one
version
of
the
Prometheus
resource
and
then
another
cluster
that
uses
a
different
version,
one
of
those
health
checks
is
just
gonna
be
wrong,
and
one
of
the
proposed
Solutions
was,
to
just
like
add
an
annotation
to
the
resource
to
ask
Argo
CD,
don't
even
bother
doing
a
health
check
on
this
resource
and
that
might
already
exist.
They
kind
of
hacked
it
in,
but
it
seemed
like
a
reasonable
proposal.
B
A
Okay,
yeah
I
read
this
this
comment
from
this
person
and
sounds
reasonable
to
me
as
well,
so,
basically
from
the
Lua
script,
we
have
access
to
the
entire
object,
so
we
can
check
the
version
in
the
health
check
itself,
not
necessarily
having
to
add
additional
logic
in
the
in
the
Argo
CD
side.
Mainly
the
health
check
Lewis
could
be
self-contained
to
validate
this
condition
as
well,
so
also
something
we
could
investigate.
A
Yeah
I
agree,
it's
I,
think
you're
worth
taking
a
look
at
this
different
versions
of
Prometheus
will
provide
the
status
in
different
in
different
formats
and
it
may
it
might
become
a
reality,
as
other
crds
improve
their
versions
as
well
all
right.
So
how
do
you
suggest
to
move
forward
with
this?
So
they?
Basically
you
wanted
to
highlight
this.
For
these
group
Michael.
B
Yeah
I
guess
we
have
a
couple
different
options
either
we
can
say
you
know
our
recommended
approach
is
to
do
basically
what
these
folks
did
and
just
write
a
custom
health
check
to
look
at
that
annotation
or
we
could
add
something
built
into
Argo
CD
that
just
lets
all
resources.
Customer
not
ignore
the
health
check.
If
you
want.
B
A
Right,
okay,
all
right!
So,
let's
discuss
aimed
a
ticket.
So
we
have
a
history
and
all
right
anything
else
from
this.
Anyone
Michael
nope
anyone
else:
okay,
cool!
Thank
you,
Michael,
all
right!
So
moving
forward.
We
have
one
more
Topic
in
the
agenda,
which
is
for
the
follow-up
proposal
for
image.
Updater
merge
in
Arlo,
City
I
saw
your
action
during
the
holidays.
You
wanna
mention
about
it.
You
want
to
say
a
few
words
about
the
the
new
proposal:
hey.
D
This
here
to
as
a
reminder
for
community,
if
anyone
hasn't
seen
this,
that
I
created
this
follow-up
proposal
based
on
build
your
discussions
about
the
image
updater
so
just
have
some
context.
D
I
had
earlier
brought
up
a
proposal
for
how
we
could
go
about
merging
image
of
data
into
Colorado
city
and
then
Tingler
Community
as
a
whole
felt
that
we
may
need
a
more
longer
term
vision
for
on
why
it
would
be
a
good
idea
to
do
that
so
we'd.
And
then
we
discussed
some
long-term
visions
that
we
had
about
how
we
can
make
image
updater
a
more
first
class
citizen.
So
that
would
involve
some
changes
to
the
application.
D
Crd
that
we
had
in
mind
mostly
adding
some
new
fields,
for
example,
is
something
we
discussed
so
that
could
replace
the
existing
mechanism
that
we
have,
which
is
that
it
uses
annotations
to
express
some
pretty
complicated
configuration
for
using
image
of
data.
So
one
of
the
things
that
we
thought
about
was
how
we
could
leverage
application
crd
for
that,
among
other
things,
which
are
all
kind
of
detailed
in
The
Proposal.
D
So
this
is
this
proposal
is
a
result
of
those
discussions
to
kind
of
dive
deeper
into
what
the
long-term
vision
for
it
is
and
how
it
fits
into
all
the
CD
in
a
way
that
would
be
beneficial
for
all
of
its
users
and
like
help
close
some
gaps
in
between
the
CI
and
CD
that
currently
exist
that
are
solved
by
the
image
of
data.
So
this
proposal
basically
has
like
an
example.
That's
highlighted
here
for
what
the
new
Fields
could
look
like
and
how
they
could
fit
into
the
application.
D
Crd,
along
with
some
other
comments
about
what
would
be
needed
to
support
that,
for
example,
the
changes,
the
changes
in
the
controllers
to
watch
the
CID
like,
for
example,
the
there'll,
be
fields
which
will
be
used
just
by
with
by
image
updater
and
not
by
application
controller,
for
example.
So
that's
nuances
and
things
that
have
been
identified
that
are
laid
out
there.
D
D
Don't
know
how
much
detail
to
go
into
here,
because
it
might
take
a
lot
of
time,
but
I
would
encourage
people
to
who
are
interested
to
take
a
look
at
this,
and
so
we
can
spend
some
more
time
analyzing
things
about
this
and
that
those
can
be
addressed
so
yeah.
D
The
main
point
of
adding
that
to
the
agenda
was
just
to
call
some
attention
to
this
proposal,
since
it
was
raised
to
before
the
holidays,
but
that's
generally,
the
context
of
it
and
I
will
say
that
it
would
be
great
if
we
could
try
to
get
it
into
two
seven,
if
possible,
so
that's
kind
of
what
I'm
trying
to
shoot
for
so
any
kind
of
feedback
would
be
much
appreciated
for
this.
A
Okay,
so
from
your
proposal,
I'm
understanding
that
what
you're
suggesting
adding
this
new
image
attribute
index
pack
in
the
application
spec
and
that's
where
you're
concentrating
basically
the
whole
configuration
for
how
the
image
updater
would
work
together
with
our
little
CD
controller.
Is
that
correct,
yeah.
D
Since,
since
image
of
data
in
its
nature
is
more
decoupled,
I
think
it
makes
sense
to
have
like
store
the
configuration
in
a
separate
image.
Spec
there
isn't
too
much
that
I
identified
in
what
the
image
of
data
currently
does.
That
would
need
settings
to
be
kind
of
merged
or
interspersed
with
existing
spec
Fields.
Essentially,
what
I've
done
here
is
seen
the
existing
annotations
that
image
updater
looks
out
for
and
converted
those
into
their
own
kind
of
feature
fields,
and
it
seemed
to
fall
conveniently
into
like
its
own
image
block.
A
Okay
in
the
whole
section
that
you're
as
amplifying
here
is
part
of
the
image
attribute,
is
that
correct
that
I
can
I
can
double
check.
The
indentation
here
in
this
I
just
want
to
make
sure
that
this
is
also
part
of
the
same
the
same.
D
Structure,
yeah,
it's
it's
all
under
image
and
under
that
updates,
so
I
think
one
of
the
conversation
ads
that
Jan
was
that
image
updates
can
be
one
thing,
but
to
be
more
future
facing
there
can
be
image,
dot,
verification
or
something
else
in
the
future.
So
so
it's
all
under
image.
Door
updates,
right
now
and
separately
in
the
status
as
well.
A
Okay,
I
guess
my
next
question
is
you
I,
I,
guess
I
understood
you
mentioning
something
like
image:
updater
controller
working
together
with
our
application
controller,
but
I
think
what
we
discussed
is
making
this
a
first
class
citizen,
meaning
it
would
be
taken
care
of
by
the
application
controller.
Only
so
I
I
just
want
to
make
sure
what
is
your
take
on
in
this
proposal?
Are
you
still
suggesting
us
to
have
two
controllers
or
the
proposals
mentions
about
bringing
that
logic
inside
application
controller
itself.
D
The
proposal
discusses
that
as
an
alternative
I
think
we
spoke
about
potentially
bringing
that
logic
directly
into
application
controller,
but
I
think
Jan
and
I
felt
it
may
be
better
to
have
it
as
a
separate
controller,
but
the
code
Can
it
can
still
be
within
Augustine,
just
not
like
as
tightly
merged
into
application
control
itself.
D
That's
that's!
That
is
detailed
in
the
proposal
thing
but
like
personally,
I'm
leaning
towards
not
including
it
directly
into
application
controller,
but
having
it
in
a
separate
controller
within
our
CV.
So
then
that
controller
would
be
watching
for
the
changes
in
the
spec
dot
image.
Part
of
the
application.
Basically.
A
Okay
and
the
main
reason
why
not
having
that
logic
in
the
application
controller
is
also
explained
here,
because
I
would
be
interested
in
understanding
the
the
reasonings.
D
Yes,
I
think
I'm,
just
I'm,
just
looking
it
up
as
an
alternative,
yeah
I
think
the
main
reason
was
just
because
the
core
concern
of
the
image
updater
is
to
kind
of
act
upon
these
specific
Fields
right.
Select,
the
separation
of
separation
of
logic
seem
to
make
more
sense
because
the
application
controller
itself,
even
though
it
acts
entirely
on
the
application.
The
specific
aspect
of
updating
images
is
what
the
image
updater
is
entirely
focused
on,
so
it
seemed
like
it
seemed
more.
D
A
A
So
I
was
mainly
interested
in
interested
in
understanding
the
how
this
proposal
changed
that
right.
So
the
if
we're
keeping
the
existing
components
that
the
way
it
is
and
just
adding
this
additional
logic
to
existing
existing
controller.
A
To
me,
it
sounds
more
appropriate,
but
I
mean
we
need
to
better
understand
what
up
I
didn't
read
the
the
entire
proposal.
Yet
I
I
have
something
that
I
have
that
in
my
my
to-do
list,
but
yeah
something
I
wanted
to
to
investigate.
C
Yeah
and
maybe
maybe
if
I
can
add
to
that
I
I
think
like
JD
already
mentioned,
the
the
separation
of
concerns
plays
a
big
role
here,
like
the
application
controller.
Usually
it
reconciles
an
application
with
the
cluster
right
yeah
and
the
image
updater
you
basically
well,
it's
it's
not
really
a
reconciler,
but
if
you,
if
you
would
like
to
say
so
it
it
reconciles
and
image
registry
with
with
an
application,
so
yeah
I
mean
it
I.
Think
integrating
it
into
into
the
application
controller
would
be
quite
a
couple
of.
C
Of
challenges
also,
as
regarding
to
scaling
and
reliability,
maybe
I
I,
don't
know
it's
yeah,
but
yeah.
It's
a
good
point
that
maybe
we
should.
We
should
look
into
the
proposal
and
and
provide
a
good
reasoning
for
that,
so
that
that
we
can
continue
discussing
on
that
sauce,
yeah
yeah
thanks.
A
Cool
thanks,
Ian
all
right,
I
I,
think
to
start
with
this
new
version
of
The
Proposal,
that's
those
are
the
questions.
I
had
I,
don't
know
if
anybody
else
has
something
to
to
mention
comment
on.
B
No
questions
yet
just
that
I've
got
an
item
on
the
next
Sprint
to
look
at
this
and
leave
comments.
So
it's
in
the
pipeline.
A
A
All
right,
okay,
thanks
thanks
JD
for
working
on
this
I,
also
want
to
take
a
look
deeper,
look
in
the
proposal,
and
if
you
can
provide
the
reasoning
we
can
we
can.
We
can
continue
discussing
in
the
in
the
proposal
itself.
D
Yeah
sure
I
can,
for
we
can
follow
up
in
the
comments.
Maybe
I'll
try
to
add
any
additional
thoughts
if
I
have
them
in
the
comments
and
tag
you.
A
A
Or
can
I
easily
see
this?
Just
we
have
a
new
board
where
you
can
check
the
dates.
Let
me
see
if
I
can,
if
someone
has
it
easily,
they
send
a
link
in
the
chat,
otherwise
I'll
try
to
see
if
I
can
find
it
here.
A
Chat
thanks
Michael.
Let
me
see
that
right
so
yeah.
Now
we
have
this
board
Argo
City
roadmap.
I
think
everybody
has
access
to
this,
and
this
is
the
plan
right
so
we're.
A
The
idea
is
to
keep
here
the
the
target
target
dates
that
we
have
for
those
for
the
for
the
releases
and
the
features
that
are
associated
with
them.
B
The
that
proposal
is
still
in
PR
form.
We
should
probably
get
that
merged.
So
let
me
check
what
the
RC
data
is
for.
2
7.
I've
got
that
marked
as
Monday
March
20th
for
2.7
rc1.