►
From YouTube: Kubernetes SIG API Machinery 20191023
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
B
C
B
Yeah
so
so
one
way
would
be
to
expose
something
via
discovery.
Just
just
like.
First
up
pops
into
my
head,
you
could
expose
something
via
discovery
that
says
I'm
a
sensitive
resource
and
that
could
be
used
to
inform
and
audit
trail,
and
my
phone
is
ringing
how
embarrassing
I
and
so,
and
so
you
would
have
the
external
notion
in
a
generic
way.
Aggregative
API
server
could
say,
I
am
sensitive
and
then
the
aggregator
would
not
perhaps
a
lot
little
rasta
monstas.
C
So,
okay
I've
got
two
mental
models
for
how
you
could
go
about
doing
this
one.
Is
you
just
marking
particular
fields
as
sensitive
and
if
any
field
is
Markus
sensitive
and
you
want
to
encrypt
the
whole
object
at
rest,
but
that
informs
like
logging?
You
just
exclude
the
sensitive
fields.
The
other
is
like
you,
don't
do
all
that
work,
and
you
just
mark
the
you
just
mark
the
the
resource
as
sensitive.
B
Or
not
so
so,
I
guess
my
my
goal
for
this
conversation
was:
do
we
think
that
such
a
thing
would
be
useful?
I
think
that
it
is
I
want
to
make
sure
that
most
people
agreed
it's
useful
and
then,
if
we
agree
that
as
useful,
we
can
separately
talk
on
slack
about
how
we
could
model
it
and
then
get
back
to
the
sig
off
folks
about
hey
we'd,
be
interested
in
a
kit
that
did
something
like
this.
If
you
were
in
cloud
yeah.
C
B
D
B
C
E
B
B
C
C
B
B
F
In
this
room
or
further
discussion,
the
only
observation
would
be
the
for
logging.
I
mean
if
we
wanted
to
be
sensitive
with
logging
doing
at
a
resource
level.
Basic
is
going
to
mean
that
you
can,
if
you
want
to
be
secure,
all
you
can
do
is
log
the
path
to
the
resource,
but
you
shouldn't
be
logging,
anything
even
the
name
right,
I.
C
B
So
we
can,
we
can
talk
on
the
thread.
There
are
wrinkles,
we
can
decide
whether
we're
gonna
go
after
those
wrinkles
or
not.
Yeah
Jordan
made
the
wrinkles
I
believe
him.
I
was
only
the
guy
that
reviewed
and
approved
yeah
I'm,
pretty
sure
Jordan
causes
the
wrinkles
to
exist
all
right.
So
thanks
for,
let
me
go
first.
Stefan.
C
C
G
C
E
C
C
E
So
what
I
find
natural
is?
Okay,
I
cannot
market.
You
can
see
it
yeah
you
can.
So
this
is
what
I
find
natural
or
consistent
for
whatever
we
do.
When
we
talk
about
equal
objects,
I
expect
if
they
are
equal
before
the
request,
so
on
the
client
side
following
some
equality
definition
I
expect
that,
as
the
request
does
the
same
thing,
if
this
is
not
the
case,
we
would
have
good
reasons
that
we
that
we
violates,
as
this
condition
kimba
in.
E
Means
when
I
have
objects
like
JSON
blobs
on
the
client
side
and
they
are
equal
somatically
like
they
have
different
undefined
and
not
an
empty,
so
some
values
differ.
If
you
really
look
strictly
in
the
object,
but
according
to
this
week,
equality
is
a
as
the
same.
So
when
you
start
with
that,
so
that's
what
I
call
a
equal
B.
This
EQ
I
expect
that
when
I
sent
those
two
objects
to
the
server,
it
was
the
same
request.
E
C
G
H
E
C
E
F
H
F
C
C
E
Expect
it
as
well,
it's
basically
what
we
have
for
native
resources
to
a
certain
degree,
yeah
just
by
deserializing
yeah,
this
problem
that
we
can
just
not
switch
to
semantic
equality
as
a
next
point
at
starting
with
TP
ours
NCATS.
Of
course,
we
never
really
defined
that
to
the
user.
I
think
and
we
were
always
strict,
like
we
stored
everything
s
sent
by
the
user
and
returned
it
s
stored
in
entity
without
any
of
source.
E
H
There's
a
variety
of
client
behaviors,
so
some
clients
that
so
like
go,
treats
missing
items
of
a
key
value
map
very
gracefully,
but
some
languages
will
panic.
If
you
look
for
a
key
that
isn't
there,
and
so
you
submit
an
object
to
the
server
and
that
has
like
a
key
:
null
and
the
server
preserves
that
and
it
returns
it
to
your
client
is
happy
and
if
it
normalized
that
away
so
the
key
was
absent.
C
C
H
B
E
So
so
what
I
get
from
that
we
defined
pretty
bad
semantics
for
our
API,
which
bites
us
now,
and
the
question
is
what
is
the
way
out.
So
we
can
ask
that
later
on
validation
and
defaulting
outposts
in
way
as
I
defined
in
ways
which
needs
to
its
equality.
Validation
can
distinguish
between
undefined
and
empty,
so
you
can
have
objects
which
are
equal,
semantically,
equal,
but
one
as
well
as
other
one
is
not
and
similar
things
to
see
for
thing.
E
You
can,
if
you,
if
you
lose
a
null
or
an
empty
and
it
becomes
undefined
for
some
reason,
because
you
something
like
server-side
apply
or
some
edge
mechanism.
Suddenly
the
object
has
an
undefined
field.
You
see
for
that
and
yeah.
If
you
Center
to
the
server,
maybe
it's
not
it's
a
it
should
be
an
OA,
but
it's
not
anymore
because
of
defaulting
or
it's
not
very
deterring
anymore.
So
the
big
quest
for
a
and
B
is
different,
just
by
defaulting,
whether
it
applies
or
not
and
yeah.
E
C
E
B
Yeah
we
did
not
document
it,
it
was.
It
was
an
artifact
of
the
way
they
were
received
and
deserialize
on
the
wire
into
J's
from
Jason
and
then
stored
back
that
way
now,
I
do
think
we
get
an
opportunity
when
we
introduce
the
whatever
binary
encoding.
We
have.
We
get
an
opportunity
to
say.
If
you
want
to
use
binary
encoding,
it
will
change
what
these
things
mean.
Yes,.
H
C
I
think
we're
getting
ahead
of
ourselves
here.
There's
two
kind
of
separate
questions.
One
is:
how
do
we
want
it
to
eventually
work
like
what
is
what
is
the
proper
way
to
work
and
the
like?
After
we
know
where
we're
trying
to
go,
then
we
can
talk
about.
How
do
we
want
to
get
there?
Like
was
the
what's
the
path
to
to
change
this
cuz?
D
If
you
go
down
a
bit
and
it's
still
subject
to
this
schema,
so
it's
but
there's
a
lot
of.
H
E
E
C
The
the
type
that
we
currently
use
to
store
an
object
probably
faithfully
passes
it
through.
Just
that
not
everything
corresponds
to
like
a
sensible
instruction
right,
like
so
apply,
uses,
presence
or
absence
to
determine
whether
or
not
you
have
an
opinion
about
the
field,
which
means
that
is
very
problematic
to
use,
presence
or
absence
to
drive
some
semantic
behavior
about
the
object.
But.
C
I,
don't
you
want
it
to
be
null
yeah?
You
know,
we've
talked
about
fishery
facilities
right,
we
talked
about
doing
maintaining
field
removals
via
apply.
That
way,
does
it
work
already
today?
No,
but
if
you
said
to
tell
you
to
you
know
it's
because
you
want
the
venue
to
be
no,
you
know
be
the
same
as
removing
it.
No.
B
C
E
Thought
is
here:
you
can
build
something
like
normalization
and
we
can
even
do
it
very
easily.
Is
that
there's
the
old
way
of
nomás
ations
a
new
way,
so
we
just
think
yeah.
E
My
thought
is:
we
have
to
make
this
explicit
for
CID
developers.
There
must
be
a
conscious
choice
that
they
want
a
new
behavior
and
then
they
know.
Of
course,
it's
a
other
API
changes.
Maybe
can
do
it
in
a
new
version
and
you
API
version
to
avoid
breaking
changes
for
the
customers
of
what
they
are
consumers,
but
it
must
be
conscious.
E
C
H
I
C
C
C
Not
good,
if
some
of
our
guys
work
differently
than
other
api's
yeah.
So
do
we
we
we
don't
have
a
meeting
or
a
sync
up
for
the
seer
key
for
our
ongoing
security
work.
Doing
nope
I
wonder
if
we
should
expand
the
apply
working
group
to
consider
schemas
in
general.
That
makes
sense
to
you
Stefan.
Do
you
have
another
idea,
I.
C
E
H
A
client
has
to
compare
if
to
API
things
are
equal,
is
just
like
serialize
to
JSON
and
see
if
the
strings
are
equal,
and
so,
if
we're
depending
on
clients,
even
today
like
we
have
the
go,
DB
semantics,
equality,
helper
and
even
today,
our
controllers
sometimes
get
it
wrong
and
we
have
to
go
fix
bugs
like
if
we
need
to
make
sure
that
whatever
we
ask
clients
of
custom
resources
to
do
is
not
unreasonable
in
random
languages.
Yeah.
C
C
H
I
mean
if
it's
from
a
web
book,
then
you're
still
going
through
a
decoding
pass,
so
we're
using
the
same
decoder,
stack
reading
from
a
TV
and
reading
from
a
web
book
and
reading
from
the
request,
so
that
that's
good.
It's
the
in
process,
things
that
we're
like
setting
a
field
to
a
nun,
sized
int
which
would
round-trip
to
a
size
dent.
That's
where
we
got
into
trouble.
C
C
H
Yeah
I
mean
just
some
degree
of
normalization
on
encoding
like
I'm.
We
do
it
on
the
in
memory
structure,
which
is
fine
if
a
client
was
gonna
do
that,
it
would
have
to
like
encode
them
with
the
same
encoding
settings.
But
most
most
languages
have
a
concept
of.
Are
these
two
objects
equal
and
can
do
like
traversal
or
memory
checks,
or,
like
worst
case,
you
could
include
them
both
to
JSON
and
compare
the
strings?
Assuming
you
have
a
deterministic
serializer
yeah.
C
H
But
also
that,
if
we,
if
we
replace
it
with
another,
go
based
implementation,
that
is
even
if
it's
well
tested
and
detailed
and
principles
and
everything
like
expecting
that
to
be
ported
into
every
language
that
everyone's
gonna
write
a
client
and
like
it
would
be
I.
Think
that's
where
we
get
into.
Should
this
normalization?
Should
this
affect
what
comes
back
to
the
server
like?
Should
the
server
be
responsible
for
any
coercing
or
normalization
so
that
a
naive
client
can
like
get
an
object?
C
Like
to
add
some
color
to
that,
which
is
a
lot
of
our
API,
in
fact,
I'd
argue
most
or
all
of
our
API
is
about
enabling
multiple
controllers
or
agents
to
act
on
the
same
resources
in
parallel
and
not
have
to
necessarily
completely
understand
what
each
other
is
doing
and
from
from
that
standpoint,
like
clients
really
need
to
tolerate
the
controller
or
something
else
coming
in
and
taking
over
part
of
the
part
of
their
resource
in
some
way.
Yeah.
H
A
I
Controllers
that
I've
seen
they're
like
use
the
pattern
of
like
be,
do
some
work
to
do
a
deep,
equal
or
something
I
think
five
people
depending
on
whether
not
they
know
this
we've
got
key
people,
insists
and
then
use
that
to
decide
like
if
they
want
to
submit
to
a
server.
That's
a
fairly
common
powers,
Wow.
G
C
B
C
But
not
all
of
our
controllers
are
need
to
be
performant.
The
ones
that
need
to
be
performant
have
been
changed
to
be
patches
like
the
the
garbage
collector
or
whatever,
but
like.
If
you
look
at
I,
don't
know
the
scheduled
job
controller
like
that
thing
is
not
performing
at
all
it
does
it
like
pulls
the
world
like
every
ten
seconds
or
something.
H
C
Yeah
I
can
buy
that
yeah
ugly,
okay,
I
think
we
have
made
good
progress
on
this
and
we
will
follow
up
on
email
in
that
cabin
at
the
apply
working
who's
eating.
H
J
C
H
You
I'm
not
gonna,
take
long
I
didn't
want
to
call
out
the
the
kept
that
I
just
opened
about
running
conformance
tests
without
beta.
It
guys
enabled
this
is
mostly
on
cigar
CH
and
the
conformance
work
group
front,
but
it
touches
the
API
server
or
the
API
machinery
in
a
couple
places
like
with
making
it
easy
to
turn
off
all
beta
api's
and
turn
off
all
beta
features,
so
I
tagged
us
as
participating
I'll,
throw
a
link
and
I
guess
slack,
but
it's
yeah.