►
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
So
the
purpose
of
this
session
is
just
to
kind
of
provide
some
basic
context
and
history
on
why
the
working
group
exists
and
what
its
goals
are,
and
you
know,
sort
of
help
introduce
people
who
are
interested
to
what
we're
doing
in
the
code
and
answer
any
questions
you
have
so
we're
gonna
kind
of
introduce
ourselves
and
then
provide
a
little
bit
of
overview
and
then
we'll
we
can
kind
of
pause
for
questions
or
deep
dive
into
more
technical
areas
depending
on
on
interest,
so
welcome
everyone.
A
B
Yeah
thanks
mike
and
then
my
name
is
lee
kapili.
I
work
with
weaveworks
and
been
helping
out
with
the
component
standard
efforts
since
about
march
also,
do
we
have
lucas
on
the
call.
A
A
If
you
know
him
in
open
source,
I
don't
think
he's
able
to
join
today
and
lucas
used
to
be
a
chair,
but
recently
stepped
down
due
to
time
constraints,
so
he
may
join
the
meeting
as
we
go,
but
he's
not
able
to
be
here
yet
so
you
know
we
don't
have
that
many
people
on
the
call,
so
why?
How
about
everyone
introduce
themselves
briefly.
B
I
see
david
david
hi,
david
hi.
D
My
name
is
dave
greenstein.
I
work
for
coda
global.
We
just
started
sort
of
engaging
the
open
source
community
and
and
working
to
participate
in
the
different
cigs
is.
This
is
a
big
part
of
the
technology
offerings
that
we
work
with?
You
know
daily
and
have
for
the
last
couple
of
years.
So
thanks
for
having
us
and
we're
excited
to
join
and
help
contribute.
F
Yeah
good
afternoon,
everyone,
I'm
idris,
I'm
from
andela,
and
we
we've
been
using
kubernetes
for
a
couple
of
years
now
and
you
know
sort
of
thinking,
maybe
it's
time
for
us
to
also
contribute
to
the
product
we've
been
using
for
a
while.
F
So
I
decided
to
join
this
combining
session,
so
I
can
get
an
idea
of
how
it
all
comes
together,
and
thank
you
for
having
me
too.
B
Thanks
so
much
for
joining
good
good,
we
always
appreciate
when
people
you
know
had
real
experience
with
operating
the
software
and
then
want
to
come,
contribute,
there's
so
much
help,
that's
needed
from
people
who
are
actual
end
users,
and
so
it's
a
very
valuable
area
of
experience.
Thanks
so
jorge
already
introduced
himself
thanks,
matt
you're
on
the
call.
G
Hey
yeah,
hey
hi,
matt,
how's
it
going
so
yeah.
I
I
work
at
beatport.
My
name
is
matt.
I'm
a
fellow
I
used
to
be
a
colleague
of
leahy
actually
over
here
at
b
port,
and
we
do
a
lot
of
stuff
with
kubernetes
over
here.
So
I'm
just
I'm
trying
to
get
into
contributing
as
well.
G
Of
talking.
B
With
lee
about
it
lately
and
trying.
G
So
yeah,
I'm
hoping
to
kind
of
you,
know,
make
it
in
and
start
contributing
myself
yeah
looking
forward
to
it,
I'm
out
again.
H
I
Yeah,
my
apologies,
I
might
walk
right
now
and
it's
not
quite
convenient,
but
my
name
is
oga.
I've
been
following
the
kubernetes
space
for
a
while,
and
I
was
looking
to
get
involved
and
I
thought
this
would
probably
be
something
I
could
do
and
see
how
it
goes.
Thanks
for
having
me.
B
Yeah
thanks
for
making
the
time.
I
know
it's
not
easy.
We
all
got
work,
but
cool
alex,
also
you're
able
to
join
thanks
for
making
time
for
this.
B
J
Yeah
hi
yeah,
I'm
alex.
I
am
working
for
an
isp
in
germany
and
we're
trying
to
integrate
kubernetes
with
our
openstack
cloud.
So
I'm
working
on
this
and
I've
been
trying
to
kind
of
like
get
started,
contributing
with
kubernetes
for
a
while,
mostly
doing
like
some
golden
issues
and
got
a
bit
bored
of
that.
J
So
I'm
looking
for,
like
a
you,
know,
bigger
kind
of
community
or,
like
you
know,
working
group
where
I
can
contribute
to
so
yeah
happy
to
have
you
to
get
to
know
you
guys,
and
hopefully
I
can
get
to
contribute
some
stuff.
B
Cool,
so
is
that
the
list
there's,
we
also
have
sebastian
and
denise.
B
K
K
Hello,
I
was
I'm
just
muted.
I'm
I've
been
interested
in
the
subject
for
a
while
and
not
sure
how
I
can
contribute,
but
I'm
hoping
to
join
this
call
and
find
out
more.
H
Hi,
a
undergraduate
student,
I
just
completed
my
college
from
india,
I'm
right
now,
working
as
a
shadow
for
docs
release
team
for
1.16
release,
so
I'm
very
new
to
this
kubernetes
community,
I'm
just
finding
ways
to
start
contributing
and
then
getting
started
with
the
community.
Thanks
for
having
me.
A
Thank
you,
cool,
absolutely
yeah.
You've
got
a
number
of
people
who
are
kind
of
interested,
maybe
in
learning
more
maybe
in
contributing
we've
got
some.
I
think
interesting
things
to
talk
about
today.
You
know
recognizing
that
most
of
the
people
here
are
kind
of
new
to
the
space.
If
anything
is
kind
of
going
over
your
head,
please
just
speak
up
and
let
us
know
we
can
answer
more
questions.
That's
what
this
sessions
for
is
helping
you
get
started
and
learn.
A
So
just
to
start,
we
have
a
couple
definitions
here
in
the
notes.
When
we
talk
about
components
and
kubernetes,
there
can
be
different
things
that
we're
talking
about
in
general.
A
component
is
just
like
a
unit
of
of
some
piece
of
the
system
so
like
it
could
be
an
ongoing
process
or
a
tool.
A
The
pieces
we
often
talk
about
when
we
talk
about
a
core
component
are
the
things
that
are
really
required
to
run
your
cluster
and
the
things
that
come
with
your
cluster,
so
think,
like
the
cubelet,
which
is
running
on
the
node
or
q
proxy,
which
is
running
on
the
node
or
the
api
server
that
houses
all
the
kubernetes
apis
or
the
controller
manager
that
contains
all
of
the
standard
controllers
that
come
with
the
kubernetes
cluster
and
right
now,
that's
kind
of
the
main
focus
of
the
working
group.
A
However,
there
are
a
number
of
other
components
that
sit
just
above
this
layer
or
just
outside
of
it.
So
there's
things
like
integrations
with
various
cloud
providers.
There's
the
cluster
api
project,
which
is
going
on
outside
of
kubernetes
core,
but
it's
very
close
to
kubernetes.
A
There's
tools
like
cube
adm,
that
a
lot
of
people
use
to
set
up
clusters,
and
so
the
way
that
these
relate
to
our
working
group
is.
They
may
end
up
consuming
some
of
the
code
that
we
produce.
So
what's
actually
the
purpose
of
working
group
component
standard.
A
A
Some
of
it
is
we're
going
to
come
up
with
a
standard
convention
that
every
component
is
going
to
follow
for
something
kind
of
work,
and
these
efforts
were
kind
of
all
over
the
place
and
writing
code
all
over
the
place,
and
so
the
goal
of
this
working
group
is
twofold:
one:
to
create
a
forum
for
people
to
talk
about
these
things
and
discuss
them,
because
most
of
that
was
just
happening
in
random,
chats
random
issues
on
github
and
didn't
really
have
a
centralized
meeting
or
place
to
discuss
these
things.
A
So
that's
part
one
of
what
the
working
group
is
for
and
then
part
two
is
just
to
kind
of
house
all
the
work
around
moving
all
this
code
that
has
been
spread
out
everywhere
into
a
common
place
and
that
commonplace
is
a
repo
called
component
dashbase
for
now,
as
things
evolve,
that's
possibly
subject
to
change,
but
for
now
that's
where
we're
trying
to
move
a
lot
of
this
stuff
too,
and
there's
links
to
that
repo
and
also
the
cap,
that
kind
of
kicked
off
this
working
group
and
that
repo
and
open
source-
and
we
can
dive
into
those
later
if
people
are
more
interested
and
then
just
to
give
a
brief
overview
of
kind
of
the
areas
of
standardization
that
are
ongoing
right
now.
A
One
big
area
and
that's
the
area
that
I'm
focused
on
is
management
of
configuration
and
flags
for
all
the
components.
One
of
the
big
efforts
I've
been
pushing
for
the
last
few
years
has
been
to
move
off,
of
using
command
line
flags
and
more
onto
using
version.
Config
files
with
versions
schema
that
are
similar
to
the
other
kubernetes
api
objects,
which
can
simplify
the
management
of
those
config
apis.
We
can
get
more
into
that
later.
If
people
are
interested,
another
area
is
standardizing.
A
The
logging
subsystem
across
most
kubernetes
components
to
make
sure
that
we
have
sort
of
consistent
log
messages
coming
out,
and
that
is
mostly
housed
around
kind
of
a
k-log
project,
which
is
a
4k
g-log.
A
I
think
dimms
and
vince
pry
have
been
working
on
that
a
bunch
and
then
finally,
there's
this
area
around
monitoring
and
debugging
endpoints,
which
are
these
endpoints
that
are
served
by
a
lot
of
components.
Some
components
serve
all
of
them.
Some
only
serve
some
of
them.
There's
things
like:
what's
the
version
of
this
component?
What's
the
end
point
for
health
checking?
Is
there
an
end
point?
A
I
can
get
the
current
config
off
of
performance
monitoring
various
metrics,
and
so
there
is
an
item
in
in
the
charter
of
the
working
group
to
look
at
that
at
some
point.
Nobody's
really
done
it
on
a
consistent
basis
in
our
meetings
so
far,
and
then
second
to
that
is,
if
somebody
wants
to
get
information
off
these
endpoints,
how
do
they
off
to
that?
How
do
they,
you
know,
can
components
set
up
the
delegated
auth
sub
system
with
the
kubernetes
api
in
order
to
you
know,
extend
to
support
that
workflow?
A
So
that's
just
some
of
the
areas
you
know
we
can
add
more
depending
on
what
people
are
interested
in
if,
if
it's
an
area
that
is
common
across
all
core
crew
and
these
components
in
an
area
that
tends
to
be
non-standard,
so
again,
the
purpose
of
the
working
group
is
providing
a
place
where
we
can
discuss
how
to
standardize
and
improve
these
common
pieces
of
infrastructure
across
the
core
components.
J
J
A
A
However,
some
components
you
might
want
to
configure
them
via
your
cluster
and
so,
for
example,
the
cubelet
and
q
proxy,
both
support
to
varying
degrees,
placing
that
config
file
in
a
config
map
that
it
can
consume
and
there's
some
ongoing
work
in
q
proxy
right
now
to
refactor
its
api
to
make
it
easier
to
and
more
sort
of
more
approachable
to
deal
with
that,
if
that
makes
sense,
but
the
short
answer
is
yes,
both
the
long
answer
is
is
even
though
we
support
both
there's
caveats
with
each.
B
Just
to
add
a
little
bit
more
color
to
that,
if
you
look
at
the
cuvette
am
project's
use
of
configs.
B
Often
kubertim
will
start
with
a
list
of
multiple
documents
that
are
in
a
file
that
you
passed
to.
The
tool
kubereum
is
used
to
install
a
cluster,
and
part
of
that
is
managing
the
configuration
of
the
components
and
kubernetes
will
basically
distribute
versioned
copies
of
the
config
into
the
group
system,
namespace
in
cluster
and
then
on,
join
of
following
nodes.
It
uses
it
as
a
distribution
mechanism
but
then
copies
down
the
config
from
the
config
maps
onto
the
node
for
things
like
the
kubelet.
B
B
A
B
A
And
the
other
thing
to
keep
in
mind
is
that
the
config
file
apis,
two
most
components
are
not
ga
yet
so
the
the
qubits
is
beta,
which
means
it's
relatively
stable,
but
two
proxies
is
alpha
and
most
other
components
are
alpha.
B
We
can
get
more
into
this
later,
but
jorge
mentioned
in
the
zoom
group
chat
about
lucas's
sample,
config
repo,
which
is
a
technical
example
of
how
config
can
be
made
to
read
a
kubernetes
api
from
disk,
so
cool
yeah.
I
this
is
licensed
under
lucas's
personal
license,
but
I
am
about
to
release
code
to
the
add-on
operators
repository
today
that
re-licenses
this
with
permission
to
apl
too
oh
sweet.
B
So
it's
it's
just
going
to
be
for
some
that
we're
doing
in
that
sig
or
that
project,
but
yeah
thanks
for
being
night
out.
It's
super
helpful.
A
Yeah,
that's
great
yeah,
I
mean
so.
If
people
are
interested,
I
can
keep
talking
about
component
config
just
to
fill
time,
and
then
anyone
can
feel
free
to
interrupt
me
and
ask
other
questions
that
are
totally
unrelated.
If
you
come
up
with
something.
B
Yeah-
and
this
is
definitely
the
like
the
lowest
order-
complexity
thing
that
we
have
right
now
in
that
working
in
component
config
and
making
it
consumable
by
people
who
want
to
write
components
and
just
having
documentation
about
how
to
do
this
stuff.
B
I
also
mentioned,
like
some
code
generation
mike,
if
you
want
to
open
up
and
like
kind
of
give
the
overview,
I
could
then
show
some
code
and
demonstrate
a
problem.
A
Sure,
and
and
to
piggyback
on
what
lee
said.
There's
a
lot
of
work
to
be
done
in
this
area
around
just
migrating
flags
that
are
exposed
by
components
into
the
configure
guys.
That
is
just
sort
of
an
ongoing
process
and
there's
just
lots
and
lots
of
parameters
that
need
to
be
moved
and
that's
a
great
way
for
somebody
to
get
started,
because
it's
relatively
simple
to
take
a
flag
and
then
add
a
field
for
it
in
the
config
structure
and
then
there's
a
few
other
things
you
have
to
do
to
set
it
up.
A
But
that's
just
ongoing
work
that
I
haven't
had
a
lot
of
time
to
do
and
lee
hasn't
had
a
lot
of
time
to
do
it
and
you
know
so,
if
you're
just
trying
to
get
started,
that's
a
really
big
help
because
it
directly
moves
this
work
forward.
A
And
so
if
people
are
interested
in
that,
you
know
feel
free
to
ping
me
on
slack
or
ping.
The
working
group
chat
on
slack
and
we
can
help
you
get
started.
So
I'm
gonna
jump
in.
Oh
did
someone
have
a
question.
J
A
Yeah
so
where
every
component
has
its
typically
its
own
set
of
parameters
within
that
there
are
some
common
areas,
and
that
is
part
of
what
we'd
like
to
standardize
to
have
at
least
some
sort
of
shared
substructures
within
the
configuration
apis.
However,
many
parameters
are
not
in
common
between
components,
and
so
the
thing
we're
trying
to
standardize
is
really
the
style
and
the
api
conventions
across
like
components
to
make
those
apis
feel
consistent.
Even
if
you're
setting
different
parameters.
B
If,
if
you've
never
kind
of
gotten
into
the
weeds
of
api
machinery,
lucas's
kubecon
talk
that
jorge
linked
in
the
chat,
and
I
believe
he
added
it
to
the
document
somewhere
as
well.
Yeah
under
resources.
B
Lucas
explains,
you
know
how
a
kubernetes
api
is
assembled
from
the
code
and
from
code
generation
at
a
high
level
and
then
kind
of
talks
about
that
lack
of
shared
structures
and
some
suggested
areas
where
we
would
like
to
work
to
unify
the
way
that
components
are
configured
to
be
exactly
what
you
were
asking
about
alex
so
yeah,
just
we're
not
there
yet,
but
we
would
like
to
be
there
and
that's
totally
in
scope.
A
Okay
yeah,
so
I'm
gonna
jump
into
the
second
link
here,
which
is
a
dock.
I
wrote
a
couple
of
years
ago
about
so
this
was
after
we
prototyped
a
lot
of
things
in
the
keyboard
and
gotten
the
cubelets
component
config
api
to
v1
beta1
state.
I
wrote
this
doc
to
kind
of
capture
the
background
and
ideas
around
that
philosophy,
and
so
we
can
go
through
this
a
little
bit.
A
The
main
motivations
behind
component
config
were
that
at
the
beginning
of
kubernetes,
every
component
was
just
configured
with
this
gigantic
set
of
command
line
flags,
and
there
are
various
problems
with
that.
One
of
the
biggest
problems
is
that
these
apis
are
not
or
talking
about
command
line
flags
as
an
api.
These
apis
are
not
particularly
easy
to
version
and
we
like
versioned
apis
and
we're
very
used
to
the
idea
of
the
api
version
in
kubernetes
for
the
objects
that
live
in
the
kubernetes
api
server.
A
So
this
was
sort
of
a
perennial
pain
for
us
across
upgrades
where
maybe
deprecation
policies
weren't
respected,
because
people
didn't
understand
that
there
you
know
was
some
policy
around
how
to
manage
flags.
Maybe
api
reviews
weren't
happening
around
the
addition
of
flags.
A
Maybe
there's
some
defaults
changing
when
there
shouldn't
be,
and
it
was
just
difficult
to
manage
flags,
but
we
knew
how
to
manage
apis
for
kubernetes,
and
so
the
the
general
idea
was
well.
Why
don't
we
try
and
do
something
more
similar
to
the
kubernetes
apis,
and
you
know
that,
coupled
with
the
fact
that
config
files
are
becoming
a
more
popular
way
to
configure
utilities
in
unix
systems
these
days
anyway,
as
opposed
to
flags,
there
might
be
something
there,
and
so
we
spent
a
lot
of
time.
A
Thinking
about
this
and
building
out
a
philosophy
on
top
of
it,
and
that
philosophy
is,
is
in
many
ways
summarized
as
use
a
config
file
with
a
version
schema
because
it's
easier
to
manage
and
there's
many
other
reasons
in
this
stock
that
that's
the
case,
but
that's
the
general
idea
is
your
config.
Apis
should
be
versioned,
and
then
we
also
like
working
with
files.
A
B
A
B
A
So
there's
two
things
here:
one
which
is
sort
of
what
I
just
talked
about
is
standardize
the
conventions
and
approach
to
apis
for
configuration
for
all
core
cluster
components
and
then
the
second
thing
is
once
you've
done
that
you
can
build
on
top
of
it
with
some
of
these
dynamic
deployment
mechanisms
that
kubernetes
enables
so
one
we've
already
talked
about
is
using
a
config
map
to
configure
like
a
deployment
or
a
demon
set
like
cube
proxy.
A
You
could
just
stick
its
config
file
now,
there's
some
caveats,
but
you
could,
in
theory,
just
stick
its
config
file
in
a
config
map,
expose
it
as
a
config
map
volume
source
to
cube
proxy
and
then
just
configure
the
path
to
that
source
on
the
command
line.
Of
course,
there's
some
caveats
around
how
to
properly
do
progressive
rollouts
and
how
to
refactor
and
redesign
cue
proxies
api
so
that
a
single
object
can
be
rolled
out
across
multiple
cube
proxies
rather
than
needing
another
object
for
every
single
cube
proxy
instance
in
the
cluster.
A
A
So
then,
within
that
kind
of
component
config
area,
we
have
a
few
different
ongoing
projects
that
most
of
these
kind
of
get
into
the
weeds
of
it,
but
the
main
one
that
is
great
for
new
contributors
to
help
with
is
this
last
bullet,
which
is
migrations
again.
If
you
want
to
help
with
that
ping
me,
and
then
we
have
a
number
of
other
things,
so
one
so
I'll
start
with
this
legacy
flag,
one
and
I'll
just
kind
of
go
through
the
list.
A
So
one
of
the
difficult
things
with
doing
an
incremental
migration
of
flags
to
the
config
apis
is
that,
due
to
our
existing
deprecation
policies,
you
need
to
maintain
backwards.
Compatibility
with
that
old
command
line
api
for
like
two
releases,
and
when
you
try
to
do
this
seamlessly,
there's
all
sorts
of
educations
that
show
up,
because
what
you're
effectively
doing
is
giving
command
line
flags
precedence
over
the
config
file
and
the
way
that
flags
worked
across
most
kubernetes
components
and
in
most
go
applications.
A
This
sort
of
require
you
to
re-parse
the
command
line
in
order
to
reapply
the
flags
over
a
config
file
once
you've
brought
it
in.
So
you
have
this
kind
of
goofy
chicken
egg
problem
where
you
have
to
read
the
command
line
to
know
where
the
config
file
is,
and
then
you
have
to
read
the
config
file
and
then,
in
order
to
enforce
that
precedence,
you
have
to
bring
the
you
know,
reapply
those
flag
values
onto
your
internal
state.
A
Once
we
built
that
out-
and
so
this
legacy
flag
library
is
designed
to
replace
p
flag,
it's
a
wrapper
around
p
flag.
That
does
some
additional
things,
namely
it
reads
all
the
values
off
the
command
line
into
a
scratch
space
so
that,
once
you've
read
the
command
line,
you
don't
ever
have
to
read
it
again
and
it's
very
convenient
to
apply
those
values
to
arbitrary
objects.
A
A
So
that's
one
sort
of
sort
of
in
the
weeds,
deep
area
of
work,
but
that's
kind
of
important
to
moving
that
work
forward
in
other
components
because
sort
of
everyone's
in
this
situation
of
needing
to
do
this
incremental
migration
and
everyone's
going
to
need
to
maintain
backwards,
compatibility
due
to
the
deprecation
policy
and
it's
without
something
like
this.
It's
very
complicated
to
do
that.
A
People
who
are
interested
in
prototyping
kind
of
the
future
of
component
config
and
other
components,
or
even
if
somebody
wants
to
give
the
keyboard
you
know
a
shot
which
is
probably
the
hardest
possible
one
to
do
it
in,
but
if
someone's
very
ambitious
I'd
be
happy
to
help
with
that.
So
that's
one
area.
The
next
item
on
the
list
is
all
the
work
going
on
around
improvements
to
the
encoders
and
decoders
so
lee.
If
you
want
to
talk
about
that,
because
I
think
you've
been
more
involved.
B
This
is
vendored
by
based
or
imported
by
basically
everything
in
all
of
our
repositories,
because
you
need
encoders
and
decoders
to
work
with
the
api
groups
in
your
schemes,
and
this
is
like
how
objects
basically
go
from
transport
back
into
a
memory
struct
in
golang
right
or
going
from
a
memory
struct
into
you
know
something
that
can
be
transmitted
over
grpc
to
etcd,
and
so
these
things
have
to
be
very
performant
and
they
have
a
few
shortcuts.
B
Currently,
so
one
thing:
that's
a
pain
that
we've
had
in
kubernetes,
which
has
been
kind
of
the
pioneer
for
config,
is
that
people
will
write
their
config,
but
they
won't
use
a
capital
letter
where
it
should
be
and
our
current
encoders
they
just
drop
unknown
fields
or
they
don't
care
if
they're
duplicate
fields
and
sorry
decoders,
and
that
can
be
a
problem.
So
the
strict
encoder
work
has
or
sorry
strict
decoder.
B
Work
has
been
plumbing
through
our
kind
of
stack
of
abstractions
to
be
able
to
at
the
very
top
of
the
abstraction
which
is
the
codec
factory,
to
say:
hey
runtime,
please
don't
let
me
do
things
like
duplicate
fields
and
please,
like
error
out
when
I
like,
have
the
wrong
capitalization.
That
kind
of
thing
so
that
once
that
plumbing
is
there,
then
we
can
have
our
component
config
abstractions
be
using
strict
decoders
right
and
there
are
some
other.
B
The
pretty
stuff
is
in
there,
because
it
was
previously
an
option,
but
we're
now
pulling
it
out
into
an
options.
Struct.
I
have
some
some
patches
that
are
up
there
once
that's
done,
then
we
can
move
on
to
actually
testing
the
apis
for
canonical
conformance
so
because
we
generate
all
of
our
apis
from
code.
B
There's
a
rather
medium
size
amount
of
code
that
you
need
to
write
in
order
to
declare
your
types
and
your
scheme
and
your
api
groups
and
your
preferred
version
and
with
a
component
config,
you
have
to
do
several
versions
of
your
api
and
writing.
All
of
that
code
is
currently
rather
manual
and
you
can
do
it
wrong.
B
What
I
mean
by
doing
it
wrong,
is
you
can
do
it
in
a
way
that
doesn't
follow
the
kubernetes
api
and
style
conventions,
and
so
the
follow-up
to
the
strict
decoders
is
to
write
a
test
suite.
That
makes
sure
that
everything
in
your
component
is
assembled
in
a
way
that
you
expect
with
room
for
exceptions
and
things
like
that,
but
so
there's
an
interesting
series
of
of
patches
that
we've
had
open
in
a
work
in
progress
state.
B
For
you
know
since,
like
march,
this
is
a
particularly
strange
area
of
kubernetes
to
be
contributing
in,
and
I
would
be
happy
to
walk
anybody
through
these
patches
because
getting
knowledge
about
the
runtime
library
I've
found
is
a
lot
of
just
reading
code
and
experimenting
there's.
B
A
B
B
Matt's
comment
here
is
that
the
abstractions
about
the
types
is
like
really
difficult
to
work
with
in
coop
ctl
and
that's,
I
can't
say
from
an
empirical
experience
about
coup
ctel,
but
I
I
can
tell
you
that
it's
really
difficult
to
work
with
types
in
in
kubernetes.
So
yes,
everything's.
A
F
Yeah,
I
have
a
question
too,
when
you're,
explaining
the
encoder
and
decoder
part,
I
didn't
really
catch
your
the
context
you
gave
with
how
it
works
with
multi-dog
support.
B
Yeah,
the
multi-doc
support
thing
is
an
abstraction
that
we
would
like
that's
kind
of
what
mike
was
saying
with
like
going
to
the
higher
order
like
easier
to
use
things
in
kuberiam.
We
have
multi-dock
implementation,
where
you
can
pass
a
single
kubernetes
config
file
with
many
different
api
types
right,
so
you
can
have
a
kubelet
configuration,
a
join
configuration
cluster
configuration
all
and
a
coupe
proxy
configuration
all
in
the
same
file
on
disk.
A
Cool,
so
then,
the
next
item
on
this
list,
so
we're
gonna,
start
really
getting
in
the
weeds
in
the
next
two.
But
there
there's
so,
even
though
we're
moving
to
apis
that
are
at
the
root.
A
These
version,
config
schemas,
there's
still
a
desire
from
a
lot
of
people
to
be
able
to
override
certain
parameters
on
the
command
line,
that's
mainly
from
a
ux
perspective,
because
in
kubernetes,
for
example,
in
a
pod
spec,
when
you
you
can
specify
a
command
for
a
container
very
easily.
But
it's
considerably
more
difficult
to
write
a
file.
A
You
either
have
to
use
a
config
map
and
use
configurable
volume
source
or
you
have
to
use
an
init
container
and
especially,
if
you're,
just
trying
to
override
a
single
parameter
or
a
few
parameters
that
would
be
set
in
that
file.
Then
you're
in
the
business
of
using
set
on
the
file
or
doing
some
other
substitution
or
some
other
editing
at
runtime,
and
it
can
quickly
get
very
complicated.
So
lubimir,
who
goes
by
neolit123
on
github,
wrote
up
a
proposal
for
different
ways
to
do
that.
A
Overriding
and
sort
of
the
leading
piece
is
to
use
json
patch
and
offer
an
option
to
do
that.
So
this
this
document
is
currently
in
review,
we're
having
a
lot
of
back
and
forth
on
it.
A
If
people
are
interested
in
kind
of
that
specific
piece
you
know
now
would
be
a
good
time
to
jump
into
the
comments,
but
again
that's
sort
of
a
more
advanced
area,
and
then
the
other
item
here
is
ross's
proposal
to
you
know,
or
rather
tracking
of
what
are
the
final
things
we
have
to
do
to
be
able
to
graduate
q
proxy's
component
config
api
to
beta,
and
so
he
has
a
cap
that
is
open
for
this,
and
one
of
the
major
areas
of
this
kept
is
solving
two
of
the
sort
of
unsolved
problems
in
the
component
config
space,
one
of
which
is
how
to
deal
with
platform
specific
configuration
so
conventions
around
writing
apis,
so
that,
if
you
have
some
parameters
that
only
make
sense
on
linux
and
other
parameters
that
only
make
sense
on
windows,
for
example,
what's
kind
of
our
convention
for
representing
that
in
a
structure,
and
then
the
other
problem
is
how
to
deal
with
instance,
specific
configurations.
A
So
there's
certain
things
like
ip
addresses
that
are
only
ever
specific
to
a
single
instance
of
a
component
running
somewhere
in
the
cluster.
And
so
you
can't
share
that
configuration
between
multiple
instances,
and
this
is
a
challenge
if
you
were
to
just
take
like
a
basic
config
file
that
say,
have
an
ip
address
field
in
it
and
try
to
share
that
state
across
many
components
in
the
cluster,
because
the
config
would
only
be
right
for
one
component.
A
A
Maybe
you
do
some
shell
on
the
command
line
when
you
start
it
up
some
substitution,
but
it's
much
harder
to
do
into
a
raw
file,
and
so
part
of
this
proposal
is
figuring
out.
Can
we
split
it
up
and
have
multiple
files?
And
what
do
we
do
around?
That
so
this
is
kind
of
the
place
to
dig
into
those
two
issues.
J
Sorry,
that's
right.
Go
ahead,
all
right!
What's
the
current
state
of
of
like
the
migrations,
is
there
some
overview
of
on
what
components
require?
What
amount
of
love
in
this
area
or.
A
We
probably
need
to
have
better
tracking
of
that.
We've
had
various
attempts
in
the
past.
Like
a
year
ago,
I
created
a
hundred
some
github
issues
for
tracking
the
keyboard
migrations.
So
if
you
search
for
like
cubic
flags
and
github
issues,
you'll
probably
find
the
auto
created
issues.
A
A
lot
of
them
have
been
closed
by
robots
at
this
point,
because
people
weren't
working
on
them
and
then
we
also
have
sort
of
an
overall
tracking
issue
for
the
working
group,
but
that's
also
somewhat
out
of
date.
So
the
the
short
answer
is
like
no
there's
not
really
a
good
way,
but
if
you're
interested
in
working
on
that,
I
can
help
you.
L
I
was
basically
about
to
start
asking
the
same
thing
like.
Is
there
a
list
of
issue
numbers
or
something
that
we
can
start
reading
up
on?
But
you
just
answered
that
great
minds
and
all
that.
Thank
you
guys.
A
Yep
and
if
you
are
familiar
with
the
the
kubernetes
code,
at
least
to
a
cursory
degree,
most
components
have
like
a
command
like
cmd
directory
and
then
somewhere
under
that
directory
there'll,
be
a
file
called
options.go
and
that's
usually
where
the
flags
are
registered
and
in
components
that
are
in
the
process
of
adopting
component
config.
Those
flags
will
be
configured
to
write
their
values
into
the
component
config
structure.
A
A
A
And
I
can
go
find
I
can
find
some
examples
of
moving
these
for
the
keyboard
and
add
it
to
this
dock
as
well.
J
Leave
one
more
question:
while
you
are
adding
this
comment,
so
the
component
config
structure,
would
that
be
in
the
same
file
and
options
ago,
or
would
it
be
look
at
it
somewhere
else?
Yeah.
J
A
Okay,
it's
typically
located
somewhere
else,
I'm
going
to
stop
sharing
release
that
you
can
share
it's
typically
located
somewhere
else.
It's
defined
according
to
the
same
sort
of
machinery
and
conventions
that
kubernetes
apis
are
defined,
as
so,
you
end
up
creating
an
api
group
for
your
component
and
then
you
sort
of
follow
the
existing
kubernetes
api
conventions,
which
include
a
basic
directory
hierarchy
under
that
directory
that
you're
creating
the
api
group
so
yeah.
If
you
there
are
many
examples
across
the
current
experience
lee.
If
you
want
to
show.
F
B
Cool
this
is
exactly
what
mike
was
talking
about
right.
So
here
we
have
a
command
line
tool
right,
called
installer
and
in
the
main
it
parses
flags
and
reads
a
config
from
some
other
places,
so
that
read
config
what's
happening
in
there.
B
Well,
it
is
importing
a
bunch
of
libraries
from
a
similar
location.
So
this
is
the
directory
that
I'm
in
right
now,
except
in
command
under
package
apis.
This
is
kind
of
like
a
canonical
path.
We
have
this
config
directory
right,
so
I
have
an
eight.
I
have
a
config
api
inside
of
my
packages
and
then
we're
doing
a
bunch
of
machinery
here
that
needs
to
be
standardized,
but
so
that's
the
command
line
tool
invoking
reading
and
config.
B
So
to
your
question,
alex,
I
think
you
were
asking
about
where
that
structure
is.
This
is
where
our
config
api
is
right
here,
this
folder
and
there's
a
scheme
here
right.
So
the
scheme
is
what
holds
all
of
the
type
mappings
for
the
basically
the
golang
definitions
of
what
the
json
and
yaml
equivalents
are
and
grpc.
If
you
are
doing
an
api
server
api,
but
so
a
scheme,
you
can
see
it's
importing
config
and
then
config
v1
alpha
one.
B
So
this
is
what's
referred
to
as
an
internal
type,
and
then
this
is
an
external
type.
The
internal
type
is
the
parent.
The
internal
type
is
what
the
component
wants
to
get
the
config
to
in
memory,
so
we
would
typically
read
an
external
type
from
disk
and
then
serialize
it
into
an
internal
type
or
sorry
deserialize.
It.
A
It
gets
deserialized
into
the
external
structure
and
then
converted
via
the
conversion
machinery
into
the
internal
type,
and
that
the
reason
that
happens
is
is
the
way
that
conversions
between
different
external
versions
work
today
is
that
the
there's
a
bunch
of
code
gen
that
generates
these
automated
conversions
that
first
go
from
an
external
type
into
the
internal
type
and
then
can
go
back
from
the
internal
type
into
another
external
type.
Another.
B
B
Yes,
so
you
can
see
here
right,
the
basic
api,
if
we
didn't
have
any
external
version
is
just
config,
and
then
you
have
types
and
register.go,
so
the
register.go
is
used
to
basically
add
to
the
scheme
which
is
in
scheme,
and
this
is
basically
the
meat
of
our
api
right
here
right.
This
is
very
simple.
I
just
have
an
add-on
installer
configuration
struct.
B
There
is
a
bunch
of
these
other
files
because
we
have
to
tell
kubernetes
about
like
what
the
domain
of
the
api
is
right
and
what
the
preferred
version
is,
and
that
kind
of
thing
and
how
to
add
it
to
the
type
registry
which
is
a
scheme,
and
we
need
to
do
that
same
thing,
then
for
the
internal
version
right.
So
these
zz
files
right
here
which
are
about.
A
Starting
coming
back
to
the
register.go
file.
I
A
Is
this
typically,
you
should
register
a
like
a
subdomain
at
config.io,
so,
like
the
api
group
here
component
will
be
like
food.config.io,
I'm
not.
I
don't
have
state
on
this,
so
I'm
not
gonna
like
critique
it,
but
just
fyi
to
everyone
who's.
Listening
when
you
do
this
for
a
another
kubernetes
component
so
like
the
cuboids
is
cubit.config.io.
B
Yeah,
this
would
be
probably
add-ons
right,
yeah
right
thanks
for
catching
yeah,
I
think
yeah,
and
then
I
would
have
to
so
here's
an
example
right
where
it's
like.
I
had
to
write
all
this
code,
and
this
is
where
it
would
be
great
to
have
a
test
suite
that
catches.
The
fact
that
the
group
name
like
in
the
in
the
different
versions
would
not
be
conformant
to
a
the
spec,
or
maybe
I
even
configured
them
in
the
wrong
group.
Right
like
I,
I
put
one
in
one
group
and
one
of
the
other
and.
B
Yes,
but
you
basically,
you
write
all
of
these
files
kind
of
by
hand,
and
you
have
to
put
them
in
the
proper
packages
and
you
need
to
annotate
them
with
these
coup
builder
and
or
sorry
code
generating
annotations
and
it's
just
very,
quite
difficult.
So
coup
builder
can
help
you
do
a
lot
of
this
stuff,
but
it
can't
do
it
for
a
component
config
style
api,
which
has
an
internal
type.
A
That
said,
most
most
of
the
components
that
are
migrating
to
component
thing
have
already
done
this
step,
so
you
really
have
to
do
this
yourself
if
you're
just
getting
started
on
an
existing
core
component.
B
Yeah
to
to
mike's
point
about
how
you
don't
have
to
do
this,
the
time
you
have
to
do
this
is
when
you
want
to
create
a
new
component,
so
I
mean
that
that's
a
that's!
A
higher
order
need
for
sure
than
having
the
test
suite
that
ensures
that
our
our
apis
are
correct
or
having
the
strict
decoding,
which
ensures
that
people
can
use
their
config
files
in
a
same
manner
without
crazy
errors
or
no
errors.
Yeah.
A
Lee
do
you
by
any
chance,
have
the
kubernetes
repo
open
in
your
editor.
I
can
do
that
one.
We
can
show
the
keyword
stuff
really
quick,
yeah.
A
And
then,
if
you
head
into
command
keyboard,
app.
A
This
is
where
the
keyboards
flags
are
registered.
There's
there's
two
objects
at
play
here.
One
is
cubic
flags
which
are
things
that
are
currently
just
flags,
I'm
not
config
and
the
other
one
is
cubic
configuration
which
comes
out
of
the
directory
that
defines
that
component
config
type,
which
is
similar
to
what
we
just
showed.
You.
B
A
Oh
yeah,
it
does
that
preview
thing,
yeah
double
click,
the
tab
there
we
go,
then,
if
you
scroll
down
to
keep
going
validation,
I
think
it's
like
way
at
the
bottom.
There
we
go
so
here,
you'll
start
to
see.
There's
there
are
two
functions
in
here:
one
adds
the
config
flags,
one
adds
the
flags
that
are
just
flags
and
it's
just
a
long
list
of
flag
registrations.
A
A
Some
of
the
parameters
can't
be
moved
yet
because
they're
either
instance
specific
or
platform
specific
config,
and
we
haven't
figured
out
how
to
handle
that
yet
and
that's
kind
of
what
ross
is
working
on
in
key
proxy
right
now,
but
a
lot
of
them
can
be
moved
and
just
haven't.
A
So
you
know
take
a
look
at
the
parameter
if
it
seems
like
something
that
should
be
reasonably
shareable
across
multiple
instances
or
multiple
nodes,
then
you
know
it
probably
makes
sense
to
you,
but.
B
B
B
A
B
A
Are
the
flags
and
so
yeah
this
this
function
is
yeah,
I'm
showing
everything
that
hasn't
been
moved.
B
A
E
A
And
on
one
hand,
that
might
slow
things
down
a
little
bit
if
you're
just
trying
to
move
it,
but
on
the
other,
especially
if
you're
new
you'll
probably
learn
a
lot
about
kubernetes.
By
participating
in
that
discussion
about
whether
or
not
it
should
be
dedicated,
because
you'll
get
a
lot
of
the
context
and
history
of
why
it
existed
in
the
first
place.
So
that
can
actually
be
a
good
way
to
get
some
experience.
B
H
M
B
I
mean
I'm,
some
people
may
be
able
to
or
may
have
to
drop,
but
I
I
don't
have
a
hard
stop.
I.
A
Have
to
get
going
and
I'm
recording
so
we're
probably
gonna
cut
it
now,
but
we
can
schedule
another
session,
maybe
in
a
few
weeks
for
everyone
to
kind
of
follow
up
on
what
we
talked
about
here
and
maybe
even
bring
in
some
other
people.
B
Yeah,
please
join
our
slack
channel
and
or
the
mailing
list
and
post
any
questions
I'll,
be
monitoring
both
of
those
very
closely
so
that
we
can
help
you
get
connected
with
people
who
can
you
know,
get
you
to
your
goals
and,
ultimately,
let's
all
make
you
know,
kubernetes
a
little
bit
of
a
better
place
by
standardizing
this
stuff.
K
Will
you
send
out
the
link
to
the
recording
to
the
today's
participants.
A
Yeah
so
it'll
we're
going
to
add
it
to
the
youtube
playlist
for
working
group
component
standard.
So
you
should
just
be
able
to
find
it.
I
A
B
And
then
I
hit
this
right
to
assign
it.
A
And
then
just
plus
mtosnetgoogle.com.
E
Yeah,
do
the
google
one?
Oh
sorry,.
A
Cool
sweet
thanks
so
much
everyone.
This
is
a
pretty
great
session,
seems
like
we've
got
some
good
interest
and
we're
excited
about
that
so
again
feel
free
to
reach
out
to
any
of
us
for
help
getting
started
and
we're
happy
to
have
you.
Thank
you.
Thanks.