►
From YouTube: WG Component Standard 20190709
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
So,
okay,
welcome
to
the
july.
9Th
working
group
component
standard
meeting
seems
like
we
have
a
few
agenda
items
today.
So
let's
just
jump
into
the
notes
here.
A
So
the
first
thing
on
the
list
is
ross's
component:
config
validation
and
conversion
migration
stuff.
So
there's
ross
here.
B
Yep,
so
this
actually
was
raised
as
a
question
due
to
like
in
cube
adm.
We
are
actually
trying
to
migrate
away
from
using
the
internal
types
for
component
configs,
and
this
is
actually
causing
us
some
issues.
So
we
lose
the
ability
to
verify
and
migrate
component
conflicts,
and
we
are
actually
looking
forward
to
figure
out
what
to
do.
B
And
currently
we
have
like
a
couple
of
options.
The
first
option
is
to
move
the
mic
just
for
the
component:
config
smoothie,
verify
and
conversion
code
inside
the
public
types
so,
for
example,
have
a
conversion
that's
supposed
to
convert
all
of
the
legacy
component
configs
for
certain
api
groups
into
the
latest
version
and
also
provide
some
verify
methods
to
verify
the
latest
version
of
this
component
config.
B
This
is
option.
One
and
option
two
is
to
have
an
additional
command
line,
either
sub
commands
or
options
that
are
going
to
be
easily
embeddable
inside
the
components,
and
these
are
going
to
provide
to
verify
and
migrate
functionality
and
probably
some
other
options
that
I
I
didn't
think
of.
A
B
Yes,
those
are
the
the
component
configs.
We
want
to
upgrade
to
always
the
latest
version.
That's
because
you
can
have
a
component.
For
example,
you
can
have
the
cube
proxy,
which
today
has
only
v1
alpha
1
but
like
in
the
next
version.
It
can
have
v1
alpha
1
and
v1
alpha
2.,
and
we
need
to
upgrade
at
some
point
to
v1
alpha
2.,
because
if
we
don't
do
that.
B
Yeah,
that's
probably
going
to
be
the
same
for
like
from
alpha
to
beta
or
between
beta
versions.
If
we
don't
do
upgrade
at
some
point
by
the
like
cluster
provisioning
tool,
we're
going
to
lose
the
ability
to
have
a
upgrade
that
same.
C
Does
that
make
sense
that
makes
sense,
but
and
the
reason
why
one
of
the
like
simple
cases
why
we
would
need
this
is
because
of
like
if
you
change
the
defaults
and
the
user
has
not
overridden
the
default
in,
say
alpha,
2
right
and
then
in
beta
1.
We
change
like
requests
per
second
to
move
like
150,
then
you
would
want
them
in
their
new.
You
know
cluster
deployment
to
receive
the
new
default.
E
This
from
a
different
angle,
so
in
kubernetes
there's
a
generic
problem
where
we
don't
have
tooling
to
migrate
user
manifests.
So
if
somebody
creates
a
configuration
for
cube
proxy,
it
doesn't
matter
if
it's
alpha
or
beta
if
something
changes
in
the
next
release
and
they
want
to
migrate,
we
don't
have
tooling
for
that,
so
they
have
to
edit
manually
and
basically,
what
ross
is
asking
is.
E
Should
we
have
this?
You
know
as
a
standard
command
for
q
proxy,
like
q
proxy
migrate.
My
config,
please.
B
Yes,
we
can
actually
even
extract
it
further
and
provided
is
just
a
simple
function
inside
the
component
base.
A
Right
and
so
we're,
I
guess
another
interesting
thing
is
so
there's
a
couple
questions.
One
is
kind
of
like
how
much
should
keep
adm
be
trying
to
do
for
people,
and
I
have
to
go
look
at
it's
been
a
while,
since
I
looked
at
cubadm
and
and
kind
of
where
it's
at
so
my
judgment
might
not
be
the
best
on
that,
but,
like
historically
speaking,
you
know
the
conversion.
Logic
has
been
a
feature
of
the
component.
That's
you
know
providing
the
public
config
api.
A
So
if
there
are
conversions
available,
say
qubit
has
v1
beta,
1
and
v1
beta
2.
You
should
be
able
to
hand
cube
a
v1
beta,
1
or
v1
beta2,
and
so
I
guess
the
question
is
like.
B
C
But
it's
a
little
bit
because
kubernetes
has
to
decide
how
the
object
gets
stored
and
persisted
across
across
cluster
upgrades,
which
means
that
we
need
to
have
pre-flight
checks
beforehand,
where
kuberdam's
like
whoa,
I'm
not
even
going
to
touch
that
config
file,
because
the
kubelet
doesn't
work
with
that
thing
anymore.
C
A
I
mean
the
tricky
thing
is
especially
like
say
someone's
running
like
get
ops
with
cube
admin
and
they
write
so
they
write
a
file.
That's
in
like
the
oldest
version
and
say
even
you
like,
even
if
the
cubelet
was
just
like
the
api
server
automatically
up
converting
that
version
internally
and
say
it
say
it
like
overwrites,
whatever
file
they
provide
on
disk
to
be
the
latest
version.
How
do
you
propagate
that
backup
through
to
cube
adm
or
to
the
like,
get
repo
that
someone's
running
get
offset?
I.
C
I
would
imagine
that
we
would
so
if
we
need
to
keep
the
my
suggestion.
Yesterday
is:
if
we
keep
the
conversion
logic
in
the
components
because
of
its
dependence
on
the
internal
type,
then
we
should
have
a
standard
cli
that
is
importable
from
components
from
the
component
base.
Just.
A
Right
so
like
I
guess,
the
question
is
kind
of
how
to
how
to
provide
that
functionality.
You
know
one
way
to
do
it
is
like
the
I
guess.
The
first
option
right,
which
was
just
actually
vendor
the
internal
types
too
and
like
say,
look,
don't
use
the
internal
types
directly,
but
they're
part
of
this
library
for
conversion
is
that
right.
B
C
B
Provide
conversion
functions
from
like
from
any
of
the
older
types
into
the
newer.
The
newest
version.
A
Yeah,
I
guess
either
of
those
would
be
fine,
the
automate,
the
generating
two
versions,
all
work
through
the
internal
types.
Still,
I
think
great
so
yeah
they
might
have
to
there
if
we
want
the
generated
ones.
A
B
A
Yeah
is
that
okay,
so
that
one?
So
I
guess
I
guess
the
the
trade-offs
are
like
for
option
one.
It
requires
you
to
vendor
like
the
whole
scheme
and
for
option
two.
It
requires
you
to
actually
have
the
component
binary
available.
A
A
B
So
for
kubernetes,
like
it,
doesn't
matter
too
much
between
option
one
and
option
two,
but
some
of
the
other
tools
actually
don't
render
in
any
of
the
public
types
they
simply
operate
on
yaml
strings.
E
And
also,
if
you,
if
we're,
if
we're
using,
basically
you
know
the
control
plane
in
static
ports,
it
means
that
you're
downloading
an
image
you're,
not
downloading
a
binary.
So
you
have
to
execute
the
conversion
inside
the
image.
B
Yes,
so
we
have
to
like
spin
up
a
simple
container,
but
we
have
the
like
access
to
the
cri
tooling.
We
can
spin
up
one
of
something
to
just
convert
the
yaml
file
or
validate
it.
B
Well,
currently,
for
cube
proxy
or
and
stuff
that
basically
run
as
a
demon
set.
We
only
have
like
images.
We
don't
have
the
binaries
itself,
but
for
the
cubelet
itself
we
can
actually
execute
the
binary
directly.
A
B
A
E
E
A
Right,
typically,
what
we've
said
is
look.
You
need
to
go,
read
the
release,
notes
and
you
need
to
write
a
view
on
beta2
config
and
there's
a
window
where
you
can
do
that,
my
migration
manually
and
that
that
technically
works
it's
not
very
complicated.
A
It
just
requires
people
to
do
a
manual
thing,
and
so
you
know
now
the
question
is
like:
can
we
actually
automate
that
if
we
have
conversions
technically,
we
can,
and
it's
just
a
question
of
you
know:
how
do
we
do
that?
How
do
we
expose
that
to
our
tooling.
E
B
A
And
so
I
guess
yeah
another
another
thing
we're
asking:
is
you
know
how
much?
Where
should
the
burden
be
like?
Should
it
be
on
cube
adm
to
go
figure
out
what
these
conversions
should
be?
You
know
on
the
behalf
of
cuba,
adm's
users
and
then
just
do
like
public
type.
Conversions
inside
of
cube,
adm
or
you
know,
should
the
components
be
providing
that
functionality
for
anybody
to
use.
A
A
A
A
Or
we
could
say
actually
components
are
responsible
for
providing
the
automated
conversions
between
their
types
and
then
qvam
would
just
consume
that,
and
I
think
the
latter
is
is
like
the
better
way
to
go,
because
it
doesn't
with
the
burden
on
cuba
adm
to
figure
all.
C
C
Same
functionality,
so
the
logic
is
that
would
be
in
component
based
and
then
like
vendored
into
kuberdiam
would
be
like.
Oh
here's,
the
here's,
the
preferred
gvk.
A
Well,
it
would
probably
be
in
it
would
probably
be
in
each
components
like
api
staging
repo
in.
A
C
Would
there
be
a
function
like
convert
v1
alpha,
one
two
preferred.
A
Yeah,
I
I
have
to
go,
look
and
see
once
you
have
like
a
scheme
registered
with
a
bunch
of
versions
on
it.
I
think
there's
a
way
to
say
you
can.
C
C
C
C
A
So
I
think
the
I
don't
I
mean
you:
if
you
go
to
the
internal
type,
you
should
be
able
to
go
out
to
any
other
external
type.
B
Types,
the
code
generator
for
the
conversion
routines
is
like
it's
able
to
be
pointed
to
a
version
that's
going
to
be
used
to
convert
to.
B
So,
if
that's
not
the
internal
tag,
but
the
latest
version,
it's
probably
going
to
work
well
enough,
and
I
think
that
this
is
probably
like
implementing
this
is
going
to
be
happening
on
a
per
component
base.
So
people
are
going
to
probably
backlash
on
this.
C
B
Are
actually
asking
them
to
expose
their
internal
tabs,
because
that
way
they
may
lose
the
ability
to
like
do
whatever
they
want
with
the
internal
types.
A
B
Not
every
pair,
probably
we
should
do
just
the
latest,
like
stable,
config
latest
released
conflict
and
has
to
be
able
to
go
backwards
so
yeah,
so
it's
yeah.
So
basically,
if
we
have
v1
v2
and
v3,
everything
is
going
to
be
convertible
to
v3.
So,
for
example,
if
you
want
to
convert
from
v1
to
v2,
you
just
need
to
convert
from
v1
to
v3
and
then
from
v3
to
v2.
C
C
You
would
need
different
versions
of
the
library
if
you
didn't
want
to
maintain
all
of
the
independent
functions
in
order
to
do
a
linear
one
like
as
a
user
right
like,
I
would
need
to
have
an
older
version
of
like
the
coupe
proxy
binary
or
something
that's
fendering.
An
older
version
of
the
library.
C
C
A
C
A
C
Yeah,
I
that
sounds
like
really
hard
and
it's
gonna
have
to
go
through
like
months
of
api
machinery
or
review.
A
A
Right
yeah,
once
it's
all
hidden,
hidden
behind
the
binary
interface
it's
protected,
so.
C
A
Maybe
I
I
don't
know
if
it's
that
big
a
deal
to
have
it
exposed
and
just
like
well
documented
that
it's
an
internal
api,
you
can't,
for
example,
you
can't
provide
the
internal
type
to
cube
proxy
as
a
config
file.
It
won't
accept
it
right
so
yeah.
C
C
A
C
So
we're
at
the
hour
here
sorry
sorry
mike,
but
do
we
want
to
give
george
a
chance
to
shock?
Oh,
it's
george
game.
C
A
F
D
D
A
I
don't
know
george,
if
you
wanted
to
talk
about
that.
Pr
at
all
money
is
relatively
quickly,
so
real
quick.
Are
we
going
to
conflict
with
cluster
lifecycle.
C
No,
this
is
cluster
add-ons
right
now,
which
I
should
be
joining,
but
again
sorry
jorge.
I
pronounced
your
name
wrong
again.
C
My
bad
and
yeah
is
anyone
here
intending
to
join
the
cluster
add-ons
call.
F
We
can't
start
the
cluster
add-ons
course.
I
was
actually
wondering
whether
this
running
over
prevents
the
cluster
allen
school
from
starting,
but
you
guys
wrap
it.
A
F
C
Yeah
all
right,
let's
call
it
this
way,
yeah
quick.
Does
anyone
have
any
qualms
about
making
next
monday?
This
is
basically
the
same
meeting
time
that
was
chosen
for
this
week.
Just
we
have
to
push
it
back
a
week.
C
Okay,
I
wanted
to
make
sure
that
you
could
join
that
mike,
because
I
think
you
were
not
available
for
this
monday.
Yeah
cool
I'll
send
out
a
mailing
list
to
invite
for
that.