►
From YouTube: CNCF TAG App Delivery 2021-06-16
Description
CNCF TAG App Delivery 2021-06-16
B
C
B
I
got
this
really
cool
headset
this
bluetooth
and
I
can't
use
it
because
I
can
never
figure
out
if
it's
connected
or
not,
everybody
will
say
tracy
you
sound
like
you're
in
a
tunnel.
It's
like!
Oh,
it's,
the
microphone's
pulling
off
of
my
laptop,
not
my
headset,
it's
like.
If
I
have
my
cell
phone
or
somewhere
around
it,
it
will
go
reconnect
to
something
else,
really
annoying,
because
it's
a
really
nice.
B
B
Yeah,
bluetooth
is
a
pain.
I
can't
even
find
the
headset.
Now
I
probably
tossed
it
somewhere.
I
probably
got
mad,
I'm
done
with
this,
and
it
was
really
cool
because
it,
you
didn't,
have
to
put
it
on
your
ears.
It
was
bone
conducting,
so
you
could
just
kind
of
put
it
around
your.
I
don't
know
what
I
did
with
it.
B
B
D
C
There's
a
funny
issue
in
the
current
that
delivery
is
released
with
a
ticket
delivery
logo,
so
the
kangaroos
all
was
almost
the
same
as
before.
Simply
the
tag
has
changed.
So
if
anyone
has
some
some
ideas
or
comments
about,
it
feel
free
to
add
them
to
the
comments.
Otherwise
I
think
we
can
close
it
in
the
near
future,
but
I
simply
wanted
to
say
that
there
is
a
new
issue.
First.
A
Yeah,
I'm
happy
too
so
our
last
meeting
we
had
some
really
good
feedback.
Thank
you,
everybody
for
participating
in
that
and
we're
sort
of
finalizing
that
draft
document
for
the
proposal
of
the
working
group,
thanks
again
for
tracy
for
coming
up
with
such
a
great
name.
I
think
that
everybody
is
pretty
happy
with
that.
The
things
that
we
took
away
that
we
need
to
still.
B
A
Out
is
how
we
wanted
to
incorporate
data.
We
wanted
to
also
lend
a
few
lines
to
how
we
were
going
to
identify
tooling
such
as
helm,
and
why
we
weren't
going
to
include
it
in,
and
you
know
what
was
the
reasoning
around
the
selection
of
tooling
and
platforms
we
had
identified,
and
then
I
think.
Finally,
we
also
wanted
to
look
at.
A
And
you
know,
practitioners
within
the
industry
to
help
us
identify
the
landscape.
Firstly,
and
to
also
talk
about
from
an
anecdotal
point
of
view.
You
know:
where
do
they
see
the
the
current
trends
of
workload
delivery
on
top
of
provisioned
infrastructure,
and
I
think
that
would
help
inform
us
as
we
go
forward.
But
in
terms
of
the
documentation
we
were
looking
to
finalize,
I
would
say
the
draft
of
the
corporate
every
working
group
charter
by
the
end
of
this
week.
Really
I'm
not
sure
if
anybody
had
anything
to
add
to
that.
A
A
So
again,
thank
you
for
that,
but
the
most
important
ones
that
perhaps
that
we
could
spend
a
few
moments
talking
about
was
there
was
some
good
contribution
from
sohail
last
time
about
the
data
model
within
this,
and
I
went
away
and
thought
about
it
and
spoke
to
a
few
peers
around
it.
And
one
of
the
things
that
I
was
going
to
put
to
this
group
is
that
it
almost
feels
a
little
bit
out
of
the
domain
boundary
of
what
we're
trying
to
talk
about.
A
In
terms
of
you
know,
what
is
the,
what
are
the
exemplars
of
how
you
would
do
an
application
deployment
on
a
provision
were
infrastructure
workload,
and
I
think
the
data
model
was
something
that,
whilst
we're
keen
to
talk
about
it,
I
didn't
see
a
way
to
weave
it
into
the
problem
statement.
So
unless
anybody
has
any
other
thoughts
on
this,
I
was
going
to
suggest
that
we,
we
don't
add
anything
else
into
that
problem
statement.
A
E
A
Well,
if
no
one's
in
disagreement,
then
we'll
we'll
leave
that
as
a
comment,
you
can
see
sahel's
comment
on
the
right
about
the
data
model,
but
we'll
just
leave
and
I'll
just
make.
It
make
a
note.
A
link
to
this
comment
that
we
we're
not
going
to
resolve
it
further
down.
Jennifer.
If
you
want
to
go
down
to
the
examples
of
known
solutions
aimed
for
deployment
infrastructure.
This
is
the
only
other
part
of
the
charter
that
was
slightly
contentious.
A
One
of
the
things
that
tracy
brought
up
and
I've
actually
scheduled
a
meeting
with
paulus
paolos,
who
runs
cncf
brazil
or,
as
part
of
it,
and
the
cncf
ambassador
around
the
working
microservices
working
group.
That
he's
looking
to
propose
that's
going
to
be
scheduled
on
the
table,
but
the
broader
question,
and
forgive
me
if
I
was
putting
words
into
your
mouth
tracy,
but
I
think
you
were
saying,
let's
consider
microservice
architectures
and
how
does
that
fit
into
deployment
infrastructure
and
applications.
So
the
the
tldr
for
myself
is.
A
I
don't
have
a
way
of
articulating
that
in
this
very
simple
set
of
examples
of
how
do
we
do
deployments,
but
I
feel
like
microservice
architecture
is
an
end
result
of
we
want
to
be
able
to
have
a
distributed
systems,
landscape
deployed.
These
are
two
of
the
kind
of
domain
boundaries
or
the
pillars
of
getting
there.
So
unless
anybody
wants
to
sort
of
talk
a
little
bit
more
about
that
today,
that's
a
work
in
progress,
I'll,
go
and
talk
to
paulo's
and
we'll
gather
some
more
ideas
around
that.
E
A
There's
a
really
thanks.
I
think
that's
a
really
good
question.
Actually
that,
I
think,
is
something
that
was
mentioned
last
week
by
and
forgive
me
I
forget
who
mentioned
it.
It
might
be
in
the
comments,
but
when
we
were
talking
about
you
know,
do
we
mention
things
like
customized?
Do
we
mention
things
like
helm?
How
far
into
the
minutia?
Do
we
get?
I
think,
what's
important.
A
Is
that
we're
trying
to
identify
two
things
as
per
this
venn
diagram
right,
you're,
looking
at
tooling
that
enables
the
provisioning
of
infrastructure
versus
tooling
that
enables
the
provisioning
of
application
workloads,
whether
or
not
that
tooling
is
declarative
or
non-declarative,
probably
shouldn't
be
the
focus
and
maybe
for
representation.
We
should
have
some
of
both,
which
I'm
not
against
at
all,
and
maybe
that's
also
why
we
should
have
a
statement
about.
We
are
not
specifically
identifying
tools
like
helm,
et,
cetera,
et
cetera,
and,
I
think
alois
had
a
really
good
point
around
effectively.
A
Those
are
cli
tools
that
are,
you
know
at
the
end
of
the
day,
those
are
driving
outcomes
rather
than
actually
orchestrating
change
themselves,
but
I
welcome
any
any
thoughts
you
have
on
it.
If
you
want
us
to
put
something
in
or
if
you
have
some
thoughts,
let's
capture
them,
let's
talk
about
them
now,.
A
Yeah
you're
very
welcome
and
again
this
is
something
we
have
like
another
week
or
two
and
we'll
come
back
to
this.
The
these
examples
are
very
much
representative
of
the
folks
who
are
involved
in
these
calls,
and
so
we
all
come
with
our
own
opinions
and
backgrounds.
We
didn't
go
down
to
the
level
of
actual
yama,
like
you
know,
the
conversion
of
data
constructs
purely
because
of
simplicity,
but
I
don't
think
it
would
hurt
to
write
a
paragraph
about
what
are
these
examples
actually
capturing,
because
it
didn't
see.
B
A
A
B
A
I'll
just
do
an
inline.
Okay,
that's
actually
very
useful
that
helps
us
to
as
a
group
understand
what
our
problem
area
is
and
what
our
domain
boundaries
are.
I
still
think
perhaps
it
would
be
worth
writing
a
little
bit
of
prose
here
or
just
articulating
what
these
are,
but
that's
really
useful.
Thank
you.
A
I
think
just
below
that
diagram
illustration,
it
might
be
worth
just
having
a
few
sentences
and
I'm
happy
to
go
away
and
have
a
have
a
shot
at
this,
and
just
say
you
know,
in
the
below
are
several
examples
of
patterns
we
that
are
commonly
used
throughout
the
you
know:
the
ecosystem
for
infrastructure
deployment
and
application
deployment.
These
are
by
no
means
exhaustive
and
don't
necessarily
represent
the
multitude
of
tooling
around
them.
However,
you
know
these
are.
A
A
So
I
don't
know
if
anybody
wanted
to
interject
here,
but
I
was
going
to
suggest
was
that
we
can
go
once
through
these
these
goals
here
and
then
at
the
end
of
it,
it
might
be
worth
looking
at
how
we
want
to
actually
make
a
start
on
the
next
segment,
which
is
actually
building
out.
That
survey
that
we
want
to
propose
to
our
project
maintainers
and
collaborators.
A
The
second
thing
we
were
looking
to
do
from
that
was
to
capture
these
practices,
and
we
did
talk
a
little
bit
about
a
landscape
radar
at
a
very
high
level
and
we're
not
trying
to
create
a
panacea
here.
But
at
the
same
time,
it's
very
useful
for
us
to
understand
in
a
visual
way
what
currently
people
are
doing.
And
then
the
third
point-
and
this
is
this-
dovetails
into
a
proposal-
thomas
I'd-
give
you
a
bit
of
time
to
talk
about
is
that
we
want
to
create
some
examples
of
how
this
could
work.
A
Kubernetes
there'll
be
a
problem
scope
that
is
bound
within
that
and
when
we're
producing
the
white
paper,
it'll
be
talking
about
application.
Workloads
deployed
onto
kubernetes
based
infrastructure
because
I
feel
like-
and
I
think
we
we
also
had
some
discussion
around
this-
that
anything
more
than
that
it
becomes
too
too
diverse,
and
there
are
too
many
permutations.
You
know
you
could
start
talking
about
hypervisors,
you
could
start
talking
about
bare
metal
and
that
the
white
paper
would
feel
very,
very
dis.
A
A
One
of
the
things
we
we
didn't
cover
last
week,
we
have
a
we
had,
so
we
we
covered
it.
We
didn't
actually
write
it
down
and
I
just
wanted
to
mention
it
here.
It's
in
the
comments
is
that
we
wanted
to
confirm
that
we're
not
looking
to
create
a
new
type
of
standard,
and
the
reason
I
didn't
add
this
in
yet
is
because
I
went
away
and
spoke
to
a
few
folks
around
how
we
wanted
to
word
this.
A
This
working
group
is
far
more
an
inversion.
It
is,
it
is
consuming
all
that
data
and
just
sort
of
presenting
it
as
is
and
trying
to
surface
some
of
the
common
patterns
between
it.
So
I'll
make
sure
that
that
gets
added
to
this
charter
probably
today,
and
I
think
that
jennifer
probably
is
it
for
where
we
are
with
the
charter
for
this
working
group.
D
A
A
Ultimately,
this
is
to
produce
a
useful
document
on
what
is
the
state
of
affairs
and
you
know
in
2021,
and
where
the
trends
looking
to
to
go,
and
also
where
are
some
of
the
pain
points,
because
we're
going
to
be
equipped
with
something
that
wasn't.
It
wasn't
present
in
the
operator
white
paper,
and
that
is,
we
have
a
lot
of
event
we'll
be
hopefully
getting
a
lot
of
end
user
interviews
that
we
can
use,
if
not
publicly,
then
at
least
privately
for
some
of
the
more
anecdotal
parts.
E
D
C
C
So
I
thought
this
would
be
very
useful
and
therefore
daniel
created
created
the
whole
stuff
around
it
and
I
think
it
it
clarifies
many
things
and
yesterday
we'll
talk
about
about
the
the
what
what
we
will
also
try
to
get
into
the
white
paper
in
the
next
few
days
weeks
and
what
we
could
add
in
the
second
version.
But
we
will
add
all
of
these
decisions
to
the
to
the
request.
So
everything
is
reproducible.
A
And
so
perhaps
what
we
could
also
do
is
at
the
end
of
this
public
review
phase
is
to
look
at
the
way
that
we're
wording
our
white
paper
and
to
take
some
of
that
knowledge
and
to
use
it
for
the
next
white
paper
so
that
we
either
have
a
glossary
of
terms,
or
we
can
at
least
just
learn
that
there
is
a
certain
level
of
you
know,
lexicon
that
we
can.
We
can
all
benefit
benefit
from
to
keep
it
fairly
neutral.
C
D
C
F
Hello,
everyone,
I
hope,
I'm
audible,
so
we've
made
some
progress
on
the
chaos
engineering,
workgroup
charter.
I
think,
in
the
last
meeting
we
discussed
that
there
was
some
interest
coming
in
from
the
other
tags,
notably
tag
network
and
security,
and
there
was
a
need
to
collaborate
and
create
a
work
group.
F
F
So
we
have
the
background
here
mostly
talking
about
how
chaos
engineering
has
evolved
and
the
paradigm
of
cloud
native
computing
has
gone
ahead
and
tweaked
chaos
engineering
a
little
bit
well,
the
core
principles
remain
the
same.
The
operational
model
is
little
bit
different.
We've
tried
to
explain
in
the
problem
statement
as
to
what
those
changes
are
mainly.
F
It
is
about
where
chaos
engineering
is
run,
what
kind
of
environments
they
are
run
at,
and
the
personnel
that
executes
or
implements
chaos,
engineering
and
what
are
the
kpis
around
chaos
engineering
in
the
recent
times
around
what
they
used
to
be
earlier,
etc.
So
some
of
that
has
been
mentioned
in
the
problem
statement,
and
we
are
looking
forward
to
refining
this
as
more
opinions
coming
from
other
members
from
the
tag,
networking
and
tag
security
and
also
the
end
users,
who
are
the
real
sort
of
the
consumers
of
chaos
engineering.
F
F
F
Some
of
that
information
is
available.
Today,
we've
got
some
responses
coming
in
the
surveys
are
going
to
be
kept
open
for
some
more
time,
we've
decided
on
sort
of
using
this
data
into
the
white
paper
in
a
week's
time
or
a
little
bit
more.
So
that
is
very
exciting
for
us
to
gather
what
the
community
is
thinking
and
the
respondents
are
at
a
mix
of
end
users,
as
well
as
chaos,
projects
or
vendors,
as
well
as
cloud
native
vendors
that
are
not
doing
chaos,
engineering
and
people
who
are
contributing
the
other
projects.
F
F
F
A
F
Absolutely,
yes,
that's
a
great
point
alex
in
fact,
we've
gone
ahead
as
a
project
and
listed
ourselves
as
adopters
in
the
potato
head
project,
we're
big
fans
of
the
project
and
litmus
is
making
use
of
potato
head
in
most
of
its
demonstrations
or
101
discussions
around
chaos.
Engineering
so,
and
especially
the
distributed
potato
head
is,
is
also
a
great
help
in
that
respect.
So
definitely
I
think
we
could
use
that
as
a
sample
application.
We
will
center
our
discussions
around
during
the
work
group
discussions.
Yeah.
A
F
Yep,
so
I
do
not
have
that
information
right
now
alex
to
be
honest,
but
we
will
go
ahead
and
seek
this
participation
from
members
of
sig
network
and
security.
So
we
already
have
the
chaos
mesh
folks
who
are
aligned
with
sig
network
tag
network,
and
I
think
we
have
a
meeting-
that's
coming
up
this
week
on
friday
to
state
their
goals
from
this
work
group,
and
so
we
will
have
that
information
in
and
then
we
would
need
to
get
the
same
sort
of
information
from
the
folks
at
tag
security.
F
D
F
F
So
it's
a
mix
of
both
types
as
of
today
and
there's
also
some
representation
from
the
the
vendors
of
chaos,
engineering
tools
themselves.
We've
got
some
responses
from
your
toolkit
folks,
for
example,
so
there
are
different
perspectives
that
are
coming
in.
I
think
we
will
have
more
information
more
thoughts
streaming
in
as
we
go.