►
Description
Meeting notes https://docs.google.com/document/d/1ushaVqAKYnZ2VN_aa3GyKlS4kEd6bSug13xaXOakAQI/edit#
A
A
If
you
want
to
get
access
to
the
google
doc
you
have
to
to
to
join
the
secretary
cycle
mailing
list.
Also,
we
have
a
mythic
etiquette
for
for
this
meeting.
You
have
to
use
the
the
eraser
and
the
feature
of
zoom
before
speaking,
and
I
will
do
my
best
to
to
to
follow
everyone
and
give
everyone
a
room
if
you
want
to
sign.
If
you
have
some
topic
that
we
want
to
talk
about,
feel
free
to
edit
the
agenda
and
other
new
topics.
A
A
Okay,
I
don't
see
and
raise
the
let's
move
on
so
open
proposal.
Readout.
Is
there
someone
that
that
want
to
give
an
update
on
on
a
open
proposal.
B
Hi,
I
just
wanted
to
bring
up
that.
We
have
a
proposal
for
the
cluster
api
runtime
hooks
for
add-on
management.
This
is
the
one
that's
built
on
top
of
runtime
sdk,
we're
still
looking
for
reviews.
So
if
anyone
can
provide
feedback
and
review
the
google
talk,
that
would
be
greatly
appreciated
and
depending
on
the
feedback
that
we
get
there,
we
are
planning
to
open
a
pr
for
this
towards
the
end
of
the
week.
C
Hey
about
the
machine
pool
machines,
we
got
some
really
great
feedback
this
week
from
you
fabricio
and
alberto
and
cheyenne,
and
thank
you
very
much.
I
think
we
have
good
answers.
Everything
and
I'll
probably
finish
updating
today
and
just
thanks
everybody
for
taking
a
look
at.
I
think
it's
moving
forward.
A
Thank
you
matt.
If
I
may
add
something
to
these
for
the
ibm
proposal
with
jacob,
we
started
a
tread,
and
probably
next
week
we
are
going
to
have
a
focus
meeting
trying
to
helping
in
in
moving
the
proposal
over
the
line
so
to
resolve
the
the
the
biggest
comment
of
comments.
So,
if
you
want
to
do
the
same
for
other
proposal,
I'm
yeah
I'm
up
for
deep
dive
and
try
to
help
as
much
as
possible.
Everyone
else.
C
A
Okay,
thank
you,
and
yes,
yes,
scene
is
is
yeah.
He
is
writing
in
chat
that
that
is
going
to
add
into
the
gender
some
notes
about
the
the
meeting
for
the
iphone
proposal.
Next,
one
is
jack.
If
I'm
not
wrong.
D
Hi
everybody.
I
wanted
to
just
add
a
brief
comment
about
the
add-on
orchestration
proposal,
so
that
was
that
was
your
proposal
initially
fabrizio
so
fabrizio
and
jonathan
and
myself
had
a
really
great
conversation
on
friday
about
the
state
of
this
and
what's
left
to
fill
out
in
terms
of
the
proposal
and
so
we're
going
to
start
getting
more
jonathan,
myself
are
going
to
start
getting
more
involved
there.
D
This
is
going
to
be,
I
think,
much
more
active
in
the
coming
weeks
and
then
I
also
wanted
to
share
an
outcome
of
that
conversation,
which
is
that
jonathan
and
I
are
actively
prototyping
something
in
a
mvp-like
way
to
partly
continually
inform
how
this
proposal
might
end
up
and
also
to
explore
the
idea
of
implementing
this
outside
of
cluster
api
itself,
at
least
initially
as
a
way
of
sort
of
unblocking
functional
demos
and
just
making
us
materially
feel
like
we're
making
progress.
D
So
if
anyone
is
interested
in
this
proposal,
please,
in
addition
to
fabrizio,
feel
free
to
hit
myself
jack
francis
or
jonathan
tong
up
on
slack
comment
on
the
proposal,
I
think
that
their
their
eyeballs
on
it
right
now
so
we'll
see
those
comments
fairly
actively.
A
Thank
you,
jay,
just
adding
literal
marks,
so
the
idea
of
the
mqp
is
is
just
a
way
to
move
fast,
explore
problem
and
also
a
way
to
give
a
comment
to
give
feedback
to
the
community
as
frequent
as
we
can
about
the
direction.
So
there
muppy
is
just
a
way
to
explore
is
not
a
way
to
steer
away
from
the
community.
E
Yeah
hi-
I
just
wanted
to
add
here
that
we
move
the
cluster
api
state
matrix
proposal
to
a
per
request.
We
also
added
a
point
at
the
agenda
more
on
this.
Then,
when
we
go
through
the
engine,
I
think.
A
Okay,
so
we
will
get
to
this
data.
Some
other
update
I
see
jack
with
the
essentially
raised,
is
from
before
okay,
so,
okay,
let's
move
on
with
the
agenda
then
so
first
one
is
christian.
We
first
test
matrix.
E
The
tldr
is,
it
will
be
a
new
component
in
the
experimental
directory
at
the
cluster
api
repository
and
initially
we
want
to
do
or
implement
it
using
a
opt-in
mechanism,
so
maybe
yeah
for
being
able
to
enable
it
using
the
tilt
configuration
like
doing
for
prometheus
or
the
de-logging
extension
yeah.
We
will
also
have
to
then
figure
out
how
to
or
where
to
push
the
new
image
to
and
so
on.
E
Yeah
yeah.
E
I
don't
know
if
there's
some
idea
that
this
thing
is
will
be
experimental,
will
be
a
bit
will
be
isolated
from
the
core
copy
stuff.
So
we're
not
heating
any
issues
here.
It
will
have
its
separate
go
module
because
it
will
have
some
dependencies
from
cube
state
matrix.
So
we
don't
mix
up
things
there.
E
A
Okay,
since
no
I
I
just
echo
mine,
I'm
really
looking
forward
to
get
these
soon.
A
I
don't
see
blocker,
because,
basically,
what
what
christian
is
proposing
is
is
something
which
is
separated
from
from
from
everything
else
and
as
soon
as
we
have
this
in,
we
will
quickly
achieve
to
make
metrics
available
for
all
cluster
api
developers
using
tilt
and
also
we
will
provide
instruction
on
how
to
install
for
the
wider
community,
and
so
we,
basically,
this
will
trigger,
hopefully
a
nice
feedback
loop
that
will
drive
the
next
step
of
this
effort.
E
So
maybe
to
highlight
what
the
next
steps
would
be
as
soon
as
the
proposal
got
merged.
The
folks
said:
mercedes-benz
will
then
create
a
pull
request
to
contribute
this
their
existing
implementation
to
the
experimental
directory
and
with
some
cleanups
and
fixes,
of
course,
to
match
the
proposal
and
then
follow
upper
requests.
A
So
if
there
are
no
question
for
christian,
we
can
move
to
the
next
point,
which
is,
I
hope,
to
pronounce
it
well.
F
Yes,
that's
correct
for
intention,
thank
you
and
I
am
quite
new
for
this
community.
So
should
I
introduce
myself
briefly
interesting?
F
Okay,
I
I'm
hirom
from
ntt
in
japan
we
are
a
telecommunication
company
and
we
are
now
planning
to
use
a
cluster
api
for
managing
cluster
and
we
want,
as
I
write
here
as
I
wrote
here,
how
we
want
to
deploy
the
same
applications
which
uses
hardware,
acceleration
features
running
on
different
platforms
like
aws
or
open
start
at
the
store
and
the
the
problem
for
us
is
we
want.
F
As
I
said,
we
want
to
use
hardware
acceleration,
but
there
it
seems
platform
specific
configuration
like
like,
like
a
url
I
put
here,
so
we
we
need,
we
want
to
integrate
these
kind
of
steps
into
a
common
interface.
F
So
what
I
want
to
ask
today
is
that's
such
goal.
Much
to
the
the
goal
of
this
community,
I
mean,
if
I
propose,
if
I
will
propose
such
features
to
class
api,
is
it
feasible
for
you
all
or
it's
unreasonable?
G
Yeah,
so
I
think
indeed
like
in
general
device
management
in
cluster
api
has
always
been
a
something
where
we
we're
lagging
a
bit
like
either
networks
like
network
cards
for
like
for
gpus,
but
for
gpus.
It
is
a
bit
harder
because
there's
definitely
like
like
there
are
different.
G
Definitely
differences
between
how
it's
done
on-prem
and
in
public
cloud,
especially
when
you,
when
we
think
about
public
cloud
like
you,
have
to
choose
the
instance
type
and
that's
like
pretty
much
what
you
have
to
do
where,
in
you
know
in
on-prem,
you
have
to
you
have
to
deal
with
nuances
such
as
like.
Do
you
want
your
gpu
to
be
consumed
through
pci
faster?
Do
you
want,
like
your
gpu,
to
be
virtualized
and
such
so?
I
think
it
might.
G
It
might
be
hard
to
like
to
find
a
common
abstraction,
but
like
yeah,
if
you
have
an
idea
or
something
totally
welcome
to
read
an
issue
and
comment
on
it,.
F
Alright,
so
let
me
confirm,
let
me
just
confirm
the
direction,
how
direction
of
my
proposal
is
not
conflict
and
not
conflicting
with
your
direction
right.
H
F
Sorry,
I
I
don't
get
it,
what
what
does
it
mean
layer.
H
Well,
so
I'm
trying
to
understand
you
know
what
like
so
right
now,
if
you
want
to
have
accelerated
hardware
support
for
a
given
platform,
the
the
actuator
for
that
platform,
whether
it's
aws
or
gcp,
needs
to
have
that
acceleration
added
to
it
specifically.
H
So
I
think
if
you
know
if,
if
you're
interested
in
adding
acceleration
for
specific
hardwares
to
each
of
the
different
actuators,
I
don't
I
don't
that's.
Definitely
in
line
with
with
what
the
project
is
doing
and
I'm
sure
people
would
appreciate
those
type
of
things
I
was
trying
to
understand.
Were
you
asking
for
an
for
an
api
layer
above
the
infrastructure
machine
template
or
or
are
you
okay
with
defining?
F
I
get
it
I
I
I
accept
a
separated
template.
I
I
mean
like
a
like
a
one.
One
option
we
told
is
adding
an
option
to
client
class
the
ctl
to
enable
gpu
features
for
each
provider,
so
so
that
the
cluster
ctl
can
make
a
yamo
file
manifest,
which
enables
gpu
features
corresponding
to
its
platform.
H
F
I
H
So
I
mean
that
that
would
necessarily
involve,
I
think,
putting
you
know
some
specific
logic
into
the
cluster
ctl
templating
engine.
You
know
so
that
it
could
know
how
to
do
the
specific
thing
for
each
provider
that
that,
I
think,
is
where
it
might
start
to
get
complicated.
A
Let's
continue
that,
then
I
will
comment
on
this
one.
So
next
one
is
cecilia.
J
Yeah,
I
think
this
is
not
talking
specifically
about
gpu.
I've
actually
heard
similar
feedback
from
users
before
that
cluster
api,
like
it
like
kind
of
falls
short
of
like
allowing
you
to
fully
not
care
about
infrastructure,
because
you
still
need
that
platform
specific
knowledge
of
knowing
what
vm
sizes
you
need.
J
If
you
need
that
number
of
like
cores
in
like
different
cloud
providers,
how
that
is
different,
on-prem
et
cetera,
like
you,
still
need
to
have
some
some
like
platform,
specific
knowledge
and
configure
those
like
machine
types
like
specifically
in
the
infrastructure
provider
crds,
and
then
there
might
be
some
inconsistencies
in
how
those
configurations
work
across
providers
so
like,
for
example,
gpu.
J
I
think
it
works
a
bit
differently
in
cap
z
versus,
like
kappa,
so
I
think
like
this
might
not
be
an
easy
thing
to
sell
that
we
can
just
open
a
pr
for
but
like
if
we're
thinking
like
long
term,
it
would
be.
I
mean,
really
cool
if
we
thought
about
how
we
can
maybe
abstract
this
another
layer
and
have
some
sort
of
way
that
you
can,
as
a
user.
Just
describe
what
you
want
say.
J
G
Yeah,
I
I
guess
like
like
in
the
very
very
short
term
like
if
you
want
huge,
to
have
something
like
that,
like
an
option
can
be
to
rely
on
rely
on
various
flavors
for
like
for,
like
all
the
providers,
and
then
you
can
select
the
gpu
flavors
depending
on
the
platform
you
want.
Is
it
like
in
general,
like
yeah?
I
I
kind
of
agree
that
we
are
falling
short
like
in
in
general,
like
for
for
device
management
in
cluster
api.
A
H
Yeah,
so
I
guess
I'm
thinking
about
this
from
kind
of
like
the
user
experience
perspective
and
the
cluster
ctl
angle
like
given
that
every
if
this
was
to
be
centralized
in
like
something
like
cluster
ctl,
because
every
provider
could
have
a
difference
in
the
way
they
do
this,
I
think
it
would
be.
It
would
be
a
difficult.
H
You
know
like
specify
these
kind
of
cluster
class,
or
you
know
these
high
level
constraints
from
the
command
line.
I
don't
have
an
answer
per
se,
I'm
just
asking
questions.
I
guess.
A
I
let
a
scene
to
speak
and
then
I
I
want
to
say
something
on
this
one,
but
I
don't
have
a
razor
end.
So
that's
that's
another
one,
okay,
okay,
so,
first
of
all,
thank
you
for
coming
here.
A
This
is
definitely
the
the
right
place
to
have
those
discussions,
and
I
I
think
that
there
are
two
points
in
in
in
your
request
and
in
the
feedback
so
that
we
have
so
first
one
is
that
we
can
do
better
in
in
having
consistency
across
providers,
and
this
is
a
discussion
that
yes
scene
is,
is
kind
of
driving
and
we
would
like
to
error
so
if
we
think,
if
we
notice
difference
which
are
across
providers
that
are
not
justified
by
the
underlying
infrastructure,
just
design
choice
made
by
the
different
team
and-
and
there
is
room
for
harmonizing
stuff-
is,
let's
raise
the
point
and
we
are
always
looking
to
improve
and
become
more
consistent
as
a
system.
A
This
is
the
first
point,
second
point
and
yeah
just
for
reference.
We
discussed
these.
I
don't
know
for
the
control
plane
endpoint
recently
and
the
gpu
and
could
be
another
point
with
regard
to
a
possible
solution
for
now
I
will
remind
there
was
someone
other
this
in
in
the
chat
as
well,
so
we
have
another
option
today,
which
is
a
cluster
class
and
manager
topology.
I
don't
know
if
you
are
aware
of
this
feature
other,
but
I
invite
you
to
take
a
look:
we've
casted
class.
A
Basically,
there
is
now
separation
between
the
person
that
defines
the
template
and
the
cluster.
So
there
is,
you
already
have
a
layer
that
allows
you
to
create
clusters
in
in
in
a
different
on
different
infrastructure
infrastructure
that
they
look
as
almost
the
same
and
all
the
infrastructure
specific
detail
are
kind
of
hidden
in
the
cluster
class.
A
It
is
kind
of
complex.
I
will
link
to
the
document,
the
the
recommendation,
but
it
is
also
really
powerful,
and
this
reminds
me
an
idea
that
that
we
were
discussing
with
some
colleagues
recently
about
having,
for
instance,
a
set
of
cluster
variables
which
are
shared
across
provider
or
a
common.
A
Variables
that
every
everyone
use,
I
make
an
example.
If
you
want
other
to
define
a
variable
for
cni,
we
can
define
one
and
write
this
type
somewhere
in
the
in
in
a
separate
repository
or
in
the
classifier
book,
and
so
everyone
should
not
reinvent
a
variable
for
cni.
It
is
a
common
problem
and
we
can
do
the
same.
Also
for
I
don't
know,
machine
size
or
for
device
type
like
gpu
or
stuff
like
that.
So
we
have
options.
A
My
suggestion
is:
let's
open
an
issue
where
you
try
to
where
you
describe
your
problem
and
from
that
we
we
try
to
decide.
It
is
something
that
we
can
discuss
in
an
issue,
give
you
guidance
or
is
something
that
needs
to
open
a
proposal
to
this,
because
the
problem
is
bigger
or
stuff
like
that.
Is
that
fine
for
you,
okay,.
F
So
I
I'll
open
the
issue
and
it's
better
to
evaluate
elaborate
on
the
program,
and
maybe
we
have
to
propose
some
suggestions,
specific
suggestion
and
and
continue
to
discuss.
It
is
that
okay.
A
Yes,
it
might
be,
in
my
opinion,
the
the
the.
What
is
really
important
is
that
you
try
to
explain
as
much
as
as
better
as
possible
what
we
are
trying
to
achieve,
and
so
we
can
basically
help
you
to
understand.
Oh,
there
is
already
something
that
can
help
you
or
we
need
something
new.
This
is,
let
me
say
the
first,
if
I,
if
you
have
idea,
feel
free
to
express
them.
Of
course
they
are
always
welcome,
but
let
me
say
for
us
to
help
you.
A
F
Okay:
okay,
I'll,
do
that
and
could
you
could
you
please
tell
me
there
what
what
kind
of
feature
you
mentioned,
topology.
A
And
then,
when
you
write
across
the
class,
this
is
a
here.
You
can
find
an
example,
then,
basically
you
can
have
a
cluster
which
is
really
simple,
and
this
cluster
ever
this
topology
field
that
allows
you
to
drive
to
drive
your
your
cluster.
The
the
idea
is
that
just
changing
this,
this
this
class,
you
can
target
a
different
infrastructure.
All
the
complexity
is
eaten
away
and
managed
by
outers,
and
this
is
pretty
powerful.
A
You
can
have
a
variable,
so
you
can
basically
pilot
attributes
for
your
machine
deployment
or
whatever
so
and
yeah
under
here
you,
you
find
all
the
documentation
some
example.
This
is
the
the
feature
I
was
suggesting
to
you
to
look
at.
A
In
this
case
now,
we
support
jesus
basis
to
to
tell
how
your
variable
change
the
template,
and
so
it
is
kind
and
it's
pretty
powerful,
and
we
have
also
proposal
to
improve
the
to
even
improve
these,
which
is
the
cluster
api.
Topology
mutation
look
so
it
it
is.
I
think
that
this
is
an
area
where
the
cluster
api,
the
user
interface,
is
improving
and
I,
from
my
understanding
of
your
requirement,
it
can
really
help
your
case
but
yeah.
I
need
to
read
the
issue
before.
F
A
F
A
That
that's
let
me
say
that
the
first
reaction
that
I
got
to
your
program
but-
and
this
is
something
that
we
have
so,
let's
open
the
issue-
identify
what
are
your
requirements
and
move
on?
Okay,.
A
Okay,
thank
you
again
for
coming
here
and
sharing
your
problem
with
us.
Next
next
up
is
kilian.
I
Yeah,
so
this
is
the
discussion
that
came
up
we're
currently
in
the
process
of
adding
a
new
api
types
as
part
of
the
runtime
sdks.
This
is
the
first
runtime
sdk
pr
encode
after
the
proposal
merge
so
we're
adding
the
extension
config
types.
The
link
is
in
the
agenda,
so
we
got
some
good
reviews
on
the
design.
I
The
api,
including
very
deep,
review
from
joel,
joel
speed,
who's,
been
doing
some
api
reviews
recently
and
one
thing
that
came
up
around
kind
of
ux
and
the
way
our
apis
work,
and
this
reflects
on
the
way
other
parts
of
our
api
are
so
there's
a
few
issues.
The
two
main
ones
are.
I
We
currently
don't
use
this
so
cube
builder,
allows
you
to
tag
fields
as
explicitly
required.
So
there's
this
q
builder
tag,
and
this
actually
doesn't
have
an
effect
on
our
crds.
So
right
now,
fields
can
be
optional
or
required
right
now.
We're
defining
that
similar
to
the
way
kubernetes
does
optional
fields,
have
json
titan
and
empty
they're
pointers
normally,
unless
there's
a
reason
for
them
not
to
be,
and
they
also
have
this
a
specific
optional
tag
and
then
all
fields
that
aren't
optional
are
required.
I
The
idea
here
is
that
we
would
add
in
this
specific
required
tag
into
our
api
types,
and
this
would
have
no
effect
actually
on
our
open
api
spec.
It
would
only
have
an
impact
of
users
being
able
to
look
at
it
and
see
whether
or
not
the
field
was
required.
There's
also
this
sort
of
edge
case
where
an
entire
package
could
be
set
to
optional
by
default,
because
the
way
open,
api
or
q
builder
work,
I
don't
think
that's
a
major
issue,
but
it's
sort
of
nice
to
have
so.
I
I
think
the
issue
here
is:
this
is
kind
of
an
api
change.
It'd
be
slightly
weird
to
do
it
for
just
one
part
of
our
api
and
leave
the
rest
of
the
api
on
the
old
system.
I
So
I
think
the
idea
for
recent
said
this
here
is
to
push
this
the
next
time
we're
reading
the
api
and
add
those
tags
across
our
api
types,
yeah.
Anybody
who
has
any
opinions
on
that
comments
on
it
yeah
it's
linked,
there's
the
top
one.
So
the
second
issue
that
came
up
was
a
broader
issue
of
using
cube
q
builder,
slash
open
api,
so
q
builder,
as
a
tool,
is
able
to
generate
these
open
api
specs.
I
So
you
add
these
q
builder
tags.
It
can
do
this
required
optional
thing,
but
it
can
also
do
more
complicated
validation,
so
it
can
do
things
like
minimum
maximum
integers.
It
can
do
things
like
regex
max
matching
different
things
like
that,
like
making
sure
things
are
urls
stuff
like
that
today,
we
do
all
of
this
validation.
I
Sorry,
today
we
do
have
some
of
this
q
builder
validation,
sort
of
randomly
across
the
different
apis.
Some
of
them
have
it
some
of
them.
Don't
some
have
it
in
some
places,
but
what
we
really
rely
on
for
validation
are
our
web
books,
so
these
are
kubernetes
admission
web
hooks
that
run
every
time
you
create
an
object.
Update
an
object,
delete
an
object
and
they
just
decide
whether
or
not
the
object
is
valid.
I
So
that's
where
we
do
things
like
the
same
types
of
validation,
minimum
maximum
numbers
strings
and
then
some
more
complicated
validation
around
so
there's
some
quite
complicated
validation.
So
one
is
things
like
this:
we
want
to
ignore
version
numbers.
This
is
actually
in
defaulting,
sorry,
but
yeah
I'll,
actually
get
to
that
in
a
second
might
be
clear,
so
one
of
joel's
suggestions
was
that
we
should
move
whole
hog
to
q,
builder
validation
and
try
and
at
least
include
cubicle
or
validation.
Wherever
we
can
there's
a
bundle
of
complex
things
about
this.
I
One
is
that
currently,
if
I'm
right,
cubecuttle
will
run
open
api
validation
on
the
client
side,
but
won't
run
defaulting
before
that.
So
you
end
up
in
a
situation
where,
even
with
the
required
tag,
this
is
an
issue.
Basically,
things
aren't
defaulted,
so
cube.
Cuddle
says
that
your
type
is
invalid,
even
though
the
web
hook
is
ready
to
default
them.
I
We
could
there's
a
there's
an
issue
open
to
deal
with
this.
I
think
it's
linked
there
yeah.
So
there's
an
issue
open
to
deal
with
that,
and
that
is
probably
a
solvable
issue,
but
it
won't
actually
work
for
a
lot
of
our
defaulting.
So
that's
one
issue
and
we
have
an
ordering
problem
of
defaulting
validation
and
then
we're
trying
to
default
in
validation
in
two
different
places.
I
There's
another
issue
around
the
way
we
kind
of
test
things
so
doing
things
in
webhooks.
We
can
actually
unit
test
that
we
can
write
more
complicated
unit
tests.
We
can
figure
out
our
edge
cases
and
stuff.
Once
we
push
stuff
into
the
open
api
schema,
it
becomes
more
difficult
to
test
and
I
think
that's
it
for
the
major
issues.
I
So
right
now
for
the
similar
to
the
required
stuff
for
this
open
api
validation.
I
think
that
is
to
push
it
for
now
not
do
it
on
our
extension
crd
and
instead
to
try
to
tackle
it
later
on
in
a
more
holistic
way.
I
Once
we
understand
so,
I've
taken
an
ai
here
to
kind
of
figure
out
what
all
the
validations
are
and
which
ones
we
would
never
be
able
to
do
in
open,
abio
schema,
which
ones
might
we
might
be
able
to
do
with
some
sort
of
hacks
and
which
ones
we
will
be
able
to
do
easily.
But
I
think
one
of
the
main
issues
here
is
that
there
is
no
way
to
move
fully
to
the
cube
builder,
slash
open
api
system
without
changing
the
way
we
think
about
and
implement
both
validation
and
defaulting
in
capi.
I
A
Thank
you,
let's
see
sorry
before
moving
on,
we
still
we
have
50
million
left
and
still
three
four
four
four
item
in
agenda.
So
let's
try
to
time
box
this
one
we're
seeing
yeah.
G
G
So
I
think
it
might
make
sense
for,
like
smaller
things,
where
you
want
to
ensure
that
okay,
this
field
has
is
a
string.
This
field
is,
might
not
be
empty
or
such
things,
but
as
long
as
we
start
getting
into
a
more
complex
validation,
I
think
it
we're
better
off
with
web
hooks
that
we
can
unit
test.
A
Thank
you
so
first
quick
comment
from
from
me
on
this
side.
So,
first
of
all
I
would
like
to
thank
joel
for
the
feedback.
He
is
really
providing
value
and
and
triggering
an
interesting
discussion.
A
My
only
comment
is
that,
as
I
don't
have
a
solution,
I
would
like
to
better
understand
the
problem,
but,
as
I
kind
of
agree
with
killian's
statement
that
we
are
discussing
stuff,
which
is
not
really,
which
is
more
a
general
approach
than
something
related
to
the
single
pr,
so
I'm
personally
inclined
to
let
the
pr
merge
accord
with
the
current
default
standard
that
we
have
in
the
prod
in
the
in
the
project
and
then
yeah
iterate
on
this
idea.
Try
understand,
talk
with
joe
and
understand
better.
What
is
asking
test
them
to
understand
the
implication.
A
Maybe
we
are
understanding
it
wrong
and
or
we
simply
are
used
to
do
some
things
in
a
different
way
and
we
can
benefit.
But
I
will
not
let
me
say
I
I
will
split
the
the
work
and
the
improvement,
the
dpr
and
the
improvement,
our
guidance.
A
Okay,
is
there
someone
that
wants
to
add
something
to
this
topic?
Otherwise,
kirian?
Could
you
stop
sharing?
I
go
back
to
share
my
should
be
this
one.
H
Yeah
I'll
try
to
keep
this
quick,
so
I'm
just
we
were
looking
over
the
kubemark
provider
repo
and
I
just
want
to
make
sure
that
we
have
like
good
health
there
with
the
owners
or
the
admins
or
the
repository,
and
I
was
wanting
to
reach
out
here
just
to
see
like
do
we
have.
Is
there
like
a?
Does
anyone
know
if
there's
a
link
or
or
some
sort
of
documentation
around
like
how
we're
supposed
to
manipulate
those
like?
How
would
we
add
another
admin
to
the
repo
and
then
like?
A
H
A
Okay,
thank
you.
Next,
one
just
seen.
G
Yeah
so
yeah,
I
started
taking
a
look
at
our
provider's
apis
and
it
seems
like
we
are,
in
some
cases
missing
some
like
consolidation,
where
we're
like
we're
doing
like
provider,
specific
approaches
to
things
that
can
be
probably
brought
up
to
cluster
api.
So
I'm
currently
like
just
an
fy,
I'm
currently
working
on
the
document
to
to
less
to
list
out
those
things.
The
first
obvious
one
that
I
started.
G
You
know
this
were
the
way
we
were
requesting
like
network
network
devices
and
the
second
one
is
regarding
the
taggings
of
of
cluster
api
machines.
So
I
think
yeah
like
overall,
there
might
be
some
areas
where
we
can
consolidate
and
abstract
things
in
cluster
api,
so
yeah
feel
free.
L
Yeah
over
at
the
cappy
provider,
which
is
now
equinix
metal,
if
you
don't
know
peace,
packets,
what
we
used
to
be
called.
We
finally
got
our
long
long
work
done
by
jason,
update
out.
That
puts
us
on
v1
beta
1,
and
now
you
can
use
the
newer
features
and
stuff
well
at
least
the
newer
api
features.
So
there
you
go.