►
From YouTube: CNCF SIG-App Delivery Meeting - 2019-09-11
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
A
A
B
The
document
is
open
for
for
editing
during
the
meeting
and
the
my
idea
was
that
the
people
who
are
on
the
call
give
them
like
a
very
short
time
to
introduce
themselves
where
they're
from
what
expecting
are
after
me,
like
just
really
one
sentence.
I
fully
make
this
quick,
but
I
think
is
that,
like
it's
the
first
meeting
to
get
to
know
what
the
people
who
joined
in
here
quickly
and
we
just
ideally,
we
just
go
down
the
list
pretty
quickly.
C
D
A
B
G
Hi
I'm
Alexis
I'm
just
joined
I'm
along
with
Michele
one
of
the
two
toc
sponsors
for
this
group
and
I'm
very,
very
pleased
to
see
that
we
have
a
you
know
fully
fledged
group
of
chairs.
We
can
run
it.
Thank
you
for
joining.
Thank
you
for
putting
yourselves
for
it.
Thank
you
for
getting
elected,
and
let
me
know
if
you
need
anything
to
help.
H
Guys
is
Mark
Chavez
I'm
from
Verizon
I
work
in
the
cloud
engineering
team.
Basically,
we
manage
the
kubernetes
platform
on
behalf
of
a
large
number
of
application
teams
within
Verizon.
One
of
the
things
that
we're
kind
of
looking
to
improve
is
how
we
can
more
rapidly
enable
cloud
native
application
development.
So
you
know
hence
my
keen
interest
in
this
sick.
B
Cube
con
yeah
since
I
was
in
contact
with
the
CF
team.
Your
very
brief
update
Nancy
is
out
of
office
this
week,
but
the
plan
is
that
we're
going
to
have
ideally
to
workshop
sessions
at
cube
con
where
we
introduce
the
sick
to
the
broader
community,
st.
cloud
Native
community
and
the
other
one
being
a
working
session.
So
a
China's
have
not
been
fixed
and
not
finally
confirmed,
but
this
is
supposed
to
happen
over
the
next
two
weeks
and
as
soon
as
we
have
more
details,
we'll
obviously
share
it
with
the
group.
B
G
B
B
Then
involve
themselves
in
the
activities
and
as
we
need
as
I
see,
the
need
for
tech
leads
even
more
and
open
to
appoint
them
as
needed.
I
think,
first
of
all,
we
need
to
get
into
working
more
to
work
on
specific
topics
first
and
then
move
forward
there
and
there's
somebody
thinks
they
already
see
the
need,
as
of
today,
for
for
exactly
for
the
group.
A
E
A
G
Can
say
a
few
words
about
that:
I
think
that
one
of
the
I
think
there
are
a
few
areas
where
we
can
make
rapid
progress.
I
think
one
of
them
was
there
was
a
landscape
and
text
on
an
e
task,
which
was
to
take
the
work
that
Gareth
began,
which
is
now
the
sort
of
humongous
Gareth
Brian
giant
spreadsheet,
of
everything
and
make
some
sense
of
that
ship
so
that
people
can
talk
about
it
together
without
meaning
different
things.
G
So
I'm
thinking
here
about
serverless
working
group
and
also
I
think
there
is
an
opportunity
if
you
want
to
take
it.
It's
up
to
you
to
create
a
password
group,
because
there
are
some
people
who
are
incredibly
excited
about
cars
and
they
can
go
talk
about
that
for
a
little
while,
but
I
think
the
main
tasks
are
the
landscape
and
also
a
sort
of
definition
of
what
is
at
delivery.
G
D
G
B
So
I
think
that's
pretty
much
in
line,
because
what,
if
I
had
in
there
anyways
I
think
brings
us
to
the
activities
piece
and
just
hi
so
for
today,
I
really
see
that
we
just
highlight
we'll
talk
about
activities
come
up
with
a
couple
of
action
items
for
the
next
meeting,
and
some
people
are
moving
in
forward
and
40.
Other
chairs,
please
add
to
it
to
to
to
my
overview
here,
but
we
have
we
have
in.
There
is
the
clarification
of
terminology
and
Harry
started.
B
The
document
here
I
think
this
is
in
step
number
zero
before
moving
into
the
landscape,
because
key
will
be
for
us
to
identify.
What
do
we
actually
want
to
have
your
landscape
there
like?
How
do
we
define
application
really
which
tool
in
which
capabilities
do
we
want
to
have
in
there,
which
then
leads
us
to
the
landscape
and
I?
Think
that
the
document
from
Gareth
and
Brian
is
a
great
starting
point
there
and
then,
maybe
here
you
can
walk
us
through
that
document,
then
you
start
it
there
yeah.
B
Then
yet,
then
it
goes
further
down
there,
like
the
maturity
map
of
that
delivery,
like
it
that
maturity
I
think
that's
sent
a
follow-up
step.
What
I
put
in
there
is
the
the
end
user
survey
and
the
idea
here
actually
is.
We
should
ask
people
where
they
would
need
most
help
right
now,
so
I
see
that
the
signals
are
contributing
to
whatever
people
are
struggling
with
the
most.
So
we
can
ask
them
is
the
biggest
problem
delivery?
Is
it
application
definition?
Is
it
rollout
processes?
Is
it
operations?
B
Is
it
monitoring
so
so
like
come
up
with
Melissa
questionnaire,
where
people
see
where
the
biggest
gaps
are
in
what
they
need,
which
and
then
hope
also
drives
more
more
of
the
upcoming
activities
as
well,
and
ideally,
this
is
something
we
can
put
together
also
rather
quickly
and
could
be
something
that
using
the
the
C&C
F
we
send
out
to
a
wider
audience
to
get
an
understanding
of
what
priorities
of
especially
the
end.
Users
are
right.
B
Now
one
proposal
I
put
in
there,
which
I
think
is
much
further
out
at
some
point
once
we
have
the
landscape
of
tools-
is
to
have
something
like
a
test
bed
where
people
can
easily
spin
up
and
an
application
delivery
test
that
and
most
few
seeing
different
tools,
different
open-source
projects
that
they
want
to
put
together
and
I
put
in
here
the
example
of
something
that
right
I
did
where
they
have
like
their
open
innovation
that
stack.
You
just
click
the
tools
that
you
want
for
certain
areas
and
kind
of
starting
to
connect
them.
B
E
Think
that
it
just
gives
me
wide
members
I
think,
is
interesting
and
mainly
just
comes
in
some
language
from
the
agenda
that
just
caught
my
eye
and
the
idea
with
being
black-white,
clicker,
singular
and
it
being
on
a
fixed
cadence
and
rather
than
it
necessarily
being
wider,
is
all
around
a
specific
topic
and
I'm
not
sure.
If
other
people
have
like
strong
opinions,
there.
E
E
There'll
be
other
areas
where
it's
basically
a
very
much
a
Wild,
West
environment
and,
like
some
of
those
might
make
sense,
ends
earlier
different
times
to
have
a
specific
I
kept
around.
So
an
example
might
I'm
not
saying
this
is
definitely
the
room
to
do
or
even
wanted
to
do,
but
maybe
continues
like
continues.
Integration
tools
for
kubernetes
conflict
like
something
that's
specific
or
maybe
something
more
general,
like
even
continuous
deployment
as
a
space.
A
B
Yeah
I
can
see
a
pointer.
Maybe
if
you
have
more
clarity
in
certain
items
and
others,
it's
helpful
I
think
it
might
also
help
us
to
break
down.
Maybe
the
people
are
working
on
something
into
smaller
working
groups
like
you,
for
example,
think
about
like
the
topic
could
have
a
brought
up
around
the
application
definition,
so
we
could
work,
maybe
an
application
definition.
At
the
same
time,
we
could
look
at
continuous
delivery
best
practices
because
it's
yeah
we
could.
E
B
J
E
B
B
You
can
define
for
certain
tools
like
a
set
of
capabilities
that
you
want
the
tool
to
have
or
not
have
because
everybody
wants
like
be
on
every
possible
box
and
if
you're
in
a
CNCs
landscape,
that's
maybe
the
goal
of
your
marketing
team,
but
it's
not
even
a
more
helpful
to
the
user.
I
think
you
can
also
drive
some
of
the
direction
like
if
you
want
to
be
continuous
delivery
tool,
you
have
to
support
like
I,
don't
know:
Bluegreen
deployments,
cannery
deployments
these
kind
of
things.
B
You
have
to
be
able
to
work
with
application
definitions
and
this
in
this
way
you
have
to
be
able
to
do
this.
I
would
say
this
will
be
longer
discussions,
but
I
think
this
will
be
good
discussions,
all
the
ways,
the
tool
providers,
and
then
you
would
know
that
if
it's
in
the
landscape
it
provides
a
certain
set
of
capabilities
or
might
even
though
it
provides
most
of
it,
but
missing
XYZ,
so
white,
a
might
be
controversial,
I
think
it's.
It
could
be
helpful
to
really
move
to
move
that
space
forward.
F
Can
I
add
something
to
this
just
stuff
we've
seen
a
lot
of
is
a
lot
of
people.
Adopting
kubernetes
are
basically
doing
Greenfields
apps,
but
vast
majority
moving
kind
of
legacy
systems
across
and
basically
need
to
know
how
to
how
to
take
these
systems
and,
if
they'll
run
on
kubernetes,
and
you
know
what
they
need
to
look
like
to
run
on
there
I
think
we're
in
things
that
could
be
really
useful.
Oh,
that
this
is
kind
of
gone
down
their
capabilities
Road,
which
is
based.
F
You
know
what
things
do
you
need
to
consider
for
your
application
to
move
around
to
kubernetes.
You
know
things
like
communication
service
discovery.
You
know
secrets
all
that
types
of
we
have.
We
all
have
that
stuff
going
but
kind
of
giving
it
giving
us
giving
that
kind
of
a
set
of
areas
that
you
need
to
consider.
So
the
point
is
considerate
and
then
so
that
could
be
a
definition
of
the
app
and
then
the
supporting
external
tools
would
be
your
CI
pipelines.
F
Your
you're
testing
your
deployment,
all
that
type
of
stuff
do
not
make
because
we
see
the
last
week
we
get
a
lot
of
kind
of.
Oh,
we
want
to
build
this
unbelievably
VM
based
application
on
to
kubernetes,
and
they
don't
realize
how
much
work
is
about
add
it's
like
I'm
one
of
those
hundreds
of
questions,
but
there's
this
there's
there's
many
many
areas
to
consider
before
moving
across
I'm,
not
talking
about
decomposing
applications
right
that
type
of
stuff.
F
Do
you
think,
like
you
know
how
you
probably
have
more
operators
or
whatever
you
know,
and
you
could
give
advice
on
that,
because
we're
I
think
people
need
advice,
not
our
you
know
kind
of
boundaries,
not
necessarily
you
know,
use
spinnaker,
use,
Jenkins
or
use
whatever
the
tools
would
come
out
and
the
vendors
are
very
good
at
marketing
their
tools
in
that
one
first
capabilities,
probably
better
aspect
to
look
at
so.
B
Yeah,
if
I
understand
you
correctly,
this
is
really
how
does
a
replication
deliver
a
change
from
your
traditional
model
to
the
Terra
native
kubernetes
model,
and
we
focus
on
this
one
as
a
transition
about
the
application,
with
some
implications
on
the
app
yeah
like
the
whole
model,
is
to
micro
services
piece.
We
leave
out
of
this
because.
G
H
G
Speaks
to
the
second
objective
after
the
landscape,
which
is
the
one
that
tells
ads
proposed
on
the
email
list,
which
is
to
have
some
sort
of
working
sketch
of
what
application
application
delivery
means
in
a
cloud
native
setting,
without
necessarily
referring
to
particular
technologies.
But
talking
about
patterns
and
principles.
Yeah.
B
B
Okay,
then
I
would
propose.
We
use
the
remainder
of
the
time,
maybe
to
jump
into
the
document.
Harry
already
started.
Maybe
here
you
can
share
and
walk
us
through
what
you
already
did
around
the
terminology.
Doc
I
think
that's
where
what
gets
us
into
working
mode
is
the
first
piece
that
we
have
around
yeah.
C
So
I've
already
started
a
job
talk
about
the
terminologies
in
scope
of
the
cloud
native
application
lifecycle,
so
I
think
I
clear.
That
is,
the
goal
of
this
documentation
is
just
like
step,
zero
of
all
the
activities
we
want
to.
We
want
to
do
so.
We
want
to
clearly
define
the
terminologies
in
this
field
and
because
what
is
being
over
scope
of
what
is
not
so
there
are
several
technologies
already
released
here,
for
example,
what
is
application
or
what
is
of
this?
C
B
Just
quickly
jump
in
here
what
I
think
we
put
into
the
gold
overall
and
what
became
clear
to
me
during
this
meeting
I
think
we
should
define
cloud
native
applications
they
pass
by
itself
as
well
so
I
just
put
in
my
personal
opinion
here
pretty
much,
but
but
because
I
have
people
look
at
what
what
did
all
entails.
Mm-Hmm
so
that
we
have
a
definition
of
what
we
like
on
the
bigger
picture
are
working
on.
B
So
for
me
that
that's
again,
just
my
getting
so
opinion
is
really
from
the
time
you
have
an
artifact
available
to
the
way
you
deploy
it.
You
test
it.
You
security,
audit,
you
operated,
you
run
it
and
retire.
The
application,
which
is
just
the
starting
point,
so
feel
free
to
like
this
document
is
also
shared
with
people,
so
that
they
can
also
comment
on
this
I
was.
E
C
C
So
we
want
that
part,
but
we
also
could
also
explain
what
is
a
relationship
between
CI
and
the
application
believe
you
can
actually
choose
any
kind
of
CI
system
and
all
three
who
were
user
to
make
the
season,
but
when
we're
talking
about
the
steady
part,
we're
actually
hoping
that
you
know
there
are
some
standard
or
you
know
best
practices
program
clarified
in
the
sake
application
kind
of
like
that,
and
we
may
also
extend
little
bit
about
what
is
seedy
about
the
relationship
in
City
and
application
delivery.
Go
from
my
point
of
view.
C
The
Stig
is
actually
talking
about
a
specific
technologies
and
the
practice
is
about
continuous,
actually
continues.
Did
you
don't
have
to
use
it,
but
this
will
be
more
like
a
best
practice
yeah
for
technology
part.
Besides
the
the
application
delivery
or
the
application
flavory,
we
actually
need
to
explain
something
like
what
eight
application-
and
another
thing
I
want
to
add
here
is
application
instance,
because
we
are
talking
about
Iran
hi
becomes
that
here,
for
example,
a
kubernetes
deployment
very
replicas
equals
to
three
actually
has
three
application
instances.
C
C
These
or
app
for
some
application
angle
or
purpose
home
the
two
levels,
and
not
only
extend
it,
abated
application
versus
workloads,
because
this
is
actually
to
be
confusing
for
many
people.
I
think
we
already
know
that
application
is
just
a
collection
of
the
configuration,
but
actually
what
the
content
is
rigged
up.
You
could
seek
apps
recovery,
it's
more
likely
mechanism
from
the
platform
to
operate
the
application
instances
automatically.
C
So
it's
something
like
kubernetes
deployments:
they
posted
there
are
all
workloads
and
the
kubernetes
operator
is
just
another
kind
of
workloads
which
is
you
know,
rhythm
by
user
itself.
So
I
think
we
need
to
make
make
it
clear
boundary
between
applications
and
workloads,
because
they
are
ladders,
actually
a
lot
of
project
which
I
think
they
are
working
on
the
workloads
that
sometimes
they
claim
themselves
they're
working
on
applications-
and
we
want
to
you
know-
maybe
fix
this
confusion
in
the
future
and
for
platform
I'm.
C
Talking
about
you
know
the
runtime
layer
to
provide
various
ability
to
run
application.
In
most
cases
it
could
be
kubernetes,
but
we
I
think
we
don't
want
to
do
six
of
the
application
delivery
to
kubernetes.
Only
so
if
users
trying
to
highly
application
delivery
model
to
function
and
service
or
forget
or
cholera
and
anything
which
can
run
container
I,
think
it's
fine
after
we
have
some.
C
You
know
the
terminologies
that
I
will
also
introduce
the
model
here,
which
actually
explains
the
phases
in
an
AP
application
lifecycle
which
actually
you
inspired
a
lot
from
Eliza's
previous
email,
talking
about
the
lifecycle
and
application
delivery.
So
it's
like
from
application
definition
to
application
deployment
rolled
the
application,
automation,
operation
and
at
Landstuhl
platform,
and
the
first
three
part
will
be
the
main
concerns
of
these
applications.
The
state
application
delivery.
Well,
the
application
to
automation
of
the
operation
which
focus
on
application
instances,
which
is
now
more
focused
by
the
kubernetes,
the
gaps.
C
So
you
can
see
how
this
two
six
competitor
and
for
the
platform
constants
is
not
the
concerns
of
this
week,
but
we've
also
cooperative
in
the
platform
concerns
like
well.
Cooperative,
eight
kubernetes
for
cooperative
is
anything
which
can
run
the
the
the
applications
and
this
image
is
it
actually
editable
in
these
slides?
C
So
if
you
have
any
stress,
changes
or
any
comments,
just
you
can
just
edit
the
picture
there,
so
this
documentation
are
fully
complete
yet
because
maybe
we
think
maybe
we
will
add
more
terminologies
here
and
as
alloys
transformation
that
we
want
to
have
a
very
clear
definition
for
the
Chlo
native
app
delivery
unveil
yeah.
So
this
is
pretty
much
about
this
documentation.
I
believe
this
dr.
tation
should
be
finished
after
the
next
meeting,
because
this
is
the
very
quick
work,
and
this
is
the
start
of
all
the
other
activities
that
we
want
to
reach
women.
F
F
So,
for
example,
let's
say
things
like
we
see
done:
I've
seen
is
basically
people
logging
to
files
and
try
to
log
two
files
a
container
as
opposed
to
just
to
stand
out.
You
know
so
the
actual
application
functionality
itself,
that
is,
that
will
work
with
that
would
make
it
work
well
in
in
kubernetes.
You
know
so,
if
they're,
if
they're
doing
things
like
premedia,
scraping
or
all
that
so
using
the
the
functions
that
the
platform
provides.
Is
that
in
scope
or
that
otoscope
I.
C
F
Oh
yeah,
what
a
big
property
this
basis!
So,
if
you
take
a
nap,
let's
say,
for
example,
spring
boot
up
and
they
want,
they
want
to
learn
in
secrets
of
conflict
different
ways.
They
can
load
that
in
as
such,
depending
on
spring
boot,
but
that's
power
of
the
application.
The
platform
will
would
provide
secrets
and
conflicts,
not
necessarily
a
subsidy
application,
consumer
research.
So
we
are
we
at
the
secrets,
a
concrete
level.
Are
we,
the
application?
Conservative
I
think
it
I.
B
B
So
basically
have
an
of
micro-services
all
the
configuration.
That's
needed,
like
databases
secrets
all
of
these
things,
and
how
do
we
find
like
this
whole
thing
as
as
a
unit
together
like?
What's
the
way
to
actually
find
this
I
was
you
can
ask
a
Yammer
file
for
my
I
can
have
the
Yammer
file
for
my
service
definitions,
I
have
my
C,
or
these
have
obviously
my
secrets
and
all
of
this,
but
how
is
like
the
whole
thing
defined
as
a
whole?
That's
also
a
I
think
you
eventually
ended
up
with
helm
charts
here.
B
So
so
my
proposal
would
be
that
all
the
people
on
the
call
at
in
anything
they
want
to
see
or
that
they
usually
define
as
part
of
the
application,
I,
think
secrets
and
stuff.
This
is
a
good
point.
There
I
think
we
were
storing.
Maybe
a
bit
more
from
a
superficial
perspective
is
how
can
I
even
say
that,
like
five
services
belong
together
and
everybody
else
understands
what
I
want
to
do
here
and
pajamas,
he
goes
beyond
that,
and
then
we
have
fix
your
own
dependencies
that
you
might
want
to
map
in
there.
B
K
C
I
agree
with
the
logs
here:
actually,
the
configuration
of
your
dependencies
or
whatever
you
need
to
wrong
application,
is,
thankfully
blown
into
the
definition
of
application.
Well,
the
concrete
the
unit
of
the
hennas
itself,
for
example
team,
ICU
or
the
new
signature
self,
is
it's
not
in
scope
by
the
configuration
for
that.
J
B
That
that
could
beat
that
I
think
that's
a
good
action
to
really
find
what
we
want
to
define
as
part
of
awesome
application
resolution
and
as
people
have
done
this
in
the
past,
I
think
of
that
people
have
unit
experience
that
they
can
share
yeah.
That
area,
possibly
agreeing
on
what
we
will
define
is
a
delivery.
A
All
right,
it
sounds
good,
so
I'm
hearing.
How
long
do
you
I
mean
I
know
this
document
is:
is
brand
new?
How
long?
How
long
are
we
gonna
sit
on
this?
What
what
is
what
is
the
next
action
item
after
we
finish
this.
C
Document
yeah,
so
the
next
action
about
this
documentation
is,
will
will
trying
to
open
the
review
for
the
whole
community.
Well,
I
think
we
will
would
love
to
stand
off
the
link
to
the
committee
members
to
comment
and
a
review
the
documentation,
and
we
will
finish
the
terminology
part
as
soon
as
possible.
So
we
just
want
to
include
very
essential
concept
in
this
darkness.
C
We
don't
extend
everything
and
just
make
sure
that
the
next
steps,
like
you
are
working
on
land
scope
and
we
are
working
on
any
kinds
of
artifacts
of
delivery
of
deliverables
from
the
city.
We
will
focus
on
the
same
page
here
so
when
we
talk
about,
for
example,
in
talking
about
applications,
even
though
okay
we're
talking
about
the
group
of
configuration,
so
that
is
the
main
purpose
for
documentation.
It
should
be
finished.
A
very
quick.
A
All
right
that
sounds
that
sounds
great
yeah.
Well
guess
what
we'll
probably
do
is
I
mean
I
know
we
did
it
in
the
slack,
but
it
also
should
go
out
from
the
mailing
list
as
well,
and
just
just
so
people
know.
What's
going
on.
C
Yeah,
so
in
the
next
meeting
I
will
expect.
We
will
stand
out
the
final
version
of
a
documentation
for
the
snake
to
take
Lucan
to
relieve
it,
and
they
may
agree
that
they
already
you
know
it's
it's
already
staged,
then
we
can
move
to
the
next
steps
to
do
the
landscape
and
and
then
of
course,
we
can
actually
start
to
defy
the
categories
of
the
landscape,
which
I
think
is
also
very
important
for
us
to.
You
know
you
can
do
credit
landscape
work.
K
Hi
guys
I
just
wanted
to
to
make
a
comment
here
that,
since
we
are
kind
of
breaking
new
ground,
I
think
it
would
be
helpful
for
us
when
we
are
talking
about
defining
terminology
and
setting
our
scope
for
what
we're
doing
that.
Maybe
we
provide
also
examples
of
what
we
consider
to
be
in
the
range
of
the
scope
of
the
project
and
what
might
be
outside
of
the
range
of
the
scope
as
well
as
when
we
consider
terminology
in
terms
of
what
does
it
take
to
deploy
an
application
on
kubernetes?
K
You
know
some
examples
of
what
do
we
consider
in
the
range
of
the
types
of
things
that
we're
gonna
be
discussing,
whether
it
be
secrets
or
hump,
charts
or
llamó
files
or
whatever
that?
Perhaps
maybe
we
give
some
specific
examples
just
so
that
we
can
call
out.
What's
what
what's
in
and
what's
out,
I
will.
C
Expect
that
to
the
the
members
of
the
landscape,
they
understand
it
correctly,
I
mean
full
detailed
part.
Maybe
of
least
you
know,
example,
they
will
be
part.
They
will
be
the
item
in
the
landscape
like
application,
packaging
or
application
application
packaging,
and
there
will
be
also
the
category
in
landscape
like
up
indignation,
and
there
will
be
examples.
Two
projects
listed
here
so
which
one
doing
the
elevation
on
doing
this
I
think
that
even
more
likely
purpose
for
landscape
it
I
think
it
went
okay.
K
B
K
Don't
misunderstand
me:
I'm
not
trying
to
say
that
we
show
an
example
of
what
we
consider
a
good
practice
or
bad
practice,
but
simply
if,
if
it
helps
to
clarify
the
scope
of
what
we're
discussing
that,
we
can
say
this
item.
For
example,
we're
not
going
to
include
in
this
discussion
or
in
terms
of
what
we
consider
deploying
an
application
simply
to
help
set
the
clarity
around
the
scope
of
what
we're
trying
to
do.
C
Agree
that
we
can
actually
at
a
concrete
example
like
Yama,
fell
in
the
documentation
to
explain
what
it
is.
It's
actually
make
a
lot
of
sense
to
do
that.
I
believe
that
yeah
but
I
don't
know
I,
don't
hesitate
to
specific
to
knows
some
specific
project
in
the
terminal
and
unique
technology.
Oh.
J
K
B
And
yet
it
does
make
sense
and
I
think
given
every
after
next
meeting
in
two
weeks,
and
you
really
want
to
make
progress
on
this
I-
think
that's
really
what
we
should
be
focusing
on
like
this
application
definition
piece,
don't
really
have
progress
around
for
the
next
meeting.
Still
we're
like
a
reasonably
sized
group
I
think
we
shouldn't
take
on
too
much
work
for
the
next
week,
and
this
is
still
vague
enough.
My
proposal,
would
you
really
focus
our
energy
for
the
next
week
on
this
one.
B
F
B
D
B
F
F
B
A
E
Been
adding
to
it
it's
public
for
all
the
people
who
were
on
the
previous
national
group
Mentalist
base
very
much
out
of
day
a
lot
of
the
day,
Saturday
and
I.
Think
it's
a
useful
list
at
this
point.
None
of
the
data
is
useful
and
also
the
mechanism
that
was
used
was
very
much
just
fighting
time
so
like
maintaining
yeah
like
I,
definitely
wouldn't
recommend
as
maintaining
that
or
necessarily
using
Google
Spreadsheets
I.
E
Think
it's
worth
a
conversation
about
how
we
like
how
we
maintain
the
data
and
try
and
like
slice
and
dice
it
I
I,
don't
think
a
spreadsheet
is
the
right
long-term
answer.
Whilst
there
right
now
is
definitely
a
snapshot,
have
you
didn't
try
and
have
some
time
about
what
might
make
sense
to
yeah?
That
would.
E
B
A
Cheers,
thank
you
all
right.
So
we're
moving
down
a
list,
I
think
we're
about
done
here
today.
I
guess
we
will
meet
again
in
two
weeks
on
this
Wednesday
at
the
same
time,
but
before
everyone
leaves
I
would
like
to
see
lots
of
comments
on
this
central's
of
cloud
native
app
stock,
because
I
will
have
quite
a
few
and
because
this
is
very
important
to
at
least
get
the
words
of
what
we're
talking
about
correct.