►
Description
How do GitOps and enterprises coexist? Today we’ll have Henrik Blixt from Intuit join us to share how they use ArgoCD and what they have learned to power their GitOps workflows. As always, we want as much as possible to make this an open conversation - where you ask the questions and get some real-life answers from people who have had those questions before, so tune in live and remember to keep calm and Git on!
About ArgoCD:
Argo CD is an open source, declarative, GitOps continuous delivery (CD) tool which automates the deployment of services and applications in Kubernetes environments.
https://argoproj.github.io/argo-cd/
Follow us:
Christian Hernandez https://twitter.com/christianh814
Chris Short https://twitter.com/ChrisShort
Henrik Blixt https://www.linkedin.com/in/hblixt/
What is GitOps Guide to the Galaxy?
Every other Thursday at 3am ET hosts Christian Hernandez and Chris Short sit down to discuss everything in the GitOps universe, from end-to-end CICD pipelines to creating Git workflows.
Subscribe to Red Hat's YouTube channel: https://www.youtube.com/redhat/?sub_c...
About OpenShift:
Red Hat OpenShift is an open source container application platform based on the Kubernetes container orchestrator for enterprise application development and deployment.
Openshift.com https://red.ht/33Fh6uV
OpenShift on github https://github.com/openshift/
OpenShift on redhat.com https://red.ht/2o4ccDk
#RedHat #GitOps #Kubernetes
A
A
A
A
B
All
right
we
are
live.
Everyone
welcome
to
getup's
guide
to
the
galaxy.
My
name
is
chris
hernandez.
As
you
see,
we
are
missing
someone
today
we're
missing.
Chris
short,
so
unfortunately
I
don't
have
a
cool
intro,
like
chris
short,
does
he's
having
internet
issues,
so
we
we,
we
hope
to.
We
hope
to
have
him
back
soon.
Hopefully,
comcast
can
get
out
there
at
one
point
this
week
to
help
him
out,
but
we
are
here.
B
I
am,
I'm
actually
really
happy
to
be
joined
by
two
people
from
into
it
right,
so
we
have
hendrick
and
alexander.
I
won't
butcher,
you
guys
last
name
I'll.
Let
you
guys
introduce
yourself
from
from
intuit
and
we're
here
to
talk
about
argo.
Just
like
argo
cd,
the
argo
project
in
general
get
some
some
cool
background
about
how
intuit
is
using
argo
city
and
how
they
they
brought
it
into
the
open
source
community.
C
Thanks
christian,
it's
a
pleasure
to
be
here.
My
name
is
henry
blixt:
I'm
a
product
manager
at
intuit.
I
think
my
official
title
is
product
manager
of
platform
and
open
source,
so
I'm
the
product
manager
responsible
for
for
argos.
I
deal
with
with
a
lot
of
regular
product
management
issues
in
our
how
we
use
argo
internally.
C
What
features
our
internal
customers
need,
but
I'm
also
working
a
lot
outbound
with
cncf,
with
our
partners
like
red
hat
and
figuring
out
how
we
take
argo
and
argo
project
to
the
in
the
next
level
and
how
we
work
with
the
community
to
do
that.
So
I
have
a
come
from
a
background
in
in
openstack.
Please
don't
hold
that
against
me.
B
C
A
A
But
I
can
try
it
yeah,
it's
much
extensive,
which
is
long
and
strange,
I'm
a
principal
social
engineer
at
intuit,
and
I
also
I'm
a
maintainer
of
argo.
As
you
might
know,
it's
a
set
of
projects.
So
basically
I
was
involved
with
many
of
them,
but
most
recently
I'm
working
on
argo
cd
specifically
and
I'm
basically
developing
it
and
I'm
responsible
for
running
it
into
it.
And
so
that's
why
I
know
a
lot
about
scalability
challenges
and
yeah.
This
is
I'm
happy
to
share
what
we've
learned
so
far
and
help
you
use
rbc
yeah.
B
So
what
cool
yeah
like
actually
one
of
one
of
the
the
the
things
that
that
a
lot
of
people
don't
know
is
that
intuit
actually
was
a
customer
so
like
actually,
I
think
alexander,
maybe,
would
have
a
little
bit
more
background
about
the
the
acquisition
and
maybe
I'm
getting
this
wrong.
So
I'll,
just
kind
of
kind
of
give
an
overview,
but,
like
actually
argo
cd
came
from
what
was
the
company
name?
Athletics,
athletics,.
B
A
C
Yes,
it
actually,
it
actually
started
a
bit
earlier
into
it
embarked
on
a
modernization
journey
you
know
into
it
has
been
around
for
a
while
right
and
there
was
a
lot
of
legacy
stuff
standard
data
centers,
you
know
we
ran
into
issues
of
engineers
were
moving
too
slow.
There
was
just
a
lot
too
much
red
tape
and
things
that
needed
to
happen
to
do
new
releases
spend
too
much
time
managing
hardware.
C
That's
not
really
business
critical
to
to
a
software
and
a
financial
software
company
like
us
hardware
is
managing
hardware,
is
not
you
know
in
our
our
core
business,
so
so
there's
some
modernization
journey
that
started
long
quite
a
bit
before
that
and
it's
and
it's
part
of
that
they
started
looking
at
now.
How
do
we
increase
developer
velocity?
C
I
think
this
was
about
three
and
a
half
years
ago
alex
that
applies
was
required,
and
I
think,
just
a
few
months
after
as
the
atlantic's
team
and
some
more
people
at
intuit
started
building
out
the
new
platform,
this
modernization
platform
that
we
very
thoughtfully
named
the
modern,
modern
south
platform
cd
was
born.
So
cd
came
out
of
that
in
the
early
20
mid,
mid
2018.
A
A
About
you
know
why
why
this
even
was
created
and
what
was
our
goals,
so
I
I
think
it's
important.
We,
we
were
not
trying
to
just
create
a
new
project
for
the
sake
of
project
creation
and
we
actually
had
a
big
kind
of
challenge.
We
were
supposed
to
just
on
board,
potentially
thousands
of
developers
with
like
with
not
so
much
of
kubernetes
knowledge
on
kubernetes
and
that's
why
we
were
just
trying
to
create
the
tool
that
would
simplify
it.
A
A
You
know
the
simplest
possible
experience,
and
that's
why
argo
is
kind
of
is
like
a
it's
a
github
separator
as
a
service,
so
you
don't
have
to
run
anything
to
use
it.
You
just
open
the
url
and
then
you
that's
it
you
you
you.
Basically
you
can
consume
it,
and
it
also
explains
why
argo
cd
has
rich
user
interface.
A
C
A
C
C
You
know
it's
fully
on
kubernetes,
you
know
all
cloud
native
and
we
closed
our
last
data
center.
I
think
about
two
years
ago,
so
this
is
fully
wow,
fully
fully
public
cloud
fully
cloud
native
about
5
000
engineers.
So
it's
it's
been
a
pretty
quick
or
a
very
quick
shift.
I
would
say
into
this
into
using
this
new
platform
and
migrating
off
of
you
know
closing
our
old
data
center.
B
Yeah,
oh
yeah,
it's
it's
kind
of
like
well.
What's
the
saying
necessity
is
the
mother
of
invention
right,
like
you,
you
were
you
had
this
need,
and
so
okay?
Well,
let's
just
build
a
tool
that
is
very
easy
to
use.
That's
actually
one
of
the
one
of
the
things
I
really
really
loved
about
argo.
When
I
first
started
working
with
argo
cd
was
the
the
learning
path
right.
The
the
learning
curve
is
is,
is
very
it's
not
steep
at
all
right.
B
So
it's
it's
easy
to
use
it's
easy
to
get
started,
but
then
it's,
it's
kind
of
you
know
like
learning
like
you
see
back
here,
it's
kind
of
like
learning
the
guitar
right
like
getting
started
is
actually
pretty
easy.
Like
hey,
oh
hey,
like
you
know,
I
can
play
a
few
chords,
but
if
you
want
that
mastery,
it's
there
for
you
as
well
right,
so
it's
kind
of
it's
flexible.
So
I
kind
of
like
equate
that
to
why
I
liked
argo.
B
So
much
is
that
to
get
started
was
really
really
simple
and
it
sounds
like
by
design
that's
how
it
was
to
onboard
you
had
thousands
of
thousands
of
of
of
engineers.
You
didn't
want
to
bog
them
down
with
all
the
infrastructure
stuff
or
all
the
delivery
stuff
you
didn't
want.
You
just
want
them
to
be
able
to
code
rapidly
yeah.
That's.
C
A
A
We're
talking
about
the
history,
I
think
it
it's
nice
to
mention
that
so
yes,
we
started
that
into
it
and
we
open
source.
And
obviously
you
know,
the
project
that
was
just
created
not
necessary.
Has
a
ton
of
users
and
intuit
was
kind
of
a
driver
of
features
for
a
long
time.
But
I
guess
maybe
after
maybe
one
year
of
development,
it
flipped
and
till
now.
C
A
B
I
never
would
have
thought
of
that
myself.
It's
a
great
use
case.
So
that's
there's
actually
a
question
here.
If
you
guys
are,
are,
are
open
to
taking
questions
go
ahead.
There
is
actually
talking
about
the
history
right,
so
this
is
from
from
washari
one
of
our
regular
viewers
right
so
welcome.
He
says
he
asks
since
we're
getting
a
history
lesson
here.
What
would
you
do
differently
today?
A
Yes,
I
think
one
thing
would
I,
which
I
would
change,
is
that
we
were
too
focused
on.
You
know
this
kind
of
multi-tenancy
use
case
and
we
kind
of
so
what
we
did
wrong
in
the
beginning
and
we're
still
trying
to
improve
it,
and
we
keep
doing
it.
Basically.
Rbcd
was
a
tool
that
helped
manage
applications
declaratively,
but
itself.
It
was
managed
imperatively
only.
A
B
A
B
I
know
because
I've
I've
written
helm,
charts
to
deploy
argo
cd,
but
essentially
you
need
that
day,
zero
thing
right,
so
basically
it
instantiates
argo
cd
and
then
I
just
apply
the
manifest
that
argo
city
uses
to
then
you
know
kind
of
that.
That's,
like
my
entry
point,
but
it's
good
to
hear
that
you
know
those
you're
making
those
incremental
incremental
changes
to
make
it
more
declarative
so
and
then
so
before.
B
B
Yeah
yeah
exactly
so
the
the
dex
integration
is
actually
there.
You
can
actually
can
use
it.
It's
just.
We
can't
support
the
dex
image
itself
right,
so
you
can't
pick
up
the
phone
and
call
red
hat
if
something
with
dex
breaks,
so
you
have
to
go
upstream.
So
we
can't
officially
say
we
support
it,
but
it
actually
works
right.
It's
just
argo
cd,
argo
cd,
that
100
works
with
dex.
That's
I
think
the
primary
or
or
I
think
you
do
have
a
oidc
connector
directly.
B
C
Just
going
back
to
your
last
question,
I
think
we
would
have
done
differently.
I
think
one.
One
thing
that
we've
noticed
is
this
was
almost
a
little
bit
of
a
victim
of
our
our
own
success,
because
argo,
you
know
between
the
four
projects
has
been
growing
very
quickly
here
since
since
the
inception
and
we
spent,
we
spent
a
lot
of
time
with
the
community
helping
the
community
and
a
lot
of
companies
that
reached
out
within
a
lot
of
one-on-one
one-on-ones
with
various
companies
and
helping
them
with
various
things.
C
And
you
know
red
hat.
You
know,
we've
been
really
excited
about.
You
know
partnering,
with
red
hat
and
red
hat,
stepping
up
and
helping
out
and
doing
a
lot
of
good
work
with
argo,
and
I
think
that's
one
of
the
things
that
maybe
should
have
done
earlier.
Just
try
and
do
more
partnering
and
getting
more
other
companies
to
come
in
and
help
out
as
well,
because
it
was
starting
to
you
know,
strain
our
our
resources,
just
with
all
the
support
and
all
the
external
work
that
we
did
not
necessarily
feature
building.
C
B
Like
you
see,
companies
like
like
microsoft,
right,
like
apple
intuit,
like
going
into
the
open
source
space
and
saying
hey
like
this.
This
is
this
is
a
valuable
way
to
improve
our
software
and
and
make
those
have.
Those
contributions
upstream
is
is
is
now
now
it's
seen
like.
Oh
you
know
like
this
is
a
strategic
move
that
we're
that
we're
making
in
in
our
company.
So
I
think,
that's
that
that's
a
good,
a
good
point
that
you
bring
up
henrik.
C
It's
an
excellent
way
of
developing
software.
I
mean
I've
been
yeah.
I've
been
a
linux
user.
Since
the
mid,
mid
90s,
I
haven't
seen
how
that
community
and
that
software
has
evolved.
You
know
I'm
a
big
believer
in
open
source
and
it's
really
good
to
get
into
it
and
see.
You
know
how
how
much
energy
and
how
positive
you
know
that
the
whole
management
chain
is
about
open
source,
and
you
know
we
don't
monetize
it.
We
do
it
like.
I
said
to
build,
to
build
a
good
product
in
order
to
work
with
the
community.
A
B
Cool
yeah
and
and
as
far
as
you
guys,
using
argos
cd
or
like
so
like
you
know
it's
it's
it's
advantageous
right
to
software
development.
You
guys
have
argo
city,
you
guys
have
all
these
internal
users.
Can
you
I
know
henrik,
you
talk
about
you,
you,
you
may
have
a
few
a
few
slides
for
us,
but
can
you
talk
a
little
bit
about
how
argo
not
not
just
necessarily
argo
cd,
but
just
like
the
argo
project?
How
are
you
guys
are
using
that
software
into
it.
C
A
B
A
A
C
B
A
And
that
means
in
a
company
like
intuit,
you
must
have
a
lot
of
clusters,
and
so
you
need
some
way
to
manage
those
clusters
and
basically
we
have
a
journal
product
that
lets
you
create
clusters
and
then
the
product
will
take
care
of
those
of
maintenance
of
this
process.
Basically,
it
will
took
care
of
upgrades,
it
will
rotate
emis.
A
A
You
just
explain
what
you
want
to
do
and
you're
supposed
to
say
that
hey,
I'm
going
to
deploy
a
web
service,
I'm
in
the
business
unit
abc
and
I'm
part
of
group
subgroup
of
that
unit,
something
something
and
you
will
get
a
namespace
which
has
a
meaningful,
predictable
name
in
the
right
cluster
and
so
for
end
users
for
developers.
It
looks
like
not
like
heroku
but
kind
of.
C
A
C
C
Yeah,
the
developer
portal
that
alex
mentioned
that
we
we're
going
to
click
click,
click,
the
click
to
start
something
in
it.
In
addition
to
the
name
spaces,
it
also,
you
know,
creates
a
jenkins
pipeline,
creates
a
folding.
Artifactory,
creates
three
repositories
in
in
git
and
basically
sets
up
your
whole
environment
and
it
deploys
it
example
service.
So
it's
super
easy
to
get
started
and
basically
and
it
links
in
jira
and
wavefront.
You
know
the
other
things
that
we're
using
so
so.
C
A
A
The
most
next
tool
is
argo
cd,
and
this
is
that
this
is
the
tool
to
troubleshoot
your
application
in
kubernetes
and
the
third
one
is
the
tool
that
manages
namespace
creation
and
cluster
creation
and
this
tool,
I
think
mostly
for
you
know,
for
the
platform
team-
and
you
know
if,
like
yeah,
I'm
pretty
sure
mostly
platform
team
uses
it
to
manage.
I
think
around
four,
almost
like
300
to
400
clusters
into
it,
yeah
and
developers.
A
I
think
we
basically
want
developers
to
never
use
any
of
these
tools,
except
you
know
you,
you
create
the
project
once
in
the
dev
portal
and
hopefully
you'll
never
need
them
again.
But
if
something
doesn't
go
right
and
let's
say
your
application-
you
know
crashing
in
production,
then
they
will
go
to
argo
cd
and
try
to
troubleshoot
it
and
figure
out.
What's
going
on
and
as
I
mentioned.
C
A
C
Yeah,
I
can
just
share
some
share
some
numbers.
So
since
we
started
going
into
that
here,
what
you
know
what
scale
roughly
we're
we're
using
so
since,
since
every
every
application
basically
gets
its
own
name
space,
you
know
we're
looking
at
about
11
000
applications
and
about
as
many
name
spaces
into
it,
and
I
think
we're
probably
getting
closer
to
400
clusters
in
total.
Somewhat
some
of
the
production
ones
like
alex
said,
are,
are
getting
up
there.
C
So
so
one
thing
that
we
measure
that
we
look
at
is
the
the
release
velocity
they're
checking.
You
know
how
many
releases
the
engineers
do
per
per
week.
So
that's
a
measure
of
looking
at
how
fast
they
can
push
out
new
releases
not
and
using
that
as
not
necessarily
as
a
strict
goal
in
itself.
But
it's
you
know.
If
you
look
at
it.
C
Historically,
you
can
see
that
at
least
the
release
losses
going
up
and
use
that
as
a
comparative
comparative
and
comparative
number,
how
fast
we
can
move
and
and
adding
things
like
argo,
adding
things
like
rollouts
with
canary
analysis
and
things
like
that
can
help
us
increase
that
release
velocity.
So
that's
that's.
You
know
why
why
we,
we
think
that's
an
important
number
and
you
see
here-
cumulative
applications
are
like
in
three
years,
has
basically
gone
from
zero
up
to
eleven
thousand,
it's
accelerating
more
and
more
basically
yeah,
exactly
both
both
because
we're.
C
You
know
we're
on
boarding
more
more
developers,
but
the
developers
we
have
are
also
releasing
faster
because
we're
increasing
our
release
velocity.
So
we
have
more
more
developers,
we're
increasing
their
velocities.
So
it's
like,
like
a
double
double
whammy,
which
means
that
you
know
everything
is
growing
just
faster
and
faster.
B
Yeah,
you
know
what
I
what
I
really
like
about
so
far.
What
I
really
like
about
by
the
way
that
that's
really
impressive
right
going.
You
know
that
that
that
that
trajectory
going
up
into
the
right
really
really
rapidly.
But
what
I
really
like
about
that
slide
is.
It
is
something
that
I'm
going
to
show
internally
to
to
red
hatters
here,
because
our
some
of
our
some
of
our
consultants,
some
of
our
architects
solution,
architects,
were
like
look.
B
You
know,
because
you
know
we're
red
hat,
we're
a
reseller
right.
We
we,
you
know,
we
we
sell
software
there
we
get
customers,
as
our
our
field
would
ask
you
know,
like
our
customers
are
worried
about.
If
argo
can
scale-
and
it's
like,
I
think
that
slide
shows
that
it
absolutely
does
scale,
and
I
don't
think
your
you
know.
You
know
five
clusters
is
going
to
be
a
problem
for
article
cd,
so
I
love
that
slide.
B
I
love
I
love
seeing
how
that
how
you
quickly
onboarded
developers
and
engineers,
just
by
introducing
these
these,
these
tools
that
are
that
are
meant
to
get
the
platform
out
of
their
way.
So,
for
what
I'm
hearing
is
that
all
these
tools
that
are
being
built,
your
your
kubernetes
as
a
service
sort
of
thing,
argo
cd?
You
know
those
automation
that
you're
building
around
is
really
just
kind
of
just
removing
the
the
walls
of
getting
the
platform
out
of
the
way
of
of
developers.
A
Things,
but
I
think
that's
the
it's
like
a
primary
focus
of
pretty
much
every
release
like
nowadays
in
every
release
we
deploy.
You
know
we
multiply,
we
improve
things
and
I
think
we
still
and
we
yeah,
so
don't
worry
that
argo
cd
is
in
the
maintenance
mode,
not
getting
new
features.
It's
like
not
true
at
all.
Basically,
the
scalability
and
performance
is
maybe
the
most
important
topic
in
every
rbc
series.
B
Actually,
speaking
speaking
of
of
of
scale,
there's
actually
a
few
questions,
there's
two
questions
that
came
down
to
them
together.
I'm
gonna
ask
them
as
one
question
right
so
they're
asking
about
argos
cd,
h,
a
right
so
in
in
terms
of
h,
a
but
actually
more
more
specifically
how
many
instances
of
argo
cd
does
it
take
to
run
at
that
scale.
B
A
C
A
Limit
the
blast
radios.
Basically,
that
was
like
a
business
requirement.
You
know,
I
don't
know
who
vps
of
a
company
they
didn't
want.
They
wanted
to
make
sure
they
isolated
from
each
other
and-
and
I
think
it
makes
sense
and
that's
why
I
think
we
ended
up
having
36
argo
cd
instances
and
some
of
them
you
know
like
cluster,
some
of
them
bigger
some
of
them
smaller.
I
think
the
biggest
one
manages
close
to
3000
applications
yeah
and
that's
it's
like
one
of
the
biggest
instances
we
have
plus.
A
A
C
But
yeah,
so
I
think
about
like,
like
alex,
I
think,
about
the
largest
instance
different
compared
to
the
numbers
I
just
showed.
I
think
about
a
quarter
of
of
the
applications
are
on
that
on
that
instance,
in
terms
of
scale,
so
that's
fairly
fairly
sizeable
and
and
another
thing
in
terms
of
scale.
You
know
we
that
we
get
asked
about.
Quite
a
lot
is
that
when
you
talk
when
you
talk
about
github's,
not
necessarily
the
argument
cd
per
se,
is
you
know
the
number
of
repositories?
It's
such
a
pain.
C
You
know
you
get
too
many
repositories
again.
Managing
that
is
a
hassle.
Like
I
said
we
do.
We
give
developers
three
repositories
per
application,
so
I
mean
you
can
do
you
can
do
the
math
on
how
many
repositories
we
have?
I
mean
it's
a
it's
a
fairly
large
number
and
we
don't
really
have
any
any
main
headaches
or
concerns
about
managing
that,
because
it's
all
it's
all
automated
in
our
in
our
platform,
alex
is
closer
to
managing.
That
might
have
a
slightly
different
opinion.
A
Kind
of
takes
advantage
of
number
of
repositories,
because
it's
a
natural
way
for
us
to
kind
of
shard.
The
load
and
rbcj
has
problems
if
you
in
monorail-
and
that
was
challenge
for
us,
because
we
didn't
have
a
case
of
monoreport
and
then
recently
we
get
to
the
same.
You
know.
Basically,
we
now
have
it
and
we
think
in
in
last
two
releases.
We
had
to
rework
some
of
our
bcd
parts
to
supports
mono
report
case
and
just
to
clarify.
B
B
B
B
C
C
B
So
you
guys
had
you
know
this,
this
need
and
you
guys
are
building
all
these
tools,
so
you
know
how
does
that
relate
into?
So
let
me
ask
this
question
different
ways.
As
I
was
asking
the
question,
I
found
a
different
way
of
asking
it:
how
how
into
getups
is
intuit
or
was
it
getups?
Something
you're
like
oh
interesting
that
these
people
are
used.
You
know
the
users
now
are
using
argo
cd
for
for
get
ops
was
it?
A
From
from
from
the
beginning,
it's
like
kind
of
yeah,
we
realized
that.
I
think
that
the
reason
we
chose
it
is
because
we
didn't
want
to
build
things
that
you
get
for
free
from
github's.
You
know
like
we
didn't
want
to
build.
We
didn't
want
to
introduce
the
database,
this
history
of
changes,
because
it's
going
to
run
and
you
know,
paint
to
develop
so
we
kind
of
realized.
C
A
We
learned
from
basically
before
we
started
building
rbcd.
Yes,
we
looked
at
what
existed
already
and
I
think
the
biggest
kind
of
we
had
two
other
candidates.
One
was
spinnaker
and
one
was
flux,
so
spinnaker
is
not
githubs
and
we
kind
of
didn't.
I
mean
I
shouldn't
say
like
it,
but
basically
we
didn't
think
it's
the
best
fit,
because
spinnaker
was
kind
of
proposing
to
introduce
abstraction
on
top
of
kubernetes,
which
is
itself
abstraction.
We
didn't
like
that.
A
We
didn't
want
to
have
abstraction
on
top
of
abstraction
and
we
learned
that
it's
really
difficult
to
basically
kubernetes
is
changing
a
lot,
and
that
means
we
didn't
want
to
abstract
away
kubernetes
from
developers.
That
was
one
kind
of
thing
and
another
one.
So
we
really
like
approach
that
implemented
by
flux,
but
it
didn't.
We
could
not
just
go
ahead
and
use
it
because
flux
was
kind
of
it
didn't
have
this.
It
didn't
have
a
model
to
serve
a
lot
of
teams
without
asking
them
to
know
kubernetes
already.
B
A
C
A
And
it
kind
of
made
the
problem
trigger
now
with
kubernetes
without
any
other
tools.
You
just
have
cuba,
ctl
cup
detail,
commands,
give
and
apply,
and
it
will
do
exactly
the
same
work
except
it's
not
super
convenient
and
that
that's
what
we
realized
and
we
just
decided
that
it
makes
sense
to
build
an
application
that
does
cuba
ctl
applied
capacity
or
ctld
for
you,
but
makes
it.
You
know
convenient
and
easy
to
use
right
and
that's
what
pretty
much
I
ocd
it's
a.
C
B
Yeah,
it's
it's
and
also
what's
what's
what's
really
cool
about
argo,
just
just
also
is
you
guys
were
talking
about
the
ui.
I
think
you
guys
inadvertently
created
a
great
developer
ui
without
even
trying
with
argo
cd
right
is.
You
know
you
needed
a
way
to
visualize
it
and
it's
actually
a
good,
a
good
ui.
C
B
Kubernetes,
so
that's
that's
that's!
That
was
another.
I
I
actually
like
using
the
argo
cd
ui
versus
like
using
something
like
octane
or
even
even
the
openshift
ui
right,
I'll,
flip
back
and
forth,
because
I'm
like
oh,
I
want
to
see
a
representation
of
my
app,
not
necessarily
its
individual
components.
A
A
What
we're
thinking
about
aging
new
feature
is
that
if
we
already
have
to
collect
the
data
to
do
githubs-
and
we
just
can't
do
it
yeah
and
it's
worth
showing
it
because
it's
so
cheap,
we
just
need
to
build
ui
to
show
it.
If,
let's
say,
if
we
need
to
build
something
to
start
collecting
the
data,
then
maybe
no
and
one
example-
is
that,
for
example,
we
could
start
collecting
metrics
within.
A
B
Yeah
well
yeah,
it's
it's
because
argo
cd
for
the
most
part
is
stateless
right,
like
you
just
use
ncd
you
just
use
ncd,
essentially
on
the
back
end,
but
you
know
when
you
deploy
argo
cd,
it's
just
you
know,
redis
cache
and
then
the
controllers
really.
And
then
you
know,
because
the
idea
is
you
know
everything
should
be
stored
in
get
anyway.
B
C
There's
and
that's
something
that
I
know
that
a
lot
of
a
lot
of
users
who
talk
to
they
they
like
about
all
the
four
argo
projects
that
they're
they're
not
trying
to
be
everything.
You
know,
they're
they're,
building
blocks
and
you
can
take
in
argus
the
argo
rollouts
are
go,
workflows,
events
and
and
put
together,
use
them
individually,
put
them
together
and
build.
C
You
know
whatever
platform,
whatever
your
needs
happen
to
be
out
of
that,
but
no
we're
not
trying
to
combine
all
the
four
projects
into
one
monolith
or
like
alex,
had
tried
to
do
too
much
monitoring
and
like
just
trying
to
do.
You
know
what
what
what
makes
sense
without
getting
getting
too
too
big
and
bloated,
keeping
them
building
blocks.
B
B
Are
there
any
plans
for
any
other
modular
tasks,
for
example,
for
example
like
pipeline
abstracts
or
any
other
edge
use
cases
right
so
so
for,
for
example,
right
so
you
you
know,
sync
waves.
Was
there
because
you
know
stateful
applications
sometimes
just
need
an
order
right.
You
can't
just
apply
things
all
at
once,
so
are
there
any
other
like
edge
use
cases
that
you
guys
are
are
are
looking
at
in
order
to
incorporate
into
argo
city?
I.
C
A
We
think
that
more
or
less
we
official
complete
in
terms
of
syncing
applica
resources
within
applications,
but
we
keep
getting
questions
about.
How
do
you
orchestrate
thinking
of
multiple
applications
at
the
same
time?
What
if
you
have
if
such
a
big
application,
so
it
kind
of
consists
of
independent
blocks?
And
this
we
don't
have
a
good
answer.
We
come
up
with
a
kind
of
pattern,
so
you
can
create
arbor
city
applications
that
create
applications,
and
then
you
can
try
to
use
sync
waves
to
orchestrate.
A
Let's
say
you
have:
let's
say
you
need
to
create
the
exact
same
set
of
resources
in
in
each
and
every
cluster,
so
in
rbcd
world
you
will
have
to
create
application
per
cluster
and
that's
a
lot
of
manual
work
with
application
set.
You
can
create
a
single
resource
that
describe
what
kind
of
application
you
want
to
create
a
niche
and
every
cluster,
and
it
will
do
it
for
you,
and
I
guess
the
next
step
is
to
add
more
either
into
argo
cd
itself
itself
or
into
our
application
set.
A
Add
some
features
that
let
you
define
how
you
want
to
sync
all
these
applications.
You
might
split
them
into
waves.
You
might
say
I
want
to
sync
all
of
my
staging
applications.
First
then
wait
and
then
maybe
sync
all
production
applications,
but
do
some
kind
of
you
know
a
form
of
canary
deployment
of
your
changes?
And
you
can
you
know,
split
your
production
clusters
even
into
waves.
B
Like
yeah,
actually
I
was
one
of
those
voices
right,
so
I
know
that
our
engineers
worked
red
hat
engineers
worked
on
application
sets
and
like
the
first
thing
I
asked
is
like
it'd
be
really
cool.
If
I
could
do
waves
with
application
sets
so
treat
applications
as
almost
like
a
component
like
components
right
like
how
you
treat
objects
so.
A
B
App
argo
city,
app
application,
there's
others
there's
objects
that
the
application
sits
under
now.
I
almost
want
to
treat
the
application
the
same
way
as
I
would
like
a
deployment
right.
I
want
to
be
able
to.
You
know,
deploy
the
first
application
and
then
using
you
know,
application
sets
then
deploy
the
second
one
and
then
have
a
kind
of
like
a
wave
or
like
a
canary,
like
you
said
that
that's
that's,
really
cool!
That's
that's
something
again
like
you
release
something,
and
it's
like
all
these
people
have
all
these
ideas
like
well.
B
B
Really
cool
see
here,
so
someone
actually
asked
about
patching
deployment,
but
I'll
actually
replace
that
question.
With
my
question
that
alex
I
I
I
I
I
I
asked
this
question
right
right
before
he
went
live,
but
there
is
a
you
know:
applying
manifests
using
cube.
Ctl
there's
like
some
ramifications
about
just
using
apply
that
actually
people
don't
don't
know
about.
There
are
actually
some
weird
use
cases
that
happen
like
when
you
apply
versus
replace
versus.
So
can
you
kind
of
go
through
a
little
bit?
B
A
A
State
in
sync,
and
just
to
kind
of
clarify,
I
think
we
did
not
invent
freeway
div,
it's
it's
in
kubernetes
it's.
This
is
the
way
kubernetes
offer
developers
to
manage
resources,
and
the
idea
is
that
you
can
have
a
file.
It
doesn't
matter
where
in
git
or
just
on
your
laptop
and
that
file
has
a
yamaha
that
or
json
that
ex
you
know
it
kind
of
explains
what
you
want
to
have
in
the
cluster.
A
A
And
then
to
tomorrow,
some
developer
go
and
change
an
image.
For
example,
without
you
knowing
and
then
you
can
run
cubectldf
and
you
can
feed
the
file
stored
on
your
disk
and
basically,
what
will
happen
is
that
cube
ctl
will
try
to
compare
what
you
meant
to
have
last
time
what
you
meant
to
have
what
you
want
to
have
now
and
what
you
really
have,
and
it
will
show
you
it
will
catch
the
difference,
and
this
lets
you
catch.
For
example,
you
might
want
to
just
don't
specify
yeah,
I'm
trying
to
explain
why?
A
Is
it
so
complex?
Why
don't
just
you
just
compare
two
states,
so
there
are
edge
cases
like,
for
example.
Let's
say
you
don't
care
how
many
replica
sets
you
need
to
have
on
your
deployment
because
you
have
hpa
and
hpa,
manages
it
for
you.
So
in
this
case
you
can
simply
don't
specify
a
number
of
replicas
in
your
file
stored
in
git
and
that
led
kind
of
that
it.
You
know
it
will
basically
add
some
flexibility
here
and
that
that
particular
field
can
be
managed
imperatively.
A
B
C
A
A
B
C
B
B
When
you
run
argo
cd,
sync
it'll,
add
so
it'll
take
into
account
that
last
applied
right,
which
you
change,
the
the
container
image
to
something
else
and
then
you're
desired,
and
then
all
of
a
sudden
you'll
have
two
containers
in
the
deployment
and
it'll
always
be
out
of
sync.
Only
because
it
it
it
does
an
apply,
meaning
that
it,
it
it'll,
add
it'll
append
to
that
array
of
containers
versus
replacing
it
because
you've
applied
it
right
right.
B
So
it'll
it'll
take
that
into
account,
because
it's
an
apply
not
not
a
replace
that
our
argo
city
can
do
a
replace
by
the
way
you
just
have
to
be
careful
with
it,
because
if
you
have
stateful
applications
with
pvs
it'll
delete
the
pv
right
when
you
delete
the
resource.
So
you
have
to
be
a
little
a
little
careful,
but.
A
C
A
Get
the
gif
and
to
apply
changes
and
just
for
performance
reasons.
We
switched
to
a
library
which
is
part
of
keep
ctl,
so
kubernetes
community
factor
cube
ctl
and
they
converted
parts
into
a
library
and
that's
why
we
could
just
take
advantage
of
it.
We
import
code,
which
is
used
by
cube,
ctl
and
then
execute
that
code
to
make
it
quicker
so
yeah.
B
Which,
which
is
actually
part
of
the
reason
why
argo
city
is,
is
so
easy
to
use
it
stays
close.
It
stays
true
to
the
platform
right,
it
stays
really
close
to
the
kubernetes
platform.
So
we
have
like
about
10
minutes
left.
I
want
to
give
the
floor
to
you
know:
either
you
alex
or
henrik
whatever
you
guys
want
to
talk
about
for
the
last
10
minutes.
You
guys,
henrik.
I
don't
know
if
you
want
to
talk
about
roadmap.
You
want
to
talk
about.
B
C
Yeah,
so
so
on
the
roma
side,
you
know
where
we're
so
I
guess
the
two
two
parts
of
that
really.
This
just
want
to
work
with
the
community.
You
know,
like
our
partners,
like
red
hat
and
the
community,
to
to
build
out
features
for
for
for
for
the
argo
project,
and
I
think,
like
like
alex
said
in
in
in
some
ways,
we've
we've
reached
we're
covering
our
use
cases
for
the
most
part.
Now
that
we're
doing
it
into
it,
so
the
more
input
we
can
get
from
y'all
that
are
listening
to
this.
C
You
know
what
your
use
cases
are.
That
would
help
tremendously
in
you
know
shaping
the
future
roadmap
of
of
argo
cd
and
what
we're
doing
internally
now
also
is
we're
focusing
a
lot
also
on
argo
rollouts
and
that's
and
that's
kind
of
a
little
bit
of
a
missing
key
still
in
our
progressive
delivery
strategy
and
how
we
do
progressive
delivery
into
it.
C
As
I
said
before,
there's
like
an
extension
frame
where
it
has
been
worked
on
where
we
can
basically
pull
in
in
anything
and
show
it
in
cd
but
we're
using
robots
as
one
of
the
first
first
examples
of
that
and
just
getting
the
parts
together
without
breaking
that
building
block
strategy.
So
I
think
that's-
and
I
remember
we
did
the
user
survey.
C
A
few
months
ago,
external
user
fargo
cd.
There
was
a
lot
of
the
people
who
responded
are
looking
at
user.
Argo
rollout.
So
I
know
this.
So
that's
definitely
one
of
the
things
we're
looking
at.
You
know
how
we
bring
those
two
more
closely
together
internal.
We
also
have
some
other
projects
we're
working
on
that
are
still
being
validated,
but
they're
both
around
github's
nargo
city
and
on
the
workflows
side.
You
know
that
we're
looking
at
open
sourcing
here
later
this
year,
so
there's
a
lot
of
interesting
additional
stuff
coming
out
there.
C
B
A
I
won't
take
all
five
minutes,
but
I
just
wanted
to
use
a
chance
to
you
know
market
a
little
bit.
One
new
feature
that
I'm
passionate
about.
So,
as
we
mentioned,
argo
cd
kind
of
shines
when
you
need
to
you
know,
serve
needs
of
multiple
teams,
and
you
have
a
platform
team
that
manages
rcd
and
everyone
else
uses
it.
At
the
same
time,
we
heard
some
feedback
from
users
who
have
no,
you
know
they
they
have
no
such
need.
They
don't
need
to
show
needs
of
many
other
teams.
A
They
just
want
to
have
a
tool
that
manage
you,
know,
resources
in
the
cluster
and
they
basically
just
want
to
run
and
use
it.
And
for
these
users
some
features
of
argo
cd
like
the
x
sso
are
back.
They
view
it
as
a
you
know,
unnecessary
set
of
features
like
they
don't
like
them
like.
Why
do
you
have
to
configure
admin?
If
you
are
already
admin
link,
you
have
kubernetes
are
back
that
protect
your
cluster.
Why
do
you
have
to
set
up
one
more
protection
and.
C
A
A
Basically,
it
will
have
just
a
back-end
part
and
no
api
server,
and
that's
why
the
codename
of
the
feature
is
headless
rcd,
the
name
might
change,
we
don't
really
like
it,
but
yeah,
but
basically
you
can
run
headless
rvcd
and
we
just
took
all
existing
features
of
a
client,
the
web
ui
and
the
cli
part
and
kind
of
packaging
them
to
the
client-facing
cli.
So
you
basically
it's
the
same
experience,
but
you
don't
have
a
service
and
all
you
have
to
have
you
just
need
to
have
kubernetes
access.
A
Basically,
you
need
to
your
cup
cita
should
work
locally
on
your
laptop
and
you
can
run
argo
cd,
dashboard
command,
for
example,
and
it
starts
your
locally
or
you
can
just
execute
all
the
cli
commands
as
usual,
but
it
won't
try
to
talk
to
api
server.
It
will
talk
directly
to
kubernetes
and
I'm
really
excited
about
that
feature,
and
I
think
it
will
be
interesting
for
kubernetes
admins,
who.
C
C
You
know
to
obviously
add
into
it
we're
not
going
to
roll
out
5g,
but
you
know
it
would
be
really
interesting
to
hear
from
the
from
the
user
community
as
well,
and
if
you
have
anyone
that
has
iot
use
cases
or
or
teleco
use
cases
you
know
to
to
ping
us-
and
I
think
this
this
on
the
air
codes.
Headless
argo,
I
think,
has
some
really
good
promises
as
well.
In
some
opening
up
some
new
use
cases
that
we
haven't
been
able
to
solve
with
argo
before.
B
Yeah,
we'll
we'll
we'll
definitely
keep
we'll,
definitely
talk
about
a
new
name.
I
guess
eventually,
I
guess
we'll
talk
about
helmet,
helmetless,
argo.
I
don't
know
what
you
how
you
would
write
the
logo
the
same
same
argonaut,
but
without
the
helmet,
I'm
not
sure
cool
yeah,
so
we're
just
about
done
with
time.
I
am
I'm
gonna
talk
about
kubecon
a
little
bit
right,
so
kubecon
is
just
around
the
corner,
we're
actually
the
the
get
ops
working
group.
B
B
I
have
a
I
have
a
room
here
since
I'm
in
l.a,
but
if
you
can't
come
and
talk,
if
you
can't
come
to
la
it,
there
will
be
a
virtual
part
of
it
right.
So
don't
think
you
can't
submit
a
cfp.
I
put
the
cfp
in
the
chat
here
on
twitch,
so
go
ahead
and
check
that
out,
cfps
close
next,
not
this
sunday,
but
next
sunday,
so
get
those
get
those
in.
So
with
that.
B
C
And
also
have
a
few
seconds
I'd
also
like
to
plug,
there's
actually
going
to
be
an
argo
con
in
december
yep.
So
I
just
want
to
get
that
out
as
well.
This
will
be
a
single
day
event
in
san
francisco
on
december
8th.
So
the
program
is
still
see
if
cfp
is
open.
Program
is
still
being
put
together,
but
for
those
who
are
in
the
area
or
can
travel
for
it
for
a
single
day
event,
you
know
we'll
have
that
the
website
is
open,
the
registration
is
open.
B
B
Oh
okay,
all
right
all
right,
cool
cool,
so
yeah.
So
thank
you,
everyone
for
joining
again!
Thank
you,
henrik,
alexander,
and
actually
congratulations
bobby
by
the
way
our
intern
ran.
This
whole
show
for
us,
a
solo
so
he's
behind
the
scenes,
so
everyone
wave
at
bobby
and
yeah.
Thank
you.
You
can
see
us
out
bobby
thanks.
Thank
you.
Everyone.