►
From YouTube: WG Component Standard 20200609
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
good
morning,
folks
welcome
to
the
tuesday
june
9th
2020
working
group
component
standard
meeting
pretty
light
agenda
this
morning,
but
I
thought
it'd
be
good
for
us
to
all
you
know,
sort
of
sync
up,
since
we
haven't
had
a
meeting
in
a
while
and
just
kind
of
talk
about.
What's
going
on
and
and
what
people
are
working
on
so
I'll
jump
in.
A
Just
because
I
was
I
had
the
only
agenda
item
which
was,
I
was
hoping
to
make
some
progress
on
the
instant
specific
cup
last
week
to
try
and
unblock
that.
I
made
a
little
progress
on
a
draft
but
sort
of
realized
that
there
were
more
things
I
hadn't
thought
about.
While
I
was
writing
that
that
I
want
to
sketch
out
in
code
in
a
little
more
detail,
so
just
to
summarize,
we
thought
we
had
a
consensus.
A
The
last
meeting
to
just
go
with
sort
of
the
case
by
case
merge,
like
add
an
instance
specific
type.
If
it
turns
out
there's
some
field
that
was
miscategorized,
we'll
put
it
in
both
and
define
a
merge
where
the
instance
specific
one
overrides
the
shared
config.
A
I
think
that
one
thing
I
hadn't
thought
of
was
you
know,
because
we
use
the
internal
types
directly
today.
If
the
fields
in
both
places,
you
know
what
does
other
runtime
code
do?
Does
it
read
it
from
the
instant
specific
one?
Does
it
read
it
from
the
shared
one?
If
it
was
a
miscategorized
field,
there's
always
going
to
be
legacy
code
that
was
reading
it
from
one
place
and
not
the
other.
So
there's
there's
some
additional
thinking
to
do
there
like
on
one
hand.
A
The
other
thing
I'll
just
throw
out
there
is
like
I
haven't,
had
a
ton
of
time
to
work
on
this
and,
if
other
folks
are
interested
in
working
on
it,
I'm
happy
to
hand
it
off
to
someone
who's.
Who
wants
to
unblock
this
as
well.
A
So
that's
that's
my
update.
How
are
you
guys
doing.
B
Well,
I'm
having
some
more
progress,
some
component
config
site
kubernetes,
but
basically
mostly
on
the
support
of
and
manual
upgrades
of
component
configs.
So
I
have
the
pr
which
basically
stamps
config
maps
with
generated
by
qb
on
campus,
with
a
shot
256
hash
already
merged
so
from
I
think,
119,
all
that's
generated
by
cubadiem
and
not
supplied
by
the
user
is
going
to
be
hashed.
B
So
this
will
hopefully
allow
qb
to
basically
just
throw
away
hashed
complete
maps
that
have
component
conflicts
in
them
if
they
need
upgrading
and
just
generate
new
ones
and
pretty
much
that's
on
my
part.
So.
A
B
Partially,
yes,
but
yeah
legacy
clusters
which
don't
have
this
stump,
are
still
going
to
be.
Basically,
they
still
have
to
have
their
component
complex,
upgraded
manually,
even
if
they
were
just
generated.
A
B
In
and
but
yeah
so
far
we
haven't
faced
any
change
in
the
version
of
component
conflict,
so
we
haven't
actually
faced
that
problem,
but
I
suspect
that
soon
we
are
having
we
are
going
to
have
to
deal
with
that.
A
Yeah,
I
think
that
for
the
future.
B
A
B
And
basically,
if,
if
it
has
been
modified
or
if
it
was
supplied
in
its
entirety
by
the
user,
the
user
is
then
responsible
to
just
go
in
and
change
it,
and
currently,
I'm
working
also
on
an
interface
to
basically
allow
the
user
to
specify
new
override
component
context
on
upgrade.
So,
basically,
we
have
currently
a
cubed
m
upgrade
plan
command,
and
this
command
is
basically
showing
you
what
version
is
available
to
what
component
and
how
you
can
upgrade
the
grenades
version.
B
B
What
version
is
supposed
to
be
in
there
and
does
the
user
actually
have
to
do
something
to
manually
upgrade
those
and
cube
a
them
upgrade
apply,
which
is
basically
going
to
upgrade
your
the
the
first
instance
of
the
control
plane
is
going
to
also
have
an
interface
that
enables
you
to
specify
a
file
which
has
these
override
conflicts
and
justify
them
as
part
of
the
upgrade
process.
B
A
Are
the
overrides,
are
the
overrides,
like
just
a
whole
scale
update,
or
are
they
like
more
of
an
apply,
merge
approach.
B
Just
call
scale
update,
we,
I
I
don't
have
any
plans
to
have
any
merges
here.
After
all,
we
we
don't
know.
What's
basically
what
was
the
old
version
by
the
time
we
actually
cubed
him
decides
that
this
conflict
is
not
no
longer
supported.
B
It
basically
has
no
clue
what
it
is
is
a
recognized
conflict
by
the
api
group.
So
the
api
group
is
the
the
marker
there,
but
if
it's
a
different
version
than
the
one
it
is
supporting,
it's
going
to
basically
say
hey.
You
need
to
change
your
component
config
version
to
this
one.
B
C
A
D
C
Sorry
so
I'm
the
last
batch
of
experimental
flags
of
cubelet
migration,
so
we
have
some
three
or
four
appears
open
for
this.
A
Got
it
if
you
can
ping
me
links
to
the
latest
ones,
that
would
be
super
helpful,
yeah
a
lot
of
times
the
github
stuff
gets
lost
in
my
email.
It's
just
super
noisy,
that's
true.
A
C
D
C
Clear
for
people
what
to
do,
I
think
it's
only
been
used
on
the
boot
cube
for
self-hosted,
but
I
think
this
is
mostly
deprecated
now
going
on.
A
Yeah,
I
don't
think
many
people
use
use
the
lock
file.
A
I
think
we
could
probably
put
it
on
a
deprecation
path
for
after
three
releases,
or
so
we
should
probably
talk
to
people
if
they
want
to
make
it
longer
like
a
year
like
when.
If
the
thing
is,
we
don't
know
like
which
companies
really
rely
on
it
to
do
like
a
self-hosted
setup
like
when
core
os
was
still
around
before
red
hat
bought
them,
they
used
it
in
production
so
like
it
was
never
something
we
would
have
removed
in
that
at
that
time.
C
A
Yeah
yeah,
maybe
trying
to
think
I
would
ask
jordan
at
least
if
he
knows
anything
about
how
people
use
it.
He
might
have
some
more
knowledge
or
we
can
maybe
poke
tim
hawking
on
it
and
see
if
he
knows.
A
It
doesn't
look
like
there's
a
ton
of
conversation
on
the
pr
yet
I'll
tag.
A
few
people.
A
A
So
yeah,
I
wouldn't
change
this
to
a
deprecation
yet
I'll.
Let
some
folks
comment
on
it
first,
because
if
we,
if
we
do
have
to
keep
it,
we
might
as
well
move
it
to
the
config.
A
A
Sounds
good
thanks
joe
what's
up.
D
Hey
y'all
finally
got
the
object
meta
for
component
config
kept
out
there
and
well
got
some
comments
from
from
you
and
from
jordan
and
we'll
start
to
iterate
through
fleshing
out
the
the
meat
of
those
items
in
the
the
issue,
as
well
as
the
cap
itself
and
start
getting
some
better
ideas
on
specific
placement
of
the
object,
meta
code
for
the
apis
and
just
keep
iterating
on
that.
For
now,.
A
Awesome
sounds
good,
just
in
case
I
missed
any
emails.
Do
you
have
any
replies
to
comments
or
anything
you
need
me
to
swing
by
on
nothing.
D
Off
the
top
of
my
head,
there
were
a
couple
of
items
that
I
I
did
want
a
little
bit
more
clarity
on,
but
I'll
ping
you
on
those.
D
A
A
All
right,
I
think,
that's
it
for
me
as
far
as
my
to-do's
and
updates
does
anyone
have
anything
else.