►
From YouTube: CNCF TAG App Delivery 2021-06-02
Description
CNCF TAG App Delivery 2021-06-02
A
B
C
D
E
A
D
E
F
We
have
two
topics
here:
the
operator
white
paper
and
then
the
bigger
part
will
be
the
application.
Enablement
charter
refinement
work,
so
I
I'd
suggest
we
turn
the
agenda
actually
upside
down.
If
you
don't
mind,
I
think
we're
quicker
with
the
operator
white
paper
and
then
take
the
rest
of
the
meeting
on
the
application,
enablement
part
and
I'll
just
bring
up
a
also
a
quick
note
from
because
we
have
here
as
well
from
yesterday's
toc
meeting
for
the
people
who
did
not
join
so.
F
F
F
I
think
it's
good
input
here
also
looking
at
the
charter
for
app
delivery
and
then
doing
it
there
as
well,
so
it
was
liz's
proposal
and
I
think
if
we
could
get
this
ramped
up
in
the
next
month,
we
should
be
doing
this
and
we
are
going
to
now
officially
retire
air-gapped
environments
because
we
have
honestly
nobody
really
working
on
it
and
it's
just
on
the
calendar
I'll
just
officially
retire
it.
I
also
mentioned
this
yesterday
unless
anybody
steps
up
and
says
yes,
this
is
something
I
want
to
work
on.
F
I
don't
know
25
people
who
want
to
work
on
it
as
well.
It
was
from
the
telco
folks
initially
when
we
had
when
we
discussed
it,
that
cube
kind
of
was
super
important,
but
we
never
really
gained
traction,
and
I
think
we
could
still
start
it
over
if
we
wanted
to.
But
for
the
time
being
I
would
retire
it.
A
A
It's
a
pretty
nice
nice
piece
of
piece
of
paper,
if
you,
if
you
print
it
out
and
if
someone
of
you
would
like
to
review
it,
find
out
if
there's
something
really
wrong
in
there
and
so
on,
feel
free
to
read
it.
I've
posted
the
link
in
the
channel
document
and
also
it
would
be
nice
if
you
comment
on
our
pull
request,
approve
it
and
so
on.
We
need
as
many
contributions
as
possible
in
this
phase
and
to
know
that
everything
we
wrote
there
is
correct,
and
everyone
is
okay
with
this.
A
F
G
A
F
A
F
F
I
I
can
introduce
myself
real
quick.
My
name
is
josh
gavint.
I
work
on
cloud
infrastructure
at
discover.
Financial
in
chicago
previously
worked
in
some
open
source
projects
in
the
past,
but
we're
trying
to
improve
in
particular
what
got
my
attention
was
the
thomas's
work
on
the
the
app
enablement
and
the
infra
and
app
coordination,
which
is
an
issue
that
we're
working
on
so
hoping
to
be
able
to
contribute
and
nice
to
meet.
You
all.
A
E
Your
white
paper,
so
I'm
so
sorry,
I'm
you
know,
I
just
joined
this
group.
I
don't
know
about
six
weeks
ago
and
we
haven't.
I
haven't
been
in
part
of
this
discussion
when
you
for
this
operator
paper.
Can
you
give
me
an
idea?
Is
this
a
high
level
operator?
This
is
this
is
something
that
goes
beyond
like
a
I
get
a
git
ops
operator.
Could
this
operator
be
used,
for
example,
to
define
a
pipeline?
For
example?
Does
it
have
a
do?
A
E
D
E
Great
looking
forward
to
reading
it
and
and
getting
my
head
wrapped
around
it,
I
always
like
to
try
to
cross-pollinate
between
what
teams
are
doing
and
know
on
the
cn
cdf
side.
We
have
the
events
sig
and
I've
always
seems
like
we
should
have
events
and
the
an
operator.
In
other
words,
the
events
team
is,
are
we
going
to
have
a
listener
and
as
a
listener,
an
operator
right
and
it
could
potentially
be
an
operator-
could
be
a
well?
Let's
put
it
this
way?
A
listener
could
be
the
kind
of
an
operator.
A
F
I
think
at
some
point
it
would
also
make
sense
for
this
round
to
to
talk
about
the
the
event
standardization
that's
done
in
the
cdf.
So
in
yesterday's
meeting
I
mean
it
goes
a
bit
beyond
the
agenda.
Here
we
defined
the
first
proof
of
concept
where
we're
actually
linking
a
cd
foundation
and
a
cncf
project
together
to
talk
to
each
other
using
standardized
events.
At
least
we
defined
what
we
want
to
do.
F
We
haven't
built
it
obviously
in
60
minutes,
but
this
is
some
work
and
I
also
want
to
see
demo
here
and
also
then,
obviously
over
there,
maybe
bringing
both
groups
together.
I
think
it
is
something
we
should
consider
for
a
future
meeting,
because
the
day
work
has
some
overlap.
I
think
some
of
the
especially
event
payload
definitions
are
pretty
close
to
what
you
would
use,
what
you
might
want
to
put
in
a
c
or
d
in
a
kubernetes
environment.
F
E
E
D
F
D
I'll
just
bring
it
up
to
editing
yeah,
so
so,
fundamentally,
last
meeting
we
presented
this
and
there
was
some
really
really
useful
feedback
on
the
document
itself
and
we've
tried
to
incorporate
as
much
of
that
as
possible
and
just
within
this
segment
here,
one
of
the
big
pieces
that
I
think
is
probably
worth
reviewing
and
having
a
bit
more
discussion
around
is
the
problem.
Statement
of
app
enablement
is
quite
nascent,
and
so
we
wanted
to
make
it
clear
through
real
world
examples.
D
What
are
things
that
are
problems
when
you
are
trying
to
deal
with
infrastructure
in
one
hand
and
workloads
in
the
other
and
mesh
those
together
in
a
single
single,
coherent
pipeline
or
deployment
right?
So
let
me
just
iterate
through
the
examples
that
I
have,
and
maybe
I
can
break
that
out
for
some
questions
and
some
suggestions.
D
So,
first
and
foremost,
the
original
example
was
was.
It
was
a
single
journey
of
an
engineer
trying
to
deploy
some
sort
of
storage
class.
We
simplified
this
for
the
con
for
being
consumed
by
folks
in
the
toc
and
and
the
general
public,
and
we
now
have
three
very,
very
simple
examples:
a
developer,
using
a
storage
class
locally
to
test
an
application
not
available
in
a
higher
environment,
so
displaying
that
delta
of
underlying
infrastructure,
where
a
workload
depends
on
it.
D
Under
my
arc,
my
microservice
architecture,
it's
kind
of
an
assumption
that
one
is
there
before
the
other,
and
so
we
want
to
sort
of
analyze
some
of
the
real
world
examples
around
this,
but
more
more
especially.
I
wanted
to
just
give
these
as
as
initial
examples
as
to
why
we
feel
application.
Enablement
has
a
place
in
understanding
that
the
bounded
context
of
these
problems
and
how
we
can
solution
them
and
what
people
are
doing
I'll
just
stop
there
to
invite
any
questions.
D
A
A
You
have
a
kind
of
a
kind
of
a
separation
between
let's
say,
development
and
operations,
even
if
it
should
not
exist
and
they
have
different.
Let's
say
life
cycles
or
approval
processes
and
so
on,
and
they
have
to
be,
they
have
to
fit
together
at
some
point
at
some
point,
and
I
think
it
totally
makes
sense
that
we
that
we,
that
we
think
about
it
and
try
to
find
a
find
solutions
for
that.
B
No,
I
was
about
to
say
that
when
I
saw
the
two
stacks
one
side,
the
configuration,
the
other
side
gitops
or
cacd-
I
I
didn't
spend
a
lot
of
time
on
this
alexa.
Maybe
I
should
be
doing,
but
I
also
think
there
may
be
an
opportunity
to
bring
in
how
do
you
test
right
before
you
do
it
or
after
you
deployed.
So
there
is
probably
an
element
of
chaos
engineering.
You
know
we.
B
D
Yeah,
I
think,
that's
a
that's
a
that's
a
fair
point,
because
we
we
are
looking
at
these
examples
as
if
they
are
independent
and
as
if
they
are
atomic
right.
One
thing
begets
the
state
of
another
we're
actually
in
reality,
we
are
doing
a
lot
of
battering
against
them,
whether
that's
running
twist
lock
over
our
images,
whether
that's
scanning
the
terraform
configuration
files,
there's
a
lot
of
nuanced
and
and
not
so
clear,
behavior
that
happens
in
everyday
pipelines
and
scenarios
and
to
tracy's
point
around
cross-pollination
application.
D
D
Where
does
chaos
testing
and
where
does
that
part
of
the
landscape
fit
in,
is
really
worth
talking
about,
and
that
should
actually
be
as
I'll
talk
about
in
a
moment
a
bit
later
on
in
our
end
user
studies,
because
I
think
a
large
part
of
how
we're
going
to
be
successful
here
is
by
actually
accurately
mapping.
What's
currently
in
the
current
landscape
because,
as
you
said,
it
is
sort
of
an
emerging
field
and
there
are
many
different
flavors,
whether
that
is
a
an
argo
flux.
D
D
That's
that's
an
extremely
good
example.
It's
pertinent
because
we
have
some
projects
like
the
kubernetes
service
catalog.
We
have
thomas
and
I
were
also
running
a
few
experiments
into
sort
of
metadata
being
injected
into
environments,
and
so
I
think
that
there
are
people
from
different
companies
who
are
trying
to
solve
this
in
various
ways
and
what
we're
seeing
is
a
pattern
of
behavior
in
that
there
is
no
completely
automated
ubiquitous
solution.
At
least
there
is
not
one
that
has
gained
a
lot
of
traction
so
yeah.
That's
a
great
example.
F
Maybe
service
color,
but
even
cluster
api.
Tell
me
any
managed
service
where
I
can
use
cluster
api
to
create.
My
cluster
is
only
for
self-hosted,
so
I
cannot
script
okay.
This
is
the
cluster
that
that
that
I
want
using
cluster
api
because
I
can't
do
it
on.
I
don't
know
for
alibaba,
but
I
know
that
for
most
companies
I
simply
can't
use
cluster
api.
I
can
use
it
for
my
development
environment
with
like
a
kind
the
case.
F
D
G
G
C
F
D
Yeah
I'm
trying
to,
as
we
say,
I'm
trying
to
in
every
example,
think
of
not
just
infrastructure
trying
to
combine
the
infrastructure
with
the
application
workload
because
I
feel
like
it
helps
to
emphasize
the
point
of
the
direction
of
the
working
group
and
that
it
is
definitely
about
the
complexities
of
the
infrastructure.
But
then
also
imagine
you
have
to
deploy
a
cluster.
Then
you
have
to
deploy
your
your
pipelining
tool
tools
on
top
of
it,
so
that's
git,
lab
runners,
jenkins,
runners,
etc.
D
Then
you
have
to
have
a
additional
step
and
that's
probably
not
managed
by
the
same
team.
So
it
you
could
almost
paraphrase
that
to
say
that
the
auto
enrollment
of
new
provisioned
infrastructure
to
deploy
application
workloads
has
a
multi-step
process
right
and
that
would
still
not
solve
the
problem.
G
F
D
Okay,
okay,
so
so
that's
that's
our
examples
and
if
you
haven't
kind
of
sort
of
thought
about
it
by
now,
really
a
lot
of
the
emphasis
of
this
group
is
to
look
at
the
current
cloud
native
tooling,
the
current
cloud
native.
I
would
call
it
workflow
workload
flow
and
application,
enable
tools
such
as
you
know,
ci
cd
and
how
they
combine
together-
and
you
know
as
we're
just
saying
that
the
name
of
this
working
group
may
well
change,
but
we're
definitely
we're
identifying.
D
Within
this
event,
you
know
an
overlap
between
the
two,
the
two
of
them.
Maybe
this
is
worth
having
a
little
bit
of
time
about
spent
on,
because
it's
clear
to
me
what
this
diagram
means,
but
I
want
to
know
if
it's
clear
to
other
people.
If
there
are
questions,
then,
let's,
let's
redesign
it.
If
there's
things
that
aren't
clear,
then
maybe
let's
restructure
it
in
a
way.
A
I
There's
a
layer
there
of
build
like
app
build
tools
like
the
corresponding
thing
from
crosstalk
blooming
ansible
terraform
is,
I
guess,
what
gradle
cargo
go,
the
the
compilers
and
it's
kind
of
coordinating
those
app
compilers
with
the
infrastuff
crossplay
blooming
ansible
we're
trying
to
combine
those
in.
I
guess
argo
or
flux
like
argo
or
you
know
one
of
those
would
coordinate
something
like
that
so
yeah.
So
I
guess
I'm
saying
maybe
there's
a
third
circle
that
we
reflect
here.
The
app
packaging
tools.
D
That
sounds
really
good.
Josh,
I'm
going
to
put
a
name
to
that.
Just
so
I
can
make
sure
to
follow
up
not
to
chase
you
but
to
follow.
I
think
it's
also
like
a
really
succinct
point,
and
it's
also
come
at
a
really
interesting
inflection
point
in
the
people
are
really
trying
to
analyze
the
value.
Add
of
some
of
the
higher
order,
tooling
and
gitops
paradigm
tooling,
and
I
think
they're
trying
to
figure
out
how
they
can
get
that
into
their
workflow.
How
do
you
make
paloomi
work
with
argo
cd?
D
How
do
you
deploy
stateful
infrastructure
from
from
with
a
tool
that
actually
is
essentially
a
reconcile
loop?
That
runs
through
a
git
ops
pattern,
like
all
the
different
cornucopia
of
flavors
people
are
using
in
the
wild?
You
know
I've
seen
people
using
kept
him
with
ansible
spinnaker
with
crossplane
et
cetera,
and
I
I'm
sure
that
what
you
were
just
saying
there,
around
representation
of
a
third
potential
build
tooling
and
compiling
section,
is
going
to
be
relevant
for
some
people.
Definitely.
D
Okay,
well
with
that
said,
the
the
next
section
was
where
you
know
a
lot
of
folks
wanted
to
make
sure
there
was
fair
representation
of
projects,
and
I
think
that
is
another
thing
I
want
to
do
today
is
I
don't
put
too
much
weight
on
cross
plane
and
terraform?
There
are
plenty
of
other
real
world
deployment
tools.
You
know
whether
that's
salt
stack,
whether
that's
chef
and
puppet
and
other
things
like
that.
D
H
One
of
the
comments
I
put
in
there
was
maybe
to
think
about,
like
the
data
model
in
terms
of
kind
of
figuring
out
what
the
boundary
of
what
you're
considering
application
enablement
is
like.
There
was
a
discussion
around
clusters,
for
example,
and
so
like
I
agree
that
there's
some
part
of
you
know,
clusters
should
be
represented
in
terms
of
deployment,
but
a
deep
model
around
defining
clusters
might
not
be
part
of
the
data
model
for
what
you
want
to
represent
and,
and
so
that
might
help
frame
your
problem
in
terms
of
kind
of.
H
What
is
it
that
you
want
to
do?
Another
comment
I
think
around
this
infrastructure
piece
is
more
the
pattern
like,
for
example,
like
we
talked,
you
talked
about
crossplane,
but
it
has
this
concept
of
a
claim
and
a
resource,
and
so
that
might
be,
the
pattern
might
be
more
important
than
the
stacks
themselves
in
terms
of
separating
the
concerns
around
application.
Name,
for
example,
like
all
you
applications
might
need
to
do,
would
be
these
to
declare
the
type
of
database
they
need
and
the
actual
filling
fulfilling
of
it
might
be.
H
D
That's
a
really
really
well
articulated
point.
I
was
just
thinking
of
where,
where
best
put
this
in
the
document,
yeah
and
perhaps
even
in
the
problem
statement-
is
a
good
place
as
you
as
you
had
it
yeah.
Thank
you
for
contributing
that.
I
think.
Also
like
your
points.
Your
points
around
the
data
model
is
so
important
because
you
know
we
think
about
the
control
path
and
the
data
path
as
as
really
good
representations
of
how
we
want
to
model
the
patterns.
D
H
F
F
F
D
That
that
that's
a
really
good
shout
out,
we
should
come
to
this
section
because
actually
I
think
we
have
to
come
with
to
lowest
common
denominator.
I
think
we're
all
kind
of
in
agreement
just
looking
at
cloud
native
landscape
and
there's
probably
going
to
be
an
agreement
that
there
needs
to
be
a
certain
level
of
baseline
infrastructure,
so
there's
going
to
be
a
cloud
provider
or
some
equivocal
provisionable
local
provider
on
hypervisor
like
a
vmware
kind
of
thing.
So
let's
get
yeah
good
point.
D
Let's
get
to
that
in
a
minute,
I'll,
just
make
sure
to
hold
that
thought
in
my
head.
Just
just
finishing
up
here
then
so
we
we
had
some
good
discourse
about
the
actual
the
chart.
The
charter's
problem
statement
itself
in
terms
of
like
considering
the
data
path
and
the
data
model
as
one
of
the
aspects
or
the
facets
of
what
we're
looking
at
here.
Does
anybody
have
any
more
opinions?
I
think,
there's
a
few
things
have
been
added
onto
this
document
around
known
solutions
for
deployment.
D
This
isn't
exhaustive,
obviously,
and
it's
not
a
panacea,
to
say
that
anything
on
this
list
is,
is
any
sort
of
preference.
It's
just
typically,
what
folks
from
the
group
have
participated
with
so
please
there
are
more
things
you'd
like
to
add
that
you've
seen
use
and
again
to
emphasize
these.
It
needs
to
be
things
that
we
can
actually
potentially
interview
folks
about
and
ask
their
experiences
and
how
they've
combined
them
with
infrastructure
pipelines
as
well.
E
I
would
like
to
see
add
so
the
the
problem
I'm
having
with
this
category,
so
I'd
like
to
add
ortilius
on
there,
but
artelius
would
call
something
like
argo
or
it
could
call
something
like
captain,
because
what
artillious
is
doing
is
it's
pushing
the
deployment.
But
it's
doing
all
the
configuration
management
to
track
the
pieces
and
parts.
D
Yeah,
that's
per.
I
think
I
think,
that's
perfectly
fine
and
actually
you
I
know
I
I
wonder
if
it's
too
naive
breaking
down
into
two
categories,
but
I
think
that
the
problem
with
is:
if
we
get
to
fine-grain,
then
the
the
working
group
becomes
confusing
and
I
think
as
we're
trying
to
invite
as
many
people
to
participate
as
possible,
simply
saying
it's
either
going
to
be
an
application
deployment
or
a
workload,
enablement
tool
or
an
infrastructure
tool
helps
people.
You
know
cognitively
just
to
bucket
that,
so
I'm
super
okay
with
adding
otilius.
E
Thank
you.
You
know.
The
thing
is,
is
that
the
anytime?
I
see
you
know,
I
see
these
lists
when,
if
I
looked
at
any
one,
all
of
these
are
very
different
like
kept
in
is
completely
different
from
argo
right.
Captain
could
probably
push
a
you
know,
push
to
get
ops
operator
and
be
integrating
with
argo.
So
it's
these.
It's
always
terms
and
vocabulary
that
messes
us
up.
E
Yeah-
and
we
really
are
talking-
I
mean
what
most
of
what
we
have
just
had
a
discussion
around
is
really
what
I
would
call
more
traditional
configuration
management.
That's
really
what
we're
trying
to
get
our
arms
around,
and
what
do
you
call
a
package
which
is
an
application,
and
how
do
you
pull
all
those
pieces
together?
It
may
not
necessarily
be
doing
the
the
lift.
Argo
doesn't
solve
a
lot
of
those
things,
flux
doesn't
spinnaker.
Doesn't
it
may
do
the
lift,
but
it
requires.
D
E
D
A
meta
spec
we'll
go
on
to
actually
probably
the
next
section,
let's
go
to
the
next
section
now,
but
in
the
goals.
Really.
What
we
want
to
identify
in
this
working
group
is
how
are
people
using
the
landscape,
if
you
imagine
it
as
kind
of
like
a
cat's
cradle
of
you,
know,
inter
intersecting
lines
and
and
points
of
entry.
D
It's
just
we're
starting
to
see
a
lot
of
trends
in
what
tooling
is
is
enabling
workloads
and
how
it's
enabling
workers
and
some
of
the
pain
points,
and
I
think,
there's
a
real
value
in
that
as
a
new
engineer
might
come
into
the
come
into
the
the
the
domain
and
look
for
a
white
paper
or
examples
like
with
potato
head
and
want
to
see
how
to
use
ortega.
So
I
want
to
see
how
to
use
captain.
I
want
to
see
how
to
use
pollumi,
for
example,
so
I
think
there's
definitely
yeah.
D
E
I
E
Poly
databases
are
becoming
more
of
the
deployment
puzzle
as
we
move
away
from
a
mono
database
and
are
in
a
micro
service
architecture.
When
you
have
every.
If
you
have
you
know,
if
you
have
15
or
20
microservice,
which
is
a
start,
and
you
have
15
and
20
databases
that
go
with
it,
you
tend
to
want
to
start
thinking
about
the
databases
being
part
of
the
deployment
unless
a
task
that
a
dba
does
in
the
back
room.
D
D
D
D
That
that's
a
good,
that's
a
really
good
point,
yeah!
So
helm!
I
think,
comes
back
to
the
traditional
configuration
management
actually
pushing
yaml
into
the
api
server
right.
So
I'm
trying
to
think
of
if
I
was
to
bucket
it
into
one
of
these
two
things.
It
doesn't
deploy
a
workload,
so
it
doesn't
help
a
in
the
sense
that
it
doesn't
build
the
workload
right.
D
It
doesn't
create
the
image
it
just
tells
the
kubernetes
cluster
to
perform
an
activity
and
it
doesn't
actually
build
any
infrastructure
like
it
doesn't
talk
to
the
esx
hypervisor
and
create
a
new
vm.
It
doesn't
spin
up
anything,
so
we
could
put
it
in
here,
but
I
think
that
it's
actually
one
of
those
potential
gray
areas
where
it's
not
clearly
defined
as
one
or
the
other.
Anyone
else
want
to
chime.
In
on
that
I
mean
I,
as
I
said,
if
you
put
helm
in,
you,
want
to
customize
them
as
well.
C
C
C
D
But
you
know
what,
let's:
let's
not
try
and
define
it
right
now,
I'm
going
to
call
it
out
as
a
comment,
because
I
think
you're
right.
We
should
have
an
opinion
on
it
right
or
at
least
have
some
words
to
say
about
it.
It
does
seem
like
there
is
some
that
there's
some
differentiation
in
opinion
and
that's
healthy.
So,
let's
just
let's
just
call
it
out
so
I'll
put
helm,
customize
and
other
related
tooling
hasn't
been
identified,
and
I
think
maybe
we
should
put
a
little
sentence
or
two
in
the
document.
D
F
Maybe
one
comment
from
my
site
because
we
did
this
in
the
past
also
in
the
beginning,
with
the
operator
white
paper
looking
at
individual
solutions
that
was
even
narrower,
but
I
think
we
should
rather
look
at
functionalities
across
the
application
life
cycle
or
a
task
rather
than
projects,
because
many
projects
are
doing
multiple
things.
I
think
just
listing
projects
that
are
kind
of
related
in
a
very
abstract
way,
I
think,
is
helpful,
but
that
deep
discussion
might
lead
you
somewhere,
because
somebody
could
argue
helm
also
provides
package
management.
F
So
I
can
model
my
entire
package
dependencies
in
helm
up
and
as
I
can
use
basically
crds
or
any
kubernetes
yaml
in
there.
I
can
model
my
database
also
as
part
of
my
help
package,
which
is
technically
not
wrong,
so
I
think
that
it's
rather
easier
which
functionality
you
want
like
service,
discovery,
service
mapping
and
then
different
tools
can
provide
it,
but
with
tools
you
will
see
that
they
do
certain
things
and
other
things
as
well
and
they're
very
hard
to
categorize.
F
That's
also
where
I
remember
when
we
did
this
app
delivery
model
that
that
hairy
back
then
started
well.
It
was
so
hard
to
put
a
tool
into
an
individual
bucket
because
many
tools
fit
into
multiple
packets
all
the
time
and
that's
why
it's
sometimes
easier
to
talk
about.
Let's
call
them
capabilities
or
whatever
you
want
them
to
be
around.
F
D
Okay,
I
think
you're.
I
think
that's
a
really
good
point,
so
I
will
go
in
actually
work
with
the
the
team
on
that
because
I
think,
like
that,
might
be
a
better
way
change
the
heading
to
talk
about
oops.
Excuse
me
change
the
heading
to
perhaps
say
something
like
deployment
infrastructure
tools.
Typically
exhibit
these
types
of
behaviors.
You
know
ability
to
spin
up
from
an
underlying
infrastructure
resource
xyz,
and
then
we
can
list
out.
These
are
some
of
those
examples,
and
perhaps
that
would
help
to
answer
the
question
around.
D
D
So
if
you
think
that
you
feel
strongly
enough
that
one
of
these
is
a
really
good
exemplar
for
a
unique
pattern
or
a
unique
opinionated
way
of
doing
things,
then
it
should
be
on
this
list
and
in
touring
like
helm
and
customize,
that
they
do
have
some
really
interesting
and
some
features
that
are
very
powerful.
But
they
they
are
both
solving
a
similar
problem
domain.
C
Yeah,
sorry,
I
I
just
just
add
that
before
first
shut
up,
I
I
would,
I
would
kind
of
put
helm
and
and
customize
and
those
kind
of
things
very
closely
to
being
like
it's
a
cli
tool
right.
It's
it's
not
some!
It's
not
a
solution.
It's
it's
a
tool
that
you
use
the
flux,
for
instance,
uses
helm
and
how
it
uses
it
doesn't
matter,
but
it
uses
them
to
deploy
things.
But
flux
itself
is
a
solution
to
deploy
applications.
C
E
I
think
that's
a
great
idea,
I
mean,
I
think
it's
because
to
stay
out
of
trouble.
I
think
we
have
to
have
helm
in
this
discussion
somewhere,
because
so
many
people
use
it,
but
I
think
calling
it
out
as
a
tool.
That's
a
cli
tool
that
is
oftentimes
part
of
the
solution
of
any
of
these.
I
know
you
know
spinnaker
probably,
would
could
refer
to
it.
There's
I
mean
it
can
be
called
in
many
different
ways,
so
we
I
think
we
have
to
address
it
somewhere.
C
Yeah
and
just
just
the
reason
why
I
think
it's
special
is
because,
while
it
is
a
cli
tool
when
flux
uses
it,
it's
an
operator
which
I
think
is
relevant
and
then
also
it
does
have
workflow
features,
which
kind
of
fits
similar
to
what
argo
does
right.
It
has
life
cycle
hooks.
So
it's
not
to
me.
It's
not
obviously
excluded.
So
if
it's
not
doesn't
make
sense
in
here
that
it
should
be
explained.
Why
not?
That
was
my
link.
C
D
I
think
to
maybe
just
shed
some
light
it
might
help
is,
I
think
anything
that
people
feel
passionate
about,
and
that
is
relevant.
The
landscape
should
be
in
here.
So
I
don't
think,
there's
any
point
in
excluding
something,
but
what
I
will
do
is
I
think
we
can
probably
rework
these
sections
to
be
a
little
bit
more
sympathetic
to
behaviors
and
then
maybe
it
would
make
sense
for
either
us
to
write
a
little
bit
about
how
more
or
to
what
or
not
so.
D
Okay,
cool.
Thank
you
thanks.
Everyone,
that's
really
great
input.
We
don't
need
to
go
too
much
through
this.
This
is
just
a
little
stanza
around
sort
of
why
we
think
it
matches
the
charter.
You'll
be,
please
feel,
free
to
comment
on
it.
I
think,
what's
pretty
more
important
that
we
can
spend
the
rest
of
our
time
on
is
the
the
working
mode
and
the
goals
and
non-goals
so
I'll
quickly
go
through
the
the
working
mode.
D
This
is
primarily
going
to
be
expressed
through
the
goals.
The
team
will
do
the
the
the
standard
kind
of
formats
and
rituals,
but
the
things
that
we're
interested
in
doing
first
and
foremost,
are
vendor
and
user
interviews
and
focusing
these
questions
on
understanding.
What
are
the
patterns
of
success
so
that
we
can
identify
a
set
of
behaviors
that
are
helping
folks
to
deploy
applications
and
infrastructure
and,
more
importantly,
where
those
pain
points.
D
Secondarily
to
that-
and
this
is
sort
of
a
incremental
list
here-
it's
not
parallel
capturing
the
current
practice
of
landscape,
landscape
radar
and
again.
I
would
invite
some
comments
on
this
in
a
moment,
because
I
know
that
this
can
be
a
very,
very
broad
net
to
cast
and
then
provide
interoperability.
Examples
right,
so
this
again
comes
back
to
we
like
to
use
potato,
and
so,
if
you're,
not
familiar
with
that,
you
know
it's
a
cncf
project
which
has
an
example
code
microservices.
D
D
So
if
I
just
I'm
going
to
add
this
as
a
suggestion
to
put
that
in
at
the
top
here
just
so,
we
have
that
as
kind
of
a
north
star
to
where
we're
going
with
all
this
and
then
the
last
part
of
this.
If
we
successfully
achieve
these
three
points
is
to
provide
a
successful
patterns
white
paper
in
a
similar
vein
to
the
operator
white
paper.
So
we
clear
up
some
of
the
taxonomy.
We
identify
some
of
the
popular
tooling.
D
E
B
E
You
know
it's
going
to
have
a
square
like
kept
in,
you
know
or
argo
cd,
but
it's
in
a
micro
service
architecture
that
stuff
just
changes
so
much
we're
talking
about
moving
little
things
across
the
pipeline
on
a
high
frequency
basis
and
deploying
them
all
day
long
it
does.
It
does
offer
some
new
challenges,
and
I
don't
know
if
anybody
else
has
been
reached
out
to
but
paulo
simoes.
E
C
H
So
that
was
that
was
one
of
the
things
you
know
we're
talking
about
microservices
here,
but
unless
we
kind
of
can
represent
it
in
some
sort
of
a
data
model,
we
could
look
at
the
same
thing
and
call
it
different
things
anyway.
So
that
would
be
good
for
people
if
you're
gonna
have
a
group
like
this
and
again,
data
mall
is
important.
H
E
E
Has
questions
on
on
how
to
you
know
create
a
microservice
architecture?
What
how
the
domain
should
look,
what
the
layer
should
be,
so
that's
why
it
would
be
of
service
to
the
broader
community
to
start
having
a
conversation
somewhere
on
the
micros
on
microservices
and
I
feel
like
and
potentially
instead
of
creating
a
new
working
group.
While
a
working
group
would
be
good
to
have
a
focus
on
it,
it
could
also
be
added
to
us.
You
know
version
two
of
this
document.
F
F
D
That's
great,
thank
you
so
much
so
I
think,
and
just
just
to
sort
of
maybe
give
a
final
thought
on
the
microservice
architecture's
piece,
regardless
of
your
opinion
on
it.
What's
important
is
that
it's
prevalent
in
the
landscape
and
it's
a
problem
area
that
folks
are
trying
to
solve,
for
you
know
whether
that's
you've
got
50
spring
boot
applications
that
all
talk
rpc
to
each
other
with
10
databases
or
whether
you're
a
bedroom
developer.
It's
it's
something
that
I
think
we're
seeing
a
lot
and
it's
it's
gaining
gaining
traction.
D
So
I
would
just
like
to
use
the
last
few
moments
to
talk
about
the
non-goals
and
if
anybody
feels
strongly
about
this-
and
I
think
there's
something
we
do
need
to
have,
because
we
don't
we're
not
trying
to
boil
the
ocean
here
and
we
don't
want
to
run
the
risk
of
the
the
working
group
becoming
too
broad
and
too
thin.
So
does
anybody
have
anything
they
feel
like
would
be
a
good
start
to
put
as
an
on
goal
here
I'll
start
with
one?
D
D
D
If
you
could
elaborate,
why
you
think
that'd
be
a
good
place
to
start,
then
I'm
I'd
definitely
be
happy
to
sort
of
think
think
about
it.
We
could
put
it
to
the
rest
of
the
folks
in
the
core,
but
I
think
it
could
be
kind
of
a
big
part
of
this.
It's
because
that's
a
typical
operation
is
that
you
would
start
clusters
up
and
add
things
like
ingress
and
databases.
F
F
So
an
on
goal
could
also
be
we
consider
this
for
a
future
version,
but
unless
every,
unless
you
think
it's
like
everybody,
you
think
everybody
thinks
is
like
so
super
important.
If
we
don't
discuss
it
at
all,
there
might
be
an
issue.
I
think
it's
just
defining
the
baby
steps.
Whatever
can
we
have
like
with
the
resources
we
have
available
to
work
on
something
have
the
biggest
impact,
and
what
do
we
leave
on
the
side?
For
the
time
being,
I
think.
D
I
think,
if
I
think
about
right
actually,
when
you
think
about
it,
if
you
add
in
the
complexities
and
the
permutations
of
deploying
say
a
kubernetes
cluster,
it's
incredible.
You
know,
so
I
think
you're
absolutely
right.
So
we,
if
everyone's
in
agreement,
we'll
say
that
we're
not
going
to
look
to
identify
every
time
an
organization
builds
the
container
platform,
but
we'll
assume
that's
kind
of
a
given.
Does
that
sound,
fair.
F
We
know
that
this
is
a
problem,
but
we're
leaving
it
out
of
the
the
initial
round
of
what
you're
doing
here
my
command.
I
would
still,
I
think
we
will
eventually
to
trace
this,
but
I
think
we
will
be
talking
microservices
here
anyways
I
mean
once
we
name
something
cloud
native.
We
have
the
cncf
definition
of
cloud
native,
which
is
composable
components,
frequent
deployments
these
things
we
will
have
in
there.
H
F
E
F
I
D
No,
absolutely,
let's
just
just
reiterate
this
in
all
the
goals
of
this
working
group
is
collect.
Data
analyze
data
provide
some
examples
of
the
patterns
that
we've
seen
you
know,
so
that
could
be
some
examples
of
of
autilius
or
kept
in
or
flux
or
terraform,
and
then
provide
successful
patterns.
Now
this
is
an
opinionated
word.
We
we
can
change
that,
but
we
could
just
say
provide
patterns
within
a
white
paper
that
show
what
the
community
are
doing
at
large
and
how
those
patterns
work.
E
D
E
Many
different
kinds
of
requirements
that
there's
never
going
to
be
that's
like
trying
to
come
up
with
a
standard,
ci
cd
pipeline-
it's
impossible
yeah,
but
I
would
definitely
put
in
there
just
to
really
clarify
is
that
we
are
not.
I
I
would
like
to
see
and
are
not
in
the
non
goals
that
we
are
we're
not
defining
how
deployment
should
be
done.
B
D
No,
no
absolutely
I
mean-
and
I
think
that
that
was
part
of
the
very
very
intentional
bucketing
of
application,
delivery
and
infrastructure
provisioning
as
the
two
halves
of
this,
because
we
don't
want
to
start
getting
into
the
into
the
into
the
weeds
about
which
tool
is
better
than
another
and
how
we're
defining
the
behaviors
as
being
successful.
This
is
unsuccessful,
so
yeah,
there's
that
that's
that's
our
initial
list,
so
we're
not
defining
a
new
type
of
standard,
we're
not
building
kubernetes
from
scratch.
D
F
F
D
F
D
D
D
D
F
So
this
name,
I
actually
stole
from
everywhere-
that's
how
we
ended
up
there.
It's
all
composable
from
alex,
because
you
mentioned
composability
of
different
things.
Hong
kong
indirectly
mentioned
it
as
well,
because
he
wanted
to
use
services.
Cloud
native
is
obviously
where
stole
this
from
app
is
because
this
is
app
delivery
and
platforms.
There
is
a
very
good
platform
and
application
platforms,
blog
post
from
gardner
and
don't
get
me.
F
This
is
gartner,
because
that
blog
post
is
actually
good,
that
this
is
actually
a
good
read
what
what
companies
are
challenged
with
I'll
share
it
on
the
mailing
list.
To
make
up
your
mind-
and
I
just
put
everything
in
there-
that
the
thing
might
be,
where
they're
building
the
platform
to
ship
their
applications
or
to
get
their
applications
out
there.
F
D
E
That's
what
we're
trying
to
do
is
create
a
way
to
coordinate
two
very
difficult
pieces
of
the
puzzle,
the
infrastructure
and
manage
the
application,
and
it
is
really
a
cooperation
between
the
development
teams
and
the
infrastructure
team.
So
and
I
think
composable
kinds
of
gives
the
idea
of
the
configuration
aspects.
D
I
think
that's
great,
I
tell
you
what,
if
you
folks,
wouldn't
mind
like
if
you
get
time
just
do
a
plus
one
on
whatever
what
the
names
you
think
make
the
most
sense.
That's
probably
the
best
way
to
do
this
right.
We
can
review
it
and
tell
you,
but
that's
a
great
suggestion.
Is
that
okay
for
us
to
do
that?
Yes,
cool!
Well,
I've
reached
the
end
of
the
presentation.
F
F
F
I
think
that
usually
the
big
success
is
that,
and
what
we
also
should
try
to
do
is
attack
involve
the
other
projects
that
we're
working
with
that,
like
that,
there's
under
sick
c
gap
delivery.
It's
not
really
under
because
well
they're
independent
projects,
obviously,
but
trying
to
get
them
actively
involved
in
in
what
they're
working
on
this.
C
F
Round
of
reviews
then,
and
trying
to
reach
out,
I
mean
many
of
us
know
other
projects
where
this
would
make
sense
and
and
again
feel
free
to
also
get
people
involved
where
of
projects
that
are
not
cncf
projects.
I
also
want
to
bring
this
up
again.
You
don't
have
to
be
a
cncf
project,
obviously
to
contribute.
B
B
So
for
those
of
you
who
were
not
aware
sometime,
you
know
before
kubecon
when
we
were
talking
about
generally
chaos,
engineering
trends.
It
appears
that
there
are
multiple
projects
at
least
two
instead
scenes
here,
which
have
been
working
with
a
large
community
and
it
is
worthwhile
to
put
together
the
learnings
into
white
paper.
That's
what's
suggested
by
alloys.
I
liked
it
very
much
and
we
approached
the
other
project
chaos
mesh.
They
were
very
happy
to
coordinate
and,
interestingly,
one
more
project
also
joined
chaos
blade.
B
So
all
three
projects
are
working
together
to
put
together
the
learnings
from
the
community,
and
we
had
couple
of
meetings
really
cube.
Corn
and
few
other
stuff
came
in
the
way,
and
I
think
you
know
we
all
get
up
to
start
working
on
that
and
get
something
that
is
reviewable
both
in
this
tag,
and
I
think
the
other
projects
are
in
the
networking
tag.
So
security
will
be
one
small
piece
of
that
white
paper
and
I'm
very
happy
to
coordinate
the
charter
with
all
the
other
three
tax,
specifically
on
security
chaos
as
well.
B
So
that's
really
the
update.
You
know
we
did
meet.
That's
a
success.
We
have
not
made
a
lot
of
observations
written
though
we
just
talked
about
it.
We
hope
to
find
something
useful
in
the
next
two
weeks
right.
So
that's
really
the
update,
yeah
any
comments,
voice
or
any
suggestions.
It's
really
the
back-end
work.
That's
going
on.