►
From YouTube: Kubernetes SIG Apps 20171023
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
A
The
next
thing
that
we
have
up
is
some
stuff
in
testing.
So
when
it
comes
to
the
flaky
tests,
there's
two
bullet
items
here
say:
gaps
is
now
the
worst
outlier
they
discussed
in
the
community
meeting
a
week
ago.
We
brought
it
up
here
and
so
we're
looking
for
folks
who
can
jump
in
on
the
job
tests,
because
that
appears
to
be
where
some
of
the
flakiness
is
and
then
there's
just
one
with
network
partitions
and
there's
an
issue
on
it.
A
Both
of
them
are
are
here,
and
so,
if
you're
working
on
any
of
those
bits,
if
you
could
take
a
look
at
it,
because
we're
now
becoming
the
outliers
and
I
might
start
looking
for
folks
specifically
to
go
fix
some
of
this,
so
we
can
clean
up
some
of
the
flaky
jobs
and
failed
tests,
and
so
that's
it
for
the
opening
stuff.
Next,
we
have
a
demo
for
meta
controller.
Do
we
have
somebody
online
to
talk
about
meta
controller?
A
B
B
Can
you
see
the
screen
yeah
alright,
so
my
name
is
Anthony.
Hey
I
wanted
to
do
a
demo
of
a
proof
of
concept
that
I'm
working
on
called
medic
controller,
and
the
idea
here
is
it's
kind
of
analogous
to
CRD.
They
build
on
CID,
where
you
know
what
CRT
you
kind
of
it
gives
you
a
really
easy
interface
to
add
new
custom
resources
and
the
API
server
will
serve
those
for
you
on
your
behalf.
B
You
can
kind
of
customize
a
little
bit
what
it's
doing
now
with
things
like
JSON
schema
validation,
but
the
idea
is
whatever
you
want
it
to
do
on
your
behalf.
You
describe
that
in
the
CID
object
and
they
will
do
it
for
you.
This
is
a
similar
thing,
but
for
the
controller
side,
so
I
want
to
create
the
CID.
It's
just
a
dumb
object
that
sits
there
in
stores
data.
What
really
makes
it
into
like
a
full
API.
B
You
know
abstraction
to
kind
of
make
it
easier
to
write
new
controllers,
so
you
can
think
of
this
kind
of
my
analogy.
This
is
trying
to
do
for
controller
part.
What
CRD
did
for
custom
resource
so
to
write.
A
controller
is
now
going
to
be
more
of
a
declarative
thing.
That's
just
caused
into
your
hook.
B
So
more
concretely,
the
kind
of
modest
goal
here
is
to
put
an
end
to
all
feature:
requests
filed
against
a
gaps
to
get
started.
I'll
show
an
example.
First,
just
talk
about
that.
This
is
a
cluster
hat
on.
You
can
put
it
in
any
career
nice
cluster
and
you
can
just
install
it
without
having
to
rebuild
anything
I'm.
B
The
meta
controller
and
on
itself
there's
a
bunch
of
stuff
for
our
back,
but
other
than
that.
It's
truly
just
creating
a
couple
of
CDs
there's
an
API
called
lambda
controller,
another
one
called
initialize
your
controller,
and
then
it's
launching
the
pod
that
actually
runs
the
minute
controller
itself.
B
So
the
first
example
is
what
I
call
a
cat
said,
which
is
kind
of
a
reincarnation
of
pet
set,
and
this
is
basically
a
reimplementation
of
pet
set
in
JavaScript,
and
the
only
reason
I
chose
JavaScript
is
one
to
show
that
it
can
be
any
language,
because
this
is
going
over
a
web
hook,
and
the
other
reason
is
because
the
way
this
works,
all
we're
doing
is
passing
you
JSON.
You
make
a
decision
on
what
you
want
to
happen
and
you
return
JSON
after
that,
so
Daesan
and
json
out.
B
Javascript
is
actually
really
nice
language
for
working
with
it.
It
gives
you
some
really
clean
syntax.
If
you
look
through
this
all
its
really
doing,
is
you
know,
there's
some
stuff
that
fills
in
a
pod
template
kind
of
like
if
you
were
doing
a
client-side
generator,
except
that
this
is
going
to
be
running
on
the
server
side
in
the
cluster
and
reacting
dynamically
and
then
at
the
bottom.
B
You
just
have
the
the
actual
business
logic
of
pets,
an
or
saiful
said,
and
this
is
just
really
ported
from
the
actual
go
code,
but
now
it's
in
JavaScript.
So
it's
just
doing
things
like
put
the
pods
in
order
decide.
You
know
whether
to
fill
things
in
if
everything
below
it
is
ready
and
so
on
and
so
forth.
So
let
me
try
to
run
this.
B
That
it
behaves
like
pets
it.
This
is,
as
you
may
have
noticed,
it's
just
like
100
lines
of
JavaScript,
so
it's
not
really
worth
building
a
whole
image
for
it.
I'm
just
going
to
put
this
into
a
config
map.
B
B
B
But
then
what
we
have
down
here
is
this
implication
of
the
new
lambda
controller
API.
As
part
of
my
project,
which
is
saying
start
running
this
controller
on
my
behalf
and
I'll,
tell
you
some
of
the
things
that
you
need
to
know
like
this
is
the
parent
resource.
These
are
the
things
that
I
care
about
as
children
and
it'll
implement
things
like
controller
F
for
you
and
then
this
is
how
you
talk
to
my
hook,
where
I
tell
you
the
business
logic
of
what
you
want
to
do.
B
And
this
is
really
just
a
copy
and
paste
of
the
stateful
set
example
that
you'll
find
in
the
docs,
except
that
I
replaced
the
API
version
in
kind
so
other
than
that
it's
just
implementing
the
same
stateful
set
API
and
what
we
should
see
is
yeah.
It's
just
kind
of
loading
up
and
similar
to
staple
said.
B
B
B
Yes,
now
there's
a
new
label
here,
so
you
just
went
through
update
a
config
map
and
restart
a
controller.
Now
you've
got
a
new
feature
that
you
just
added.
I
won't
go
through
this
other
example
just
for
time,
but
there's
another
one
that
you
know
has
been
a
feature
request.
That's
been
sitting
here
for
about
over
a
year
now
and
really
all
it's
saying
is
you
know,
I
want
to
have
a
little.
B
My
own
different
system
of
automating
deployment,
rollouts
and
I
have
another
example
that
you
can
look
at
in
the
repo
here
where
I
just
wanted
implemented.
That-
and
this
is
really
just
taking
like
very
similar
API
to
what
deployment
is
now.
People
go
and
work
with
replica
sets
for
you,
but
it
just
implements
this
different
way
of
doing
rollouts
did
and
that
the
user
described
here
so.
C
B
B
A
So
this
is
interesting
because
we've
been
talking
here
a
little
bit
about
operators
and
there's
another
project.
We've
been
looking
at
called
operator
kit,
and
now
there
is
this
with
controllers
and
it
gets
into
kind
of
application
management
and
what
you
can
do.
I,
don't
know
if
you've
looked
at
operators,
but
is
there
anything
you
can
talk
to
draw
comparisons
or
contrasts
between
what
you've
got
here
and
something
like
operator,
kit,
yeah.
B
So
I
see
operator
kit
is
being
kind
of
sort
of
like
API
server
builder.
By
analogy,
like
you
makes
CRD
or
you
can
make
your
own
API
server.
Api
server
builder
helps
you
if
you
want
to
go
the
path
that
gives
you
the
full
power.
This
is
the
analogy
to
CID.
You
can
use
lamda
controller
or
meta
controller.
If
you
just
want
a
very
simple
thing
that
fits
into
the
pattern
that
we
can
provide,
that's
all
you
need.
You
just
declare
a
resource
and
you're
done.
D
A
B
A
A
A
D
Well,
go
ahead
and
get
started
so
there
was
discussion.
Let
me
see
if
I
can
share
on
the
gaps
and
six
Eli
mailing
lists.
I
wrote
kind
of
an
overview
of
some
history
and
the
about
thinking
behind
how
declarative
application
management
was
intended
to
work
in
kubernetes,
and
there
was
some
follow-up
discussions
and
it
was
decided
to
form
a
working
group.
D
So
yeah
so
anyway,
it
was
decided
to
form
a
working
group
and
the
I'm
going
to
talk
a
little
bit
about
the
focus
of
the
working
group.
It's
a
little
bit
originally.
This
was
this
presentation
was
scheduled
before
we
had
formed
the
working
group
and
I
was
planning
to
explain
some
parts
of
my
document.
I'll
still
do
that,
but
less
of
a
focus
on
that
more
what
the
application
working
group
application
definition
working
group
is
going
to
focus
on
and
hopefully
Antoine
will
join,
so
he
can
I
product
since
he
agreed
to
help
lead.
D
D
E
Sure
so
I
just
seen
there
is
a
lot
of
tools
in
psycho
system
and
they
suit
to
sing
like
it's.
There
is
a
lot
of
opinion
and
there
is
like
also
maybe
something
missing.
A
stream
and
the
working
group
is
we're
going
to
try
to
improve
this
and
by
improving
just
thinking
about
finding
like
a
as
a
nun,
called
a
silver
bullet
solution.
It's
just
like
really
try
to
find
interface
concern
and
and
improve
initial
primitive,
so
I
think
that
is
going
to
explain
like
the
ketchup
relative.
We
can
improve
them
and
before
improve.
E
D
D
Okay,
so
I'm,
not
I,
wasn't
entirely
sure
everyone
really
understood
what
we
meant
by
declarative,
primitives
and
talk
a
little
bit
about
that,
and
why
is
the
way
it
is
so
my
primitives
I
mean
the
kubernetes
api
itself
and
the
mechanisms
surrounding
the
api,
including
the
client
libraries.
We
support,
like
client,
go
and
open
API
base
tools.
D
All
the
API
is
that
you
know
about
and
then
queue
control
just
because
it
is
a
client
that
is
maintained
by
the
core
project,
not
that
it
has
necessarily
any
special
status
other
than
that.
Eventually,
I
would
like
to
get
keep
control
moves
out
of
the
through
ninety's
Primanti's
repository
into
its
own
repository
with
its
own
cycle.
D
There
are
a
bunch
of
improvements
we
need
to
make
control
before
that
will
be
possible,
but
in
the
meantime,
we'd
like
to
remove
friction
cute
control
issues
that
have
impede
declarative
kind
of
workflows,
you
just
and
the
declarative
model
and
users
would
like
to
be
able
to
write
their
configurations
and
whatever
syntax
or
schema,
doesn't
matter
for
this
conversation
that
would
like
to
write
it
basically
just
invoke
one
command
to
make
it
so
and
that's
the
only
command
they
should
have
to
use.
Actually
Anthony's
demo
demonstrated
the
power
of
that
control.
Apply.
D
Just
do
my
and
ma
the
resources
get
instantiated
in
the
cluster,
whether
they
are
built-in
resources
like
deployment
or
custom
resources
like
the
cat
set.
So
that's
a
really
powerful
and
simple
model,
especially
for
updates
updates,
are
really
the
killer,
app
in
some
sense
for
declarative
management,
but
in
general
declarative.
The
declarative
approach
allows
you
to
applied
multiple
operations
to
the
same
set
of
resources.
Those
resources
effectively
describe
the
topology
of
your
application
or
your
policies
or
whatever
it
is.
D
You
want
to
instantiate
and
which
things
you
want
to
exist
or
which
do
exist,
and
then
that
enables
you
to
specify
multiple
different
operations.
In
fact
keep
control
you
can
do
not
only
apply
but
create
delete,
even
get
you
can
just
specify
resources
by
file
or
by
name
or,
however,
you
want,
and
it
will
identify
those
resources
and
do
the
operation
that
you
specify,
but
right
now
there
are
certain
changes
that
people
want
to
make
which
don't
work
so
well
with
keep
control.
D
I
didn't
have
time
to
do
a
demo
or
an
example,
but
you
know
anybody
who's
tried.
It
knows
you
know
you
have
to
figure
out.
Okay,
how
do
I
actually
update
my
image
with
docker?
A
lot
of
people
just
want
to
push
to
the
same
tag
again
and
then
expect
that's
rollout,
but
that
has
a
that
approach.
Does
it
works
so,
naturally,
with
with
kubernetes
and
the
rollout
mechanisms
we
provide
like
rolling
update,
so
we
would
like
to
smooth
out
some
of
those
rough
edges.
D
He'd
control
also
has
a
number
of
imperative
commands.
Keep
control.
Ron
is
probably
the
one
that
people
use
most
often,
but
also
we
saw
in
Anthony's
demo
acute
control
create
secret
our
acute
control,
trade,
config
map,
sorry
and
both
of
those
commands.
That's
probably
the
second
most
common
imperative
span
that
people
use
creating
a
config
map
from
some
data
on
disk,
whether
it
be
a
file
containing
environment,
variable
mappings
or.
D
D
But
there's
a
lot
of
cruft
in
the
ya
know
like
it's
generated
due
to
various
issues
with
how
we
express
Express
the
schema
and
our
types,
echo
files,
so
everybody's
probably
seen
like
creation
timestamp
null
or
stop
an
empty
status
and
resource
they
spit
out.
That
just
creates
fishing,
because
people
go
and
feel
like
they
have
to
remove
those
lines
by
hand
every
single
time.
D
So
we
should
just
clean
that
up
so
they're
they're,
a
bunch
of
things
like
this,
which
are
not
you,
know
huge
bugs
that
are
totally
broken,
but
it
just
makes
it
less
natural
to
use
these
kinds
of
commands
and
these
kinds
of
ways
so
also
keep
control
of
create
secret
like
why
can't
or
queue
controlled
trade
config
map.
Why
don't
I
have
just
a
way
of
using
that
with
apply
directly?
That's
a
long,
long-standing
request.
D
We
need
to
move
more
of
cute
controllers
functionality
actually
into
reusable
libraries,
and
we've
done
a
little
bit
of
work
around
that,
but
also
into
the
V
API
for
super
super
commonly
needed
operations,
and
one
of
the
biggest
examples
of
that
is
deployment.
The
deployment
API.
Originally,
we
had
implemented
rolling,
update
and
keep
control
mostly
due
to
experience,
but
then
you
could
only
do
rolling
update
to
keep
control
and
is
brittle
and
it
had
another
number
of
other
disadvantages.
D
So
we
actually
built
a
controller
in
an
API
for
that
and
that
enables
all
kinds
of
clients
to
access
that
client,
libraries
or
in
other
languages
like
JavaScript.
So
you
can
access
it
from
medic
controller
or
a
UI
or
whatever
is
you
can
access
that
functionality
so
we're
trying
to
make
cute
controls,
slimmer
and
slimmer
and
use
it
as
a
way
for
providing
kind
of
narrower
functionality
or
super
general-purpose
functionality
that
works
with
every
resource,
but
kind
of
the
heavy
heavy
lifting
in
terms
of
more
complex
operations?
D
And
then
you
know.
Finally,
one
of
the
issues
that
I
mentioned
that
needs
to
be
resolved
in
order
to
move
cute
controller
out
into
an
independent
repository
within
a
release
cycle
is
to
fix
forward
compatibility
issues
and
the
main
blocker
there's
just
for
most
operations
not
to
rely
on
built-in
types,
because
that's
not
extensible,
it
doesn't
work
with
API
aggregation
or
CRD.
D
So
why
is
cute
control
apply
so
special
and
and
subtle?
Well,
first
of
all,
what
problem
wasn't
intended
to
solve?
The
main
problem
apply
was
intended
to
solve
is
to
update
declaratively
matter
state
without
clobbering
non-declarative
state.
Why
people
wonder
why
can't
I
just
do
a
put
and
have
and
just
update
my
spec
and
do
a
put?
Why
doesn't
that
work?
And
this
is
really
the
reason
why
it
works
it
doesn't.
Work
is
because
they
would
clobber
non-declarative
state
so
yeah.
So
what
what
kinds
of
non-declarative
state,
where
you
have?
D
Wouldn't
everything
just
be
declarative
in
your
configurations,
so
they're
they're,
a
bunch
of
examples?
Cute
controls
support
some
in
period
of
operations
and
I'm
just
using
cute
control.
Here's
an
example
on
the
assumption
that
people
are
familiar
with
it.
But
of
course
you
could
do
these
other
ways.
Keep
control
label
or
annotate
may
have
some
information
that
you
want
to
attach
to
resources
that
is
not
specified
in
your
configuration
files.
D
I
may
not
even
make
sense,
or
you
may
have
different
teams
responsible
for
managing
those
configurations
and
managing
the
operational
side.
Once
everything
is
deployed,
scaling
is
probably
the
most
common
example.
Just
keep
control
scale
horizontally
scale
in
dr
compose
for
a
long
time
I
don't
I
haven't
looked
at
it
recently.
They
didn't
even
have
away
specifying
scale
in
a
compose
file
that
was
always
operationally
specified
right
in.
D
Might
want
to
specify
it
yes,
this
must
always
be
5,
and
certainly
that's
more
common
for
stateful
applications
for
state
lists.
Often
people
want
to
scale
based
on
load
based
on
other
things.
Sometimes
they
deal
automatically
like
with
horizontal
pod,
auto
scaling
in
in
the
future
vertical
pod,
auto
scaling
to
set
CPU
and
memory,
but
even
some
people,
even
just
do
it
by
hand
like
they
have
a
diurnal
cycle,
so
they
set
a
cron
job.
D
D
People
cute
control
set
image
is
super
common
as
part
of
continuous
deployment.
You
know
you
set
up
a
filter,
build
a
new
container
image,
get
the
get
the
digest
and
then
just
do
keep
control
set
image
with
the
digest.
You
want
to
may
not
want
to
do
that
through
the
declarative,
configuration
path,
because
you
know
you
just
be
continuously
updating
that
maybe
multiple
times
a
day
and
you
always
are
going
to
reconstruct
that
from
whatever
the
latest
tag
is
in
your
image
image
repository.
You
don't
need
that
to
be
also
in
your
git
repository
right.
D
D
Me
now,
yes,.
D
A
D
Unplug
for
the
microphone
yeah
so
anyway,
I
was
just
saying
in
my
experience:
there's
no
hard
line
between
properties,
you
that
sometimes
one
you
want
to
manage
declaratively
in
your
configuration
and
check
it
into
source
control
and
other
times
you
don't
want
to
manage
it.
That
way
you
want
to
manage
it
imperative,
lis,
operationally
or
even
automate,
fully
automate
so
apply
is
intended
to
handle
this
in
a
graceful
manner
for
arbitrary
attributes.
D
So
how
does
it
work
applies
three-way,
merge,
I,
say
think
of
it
as
it
get
merge.
It
doesn't
literally
work
like
that
for
various
reasons,
but
I
think
that's
a
good
way
to
think
about
it.
Like
you
make
a
clone
of
some
git
repository
in
the
meantime
that
git
repository
all
the
other
commits,
may
be
merged
and
may
be
changed.
You
make
your
changes
and
then
you
want
to
merge
those
in
and
hopefully,
if
you're
lucky
and
you're,
not
touching
generating
code
or
something
it
all
merges
with
no
conflicts
right.
D
D
Then
you
start
from
not
from
the
last
day,
but
you
start
from
your
previous.
We
specify
a
declarative,
configured
State
and
you
update
that,
and
now
you
want
to
apply
effectively
your
changes
as
long
as
they
don't
conflict
with
the
live
State.
Now
it's
not
quite
the
same
and
that
you
actually
expect
the
other
properties
you
specify
declaratively
to
also
remain
the
same
right.
So
there's
it's
not
quite
the
same
is
get
merge.
D
For
that
reason,
you
actually
want
to
assert
that
those
other
properties
are
the
same
and
you
probably
wanted
to
take
conflicts,
and
in
some
cases
you
want
to
be
warned
about
the
conflicts
and
in
other
cases
you
just
want
to
stop
whatever
was
there,
for
example,
it's
common
to
tweak
things
during
debugging
or
fire
fighting
and
then
what
to
make
them
after
the
fires
out.
You
want
to
make
everything
the
way
it's
supposed
to
be
again,
but
I
have
a
little
example
here,
that's
kind
of
simple
and
really
action.
D
Everything
would
be
simple
if
you
just
had
a
flat
set
of
fields
right,
but
if
you
had
a
declarative
state
of
one
field
bar
with
a
value
Pokemon
and
alive
states
that
also
included
another
attribute
foo
with
a
value
of
five,
then
you
want
to
change
your
declarative
state
bar
to
causality,
and
you
didn't
want
to
stomp
the
value
of
five
for
foo
right.
You
want
to
merge
your
change.
A
bar
in
with
the
live
State
and
not
stop
on
foo,
so
apply
is
through
this
three-way.
Merge
is
what
does
that?
So?
D
Why
is
it
complicated?
Mostly
it's
complicated,
just
because
it's
never
had
an
owner
or
a
systematic
design,
it
just
kind
of
evolved,
ad
hoc
and
recently
a
new.
It
is
reimplemented
in
order
to
fix
that
part
of
the
problem,
but
also
there's
a
lot
of
schema
complexity,
because
the
schema
wasn't
really
designed
to
do
this,
even
though
we
had
in
mind
from
the
beginning
that
we
wanted
to
be
able
to
do
it.
D
We
didn't
have
the
mechanism
implemented
when
we
started
gay
bi,
so
we
weren't
able
to
use
that
to
inform
the
evolution
of
the
API
over
time.
So
non
positional
list
is
probably
the
number
one
complex
thing.
We
have
a
number
of
lists
which
are
effectively
like
Maps.
There
keep
lists
so
can
the
Container
lists
and
the
pod
spec
is
probably
the
best
example
of
that
the
containers
are
identified
by
the
container
name,
not
by
their
position
in
the
container
list.
D
So
if
you
want
to
defer
we'll
add
another
container
to
the
list,
you
might
not
always
want
to
add
it
to
position
one.
It
depends
on
where
the
actual
containers
are
in
the
list.
Actually,
this
complicates
a
lot
of
things
because
now,
if
you
want
to
update
any
property
of
an
item
in
the
list,
you
have
to
be
able
to
find
the
right
item
in
the
list
in
order
to
be
able
to
update
that,
and
so
similarly,
we
have
number
of
sets
that
are
generally
represented
as
lists
we
have
undiscriminating
unions
in
the
API.
D
The
volume
sources
are
probably
the
best
example
of
that
there
is
a
bunch
of
implicit
context
where
multiple
different
structures
are
actually
the
same,
but
they
have
different
sets
of
information
populated
object,
references.
You
have
all
kinds
of
different
flavors
of
object,
references
probably
those
examples,
so
these
are
all
the
complicating
factors
that
actually
make
it
hard
to
just
match
up
one
version
of
a
resource
with
with
another
and
be
able
to
match
up
all
the
sub
parts
and
actually
correctly
determine
how
to
dip
them
or
how
to
patch
them
and
merge
them
together.
D
D
But
if
you
are
say,
removing
a
label
or
something
like
that,
removing
a
map
element
or
a
list
element,
then
there
has
to
be
some
way
to
express
that,
and
we
didn't
have
a
first-class
way
of
expressing
the
merge
operation
through
the
API.
So
a
number
of
delete
proper
operations
were
added
to
our
own
custom
patch
flavor
called
strategic
merge
patch.
D
In
order
to
express
that,
but
again
it
was
done
in
an
ad
hoc
way
and
wasn't
really
thought
through
all
the
cases
that
needed
to
be
supported,
there's
a
bunch
of
confusing
defaulting
behavior,
especially
default
setting
one
field
from
values
in
another
field
or
from
some
parts
of
another
field.
My
favorite
example
is
image,
pull
policy,
which
is
that's
always
if
the
tag
on
the
image
is
latest.
That's
like
not
only
does
that
complicate
apply
that
just
confuses
people,
so
those
kinds
of
things
we're
trying
to
try
to
fix.
D
For
example,
the
v1
workload
api's
will
not
default
selector
from
popped
and
put
labels
in
park.
For
this
reason,
but
also
because
it's
confusing
and
it's
an
example
of
this
non-declarative
friendly
api
behavior,
like
you,
can
easily
change
a
selector
in
a
way
and
it
orphans
the
pods
of
a
controller
right
and
one
could
imagine
ways
of
making
that
more
declared
and
friendly.
But
it
makes
the
API
implementation
the
controller
implementation
way
more
complicated
and
it
seems
like
it's
not
worth
it
so
effectively.
D
Labels
are
like
names
and
that
they
identify
the
resources
themselves
and,
to
the
extent
that
the
declarative
model
kind
of
depends
on
being
able
to
figure
out
what
the
declarative
configuration
applies
to
you.
Changing
the
names
in
between
declarative
operations
is
just
asking
for
asking
for
trouble
so
anyway,
and
hopefully
that
gives
people
a
better
understanding
of
why
just
updating
the
declared
state
is
not
as
simple
as
it
might
seem.
D
We
hope
to
work
through
some
of
these
use
cases,
including
some
of
our
own
dog
food,
eat,
our
own
dog
food,
like
we
have
utility
jobs,
documentation,
examples,
add-ons
and
other
things
that
we
can
try
out
various
approaches
on,
but,
as
Antoine
said,
as
we
prototype
and
and
work
through
these
example
examples.
Hopefully
new
mechanisms
we
come
up
with
or,
as
we
fix
some
of
the
issues
that
we
talked
about,
we
can
actually
get
feedback
from
people
on
whether
it's
actually
better
or
not
so
I'm
also
going
to
talk
for
a
few
minutes.
D
This
is
the
only
this
is
the
final
topic:
yep,
okay,
so
I'm
going
to
quickly
go
through
some.
What
I
call
customization
examples
to
inform?
Why
there's
no
silver
bullet
or
why
multiple
approaches
people
seem
to
want
to
try
multiple
different
approaches,
a
lot
of
people,
think
of
customization
in
the
context
of
template.
What
people
some
people,
call
template,
ization
or
parameterization,
making
it
possible
to
instantiate
a
declarative
configuration
in
multiple
different
ways,
depending
on
some
context
that
context
might
be
parameter
values
or
it
might
be
something
else.
D
But
really
the
broad
thing
you're
trying
to
do
is
take
an
off-the-shelf
configuration
and
customize
it
for
for
your
needs.
It's
supported
by
almost
all
those
tools
I
listed
before
parameterization
is
definitely
the
most
common
form
by
far,
but
not
the
only
one
and
I
have
some
links
to
some
examples.
D
D
Customizing
identity
in
some
cases
is
common
as
well,
but
that's
by
far
the
overwhelming
majority
for
jint
more
generic
templates,
like
just
starting
up
engine
decks,
or
even
just
a
service
and
employment.
Those
kinds
of
things:
it's
pretty
common
to
customize
things
like
the
command-line
arguments,
environment
variables
in
config
files,
resource
parameters
are
super
common,
like
CPU
memory,
number
of
replicas,
the
image
or
image
tag,
those
kinds
of
things
there.
D
Other
properties
are
less
commonly
customized
in
kubernetes
things
that
are
more
part
of
the
operational
environment
like
security
policy
and
those
types
of
things
are
often.
People
want
to
customize
nan
they're
declarative
configuration
because
they're
more
operator
concerns
that
are
different
depending
on
the
environment
in
which
she
deploy
it,
but
they
want
to
specify
it
out-of-band
through
some
other
mechanisms
like
admission
control
is
a
common
one.
D
We
support
limit
range,
pause
security
policy
and
now,
with
admission
control
extension,
you
can
use
that
to
inject
all
kinds
of
operational
configurations,
scheduling
constraints
whatever
it
is,
and
that's
another
case
where
you
need
to
merge
the
declaratively
managed
state,
and
so
so
declaratively
manners
state
so
yeah.
So,
just
talking
about
basic
strategies,
I'm
for
a
long
time
in
kubernetes,
we've
just
written
out
the
the
raw
literal
yeah
Mille
for
the
API
resources
and
that's
simple
and
it
helps
teach
the
API
the
kubernetes
api
and
it's
also
pretty
easy
to
form.
D
If
you
want
to
customize
it,
you
can
just
you
know,
even
just
copy-paste
the
example
and
customize
it
to
your
needs.
Literally
forking
is
useful
if
you
want
to
be
able
to
rebase
and
get
pickup
changes
from
the
original
and
use
tools,
you're
familiar
with
for
looking
at
the
diffs
and
resolving
conflicts,
and
if
you
only
need
to
stamp
out
one
one
version
of
that
application.
It's
a
pretty
natural
and
straightforward
thing
to
do.
Another
approach,
which
is
not
super
commonly
used
in
community
space
so
far,
is
patching.
D
Kpm
antwon's
kpn
actually
supported
a
version
of
this
awhile
back
around
the
time
that
helm
was
getting
started
and
it's
something
that
we're
exploring
exploring
now
but
patching
enables
makes
it
straightforward
to
potentially
instantiate
multiple
different
instances
or
to
combine
multiple
different
patches
together
in
the
same
resource.
So
there
are
a
bunch
of
other
techniques
that
you
can
use,
but
my
main
point
and
I
put
parameterization
at
the
bottom
I
already
mentioned.
That
one
is
that
there
are
more
approaches
than
just
parameterization
that
people
can
use
to
customize
off-the-shelf
configurations
good
within
Google.
D
We've
tried
lots
and
lots
of
different
approaches:
lots
of
custom
configuration,
dsls,
python-based
domain-specific
languages
for
configuration.
One
interesting
pattern
is
that
people
want
to
build
automation
on
top
of
the
basic
orchestration
mechanisms
and
on
top
of
other
transformations
that
are
done
in
the
configuration
system.
We
got
this
huge
configuration
ecosystem
inside
of
Google,
and
then
people
want
to
build
an
automation
on
top
of
it,
make
you
figure
out
fit.
Well,
it's
not
really
possible
to
build
automation
on
top
of
the
general
configuration
languages.
D
So
then
they
build
a
datum
data
model
over
a
restricted
subset
of
the
configuration
language
in
order
to
leverage
the
tooling
beneath
that
right,
so
effectively,
they're
building
an
API
or
a
data
model.
On
top
of
that's
clear
to
staff
just
to
reuse
all
that
code,
which
is
written
in
some
four
key
language.
D
So
that's
one
reason
why
I
feel
like
anchoring
declarative
management
around
the
actual
API
or
custom
resources
like
CR
DS
is
a
good
way
to
go
because
I
always
see
people
gravitating
back
towards
that
and
I
don't
know
if
people
saw
the
there's
an
old
blog
post
from
a
few
years
ago.
The
configuration
complexity,
clock
that
goes
around
from
hard
coding,
everything
to
making
everything
a
parameter
to
writing
some
custom
rules,
language
to
writing.
A
turing-complete
DSL
and
the
background
are
coding.
D
D
But
anyway,
yeah
so
coming
back
to
interoperable
building
blocks,
I
think
you
know
there
are
a
lot
of
commonalities:
common
needs
between
the
different
tools,
existing
tools.
You
know
it's
pretty
easy
to
just
run:
seturam
suppsed
or
something
like
that
to
do
some
basic
parameterization.
These
tools
are
a
lot
of
them.
Since
people
don't
them
themselves.
We're
focused
on
what's
easy
to
build
versus,
what's
easy
to
use,
but
as
a
consequence,
they
hide
information
from
other
tools.
D
For
example,
the
parameters
are
typically
not
discoverable
if
you
want
to
build
a
UI
or
a
form
generator
or
validation
tool
or
documentation,
or
something
like
that,
on
top
of
it,
the
or
even
just
being
able
to
find
off-the-shelf
applications
and
pull
them
down
locally,
so
that
you
can
then
deploy
those.
That's
a
basic
thing
that
you
need.
Regardless
of
what
syntax
you
wrote
your
configuration
in
so
here's
just
an
example
of
a
helm
chart
where
basically,
every
line
was
parameterised
I
think
there
are
better
ways
to
solve
scenarios
like
this
than
just
parameterization.
D
So
if
columns
supported
just
as
one
example
other
when
they's
to
customize
configurations
and
other
schemas,
and
things
like
that,
then
people
could
use
all
the
rest
of
helm
and
use
a
more
suitable
solution
to
this
particular
problem.
So
what
are
these
overlapping
concerns
and
font?
You
want
to
talk
about
this
a
little
bit
since
this
year
and
maybe
talk
about
what
you
work
in.
E
Yeah
so
I'm
not
trying
to
find
like
different
concerns.
We
can
work
on.
One
of
them
is
application
metadata.
So
some
tools
of
metadata,
like
hem
of
the
chart,
is
some
and
say
well.
If
every
package
does
require
more
days,
is
the
same
set
of
information,
so
we
can
just
maybe
agree
on
that
and
and
then
think
about
tools
to
to
leverage
this
information
cross
cross
store.
So
I
will
probably
do
a
demo
about
that
next
week
or
form
weeks,
I,
say,
parameter,
schema,
I,
think
it's
very
interesting.
A
E
D
D
I,
just
wanted
to
emphasize
Oh
Antoine
for
people
don't
know,
is
working
on
registry,
which
already
supports
multiple
different
configuration
schemas
and
needs
the
common
source
metadata.
Basically,
the
same
information,
that's
in
chart
by
Hamel
right,
so
that's
kind
of
a
proof
of
the
concept
that
common
information
could
be
used
across
multiple
different
tools.
So.
A
So
because
we've
only
got
a
few
minutes
left
here,
I
wanted
to
jump
in
and
point
out
a
couple
of
other
things.
One
thing
that
I
didn't
see
in
this
deck
is
user
experience
or
developer
experience,
because
you
know
when
it
comes
to
developers
who
actually
have
to
consume
some
of
these
things
that
we
might
break
out
of
coop
control
or
that
we
need
what's
the
experience
like
for
them
and
how
do
we
know
that
it
meets
their
needs
and
and
the
use
cases
and
the
problems
they're
bumping
into.
A
There
are
a
lot
of
opinions
that
were
in
here,
but
do
they
actually
meet
the
needs
because
you
know
we've
got
I,
see,
we've
still
got
32
connections
to
this
call,
and
so
we've
got
a
whole
bunch
of
people
who
are
building
and
using
and
dealing
with
operating
applications.
Today,
and
so
one
of
the
things
that
were
tasked
with
in
this
working
group
is
actually
collecting.
What
problems
are
you
running
into
now?
A
You
know
where
are
you
seeing
roadblocks
with
your
tools
today,
so
that
way
we
can
take
and
listen
and
not
just
have
opinions
on,
go
forth
and
do
it
this
way
or
that
way.
But
actually
you
know
there
are
a
bunch
of
tools
out
there
with
different
ways
of
doing
things,
some
good
some
bad
and
different
people
having
opinions
on
what's
good
and
bad,
and
why
and
so
and
there's
roadblocks
that
you
weren't
into
you're,
like
I,
can't
find
a
way
to
easily
do
this
or
doing
something.
A
This
way
ends
up
being
a
lot
of
extra
work
and
it's
a
pain
to
do.
Or
this
way
has
these
pitfalls,
where
I
might
end
up
screwing
something
up
because
I
changed
it
in
two
places
and
not
the
five
places
it
needs
to
be
changed.
There's
different
things
like
that
that
we're
gonna
run
into,
and
so,
if
you
have
stuff
like
that
feedback
you
want
to
give
you
can
either
send
it
to
me
Maia
fraeno
or
you
can
come
to
the
working
group
and
share
it
with
us.
A
One
of
the
things
that
hopefully
we'll
end
up
doing
is
coming
up
with
a
nice
way
to
collect
some
of
that,
because,
even
though
there's
a
lot
of
opinions
here,
we
need
to
make
sure
that
we
listen
and
we
solve
real
problems,
because
if
we
don't
do
that,
then
we're
gonna
build
another
thing:
that's
just
you
know
another
standard
along
in
the
way
of
standards,
and
it
doesn't
necessarily
make
things
better
than
it
was
before
it
just
makes
them
different.
You.
D
F
So
so,
scarus
as
a
user
and
builder
of
a
bunch
of
tools,
on
top
of
like
the
QA
ecosystem,
like
how
I
took
what
this
is,
and
this
wise
I'm
interested,
is
that
it's
both
lowering
the
barrier
to
entry
for
people
building
higher-level
tools.
At
the
same
time
as
improving
the
interoperability
of
those
tools
and
I.
F
Think
if
we
do
this
right,
all
of
the
people
who've
built
any
tools
in
that
list
can
delete
20%
of
their
code.
That
would
be
a
sort
of
success
and
it
and
at
the
same
time,
be
more
interoperable
and
I.
Think
then
that
prevents
locking
into
the
tools
that
people
are
building
on
top
and
that
allows
people
to
move
with
them.
Does
that
make
sense
that
people
who've
sort
of
been
formulating
the
work
that
was
my
sort
of
take
on.