►
From YouTube: WG Component Standard 20200414
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
The
recording
okay
good
morning,
everyone
welcome
to
the
tuesday
april
14th
working
group
component
standard
meeting.
It's
been
a
little
while,
since
we've
had
a
meeting,
so
this
is
nice
to
have
a
couple
of
agenda
items
today,
there's
two
we're
going
to
talk
about
and
then
we'll
phoenix
blue's
adding
one
also.
So
then
we'll
have
room
for
more.
So
the
first
thing
is:
I
wanted
to
follow
up
and
get
some
direction
on
the
instance
specific
config
cap.
I
wrote
this
with
sort
of
two
goals.
A
Yep
great,
so
I
wrote
this
cap
originally
with
sort
of
two
goals,
one
basically
being
to
unblock
component
config
implementations
and
that's
the
main
goal.
Migrations
are
blocked
on
having
a
solution
for
fields
that
may
need
to
be
specific
to
a
single
instantiation
of
a
component
and
not
shared
across
pools
of
components.
Component
configs
are
designed
typically
to
be
shared,
so
that
blocks
those
fields
from
being
in
the
config,
so
we
needed
to
have
some
way
of
splitting
them
out.
This
original
proposal
was
to
have
two
different
kinds.
A
There's
been
a
lot
of
discussion
around
that
and
I
sort
of
summarized
the
discussion
here
in
this
comment.
So
it
seems
like
the
two
options
that
are
on
the
table.
Right
now
are
if
we
define
two
kinds,
be
willing
to
duplicate
some
state
between
them.
If,
for
example,
we
have
a
field
like
a
bind
address
that
could
sometimes
be
instance
specific
or
sometimes
be
shared
and
then
define
a
merge
semantic
for
just
those
two
kinds
or
go
a
lot
further
and
define
a
general
merge.
A
I
think
I
am
in
the
vote
of
one
option,
one
because
it's
a
lot
more
attractable
and
my
goal
is
to
unblock
component
config
migrations
so
which
would
be
to
have
an
instance
specific
kind
and
a
shareable
kind,
and
there
will
be
some
overlap
in
the
fields
and
to
merge
them.
You
take
the
values
from
the
instance
specific
that
are
in
the
overlap,
and
I
wanted
to
see
how
folks
feel
about
that.
B
C
I
I
agree
that
this
is
a
good
thing
to
do.
I
think
that
what
you
say
about
it
being
practical
to
create
a
second
type
for
the
mostly
instance
specific
things
potentially
with
some
you
know,
key
specific
overrides
makes
sense.
C
When
to
me
like
the
fact
that
there
is
a
configuration
like
inherently
it's,
to
give
the
user
options
right.
So
these
things
are
options
that
are
intended
to
be
configured
and
like
for
the
project
to
decide
what
is
instant,
specific
or
node
specific
like
versus
what
should
be
shared
and
managed
at
a
config
level
across
the
whole
cluster.
Is
you
know
like
it's?
It's
a
little
bit
of.
A
C
A
Yeah,
I
I
understand
what
you're
saying
as
far
as
giving
users
that
flexibility
and
I
think,
you're
right
that
we
are
sort
of
in
in
you
know
the
you
know,
arms
of
the
current
design
or-
or
maybe
it's
just
that,
because
nobody
has
gone
ahead
and
defined
a
general
merge
semantic
that
can
be
used
across
kubernetes,
like
the
closest
thing
that
exists
is
server
side
apply,
and
you
know
it's
not.
It
hasn't
been.
A
It's
not
like
a
library,
that's
easy
for
everybody
to
consume
and
just
do
the
same,
merge
on
the
command
line.
I
think
it's
just
a
lot
more
work
at
this
point.
To
do
that
and
so
like,
like
you
said,
we
got
to
be
practical
and
that's
what
I'm
trying
to
do
is
just
be
practical
to
unblock
the
next
step
of
this
project,
but
I
think
you're
right.
A
Yeah,
I
think
that
there
are
a
couple
places
we
allow
that
sort
of
weight
binding,
but
it's
not
particularly
comprehensive
right,
like
we
have
the
downward
api
for
pods.
That
would
be
one
example
where
it's
sort
of
templated
and
you
get
the
instant
specific
value
at
the
end
of
the
day,
like
a
pod
name,
for
example,
but
yeah
you're
right,
it's
not
everywhere,
and
we
don't
have
generally
good
solutions
for
that,
and
I
think
some
of
that
might
have
even
been
intentional
just
to
keep
things
simple
until
it
was
shown
necessary.
C
So,
with
with
regard
to
creating
the
instance
specific
types.
A
No,
I
just
wanted
to
get
get
some
consensus
on
that
direction.
I
need
to
go
rewrite
the
cap
now
to
actually
lay
that
out
how
that
would
work.
A
Cool,
so
that's
that
one
anyone
have
anything
else
to
say
on
that.
C
Of
what
you're
thinking,
options
or
bind
options,
or
something
like
that
like,
if
there's
some
general
way
to
describe
all
of
those
things
instead
of
just
bucketing
it
under
instance,.
A
Yeah,
I
would
love
to
have
a
name
that
is
more
immediately
descriptive.
There
seem
to
be
a
variety
of
options
that
fall
into
this
category.
I
haven't
really
come
up
with
a
better
descriptor
for
them
in
that
taxonomy
yeah.
A
Yeah,
that's
what
we
called
it
even
a
longer
time
ago.
D
A
Not
always,
okay
can
be
things
yeah,
so
like
a
a
bind
address
is
one
that
is
in
potentially
both
categories,
because
you
could
just
be
everybody
buying
stall
interfaces,
it
could
be
like
people
have
specific
requirements.
The
other
common
ones
are
things
like
host
names
and
ip
addresses.
A
C
I
do
think
that
interface
names
are
something
that
we
could
look
into
just
from
a
standardization
standpoint,
because
there
are,
you
know,
with
tools
like
systemd
like
late
into
the
boot.
Those
things
are
stable,
so.
A
A
Okay,
that
sounds
good.
I
will
go
refactor
the
cap
to
sort
of
explain
the
merge
semantic
between
the
two
kinds
and
think
about
naming
a
bit
chris.
Do
you
want
to
go
ahead
and
present
sure
share
my
screen?
D
Oh
host,
disabled
attendee,
sharing.
A
Oh,
I
did
all
right,
let
me
do
it
I'm
in
the
web
client.
So
I
don't
know
what
what
restrictions.
D
Changed
cool!
Well,
while
you
pull
that
up.
In
essence,
what
I've
been
doing
is
trying
to
integrate
component
config
style
configurations
into
controller
runtime,
so
that
we
can
eventually
get
that
downstreamed
into
things
like
operator
sdk
and
into
q
builder,
so
that
we
can
get
this
more
widespread
into
custom
controllers
and
not
just
core
kubernetes
components.
D
There
was
an
open
issue
from
jeff
johnson
from
the
component
or
the
cluster
add-ons
working
group
trying
to
get
this
going.
So
I
started
implementing
a
design
dock
for
it
and
we
got
that
merged,
but
now
we're
working
through
and
working
through
the
different
ux
of
how
we
could
implement
this.
I'm
kind
of
I'm
looking
for
reviews
michael's
been
super
wonderful
in
helping
review
where
it
currently
is
and
yeah.
Now
I'm
trying
try
to
take
it
to
the
finish
line.
I
guess.
D
So
the
beginning,
the
beginning
parts
is,
I
think,
I'm
working
on
this
as
a
multi-part
feature
so
currently
in
controller
runtime
to
actually
configure
the
core
component
of
it.
The
manager,
which
is
what
everything
gets
spawned
off
of
or
all
the
controllers
get
spawned
off
of.
D
You
pass
in
an
option
struct
and
I'm
trying
to
keep
that
as
a
base
like
almost
as
an
internal
type,
which
I
don't
like,
but
it
will
work
as
a
as
a
first
implementation
to
help
roll
people
into
this,
and
so
the
first
implementation
is
basically
a
new
options
from
component
config
which
currently
in
its
in
what
this
poll
request
has.
Is
you
defined
a
bunch
of
setters
and
getters
for
pulling
out
the
specific
manager
configurations
needed
to
configure
options?
D
But
can
be
rewritten
into
your
own
custom
type
as
you
want
to
add
more
configuration.
So
if
you
go
into
files.
A
D
Files
changed
and
you
can,
you
can
go
to
the
component.
Config
go,
which
is
all
the
setters.
D
Which
michael
and
I've
been
talking
about,
trying
to
figure
out
a
way
to
get
rid
of
these,
and
so
this
these
currently
will
go
through,
and
basically
you
could
define
your
object.
However,
you
want
as
long
as
it
supports
these
these
functions.
We
can
pull
out
the
configurations
and
reconfigure
the
options
struct
if
you
scroll
down
to.
C
D
D
New
to
me,
michael,
but
basically
be
able
to
pull
the
actual
fields
off
as
as
actual
fields.
Instead
of
using
an
interface
and
making
everybody
develop
or.
A
Write
write
out
these
functions
for
their
types
right
and
now
like.
If
you
had
implemented
this
interface
already
on
your
base
type
and
people
are
directly
embedding
it.
I
don't
think
people
are
gonna,
have
to
re-implement
it
right.
You
get
the
you
get
the
methods
for
free.
I
think
what
is
I
think,
what
I'm
noticing
is
that,
like
typically
and
it's
not
necessarily
a
bad
thing
for
you,
but
typically
we
don't
have
these
interfaces
implemented
on
the
ghost
trucks
right.
A
It's
just
a
bunch
of
public
types
and
you
just
like
pull
values
off
like
you
would
any
stretch,
and
so
I'm
just
like
wondering
if
there's
a
way
to
reduce
that
complexity
here
and-
and
I
think
the
other
side
of
it
is
like
your
intention-
is
that
users
can
extend
this
type
right
with
their
own
their
own
options,
and
so
that
was
the
motivation
for
the
interface
so
that
you
would
be
able
to
still
pass
this
sort
of
options.
A
So
that's
one
option
and
I
do
want
to
say
too
speaking
of
api
machinery
conversions.
So
it
sounds
like
q
builder.
Does
conversions
a
little
differently?
Yeah!
That's
fine!
I
like
I,
don't
have
a
strong
opinion
on
it
because
I'm
not
super
familiar
with
what
qbuilder
does
and
if
you
think
how
they
do.
It
is
better
then
like
okay,
maybe
maybe
you
do?
Maybe
you
don't,
but
where
are
the
trade-offs,
because
if
that's
a
ux
that
people
like
who
are
using
control
over
one
time
are
more
familiar
with,
it
might
make
more
sense.
D
Yeah
the
so
to
do
it
that
way.
Actually
I
put
did
I
put
the
branch
in
here.
I
think
I
sent
it
directly
to
you.
Let
me
certainly
get
how
to
get
this
to
yeah
somewhere.
D
So
I
implemented
using
that
pattern
from
controller
runtime
and
cube
builder
and
the
idea
there
how
they
do
it
is
they
basically
create
sorry,
I'm
still
trying
to
find
it
there.
It
is.
A
They're,
their
docs
pages
look
like
they
pick
a
version
as
the
hub
like
they
take
an
external
version
as
a
hub.
Instead
of
having
an
internal
yeah.
D
Which,
technically
you
don't
have
to
they
just
document
it
that
way,
so
in
in
the
the
separate
branch
that
I
just
sent
you
or
that
I
sent
in
zoom,
it
actually
sets
up
an
internal
type
at
just
package.
Api
can
config
instead
of
a
version
config
and
it's
a
direct
replica
just
like
we
do
in
normal
conversions.
D
But
the
difference
is,
is
I
specify
the
internal
type
as
the
hub,
which
is
just
defining
a
function
called
hub
on
it?
And
then,
when
you
want
to
do
the
conversions,
you
write
from
your
version
type
you
have
it
define
a
converts
to
and
it
converts
from,
and
then
you're
able
to
call
those
to
convert
it
convert
an
external
type
into
an
internal
type,
so
implementation.
B
A
One
one
advantage
of
so:
for
example,
if
you
used
all
external
types
and
just
made
one
of
them
the
hub
one
advantage
of
that
is
that
if
ever
somebody
else
is
trying
to
vendor
your
types
and
do
the
conversions
all
that
machinery
is
public,
so
they
can
do
it.
That's
the
struggle
with
the
internal
type
is
that
we
actually
don't
export
those
into
the
staging
repos,
and
that
makes
it
so
that
nobody
who
consumes
those
can
actually
do
the
conversions
and
it's
only
the
component
itself
and
that's
what
does
some
design
discussions
in
no
resolution?
D
A
Okay-
and
I
think
another
option
we
sort
of
tossed
around
yesterday,
was
to
sort
of
flip
the
embedding.
So
let
me
go
back
to
that
last
example.
A
A
You'd
still
have
the
type
safety
of
passing
your
thing
around
for
things
you're
using
it
for
and
then
users
would
build
extraction
to
their
types.
So
that's
another
option.
Oh.
A
D
B
D
The
custom
types
could
be
passed
into
not
this
type.
I
see
okay,
that
was
what
you're
getting
at
by
saying:
flipkart,
okay,
yeah.
C
A
A
Everything
yeah
or
you
just
call
it
like
extensions
or
extension,
or
something
yeah,
okay,
that
implies,
and
then
we
have
documentation
that
says.
Okay
like
this
should
also
be
a
kubernetes
object.
It
should
have
all
the
metadata,
etc,
etc,
and
then
what
what
happens
is
so.
This
is
where
you'd
have
to
like
kind
of
check
with
api
machinery
to
see
if
it
would
work.
A
If
you
chose
the
external
only
approach,
because
the
docs
for
runtime
that
raw
extensions
say
that
it
should
be
runtime.object
on
the
internal
type
that
might
be
tricky
if
you're
only
converting
between
externals,
but
it
might
also
just
pass
through
between
externals.
That's
something
to
test
and
verify.
Let
me
see
if
I
can
actually
pull
it
up
here.
D
D
A
We
talked
about
this
last
night.
I
haven't
done
enough
research
to
give
that
one,
a
good
yeah,
that's
fair!
I
like,
I
think
it's
it's.
It's
probably
worth
just
like
poking
a
few
of
these
yeah
and,
like
I
don't
know,
throw
a
quick,
google,
doc
or
a
markdown
file
together
and
just
lay
out
the
trade-offs
like
pros
cons
of
each
don't,
spend
like
too
much
time
on
it,
because
we
want
to
block
you,
but
that
would
that's
probably
just
useful
as
a
historical
artifact
of
why
we
decided
to
do
whatever
we
decide.
C
My
initial
gut
reaction
to
this
is
that
I
like
in
lining
the
json
tags
in
lining
the
type.
C
A
Yeah,
I
think
that's
a
good
point.
Lee
and
chris.
I
had
some
thoughts
on
that
too,
which
was
that
I
think
one
of
the
other
stated
reasons
for
the
interface
is
like
people
who
have
sort
of
arbitrary
ways.
They
want
to
structure
their
configurations,
which
is
actually
it's
probably
an
anti-pattern,
and
you
know
in
most
cases
it's
it's
not
going
to
be
that
different.
D
A
No,
it's
well.
A
So
raw
extension
is
this:
it's
basically
a
a
raw
bite
plus
a
an
object
yeah,
it
might
work
as
far
as
inlining,
but
it
I
think
it's
weird
to
have
a
field
called
raw
in
a
field
called
object
just
in
lines
in
every.
C
Yeah,
I
was
thinking
controller
configuration
extension
is
like
a
field
team
or
something
that's
optional.
Basically,
I
was
saying
we
could
do
both
so
that
you
wouldn't
have
to
change
any
of
the
generated
code
that
controller
runtime
creates
for
putting
together
the
manager.
But
then
you
could
get
your
own
custom
types
plugged
in
to
that
extension.
A
A
D
All
you
have
to
do
is
pass
in
the
actual.
Whatever
your
custom
type
is,
and
it
gives
you
it.
C
D
A
I
think
you
can
do
it
either
way
and
that's
that's
so
we
can't
make
a
decision
just
on
like
oh,
you
can
do
it
this
way
and
you
can't
do
it
the
other
way.
It's
gonna
have
to
be
more
nuanced
on
like
what's
what's
easy
for
us
to
reason
about
what's
simpler
in
code
like
what
do
users
expect,
you
know,
what's
more
abstract
or
less
abstract,
it's
going
to
be
like
sort
of
value
judgments
like
that.
So
I
think
that's
where
it's
useful
to
have
a
doc
where
we
can
argue
about
this.