►
From YouTube: What's Next for GitOps - Siamak Sadeghianfar (Red Hat) OpenShift Commons Gathering 2022
Description
OpenShift Commons Gathering 2022
What's Next in GitOps at Red Hat: Argo, Tekton, Operators, Pipelines and more
Speaker: Siamak Sadeghianfar (Red Hat)
Full Agenda:
https://commons.openshift.org/gatherings/OpenShift_Commons_Gathering_on_GitOps.html
Learn more at OpenShift Commons https://commons.openshift.org
A
But
I
think
one
of
the
things
that
was
really
important
too
is
we've
gone
through
sort
of
the
history.
What's
going
on
in
the
community
right
now,
we've
heard
from
an
end
user
using
it
in
production,
and
you
know
gotten
on
board
with
the
path.
But
what
is
next
in
get
ops,
and
you
know
we
do
a
lot
of
work
at
red
hat
out
in
the
open
and
stuff,
but
there's
a
bunch
of
stuff
going
on
too
internally.
B
I
know
that
you
heard
about
this
a
little
bit
from
christian
and
and
cornelia
as
well,
but
I
want
to
look
at
it
from
a
different
perspective
that
we
see
as
a
recurring
pattern
with
a
lot
of
our
customers
and
talk
a
little
bit
also
about.
Why,
specifically
now
what
is
now
a
githubs
con,
co-located
event
and
commands
and
session
today.
B
B
So,
let's
start
with
what
white,
githubs
and
and
cornelia
laid
out
the
really
well
stories
of
how
gidos
is
born
out
of
the
devops
movement
and
and
the
values
and
principles
of
there,
and
I'm
not
going
to
get
too
much
in
into
that
conversation
as
you've
seen.
What
I
want
to
point
out
is
that
adopting
devops
is
difficult
and
challenging.
A
lot
of
organizations
are
on
a
journey
to
adopt
devops,
like
the
numbers
that
you
hear
from
analysts
are
around
60
70
percent
of
organization
at
the
interview
are
on
that
journey.
B
However,
one
aspect
of
that
difficulty
comes
from
obviously
the
cultural
perspective
and
dealing
with
people
and
shift
the
mindset.
The
other
aspect,
which
is
expected
to
be
more
straightforward
but
in
practice
has
has
proven
to
be
quite
challenging,
is
to
make
sense
of
all
the
principles
and
practices
that
exist
in
devops.
B
What
happens
is
that
most
teams,
most
organizations
start
with
continuous
integration,
which
is
kind
of
a
low
hanging
fruit
to
automate
building
the
application
and
releasing
applications,
some
of
the
aspects
of
of
building
and
delivering
application,
and
from
that
point
on,
it
becomes
quite
difficult
to
navigate
this
space
and
figure
out
what
should
be
done
next,
where
else
they
need
to
go,
and
this
is
an
area
that
we
see
some
of
the
teams.
A
lot
of
the
teams
start
to
stagnate.
B
They
they
couldn't
get
stuck
beyond
that,
and
it's
not
clear
how
to
proceed
from
there
and
an
observation
of
the
situation
is
also
when
you
look
at
100
different
teams
adopting
devops
practices,
even
though
the
practices
are
the
same,
the
values
are
the
same.
You
probably
see
about
100
different
ways
that
devops
is
implemented,
so
that
that
brings
a
lot
of
flexibility
to
the
teams
to
find
their
own
path,
but
also
puts
a
lot
of
responsibility
on
those
teams
to
find
their
own
path.
A
lot
of
teams
are
much
more.
B
They
would
have
much
more
success
if
there
is
a
prescription
to
start
with
and
and
find
their
path.
Beyond
that
point
than
maturity
increases,
so
that's
one
aspect
of
devops
that
has
been
challenging
for
a
lot
of
the
practitioners,
and
another
aspect
is
that
we
should
see
a
shift
of
focus
from
continuous
integration
to
continuous
delivery.
B
A
cd
is
really
referring
to
that
entirety
of
the
process,
regardless
of
human,
continuous
delivery
or
continuous
deployment
in
practice
a
lot
more
over
the
last
year,
we
see
cds
used
very
often
to
refer
just
to
that
deployment
to
the
actual
delivery
of
of
the
things
of
the
software,
not
to
that
entirety
of
process.
As
a
consequence
of
this,
a
lot
of
the
solutions
out
there
a
lot
of
projects
within
the
open
source
or
commercial
solutions
coming
out.
B
We
have
already
defined
what
git
ops
is
I'm
not
going
to
get
too
much
into
that,
but
it
is
truly
a
blueprint,
a
concrete
way
of
proceeding
with
with
devops
adoption,
with
implementing
some
of
the
practices
that
are
already
familiar
for.
Many
organizations
really
build
on
the
infrastructure
as
code
principle
and
having
version
control
for
all
artifacts
and
and
configs,
and
everything
that
is
involved
in
application
delivery.
So
a
lot
of
those
aspects
are
known:
they're,
just
not
put
together
in
this
particular
composition.
B
So
that
are
extremely
prescriptive
in
the
way
that
you
need
to
proceed
and
what
how
you
should
organize
your
application
delivery
to
adhere
to
to
the
githubs
principles
and
and
be
able
to
get
the
benefits
that
githubs
provide.
So
we
see
githubs
as
really
one
particular
blueprint
of
how
devops
implementation,
especially
specifically
from
the
process
and
technology
perspective,
looks
like
it
doesn't
do
much,
unfortunately,
for
the
cultural
aspect.
It
is
a
change
of
mindset,
but
those
challenges
of
devops
still
remain.
B
B
Why
am
I
talking
about
git
ops
to
you
today
and
all
these
events
are
happening
this
year,
because,
if
you
think
about
it,
git
ups
is
as
even
as
as
the
phrasing
of
githubs
is
nothing
new
v
work
takes
all
the
credit,
obviously
for
recording
the
award
and
making
and
evangelizing
the
concepts
of
give
ups
and
the
git
workflow
around
it.
However,
this
happened
about
five
years
ago
right.
So
what
what
is
the
deal
with
your
hearing
about
this
now
and
we
haven't
had
so
many
things
happening
around
git.
A
B
Workflow
so,
where
that
comes
from
cornelia
talked
about
this,
a
little
bit
containers
had
to
do
a
lot
with
it
and
more
than
that,
it's
really
kubernetes.
That
has
changed
the
type
of
infrastructure
that
that
teams,
an
organization
deal
with,
and
a
lot
of
that
is
attributed
to
kubernetes,
but
from
a
certain
and
particular
aspect.
B
So
if,
if
you
look
at
the
latest
stats
that
are
coming
out
this,
what
you're
seeing
on
the
slide
is
coming
from
the
cncs
survey
that
was
conducted
2020,
so
it's
already
quite
old
and
and
stale,
but
it
does
make
a
point
that
I
want
to
highlight
here
is
that
83
percent
of
organization
that
were
surveyed
at
that
point
were
running
kubernetes
in
production.
The.
A
B
That
had
kubernetes
in-house
was
close
to
93
or
95.
If
I
recall
correctly,
these
are
the
ones
that
running
it
in
production
and
this
number
more
than
50
around
50
had
more
than
five
clusters.
So
what
they
recognized
in
that
survey
about
two
years
ago
is
that
the
number
of
teams
organization
that
are
running
two
to
five
clusters
in-house
is
decreasing
year
over
year
and
number
that
are
running
above
six
clusters
and
10
clusters
and
50
clusters.
That's
that's
increasing,
and
what?
What
does
that
have
to
do
with
anything?
Why?
B
Why
is
that
code
related
to
github?
So
the
reason
for
that
is
really
the
more
clusters
customers
are
dealing
with
teams.
Our
organizations
are
dealing
with.
There
is
more
complexity
in
doing
pretty
much
anything
that
has
to
do
with
operations.
The
operations
of
the
platforms
becomes
more
difficult,
kubernetes
itself.
If
you're
dealing
with
50
clusters,
you're
an
itr
option
or
platform
ops
team
dealing
with
100
clusters,
how
do
you
make
sure
that
the
network
policies
across
all
these
clusters
are
consistent
or
authentication?
B
B
How
do
you
guarantee
that
the
configurations
are
in
seeing
the
deployments
and
are
done
in
a
predictable
manner
and
guarantee
the
deployment
succeeds
right?
So
if
we
compare
this
to
that
traditional
way
of
ci
that
I
mentioned
as
a
low-hanging
fruit,
people
put
that
in
their
ci,
you
have
a
loop
in
that
ci
deploys
to
20
clusters,
then
something
goes
wrong
and
and
you're
left
on
your
own.
The
ci
is
not.
B
For
you,
it
means
something
is,
is
failing
after
a
successful
deployment.
So
with
increasing
the
number
of
clusters,
there
are
a
lot
of
complexity
that
comes
with
running
a
lot
of
operation.
There
are
a
lot
of
simplicity
coming
along
the
way
as
well,
because
managing
smaller
clusters
are
much
easier
than
managing
larger
clusters.
So
there
is
a
reason
that
organizations
are
going
toward
adopting
and
having
a
large
number
of
clusters.
B
One
aspect
of
it
has
to
do
with
the
maturity
of
kubernetes
adoption
organizations
that
are
adopting
kubernetes,
so
they're
just
spreading
within
the
organization.
More
and
more
teams
are
on
board
on
this
platform.
More
and
more
applications
are
on
board
on
kubernetes
platforms.
On
the
other
hand,
it's
it's
easier
for
them
to.
If
you
want
to,
for
example,
upgrade
the
nodes
of
kubernetes
is
much
easier
if
that
cluster
has
10
nodes
instead
of
200
nodes.
B
So
there
are
benefits
of
having
a
large
number
of
small
clusters,
but
there
are
complexities
that
get
increased
in
in
how
you
manage
those
clusters
from
a
configuration
perspective
and
how
you
deliver
applications
to
it.
So
that's
something
that
we
see
as
one
of
the
really
main
drivers
that
is
pushing
a
lot
of
interest
toward
github's
as
a
workflow,
especially
to
start
with,
as
a
workflow
for
managing
cluster
configuration
itself
and
and
after
that
for
deployment
of
application
application
delivery.
B
What
we're
seeing
in
reality
that
most
organizations
are
fierce
and
primarily
interested
in
it
for
as
a
means
of
configuration
management
of
clusters
and
and
delivering
changes
to
those
clusters
and
applications
and
workflows
being
only
one
one
of
the
aspects
of
what
they
are
managing
on
on
those
classes.
So
that's
really
what
we
attribute
the
huge
growth
of
interest
in
get
ups
and
and
both
in
the
community
more
projects
coming
along
more
people
getting
involved
in
the
existing
projects.
Argo,
cd
and
fox,
as
as
the
main
githubs
related
projects
and
cncf,
are
mentioned.
B
So
what
is
next
now
for
for
for
githubs
with
that
in
mind
that,
with
that
level
of
interest
that
exists,
where
are
we
going
beyond
that
simple
concepts
of?
So
everything
is
declarative?
You
put
stuff
in
git
repo,
they
are
delivered
and
synced
to
to
a
number
of
clusters
and
reconcile
to
bring
those
clusters
to
the
state
that
you
have
that
that
that's
quite
like
the
starting
step
really,
but
where
does
it
go
beyond
that?
So
I
have
included
takedown
here
as
well.
B
Openshift
pipeline
openshift,
git
ups
are
the
name
of
the
the
product
offerings
at
red
hat.
Then
you
can
replace
them.
In
my
conversation,
my
my
talk
with
takedown
and
argo
cd
based
on
takedown
and
argo
cd
and
take
down
argosy
as
a
cis
core
of
ci
cd
solution
that
we
see
across
many
organizations
being
adopted
and
what
they
enable
across
all
these
organizations
is
most
and
for
most
configuration
management,
primary
configuration
management
for
both
applications
and
the
clusters.
B
How
you
can
declaratively
roll
out
changes
to
to
these
clusters
to
this
infrastructure
that
they
have
that
that
relates
to
kubernetes-
and
I
do
point
out
kubernetes
a
lot
here
because,
like
it
came
up
on
on
on
chat,
git
ops
does
exist
outside
the
kubernetes
sphere
as
well.
However,
being
declarative
is
is
a
requirement
for
being
able
to
run
github's
processes.
Otherwise
you
will
be
shoehorning.
B
A
lot
of
the
principles
that
edops
has
and
kubernetes
is
is
the
platform
that
brings
that
to
a
lot
of
type
of
infrastructure
that
that
customers
run
and
teams
it
up
so
because
of
it
we
very
often
talk
about
it
within
the
in
the
context
of
kubernetes,
but
it's
absolutely
not
limited
to
that
application.
Delivery
is
the
other
aspect.
B
But
where
does
it
go
from
there?
What
we
are
seeing
is
that
a
lot
of
other
use
cases
when
customers
reach
to
this
level
of
maturity.
There
are
a
lot
of
other
use
cases
that
becomes
within
sight
for
for
these
customers,
and
I
have
added
a
bunch
of
other
products
from
specifically
from
red
hat,
that
I'm
familiar
with
like
red
hat,
advanced
cluster
security,
red
hat,
advanced
cluster
management
and
ansible.
But
what
I
mean
here
is
mostly
the
capability
that
this
per
these
products
provide
and
any
other
product
or
project
that
have
similar
capability.
B
They
can
fulfill
the
same
role
within
the
githubs
workflow.
For
example.
Fleet
management
is,
as
as
teams
and
organization
have
more
and
more
clusters.
It's
not
just
about
how
I
configure
this
cluster
or
how
I
make
sure
that
the
network
policy
that
all
this
cluster,
having
seen
is
also
about
how
I
can
declaratively
provision
new
clusters.
I
need
10
new
clusters
with
this
spec.
How
can
I
have
that
declared
in
a
git
repo
and
provision
those
clusters
from
that
git
repo?
B
B
Then
we
have
use
cases
that
is
like
similar
to
fluid
management,
but
that's
really
a
larger
scale,
because
you
have
age
devices
that
are
really
tiny,
very
small
compute
and
they
need
to
have
the
ability
to
bring
themselves
up
to
a
certain
baseline
of
configuration
and
workloads
when
they
have
connectivity,
so
that
becomes
within
the
reach
of
utas
workflows,
combined
with
some
of
the
tools
that
I
mentioned
supply
chain
security
is
extremely
hot
topic.
This
year
I
think
you'll.
You
will
hear
a
lot
about
it
across
the
various
journals
and
conferences.
B
Email,
ops,
is,
is
another
aspect:
it's
not
too
different,
really
for
how
how
how
his
approach
for
how
git
ops
is
approached
for
regular
application.
But
there
is
huge
use
cases.
We
see
it's
growing
with
a
lot
of
our
customers
for
some
of
the
mlaps
offering
that
redhead
has
infrastructure
as
what
we
talked
about,
but
another
aspect
that
this
is
expanding
to
and
we
see
we
get
questions
a
lot
about
and
expanded
on
is
policy
escort
and
compliances
code,
so
the
same
way
that
configuration
and
infrastructure
should
be
declared
as
code.
B
We
see
the
desire
a
very
strong
desire
from
customers
to
be
able
to
describe
their
policies.
How
this
platform,
from
perhaps
should
be,
should
look
like
not
just
from
a
configuration
perspective,
but
also
from
a
prevention
and
remediation
perspective.
What
is
not
allowed
to
be
done
on
these
platforms
by
the
developers
or
by
their
project
admins
and
to
be
able
to
describe
those
also
declaratively
in
a
syntax
that
is,
that
can
go
into
a
git
repose
and
deliver
to
those
clusters
controlled
and
applied
to
those
clusters
through
the
githubs
workflow
using
argo
cd.
B
So
what
is
specifically
next
for
openshift
github?
I
talked
about
a
space
I
wanted
to
mention
a
little
bit
of
what's
next
in
openshift,
git,
ops
and
argo
cd
by
extension,
like
I
mentioned,
our
openshift
get
ups
is
is
based
on
argo
cd.
Our
cd
is
the
core
of
it.
We
are
heavily
invested
in
our
cd
community.
B
All
our
engineers
work
within
within
the
argo
city,
community
and
drive
the
use
cases
that
we
see
in
the
enterprise
within
within
that
community,
multi-tenancy
and
self-service
is,
is
an
important
area
for
us.
This
is
something
that
we
hear
from
a
lot
of
our
customers,
that
are,
that
that
are
really
after
providing
internal
platform
for
the
application
teams,
enabling
application
developers,
teams
to
through
cell
service
mechanism,
be
able
to
to
implement
the
github
workflow
for
delivering
their
application.
B
This
is
something
that
you
can
see
in
in
different
type
of
devops
related
reports
that
come
out.
What
comes
to
my
mind
is
the
the
famous
state
of
devops
report
from
puppet,
and
I
think
it
was
last
year
in
2021
that
that
was
one
of
the
aspects
of
one
of
the
trends
that
it
picked
up
as
bill.
One
of
the
ingredients
of
success
in
devops
adoption
was
the
platform
approach
within
the
organization,
a
platform
approach.
It
is
not
something
that
you
go
by.
We
talk
about
openshift
platform,
a
lot
at
red
hat.
B
B
B
Then
this
is
something
that
is
already
possible
and
highly
used
within
argo
cd
in
order
to
control
when
you're
looking
at
a
git
repo
in
what
order
those
resources
or
those
manifest
should
be
applied
to
the
clusters
that
are
being
applied.
Application
dependent
dependency
talks
at
one
level
higher
than
that
how
in
which
order
different
git
reports
should
get
applied
to
to
a
cluster,
to
respect
the
dependency
that
those
components
might
have
between
each
other
advanced
helm,
use
cases
in
another
area.
Helm
is
an
important
component
of
application
packaging.
B
A
lot
of
our
cd
user
base
use
hill
for
for
deploying
their
application.
There
are
improvements
within
the
githubs
workflow
that
would
like
to
to
exist.
Example
of
that,
for
example,
is
the
separation
of
a
hand
chart
from
the
values
that
should
be
applied
to
to
that
chart
before
deployment
to
cluster,
to
be
able
to
have
version
them
separately,
life
cycle
them
separately
in
different
gauge
repositories,
and
there
are
other
aspects
of
helm
that
we
are
looking
into.
B
Making
that
experience
much
better
than
it
is
today
and
last
but
not
least,
is
progressive
delivery
that
that
that
relates
mostly
to
openshift
get-offs,
already
exists
within
the
argo
community.
As
argo
rollout,
progressive
delivery
points
out,
enabling
more
advanced
deployment
scenarios
that
you,
perhaps
when
you
want
to
roll
out
a
deployment
from
a
git
tree
or
to
a
cluster
or
to
your
fleet
of
clusters,
you
want
to
perhaps
only
roll
it
up
to
five
percent
of
your
fleet
and
monitor
a
certain
metrics
as
the
success
factor
of
this
deployment.