►
From YouTube: WG Component Standard 20190416
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
Yeah,
okay,
so
it
looks
like
we
are
kind
of
a
small
crowd
today,
but
we're
gonna
get
started
anyway.
So
welcome
everybody
to
the
tuesday
april
16
2019
working
group
component
standard
meeting.
It
looks
like
we
have
some
items
on
the
agenda
for
this
morning,
not
too
many.
So
let's
get
started
so
the
first
thing
on
here-
I
guess,
is
this
refactor
from
stuart.
Here
I
can
share
as
well.
C
Yeah,
so
I
I've
been
working
with
stuart
on
the
design
of
this.
It's
inspired
by
comments
on
a
oh.
I
probably
should
post
that
as
well.
I
posted
a
google
group
topic
from
api
machinery.
I
do.
I
didn't
include
that
last
week,.
B
C
Anyway,
I
I
tried
to
base
some
changes
to
codec
factory
and
then
speaking
with
liggett
and
lucas
and
lulumir
offline
blueberry
were
in
this
meeting.
It
was
like
two
weeks
ago.
We
wanted
to
implement
a
strict
codec
factory
type
thing
but
outside
of
api
machinery,
and
so
I
went
and
did
that
and
I
had
to
copy
a
bunch
of
code
and
it
was
super
weird
and
I
didn't
like
it,
but
I
posted
the
pr
anyway
and
then
I
opened
this
api
machinery
topic,
which
I
finally
have
a
link
to.
C
So
thanks
for
pulling
this
up,
basically,
I
said:
hey,
I
have
this
patch
and
we
need
a
universal
decoder
and
we
didn't
want
to
modify
the
existing
universal
decoder,
because
eventually
api
machinery
is
going
to
be
universally
strict.
C
C
C
That's
my
codec
factory
patch,
okay
with
the
stuff,
that's
outside
of
api
machinery
that
I
didn't
like
and
daniel
ended
up,
also
reviewing
a
bunch
of
stuff
that
was
from
the
dependent
commit
from
74111,
which
is
the
config
serializer,
now
turned
strict
json,
and
so
I
worked
with
daniel.
I
worked
with
stuart
to
kind
of
implement
some
of
that
stuff
in
stewart's
force
pushed
his
thing
and
it's
it's
pretty
ready
for
review,
there's
just
like
little
nitpicks
and
stuff,
but
hopefully
we
can
get
it
in.
B
This
the
76303
is
the
next
one.
You
were
focused
on.
C
Yes,
basically
76303
takes
like
the
very
atomic
and
and
what
I
mean
is
like
a
like
very
low
level
constructs
of
the
json
yaml
serializers
that
have
strict
options
enabled
and
it
allows
you
to
construct
things
like
decoders
and
encoders.
That
will
do
fallback
logic
and
defaulting,
and
that
kind
of
thing.
So
that's
what
this
patch
allows:
a
user
access
like
easier
access
to.
C
This
patch
needs
to
be
rebased
on
seven
four
one
one
one
though,
but
so
we
need
to.
We
really
need
to
get
that
one
in
because
not
having
this.
The
constructs
like
makes
the
like
seven
patches,
that
I
have
open
right
now,
really
hard
to
work
on.
C
Did
that
happen?
I
think
it
was
recent
nice
six
hours
ago,
yeah
that
I
mean
I'm
glad
that
stefan
pushed
that
through.
C
B
A
C
Do
you
have
an
opinion
on
like
we
made
some
fields
that
were
previously
private
public
should?
Should
we
do
a
little
bit
of
work
to
make
sure
that.
C
It's
on
the
serializer
struct.
Basically
before
there
were
these
private
bools
and
for
like
tracking
whether
or
not
it
was
a
yaml
serializer
or
that's
exactly
it
right
there.
So
serializer
options
has
a
bunch
of
public
fields
because
people
need
to
be
able
to
specify
those.
But
now
it's
embedded
into
serializer,
which
means
that
serializer
gets
a
bunch
of
public
fields
right,
so
yaml,
pretty
and
strict
online
74.
C
In
my
opinion,
it
just
seems
like
there's,
been
some
work
in
this
package
to
make
serializer
immutable
to
the
client
yeah.
So
why
is.
A
C
If
we
embed
it
as
a
non-capitalized
serializer
options,
does
that
mean
that
the
I
guess
yeah
the
substruct
fields
would
not
be.
C
That
could
be
a
really
simple
patch
yeah,
just
a
one
character
change
and
just
basically,
you
would
not
be
able
to
construct
a
serializer
without
the
constructor.
A
C
A
C
This
merged
to
do
follow
up
for
private
embedded.
C
Characters
in
it
yeah
I
got
it
for
sure
anyway.
Hopefully
that's
valuable
in
terms
of
context
sharing
on
the
those
series
of
patches.
We've
got
a
lot
of
work
that
we
can
really
accelerate.
Now
that
that
strict
json
stuff
is
in
so
I'm.
C
Like
a
madman
today,
do
you
regarding
we've
got
an
action
item
from
like
two
meetings
ago
on
the
https
package,
move
the
api
server
and
I
just
haven't
had
the
time
to
look
around
in
there?
Are
there
any
pointers
or
notes
that
we
can
take
to
make
that
process
easier?
When
I
go
do
that.
A
C
B
C
C
Yeah
it's
currently
in
the
api
server,
and
I
know
that
it's
like
imported
by,
like
other
components,
maybe
the
controller
manager
or
other
things
that
need
delegated
off
and
that
kind
of
stuff.
But.
C
I'm
looking
at
a
upgrading
to
one
of
those
six
cores
intel
once
do
you
use
a
laptop.
B
C
C
C
Yeah
and
then
well,
we
can
move
on
from
that.
Also
I
mean
there
was
the
k
flag
thing
that
he
mentioned
in
that
same
bullet
point.
A
C
And
so
I'll
definitely
put
that
in
the
notes
here
just
so
we
have
my
thinking,
opinions.
A
Yeah
the
link
is
in
last
week's
notes,
too
yeah
yeah.
C
Yeah,
okay,
you've
got
the
npr
and
then
I
assume
once
you
put
that
in
then
there's
gonna
be
like
tons
of
cleanups
from
the
kubernetes
kubernetes
side
of
things.
Yes,.
C
A
B
Just
not
gonna
worry
about
that
at
the
moment.
Yeah.
I
did
send
another
one
last
week
to
move
a
bunch
of
cubic
flags.
C
A
Yeah,
there's
like
there's
some
open
questions
on
it
about
whether
certain
apis
should
be
improved
on
the
way
there.
C
C
Actual
apis,
or
just
like
the
encode
apis
of
kubelet.
A
A
That
transition,
so
they
have
to
go
through
that
that
anyway,
so.
C
C
Yeah,
let's
see
all
right
cool,
so
we've
got
that
and
then
oh
yeah.
So
my
next
point
right
here,
which
is
opinions
on
this,
would
you
just
click
on
it
thanks?
C
So
this
patch
adds
an
api
group
testing
library.
C
This
was
something
that
I
carried
from
some
of
lucas's
work
and
after
kind
of
looking
at
all
of
the
work
that
I
broke
up
in
the
way
that
we
had
kind
of
discussed
this
api
testing
library
is
actually
a
dependency
for
another
api
testing
library
in
the
patch
that
I've
linked
there
and
which
means
that
if
we
want
to
be
able
to
write
dependent
tests
and
check
them
in
with
this
patch,
they
need
to
be
done
like
from
the
other
patch.
C
So
basically,
the
open
question
is
just
like.
Should
we
merge
this,
as
is
like,
without
anything,
to
actually
exercise
the
code
and
wait
for
the
follow-up
pr,
or
should
I
close
this
and
then
rebase
it
and
into
a
larger
patch.
C
C
No,
I
that
sounds
totally
reasonable
to
me,
so
just
wanted
to
get
a
little
bit
of
feedback
from
others,
and
I
think
I'll
probably
close
this
patch
and
then
merge
it
into
the
linked
patch,
okay
yeah.
If
that
makes
sense
to
you
to.
C
A
Yeah,
you
know
be
wary
of
of
trying
to
do
too
much
in
one
pr
and
starting
to
refactor
things,
while
you're
in
the
middle
of
another
goal.
C
C
A
C
C
Good
luck,
yeah
cool!
So
where
are
we
on
on
time?
Here
we
have
eight
minutes
to
talk
about
our
feelings.
A
I'm
feeling
good
it's
a
it's
a
cloudy
morning,
but
it's
gonna
be
a
bright
day.
It's
also
cloudy
here
in
colorado.
Where
are
you
based?
I'm
in
california,.
A
E
I'll
be
looking
at
the
the
air
that
removes
the
cobra
flux.
Is
it
an
actual
removal
or
we
are?
Are
we
deprecating.
A
And
then,
they're
being
so,
they'll
they'll
be
provided
by
the
config
file
now
and
also
deprecated
on
that
command
line,
but
they're
still
backwards
compatible.
E
Yeah
and
how
much
versions
do
we
have
to
keep
them
for
for
like
two
versions,
it's.
B
A
A
A
C
A
There
are
definitely
like
some
pain
points
that
we
need
to
think
about
with
component
config
more
on
the
in
cluster
side,
so,
like
you're
running
your
system,
demon
or
like
you're
running
to
epoxy,
right
where
it
is
really
easy
to
set
arguments
on
a
pod,
spec
and
just
edit
it
right
there
in
the
pod
spec
it's
like,
and
you
have
like
the
downward
api
that
can
plumb
into
the
arguments
and
other
things
like
that,
which
you
you
don't
get
that
sort
of
templating
or
convenience
with
the
config
map
approach.
A
C
A
A
A
That
I
haven't
ever
looked
at
that
yeah,
you
can
use
that
and
the
keyboard
will
try
and
do
some
fancy
things
and
like
maintain
a
last
known,
good,
config
and
pre-validate
configuration
before
it
restarts
to
use
it
and
that
sort
of
thing
and
that
that
part's
cool
the
part
that's
challenging,
is
like
the
cubits.
A
Api
itself
is
super
low
level
in
that
config
file
and
so
and
we
sort
of
biased
our
decision
towards
like
let's
expose
as
much
of
that
as
possible
in
the
api
server,
so
that
we
don't
have
like
a
layering
or
like
a
parameterization
of
the
config,
because
then
it
gets
super
hard
to
debug.
You
have
like
two
layers
that
combine,
instead
of
just
like
it's
either
in
one
place
or
the
other.
A
Now
I
sort
of
think
like.
Maybe
you
know
that
like
well,
that
seemed
like
a
really
good
idea
at
the
time
it
caused
other
problems
where
now
you've
lifted
a
bunch
of
options
into
the
api
server
environment
that
are
super
low
level
and
like
maybe
nobody
would
actually
want
to
change
them
dynamically
to
bootstrap,
dynamic
config.
C
Yeah
my
opinion
on
this
is
that
you
should
like
especially
with
something
as
monolithic
and
complex
as
the
kublet
configuration
like.
As
soon
as
you
have
an
app
that
has
that
many
settings,
it's
my
opinion
that
you
need
to
have
a
hierarchical
and
merging
config.
A
Yeah,
so
that's
that's.
That's
one
potential
option
that
I'd
like
to
investigate
further
at
some
point,
probably
after
we
get
the
keywords
api
to
like
ga
and
back
to
dynamic,
config
and
say,
hey
or
maybe
not
ga,
maybe
like
v1,
beta,
2,
right,
yeah,
dynamic,
config,
stuff
and
say
hey
like
maybe
it
makes
more
sense
to
have
this
be
an
overlay
model.
C
And
for
that
overlay
also,
you
meant
to
be
like
very
user
configurable
like
you.
Could
you
know
we
can
pick
a
sensible
default
if
it
makes
sense
for
for
people.
You
know
to
have
like
the
ability
to
override
any
flag
right
from
any
node.
That
should
probably
get
you
as
as
far
as
most
people
are
ever
going
to
be
but
like.
If
somebody
wants
to
run
their
cluster
separately,
they
can
structure
the
overlay
in
a
different
order
or
whatever
based
off
of
some
settings.
C
A
Might
just
have
the
the
api
server
and
the
local
stuff.
E
I
got
a
quick
question
with
regards
to
flex
and
config.
Like
is
it?
Is
it
an
ultimate
goal
for
us
to?
You
know
to
support
exposure
of
config
fields?
The
same
way
viper
is
doing.
E
Yeah,
so
so
viper.
Basically,
if
you
have
a
structure
for
the
config,
which
is
like
a
nested
struct
into
struct
from
the
command
line,
you
can
basically
pass
dot,
separated
structs
to
access
a
field
which
basically
solves
the
problem
with
the
pot
spec,
but
I'm
not
sure
if
we
so
viper.
Nobody
likes
viper,
because
it's
it
has
problems,
but
I
was
wondering
like:
should
we
like
invest
time
into
writing
our
own
solution
for
this.
A
It's
something
I've
thought
about,
I
would
say
not
yet
I
think
it's
there's
probably
more
questions
to
answer
around
like
because
config
is
versioned.
Now
how
do
we
version
the
command
line
properly?
So
maybe
you
need
another
flag
to
like
select
the
version
or
something
there.
A
C
Yeah,
that
would
be
a
strange
one
because,
like
there
would
be
certain
things
that
you
probably
it'd
be
pretty
weird
to
edit,
like
after
you've
already
deserialized
the
config
like
it
has
a
group
version
in
kind
and
then
like
are
you
allowed
to
override
the
group
version
kind
from
the
command
line
right?
Then
you
have
to
re
re-deserialize
the
config.
A
How
do
you
you
know
you
need
to
be
able
to
register
both
of
those
against
the
command
line
and
then
select
the
version
you
want
and
possibly
have
a
default
version
on
the
command
line,
and
that
also
raises
questions
of
like
when
that
default
version
on
the
command
line.
Changes.
Does
that
break
compatibility
so
there's
yeah,
there's
some
definitely
some
things
to
think
through,
but
it
is
pretty
clearly
valuable
from
a
ux
perspective
as
well.
So
you
can't
just
dismiss
it.
C
Yeah,
I
agree.
I'm
not
that's
worth
thinking
about.
I'm
gonna
leave
just
a
note
that
we
talked
about
that
at
all.
C
Just
I
think,
yeah
just
having
a
little
bit
of
project
management
discipline
and
help
us
moving
forward,
trying
to
keep
track
of.
What's
going
on.
C
Okay,
I
have
to
get
going
yeah
yeah,
let's,
let's
close
this
out
I'll
finish.
Writing
this
note
and
then
now
I'll
get
rebasing
on
some
of
the
stuff
that
we
have
in
flight
awesome
yeah.
Thank
you.
Thank
you.
Everyone.