►
From YouTube: Kubernetes SIG Architecture 20180920
Description
http://bit.ly/sig-architecture
Mostly about conformance testing
A
Good
morning
or
afternoon
or
wherever
you
might
be
in
the
world
today
is
Thursday
September,
20th
2018,
and
this
is
the
kubernetes
egg
architecture.
Meeting
and
I
am
your
host
Jay,
singer
DeMars,
and
if
you
want
to
follow
along
after
the
fact
or
right
now,
our
agenda
is
available
at
Vitali,
/,
sig
architecture,
and
we
have
a
relatively
truncated
agenda
today,
mostly
dealing
with
conformant
stuff.
A
So
without
further
ado,
we'll
go
to
the
first
agenda
item,
which
is
concerns
regarding
proposed
proliferation
of
conformance
profile
and
desired
alignment
between
SiC
architecture
and
conformance
working
group,
and
then
see
this
pull
request,
which
is
in
the
community,
it's
26:51
and
then
we'll
close
on
the
conformance.
That's
criteria
so
I
I
know
there's
a
few
stakeholders
in
this
conversation
here.
So
what
I'd
like
to
do
is
just
open
the
floor
to
whoever
wants
to
start
and
I
think
Brad.
A
B
If
I
took
these
out
of
context,
but
what
I
looked
at
when
I
saw
both
of
those
desires
to
do
profiles,
I
really
felt
from
a
process
point
of
view
jumping
to
right
into
creating
new
profiles
is
the
wrong
approach.
We
really
need
to
be
asking.
Why
can't
my
favorite
item
be
added
into
the
core
conformance
test
suite?
So
you
know
imagine
a
world
where
60
different
vendors
are
picking
their
favorite
subset
of
profiles
to
support.
Let's
say
you
keep
it
to
less
than
10
or
11.
B
If
we
have
60
plus
vendors
picking
their
favorite
subset
of
profiles
to
support
and
I've
done
interoperability
for
other,
you
know
cloud
environments,
I
can
assure
you
you
will
have
no
interoperability,
and
what
will
happen
is
a
customer
or
analyst
will
be
working
in
one
platform,
they'll
try
and
move
it
to
something
else.
The
the
profile
subsets
will
not
line
up
and
they
will
walk
away
with.
B
Kubernetes
is
no
longer
interoperable.
You
simply
cannot
move
your
workloads,
there
is
no
workload
portability
and
then
they
will
bash
us
and
we
would
come
back
with
the
answer
of
well.
You
didn't
see.
This
was
the
one
with
just
the
basic
profile
and
this
one
had
the
basic
profile
and
the
optional
such-and-such
and
see.
You
know
you
didn't
quite
understand
what
was
going
on
user
from
an
engineering
point
of
view.
You
can
try
that
answer,
but
the
reality
is.
B
B
Everybody
should
say:
can
we
add
my
favorite
item
to
the
core
conformance
test
suite?
If
a
majority
of
vendors
agree,
we
should
push
to
get
it
pushed
in
the
core
if
only
a
small
minority
of
vendors
want
that
bad
item
added?
That's
when
you
typically
see
somebody
say
well,
let's
make
that
an
optional
profile,
but
the
reality
is
it's
only
a
small
number
of
vendors
and
it's
an
optional
item.
Defining
a
profile
is
not
going
to
provide
you
a
lot
of
value
right.
B
B
There's
other
places
where
people
want
to
use
a
profile
for
an
optional
component
like
a
Service,
Catalog,
again,
I
think
we
can
take
you
through
some
arguments.
That
say
you
think
you're
getting
some
value
by
putting
this
into
a
profile
but
you're,
risking
all
this
confusion
to
the
end-user
by
making
a
conform,
a
kubernetes
conformance
bless'd
profile.
So
you
need
to
look
out
for
that
and
then
the
other
one
you
look
for
is
things
like
persistent
storage
where
well,
hopefully
we're
thinking.
B
We
all
need
this
and
there
should
be
a
standard
in
your
face
that
everybody
can
do
and
then
we
could
put
it
in
the
core.
So
this
was
just
sort
of
you
know.
Looking
at
this
from
say
the
conformance
point
of
view,
I'm
not
clear
on
what
the
cig
architecture
point
of
view
is
this,
but
but
ideally
we're
aligned
and
ideally
what
we're
trying
to
make
the
same
right
things
happen.
B
Point
of
view,
when
you
do
that
approach,
really
what
you've
done
if
you've
taken
the
problem
of
interoperability,
kind
of
swept
it
under
the
rug
and
then
it's
gonna
pop
up
later
on
the
end-user.
The
analysts
we're
then
trying
out
kubernetes.
So
so
I
didn't
know,
please
you
know
if
I,
if
I
butchered
anybody's
point
of
view,
please
feel
free
to
shame
me,
but
but
that's
kind
of
where
my
thought
process
was
no.
A
It's
not
about
shame,
it's
really
coming
to
a
shared,
an
understanding
about
how
we
seek
informants
to
us
and
what
the
role
is
and
why
we're
approaching
the
problem.
That
way
so
I
think
Brian
has
a
pretty
clear
point
of
view
on
this.
So
I'll
turn
it
over
to
him
and
then,
if
anybody
else
is
once
this
after
Brian
just
raise
your
hand
or
ping
me
and
chat
and
we'll
go
from
there.
Okay.
C
Api's
that
are
super
critical
to
covered
by
conformance
like
pods,
which
are
highly
highly
pluggable,
are
not
well
covered.
We
need
to
in
order
to
fan
out
the
review
effort.
We
need
to
have
really
crisp
criteria.
S'alright
the
current
stage,
we're
trying
to
categorize
the
types
of
incompatibility
and
optionality
and
other
caveats
that
exist
in
the
current
tests,
and
that
may
also
exist
in
other
existing
tests,
or
you
know
just
sort
of
theoretically
things
we
know
about
like.
Should
you
be
able
to
contact
the
public
Internet?
C
C
C
If
our
back
is
implemented,
we'd
probably
want
to
behave
like
our
back
everywhere
else,
but
it
would
be
reasonable
to
not
support
it.
In
my
opinion,
and
our
back
actually
has
usability
issues
right
and
you
need
to
fix
those
issues,
but
you
know
there
are
reasonable
reasons
why
you
might
not
use
that.
So
that's
just
one
example,
but
there
are
a
number
of
features
that
are
served
in
that
category
where
things
are
supported
in
different
ways
and
some
things
we
haven't
even
figured
out
how
to
abstract
enough
for
conformance
like
storage
volumes.
C
As
just
one
example,
there's
no
network
attached
volume
that
is
available
everywhere,
so
we
have
to
figure
out
how
to
abstract
that
using
persistent
buying
claims
and
storage
classes,
and
things
like
that
before
we
can
even
begin
to
think
about
covering
that
in
performance.
So
I
don't
want
to
end
up
with
a
cross-product
of
twelve
different
profiles.
I
totally
agree
that
would
be
a
nightmare
and
conformance
would
become
meaningless.
I
could
see
an
additional
profile,
a
optional,
slightly
non
portable,
but
super
commonly
supported
functionality.
C
Don't
think
we
know
exactly
what
that
looks
like
yet,
but
I
do
want
to
make
sure
that
we
have
a
way
of
confirming
portability,
because
if
you,
you
know,
if
different
things
can
be
locked
down
on
every
single
environment,
again
we'll
be
back
with
things
in
practice
being
non
portable
right.
So
that
kind
of
lockdown
feature
set.
C
It's
gonna
be
critical
to
define
some
sort
of
profile,
our
on
that
and
I'm
thinking
that
it
would
probably
should
be
today's
profile
like
this
really
really
really
should
work
everywhere
and
so
in
terms
of
mitigating
cross
product
effects.
Another
approach
we
can
do
is
have
profiles
be
cumulative,
like
you
must
support
everything
and
all
the
profiles
below
this
one.
C
B
And
I
knew
all
that,
but
there's
a
key
process
step
which
is
and
I'll
take
our
back.
There
really
needs
to
be
a
discussion
with
the
60
plus
vendors,
where
you
get
a
good
feel
for
how
many
of
you
really
think
you
you.
You
have
a
plan
to
support
this,
because
if
pretty
much
every
vendor
raises
their
hand,
I
think
I
can
make
the
case
put
it
in
court
and
then,
if
only
10%
of
the
people
raised
their
hands.
Well,
you
can
create
a
profile.
B
But
if
you're
thinking
you're
creating
that
profile-
and
you
are
contributing
to
to
making
kubernetes
more
across
platforms,
I
would
argue
that
I,
don't
think
you're
getting
as
much
impact
as
you
might
think
by
creating
the
new
profile.
But
that's
why
I
really
want
that
process
statement
of
having
those
conversations,
because
what
I'm
expecting
to
happen
and
what's
happened
is
the
past
is
of
all
your
list
of
cool
things.
B
There's
going
to
be
a
certain
list
that
pretty
much
everybody
wants
to
do
and
we
should
push
and
motivate
to
get
everybody
to
put
it
into
the
core
because,
as
you
put
it
into
the
core
and
that's
the
piece,
that
is
the
big
piece
that
truly
you
can
think
about
that.
If
I
take
my
stuff
and
I
move
it
from
one
platform
to
another,
I
can
be
guaranteed.
That's
gonna
work!
That's
really
what
you
want
to
happen.
B
First,
as
the
best
option
best
option
is
and
I
don't
know
what
the
case
is
because
I
don't
think
anybody's
asked,
but
if
we
define
what
an
are
back
profile
is
I
would
love
to
hear
if
it's
60
vendors
that
are
saying
yeah,
we
all
want
that
in
which
case
squash
it
like
we
squash,
multiple
commits.
You
know
multiple
PRS
and
the
one
PR
make
it
into
the
core.
D
I'm
done,
thank
you,
yeah
I,
think
I
don't
want
to
over
tilt
on
vendors
and
when
I
look
at
sort
of
how
other
communities
have
you
know
essentially
had
vendors
driving
the
product.
I
think
that's
one
of
the
things
that
we're
trying
not
to
do
in
kubernetes,
and
so
you
know,
arguments
that
start
with.
Let's
just
pull
the
vendors
and
do
what
they
say
is
not
going
to
carry
a
lot
of
weight
with
this
community
and
I.
Think
part
of
it
is
that
it's
up
to
us
to
lead
not
for
the
vendors
to
lead.
D
So
as
a
group,
we
need
to
be
principled
in
terms
of
why
we're
doing
stuff
who
the
users
are
and
really
focus
on
those
end,
users
and
I.
Think
not
all
users
are
going
to
necessarily
come
through
vendors
when
I
look
at
say
the
Linux
kernel
like
if
we
actually
talk
to
vendors
we'd
be
looking
at
like
the
mainstream.
You
know
distributions,
but
because
a
Linux
kernel
has
well-reasoned
interfaces
between
the
kernel
and
the
rest
of
the
user
space.
D
And
then
I'd
like
just
to
respond
to
Brian's
point
around
sort
of
like
how
do
we
want
to
structure
the
profiles?
One
thing
that
I'd
like
to
have
us
have
as
an
option
here
is
actually
thinking
about
bundles
of
functionality
and
then
how
do
you
actually
specify
those
bundles
add-in
to
a
profile?
So
or
maybe
you
call
it
test
Suites
and
profiles,
and
maybe
we
say
this
profile
is
a
set
of
test
Suites.
C
E
Joe
said
most
of
the
things
that
I
wanted
to
say,
but
then
the
other
one,
a
couple
of
things
that
I
wanted
to
add,
which
was
like
more
practical
is
we
have
60
vendors
who
said
that
they
tried
the
test
to
eat
and
things
like
that.
But
I
don't
see
enough
feedback
from
those
vendors
saying.
Look
this
test
doesn't
make
sense.
Look
this
thing
being
tested
is
not
right
so
and
just
for
example,
right
the
practical
problem
why
one
of
these
things
started
was
in
the
use
of
the
privileged
flag
and
I.
E
Don't
think
a
lot
of
people,
people
will
switch
that
off,
but
then,
when
they
are
doing
conformance
test,
they
will
switch
it
on
so
that
they
can
pass
the
conformance
test.
So
that
is
not
what
we
would
like
to
encourage
right.
So
that
is
from
the
practical
point
of
view.
Then
there
were
some
people
who
came
up
with
saying:
okay
view
it.
This
needed
the
internet,
so
they
got
so
that
kind
of
feedback
is
fine,
that
the
test
is
not
working.
E
But
what
was
missing
from
you
know
the
60
vendors
is
nobody
looked
at
the
existing
test.
Suite
and
whether
it
actually
made
sense
that
each
test
that
are
there
actually
did
something
important
right.
So
that
is
the
feedback
that
I
would
like
to
get
from.
The
people
who
are
working
on
these
tests
at
different
vendors
and
I
want
them
to
engage
in
the
community.
Just
like
everybody
else
does
you
know,
create
issues
you
create
pr's
and
follow
the
community
process.
So
we
can
I,
don't
want
to
give
the
vendors
more.
C
B
Iii
want
to
apologize,
I
mean
when
I
when
I
say
vendors
I
do
mean
a
more
expanded
form
than
just
vendors.
It's
you
know,
whoever
is
providing
a
coop
environment
for
people
to
run.
You
know
again,
I
keep
the
concept
of
conformance.
Is
me
as
an
end
user.
I
want
to
feel
like
I
have
workload
portability,
that's
the
goal
of
conformance
right,
so
I
can
go
from
here
to
maybe
what
is
say
a
vendors
environment
to
maybe
to
something
else.
That's
a
nada
vendors
environment.
B
What
have
you
and
I
apologize
for
being
a
little
sloppy
with
my
terminology
there,
but
the
concept
is
you
know,
can
you
look
yourself
in
the
eye
and
think
well,
if
I
define
all
these
profiles,
I've
made
things
better
for
my
end-user,
so
leave
that
bleep
the
whole
vendor
thing
out
of
it.
If
you
define
a
whole
bunch
of
profiles,
do
you
really
feel
you've
made
things
better
for
your
end-users?
I
would
argue.
B
That
is
I
think
completely
in
sync,
with
with
my
concern
with
there
being
more
process
there
to
say,
let's
say,
make
sure
we
get
this
right
and
and
try
as
best
we
can
I
understand
the
wheels
will
fall
off
on
Brad's,
wonderful
approach.
Eventually,
you
know
there'll
be
something
that
is
worthwhile
that
couldn't
have
gone
into
core
I,
think
you
do
your
end
users
a
disservice.
B
If
you
don't
at
least
try
and
ask
that
question
first,
that's
what
I'm
saying
just
just
remember
that
poor
end-user,
who
is
now
got
a
think
about
you,
know
multiple
profiles
and
and
really
can
I
map
from
this
environment
to
the
other,
that
that's
who
I
am
truly
worried
about.
I
know:
I
mentioned
vendors,
but
but
I
am
an
end-user
focused
person.
Well,.
C
F
That
so
yeah,
so
when
I
look
at
this
and
I
need
to
comment
over
here,
you
know
there's
kind
of
two
different
things
here
right.
There
is
conformant,
because
that
really
helps
the
end
users
who
end
up
using
the
clusters,
but
for
the
vendors
they're
trying
to
market
and
make
sales
their
products,
especially
as
they're
trying
to
get
everything
to
take
off
right
now,
right
and
so
I
bet
you
for
a
lot
of
them.
F
They're,
probably
trying
to
get
most
of
them,
are
probably
trying
to
get
their
distros
to
take
off
right
now
and
so
they're,
not
putting
that
time
into
necessarily
listening
in
to
end-users
as
they're
dealing
with
sales
and
marketing
and
pulling
stuff
together
and
trying
to
make
it
the
experience.
Great
so
is
it's
kind
of
two
different
purposes
here.
Are
we
making
compliance
for
the
end
users,
so
we
need
good
and
user
feedback
well.
A
So
the
the
core
purpose
of
what
these
are
trying
to
accomplish
is
that
we're
trying
to
provide
assurances
to
end
users
that
workloads
that
they
have
will
will
work
in
a
similar
way
across
different
cloud
providers
and
vendors
and
we're
trying
to
also
provide
sort
of
those
guardrails
and
walls
around
what
constitutes
the
core
kubernetes
experience,
and
so
those
those
things
together
sure
they
may
have
implications
in
terms
of
how
saleable
product
is
or
not,
but
honestly
those
those
concerns
shouldn't.
Be
we
don't
that's,
not
our
problem.
A
The
way
people
deal
with
these
tests
in
the
real
world
is
something
that
is
outside
of
our
concern.
We
just
have
to
make
the
best
choices
we
can
and
on
behalf
of
of
our
user
community
and
and
the
the
providers
that
are
trying
to
follow
these
tests
should
do
so
in
good
faith
and
be
consistent
with
those
the
purpose
of
those
tests
as
well.
So
I
I,
don't
I,
don't
like
the
idea
of
drifting
off
into.
Is
this
something
that's
done
for
market
value
or
not?
It's
like.
We
have
a
purpose.
G
We're
all
in
violent
agreement
we're
just
talking
about
it
differently,
I
kind
of
want
to
move
on,
because
everything,
that's
being
said,
is
being
regurgitated
in
some
different
fashion,
saying
the
exact
same
thing,
I
think
we
all
agree
to
many
of
the
same
concerns
and
I've
been
in
this
effort,
since
epoch
and
I've
heard
the
same
story
and
stick
from
different
people.
It's
generally,
we
are
generally
saying
the
same
things,
so
you
know
we
have
a
lot
of
people
on
this
call.
B
C
B
H
H
I
cannot
share
my
screen
because
the
host
has
disabled
it.
Maybe
somebody
else
wants
to
do
it,
but
okay,
I
am
a
co-host.
Now,
let's
try
the
skin
to
do
okay
cool,
so
this
doc
was
sourced
from
this
poll
request:
I'm,
the
owner
of
it
and
then
Tim,
Clayton
and
Brian
are
supposed
to
be
the
people
who
give
sign-off
and
looking
through
a
bunch
of
the
feedback.
H
The
biggest
concerns
I
saw
repeated
a
couple
of
times
were
around
data
and
optional
features
which
I
kind
of
want
to
punt
to
out
of
scope
like
you,
y'all
were
like
clearly,
there
are
lots
of
opinions
and
thoughts
on
profiles
and
optional,
stuff
and
I.
Don't
care
I
just
want
to
focus
on
the
or
level
of
functionality,
so
the
I
felt,
like
Tim,
st.
H
Clair,
maybe
had
some
opinions
on
how
we
could
further
refine
the
list
of
requirements,
and
there
were
concerns
around
like
privileged
or
non-standard
file
system,
things
that
maybe
we
needed
to
refine
a
little
bit.
I
also
heard
some
concerns
that
it
was
unclear
whether
or
not
this
document
was
trying
to
state
intent
or
state
of
the
world,
and
so
I
put
a
little
blurb
here,
where
it's
about
intent
and
not
about
profiles
and
step.
H
One
is
to
go
through
and
make
sure
that
the
existing
conformance
tests
meet
all
of
these
requirements,
and
it
sounds
like
during
the
last
meeting
there
was
discussion
of
adding
additional
string,
ly
typed
tags
to
the
test
names
to
define
things
like
these
are
tests
that
require
privileged
access.
These
are
tests
that
require
network
access
things
of
that
nature
and
that,
then
we
could
follow
up
and
decide
whether
that
means
we
should
kick
those
tests
out
of
conformance
or
whether
or
not.
We
should
expand
the
scope
of
conformance
to
include
those
tests.
G
H
So
to
me,
the
biggest
outstanding
thing
was
whether
or
not
Tim
you
seem
to
have
the
most
concerns
about
making
sure
the
requirements
were
bulletproof
and
Brian.
You
had
something
about
network
stuff
somewhere
in
refining
the
list
of
requirements.
We
need
to
add
something
about
networking.
It's
unclear
to
me
whether
you
mean
we
should
make
networking
part
of
core
conformance
or
whether
tests
that
cover
networking
or
something
we
want
to
do,
and
we
should
tag
them
with
a
networking
tag
or
something.
H
Mean
look
at
Mike
you're,
saying
networking
behavior
isn't
going
to
be
surfaced
by
API
and/or
code
coverage.
Now
this
part,
so
it
sounds
like
you
want
to
make
sure
we
somehow
prioritize
networking
in
the
tests
that
he
put
together
to
me.
That
probably
sounds
like
there's
an
additional
like
tag.
We're
gonna
have
to
put
for
these.
This
requires
internode
or
interior
pod
networking
I.
Don't.
C
H
C
That
is
an
example
of
our
complication,
and
so
both
tests
that
are
run
using
some
emulation
environment
like
doctor
and
doctor,
wouldn't
do
real
networking
I
guess
they
could
still
pass.
Maybe
that's:
okay,
but
yeah
single
node,
like
mini
cube,
wouldn't
be
able
to
pass
at
that
point.
I
think
we
do
have
some
tests
that
do
to
the
way
they
label
or
tame
things
require
multiple
nodes
already.
So
we
have
to
decide
what
we
want
to
do
about
that.
C
Got
me
just
need
to
be
a
special
case
where
we
say:
well:
it's
not
worth
giving
the
badge
of
conformance
to
to
testing
to
fools
like
Minnie,
Cube
and
there's.
We
should
just
categorize
the
test
results
and
tell
people
look.
You
know
some
of
these
categories
may
not
fail
and
your
or
may
not
pass
in
your
test
environment.
H
C
I
Just
suggesting,
maybe
maybe
it's
worthwhile
to
have
a
third
mode-
that's
not
pass
or
fail.
That
is
this
test
ran
and
determined
that
it
is
not
eligible
for
this
environment.
It
shows
up
as
no
yellow
in
some
dashboard.
It's
not
a
failure,
but
you
have
to
understand
that
if
you're
looking
at
conformance
results,
this
test
did
not
run
yeah.
H
Okay,
did
anybody
have
any
specific
concerns
to
raise
because
I
feel
like
I,
have
swept
through
the
dock,
and
there
was
nothing
that
really
made
me
want
to
add
or
change
the
existing
list
of
requirements.
The
main
things
that
I
iterated
on
we're
clarifying
that
this
is
definitely
just
core
core
core
core
I:
don't
care
about
Plata
I?
Don't
care
about
optional!
That's
later
and
I
tried
to
clarify
the
examples
of
tests
we
which
aren't
eligible,
was
making
sure
yeah.
H
So
if
concerns,
because
the
reason
I
brought
this
into
a
Google
Doc
in
the
first
place
was
I
thought,
then
we're
going
to
be
lots
of
opinions
on
exactly
how
we
should
refine
the
specifics
of
the
requirements
and
I
guess
what
I?
What
I'm
taking
away
is
that
last
week
we
all
decided
we
should
just
tag
what
those
different
special
cases
are
in
the
existing
conformance
tests
and
then
come
back
and
decide
whether
or
not
we
want
to
actually
consider
that
core
yeah.
C
H
Like
figuring
that
out
later,
but
I
will
also
say
for
what
it's
worth
the
test:
metadata
I,
don't
I
personally,
don't
know
how
useful
this
stuff
is,
and
I
I,
just
one
complication.
We
have
with
the
way
it's
best
applied
comments
next
to
attest
is
that
it
doesn't
work
with
table
based
tests.
So
I
would
question
whether
or
not
this
is
this
is
super
valuable
or
whether
we
want
to
consider
a
different
way
of
doing
this.
C
C
Name
is
what
the
tests
are
testing,
so
someone
actually
go
through
look
through
what
the
tests
are
testing
and
like
write
down
a
couple
sentences
about
why
you
think
they're
testing
I
agree
that
there's
no
good
way
of
maintaining
that
I
questioned
the
value
of
table
based
tests
for
this,
but
you
know
I
can
see
the
point
to
that
and
the
table
based
test
could
could
have
a
description
that
says
you
know
this
probes
get
for
all
ap
ice
or
something
like
that.
Yeah.
H
H
H
Don't
necessarily
feel
like
this
is
in
scope
for
this
PR,
so
I'm
going
to
give
a
last
call
on
the
requirements,
and
then
I
will
put
put
this
back
into
the
PR
and
get
ready
to
merge
it
tomorrow,
and
the
next
steps
are
to
iterate
through
and
add
tags
like
privileged
and
networking
in
hosts
FS
to
access
to
tests
that
acquire
that
stuff.
Okay,.
C
So
this
is
another
case
where,
in
some
environments,
they
may
reasonably
walk
down
these
of
toleration,
x'
and
note
selectors
and
things
of
that
nature
and
that
breaks
some
tests
that
at
least
are
being
proposed
for
conformance.
I
guess,
is
similar
to
the
single
mode
multi
node.
We
have
an
additional
thing
which
I
haven't
figured
out
what
to
do
about
yet
the
some
providers
may
have
nodes
that
are
tainted.
That's.
C
Then
the
conformance
test,
wouldn't
naturally
run
on.
So
as
long
as
there
are
a
sufficient
number
of
nodes,
one
or
two
that
are
not
tainted
conformance
could
pass
on
those
nodes
and
then
the
other
nodes
could
be
completely
incompatible
and
now
wouldn't
get
serviced
by
the
tests.
I
don't
know
what
this.
G
D
Think
this
is
one
of
those
hard
decisions
like
I'm
uncomfortable
with
some
of
the
things
that
gke
does,
for
example,
with
respect
to
I,
try
and
tune
some
of
the
things
that
are
installed
onto
his
very
small
cluster,
and
it
goes
behind
my
back
and
modifies.
Those
like
is
that
conforming,
behavior
and
I
think
we
should
probably
think
about
whether
that's
something
that
we
want
to
be
conforming
or
not.
Well,.
J
I
mean
this
is
a
standard
admission
plug-in
that
is
shipped
with
cube
core
that
can
be
turned
on
and
enabled
that
control
scheduling
policy.
And
if
you
choose
to
control
scheduling
policy
in
this
way,
shipped
with
cube,
then
you
will
fail
this
conformance
test.
I,
don't
think!
That's
you!
You
can't
have
a
conforming
cluster
and
then
say:
here's
the
official
plugin
to
make
your
cluster
non-conformance.
Alright,
there's
all.
D
C
So
that
comes
back
to
the
issue
that
was
raised
before
about
how
much
one
people
to
gain
conformance
tests
or
got
to
change
standard
configurations.
Just
so
tests
can
pass
and
then
you
know
that's
not
the
same
experience
as
users.
That
may
be
another
reason
why
we
need
some
kind
of
profile.
It's
worth
thinking
about.
Like
do
you
support
standard
set
of
cluster
admin?
Things.
Do
you
support,
you
know,
I,
don't
know
what
that
might
be,
but.
D
Because
I
think
there
is
a
difference
and
I
think
we
see
this
with
our
customers,
where
some
customers
want
full
admin
on
their
cluster.
They
want
to
be
able
to
do
this
stuff
and
then
there's
vendors,
who
are
like
you
know:
I'm,
not
gonna,
give
you
full
admin,
because
this
is
a
managed
cluster,
not
an
actual
sort
of
a
self
management
cluster
and
there's
different
capabilities
that
we
may
want
to
represent
to
users
across
those
two
different
pros.
So.
C
It's
worth
starting
to
catalogue
those
things
as
they
come
up,
so
we
can
think
about
how
you
want
to
deal
with
them
because
again,
I
think
you
know
we're
hearing.
You
know
I
work
for
a
vendor,
but
I
do
care
a
lot
about
the
users
where
I
want
to
confirm
it's
in
the
first
place
so
that
things
can
be
reasonably
portable
and
you
know-
and
some
people
want
things
very,
very
locked
down,
and
so
we
may
even
need
test
to
prove
that
things
that
are
locked
down
at
some
point.
C
G
Commented
on
the
on
the
PR:
there
needs
to
be
a
check
that
it's
at
least
greater
than
one.
Otherwise
you
can
actually
the
way
the
test
is
written
and
you
could
actually
not
schedule
anything
of
zero
and
have
a
return
of
zero
and
B
okay.
So
it
went
to
the
opposite
spectrum
so,
right
now
we
need
to
have
at
least
one
to
make
it
solid.
Otherwise
we
need
to
a
her
out
or
fail
something
better
something:
okay,.
C
So
the
test
is
just
not
rigorous
enough
as
well.
Okay,
so
this
one
we
may
need
to
follow
up
after,
but
I
mean
I,
don't
think
we
need
the
criteria
to
be
perfect
and
what
I
found
is,
as
we
review
tests
more
issues
come
up
that
then
we
thought
about
before
so
for
the
set
of
people
that
were
spinning
up
like
Aaron
Tim,
you
know
on
redoing
the
test
just
like.
If
something
is
not
in
the
list,
you
know
just
raise
it
and
we
can
discuss
it
and
we
can
document
the
resolution
of
that
I.
C
H
I
think
another
thing
where
it's
being
clear
about
with
this
Google
Doc
is
some
people
maybe
took
this
as
this
is
the
set
in
stone
list
of
requirements
and
the
intent
is
for
this
to
be
a
living
document
that
we
refine.
As
we
learn
more
of
these
things
and
take
a
closer
look
at
stuff,
I
feel
more
comfortable,
saying
it
is
set
in
stone
when
we've
reached
a
stage
where
we're
comfortable
talking
about
profiles,
yeah.
C
C
A
C
C
You
know,
because
those
are
those
are
the
areas
where
they
really
might
be
inconsistent
across
different
providers,
and
you
know
the
optional
behavior
loss
to
deal
with
eventually,
but
they
don't
even
have
coverage
of
half
the
pod
features
at
least
right
now,
so
that's
and
that
pods
cubelet
is
highly
pluggable
with
C,
Ric
and
ICSI,
and
there,
you
know,
are
other
implementations
and
all
of
all
the
node
components
at
this
point
as
well.
So
Jim's,
quick.
E
H
Two
weeks
ago
and
I
was
told
that
is
considered
orthogonal
to
this
effort,
but
I
think
we
all
agree.
We're
bending
ginko
well
past
its
breaking
point
and
I'm
trying
to
see
if
I
can
find
some
of
my
teammates
who
are
interested
in
attempting
to
doctor
how
we
do
some
of
this
stuff.
King
comes
not
strictly
necessary.
I
think
we
were
using
ginkgo
because
we
needed
JSON
results
and
that's
not
there
are
there
other
examples
of
people
doing
much
the
same
without
King
Co,
but
that
does
require
engineering
effort.
Yes,.
I
H
Exactly
so
there's
another
project:
that's
made
some
headway
on
that
and
we
have
a
community
member
he's
working
on
refactoring
t2e
framework,
but
that's
not
necessarily
the
same
thing
as
divesting
ourselves
of
ginkgo
so-dimms.
If
you
know
of
anybody
who's
willing
to
work
on
this,
please
send
them
our
way.
Okay,
we
all
agree.
It's
it's!
It's
well
past
time.
Okay,.