►
From YouTube: kcp CEL conversion demo
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
Hi,
my
name
is
Andy
Goldstein
and
today
I'm
going
to
demonstrate
a
prototype
of
cel-based
conversion
between
different
API
versions
in
kcp.
What
I
have
on
the
screen
right
now
is
a
sample
custom
resource
if
you
will
called
widget
and
you'll
notice
that
its
spec
has
two
Fields
first
name
and
last
name.
This
is
also
version
one
of
my
API
and
maybe
I
decide
that
I
actually
want
to
have
a
field
called
name,
that's
underneath
spec
and
that
I
want
to
have
spec.name
DOT,
first
and
spec.name.last
with
custom
resource
definitions.
A
A
This
is
the
API
resource
schema
for
my
widget
type.
This
is
like
a
custom
resource
definition,
but
it's
a
kcp
extension
that
allows
us
to
publish
apis
from
one
workspace
and
have
other
users
consume
them
from
other
workspaces.
It
looks
very
much
like
a
custom
resource
definition.
One
thing
to
note,
however,
is
there
is
the
addition
at
the
bottom
of
this
conversion
section.
A
If
we
wanted
to
set
spec
dot,
name
DOT
first
name,
we
would
look
at
the
Hub
version
and
look
at
self,
which
is
the
Hub
version,
go
to
its
spec
and
then
grab
the
first
name
field,
so
we're
taking
spec.firstname
and
putting
in
putting
it
into
spec
dot,
name,
DOT
first
name.
Similarly,
we'll
do
the
same
thing
with
last
name,
and
if
we
need
to
convert
to
the
other
direction,
where
we're
going
from
V2,
which
is
not
the
Hub
version
to
V1,
which
is
the
Hub
version,
we
will
go
from
specdot
or
sorry.
A
We
will
go
to
spec.firstname,
which
is
the
Hub
representation
from
the
field,
spec
dot
name,
DOT,
first
name
in
V2.
So
what
does
this
look
like
in
practice?
Well,
I
have,
in
my
other
tab
here:
I
have
kcp
up
and
running
you'll,
see
The
Shard
is
ready.
So
if
I
go
here
back
to
my
terminal,
I
can
go
ahead
and
apply.
A
The
conversion
file,
which
has
the
API
resource,
schema
the
API
export
and
an
API
binding,
so
that
everything
is
usable
within
this
same
workspace
and
then
the
next
thing
I
can
do
is
I
can
create
a
widget
and
the
example
that
I
showed
was
for
V1.
So
if
I
apply
my
widget,
we
can
see
that
that
was
created.
A
Now.
If
we
get
this
and
we
look
at
the
yaml
for
the
witch
that
I
just
created,
you'll
notice
that
this
is
sorry
you'll
notice
that
this
is
V2
and
you'll
notice
that
it
has
spec
dot,
name,
DOT,
first
name
and
Dot
last
name,
but
that's
interesting,
I
didn't
have
a
conversion
web
hook
or
anything
like
that.
So,
let's,
let's
take
a
look
again
at
the
resource
schema
specification.
A
A
Put
it
at
the
end
and
you'll
see
coming
out
of
etcd,
the
API
version
that's
stored
is
V1
and
the
spec
has
first
name
and
last
name,
but
again
just
to
show
the
keep,
control
or
sorry
yeah.
The
the
version
from
the
server
is
V2,
with
name
as
a
s
and
as
a
spec
field
that
has
first
name
and
last
name
as
subfields.
So
that's
it
for
the
initial
demo
for
CEO
based
conversion
in
kcp.