►
From YouTube: CNCF SIG-App Delivery Meeting - 2019-07-17
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
B
So
I
kick
things
off
and
then
you
guys
can
you
folks
can
take
over.
So
this
is
Alexis
speaking
I'm,
the
TOC
representative,
along
with
Michele
for
this
new
CN
CF
sig,
app
delivery,
which
is
forming
it
has
not
fully
formed
yet
on.
This
call
are
some
initial
volunteers
from
the
community
who
hope
to
participate
in
getting
the
Charter
into
shape,
and
some
of
you
may
have
put
your
hat
in
the
ring
for
being
a
chairperson,
I
believe,
went
incorrect,
Mia
Farrow
and
we
ended
up
with
three
three
chair
seats.
B
Think
we
are
vanilla.
Actually,
this
is
a
good
opportunity
for
me
to
ask
everybody
on
the
call
if
they
understand
what
is
expected
around
the
chairs
and
if
this
is
all
surprise
to
them,
if
you,
if
this
is
all
brand
new
to
you
should
say
so,
we
can
talk
through
how
it
works
and
Michelle
posted
a
form
to
fill
in
on
the
on
the
new
email
list
that
you're
all
on
I
think
a
little
while
back
so
can
I.
Just
ask
everybody
if,
if
you're
aware
of
the
chair
system.
E
D
Yeah,
it's
fairly
straightforward
if
you're
familiar
with
kubernetes
SIG's,
it's
not
that
different
from
from
a
point
of
view
of
leadership.
So
the
idea
is
that
there
are
typically
two
sort
of
sets
of
tasks
that
are
required
to
make
these
SIG's
effective.
The
one
set
of
tasks
are
very
deeply
technical
and
required,
typically
quite
a
lot
of
time.
In
the
case
of
these
CN
CF
SIG's,
those
might
involve
you
know,
reviewing
code
digging
through
repositories.
You
know
testing
systems,
this
kind
of
stuff
and
people
with
strong
technical
skills
in
the
particular
areas
are
required.
D
For
that.
The
the
other
set
of
tasks
are
I,
don't
mean
that
disarm
any
sort
of
less
important
but
they're
more
of
a
sort
of
an
administrative
nature,
a
leadership
nature.
So
people
making
sure
that
you
know
all
the
stuff
gets
done
on
time
that
that
meetings
get
held
properly,
that
the
right
people
are
there
and
that,
where
necessary,
if
there
are
disputes
that
they
get
resolved
in
an
in
a
sensible
fashion
which
are,
you
know,
require
a
significant
amount
of
technical
understanding
of
the
domain.
B
A
A
B
B
So
once
we've
got
up
and
running,
you
know
the
chairs
and
the
community
will
have
many
interactions
we
hope
with
with
all
of
the
TOC
and
through
that
process,
we'll
get
to
a
place
where
you
know.
We
have
clear
goals
that
we
all
agree
on
that
are
adding
value
around
this
particular
segment
of
the
market.
B
Now
we
want
to
get
this
charter
into
a
place
as
soon
as
possible,
where
it
can
be
voted
on,
which
means
that
it
will
be
presented
to
the
voting
TOC
on
a
public
call,
and
it
will
be
asked
whether
or
not
this.
This
is
ready
for
a
vote,
and
if
it
people
say
it
is
ready
for
a
vote,
then
a
vote
will
be
called
and
will
need
to
be
approved
by
quorum
as
of
the
Charter.
B
B
Therefore,
if
we
could
get
this
charter
into
shape,
where
it
can,
you
voted
ASAP
now
we
need
for
that
to
happen,
for
somebody
to
volunteer
to
be
the
chief
editor
of
the
document,
but
anyone
like
to
be
either
the
chief
editor
or
one
of
the
two
or
three
editors
you
get
it
into
a
readable
form.
Taking
into
account
all
these
lovely
comments
on
the
right
hand,
side
yeah,.
F
It
seems
like
you
might
be
best
to
have
a
couple
people
sort
of
have
offline
meetings
to
discuss
each
comments
and
stuff
and
sort
of
get
agreement.
And/Or
consensus
among
this
group
and
then
you
can
approve
or
reject
like
the
comments
appropriately
and
I
want
my
volunteering.
For
that
say
anyone
else
wanna
volunteer.
B
A
D
B
If
we
can
hope
to
get
this
into
at
least
ad
commented
form
by
the
end
of
next
week,
I
think
they'll
be
great
progress
anyway.
So
maybe
the
three
of
you
could
huddle
offline
to
do
that.
Thank
you.
So
where
do
we
look?
Why
don't
we
go
through
the
document
together
now
piece
by
piece
and
we
can
make
sure
we
understand
what
it's
saying
have
discussions
on
points
where
there
appears
to
be
contention
Alice?
Do
you
want
to
lead
us
through
that?
Can.
B
B
We
should
make
sure
that
the
people
who
are
on
that
on
the
mailing
list
and
slack
channel
for
the
sig
as
it
is
today,
have
a
chance
to
contribute
and
are
aware
that
this
is
an
important
question
that
we're
discussing
and,
secondly,
I
think
we
need
to
surface
it
to
the
TOC
as
well
a
little
bit,
because
these
are
kind
of
major
strategic
matters,
but
but
as
a
first
step
yeah
before
we
go
into
the
line
by
line.
What
does
anyone
want
to
advocate
strongly
for
or
against
developer
tools
being
in
the
app
delivery?
So.
G
Part
of
why
I'm
involved
in
this
working
group
is
that
there's
a
lot
of
gaps
and
our
company
in
terms
of
where
some
of
the
things
people
are
writing,
like
Helmand
other
things
start
and
where
you
actually
have
a
working
system.
So
part
of
my
interest
is
working
on
that
and
and
I
think
it
would
involve
at
some
point.
You
know
completing
the
solution,
at
least
what
kubernetes
delivers.
You
know
to
provide
this
I,
don't
know
how
we
get
to
that
without
some
sort
of
a
development
you
know
a
code
or
something
so
I
guess.
D
Maybe
maybe
a
good
question
to
ask
is:
do
we
believe
that
stuff
to
be
in
scope
for
the
CNC
F?
If
it's
out
of
scope
for
the
CNC
F,
then
we
don't
really
have
a
problem
if
it's
in
scope,
forests
for
the
CN
CF,
but
out
out
of
scope
for
the
sig,
then
which
sig
is
it
in
scope
of
I?
Think
that's
sort
of
in
my
mind
the
three
questions
we
need
to
answer,
one.
B
Thing
that
we
may
end
up
doing
with
some
facilities
areas
is
punting
them
into
a
subsidiary
working
group.
For
for
the
time
being,
so
you
know
we're
not
trying
to
have
too
many
things
at
once
to
begin
with,
and
there
are
things
which
are
going
to
slip
out
of
the
core
charters
of
each
C
so
having
them
sort
of
tagged
on
the
end
of
one
of
these
things
in
the
form
of
a
working
group
for
now
may
be
a
good
thing
to
do,
but,
yes,
I,
think
starting
with
should
cloud
native.
B
H
High
I
do
I
think
that
if
app
delivery
is
about
CI
and
things
that
you
deal
with
a
couple
of
times
a
day
that
the
development
process,
where
you're
doing
things
many
times
an
hour,
is
a
difference
that
matters,
but
also
is
clearly
related
that
it's
the
same
thing
but
done
more
often,
and
so
yes,
I-
think
that
AB
delivery
being
about
how
you
get
code
into
a
cluster
that
you
also
want
to
do
during
development.
It
should
fall
under
this
chart
right.
B
A
Adoring
the
counter
view,
so
what
I
found
very
helpful,
which
we
can
level
to
discuss
on
the
mailing
list
and
I
thought
that,
like
on
the
major
points,
just
started
to
write
on
these
its?
If
it's
confusing,
because
we
have
slack
mailing
list
so
it's
meaningless.
But
what
would
the
actual
deliverables
be?
That's
always
helpful
for
me,
but
I
wanted
to
work
on
something
and
differentiate
a
topic,
that's
interesting,
but
think
of
okay
in
like
three
to
six
months.
What
could
we
actually
have
as
an
output
of
the
working
group
regarding
any
any
topic?
I.
A
It
but
the
way
I
would
challenge
it.
What
would
be
the
outcome
that
we
expect
or
the
deliverable?
If,
even
if,
it's
just
a
backpack,
the
best
practice
document
doesn't
need
to
be
a
standalone
project
or
something
that's
the
way
I
would
challenge
it,
because
otherwise
it's
part
of
charter,
but
we
don't
know
what
we
actually
work
against.
D
D
Well,
that
proposes
that
the
primary
responsibilities
are
one
to
educate
end-users
and
projects
so
take
you
know
all
that
information
that
scattered
all
over
the
internet
and
condense
it
into
more
easily
consumable
forms
one
form
of
those
is
white
papers,
the
other
ones.
You
know
presentation,
other
things,
secondly,
is
is
look
at
a
sort
of
strategic
view
of
the
area.
So
if,
if
we
disbelieve
will
scope
ranges
from
you
know
coding
tools
to
to
CICE
or
whatever
I'm
just
making
up
words
now,
but
whatever
that
scope
is
you
know
what?
What
part
of
that
do?
D
We
want
to
have
as
part
of
the
CN
CF,
which
parts
do
we
want
to
keep
outside
of
CN
CF?
How
do
they
interface
with
each
other?
Are
we
missing
key
projects
do?
Do
we
think
we
need
a
CI
CD
system,
for
example,
whatever
that
might
be?
Do
we
need
more
than
one
answering
all
these
questions,
debating
them
out
and
answering
them
and
coming
up
with
a
position
that
is
recommended
to
the
TRC?
Who
can
then
say?
Yes,
we
agree
with
you
all
no
go
back
and
do
some
more
homework
identity,
I.
G
Think
a
target
state
for
you
know
how
you
do
application
delivery
would
be
a
good
starting
point
for
us
to
agree
on
I,
guess,
I,
think
and
I.
Think
and
people
are
writing
tools
in
here,
but
I
think
we'd
be
interesting.
You
see
how
people
have
put
together
things
around
kubernetes.
You
know
to
do
some
of
these
things
and
then
maybe
from
that
you
could
infer.
G
F
During
the
last
two
coop
comes
in
the
service
working
group
sessions,
I
kind
of
forced
the
audience
to
participate
in
a
little
bit
of
a
birds
of
a
feather
session,
just
to
get
some
input
from
them
in
terms
of
what
they're
doing
the
server
lists
or,
if
they're
not
using
it.
Why
not-
and
it
was
actually
really
really
helpful
for
me
to
understand
why
more
people
haven't
adopted,
serverless
and
I-
think
the
the
reactions
I
got
also
applied
to
to
containers
in
general.
F
Is
why
I'm
bringing
it
up
here
and
it's
a
lot
of
it-
was
around
things
like
they
didn't
know
how
to
break
up
the
monolith
into
smaller
pieces,
whether
it's
for
micro
services
or
functions.
They
didn't
know
whether
there
was
a
sufficient
tooling
around
getting
their
job
done,
and
so
I
think
that
this
topic
sort
of
touches
on
those
exact
sort
of
concerns
that
I
was
hearing
from
the
community
and
that's
kind
of
why
I
voted.
F
A
Think
if
you
have
a
reasonable
amount
of
people
who
obviously
boatful
yes,
another
good
point
also
came
up
in
the
chat,
especially
the
topic
around
development.
Local
development.
Local
debugging
is
how
many
run
your
micro
services
before
and
those
running
in
the
cluster,
but
I
think
the
agreement
is
overall
in
the
beginning,
it's
more
as
best
practices
and
more
as
shared
tool,
development
practices
across
companies,
and
that
would
be
valuable
for
people
opting.
A
It
also
heard
that
Monell
is
to
micro-service
discussion,
which
must
be
a
bit
of
a
challenging
topic,
but
I
think
the
outcome
overlays.
It
is
best
practice.
Isn't
it
just
happy
the
collection
it
makes
sense
and
I
think
it's
totally
fair
for
a
special
interest
group
to
have
education,
material,
blog
posts,
white
papers
or
whatever
it
is,
and
I
also
believe
it's
helpful
for
people
to
have
this
in
there.
So,
let's
from
that
perspective,
I'd
say,
let's
include
it
and
also.
D
Thing
I've
noticed
sorry,
one
quick,
brief
coming
Alexis
I
know
that
there
is
so.
This
is
a
fairly
broad
area.
If
you,
if
you
go
across
all
of
you,
know,
IDs
and
and
passes,
and
CI,
CDs
and
all
sorts
of
other
related
technologies
and
I
know,
there's
a
concern
that
that
may
just
be
too
broad
to
to
tackle
as
a
new
cig.
So
you
know
one
way
of
mitigating.
That
is
to
say
you
know
over
time.
D
A
G
K
Another
thing
actly
were
seeing
is
very
related
to
see
I
I
I
would
prefer
to
see
that
big,
separate
CI
and
city
with
a
clear
boundary,
because
CI
is
more
about
how
to
shape
your
source
code
to
a
runnable
image
or
anima
banner
it.
But
city
is
more
like
hub
to
shape
your
binary
and
an
image
to
real
cluster
and
to
running
application,
which
has
clear
bungee
here.
I
wish.
G
E
It's
hi-
this
is
gonna
I,
have
seen
in
practice
at
box
that
one
CI
NCD
are
definitely
distinct.
They
do
sometimes
have
very
intricate
relationships
between
themselves
and
feedback.
Loops
and
I
have
to
be
taken
into
account.
So
as
an
example
in
some
CIS,
you
can
actually
do
a
deployment
in
a
you
know:
sandbox
environment,
so
there's
a
lot
of
correlation
that
happens
between
them.
So,
even
though
we
tried
hard
to
separate
those
out,
it's
very
hard
to
really
draw
very
clear,
hard
boundary
between
them.
In
my
experience.
D
B
Secret
different
I'd
have
them
in
different
sayings.
So
I
think
this
is
an
artifact
of
us
trying
to
form
some
SIG's
without
forming
lots
and
lots
of
them
all.
That's
all
the
time,
so
I
think
for
now
I'm
happy
with
the
sort
of
reason
you're
Catholic
approach.
But
yes,
if
we
did
have
the
specification
of
just
a
CI
CD
C,
then
we
I
would
be
expecting
other
things
to
pop
up
elsewhere.
D
Maybe
maybe
a
solution
that
that
keeps
everyone
happy
in,
particularly
yourself,
because
you
are
the
Sigma
that
the
TSE
represented
is
to
have
formal
working
groups
so
that
the
sink
covers
all
of
the
areas
we
mentioned.
But
it
has
formal
working
groups
focused
on
on
specific
areas,
CIC
D
being
one
of
them.
D
A
B
A
Different
in
a
monolithic
application
when
wirelessly
building
the
entire
app
and
then
ship
it
so
it's
much
closer
together
in
a
little
micro
service,
type
of
environment,
that
more
into
the
environment
and
parts
of
used
to
be
like
take
together,
lay
down
part
of
the
delivery
process
that
you
also
see
with
best
practices
around
the
green
deployments.
Cannery
deployments
these
type
of
things.
They
can
be
treated
very
differently
from
building
the
actual
artifact
and
how
the
artifact
should
be
at
all.
So
for
us,
we
we
treat
them
differently
so
between
CI
Frankie,
D,
yeah
thanks.
A
What
I
just
pasted
in
here
are
not
to
make
the
document
even
more
crowded
and
messy,
but
I
took
this
day,
one
to
the
end
operations
model,
and
maybe
it
helped
us
to
say
okay
like
because
we
talked
about
a
profession,
you'll,
never
read
to
say:
can
we
focus
on
this
and
we
definitely
leaf
out
other
pieces
just
as
a
conversation
standard
enough
to
take
business?
The
final
of
one
of
the
questions?
Okay,.
B
J
B
We
started
the
call
with
a
describing
what
we're
trying
to
do
on
this
core,
which
is
within
a
preliminary
state.
Still,
these
are
initial
members,
volunteering
in
this
in
the
CN
CF
community
to
help
set
up
the
app
delivery
stake
and
get
going.
We
hope
to
have
feature
calls
as
well,
of
course,
as
well
as
using
the
mailing
list
and
slack.
This
call
is
currently
being
recorded
and
will
be
made
public.
B
The
initial
conversation
was
around
the
chairperson
roles
and
a
few
people
are
new
and
had
brought
up
to
speed
on
what
was
going
on
there
and
I
reminded
people
that
there
is
the
opportunity
to
put
your
hat
in
the
ring
to
volunteer,
to
stand
as
one
of
the
three
chairs
and
then
Quinton
talk
people
through
a
bit
about
the
the
kind
of
template
governance
structure
for
these.
For
these
things
that
we've
essentially
can
Herot
it
into
this
into
this
one.
B
B
B
It
would
be
great
if
we
can
get
the
comments
off
the
document
and
get
it
into
a
readable
format.
Him
that's
the
important
first
step
then,
rather
than
I,
was
proposing
the
Australian
to
discuss
in
the
Charter,
but
it
was
pointed
out
there
a
couple
of
quite
big
lumps
in
the
carpet
or
elephants
in
the
room,
if
you
prefer
that
a
metaphor
around
whether
or
not
dev
tools
should
be
part
of
cloud
native
and
that's
and
that's
whether
they
could
be
file
on
this
thing
and
whether
or
not
there's
also
same
question
ramp.
B
As
so,
we've
been
discussing
that
since
the
beginning
of
the
call
and
I
imagine
there'll
be
further
discussion
on
that
point.
Henceforth,
we
should
I
think
come
to
an
initial
view
on
these
questions,
write
it
into
the
document
and
advertise
the
question
to
other
people
who
are
not
on
the
call,
but
in
the
group
and
also
to
the
TOC
who
I
imagine
will
have
an
opinion
about
what
we
want
to
do
there
too.
Okay
into
something
sense:
Michelle.
J
B
J
F
That's
basically,
the
dev
tooling,
is
in
scope
of
the
exact
mechanism
by
which
we
do
it.
It's
still
TBD
I
think
we're
going
to
move
on
to
other
things
like
I
suggested.
The
other
you
said,
elephant
in
the
room
was
whether
path
is
part
of
it
and
I
just
noticed.
Someone
else
also
added
functions
and
service
and
service
was
being
out
of
scope.
I
think
we
need
to
talk
about
whether
paths,
paths
or
service,
or
in
or
out
of
school.
J
C
D
Oops
feedback.
Sorry,
that's:
okay,
I
I!
Think
that
that
everything
that
is
in
scope
of
the
CN
CF
needs
to
be
in
scope
of
one
of
the
SIG's
and
right
now
we
have
I
think
it
is
seven
SIG's
and
I
think
we
need
to
like
if
something
that
is
exists
that
we
believe
to
be
in
scope
of
the
CN
CF
I
think
it
should,
by
definition,
be
in
scope
of
one
of
those
seven
settings.
D
If
that
sig
decides
that
it
is
too
big
and
has
too
much
scope,
then
I
think
that
SIG's
should
elect
to
split
in
two
and
and
creates
a
separate
sig
to
cover
some
subset
of
the
area
that
they
cover.
So
so
that's
the
general
model,
I
think,
makes
sense
and
I
think
what
we
have
come
to
some
kind
of
consensus
on
all.
Certainly
Alexis
agreed
with
that.
D
Just
before
we
joined
Michelle
was
that
in
this
particular
case,
all
of
this
stuff
that
developers
do
from
from
designing
and
writing
code
to
testing
it
to
pushing
it
through
sea
checking
it
into
his
revision
control
systems
and
the
whole
pipeline
by
which
stuff
eventually
ends
up
in
production.
Is
in
scope
for
this
sig,
the
concern
was
that
it
was
too
broad
and
that
we
would
get
perhaps
defocused
where,
where
perhaps
there's
a
perception.
D
I
think
that
CI
CD
is
is
a
small
but
important
and
urgent
part
of
that
process,
and
perhaps
we
should
focus
on
that.
First,
one
mechanism
which
Alexis
supported
was
to
have
working
groups.
You
know
focused
on
those
specific
areas
because
clearly
I
des
are,
you
know,
related
to,
but
quite
different
from.
You
know
remote
debuggers
or
path
systems
or
CID
CI
CD
systems.
But
these
things
will
overlap
at
some
point.
They
all
connect
together,
so
I
think
that's
where
we
got
to.
J
D
Wasn't
actually
referring
to
specific
projects
that
we
have
today,
I
was
more
reflecting
on
the
fact
that
the
CNC
F
is
there
to
encourage
use
and
successful
adoption
of
cloud
native
technology,
and
part
of
that
is,
is
you
know,
providing
people
with
with
knowledge
and
technology
to
make
that
possible
and
I
think
we're
missing
some
of
those
things
at
the
moment
and
it's
a
question
of
strategy
as
to
you
know:
do
we
do
we
focus
on
building
blocks
and
and
let
vendors
tie
the
building
blocks
together
into
products?
I?
D
J
The
thing
about
has
is
that
it
encompasses
lots
of
different
components
that
work
together
to
help
this
like
workflow
and
and
that
might
overlap
with
other
SIG's
like,
for
example,
like
anything
with
anything
to
do
with
monitoring
and
observability.
So
how
do
we
like?
How
do
we
deal
with
the
fact
that
app
has
is
not
just
something?
That's,
maybe
something
smaller
like
it's,
it's
not
as
well
scoped
as
developer
tools
or
CI
CD.
It
just
ranges
a
bunch
of
SIG's,
so
that's
I
think
when
Alexis
and
I
were
talking
about
this
earlier.
D
D
When
you
have
distributed
storage
system,
you
have
security,
so
there's
overlap
with
a
security
sig
and-
and
we
just
we're
just
gonna-
have
that
all
over
the
place
and
I
think
acknowledging
where
those
overlaps
exist
and
and
just
dealing
with
them
sensibly
is
the
approach
I've
suggested
and
in
the
Charter
for
the
storage
sig,
for
example,
we
called
out
exactly
you
know
all
the
overlap
areas
we
were
aware
of
and
and
described
briefly
how
we
plan
to
address
them.
I.
I
J
But
maybe
acknowledging
that
hey,
we
maybe
may
need
something
you
know
later
down
line
to
iterate
on
makes
sense
to
me.
I
don't
want
to
pre-optimized
here
and
may
just
make
a
new
sake
for
it
especially
have
any
projects
at
the
moment
that
fall
into
that
category,
unless
I'm
forgetting
something
well.
F
There
was
all
of
them
and
and
what
you'll
see
was
something
like
a
native
is
it
sort
of
brings
them
all
together
into
one
and
said
I'm,
not
gonna,
necessary,
forced
you
to
pick
a
label
right
just
where
the
functional
aspects
or
functional
characteristics
you
want
of
your
container
right?
Does
it
scale?
Does
it
not
and
that
kind
of
stuff,
and
so
I
think
trying
to
say
we're
going
to
have
a
path?
Is
then
gonna
ask
the
question
of
okay?
F
Well,
then,
do
we
need
a
containers
or
a
functions
sake,
and
how
do
you
force
someone
to
take
something
to
live
just
in
one
of
those
categories?
I
think
it's
gonna
be
really
challenging.
I'd
much
prefer
to
start
off
with
saying
we're.
Gonna
manage
containers
in
general,
because
that's
the
core
of
what
Canada
is
all
about.
D
Entirely
and
and
and
that
that
was
the
view
that
I
put
forward
in
one
or
other
of
the
documents
is
that
until
you
actually
understand
the
space
properly
until
you
actually
know
what
these
words
mean
and
where
they
overlap,
it's
very
difficult
to
draw
those
boundaries,
so
I
would
prefer
to
to
have
a
big
amorphis
blob
which,
as
you
say,
is
is
you
know,
applications
for
cloud
native
and
then
tease
it
apart
and
figure
about
how
it's
actually
done
and
how
these
various
labels
are
used.
I,
don't
even
think
labels
like
pairs
are
used
consistently.
D
J
A
J
Great
so
Alexis
and
I
were
thinking
that
it
would
be
great
to
pull
that
into
that
working
group
under
the
umbrella
of
this
state
for
the
short
term
medium
term,
and
then
we
evolves,
like
men
mention
you
know,
as
we
tease
things
apart,
what
what
it
means
to
run
these
applications
or
deliver
these
applications
and
cloud
native
environments
as
we,
you
know,
progress
if
that
working
group
necessitates
its
own
state,
we
can
just
go
ahead
and
and
build
that
on
safe.
That's
the
that's!
F
A
J
J
Okay,
so
we
did
talk
about
the
relationship
with
the
server
list
working
group
and
then,
if
you
scroll
down,
there's
also
the
relationship
between
two
brandies,
sig
apps.
So
just
to
give
a
little
bit
of
context
here,
I
used
to
chair
Singh,
opsite,
I
co-founded,
say
gaps
in
kubernetes,
and
this
was
you
know
back.
Then
we
were
working
with
the
people
who
were
developing
the
workloads
API,
and
we
were
also.
We
also
had
a
bunch
of
people
who
were
both
building
tools
on
top
of
this
API
for
kubernetes
in
the
same
sig.
J
And
what
was
nice
about
this?
It
was,
you
know,
early
on
being
in
the
same
place,
for
these
two
groups
of
people
was
beneficial
for
both
parties,
because
the
workloads
group
got
some
feedback
from
their
end
users
and
their
end.
Users
got
to
know
what
was
about
to
happen.
All
the
changes
that
were
about
to
happen
and
the
planning
of
this,
and
they
got
to
basically
be
a
part
of
the
planning
of
these
API.
So
it
was
beneficial
for
both
groups.
Now
it's
evolved
quite
a
bit.
These
api's
aren't
stable,
so
I
do
see.
J
You
know
the
evolution
of
siga
acts
like
I
think
in
that
evolution,
some
of
the
ecosystem
tools
that
are
part
of
that
apps
group.
It
makes
sense
to
me
for
those
two,
you
know
also
be
part
of
this
group
as
well.
So,
for
example,
Helms
started
out
as
project
under
to
bridge
the
gaps.
You
know
now
that
project
fits
more
under
saying
app
delivery.
K
With
more
quarters
of
how
they
one
of
the
applications
regarding
to
multiple
instances
like
workloads
like
some
instances,
already
rolled
strategy,
well,
the
app
delivery
is
more
on
the
higher
level
to
describe
both
in
application.
Equal
application
to
the
platform
and
the
platform
itself,
though,
use
more
like
seek
app
technology
to
run
applications.
So
I
think
it's
everything.
D
J
K
A
And
even
for
a
CV
part,
I,
don't
know
exactly
about
this.
Cd
f's
go
but
there's
definitely
also
round
deployment
best
best
practices
that
can
be
shared
when
we
mentioned
before,
like
blue
green
diploma
and
start
deployments,
can
every
release
is
how
to
best
implement
them,
not
sure
how
much
the
CD
everybody
cares
about
those
best
practices
rather
than
the
tooling
around
it.
But
it's
definitely
a
group
that
we
should
have
a
certain
interaction
with
whatever
just
then
there
means
in
practice.
K
Yeah,
actually,
from
my
point
of
view,
the
CDF
is
more
like
the
homes
for
the
exterior
edited
open
source
project
like
techno,
my
explaining
her,
while
in
absolute
or
even
more,
for
curse,
only
philosophy
or
the
practices
of
how
to
keep
your
application.
Finally,
Road
strategy
we
may
be
in
the
future.
We
may
have
some
standard
project
like
workflow
engine
like
road
engine
which
can
be
applied
to
every
city
project,
I,
think
that
it
will
be
Oracle.
K
J
J
A
You
another
important
part
of
projects
we
should
engage
with.
Is
everything
that's
currently
happening
around
operators?
It's
kind
of
weird
that
they're
not
really
in
a
subsea
project
I
mean
that
the
core
goal
of
operators
is
to
automate
running
apps
on
Cavani
day.
So
what
you
would
expect
them
to
have
a
close
relationship
there
and
I
think
was
at
least
engaged
with
the
projects
they're
in
in
whatever
way,
because
they're
kind
of
possibly
like
to
see
gaps
to
some
extent
because
they
using
the
API
API
servers
and
the
API
server
are
there
I?
J
There's
some
question
whether
operators
should
live
in
the
CNC
F,
because
if
you
have
a
like
a
specific
operator
for
a
specific
technology,
maybe
that
technology
has
its
own
foundation
and
perhaps
that
foundation
might
went
on
the
operator
since
they're
the
most
well
versed
in
that
specific
piece
of
technology.
So
there's
some
discussion,
but
I
100%
agree
that
we
should
have
those
conversations
and
really
take
some
initiative
to
figure
out.
J
K
Actually,
the
be
cheeky,
you
know:
I
work
with
young,
so
I
know
that
Ray
had
actually
has
his
own
opinion
on
world
operators.
Who
going
to
wish,
from
my
point
of
view,
is
a
little
bit
different
from
what
we
are
talking
about
in
the
safe
or
like
the
nonprofit
Linux
Foundation,
more
like
a
production
label
project
right
now
and
actually
from
technical
views
or
printer
is
actually
another
kind
of
controller
of
kubernetes.
So
it's
actually
more
related
to
the
stick.
Add
what
we
actually
discussed
before,
which
you
know.
K
D
Is
also
that
it's
that
it's
less
tightly,
coupled
with
what
we're
doing
then
than
most
of
the
other
topics,
we've
spoken
about
useful
to
know
about
that,
but
not
core.
Also
wonderful.
There
I'm
not
an
expert
on
operators,
but
it
seems
to
meet
that
there's.
A
relatively
small
amount
of
common
operator,
stuff
and
vast
majority
of
the
operators.
Space
is,
is
deep
understanding
of
specific
applications
and
writing
operators
that
run
them
and
the
commonality
between
those
operators
is
not
very
great,
but
speculation
on
my
part,
yeah.
A
Yeah
I
would
agree
there.
It's
still
hard
to
write
operators
to
some
extent.
They
are
kind
of
useful
for
a
lot
of
tops,
I.
Think
they're,
not
at
the
level
of
simplicity
that
you
build
your
own
micro
service
would
write
their
own
operator
to
run.
It
wouldn't
be
like
the
easiest
way
to
go.
There
still
I
think
as
part
of
an
application
field
in
racing.
I
really
don't
want
to
focus
on
there
original
best
practices,
because
I
see
a
lot
of
the
discussion
house
orientation
spoken
about
on
this
CD
part.
A
So
until
the
point
of
you
ship
something
but
that's
usually
when
there
will
found-
starts
when
it
starts
to
run
half
the
best
practices
from
an
operational
perspective
fit
in
there
and
that's
something
where
it
touches
the
operators
to
some
extent,
maybe
just
indirectly
by
say.
Ok,
these
are
the
best
practices
harder
on
demand
services
running
on
kubernetes
and
see
how
this
relates,
but
only
it's
important
to
go
beyond.
A
A
D
Actually
raises
another
question:
maybe
I
can
ask
it
briefly.
I
know
we're
running
out
of
time,
but
the
whole
the
whole
concept
of
sree,
like
that,
the
people
who
actually
run
these
things
and
and
the
additional
sets
of
tools
and
processes
that
they
use,
presumably
that
all
falls
within
the
scope
of
the
CNC.
D
If
we
don't
have
a
lot
of
that
in
in
the
CN
CF
currently,
but
presumably
it
falls
within
the
scope
and
could
be
seen
to
be
in
scope
of
this
SIG
or
I
mean
right
now,
we've
got
you
know,
monitoring
in
a
monitor
in
an
observability
sig
we've
got
these
operators.
We've
got
see
I
CD,
which
falls
into
this
SIG.
I
J
A
You're
operating
your
application,
so
my
proposal
before
it
well
maybe
to
put
in
the
scope:
no
okay,
I'm,
sorry
I
have
been
running
kubernetes
services
for
quite
a
while.
I
wanted
to
have
my
best
practice,
who
even
know
where
to
go
to
work
termites
with
three
to
six
months.
Deliverables
you
might
not
have
any
actually
labor
is
in
there.
A
We
chose
okay,
we
if
we
think
that
we
could,
if
you
want
to
work
on
this,
come
here,
but
right
now,
there's
no
actual
work
plan
for
the
next
foreseeable
months,
which
would
be
my
approach
and
how
to
handle
it,
split
up
the
scope
and
their
deliverables.
Let's
make
it
clear,
but
I
think
it's
good
to
have
it.
That
big
note
it
down
that
this
is
something
we
want
to
cover
here.
K
The
action
Michelle
just
to
raise
a
very
good
point
of
you
know
how
to
choose
and
true
evaluate
if
something
is
belonging
to
this,
they
cannot.
Actually,
you
can
see.
There
are
multiple
roles
in
the
application.
Very
first
dates
like
there
is
develop
developer.
There
is
application
operator.
Maybe
there
is
some
actual
pressure
or
something
more
so
I
think
this
stick
is
more
dated
to
application
operator
and
also
part
of
the
developer
themselves,
not
related
to
infrared
hers.
It's
very
interesting
idea:
yeah.
D
Then
you
have
the
application
s
Ari's,
who
run
it
monitor
it
get
alerts,
get
working
up
in
the
middle
of
the
night,
etc,
etc.
And
then
you
have
infrastructure
sres
who
run
you
know
the
networks
and
the
and
the
discs
and
all
these
kinds
of
things
and
they're
quite
distinct
groups,
and
they
have
their
own
sets
of
tools
and
their
own
sets
of
processes.
K
J
J
So
it'd
be
really
interesting
to
continue
this
kind
of
discussion
within
this
SIG
around
personas
and
roles,
and
things
like
that,
because
you're
right
and
not
every
company
operates
the
same
way.
There
are
distinct
roles,
but
it'd
be
nice
to
kind
of
have
some
more
discussion
around
what
people
are
doing.
J
I'll
have
to
dig
it
up.
It
was
like
three
or
four
four
or
five
years
ago,
so
I
went
for
engineering,
which
is
a
passe
company
and
I
was
having
I
had
the
same
kind
of
question
so
I'll
they
go
I'll
see
if
I
can
find
it.
J
We
have
two
minutes
left
in
this
on
this
call.
So
I
just
wanted
to
see.
If
there
are
some
action
items
we
can
talk
about.
So
what
do
we
think
we
needs
to
be
done
here?
I
mean
we
can
continue
this
conversation
over
the
next
several
days
on
the
mailing
list,
Quentin
Ellis
and
who
else
volunteered
to
help
edit.
The
document.
A
It's
up
here,
something
could
just
be
edited
in
because
they're,
not
big
discussion
items
here,
isn't
some
typos
and
some
stuff
that
people
were
proposing,
and
my
idea
was
for
the
bigger
discussion
items
to
start
to
spread
on
the
mailing
list.
Today,
people
can
comment
on
them,
so
the
next
step
is
really
packaging
up
or
do
we
want
to
have
on
the
discussion,
a
mailing
list
and
other
things
just
get
them
waters
into
the
specter.
That's
just
minor.
J
Okay,
awesome,
so
let's
go
ahead
and
continue
the
conversation
on
the
mailing
list.
If
there
is
anything
left
we'll
edit,
the
document
kind
of
finalizing
package
up,
so
they
can
get
it
ready
for
the
TOC
and
I
will
keep
tabs
and
continue
spinning
those
discussions
to
help
move
it
along
as
well
so
yeah
I.
Think
that's
a
good
stopping
point.
I
just
want
to
say
thank
you
to
everyone
for
showing
that
I
apologize
for
being
late
again,
but
I
am
so
incredibly
excited.
For
this
sake.
J
There's
so
much
meat
here
so
much
to
dig
into
so
I'm
excited
about
the
white
flavors
come
out
and
excited
with
documents
and
these
best
practices
I
think
that's
what
most
passionate
about,
but
yeah
I
I
am
really
pumped.
So
thank
you
all
for
coming
and
we'll
continue
the
discussion
on
the
mailing
list,
but.