►
From YouTube: 20210826 SIG Arch Community Meeting
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
All
right,
good
day,
everybody,
this
is
kubernetes
architecture
meeting
for
august
26th
2021..
We
have
a
short
agenda,
but
I
think
the
second
one
is
going
to
be
a
little
bit
of
a
talking
extravaganza.
So,
let's
get
started.
Why
don't
rihanna?
You
start
out
with
the
first
item
here.
B
All
right,
thank
you.
It's
a
short
one.
As
all
agreed
in
the
community.
I
changed
the
meeting
to
a
monthly
meeting
to
increase
people's
ability
to
attend
and
the
tests
are
more
getting
more
difficult,
says
less
churn
and
it
takes
longer
to
get
things
on
the
board
so
a
month
they
would
do,
but
I
forgot
to
make
the
pr
to
change
all
the
documents,
so
there's
the
pr
for
the
documents.
If
somebody
can
just
approve
that
for
us,
please.
A
Okay
sounds
good.
Unfortunately,
I
won't
be
able
to
make
the
first
monthly
meeting,
but
hopefully
the
next
one
after
that,
because
you
move
the
time
on
me
all
right.
Okay,
thank
you.
Everybody
any
other
comments
on
that.
C
Yeah,
thank
you
and
I
recognize
that
this
is
somewhere
between
sig,
arch
and
sig
api
machinery.
The
link
I
have
is
just
to
the
mailing
list
thread
which
actually
goes
to
both
sigs
and
we've
had,
I
think,
decent
discussion
around
that
there's.
C
I
think,
there's
any
number
of
ways
to
kick
this
off,
but
I
think
that
the
real
background
for
anyone
who's
missed
the
thread
is
that
as
we're
developing
gateway
api,
when
we
started
with
our
first
alpha
release,
we
had
references
to
using
kind
which,
at
the
time
matched
the
api
conventions
of
the
day
or
what
we
were
used
to
as
we're
moving
to
v1
alpha
2
and
trying
to
become
an
official
cades.I
o
api.
C
The
api
conventions
now
state
that
all
our
reason,
all
our
object,
references
which
we
have
a
lot
of,
should
now
use
resource
instead
of
kind
and
we're
looking
at
this
as
a
project
that
is
already
introducing
a
large
new
api
as
yet
one
more
thing
that
will
potentially
confuse
users,
add
additional
complexity
and
we're
concerned
about
that,
and
so
we're
trying
to
find
ways
to
either
hopefully
be
able
to
continue
with
our
existing
resource
reference
structure,
so
using
kind
or
at
least
understand
more.
C
Why
we
should
move
away
and
have
that
documented
more
clearly,
my
my
you
know,
following
through
all
of
the
thread,
I
was
hoping
that
we
could
come
to
two
conclusions
now.
This
may
be
me
misunderstanding
the
thread
before,
and
I
and
I'm
sure
someone
will
correct
me
if
I'm
wrong
here,
but
it
seems
like
it's
a
bit
of
an
edge
case
to
declare
different
resources
with
the
same
kind
and
group.
It
is
possible.
C
We've
definitely
clarified
that,
but
it's
not
done
in
core,
and
it
seems
like
something
that
adds
a
fair
amount
of
complexity
and
things
like
clients
like
kubecuttle.
Just
don't
behave
well
with
that.
With
that,
so
maybe
adding
a
recommendation
that
that
is
not
something
that
makes
sense
in
a
lot
of
cases
and
then,
secondly,
adding
some
kind
of
guidance
that,
if
you're
going
to
create
an
object,
reference
type
and
it's
going
to
refer
to
different
resources
with
a
shared
kind.
C
D
Thanks,
so
I
want
to
point
out
that
you
don't
know
in
advance
whether
your
kind
is
going
to
be
reused
by
another
resource.
D
D
That
accepts
the
same
kind.
It
accepts
the
same
kind
and
returns
the
same
kind,
and
that
makes
it
compatible
with
hooks,
for
instance,
that
expect
one
or
the
other,
and
there's
no
way
to
know
that
in
core
another
place
where
this
has
significant
utility
is
when
you're
dealing
with
admission
web
hooks,
they
all.
D
C
That's
that's
a
good
point.
I
I
I
was
unaware
of
those
those
specific
use
cases
is
it.
Is
it
fair
to
say
that
those
are
very
specific
uses
of
this
pattern
and
we
can
describe
them
but
yeah?
You
know
like
I.
I
I'm
very
familiar
with
the
gateway
api
use
case,
and
I
know
that
this.
This
kind
of
pattern
does
not
seem
to
make
sense
for
gateway
api
or
anything
that
we're
referencing.
C
C
I
I
think
we
have
a
pretty
good
handle
on
what
we're
going
to
be
representing
or
referencing
in
gateway
api
and
it
it
seems
somewhat
orthogonal
that,
yes,
there
are
some
use
cases
where
you
may
want
to
use
kind
for
more
than
one
resource,
but
that
seems
like
it
has
a
number
of
issues,
and-
and
maybe
we
just
need
to
highlight
the
the
shortcomings
of
that
approach-
not
that
it's
not
valid,
but
that
it,
for
instance,
does
not
play
well
with
coop
cuddle,
as
as
an
example
does
that
seem
fair
or
maybe
that
is,
I
don't
know.
E
One
of
the
things
that
we've
noticed
over
time
in
trying
to
write
the
conformance
suite
is
we
focused
on
the
the
endpoints
or
the
actions
of
how
you
interact
with
the
kubernetes
api,
which
was
the
was
the
easiest
way
to
pick
up
and
hold
and
define
the
the
formal
definition
of
kubernetes
from
a
tested
perspective
when
there
are
different
implementations.
A
F
F
So,
if
we're,
if
we're
trying
to
decide
between
kinds
and
resources
and
how
we
reference
things,
anything
that
is
endpoints
based
is
talking
about
resources,
so
pods
nodes
things
like
that
to
rob's
point.
I
think
there
are
a
few
different
ways.
References
are
used
and
they
have
to
do
with
whether
the
controller
or
whether
the
thing
looking
at
the
api
object
expects.
F
Lots
of
potential
references
pointing
to
data
in
different
locations
when
it
fetches
that
data
the
controller,
expects
to
understand
it
and
expects
it
to
be
uniform.
So
an
example
of
that
is
the
the
auto
scaling
controller,
where
the
references
in
an
hpa
are
pointing
at
different
places.
F
So
that's
using
references
as
coordinates.
Another
pattern
is
where
the
reference
there's
a
small
set
of
expected
objects
and
the
fact
that
it's
modeled
as
a
generic
reference
is
maybe
misleading,
and
maybe
this
was
getting
to
what
rob
was
talking
about
so
like
in
the
rbac
api.
F
And
then
the
third
case
is
where
the
the
reference
can
be
used
as
like
an
extension
mechanism,
and
I
I
think
this
is
what
ingresses
used
references
for,
where
you
have
a
resource
backend
and
you
can
say,
like
whatever
ingress
controller,
is
serving
this
ingress,
like
here's,
a
pointer
to
the
parameters
for
that
controller,
and
it
might
be
some
custom
type
and
it
might
be
like
who
knows
what
it
is,
but
presumably
that
ingress
controller
knows
how
to
interpret
that
data.
F
When
it's
a
pointer
to
some
custom
thing,
you
can
kind
of
fall
into
one
of
two
scenarios,
one
it's
it's
expected
to
be
like
a
crud
type
that
you
could
cube.
Control,
apply
the
thing,
and
so,
in
that
case,
expecting
it
to
be
like
a
one-to-one
like
the
kind
pointing
to
the
first
resource
serving
that
kind
that
cube
control
apply
worked
with,
like
that's,
probably
reasonable.
F
If
it's
the
second
example
where
it's
like
hpa
and
really
you're,
just
trying
to
point
to
an
end
point
where
this
controller
is
going
to
pull
data
from
then
the
resource
side
is
more
important.
So
like
I
can
see
both
sides
like
if
it's
a
crud
type
then
yeah,
it
probably
doesn't
make
sense
to
have
more
than
one
in
the
system
if
you're
going
to
be
controlled.
Applying
this
thing,
it's
not
going
to
work
well
for
you.
If
you're
expecting
to
be
able
to
write
to
some
other
random
resource.
F
If
you're
using
this,
just
as
a
coordinate
for
the
controller
to
pull
information
from,
then
I
don't
think
it's
a
good
idea
to
chop
off
the
power
of
the
api
and
say
nope
like
it
might
have.
It
might
have
worked
great
for
you
to
like
provide
an
aggregated
api
server
that
surfaced
this
information
using
some
totally
different
mechanism,
and
you
speak
these
same
types
in
order
to
be
interoperable,
but
nope
we're
not
going
to.
Let
you
point
references
at
that
thing.
A
So
that
that
I
don't
know
what
you
said
made
sense
to
me,
I
guess
what
I
what
I
would
ask
is:
if
there's
not-
and
this
is-
I
think
what
rob
is
getting
at
too
and
his
thing
is.
Is
there
not
a
a
pragmatic
solution
here
where,
if
you
use
kind
it's
a
sort
of
canonical,
it
represents
a
canonical
resource
location
for
that
particular
kind,
and
that
the
reference
could
alternately,
use,
resource
and
controllers
or
clients
know
when
they
see
kind?
That
means
the
canonical
version
for
built-ins.
A
That's
easy,
I
can't
say
for
other
things
you
know,
but
we
still
allow
resource
in
the
cases
where
we
need
it.
It
would
seem
that
that's
sort
of
aligns
with
the
sort
of
does
what
the
user
expects
it
to
do
type
of
mentality,
as
opposed
to
being
precisely
correct.
F
So
the
the
use
of
resources
and
tests
seems
completely
appropriate
and
okay,
because
that's
not
something
that
users
are
going
to
deal
with
right,
most
users.
I
guess
I'm
just
echoing
what
jordan
said.
Most
users
by
by
count
are
going
to
experience,
cruddy
sorts
of
types,
and
we
have
a
wide
proliferation
of
types
using
kind
for
references
there
already
right.
F
We
wrote
the
these
new
guidelines
new
to
be
pedantically
strictly
correct,
which
means
we
went
the
other
direction
and
I
feel
like
we
are
now
punishing
98
of
our
users,
for
what
two
percent
are
going
to
experience
an
important
two
percent
they're
using
real
use
cases
to
be
sure,
but
most
of
our
users
are
not
going
to
see
or
know
that
they
don't
know
what
resources
are,
and
this
is
my
biggest
problem
with
it
is
no
user
knows
what
these
resources
are,
because
nobody
uses
the
urls
raw
right.
F
They
all
use
command
lines
or
they
use
discovery,
and
so
it's
completely
opaque
to
people,
but
they
have
to
memorize
a
heuristic
for
converting
a
kind
which
they
do
know
into
a
resource
path
and
most
of
the
time,
it's
doing
the
exact
same
thing
that,
like
just
take
the
first
match
right.
It's
except
they're,
doing
it
in
their
head,
so
we're
forcing
our
users
to
do
the
thing
that
I
feel
like
we
should
be
doing
so.
F
F
That
we
currently
have
so
like
that
use
references
or
have
object
that
have
references.
I
think
our
back
is
a
good
example
of
one.
Where
kind
was
fine
ingress
which
is
expecting
to
point
to
objects
which
are
cruddy
is
also
probably
fine
to
use
kind
hpa,
I
would
say,
is
the
clearest
industry
intrigue,
that
of
something
that
should
have
used
resources.
C
Yeah,
that
makes
sense,
and
just
to
clarify,
I
don't
don't
have
too
much
to
add
other
than
just
for
gateway
api.
Specifically,
I
would
say
we're
most
similar
to
ingress
in
the
sense
that
ingress
the
reference
is
to
potentially
a
custom
backend
type,
but
that
any
back-end
type
that
is
supported
is
known
in
advance
by
the
ingress
implementation
that
that's
the
key
and
that's
that's
same
with
gateway
implementation.
C
What
we're
talking
about
here,
as
references
are
entirely
known
by
the
implementation,
the
implementing
controller,
that's
using
the
api,
it's
not
the
more
abstract,
here's
a
reference
to
an
unknown
resource
that
we
want
to
pull
some
data
from.
That's
not
really
what
we're
talking
about
here,
we're
talking
about
a
known
set
of
types
and-
and
that
seems
to
line
up
with
what
you're
saying
here
about
a
kind
probably
being
acceptable.
F
Did
I
jump
to
the
front?
I
I
wanted
to
ask
about
the
hpa
case.
Isn't
it
like
when
we
do
hpa,
I'm
going
to
show
my
little
bit
my
ignorance
here
when
we
talk
about
hpa?
Aren't
we
always
talking
about
the
scale
sub
resource
like
we
can
talk
about
the
the
parent
kind
like
a
deployment
or
replica
set,
but
hpa
itself
is
going
to
go
straight
to
the
sub
resource
right,
but
the
hpa.
F
So
it's
having
to
take
the
kind
and
translate
it
to
a
resource
and
then
call
the
sub-resource
of
that
and
it
doesn't.
It
doesn't
even
really
care
about
what
the
parent
kind
is,
which
is
why,
like
from
its
perspective,
it's
entirely
it's
entirely
about
the
end
point,
but
it's
busy.
It
feels
like
it's
busy
work,
but
it's
hpa
as
a
piece
of
automation
can
absorb
that
busy
work
where
humans
shouldn't
have
to
right.
F
Humans,
crud
the
deployment
or
they
crud
the
replica
set,
or
they
crud
the
stateful
set
and
when
they
point
their
hp
at
it,
they
want
to
speak
in
terms
of
the
thing
that
they
own.
So
that's
assuming
that's
assuming
the
parent
is
always
a
card
object.
If
you
want
to
let
hpa
scale
a
thing
and
the
way
you
interoperate
with
hpa
is
by
exposing
an
endpoint
that
speaks
the
scale
sub-resource.
F
D
F
Or
or
alternatively,
you
have
an
api
but
you're
using
a
kind
that
is
also
mounted
somewhere
else,
so
say:
you're,
managing
machines,
and
you
like
the
cluster
api
and
so
you're
like
why
design
my
own
api.
This
is
a
perfectly
good
kind.
It
expresses
what
I
need:
here's
how
you
can
get
it
and
put
it
and
I've
got
a
scale
sub
resource.
F
This
all
feels
very
hypothetical
and,
like
we're,
punishing
the
user
experience
for
what
feel
like
hypotheticals,
where,
honestly,
the
like
the
pain
of
don't
do
that
like
define
your
own
kind,
like,
I
think,
that's
where
we
flowed
like
we
should
have
made
it
really
trivial
to
say:
here's
a
kind
and
it
tastes
like
or
inherits
from,
or
feels
like
quacks
like
another
type
like
formalizing,
that.
F
Our
type
system,
or
not,
that
proposal
may
be
a
little
late
in
arrival.
So
it's
not
a
not
exactly
a
serious
proposal,
although
if
you
had
appetite
for
it,
I'd
be
happy
to
discuss
it
but
yeah.
What
to
to
your
earlier
comment
about?
No
one
knows
about
resources.
F
Actually,
anyone
who
writes
an
arbac
policy
or
an
admission
webhook
knows
about
resources,
because
that's
how
you
express
policy
that
only
uses
I
will
reassert
that
90
plus
percent
of
users
will
never
write
those
resources.
They
will
just
be
using
them.
D
I
started
talking
and
I
lowered
my
hand,
so
so
the
gateway
resource.
You
said
it
was
going
to
be
a
small
set.
I'm
curious
whether
it's
actually
a
set
that
you
know
so
well,
you
would
hard
code
a
rest
mapping
for
it.
D
C
Okay,
that,
yes,
so
I
think
there's
a
few
things
here
so
gateway
api
com
combines
a
few
resources.
It
we're
calling
gateway
api
button,
it
includes
gateway
and
several
routes.
A
lot
of
our
references
are
within
gateway
api,
so
there
you
may
want
to
describe
how
a
route
attaches
to
a
gateway.
That's
that's
a
reference,
but
we
wanted
to
leave
a
little
bit
of
room
out
there.
C
Instead
of
just
we
default
to
you
attached
to
a
gateway
in
your
object
reference,
but
we
wanted
to
leave
room
out
there
for
implementations
to
provide
their
own
flavor
of
route
parent
their
own.
So
an
implementation.
A
controller
may
include
its
own
set
of
resources
that
it
supports
to
extend
the
api.
The
controller
would
understand
those
resources
and
know
them
because
it
those
would
be
unique
to
that
implementation
of
the
api.
C
So
we
have
this
kind
of
well-defined
core
that
that's
what
we
expect
the
vast
majority
of
references
to
be,
but
we
also
allow
for
implementations
to
bring
and
support
their
own
resources
and
reference
those
using
the
same
reason
reference
types.
This
is
really
similar
to
the
ingress
api,
where
you
support,
for
we
support
forwarding
to
a
custom,
backend
type,
we
don't
it's,
we
don't
expect
that
custom
back
end
type
to
be
knowable
or
understandable
by
a
large
set
of
implementations.
This
is
something
that's
really
implementation,
specific
and
each
controller.
C
Could
I
don't
know
if
any
controllers
actually
using
this
right
now,
but
they
they
could
forward
to
say
a
storage
bucket,
that's
proprietary,
to
their
implementation
of
the
api.
So
that's
really
that
the
kind
of
extension
mechanism
we're
talking
about
here,
a
known
set
of
resources
for
that
given
controller.
F
So
it
is
not
unlikely
that
a
specific
gateway
implementation,
their
their
implementation
of
it,
might
be
like
the
our
back
immunization.
It's
like
we
support
this
one
kind,
and
so,
if
there's
a
gateway,
we're
supposed
to
be
handling,
we
expect
the
reference
to
be
like
this
kind
and
that's
it
and
yeah.
If.
B
F
E
I
feel
like
we,
I
may
not
know
them
as
the
architects,
but
as
we're
exploring
an
api
at
runtime
or
or
doing
writing
performance
the
ability
to
detect
and
find
those.
I
know
that
when
we
did
our
early
stuff
to
see
what
the
different
combinations
were
for
the
different
tributes
within
kubernetes,
there
were,
I
think,
77
000
different
combinations
that
we
don't
test
much
of,
and
it
when
I
wonder,
is
if
there's
a
way
that
similar
to
how
we've
done
it
with
the
ingress
api.
F
F
That
sounds
the
same
as
this
that's
right
and
in
theory
I
could
point
my
gateway
or
my
ingress
at
a
secret
or
a
config
map,
and
that
would
be
schematically
valid,
but
my
controller
would
go
through.
I
don't
know
what
to
do
with
that
and
ignore
it
or
cause
an
area,
or
maybe
your
controller
would
perfectly
handle
a
config
map.
They
say
my
custom
type
is
config
map
and
here's
how
I
pull
data
out
of
the
config
map
right.
F
My
sorry,
my
point
being
I
as
an
end
user,
should
know
through
documentation
right
now
what
my
implementations
do
or
don't
support
I
can
make.
I
can
schematically,
say
any
kind
I
want
right
and
that
it
will
pass
validation,
but
it
may
or
may
not
be
useful
to
the
to
the
controller
so
actually
hippie.
You
said
something
that
was
interesting
by
jumping.
No,
I'm
still
up.
You
said
something
that
was
interesting
like.
Is
it
useful
to
expose
that
like?
A
A
F
C
We
have
been
trying
to
explore
ways.
We
could
describe
that
in
a
generic
and
consistent
way
on
the
gateway
class
resource,
a
very
similar
parallel
to
ingress
class.
I
think
the
same
concepts
apply
to
ingress
class
as
well
as
this
given
ingress
class
supports
forwarding
to
these
specific
backend
types
kinds:
resources
whatever
we
want
to
call
them.
I
think
there's
maybe
a
way,
but
it's
it's
a
little
weird
to
get
there,
but
I
agree
that
could
be
a
useful
concept.
H
All
right,
so,
okay,
just
chime
in
all
right.
I
have
a
I've,
actually
been
kind
of
thinking
through
this
problem
with
like
anton
police
on
api
expressions,
and
we
kind
of
wrote
up
this
doc.
That
has
a
proposal.
It's
basically
leveraging
open
api
extensions
to
document
sort
of
what
the
reference
types
are
and
categories.
F
That
sounds
really
interesting.
I
don't
think
it
changes
the
larger
conversation
here,
which
is
really
I
I
just
the
question
I'm
asking
is:
should
we
revisit
the
guidance
that
that
you
wrote
use
again?
Thank
you
for
writing
it.
Should
we
revisit
that
with
some
more
subtlety
to
it
in
terms
of
what
we
should
give
people
guidance
when
they're
producing
apis.
H
F
H
So
I
I
think
one
just
want
to
provide
some
context
on
the
conversation
I
think
yeah
jordan
was
involved,
and
so,
as
david
who
might
be
in
this
meeting
as
well,
so
I
I'm
primarily
defer
to
them,
because
I
think
they
give
a
lot
of
feedback
on
it.
My
personal
opinion
is,
I
do
feel
like
kind
is
so
well
entrenched
that
yeah
we
probably
have
to
provide
some.
B
D
D
D
F
D
I
think
if
you
truly
know
the
mapping
and
no
one
would
have
to
actually
look
it
up,
that
sounds
okay.
If
you
have
to
look
it
up
and
again
owner
references.
This
happens
like
weird
things
happen
in
garbage
collection,
weird,
what
unexpected
things
happen
in
garbage
collection
when
discovery
is
unavailable
and
having
a
way
in
an
owner
reference
to
say
like
this
is
generic,
but
I'm
going
to
map
x
to
y,
and
this
is
now
your
resource-
would
make
it
easier
to
to
know
what
was
going
to
happen.
I
think.
F
Could
we
consider
that
to
be
like
an
additive
thing,
so
let
me
try
an
attempt
at
a
principle
for
the
guidelines
for
api
review.
D
F
H
Yeah,
I
think
I
think
it
would
have
to
happen
async,
because
I
know
that,
like
you
know
so,
my
understanding,
I
think,
of
like
the
patterns
and,
for
example,
controller
runtime
for
doing
watches
is
all
based
on
kind
which
I
think
does
disambiguate
via
the
rest
mapper.
So
it's
not
like
you're
providing
a
static
mapping
to
basically
make
that
happen.
You
are
relying
on
disco
on,
I
think
discovery
there.
So
I
just
I
don't
know
if
it's
not
good.
F
Suppose,
hypothetically,
we
expose
restmapper
as
a
as
an
optional
thing
and
subsystems
could
somehow
through
the
magic
of
names
or
something
expose
their
custom
rest
mapping
for
their
subsystem.
So
I
create
a
rest
map
instance
for
that
links
back
to
a
specific
gateway
class
and
says
for
this
gateway
class.
F
H
F
F
But
users,
users
don't
need
to
deal
with
it
because
we
could
build
that
into
the
clients
and
the
discoveries
so
that,
if
I
provide
something,
that's
ambiguous
and
it's
in
a
particular
context,
that
is
somehow
derivable,
which
I
don't
know
how
to
answer
that
and
then
I
can
disambiguate
because
anytime
we
have
api
servers
that
has
references.
F
We
can't
assume
that
we
know
all
the
clients
that
are
going
to
follow
those
references
and
the
more
ways
there
are
to
turn
a
reference
into
a
url,
the
more
likely
it
is
you're
going
to
get
like
incompatible
implementations.
So
right
now,
there's
basically
three
ways:
there's
the
like
pluralized
using
code
that
adds
s
ie,
there's
use
discovery
and
there's
hard
code.
This
kind
goes
to
this
endpoint
if
we
have
like
a
fourth
like
in
this
context,
kind
uses
a
mapping
defined
over
here,
like
that
seems
bananas
to
me.
A
F
A
A
This
is
what
this
kind
means
in
this
particular
reference
and
that's
the
hard
coding
I'm
talking
about,
and
you
could
make
that
if
you
want
a
generic
cube
control
style,
clients
to
be
able
to
disambiguate
or
figure
out,
follow
that
reference.
Then
you
could
make
that
information
discoverable
rather
than
hard-coded,
but
I
don't
know
the
value
in
making
that
trackable
I
mean
I
can
see
some
cases
like
some
sort
of
configuration,
consistency,
checks
and
things
like
that,
potentially
it
being
useful,
but
anyway.
F
I
I
agree,
I
I
don't
think
it's
necessarily
super
useful.
I
just
think
the
the
fact
that
it's
plausible
makes
it
feel
less
awful
to
me
yeah.
I
think
the
the
guidance
around
resource
was
primarily
around
avoiding
failure
modes
like
saying,
if
you
specify
a
kind
and
it's
a
generic
reference,
that
we
can't
bake
a
lookup
map
ahead
of
time,
then
we're
going
to
have
to
use
discovery
and
that
introduces
failure
modes
that
you
probably
haven't
thought
through,
and
so,
if
we
could
just
shortcut
that
by
saying
this
is
the
resource
I
meant
like
that.
F
Seemed
nice
yeah.
H
Yeah,
I
think
it's
fair
to
complete
that,
like
it's
fair
to
just
think
start,
including
the
caveats
right,
but
then
acknowledge
that
in
you
know,
in
the
current
world
that
exists,
there's
many
people
that
do
the
kind.
So
if
you
do
that,
here's
kind
of
what
you
have
to
worry
about,
you
have
to
worry
about
disambiguating
and
making
sure
that
you
know
through
whatever
I
guess
of
the
mechanisms
you
have
right.
H
I
think
another
control
mechanism
you
kind
of
have
is
is,
hopefully
you
know
complete
ownership
of
the
kind
and
resource
that
you're
kind
of
referencing.
So
you
know
you
can
innate.
You
can
basically
guarantee
some
level
of
sort
of
like
one-to-one
mapping
by
having
complete
ownership,
obvious
of
the
resourcing
kinds
that
you're
referencing.
H
Yeah,
well,
that's
that
is
certainly
true.
Well,
if
you
control
yeah,
I
mean
I
mean
people
can't
basically
contain
complete
ownership
over
a
group
version
right.
So
you
you,
I
guess
other
people
could
always
register.
H
H
E
Thank
you.
I
want
to
remind
us
all
that
when
we
define
what
kubernetes
is
for
everyone,
we
currently
have
a
api
server,
that's
spun
up
and
we
do
a
explore
of
that
and
dump
it,
and
if
what
we're
doing
is
going
to
change
that
process,
we
should
keep
it
in
mind.
E
What
we're
speaking
of
right
now!
I
am
not
sure
how
that
fits,
because
these
api
servers
that
are
underneath
aren't
spun
up
in
that
line
of
code
that
generates
the
open
api
json.
That
is
the
definition
of
what
we're
of
a
conformance
in
kubernetes
and
I'd
love,
to
hear
more
about
how
this
decision
influences
that.
F
F
So
I
asked
a
question
in
the
chat
and
david.
I
see
your
answer,
but
I'm
not
sure
I
understand
your
answer
just
to
to
come
at
it
from
a
different
direction.
F
What
if
we
said
in
fact,
resources
is
correct
and
we
spent
the
time
to
go
back
through
all
of
the
existing
apis
that
do
object,
references
and
add
resource
alongside
kind
and
then
auto
populate
it
whenever
possible
and
start
to
put
it
in
user's
face
instead
of
saying.
Well,
we
didn't
so
we
shouldn't.
I
have
an.
D
Over
for
you
it,
I
tried
it
with
garbage
collection
and
what
happens
today
is
there
is
a
property
today,
where
at
least
for
gc,
you
can
create
a
reference
to
a
thing
that
doesn't
yet
exist,
whether
that's
like
good
or
bad
or
otherwise.
Like
it's
a
thing
you
can
do
and
it
makes
the
resource
mapping
potentially
late
binding,
and
so
I
had
difficulty
bringing
it
to
fruition.
A
Of
of
that
I
mean,
I
guess
you
or
the
existing
discovery,
but
that
people
can
also
specify
resource
if
they
actually
care
in
that
particular
reference.
A
This
kind
of
provides
the
backwards,
compatibility
and
sort
of
works,
as
users
would
expect.
Now.
If
they
provide
an
inconsistency
between
the
two,
then
either
resource
takes
priority
or
you
puke
or
something,
but
to
me,
that's,
like
I
said,
would
match
how
users
expect
it
to
work.
Oh
we're
used
to
just
putting
in
kind,
but
oh
kind's,
not
sufficient
to
disambiguate
here
I'll,
add
resource
and
that
that's
it
anyway,
tim
your
hands
up
still.
We
are
just
about
out
of
time
folks.
A
Well,
we
have
eight
minutes
left,
so
we
have
some
time,
but
we
should
try
to
figure
something
out.
As
far
as
it
sounds
like
we
have
some
suggestions
as
far
as
the
updated
guidance,
but.
F
C
A
Okay,
well
then,
I
guess
that
was
a
pretty
good
discussion
and
we're
making
maybe
some
progress
so
any
in
that
case,
if
we've
got
our
volunteers
or
victims
or
whatever
you
want
to
call
them,
then
any
other
business
we
need
to
address
on
this.