►
From YouTube: Kubernetes SIG CLI - KRM Functions Subproject 20220112
Description
Agenda and minutes: https://docs.google.com/document/d/1x80l4i88F27zSCxSjlhvwFdH6jQAHou1k1ibuXrDTaw/edit#
A
A
A
B
C
D
C
F
F
C
E
A
H
A
Okay,
so
the
first
topic
that
I
have
in
the
agenda
here
is
just
a
quick
mention
that
the
60
lie
maintainer
track
session.
Cfp
is
open
and
as
part
of
that,
the
sig
leads
we're
talking
about
potentially
highlighting
the
sub
project,
because
it's
new,
we
should
tell
folks
what
we're
all
about
and
what
care
and
functions
are
and
why
we
think
they're,
really
cool
and
folks
should
use
them.
So
just
wanted
to
put
that
out
there
and
say
if
you're
interested
in
participating
in
that
session
to
represent
this
group.
A
Obviously
we're
super
new
and
we're
still
getting
started,
but
I
think
it
would
be
a
great
opportunity
for
us
to
participate
in
that
session
in
in
may
and
by
then
we'll
probably
have
more
concrete
things
to
add.
So,
please
reach
out
to
me
if
you
would
be
interested
in
if
you're,
attending,
kubecon
and
interested
in
co-presenting
that
session
as
part
of
the
maintainers
track.
A
The
second
thing
is,
I
just
wanted
to
do
a
quick
check
in
that
this
time
and
cadence
is
still
going
to
make
sense
for
everyone.
We
had
picked
it
based
on
a
little
survey
that
we
did,
but
it
was
a
couple
months
ago
so,
rather
than
just
assuming,
I
wanted
to
make
sure
that
everyone
here
is
going
to
continue
to
be
okay
with
this
time
and
that
no
one
else
who
is
a
key
collaborator
from
your
respective
companies,
was
categorically
unable
to
make
it
now.
A
C
F
So
currently
we
have
seen
a
couple
of
a
couple
of
limitations
of
the
existing
sdk
like
the
first.
The
first
of
all
is
that
it
it
is.
It
has
a
very
big
surface
and
can
be
hard
to
navigate,
especially
for
new
peoples,
so
this
improvement.
We
in
this
improvement
we
want
to
like
provide
some
like
more
generic.
F
F
And
so
so
I
have
discussed
this
with
katrina
before
so
initially.
This
pr
was
like
writing
in
a
separate
package,
but
after
discussing
with
katrina,
so
we
want
to
have
it
in
the
existing
package,
so
I
kind
of
like
refactored,
the
previous
iterations
and
so
right
now
they
are
in
the
cayamo,
slash
athens
framework
package
and
also
the
kayamo
slash
yamo
package,
and
there
are
two
things
I
want
to
point
out
in
this
package
in
this
service.
F
F
So
it's
like
exposed
some
low
level,
yamos
implementation
details,
and
sometimes
it's
not
easy
for
users
to
understand.
So
this
prc
introduced
a
new
abstraction,
called
cube
object
and
it
provides
some
functions
like
get
and
set
so
which,
when
user,
want
to
mutate
a
field
or
get
a
field,
they
can
just
use.
That
can
be
very
handy
on
the.
So
in
the
prs
there
are
godot
links
and
you
can
find
it.
A
Great
question
about
the
the
cube
object
thing
in
particular,
since
you
mentioned
that
one
you
mentioned,
that
it
provides
accessors
for
looking
at
fields
directly
in
inside
the
yaml
to
sort
of
help.
You
dig
through
it,
and
that
is
something
that
our
node
does
already.
It
doesn't
have
a
generic
one
to
access
any
arbitrary
field
using
like
a
json
path
notation,
but
it
does
have
a
bunch
of
specific
ones
based
on
awareness
of
like
the
structure
of
metadata,
in
particular,
since
that's
consistent
across
all
krm.
E
F
F
F
Which
we
have
got
some
user
feedback,
that
a
user
found
sometimes
is
confusing
and
not
intuitive
the
arnold,
and
also
I,
in
my
opinions,
the
arnold,
the
helper
functions
like
get
name
space
and
look
at
each
other.
In
this
thing,
I
think
we
should
move
it
to
the
cube
object,
so
the
arnold
should
only
provide
the
lower
level
helper
staff.
A
F
Oh,
I
I
doesn't
mean
to
have
customized
to
move
away
from
arnold
or
anything
like
that.
I
mean
like
for
for
the
like
customized
maintainers
or
like
type
maintainers
like
we
have
a
lot
of
experience
dealing
with
arnold
so
like
we
may
find
that.
Oh,
it's
not
that
hard,
but
from
the
conversation
with
some
function
developers
they
don't
think
that
way.
I
think
like
qr
object
can
probably
provide,
are
easier
to
dealing
with
this
object
and
so.
F
The
implementation
details
we
can
still
use
our
nodes
since,
like
using
our
node,
it
doesn't
cause
a
problem
for
us
since
we
are
familiar
with
that,
but
for
function,
authors
developers,
I
think
we
can
suggest
them
to
use
the
new
abstractions
which
have
a
a
simpler
interface
and
a
smaller
a
much
smaller
a
surface
for
them
to
like
navigate
so
currently.
For
example,
the
dealing
with
cube
objects,
the
user
mostly
can
just
use,
get
and
set
and
do
the
almost
all
the
job.
F
A
A
So
if
it
would
be
a
solution
to
add
the
generic
setter
to
the
r
node
and
just
have
the
documentation
and
all
our
guides
and
everything
and
all
the
examples
use
that
so
that
we're
promoting
the
easy
way.
Then
then,
maybe
that
would
be
worth
considering,
but
I
definitely
want
to
take
a
look
at
your
pr.
That
sounds
really
interesting
and
really
excited
to
improve
the
sdk.
F
F
E
A
F
F
F
F
And
then
next
we
are
going
to
set
up
the
infrastructure
for
the
for
the
registry
repos
like
ci,
for
the
entry
functions
and
the
release
pipeline
for
the
entry
functions
and
also
cs2
for
both
entry
and
off
of
three
functions.
For
example,
verifying
the
metadata
is
combined
with
our
schema
and
also
we.
F
We
are
going
to
have
a
website.
This
website
will
be
a
interface
that
user
can
browse
and
interact
with
and
it
should
be
able
to
serve
both
the
dynamic
aggregated
catalog
by
publisher,
also,
the
static
snapshot
in
the
catalog
published
by
the
publisher
and
before
phase
2.
I
I
don't.
I
don't
prepare
the
at
least
yet.
We
can't
do
that
when
we
are
almost
done
with
this
one.
I
guess.
A
Yeah,
it
seems
reasonable
to
me.
I
love
the
idea
of
doing
the
helm,
chart
one
as
a
first
kind
of
like
proof
of
concept,
because
that
one
is
going
to
be
super
useful
to
have
community
hosted
version
of.
So
I'm
really
excited
about
having
that,
and
once
we
have
some
the
publishing
infrastructure,
like
I'm
glad
you
put
that
toward
the
beginning
as
well,
because
that
will
allow
our
consumers
to
start
prototyping
their
side
of
things
in
terms
of
catalog
consumption
and
consuming
just
the
functions
themselves
that
we
are
publishing
from
our
new
source.
A
A
A
C
A
A
So
that
the
last
thing
that
we
have
on
the
agenda
is
for
the
I
oriented
that
by
kepp.
Basically,
since
we
are
a
sub-project,
obviously
so
here's
what
I
have
in
the
agenda
functions
registry
is
what
we
were
just
talking
about.
So
I,
I
guess,
is
there
anything
else
to
mention
besides
the
plan
in
terms
of
progress
and
and
what
is
on
the
roadmap
for
the
next
two
weeks,.
F
But
so
for
the
function
registry
for
next
week,
I
think
we
can.
We
will
try
to
first
get
the
render
helm
chart
function
in
the
repo
and
then
this
the
ci
infrastructure
for
the
entry
functions
and
the
the
release
pipeline.
I
guess
that's
pretty
much
for
we
yeah
yeah.
Hopefully
we
can
achieve
this
really.
A
Most
of
customize
is
designed
to
be
used
as
transformers
and
can
actually
be
already
thick.
You
can,
instead
of
using
any
particular
field,
you
can
use
a
full
transformer
config
for
it,
which
is
key
to
this
approach,
but
there
are
some
very
important
fields
for
which
that
is
not
true,
notably
the
generator
fields
themselves,
which,
due
to
an
implementation,
to
detail
of
go
plug-ins,
which
is
how
they
are
built.
A
They
are
not
allowed
in
the
transformers
field
currently,
which
is
problem
number
one
and
problem
number
two
is
the
resources
field
itself,
which
is
in
a
way
the
main
generator
is
not
even
implemented
as
a
generator
at
all.
It's
not
implemented
as
a
plug-in.
It's
baked
into
the
api
module
in
a
way
that
would
need
to
be
extracted
if
we're
taking
a
pure
functions
approach
in
a
composition.
A
So
you
want
to
be
able
to
have
a
kind
resources
essentially
and
that's
not
possible
today.
So
those
are
the
the
main
things
that
are
that
are
preventing
that
pr
for
moving
forward.
Essentially,
all
that
work
has
to
be
done.
Otherwise
we
can
put
a
scaffolding
in
there
and
it
technically
works
and
is
internally
consistent.
But
it's
not
very
useful
because
there's
there's
not
really
all
that
much.
You
can
do
to
kick
start
that
pipeline
with
some
actual
resources
to
transform.
A
A
A
We
have
the
caps
really
emphasize
how
it
can
be
used
to
do
authorization
for
bundles
of
plugins
as
well
to
provide
a
better
strategy
and
sort
of
decoupled.
The
end
user
configuration
of
the
plugins
from
from
the
specification
of
which
controller
implements
them.
So
it's
very
important
part
of
the
proposal
and
hopefully
we'll
make
some
progress
on
that
one
soon.