►
From YouTube: SIG Architecture 20180809
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
Good
morning,
/
afternoon
evening,
wherever
you
might
be
in
the
world,
today
is
Thursday
August,
9th
2018.
This
is
the
kubernetes
SiC
architecture,
community
and
I.
Am
your
host
co-chair
Jay,
singer
mutters?
Your
other
chair
is
Brian
grant
who
I
believe
may
be
joining
you
shortly,
but
without
further
ado,
I'm
going
to
go
ahead
and
dig
into
the
agenda,
which
is
available
for
your
perusal
at
bit:
dot
Lee,
slash
sake,
architecture
and
that
document
I
will
paste
a
link
in
the
chat.
A
Okay,
can
you
all,
let
me
know
anybody
that
visible
everybody
yep
great
things,
sure
all
right.
So
what
we're
gonna
do
is
go
through
the
agenda.
So
first
thing
is
just
housekeeping
which
is
to
quickly
walk
the
boards,
so
to
speak,
of
our
project
boards,
so
in
kept
tracking
I,
basically
have
added
a
bunch
of
new
cups
to
the
backlog,
and
so,
if
you
are
the
owner
of
one
of
these
caps,
are
you
are
involved
in
one
of
these
six
that
are
working
on
these
definitely
feel
free
to
to?
B
A
Today's
in
sake
review
column
and
then
after
that,
essentially
we
have
this
column,
that
is,
for
those,
the
Kemp's
that
have
architectural
implications
that
need
to
be
reviewed
by
this
sake,
and
so
we
will
put
those
there.
This
is
also
just
for
visibility,
where
we
add
things
that
are
an
API
review.
A
So
essentially,
this
allows
you
to
see
the
full
backlog
of
things
that
we
need
to
to
do
for
for
the
six
for
architectural
divisions
right
now,
I
don't
necessarily
need
to
go
through
these,
but
if
you
have
any
updates
on
these
feel
free
to
add
those
conformance
tests
Erin
how
fortuitous
that
you
have
arrived,
because
it
looks
like
this
may
be
stuff
that
you've
added
you
want
to
talk
about
this.
That's
so
random
how.
D
D
Sorry
there
with
multiple
ways
of
meeting
yeah
and
we
need
to
get
a
group
of
people,
who's
kind
of
trained
to
know
what
to
look
for
or
I,
think
Aaron
you're,
probably
likely.
The
first
person
we're
gonna,
add
as
you've
been
digging
into
this
I
think
you're,
building
an
understanding,
and
then
we
can
ask
questions
and
refine
the
criteria
that
are
checked
in
and
once
that's
clear.
Then
we
can
have
a
clear
way
of
sort
of
onboarding
and
the
usual
way
we
had
intended
to
on
board
people
is
to
have
them.
D
So
I
think
that
same
process
can
work
here
as
far
as
getting
my
time,
I'm
trying
to
batch
their
reviews
as
much
as
possible.
So
we
can
get
them
into
the
tracking
board.
Then
I
can
sweep
through
and
comment
on
like
everything,
that's
in
one
column
or
two
columns,
I,
don't
know
if
we
need
all
of
these
columns.
Maybe
just
have
three
columns
or
something
like
that,
but
you
know
getting
interrupted
at
various
times
during
the
week.
D
Doesn't
work
super
well
for
me,
so
I
just
want
to
sweep
through
them
in
a
batch
but
yeah
the
pod
tests,
because
we
have
so
many
different
plugins
at
the
node
level
and
because
some
people
are
trying
to
reimplementation
allottee
as
well.
It's
super
important
that
we
get
pod
level
functionality
into
the
conformance
suite
it's
one
of
the
most
critical
things
that
pretty
much
everybody
uses.
D
E
A
D
C
I'll
pin
you
offline,
like
I,
think
what
would
be
helpful
from
my
perspective
is
to
at
least
know
when
that
batch
is
so.
I
can
start
setting
that
as
the
deadline
for
other
people
that
so
like
I
can
review
their
stuff
and
time
to
get
it
handed
over
to
you,
I
think
the
other
thing
that
would
help
grow
the
pool
of
people
who
understand
what
conformance
is
is
if
you
kind
of
refine
that
document
on
informants
requirements,
I
showed
it
initially
to
this
meeting
as
a
work
in
progress
and
then
Tim
Sinclair
said:
oh
cool.
C
It's
ready
for
review,
even
though
I
had
it
as
a
working
progress,
so
I
think
after
chatting
with
him
offline,
I'm
gonna
make
a
Google
Doc
and
see
if
a
bunch
of
us
can
make
a
more
refined
pass
on
that,
because
I
really
want
to
walk
away
with
the
doc.
That's
a
pretty
clear
to
understand
checklist
or
people
who
are
writing
tests
and
people
who
are
reviewing
tests
to
understand
like
does
this
make
sense,
as
conformance
right,
yep
sounds
good.
Alright,.
A
That's
it
for
me:
thanks
Aaron,
that's
great
moving
right
along
a
guy
reviews
board
right
now,
there's
one
assigned
I
added,
some
more
from
the
backlog
or
two
three
backlog,
rather
from
the
main
repo,
so
need
to
figure
out
a
process
for
how
to
how
to
better
scale
this
stuff,
because
I,
don't
scale
well
and
I
need
to
probably
start
training
people
and
kind
of
how
to
manage
some
of
this
stuff.
So
essentially,
what
we're
gonna
try
and
do
is
pair
people
reviewers
to
these,
if
you're
not
already
so.
F
A
A
My
inclination
is
to
have
the
person
with
the
most
subject
matter:
expertise,
review
it
and,
as
somebody
who's,
a
discriminating
reviewers
yourself.
You've
reviewed
enough
things
that
you
probably
know
if
you're
too
close
to
it
in
a
sense
that
you
can't
be
impartial.
So
we
pretty
much
was
a
review
team.
My
hope
is
that
they
will
recuse
themselves
where
it's
appropriate
and.
B
D
I
think
that
yeah
for
day-to-day
reviews,
I
think
that
totally
makes
sense
that
it's
totally
appropriate
as
someone
who's
been
brought
in
on
things
with
no
context,
it
is
pretty
hard,
although
one
thing
I've
noticed
in
the
past
was
storage
in
particular.
Is
it
doesn't
follow
a
lot
of
the
same
guidelines
and
patterns
and
conventions
as
other
parts
of
the
system,
or
may
not
be
aware
of
decisions
that
were
made
in
other
parts
of
the
system?
F
Seems
reasonable,
my
my
thinking
and
asking
the
question
was
mostly
around
having
someone
to
challenge
since
I'm.
You
know
since
I
know
the
design
of
it
I
have
sort
of
built-in
assumptions
and
biases
towards
it,
and
it's
been
very
useful
in
the
past
to
get
people
who
are
less
familiar
to
look
at
it
and
say
well,
why
do
you
have
to
do
it
that
way?
Isn't
there
this
other
option
that
you're
you
didn't
explore?
Could
you
do
that
so
I
think
for
big
reviews.
That's
useful!
This
one
I
think
is
on
the
edge
of
that.
A
The
review
process
once
it's
merged,
essentially
it
does
call
out
that
a
reviewer
can
pull
another
of
yours
as
they
see
fit
to
that
assumptions
or
to
have
a
discussion
around
some
things,
because
I
believe
that
a
lot
of
these
things
are
really
discussion.
Points
because
they're
going
to
drive
the
future
of
how
the
the
api's
are
implemented.
So
I
I
would
see
that
reserving
time
specifically
in
the
saiga
architecture
meeting,
if
there's
a
discussion
on
it,
what
makes
sense-
and
so
maybe
those
maybe
that's
a
good
way
to
handle
those
or
you're
like
well.
A
F
I've
got
another
one,
that's
in
the
queue
I,
don't
know
when
they're
coming
up
for
this,
but
it's
not
one
of
mine
that
it
came
through
me
and
I
said
you
should
use
CRD
and
there's
some
pushback
because
of
the
limitations
of
CRD,
and
so
some
people
are
experiencing
some
pain
and
I
feel
good
about
that,
but
maybe
not
bad
enough
to
change.
Yeah.
D
There's
a
lot
of
pain.
This
will
come
up
in
the
runtime
class
for
Q
as
well
momentarily
we're
in
a
situation.
You
know
the
typical
situation
of
yeah,
the
old
ways
deprecated,
but
the
new
way
is
not
ready.
Yet
CRT
CRT
is
is
one
thing
along
those
lines,
but
adding
shields
to
existing
stable
API
is
another
thing
along
those
lines
where
we
said:
don't
use
annotations,
but
oh
yeah
don't
add
fields
either.
So
so
we'll
need
to
figure
out
how
to
how
to
address
that.
G
D
D
So
somehow
we
need
to
turn
the
tide
on
that
eventually,
so
we
had
just
moving
forward
in
the
agenda.
We
had
a
bunch
of
things
added
and
the
main
topic
is
the
runtime
class
review.
Almost
certainly,
we
won't
get
through
all
the
issues,
but
I
would
like
at
least
a
half
an
hour
for
that.
Maybe
we
should
just
do
the
short
items
first
and
call
time
at
11:30.
I
can't
see
who
is
on
the
call
Matt
Farina.
Are
you
on
I
am
okay.
You
had
a
question
about
the
release.
Versioning.
I
I
We
haven't
yet
gotten
to
the
one
point,
no
thing
where
we
follow
a
semantic
versioning
like
right.
We
even
if
people
are
importing
them,
we're
not
making
guarantees
at
this
point
that
said,
I
agree
that
we
need
a
strategy
to
handle,
goes
module
system
and
I.
Believe
I
even
filed
an
issue
about
it
like
several
months
ago
and
science.
D
I
H
Yeah
yeah
so
that
well
there's
two
things:
if
you're
on
v-0
or
v1
major
versions
in
some
ver,
it's
still
the
normal
path.
Once
you
go
to
v2
and
v3,
then
your
path
changes
for
the
imports
and
then
it
also
uses
the
tags
from
your
version
control
system,
which
is
where
for
something
like
kubernetes.
You
know
we
say
it's
a
v-0.
Our
tags
correlated
to
our
go.
Api
is
correlated
to
consumer,
speak
something
different
than
what
go
modules
expect
I
mean.
B
H
I
H
I
G
Think
doesn't
this
go
back
to
the
conversation
we
had
maybe
a
month
ago
about
going
to
the
repository
binding
out
things
that
we
want
a
vendor
things
that
we
want
to
push
server-side
and
kind
of
coming
up
with
the
plan
for
like
making
things
more
vulnerable
and
then,
if
we
solve
that
problem,
perhaps
we
could
get
semantic
versioning
to
work.
Those
portions
of
AV
item
be
actually
one
a
vendor
out.
Okay,.
H
Okay,
Matt,
so
I
was
just
gonna,
say:
I
mean
there's
a
real
world
to
go
problem,
and
then
we
talked
about
here
there's
a
whole
bunch
of
people
who
import
kubernetes,
kubernetes
and
their
stuff
is
not
something
in
the
staging
repo.
So
on
the
current
path,
once
we
have
go
modules
in
place
and
people
need
to
use
go
modules,
then
they
won't
be
able
to
import
kubernetes
kubernetes
and
be
able
to
deal
with
go
API
changes.
The
way
we've
been
doing
them
in
kubernetes
kubernetes.
H
I
I
But
the
thing
is
right:
now:
we're
publishing
them
to
separate
repos,
because
you
have
to
do
that
in
order
to
let
people
import
it
separately.
Under
the
new
system,
we
could
describe
multiple
modules
in
a
single
repo
and
people
wouldn't
would
no
longer
that
would
no
longer
be
mandatory.
We
might
still
choose
to
do
it,
but
it
wouldn't
be
managed.
I
see.
Oh.
D
Sorry,
since
we
don't
have
a
lot
of
time,
which
is
we've
been
talking
about
sub
projects
for
cigar
contexture,
one
of
them
I
actually
worked
on
that
a
little
bit.
One
of
the
sub
projects
I
think
we
need
is
code
organization.
How
do
we
deal
with
repos
staging
done
during
go
modules?
I
guess,
yeah,
another
new
thing,
so
I
think
we
need
to
actually
have
that
as
a
discrete
sub
projects.
Cigar
picture
and
I
have
a
set
of
people
who
are
actually
working
on
that
and
thinking
about
it
and
analyzing.
D
Well,
how
big
of
an
impact
across
the
project
is
this
going
to
be?
Are
we
gonna
actually
be
able
to
do
that
in
a
in
a
timely
manner
and
interact
with
the
other
stakeholders
and
drive
that
forward?
You
know,
especially
with
the
changes
to
vendor
in
coming
up
and
go
modules
and
whatever
we're
gonna
need
a
more
concerted
effort
on
this,
and
we
haven't
made
a
lot
of
progress
on
things
like
feature
branches:
either.
D
C
H
C
I
G
D
J
D
F
Also
need
I
think
as
a
group
to
make
a
decision.
Finally,
eventually
as
to
how
we
feel
about
people
vendor
in
kubernetes
communities
or
portions
thereof,
whether
we
want
to
take
a
stronger
position,
we've
sort
of
danced
around
the
topic
before,
but
maybe
the
position
should
be
you
don't
vendor
kubernetes
communities,
you
vendor
or
something
but
I'm,
staging
I.
Think.
I
H
I
Better,
oh
okay,
one
thing
we
should:
we
should
figure
out
before
we
make
a
decision
about
whether
people
should
be
ven
during
kubernetes
kubernetes
is
how
difficult
is
it
to
offer
like
two
tracks
of
entering
like?
If
it's
not
difficult
at
all,
then
we
should
just
say:
no:
don't
vendor
kubernetes
kubernetes
we're
gonna,
make
that
easy
for
developers
and
if
it
is
incredibly
difficult
to
offer
multiple
tracks,
then
maybe
we
can't
stop
checking
in
generator
files
or
something
like
that.
I
D
F
D
D
D
F
D
F
E
Well,
reinstall
each
got
into
a
situation
where
the
used
annotation
for
some
time
we're
stuck.
He
eventually
wanted
to
move
somewhere
else,
but
in
the
meantime
the
annotations
were
required
as
API
and
unfortunately
we
didn't
use
any
alpha
or
beta
or
whatever
prefix.
So
it
looks
like
a
stable
annotation
right.
So.
D
F
F
I
The
runtime
class
is
defining
different
runtimes
in
the
cluster,
so
different
ways
of
running
actually
running
a
container
and
the
primary
motivating
use
case
for
this
is
to
support
multiple
runtimes
in
the
cluster.
This
is
kind
of
bubbling
up
to
the
surface
now
with
cauda
containers
and
G
visor
for
implementing
sandboxes.
I
So
this
is,
you
know,
rather
than
using
run
C
to
do
a
native
Linux
container
implementation
using
nested,
virtualization
or
G
visors,
emulated
user
space,
kernel
approach
to
actually
run
the
containers
and
then
kind
of
looking
more
like
future-looking.
We
also
anticipate
Windows
runtimes,
coming
down
the
pike
potentially
runtimes
for
kind
of
legacy,
VM
type
workloads
and
some
of
the
server
list
stuff
that's
being
talked
about
as
well,
so.
D
I
Was
part
of
our
kind
of
like
original
concept,
but
it
got
cut
from
the
initial
alpha
proposal.
So
if
we
look
at
the
non
under
the
non
goals,
I
have
a
list
of
things
that
we'd
eventually
like
to
tackle,
or
at
least
consider
but
aren't
included
in
the
initial
proposal
and
the
first
one
of
those
is
surfacing.
Support
for
optional
features
and
that's
exactly
what
you're
just
saying
is
defined,
which
features
can
actually
be
used
with
this
runtime.
With
this
node
yeah.
I
And
that
that's
kind
of
going
towards
the
second
goal,
high
level
goal
of
this,
which
is
to
provide
a
place
for
surfacing
runtime
container
runtime
properties
to
the
control
plane
when
it
matters
and
so
surfacing
the
optional
features
is
one
pod.
Overhead
is
another
piece
that
we've
discussed
so
different.
Runtimes
require
different
amounts
of
memory
for
the
various
underlying
infrastructure
pieces,
and
so
runtime
class
would
provide
a
way
for
specifying
that
we've
talked
about
integrating
it
with
scheduling.
I
Think
it's
going
to
need
to
be
explicit
because
there's
going
to
need
to
be
there's
going
to
be
need
to
be
features
that
you
will
want
to
request
for
Windows
containers
that
you
can't
use
for
Linux
containers
and
vice
versa.
So
you
know
on
our
Linux
containers.
We
have
fields
in
the
pods
back
for
things
like
app
armor
and
sakam,
and
capabilities
that
don't
make
sense
for
Windows
containers.
I.
Don't.
I
D
I
One
thing
that
we've
has
come
up
a
few
times
in
cig
node
is
whether
the
operating
system
like
Linux
versus
Windows
is
going
to
be
it
end
up
being
a
top-level
field,
the
container
spec
or
if
we
can
rely
on
runtime
class.
For
that,
whether
or
not
it's
a
you
know
a
top-level
field
in
the
API
spec
I
think
it
still
makes
sense
to
pair
that
with
runtime
class
as
well,
because
there
might
be
different
options
for
say,
running
a
Windows
container.
I
A
G
That's
kind
of
thing
I'm
trying
to
have
so
you
want
to
overall
runs
on
a
condom
to
get
a
pot
level
to
pass
any
configurations
for
the
behind.
You
know
the
so
there
may
be
other
configuration
parameters
for
individual
containers
that
are
also
operating
systems.
So
it's
not
addressed
inside
of
the
containers,
Bacchus
problem.
G
I
On
specific,
so
the
runtime
class
is
just
it's
selecting
the
runtime
that
will
be
used
to
run
the
pod.
It's
not
actually
configuring
that
runtime,
so
there's
kind
of
two
different
types
of
configuration,
there's
the
static
configuration
which
is
we're
saying
that
is
explicitly
out
of
scope
for
runtime
class.
This
is
a
runtime
component
config
and
we're
just
assuming
for
now
that
that's
statically
configured
on
the
node
through
whatever
config
file
and
then
there's
the
kind
of
the
dynamic
cur
pod
configuration,
which
is
all
the
stuff
that's
in
the
container
in
the
pod
spec.
G
L
So
an
example:
that's
currently
kind
of
in
review
is
the
user
name,
spacing
user
name
spacing
stuff,
so
not
all
runtimes
support
that
and
the
ones
that
do
may
have
it
on
or
off,
and
so
would
a
pod
that
wanted
to
make
use
of
that
reference
need
to
reference
a
runtime
class
that
indicated
support
for
it
and
then
also
opt
in
to
that
feature
or
configure
that
feature
in
the
pods
back.
It
seems
like
double
opt
in.
F
F
Maybe
I
should
clarify
exactly
the
things.
I'm
thinking
about
storage
class
I
think
had
two
interesting
properties
that
I'm
curious
about
here.
One
is
the
fact,
as
resource
users
can
go
shopping
for
it,
but
there
default
and
the
default
is
configured
by
an
admission
controller
which
looks
at
all
the
existing
classes
and
sides
which
one's
the
defaults
based
on
some
heuristic
and
the
other
is
that
the
classes
are
effectively
site,
defined,
there's
no
standard
across
classes
of
what
they're
named
or
what
they
mean.
F
You
know
we
don't
necessarily
want
the
class
to
be
named
docker,
you
wanted
to
be
named
containers
or
C
groups,
or
something
that
means
something
to
your
particular
site
and
those
to
certain
bits
of
abstraction.
Most
users
don't
actually
have
to
deal
with
it
at
all,
and
only
those
users
who
specifically
have
some
need
to
choose
a
different
than
default
on
time
can
do
so,
and
the
administrators
are
in
full
control
of
what
those
classes
meet.
B
I
D
You
need
a
runtime
class
class
between
the
set
of
properties
that
you
expected
and
which
class
represented
that
we're
running
into
this,
in
conformance
as
well,
for
storage,
for
instance,
which
is
if
we're
gonna
have
conformance
profile,
say
well.
Your
cluster
must
have
dynamic
provisioning
of
volumes
with
a
particular
set
of
portable
behaviors.
D
F
J
Published
for
each
and
every
runtime
that
we
think
is
going
to
be
supporting
the
app
stream
because,
like
that
then
goes
into
the
overall
application,
API
surface
right
like
across
kernel
across
drawer
storage.
It's
it's
a
large
surface
area
and,
like
so
whole
continent,
I
mean
in
capturing
that
to
idea.
I
It
could
be
conformant
defined
by
conformance
test
and
say
these
are
the
features
that
must
be
implemented
by
you
know
the
native
runtime
class,
and
these
are
the
ones
that
are
optional
and
these
the
ones
that
must
be
forbidden
or
not
used
or
something
effectively.
We'll
have
that
once
we
add
the
pod,
the.
I
Yeah,
employment
or
it
could
be
more
of
a
semantic
description
of
like
these-
are
the
expectations
for
this
runtime
class,
for
instance,
with
a
sandbox
runtime
class
I.
Don't
think
we
can
realistically
write
a
test
that
guarantees
to
security
boundaries
between
the
process
and
the
host
kernel,
and
so
that's
a
place
where
we
would
have
a
semantic
description
and
say
you
know
this
is
the
expectation
for
a
sandbox
runtime.
J
D
C
J
I
But
this
this
notion
of
kind
of
run
time
class
names
that
are
portable
across
environments-
is
why
this
isn't
just
a
runtime
field
on
the
pod.
It's
why
we've
kind
of
decoupled
it
had
this
sort
of
like
in
direction
of
the
pod,
refers
to
the
runtime
class,
the
runtime
class
spec.
If
we
jump
down
to
the
API
definition,
includes
a
runtime
handler,
which
is
the
actual
thing
that
is
interpreted
by
the
CRI
to
run
the
runtime,
so
you,
your
runtime
class,
might
be
sandboxed
and
your
runtime
handler
is
gee
visor.
We
stuff
like
that.
So.
G
Cool
Khan
apps
with
how
you
would
actually
use
it
in
production,
every
other
Buster
I
would
create.
Instead
of
like
that.
So
a
typical
use
case.
We
used
to
be
like
I,
bring
up
a
cluster
and
then
I
install
a
series
of
one-time
classes
to
describe
what
the
capabilities
are
of
different
runtimes
and
then
how
do
I
attach
that
to
the
individual
nodes
where
the
runtimes
are
supported,
or
is
that
because
I
introduced
add
boot
up
time?
Also,
can
you
delete
them
and
update
them.
I
So
again,
we're
we're
kind
of
like
listing
out
every
single
thing
that's
listed
as
stuff.
We
want
to
do
with
this
and
like
why
this
is
a
useful
feature
and
a
useful
resource
to
have,
but
let's
not
tackle
that
now,
so
we
we
eventually
would
like
to
have
some
sort
of
notion
of
discovery
where
nodes
could
say
this
is
the
runt
views
of
the
three
runtimes
I
support
and
the
scheduler
can
kind
of
route
pods
to
the
the
desired
nodes.
Is.
I
Or
something
like
that,
exactly
and
and
if
the
pod,
if
the
node
tries
to
run
a
PHA
or
goes
to
run
a
pod
and
lines
that
well
I,
guess
if
the?
If
there
goes
to
run
a
pot
and
the
runtime
class
doesn't
exist,
the
pod
will
be
rejected
or
failed.
If
the
container
runtime
goes
to
run
the
pod
and
says
I,
don't
know
what
to
do
with
the
runtime
handler
fubar,
then
that
will
just
return
an
error
and
ultimately
so
I'm
gonna
do
a
time
check.
We.
D
I
What's
the
current
implementation
status,
we
would
like
to
get
this
into
112
as
an
alpha
feature
behind
a
future
date.
But
do
we
have
runtime
is
ready
to
use
it?
Yes,
so
there's
where's
the
so
cry.
Oke
container,
D
and
frac
D
and
Windows
all
have
an
annotation
that
they
use
and
they're
all
different
or
deciding
whether
a
pod
should
be
run.
I
I
Has
there's
a
cryo
trusted
sandbox
annotation
on
the
pod
that
determines
whether
to
use
the
trusts
that
are
untrusted,
runtime?
Okay,
so
the
goal
is
to
deprecate
all
those
annotations
and
that
things
should
be
using
runtime
class
instead
but
support.
Ultimately,
you
know
we'll
add
this
as
a
field
to
the
CRI
and
it
will
be
up
to
the
individual
runtimes.
To
actually
add
you
know,
do
something
with
that
field
and
and
add
support
for
it.
D
Okay,
so
this
would
be
alpha
and
the
initial
release
it
appears
correct,
yeah
I
did
glanced
at
the
API
PR
and
so,
as
was
hinted
at
earlier,
and
we're
trying
to
move
early
development
out
of
kubernetes
Trinity's
master,
so
alpha
features
generally
are
turned
off
by
default,
or
at
least
we
tried
to
make
that
true.
We
don't
yet
have
a
field
getting
mechanism.
As
far
as
I'm
aware
Jordan
and
Daniel
there's.
G
D
To
use
annotations,
but
we
don't
feel
gates
yeah
either
and-
and
you
know,
as
we
try
to
stabilize
pod
I,
really
don't
want
to
add
an
alpha
field.
It
is
present
there
if
we
can
help
it.
I
also
don't
want
to
add
any
more
compiled
in
types
if
we
can
help
it,
and
since
this
isn't
going
to
be
a
high
churn,
API
type,
there's
no
strong
technical
justification
for
why
I
ask
to
be
compiled
in
like
it
doesn't
need
proto
or
some
of
those
other
things.
D
D
D
So
yeah
I
would
say
you
know,
for
the
people
who
want
to
try
this
out.
Could
they
build
a
development
bill
kubernetes
like
who's
chomping
at
the
bit
to
actually
to
actually
get
this
and
try
it
out
and
get
feedback
on,
whether
it
works
or
not?
For
those
runtimes
like
I,
don't
know
who's
using
black
TD
or
trusted
runtime,
sir
who's
waiting
to
that,
does
it
actually
need
to
be
an
official
release,
even
disabled.
B
Even
though,
initially
explicitly
say
that's
not
in
the
scope,
but
you
know
we
want.
We
also
say
that
we,
our
purpose,
extended
that
they
touch
or
window
support
and
our
leaders,
so
the
goals
we
want
to
this
cannot
get
experience.
We
have
the
load
capacity,
changing
anything
you
could
undyne
these.
The
paths
have
the
specific,
the
one
temp
requirement,
so
how
this
camp
only
forward
yeah
I.
D
G
You
do
this
was
just
an
extension
like.
Doesn't
it
implicitly
the
fire
for,
because
the
modifications
to
find
necessary,
negated
work
and
cubelet
included,
I
was
going
to
become
schedulers,
you
beer
is
to
use
teens
and
toleration
is
to
for
supply
and
yeah
I.
Don't
think
the
scheduler
needs
any
changes
right
now.
This.
F
Is
a
pattern
that
we
see
every
day
of
the
week
in
you
know,
somebody
wants
to
do
some
new
idea
and
in
order
to
get
there,
it
has
to
have
some
route
in
an
existing
object.
We
saw
the
same
thing
snapshots
and
all
they
need
is
one
one,
tiny
little
field
and
then
they'll
be
happy
and
like
we
can
totally
push
you
to
see.
Rd
and
well.
F
A
bundle
field
that
you
need
as
a
you're
right
unless
we
design
some
other
way
to
do
this
in
the
more
extensive
away
right
in
the
past,
we
said
we'll
do
it
as
an
annotation
that
way
it's
not
official,
and
we
know
that
there's
a
lot
of
pain
down
that
road
and
then
we
said
well,
don't
do
annotations
do
alpha
fields.
We
know
that
there's
a
lot
of
pain
down
that
road.
Do
we
have
another
alternative
that
we
can
tell
people
I
mean
draw
comparisons?
F
F
F
D
L
F
J
B
B
How
are
you
right
now
really
well
the
reading
a
minute
one
of
the
really
advanced
a
lot
happening,
speculated
accumulate
to
acne
and
accumulate.
You
might
not
a
lot
of
features
and
accumulate
this.
You
don't
have
API
to
become
for
under
here
and
there's
a
program
or
coumadin
have
a
lot
of
cool
features
and
the
eviction
management
is
the
core
feature,
but
there's
no
good
way
to
to
conform
of
the
eviction
management
to
to
conform
of
the
coning
of
the
services.
So
a
lot
of
feature.
B
F
D
F
D
Other
things
everything
is
generated
from
the
everything
that's
generated.
We
need
to
convey
everywhere
that
it's
alpha
and
be
able
to
get
it
on
and
off,
based
on
whether
alpha
features
are
enabled
like
it
should
not
show
up
in
your
open,
API
spec
at
alpha
features
are
disabled.
Do
you
expect
the
same
for
beta?
You
choose
eventually,
yes,
within
a
year,
I
expect
the
same
for
beta
right
people
needs
to.
We
have
people
who
really
really
need
stability,
that
they
don't
want
upgrades
to
break
them.
D
They
want
to
disable
alpha
and
beta
features,
so
they
don't
get
in
trouble
with
their
users.
Like
a
you
know,
the
operator
may
not
control
all
the
people
who
are
deploying
stuff
to
the
cluster
right,
so
we
are
getting
demand
for
that
and
I
think
the
biggest
holdup
is
l7
load
balance
who
the
lack
of
a
stable
API
there,
but
once
we
had
a
stable
API
there
like
betas
the
new
alpha
for
a
lot
of
people,
I
think.
D
So
and
we're
going
to
need
this
mechanism
on
the
API
side,
I'm
going
to
say
it
definitely
cannot
be
a
compiled
in
API
like
we
need
to
try
to
use
this
year
ID
for
it.
There
is
no
technical
justification,
especially
at
the
alpha
stage,
so
using
a
compiled,
an
API,
the
field
is
more
questionable,
but
I
would
like
to
push
really
hard
on
seeing
how
hard
the
field
gating
is.
D
I
D
C
L
Ahead,
Jordan,
you
can
use
the
dynamic
client
if,
especially
if
it's
basically
looking
up
a
single
object
and
pulling
a
single
field
out
of
it,
they
can
do
that
without
needing
compile
types.
It's
small
and
low
traffic
and
a
very
simple
object
to
get
information
out
of
they
can
do
that
with
completely
unstructured
requests.
If
we
wanted
to.
D
It
would
be
good
to
find
out
what
we'd
break.
That's
not
actually
true
since
and
we're
moving
trying
to
move
more
in
the
direction
of
and
I
wish.
We
didn't
call
a
custom
resource
more
like
dynamic
resources
is
to
compile
in
types.
It
has
a
lot
of
potential
benefits
for
rolling
out
new
features.
I,
not
for
you.
You
can
change
it.
Dynamically,
like
within
release
and
roll
it
out,
even
until
I
have
clusters
and
things
like
that.
You
get
ski
changes
immediately
or
you
can
roll
back
changes
if.
F
Something
breaks
so
like
so
many
of
these
proposals.
I,
don't
think.
There's
much
debate
among
the
sig
arch
crew,
that
CRD
or
just
Rd
is
a
is
the
right
way
to
be
adding
new
resources.
There
are
some
issues
with
it.
Yann
raised
a
few
this
morning,
like
who
registers
the
CR
D
and
what
happens
if
it's
not
there
and
those
sorts
of
things
that
I
think
we
do
answer.
But
you
know
the
thought
ask
same
questions
and
we
told
controller
okay,
so
we
need
to
come
up
with
a
good,
solid
demonstration
of
this.
D
And
the
big
the
biggest
problem
with
annotations-
and
we
can
address
things
like
dropping
the
field
and
it's
not
supposed
to
be
present,
dropping
the
annotation
and
it's
not
supposed
to
be
present
and
stuff
like
that.
But
it's
you
can't
represent
the
same
thing,
two
different
ways
in
the
same
version
of
the
API
that
there's
just
no
mechanical
way
to
make
that
work
with
all
clients
and
scenarios.
You
basically
have
to
do
it
in
different
API
versions.