►
From YouTube: Kubernetes SIG Apps 20190128
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
At
last
discussion
there
supposed
to
be
a
kept
that
would
be
in
progress
and
that
the
there
were
a
few
volunteers
and
they
were
directed
to
start
looking
at
writing
test
cases
and
there
was
supposed
to
be
a
walkthrough
Code
walkthrough,
but
that
hasn't
been
scheduled.
That's
the
last
I
know
about
it.
Okay,.
A
A
C
Hey
yeah
so
I
mean
we
hope
to
get
something
out
by
the
end
of
this
week.
Internally
Reuben,
just
basically
a
bunch
of
people
have
been
discussing
the
the
cat,
the
person
who's
going
to
author.
It
will
not
be
me,
but
leave
Arnie's,
just
a
gas
number
and
we're
trying
to
get
that
out
as
soon
as
possible.
He's
just
been
a
little
bit
distracted
by
other
games,
so
we
hope
to
have
it
out
by
the
end
of
the
week.
Go.
A
D
All
right
are
you
all
able
to
see
the
screen.
I
have
shared
yep.
We
can
see
perfect
all
right
so
yeah.
What
I
want
to
just
talk
about
is
in
sig
CLI
we're
rethinking
how
we
want
the
coop
control
documentation
to
look.
I
am
I,
wrote
a
bit
of
it
myself
some
years
ago
and
so
I
accept
full
responsibility
for
all
the
all
the
issues
with
it.
D
So
if
I
am
harsh
on
it,
that's
the
context,
but
one
thing
we
found
when
looking
at
like
some
of
the
books
coming
out
on
kubernetes
and
stuff,
is
that
they
are
pretty
comprehensive
and
offer
like
a
nice
linear
approach
of
being
able
to
learn
about
a
tool
and
the
community's
documentation
itself.
I
think
has
mostly
been
focused
on,
like
the
entire
Koopman
of
this
project
and
the
api's
a
lot
like.
If
you
look
at
the
tutorials,
there's
a
lot
of
focus
on
the
api's.
D
Managing
apps,
which
is
kind
of
our
recommended
approach,
is
actually
under
overview
and
then
object
management
using
coop
control
and
then
kind
of
buried
under
here
and
then
in
this
documentation
really
hasn't
been
updated
since
1.5
I
believe,
in
fact,
I
think
I
looked
through
the
comments
on
here
that
I
wrote
to
myself
and
said
this
will
no
longer
be
true
in
1.6
uncomment
this
and
update
the
documentation.
So
it's
MIT
buried.
D
It's
a
bit
out
of
date-
and
this
is
really
just
focused
on
one
piece
of
hidden
or
of
thinking-
has
changed
quite
a
bit,
there's
also
other
documentation
under
the
reference
here,
which
is
kind
of
scattered
it's
hard
to
do
a
linear,
read
through
this
stuff.
You
got
this
kind
of
overview
with
some
different
different
things
that
has
useful
stuff
but
says
common
operations
here
right.
D
So
it's
not
particularly
well
formatted
and
then
you
go
back
and
then
there's
also
a
cheat
sheet,
which
has
you
know
some
of
the
same
overlapping
information,
but
written
by
a
little
bit
differently
and
then
there's
usage
and
conventions
right.
So
the
the
organization
of
this
thing
is
not
fantastic
and
it's
comparative
hard
to
do.
A
nice
doesn't
look
good
compared
to
a
book,
so
we
took
a
stab
at
saying.
Okay.
What
would
this
look
like
if
we
did
something
like
the
rust
book
right?
D
If
you've
looked
at
the
rust
get
book,
I
think
they
use
their
own
language
now
they
they
put
together,
really
nice
online
documentation
for
their
their
product,
and
so
it
seeks
a
live
re-envisioning
like
what
could
this
look
like
right
and-
and
we
haven't
really
settled
on
this
format
yet,
although
there
has
been
mostly
people
like
it
and
most
of
the
feedback,
I've
gotten
is
yes
move
forward
with
this,
but
the
idea
is,
like
you:
have
a
nice
navigation
just
focused
on
qu
control,
right
and
and
separate
it
out
with,
like
nice,
printing
resources
and
break
out
the
different
ways
of
printing
resources
with
nice
examples,
and
in
some
of
the.
D
Some
nice
little
widgets
here,
I'm,
like
having
the
code
displayed
side
by
side
and
then
also
like
working
with
containers,
would
have
its
own
section,
for
how
do
we
do
some,
this
stuff
and
so
just
buried
in,
like
a
cheat
sheet
of
which
is
one
of
several
different
documents
that
doesn't
explain?
What's
in
it,
we
have
a
way
of
navigating
this
stuff
and
learning
about
it
and
then
also
the
as
part
of
this
we're
thinking
both
okay.
How
do
we
want
the
documentation
to
look
and
feel?
What
can
we
do
at
that?
D
What
should
it
actually
say
or
what
should
our
product
support,
because
when
you're
writing
the
documentation,
it
occurs
to
you
like.
Oh,
this
is
how
you
create
an
object.
Here's
how
you
update
an
object,
and
then
you
get
you're
like
okay
deletes
next
and
you're,
like
actually
prune,
doesn't
work
well,
in
fact,
we
tell
people
not
to
use
it
because
there's
a
lot
of
pitfalls
with
using
it
and
it's
a
little
bit
dangerous.
D
D
It
would
be
great
if
there's
a
status
message
that
printed
out
hey,
it's
all
done
and
everything
succeeded
or
no,
it's
crashed
looping
and
we're
not
going
to
try
and
complete
this.
So
using
this
as
a
tool
to
look
at
like
how
should
we
be
develop
like
developer?
Are
you
EXO
it's
a
little
cleaner,
and
so
that's
why
the
top?
It
says:
hey,
there's
a
feature
list
for
stuff.
D
We
want
to
build
out
here
and
then,
lastly,
about
documenting
stuff
that,
like
isn't
like
specific
commands
but
like
how
do
you
either
use
this
tool,
or
how
do
you
make
sure
that
the
other
tools
you're
using
work
well
with
this
one
right?
So
there's
this
building
containers
section
down
here-
that's
not
like
intended
to
be
about
like
how
do
you
build
a
doctor,
pain
or
everything
about
that?
It's
more
about
like
hey
what
is
use,
what
are
the
implications
of
using
latest
in
your
images
right?
How
is
that
going
to
impact
a
deployment
rollout?
D
How
is
that
gonna
impact
to
control,
applying
it
right,
because
you're
not
going
to
change
the
image
tag,
so
it
won't
do
a
rollout
potentially,
should
you
use
a
version
like
a
digest
image
digest
right,
which
is
automatically
generated,
so
there's
different
things
around
building
containers
that
are
important
when
using
coop
control
and
like
how
do
we
educate
users
about
those?
The
thing
was
like
rolling
out
changes
to
multiple
environments.
Here
this
would
be
like.
How
do
we
go
instead
of
saying
like
there's,
this
COO
control
context
flag?
It
allows
you
to
do
this.
D
How
do
we
start
from
like
what
are
the
problems?
Users
are
typically
facing
and
then
map
those
into
here's,
this
feature
of
qu
control
that
allows
you
to
do
this
better
right,
so
so
multiple
clusters
might
be
to
control
context,
for
instance
use
this
flag.
If
you
would
need
welcome
to
cluster
sport,
multiple
environments
could
be
namespaces,
for
instance,
and
and
how
do
we
tell
users
like
how
do
we
give
instead
of
just
giving
users
a
box
of
like
Legos
and
saying,
go
build
a
pirate
ship?
D
Like
how
do
we
make
sure
that
both
all
the
Legos
to
build
the
pirate
ship
already
in
there
and
as
writing
this
documentation,
realize
no,
not
all
the
Legos?
Are
there
so
telling
people
to
go
build
the
pirate
ship
is
not
a
nice
thing
to
do
and
to
like?
Why
don't
we
give
instructions
to
people
on
like
here's,
one
way
to
build
this
thing
right,
and
maybe
it's
not
exactly
what
you
want
and
you
can
change
it,
but
at
least
it's
a
starting
point
to
evolve
questions.
D
E
Yes,
hi
Phil,
can
you
hear
me
hi
Matt
how
you
doing
yeah
yeah
good,
so
your
your
Lego
ship
analogy
and
the
book
analogy,
I
think
they're
really
good,
but
they
they
kind
of
highlight
something
here
right
that
thinks
we're
talking
about
you
see
when
you
write
a
book,
you
can
write
about
your
opinions
right
and
different
people
will
write
different
books
on
the
same
exact
topic
that
share
different
opinions.
E
We
start
looking
more
like
a
path
because
we're
providing
lots
of
things
and
that
kind
of
goes
down
into
the
route
of
the
whole
idea
of
the
the
legged
you're
gonna
go
build
a
pirate
ship
right
and
you
have
those
pieces
and
are
you
gonna
have
them
all
to
put
together,
and
that
would
mean
we
actually
create
all
of
those
pieces
or
we
have
opinions
on
what
those
pieces
are
and
that
it
should
be
a
pirate
ship
right.
Maybe
you're
gonna
build
a
castle.
E
You
know,
I'll
do
the
math
or
seven
years
ago
had
container
orchestration
and
management
on.
It
was
Alexei
containers,
but
it
was
a
passing
four.
It
was
very
opinionated
and
what
they
said
I
mean.
If
you
really
wanted
to
hack
around,
you
could
actually
put
another
API
on
the
front
break
their
opinions.
It
wasn't
easy
like
it
is
here,
and
this
was.
C
You
can
also
have
books
that
are
purely
meant
to
be
informative,
like
let's
say
encyclopedia
or
a
dictionary
or
a
work
of
nonfiction,
where
you're
describing
like
state
of
the
art
or
prior
in
a
particular
subject
and
I.
Think
the
intention
with
this
is
to
be
the
latter
and
not
the
former,
and
much
like
the
documentation
that
we're
not
maintaining
right.
Now,
it's
a
place
where
authors
of
features
in
kubernetes
that
are
exposed
via
Kuby
kuddle
can
come
to
actually
like
do
something
constructive
to
at
least
say.
C
This
is
the
feature
we've
implemented
and
how
its
reflected
in
the
CLI
and
realized
in
the
infrastructure
today-
and
this
is-
was
our
intention
for
how
it
should
be
used
and
because
it's
it's
more
of
a
wiki
book
than
it
is
like.
You
know
something
that
you're
authoring
and
sending
out
and
you're
printing
anyone
in
the
community
is
free
to
come
and
add
to
that
and
god
I
wish
people
will
come
and
add
to
our
crew,
be
coddled,
documentation
or
CI
documentation.
I
mean,
let's
be
honest.
C
The
reason
we're
here
right
now
is
because
I
don't
think
it's
been
updated
since,
like
lump
like
five,
so
it's
not
clear
where,
like
we
do
anything
I
think
from
reading
it
and
I
didn't
take
the
time
to
go
and
read
it.
The
story
is
just
telling
us
here's
how
I
walk
through
each
command
and
do
something
with
the
system.
It's
not
saying
you
have
to
do
it
a
particular
way.
It's
not
even
not
being
prescriptive
in
any
way.
So
I,
don't
I,
don't
feel
like
reading
it
actually
reading
through
it.
C
E
D
D
It's
not
about
like
hey
we're
going
to
pretend
that
we're
just
like
you,
it's
not
about
being
like
really
publishing
a
book
of
which
there
are
many,
and
you
pick
one,
and
then
we
could
are
like
spin
on
everything
right
on
with
opinions
like
that.
Word
is
really
vague
and
can
mean
a
lot
of
things
right,
like
the
opinions
in
this
document
are
really
about
like.
If
you
don't
want
to
hose
yourself.
Here's
what
you
need
to
do
like
here's,
an
opinion.
D
I
have
highlighted
right,
like
if
you're
going
to
run,
coupe
control,
get
and
pull
out
fields
with
JSON
be
sure
to
pin
the
API
in
group
versions
right.
Otherwise,
when
you
upgrade
your
kubernetes
version,
then
the
default
get
gets
a
different
version
of
the
API.
That
field
doesn't
exist
anymore
right
and
so
now
your
scripts
are
broken
right.
So
that's
an
opinion,
but
it's
also
the
like
correct
way
of
doing
something
right
and.
E
E
But
know
there
there
are
opinions
here
right
so
doing
declarative
application
management
outside
of
the
kubernetes
api
is
an
opinion.
In
fact,
a
lot
of
us
think
of
it.
This
way,
I
somebody
said
to
me:
you
know
you
should
manage
all
of
your
stuff
in
get
using
a
DevOps
approach
to
managing
how
all
of
your
config
should
be,
and
that
right
there
is
a
opinion
and
it
gets
into
opinions
right.
So,
if
you're
going
to
manage
it
this
way,
what
does
that
do
for
ecosystem
projects
like
puppet
chef
and
ansible
right
danceable?
E
You
can
do
applications,
and
so,
if
we
say
you
should
be
doing
this
in
a
proach
where
you're
keeping
your
stuff
in
declarative
files,
you're
not
just
declaring
it
to
the
API
you're,
actually
also
having
those
declarative
files
outside
of
the
API,
and
this
is
how
you
manage
it.
Then
what
does
that
say
to
those
other
tools
and
what
does
it
say
to
process
I
think
you've
won
more
but
but
level.
E
E
E
D
E
Do
we
want
chef,
ansible
and
puppet
to
think
this
is
the
it's
okay
for
their
way
to
be,
and
then
how
does
our
language
and
stuff
say
that
and
then
we
level
up
right
because,
let's
say
I
have
a
wordpress
I've
got
an
app
that
lets
me
sign
up
for
WordPress
sites
and
everybody
gets
their
own
WordPress
site
running
in
kubernetes
clusters
and
based
on
your
config.
They
get
different
things,
but
you
all
sign
up
with
it
for
an
app
almost
like
what
automatic
does
with
WordPress.
E
Let's
just
use
this
an
example:
why
would
they
go
even
store
anything
in
a
DevOps
model
to
deploy
and
update
things?
Wouldn't
their
application
just
talk
directly
to
the
kubernetes
api
to
create
update
and
do
those
things
it's
a
very
different
way
to
manage
your
application.
It's
kind
of
the
app
developer
thinking
about
it,
but
it's
an
entirely
different
process
from
the
DevOps
way
of
deploying
things
right.
It's
just
a
different
model,
and
so
how
do
we
as
a
project
communicate
there?
Are
these
different
ways?
C
E
But
Kuby
canto
xvii,
you'll
to
add
more
and
more
features
to
do
application
management
and
as
it
is
pushed
if
something
is
the
official
thing
don't
do
other
things
like
this
has
happened
more
than
once
and
so
Kuby
cuddle
does
application
management.
This
way
people
go
out
and
tell
other
people.
This
is
the
way
you
do
it,
and
so,
therefore,
this
is
how
your
stuff
should
be,
and
we've
had
a
problem
with
this
in
the
past.
When
something
ends
up
in
our
tools.
People
saying
this
is
another
way
everybody
has
to
do
it.
D
Gonna
say
one
more
thing,
and
then
maybe
we
can
like
please
say
it
like,
then
maybe
we
can
like
I've
liked
it
I'd
like
hearing
like
the
feedback
on
how
should
we
evolve?
This
thing,
like
the
reason
I'm
coming
here
right
and
trying
to
get
feedback,
is
like
to
get
input
so
I'd
love
to
hear
everyone's
thoughts
and
then,
like,
obviously,
the
what
we
end
up
doing
is
going
to
be
determined
by
the
people,
writing
the
documentation
and
showing
up
and
helping
give
feedback
regularly,
not
just
once
so.
D
D
If
you
want
or
use
to,
control,
apply
or
use,
cou
control,
delete
and
then
recreate
like
yes,
we
could
like
say
we
run
opinionated
about
how
to
use
our
own
tool,
and
we
have
several
different
ways
of
using
our
tool
that
some
of
which
are
more
effective
than
others,
but
I,
don't
think
that
helps
our
users
right,
like
and
I,
think
it
helps
everyone
else
to
just
know
how
we
found
using
the
tool.
Do
you
want
successful
when.
E
D
Like
if
you
used
to
control
run
you
you,
don't
have
an
audit
trail,
you
don't
have
a
great
way
of
dipping.
I
mean
there's,
there's
like
table
stakes
where
it's
like.
Oh
that's,
not
a
great.
We
have
not
found
that
to
be
particularly
accessible,
largely
like
the
developers
own
experience,
running
applications
feeds
into
this
right,
where
we
found
being
able
to
audit
changes
and
roll
them
back
to
be
a
useful
capability.
E
E
To
actually
say
these,
opinions
are
based
on
what
people
are
doing,
I
don't
know,
there's
work
to
try
to
put
a
survey
together
and
get
that
out,
but-
and
maybe
that
impacts
and
informs
the
survey
to
look
at
instead
of
a
small
group
of
people
saying
this
is
how
we
know
to
be
effective,
but
to
actually
look
at
what
our
end
users
finding
to
be
yeah.
That's.
E
E
Probably
not
gonna
get
them
to
show
up
to
six
CLI,
because
only
a
fraction
of
people
right
there
they're
interested
in
their
app
stuff,
they're
not
going
to
show
up
to
six
CLI
to
come,
contribute
but
they'll
give
you
their
two
cents.
I
think
it
actually
requires
doing
things
like
surveys
going
out
and
asking
questions
of
people
at
companies,
so
the
CNC
F
has
the
end
user
community,
which
is
people
who
don't
produce
products,
but
our
end
users.
E
It's
like
a
specific
targeted
group
and
they're
very
willing
to
talk,
and
so
some
of
the
new
things
that
are
gonna
happen
is
they're.
Gonna
have
forums
where
different
topics
they'll
bring
in
users
together
and
projects
can
go
approach
them
there's
ways
to
actually
deliver
surveys
to
them
and
ask
them
to
fill
them
out.
There
is
a
contact
and
I've
shared
her
name
for
getting
off
the
top
of
my
head,
who
handles
this
and
she's,
actually
organizing
the
forms
and
everything.
E
B
D
Time
we
want
to
write
the
documentation,
update
that
condition.
We
can't
write
the
survey.
We
haven't
updated
documentation
since
1.5
right.
So
there's
like
a
practical,
you
know
what's
possible
and-
and
it
would
be
so
much
more
helpful-
it's
like
advocates,
you
don't
have
to
show
up
and
even
write
the
documentation,
although
that
would
be
helpful,
but
just
having
people
come
by
and
give
their
voice
instead
of
us
having
to
reach
out
each
time
we
went
to.
E
Yeah,
it's
something
I
mean
that's
the
reality
of
it
right.
That's
why
products
and
companies
have
product
managers,
so
the
engineers
focus
on
the
engineering
and
that
product
manager
goes
and
meets
with
all
kinds
of
customers
to
interface
with
them
and
to
hear
from
them
because
they
don't
joke
to
the
engineers.
There's
there's
kind
of
that
liaison
think
that
just
to
really
understand
them
has
to
happen.
I
know
just
to
give
an
example.
E
On
the
helm
side
for
years
we've
done
things
where
we've
sat
down
with
people
who
work
at
companies
to
do
massive,
helm,
installs
and
just
listen
to
them.
Take
notes.
Ask
them
questions
literally
just
have
interviews
with
them
over
time.
In
addition,
that
has
been
baked
into
surveys
over
time
to
try
to
gather
information
as
well
like
well,
Helen
was
still
part
of
kubernetes
and
we
did
the
last
apps
one.
E
We
had
a
whole
section
where
we
captured
what
kinds
of
questions
did
the
project
you
want
to
ask
in
order
to
put
that
onto
users
to
learn
more,
and
we
learned
some
really
interesting
details
from
that,
but
we
have
to
go
out
to
them
in
order
to
get
it
because
they
just
don't
come
by
that's
the
reality
of
it.
Yeah
you
like.
D
C
Just
very
differently
so
I
mean
we,
there
are
many
kubernetes
products
for
kubernetes
is
an
open
source
software
solution
that
you
can
take
and
go
build
your
product
on
top
of,
if
you
want
to
so
I'm
really
looking
at
this
is
what's
good
for
our
users.
What's
not
good
is
having
documentation
for
can
be
cut.
All
that's
like
goes
back
to
1.5
or
1.6.
My
measure
for
like
whether
they're
satisfied
with
it
or
what
needs
to
be
done
generally
comes
from
github
and
slack
and
I
think
back
to
like
how
so
back.
C
In
the
day,
there
was
no
like
CC,
Li
and
say
gaps
and
like
even
up
until,
like
my
time,
mostly
the
Kubik
level
documentation
and
a
lot
of
the
implementation
was
contributed
by
developers
who
are
also
working
on
the
back-end
infrastructure.
You
go,
you
write
your
features
in
there
controller
you
add
codes,
a
cookie
cuddle
then
do
expose
it,
and
hopefully
you
document
everything
well
enough
and
I
think
that's
evolved
and
that's
changed
a
lot.
C
And
now
you
have
people
who
are
dedicated
like
a
hundred
percent
to
the
CLI
for
all
features
and
there's
a
lot
of
work.
A
lot
of
interesting
work
going
on
right
now
it
could
be
cut
all
out
of
tree
and
to
fix
the
dependencies
on
internal
place
and
there's
a
lot
moving
on
right
there.
So
I
just
don't
want
the
context
of
these
features
to
get
caught
or
get
lost
and
linked.
There's
a
lot
so
I
mean
when
people
implemented
this
stuff
they're
working
is.
It
was
implemented
with
specific
use
cases
in
mind
and
I.
C
Just
don't
see
how
it's
hurtful
at
least
to
start
with
capturing
to
use
cases
that
the
authors
of
the
original
software
you
know
intended
with
it.
If
nothing
else,
that's
informative
to
the
end
user,
about
what
the
intended
use
case
was
and
growing
from
there
to
add
other
use
cases
and
as
the
opinions
or
add
you
know,
to
enhance
it
with
other
viewpoints.
That's
great,
but
to
say
that
we
should
do
nothing
because
we
haven't
I,
don't
know
I,
don't
see
how
that
helps.
Anybody
in.
E
Our
users,
please
realize
I'm,
not
suggesting
we
do
nothing
by
this
I
think
there's
a
lot
of
fantastic
material
in
here
it's
when
you
get
into
some
of
the
pinions
and
I
think
you
know
we
touched
on
before
building
containers
or
rolling
changes
out
to
multiple
environments
right
that
very
easily
gets
into
certain
opinions.
Is
it
a
push
face
rollout
or
do
you
have
something
in
the
cluster?
Doing
a
pull
based
roll
out
like
we've
works,
flux
right?
That
does
things
differently.
E
All
of
these
end
up
being
a
pain
and
the
way
this
is
written
up,
whether
it's
talking
about
the
tools,
group
control
applies
or
having
an
opinionated
process,
influences
things
and
then
there's
the
way
people
walk
away
from
this
say
well,
coop
control
says
this
is
how
you
do
it.
So
those
other
ways
are
wrong
and
we
shouldn't
say
that
this
kind
of
thing
doesn't
happen
because
people
do
it
and
I
mean
earlier
this
year.
I
shouldn't
say
earlier
this
year.
E
Sorry
earlier
last
year
about
a
year
ago,
somebody
approached
me
about
wanting
to
get
a
project
into
kubernetes
SIG's
in
order
to
make
it
the
de-facto
way
to
do
things
to
stop
the
other
projects
in
this
space.
And
so
when
we
talk
about
positioning
and
thought
around
this
and
using
it,
people
definitely
use
it,
and,
and
so,
while
I
think
you
know,
the
opinions
are
it's
great
to
have
opinions
out
there?
E
There's
multiple
opinions
on
them
and
there's
multiple
tools,
implementing
those
multiple
opinions
and
I
want
to
make
sure
that
the
I
would
really
like
the
kubernetes
project
and
not
to
stunt
the
area
by
the
way
people
take
something
in
engage
on
it
and
I.
Don't
think
anybody
has
that
intent
here.
I
think
we've
got
the
best
case,
analysis
out
of
the
people
that
I
know
and
we're
all
talking
here.
We
got
the
best
case
intent.
E
It's
other
people
in
other
ways,
things
end
up
going
that
just
just
cause
things
like
this,
and
you
know
it
was
beaten
it
to
me
very
early
into
kubernetes.
That
kubernetes
is
not
a
pass.
We
don't
want
to
have
too
many
opinions
like
passes
of
the
past
do,
and
so
that's,
where
I
get
very
weary
when
we
start
going
down
the
road
of
too
many
opinions,
because
we
you
know
that
does
go
down
that
path,
road
of
our
opinions
or
select
groups
of
opinions
and
that's
always
been
baked
in
very
early
on.
E
D
Have
to
be
concrete
about
what
opinion
means
right
like
cuz?
What's
an
opinion
to,
you
may
not
be
an
opinion
to
me
or
someone
else
right
and
if
we
start
saying
across
the
project,
there's
a
you
know:
mandate
that
no
opinions
or
restrictive
opinions
or
that
sort
of
thing
like
well
is
telling
someone
use
the
context
flag
to
specify
the
cluster.
Is
that
an
opinion?
C
E
Right:
it's
how
far
those
opinions
go
like
suggesting
that
you
know
the
way
to
do.
Multiple
environments
is
to
do
it
this
way
and
here's
how
you
use
the
commands
to
do
it
versus
here's.
How
you
can
use
commands
for
different
things
and
a
lot
of
it
is,
is
in
the
language
we
use
and
in
how
we
do
it
instead
of
saying
you
know,
this
is
how
you
solve
multiple
environments
versus
here's
ways.
E
C
C
Right
there
there
are
different
things,
but
I
think
my
overall
point
is
just
basically
the
only
way,
and
so
documentation
and
open
source
is
one
of
the
hardest
things
to
get
done
right,
because
it's
a
contribution
that
many
people
don't
actually
want
to
make
and
I've
seen
not
just
our
projects
in
our
communities,
but
in
many
open-source
communities
constant
calls
where
hey
you
want
to
start
out.
Documentation
is
a
great
place
to
start,
because
we
don't
have
it
here's
a
place
where
we
know
we're
lacking
for
open
source
contributions.
C
The
only
way
that
I've
seen
things
to
be
successful
is
to
get
someone
to
make
an
initial
contribution,
and
if
it
is
slightly
controversial
or
many
other
people
have
opinions,
then
they're
always
welcome
to
contribute
on
top
of
that
and
we
can
solve
it
as
a
community
and
we
can
incorporate
the
viewpoints
of
all
of
our
members
like
I.
Don't
I,
don't
see
why?
C
Having
this
format
versus
the
existing
format,
which
isn't
very
discoverable,
add
another
criticism
to
it
would
restrain
that
an
extra
smiter,
but
that's
just
life
right,
so
I
can
feel
entire
community
feels
like
this
is
not
the
way
to
go.
Okay,
I'm
not
going
to
be
like
super
opinionated
on
that
either,
but
I
just
think
that
it's
great
that
there's
a
solution
here
and
doc
seems
to
like
it.
C
E
Now
this
has
been
expressed
to
me
by
more
than
one
person
on
the
project
and
that's
a
very
strong
opinion
right
and
so
without
getting
into
even
my
opinion.
One
of
the
things
is
because
that
is
a
very
strong
opinion
on
how
you
engage
with
kubernetes
and
it
doesn't
work
well
with
the
ecosystem,
right,
I'm
inclined
to
say
that's
the
kind
of
opinion
that
should
not
be
reflected
in
our
documentation.
E
But
I
know
there
are
people
who
would
like
to
see
that
reflected
in
our
documentation
and
that's
the
must
case
and
I
really
want
to
make
sure
that
we
don't
do
that
when
there
are
people
who
hold
a
strong
opinion.
So
that
way
we
play
well
with
people
who
have
many
varying
different
styles
in
the
cloud
native
space,
because
we're
going
down
the
road
if
we
went
that
way
of
very
strong
opinions
and
we're
not
just
doing
that.
E
We're
telling
people
interact
with
our
API,
how
they
should
build
their
applications
to
interact
with
the
API
and
how
they
should
do
their
workflows
and
so
right.
These
tools,
whether
somebody
use
Jenkins
or
chef
or
puppet
people,
are
really
opinionated
on
those
right
like
far
beyond.
Sometimes
the
vim
verse
max
debates
and
now
we're
coming
in
with
an
opinion
on
how
they
should
do
things,
and
that
to
me
is
it
makes
me
nervous
and
it's
kind
of
confining
and
restricting
to
what
we're
telling
them
to
do.
E
D
The
information
is
exactly
the
same,
but
the
sentence
structure
indicates
that
this
is
how
you
use
to
control
in
order
to
achieve
a
specific
task,
rather
than
here's,
how
you
do
it
in
kubernetes
or
something
like
that.
So
maybe,
if
anyone
Matt
I,
know
you're
very
busy,
but
if
anyone
else
shares
like
your
perspective
or
could
help
build
this
documentation
with
us,
we
could
have
more
discussions
continually
a
quick.
E
D
Questions,
no
one
has
approached
me
yes,
offering
to
help
I
think
totally
open
I've
been
I've
been
asking
a
lot
of
ones
like
yes,
I
will
totally
help
so
I
pushed
it
to
a
branch
on
to
control
repo,
just
as
a
place
for
anyone
to
play
with
it.
Like
you
do
exactly
things
you
said,
and
no
one
has
really
engaged
me
about
it.
So
I
kind
of
stopped
updating
it
I'm
pretty
open
to
anything.
C
D
D
We
have
all
these
different
things,
but,
like
you
know,
what
do
you
think
of
like
another
section?
That's
just
like
here
is
everything
on
tooling
or
coop,
control
or
api's
or
whatever.
It
is,
and
that's
really
only
in
an
idea
phase
right
now,
so
potentially
we
have
something
like
is
on
the
main
site.
The
other
ideas
that
have
been
suggested
are
take
this
content
and
put
it
on
the
net
a
site
under
concepts
or
some
other
place.
The
docs
folks
have
been
leaning
away
from
that
and
leaning
towards
like
why?
D
We
get
to
keep
kind
of
the
things
we
like
about
it,
while
we
experiment
and
figure
out
like
how
could
this
live
on
the
main
site
or
how
well
does
this
work
on
its
own,
and
so
the
I
think
plan
right
now
is
to
just
link
out
to
this
page
from
the
main
Kate
stock
site
and
say
here
is
documentation
on
coop
control.
If
you,
if
you
want
to
learn
about
how
to
use
the
tool
but
again
open.
E
To
anything,
go
on
Matt
I
have
a
couple
of
first
I
think
is
trying
to
figure
out
the
initial
content.
This
is
probably
a
good
idea
and
the
way
that
coop
control
can
approach.
This
will
probably
help
other
projects
that
may
want
to
go
this
road,
like
mini
cube
or
dashboard,
or
something
like
this
that
can
have
separate
release
cycles,
also
have
their
own
documentation
that
isn't
a
nice
structured
form
for
their
thing.
E
E
Is
the
multilingual
workflow
they're
building
in
with
the
other
communities
like
China
and
Korea,
and
so
we're
going
to
eventually
want
to
get
that
in
because
there's
a
lot
of
non-english
speakers
who
are
engaging
with
this
stuff
and
they've
figured
that
out,
so
they
either
need
to
figure
how
to
bring
it
in
here
and
for
anybody
wondering
by
the
way
this
is
get
book.
Get
book
actually
does
multi
lingual.
E
So
that
is
something
if
we
did
want
to
bring
it
over
here
and
could
work
where
their
workflows
would
happen,
but
it's
just
one
of
those
things
to
keep
in
mind
and
work
out.
I
like
the
doc
book
format
for
this
I,
like
it
actually
better
than
kubernetes
Docs,
for
this
kind
of
navigation
and
thing
so
at
least
that's
my
two
cents
and
I
would
start
off
here:
I
I,
wouldn't
film.
Where
is
this
branch?
We
had
another
question
here.
Oh
sorry,.
D
D
That's
a
great
question:
do
you
mind
if
I
do
that?
Would
you
mind
if
I
had
to
update
the
notes
with
that,
like
it
I
think
like
please
yeah
it
may
have
been
because
I
need
to
make
sure
I
may
even
just
be
in
the
I,
think
I
might
have
merged
the
main
branch
back
and
yeah.
It
looks
like
I
have
so
I'm,
not
sure
how
this
is
update.
This
is
there's
the
there's
I
just
posted
a
link
to
to
where
the
code
exists.
D
E
D
D
E
Please
do
because
you've
got
at
least
one
person
and
then
maybe
myself
who's
interested
in
Docs.
You
might
come
poke
at
this
and
if
we
can
do
pull
requests
and
of
course
this
will
bring
in
the
CLA
and
everything
nicely
it's
a
way
to
help
get,
and
you
know
we
can
start
talking
and
pointing
people
over
to
this
and
say:
go
you
want
to
contribute
to
better
Doc's
on
this
stuff.
Here's
where
you
go.
D
Fantastic
yeah
I'll
do
that:
okay,
I'll,
send
an
email
to
say
caps
and
I'll,
try
and
make
sure
that's.
The
pull
request
is
up
and
by
end
of
day
thank
you
sounds
good
thanks
for
that.
Okay,
I'm
gonna
can
I
just
do
a
quick
thing
on
the
sorry
future
I
think
I
did
the
follow
up
topic.
I,
don't
know
if
I've
totally
derailed
your
meeting
here,
yeah.
D
D
Yeah,
okay
I'll
make
this
quick,
so
I
just
also
wanted
to
talk
about
like
the
vision
for
coop
control
in
2019.
I
know
that,
like
what
ku
control
does
impacts
a
lot
of
people
and
say
gaps,
and
so
just
understanding
like
where
our
priorities
are,
would
probably
be
helpful
to
everyone
and
then
allow
you
to
come
talk
to
us.
If
you
think
like
there's
something
we
can
do
that
related
to
these.
So
the
first
is
better
vision.
Skew
support.
D
This
is
something
that
ink
is
really
important
because
it
impacts
the
correctness
of
the
tool
and
also
allows
people
to
get
like
some
of
the
latest
features
on
bug
fixes
in
coop
control
for
later,
even
if
they
have
like
later
releases
the
kubernetes
server
right,
if
they're,
so
you
may
want
to
upgrade
your
client
at
a
faster
pace
than
the
main
server.
It's
gonna
be
important
when
we
move
to
a
separately
cycle.
D
So
if
we
decide
to
start
releasing
more
frequently
version,
skill
will
be
more
important,
so
I'd
like
to
have
every
version
of
kubernetes,
that's
currently
supported
or
still
getting
patch
releases
and
that
sort
of
thing
be
supported
by
the
latest
version
of
control.
The
latest
release,
which
is
not
the
case
now
so
that's
something
we
really
want
to
see:
moving
kubernetes
the
coop
control
code
into
its
own
repo,
so
that
it
can
be
built
separately
and
eventually
have
its
own
release
cycle
is
on
there.
D
This
will
also
help
with
making
sure
that
things
into
control
can
be
exposed
as
libraries
a
little
more
easily
after
that,
it's
like
extension
mechanisms
just
or
at
the
API.
So
this
is
there's
two
types
of
extensions.
We
talked
about,
there's
like
a:
how
do
we
extend
the
CLI
surface
area
itself
with
new
commands
and
that
sort
of
thing
that
are
totally
be
spoken
unrelated
to
API
is
potentially
right.
That's
not
what
I'm
talking
about
here.
What
I'm
talking
about
here
is
like
server-side
printing.
How
do
we
make
sure
like
who
control
rollout
status?
D
Is
this
command?
That
will
tell
you
about
like
the
status
of
your
deployment
rollout,
but
it
won't
tell
you
the
status
of
whatever
thing
you
built
your
CRD.
So
how
do
we
make
sure
that
all
of
the
commands
we
support
work
natively
with
service,
as
well
as
commands
that
are
bespoke
to
API,
such
as
control,
create
config
map,
for
instance,
creates
a
config
map
API?
How
can
we
make
it
so
it's
possible
for
you
to
get
those
in
get
the
same
sort
of
commands
for
your
series
without
having
to
go,
publish
a
binary
write.
D
I
just
talked
about
much
simpler
and
a
simpler
way
for
everyone,
plugins
for
more
advanced
things
that
aren't
related
to
API
is,
but
it
may
be
processing
of
files
locally
or
something
like
that
would
still
need
to
be
done
as
binary
plugins,
but
why
you'd
want
to
do
that?
It's
something
we're
trying
to
like
understand,
because,
if
it's
just
about
like
it
being
under
the
cou
control
path
like
how
much
value
does
that
add
something?
We
don't
really
know
right.
D
E
E
One
of
the
sad
things
that
we
discovered
was
that
the
clusters,
what
we're
using
many
of
them,
were
past
the
supported
release
cycle
right.
The
reality
is,
there's
a
lot
of
that
going
on
and
just
to
think
about
that
in
the
version
queue
support
to
say
you
know
what,
as
long
as
the
api's
haven't
changed,
we
can.
E
We
can
make
it
work
with
that
because,
quite
frankly,
I
mean
if
somebody's
using
like
homebrew
on
their
Mac
right
and
they've
just
upgrade
the
kubernetes
CLI
they're
gonna
have
the
latest
and
then
they're
running
clusters
that
maybe
are
still
running
1/9,
there's
totally
a
lot
of
them
out
there
still
don't
get
me
started
on
it.
It's
the
reality
of
the
situation
right.
That
kind
of
thing
would
be
just
something
to
think
about
in
the
version
skew
support,
and
then
the
other
part
is
with
plugins
and
extension
right.
E
You
talked
to
me
about
the
UNIX
philosophy
a
while
ago
for
this
stuff.
It
might
be
worth
documenting
that
somewhere
to
say
you
know
what,
if
you
want
to
do
things,
coop
control
is
meant
to
work
with
the
UNIX
philosophy.
So
you
can,
you
know,
export
and
maybe
do
things
this
way
where
it
sends
the
standard
out.
Maybe
your
VMO
file
and
if
somebody
wants
to
do
with
binary
paths
or
something
inside
it
can
be
piped
through.
We
talked
about
it
because
in
that
case
we
don't
have
to
know
all
the
different
ways.
E
D
The
latter-
yes,
that's
a
good
point.
Actually,
maybe
if
we
just
tell
people
like
you
know,
like
here's
all
the
ways
you
can
interact
with
coop
control,
whether
you
do
it,
you
can
do
these
with
the
plugin
or
without
right.
It
doesn't
really
matter.
That's
a
great
idea.
I
can
add
that
to
the
documentation
as
well,
I
think
that'd
be
helpful.
D
The
version
skew
support
I
completely
agree
right,
like
you
know,
the
the
api's
do.
Change
like
we
drop
open,
API
support
for
one,
or
rather
sorry
we
didn't
drop
it.
We
changed
the
version
of
open,
API,
we're
using
and
then
drop
the
old
one
right,
and
so
these
things
do
change.
So
so
that
doesn't
mean
we
can't
support
the
versions
right
like
we
could
leave
the
support
for
the
old
ways
and
for
a
long
time,
server-side
printing
is
good.
This
is
gonna
happen
again
right
where
we're
moving,
though
printing
into
the
server-side.
D
We
are
going
to
want
to
take
it
out
of
the
client-side
at
some
point
when
we
do
that,
it's
gonna
stop
working
for
all
the
api's
I.
Don't
have
that
server-side
printing,
yet
I
would
like
my
pipe
dream.
Right
is
to
just
draw
a
line
in
the
sand
and
say
every
to
control
version
from
here
on
out
will
be
backwards,
compatible
with
his
API
version
like
forever
right,
whether
that's
realistic
or
not.
There's
another
question,
but
yeah
getting
getting
more
than
just
the
supported
versions
would
be
great
too
right.
F
F
D
E
D
Yeah
we
actually
have
really
experimented
with
different
storms
of
mentoring
and
helping
people
contribute,
and
a
lot
of
people
actually
start
there
and
then
do
some
stuff
and
then
go
to
some
of
the
project
that
they
find
to
be
more
in
line
with
their
interests.
But
we
do.
We
are
very
friendly.
Although
it's
serious
I've
been
told
that
we're
we're
serious,
we
don't
use
enough
emojis
in
our
slag
channels,
but
we're
still
nice
people.
The.
E
George
would
know
the
right
location
in
there
that
we
were
looking
for
people
to
help
with
cron
job,
and
we
brought
it
up
at
the
community
meeting
that
we
wanted
people
to
contribute
and
we
get
a
whole
bunch
of
people
who
said
yes,
I
want
to
help
with
that.
Let
me
get
involved
so
the
next
time
you
go
present
there
I
would
really
suggest
pressing
that
and
maybe
putting
something
up
there
to
help
you
get
more
people
to
help
you
with
these
things,
because
I
know
you,
you
could
use
more
help.
Yeah.
G
Great,
so
if
we
take
back
the
the
Lego
analogy,
I
think
we
will
be
discussing
about
the
camera,
and
my
son
has
a
nice
Lego
box,
and
you
know
this
camera
that
fits
in
the
end
of
the
people.
It's
not
the
obvious
building
blocks
you
need,
but
sometimes
okay.
So
there
was
a
cap
about
portable
resource
definition
and
yeah
I
gave
it
another
name,
standard
resource
definition.
So
basically
the
idea
behind
it
would
be
to
talk
yeah,
so
the
case
of
resource
efficient,
but
the
list
of
standout
one
living
upstream,
so
yeah.
G
Let's
try
to
start
with
that.
So
I
will
speak
about
the
use
case.
Yeah.
Okay,
let's
go
so
for
me.
The
use
case
is
as
a
package
man
maintainer,
so
I
create,
for
instance,
the
helmet
on
place
for
rocket
shot.
It's
not
the
best
one,
probably
the
worst
one,
but
still
and
previously
contributed
some
other
coefficient
images,
mm-hmm
and
I'm.
Looking
at
maintaining
packages
for
technologies
for
open
source
applications
like
next
cloud,
what
has
much
more
discourse
on
skin
essence
and
the
problem
I
seem
intent
on
plates.
G
So
this
is
the
reusability
issue
and
the
second
thing
is
in
the
multi
cloud
deployments.
So,
for
instance,
openshift
is
working
on
having
things
to
be
possible
to
be
deployed
on
Azure
and
Amazon,
and
so
as
an
app
developer.
Then
you
say:
I
need
my
sequel
database
and
Amazon
has
a
different
idea
of.
What's
my
sequel
database
done,
and
so
the
80
for
me
to
solve
this
program
would
be
to
Apple
repo.
G
So
that
would
look
like
this
so
start
with
those
definitions
that
would
leave
upstream,
ideally
with
a
bunch
of
folders,
and
so
maybe
one
for
PostgreSQL
one
for
what
is
a
kind
of
s3
bucket
and
I
watched
the
see
gaps
meeting
from
last
week
about
Chrome
horizontal
todo
to
skater,
discussing
like
yeah.
This
is
great.
G
This
is
a
great
controller
like
to
share
it
around,
but
we
don't
know-
and
so
maybe,
if
the
CRT
itself
yeah
the
difference,
the
implementation,
then
I
did
other
things,
but
to
start
with
one
search,
the
post,
SQL
I,
don't
know
if
you
so
what
cause
plane
did
and
I
think
it's
really
nice.
So
there
is
a
kind
of
interaction.
G
So
this
is
how
it
looks
like
in
cross
plane
for
Postgres,
so
basically
you're
just
one
CRT,
that
is
like
post
post
SQL
instance,
and
then
you
have
a
direction
different
scenes,
inferencing
the
resource
class
compound
passwords,
and
then
this
is
how
it
looks
like
so.
This
is
this
is
a
good
cloud
PostgreSQL
compatible
api,
but
you
could
have
also
the
same.
That
would
look
like
this,
which
is
like
the
local
post,
SQL
and
the
implement
detail.
G
Detail
is
based
on
cockroach,
and
so
then
it's
up
to
the
coastal
administrator
to
decide
what
is
a
los
local
post
press
or
cloud
Postgres,
but
the
user
itself
or
the
package
maintainer
I
could
use
this
PostgreSQL
resource
that
will
be
standardized
inside
the
technologies
upstream
and
meet
them
as
a
package.
Maintainer
I
could
use
this
objective.
G
So
this
is
one
example:
I
will
not
go
through
the
backup
one,
the
ads
binding.
One
is
interesting,
because
this
is
like
the
standard
way
that
obscured
came
up
with
to
basically
do
the
service
catalog
binding,
but
you're
not
detailed
up,
because
I
don't
have
time.
Yes,
so
everything
here
looks
really
like
Service
Catalog,
so
how
to
create
an
instance
and
how
to
delete
an
instance
and
how
to
bind
to
it,
but
for
me,
Service
Catalog
s
too
much
mutations
so,
for
instance,
day
to
operation.
G
So
if
you
take
the
example
of
my
sequel,
RDS
running
on
Amazon,
what
if
you
want
to
take
a
backup?
So
this
is
not
planned
on
the
sons
catalog.
So,
basically,
you
need
an
operator
anyway,
and
there
are
many
things
around
them
too,
and
these
three
operations,
another
thing
is
watch
resources.
So
nice
thing
about
controller
is
that
the
controller
enforces
the
state,
whereas
the
Service
Catalog
is
just
about
deploying
or
creating
an
instance
of
it,
but
it's
not
getting
watching
this
how-to
your
update
resource.
F
A
B
A
G
E
So
so
I
was
the
one
who
is
carrying
that
cap
for
so
I'm
happy
to
chat
about
it.
There's
some
other
considerations.
We
have
in
fact
I've
got
some
some
changes
to
propose
to
the
cap
as
well
to
make
it
more
like
TVs,
PVCs
and
storage
classes.
But
one
of
the
things
like
we
have
to
deal
with
is
if
your
WordPress
right
and
something
the
Service
Catalog
doesn't
deal
with,
is
give
me
a
standard
way
of
getting
the
database
credentials
out.
So,
if
I
deploy
it
in
a
jar,
I
have
deployed
a
Google
employee.
E
And
how
do
we
do
that
right?
I'll
have
to
go
read
up
on
it.
Unfortunately,
I
have
not
had
the
chance
to
read
through
all
your
work.
I
just
got,
but
that's
one
of
the
things
that
we
need
to
figure
out
here,
and
so
the
idea
was
actually
in
kubernetes
to
have
a
catalog
of
all
of
those
CR
DS
/
thing
and
then
also
include
the
closed
loop
secrets
where
it
needed
to
be
with
a
schema
and
instead
of
the
type
being
opaque,
you
can
have
a
specific,
tight
and
tie
that
back
to
the
project.
E
So
you
can
have
different
controllers
from
different
people
that
do
different
things.
That
was
the
intent
of
it
and
to
close
the
loop,
and
all
of
this
so
I
think
we're
thinking
along
the
same
lines,
and
this
is
probably
a
good
chance,
maybe
for
us
to
either
get
together
this
week
or
continue
this
conversation
in
cig
Apps
next
week
to
to
progress
this,
but
I
probably
want
to
do.