►
From YouTube: WG Component Standard 20200107
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
welcome
everyone
to
the
tuesday
january
7th
working
group
component,
standard
meeting,
happy
new
year
hope
everyone's
well
arrested
after
the
break.
I
enjoyed
your
holidays,
so
we're
just
starting
to
pick
up
again
for
the
new
year,
so
everyone's
I'm
sure
going
through
email
and
like
catching
up
after
the
break.
So
I
don't
want
to
do
too
much
right
away,
but
I
did
have
a
couple
things.
A
Some
people
did
make
some
progress
over
the
break,
so
cevita
looks
like
made
some
progress
on
keyboard,
flag,
migrations
and
that's
starting
to
move
forward.
So
that's
really
exciting
to
see
that
work.
Getting
done.
There's
a
couple.
People
I
need
to
check
in
with
one
is
praveen.
Sastry
was
planning
on
doing
some
work
on
solving
the
instance,
specific
config
problem
and
writing
a
cap.
So
I
need
to
check
in
and
see
if
there's
been
some
progress
there
that
may
block
us
soon.
A
If
it's
not
done
so,
I
want
to
make
sure
that's
moving
forward
and
then,
if
any,
I
don't
know
if
anyone
has
seen
it
yet,
but
there
is
a
cap
out
for
a
new
structured
logging.
I
think
by
cerrathius.
I
hope
I
spelled
that
right.
I
will
get
a
link
and
put
it
in
the
notes,
but
that's
kind
of
a
major
logging
overhaul
for
all
of
kubernetes
it
and
it
connects
to
our
working
group.
So
I've
taken
a
look
at
it.
Other
folks
might
want
to
take
a
look
at
that.
A
B
Over
the
break,
I
was
actually
rebasing
on
ross's
work
in
kubernetes,
which
just
hits
a
lot
of
component
config
stuff
and
there's
some
interesting
decisions
that
I'm
learning
from.
So
thanks
for
for
doing
that,
work
for
us.
A
B
Yeah
I
mean
the
crux
of
it
is
that
we
used
to
index
the
component
configs
in
memory
with
their
internal
versions
by
kind
and
since
those
apis
are
in
different
groups,
when
things
would
change
groups,
then
you
have
a
hard
time
dealing
with
multiple
groups
for
the
same
kind,
so
russ's
work
actually
indexes
the
configs
by
group
and
so
that
we
can
navigate
them
at
a
top
level,
a
little
bit
easier
and
then,
in
that
process
everything
is,
was
kind
of
more
isolated
from
the
rest
of
the
code
and
mostly
it
just
acts
on
the
external
versions.
C
Yeah,
so
the
the
idea
is
to
just
reverse
the
way
we
actually
manage
component
configs,
and
we
previously,
as
you
mentioned,
used
kinds
and
kinds
are
not
like
the
best
solution.
Simply
because
kind
names
can
actually
change
or
even
like
have
the
same
kind
name
in
between
different
groups,
and
this
is
a
problem
for
kubernetes,
so
we
actually
reversed
all
and
we
went
to
use
groups
as
an
indexing
solution
for
cubadium,
and
this
way
also
allows
us
to
basically
encapsulate
most
of
the
version.
C
Specific
stuff
and
basically
versions
are
actually
version
are
hardly
visible.
Outside
of
this
component
of
cube,
80.
C
Yeah
so
basically
cube.
Adm
is
used
to
like
to
deploy
several
components
that
have
support
for
component
configs
like
these
are
currently
only
the
kubelet
and
q
proxy,
but
we
also
were
thinking
in
expanding
this
into
the
controller
manager,
the
scheduler
and
the
api
server
when
they
actually
gain
better
versions
of
component
configs.
D
D
C
C
C
The
work
on
this
refactoring
is
actually
pretty
much
a
result
of
the
like
the
discussion
we
actually
have
had
several
months
ago
on
component
config
management
like
upgrades
and
defaulting
and
stuff
validation,
and
basically,
we
actually
moved
away
from
trying
to
upgrade
component
configs
and
instead
moved
into
the
direction
where
we
actually
have
users
to
migrate
them
or
if
they
were
actually
generated
by
a
cubed
m,
have
cubadium
just
scrub
the
old
configs
and
generate
new
ones,
got
it
yeah,
that's
probably
easier
for
now.
C
On
like
some
of
the
discussions
here,
we
actually
had
cluster
api
folks,
basically
having
the
same
issue
as
cubadiem
have,
and
this
is
probably
a
basically
the
first
time
cubedm
actually
hit
this
and
probably
other
components
in
the
kubernetes
ecosystem
is
going,
are
going
to
actually
hit
this
like
multiple
times
and
closer
api
is
probably
one
of
the
next
components
to
do
this,
and
probably
some
generalized
form
of
cap
at
some
point
may
be
meaningful,
especially
whenever
these
are
like
more
than
one
component
that
have
to
deal
in
a
strange
way
with
component
conflicts
yeah.
B
One
question
I
did
have
reading
the
code
and
like
writing
new
or
extending
the
implementation
is,
it
seems
like
we
no
longer
in
kubernetes,
are
actually
importing
internal
types.
Correct
me
if
I'm
wrong
ross.
C
B
And
then,
basically
the
thought
there
is
that
we're
kubitam
will
only
support
it's
basically
using
an
external
api
right,
even
though
the
tool
operates
on
these
structures
like
it,
it's
only
working
with
a
single
version
right.
C
Like
with
the
current
release
cycle,
so
this
doesn't
get
shipped
okay
but
yeah.
Currently
only
a
single
group
and
version
is
going
to
be
a
support
per
component
in
the
future.
We
may
actually
extend
it
a
little
bit,
but
then
we
end
up
with
how
should
we
migrate
and
stuff
like
that?
So
currently,
it's
much
more
easier
to
just
support
a
single
group
and
version
and
basically
get
migrations
and
stuff
to
for
the
users
to
do
them
and.
B
That's
with
the
just
as
a
background,
because
the
reason
for
that
might
be
a
little
confusing,
but
for
the
benefit
of
everyone
on
the
call.
B
So
the
trouble
with
using
an
internal
type
such
as
like
the
cube
proxy
configuration
in
kubernetes,
is
that
the
external
type
lives
in
the
proxy
repository
and
then
the
internal
type
actually
lives
in
kubernetes
kubernetes,
and
there
is
a
parallel
effort
that
influences
the
decision
to
not
use
the
internal
type
of
of
reducing
kubernetes,
eliminating
kubernetes
dependencies
on
kubernetes
kubernetes,
so
that
kubernetes
can
be
moved
out
of
tree.
B
So
hopefully
that
is
helpful
and
then
the
reason
I'm
asking
this
question
is
because
I'm
working
with
another
component
config
api
that
is
completely
out
of
tree
in
the
add-ons
repo,
and
so
that
like
makes
me
ask
the
question:
can
I
use
the
internal
type
in
an
external
repository?
C
Yeah
technically
said
you
shouldn't
simply
because
the
internal
type
is
bound
to
changes.
So
at
some
point
you
may
actually
want
to
bump
the
imported
version
a
little
bit,
and
then
you
suddenly
find
out
that
the
internal
types
have
changed
and
you
need
to
change
a
bunch
of
code
in
your
repository,
and
this
is
basically
getting
you
nowhere.
So.
B
A
A
Because
because
we
can
add
fields
without
bumping,
the
api
version
like
if
you're
consuming
the
exported
like
the
staging
repo
for
cubelets
apis,
you
need
to
make
sure
you
have
the
same
version
of
that.
You
both
expect
the
same
version,
there's
a
little
bit
of
leeway
because,
like
with
go
modules,
you'll
you'll
just
use
one
version
that
that
dependency
across
your
entire
build
and
as
long
as
like
and
you
shouldn't
be
referencing
any
like
weird
field
names.
So
it
should
work.
But
it's
just
something
to
be
aware
of.
B
A
A
Yeah,
that's
that's,
maybe
a
little
I
was
thinking
just
like
if
you're
literally
just
calling
like
functions
in
code
with
the
structs
yeah,
not
serializing,
anything
but
yeah.
So
the
other
thing
ross
just
and
I'm
sure
you
guys
have
this,
but
just
to
make
sure
it's
in
your
release
process
when
a
new
version
of
kubernetes
comes
out
like
make
sure
you've
updated
all
those
api
dependencies.
Even
if
the
group
versions
haven't
changed
because
there
might
be
new
fields
that
you
need
to
expose.
C
Yeah,
we
will
surely
actually
keep
close
ties
with
the
kubernetes
version.
We
haven't
yet
decided
on
a
like
strict
versioning.
D
C
Even
the
exact
methodology
upon
which
we
are
going
to
attack
cubed
m
out
of
three,
but
at
this
point
we
are
thinking
on
basically
matching
pretty
closely
even
patchy
releases.
So
whenever
committee's
much
release
is
released,
kubernetes
is
going
to
be
released
too.
B
Yeah
yeah,
I
mean
patches,
wouldn't
always
necessarily
like
we.
We
may
decide
to
patch
kubereum
in
response
to
a
release
bug
on
dot,
oh,
which
I
think
would
actually
be
quite
beneficial
for
kubityama's
project,
because
we've
had
several
dotto
bug,
bug
releases
where
things
were
overseen
and
then
not.
Every
kubernetes
patch
release
may
warrant
a
kubernetes,
but.
C
Yeah,
that
is
correct,
but
probably
it's
going
to
cause
much
more
confusion
amongst
users
to
have
different
yeah
release
numbers
and
from
like
that
standpoint,
we're
probably
going
to
end
up
just
patching
cuba
dm
and
releasing
it
anyways.
C
Yeah
there
is
a
document
by
lumir
somewhere
in
google
docs,
and
you
can
actually
suggest
some
ideas
there,
because
nothing
is
yet
final.
B
E
B
Well,
yeah
not
to
get
on
too
long
over
a
rant
about
cuba,
damn
governance,
but
that's
what's
happening
in
component
config
land
with
arguably
the
biggest
user
component
config
at
the
moment
and
then
yeah.
I
think.
B
Yeah
to
that
point,
the.
B
Oh,
oh
yeah,
yeah,
they're,
kublet
flags,
that's
right!
There's
like
run
once
in
there
and
all
that
if
you
were
either
working
with
sabita
or
well,
I
mean
savita.
Do
you
wanna?
If
you're
able
do
you
wanna
talk
about
your
work
a
little
bit
here.
E
So
I
have
been
looking
through
all
the
flags
thanks
to
mike
and
the
who
gave
me
an
overview
and
walkthrough
of
all
the
code
and
oh,
my
cool
put
additional
flags
in
there,
so
I
compiled
all
of
them.
I
categorized
them
and
I
created
an
issue.
I'm
not
sure
if
we
want
to
tackle
everything
all
together,
but
I
thought
it's
good
to
have
all
of
them
in
one
place.
A
Yeah
thanks
thanks
very
much
for
putting
that
together.
It
looks
really
great.
It's
gonna
be
really
helpful
to
track.
You
know
all
those
in
one
place
for
the
cubelet
as
opposed
to
spread
out,
and
I
think
you
know
we
like
we
talked
about.
We
can
start
with
just
moving
one
of
them
to
make
sure
we've
got
the
process
down
and
then
we
can
just
get
it
rolling.
E
Sure
so
I'm
gonna
follow
the
example.
Pr
that
you
have
you,
you
have
on
the
documentorship
document
and
I
will
also
document
things
along
the
way
I
didn't
notice
some
of
the
files,
the
file
location,
paths
changed
and
it
has
been
updated
in
one
of
the
documents.
E
If
there
are
anyone,
if
there's
anyone
who
want
to
help
join,
they
are
welcome
because
there
are
a
lot
of
flags.
A
Awesome
great,
so
if
everyone
anyone
wants
to
help
you
can
reach
out
to
cevita
or
me
on
slack
and
we'll
hook,
you
up.
D
A
Yeah,
it's
a
great
question,
so
the
the
number
one
thing
is
is,
of
course,
just
getting
the
sort
of
existing
options
exposed
in
the
component
config
api,
so
that
we
can
move
away
from
the
flags
that
are
currently
used
to
set
those.
A
C
So
a
little
comment
on
the
object,
meta
stuff
at
cube:
adm.
We
decided
not
to
basically
go
forward
with
it
just
for
now,
simply
because
it's
actually
needed
only
for
customize
at
the
moment
at
least
and
customize
is
basically
not
ideal,
and
probably
it
should
actually
be
the
one
to
change
or
basically
think
of
something
else.
So,
for
example,
kind
actually
dropped
my
support
and
they
don't
need
object
meta.
As
of
today,.
A
Interesting,
so,
okay,
so
I
I
think
phil,
which
rock
also
is
trying
to
set
up
a
meeting
for
six
cli.
It
was
on
maybe
friday
this
week
and
these
were
some
of
the
agenda
items
and
he
had
some
other
ideas
around
how
to
do.
You
know
big
transformation
and
generation
when
I
talked
to
him
at
kubecon
so
joe.
That
might
be
a
good
good
thing
to
look
at
I'll
see
if
I
can
find
the
email
and
get
your
way
yeah.
B
I
was
fumbling,
but
I
finally
did
find
the
the
link
to
savita's
excellent
kublet
flag
issue.
So
if
you
are
looking
for
something
a
model,
you
work
around
for
something
like
the
controller
manager
or
want
to
get
involved
there
or
just
learn
about
a
lot
of
esoteric
kublet
flags
and
kind
of
understand.
What
the
context
and
like
properties
of
those
flags
are
go
ahead
and
take
a
look
at
her
issue.
It's
really
well
put
together.
A
Cool
all
right
thanks,
everyone
have
a
great
day
happy
new
year
and
see
you
in
the
office
hours
or
next
week,
cheers.