►
From YouTube: WG Component Standard Office Hours 20200818
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
All
right,
good
morning,
everyone
welcome
to
the
tuesday
august
18th
working
group
component
centered
office
hours.
This
is
our
hour
for
folks
to
drop
in
and
ask
questions
I'm
mike
and
I'll,
be
in
the
channel,
hey
amin.
How
are
you
hey
good
and
you
good
same
old,
same
old?
You
know.
B
Cool,
so
I
send
you,
I
send
us
some
work
that
I
have
been
thinking
on
on
the
way
to
solve
that
problem,
and
there
are
some
alternatives
on
doing
that.
A
B
A
The
cert
the
structured
merge
diff
is
the
is
the
server
side
apply
one
I
think,
and
then
the
strategic
merge
patch
is
an
older
patch
mechanism
newer
than
json
patch
older
than
structured
mergedif.
A
That
is
a
little
like
a
little
bit
more
semantically
appropriate
for
kubernetes
apis
like
it'll.
Do,
for
example,
if
you
some
things
in
kubernetes
types
are
represented
as
lists
where
each
item
in
the
list
has
a
name,
and
it
can
merge
that
structure
like
a
map
treating
the
name
as
a
key.
A
A
B
I'm
gonna
see
my
my
browser,
yes,
okay,
so
this
is
the
strategic
patch.
This
is
the
json
sixth,
something
so
the
first
idea
that,
I
think,
is
better.
This
approach
is
to
merge
the
elmo
files
before
and
one
way
to
do.
That
is
to
ignore
what
kind
and
path
an
api
version
is
the
instance
one.
So
we
extract
only
the
fields
of
data
that
we
want
and
merge
these.
On
top
of
the
of
the
shared
shared
configuration
or
shared
email.
A
Yeah,
I
think
I
agree
with
that.
That's
what
we
want
is
to
to
just
merge
them
before
hand,
and
we
can
just
require
that
they're,
like
both
the
the
instance.
We
honestly,
if
we're
doing
a
merge,
we
we
almost
don't
even
need
like
a
separate
instance
type.
A
A
If
we
do
it
generically
like
we
don't
need
to
have
a
separate
type
like
we
just
let
users
decide
like
what
they
you
know
what
they
want
to
specify,
for
instance,
and
what
they
want
to
specify
globally
and,
like
all
scenarios
are,
are
work
right
and
then
the
the
objection
was
oh,
but
it
might
be
really
complicated
to
like
come
up
with
a
generic
merge
so
like
maybe
for
now.
We
should
just
do
this
case-by-case
thing,
but
then,
as
you
discovered,
it's
also
really
complicated
to
do
the
case-by-case
thing.
A
So
now
we're
looking
at
a
generic
merge.
B
A
So
I'd
say
like
we
should
just
validate
like
you
know,
if
you
you
know,
maybe
we'll
let
you
specify
a
dash
dash
config
multiple
times
or
may.
I
think
we
should
still
have
a
separate
instance
config
flag,
actually
just
to
like,
because
you
only
need
really
need
two
layers
and
that
like
makes
it
clear
when
somebody's
reading
an
invocation,
what
which
one
is
going
to
be
the
one
on
top.
A
Then,
like
we
should
just
require
that
both
files
use
the
same
api
version
and
kind
so
that
we
don't
have
any
like
conversion
stuff
to
worry
about
before
doing
a
merge
which,
like,
as
you,
also
discovered
screws
up
any
attempts
to
like
properly
filter
out
fields
that
weren't
actually
set.
B
Because
we
need
to
cop
this
back
in
the
end
of
the
in
the
end
of
the
merge,
so
we
need
to
to
bring
the
instance
config
with
the
same
values
of
the
shared
config,
to
keep
both
the
same
in
the
end
of
the
merge.
If
you
don't
specify
the
instance
config,
it
will
always
be
defaulted,
but
you
need
to
copy
them,
after
all,
the
merge
for
them
to
be
the
same.
A
B
So
basically,
the
idea
is
to
decode
and
remove
everything
and
then
patch
on
top
of
the
ammo,
and
then
you
have
the
final
yamo
here.
B
B
A
A
If
we
are,
this
is
at
the
point
that
we're
we're
merging
them
before
we
unmarshal
them,
though
right
so
couldn't
we
couldn't
we
merge
them
like
we
load,
we
just
load
the
file
bytes
right
or
whatever
we
merge,
the
the
json.
A
I
mean
I
guess
we
can.
We
have
to
like
convert
to
json
first
and
maybe
that's
the
tricky
part.
That's
that's
causing
us
to
lose.
That
information
is
that,
what's
going
on.
A
You
know
one
of
them,
you
know
one
like
you
have
like
some
partially
disjoint
sets
right
and
like
the
things
that
do
intersect
should
just
layer
cleanly
and
the
things
that
don't
are
just
like
left
as
they
were
right
and
then
you
should
just
be
able
to
like
once
you
process
that
into
a
single
set
of
bytes,
then
you
unmarshal
that
and
then
run
your
defaulting
on
it.
Why
doesn't
that?
Why
do
why?
Do
we
still
need
to
do
this
copying.
B
Let's
say
we
skip:
let's
say
you
skip
so
this.
This
does
not
happen.
Okay,
okay.
We
have
the
prox
config
here
and
the
instance
config
generated
with
the
default
with
the
default
values
right
sure,
because
we
need
at
least
to.
A
Render
the
default
values,
if
you
you
shouldn't,
need
to
manually,
do
that
if
you,
if
all
you
so,
for
example,
if
we,
if
we
only
pass
one
file,
we're
not
don't
have
to
do
a
merge.
Nothing
like
that,
like
the
traditional
way
to
do.
It
is
just
to
use
the
universal
decoder
like
load
it
right
and
then
that'll
handle
that
actually
unmarshals
it
first
and
then
like
into
a
zero,
valued
struct
and
then
runs
the
defaulting
after
okay.
So
I
don't.
A
I
don't
think
we
have
the
same
problems
of
like
defaulting
it
before,
so
that
it's
like
in
the
right
state,
because
all
that
all
that,
like
sort
of
pre-defaulting
stuff
was
so
that
we
could
have
ways
of
determining
whether
filter
is
set
or
unset
right.
B
Yeah
but
let's
say
we
passed
the
bind
address
in
the
configuration
yeah.
B
A
So
what
I'm,
what
I'm
saying
is:
don't
even
pat,
don't
like
take
instance,
config
out
of
cublet
server
like
it's
not
instance,
config
as
a
as
a
name
is
not
something
that
gets
passed
any
deeper
in
the
system
past
our
like
startup
routine,
and
because,
if
we're
using
the
same
kind
for
both,
then
like
everything
should
just
be
merged
into
the
cubic
configuration
one
before
it
goes
any
further.
B
A
Still
get
like
the
user
experience,
that's
clear,
like
okay,
it's
easy
for
me
when
I'm
debugging
this
thing
to
see
like
this
is
the
normal
config,
and
this
is
the
instance
config
that
I
know
overrides
the
normal
one,
but
then
internally
like
it
just
becomes
one
thing
so
there's
you
know,
there's
no
confusion
inside
cubelet
of,
like
which
one
should
I
use,
there's
no
copying
back
and
forth
to
make
sure
they
match
and
all
that
kind
of
stuff.
A
B
Okay,
yeah:
well,
that's
the
same
idea
with
this
with
the
other
solution
for
the
strategic.
C
B
A
Oh
okay,
yeah!
So
what
would
this
look
like
if
we
like?
I
guess
if
we
every
field
is
a
shared
field.
If
you
we
use
the
same
kind
so
or
do
like
shared
versus
duplicate,
but
basically
every
like
every
field
is
representable
in
every
layer
of
the
the
merge.
If
we
use
the
same
kind
right
so
probably
probably
simplify
that.
A
A
Yeah
yeah,
I
guess
the
next
like
the
next
thing.
I'd
want
to
look
at
is
like.
Can
we
like
how
much
of
this
can
we
simplify?
If,
if
we
do
decide
like
all
right,
we're
gonna
do
dash
dash,
config
and
dash
dash
instance
config,
but
they're
going
to
both
use
the
same
already
existing
cubic
configuration
type
to
do
the
merge.
A
I
think
it
gets
pretty
simple
right
so
then
I
think
I
think,
like
the
does
strategic
merge
patch
require
unmarshalled
data.
A
Like
does
it
work
on
the
raw
bytes,
or
does
it
work
on
like
you
have
to
have
already
like
gotten
your.
A
B
Is
the
same
structure?
Everyone
is
merging
this
stuff
before
doing
the
marshall.
A
I
so
I
think,
let's,
let's
do
a
quick
prototype
with
like
those
assumptions
like
the
simplifying
assumptions
of
like
all
right
we're,
just
we're
not
going
to
do
a
separate
type,
we're
just
going
to
let
you
like,
as
a
user
like
arbitrary
layer
arbitrarily
layer,
these
on
the
command
line
and
like
see
how
simple
we
can
get
it
where
it
still
satisfies
our
requirements,
and
then
I
think
the
next
step
after
that
would
be
to
just
sort
of
double
check
with
strategic,
merge
patch
that,
like
it,
has
the
merge
semantics
we
want
for
our
api,
like
and
and
just
think
through,
like
the
use
cases
right
so
now
that
I'm
letting
you
set
your
instance
config
to
the
same
type,
the
use,
the
sort
of
use
cases
that
a
user
could
use
this
for
increase
in
number.
A
So
it's
not
just
like.
I
had
this
shared
thing,
and
now
I
want
it
to
be
instant
specific,
like
a
bind
address
now.
It's
also
like
I
have
this
local
override
I
can
set
so
like
you
know,
for
example,
if
somebody's
using
dynamic
config
right,
maybe
an
admin
says
well,
I
have
control
of
node
and,
like
you
know,
I
I
want
to
like
make
sure
this
is
like
locked
down
to
this
setting
something
like
that.
A
So
there's
like
more
things,
I
could
see
people
starting
to
use
it
for
so
I
want
to
think
through,
like
so
today,
right
like
when
we
merge
feature
gates,
we
do
a
piecemeal
merge
of
the
flags
into
the
config.
So,
like
you
set
some
feature
gates
in
your
config,
you
could
set
different
feature
gates
in
the
flags
and
they
all
get
combined
and
the
flags.
If
you
set
the
same
one
in
in
flags
and
config,
the
flag
feature
gate
that
you
set
will
override,
but
it's
piecemeal
in
the
instance
config
case.
A
Do
we
still
want
that
to
be
a
piecemeal
merge,
or
do
we
just
want
to
replace
the
entire
feature
gates
map
with
the
like
locally
specified
ones?
That's
a
good
ques!
It's
a
good
question.
I
think
we
might
want
it
piecemeal,
like
tess
kind
of
rely
on
setting
it
via
dynamic
config.
Maybe
it
would
break
sometimes.
A
Yeah,
oh
sorry,
so
like
I
have
a
map,
I
have
two
maps.
Okay,
the
the
the
both
have
a
schema
that
says
your
key
can
be
a
b
or
c.
A
Okay,
and
you
might
you
have
some
like
say:
they're,
just
boolean
values
like
I'm.
Turning
a
on
or
turning
a
off
same
for,
b
and
c,
I
had
there's
two
possible
strategies,
one.
If
I'm
merging
these
two
maps,
I
can
just
replace
the
first
map
with
the
second
map
altogether,
but
in
another
case
I
might
have
just
set
a
true
and
be
true
in
the
respective
maps
so
like
the
first
map
has
a
true
and
the
second
map
has
be
true.
So
my
final
map,
my
two
options,
are
either
I
replace
it.
B
Okay,
I
think
there
are.
There
are
some
ways
to
do
this
kind
of
margin
strategy
more
to
handle
these
things.
Okay,.
A
A
Yeah,
okay,
as
long
as
like
I
just
want
to
make
sure
we
might
you
know
we
might
need
control
over
that
and
we
can.
We
can
decide
that
in
a
discussion
on
github
on
like
the
cap
or
something
but
like
I
I
just
that's.
That's
I'm
sure.
That's
a
question.
That's
going
to
come
up,
so
I
just
wanted
to
kind
of
get
ahead
of
it
and
and
make
sure
we
know
whether
we're
even
able
to
do
that
with
strategic.
B
Okay,
so
basically
we
will
get
rid
of
the
instance
type,
so
every
field
will
be
on
the
share
it
on
the
share
it
now.
The
cubelet
configuration,
for
example
yeah.
So
when
you
want
to
specify
some
particular
ones,
we
just
keep
the
same
configuration
that,
like
the
host
name
overwrite,
we
still
duplicate
this
in
the
other
file
that
will
be
merged.
A
I
think
so
too
it's
simpler,
it's
fewer
types.
It's
you
know
like,
especially
when,
where
go
doesn't
have
generics
available
like
it,
gets
really
crazy
to
try
and
like
do
this
with
multiple
types.
A
B
Oh
so
I
have
like
until
the
end
of
the
week
free,
so
I
can
bring
a
prototype
for
both
cubelet
and
give
brock's,
and
then
we
try
to
extract
these
later.
A
B
A
Awesome
yeah
so
we'll
just
just
to
summarize
we'll
we'll
keep
dash
dash,
config
and
dash
dash
instance.
Config
is
the
way
that
you
specify
the
layers,
but
both
will
take
an
object,
that's
just
cubic
configuration
and
then
you'll,
merge
them
and
then
continue
with
just
cuba
configuration
internally.