►
From YouTube: SIG Architecture 20181101
Description
A
A
Our
agendas
not
located
in
annoying
phone
call
is
located
that
bitly,
slash
sick
architecture,
and
you
can
open
that
now
and
we're
gonna
go
through
that.
So
the
first
item
up
on
the
agenda
is
the
the
PR
for
our
Charter.
Let
me
pull
out
up
here,
and
basically
this
is
not
much
more
than
the
boilerplate
that
is
provided
by
the
steering
committee
for
us
and
other
seeks
to
work
with.
B
A
So
there
were
a
few
things
that
have
come
up
over
time:
I
concerns
about
the
crew
etc,
and
basically
it
feels
like
those
things
can
and
should
be
reviewed
over
time
and
that
the
best
thing
to
do
is
just
to
start
with
a
charter
draft
so
that
we
have
some
governance,
because
right
now,
as
the
the
sig
is
lined
out,
it's
pretty
I
mean
our
Charter
is
pretty
rudimentary.
So
the
the
second
half
of
this
work
is
that
we
need
to
go
in
and
define
our
sub
projects.
There's
already
some
language
out
there.
B
A
A
At
least
an
hour
learning
how
to
manage
the
kept
board
and
going
through
caps
and
checking
that
their
status
of
their
state
were
aligned
in
the
board.
Thank
you
so
much
for
that.
That
is
a
really
generous
gift
of
time,
too,
to
the
sick.
So
Brian
was
there
something
that
you
wanted
to
mention
on
the
the
Charter
thing.
C
D
Just
think
you
know,
starting
simple,
merging
and
iterating
is
great,
as
you
pointed
out,
numerous
times
were
lacking
people
living
our
efforts
forward.
The
the
efforts
are
around
API
and
architectural
governance,
and
the
renewed
process
is
like
a
guarantee
process
that
we
talked
about
for
a
long
time.
D
The
code
organization,
which
is
the
most
understaffed
of
all
the
things
that
we've
been
talking
about
for
the
longest,
so
you
know
yeah
we're,
making
good
progress
on
conformance,
we're
starting
to
make
some
progress
on
kept
and
and
I'm
hoping
to
rekindle
the
progress
on
the
API
review
process
and
get
those
things
moving.
I
think
those
are
top
priority
for
the
sig
is
to
actually
move
things
forward
and
get
things
done.
So,
let's
focus
on
that.
A
Okay,
interestingly
too,
as
matt
was
going
through
the
process,
he
found
a
few
API
review
candidate
PRS
out
there
so
or
at
least
caps
that
had
implications
as
far
as
API.
So
that
was
a
nice
that
they
confirmed
that
there
is
value
in
going
through
these
things
and
putting
some
scrutiny
on
them
and
seeing
what
needs
to
be
reviewed
by
this
sake.
Cuz
and
he'll.
Probably
back
me
up
in
saying
this-
that
it
was
a
it
was
probably
20%
of
the
caps
had
some
sort
of
architectural
impact
so
granted.
A
D
Absolutely
and
right
now,
that's
super
manual.
You
know
hopefully
moving
the
caps
to
a
known,
a
repo
unto
itself
will
create
a
tolerable
amount
of
traffic
so
that
we
can
monitor
it
more
closely
for
API
reviews.
Definitely
some
more
automation.
We
helped
surface
those
things.
The
roll
board
was
again
pitched
during
the
community
meeting.
Just
now
you
might
want
to
think
about.
D
If
we
there
are
concrete
tools,
so
we
think
we
can
help
us
and
someone
hasn't
bandwidth
to
work
with
on
I
get
those
things
don't
we
might
want
to
consider
posting
a
roll
to
roll
board
and
it
doesn't
just
have
to
be
building
cooling.
It
could
be
other
things
as
well,
but
right
now,
I
think
we're
even
bottlenecked
on
the
oversight
and
figuring
out
what
to
do
sign,
but
once
we
get
that
under
control,
we
there
probably
other
people
we
can
recruit.
Tell.
A
Another
thing,
too,
is
that
we
talked
about
the
the
crew
and
sort
of
what
what
that
decision-making
buddy
looks
like
us.
We
do
have
sort
of
a
generalized
decision-making
function.
I
mean
there
are
things
that
come
to
us
that
we
just
need
to
come
up
with
some
sort
of
consensus
on
and
the
federated
model.
That,
basically,
is
what
Dan
was
describing,
essentially
that
if
you've
got
ownership,
if
you're
in
an
owner's
file
in
any
of
the
sub
projects
that
we
have
then
you're
automatically
federated
into
the
decision-making
body.
A
A
D
I
think
I
think
we
can
improve
on
that
for
the
things
that
have
come
to
the
group.
We
have
clear
deciders
and
a
decision
process
right
like
if
it's
an
API
change.
We
have
API
Cooper's,
it's
not
specific
as
a
whole.
It's
a
specific
subgroup
Tostig
for
other
general
issues
like
caps
to
come.
You
know,
I
think
we
provide
some
some
guidance
or
raise
issues
that
they
take
back.
So
it's
not
a
decision
as
much
as
informative,
sort
of
role
or
function
and
I.
D
Think
that's
fine,
for
whoever
shows
up
you
know
can
definitely
provide
their
their
wisdom
or
insights
into
the
problem
without
a
formal
decision-making
process.
So
you
know
there
may
be
issues
that
you
come
up
where
we
need
new
processes,
but
I
think
for
the
most
part.
So
far
that
hasn't
really
come
up
in
this.
A
Forum,
yeah
I
just
want
to
make
sure
that
dunces
concerns
are
heard
because
he
is
very
passionate
about
it
and
I
understand
and
get
where
he's
out
on
that.
So
I
just
want
to
respect
that.
There's
there's
a
lot
of
commentary
that
we
had
that
I
think
at
some
point
we
need
to
reconcile
and
just
figure
out
the
right
way
to
do
it.
I.
E
Had
a
question
on
that
topic,
so
it
seems
like
in
the
latest
revision
of
the
Charter
we've
essentially
pushed
a
lot
of
the
work
and
the
decision-making
down
into
these
sub
projects,
and
it's
not
clear
to
me
how
so
the
sub
projects
looking
at
the
relevant
page,
are
defined
by
owners
files
and
various
different
repository
as
far
as
I
can
tell
how
how
do
people
and
we're
sort
of
complaining
that
that
people
are
not
getting
involved
enough
in
these
in
the
work
of
the
sig?
How
do
people
actually
get
involved?
E
D
So
I
guess
a
couple
of
things
about
that.
One
is
the
sub
projects.
Instance
diamo,
we're
in
process
of
updating,
with
based
on
our
previous
thread,
Quinten
about
what
the
sub
project
should
be,
so
we're
copying
up
from
the
previous
PR
sandbox
and
just
60ml
kind
of
as
we
speak.
You
know
in
terms
of
where
those
discussions
take
place.
I
think
it
depends
on
the
kept
process.
It's
mostly
through
discussions
in
this
meeting,
and/or
segi
m
and
specific
PRS
and
issues
in
the
community
repo
with
respect
to
conformance
testing.
D
F
I
just
want
to
live.
We
heard
the
quiz
question
which
is
cigs,
have
a
required
to
have
public
meetings,
but
apparently
decisions
are
going
out
meeting
SIG's.
They
need
sub
projects
where's
the
required
meeting
that
I
can
attend
it's
public
for
some
project.
It's
this
one.
You
get
a
super
duper
long
answer.
Well,.
D
I
mean
principally
it's
this
one
so
across
the
across
the
entire
project,
mini
SIG's
have
multiple
sub
projects
and
they
don't
necessarily
have
meanings
for
every
single
project
like
if
you
look
at
Signet
work,
there
are
services,
there's
ingress,
there's
odd
networking.
You
know,
there's
CNI.
There
are
a
bunch
of
different
sub
efforts.
A
lot
of
the
work
on
the
project
gets
done
in
TRS
and
non
meetings,
and
that
is
also
true
for
the
same
right.
So,
like
the
conformance
PRS,
there
are
many
inflight.
D
E
But
let
me
just
let
me
just
make
it
clear
and
sort
of
goes
back
to
what
Eric
said.
So
this
is
not
me
asking
how
do
I
get
involved.
This
is
me
pointing
out
that
we're
complaining
that
that
not
enough
people
are
involve
act
right,
learn.
We
don't
clearly
communicate
how
people
should
get
involved,
because
the
webpage
at
the
moment
has
a
bunch
of
inaccurate
sub
projects
as
far
as
I
can
tell
and
no
indication
of
how
people
can
actually
get
involved
in
healthcare.
E
D
Is
actually
true
because
we
regularly
go
over
the
chase
is
created
dashboards
for
those
sub
efforts
and
we
go
over
those
dashboards
pretty
regularly
in
this
meeting.
So
you
can
get
a
sense
for
what
the
group
does
for
that.
I
totally
agree
that
we
need
to
update
the
list
of
sub
projects.
The
more
accurate
really
accurately
reflect
the
work
the
group
is
currently
doing
and
we're
working
on
that.
If
what
you're
also
have
important
to
say,
here's
how
to
get
involved
I
think
that
would
be
useful.
D
F
B
I'm
gonna
interview
on
because
so
yeah,
so
that's
a
big
mean
problem
like
we
are
saying
that
people
don't
have
people,
we
have
to
welcome
people
and
we
have
to
get
them
to
do
what
we
would
like
them
to
do
so
for
each
of
those
sub
projects.
We
should
have
a
few
things
that
we
down
saying
go.
Look
at
this
github
query.
Go
look
at
this
dashboard.
You
know
some
minimum
stuff
like
for
five
lines
for
each
of
the
sub
project.
B
If
you
can
write
them
up,
you
know
we
can
point
that
to
people
and
say
you
know,
that's
where
the
work
gets
done.
Please
go
involve
yourself
in
the
PRS
and
look
at
the
reviews,
and
you
know
look
at
the
caps
and
look
at
these
caps,
which
are
of
importance
to
us
and
look
at
these
dashboards
and
see
if
you
can
make
progress
on
the
dashboards
moving
things
from
one
column
to
the
other
right.
B
A
Yes,
I
can
do
that.
Okay
and
I
just
want
to
call
an
intern
I'm.
Sorry
I
totally
I'm
jumping
it
for
you
right
now,
but
this
is
topical.
The
process
for
Matt
Farina
to
make
a
huge
impact
on
our
kept
board.
Was
him
saying
to
me
and
slack:
hey
Jase
I
want
help
I'm
like
okay
you're,
so
gonna
regret
it.
They
there
we
go.
The
next
thing
I
did
was
I
added
him
to
the
the
maintainers
file
for
the
board,
so
you
can
move
Carter
out
of
the
board
and
look
at
those
things.
A
Next
thing
he
did
was
programmed
of
human.
Ask
me
a
few
questions
and
I
help
them
figure
out.
What
was
what
and
what
the
states
were
is
it
was
interactive,
but
it
happened
and
work
got
done
and
it
was
really
pretty
easy,
but
I'm
I'm,
not
exaggerating
when
I
say
that
no
one,
no
one
has
approached
me
about
actually
doing
the
work,
not
one
person.
That's.
F
Been
in
the
community
for
like
three
years
not
longer
so
he
pretty
much
knew
the
right
person
to
go,
find
and
slacks
the
right
way
to
do
it
correct
what
I'm
hearing
is
like
if
you're
very
capable,
but
you
don't
know
where
to
go.
Unless
you
now
navigate
the
hierarchy.
There's
no
label
like
some
project.
That's
not
it's
not
a
resource!
Locator
hundred.
B
G
D
G
So,
if
you're
interested
enough
to
do
the
work,
you're
interested
enough
to
know
like
where
or
how
the
work
is
happening,
if
you
don't
know
that,
then
sub
projects
are
laid
out
in
the
readme
files
for
all
of
the
different
SIG's
and
yeah
okay,
those
owners
files
aren't
great,
but
those
owners
files
are
a
list
of
points
of
contact.
So
now
you
have
a
github
username
that
you
can
go
back
and
maybe
you're
resourceful
enough
to
go.
There
I
think
the
general
higher
level
things
like
Brian
is
suggesting
ask
the
mailing
list.
G
We
could
make
that
boilerplate
in
any
six
readme
hey
if
you're
interested
in
any
of
these
sub
projects
and
you're
not
sure
where
to
start,
please
send
an
email
to
blah.
I.
Think
DIMMs
thing
of
enumerated.
Just
a
couple
sentence,
description
of
what
a
sub
project
is
and
why
it
is
there.
It's
also
a
great
idea
and
guess
what
our
automation
supports.
G
E
I
mean
I
think
what
I'm
proposing
is
that
it
be
very
clear
where
work
and
decisions
are
actually
happening
and
if
they're
happening
on
issue
lists
or
pr's
with
particular
labels.
Let's
just
you
know
state
that
this
is
where
this
sub
project
does
its
work,
and
this
is
where
the
decisions
get
made
and
if
you
want
to
get
involved
in
in
helping
with
that
work
or
being
involved
in
those
decisions.
Here's
where
you
go
and
if
it's
this
meeting,
that's
fine,
but
it
doesn't
seem
like
a
lot
of
that.
E
Work
happens
in
this
meeting,
which
is
fine.
If
it's
a
different
meeting,
then
let's
you
know
tell
people
where
that
is
and
when
it
happens,
and
if
it's,
if
it's
on
a
mailing
list,
there
are
no
links
to
any
mailing
lists,
and
in
here
there
are
no
links
to
any
issue
lists.
There's
no
list
of
things
that
need
to
be
done.
That
people
can
go
and
have
a
look
at
and
say:
oh
I
can
do
that.
Let
me
contribute
here's.
How
I
do
it
and
I
think
you
know
we're
here
difficult
when.
D
E
A
That
explains
things,
and
anybody
can
read.
This
document
understand
how
to
get
involved.
It
has
names
it
has
places.
It
has
everything
that
you
need
to
know.
It's
like
this
is
one
of
our
sub
projects.
We
only
have
a
few
more
so
somebody
please
step
up
and
document
these
things,
and,
and
that
would
be
a
great
step
in
the
right
direction
as
well
so
yeah.
H
I
can
we
can
we
consider
who
are
audiences
for
this,
like
people
who
have
never
contributed
to
kubernetes
before
are
probably
not
great
candidates
for
working
on
DPI
reviews
or
code
organization
or
like
these
things
are
hard,
and
they
require
a
lot
of
experience
with
our
code
base
before
you
before
it's
going
to
be
easy
for
you,
maybe
even
before
it's
gonna
be
possible
for
you
to
help.
So
we're
not
I,
don't
think
we're
talking
about
people.
Who've
never
touched
kubernetes
before
so
people
who
have
interacted
with
the
community
community
a
little
bit.
H
D
A
F
I
Gonna
say
that
documenting
what
the
sub
projects
like
what
artifacts
are
producing
and
where
that
work
is
happening,
is
good
for
people
who
want
to
jump
in
to
help
with
the
work.
But
it's
also
good
for
people
who
are
depending
on
those
artifacts
and
need
to
find
a
person
to
ask
a
question
about
related
to
that,
and
so
I
think
identifying
the
sub
projects
is
a
good
first
step
and
then
the
people
who
are
participating
in
those
a
good
second
step
is
for
them
to
go.
I
H
A
E
I
can
I
can
plan
up
for
it
to
do
that.
I
will
go
through
the
process
and
and
put
myself
in
the
position
of
somebody
wanting
to
help
and
I
will
try
and
find
out
and
try
and
help.
Okay,
some
notes
on
exactly
what
obstacles
I
ran
into
and
if
there
are
none,
then
there's
no
work
to
be
done.
I
suspect
it's
more
difficult
than
we're
making
it
out
to
be.
You
were
on.
H
There
I
think
there's
one
very
interesting
complication
with
putting
things
in
the
owners
file
list,
which
is
the
API
reviewers,
are
scattered
through
a
bunch
of
random
owner
files
throughout
the
system
and
it's
sort
of
defined
the
other
way
like
any
any
owners
file.
That
mentions
the
API
reviewers
this
by
the
API
is
a
project.
So
it's
going
to
be
a
huge
pain
to
to
curate
that
manually
right,
I,
disagree.
D
A
And
I
was
gonna
say
so
so
we're
on
the
hook
to
do
a
contributor
summit
presentation
in
coop
con
in
a
in
Seattle
and
rather
than
any
one
of
us
monologuing
about
the
joys
of
architecture.
It
seemed
like
a
be
an
idea
to
come
to
the
Sagan
and
just
solicit
ideas
about
things
that
we
think
be
topical,
relevant
important.
The
information
we
need
to
radiate
out
like,
for
example,
do
people
even
know
that
there's
an
API
review
process
now
stuff
like
that.
A
D
D
D
D
So
what
I
was
thinking
is
we
would
put
a
stake
in
the
ground
of
what
that
we
wanted
the
direction
for
2019
to
be,
and
so
this
is
sort
of
an
opportunity
to
start
collecting.
The
people
had
strong
feelings
about
things
we
needed
to
do.
I
feel
like
this
year.
We
didn't
do
a
super
great
job
and
making
high-level
progress
in
any
particular
direction.
D
Similarly,
if
there
are,
if
you
want
to
make
statements
about
directions,
we
want
to
go
whether
it's
code
organization
and
improving
or
improving
the
release,
quality
or
stability
or
factoring
out
the
resource
management
platform
or
whatever
is
you
know,
I
think
having
some
high
level
raising
the
visibility
across
the
entire
project
on
some
small
side
of
things,
it's
not
opportunity
to
do
it.
It's
a
half
hour
plotted
to
be
a
half
hour
presentation
and.
A
A
That
sort
of
thing
it's
really
that
arkad
Sagarika
texture
acts
as
sort
of
a
program
management
body
for
this
technical,
highly
roadmap
oriented
work.
So
our
job
is
to
facilitate
the
work
to
help
SIG's
that
are
involved
to
come
to
consensus,
to
basically
act
as
the
facto
leaders
for
the
work
and
not
necessarily
the
doers
of
the
work.
So
that's
I
think
an
important
distinction
that
we
have
as
a
role
as
a
guiding
role
in
the
project.
That's
why
this
this
sig
was
originally
formed
at
the
contributor,
the
I
guess.
A
D
I
B
K
C
Reena,
you
know
I
just
had
one
question
and
it
struck
me
and
I
haven't
had
a
chance
to
go
post
it
to
the
list.
Are
there
any
legal
requirements
we
have
to
follow
when
we
fork
something
into
the
kubernetes
org,
because
I
know
bringing
outside
code
in
that's
already
been
started
elsewhere,
usually
trigger
some
stuff
and
I?
Don't
remember
what
it
is,
but
that
was
the
only
thing
that
we
probably
want
to
dot
the
I's
across
the
t-zone.
Well,.
I
Said
we
already
do
that
for
the
communities
repo
and
we
don't
do
it
for
all
the
other
repos,
what
we
go
through
every
vendor
project
crawl
through
their
git
repo.
Until
we
find
something
that
tastes
like
a
license
file
take
that
license
file
copy
it
into
a
single
place.
That
is
only
about
four
approvers
on
it
and
require
that
as
part
of
pre
submit
when
I
last
looked.
D
I
L
Process
Brendan
did
you?
Have
some
I
think
that
this
is
a
little
bit
of
a
bike?
Show
I,
think
Matt's
question
actually
was:
if
we
pull
it
into
the
org,
do
we
eat
we've
already
licensed
G
log
I,
don't
think
we're
suggesting
we're
gonna
change
the
license
of
G
log,
we're
just
changing
its
home
I.
Don't
think
it's
necessary.
D
B
A
J
B
G
So
I
can
like
I,
can
be
a
Sherpa
for
these
kinds
of
PRS
I.
Guess
that's
what
this
does
board.
It
is
that's
how
I
use
it.
I
do
actually
had
a
lot
of
things
and
shuffle
things
around.
So
thank
you,
Tim
st.
Claire
for
assigning
Hawke
and
talking
it's
on
your
board.
Now
you
are
H
a
proxy
it
as
needed
and
we'll
go
from
there.
You
got
it
I.
Think
the
other
open
thing
which
there
was
a
mailing
list
thread
about.
So
maybe
we
don't
need
to
discuss
it
too.
G
Much
was
whether
or
not
we
say
that
conformance
requires
a
multi,
node
cluster.
There's
a
daemon
set
test
that
fails
on
a
single
node
cluster.
We
said
that
shouldn't
be
conformance
because
it's
skipping.
If
the
cluster
is
a
single
node,
they
said
it
doesn't
make
any
sense.
If
the
cluster
is
single,
node
and
then
Brian
started
the
thread
on
sig
arch
asking
a.
Maybe
we
should
just
say
that
a
cluster
can't
be
considered
conformant
unless
it
has
at
least
two
notes
the
this
would
like
really.
D
D
M
M
D
L
B
L
B
H
B
D
I
think
that
that
would
that
would
be
useful,
but
the
other
thing
that
we've
discussed
doing
is
actually
characterizing
the
test
and
adding
tags
for
properties
which
we
believe
may
not
be
universally
true
right
requires
host
privilege
or
network
privilege
or
cluster
privilege,
or
you
know,
OS
Linux,
specific
features
or
Windows
teachers
or
those
kind
of
things.
I
think
that
would
be
useful
regardless
for
us
understanding.
You
know
this
test
failed.
Why
I
might
have
failed
or
you
know
what
kind
of
coverage
do
you
have
different
scenarios?
D
G
A
We
want
to
know
what
workloads
are
portable
across
different
environments
and
ecosystems,
so
it's
that
people
have
a
consistent
user
experience.
The
other
one
I,
don't
think
that
the
really
mini
cube
is
touching
on.
Is
the
developer
experience
that
what
I
develop
on
my
local
area
is
gonna
run
in
production
or
whatever
that
looks
like
so
I
think
that
we've
done
a
good
job
of
categorizing?
What
the
portable
workload
scenarios
like
but
I
think
in
the
future
is
a
2d.
We
should
talk
about
what
the
developer
experience
looks.
G
That's
that's
where
I'm
coming
from
I
did
likes
to
use
hack,
local
up
cluster
I
like
to
use
the
kubernetes
in
docker
sub
project
that
we've
started
at
stake
testing.
These
are
both
much
much
faster
and
let
me
use
development
builds
of
kubernetes
as
opposed
to
mini
cube,
which
is
locks
to
release,
builds
but
they're
single
node.
Only
so
one
proposal
I
had
was
what,
if
I
just
dropped,
multi
node
multi
node
tag
in
this
and
then
what
do
we?
And
then
this
like
makes
the
conformance
question.
Do
we
say
that?
G
Well,
it's
multi
node,
so
this
is
going
to
be
part
of
a
multi
node
profile,
because,
right
now
we
have
like
a
couple
hundred
tests
that
do
work
against
single
node
clusters.
Or
are
we
changing
the
definition
of
conformance
to
say
nope
conformance
means
has
to
be
a
multi
node
cluster,
so
I'll
tag.
This
is
multi
node,
just
so
I
know
when
I'm
running
it
on
a
single
node
that,
like
that's
a
test
that
is
expected
to
fail
for
me,
but
it
does
me
that's
why
my
local
development
environment
is
not
Corman's
for.
K
L
I'm
on
board,
with
Aaron's
proposal
to
like
I
think
having
a
base
profile
at
single
node
and
then
saying
we
have
this.
You
know
one
test
into
the
multi
node.
That's
fine,
it's
hard
for
me
to
figure
out.
If
it's
you
know
necessary,
but
but
I
think
it's
fine
either
way
are
gonna.
Do
profiles
right-
and
this
is
the
latter
discussion
like
it
is
100%
clear
to
me
that
we're
gonna
have
to
do
profiles
whether
the
easiest
way
to
start
the
profile
process
is
with
this
one
test.
Maybe.
D
We
aren't
gonna
have
to
do
profiles.
I
agree
with
that.
We
need
to
think
about
the
user
experience
or
the
profiles
and
how
many
profiles
we're
gonna
have
I.
Don't
want
to
just
do
one
profile
that
affects
like
a
really
small
number
of
tests.
I
think
that
would
be
super
confusing
for
users
if
we
end
up
with
lots
of
profiles,
most
of
which
don't
matter
so.
D
F
L
Think
the
point
is
I
think
the
point
is:
there's
gonna
be
a
bunch
of
process
associated
with
profiles,
and
this
one
is
clear:
it's
definitionally
clear
so
like
let's
go
to
the
process
with
one
test
and
go:
do
it
figure
out
the
process
and
then
we
can
do
tomorrow
and
I
mean
we're
not
gonna.
We're
not
saying
that
every
time
there's
a
one-off
test
that
fails,
you
know
we
should
make
out
a
profile.
That's
not
the
statement.
Well,
the
statement
is
this
is
an
easy
way
to
do
a
profile.
That's
obvious
and.
E
Just
wanted
to
mention
that
I
mean
if
we
zoom
out
a
little
bit.
The
main
aim
of
of
conformance
tests
is
that
I
can
write
an
application
that
does
not
step
out
of
the
conformance
tests
and
then
I
can
know
that
that
it
will
run
on
any
conformant
cluster.
But
if
the,
if
the
conformance
tests
are
not
broad
enough,
then
I
can't
possibly
write
a
useful
application
that
runs
within
them.
It
always
has
to
use
you
know
stuff
outside
of
conformance
and
on
the
flip
side.
E
If,
if
the
conformance
is,
is
you
know
too
broad,
then
then
we
limit
what
a
conformant
application
or
sorry
a
conformant
deployment
is
so
yeah.
We
can't
just
try
and
minimize
the
number
of
profiles,
because
if,
at
the
end
of
the
day,
the
profile
with
the
single
profile
we
have
is
not
useful,
because
you
can't
develop
a
an
application
within
it,
then
we
failed.
M
Well,
I
thought
was
I
think
everyone
agrees
that
profiles
your
going
to
happen
at
some
point.
I
think
Brian
is
a
very
good
point
that
if
you're
going
to
do
it,
we
should
do
it
for
something
that's
worthwhile.
So
is
it
really
worth
our
effort
or
someone's
effort
to
go
in
and
figure
out
how
to
do
profiles
to
support
the
single
node
use
case
for
one
test?
Is
that
really
where.
H
L
H
L
I
mean
I
think
it's
fine
to
say
that,
like
we're,
gonna
say
it's
not
conformant,
but
it's
the
scope
of
its
non-conformance
as
well
understood
I,
that's
different
than
saying
conformant,
except
I,
guess
at
some
level
to
the
other
point.
I
think
that
there's
two
aspects
to
building
any
program
like
profiles-
one
is
the
process
and
that's
just
straight
bureaucracy,
and
the
other
is
the
definition
of
the
profiles.
I
think
they're,
actually
both
going
to
be
semi,
thorny
and
I
think
that
we
will
make
better
program.
L
D
F
D
J
Okay,
so
so
forget
forward
on
that.
So
basically,
when
it
comes
to
to
the
windows
two
weeks
ago,
we
talked
about
you
know.
The
preferred
approach
that
we
wanted
to
do
was
to
have
a
cluster
built
that
contained
both
Windows
and
Linux
nodes,
because
in
that
mode
we
could
go
ahead
and
all
the
conformance
tests
could
still
run
and
they
would
run
on.
J
You
know
one
on
the
appropriate
nodes,
and
so
that
was
the
first
option
that
we
we
have
a
work-in-progress
PR
on
them,
that's
linked
to
there
and
what
that
does
is
basically
add
an
additional
flag
that
will
add
node
selectors
to
the
tests
appropriately.
This
is
something
that
is
a
it's
a
relatively
simple
solution
for
an
implementation
standpoint.
B
J
K
I
had
a
question
with
regards
to
what
it
means
to
be
conformance
on
a
Windows:
that's
not
a
profile
in
a
mixed
cluster,
because
it's
clear
to
me
that
some
features
will
work
in
a
and
not
B
right.
So
unless
it's
unless
it's
been
a
profile,
this
is
a
good
example
of
actually
where
I
think
profiles
matters
a
lot
more
because
the
characteristics
of
features
will
not
be
the
same
across
platforms
right
it
just
won't.
You
can't
enable
certain
workloads
with
feature
XYZ
on
this
environment.
K
L
D
Yeah
I
have
a
few
things.
I
just
wanted
to
say
about
this.
So
first
of
all,
I
want
to
thank
Brendan
for
for
dumping
test
categorization
into
the
bottom
of
the
conformance
profile.
B2
is
to
link
into
the
chat
I
think
there
are
a
few
different
issues
that
are
getting
muddled
together.
One
is
there
are
tests
that
work
in
theory
on
both
Windows
and
Linux,
but
I
think
you
may
have
to
still
have
to
have
different
images.
Yes,.
J
D
L
Do
we
network
is
already
done
right
and
merged
right?
Oh
I'm,
sorry,
this
list
to
be
merge.
Ok,
there
PR
that
the
work
is
done
against
is
not
merged
and
it's
necessary.
Like
I
mean,
for
example,
a
Chinese
conformant
person
can't
actually
pass
conformance
right
now,
because
you
can't
pull
Google
Images
right
so,
like
there's
work,
that's
needed
for
around
parameterizing
images
in
general,
yeah.
D
Cool
and
and
then
we
need
to
categorize
things
that
are
specifically
dependent
on
Linux
behaviors,
like
they're,
just
Linux
passed
through
like
a
plumber
or
something
like
that
yeah
and
it
looks
like
there
is
a
start
of
a
list
of
like
specific
tests.
I
have
had
time
to
look
through
the
whole
thing
yet,
but
I
intend
to,
and
presumably
there
might
be
tests
to
get
added
that
have
some
Windows
dependencies
and
then
there's
the
question
of
when
the
way
we
run
conformance
for
the
tests
that
are,
you
know,
sort
of
OS
independent
in
theory.
D
What
do
we
do
so
we're
gonna
have
other
tests
that
it's
already
started
coming
up
that
had
specific
requirements
of
the
host
systems,
whether
it's
GPUs
or
or
whatnot,
so
I
think
we're
gonna
want
to
think
about,
maybe
not
the
whole
cluster
as
a
you
know,
adhering
to
a
specific
profile.
But
what
do
we
do
about
tests
with
specific
requirements
on
specific
types
of
nodes
and
I?
Don't
know
the
answer
today?
Yes,
but
that
might
be
a
factor
like.
Maybe
we
don't
need
a
Windows
profile,
just
that
you
know.
D
L
L
One
is
trying
to
be
very
pragmatic
towards
getting
Windows
support
to
GA
and
1.13,
and
obviously
we
want
to
be
able
to
have
conformant
clusters
like
the
most
sort
of
cheater
way
to
do
this,
but
actually,
just
me
to
say:
hey
it's
a
hybrid
cluster,
it's
conformant,
let's
add
Linux
specific
big
node
selectors
to
every
test
and
we'll
pass,
and
we
won't
even
test
the
windows
side
of
the
house
like
that.
That
feels
like
cheating,
right
and
so
the
hybrid
approach
that
we're
taking
is
to
actually
say
hey.
L
L
The
alternative
is
to
actually
bite
the
bullet
and
do
profiles.
My
belief
is
that
may
very
well
turn
into
a
giant
bike
shed
and
the
thoughts
will
miss
the
1,
1
3
deadline
and
so
in
some
ways
it's
to
say:
hey,
let's
have
a
like.
Let's
have
something
we
can
say
usefully
about
conformance
in
a
Windows
environment
for
1.13,
with
an
acknowledgement
that
we
believe
that
ultimately,
profiles
is
the
right
way
to
do
this
in,
or
maybe
it's
like
what
you're
saying
like
you
know
some
sort
of
form
of
node
selector.
L
L
Have
to
run
on
it's
really
hard
actually
having
done
this,
so
we
actually
implemented
this
or
at
your
container
instances
it's
really
hard,
because
if
it's
a
known
base
layer,
then
maybe
but
there's
nothing
in
the
docker
image.
Spec
that
says
anything
about
what
the
lair
is.
So
you
have
to
let
go
and
do
heuristics.
K
He
know
so
it
sounds
great,
like
in
general,
in
managing
multiple
SIG's
over
time.
This
is
the
typical
pattern
that
we
use.
We
basically
say
like
we'll:
do
X
for
period
of
time,
Y
and
you
know
we'll
we'll
eventually
go
to
fix
it
later
on
with
this
grand
vision
of
the
future,
and
what
happens
is
that
grand
vision
of
the
future
never
actually
comes
to
fruition.
So
it's
there's
there's
we
can
let
this
pass,
but
then
where's
weird
to
be
stopped.
K
L
D
So
so,
looking
through
the
list
of
tests-
and
you
know
not
being
super
familiar
with
Windows,
you
know
there
are
things
that
are
obviously
Linux
isms,
like
Linux
capabilities
or
SATCOM,
or
app
armor
and
su
Linux
and
those
kinds
of
things
I'm.
Seeing
some
tests
in
this
list
that
are
not
as
obvious,
do
you
have
a
doc
somewhere?
That
explains
like
whether
these
things
are
well
I've
just
not
implemented
yet,
or
these
don't
even
make
sense
for
Windows
and
here's.
Why
I.
J
D
L
J
D
Gonna
need
that
list
for
users
anyway,
like
if
you're
running
on
Windows.
You
should
expect
these
things
to
not
work
and
why
right
we're,
probably
gonna
need
some
kind
of
winters
or
validator.
So
it
really
helped
me
for
reviewing
whether
this
test
list
makes
sense
to
to
write
that
kind
of
justification,
and
then
we
can
get
it
turned
into
user
dogs,
yeah.
J
L
I
think
and
I
see
Tim's
hands,
so
I'm
gonna
respect
that,
but
there's
one
say:
I
think
these
are
the
reasons
why
it's
gonna.
If
we
go
down
this
road,
it's
gonna
take
longer
than
1.13
and
why
I
would
prefer
to
have
this
sort
of
parallel
approach
where
we
go
conform,
it
sort
of
best
effort
conformance
for
1.13
without
changing
the
conformance
suite
and
then
you
know,
do
the
do
the
due
diligence
on
all
of
the
tests
in
in
a
slower
path
and
and
with
profiles.
Okay,
I'm
somewhat.
D
Sympathetic
to
that,
because
it's
gonna
be
apps.
Conformant
is
any
windows
system
right,
so
it's
not
like
they're
gonna,
be
a
different,
a
bunch
of
different
differently,
compatible
windows,
implementations,
but
I
want
to
read
through
the
whole
list
of
tests.
First,
so
I
could
get
a
better
sense
of
what
the
damnit,
what
what's
not
gonna
work
I.
I
Just
want
to
echo
that,
because
every
one
of
those
just
one
example
is
a
great
example
because
it
was
added
for
real
users
for
real
reasons
and
I
certainly
don't
think
we're
in
a
position
to
say
well,
Windows
doesn't
implement
this
feature
so
therefore
it
can
never
ever
be
compliant,
but
I
think
we
need
to
be
crystal
crystal
clear
about
users
if
you're
using
Windows
this
subset
of
things
that
work
on
kubernetes
Linux
don't
work
either
yet
or
will
never
work.
Yeah
who's.
L
Although,
actually
along
those
lines,
I
just
found
out
that,
if
you're
injecting
credentials
for
Redis
for
the
Sentinel,
it
doesn't
work
on
Linux
either,
because
Redis
expects
to
be
able
to
read,
write
that
file
and
now
that
file
is
read-only
right.
So,
like
weird
happens,
all
over
the
place,
I
guess
is:
maybe
the
TLDR
out
of
the
edges
we're.
J
Well,
there's
one
on
one
call
around
single
file:
mapping
is
this
is
not
different
between
kubernetes
and
Dockers
form
and
the
developer
scenario
doesn't
work
on
Windows
across
the
board.
So
applying
the
principle
of
least
surprise
here,
Windows
user
would
never
expect
that
to
work
because
they
moved
to
kubernetes
from
another
Orchestrator.
Well,.