►
From YouTube: kubeadm office hours 2020-09-30
A
A
A
Okay,
I
don't
see
any
meeting
participants
announcements,
I
don't
have
anything.
Does
anybody
else
have
anything
here.
A
A
So
basically,
if
you
haven't
looked,
there
is
already
please
have
a
look.
Comments
are
appreciated
the
only
comments
that
are
present
currently
by
jordan.
I
believe
he's
questioning
some
of
the
decisions
around
when
we
should
remove
the
taints.
A
A
From
my
perspective,
we
can
separate
the
whole
process
into
two
stages,
but
jordan
is
saying
that
we
have.
We
should
have
more
stages,
so
please
have
a
look
at
the
whole
discussion.
The
whole
cap,
I
think
it's
actionable
for
120
in
terms
of
stage
one
and
I
can
prepare
the
cap.
B
A
A
I
would
also
try
to
pink
jason.
Does
anybody
else
have
comments
about
the
cap.
A
Okay,
so
I
guess
I'm
going
to
leave
today
and
tomorrow,
maybe
as
the
final
days
for
the
draft
to
exist
and
after
that,
I'm
going
to
go
for
the
kep
pr
itself.
A
And
I
guess
we
can
discuss
more
on
the
kpr.
But
it
has
to
merge
as
implementable
before
the
6th
of
october.
A
So
this
is
some.
The
next
topic
is
some
good
news
that
we
during
the
planning
session,
we
proposed
some
deprecations
and
graduations
in
cuba,
dm
mostly
around
our
alpha
subcommands
and
actually
the
work
around.
This
is
already
complete.
We
managed
to
finish
most
of
this
in
a
couple
of
weeks,
which
is
great.
A
I
have
some
remaining
items
to
update
the
community's
website
documentation
around
some
of
these
commands,
but
that's
pretty
much
it.
If
you
want
to
look
at
what
we
changed,
we
you
can
go
back
into
the
agenda.
Look
at
the
planning
items
for
deprecation
removals
and
also
graduations.
A
So
this
this
is
a
recent
issue
that
was
locked
by
a
user,
this
angus
so
he's
basically
questioning.
Why
are
we
downloading
the
cube
proxy
configuration
on
join,
and
I
really
don't
have
a
good
answer
for
that
other
than
the
fact
that
we
store
our
corporate
config
inside
the
question
configuration
for
corporate
and
q
proxy?
A
But
while
the
corporate
configuration
is
used
so
that
we
can
write
it
for
the
joining
node
on
disk,
the
q
proxy
configuration
is
not
used
at
all,
because
the
only
purpose
of
this
configuration
is
to
feed
it
in
the
demon
set
that
you
know
the
instance
of
the
demos
it
already
has
the
configuration.
So
it's
not
not
really
needed
on
the
node
and
the
question
here
for
the
group
is:
should
we
redesign
this?
Should
we
stop
downloading
the
q
proxy
configuration
completely.
C
The
problem
here
is
that
this
is
a
little
bit
indistinguishable
from
our
site
because,
like
the
ta
api
is
just
download
configuration
from
the
cluster-
and
it
already
has
quite
a
few
parameters
so
adding
an
additional
parameter.
Whether
this
is
a
join
or
not,
please
making
it
a
little
bit
heavy
and
like
it
also
should
not
make
any
problems
in
not
finding
the
prox
configuration
when,
for
example,
the
user
opted
out
of
proxy.
C
C
A
A
problem
here
yeah
I
so
basically
from
the
prior
slack
discussion
that
spawned
this
particular
ticket
he
mentioned
that
he
started
testing
it
on
some
very
old
version
111
or
something
like
that.
I
also
cannot
con
confirm
that
we
have
problems
in
recent
versions
around
missing
our
back
or
the
missing
configuration
itself.
So
if
the
user
skips
q
proxy
or
if
the
booster
token
doesn't
have
privileges
to
access
the
q
proxy
configuration,
then
there
shouldn't
be
any
problem.
A
So
I
agree
with
you
rossi
that
maybe
we
shouldn't
refactor
this,
because
it's
a
complexity.
I
had
a
look
at
the
code.
Yesterday
we
for
q
proxy,
we
have
a
boolean
flag
that
issued
warm
for
missing,
config
or
unauthorized
graphic,
but
I
think
this
is
already
we
are
already
handling
this
properly.
I
think
the
the
only
question
is
like
I
mean
it's
part
of
the
question
like.
Why
are
you
granting
the
booster
token
access
to
this
configmap?
If
the
note
doesn't
need
the
configuration
at
all?
A
B
B
So,
in
my
opinion,
we
we
should
take
a
look
and
at
least
keep
the
the
issue
around
and
see
if
we
find
a
way
to
make
this
easy
to
implement
because
yeah,
if
you
are
ready,
as
you
are
saying
we,
we
don't
need
this
when
when
we
do
join,
probably
it
was
introduced
when
doing
some
refactor
around
the
conflict
about
management,
but
in
theory
we
should
get
rid
of
these
dependencies,
especially
if
we
look
at
the
work
that
we
have
to
do
for
adults.
B
C
By
the
way,
I
think
that
if
we
actually
just
remove
these
exercises
from
the
bootstrap
token,
we
can,
it
should
probably
just
work,
because
the
code
that
is
in
the
component
config,
like
downloading
code
checks
for
either
missing,
like
present
error
or
forbidden
error,
and
the
forbidden
is
just
because
most
of
the
code
here
in
cuba
then
which
actually
handles
creating
config
maps.
C
A
Ideally,
I
think
we
should
make
the
component
config
download
called
to
accept
like,
for
example,
a
function
that
is
new,
which
means
that
okay,
this
component
exists
in
the
cluster,
maybe,
but
we
shouldn't
ever
download
it.
Something
like
that,
and
we
can
also
remove
the
hardback
at
this
point,
because
it's
not
needed.
B
Future,
however,
the
idea
of
checking
what
happened
if
we
remove
their
back
rule
is
a
good
one.
For
me,.
A
Yeah,
it's
it's
going
to
work
like
ross
is
saying
because
the
the
bootstrap
token
is
going
to
try
to
download
the
config,
but
it's
going
to
just
throw
a
warning
and
that's
it.
A
Okay,
let's,
let's
leave
this
open
for
now
so
another.
This
is
yet
another
instance
of
somebody
requesting
that
we
move
the
cri
socket
annotation
from
the
upward
config
phase
of
kubernetes.
The
original
issue
was.
A
However,
I
made
a
comment
here
that
maybe
we
should
move
the
ci
circuit
rotation,
either
to
the
couplet
start
phase
or
the
corporate
finalized
phase
to
be
consistent
with
kubernetes
and
joint,
because
qb
join
uses,
the
couplet
phase,
at
least
on
yeah.
It
uses
the
couplet
phase
to
annotate
the
cri
circuit.
However,
on
bootstrap
control
plane
nodes,
we
cannot
do
this
easily
in
the
corporate
start
phase,
because
the
kubelet
start
phase
is
too
early
and
the
node
object
doesn't
exist
yet
so
we
have
to
basically
walk
in
this
phase.
A
A
C
Actually,
I
was
always
against
splitting
this
out
in
a
different
phase,
simply
because,
like
what
I'm
thinking
here,
is
that
probably
in
some
time
in
the
future,
we're
probably
going
to
read
this
not
from
the
annotation
but
from
the
cube
that
convict
and
currently
we're
sticking
with
the
annotation,
because
the
fields
are
not
inside
of
the
cubelet
component
config.
C
But
at
the
point
in
which
these
fields
are
introduced
there,
then
probably
this
is
going
to
still
be
the
right
place,
because
upload
config
is
going
to
upload
the
cubelet
config,
its
config
map,
so
like
not
splitting
it
in
a
different
phase,
is
going
to
keep
things
simple
and
the
same,
even
when
a
change
to
the
kubrick
conflict
actually
occurs
so
probably
before
deciding
on
moving
over
to
a
new
subface.
C
On
our
side,
I
don't
know
actually,
but
I
do
think
that
he
is
actually
working
on.
Well,
not
he
him
personally,
but
I
think
that
some
of
the
folks
around
work
group
component
standards
are
working
on
introducing
like
new
fields
in
the
component
config,
and
they
are
doing
this
like
for
a
few
fields
every
cycle.
C
So
I
don't
know
like
they
have
a
pretty
long
list
of
command
line
parameters
for
the
cubelet
that
they
want
to
migrate.
And
it's
probably
just
a
matter
of
time.
A
I
actually
remember
seeing
that
issue
for
that
series
circuit,
couplet.
A
So,
okay,
so
if
we
have
the
the
field,
so
currently
the
field
is
missing
from
the
config.
It's
only
present
present
on
the
coi.
If
we
have
the
field
inside
the
config,
then
the
upward
config
phase
is
actually
the
right
place
for
that.
B
B
I
I'm
not
sure
I
think
that
we
should
ask
to
rafael
to
come
to
a
meeting
and
discuss
the
issue
again
and,
in
the
meantime,
collect
the
information
from
michael
about
how
this
working
is
progressing
because
basically
he's
asking
to
change
the
the
init
phase
in
order
to
suppress
to
support
an
upgrade
scenario
which
is
kind
of
confusing
to
me.
So
I
would
like
to
better
understand
that
they
need
that.
The
use
case.
A
Yeah,
you
know
upgrades
aside
what
I
think
he's
trying
to
do,
and
others
may
do
as
well
like
the
user
reporting
the
same
problem
yesterday
is
they
want
to
update
the
corporate
configuration
in
the
coaster
and
the
annotation
of
the
cri
socket?
A
I
I
think
they
don't
want
to
this
to
happen
in
parallel
to
the
action
that
they
want
to
do,
which
is
updating
the
kubrick
conflict.
B
Yeah,
I
I
got,
I
got
your
point,
but
but
if
we
look
at
kubernetes
at
cougar
mean
in
it
is
is
not
meant
to
upgrade.
It's
just
a
case
that
that
upgrades.
B
B
A
B
They
are
a
toolbox
for
doing
anything
different
way,
not
not
for
doing
change
the
cluster,
so
this
was
at
least
in
my
mind.
The
idea
of
phases
is
just
to
provide
a
breakdown
of
what
in
it
does
and-
and
so
this
is
not
another
use
case
covered
by
this
command
and
I'm
and
we
should
be
careful
to
extend
the
the
scope
but
yeah.
B
My
suggestion
is
to
understand
what
what
is
the
work
to
talk
with
michael
and
talk
with
rafael,
so.
A
I'm
going
to
keep
this
stuff
open
and
also
other
comments
from
rossi
that
eventually,
this
will
be
in
fact
applicable
to
the
same
phase,
because
we
might
remove
one
of
these
crystals
completely.
A
B
Last
time,
I
think
it
is
important
to
start
with
to
start
working
on
on
the
next
kubernetes
roadmap,
so
I
was
thinking
on
how
to
get
this
with
this.
These
this
work
started.
So
the
idea
that
I
had
is
just
to
open
a
a
kind
of
umbrella
issue
where
we
link
the
the
issue
for
each
the
argument
that
that
could
be
part
of
the
roadmap.
So
I
I
created
this
umbrella
issue
and
added
three
small
topic.
One
is
the
idea
of
the
kubernetes
library.
The
other
is
the
idea
of
supporting.
B
A
Because,
essentially,
this
is
proposing
your
ideas
for
what
the
roadmap
should
be
and
the
rest
of
the
maintainers
have
to
agree
on.
B
That
I
I
I
don't
know
in
the
other,
in
the
other
project,
for
instance,
copy
we
are
not
doing
the
the
wrong
but
use
using
a
cap.
B
We
are
just
collecting
idea
putting
this
this
idea
in
a
markdown
document
and
and
having
issue
for
each
topic.
That
then
may
be
a
topic
that
deserves
a
cat
but
yeah.
This
is
the
approach
that
I
see
so
having
a
cap,
for
the
roadmap
is
kind
of
strange
because,
but
I
I
don't
know,
I
I'm
proposing
this
approach
using
issues
because,
in
my
opinion,
makes
sense,
but
I'm
I'm
open
to
this
card.
If
you
prefer
to
having
a
discussion
in
a
google
document,
could
make
sense,
I'm
open
to.
A
Yes,
I
would
have
preferred
to
have
the
discussion
in
a
google
doc.
First,
you
know.
Cap
is
not
a
good
idea.
If
we
have
a
google
doc,
where
we
enumerate
all
the
tasks
that
we
want
to
do.
We
can
discuss
on
the
google
doc
and
after
that
we
could
have
opened
the
issues
if
people
agree
on
the
priority
and
things
like
that.
A
All
right,
but
you
know
after
we
establish
the
priorities
for
the
items,
we
can
then
create
the
separate
google
docs.
My
point
is
that
we
created
items
that
are
part
of
a
roadmap
that,
and
people
have
not
agreed
yet
on
the
priority
of
these
items,
even
if
they
want
to
see
the
clarity
of
approaches
for
githubs
in
kubernetes.
B
I
I
don't
agree
with
this
statement:
I'm
open
an
issue.
The
issue
can
be
closed.
The
people
can
can
vote
against.
B
But
if
we
don't
start
a
discussion
in
a
public
place,
how
all
the
people
can
express
their
opinion,
so
opening
an
issue
does
not
means
that
people
agree
on
on
on
this
action.
He's
just
proposing
an
idea
and-
and
if
people
does
not
agree,
can
they
simply
have
to
comment
and
then
the
issue
will
be
closed.
A
B
I
I
think
that,
at
least
in
my
mind
our
roadmap
is
something
is,
let
me
say,
a
desired
state
that
we
wanted
to
achieve
in
future,
but
it
the
roadmap
is,
is
not
the
implementation
plan.
So
when
defining
the
roadmap,
we
are
not
defining
the
action
to
get
there.
We
are
just
defining.
We
want
to
get
there.
B
B
D
So
I
would
volunteer
to
help
write
that
draft
account
for
that
cubanium
library
and
then
we
can
then
decide
when
we
want
to
do
that,
and
I
think
we've
done
some
of
that
for
the
aws
project,
where
I've
written
a
kept
long
in
advance,
and
then
we've
decided
when
we're
going
to
do
that
and
we've
not
actually
acted
on
it
immediately.
A
A
B
B
B
B
A
Yeah,
a
google
doc
also
could
have
been
a
good
idea
because
everybody
can
edit
at
the
same
time,
this
roadmap
document
and
we
can
swap
priorities,
add
more
items
and
here
in
the
comments
everybody
has
to
post
their
copy
idea
of
the
roadmap.
So.
A
I
personally
have
you
know
I
the
way
I
look
at
the
kubernetes
project.
I
see
I
try
to
solve
one
problem
at
a
time.
There
are
a
lot
of
technical
depth
in
kubernetes
and
today
a
lot
of
problems.
A
I
try
to
solve
them
one
at
a
time,
and
I
know
that
the
you
know,
for
instance,
the
cubed
m
library,
is
something
that
we
want,
but
I
have
it.
You
know
way
down
the
line
in
my
perspective,
so
from
my
again
from
my
perspective,
I
I
would
put
some
refactors
before
the
kubernetes
library
and
now
I
guess
the
question
is:
how
do
I?
How
do
I
coordinate
that
in
the
ticket?
Should
I
just
see
my
view
of
the
roadmap,
or
should
it
just
go
in
a
google.
B
B
So
let
me
clarify
a
thing:
when
you
talk
about
refactors,
they
are
smaller,
refactor,
bigger
factor
how
they
fit
with
the
the
the
library
they.
So
you
it's
up
to
you.
You
can
open
an
issue
and
which
is
refactors
or
many
issues
which
are
refactors
and
add
them
to
the
roadmap,
and
then
we
will
decide
if
these
are
before
or
after
the
library.
A
Yeah,
I
I
see
a
zero
point.
We
should
definitely
consider
what
is
part
of
the
library
factor
and
what
is
generic
refactor
bug
fixes
cleanups
and
what
has
higher
priority
in
the
library
itself.
A.
A
A
Yeah
also
because
we
spoke
about
coaster,
api
providers
and
cost
api
core
being
consumers
of
the
live
of
cube
adm
code
as
forks
for
king
cubedium.
I
would
like
to
see
a
list
of
what
usages.
B
A
I
know
that
we
had
user
requests
for
the
same
package
before
but
other
than
that.
I
really
don't
know
what
question
api
is
doing
with
the
forking
kubernetes
code.
Yeah.
A
B
First
personally:
yes,
because
the
library
unblocks,
for
instance,
the
work
for
the
operator
or
basically
cutting
down
the
technical
depth,
make
it
possible
to
have
pluggable
add-ons,
which
are
the
the
other
two
issue,
but
I
meant
irubamir
to
take
to
to
the
server
slot
and
go
through
the
backlog
together.
Try
to
do
this
cleanup
together.
A
E
B
I
had
an
idea,
a
possible
idea
in
how
to
unblock
these.
I
have
to
write
down
something
in
the
issue.
The
idea
is:
is
a
little
bit
didn't
different
to
be
discussing
the
past,
but
yeah?
I
I
would
like
to
a
blog
to
unblock
the
the
the
situation
on
addons,
so
I'm
trying
to
to
keep
the
initiative
on
on
this
topic.
E
Okay,
hi
friends,
it's
lee
thanks
for
pushing
this
conversation
forward,
just
wanted
to
notify
everyone
here
that
tomorrow,
justin
will
be
doing
a
kickoff
and
live
coding
session
for
the
add-ons
integration
in
cops.
It's
at
9
00
a.m.
Eastern
time.
E
Tomorrow,
the
the
design
overlap-
probably
I
mean
it's
good
if
we
can
kind
of
keep
some
uniformity.
B
B
Yeah
yeah,
I
have
an.
Unfortunately
I
have
an
overlapping
meeting.
It
would
be
great
if
justin
record
the
session
and
and
and
then
publish
the
the
video
in
the
in
the
channel.
A
A
I
created
a
basically
an
api
package
with
multiple
versions
and
I
created
some
logic
to
up
convert
any
given
type
to
a
future
type
in
the
next
version,
and
everything
is
consumable
from
the
outside.
It
does
not
depend
on
api
machinery,
it's
just
an
experiment,
but
if
you
vendor
such
a
package
in
high-level
tools
like
question
api
or
cops
or
anything
else,
you
can
potentially.
A
Not
depend
on
the
conversions
of
the
component
itself.
It
actually
ended
up
being
super
simple.
It's
I
started
questioning
like
the
whole
api
machinery
scheme,
codex,
conversions
and
so
on.
I
think
it's
over
engineered,
but
I
don't
have
anything
to
show
right
now.
I
I
also
should
prepare
some
slides,
maybe
to
showcase
the
idea,
but
I
also
looked
at
how
much
effort
it
is
to
refactor
cuba
dm
to
use
such
a
thing,
and
it's
a
lot.
A
But
then
again,
if
you
have
a
copy
of
this
in
the
cube,
idm
repo,
you
can
copy
the
public
types
only
you
can
apply.
This
new
method
of
you
know
managing
the
scheme
with
defaulting,
valid
validation,
and
this
means
that
you
have
to
fork
constants
and
some
logic
for
validation
and
so
on.
A
A
I
personally
don't
like
this
idea.
I
think
that
we
should
move
kubernetes
first
and
then
refactor
this.
If
we
want
to
but
yeah
it's
maybe
I
should
just
create
some
slides
in
a
google
doc
and
show
what
what
I
have
conceptually.
C
Yeah
but
like
what
happens,
if
you
have
like
fields
which
were
removed
from
the
like
the
newer
configuration,
so
you
cannot
actually
do
a
trivial
convert.
A
If
so,
if
I
have
v1
beta3,
for
instance,
and
the
current
version,
I'm
working
with
this
v1p2,
if
you
want
beta3
removes
fields,
this
means
that
my
conversion
logic
from
the
two
functions,
the
two
kinds
that
I'm
converting
should
just
basically
drop
these
fields,
and
then
consumers
of
the
v1
beta
3
type
should
not
care
about
the
fields
that
I
don't
see.
A
problem.
E
With
examples
of
this
in
the
api
server,
these
things
are
are
saved
in
the
down
converted
type.
That's
missing
the
fields
through
object,
meta
via
annotations,.
E
If
we,
you
know
revisit
the
object
meta
cap
for
that
phoenix
blue
was
working
on
joe
crc,
then
I
don't
know
yeah
phoenix
blue.
He
was
working
on
proposing
that
our
component
configs
have
object
meta
for
a
couple
reasons,
and
this
would
be
one
of
those
I'm
not
overly
attached
as
well
to
the
internal
type.
E
A
Well,
I
personally
think
that
that
down
conversion
is
not
needed
at
all
and
because
I
can
give
an
example.
If
you
have
version
two
on
the
disk
and
you
feed
it
to
the
application
that
supports
this
version
of
your
version,
you
can
decide
what
you
should
use
in
the
application
itself.
You
can
say:
okay,
I'm
going
to
use
the
same
version
in
that
case,
there's
no
conversion,
there's
no
dark
collection.
A
If
you
decide
to
use
v1
beta3
in
your
application,
this
means
that
you
take
the
version
2
and
convert
it
to
version
3
use
version
3
in
your
code
in
your
logic,
but
if
the
fact
that
fields
have
dropped,
you
have
to
go
with
it.
Just
you
stop
stop
using
this
functionality
because
you're
about
the
new
version
of
the
api
and
the
round
trip
to
the
old
version.
I
I
don't
think
it's
even
you
why?
Why
is
it.
E
I
mean
it's:
it
just
assumes
that
the
user
of
component
config,
you
know,
stops
at
somebody
who's
manually,
maintaining
files,
but
as
soon
as
you
have
solutions
that
are
building
on
top
of
these
apis,
it's
hard
to
make
assumptions
about
what
people
will
do
with
upgrading
and
downgrading
kubernetes
version
and
the
associated.
E
You
know
configurations
for
those
components,
so
api
engineering
has
the
ability
to
preserve
fields,
and
I
would
be
fine
having
object
mana
on
all
of
the
component
config
objects.
E
If
we
wanted
to
get
rid
of
the
internal
types,
then
we
could
still
do
those
kinds
of
things
and
we
have
the
benefit
of
serializing
but
yeah.
This
is
you
know
getting
into
component
config
discussion.
I
do
like
certainly
empathize
with
your
assessment
that
there
are
pieces
of
this
that
are
leaky
and
over-engineered
so,
and
it's
like
super
hard
to
maintain.
A
Yeah,
I
I
guess
when
I
prepare
these
slides
for
the
document,
eventually,
I'm
going
to
explain
why
I
think
down
conversion
is
it's
out
of
scope.
I
I
don't.
I
don't
think
component
conflict
in
particular
needs
this.
C
A
Unless
you
like,
if
you
downgrade
a
component,
this
means
that
you
also
want
to
downgrade
the
config
that
is
stored
somewhere.
E
Feel
like
you
would
just
store
an
original
copy
of
the
newer
version,
but
yeah
I
again
it's
just
hard
to
make
an
assumption
about
what
people
will
do.
I
do
agree
that,
like
that,
when
you
downgrade
a
config,
you
should
be
making
a
copy
and
not
destroying
the
original,
so
that
it
makes
sense
to
me
to
yeah.
A
If
we
have
first
clear
instructions
how
to
use
a
particular
library
or
package
that
includes
this
api
mechanic
for
public
type
conversion,
you
know
if
people
follow
the
rules,
they
shouldn't
have
the
problem.
A
A
But
if
I
just
I'm
going
to
draw
my
idea
out
there,
let's
see
how
it
goes
in
terms
of
down
conversion
itself,
it's
possible,
but
it
will
introduce
the
data
loss.
If
the
new
api
drops
fields,
the
dow
conversion
itself
is
possible,
but
we
are
just
going
to
trim
some
of
the
fields.
A
So
the
round
trip
is
not
going
to
be
possible,
but
yeah.
This
is,
can
be
a
long
discussion.
B
I
want
only
to
add
that
in
copy
we
are
doing
around,
we
support
around
three
conversion
using
an
annotation
as
like
was
saying,
and
this
basically
the
reason
behind.
That
is
that
you
don't
know
the
version
of
the
client
that
can
ask
your
api,
and
we
want
to
support
this
case.
B
Let's
assume
that
I
have
two
users
referring
to
a
cluster:
one
is
using
kubernetes
version
x
and
the
other
is
using
an
older
venture.
The
person
using
our
older
version
should
read
the
the
the
the
the
configuration
and
get
it
casted,
because
it
it
calls
the
dpi
and
and
the
custom
and
the
and
it
get
back
converted.
B
A
E
Yeah,
it's
just
about
when
the
that
client
makes
a
write
back
right,
they're
not
allowed
to
write
back
over
the
same
object
if
the
object
that
they
read
from
had
to
be
down
converted
and
that's
the
trick.
You're
like
that's
allowed
when
you're
talking
to
the
api
server
because,
like
it's
assumed
that
when
objects
are
down
converted
that
the
fields
will
be
preserved
to
via
annotations.
E
E
A
A
Okay,
I'm
going
to
think
about
this
problem
as
well.
It's
I'm
trying
to
differentiate
the
whole
api
server
web
hook,
conversion
and
the
conversion
of
component
config.
I
think
we
have
differences.