►
Description
Code walkthrough on how to implement API conversion.
The notes shown in the video can be found here: https://hackmd.io/aYLvrb_jTXiwg_MnpD804w
A
Okay,
so
hello,
everyone
today
is
the
14th
of
january.
We
are
doing
a
yeah
called
through
pair
programming
on
conversion,
we're
doing
it
based
on
the
class
api
provider,
bootstrap
provider
cube
idm.
I
start
first.
I
first
start
with
some
some
context
around
how
conversions
work
and
then
we
just
implement
adding
a
new
field,
essentially
yeah.
So
let's
get
started
and
I
should
share
my
screen.
B
A
A
A
So,
for
example,
we
have
u
on
r3,
then
we
change
our
code,
our
apis,
and
we
can
do
another
four
and
then
our
crts
contain
mu
and
alpha
three
and
v1
iphone
four,
and
nowadays
we
have
view
on
alpha
three,
four
and
computer,
one
in
our
series
and
whenever
we
upgrade
api
version,
there
are
still
existing
resources
which
have
the
old
api
version
and
they
have
to
be
converted
to
the
new
one,
and
another
use
case
is,
of
course,
when
we
upgrade
to
new
version.
We
also
upgrade
our
controllers.
A
So
when
you
release,
I
don't
know
cluster
api
v1.
We
have
v1
beta
in
in
this
case.
We
had
we
on
bit1
resources
and
our
controllers
were
compiled
against
human,
better
one.
But
of
course
there
might
also
be
external
controls
which
are
still
using
v1
i4
and,
of
course,
this
shouldn't
lead
to
any
errors,
because
otherwise
everyone
would
have
to
upgrade
at
the
same
time,
which
is
probably
not
realistic.
A
So
let's
make
some
examples.
So
I'm
explaining
this
based
on
the
kubernetes
conflicts
theory
and
we
assume
we
have
and
that's
the
current
state.
Actually
we
assume
we
have
three
versions
b,
one
of
three
alpha
four
and
we
on
beta
one
there's
something
called
a
storage
version
and
a
storage
version
is
essentially
the
version
which
is
used
by
kubernetes
to
store
it
in
edcity.
So
when
you
would
look
at
at
city,
we
will
you
would
find
we
on
beta1
resources
stored
there.
A
So,
let's
go
through
some
use
cases.
First
use
case:
it's
not
super
realistic
to
see
you
that
a
user
tries
to
get
an
old
version,
but
use
this
user
tries
to
create
a
resource
default
version
so
actually
creating
a
resource
with
old
versions.
Probably
realistic,
but
getting
it
isn't
because
cube
ctl
automatically
discovers
which
version
of
api
is
there.
So
if
I
type
in
cube
ctrl
get
cubed
in
config,
it
will
just
automatically
check
which
versions
are
there
and
then
I'm
not
sure,
but
it
will.
A
It
will
definitely
pick
me
on
better
one.
I
assume
it's
because
it's
the
storage
version,
maybe
there's
also
flag
and
series
like
default
version
or
something
I
would
have
to
look
that
up.
But
what
could
happen
is
the
user
or
ci
pipeline
still
has
resources
with
the
old
version.
So
it's
realistic
that
someone
tries
to
create
an
old
resource.
A
The
api
server
knows
that
it
should
store
it
in
v1
and
beta1.
So
it
goes
to
our
controller,
because
we
in
our
crd,
we
configured
a
conversion
webhook,
which
is
our
controller.
So
the
api
server
asks
our
controller
to
upgrade
from
b1
r4
to
vue
on
bit
one
it
gets
back
to
vmware
one
resource
and
then
it
stores
certain
lcd.
A
So
that's
pretty
simple,
and
if
I
do
a
get
depending
on
the
version
I
mean,
if
I,
if
I
try
to
get
a
view
on
bit
one
version,
it
would
directly
return
better
one.
If
I
try
to
get
an
old
version,
it
would
ask
our
controller
again
to
convert
so
now.
The
next
use
case,
which
is
what
I
already
mentioned,
so
we
have
a
controller
and
especially
third-party
controllers
might
be
still
using
old
versions
and
we
could
have
a
problem
there.
A
A
I
think
it
couldn't
happen
if,
if,
if
patch
is
used
via
the
controller,
runtime
client
or
client
go,
but
if
you
call
an
update,
then
the
field
would
be
definitely
cleared
because
yeah,
the
client
just
doesn't
know
anything
about
the
field,
and
conversion
is
here
to
help
so
that
the
controller
doesn't
even
have
to
be
aware
of
that.
There
is
a
new
version
and
here's
how
it
works.
A
We
assume
the
controller
gets
the
cube,
config
modifier,
secure,
config
and
then
writes
it
again.
So
first
step
the
controller
gets
the
old
version
of
the
qubit
name.
Config
then
it
will.
The
api
server
will
first
read
better
one
from
the
lcd.
Then
it
knows
hey.
I
need
you
on
i4,
so
it
asks
our
controller
again
to
convert
it
and
then
we
return
uniform.
A
Then
our
controller
does
some
stuff
to
qrdem
config
and
the
controller
writes
vlog
for
to
the
server
the
the
api
server
as
our
controller
again
to
convert
to
better
one
and
api
servers,
sourcing,
better
one
so
and
and
how
is
our
field
preserved
now,
essentially
through
step
three
and
six
in
step?
Three,
the
entire
vivo
beta
one
cube
and
adm
config
is
stored
as
an
annotation,
so
actually
the
viewer
for
a
cuban
config
user.
A
It
is
also
written
back
here
and
in
this
conversion
we
take
the
annotation
and
we
restore
specific
fields
when
we
know
that
they
are
new,
even
better
one
and
yeah.
That
way,
it's
it's
not
getting
deleted
to
make
that
a
little
bit
more
visual
I'll
show
how
that
how
that
looks
in
the
api
with
cube
cdl.
A
A
Okay,
so
let's
take
a
look
at
my
cluster,
so
what
we
see
here
is
that
cube
ctl
per
default
gives
us
the
view
on
bit.
1
cubed
config
we're
not
getting
any
kind
of
annotations
here
here
and
it's
just
our
regular
starts.
What
we
can
also
do
is
retrieve
an
old
version
of
the
qubiting
conflict.
Just
have
to
go
back
slightly
and
let's
just
print
it
as
yammer.
A
For
now,
let's
see
which
one
is
okay,
so
now
we're
getting
alpha
free,
we're
getting
conversion
data
and,
as
you
can
see,
we're
getting
a
whole
bit
of
one
resource
here
as
annotation
and
yeah.
That's
essentially
it
if
we
take
that
annotation
and
extract
it
with
jq
somewhere
back
here.
I
hope
it's
sort
of
working
one.
A
Yeah
that
should
be
correct.
Then
we
see
the
whole
resource.
So
yeah,
that's
how
it
looks
like
okay,
so
I
think
we
established
we
need
conversion.
We
know
why
it's
useful
and
now
about
one
problem
we
could
have.
So,
let's
assume
we're
releasing
one
new
api
version
after
another,
so
we're
getting
three
four
or
five
api
versions.
A
What
you
would
expect
is
that
we
that
we
have
to
be
able
to
convert
between
all
of
them.
So
I
don't
know
someone
writes
you
an
iphone,
4
and
reads
view
on
alpha
3.
Then
you
might
assume
that
we
have
to
be
able
to
to
convert
from
alpha
4
to
alpha
3
and
do
that
between
all
versions.
So
there's
a
really
great
picture
in
the
qubit
in
book
that
shows
that
problem.
A
So
those
are
our
api
versions
and
naively
you
would
think
you
have
to
convert
between
all
of
them,
but
kubernetes
or
I
think,
series
essentially
has
the
hubspot
model
and
the
idea
is,
you
have
one
version
in
the
middle,
which
is
called
a
hub
and
you
have
the
spokes
and
you
always
convert
to
the
hub
and
from
the
hub
to
the
next
version.
So
in
our
example,
we're
converting
alpha
3
to
beta
1
to
alpha
4
and
the
hub
version.
A
It
doesn't
have
to
be
the
storage
version,
but
in
case
of
cluster
api,
it's
also
the
storage
version,
and
this
way
we
only
have
to
implement
conversions
from
and
yeah
to
the
hub
and
back
from
the
hub.
So
essentially
we
have
to
convert
from
alpha
three
to
beta
one
and
back
and
from
beta
one
to
four
and
back
and
and
not
any
kind
of
either
three
to
four,
for
example.
So
that's
just
some
some
additional
detail,
yeah.
A
So
essentially,
we
have
our
own
no
differently,
so
our
kubernetes
bootstrap
provider
apis
contains
something
called.
I
think
it's
qpm
complex
pack,
I'm
not
sure
if
it's
that
layer
or
a
little
bit
deeper,
but
essentially
we're
embedding
cubed
instructs
and
because
we
didn't
want
to
embed
them
directly.
We
have
our
own
copies
of
those
charts.
A
So
essentially
a
user
just
interacts
with
our
copy
of
the
qubit
instructs,
which
is
just
in
one
version
and
when
a
controller
then
tries
to
create
cloud
in
it
or
now
there
is
also
ignition
for
cubed
m.
It
takes
a
look
at
the
kubernetes
version
and
then
it
generates
the
cube
adm
configuration
file
as
yamo
in
the
correct
version,
so
not
100
sure,
but
something
like
just
an
example.
A
A
A
A
I
also
have
to
channel
so
first
of
all,
we
have
to
add
the
field
to
respective
types.
So
what
we
already
have
is-
or
sorry
some
word
about
code
structure.
So,
as
I
mentioned
here,
we
have
our
public
apis.
Those
are
those
three
packages
and
we
have
for
upstream
kubernetes
apis,
which
are
those
three
packages,
and
the
new
patches
field
we
have
here
is
something
which
was
introduced
in
the
cube
adm
upstream
api
in
vivo
beta
3..
A
So,
first
of
all
we
have
to
add
the
api
type
here
in
the
upstream
view
on
beta
from
peta
3
package.
So
we
have
init
configuration
patches.
We
also
have
new
struct,
which
is
the
patch
instruct
and
for
completeness
just
to
show.
We
have
the
same
thing
in
the
joint
configuration
I
think
yeah,
that's
the
joint
configuration,
so
joint
configuration
and
the
one
above
is
any
configuration.
A
So
that's
already
all
we
need
in
this
package.
We
have
to
do
the
same
thing
here.
We
have
a
so
usually
our
types
are
stored
in
files
which
are
have
just
the
same
name
as
struct,
so
we
have
cuban
conflict
types,
which
is
a
keyboard
and
conflict,
but
we
make
a
made
an
exception
for
kubernetes
types.
We
have
just
a
separate
file
which
just
contains
our
version
of
the
upstream
types
or
shim.
We
call
it
so
that's
just
yeah
our
version.
A
So
let's
see
there
might
be
more
differences,
but
I'm
just
using
that
to
easily
add
patches.
So
we
we're
not
so
we're
currently
not
supporting
all
upstream
fields.
Some
don't
make
sense.
Some
are
just
seven
minutes,
so
certificate
key
is
just
something
which
doesn't
make
sense
in
the
comics
cluster
api,
for
example,
skip
phases
is
not
implemented
yet
so
that
was
patches
in
it
configuration-
and
I
guess
somewhere
here,
that
joint
configuration
should
be
the
same
but
again
and
at
the
bottom
we
should
have
destruct.
A
That's
some
additional
code
from
us.
So
let's
add
it
here.
I
think
overall,
it
absolutely
makes
sense
to
try
to
keep
it
as
sync
as
possible
because
it's
just
easier
to
div,
and
we
have
to
do
this
from
time
to
time.
Okay,
so
now
we
have
the
field
also
in
qubit
name
types
next
step,
so
we
have
a
bunch
of
code
which
is
based
on
those
types.
So,
for
example,
we
have
deep
copy
so
deep
copy,
essentially
that
you
can
copy
all
the
structs
without
having.
A
So
here
I
actually
start
with
series,
so
that
target
is
relatively
fast,
so
it's
so
I'm
running
it
just
on
the
whole.
Already
on
the
whole
repository,
we
also
have
targets
which
only
run
it
for
the
bootstrap
provider,
the
control
print
provider
or
some
of
the
others.
But
in
that
case
we
can
just
run
it
for
everything,
so
that
should
give
us
some
changes
in
deep
copy.
So
essentially,
when
we
deep
copy
it
configuration,
we
are
now
also
copying
the
patches.
A
A
A
C
A
Auto-Generated
functions
but
other
general
functions
they
can
only
convert
if
they
know
what
to
do
essentially.
So
it's
easy
for
conversion
to
just
convert
fields
of
structure
which
are
entirely
the
same
or
just
copy
over
fields
which
didn't
change,
but
it
doesn't
know
what
to
do.
If
I
don't
know
the
type
of
we'd
not
be
usually
doing
this,
but
if
the
type
of
field
changed
or
if
a
field
is
new,
our
field
was
removed,
then
a
conversion
that
just
doesn't
really
know
what
to
do
and
that's
where
we
have
to
add
our
code.
A
But
first
of
all,
let's
do
make
generate
gold
conversions.
So
here
important
to
mention
generate
go.
Conversions
is
very
slow,
so
even
only
for
the
boost
provider.
I
think
it
takes
like
five
minutes
on
my
machine,
so
yeah
we
have
in
theory
a
target
for
the
whole
repository,
but
I
would
yeah
so
chests
will
only
run
the
brighter
specific
ones
to
not
have
to
wait.
A
A
Okay?
So
what
changes
here?
Essentially
the
new
version?
It
adds
a
warning
here
that
in
dot
patches
requires
media
conversion
because
it
does
not
exist
in
the
arrow
type.
It
also
rules
that
function
so
before
it
knew
how
to
automatically
convert
from
integer
configuration
beta1
to
iphone
4.
Now
it
doesn't
know
yeah
because
we
have
a
new
field,
so
our
job
is
essentially
to
implement
that
function,
as
we
think
it's
correct,
and
we
should
have
a
similar
div
here,
yeah
so
same
in
the
train,
configuration
and.
A
Yeah,
I
think,
let's
see
what
that
is,
I'm
sure
yeah.
So
I
think
before,
when
it
converted
an
entire
cuban
conflicts
back,
it
could
just
do
some
pointer
magic
because
the
structs
weren't
highly
the
same
and
now
it
has
to
call
our
function
actually
to
convert
it
into
individual
and
the
same
for.
I
guess,
I'm
not
sure
what
another
part
was
because
we
have
them.
We
use
them
two
places
and
oh,
no,
that's
fine.
A
A
A
So
at
that
point
you
can,
you
could
also
run
just
make
lint
and
it
would
show
you
or
something
else,
just
compile
the
stuff
and
it
would
show
you
a
bunch
of
compilers
and
that
that
places
you
have
to
take
a
look,
look
what's
going
on
and
fix
it.
Oh
actually,
we
start
with
upstream
types
doesn't
really
matter,
but
I
think
I
thought
it's
a
good
idea
to
fix
those
first,
so
better
on
generate
conversion.
A
So
what
we
see
here
is
that
it's
now
calling
two
functions
which
don't
exist
and
that's
our
chop
to
implement
them,
so
we're
usually
doing
that
in
the
conversion
code.
So
please
do
the
same
way
yeah.
So
we
have
to
implement
that
function.
Let's
see
what
our
name
is,
okay,
so
we
have
to
convert
from
beta1
init
configuration
to
upstream
beta1.
So
that's
our
public
type.
That's
our
internal
type
in
the
public
type.
We
have
the
new
patches
field
and
upstream
beta
1
type,
so
in
the
old
cube,
edm
version.
A
Essentially
we
don't
have
that
so
I'll
do
a
bunch
of
copy
paste,
because
it's
just
faster
than
writing
it
manually.
So
our
input
is
our
upstream
v1
beta1
init
configuration
and
our
output
is
just
in
configuration
and
that's
the
one
of
the
current
package.
So
that's
upstream
on
beta1,
the
scope
is
always
the
same,
and
what
we
are
doing
is
we're
just
calling
the
auto
convert
function
so
I'll
explain
that
in
a
minute,
so
the
conversion
didn't
generate
that
function,
but
it
generated
this
function
and
why
does
that
make
sense?
A
So,
essentially
this
function
is
there,
I
think
only
so
that
we
can
implement
it,
but
it
will
always
generate
autoconvert
function
and
autoconvert
function.
Just
let's
say:
does
it
best
to
convert
what
it
can
convert,
so
it
will
convert
everything
which
is
there
in
both
starts,
but
it
won't
convert
what
convert
the
patches
so
and
I
think
the
idea
is
that
in
the
in
those
cases
where
we
have
to
have
to
implement
it
manually,
we
don't
have
to
implement
that
stuff
and
there's
even
a
lot
more
of
that
code
in
there.
A
A
So
we
could
do
something
to
the
upstream
type.
So
if
there
is
some
way
to
take
the
v1
beta
free
new
field
patches
and
implement
it
in
some
other
way
in
the
older
version
of
the
api,
we
could
do
that
here
after
that
auto
conversion,
but
as
there
isn't,
because
the
field
just
simply
isn't
there
and
there
are
no
other
fields
which
could
provide
the
same
functionality,
we're
just
taking
that
conversion
and
we're
essentially
just
dropping
the
patches
field
and
that's
just
something
which
that
the
conversion
didn't
want
to
decide
for
us.
A
A
A
Oh
yeah,
that
was
fun
so
replace
order.
Okay,
so
just
the
same
for
upstream
beta
2,
because
field
also
doesn't
exist
there
and
we
can't
do
anything
to
implement
that
functionality.
Okay,
now
that's
good
too
and
yeah
what
about
upstream
view
and
beta3.
So
here
everything
is
fine,
because
the
field
exists
in
yeah
in
vivo
beta
one
and
in
upstream
on
beta3,
so
nothing
for
us
to
do.
I
think
there
should
be
something
like
yeah.
C
A
Here's,
okay,
that's
not
the
one!
I
want
to
click
on
it's
interesting
though
okay,
so
those
are
also
all
the
general
functions.
I
was
thinking
for
a
moment
that
we
are
in
conversion.com
yeah,
so
in
this
case
it
generated
a
bunch
of
functions
to
convert
patches
but
yeah
as
the
structs
are
entirely
the
same
in
the
public
type
and
in
the
upstream
type.
It's
just
able
to
do
that
automatically.
A
I
think
there
should
be
also
some
kind
of
join
configuration
to
join
configuration
functions
here.
So
that's
the
one
we
have
to
write
manually
in
the
other
case.
In
that
case,
you
just
have
to
auto,
convert
and
auto
convert.
That's
that
point
of
magic
here,
so
it
just
yeah
text,
state
of
the
old
struct
and
or
in
the
of
the
input
structure,
puts
it
in
an
output
structure.
A
A
Okay,
so
that
was
upstream
types,
public
types.
So
let's
now
forget
those
upstream
types
entirely.
Now
we
have
to
convert
between
alpha
four
and
beta
one
and
back
and
alpha
three
and
bit
one
and
back,
and
that's
usually
the
only
thing
you
have
to
do
for
other
providers,
because
they
only
have
those
packages
so
similar
compile
errors
here,
usually,
hopefully
I
think
oh,
it
could
be
yeah.
A
Yeah,
so
on
iphone
3
we
don't
have
an
issue
because
there
were
already
changes
for,
I
think
in
a
configuration
or
joint
computation
before
so
it
didn't
really
change
a
lot.
So
there
should
already
be
functions
like
convert
beyond
bit
one
joint
configuration,
so
we
don't
have
to
add
them
they're
already
there,
because
in
that
case,
ignore
preferred.
Errors
was
changed
before
so
it's
just
yeah
already
there,
but
in
view
on
other
four,
we
have
the
same
the
same
issue.
A
A
But,
okay,
let's
see
we
convert
from
beta
one
the
message:
first,
one
yeah:
okay,
no,
it's
fine!
You
can
write
from,
but
one
incompletion
to
your
knife,
foreign
configuration.
So
that's
vm
bit
one
init
configuration
and
that's
just
the
current
package,
because
we
are
again
in
the
vmi4
package
and
the
autoconvert
should
be
the
same
or
similar.
D
A
Okay,
so
if
the
structs
are
entirely
the
same,
it
creates
both
functions.
It
creates
the
auto
convert
endoconvert
if
it
detects
a
difference
which
it
can
resolve
automatically
like
you
have
one
more
field
and
one
of
the
types
it
will
only
create
an
autoconvert
function
and
then
it's
on
us
to
convert
or
convert
to
sorry
to
implement
the
disconvert
function.
C
A
I
think
it
only
generates
both
in
the
case
of
everything
is
the
same
to
keep
it
consistent.
I
guess
so
in
the
case
where
we
don't
have
to
intervene
manually.
I
think
that
function
is
not
strictly
needed
or
that
one
it
just
could
just
generate
one
of
them,
but
maybe
it's
for
simplicity
and
consistency
that
it
generates
both.
A
A
What
we
have
here
is
some
marker
functions,
so
I
talked
before
about
hub
this.
This
function
is
there
to
signal
to
control
the
runtime
that
the
view
and
beta1
version
of
that
type
is
the
hub.
They
should
be
similar,
I'm
not
sure
if
it's,
no,
it's
not
needed
for
spokes.
So
if
the
hub
functions
are
there
it's
the
hub
and
if
not,
you
have
a
spoke,
that's
relevant
later
on,
okay,
yeah,
and
here
we
could
in
theory
we
could
run
make
lint.
A
A
We
have
tests
for
that.
They
are
called,
I
guess,
fuss,
fastest
conversion
fastest
or
something
they're.
Looking
like
that,
a
test
fussy
conversion
is
the
name
and
what
they're
doing
is
the
following.
So
in
in
that
case,
just
let's
take
a
look
at
the
public
apis.
It
makes
more
sense
or
yeah.
It
just
makes
more
sense.
A
A
A
A
So
I've
actually
never
ran
a
deep
copy
target
before
and
then
the
code
wasn't
there
so
not
sure
how
that
happened,
but
yeah.
So
that
should
fix
that
now.
I
assume
we
probably
have
a
problem
here,
because
the
interface
doesn't
match
or
something
cannot
use
yeah,
maybe
because
the
type
is
different.
Maybe
it's
something
else.
A
Let's
see
if
there
was
some
oh
yeah,
I
know
what
the
problem
is.
Okay,
so
I've
started
with
the
currently
open
pr,
but
when
I
did
it
yesterday,
I
I
did
a
small
but
very
small
modification,
which
I
totally
forgot.
So
I
checked
again
how
the
upstream
types
are
implemented
and
on
the
currently
open
pr.
A
There
was
one
very
small
error,
and
that
is
that
we
have
to
use
a
pointer
here
so
because
patches
is
optional,
it's
a
pointer
and
because
now
I
have
and
probably
have
to
the
same
error
in
both,
I
guess
also
on
the
on
the
public
types,
because
I
I
copied
it
from
here
yeah,
but
we
should
really
implement
in
exactly
the
same
way.
So
if,
in
upstream
types
those
are
pointers,
they
also
have
to
point
us
here.
So,
let's
see
if
that
works,
then
I
think
so.
A
A
A
And
it
takes
a
bit
of
time
because
it
I'm
not
sure
how
often
it
runs
the
test
but
a
few
times
and
that's
the
actual
code
for
it.
Yeah
yeah
we're
running
it
ten
thousand
times
in
both
directions
to
absolutely
make
sure,
and
there
are
some
cases
where,
where
the
automatically
generated
values
are
not
valid
values
and
then
the
serialization
fails,
but
yeah
that's
just
to
protect
edge
case
with
so
when
you
yeah.
So
let's
see
so
we
have
an
error.
A
A
A
little
bit
yeah,
you
have
to
know
some
stuff
to
read,
but
so
essentially,
if
you
see
differences
between
a
field
is
nil
or
the
map
that
doesn't
matter,
that's
just
part
of
the
div
output.
It's
not
actually
a
problem,
so
that's
not
something
we
have
to
fix.
I'm
not
sure
why
the
difference
is
but
yeah.
Our
interesting
thing
is,
is
more
related
to
patches.
So
we
see
when
we
convert
from
beta
1
to
alpha
4
and
back
then
we're
losing
patches.
A
So
in
our
generated
beta
one
kubernetes
config,
we
had
patches
and
after
conversion
to
alpha
four
and
back,
we
lost
patches
and
that's
not
something
we
want.
So,
let's
see
what
we
have
to
do
so
and
why
are
we
using
them?
We
are
losing
them
because,
currently
in
our
conversion-
and
that's
the
auto
generate
that's
where
we
let's
say
integrated
us
in
the
auditorium
code.
Here
we
just
said:
hey
we're
not
doing
anything.
Patches
is
gone,
that's
fine
for
us
and
that's
why
it's
gone
now.
A
Okay,
so
now
I
have
to
explain
how
it
all
fits
together.
Please
ask
if
it's
unclear,
so
the
only
thing
we
have
here
is
the
auto
generator
functions
and
in
those
functions
we
have
to
implement
instead
of
the
auto
generation,
because
the
generation
didn't
know
what
to
do,
as
I
mentioned
before.
What's
actually
how
does
function
are
actually
used.
A
A
Essentially
we
have
the
webhook
registration.
So
when
we
bootstrap
the
the
controller,
we
are
registered
adjusting
this
type
as
webhook
and
what
that
does
is
essentially
here
it
triggers
swepbox.
So
it
does
something
for
defaulting
and
validation.
But
for
us
it's
interesting
that
we
have
conversion
so
in
just
a
conversion
webhook,
if
the
resource
is
convertible
and
convertible
is
something
like
if
it
implements
the
right
interfaces.
So
that's
where
it
checks.
A
If
the
hub
interfaces
the
hub
function,
is
there
to
fulfill
the
convertible
interface
and
it
checks
if
the
convert2
and
convert
form
functions
are
there,
but
if
that's
the
case,
it
registers
the
conversion
web
hook
under
slash
convert
and
the
conversion
web
hook.
Essentially,
is
what
implements
that
endpoint.
A
A
So
if
you
have
to,
for
example,
convert
from
alpha
4
to
beta
1,
then
it
tries
to
figure
out
which
one
is
the
hub
type,
and
then
it
does
some
kind
of
conversion
to
yeah
to
get
from
one
to
the
other,
from
f4
to
beta1,
for
example,
by
calling
the
the
correct
convert
from
or
convert
to
function,
and
I
think
that's
where
I
would
leave
that,
but
you
can
always
step
for
that
code.
It's
pretty
easy.
A
It's
just
a
request
comes
in
the
resources
parsed,
let's
figure
out,
which
functions
to
call
what
is
hub,
what
spoke
and
called
convert
to
or
convert
from
and
yeah,
and
that's
where
we
are
leveraging
the
autogenerate
function.
So
for
all
types
we
have,
it
doesn't
really
matter.
If
there
are
differences
or
not,
but
for
all
types
you
have,
you
have
to
implement
the
convert
to
and
convert
from
in
the
easy
case,
it's
just
calling
the
autogenerate
function,
because
everything
is
there.
A
A
So,
as
I
said
before,
step
three
the
keyboard
and
config
is
convert
from
beta
1
to
four
and
we
will
store
the
entire
beta1
resource
as
annotation
on
the
iphone
4
resource.
How
do
we
do
that?
Essentially,
we
are
calling
the
regular
conversion
function,
which
just
does
some
field
copying
and
that's
it
and
then,
additionally,
we
call
martial
data
and
marshall
data
takes
source,
which
is
our
beta1
resource.
A
A
A
Then
we
take
the
annotation
unmarshal
it
and
that
struct
and
then
we
can
restore
things
from
our
restored
object
to
our
destination
object
and
unmarshall
is
also
pretty
easy.
Let's
just
take
the
annotation
unmarshall
it
and
yeah,
and
here
we
make
sure
that
in
the
re
restart
object
we
don't
have
the
annotation,
but
it's
not
super
important,
yeah,
okay,
so
questions
I
know,
that's
I'm
not
sure
if
I
explain
it
well,
but.
A
C
A
I
wonder
if
there's
something
you
could
do
wrong,
let's
say
as
long
as
you
don't
hack
the
fusser
by
implementing
some
custom
fossil
fungus,
it's
100
safe,
because
it's
just
it's
generating
all
fields
and
converting
it
in
all
directions
and
make
sure
that
nothing
gets
lost.
You
only
have
to
start
to
think
then,
and
we
get
to
that
later,
when
you,
when
you
modify
the
input
of
the
fuzzer
and
say
hey
those,
this
field
has
always
that
value
and
right
then
it
gets
dangerous.
A
No
yeah,
essentially,
you
can
follow
that
workflow
at
the
fields
channel
write
the
conversion
functions
here,
do
some
stuff
or
do
some
stuff
here
or
maybe
run
the
conversion
test
before
and
if
everything
is
green,
everything
is
fine
and
if
you
get
errors,
you
have
to
figure
out
how
to
fix
them
and
there's
different
ways
to
fix
them
yeah.
But
let's
see
our
current
cases
that
we're
using
patches
what
we're
already
doing
for
qpm
config
is
creating
the
backup
as
annotation
and
what
we're
not
doing
is
restoring
the
patches
field.
A
So,
let's
see
how
we
can
restore
the
patches
field,
so
we
take
a
look
at
our
restored
struct
and
I'm
not
super
sure
where
it
is
spec
image
configuration
and
then
patches.
We
have
to
be
careful
because
in
configuration
is
actually
a
pointer
so
because
we're
fussing
all
the
things
it
could
be
that
any
configuration
is
not
even
set.
So
in
this
case
we
have
to
be
careful
and
only
restart,
if
that's
not
nil.
Otherwise,
you
will
see
a
new
point
of
dereference
in
the
faster
test.
A
One
interesting
thing:
you
might
think
that
you
have
to
take
a
look
at
if
patches
is
still
or
not,
but
that
doesn't
matter
because
if
it's
nil,
it's
just
set
to
nil.
So
it's
a
no-op
essentially
and
if
it's
has
some
content,
it's
some
content.
So
on
that
level
we
don't
have
to
care
about
that
yeah,
but
the
faster
test
of
finds
those
kinds
of
bugs
pretty
immediate
yeah.
Always
right.
I
didn't
have
a
case
where
I
didn't
found,
so
I
guess
the
ten
thousand
times.
A
I
make
sure
that
you're,
hitting
all
the
cases
yeah
and
the
same
for
train
confirmation.
Now.
I
would
think
that
that
test
works
for
qubit
and
conflict
because
we
fixed
keyboarding
config.
We
didn't
fix
kubernetes
config
template
yet,
but
that's
something
we
have
to
do
too.
But
let's
wait
for
a
moment
to
see.
If
that's
enough.
A
Okay,
so
that's
the
qubit
in
config
same
issue
in
q
and
config
template.
So
you
will
see
that
here
we
have
patches
and
just
go
down
to
the
kubernetes
template.
You
already
have
convert
tool
from
thanks
to
the
ignition
pr,
so
they
had
to
add
that
too
it's
pretty
similar
here.
The
only
difference
is
that
it's
in
spec
template
spec.
I
think
so,
let's
see
if
that
compiles.
A
A
A
A
And
if
I
didn't
forget
anything-
and
it
should
be
fine,
so
I
mentioned
before
there
are
some
cases
they're
fixing
like
that
is
not
enough.
So
currently
we
assume
that
all
values
that
a
faster
generates
are
valid-
I
mean
it
takes.
I
don't
know
it
takes
your
struct
looks
at
a
field.
It's
a
string.
It
generates
a
bunch
of
strange
strings.
A
A
It
essentially
works
like
this.
If
you
look
at
the
test,
fossee
conversion,
you
see
that
we
pass
in
some
fuss
funks
here
yeah.
Let's
ignore
that
here.
Essentially,
the
first
funds
look
like
that:
they,
the
name,
doesn't
matter
at
all.
The
parameters
are
whatever
fasting
or
for
which
type
the
fasting
you
want
to
customize.
So
in
this
case
we
won't
have
our
own
fast
logic
for
the
bootstrap
token
string.
A
So
we
just
take
the
bootstrap
token
string
and
that's
always
there,
because
you
can
use
that
to
say
faster,
please
first,
that
field
for
me.
If
you
try
to
if
you
customize
the
whole
structure
or
something,
and
in
that
case
you're
just
setting
that
fake
id
and
fixed
string
just
fake
secret,
those
are
just
fixed
strings.
So
actually
the
bootstrap
token
string
is
not
actually
fast.
It's
just
always
faked
in
fake
secret,
because
if
it
would
be
fast,
we
would
get
some
strange
characters.
A
Okay,
so
let's
see-
and
I
have
a
free
conversion
of
screen
to
iphone
4
conversion
screen,
so
we're
done
with
the
public
types.
So
for
all
other
providers
you'd
be
done
now
I
mean,
of
course
you
would
push
the
pr
run.
All
tests
make
sure
that
everything
really
works,
but
apart
from
that,
that's
all
you
would
have
to
do.
D
A
A
What
we,
what
we
tell
the
test
is
which
types
we
have
so
that's
a
better
one
and
that's
the
if4
type
and
those
are
the
customization
functions.
If
you
want
to
do
something
special
for
some
fields,
then,
when
you
run
the
test,
we
are
creating
a
fossil
here
and
now
we're
running
the
following
ten
thousand
times
so
first
we
have
spoke
before
so
that's
actually
in
that
case
here
that's
I
think
I
run
for
alpha
four.
A
A
C
A
A
D
A
Just
just
to
make
sure
that
we
cover
all
cases
so,
for
example,
if
we
generate
at
once,
we
have
a
node
registration
here,
for
example,
but
what
about?
If
we
forgot
this
little
check
here,
we
wouldn't
find
it
with
that.
It
would
be
totally
random
if
you
would
find
that
issue,
but
when
you
run
it
10
000
times,
we
can
be
pretty
sure
that
there
is
one
case
where
that
is
original
and
we
would
find
yeah
the
need
for
that.
If
so,
let's.
B
A
A
So,
let's
start
with
upstream
even
beta1,
and
we
can
see
here
what
we,
what
we're
trying
to
achieve
so
and
now
we're
not
talking
about
kubernetes
resources
so
because
we
have
the
full
resources
here.
So
here
we
have
a
cube
and
configured
in
config
template.
Those
are
trust
or
api
types
here,
we're
talking
about
cluster
configuration
cluster
status
in
the
conflation
joint
configuration.
A
A
We
have
some
structs
embedded,
which
you
want
to
use
and
those
structs
are
cluster
configuration
in
the
conflagration
joint
configuration
and
yeah
in
beta1
also
cluster
status.
I'm
not
sure
if
it's
still
there
in
beta3,
but
we
only
have
to
convert
those
drugs
and
not
everything.
So
that's
why
we
are
only
checking
those
conversions
and
not
the
whole
thing,
because
that's
what
cuberdm
needs
from
us
yeah
and
what
that
test
verifies
is
if
we
can
convert
from
the
public
cluster
configuration
type
to
the
upstream
type.
A
A
The
tests
are
written
in
the
same
way
because
we
can
use
the
same
function,
so
it
will
also
test
the
whole
round-trip
thing,
but
we
only
care
about
that
direction.
We
don't
care
about
if
you
can
convert
from
the
upstream
types
to
property
types
yeah.
So,
let's
see
if
the
test
works,
spoiler
alert,
it
doesn't.
E
A
Okay,
so
let's
see
yeah
so
in
the
confession:
trying
confirmation
as
expected,
I
guess
we're
losing
patches
again
and
I
wonder
if
that's
a
problem
for
bishop,
but
let's
see
I'll
first
fix
it,
how
I
would
have
fixed
it
and
then
let's
see,
if
that's
that's
good
enough,
so
because
we're
not
talking
about
full
communities
resources,
we
can't
really
put
anything
in
an
annotation
because
joint
configuration
doesn't
have
metadata
annotations.
It
just
isn't
there.
E
E
Would
be
fit
for
the
problem
it
who
could
be
used
as
alternative
but
yeah.
We
are
using
api
convention
api
machinery
because
we
already
have
it
in
the
project
and
we
are
kind
of
used
to
it.
So,
okay,
then
the
problem
that
we
have
to
solve
is
the
following:
the
cluster
api
api
existing
in
only
one
version,
let
me
say
beyond
beta1
the
latest
one,
then,
with
cluster
api
you
create
clusters
that
are
of
different
kubernetes
version.
E
E
A
Yep
makes
absolutely
makes
sense,
okay
and
that's
what
we're
doing
now.
I
just
living
in
here.
It's
because
it's
easier
so,
as
I
said,
we
can
customize
faster
with
those
fast
functions.
So
what
we
will
do
is
we
will
add
one
for
image
configuration
one
for
join
configuration
here
in
the
list
and
they
are
looking
like
that
and
let's
switch
to
window
and
yeah.
Those
fuzzer
functions.
A
Look
like
this,
so
we
take
the
inner
configuration
we
we
use
the
faster
to
just
first
fuss,
all
the
fields
and
then
we're
saying,
hey
patches
is
no
and
we're
saying
patches.
No,
because
yeah
patches
does
not
exist
in
in
the
upstream
type,
and
here
we
make
sure
that
the
fossil
only
j
only
generates
types
which
wouldn't
lose
anything.
So
we
have
to
set
patches
to
know
so
then
we
can
also
not
lose
patches.