►
From YouTube: Kubernetes Sig Docs 20180731
Description
Meeting notes: https://docs.google.com/document/d/1Ds87eRiNZeXwRBEbFr6Z7ukjbTow5RQcNZLaSvWWQsE/
The Kubernetes special interest group for documentation (SIG Docs) meets weekly to discuss improving Kubernetes documentation. This video is the meeting for 31 July 2018.
https://github.com/kubernetes/website
A
B
Hi,
you
guys
tell
me
yes,
hello,
welcome,
hi
hi,
I'm,
Karen,
Chesave,
I
work
in
India
on
cloud,
robotics
startup
and
we
use
kubernetes
and
a
couple
of
weeks
back,
I,
think
pooja
and
you
we
got
in
touch
on
Twitter
and
main
problem
was
around
dating
documentation
about
kubernetes.
So
I
wanted
to
know
how
to
go
about
that,
and
so
I
decided
to
show
the
same
thing.
So
hello,
everybody
and
let.
A
A
Great,
thank
you.
The
easiest
way
would
be
to
message
me
on
kubernetes
slack.
If
you
go
to
kubernetes,
that's
like
calm.
That
is
the
that's
the
best
way.
Yes,
okay,
excellent!
It's
great!
Thank
you
for
joining.
It's
it's
great
to
see
you
any
other
new
or
first-time
contributors.
I
will
say
that
I
see.
Cody
is
back.
Haven't
that
seen
Cody
for
a
year.
Welcome
back
Cody.
C
C
A
Let's
see,
updates
and
reminders
really
quickly,
so
maintainer
x',
please
check
the
wiki
for
the
pr
regular
schedule
for
through
the
end
of
the
year,
just
to
make
sure
that
you
know
what
your
scheduled
shift
is
and
if
there
are
any
conflicts
there,
let's
try
to
resolve
them
early.
A
Also,
there's
a
PR
open
right
now,
it's
Misty's
PR
open
for
better
contribution
guidelines
and
they're
out
of
the
comment
about
roles
and
responsibilities
at
different
levels
of
kubernetes
and
cig
docs
membership.
So
maintainer
is
particularly
if
you
could
look
at
my
comment
and
make
sure
that
that
looks
accurate
to
you,
because
I'm
almost
certain
that
I've
missed
something
or
that
it's
possible
to
have
more
precise,
more
precision
about
that
topic.
That
would
be
awesome.
A
E
E
So,
apparently
that
would
get
us
a
number
of
benefits,
one
of
which
would
be
that
the
table
of
contents
issue
that
we've
been
having
where
there's
where
we're
having
trouble
with,
like
the
with
the
double
bullets
and
things
like
that.
So
apparently
in
Black,
Friday
version
two,
you
actually
get
a
like
you,
don't
just
get
this
dot
table
of
contents
object
that
just
kind
of
spits
out
unordered
lists
and
lists
items
as
we
currently
have,
but
actually
gives
you
a
proper
data
structure
that
you
can
sort
of
iterate
through
and
design.
E
However,
you'd
like
and
I
haven't,
really
explored
this
much
yet,
but
but
apparently
in
Black,
Friday
too
there's
a
there's,
a
separation
of
the
the
the
rendering
phase.
So
you
could
hypothetically,
we
could
hypothetically
either
create
our
own
markdown
renderer
for
Hugo
fairly
easily
or
we
could
update
the
existing
one.
I
I
think
that
the
broadly
that
the
point
is
that
porting
cramdown
to
go
would
be
tons
and
tons
of
effort,
I,
think
and
I'm,
not
quite
sure
who
either
on
our
team
or
outside
of
it,
would
be
able
to
do
that
work.
E
A
E
A
A
Zach
Arnold
is
not
here.
He
has
a
meeting
conflict,
but
just
a
quick
update
on
1.12
exactly's
done
some
really
cool
work
on
automating
pieces
of
the
release,
workflow
and
they're
tracking,
open
PRS.
The
air
table
and
I
also
know
that
that
that
is
fed
with
a
graph
QL
a
graph
QL
query
from
the
github
API.
So
there's
some
really
cool
work
happening
in
terms
of
visibility.
A
F
We
have
a
few
parts
of
our
Docs
where
we
refer
to
their
version
by
the
maintenance
release
number
and
those
drift
out
of
date
and
get
updated,
sporadically
I'm
wondering
if
we
should
maybe
have
a
variable
that
we
do
keep
up
to
date.
That
is
the
maintenance
version.
I
think
we
actually
have
that,
but
I
think
that
we
are
terrible
about
keeping
them
up
to
date,
and
it
also
needs
to
be
kept
up
to
date
in
Prior
releases
that
we
still
support
and
we
get
maintenance
releases
for
those
all
the
time.
F
So
I'm
just
want
to
put
it
out
there
and
see
if,
if
either
we
want
to
commit
to
using
the
very
Abel's
that
we
already
have
more
consistently
in
the
docs
or
if
somebody
has
a
magical
more
automated
way
to
keep
those
up
to
date
without
manual
work.
Whatever
we
do,
it
does
not
scale
to
have
like
specific
places
in
the
docs,
where
it's
just
a
string
that
we
have
to
find
in
one
place,
and
these
are
commands
that
we're
telling
people
to
run
so.
F
The
PR
that
I
linked
to
their
solution
in
that
PR,
which
I'm
not
super
excited
about,
is
just
to
replace
the
maintenance
version
number
with
X
and
provide
an
admonition
every
single
place
that
it's
used,
telling
the
person
to
replace
X
with
their
version
of
kubernetes
that
they're
running.
So
that's
it
puts
a
lot
of
load
on
the
user
for
something
that
it
seems
to
you.
You
should
be
able
to
somehow
automate.
So
that's
why
I
want
to
put
it
out
there.
I,
don't
know
what
the
right
solution
is.
A
Thank
you
for
surfing,
surfacing
this
yeah.
It
may
be
worth
the
time,
even
if
it's
just
you
know,
even
if
it's
just
finding
well
on
an
unrelated
note,
I'm
looking
for
contractors
for
some
specific
pieces
of
work
for
kubernetes
Docs
and
something
like
having
a
having
a
handy
person,
it
might
be
nice
to
just
have
a
handy
person
to
be
like
okay,
could
you
could
you
go
through
and
replace
every
instance
of
this
with
a
variable
so.
F
But
there's
a
longer-term
thing
that
when
kubernetes
has
a
point
release,
somebody
needs
to
go
and
update
the
EML
files,
all
the
supported
branches
of
the
docs,
to
get
those
variables
to
be
up
to
date
like
when
there's
a
1.10
got
whatever
or
1.9,
not
whatever
like
week.
Those
variables
need
if
we
decide
to
use
variables
and
those
variables
need
to
be
updated
everywhere.
The
other.
The
other
question
is:
do
we
want
to
be
referring
to
maintenance
releases
by
a
specific
number
at
all?
F
D
G
It
be
possible
sorry,
would
it
be
possible
to
have
like
some
sort
of
master
variable
listened
like
the
main
folders
of
hugo
for
like
templating,
so
the
variable
is
not
reference
in
the
file
itself.
The
variables
like,
like
a
master
hugo
doc,
for
example.
So
if
something
changes,
a
version
changes
update
screw
update
that
one
kind
of
central
point
and
then
that
changes
all
the
variables
yeah.
F
We
used
something
like
that
docker.
Actually,
we
had
a
JSON
file.
That
was,
it
was
in
all
the
branches,
but
we
only
ever
looked
at
the
one
in
master,
no
matter
what
version
it
was
rendering
we
used
it
Fernet
for
navigation,
for
what
persons
were
supported
so
effectively
the
same
sort
of
thing.
One
problem
like
that
is
we're
not
on
Hugo
for
all
of
our
archives,
yet
yeah,
so
that
probably
wouldn't
scale
until
that
happens,
which
I
guess
is
going
to
be
a
year
or
something
like
that.
If
we
support
four
major
versions,
yeah.
A
Well,
nine
months
we're
getting
closer,
but
it
may
be,
it
may
be
worthwhile.
I
mean
I
understand
that
this
is
a
problem
that
is
backward
looking
as
well
as
forward
looking,
but
it
may
be
worthwhile
just
to
take
to
solve
for
forward-looking
and
let
time
resolve
the
rest
or
at
least
limit
that
solely
to
Hyuga
versions,
rather
than
try
to
solve
for
both.
Let's,
let's
take
into
the
PR
and
figure
out.
What
exactly
we
want
to
do.
A
I
mean
generally,
it
seems
like
a
good
idea
to
automate
what
we
can
rather
than
impose
another
particular
maintenance
burden.
You
should,
or
at
least
to
minimize
that
if
there
is,
if
there
is
a
file
like
a
llamó
file,
that
we
have
to
update
periodically,
I
would
rather
like
have
a
quarterly
or
whatever,
at
whatever
periodicity
updates.
A
A
A
About
branching
strategy
for
for
repositories
for
localization
repositories,
so
in
the
in
last
week's
weekly
meeting
at
the
APEC
time,
one
of
the
localization
leads
asked
whether
we
had
already
solved
for
a
branching
strategy.
What
branching
strategy
for
localization
repos
should
look
like
and
we
hadn't
we
have.
We
have
not
gotten
that
far,
partly
because
the
question
hasn't
come
up
yet
to
that
degree
of
specificity
and
partly
because.
A
I,
don't
know
I'm
honestly
unsure
of
how
much
of
our
workflow
to
export
to
a
localization
team
so
rather
than
solved
for
all
of
it.
What
I
would
like
to
do
is
just
put
the
idea
into
people's
minds
to
think
about
what
what
looks
like
a
Minimum
Viable
Product
for
exporting
or
for
expectations
for
branching
strategy
for
localization
reposts
seems
to
me
a
minimum.
There
has
to
be
a
branch
for
each
kubernetes
release
each
major
release.
A
There
has
to
be
a
working
branch
and
there
has
to
be
at
least
one
branch
that
we
can
identify
that
we
can
automate
with
with
github
web
hooks
to
import
that
content
into
que
website
whenever
that
version
or
whenever
that
branch
is
updated.
So
at
a
minimum,
that's
looking
like
a
current
plus
four.
So
that's
five
release
branches,
a
working
branch
and
a.
A
A
A
H
And
for
this
I
basically
use
four
methods:
the
needs,
assessment,
phase
versus
interviews
and
competitive
analysis
and
interviews.
I,
basically
interviewed,
like
I,
didn't
get
too
many
uses,
but
I
got
like
two
interns
over
interning
in
the
kubernetes
team,
so
I
asked
them
how
they
onboard
with
with
the
product,
and
they
did
not
have
like
my
experience,
working
with
communities.
So
they
were
not
Novus
users
and
in
competitive
analysis,
I
analyzed
for
competitors
when
this
talk,
which
is
like
kind
of
a
direct
competitor
because
it
operates
in
the
similar
space.
H
So
he
restricts.
The
valuation
is
generally
done
for
user
interfaces
and
Nielsen
has
given
like
ten
heuristics,
but
I
could
use
only
five
of
them
in
our
documentation
and
I
added
another
one,
which
was
information,
architecture
and
I.
Like
came
up
with
questions
which
are
based
on
best
practices
for
documentation
and
common-sense.
H
Some
of
them
had
likely
experience,
but
not
really
much
and
I
just
want
you
to
get
their
feedback
around
I
will
engage
some
of
the
kubernetes
basic
tutorials
and
interactive
tutorials
on
commands,
which
uses
still
control
so
the
main
findings
from
like
all
these
UX
studies
were
uses
for
diagrams.
But
the
current
diagrams
are
not
very
useful,
and
this
came
across
and
interviews
as
well
as
the
usability
test
where,
in
interviews,
people
said
that
they
want
diagram
so
that
they
could
have
like
better
mental
models
and
usability
test.
H
They
said
that
the
current
diagrams
are
not
very
helpful,
like
they
couldn't
read.
What's
in
the
diagram,
they
did
not
make
sense
of
by
the
shapes,
but
as
they
were
in
the
diagrams,
they
did
not
understand
why
things
are
not
connected
to
each
other,
and
they
said
that
there
is
cubelet,
but
I
can't
see
Q
plate
in
the
diagram,
because
readability
was
so.
We
need
to
improve
diagrams
and
then
in
introduced.
H
One
of
the
user
told
me
that
it's
not
just
important
for
me
to
understand
one
concept,
but
I
should
also
be
able
to
make
a
distinction
between
two
concepts,
and
this
was
kind
validated
in
my
usability
test.
When
a
user
could
not
understand
why
a
board
is
different
from
container
or
by
kubernetes
needs
both
the
things
and.
H
The
other
one
was
we
have
too
many
links
that
are
not
really
helpful.
For
example,
in
the
kubernetes
basics
section
we
have
docker
link
which
just
takes
you
to
the
doctor
website,
not
even
like,
but
awkward
definition
or
something,
and
there
is
a
mini,
cube
link
that
takes
you
to
the
github
page,
where
people
just
scroll
down
to
the
readme
section,
and
then
they
read
a
sentence
about
what
mini
cube
is
and
if
they
come
back
to
the
face,
then
again
they
can
read
that
sentence
which
is
complicated.
So
it's
not
really
meaningful.
H
So
we
need
to
like
audit
all
the
links
that
we
have
and
see,
they're,
adding
value
to
the
customers
and
also
we
need
to
like
figure
if
we
are
giving
them
good
recommendations
at
the
end
of
each
topic
so
that
they
know
like
where
they
need
to
go
because
nobis
uses
to
not
really-
and
there
was
we
were
going
through,
one
interactive
tutorial,
and
so
they
like
I
was
asking
them.
So
just
explain
me
what
this
command
does
and
at
this
one
place
where
people
by
deploying
pods,
they
were
like.
H
Okay,
I've
deployed
a
pod,
but
I
don't
know
what
a
pod
is,
because
we
did
not
introduce
them
to
a
board.
So
that
was
in
the
next
topic
and
there
was,
we
didn't
even
add
one
line
of
definition
to
like
explain
what
a
pod
is
so
use.
This
is
but
really
confuse
about
that
and
we
had
like
a
user
post
persona
page
which
was
like
this,
where
they
could
basically
take
a
journey
and
follow
the
path
that
they
could.
H
You
know
relate
to
signed
order,
their
application
developers,
but
then
of
the
users
interacted
with
of
X.
So
it
has
to
be
thought
they
would.
The
business
went
to
the
tabs
that
were
the
documentation,
a
concept
star
tutorial
tarps,
because
that
is
what
they
used
to,
and
that
is
how
they
interact
with
documentation
websites.
So
we
probably
need
to
pull
this
out
and
lay
out
the
options.
No
clearly
like
maybe
I'd
like
a
getting
started
section.
H
There
are
other
findings
that
that
would
improve
the
usability
of
documentation.
These
are
mostly
from
the
competitive
analysis
like
dhaka.
Documentation
has
like
a
recap
section
of
all
the
commands
that
they
go
through.
So
I
think
that
is
really
meaningful.
We
could
add
it
and
so
that
users
can
easily
access
the
commands
that
they
have
been
through.
H
H
H
D
H
Stripe
documentation
gives
like
a
very
customized
experience
and
like
in
the
getting
started
section
itself.
They
kind
of
give
you
give
users
the
incentive
to
log
in
when,
once
they
create
a
login,
then
they
can
basically
have
a
customized
put
like
commands
for
themselves,
which
they
can
just
copy
paste
and
like
run
on
the
console.
So
we
can
probably
do
something
similar
and
the
tutorials,
and
you
I
mean
they
basically
allow
you
to
put
mark
the
content
on
the
video.
H
H
H
And
I
also
found
that,
like
the
information
that
was
on
the
right
side
of
the
page
was
basically
notify
the
users
they
were
not
reading
it,
and,
even
though
we
had
put
it
like,
you
know,
find
the
most
concise
information
on
the
motion
for
important
information
on
the
right
side.
But
none
of
the
users
actually.
D
So
we
talked
with
them
all
and
they
caterpillar
has
like
sort
of
a
version
that
you
can
put
a
button
on
the
page
when
you
click
on
it.
It
loads
like
a
mini
cube
environment,
a
panel
at
the
bottom
page,
so
you
can
continue
to
scroll
the
documentation,
read
it
and
then
actually
do
stuff
in
the
console
and.
A
A
H
The
most
important
five
findings
that
I
think
are
most
in
the
beginning,
like
improving
buildings
like
having
better
diagrams,
because
it's
so
complicated
that
like
uses
when
I
cancel
anything
I,
don't
want
to
read
all
this
content
and
I
was
so
happy
to
see.
A
diagram
with
this
diagram
is
so
useless
that,
like
just
as
in
turn
doing
anything
sizing
good
diagrams
are
definitely
like
a
big
plus
and
some
of
the
places
people
who
are
reading
and
they
thought
that
they
understood,
but
they
did
not
really
understand.
H
So
we
need
to
like
differentiate
between
the
concepts
really
where
maybe
by
adding
examples,
and
they
were
pretty
fine
with
the
length
of
the
documentation
like
I
didn't
find
any
user
was
like.
Oh
my
god,
this
is
like
so
much
information.
They
were
basically
reading
through
most
of
the
content
you
have,
but
given
a
choice,
I
think
if
the
diagrams
could
convey
things-
and
we
definitely
need
to
sort
our
links
because
I
didn't
find
any
of
the
links
we
use
in
my
evaluation.
A
D
D
Right
do
we
want
to
do
the
FMC
one?
Next?
Yes,
let's
do
okay,
so
first
let
me
introduce
Dominik.
Try
now
he's
the
director
of
engineering
at
sa
P
Dominic,
you
want
to
say
hi
nice
to
meet
everybody
so
just
to
give
a
little
background.
This
all
came
from
conversations
that
I,
Dominic
and
I
know
each
other
from
the
dog
park
and
when
you
find
out
a
tech
writer
for
kubernetes
started
asking
all
these
questions
like
specifically
about
behavior
and
I
realised
I.
D
D
D
D
D
With
this
as
well,
ok,
so
the
whole
idea
is
to
help.
You
know
your
bananas
users
particularly
novices
as
well
like
build
better
mental
models
all
right.
So
if
you
ask
people
like
what
their
experience
have
learned,
learning
through
Benes
is
like
the
universal
answer
that
I've
come
across
is
that
criminais
is
a
beast.
That's
what
everyone
says
right,
it's
it's
complex
and
there's
there's
a
lot
of
things
to
learn,
and
if
you
look
at
our
documentation,
it's
very
usage,
centric
right,
we're
very
task
oriented.
We
yeah.
D
We
probably
focus
on
like
how
to
do
specific
tasks
and
we
have
tutorials,
and
but
the
underlying
concepts
are
only
really
sort
of
on
a
need-to-know
basis
and
like
the
doesn't
in
the
concepts
that
we
do
talk
about
they're
a
lot
of
times,
incomplete
or
inaccurate.
You
know,
and
then
it's
also
hard
to
reason
about
grenades
like
what
it's
actually
doing.
Right.
For
example,
like
you
know,
where's
a
pod
like
this
came
up
in
and
they
has
research
as
well
like,
and
what
does
it
was
it
do
right
like
in
our
documentation?
D
D
So
all
this
is
kind
of
confusing
and
actually
like,
depending
on
what
your
definition
of
deploy
is.
Probably
the
pot
is
the
only
thing
that's
deployed
both
in
the
communities.
You
know
world
right,
and
so
perhaps
a
more
accurate
description
would
be.
Pot
is
a
representation
of
a
request
to
execute
one
or
more
containers.
D
So,
to
give
you
a
quick
kind
of
history
of
that,
it
was
originally
developed
in
1975,
and
the
idea
is
to
address
like
the
communication
issues
in
the
software
industry,
specifically
like
the
the
discrepancy
between
like
what
is
meant
and
what
is
expressed
or
like
information
that
is
not
explicitly
shared
because
you
encounter
in
the
salon
for
days
like
new
users
often
have
to
ask,
like
you
know,
seasoned
users
for
specific
details,
but
none
of
that's
capture
and
documentation.
It's
like
just
talking.
D
You
know,
one-on-one
conversations
things
like
that,
so
we
want
to
capture
that
information
and
convey
it
through
our
documentation.
So
FMC
you
know,
has
developed
since
then
and
has
been
used
at
Siemens
and
sa
P
consistently
and
eventually
turned
into
the
Apache
modeling
project,
which
is
hosted
by
the
ISO
partner,
Institute
and
NSA
PR.
D
So
you
so
you
can
understand
better,
like
what
other
different
pieces
in
the
system
and
how
they
interact
with
their
relationships
are
right.
So,
for
example,
like
a
quick
one
that
the
dummy
did
to
illustrate
this,
for
me,
is
like
for
note
right.
So
we
talked
about
node
and
we
have
these
architecture
diagrams
that
show
the
control
plane
and
Cuba,
but
it's
like
how
does
it
actually
function
right
so
like
in
this
diagram?
D
So
this
is,
like
you
know,
in
a
simple
diagram,
explains
a
lot
more
about
the
behavior
and
I
want
to
just
note
that
misty,
you
know
when
it
always
tells
me
a
make
sure
that
we
don't
rely
too
much
on
diagrams,
which
I
totally
agree
with,
but
I
think
these
will
also
help
us
as
technical
writers
understand
the
system
better,
so
that
we
can
give
more
concise
and
accurate
descriptions.
So
I
don't
want
to
say
that
we're
necessarily
relying
on
diagrams
but
I
think
it
should
help
all
of
our
understanding.
I
A
D
So
basically,
our
proposal
is
we
want
to.
We
want
to
have
like
a
dedicated
project
to
create
some
FMC
documentation,
so
we
want
to
convey
the
essence
of
kubernetes
and
like
how
it
behaves
and
minimize
the
dependency
on
source
code
for
people
to
understand
what
commands
does
and
replace
ambiguous
language
with
accurate
models
right
because
when
we
say
like
node
or
cluster
or
pod
or
whatever
it's
a
lot
of
times,
people
aren't
talking
about
the
same
thing
and
then
we
want
to
say
create
a
set
of
diagrams
with
us
explanations
to
help.
D
You
know
users
both
novice
and
you
know
more
advanced
user-
to
build
a
more
robust
and
accurate
mental
model
of
how
companies
works,
and
then
we
and
in
general
we
also
want
to
Rene's
diode
to
be
the
canonical
source
of
core
concepts
and
terms
so
people
linked
to
us
and
not
have
to
kind
of
try
to
re,
describe
it
in
their
own
charms
and
so
for
Naugles.
We're
not
making
like
fancy
diagrams
from
working
materials
or
any
of
that.
D
We're
not
creating
specification
diagrams
and
we're
helping
users
fill
meant
better
mental
models,
but
we're
not
telling
them
how
to
architect
their
app
or
build
their
app
right.
So
what
we're
looking
for
is
so
for
this
to
be
like
a
contract
project,
so
we're
looking
for
some
funding,
because
Dominic
needs
some
dedicated
time
to
do
this,
since
it's
not
within
the
scope
of
his
regular
job,
so
he
would
contract
for
us
and
then
he
needs
to
access
to
you,
engineers
to
sort
of
ask
questions.
D
D
And
repeat
until
we
find
until
we
converge
on
a
stable
and
validated
model
that
that
everyone
agrees,
and
it
makes
sense
all
right.
So
you
know
these
are
the
project
deliverables,
the
diagrams,
the
definition
and
the
explanations,
and
then,
when
people
ask
how
do
we
test
the
effectiveness
of
this?
So
if
we
limit
the
scope
to
the
you
know,
hot
pages
right,
we
can
use
the
metrics
that
we've
been
gathering
as
the
baseline
now
and
then
check
on
the
page
views
and
the
time
on
page
for
those
to
see
they
should
increase.
D
If
these
are
effective,
also
were
separately,
working
on
being
able
to
deploy
page
satisfaction
surveys,
and
so,
if
we
can
do
that
and
deploy
them
on,
like
the
pods
pages,
we
can
get
more
direct
feedback
to
see
if
these
are
effective
for
the
people.
Reading
that
documentation,
so
that's
mostly
it
so
Dominic
here
is
here
to
help
answer.
Some
questions
do
so.
If
you
have
any
questions,
I.
J
F
F
J
Now,
maintenance:
the
question
is
what
you
refer
to
maintenance,
so
maintenance
of
the
of
the
accuracy
of
the
information
that
is
conveyed
in
the
diagrams,
so
diagrams
are
usually
labeled
and
the
further
you
go
down.
The
more
detail
you
add
I
personally,
would
definitely
suggest
very
high
level
diagrams
and
then
go
down
a
few
steps
as
long
as
you
are
in
the
realm
of
implementation,
independent
concepts.
So,
for
example,
the
pod
is
a
strong
concept
within
kubernetes
first
class
concept
that
is
unlikely
to
change
unless
kubernetes
itself
changes
significantly.
J
So
if
you
model
the
pod,
its
dependencies,
its
lifecycle
and
how
it
goes
through
kubernetes,
your
information
is
probably
up
to
date
for
a
I
want
to
say
very
long
period
of
time.
But
of
course
it
is
correct
if
there
are
any
grandpa
king
changes
within
kubernetes
and
also
that
information
conveyed
in
the
diagrams
is
obsolete.
But
since
it
is
not,
we
are
not
on
we're
not
talking
on
a
code
level
right,
we're
not
trying
to
explain
the
code
we're
trying
to
explain
the
system.
So
what
I
like
to
say?
J
I
Mean
I
just
have
more
of
a
comment
as
I
was
saying
before
and
I
try
to
get
there
I
think
you
know.
The
visuals
are
very
helpful
to
me
and
I
think
there's
a
group
of
people
where
the
visuals
are
great
I
think
it'll
be
interesting
when
you,
when
he
does
the
prod
to
see
you
know
some
of
us
know
a
whole
bunch
about
pods
and
their
characteristics.
I
think
the
interesting
thing
will
be.
How
much
does
the
model
capture
about
you
know?
I
I
had
each
pockets
my
pee
address,
you
know
how
do
you
capture
the
fact
that
you
know
two
containers
on
the
pod
and
can
communicate
via
normal
IPC,
for
example?
So
there's
a
lot
of
unique
characteristics
about
pods
and
I.
Think
that'll
be
the
interesting
to
see
how
we
captured
in
the
model
to
capture
all
those
behavioral
characteristics
and
you
learn
kind
of
sloka
on
the
streets.
J
So
is
it
in
case
it
is
a
question
or
it
invites
further
comments.
Let
me
just
comment
on
that,
so
we
were
briefly
touching
on
a
model
relationship
that
is
refinement
where
you
have
a
higher
level
model.
You
have
a
lower
level
model
and
there
a
lower
level
model.
That
is
a
relationship
between
horizontal
alignment.
J
What
you
just
described
is
an
invitation
for
also
talk
about
the
other
relationship
between
models.
That
is
aspect
so
where,
as
you
can
think
of
refinement
from
top
to
bottom
aspect,
reaches
out
a
little
bit
to
the
left
and
the
right.
So
if
there
is,
for
example,
for
the
first
phase
particular
interest
in
how
to
support
to
networking
right,
then
that
is
definitely
an
invitation
for
an
aspect
where
we
talk
about
thoughts
in
the
context
of
networking,
and
these
are
information
that
you
would
probably
omit
in
other
diagrams.
J
When
you
talk
about
lifecycle
of
a
pod
right,
they
do
have
some
touch
points,
because,
obviously,
when
the
pods
are
created,
then
the
networks
are
set
up.
But
when
we
talk
about
the
phases
of
the
pod,
like
unbound
bound
pending
running,
succeeded,
failed,
then,
probably
when
we
go
through
these
life
cycles,
the
networking
is
a
detail
that
for
understanding
the
life
cycle
is
not
necessary
within
that
model.
So
in
order
to
describe
one
concept,
so
there
are
multiple
models
around
it.
Some
are
refinements.
J
D
A
Obviously,
I
mean
diagrams
would
be
part
of
the
deliverable,
but
another
thing
that
you
mentioned
is
the
the
accompanying
text.
So
I
guess
my
question
would
be
what
what
content
is
this
augmenting?
Is
this
replacing
content?
Are
you
proposing
which
I
want
to
make
sure
you
clear
that
I
am
perfectly
fine,
replacing
our
content
with
better
content,
but
I
want
to
have
a
clearer
idea
of
where
this
content
would
live,
what
it
would
it
would
either
add
to
or
replace
in
the
context
of
of
our
documentation
model
right
now
so.
D
There's
sort
of
a
pod
pod
section
in
our
concept,
area
and
I
think
it
would
be
I
would
describe
as
a
refactor
right.
So
anything
that
is
confusing.
We
would
kind
of
get
rid
of
them,
replace
with
more
clear
things.
If
there
are
some
things
that
are
accurate
and
good,
then
we'll
keep
them,
but
I
think
I
was
a
refactor,
so.
D
J
Also,
if
you
don't
mind
me
adding
that
so
FMC
is
not
only
about
the
diagrams,
of
course.
That
is
what
its
most
measured,
because
they
are
visual.
However,
it
is
also
a
commitment
to
clear
terminology
and
definition.
So
hunting
down
definitions
actually
does
take
a
violet,
so
Andrew
and
I
circled
a
long
time
over,
for
example,
the
definition
of
what
is
a
part
and
what
does
it
do
right
and
these
definitions?
A
A
D
K
K
K
What
are
you
know,
clusters
pods,
nodes,
etc
in
the
higher
level
like
what
is
kubernetes
page,
and
would
that
maybe
be
a
different
place
to
apply
it
in
the
beginning
to
see
if
it
to
see
if
it
works,
I
realize
that's,
maybe
a
little
bit
more
complex,
but
it
seems
from
what
you've
said
that
the
same
methodology
could
be
used
at
the
system
level
rather
than
at
the
pod
level,
and
that
that
might
be,
and
that
just
struck
me
as
being
another
place
to
test
it.
The
pilot.
J
Absolutely
that
is
definitely
a
possibility,
so
we
pick
the
part,
because
it
is
a
very
prominent
concept
within
kubernetes
and
also
the
core
concept
that
actually
brings
containers
to
life.
However,
we
could
absolutely
look
into
modeling
kubernetes
as
a
cluster
of
nodes.
What
makes
up
that
cluster
both
is
a
kubernetes
application
to
begin
with
how
other
applications
managed,
how
does
control
loop
actually
work,
and
what
does
the
control
loop
affect?
You
would
then
probably
have
to
look
at
what
was
called
in
the
document
documentation.
J
The
kubernetes
object
model
talk
about
the
API
server,
the
individual
controllers
talk
to
the
API
server
to
turn,
transform
the
current
state
into
the
desired
state.
However,
it
is
actually
an
interesting
interesting
point
to
start,
because
it's
commonly
known
that
kubernetes
turns
or
kubernetes
works
towards
transforming
the
current
state
into
the
desired
state
right,
but
only
after
I
created
some
of
the
models.
Some
of
the
sketches
I
actually
realized
that
this
is
a
multi-step
process.
So,
for
example,
you
have
the
deployment
set
and
the
replica
said.
J
Sorry
you
have
the
replica
set
and
the
desired
state
of
the
replica
set
is
just
well.
There
should
be
three
parts,
then
the
thing
is
done
right,
but
now
the
scheduler
comes
up
and
says:
well,
there
are
three
parts
my
desired
state
is:
all
three
of
them
are
bound,
all
right,
I'm
done
right
and
then
the
cubelets
come
into
play
and
said:
hey
there
is
a
pot
and
I'm
not
executing
that.
So
I
have
to
do
this
right,
so
it's
kind
of
like
a
waterfall
model
of
multiple
many
control
loops.
J
A
I'm
sorry
I
could
go
to
muttering
lightly
just
for
time,
because
we're
rapidly
approaching
the
end
of
our
scheduled
time.
This
I
am
sorry
to
interrupt,
because
this
is
so
fascinating
and
I
didn't
I
I
will
say
that
I
personally
am
interested
to
see
where
this
project
goes,
but
on
a
non-binding
vote
basis.
Just
as
folks
have
listened
to
this,
our
folks
interested
in
in
exploring
this
concept
further.
Just
your
up/down
yes
now
is
anybody
not
interested,
because
this
is
totally
the
wrong
way
to
go?
A
A
A
A
A
Andrew
and
Dominic,
thank
you
very
much
for
talking
about
FMC.
This
has
been
really
really
cool
and
I.
Think
we're
really
excited
to
talk
about
it
again
next
week
and
figure
out
how
how
to
move
forward
so
we're
at
the
end
of
our
time.
I
I
know
that
there
were
like
we
talked
about
a
lot
of
stuff
today.
So
if
there
are
questions
or
follow-up
conversations
to
be
had
slack
is
available.
Let's
move.
Let's
keep
the
conversation
going
in
slack
in
cig
Docs.
B
Ahead,
hey
so
I
wanted
to
talk
about
the
day
to
documentation
that
kubernetes
has
I,
think
I'll
get
in
touch
with
you
on
stack
and
probably
show
up
for
the
next
meeting.
Basically,
the
cluster
operator
documentation
that
we
have
currently
we
found.
We
have
some
comments
about
that.
So
I
wanted
to
sort
of
figure
out
if
this
is
the
right
forum
and
is
there
sort
of
a
focus
on
that
whole
aspect
of
that.