►
From YouTube: CNCF SIG App Delivery 2020-10-07
Description
CNCF SIG App Delivery 2020-10-07
A
A
B
B
A
A
A
A
A
Okay,
then,
let's
get
started,
let's
see
how
a
lot
of
more
people
are
showing
up
so
for
today,
couple
of
updates
the
first
one
is
on
the
operator
working
group.
I
want
to
join
the
last
couple
of
meetings.
We
decided
to
merge
the
working
groups
back
into
the
main
meeting
here
from
the
presentation
working
perspective,
also
because
they
are
at
least
some
of
those
meetings
they
did
not
really
have.
We
have
didn't
have
a
lot
of
attendance.
A
We
also
had
like
very
low
attendance
all
together,
so
we
thought,
let's
move
it
into
the
main
meeting.
Also
some
of
those
meetings
I
tried
to
join
them.
Nobody
really
showed
up
to
those
meetings.
We
try
to
put
the
work
back
into
one
meeting
and
we
can
split
things
further
out
as
we
know,
but
obviously
people
can
focus
on
what
they're
interested
in-
and
this
is
true
for
both
the
air
gap
work,
as
well
as
the
work
on
the
operator
definition,
and
let
me
just
quickly
show
you
my.
A
A
I
last
meeting
I
took
the
action
item
to
comment
pretty
much
on
all
the
action
items
that
were
in
there
in
this
document
and
to
really
move
this
forward.
So
this
was
also
requested
by
that
you
see
that
we
come
up
with
a
a
better
documentation
for
a
better
definition
of
what
an
operator
is
and
I'll
just
briefly
take
the
time
to
go
over
a
couple
of
items
here.
A
A
For
the
related
technology
part,
it's
not
even
really
necessary
for
this
document,
so
we
go
over
the
document
to
describe
what
an
operator
is,
but
not
necessarily
to
define
what
other
possibilities
are
out
there
to
run
different
technologies
and
what
could
be
used
as
an
alternative
to
some
of
the
capabilities
I
could
operate.
So
the
proposal
was
to
to
remove
the
section
this
has
been
now
around
for
almost
a
month
to
remove
the
related
to
other
technology
approaches
session.
A
C
C
A
A
A
C
A
A
A
If
you
want
to
put
it
that
way,
that
say
who's
the
audience
of
this
document
and
we
started
well,
the
toc
requested
it,
which
would
mean
it's
a
very
technical
audience.
Obviously,
now,
then
we
extended
it
to
technically
kubernetes
app
developers
and
cluster
operators,
which
I
think
also
makes
sense
if
you're
building
an
app
or
if
you're,
operating
an
app
on
a
kubernetes
cluster,
you
should
understand
what
an
operator
is
that
that
totally
makes
sense.
A
Is
I
was
back
then
part
of
this
meeting,
but
I
think
we
are
still
struggling
with
the
technical
definition
of
what
the
operator
is.
So
I
remember
the
fact
that
when
we
had
this
discussion
was
yes,
my
my
boss
he's
not
like
super
tactical.
I
want
to
implement
an
operator,
and
I
want
to
give
him
a
document
that
he
understands
why
I
want
to
do
this.
A
A
D
A
Yep
I
mean,
obviously
the
cncft
you
see
is
is
a
target
audience,
but
I
think
the
main
we're
writing
it,
because
we're
building
it
for
it
on
that
uc
request,
but
I
think
that
makes
and
so
and
I
removed
the
technical
here.
I
think
it's
kind
of
like
repeating
itself.
I
have.
I
have
luckily
really
seen
on
very
few
untechnical
app
developers.
A
A
A
Yeah,
so
just
that
they
ask,
for
your
permission,
all
the
time,
if
you
do
not
agree,
simply
speak
up,
what
was
it
or
if
you
agree
that,
if
you
have
an
opinion,
then
I
think
that
that
would
be
good.
So
this
is
you
so
you're,
either
developing
an
application,
you're
running
a
kubernetes
cluster
or
you're,
an
s3
that
is
obviously
responsible
for
an
application
that
is
running
in
kubernetes.
A
A
So
an
operator
is
an
in-cluster
application
which
uses
declarative
paradigm
for
the
installation,
configuration
and
operation
of
an
application.
That
was
a
comment
that
that
tom
put
in
there
and
the
working
group.
So
I
think
the
only
discussion
in
here
is
what
about
operators
that
are
built
for
non-kubernetes
cluster
resources.
A
A
C
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
If
there
are
problems,
people
who
run
workflows
and
qualities,
often
like
to
use
automation.
Okay,
let's
find
operators
in
kubernetes
kubernetes
is
designed
for
automation.
Out
of
the
box,
you
get
lots
of
built-in
automation,
you
can
use
kubernetes
to
automate,
deploying
and
running
workloads,
and
you
can
automate
how
kubernetes
does
that
kubernetes
controller
concept
lets
you
extend
the
cluster
behavior.
I
think
this
is
something
we
should
put
in
there
you
extending
what
the
cluster
can
do.
A
A
A
I
think
that
is
a
bit
more
specific,
but
what
I
think
might
be
helpful
is
like
having
a
picture
like
usually
when
you
have
an
operator
like
these.
Are
your
major
building
blocks
that
that
you
have
in
general,
like
your
custom
resource
your
controller
component?
These
are
like
this
is
your
reconciliation
loop
or
this
is
your
interaction
with
the
kubernetes
api.
A
A
A
If
you
delete
it,
the
operator
takes
a
snapshot
then
make
sure
that
the
stateful
set
and
volumes
are
removed.
The
operator
also
manages
regular
database
updates
for
each
sample
db
resource
the
operator
determines
where
to
create
the
parts
that
can
connect
to
the
database
and
to
take
backups.
These
pots
would
rely
on
a
configmer.
A
A
A
So
I
think
that
sample
db
this
list
by
the
way
they
also
extended
to
think
that
older
documentation
didn't
have
all
of
them
in
there,
with
kudo
cube
builder
with
the
controller
and
the
operator
framework
in
there,
but
I
think
putting
something
like
this
in
moving
something
like
this
over
into
the
dock
might
actually
be
helpful.
I
think
now
I
understand
that,
like
even
having
a
picture
that
okay,
these
are
the
components
that
you
have.
This
is
what
it's
doing.
A
A
A
A
A
A
A
A
C
A
D
D
D
A
D
A
A
A
A
D
Implementation
just
a
question
on
the
two
diagrams
should
we
include
both
the
diagrams,
because
the
second
one
to
me
looks
like
sort
of
a
representation
of
the
current
population.
Like
basic
install
is
high,
and
I
mean
usually
we
use.
We
use
diagram
like
that
to
show
the
population
not
the
life
cycle,.
A
A
A
A
A
B
B
Term-
and
I
mean
it
loses
its
original
koroz
purpose,
if
we
don't
distinguish
it
from
a
controller,
we're
we're
making
it
so
different
from
the
original
purpose
that
it'll
probably
end
up
confusing
a
lot
of
people
as
well,
because
it's
gone
so
far
away.
I
mean
I
can
have
a
controller
that
uses
a
shared
informer
against
a
core
object,
and
could
you
argue
that
that
is
an
operator
just
a
or
you
know,
just
a
built-in
object
is
that
an
operator
then
there's
a
difference,
and
I
think
it
needs
to
be
outlined.
B
That's
why
this
question
even
came
up
and
we
say:
well,
there
really
isn't
any
difference,
they're
going
to
say:
why
do
we
have
the
term
operator
and
then
other
people
are
going
to
say,
but
koros
define
this
in
a
way,
that's
very
different
than
just
a
controller.
Why
are
you
redefining
it
to
something?
That's
just
so
general
that
it
can
be
a
controller.
It's
going
to
raise
a
lot
of
questions.
If
we
don't
answer.
A
But
the
question
is:
what's
the
proposal
I
mean
the
way
if
you
again
look,
interestingly,
at
the
kubernetes
documentation,
they
talk
about
the
operator
pattern,
so
it's
as
small
as
a
pattern.
How
you
can
manage
workloads,
they
don't
they
go
into.
They
provide
insights
on
how
you
can
implement
it
with
kubernetes
platform
mechanisms,
but
it
is
a
pattern
on
how
to
do
things
rather
than
it
is
like
an
actual
like
core
artifact
of
what.
What
what
we're
doing.
I
know.
Eventually,
people
are
releasing
operators.
A
B
A
Yeah,
whoever
has
good
ones,
obviously
comments
and
like
good
examples,
but
I'm
putting
this
in
here
yeah.
Then
we
are
again
at
the
related
technologies
and
approaches
section
which
thomas
has
taken
the
action
item
to
talk
with
the
individuals.
Whatever
we
want
to
keep
it,
I
think
we
don't
necessarily
need
it.
This
is
not
the
computation
here.
A
A
Okay,
we
are
almost
out
of
time,
especially
since
we
had
to
be
able
to
come
here
a
bit
later,
just
a
quick
update,
the
app
delivery
landscape
that
harry
was
kind
of
initiating
doesn't
like
not
london.
I
didn't
really
update
that,
so
I
would
move
this
to
to
the
next
meeting
to
talk
about
this
also
on
air
gap
and
the
air
get
working
group,
the
telco
he
is
on,
I
reached
out
to
them
once
I'll
I'll.
Do
it
again
for
examples
on
the
aircraft
environments
and
the
work
that
they'd
like
to
see.
A
A
My
takeaway
so
far,
however,
was
that
a
hipster
shop
is
nice
to
show
a
micro
service
application.
It
mean
it
misses
a
lot
of
things
that
are
kind
of
crucial
to
to
the
more
real
real-world
type
of
application,
like
there's,
no
stateful
workloads
in
there
there's
an
issue
for
this:
there's
not
really
a
database
in
there.
That
needs
to
be
upgraded
and
managed,
maybe
even
a
database.
That
itself
is
managed
by
an
operator
like
I
don't
know
like
a
v-test
or
something.
A
Obviously,
it's
all
like
one
version
in
one
here,
so
there
is
no
blue-green
type
of
deployment.
There
is
no
canopy
releasing
capabilities
in
there
by
default,
there's
also
no
third-party
dependencies
that
might
be
requiring
any
secret
management
and
there's
also
not
multiple
stages
with
multiple
configurations.
So
it's
kind
of
unsure
how
you
would
handle,
like
this
application
running,
let's
say
in
a
pre-production
and
a
production
scenario
with
different
secrets,
and
I
would
define
it
there.
B
I
can
I
just
also
to
throw
in
another
layer:
they've
been
the
end.
Users
have
been
putting
out
their
radars
lately
and
there
are
certain
things
that
they've
put
into
certain
categories
within
those
radars
or
whether
you
know
use
it
trial.
Those
kinds
of
things
that
have
been
typical
to
radars
I
haven't
looked,
but
does
the
hipster
shop
example,
actually
follow
the
same
patterns
that
they've
talked
about
over
on
the
radars,
or
is
there
a
mismatch?
There.
B
Shop,
yeah
and
in
the
way
they
deploy
it
and
and
what
they
use
does
it
actually
follow
what
the
end
users
have
said.
These
are
the
things
that
are
in
the
the.
Why
the
adopt
phase
does
that
actually
follow
that
or
do
does
it
use
things
that
are
maybe
more
niches
that
the
developers
of
hipster
shop
wanted
to
show
off?
A
So
what
you
have
in
here
in
the
adopt
phase,
you
have
flux
and
helm
in
there.
I
think
it
I'm
not
sure
whether
it
uses
helm
by
default
or
it
uses
just
manifests.
I
think
it
uses
both
and
interestingly,
if
you
look
at
the
rest
in
there
I
mean
there's
argo
in
there
in
the
ss
phase.
Obviously
it's
not
using
anything.
Argo
related
jenkins,
x
and
spinner
person,
not
in
there.
As
far
as
I
know,
you
could
probably
use
it.
B
A
B
B
So
we
look
like
we're
on
the
same
page
and
we're
actually
not
just
showing
off
cool
technologies
in
the
csf,
but
actually
showing
off
what
the
end
users
are
saying
are
good
ways
to
do
things,
and
so
I
think
it's
it's
a
nice
way
to
have
synergy,
because
then
you
we
can
actually
say
in
the
thing
and
the
end
users
were
talking
about
this
and
you'll
see
these
same
technologies.
You
can
reference
other
things
happening
within
the
cncf
and
show
how
they
jive
with
each
other,
and
so
it's
an
opportunity
to
reference.
A
B
A
A
But
as
we
as
we
have
more
more
more
end
users
that
also
requires
okay,
how
can
they
move
something?
Oh
it
just
gets
a
bit
more
complicated
because
then
we
also
get
12
factor
app
discussion.
Maybe
it
was
to
figure
out
that
certain
things
don't
work
work
that
well,
but
I
think
the
especially
the
git
tops
approach
is
interesting.
A
B
B
A
I
need
the
other
thing
I
found
taking
it
as
that
that
reference
application,
and
we
also
use
it
internally
for
some
demos,
if
you
really
run
it
in
a
multi-stage
environment,
it's
actually
consuming.
Quite
a
lot
of
resources
like
running
it
in
a
three-stage
environment
requires
quite
some
cluster
resources.
Obviously,
so
maybe
something
a
bit
smaller
might
be
easier
for
people
to
to
experiment
and
use
cncf
technologies,
but
I
totally
like
the
github's
approach.