►
From YouTube: WG Component Standard 20190730
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
Record
all
right:
we're
recording,
okay,
welcome
everyone
to
the
tuesday
july
30th
working
group
and
going
standard
meeting.
We've
got
a
healthy
agenda
since
we
were
just
chatting
a
little
bit
about
the
optional
fields
thing.
I
think,
let's
just
jump
in
there
first,
since
that's
now
in
our
minds.
B
So
justin
you
want
to
give
a
brief
overview
of
what
this
is.
Absolutely
I
put
up
a
cap
to
describe
a
thread
which
happened,
which
I
started
on
the
mailing
list,
where
people
were
generally
supportive
but
like
wanted
to
sort
of
go
to
kep
so
kept
is
the
next
process
next
step
in
the
process.
The
idea
is
basically
today,
our
component
config
fields
are
mostly
not
optional
types,
and
so
this
has
two
main
consequences,
the
first
one
of
which
is.
B
If
you
try
to
serialize
out
a
component
config
object
where
you've
only
set
one
or
two
fields.
You
get
all
the
other
fields
set,
though,
with
empty
values
which
makes
it
harder
to
know
like
which
fields
you
actually
set,
and
this
general
problem
of
not
making
a
difference
between
a
default
value
and
the
unset
value
also
applies
to
make
things
like
patching
a
lot
harder.
It's
hard
to
apply
a
patch
over
the
top.
It
makes
generation
harder.
B
B
Sometimes
we
have
to
do
this,
like
was
flag
set
logic,
which
is
a
little
always
a
little
scary
or
we
use
magic,
sentinel
values
to
say
like
this
is
the
unset
value,
but
we
essentially
lose
that
ability
now
in
component
config
unless
we
switch
all
the
fields
or
the
majority
of
the
fields
to
be
optional,
so
to
be
able
to
some
fields
are
already
like
a
slices
already
can
tell
the
difference
between
unset.
B
Well,
that's
sort
of
not
true,
but
some
fields
might
you
might
be
able
to
tell
already,
but
basically
the
trick
would
be
to
move,
make
all
fields
be
pointer
to
a
primitive
value,
pointers
to
a
primitive
value,
and
then
we
would
actually
have
state
on
whether
a
field
was
set
explicitly
to
a
value
or
was
unset,
and
there
would
be
a
difference
between
the
empty
value
and
the
onset
value,
and
then
there's
a
sub
discussion
about
whether
or
not
we
can
keep
the
internal
types
as
they
are
or
whether
they
need
to
go
to
pointer
types.
B
It
would
be
nice
if
we
didn't
have
to
change
the
internal
types.
I
think
there's
a
debate
about
whether
around
that
breaks
around
tripping,
for
example,.
A
A
A
Because
so,
if
we
switch
to
using
pointers
for
optional
fields
and
then
the
internal
type
isn't
pointers,
it's
just
values
today,
all
of
those
would
get
copied
into
the
external
fields
which
would
initialize
the
pointers
and
no
longer
emit
empty
those
values.
Even
if
you
had
omitted
them
originally,
so
you
won't
get
the
same
yaml
through
a
round
trip.
A
A
You
know
with
component
config:
maybe
it's
okay
to
either
make
the
internal
types
pointers,
which
I
I
still
don't
like,
because
it
puts
a
burden
on
on
the
implementers
of
the
component
or
maybe
we
don't
have
to
worry
about
round
tripping
because
most
components
just
read,
config
in
and
then
have
it
in
memory
and
like
might
expose
it
to
monitoring
or
for
tests.
But
there's
sort
of
workarounds
like
often
monitoring
data
is
kind
of
like
needs
to
be
cleaned
anyway,
and
so
people
can
do
that
and
stuff
like
that.
A
So
yeah
there's
some
thoughts
around
that,
but
I
guess
the
question
I
have
is
like
how
many
tools
like
cube
adm
would
have
a
hard
time
if
round
tripping,
wasn't
perfect.
C
D
E
Am
actually
go
ahead?
Thank
you.
I
am
actually
not
quite
sure
we
can
simply
do
away
with
the
fuzzier
in
kubernetes,
but
we'll
have
to
just
bake
in
a
lot
of
tests
that
simply
do
a
one-way
conversion,
and
this
is
kind
of
tedious.
B
To
in
my
mind,
the
challenge
with
the
round
tripping
willow
is
suppose
we
have
v1
and
everything
is
or
a
field
is
a
v1.
A
field
is
a
pointer
in
the
in
v1,
not
an
internal
is
a
pointer
in
v2
and
that
supposes
pointer
to
string.
If
I
don't
set
the
field
in
v1,
but
convert
it
to
v2
via
the
internal
type
it
will,
it
will
appear
as
a
pointer
to
empty
to
the
empty
string.
B
A
Yeah,
there's
that
and
it's
even
trickier,
because
it's
not
you
can't
just
like
implement
emit
empty
from
internal
to
external.
You
have
to
understand
like
something
to
do
with
the
you
understand
the
defaults
for
the
external
type
that
you're
targeting.
A
A
A
Now,
there's
the
there's.
The
other
quote,
like
we've.
Had
this
conversation
a
couple
meetings
ago
about
whether
the
machinery
should
change
its
conversion
model
and
do
direct
conversions
between
external
types
instead
of
going
through
the
internal
type,
I
need
to
go
back
and
rewatch
that
meeting
to
to
remember
all
the
context,
but
that
did
come
up.
F
B
So
so,
as
I
understand
it,
it's
only
cubelet,
that's
cubic
config,
that's
in
beta,
some
of
the
other
ones
that
are
in
alpha
are
looking
to
go
to
beta.
I
was
that's
what
sort
of
motivated
this
is.
I
think
I
saw
a
kept
to
bring
scheduler
to
beta,
and
I
was
like
oh
like
do.
We
want
to
talk
about
whether
we
want
to
make
things
optional
before
we
move
things
to
beta,
because
it's
going
to
be
harder
to
deal
with
cubelet
the
the
external
yaml
shouldn't
change.
B
So
there
may
be
an
argument
for
that,
but
it's
still
going
to
be
tricky
because
so,
in
other
words,
a
yaml
file
that
was
valid
before
should
still
be
valid
now,
but
there
are
still
like
incompatibilities
based
on
like
different
uses
like
client
go.
Users
are
gonna,
see
differences.
B
My
intention
was
that,
yes,
we
would,
if
we
think
this
is
the
right
thing
to
do,
that
we
would
change
everything.
Obviously
we
wouldn't
change
it
in
one
big
pr,
but
we
should
like.
If
we
it
would
be
weird
to
say.
B
Yes,
we
think
that
component
config
should
retain
the
notion
between
a
value
that
was
specified
versus,
not
specified
and
then
have
some
that
are
sort
of
legacy
and
leftover
and
not,
but
that
don't
make
that
distinction
in
my
opinion,
so
I
would
like
to
do
whichever
one
we
want
to
do.
First,
like
scheduler
or
component
controller
manager,
whichever
one
makes
sense.
C
I'll
make
a
note
that
traditionally,
like
when
I've
worked
on
config
systems,
we've
relied
on
merging
with
a
default
config
in
order
to
as
the
base
in
order
to
get
this
behavior.
C
So
our
our
defaulting
mechanisms
were
usually
config
merges
instead
of
having
the
can
the
conversion
from
external
to
internal
populate
the
internal
type
with
defaults
that
are
like
magically
about
the
type
so
like.
If
I
wanted
to
have
a
version's
defaults
right
like
I
would,
I
would
do
an
internal
type
merge
with
something
that
was
generated
from
the
default
struct
like
for
that
type.
A
A
C
I'm
not
saying
what
I'm
pointing
out
is.
The
conflation
is
not
that
the
defaults
are
stored
with
the
versions
type,
but
that,
when
the
type
is
converted
that
the
type
is
populated
with
the
defaults,
oh
yeah,
I've
always
felt.
That
was
a
little
strange
like
the
the
fact
that
that
happens.
Automatically
is
a
leaky,
abstraction.
B
C
You
can
call
them
separately,
you
cannot
call
them
through,
oh
through
codec
factory,
if
you
use
the
legacy
encoder
and
decoder
it'll
it'll
work,
it'll
it'll,
give
you
non-defaulted
structs,
but
then
there's
not
really
much
like
once
you
have
those
you
have
to
then
call
api
machinery
things
on
them.
C
C
Yes,
I
mean
like
what
we're
doing
with
component
config
already
is
leverages
api
machinery,
it's
very
different
from
the
the
path
that
objects
take
through
the
api
server
yeah.
The
api
server
does
some
non-standard
hacks
to
make
things
work
with
media
types
like
that
are
not
part
of
part
of
the
encoders
and
decoders,
which
I
think
is
weird,
and
we
should
fix
that.
Eventually,
it
does
operations
where
it
like
recreates
structs,
but
then
attaches
different
serializers,
so
that
the
media
type
changes,
which
is
a
very
low
level
thing
to
be
doing.
C
You
know
like
outside
of
api
machinery
packages
but
and
runtime,
but
so
like
the
fact
that
api
machinery
or
the
fact
that
the
api
server
has
to
do
that
in
order
for
it
to
work
like
tells
me
that
the
libraries
are
not
really
structured
in
a
way
like
where,
like
all
of
the
use,
cases,
are
fledged
out
and
exposed
in
a
sensible
interface.
G
C
So
if
we
have
to
assemble
some
things
in
the
component
repo
in
order
to
make
defaults
work
sensibly,
then
that
isn't
so
surprising
to
me.
A
C
Then
it
fails
at
the
nested
merge
right,
not
sure
that
does
it
yeah,
I
don't.
I
think
it
and
pointers
might
change
work.
I
think
it.
C
A
B
I
I
have
a,
I
don't
want
a
monopolist,
I
mean
I
have
a
suggestion.
It
looks
like
like
bobby
salamat
commented
that
he
has
like
a
want
for
this
for
the
scheduler
one.
Shall
I
do
a
sort
of
work
in
progress,
one
for
scheduler
and
we
can
have
a
look
at
it
and
we
can
like
plum
it
through
and
see
how
bad
it
gets
in
terms
of
you
know
like
the
internal
types
and
then.
A
C
The
this
comment
did
confuse
me,
but
bobby's,
one
at
the
top
yeah,
but
it
may
be
because
of
the
sheer
number
of
boolean
statements
that
are
in
there.
I
think,
because
if
you
read
it,
if
you
read
it,
it
sounds
like
he's
talking
about
not
being
able
to
know
that
a
flag
was
provided.
Oh.
B
Know
that
that's
exactly
there's
there's
some
reflection
on
the
flags
that
you
can
do
that's
built
into
v5,
but
I
think
he's
saying
in
the
in
the
component
config
world.
He
wouldn't
be
able
to
do
that
right.
Oh
you're,
saying
like
how
his
wife,
yeah,
maybe
he's
just
using
flag
to
meet
field
or
something.
B
C
Yeah
this
was
from
the
another
sig
poc
thing
that
I
wrote
like
a
week
ago,
but
basically
yeah
like
like
line
41
right
there.
C
I
this
little
part
of
the
library
has
it
builds
a
flag
struct,
so
that
people
can
figure
out
like
from
outside
of
it,
whether
the
flags
were
set
and
what
values
they
were
right.
It's
like
really
repetitive.
It's
actually
the
same
thing.
We
do
in
legacy
flag
in
legacy
flag.
You
do
that!
Yes,
I'll
show
you.
C
A
C
Because
you
could
coach
in
it
and
it
would
work,
but
it
it's
like
now.
You
have
this
struck
field,
that's
like
it
could
be
a
private
field
and
then.
A
A
You
would
I'm
just
trying
to
think
if
that
gives
you
a
whole
lot,
so
you
would
track
it
or
in
a
separate
structure
or
in
the
internal
one.
You
would
still
use
the
internal
type
fields
like
you
are
today,
assuming
that
they've
been
initialized,
and
just
assuming
that,
like
the
default
or
whatever.
A
Did
the
conversion
like
would
not
have
to
change
the
defaulting
representative
of
what
was
set
yep
and
then
conversion,
so
conversion
into
the
internal
type
would
set
whether
they
were
provided.
A
C
C
A
A
C
C
A
Yeah,
I'm
not
sure
how
practical
it
is,
but
we're
almost
out
of
time
here.
So
I
want
to
actually
I'm
not
going
to
get
kicked
out
of
this
flame,
but
I
did
want
to
talk
really
quick
about
ross's
q
proxy
pr
and
like.
I
would
like
to
merge
that,
if
possible,
maybe
like
one
thing
we
could
do
ross.
Oh
ross
is
he's
still
here.
A
Meeting
then
there's
no
point,
if
he's
not
here.
Basically
I
want
to
merge
it
and
I'd,
be
I,
like
I'd,
be
happy
to
rephrase
it
as
like.
Do
a
v1
alpha,
2
or
something
to
prototype
those
ideas
instead
of
pushing
the
data,
if
we
want
to
wait
on
beta
to
figure
out
this
optional
field,
just
so,
that's
on
the
record.
F
I
just
wanted
to
point
out
that
we
should
probably
remove
my
documents
about
overrides
from
the
agenda
because
we
already
covered
it
multiple
times
in
discussions
on
the
dock
itself,
and
I
already
provided
like
a
summary
what's
going
on.
I
need
to
find
time
for
this,
and
the
other
point
is
that
it's
not
going
to
happen
in
116
the
cap
itself,
so
so
that's
pretty
much.
It.
G
A
Okay
thanks
everyone,
good
good
meeting,
justin
feel
free
to
send
me
that
prototype
when
you
have
a
chance.
Okay,
sure
thanks
have
a
good
day.
Everyone.