►
From YouTube: OpenShift Coffee Break KubeCon EU Edition: GitOps
Description
Get your espresso ready for the EMEA OpenShift Coffee Break together with Natale Vinto, Tero Ahonen, and Jaafar Chraibi. In this special edition for KubeCon EU we will talk about all GitOps with Siamak Sadeghianfar, PM for OpenShift GitOps and Pipelines at Red Hat.
A
C
Thanks,
that's
all
I
have
a
coffee
here
as
well
good
morning
to
to
you
as
well
and
appreciate
having
me
here,
I'm
like,
I
said,
I'm
a
pm
for
like
an
open
shift
team
at
red
hat.
I
look
after
cicd
areas,
github's
one
of
them
and
really
happy
to
be
in
the
like
one
of
the
starting
shows
of
of
kubecon,
exciting
it's
very
different
kubecon
than
would
be
used
to,
but
nevertheless
exciting.
A
Yeah
yeah
yeah
so
and
on
today
we
have
a
full
agenda
here
of
openshift
tv.
We're
kind
of
kicking
off
this
full
agenda.
Let's
say
get
ups
today
is
really
the
the
main
topic,
and
we
will
have
this
discussion
today
this
morning
and
then
we
will
have
an
office.
Our
github's
office
hour
in
the
afternoon
set
afternoon
always
with
ciamac
and
jafar,
and
then
we
will
have
another
office
hours
for
openshift,
but
we
will,
during
the
show
we
will
give
you
also
details
about
it.
A
C
But
it's
really
interesting
to
see
that
the
wider,
like
landscape
of
kubernetes
user
base
and
community,
also
reflects
that
that
there
are,
there
is
huge
amount
of
interest
in
githubs,
not
as
as
something
that
is
hype
really
because
it
has
been
it's
nothing
new.
It
has
been
around
for
a
long
time,
but
a
lot
of
like
minds
at
different
teams.
C
So
we
were
like
three
to
be
part
of
that
and
see
really
all
this
excitement
about
coming
up
with
best
practices
sharing
knowledge
about,
like
everyone
is
addressing
more
or
less
the
same
problems
with
with
git
ops,
to
be
able
to
share
this
knowledge
and
culmination
of
that
in
in
a
conference
at
cubecon.
I
think
that
was
for
me
personally
that
was
really
exciting
to
see
and
the
level
of
participation
was
beyond
my
expectations.
A
C
That's
correct
yeah,
so
the
background
is
that
we
work
is
really
the
the
faults
behind
like
coining
the
word
get
up,
so
they
have.
They
have
done
an
amazing
work
and
making
git
ups
a
known
practice
under
a
particular
term.
The
practices
in
githubs,
as
you
can
imagine
like
like
most
things
in
in
software
and
and
item
infrastructure,
are
not
completely.
D
C
I
see
them
as
one
of
the
really
influential
actors
in
the
get
out
of
the
space
and
red
hat,
like
we
about
seven
eight
months
ago,
started
investing
heavily
in
our
cd
because
it
solved
the
get
ups
problem
like
really
well
for
a
lot
of
our
customers
on
kubernetes,
and
so
it
felt
like
a
really
great
chemistry
between
the
two
vendors
to
come
together
and
spend
time
to
organize
this
conference.
It's
not
really
for
for
us.
C
This
is
for
the
larger
community,
but
at
least
take
the
initiative
to
to
organize
this,
and
that
was
that
was
really
a
fantastic
journey.
We
have.
We
have
had
discussions
with
reports
before
when
it
was
the
first
time
that
we,
together
coordinating
events,
and
I'm
really
pleased
with
the
outcome
and
hoping
that
more
of
this
more
of
this.
A
C
C
Github's
working
group
and
the
the
reason
that
get
us
working
group
was
formed
is
to
create
a
vendor
neutral
community
to
discuss,
share
ideas
and
come
up
with,
I
wanted,
to
always
say
to
say
best
practices,
but
rather
like
guidelines
of
how
these
practices
could
be
used
where
they
fit
how
they
need
to
change
so
that
they
can
apply
to
a
wide
array
of
use
cases
that
different
organization
and
different
teams
have.
So
we
without
that,
like
even
before
you
know,
working
group,
you
could
see.
D
C
A
lot
of
vendors
talk
about
git
ups
and
github's
practices,
but
what
was
missing
is
that
the
discussion
very
quickly
gets
focused
on
a
particular
technology
that
one
vendor
has.
So
you
could
see
this
in
red
hat
as
well.
We've
worked
in
code
fresh
in
others
as
well
that
when,
when
we
talk
about
github,
it's
it's
a
particular
perhaps
flavor
of
it.
C
That
is
a
little
more
adjusted
to
the
the
products
that
red
hat
offers
or
the
products
of
universe
offers
and-
and
that
is
like
useful
for
users
of
that
product,
but
perhaps
not
as
much
accessible.
If
you're
using
different
type
of
products,
then
there
are
a
lot
of
different
kubernetes
flavors,
also
out
there,
and
there
are
nuances
there.
C
So
the
idea
was
to
form
this
as
as
a
place
that
we
talk
about
this
practices,
regardless
of
what
technology
is
is
being
used,
and
when
this
idea
was
raised,
we
saw
huge
interest
from
a
lot
of
vendors
that
have
been
active
within
the
cica
hit
office
space
and
a
lot
of
names
like
you
meet
of
the
forum
that
that
that
that
we
took
as
a
like
great
sign
that
there
is
like.
Sometimes
when
new
concept,
new
technologies
or
new
movements
become
popular.
You
see,
vendors
sometimes
become
very
protective.
C
You
could
see
that
in
the
beginning
days
of
kubernetes,
as
well
with
kubernetes,
was
one
container
platform
or
container
orchestration,
among
others,
and
every
every
vendor
was
trying
to
push
that
forward
and
make
that
the
best
for
all
the
use
cases,
but
eventually
out
of
merits
of
kubernetes.
That
became
the
de
facto
right,
not
not
because
everyone
in
the
beginning
agreed
when
it
comes
to
they
get
us
working
group.
C
It
was
like
really
pleasant
to
see
that
that
that
territory
seeking
is
not
happening,
and
everyone
is
on
board
to
come
up
with
like
collaborating
and
putting
their
own
like
individual
interests
inside
and
collaborate
on
practices.
That
would
benefit
everyone
and
every
organization
that
would
be
a
practitioner
of
git
ops,.
C
Initiatives
are,
are
being
bored,
one
of
them
is
that
was
announced
actually
at
the
git
ops
candidates
bill
is
the
open
githubs
project,
which
is
a
it's
a
sandbox
project
in
cncf,
and
the
aim
of
that
is
to
come
up
with
the
principles
of
github,
so
we
have
a
common
way
of
talking
about
it:
common
set
of
practices.
We
conceptually
know
what
git
ops
is
and
all
of
us
more
less
think
about
the
same,
with
their
nuances
that
that
are
different.
For
example,.
C
Some
customers,
when
they
say
git
ops,
it
is
they're
almost
religious
about
it-
that
every
change
in
a
git
repository
needs
to
automatically
go
into
the
the
production.
So
as
soon
as
it
doesn't
get
automatic
gets
deflated,
and-
and
if
you,
if
you
don't
have
that,
then
they
might
like
say
that
this
is
you're
not
really
doing
git
apps.
This
is
there.
Is
that
breakage
there
that
git
is
not
in
sync
with
your
production
environment
right
there
are
customers
that
are
that
this
would
be
extremely
scary
for
them
that,
once
you
have
something.
D
C
D
C
Regulation
or
other
aspects
right,
so
there
are
good
reasons
for
that,
but
even
like
that,
that
that
could
be
that
polarizing
that
are
we
doing
githubs
or
not
doing
githubs,
and
you
know
we're
all
technologies.
So,
although
in
the
grand
scheme
of
work
and
application
delivery,
maybe
this
this
is
not
that
significant,
but
it
it
does
become
a
polarizing
issue
for
a
lot
of
us
and
the
discussions.
C
C
This
is
how
this
is
what
you
follow
to
to
get
benefits
of
githubs
if
you're
a
vendor,
if
you're
building
solutions
tooling,
if
you're
a
community
project
building
things
around
githubs.
These
are
the
areas
to
focus
on
these.
Are
these?
Are
the
challenges
to
address
for
the
user
for
the
organization
it
often
get
up?
So
I'm
really
like
excited
about
about
a
working
group
and
the
work
that
is
coming
out
of
it,
and
this
has
been
such
a
short
time
like
really
since
it
was
formed.
C
A
And
what
what
else
would
do
through
this
working
group
wow?
It's
awesome.
First,
the
collaboration
across
vendors,
as
you
say,
the
it's,
not
a
competition,
it's
a
collaboration
in
the
industry
and
this
brings
the
open
source
driving
through
the
open
source.
This
process,
kitops,
is
also
pro
so
a
question
that
I
have
because,
as
you
mentioned
there,
there
is.
That
can
be
some
ambiguity.
So
what?
How
can
we
position
gear
ups
inside
the
devops
methodology
and
how
githubs
talk
with
the
cicd
part
or
is
kitops
part
of
the
ci
cd?
C
Sure,
so
that's
that's.
Definitely
how
I
see
it.
At
least
that
devops
is
really
that
the
broader,
encompassing
movements
talking
about
collaboration
like
devops
is
not
a
specific
thing.
It's
not.
There
is
no
checklist.
That
is
say
if
you're
doing
this
and
you
have
devops,
if
you
don't,
you
don't
have
devops.
I
think
it's
all
always
like
when
you
see
devops
teams
separate
from
the
rest
of
the
organization
or
these
types
of
like
approaches
to
to
devops.
C
You
usually
see
a
lot
of
reactions
to
it,
because
they're
also
that
encompassing
movement
with
huge
focus
on
the
people,
part
and
process
part
right,
so
people
and
culture
is,
is
really
the
main
ingredient.
That
makes
a
whole
difference
when,
when
an
organization
is
adopting
devos
practices,
and
then
there
is
the
process
and
workflow
of
doing
things,
then
there
are
technologies
supporting
this.
But
if,
if
you
don't
have
the
people
part,
if
you
don't
focus
on
on
the
culture
a
bit,
there
is
only
so
much
that
you
can
do
so.
Devops.
B
C
There
are,
there
are
not
only
these
two
groups,
there
are
many
many
teams
that
are
involved
when
a
piece
of
code
ends
up
at
a
customer
in
a
production
environment
and
it's
about
a
collaborative
way
of
working
with
with
all
of
those.
What
devops
was
not
is
or
is
not
is.
Is
that
descriptive,
concrete
way
of
achieving
that
right?
So
it's
about
values,
it's
about
culture,
change,
it's
about
process
change!
It
doesn't
give
you.
This
is
the
specific
way
you
do
devops
and
if
you're
not
doing
this
you're
not
doing
devops.
C
They
all
have
different
ways:
the
the
actual
workflows
and
the
ways
and
organization
structure
all
are
a
lot
of
them
are
unique
to
themselves,
but
they
realize
the
values
of
devops.
So
that's
how
I
do
define
devops
git
ops
is
a
concrete
way
for
the
process,
part
of
devops,
okay,
so
git
ups.
If
the
three
areas
of
devops
is
that
the
people
and
culture
is
the
process,
the
technology
github
doesn't
do
anything
for
it
doesn't
do
much
really
about
the
culture.
Get
up,
doesn't
change
the
organization's
structure.
C
So
that's
so
that's
the
way,
we're
different
it's
one
of
the
ways
that
you
realize
the
process,
part
of
devops
and
it
is
related
to
cic,
like
you
mentioned
so
continuous
integration,
continuous
deployment,
continuous
delivery.
Those
were
all
like
practices
advocated
by
devops
with
them
really
under
the
automation
umbrella,
so
that,
like
one
of
the
practices
of
devops,
that
you
want
to
automate
delivery
of
application
infrastructure
to
to
a
great
extent
and
ci
and
cd
are
one
way
of
like
performing
those
kind
of
automation.
C
A
D
D
A
But
you
are,
you
are
a
great
developer,
so
I
would
like
to
know
so
from
you.
What
do
you
think
about
the
impact
of
this
key
tops
technology
and
approach
through
with
that
can
be
done
with
openshift
to
the
customers
that
will
adopt
this?
This
is
not
only
the
technology
like
cmx
say
it's
also
a
methodology
and
it's
part
of
devops.
So
what
do
you
think
about
it?.
B
We
have
seen
these
different
adoptions.
Like
some,
let's
say
some:
some
companies
are
still
using
vms.
They
are
still
in
adoption
of
containers
and
then,
at
the
same
time
they
lived
through
the
devops
hype
and
now,
like
cmx
said,
there
is
no
hype
anymore.
It's
just
it's.
Just
there
same
happened
with
scrum,
no
one
mentions
scrum
masters
or
scrum
anymore.
It's
just
there
in
the
in
the
standard
way
of
working,
but
I
totally
agree.
B
One
hundred
percent
with
you'd
see
a
mac
that
devops
is
a
cultural
way
and
githubs
is
a
way
of
doing,
and
I
think
that
it
is
easier
for
customers
to
adapt
git
ups
because
they
can
see
the
value.
It
is
something
concrete.
I
have
said
to
customers
that,
because
they
ask
about
what
what
is
this
kid
ops?
How
do
I
do?
How
do
I?
How
can
I
do
it
or
what
is
there
for
me
and
how
do
I
need
to
have
tooling
what
is
the
best
tool?
B
I
said
that
easiest
way
just
put
your
code
to
kit
and
run
it
through
kit.
That's
the
simpler
way
of
key-ups
it
you
don't
have
to
have
automation
like
cmx
said
that
it
is
scary
that
every
commit
every
boost
goes
to
production.
I
would
say
that
not
many
companies
are
ready
for
that.
Not
many
companies
are
ready
for
deploying
once
a
day.
B
Not
many
companies
are
ready
for
deploying
once
a
month,
so
having
kind
of
github's
way
that
there
is
this
hard,
I
would
say
religion
same
as
there
was
in
scrum
and
devops
that
this
is
the
only
way
of
doing
some
use.
Git
flow,
some
some
use
different
ways
of
using
the
git
and,
like
you
can
start
with
really
small
steps
like
using
kit
as
the
single
source
of
truth,
and
it
can
be
easy
as
cube.
Ctl
apply,
minus
f,
that's
your
keydops.
B
The
keytopsy
automation
tool
is
that
developer
of
person,
but
that's
the
easiest
way,
and
that
is
kind
of
it
doesn't
have
to
be
automatic.
It
can
be
manual,
but
as
long
as
the
flow
is
correct,
then
it's
easier
to
get
from
there,
and
I
think
that
this
is
a
good
thing
that
it's
really
easy
to
adapt.
If
you
think
about
that.
B
Co,
cio
in
a
company
has
a
target
that
you
need
to
add
up
devops.
How
do
you
measure
that
you
have
been
out
of
the
devops?
You
can't
because
it's
a
way
of
working?
Never
every
company
has
its
own
definition
of
devops,
but
with
give
up
key
tops
it's
easier
because
you
can
more
strictly
define
the
targets
that
when
we
have
achieved
github's
way
of
doing
like
we
automate
deployments
or
we
run
everything
through
kit.
So
I
think
that
in
these
ways
the
world
is
ready.
From
the
tooling
point
of
view,
there
is
flux.
B
B
C
C
There
are
like
a
majority
of
customers
who
talk
to
teams
to
talk
to.
They
are
using
git.
I
I
wanted
to
say,
or
some
sort
of
version
control,
but
even
the
some
sort
of
version
control
is
like
gradually
diminishing
and
majority,
using
git
in
in
some
form
of
format.
If
it
doesn't
matter
what
they
are
doing,
if
they
are
creating,
if
they're,
using
terraform
for
provisioning
infrastructure
on
amazon
or,
if
they're,
using
ansible
or
doing
something
else,
whatever
they're
doing,
they
are
usually
putting
all
that
in
gets.
C
They
are
versioning
that
they
are
using
the
pull
request,
workflow
and-
and
this
is
about
the
operation
part
when
it
comes
to
the
active.
That's
the
entire
flow
is
really
what
has
been
used
for
ever,
so
that
makes
it
really
accessible
that
it's
not
about
really
shaking
your
organization
up
with
the
whole
new
sets
of
technologies
and
ways
of
working
but
you're
like
picking
things
that
people
have
been
doing
already
and
put
them
together
on
on
their
like
a
concise
practice
and
how
they
relate
to
each
other.
B
And
also
one
one
addition
to
that
is
that
when
the
good
benedict
like
started
to
get
traction,
the
only
thing
that
was
treated
as
code
was
the
actual
source
code
and
now
the
kubernetes
manifest.
Actually
people
see
those
also
as
a
source
code
and
like
cmak
said
everything
is
already
in
git.
The
way
how
they
are
just
deployed
may
be
are
different,
but
the
like
there
is
a
lot
of
jump
files
like
some.
Some
said
that
I
don't
know
who
it
was
that
devops
is.
A
So
maybe
we
can
talk
about
also
about
the
open
source
project
we
are
using
in
openshift
with
githubs,
which,
which
is
argo
ct
in
this
case.
There
is
a
controller
that
keep
everything
in
sync,
so
we
let's
say
we
were
kind
of
doing
that
manually,
putting
everything
in
skit
and
doing
a
cube,
ctl
apply
or
oc
apply.
A
Now
we
have
also
a
tool,
a
controller
that
help
doing
that,
and
maybe
we
can
also
introduce
that
I
was
looking
in
the
while
in
the
chat
with
some
people
in
the
chat
that
are
waking
up.
Hello,
sebi,
hello,
dario
dario
is
a
friend
which
is
having
also
a
talk
to
a
kubecon,
hello.
Everyone
there's
one
asking
about
dodge.
I
think
it's
another
thing,
but
I
don't
know,
let's
say
git
ups
and
crypto,
maybe
something
like
that,
but
yeah.
A
I
would
like
also
now
to
enter,
and
please
use
the
chat
to
do
any
question
about
keytops.
We
have
today
this
morning,
ciamac
so
catch
the
opportunity
to
ask
to
him
everything
about
guitops.
What
is
also
the
strategy.
I
would
like
to
hear
from
you
michael.
So
what
is
our
direction
in
open
shift
towards
gear
ups?
We
can,
of
course
we
we
introduced
and
we
anticipated
the
talk
about
argo
cd.
So
what
are
the?
What
is
the
strategy
of
git
ups?
And
I
know
there
is
a
kit
ops,
operatory
number
shift.
B
D
C
The
mode
of
operating,
kubernetes
and
and
delivering
application
on
it
is
that
github's,
like
fits
extremely
well
to
that,
to
that
environment
and
because
of
it
we
are
like
investing
heavily
in
in
github
specie
ics.
There
are
two
prominent
add-ons
on
openshift
that
support
this
way
of
working,
there's
openshift
pipelines
based
on
the
upstream
tickton
project,
and
there
is
openshift
git
ops
that
that
delivers
argo
cd
on
the
platform.
For
that
controller,
the
githubs
loop
that
that
you
were
discussing
and
takedown
is,
has
its
own.
Like
mary,
it's
a
ci
part.
C
I
mean
they
get
us.
We
don't
talk
about
ci
much,
it's
an
extremely
interesting
area
and
a
lot
of
solutions
out
there.
But
one
of
the
problems
we
had
seen
is
that
it's
difficult
to
to
really.
There
is
always
a
gap
between
the
pipelines
that
do
the
ci
for
your
application
and
the
kubernetes
environments,
and
then
takedown
focuses
on
really
building
on
top
of
kubernetes
constructs
and
you
define
your
pipelines
in
form
of
pods
and
config
mapping,
secrets
and
constructs
that
are
covered.
C
It
is
native,
so
make
it
really
simple:
to
have
ci
that
executes
decentralized
kubernetes
and
on
the
openshift
github,
so
you
have
argo
cd
that
focuses
on
using
that.
So,
even
though
we
say
cd,
I
think
this
is
also
a
change
that
has
recently
happened
that
cd
before,
like
four
years
five
years
ago,
within
devops
cd,
was
used
to
always
see
I
and
cd
were
used
together
to
refi
to
refer
to
the
entire
delivery
process.
More
recently,
when
we
talk
about
cd,
we
mean
the
deployment
phase.
C
How
do
you
roll
out
a
deployment
of
application?
After
it's
the
images,
the
application
is
released
through
the
ci
process.
How
do
you
roll
it
out
to
all
the
environments
that
it
needs
to
run
on?
So
that's
what,
because
focus
on
cd
and
openshift
git
ops
focuses
on
this
particular
use
case,
and
both
of
them
are
generally
available.
Now,
like
we
announced
it
at
gitobscon.
C
We're
extremely
excited
about
that
piece
as
well,
so
we
this
is
like
we
do
see
that,
as
as
the
general
like
direction
of
what
makes
it
simple
to
operate,
kubernetes,
because
this
this
goes
in
handy
now,
like
kubernetes.
In
general,
like
this
is
what
I
want
to
get
out
get
out.
If
you
take
a
step
back,
kubernetes
has
been
a
huge
enabler
first
for
devops,
like
containers
and
kubernetes,
and
now
for
github
for
for
devops.
C
Because
of
the
level
of
automation
that
kubernetes
provider,
you
don't
you
don't
need
kubernetes
to
do
ci
cd,
but
with
kubernetes.
It
becomes
extremely
simple,
because
it's
super
simple
to
provision
a
new
instance
of
your
application
in
your
qe
versus
doing
the
same
on
a
virtual
machine
on
your
hypervisor
might
not
be
as
as
simple
so
that
that
really
pushed
adoption
of
devops,
but
especially
when
it
comes
to
git
ups.
C
The
reason
I
think
this
goes
hand
in
hand
with
kubernetes
is
that
kubernetes
really
made
this
controller
pattern
very
well-known
and
familiar
like
the
controller
pattern
pattern
that
kubernetes
implements
or
it's
the
core
of
how
kubernetes
operates
was
not
invented
by
kubernetes.
But
it's
it's
an
extremely.
B
C
Way
to
look
at
driving
operation
you,
you
declare
what
you
expect,
what
you
want
and
in
form
of
yaml
and
or
json,
you
put
it
in
a
cd,
and
there
are
controllers
that
go
and
do
the
work
to
make
it
happen
right
instead
of
you
saying
first,
do
this
then
do
that
then
do
this
then
add
memory,
then
add
storage,
and
then
I
have
what
I
need
you
just
say.
I
need
something
that
has
this
much
memory
does
this
looks
like
this
and
that
and
you
hand
it
over
to
the
control.
C
The
controller
goes
and
does
whatever
he
needs
to
do
to
make
that
happen
and
gives
you
what
you
had
described.
So
this
this
way
of
this
mode
of
thinking
really
became
extremely
familiar
because
of
kubernetes,
which
is
exactly
what
what
git
ops
is
really,
except
that
you're
saying
that
expand
that
to
everything
about
your
application
and
infrastructure,
not.
C
D
C
Something
missing
in
the
middle:
that's
the
controller!
You
are
mentioning,
so
somebody
gotta,
look
at
the
skit
repo
and
do
the
same
thing
that
kubernetes
does
for
a
cd
when
it
console
outside
hcd
and
whatever
described
there
tries
to
bring
the
cluster
up
to
that
state.
So
when
it
comes
to
githubs,
you
need
to
do
someone
to
do
this.
For
for
your
gadget
cloud
story,
and
there
are
a
lot
of
technologies
that
do
this
and
red
hat.
C
Red
hat
in
general,
if
you
look
at
how
red
hat
operates,
so
it
has
brings
really
like
open
source
projects
that
have
a
lot
of
potential
and
they
are
very
well
built
and
they
have
a
very
democratic
community.
Around
them.
Vivid
community
makes
them
consumable
for
enterprise
customers,
like
that.
That's
what
we
do
across
everything
like
any
piece
of
software.
C
You
look
at
red
hat,
so
we
started
looking
at
the
community
around
it
and
what
technology
exists
and
our
seriously
sticks
out
as
an
extremely
popular
controller
for
githubs
started
by
into
it
or
started
that
into
its
acquired
and
into
it
for
like
in
in
europe.
Maybe
they
are
like
known
less
they.
They
have
different
type
of
tax
applications
and
and
cloud-based
services
like
turbo
tax,
and
things
like
that.
C
America
they're
extremely
popular,
and
they
run
hundreds
of
kubernetes
instances
and
and
they're
using
argo
city.
They
built
our
cd
as
a
way
to
operate
all
these
clusters,
so
it
isn't.
It
was
an
extremely
battle
tested
piece
of
software
for
the
githubs
method
used
by
the
organization
and
created
it,
so
it
it.
It
showed
a
lot
of
potential
and
also
we
saw
an
extremely
active
community
around
it.
There
are
when
you
look
at
the
argo
cd
project.
There
are
more
than
100
organizations
that
are
publicly
speaking
about
using
argo
cd.
C
C
Those
are
also
available
as
community
software
on
on
openshift,
but
the
the
value
of
argo
city
so
was
that
the
community
was
extremely
well
designed
and
active
and
solves
a
problem
extremely
well,
very
native
to
to
kubernetes
and
fits
really
well
with
with
the
rest
of
openshift
and
other
technologies
that
work
with.
So
that
was
the
initiation
of
our
journey
and
fast
forward.
C
A
couple
of
months
is:
we
have
both
of
those
pieces
of
software,
take
down
our
argo
cd
as
a
foundation
of
continuous
integration
and
continuous
delivery
on
openshift,
the
extremely
happy
about
that
and
what
we're
looking
forward
is.
We
want
to
bring
these
technologies
a
lot
more
into
the
ecosystem
of
openshift.
Openshift
is
a
platform,
but
it's
not
a
single
piece
of
software.
It's
a
platform
with
a
lot
of
with
an
ecosystem
of
software
from
red
hat
products
from
bed
hat
and
products
from
they
have
partners
that
run
on
it.
C
You
can
get
compliance,
make
sure
that
your
platform
is
nist
compliance
for
example
or
hipaa
compliant,
and
it
can
scan
images
and
configuration
and
create
like
really
compliant
nice
compliance
report
and
allow
you
to
fix
it.
So
we
want
to
make
sure,
for
example,
that
we
can
use
that
as
to
enable
devsecops
use
cases
within
openshift
pipeline
within
openshift
githubs,
and
tie
that
together
as
a
ci
cd
flow
that
not
only
it
it
it
isn't.
It
is
a
way
approach
to
implementing
githubs,
but
also
it
has
security
built
in
it.
C
Has
security
checks
and
security
flows
built
in
into
that
that
process?
There
is,
for
example,
another
product
on
openshift,
red
hat,
advanced
cluster
manager,
which
is
a
really
well
designed
for
a
cluster
lifecycle
manager.
You
want
to
provision
a
cluster
on
amazon
or
azure
on
vmware
or
different
platform,
or
you
want
to
manage
your
fleet
of
clusters
as
a
group
and
look
at
the
workloads
look
at
different
aspects
of
it
and
you're.
C
We
can
say
that
you
that
in
argo
city
and
argo
cd,
usually
you
say
this
v3
point
is
to
sync
to
that
cluster,
but
we
want
to
make
it
more
dynamic
through
acm,
say
right
now.
I
know
that
this
this
repo
contains
my
application,
but
right
now
I
don't
know
which
clusters
are
the
production
clusters
for
for
this
application.
I
I
know
it
because
we
have
a
very
dynamic
infrastructure
and
the
production
clusters
today
might
be
these
10
clusters
and
through
two
weeks
later
there
might
be
different
things:
10
clusters.
They
are
short-lived
clusters.
C
So
I
I
want
argo
cd
to
at
the
time
that
you're
deploying
the
application
to
somehow
figure
out
what
are
the
production
clusters
at
that
point
and
sync:
the
application
to
those
clusters.
So
we
are
looking
at
tighter
integration
with
acm,
because
acm
manages
that
fleet
of
clusters
for
the
customers-
and
it
knows
which
clusters
are
production
clusters
at
that
point.
So
our
city
can
talk
to
acm,
retrieve
the
list
of
clusters
and
start
syncing
to
those
as
an
example.
So
we're
looking
to
integrate
in
a
lot
more
and
more.
C
These
two
technologies
into
ecosystem
of
openshift
and
other
pieces
of
software
from
red
hat
and
partners
that
run
on
openshift
and
make
it
a
really
seamless.
Experience
for
customers
want
to
start
with
a
git
ops,
workflow
on
on
openshift
and
be
able
to
get
a
lot
of
value
across
the
entire
ecosystem
of
products
and
add-ons
that
are
available
on
openshift.
B
Yeah,
but
now
we
have
been
talking
about
like
devops,
it
ups
deploying
applications,
but
let's
see
like
your
take
on
actually
using
keydops
to
manage
the
opens
if
the
googlenet
has,
since
basically
goodbyes
is
just
containers
running
everything,
you
need
to
run
your
application
production.
What
is
your
take
on
using
githubs
to
maintain
the
platform,
not
just
applications?
B
C
A
great
question
so
coordinated
like
we
discussed
it,
made
infrastructure
very
declarative,
but
configuration
of
kubernetes
itself
is
not
necessarily
a
bad
declarative
and
when
you
look
at
openshift,
openshift
adds
a
lot
of
peripheral
components
to
kubernetes
to
make
it
useful
like.
If
you
want
to
use
kubernetes,
you
need
a
registry,
you
need
ingress
controller.
D
C
The
advantage
of
like
the
fruit
that
we
get
one
of
the
fruits
of
that
effort
is
that
you
could
point
you
could
put
the
entire
configuration
of
the
platform
in
in
a
directory
from
movie
ammo
and
run
a
cube
cut
out,
apply
and
the
cluster
comes
to
that
baseline
configuration
that
you
specifically
wanted
and
change
all
the
knobs
that
that
that
you
would
like,
and
if
you're
running
a
lot
of
clusters,
you
could
just
use
the
git
ops
flow.
Similarly
to
automatically
sync
all
those
changes
to
to
the
clusters
that
are
connected
to
b3.
C
So
we
see
almost
every
customer
on
openshift.bc
uses
argo
cd.
They
start
with
this
use
case
that
they
are
using
the
git
ops
workflow
for
configuring,
the
cluster
itself,
so
if
they
want
there
is
a
there's,
usually
a
platform
owner,
a
platform
group
that
that
manages
the
openshift
cluster.
For
other
teams
within
the
organizations-
and
they
own
a
git
repository
that
contains
a
configuration
of
the
platform,
and
if
other
teams
need
a
change,
they
could
also,
they
could
even
send
a
pull
request.
C
They
would
ask
for
the
change
themselves,
modify
the
config,
send
the
pr
to
to
that
repo,
the
owner
of
the
repo
reviews
that
and
for
example,
they
want
to
enable
particular
function
in
the
internal
image
registry
of
openshift.
So
they
send
the
pr
that
contains
that
change
in
in
that
config
yaml
of
registry.
C
B
C
They
have
it
like.
The
advantage
of
this
way
is
that
the
the
wider
organization
has
a
way
to
request
changes.
It's
not
ticket-based,
you
actually
request
you
send
the
change
that
you
want,
but
at
the
same
time
the
platform
owners
have
have
a
gate
and
they're
a
gatekeeper.
They
have
an
opportunity
to
review,
discuss
maybe
reach
back
to
the
requester.
Why
do
you
need
this?
C
There
are
other
ways
to
handle
it,
and
once
there
is
agreement
applied
and
rolling
out
rolling
it
out
to
to
the
cluster,
and
with
that
like
the
advantage
of
this
is
that
the
visibility
that
you
get
on
those
changes
right
that
you
every
change
that
goes
into
those
clusters
you,
you
can
always
come
back
into
the
history
of
the
git
repo
and
see
what
conversations
happen,
and
this
is
actually
like.
It's
really
important
I
wanted
to
mention
about
measuring.
C
You
talked
about
measuring
like
how
much
devops
or
get
ups
you're
doing,
and
that's
that's
extremely
actually
important
point
that
so
why?
Why
do
we
do
all
of
this?
Why
would
we
even
start
with
get
ups
sure,
it's
a
little
cool
now
and
the
automation
helps,
but
what
we
really
want
to
get
to
is
a
set
of
metrics
that
are
important
for
the
organization.
So
you
hear
a
lot
like
within
devops.
C
There
are
a
common
set
of
metrics
that
we
talk
about
like
the
lead
time
for
rolling
out
a
change,
how
how
long
it
takes
for
the
change
to
go
into
production
or
how
long
it
once
we
have
a
failure.
How
long
it
takes
to
restore
our
state
to
a
functioning
like
restore,
like
the
the
mean
time,
to
restoring
the
service
or
recovering
the
service
from
the
failure
and
the
githubs
workflow
that
we
talked
about
for
rolling
out
configuration
to
the
cluster.
So
let's
say
there,
there
is
a
problem
in
the
angular
control.
C
It's
a
huge
help
to
be
able
to
connect
that
when
was
the,
what
are
the
lists
of
changes
that
are
applied
to
the
ingress
controller
controller
in
the
in
the
last
like
over
that
time
window
from
when
it
was
working.
Fine
till
now
is
not
working
fine
anymore
and
to
be
able
to
trace
that
back
to
what
was
the
specific
changing
git
that
that
was
causing
this.
This
change
on
the
cluster,
who
issued
it,
who
reviewed
it?
What
discussions
were
happening
on
it?
What
was
the
state
before
that?
C
So
all
of
all
of
that
information
you
get
immediately
in
case
of
argo
cd,
we
really
a
click
from
the
the
shot.
The
the
sha
idea
of
the
comment
back
to
the
git
repo
and
what
changed,
and
that
extremely
like
provides
a
lot
of
information,
useful
information
to
reduce
the
time
to
recover,
because
you
get
all
that
contextual
information
at
one
place
for
you
to
be
able
to
analyze
and
figure
out
what
was
wrong
and
go
correct.
The
situation.
A
That
is
important
yamakosa
for
the
auditing
part
right.
Many,
because
so
many
users
ask
about
what
about
the
auditing
who
makes
what
how
to
roll
back
how
to
roll
forward.
So
this
is
a
very
cool
and
also
another
question
I
would
like
to
to
know
from
you
is
there
there
will
be
more
integration
between
open
shift,
web
console
and
arco
or
key
ops?
At
the
moment
you
can
install
open,
openshift
github's
operator,
you
have
irko
city
running.
Will
there
be
like
pipeline,
like
tecton,
with
more
integration
in
openshift
console?
C
We
have
about
the
runtime
of
the
application
on
openshift,
combined
with
information
we
get
from
git
and
come
up
with
with
dashboards
that
show
more
the
life
cycle
of
application
from
application
point
of
view.
So
in
in
argo
city
dashboard,
you
see
the
the
entire
fleet
of
clusters
and
applications
from
argo
city
point
of
view
in
openshift
we're
working
on
views
that
kind
of
trim
down
that
information
to
a
single
application
view.
I
have
an
application
called
payroll
and
it
has
four
different
environments:
there's
dev!
C
There
is
a
stage
and
acceptance,
testing
and
prod,
and
I
can
see
how
application
flows
between
this
environment.
When
was
the
last
time
that
it
was
deployed
on
the
stadium,
for
example,
what
was
the
change?
What's
the
status
of
application
on
that
environment
and
the
history
of
this
flow
from
a
single
application
perspective,
so
an
application
dashboard?
A
Awesome
thanks
for
for
this
update
on
this
integration,
which
is
very
cool
to
have
all
these
tools
integrated
in
openshift,
also
with
openshift.
We
have
more
and
more
tool
in
openshift
integrated
with
openshift
authentication,
so
there's
single
control
plane
right,
we're
seeing
auditing
place
where
you
can
track
everything.
So
this
is
a
very
cool
and
we
have
some
somebody
in
the
let's
say:
let's
see
the
chat,
so
somebody
brought
its
own
coffee
welcome.
A
So
all
the
people
can
start
trying
openshift
github's
operator,
trying
user
using
argo
cd
and
doing
everything
you
said
right,
going
implementing
the
tool
looking
at
the
dashboard
yeah.
So
this
this
could
be
also
useful,
and
we
shared
also
this
this
lab
in
the
github
school
and
let's
we
would
like
to
hear
from
you
any
feedback
about
that
and
see
like
this
is
not
the
only
place
where
to
start
with
github's
right.
We
have
a
more
and
more
tutorial
guide
session
coming
and.
B
C
You
don't
really
need
anything.
You
just
need
a
browser
right.
That's
all
you
need!
You
don't
have
to
get
into
the
nitty-gritty
of
like
running
an
openshift
instance
locally
or
getting
a
cluster
and
so
on.
It's
not
that
difficult
to
do
that,
but
with
canada
you
just
have
it
in
the
browser,
so
I
definitely
recommend
to
start.
C
B
C
C
Content
comes
out
in
the
coming
weeks
on
openshift
and
redhead
developer
blog,
but
also
keep
an
eye
on
the
argo
city
content.
It's
the
community
is
extremely
active,
so
we
see
a
lot
of
content
popping
up
about
different
ways
to
use
different
parts
of
argo,
cd
and
and
take
time
like
both
of
these
projects
grow
like
really
fast,
both
deep
and
on
the
breadth.
B
Yeah
yeah,
yes
and
be
cast
to
ask
to
all
the
listeners
and
who
watch
this
afterwards.
If
you
do
something
cool
with
keeps
up
kidops,
please
share
it.
You
do
you
the
work
in
the
cast
companies.
You
might
have
to
do
top
secret
things,
but
I
hope
that
you
can
share
something
write.
A
blog
post
write
a
twitter
tweet
linkedin,
something
that
what
are
you
doing
with
kidops?
What
are
you
doing?
Targo
cd,
so
that
everybody
else
knows
that
what
cool
things
can
be
done,
even
though
it's
top
secret
stuff,
you
can!
B
The
baseline
you
can
you
can
share.
Sharing
is
caring,
as
we
say
in
red
hat,
so
please
share
what
you
do
and
yeah
it.
It
was
a
pleasure,
it's
always
a
pleasure
with
siamak,
because
the
broad
knowledge
about
the
ways
of
working
around
devops
kid
of
pipelines.
So
it's
there
is
it's
a.
It
was
a
pleasant,
pleasant
chat
with
you.
Thank
you.
C
A
A
Cess
time
talking
about
kubernetes
of
the
control
plane
for
the
hybrid
cloud
on
the
keynote
session
very,
very
interesting
cool
session,
and
before
closing
I
would
like
to
remind
you
our
schedule
that
we
have
today
at
openshifttv.
If
you
go
to
the
calendar
today,
we
have
the
the
office
hour
about
service
mesh
github's
office
hour
together
always
with
cmak
and
jafar.
A
We
will
have
the
github
office
hour
this
afternoon
from
three
and
four
p.m,
and
then
we
will
have
another
office
hour
for
openshift
for
that
seven
so
full
day
here
at
kubecon,
very
excited
to
be
here
at
kubecon,
very
excited
to
have
used
as
cmak
today
talking
about
the
key
tops,
so
I
think
we
shared
everything
we
had
and
we
can
close
this
a
wonderful
episode
about
the
openshift
coffee
break
about
the
githubs.
Thank
you
siamak
for
joining
us.