►
From YouTube: Kubernetes SIG API Machinery 20180214
Description
For more information on this public meeting see this page: https://github.com/kubernetes/community/tree/master/sig-api-machinery
A
B
B
Not
sorry
I'm
here
I
just
was
waiting
for
which
I
should
start
yeah
go
ahead
and
start,
please
I'm,
not
sure,
okay,
so
alright,
this
is
my
first
time
attending
these
meetings
and
I
made
a
mistake
and
I
wasn't
aware
that
I
have
to
share
the
the
proposal
document
with
the
mailing
list
for
an
aspir
commenced
before
so
I.
Don't
think
if
anybody
has
read
the
document
yet
and
I,
don't
really
I,
don't
also
take
it.
Many
people
need
the
introduction
to
the
concepts.
That's
Hindi
proposal.
Louder.
I
can't
hear.
C
B
B
Explanation,
so
what
it
is
is
that
kubernetes
is
already
providing
a
swagger,
an
open,
API
definition
and
I.
Take
that
definition
generally.
The
swagger
definition
generally
for
people
is
either
used
for
its.
It
could
be
used
for
generating
browsable
and
dynamic
interactive
documentation.
At
the
same
time,
you
would
be
able
to
generate
robust
clients
with
it
and
also
use
it
for
generating
test
cases
for
the
for
your
clients
of
your
server
and
I
think
the
current
swagger.
B
A
C
C
B
That's
like
I
I
was
trying
like
D
I
saw
generally
look.
This
is
not
on
problem
that
only
we
have
like
I've
seen
in
github
issues.
People
have
in
this
issue
regularly
and
the
solutions
that
already
exist
is
either
having
a
manually
wrapper
that
you
have
to
maintain
yourself
and
Intuit
those
information.
That's
validation,
criteria
in
this
step
from
say
from
swagger
to
JSON,
schema
I
think
is
something
like
fabricators
doing
or
other
approaches
is
like
something
that
we
would
like
to
do
that
jason'll
patches.
That
would
inject
that
information.
B
So
we're
not
duplicating
efforts
of
duplicating
code.
So
I
have
this
his
proposal
him
after
that
he's
a
requirement
to
formally
verify.
What's
what
we
wanted
to
add
to
the
kubernetes
and
there
are
a
couple
of
recommendations
in
this
proposal.
They
are
in
the
type
of
gists
and
github
and
they
are
heavy
on
reflection.
So
not
very
heavy
reflection.
Input
condors
use
the
reflection
to
see
whether
those
types
already
kubernetes
source
code
and
reusing
those
validations
or
the
enum
values
that
already
present
intravenous.
D
A
I
I
think
the
proposal
is
about
adding
adding
adding
static
validation
to
go
to
lead
guys
back,
like
we
know,
strength
importance
to
a
reject
put
that
in
this
bag.
We
know
there's
a
minimum
maximum
value
on
again
with
that
in
the
spec,
so
I
actually
think
there's
two
kinds
of
validation.
There
is
that
sort
of
validation
which
you
can
express
like
this
is
technically
and
there's
another
kind
of
validation,
which
you
can't
really
express.
A
D
A
By
my
own
boss,
suppose,
I
think
the
ideal
version
of
this
is
that
in
our
go
types
definition,
we
specify
anything
that
can
be
statically
validated.
We
specify
that
within
your
tag,
and
then
there
general
are
generated
which
currently
generates
open,
API
spec
puts
then
amil
kanika
expect
in
the
correct
way
and
also
constructs
the
source
code
that
we
have
today
for
making
those
rules
for
validating
the
lens,
which
cannot
be
validated
statically.
So.
A
F
The
question
of
what
drives
what
right
so
for
the
types
we
have,
the
native
types,
if
you
drive
static,
validation
off
of
annotations
on
fields
or
tags
on
fields,
and
that
can
both
generate
open,
API
documentation
and
generate
validation.
That's
when
I
just
suggested
yeah
for
CDs.
We
don't
it's
being
driven
by
the
open,
API,
validation,
spec.
So
the
source
of
the
validation
is.
G
F
One
thing
that
we've
seen
around
validation,
especially
is
that
involving
an
API,
can
sometimes
mean
relaxing
validation
and
allow
no
values
in
the
future,
and
that
can
be
done
if
the
API
servers
that
are
doing
the
validation
agree
on
what
the
new
allowed
set
of
things
is.
But
if
you
have
clients
that
are
doing
their
own
client-side
enforcement,
that
you
can
get
cases
where
a
client
will
reject
will
refuse
to
handle
something.
Thinking
it's
invalid
when
in
the
actual
API
server
and
the
cubelets
feeling.
A
F
E
I
G
F
Done
server-side
we're
not
distributing
that
responsibility
to
all
clients.
So,
yes,
the
server
should
absolutely
be
able
to
validate
what
it's
submitted
to
it,
but
as
soon
as
you
distribute
that
responsibility
to
clients,
especially
if
it's
clients
generated
from
a
point
in
time
version
of
an
open,
API
spec,
you
run
the
risk
of
clients,
not
applying
validation,
correctly
or
being
pinned
to
an
old
version
of
what
was
allowed
and
not.
A
D
Is
another
aspect
of
proposal
saying
that
you
like
the
validate
the
pattern
matches
for
Strings
a
currently
a
pattern
match
is
opaque.
There's
no
way
trying
to
say
is
that
this
has
to
be
like
you,
that's
format.
It
seems
like
that's
a
shortcoming
of
the
JSON
schema
specification
which
is
embedded
in
the
open,
API
v3,
but
it
doesn't
provide
a
way
to
provide
like
a
comment
about
a
pattern
match
saying
what
its
intent
is,
and
this
question
is
for
the
proposer
and
sorry.
B
Take
over
one
Chad
is
that
when
I
said
go
inside
validation,
I
didn't
really
look,
I
think
I
should
be
more.
I
should
be
more
clear
on
that,
and
what
I
meant
is
would
be
very
good
for
property
based
testing.
So
when
you
have
a
client
that
you
could
you
wanted
to
like
in
your
estate
affair
application
you
want
to
test.
B
Your
property
based
mystic
and
for
or
the
case
for
existing
having
both
the
the
regex
as
a
as
a
format
and
also
a
pattern
in
there
is
that,
like
some
languages,
which
have
better
type
system
like
more
strong
type
system,
you
could
also
have
refined
types.
So
the
idea
is
that
we
could
have
a
refined
type
which
gets
translated
to
the
host
languages
and
whatever
type
system
that
it
provides.
B
A
E
The
meeting
next
time
we
talk
I
would
like
to
have
a
clear
indication
of
whether
and
how
we
would
try
to
use
tags
and
our
API
types
to
validate
information
server-side
and
how
it's
going
to
interact
with
the
server-side
internal
versions
that
do
not
match
the
externals.
So
that's
a
concrete
question:
I
have
it
wasn't
answered
to
propose
yeah
I,
think
yeah
doesn't
know
next
time
we
talk
about
it.
I'd
like
I'd
like
to
know
the
answer
to
that
yeah.
A
J
J
E
J
To
prevent
stuff
like
of
tracing
but
also
to
timeout
requests,
so
usual
pattern
is
so
I
bought
it,
and
so
you
know
I
get
an
agenda
so
to
have
the
first
argument
called
context.
That's
pretty
common
in
other
libraries.
We
don't
have
such
we
might
want
to
have
set,
but
of
course,
breaks
for
client
calls
of
sub
party
library
of
users.
Oh
of.
J
E
F
Mean
if
the
originating
call
is
from
a
user,
then
if
they
don't
care
about
open
tracing
or
timeout
or
cancellation,
then
they
don't
need
to
use
context,
I
kind
of
like
the
with
context
approach
and
if
everything
we
generate
makes
use
of
that
and
plumbs
something
through.
Then,
if
you
provide
a
context
at
the
entry
point,
then
you
can
use
open
tracing
and
cancellation
and
time-out
capabilities,
and
if
you
don't,
then
you
don't
care
about
those
things.
A
Walters,
somehow
convinced
me
that
it
was
proper
to
use
context
as
the
first
parameter
of
the
call
it's
actually
in
the
golang
context,
where
it
specifies
that
it
should
be
the
first,
the
first
variable
and
main
method
signature.
So
I
guess
I
see
three
options
here
like
we
can
do
it
the
way
the
documentation
says,
do
it
with
a
additional
optional
method
that
doesn't
break
the
doesn't
break
the
interface
for
existing
clients,
or
we
can
just
not
do
it
at
all.
E
A
E
J
E
J
A
What
I
do
is
just
mechanically
use
context
that
to
do
at
every
call
site
very
trivial,
like
mechanical
change,
yeah,
the
other
thing
I'll
say
is
once
it's
there
I
think,
there's
benefits
that
we
can
get
I
mean,
for
instance,
if
we
can
convince,
even
if
it's
just
other
control
playing
clients
to
use
context
and
to
tell
us
at
what
point
to
give
up
on
a
request.
This
gives
us
better
options
when
we're
overloaded.
A
A
E
A
A
E
A
A
E
A
G
F
Think
of
any
other
than
my
head,
those
most
of
the
use
cases
that
I
see
context
being
used
for
outside
of
tracing
and
timeout
and
cancellation
are
typically
like
bucket
of
parameters
that
was
easier
than
actually
adding
the
parameter
to
the
interface
and
I
and
well
I.
Don't
think
that's
a
good
idea!
Yeah.
A
It's
also
supposed
to
allow
for
I
think
this
is
hard
for
us
and
the
client,
but
it's
supposed
to
allow
for
things
like
easy
detection
that
requirement
and
another
required
HTTP
call
that
uuk
made
has
failed
and
so
that
this
one
can
then
this.
This
part
of
the
call
Joanna
parallelized
request
pattern
that
this
one
can
also
then
just
give
up.
G
A
E
E
A
I
mean
if
I
had
to
make
a
decision,
I'd
make
I'd
say
we
should
just
go
ahead
and
add
it
as
the
first
argument
to
all
of
our
oh
I'm,
also
going
to
suggest
that
you
know
as
the
one
who
caused
this
problem.
If
cloud
provider
is
already
pushing
a
change
like
this,
through
that
some
people
may
have
to
there
are
some
clients
may
have
to
modify
you
don't
want
to
come
to
corner
later
and
be
the
oh
you're
doing
this
to
me.
A
A
E
J
E
D
F
So
far,
we're
just
talking
about
in
process
we're
not
talking
about
crossing
process
boundaries
like
an
API
point
where
you
could
inject
like
a
request,
ID
or
something
I,
guess:
I
I,
don't
know
enough
about
the
language
specific
clients
we
generate
to
know
if
they
convention
for
those
yeah.
The
context
pattern
is
a
go
language
specific.
A
E
A
C
So
I
added
a
section
to
the
designer
for
for
the
timeline.
What
I
want
to
get
out
of
this
meeting
is
to
see
if
we
can
agree
on
the
first
part
of
the
timeline
that
is
1.10
and
that
is
implementing
only
the
alternative
version
field.
It's
useful
for
promoting
versions
without
change
from
alpha
to
beta
or
better
to
you,
know
stable.
If
there
is
no
change
or
if
there
is
only
added
fields.
The
users
like
history
can
can
benefit
from
this
a
lot
they
can
do
the
live
updates
from
one
version
to
another.
A
E
A
D
A
D
Believe
that
there's
possible
to
design
an
API
that
supports
three
different
categories.
One
is
we'll
call
the
mill
conversion
which
is
common.
The
next
is
a
renaming
type
of
declarative
conversion.
The
third
one
is
like
complex
conversion
requires
a
webhook.
We
think
all
three
of
those
use
cases
can
be
covered
with
one
API.
C
E
So,
ok,
let's
just
take
the
simplest
case
right,
let's
say:
let's
say
you
want
a
list
of
alternative
versions,
so
you
say
you
know
what
we
have
a
list
of
alternative
versions
as
simple
as
possible
things.
We
do
make
a
string
field,
a
slice
takes
alternative
versions
and
then
we
store
in
one
version
and
we
have
alternates
and
maybe
I
preferred.
Then
along
comes
the
idea
of
declared
your
conversion
mapping
one
field
to
another:
I,
don't.
D
Alternative
version
can
be
defined
in
one
of
three
ways
way.
One
is
that
it's
identical
to
these
two.
The
primary
version
way
to
is
that
it
differs
only
through
like
static
through
stamp
transformations
that
are
equivalent
to
like
the
declarative
is
like
saying:
transform,
schema
a
base
schema,
and
the
third
way
is
to
say
it's
a
totally
different
schema
trust
me,
and
this
web
hook
will
help
us
get
get
the
data
there.
So
I
can.
A
A
This
is
what
I'm
this
is
where
I'm
going
is
I.
This
isn't
a
good
meeting
for
designing
this,
so
the
only
like
possible
way
that
we
can
give
a
decision
here
is
by
delegating
that
really
giving
some
people
or
group
of
people
the
ability
to
say
yes
on
this
thing's
behalf
later
on
in
the
week
when
we
have
a
concrete
design,
I.
E
C
C
F
Call
it
like
a
proof
of
concept
that
demonstrates
a
couple:
storage
versions
is
one
thing,
but
as
soon
as
you
talk
about
allowing
multiple
versions
in
making
sure
that
we
can
make
guarantees
around
the
whole
lifecycle
is
incredibly
important.
So
as
soon
as
things
become
mutable
like
being
orderly
and
how
we
manage
changing
it
and
then
changing
it
back
or
orphans
and
storage
I
really
want
to
make
sure
we're
careful
around
the
changes
we.
So
we
don't
end
up
with
data.
That's
persistent
that
we
don't
know
what
to
do
with,
but
here
we.
C
A
I
I
do
want
to
make
them
like
David
asked
what
the
pressing
need
is.
I
just
want
to
make
the
point
that
many
users
are
using
CR
DS
already
in
production
on
their
own
behalf,
and
others
are
avoiding
CR
DS
in
favor
of
aggregated
API
servers,
specifically
because
of
the
lack
of
support
for
versioning.
So
it
is
a
critical
feature.
I
do
want
to
do
the
right
thing
and
not
the
same
thing.
So
I
certainly
appreciate
that,
but
I
this
is
not
an
academic
exercise,
is
to
solve
real-world
case.
It's
sure.
F
D
E
No
no
I
mean
let's
be
fair
right.
It's
not
like
this
proposal
has
languished.
It's
had
good
discussion
on
it.
It's
been
through
several
iterations.
It's
been
actively
worked,
no
one's
trying
to
halt
it
or
slow,
walk
it.
It's
just
that
it's
different
very
often,
and
it
reduces
confidence
that
we
would
get
an
ad
by
last
minute.
Correct
and
yes,
I
am
definitely
open
to
follow-up
discussion
for
a
design
see
if
we
can
find
something
that
we
think
is
going
to
have
longevity.
A
All
right,
I
will
contact
people
or
a
or
many
people
can
say
in
slack.
They
think
they
need
to,
and
the
sinc
can
trust
that
David
and
I
are
not
going
to
sign
up
for
something
that
a
good
idea
for
the
both
of
the
project,
so
I'm
good
yeah
sounds
good
to
me.
Okay,
we
are
almost
out
of
time.
I
have
started,
circulating
a
design
for
moving
queue,
control,
apply
into
various
aspects
of
the
control
link.