►
From YouTube: WG Component Standard 20191001
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
Okay,
hi
welcome
everyone.
We're
excited
to
have
so
many
new
contributors
joining
us
today.
This
is
the
tuesday
october
1st
working
group
component
standard
meeting
happy
fall
for
those
of
you
who
are
in
an
autumn
climate
right
now.
I
know
I'm
excited
about
it.
I
just
moved
to
seattle:
haven't
had
seasons
in
a
few
years,
so
I'm
very
happy
about
that.
A
A
A
One
is
the
sign
up
sheet
for
mentorship
and
then
linked
out
of
those
is
also
some
guidelines
on
migrating
flags
to
config,
which
hopefully
we'll
get
time
to
talk
about,
and
that
email
went
out
to
the
working
group
mailing
list
and
also
kubernetes
dev.
So
everyone
should
have
access
to
those
documents.
A
So,
first
off
at
a
very
high
level
as
chairs.
What
we
do
is
super
simple.
We
kind
of
define
the
goals
and
values
for
the
working
group
and
like
what
we
work
on
and
then
we
also
moderate
discussions
through
this
meeting
on
the
mailing
lists
on
github
and
try
to
ratify
decisions
in
the
working
group
and
that's
kind
of
it.
A
Most
of
the
technical
work
is
actually
done
by
the
contributors
in
the
working
group
who,
with
some
high
level
technical
guidance
from
ourselves
as
chairs-
and
you
know
sometimes
we
jump
in
with
code,
but
our
primary
job
is
to
facilitate
progress
on
the
working
groups.
Projects
unblock
people,
help
them
move
their
ideas
forward
so
as
mentors
it
kind
of
continues
that
with,
but
with
a
little
bit
of
a
higher,
more
personal
commitment,
because
we're
bringing
in
new
contributors
trying
to
help
them
ramp
up
and
grow
in
the
community.
A
So
the
number
one
goal
of
the
mentorship
program
is
to
help
contributors
grow
in
the
community
and
basically
that
just
means
we'll
help.
You
find
important
work
and
help
you
advance
on
the
community
ladder,
so
you
know
gaining
more
influence
becoming
a
reviewer,
maybe
eventually
becoming
an
approver
or
even
a
product
owner
over
time.
A
A
Okay
and
then,
finally,
we
can
provide
technical
guidance
to
contributors,
so
that
means
two
things.
First
of
all,
we
can
help
you
shape
your
ideas
and
refine
your
designs.
That
can
happen
through
formal
processes
like
the
kep
process,
but
it
can
also
happen
through
slack
chat,
informal
design,
doc
reviews
kind
of
whatever
works
best
for
you
to
help.
You
think
through
your
ideas
and
designs,
and
then
we'll
also
help
you
by
providing
code
review,
help
you
find
key
reviewers
as
well,
where
we
don't
have
development,
technical
expertise
so
for.
B
A
Of
people
coming
into
the
community
fresh,
it
can
seem
like
this
giant
black
box.
You
know
how
do
I
even
find
the
right
person
to
talk
to?
How
do
I
navigate
it
and
that's
what
we're
here
to
help
with,
I
think,
very
importantly,
you
know
our
role
as
mentors
is
to
support
you
in
doing
the
work
that
you
want
to
commit
to.
So
you
know
we're
not
necessarily
going
to
tell
you
exactly
what
to
do
we're,
not
necessarily
you
know
going
to
just
give
you
a
list
of
tasks.
A
A
lot
of
this
is
about.
You
know
you
taking
sort
of
a
higher
level
scope
of
like
this.
Broad
thing
needs
to
be
done
and
then
figuring
out
how
to
do
it
with
our
support,
because
that's
what
helps
you
grow,
so
that's
kind
of
how
we
think
about
the
mentorship
program,
and
then
I
want
to
talk
about
our
mentorship
signups
sheet.
So
we're
really
excited
with
how
many
people
responded
to
our
request
for
help.
A
This
is
really
cool,
but
it
is
a
lot
of
people
and-
and
we
want
to
manage
that
appropriately
so
in
order
to
make
sure
that
we're
not
stretching
ourselves
too
thin
to
make
sure
that
we're
not
like
over
allocating
too
many
people
to
the
same
sub
project.
A
We've
started
this
mentorship
sign
up
sheet
that
I'll
go
over
to
in
a
second,
and
this
is
where
you
can
go
to
sign
up.
If
you
want
to
be
mentored
for
a
specific
task
when
an
existing
sub
project,
maybe
you
have
a
new
idea
for
the
working
group,
something
that
could
be
standardized,
but
it's
and
it's
in
scope
for
the
working
group,
but
it's
not
an
active
sub
project.
So
basically
it's
not
listed
in
the
mentorship
sign
up
sheet
already,
but
you
want
to
work
on
it.
A
There's
a
section
you
can
put
your
name
down
for
that
and
finally,
if
you
want
to
be
a
mentor
and
you
have
significant
experience
in
kubernetes
and
maybe
you've
had
an
idea
for
a
sub-project
that
could
be
a
working
group
that
you
wanted
to
get
done
for
a
while.
But
you
don't
have
time
to
do
it
yourself,
but
you
could
help
someone
else.
Do
it.
You
can
sign
up
to
be
a
matcher.
So
let's
go
over
to
that
mentorship
sign
up
sheet
in
a
minute.
Does
anyone
have
any
questions
on
this.
A
A
There
are
a
few
active
sub
projects.
One
of
the
major
ones
is
like
the
component
config
flag
to
config
migrations,
so
we
have
different
numbers
of
slots
available
depending
on
the
component
and
how
significant
the
work
is
for
that
subproject
there's
also
legacy
flag,
prototyping
the
only
two
components
we're
going
to
protect
for
our
cubit
and
q
proxy
right
now,
because
it's
just
a
prototype,
there's
no
guarantee
that
it
will
be
actually
be
adopted
by
the
project.
A
A
We
have
a
few
open
areas
in
components
of
big
ergonomics,
so
one
is
somebody
needs
to
write
a
proposal
to
solve
what
we
call
the
instance
specific
config
problem
and
that's
basically
like
there
are
some
config
fields
that
need
to
be
set
to
a
unique
value
for
like
every
possible
instance
of
the
thing
that
would
consume
that
config,
and
so
because
of
that
they
can't
be
in
a
shared
object,
and
we
need
a
way
to
handle
that.
A
So
there's
more
detail
on
that
linked
issue,
then
there's
some
work
to
enable
the
new
strip
decoders
across
components.
A
So
that's
something
that
lee
stealthy
box
and
also
alex
handles
aubutech
have
been
working
on
and
there's
another
open
slot
for
another
mentee
there
and
then
finally,
there's
some
work
that
was
scoped
to
increase
test
coverage
for
the
component
pattern,
but
was
never
finished,
and
so
that's
also
a
great
area
for
someone
to
step
in
the
next
section
again
is:
if
you
have
a
new
project,
you'd
like
to
work
on
that
would
be
in
scope
for
the
working
group.
A
But
not
an
active
project
doesn't
necessarily
have
to
be
a
new
idea
that
you've
come
up
with.
If
you
go
and
look
at
the
cap,
that's
linked
from
the
working
group,
readme
page,
you
can
find
many
things
that
you
have
not
yet
worked
on.
So
great
examples
of
that
would
be
some
of
the
common
observability
endpoints
that
should
be
available
across
components
like
slash,
metrics,
slash,
config,
z,
slash
health
c,
making
it
easier
for
people
to
expose
those,
and
some
people
have
reached
out
to
us
wanting
to
work
on
various
pieces
like
that.
A
So
if
that's
your
speed,
this
is
the
place
for
you
to
sign
up
for
that
kind
of
thing
and
then
finally,
at
the
bottom,
if
you'd
like
to
be
a
mentor-
and
you
have
you
think
you
have
the
experience
to
do
that-
please
sign
up
here,
write
a
short
bio
about
yourself
and
then
we'll
reach
out
and
discuss
the
of
mentorship
expectations
and
position
with
you
and
decide.
If
it's
a
good
thing,
does
anyone
have
any
questions
on
the
sign
up
sheet.
B
Hey
hi,
am
I
audible?
Well
hi.
This
is
lala
here.
So
you
mentioned,
there
are
certain
slots
per
project,
so
is
it
mentioned
in
the
slot?
Because
then,
if
you
have
one
or
two
slot,
then
four
people
sign
up
how
that
is
going
to
dissolve.
A
Yeah,
so
each
each
cell
is
just
for
one
person
so
you'll
see
here
like
it
says,
contributor,
one
and
two
and
then,
where
they're
both
open,
we
have
two
slots
where
one's
like
blocked
out
there's
only
one
slot,
for
example,.
A
So
please
sign
up.
Are
there
any
more
questions.
A
Okay,
so
once
folks
have
signed
up,
you
know
feel
free
to
reach
out
to
us
directly
and
say:
hey
I
signed
up
for
this
thing.
I
want
to
get
started
and
we'll
also
make
an
effort
to
reach
out
to
everyone
who
has
signed
up
by
the
end
and
help
you
kind
of
find
it
a
first
thing
to
do.
A
With
the
flag
to
config
migrations,
most
likely,
the
first
task,
if
there's
two
of
you
signed
up
for
a
component,
meet
each
other,
either
on
slack
or
email
or
whatever,
and
then
the
first
thing
to
do
will
actually
be
to
audit
that
component
and
figure
out
what
needs
to
migrate
and
kind
of
get
a
list
of
things
to
do
together,
and
you
can
help
with
that
and
then
once
you've
done,
that
you
can
move
on.
A
I'm
gonna
switch
over
to
kind
of
tutorial
mode
here
to
go
through
the
how
to
migrate
flags
guide,
don't
be
intimidated
by
this
guide.
It
looks
like
there's
a
lot
of
steps
with
a
lot
of
edge
cases.
There
are
some
edge
cases
at
a
high
level.
What
you're
trying
to
do
is
simple.
A
The
complexity
just
comes
from
the
overall
complexity
of
the
components,
but
once
you
kind
of
understand
at
a
high
level,
everything
else
sort
of
falls
out
of
that.
So
I
don't
want
people
to
be
intimidated
by
the
length
of
greasy
instructions,
I'm
actually
going
to
skip
the
general
instructions
and
go
straight
to
the
keyboard
floor
planners
and
just
kind
of
do
like
a
code
tour,
so
people
can
get
a
sense
for
how
it
works
so
at
a
high
level
again.
A
What
you're
trying
to
do
is
there
are
a
bunch
of
flags
exposed
on
a
component,
and
we
have
invented
these
new
configuration
structures
that
can
be
represented
in
the
yaml
file
for
configuring.
The
component.
We
want
to
use
yaml
files
instead
of
flags
for
various
reasons.
There's
a
document
linked
at
the
top
of
this
document
called
version
component
configuration
files.
That
explains
some
of
those
reasons.
A
So
what
you
basically
do
is
you
find
where
the
flags
are
registered
and
you
find
where
the
config
types
are
and
then
you
make
sure
the
correct
value
is
replicated
in
the
config
type
and
then
you
kind
of
update
everything
else
that
falls
out
of
moving
that
field's
location
from
flags
over
to
the
conflict,
and
so
that
can
be
making
sure
like
the
new
defaults
are
set
correctly,
maybe
for
backwards
compatibility
or
maybe
security
improvements,
making
sure
that
validation
code
is
correct.
A
Now
that
you've
moved
it
updating
the
flag
registrations
so
that
the
values
from
flags
make
it
into
the
config
for
backwards
compatibility
reasons,
making
sure
you've
generated
some
of
the
generated
code,
updating
usages
in
the
component
kind
of
all
the
things
that
fall
out,
but
the
basic
operation
is
just
I'm
moving
this
flag
to
config,
so
I'm
gonna
go
into
cuboid
and
show
kind
of
where
some
of
that
stuff
happens.
A
C
A
Let's
see
so
this
is
the
tour
of
the
cubit.
Not
all
components
are
structured
exactly
the
same
way.
A
You'll
see,
there's
also
a
key
proxy
section
in
that
guide,
where
it
has
a
little
bit
of
a
different
structure,
but
the
high
level
ideas
are
still
the
same,
so
in
cublet
all
of
the
flags
that
have
not
been
migrated
to
config
just
about
there
are
a
few
exceptions,
but
just
about
all
of
them
are
represented
in
this
public
flags
struct,
which
is
in
the
options
package
under
command.
A
A
A
And
so
when
you
move
a
field
from
a
flag
into
a
config,
you
have
to
make
sure
it's
represented
in
both
places.
The
way
it
works
is
the
config
file
which,
as
the
external
type
is
read
in
then
it's
converted
to
the
internal
type
and
that's
what's
validated
and
used
so
first,
we
can
look
at
the
external
type
which
is
in
the
staging
subdirectory
because
we
publish
it
out
for
consumption.
So
if
people
want
to
write
tools
to
work
with
our
configs,
they
don't
have
to
clone
the
whole
kubernetes
project.
A
A
The
external
types
are
here:
staging
source,
case.io
cubic
configuration
data,
one
types.go.
A
A
You'll
notice
that
the
format
of
this
struct
is
basically
the
same
as
the
external
one,
and
that's
because
the
it
has
to
be
able
to
represent
everything
that
every
external
type
can
so
they'll,
basically
look
the
same,
and
you
just
have
to
make
sure
that
the
same
fields
are
represented
in
each
a
few
notes
about
the
external
type
that
are
important
in
the
keyword
we
kind
of
have
a
convention
for
documenting
things
about
each
config
field,
so
there'll
be
a
brief
description
of
what
the
field
does
there's
often
because
the
keyboard
also
has
this
dynamic
feature,
some
guidance
for
how
to
use
dynamic,
config
with
field
that
can
get
tricky,
and
we
can
help
you
with
that
part.
A
Finally,
like
some
information
about
the
default
value-
and
this
plus
optional
is
important
that
has
to
do
with
some
of
the
parsing
and
we
pretty
much
have
it
on
every
field
also
helps
with
graphics
compatibility
and
then,
finally,
these
struct
tags
are
important
to
get
right.
They
contain
the
name
of
the
field
in
json.
A
The
reason
we
do
this
is
because
you
go.
You
have
to
have
a
capital
first
letter
so
that
the
field
is
public
and
go,
but
in
our
yaml
and
json
documents
the
convention
is
always
going
to
start
with
a
lowercase
first
letter.
So
this
is
how
kubernetes
deals
with
that
problem
and
then
finally
emit
empty,
which
means
that
if
a
configuration
is
serialized
out,
fields
that
have
the
default
or
empty
value.
A
So
then,
once
you've
done
that
the
next
thing
that
you
would
want
to
do
is
make
sure
the
defaults
are
set
correctly.
So
the
defaults
live
next
to
the
external
type.
A
A
A
So
you'll
see
there's
just
a
function
in
here
set
defaults,
keyboard
configuration
q
proxy
is
very
similar.
It
has
to
set
defaults
to
proxy
configuration,
and
this
just
reads
through
an
incoming
structure-
checks
for
nil
or
default
values
on
it,
and
then
our
miller,
zero
values
and
then,
if
those
are
not
the
correct
defaults,
apply
the
support
people.
A
Okay,
so
once
you've,
you
know
made
sure
that
the
correct
default
is
represented
and
your
defaulting
code.
Then
you
move
on
to
possibly
adding
validation
or
moving
validation.
That
was
done
on
flags
into
the
validation
function,
and
so
validation
is
run
on
the
internal
structure.
So
once
a
structure
has
been
read
in
and
defaulted,
it's
then
converted
to
the
internal.
A
One
of
the
nice
things
about
moving
from
a
flag
to
config
api
is
that
somebody
actually
has
to
do
this
operation
of
removing
their
flag
from
their
command
line.
They've
set
and
then
writing
the
config
file,
and
what
that
means
is.
We
can
actually
add
validation
when
we
migrate
a
field,
we're
just
sticking
things
side
without
breaking
users
and
process.
A
You
can
do
different
defaults
and
you
can
do
different
validation.
You
have
to
be
careful
with
it
because
things,
especially
in
the
cubelet,
so
in
cubeproxy
it's
a
little
different.
They
have
stronger
rules
around
not
mixing
flags
and
config,
but
in
cubit,
because
the
two
get
mixed,
you
sometimes
have
to
be
more
careful,
that's
just
different
design
decisions
that
haven't
necessarily
been
reconciled
in
the
overall
discussion.
Yet.
C
And
the
legacy
flag
supports
both
patterns
and
we
don't
currently
assert
an
opinion
as
a
working
group
as
to
what
components
should
do
for
my
overrides
at
the
moment.
A
Some
arguments
that
have
spun
up
again
recently
around
that,
and
so
we
may
we
may
decide
ultimately
that
they
shouldn't
be
merged.
That's
yeah,
that's
an
important
discussion
for
us
to
standardize
on.
Ultimately,
but
it
doesn't
it
does.
A
It
should
not
block
migrations
of
flags
into
config,
because
it's
possible
to
do
it
either
way,
and
so
what
we'd
recommend
is
that
people
just
stick
with
the
whatever
the
existing
convention
is
in
the
component
that
they're
working
on
and
then
once
we've
got
all
the
flags
into
config
we're
using
the
config
api,
that's
sort
of
a
simpler
place
to
be
to
figure
out
the
other
discussions.
A
So
then,
finally,
what
you
would
do
once
you've
kind
of
made
sure
everything
looks
right,
is
go
move
back
in
the
options
file,
the
flag
registration
to
target
the
config.
So
let
me
zoom
out
just
a
little
bit,
so
there
are
two
flag
registration
functions
for
cubelet,
one
registers
flags
for
the
cubic
flag,
struct,
which
again
are
things
that
haven't
been
migrated.
A
So
our
goal
is
to
duplicate
all
flags
in
favor
of
a
config.
For
the
most
part,
there
will
still
be
a
few
flags
like
the
one
that
tells
you
where
the
conflict
file
is
that
we
never
move
and
never
defecate.
But
overall
the
goal
is
to
get
to
a
api
for
each
component.
That
is
actually
versioned
the
same
way
standard
kubernetes
apis
are,
and
that
makes
it
much
easier
to
avoid
breaking
users
by
changing.
A
There's
finally,
there's
a
step
where
we
run
code
generation,
so
you'll
see
in
the
config
directories.
There's,
for
example,
the
zz
underscore
generated
deep
copy
files.
These
are
built
by
that
make
generating
files
step,
and
they
just
generate
a
bunch
of
convenience
methods
for
working
with
configs
like
deep
copies,
for
example,
you'll.
A
And
finally,
once
you've
updated
it,
you
know
you
have
to
go
through
and
update
all
the
places
it's
used
in
kubernetes,
the
most
obvious
one
is
in
the
component
itself,
but
there
are
actually
a
few
other
things
in
the
kubernetes
core
repo
that
depend
on
these
config
types.
One
of
them
is
qadm,
so
often
it
needs
to
be
updated
when
a
flag
is
migrated
and
another
one
that's
easy
to
overlook,
but
will
cause
pre-submit
tests
to
fail.
If
you
don't
update,
it
is
cubemark
which
does
the
performance
tests
of
kubernetes.
A
Typically,
you
need
you'll
need
to
edit
the
qmark
color
cubelet.co
file,
which
is
where
they
construct
their
config
for
the
tests
and
then
finally,
there
are
some
tests
that
are
common
to
most
configs.
One
is
the
fuzzers
that
just
sets
a
bunch
of
random
values
and
performs
round-trip
tests
to
kind
of
make
sure
everything
is
working
appropriately
and
then
some
components
have
additional
helpers
and
tests
that
you
have
to
find
and
update.
A
Usually
those
will
show
up
as
test
failures
or
compilation
errors,
and
then
we
will
also
double
check
in
code
review
that
you
got
everything.
A
So
that's
just
a
brief
tour
of
kind
of
the
process
of
migrating
a
flag
to
config.
You
know
again,
it
looks
complicated,
looks
like
there's
a
lot
of
steps.
It's
definitely
not
trivial,
but
it's
not
as
hard
as
it
looks
so
don't
be
intimidated
by
this.
C
Also
round
tripping
is
just
the
idea
of
going
from
an
external
api
object
into
the
internal
type
and
then
back
to
some
external
type,
or
vice
versa.
A
A
So
that's
that's
what
I
planned
for
today,
just
to
kind
of
go
through
that
quick
tour
and
overview
of
the
mentorship
program.
So
I
guess
we
can
open
up
for
open
discussion.
We
have
another,
oh
actually
we're
at
nine
o'clock.
Unfortunately,
all
right,
so
that's
it
thanks
everyone
for
coming.
If
you
had
questions
that
we
couldn't
address
through
the
time,
please
ask
and
slacker
on
the
mailing
list
and
we'll
we'll
do
our
best
to
be
available
and
we're
excited
to
have
all
of
you
helping.
So
thank
you
very
much
and.