►
From YouTube: Argo CD and Rollouts Community Meeting 7th Apr 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).
A
All
right
welcome
everyone
to
the
april
argo
cd
and
argo
rollouts
community
meeting.
My
name
is
jesse
suen
and
I
am
a
maintainer
of
the
argo
projects
and
today
we
have
a
couple
of
announcements.
The
first
announcements
we
have
is
the
general
availability
of
argo
cd
2.0.
A
So
we
actually
had
the
release
candidate
for
just
under
a
month,
and
this
has
actually
been
one
of
our
smoothest
releases
so
far
internally
and
into
it.
We've
been
running
this
in
in
our
production
systems
for
the
since
about
march
19th,
and
so
far
it's
it's
been
one
of
the
smoothest
releases
we've
had
so
far.
A
A
So
if
you
have
a
large
application,
which
has
many
pods,
there's
a
new
button
right
here,
which
visualizes
your
pods
and
they
and
groups
them
in
at
either
a
node
level
or
a
top
level
resource
level,
or
also
a
parent
level,
which
is
useful
if
you
want
to
see
pods
jumping
from
one
replica
set
to
another
and
the
the
other
thing
we
have
is,
is
there's
a
lot
of
stuff
in
the
ecosystem.
So,
within
the
argo
project
labs
we
have
the
image
updater.
A
So
if
you
want
a
docker
push
to
actually
trigger
builds,
you
can
actually
install.
Actually,
let
me
open
the
the
link
to
the
cncf.
A
We
have
argo
cd
notifications,
which
is,
if
you
want
things
like
slack
notifications,
when
your
application
promotes
or
and
application
sets,
if
you
this
is
now
our
first
first
official
release
for
application
sets,
and
this
is
our
controller,
which
helps
you
manage
groups
of
applications
as
a
as
a
unit.
So
if
you
have
a,
if
you
find
yourself
needing
to
duplicate
your
applications
with
minor
difference
variants
of
the
same
spec,
the
application
sets
lets,
you
automate.
The
creation
of
those
applications.
A
So
yeah,
so
argo
cd
2.0
is
out
and
encourage
everyone
to
start
trying
it
if
you
haven't
already,
and
so
the
next
two
items
so
today,
shama
will
be
presenting
on
a
enhancement
proposal
to
essentially
revamp
our
configuration
management
plug-in
and
so
currently
the
problem
with
config
management
plug-ins
is
that
it's
pretty
cumbersome
to
get.
A
Basically,
if
you
want
to
customize
your
config
management,
it's
pretty
cumbersome.
You
have
to
rebuild
the
argo
cd
image
or
map
in
some
binaries
at
runtime
and
and
edit
some
config
map
to
to
specify
how
to
use
it.
So
the
config
management
2.0
is
trying
to
address
all
those
limitations
and
finally,
remington
will
be
showing
a
ui
that
the
cube,
c2,
argo
rollouts
plugin
will
have
that
you
can
run
locally
or
actually
you
can
run
it
inside
the
cluster.
A
If
you
want,
but
a
ui
that
you
can
run
locally
to
visualize
your
rollout
rollouts
as
they
are
deploying
okay
with
that
we'll
I'll
pass
it
off
to
shama
and
just
a
reminder,
these
meetings
are
recorded
and
uploaded
to
youtube.
B
So,
to
begin
with
the
summary
currently,
argo
cd
provides
the
first
class
support
for
him
customize
case
on
it
and
jsonnet
the
support
being
bundled
binaries
and
ability
to
override
parameters
in
via
ui
and
cli
the
application
discovery
in
git
repository
and
auto
suggestions,
while,
while
creating
the
application
in
ui
and
the
performance
optimization.
B
B
Two
changes
by
argo
cd
operator
first
is
to
add
an
entry
in
config
management
plug-in
in
argo,
cd
config
map
and,
second,
is
to
add
an
init
container,
either
to
add
an
init
container
via
volume,
a
volume
mount
that
adds
a
new
binary
in
repo
server
port
or
to
rebuild
the
repo
server
image
which
will
which
contains
the
necessary
tooling
required
this
problem
being
error
prone
and
manual.
The
goal
here
is
to
make
the
additional
tools
easily
accessible
for
the
installation,
and
the
second
is.
B
Second
is
to
provide
discovery
that
is
auto
selection
of
the
tool
so
for
natively
supported
config
management,
plugins.
Currently,
argo
cd,
auto
detects
and
selects
the
appropriate
tool,
given
only
the
git
repository.
This
selection
is
based
on
the
recognition
of
the
well-known
file
in
the
directory
that
is
chart.yaml
or
customizat
customization.yaml.
B
So
as
part
of
the
improvements
here,
we
want
to
provide
the
same
ability
to
auto
select
the
plugin
based
on
the
recognition
recognized
files
in
the
path
of
the
git
repository
jumping
to
the
proposal.
So
the
solution
that
we
have
drafted
for
this
problem
statement
is
to
run
the
config
management
plugin
tools
as
a
sidecar
in
the
repo
server.
B
It
will
also
contain
a
specification
file
describing
how
to
render
the
manifest
and
its
entry
point
will
be
a
lightweight
config
management,
plug-in
api
server.
That
will
receive
the
request
from
the
main
repo
server
on
how
or
to
render
the
manifest
based
on
the
specification
file.
So
the
benefits
it
it
provide
over.
B
The
existing
solution
is
that
now
plugin
owner
will
have
control
over
the
execution
environment,
so
they
can
package
whatever
dependent
binary
is
required
and
an
argo
cd
operator
who
wants
to
use
the
additional
conflict
management
tool
will
not
have
to
go
through
the
hassle
of
building
the
customized
repo
server
in
order
to
install
the
required
binaries
and
then,
and
also
this
plug-in
image
will
be
running
in
a
container
separate
from
the
main
triple
server.
So
coming
to
the
use
case,
the
first
use
case
being
as
an
argo
cd
user.
B
I
would
like
to
use
the
first
class
support
provided
for
the
additional
tools
to
generate
and
manage
deployable
kubernetes
manifest
and
as
an
argo
cd
operator.
I
want
to
have
the
smooth
experience
to
install
the
additional
tools
and,
as
the
plugin
owner,
I
do
want
to
have
some
some
control
over
my
execution
environment
so
that
I
can
install
the
dependent
binaries
now
for
the
implementation
detail.
So
for
installation,
a
plug,
a
plugin,
an
operator
will
simply
have
to
patch
the
repo
server
to
run
the
config
management
plugin
container
as
a
site
card.
B
So,
for
example,
if
I
want
to
use
the
cdks
plugin,
then
I
would
run
it
as
a
sitecar
container
in
the
repo
server
deployment
and
its
entry
point
will
be
the
con
cmp
server,
which
will
be,
which
will
be
in
the
volume
shared
between
the
repo
server
and
the
plugin
sidecar
container,
and
this
this
change.
This
will
also
change
how
this
will
also
change
the
repo
server
manifest.
So
it
now
the
repo
server
manifest
will
have
an
init
container,
which
will
pre-populate
a
volume
shared
between
the
plug-in
and
the
repo
server.
B
So
this
init
container
will
copy
the
cmp
server
from
the
volume
shed
between
the
server
and
the
plugin
container,
and
the
shared
volume
will
have
will
will
hold
the
socket
file
that
repo
server
uses
to
communicate
to
each
plugin
and
the
git
repositories
cloned
by
the
repo
server
now
for
configuration.
B
The
plugin
will
be
configured
via
manifest
file
located
inside
the
plugin
container
placed
at
the
well-known
location,
so
how
this
file
gets
here.
Algo
city
doesn't
care
how
this
file
is
placed
inside
the
plug-in
container,
the
options
being
baking
the
file
into
the
plugin
image
as
part
of
the
dockable
or
volume
mapping
the
file
through
a
configmap.
B
So
this
is
the
example
of
this
specification
yaml.
So
one
thing
to
note
here
is
that,
even
though
it
looks
like
kubernetes
object,
it
is
not
a
custom
resource.
It
only
follows
the
kubernetes
style
spec
convention,
so
here
it
will
have
an
init
command,
generate
command
discovery
command
and
allow
concurrency
so
allow
concurrency
is
something
which
we
have
currently.
It
enables
the
multiple
manifest
creation.
B
In
parallel,
the
generate
command
is
the
command
which
will
be
used
to
render
the
manifest
and
the
discovery
command
is
the
command
which
will
so
when,
when
the
repo
server
will
auto
select
a
tool,
it
will
run
this
discovery
command
in
all
the
listed
tools
and
whichever
command
responds
with
a
positive
response
will
be
chosen.
B
So
let's
say:
if
it's
a
cdks
plugin,
then,
if
this
command
is
run,
it
will
have
a
main.ts
file
and
it
will
respond
with
a
positive
response
and
then
cdks
will
be
chosen
as
the
plugin
to
render
the
manifest.
B
So
now,
what
is
the
cmp
server?
Cmp
server
will
be
a
a
new
argo
cd
component,
whose
responsibility
will
be
to
execute
the
generate
command
inside
the
plugin
environment.
So
it
will
expose
these
two
apis.
So
one
is
first
is
standard,
manifest
and
second
is
supported,
so
it
supported
returns.
Whether
or
not
the
given
path
is
supported
by
the
plugin
and
the
path
here
being
the
part
to
the
application
at
the
startup.
Cmp
server
will
look
for
the
specification
file
to
understand
how
to
perform
this.
B
These
requests
so
for
the
registration,
the
repo
server,
the
repo
server
now
needs
to
understand
what
all
plugins
are
available
to
render
the
manifest.
So
to
do
this,
cmp
servers
will
register
themselves
as
available
plugin
to
argo
cd,
repo
server
by
populating
the
name
socket
file
in
the
shared
volume.
So
the
name
of
the
socket
file
here
of
socket
file
will
indicate
the
plugin
name
and
to
discover
the
available
plugin.
The
repo
server
will
simply
list
the
shared
plugin
directory
to
communicate
with
the
plugin.
B
The
repo
server
will
need
to
connect
to
the
socket
and
make
grbc
call
against
the
cmp
server
listening
on
the
other
side.
Okay,
so
for
the
auto
selection
of
the
tool,
the
this
the
plugin
discovery
will
run
in
the
main
repo
server
container
and
the
argo
city.
Repo
server
then
will
list
the
this
directory
plugin
directory
and
run
run
the
discover
command
from
the
specification
file
in
each
one
of
them
and
whichever
response
with
the
positive
response
for
first
will
be
selected
so
for
the
voice
versioning.
B
If
there
there
will
be
one
sidecar
container
per
version.
So
if
someone
wants
to
use
two
different
versions
of
a
plus
plugin,
then
they
would
have
to
configure
two
different
cycles
coming
to
the
security
consideration
here.
So,
first
of
all
to
you
to
use
a
plug-in
as
a
site.
Car
container,
separate
from
the
main
repo
service
is
already
an
improvement
over
the
existing
mechanism,
because
the
plugin
tooling
will
not
will
no
longer
have
the
access
to
the
files
of
the
argo
cd
repo
server
image.
B
B
So
this
means
that
a
command
which
executes
in
the
git
repository
path
could
traverse
upward
and
see
and
write
the
file
which
are
outside
it
outside
the
current
tree.
So
one
proposal
to
prevent
the
out
this.
This
thing
is
that
to
is
that
each
git
repository
can
be
cloned
with
a
unique
uid
different
from
the
repo
server
uid.
So
when
the
cmp
server
executes
the
tooling
command
to
generate
the
manifest,
the
command
can
could
be
executed
with
the
uid
of
the
git
repositories
file
instead
of
the
repo
server
uid.
B
Lastly,
for
the
upgrade
and
downgrade
strategy,
one
thing
to
note
here
is
that
this
proposal
will
not
change
how
we
are
handling
the
first,
the
native
plugins
currently,
but
for
the
additional
tools
august,
argo,
cd,
repo
server
manifest,
will
change,
because
now
it
will
contain
an
init
container
which
will
populate
this,
which
will
populate
cmp
server
binary
inside
the
plugin.
B
B
Upgrading
to
this
version,
argo
cd
operator
will
now
have
to
make
the
following
changes
if
they
want
to
use
the
additional
tool.
So,
first
of
all,
they
will
have
to
install
the
plugin
as
the
sidecar
container,
so
they
will
have
to
patch
this
into
the
repo
server
manifest
and
this
cycle
containers
entry
point
should
be
the
cmp
server
and,
secondly,
they'll
have
to
place
the
manifest
file
inside
the
plug-in
container.
B
It
can
be
done,
as
mentioned
before
it
can
be
done
either
via
baking,
the
file
into
the
plugin
image
or
via
volume,
mapping
file
through
the
configmap.
So
that's
it.
If
anyone
has
any
questions
or
this,
this
is
available
as
a
pr
in
the
argo
cd
repo.
So
if
anyone
is
interested,
they
can
go
and
look
at
it
as
well.
C
Quick
questions
could
I
use
this
to
override
one
of
the
built-in
tools
like?
Could
I
use
it
to
specify
a
say,
a
custom
version
version
of
helm.
A
Yeah
one
of
the,
I
think
the
choices
we
have
to
make
is
that
should
the
native
currently
native
support
like
the
customized
helm,
should
they
be
also
built-in
plug-ins?
I
mean:
do
we
ship
the
manifest
with
like
a
helm
and
a
customize,
and
I
guess
jsonnet,
side,
cars
and
and
then
that
way
people
can
choose
to
use
upgrade
helm
at
their
leisure.
I
think
that
should
be
a
a
target
state
that
we
we
can
swap
out
the
native
stuff
with
config
management
2.0.
A
But
it
is,
I
think,
a
little
tricky
because
the
the
spec,
the
argo,
the
application
spec,
as
you
know,
already,
has
first-class
fields,
support
for
those
built-in
commands,
and
so
we'll
have
to
have
some
need
some
kind
of
special
casing
to
support
it,
both
as
a
config
management
plug-in
but
use
a
native
syntax
in
the
application
spec
so,
but
that
I
think
that
should
be
a
goal
of
ours
is
to
be
able
to
replace
the
natively
supported
stuff
with.
A
D
D
So
with
that
proposal,
basically
the
whole
plugin
configuration
can
be
packaged
into
yaml
file
and
it
can
be
crowdsourced
like
basically,
we
could
potentially
have
a
github
repository
that
has
catalog
of
plugins
and
plugin
maintainers
can,
you
know,
can
improve
configuration
which
then
can
be
used
by
everyone,
and
I
think
it's
maybe
one
of
the
most
important
improvements.
A
Right
yeah,
the
idea
is
like
we
would.
We
should
start
having
people
publish
like.
Oh,
I
have
a
new,
you
know
a
plugin
for
cdks
and
and
there's
like
a
whole
community
that
maintains
like
the
cdks,
plug-in
and
and
cdks
never
has
to
be
natively
supported
by
our
grcd.
It's
just
you
can
choose.
You
know
the
version
of
cdks.
You
want
by
just
adding
a
sidecar.
A
Similarly,
maybe
you'll
need
it.
You
can
use
off
the
shelf.
Docker
images
that
just
have
the
tooling
already,
and
the
only
thing
you
need
to
do-
is
take
that
off-the-shelf
container
image
and
just
map
in
a
specification
into
that
sidecar
with
that
tells
argo
cd
how
to
invoke
the
command.
C
B
C
A
That's
true,
like
I
guess
the
yeah,
so
if
you
it
depends,
I
guess
it
depends
on
how
you're
managing
your
argo
cd.
If
for
I
guess
for
customized
users,
it
would
be
pretty
it's
simple
because
they
just
do
a
last
mile
overlay
with
their
sidecar,
and
so
even
if
they
upgrade
the
main
argo
cd,
they
don't
really
have
to
repeat
any
sidecar
installation
ex
process
because
their
overlay
is
already
there.
I
guess
I'm
not
sure
what
the
experience
would
be
for
helm,
but
I
imagine
the
helm
chart
would
have
a
plug-in.
A
All
right
any
other
questions
for
shama
about
this.
This
feature.
A
Yeah,
so
once
again,
this
is
this
is
an
enhancement
proposal
by
the
way,
we're
trying
to
follow
this
new
process
for
big,
bigger
changes
to
argo
cd,
so
there's
for
any
any
kind
of
a
non-trivial
type
of
enhancement
that
we
want
to
make
to
cd.
There's
a
template
about.
Let
me
see
if
I
can
find
it.
A
At
but
there's
a
enhancement
proposal
template
for
these
bigger
changes
that
have
different
sections
that
you
want
need
to
fill
out.
You
know
security
considerations,
whether
the
upgrade
and
downgrade
strategies.
A
So
if
you
have
a
you
know
a
big
issue
idea
that
you
want
in
argo
cd
and
we,
I
think,
you'll-
want
to
follow
this
proposal.
We'll
ask
you
to
follow
this
proposal
process
to
describe
how
you'd
you
know,
use
cases
and
how
it
would
work.
E
Could
be
in
dogs
proposals
sorry
into
some
different
device?
That's
why
I
can
change
it.
A
Thanks
all
right,
so
showbike
will
link
to
that
in
the
chat,
and
next
we
have
a
new
webview
user
interface
for
the
argo
rollouts
plugin.
So
remington
has
been
working
on
that.
This
is
something
we
actually.
I
thought
we
could
squeeze
into
the
the
rollout
the
upcoming
rollouts
v1
release
and
remixton.
Do
you
want
to
start
sharing
yeah
absolutely.
Can
you
guys
hear
me
yeah,
okay,
great.
F
Yeah
we
can
see
your
entire
screen.
Okay,
can
you
see
the
terminal
window
yeah
great,
all
right
perfect?
So
we've
baked
this
into
the
cube.
Ctl
argo
rollouts
plugin.
So
all
you
have
to
do
to
start.
This
is
run
cube.
Ctl,
argo
wallets
dashboard
and
now
it's
going
to
be
hosting
at
localhost
3100.
So
I'll
do
a
new
window
here.
F
And
you
can
see
we
have
a
list
here
of
all
of
the
rollouts
that
are
currently
available
in
this
namespace,
so
it's
on
a
per
name
space
basis.
So
I've
just
got
this
demo
namespace
here,
rollouts
demo,
you
can
search
for
any
rollout
there's
only
three
here,
but
if
you
have
a
long
list
of
them
it
might
be
a
little
bit
more
useful
and
then
you
can
click
on
any
of
these.
F
So
in
this
overview
you
can
only
really
see
the
pods
that
are
in
each
replica
set,
there's
not
a
whole
lot
of
other
information
here.
So,
let's
dive
in
so
we
have
this
canary
rollout
here
and
it's
currently
paused.
F
So
we
have
two
replica
sets.
We
have
the
canary
replica
set
and
the
stable
one
one's
running
the
yellow
image
one's
running
the
blue
image.
So
we
can
actually
change
the
container
image
through
this
ui.
So
I'm
going
to
change
it
to
the
red
image
actually
and
we'll
save
it.
It's
going
to
ask
if
we're
sure
so
we'll
save
it.
You
can
see
this
updating
live,
so
this
new
container
is
being
created.
It's
basically
just
updating
the
canary
replica
set
to
this
new
red
image,
so
this
pod
looks
good
to
go.
F
You
can
see
we're
still
paused
here,
but
this
red
image
actually
has
some
errors
in
it.
It's
designed
to
be
an
error
full
container
image,
so,
instead
of
promoting
it
full
I'm
going
to
abort
it
so
it'll
again
confirm
that
I
want
to
import
so
now
that
we're
confirming
that
we're
boarding.
You
can
see
that
this
is
starting
to
terminate,
and
this
replica
set
now
has
an
extra
pot
in
it.
So
let's
go
ahead
and
we'll
actually
promote
it
full
this
time.
F
So
let's
go
back
to
the
blue
image
and
you
can
see
it's
suggesting
here,
some
container
images,
so
these
are
all
the
images
that
have
previously
been
used
in
this
rollout.
So
let's
go
back
to
blue
all
right.
F
F
So
now
the
this
replica
set
will
start
to
terminate
one
by
one
and
then
some
new
pods
will
be
spun
up
here
and
you
can
see
that
it's
progressing
through
these
steps
right
here.
So
you
see
each
step
that
was
defined
in
the
rollout
spec,
it's
waiting
10
seconds,
every
20
percent
weight,
and
so
it's
just
slowly
going
through
these
steps
and
you
can
see
them
update
live
here.
F
And
there
it
goes
all
right
so
now
that
these
are
all
up
and
running.
I'm
gonna
show
the
rollback
feature
here,
so
you
can
roll
back
to
any
of
these
replica
sets.
So
any
previous
state
of
the
rollback
or
of
the
rollout
you
can
roll
back,
and
you
can
see
that
it's
now
slowly
starting
to
terminate
the
blue
replica
set.
Oh
actually,
no
sorry
it's
going
to
go
back
to
the
previous
canary
state,
so
this
red
image
will
be
the
canary
image
and
this
blue
replica
set
will
remain.
F
F
And
additionally,
you
can
go
back
to
the
list
and
we
also
show
analysis
run
information
so
that
rollout
that
I
was
just
downloading
didn't
have
any
analysis
runs
in
it,
but
this
one
does
have
a
simple
job.
Analysis
run
this
one's
still
running.
F
I
think
there
was
something
wrong
with
it,
but
once
it's
committed,
if
it's
successful
then
this
will
this
little
bar
will
show
green,
and
if
it's
error,
that'll
show
red,
and
so
we
believe-
or
we
keep,
I
believe
only
10
of
these
analysis
runs
and
so
typically
you'll
have
somewhere
on
the
order
of
10
little
bars
across
here.
That
will
show
your
current
analysis
run
state
anybody
have
any
questions.
F
Yes,
it
does
yeah,
so
we
can
go
to
blue
green
there's.
Just
a
lot
less
information
here,
that's
surface
for
blue
green,
but
it
does
work
for
blue
green.
A
Yeah,
so
for
some
context,
actually,
when
we
started
trying
to
build
out
the
the
ui,
this
is
actually
something
we
wanted
to
do
in
the
argo
cd
user
interface
first
and
and
that
was
actually
where
remington
started.
His
work
is
like:
how
do
we,
how
do
we
get
argo
cd
to
show
rollouts
in
its
ui
in
like
a
in
a
better
way,
rather
than
just
the
resource
tree
view,
but
then,
as
we
started
thinking
about
it,
it
was.
A
This
is
actually
more
of
a
issue
in
general,
like
how
do
we
show
more
richer
information
for
things,
not
just
rollouts
but
other
type
of
custom
resources
that
might
come
up
in
the
future,
and
so
what
happened
was
we?
We
shifted
our
thought
process
and
saying:
okay,
instead
of
argo,
cd
have
building
native
support
for
visualizing
all
these
custom
resources.
A
What
if
we
delegate
this
out
to
some
other
pro
extension,
meaning
if
we
could
have
almost
like
an
iframe
or
something?
And
so
we
haven't
fully
thought
that
out
yet,
but
we
knew
that.
I
think
a
future
direction
of
vargo
sees
that
we
want
to
allow
the
ui
to
get
extended.
Somehow,
in
argo
cd,
and
so
instead
of
building
it
directly
in
argo
cd,
we
decided
to
make
a
standalone
argo
rollouts
ui
that
could
eventually
somehow
get
integrated
into
rcoc,
which
we're
still
working
through
that.
A
A
Here
you
know,
questions
on
issues
or
you
know
future
work,
items
or
200
or
anything.
A
A
All
right,
so
I
think
that
concludes
the
april
community
meeting
for
argo,
cd
and
rollouts,
and
thanks
everyone
for
attending
and
and
we'll
see
you
again
in
two
weeks
for
the
rollouts
and
the
events
community
meeting.
As
always,
if
you
do
have
a
topic
that
you
want
to
bring
up,
you
can
always
put
it
in
the
google
doc
that
we
have
for
these
meetings
and
just
add
it
to
the
agenda
item
and
then
we'll
make
sure
we
address.
A
All
right
thanks,
everyone,
jc
and
we'll
see
you
again
later.