►
From YouTube: Kubernetes SIG CLI 20220126 - KRM Functions Subproject
Description
Agenda: https://docs.google.com/document/d/1x80l4i88F27zSCxSjlhvwFdH6jQAHou1k1ibuXrDTaw/edit (must be on SIG CLI mailing list to access)
A
Hello
and
welcome
to
the
second
km
function,
subproject
meeting.
We
have
a
few
items
on
the
agenda
today,
so
let's
just
dive
in,
I
believe
there
we
have
all
met
each
other,
so
we
don't
need
to
do
any
introductions
today.
So
let's
just
go
with
the
first
topic,
which
is
the
function
improvement
pr
munchie.
Do
you
wanna
your
own.
B
C
Yeah,
so
this
is
like
a
follow-up
discussion,
so
we
have
discussed
this
in
a
previous
meeting,
so
I
want
to
like
trying
to
understand.
What's
what
should
I
resolve
before
like
we
can
merge
this
so
yeah?
That's
what
I
want
to
that's
why
I
want
to
bring
this
up
again
here
and
jeremy
said
he
is
going
to
provide
some
feedback,
but
I'm
still
waiting
for
his
feedback.
A
C
C
A
Yeah
and
we
can
make
breaking
changes.
This
would
be
a
pretty
huge
one
so
like
just
because
we
can
doesn't
mean
we
shouldn't
be
careful
about
it,
but
I
I
agree
with
you
that,
strictly
speaking,
it's
perfectly
fine
to
to
go
ahead
and
make
changes
that
we
think
are
warranted
in
an
alpha
library,
but
with
this
specific
change,
it's
actually
related
to
the
exact
same
thing
that
my
comment
down
here
is
really
about.
A
C
A
Okay,
did
you
understand
my
rationale
that,
like
there's
just
so
much
about
this
package
that
is
oriented
around
our
node
transformation,
like
the
filters,
the
selectors,
the
matchers,
that,
like
a
huge
amount
of
the
like
high
level
like
user-friendly
convenience
tools,
would
stop
working
and
we'd
have
to
invent
duplicates
of
them
for
the
duplicate
object
type?
If
we
were
to
have
a
second
one.
A
Because
they're
oriented
around
our
nodes
so
like
the
selector
itself,
expects
to
be
a
filter
which
is
an
our
node.
It's
a
function
that
takes
in
our
node
in
and
gives
the
list
of
our
nodes
in
and
gives
list
of
arounds
out
and
matches
a
our
set
of
that
which,
instead
of
taking
a
collection,
they
take
an
instance.
They
see
if
it
matches
or
not
return
of
boolean,
but
it's
there
are
node
oriented.
So
we
have
these
like
really
high
level
convenience
functions
that
are
like
framework.match.
A
You
know
a
user
who
needs
to
manipulate
and
dig
into
kubernetes
resource
that
came
from
some
yaml
that
we
know
has
metadata
at
high
level,
but
has
arbitrary
fields
besides
that,
like
they're
at
the
same
level
of
abstraction.
I
agree
with
you
that
the
name
sucks
that's,
unfortunately,
pretty
annoying
to
the
end
user.
To
change.
D
Yeah,
I
can
understand
katrina's
concern.
Actually,
I
think
before
we
talk
about.
If
this
cube
object
may
introduce
duplications
or
there
will
be
a
bunch
of
fixes,
we
need
to
do
on
the
r
node.
I
think
for
cube
object
and
the
arnold
and
munchie
also
mentioned
the
name
pipe.
These
are
actually
different
ways
to
introduce
the
concept.
The
the
structure
of
a
hype
over
hydration
over
krm
function
to
users.
D
D
Maybe
q
object
is
a
is
a
better
way
to
introduce
the
definitions,
and
from
that
perspective,
even
though
there
will
be
a
lot
of
work
to
fixing
the
surface
areas
that
still
deserves
the
effort.
Yeah,
that's
that's
my
opinion.
I
think
once
he
mentioned
the
the
name.
Pipe
is
not
good
and
you
change
that
to
us
as
may.
If
I
remember
correctly,
do
you
mind
introducing
the
new
surface
and
the
definition
you
want
to
introduce
to
users?
A
Yeah,
I
think
part
of
it.
I
think
I
brought
this
up
last
time
too.
It
is
a
documentation
issue,
and
I
love
that
this
pr
has
a
ton
of
examples
in
it,
because
that's
really
going
to
help,
no
matter
what
the
final
shape
of
it
ends
up
being
like.
That's
totally
something
we
really
desperately
need,
because
this.
A
Basically,
and
even
when
you're
integrating
your
function
into
customized
or
kept
you're
kind
of
doing
that,
because
they're
working
under
the
same
principles
under
the
hood,
which
is
really
cool
and
super
powerful,
especially
if
you're
talking
about
building
abstractions.
So
that's
some
of
the
reason
for,
like
multiversion
api
processor,
for
example.
A
It's
a
dispatcher
that
you
could
use
to
build
your
own,
like
orchestrator
alternative,
if
you
want,
but
you
can
also
use
it
just
inside
of
your
own
function,
to
make
it
a
sustainable
project
over
time,
because
you'll
want
to
release
new
versions
of
it.
So
you
use
it
as
a
dispatcher
just
between
v1,
alpha,
1
and
v1
beta1.
A
So
in
that
sense,
like
the
tools
are
sort
of
recursively
useful
and
that's
something
that
that
we
need
to
preserve,
which
is
why
I'm
advocating
here
for
making
this
like
a
veneer
on
top
of
the
existing
tools,
rather
than
making
sort
of
a
set
of
tools
that
are
separate
or
that
don't
interrupt
with
the
with
the
the
tools
that
we
have
that
were
built
for
this
power
so
pipe.
I
agree
like
that's
unintuitive,
to
use,
let's
say,
and
that
one.
A
The
framework
has
like
pipe
isn't
from
the
framework
right.
I
think
it's
kio,
maybe
or
kml.
I
don't
think
it's
from
the
framework
and
the
framework
has
its
own
way
of
composing
filters
together
and
getting
them
invoked
with
like
execute,
is
the
main
entry
point
so
and
then
the
api
version
processor
is
the.
If
you
want
dispatch
yeah.
D
D
A
I
I
think,
we're
on
the
same
page
that
at
least
for
this
pr,
the
the
new
features
will
get
added
to
our
node
instead
and
then
we'll
put
our
node
back
in
this
struct
here.
The
resource
extract
we're
looking
at
and
we're
kind
of
diving
into
the
reasons
behind
it
to
make
sure
that
we're
on
the
same
page,
about
that.
D
C
C
A
C
A
Here's
a
tutorial
of
how
to
layer
them
together,
like
a
filter,
is
the
central
concept
that
all
of
these
things
are
revolving
around
the
concept
that
you
have
some
yaml,
that
you're
taking
in
you're
going
to
do
whatever
to
it,
and
then
you
emit
it,
but
sometimes
that's
not
sufficient,
because
you
need
per
the
spec
to
have
some
sort
of
configuration
that
changes.
What
that
filter
does
so
the
filter
interface
on
its
own.
A
A
If
I
remember
that
correctly
that
it's
just
it's
like
processed
and
you
take
in
a
resource
list
and
you
mutate
that
resource
list-
and
you
emit
an
error,
I
think
that's
the
signature,
which
would
let
you
do
whatever
you
want
in
there
technically,
if
you
don't
feel
like
implementing
it
with
the
tools
that
we've
provided.
So
it's
like
it's
built
in
a
layered
way
where
you
can
hook
in
where
you
want.
A
So
I
am
okay
with
like
if
we
can,
if
there
are
opportunities
to
not
expose
kio
tools
where
we
can
just
take
care
of
stuff
for
the
user.
That's
that's
great
filter,
though,
is
like
the
low
level
thing
that
we
build
on
on
top
on
tops
of
all
the
other
tools
that
we
provide,
so
that
one
in
particular
can't
go
away
for
sure.
C
And
also
the
kale
provides
some
reader
writer
stuff,
which
I
believe
we
don't
need
to
expose
to
the
user,
necessarily
because
this
reader
writer
applies
something
like
either
set
set
reader
annotations,
which
is
like
more
for
the
aux
treaters,
but
not
for
the
functional
australians
for
the
functional
authors.
They
are
more
likely
to
just
read
the
ammo
and
decoded
not
to
really
set
these
additional
internal
annotations.
A
If
there's
a
way
to
make
it
less
complicated
like
by
hiding
the
fact
that
it's
a
kio
reader
that
has
all
these
fancy
options
like.
I
think
we
need
some
sort
of
reader
to
make.
It
continue
to
possible
to
make
these
testable,
but
it
we
don't
have
to
expose
options.
If,
if
that,
if
some
that's
something
we're
doing-
and
it's
not
necessary.
C
A
The
gist
of
what
the
the
package
does
is
it
actually
lets
you
test
either.
If
you
have,
if
you're
using
the
command
package
to
build
a
cobra
command,
you
can
use
it
for
that
or
if
you're,
not
using
cobra,
you
can
test
a
processor
directly
and
the
setup
is
that
you
have
one
directory
per
test
case
and
you
have
conventional
file
names
that
have
the
input
and
the
expected
output,
whether
that's
an
error
or
a
well
resource
list,
successfully
produced
and
the
framework
automatically
kind
of
wires.
A
C
A
Yeah,
that's
exactly
it
they're
all
in
the
same
directory
and
they
have
conventional
names,
but
that's
exactly
it.
It's
golden
file
tests
and
it
supports
errors
too.
So
it's
just
a
different
file
name.
If
you
expect
an
error
and
then
it
matches
the
text
in
the
errors
file
against
the
actual
error
that
was
received.
A
B
C
D
Yeah,
I'm
sort
of
wondering
if
we
should
have
a
agreement
on
the
high
level
ideas
like
what
kind
of
things
we
want
to
achieve
from
this
pr,
I
can
see
we
are
trying
to
make
the
kiamo
functions
more
powerful.
At
the
same
time,
we
want
to
simplify
or
truncate
truncate
the
surface
areas.
We
want
to
redefine
the
terms,
so
it's
easier
for
users
to
understand.
C
A
D
A
A
So
would
need
to
make
a
considerable
amount
of
adjustments,
and
we
shouldn't
take
that
decision
likely
like.
I
think
we
should
just
you
could
make
as
soon
as
these
pr's
are
in.
You
could
make
that
pr
in
a
week
or
two
from
now,
but
it
should
be
in
its
own
pr,
where
we
deliberately
make
that
decision
and
like
when
an
end
user
comes
and
like
we
it's
having
to
have
that
update
burden,
they
can
specifically
see
the
pr
that
did
it
and
the
explanation
for
why
it
happened,
and.
D
A
I
mean
if
it's
we
don't
do
releases
that
regularly.
What
I
said
could
happen
before
or
the
next
release.
Even
I
just
don't
think
yeah
and
we
should
see
what
the
consequences
are
for
ourselves
like
when
we
do
that.
We'll
have
to
rename
like
do
the
rename
ourselves
all
throughout
customized,
so
we'll
be
able
to
see
the
kind
of
levels
of
pain
that
we're
inflicting
on
our
users
and
make
the
decision
as
part
of
that.
D
C
A
I
I
don't
want
to
say
that
I
will
for
sure
approve
it
just
like
that,
because
it's
so
big
but
those
those
are
the
main
blockers
that
I
see
right
now
and
I
will
commit
to
as
soon
as
that
is
updated,
going
taking
another
look
at
the
pr
and
you
know
with
it
getting
smaller
as
well.
I
think
that
will
help
with
the
review
ability.
A
A
D
A
A
So
if
the
kml
library
evolves
the
starlark
implementation,
then
it's
not
particularly
relevant
to
customize,
because
customize
is
deprecating
that
feature
completely
and
we
could
remove
it
whenever,
as
far
as
we're
concerned,
the
question
of
moving
it
out
to
its
own
repo,
like
this
is
cncf
owned
code.
So
I
that
would
have
to
be
brought
up
at
a
sig
meeting.
The
runtimes
are
their
own
feature.
A
It's
not
just
the
function,
library
that
we're
improving
this
pr,
but
the
runtime
that
you're
talking
about
here
is
another
another
sort
of
independent
feature,
and
it
could
totally
make
sense
to
have
that
in
its
own
repo-
and
I
don't
have
any
conceptual
objections
about
that
myself,
but
would
have
to
figure
out
just
say
how
to
like
whether
that
logistically
makes
sense
and
is
worth
like.
The
effort
of
extracting
it
versus
just
evolving
the
starlark
thing
to
meet
your
needs
and
unhooking
customize.
D
A
A
Probably
not
because
it's
not
importing
that
file
but
somewhere
in
this
vicinity?
There's
there's
something
that
makes
customized
specifically
use
function,
runtime
starlark,
and
we
could
just
disconnect
that
and
then
the
changes
that
you
make
will
not
have
an
impact
on
customize
anymore,
because
customized
won't
support
starlark,
and
that
would
be.
That
would
be
the
easiest
thing
to
do
for
sure.
A
C
A
D
C
A
I
haven't
heard
the
feedback,
but
that
totally
makes
sense
to
me
so
to
be
clear:
I'm
not
advocating
for
the
function
runtime
libraries
used
by
kept
and
customized
to
diverge
like
I
think
they
should
stay
together
and
orchestrators
can
pick
and
choose
which
ones
that
they
want
to
support
so
like.
If
kept
wants
to
build
a
non-docker
container
runtime,
I
totally
want
it
in
function,
runtime
or
whether
that's
inside
camel
or
as
its
own
repo.
I
think,
having
like
a
central
collection
of
enzymes
that
are
supported
by
the
that,
like
help
implement
the
spec.
B
E
Yeah
with
very
little
context,
hi
folks,
my
my
name
is
nick.
I
am
for
many
years.
Was
the
tech
lead
of
cross
plane
now
part
of
the
sort
of
cosplay
project
steering
committee.
We
have
a
use
case
where
we're
highly
interested
in
using
krm
functions.
It's
still
early,
but
absolutely
shelling
out
to
docker,
as
is
the
way
that
we
run
things
it's
not
going
to
work,
so
I'm
only
just
diving
into
these
runtime
libraries
and
whatnot
at
the
moment,
but
I'm
definitely
curious
to
chat
to
you
all
about
it.
E
A
C
D
Yeah,
the
other
one
is
about
so
for
kml
is
under
customized,
but
we
release
it
separately.
I'm
wondering
every
time
we
want
to
make
service
changes,
though,
is
in
alpha.
I
mean
in
long
term,
once
it's
in
v1
or
a
more
material
version,
how
we
can
guarantee
the
do.
We
have
like
some
enterprise
infrastructure
that
we
can
make
sure
it
wouldn't
affect
our
users.
D
D
They
don't
need
to
tell
us
their
their
use
case
say
for
private.
They
may
have
a
private
repo
that
they
won't
be
able
that
we
won't
be
able
to
realize
in
the
gold
library
import
the
importantly
so
for
kiamo
we
have
in
the
go
document.
It
tells
all
the
public
repo
which
imports
that
kml
library,
but
there's
for
it,
wouldn't
show
the
private
repo
and
to
better
serve
the
private
repo
users.
We
can
encourage
people
to
add
text
in
the
keyammo
or
customize
framework
repo,
and
we
make
sure
those
test
passes.
D
B
A
D
D
So
I
add
my
I
add
test
in
kayamu
codebase
that
I
expect
every
change
to
kayamo
will
run
a
pre-submit
test
against
my
resource
input
and
the
expected
output
I
provide,
and
if
the
test
fails,
that
pr
shouldn't
be
merged
or
if
okay
yama
maintainers
have
some
breaking
change
about.
Like
the
you
exchange,
I
can
be
notified
without
sharing
details
without
monitor,
without
checking
the
latest
change
on
kayamu.
A
I
think
that
at
a
high
level,
that's
definitely
a
great
idea
to
have
some
sort
of
like
easy
workflow
for
people
to
contribute
their
test.
Cases,
like
I
said
customize
does
have
something
very
similar
to
that
in
concept.
Where,
even
for
just
like
bug
reports,
we
encourage
people
to
commit
test
cases
to
this
particular
directory.
So
having
like
a
workflow
for
that
established
totally,
I
don't
think
we
want
to
be
responsible,
especially
given
the
scope
of
the
team
to
like
reach
out
to
individual
people.
A
D
Yeah
yeah
yeah,
so
once
we
make
that
more
like
automated
and
prod
framework,
though
it
basically
reduce
the
maintenance
cost.
At
the
same
time,
I
think
I
we
always
have
the
question:
have
we
heard
people
reporting
certain
things
it
may
make
it
make
make
the
decisions
easier
once
we
already
have
those
resources
provided
by
users.
D
A
I
think
it
will
never
be
a
starting
point
to
get
the
answer
to
that
question.
Just
because,
like
the
portion
of
users,
who
will
bother
to
actually
contribute,
is
going
to
be
a
small
small
slice
of
what's
out
there.
But
that
said
that
doesn't
mean
it's
not
worthwhile
like
it's
definitely
better
to
have
more
internal
data
and
more
enforcement
of
what
constitutes
a
breaking
change
than
not
that's.
Definitely
a
good
thing.
C
C
A
I
just
wanted
to
mention
on
the
composition
side.
I
probably
won't
do
a
regular
stand
up
for
it,
because
the
core
code
is
out
there
and
there's
a
list
of
issues
that
need
to
be
tackled
before
it
could
be
merged
just
because
it
won't
be
helpful
without
the
issues
tackled
first
and
it's
not
a
burning
priority
for
the
customized
project
compared
to
other
issues
that
we're
facing
right
now.
So
on
the
roadmap.