►
From YouTube: Argo Contributor Experience Office Hour 27th May 2021
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).
B
No,
it's
not
just
you.
Okay,.
D
Yes,
good
morning,
so
my
topic
for
today
is
a
proposal
that
we're
calling
ui
extensions.
Can
you
guys
see
my
screen?
Yes,
great,
all
right
and
jesse?
Just
let
me
know
if
you
want
to
jump
in
or
at
anything
at
any
point.
D
So
yeah
we've
been
thinking
about
this
for
a
while
we'd
like
to
offer
a
mechanism
to
essentially
extend
the
argo
cd
ui
such
that
it
can
provide
a
few
extra
things,
so
a
couple
of
which
it
already
offers,
but
in
a
way
that
we
want
to
improve
so
argo
cd,
as
some
of
you
might
know,
offers
custom
actions
on
custom
resources
and
that's
configured
in
argo
cd,
config
map
with
lua
scripts
at
the
moment,
but
we'd
like
to
improve
that
experience
and
then
additionally,
we'd
like
to
offer
the
ability
to
expose
richer,
more
concept,
context,
sensitive
ui
that
can
be
displayed
for
custom
resources
as
well
so
yeah.
D
If
anybody
would
like
to
take
a
look
at
the
proposal,
it's
available
as
a
pr
on
github
in
the
main
argo
cd
repo,
let's
see
yeah,
so
basically
the
motivation
behind
this
was
we
wanted
to
integrate
our
go
rollouts
into
the
argo
cd
ui
and
we
didn't
want
tight
coupling
between
argo,
cd
and
argo
rollouts,
mainly
because
you,
you
may
manage
or
argo
cd
may
manage
a
variety
of
clusters
running
different
versions
of
argo,
rollouts
and
so
to
solve
this
problem,
we
decided
that
we
would
essentially
make
argo
rolla's
the
first
example
of
these
extensions,
so
the
goals
are,
as
I
said,
to
enable
new
visualizations
in
the
ui
for
resources
that
are
not
baked
in,
and
we
also
want
to
make
sure
that
these
are
configured
by
operators.
D
But
it's
done
at
run
time,
so
we
don't
want
to
have
to
recompile
ui
code
and
they
should
be
easy
to
develop
and
they
should
be
easier
to
install.
Like
I
said,
loose,
coupling
is
a
big
thing
and
then
again
we
want
to
replace
the
current
resource
customizations.
That
includes
health
checks
as
well,
not
just
actions
all
right,
so
yeah.
Our
proposal
is
kind
of
two-tiered,
so
first
would
be
a
new
crd
called
the
argo
cd
extension,
and
it
would
be
pretty
simple
as
a
first
step.
D
What
we
would
like
to
do
is
offer
the
ability
to
specify
a
repository
where
your
extension
will
live
and
then
a
revision
optionally
and
that
repo
would
be
structured
as
follows.
So
you
would
have
your
actions
in
here,
so
this
would
replace,
like
I
said,
the
config
map,
but
then
the
the
new
piece
that
was
not
done
in
any
capacity
before
would
be
this
ui
portion,
and
so
the
thinking
here
is
that
you
would,
you
know,
build
your
extension.
D
You
would
have
webpack
or
whatever
bundler
you
use,
compile
all
your
extension
code,
and
you
would
put
it
in
this
in
this
repo
here
and
that
could
be
done.
We're
thinking
by
ci
and
and
maybe
a
similar
way
to
github
pages.
Does
it
where
you
might
have
your
ci,
build
your
github
pages
and
put
in
a
different
branch?
You
could
reference
a
different
revision.
D
We
haven't
flushed
this
out
yet,
but
potentially
a
best
practice
that
could
be
specified
down
the
road
and
then
additionally,
there
might
be,
like
I
said,
multiple
versions
in
different
clusters.
That
argo
c
is
managing
that
have
different
extension
requirements,
so
this
would
be
specified
with
a
subdirectory
and
then
in
the
actual
ui
itself.
How
this
would
look?
I
think
I
have
a
screenshot
in
here
yeah,
so
this
would
essentially
be
another
tab,
so
you'd
click
on
a
rollout.
D
I
realize
it
says
replicas
that
this
was
a
bit
of
a
hacks
together,
mock-up,
so
you'd
click
on
a
rollout
and
there
would
be
an
additional
tab
here.
That
would
say
more
or
maybe
roll
out
something
like
that
or
extension,
and
it
would
surface
this
information
that
was
not
there
before
in
a
more
useful
way.
D
So
for
rollouts.
This
is
essentially
a
paired
down
version
of
the
dashboard
that's
currently
available,
but
this
is
running.
So
this
was
a
poc
and
this
was
to
kind
of
prove
that
this
is
possible
and
we
found
that
it
is.
Let's
see
okay.
So
as
far
as
implementation
goes,
we
are
going
to
have
each
extension
on
the
ui
side,
be
a
react
component.
D
D
It
needs
the
full
resource,
object
of
course,
and
then
it
also
needs
the
entire
application
resource
tree,
and
the
reason
for
this
is
one
we
get
live
updates
for
free
because
the
resource
tree
is
already
live,
updated
and
then,
additionally,
extensions
like
argo
rollouts
have
hierarchical
structure
that
we
don't
want
to
have
to
add
any
additional
logic.
We
don't
want
to
have
to
bundle
the
rollouts
api
server.
We
already
have
that
data
there
in
the
resource
tree,
and
so
we
can
leverage
this
as
it
already
is
to
provide
that
rich
data
see.
D
This
is
just
some
implementation
details
regarding
the
ui.
I
won't
go
into
that
and,
as
far
as
installation
goes,
it'll
just
be
a
single
cube.
Ttl
apply
that
will
install
it
or
install
the
custom
resource,
and
then
it
will
patch
the
argo
cd
api
server
with
the
sidecar,
and
then
the
sidecar
will
be
responsible
for
cloning,
the
repos
that
are
specified
in
that
cr
and
then
mounting
them
in
the
a
well-known
location
that
will
be
read
by
the
api
server
and
serve
so
it'll.
D
And
then,
let's
see
a
couple
security
considerations.
Well
we're
we're
basically
taking
advantage
of
argo
cdr
back
to
perform
any
actions
just
like
we
do
now
and
we'll
have
to
be
careful
about.
You
know,
potentially
malicious
extensions,
but
one
way
to
mitigate
this
would
be
to
publish
a
list
of
sanctioned
extensions
or
approved
extensions
that
we
think
are
trustworthy
like
rollouts
or
workflows,
or
maybe
more
down
the
line.
D
And,
like
I
said
alternatives
that
we
considered
would
be
just
building
baked
in
support,
for
example,
for
a
roll
out,
but
I
already
addressed
the
downsides
of
that
and
then
we
also
considered
requiring
recompilation
in
a
similar
manner
to
config
management
plug-ins,
how
they're
done
now,
but
this
is
not
really
ideal
and
we're
already
moving
away
from
that
paradigm,
with
config
management
plug-in.
So
we're
not
going
to
go
down
that
path
so
because
we'll
have
to
rework
it
anyway.
D
So
I
think
that
is
the
broad
stroke
overview
of
what
extensions.
What
we
think
extensions
should
look
like.
Does
anybody
have
any
questions
comments.
E
D
No,
it's
the
same
ingress
it's
connecting
on
the
same
end
point
so
that
the
ui
is
all
served
at
the
same
location.
The
only
difference
is
that
at
runtime,
when
you
click
on
this
new
tab,
the
ui
the
same
ui
that's
currently
there
is
dynamically
loading
new
ui
assets
or
a
new
react
component
from
a
different
endpoint.
It's
just
like
when
you
load
when
you
click
on
a
rollout,
and
it
gives
you
the
the
manifest
right.
D
A
Perfect,
I
just
pasted
another
link
into
the
chat,
so
basically
I
realized
we
discussed
very
similar
design
before
we
didn't
talk
about
ui.
It
was
only
about
health
checks
and
many
actions,
but
I
feel
like
if
you
open
that
link
from
the
chat,
it
would
be
kind
of
almost
the
same
proposal
focused
about
focused
on
hub
checks,
so
yeah.
A
And
basically,
I
I
have
a
feeling
this
proposal
kind
of
includes
this
ticket
proposal
from
that
yeah
it
is
yeah,
so
it's
kind
of
covering
two
you
know
solve
two
issues:
one
you
can
have
now
reach
your
ui
for
crgs
and
then
we're
kind
of
introducing
strongly
typed
api
to
manage
health
checks
and
customers.
E
A
It
might
change
we
kind
of
have
a
discussion,
but
basically
we
were
thinking-
or
at
least
I
was
thinking
that
that
crg
can
on
the
fly
minute.
You
know
clone
the
repository
and
then
insert
lower
scripts
from
these
files
into
the
config
map.
So
we
basically
at
least
in
the
beginning.
So
we
would
not
have
to
change
anything
in
the
triggers
in
argo
cd,
but
people
can
start
using
that
crg
instead
of
configmap
and
that
clg
will
install
keys
into
configure.
F
So,
which
means
it's
got
it's
doing
some
processing
ongoing
processing
then
right.
A
F
C
You
didn't
need
hot
loading
of
extensions
like
if
you,
if
you
didn't
need
to
have
that
requirement
that,
like
oh
as
soon
as
I
apply
a
extension
cr
after
the
fact
that
the
api
server
running
you
could
accomplish
all
of
this
using
a
knit
container.
I
guess
it
depends
if
we
want
to
be
that
support
hot
loading
or
not.
A
E
D
We
hadn't
considered
using
container
images.
I
can
kind
of
give
some
background
on
how
we
came
to
that
conclusion.
We
were
initially
going
to
essentially
reverse
proxy
the
rollouts
api
server
or
an
api
server,
so
it
would
basically
the
argo
cd
api
server
would
be
reverse
proxy.
D
A
I
think
motivation,
basically
creating
this
kind
of
formal
way
to
extend
rbcd
only
makes
sense
if
we
get
more
extensions
more
than
just
one
and
we're
just
looking
for
some
way
to
make
it
that
simple,
you
know
like
as
simple
as
possible.
This
seems
to
be
this
most
kind
of
user
friendly
way.
You
know
just
a
git
repository
that
has
a
bunch
of
files
in
here.
C
Yeah,
I
think
if
we
were
to
do
an
image
the
you
have
to
get
the
files
off
of
the
image
like
the
the
extension.js,
the
luis
dot
script,
somehow
to
the
api
server.
C
C
I
think
git
repos
allow
you
to
not
run
so
many
side,
cars
or
servers
yeah
services
to
you
know,
I
think,
if,
if
we
had
it
in
containers,
you
have
to
run
every
container.
That
is
an
extension
rather
than
just
cloning,
a
bunch
of
git
repos.
A
I
think
it's
kind
of
if
we
realize
that
everyone
prefer
to
build
image
and
distribute
files
using
an
image.
At
least
there
is
a
room
in
spec
for
that
right,
instead
of
repository
yeah
yeah,
you
can
add,
let's
say
docker
image,
or
I
mean
so
basically,
some
some
configuration
knob.
That
explains
that
your
server
should
pull
that
image
and
get
files
from.
E
Yeah,
that
seems
like
a
reasonable
set
of
requirements.
Definitely
in
openshift,
for
example,
or
in
some
of
the
operators
we've
seen.
E
It
seems,
like
they've,
tended
to
favor
using
container
images
for
this,
rather
than
you
know,
links
to
a
particular
revision
on
a
particular
git
repository.
But
I
can
see
the
reasoning
that
you
have
for
this
way.
So
yeah
that
sounds
fine.
A
E
Yeah,
that's
part
of
the
development
workflow
this
this
is
this,
isn't
really
part
of
the
development
workflow
like
this.
This
would,
unless
I'm
misunderstanding,
this
would
be
just
like
extensions
to
the
argo
cd
ui
itself,
so
it
would
be
like
basically,
the
equivalent
to
shipping
a
binary
within
the
product,
all
right.
E
A
Yeah,
I
feel
like
we
definitely
we
should
keep
in
mind
that
now
like
I
can
I
basically
like
the
image
a
little
more,
because
you
give
that
analogy.
Basically,
every
time
you
make
a
change
that
you
want
to,
you
know,
use
an
argo
cd
ui
in
production.
It
seems
like
a
release,
and
you
know
image
with
attack
is
a
good
release,
a
defect
yeah.
E
Either
that
or
pulling
like
a
binary
from
github
release.
A
E
Yeah
the
the
architecture
stuff
you've
got
here,
looks
like
it.
It
fits
very
well
with
argo
cd.
I
just
had
those
questions
around
where
it
was
hosted,
all
right,
you
know
via
ingress
and
the
where
was
pulling
the
data
so
yeah.
Those
are
my
two
questions,
but
yeah
looks
great.
G
H
Okay,
so
if
we're
done
with
that
topic,
I
guess
we
can
go
on
to
the
next
topic,
so
I
had
visual
representation
of
all
applications,
health,
which
is
a
proposal
by
remington,
but
I
was
interested
on
working
on
it,
so
one
second,
let
me
share
my
screen.
H
Okay,
so
hopefully
you
can
all
see
it.
If
you
can't,
let
me
know,
but
so
this
was
remington's
proposal
so
on
the
application
list.
Page
you'd
basically
just
see
this
progress
bar
and
it
would
you
know
it
has
the
tool
tip
and
you
would
hover
over
it
and
it
would
show
you
how
many
are
healthy.
H
So
this
is
specifically
for
the
application
health
status,
and
you
also
were
proposing
that
we
do
one
for
the
sync
status.
Similarly,
I'm
not
sure
exactly
what
you
had
in
mind
for
how
they
would
both
look
together
and
how
to
differentiate
them,
and
then
serena
had
also
commented
yesterday
about
how
this
would
look
if
there
were
a
great
number
of
application
so,
like
she
says,
there's
a
hundred
apps.
H
How
would
that
look
if
one
of
them
had
a
different
health
status,
and
that
would
be
really
a
small
target
for
you
to
hover
over
and
be
able
to
see
that
one
was.
You
know
like
out
of
sync
or
missing
or
something
so
yeah?
I
just
wanted
to
get
some
feedback
on
this
before
I
actually
start
working
on
it.
H
Is
this
something
that
people
think
would
be
helpful?
I
think
it
would.
E
Right,
sorry-
and
I
assume
it
would
be
visible
on
both
the
kind
of
tile
view
and
the
list
view.
H
Yeah,
I
guess
I
guess
so
remington
did
you
have
any
idea
about
that.
D
Yeah,
so
my
thought
was
yes,
it
would
just
kind
of
live
above
the
list
of
applications,
for
I
was
kind
of
inspired
by
if
you
go
to
like
a
github
repo
and
you
kind
of
scroll
down
and
you
see
the
languages
little
bar,
it
looks
a
little
bit
like
this,
oh
yeah,
that
might
shed
some
light
on
what
it
would
look
like
if
there
was
a
very
small
amount
of
one
out
like
a
one
application
out
of
a
hundred
that
has
one
sync
status.
You
know
it
could
be
something
like
that.
D
We
could
even
add
this
to
the
sidebar
instead
of
up
at
the
top.
I
mean
this
was
kind
of
just
a
a
really
quick
proposal.
I
didn't
really
think
a
lot
about
the
details,
but
yeah
that
could
go
maybe
above
the
the
filters
on
the
left,
sidebar
or
something
like
that.
But
you.
A
A
Let's
say
you
have
just
one
broken
application
out
of
hundred.
I
think
it's
still
okay
to
make
this
broken,
but
a
little
bit
you
know
wider
than
it
is
actually
okay.
H
H
Yeah
they
have
it
all
listed
below
so
like
it
wouldn't
be
a
tool
tip,
so
you
wouldn't
ever
have
to
like
hover
over
like
this
one
little
part
at
the
end.
To
get
it
right,
it
would
just
be
listed
there
for
you.
D
I
think
one
thought
with
that
with
having
like
a
legend
like
that
underneath
legend,
is
we
already
kind
of
have
something
similar
in
that
sidebar,
where
we
list
okay,
this?
This
many
applications
has
this
sync
status
or
this
health
status
or
whatnot.
So
we
could
just
color
code
or
I
have
a
pure
open
that
as
icons
with
colors
two
of
them,
so
we
could
basically
have
a
two-for-one
where
the
filters
are
the
legend
and
you
kind
of
see
what
I'm
saying.
Okay,.
F
D
Yeah
sort
of
has
a
list
of
how
many
applications
so
like
on
github.
It
just
has
the
percentages,
but
for
our
cases
the
a
number
is
fine
and
yeah.
I
have
a
pure
open
that
kind
of
changes,
how
that
looks,
and
it
adds
an
icon
with
color
with
a
color,
and
so
if
we
just
match
those
colors,
I
think
it
would
act
as
a
wedge.
Okay,.
B
C
A
It
won't,
but
basically
I
think
birmingham
is
kind
of.
Basically
there
is
another
pr
that
changes
these
filters
and
it
just
have
to
be
merged,
reduced
and
merged,
but
we
changed
filters
agreed
to
change
filters,
so
it
would
be,
or
instead
of
and
like
if
you
click
degraded,
you
still
can
click
progressing
and
you
would
see
both
degraded
and
progressing,
and
I
think
in
this
case
it
makes
more
sense
to
keep
showing
that
bar
on
the
top.
Even
if
you
select
them.
E
Okay,
yeah,
but,
for
example,
if
you
had
100
applications
that
were
in
sync,
I
think
that
this
page
wouldn't
show
you
all
of
them.
It
would
only
show
you
the
first
x
like
20
or
30
or
50
or
whatever
it
is,
but
I
assume
the
bar
itself
would
show
all
of
them
all
hundred.
E
E
Like
with
that,
would
it
make
sense
for
that
bar
to
be
interactive
as
like
clicking
on
the
particular
status
in
the
bar
will
set
the
appropriate
filter
so
clicking
on
the
red.
E
The
degraded
ones
and
so
on
or
is
it
or
is
it
overkill
versus
just
having
that
in
the
filter.
D
I
think
it
would
make
sense.
The
only
thing
is,
even
if
we
set
a
min
or
a
yeah
minimum
width
for
how
wide
one
of
those
bars
would
be.
I
still
think
it
might
be
a
little
bit
too
too.
Small
to
target
melody
is
really
close,
like
there's
already
a
checkbox,
so
I
think
that
it
might
just
add
a
little
bit
too
much
complexity
that
doesn't
need
to
be
there,
but
it's
not
hard
to
do.
It
would
be
like
yeah
yeah.
It
would
be
a
few
keystrokes.
It's
not
hard.
E
Yeah,
as
a
user,
I
suspect
I
mean
every
user
is
different.
I
think
personally,
I
would
probably
like
once
I
saw
that
I
would
try.
If
I
was,
I
have
to
be
curious
about
what
the
degraded
apps
were.
I
would
probably
try
to
click
that
particular
color
and
perhaps
have
the
expectation
that
it
would
show
me
just
those
items
but
yeah.
What
you
mentioned
is
correct.
There
is
a
balance
between
managing
user
expectation
versus
giving
them
an
experience.
That
is
actually.
H
H
Are
there
any
other
ui
ux
topics
that
we
want
to
discuss?
Otherwise
we
can
just
open
it
up.
A
All
right,
yeah,
I
think
we
yeah
we
can
just
discuss
random
questions.
I
think
I
don't
want
to
go
through.
You
know
the
process
changes
proposal,
one
more
time
because
I
think
with
I
was
hoping
that
tropic
would
be
in
the
discussion
and
again
because
jan
was
proposing
a
lot
of
this
related
to
the
process
so
yeah.
E
C
Okay,
oh
yeah,
sorry
about
that
yeah
that
that
seems
like
something
easy
to
do.
Yeah
by
the
way,
I
think
might
also
have
the
privilege
too.
So
just
on
the
org
on
the
quay
account.
E
I
think
an
admin
of
the
org
to
do
that.
He
may
be
if
he
is,
let
me
know
and
I'll
I'll
talk
to
him,
but.
A
I
want
to
fix
it
and
then
I
will
create
the
you
know.
Robot
I
thought
shobik
was
the
one
who
actually
created
everything
I
think
he
created.
I
asked
him
and
he
just
told
me
you
can
you
know
anyone
can
create,
and
I
created
it
when
I
added
admins,
I
didn't
realize
admin
is
not
the
highest
level
of
you,
know,
access
so
yeah.
A
I
Is
see
you
next
time,
github
discussion,
moderator,
thank
you.
A
C
E
I
think
jesse
you
were
subbing
in
for
alex
is
the
order
that
it
was.