►
From YouTube: SIG Architecture Meeting 20190110
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
A
D
So
we
have
few
main
topics
on
the
agenda
today.
One
is
about
caps
and
how
we're
going
to
use
them
and
requirements
for
teachers
going
into
kubernetes,
which
we're
going
to
do
first
and
originally,
it
was
I
forget
how
many
minutes
were
specified,
but
I
figured.
It
was
going
to
be
a
longer
discussion
and
it
was
important
so
I
added
more
time
in
case
we
need
it,
and
the
other
is
the
scope
topic
which
which
Matt
brought
and
I
did
some
research
on
that.
So
I
will
have
a
good
discussion.
D
There
leave
a
few
minutes
for
discussion
of
the
agenda
for
the
next
meeting.
At
the
end,
there
were
two
topics
from
sig
storage
that
were
put
on
here.
Initially,
one
is
already
resolved
and
the
other
one
I
asked
them
to
email.
So
please
do
take
a
look
at
the
email
and
help
them
out
and
if
it
doesn't
get
resolved
by
email,
then
it
can
get
scheduled
for
a
teacher
meeting.
A
Okay,
let's
talk
about
caps.
I
want
to
throw
out
my
straw,
man
and
then
model
point
is
to
try
and
listen
as
much
as
possible.
So
the
straw
man
is
where
I
say
words
out
loud
and
people
not
their
heads,
but
we
all
acknowledge
that
the
devil
is
in
the
details.
Straw
man
is
everything
their
lands
in
114
must
have
a
cap.
If
it's
an
enhancement,
it's
got
to
have
a
cap,
so
I
forget
what
the
line
for
enhancements
is,
but
the
one
that
I
use
in
my
brain
is
like.
A
If
it's
something
you
want
to
brag
about
in
the
release
notes,
if
it's
something
you
would
write
a
blog
post
about
it's
a
cap,
other
people
I
think
have
talked
about
how
if
it
crosses
multiple
stakes,
it's
a
cap,
whatever.
What
I'm
looking
for
is
a
document
that
starts
to
more
form
like
more
formally
specify
everything
about
this
bit
of
code.
This
chunk
of
code,
whatever
that's
landing,
because
I
would
like
to
see
at
a
minimum
a
checklist
that
specifies
the
criteria
for
alpha
beta
and
statement
and
within
that
checklist.
A
I
would
like
to
see
a
test
plan
and
an
upgrade
downgrade
plan
if
that
kept
so
requires
it
I
feel
like
it
is
unfair
to
the
release
team
to
expect
the
release
team
to
have
sufficient
technical
knowledge
to
be
able
to
vet
all
of
these
things.
So,
though,
I
believe
that
it
is
the
responsibility
or
the
authority
of
sig
architecture
as
the
state,
with
the
most
cross-cutting
views
across
the
project,
to
ensure
that
we
have
some
level
of
consistency
in
vetting
these
criteria
home.
A
So
that's,
basically
it
like
I
think
saying.
Architecture
needs
to
be
a
stakeholder
of
some
form,
the
existing
rules
that
we
have
on
caps,
our
reviewers
or
approvers
or
authors,
maybe
even
editor,
so
I,
don't
know
if
I'm
asking
for
a
new
role
or,
if
I'm,
asking
for
sake
architecture
to
beat
one
of
the
existing
holes.
I
also
recognize
that
realistically,
within
the
release
cycle,
that
I've
proposed
enhancements
freeze
is
the
end
of
January
and
I
want
to
talk
about
the
realism
of
the
pool
of
people.
A
We
have
available
to
review
the
amount
of
things
we
have
to
review
if
I
know
purely
off
of
the
number
of
enhancement,
issues
that
are
currently
in
the
B
113
milestone,
and
the
people
in
14
milestone
understanding
that
some
of
these
may
represent
issues
that
should
actually
be
closed,
but
having
been
yet
and
that
there
are
some
issues
yet
to
come.
There
are
a
ballpark
37
different
things
to
be
reviewed.
A
It
seems
maybe
unrealistic
to
expect
a
fully
detailed
test
plan
and
upgrade
downgrade
plan
and
assessment
of
scope
by
the
end
of
January
economic,
so
I'm,
okay,
with
this
being
kind
of
an
iterative
process.
If
the
community
has
a
clear
understanding
that
we're
going
to
use
this
as
a
lens
to
kick
enhancements
out
as
we
figure
out
the
criteria,
but
I
do
really
think
it's
time
for
us
to
talk
about
the
process.
The
implementation
of
how
we
want
to
use
caps-
and
those
are
my
asks
so
Matt
and
Tim
Sinclair-
had
their
hands
up
yeah.
B
A
I
think
I'm
gonna
defer
to
the
expertise
of
this.
This
safe
but
I'll
just
say,
for
example,
one
one
little
headache
we
nearly
had
a
CSI
going
to
GA
was
that
as
it
was
originally
implemented.
If
you
took
a
note
from
the
older
version
of
CSI
to
the
newer
version
of
cs5,
like
the
new
drivers,
didn't
work
with
the
old
trackers
or
something
along
those
lines.
A
That's
something
that
something
that
talked
about
the
upgrade
path
really
should
have
taken
into
consideration
and
if
I'm
wearing
my
wearing
my
operator
hat
now,
like
I,
really
would
be
paranoid.
If
I
didn't
have
a
stated
downgrade
plan,
I
don't
know
if
I'm
really
looking
for
a
thorough
test,
but
I
need
at
least
some
proof
that
we've
put
some
thought
into
this,
because
I
think
that
a
good
experience
from
an
upgraded
Mountain
perspective
should
be
part
of
our
criteria
for
beta
versus
stable.
You
have
some
expectations
of
what's
allowed
to
happen.
C
I'm
totally
cool
with
the
idea
of
having
the
sections
to
add
there
so
long
as
we
have
the
clause,
especially
for
downgrade
to
say,
like
this,
is
not
backwards
compatible
and
that
being
an
okay
type
of
thing,
because
some
things
are
new
features
that
will
be
there.
Not.
If
you
try
to
go
backwards,
they
could
be
breaking.
D
E
E
A
D
Okay,
so
a
couple
of
things
one
is:
we
do
have
existing
criteria
which
we
could
change
or
refine
about
what
constitutes,
and
enhancement
and
I
think
using
the
same
criteria
for
caps
makes
sense
the
following
up
on
what
Tim
said.
I
think
you
know
anything.
We
want
to
be
criteria,
we
should
add
to
the
template.
I
think
that
would
be
good.
You
know
we
do
have
been
talking
about.
Raising
the
quality
bar
and
caps
are
definitely
one
of
the
tools
we
should
use
to
do
that.
D
So,
as
we
come
up
with
testing
criteria,
we
should
put
a
link
to
those
criteria
into
the
existing
template.
The
graduation
criteria
section
the
existing
section
in
the
template-
is
found
to
be
confusing
because
it
is
actually
just
talking
about.
How
do
we
evaluate
whether
the
feature
works?
The
way
users
expect
which
isn't
the
normal
meaning
we
have
for
graduation
criteria,
so
we
should
fix
that
I
think
there
in
terms
of
upgrade
and
downgrade
and
some
other
things.
D
There
is
some
additional
criteria
that
we're
going
to
be
considering
as
well,
and
we
should
figure
out
how
to
roll
those
in
this
year.
For
example,
we're
talking
about
ensuring
monitoring
right
there,
yeah
Jago
added
that
I
was
going
to
mention
that
as
well.
We
add
monitoring
for
features
that
you
know
need
to
be
able
that
operators
need
to
be
actually
able
to
operate
the
clusters
and
understand
what's
going
on.
So
we
have
someone
in
consistent
support
for
exporting
information
about
kubernetes
behavior
today,
to
put
it
mildly.
D
So,
coming
up
with
some
criteria,
there
is
going
to
be
necessary
as
far
as
the
process
I
do
think.
We
need
to
figure
that
out.
You
know.
Looking
back
asked
this
past
several
releases
they've
had
between
30
and
50
enhancements
filed
through
the
futures
repo
for
each
release.
That
is
pretty
significant.
D
I
wasn't
envisioning,
stick
architecture
explicitly
sign
off
on
every
single
Kemp,
but
there
probably
needs
to
be
an
evaluation
of
whether
sega
architecture
needs
to
provide
input
to
a
kept
or
not,
and
I
think
you
know
having
the
cigs
responsible
for
docs
or
release
or
testing
can
also
be
gatekeepers
and
even
instrumentation,
maybe
can
also
be
gatekeepers
of
their
relevant
parts
in
architecture.
Does
that
have
to
be
the
only
group
cigar
teachers?
Responsibilities
would
be
more
around
things
like
API
changes,
backward
compatibility
and
things
like
that.
D
F
And
Steven
yeah
and
wanted
to
have
the
point
about
monitoring
and
I
think
just
having
a
line.
Making
a
template
is
enough
to
drive
the
conversation
and
shift
the
burden
to
the
developer
of
the
cap,
which
is
a
useful
mechanism
in
lots
of
ways,
active
omission.
It
is
itself
data,
but
then
also
wanted
to
come.
Did
we
bottomed
out
on
caps
replace
features,
and
if
so,
my
suggestion
is
that
we
more
broadly
communicate
that
I
know
that
question
has
come
around
several
times.
I
think
we're
there.
So
it
seemed
us.
A
Let's
posit
that
I
am
strongly
suggesting
that
we
do
that.
I
know
that
caleb
has
been
heavily
involved
in
the
creation
of
a
command-line
tool
for
caps,
and
it
sounds
like
it's
going
to
be
a
bumpy
experience
and
he
has
personally
expressed
to
me
that
he's
not
sure
we
are
ready
for
this,
but
I
really
need
some
validation
of
a
few
things
at
a
minimum
and
I'm
willing
to
endure
a
bumpy
process
to
get
us
there.
But
I
would
like
to
get
consensus
from
this
group.
Yeah.
A
So
I'm
hearing
a
couple
of
things
to
Europe
your
concerns
specifically
area
I
share
them
in
terms
of
trying
to
understand
the
quality
and
what
to
do
when
things
go
wrong,
inevitably
with
enhancements
that
are
coming
for
the
release
that
you
are,
the
lead
of
for
1:14
I
think
that
the
prior
art
of
Dan
and
I
requiring
more
or
less
what
we
internally
at
Google.
Have
you
know
a
launch
launch
checklist.
A
If
we
did,
you
I
think
that
that
has
been
fine
for
the
duration
of
a
single
release
in
terms
of
using
caps
as
that
mechanism,
I,
certainly
I
do
not
believe
that
either
our
ability
to
review
them
currently
because
of
the
you
know,
looseness
of
the
format
of
caps,
because
there's
no
tooling
that
enforces
what
you
must
happen
is
just
not
going
to
be
possible.
Certainly,
I
have
no
additional
bandwidth,
as
you
know,
when
I'm,
not
in
meetings
I'm
writing
code,
that's
not
just
for
the
the
CLI,
but
also
what
is
the
the
cap
itself.
A
So
you
can
actually
you
know,
lint
and
block
murders
of
caps
which
do
not
conform
to
the
standards
we
have
greed
on
here,
and
so
that's
just
not
going
to
be
ready
in
a
time
in
time
from
1:14
I.
You
know,
I
wish
I
could
say
something
different,
but
that's
my
best
estimate
as
to
when
that
will
be
ready.
It's
just
not
for
1:14.
A
That
being
said,
you
know
if
you
want
to
try.
I
can't,
obviously
stop
you
from
making
that
requirement.
I,
just
I
I
have
no
confidence
that
that's
going
to
go
well
enough
to
provide
you,
the
confidence,
you're,
looking
I
just
don't
think
kept
scar,
though
the
mechanism
you
want
for
you
weren't
particular
revenues
for
115
I,
would
really
hope.
So.
G
Okay,
so
I
just
had
a
small
question:
well,
not
really
questioned,
but
a
point
here
like
we
call
that
monitoring
I
think
rather
than
saying
monitoring.
I
think
it
would
be
reasonable
to
ask
people
to
fill
out
a
section
to
say
you
know
what
does
your
day
to
operations
look
like,
but
I
think
that
that's
something
that
not
every
camp
is
going
to
need
and
I.
Think
it's
something
that's
gonna
gonna
go
just
gonna
be
a
little
bit
different
to
deployment
to
deployment
so
I
mean
I.
G
Think
it'd
be
good
to
have
that
as
like
a
list
of
recommended
recommended
sections,
but
like
look
later
on
the
agenda,
there's
a
question
around.
You
know
what
is
the
scope
of
kubernetes
and
on
one
hand,
monitoring
is
largely
a
decision
around
picking
what
you're
going
to
use
that's
outside
of
the
kubernetes
project
today
and
so
I.
Don't
think
we
can
make
it
something.
That's
necessarily
required,
but
I
think
it's
reasonable
from
people
to
give
some
suggestions
on
on
what
could
be
possible
there
so
that
that's
all
I
had
on
that.
D
A
Okay,
so
there
is
a
question
asked
about
like
who
the
approvers
as
keps
should
be.
So
we
have
this
delineation
between
caps
that
are
sig
focused
and
kept
siddharth
kubernetes
wide
I
think
for
caps
that
are
kubernetes
wide.
They
should
have
sig
architecture
oversight.
I
think
that
it's
not
exactly
feasible
to
expect
sake,
architecture
to
be
able
to
review
every
cap
and
save
the
leaves
and
chairs
should
take
that
on.
Take
that
on
themselves
to
review
caps
that
are
specifically
only
six
focused
cross
across
big
efforts
should
be,
should
have
some
idea.
A
Another
question
right
so
yeah,
so
I
brought
this
up
in
the
sega
architecture.
Vo
f4q
come,
but
we
there
were
mentions
of
the
graduation
criteria
within
caps.
I
think
one
of
the
problems
that
we
have
is
that
we
don't
have
a
global
idea
or
a
global
standard
for
graduation
criteria,
and
we
never
really
got
to
discuss
that
in
in
that
VLF.
So
I
think
until
we
have
that
we're
gonna
keep
bumping
into
the
problem
of
what
does
it
kept?
Look
like
what
does
an
advancement
look
like
when
it's
graduated.
D
A
So,
just
a
note
that
I
little
bit
disagree
with
the
fact
that
monitoring
needs
to
be
included.
I
think
that
that
would
be
kept
kept
dependent
only
depending
on
what
kept
it
is,
will
determine
whether
or
not
we
need
to
talk
about
monitoring
like
the
caps
for
sake
p.m.
or
caps
for
architecture
that
come
out
may
not
need
that
so
TBD
right,
Aaron
and
then
Jacob
okay.
So
yes,
the
requirements
thing
is
where
I
peel
the
whole
responsibility
of
state
architect
applies.
A
I
just
feel
like
this
is
the
group
that
that's
makes
sense
to
own,
defining
the
standard
of
criteria
for
alpha-beta
unstable
I'm,
not
saying
they
should
be
the
sole
evaluators
of
criteria.
So
when
I
talk
about
upgrade
downgrade
I
would
expect
cluster
life-cycle
to
probably
be
best
qualified
to
you
to
do
that.
Fat
and
I
would
expect
Doc's
to
be
best
qualified
to
put
in
some
items
about
whether
or
not
Doc's
have
been
done,
but
I
I.
Just
like
again,
it
comes
back
to
you.
A
The
release
team
doesn't
really
have
time
to
do
a
thorough,
deep
dive.
We
need
to
be
able
to
delegate
out
those
deep
dive
stuff
so
that
all
we're
really
doing
is
verifying
whether
or
not
the
check
boxes
have
been
checked.
So
I
do
think
it's
important
that
sega
architecture
is
involved
with
most
every
cap
to
ensure
that
the
not
to
jump
ahead
like
the
scope
of
kubernetes
is
preserved
and
that
there
is
at
least
some
amount
of
oversight
on
even
single
stay
eccentric
caps.
A
A
Jump
yes,
sorry
go
for,
do
that!
Well,
not
suggesting
a
tracking
spreadsheet
specifically,
and
you
may
want
to
follow
up
with
Daniel
and
API
machinery
team,
but
but
literally
we
gave
them.
A
questionnaire
of
you
must
tell
us
these
five
things
or
your
feature
will
not
ship
in
the
release.
One
of
them
was:
how
do
we
roll
this
back?
Another
one
was:
what
is
the
scope
another
one
was
at?
Had
it
had
me
how
this
works,
I
mean
I.
A
Could
try
and
dig
this
up
but
I
think
we
put
the
onus
on
the
enhance
the
people
who
are
trying
to
deliver
enhancement.
This
was
you
know
years
before,
keps
years
before
we
had
even
a
second
iteration.
On
the
you
know
the
features
tracking
repository.
So
there
is
prior
art
that
will
allow
you
I,
believed
and
get
the
questions
you
want,
and
you
need
answered
as
the
release
team
answered
and
that
can
be
an
issue.
That's
separated
out
from
everything
else
here.
So
I
agree.
Those
aren't
the
questions.
I
want
answered.
A
It's
going
to
make
me
very
sad
if
it
means
that
a
bunch
of
humans
are
individually
scheduling,
someone
on
what
one
of
the
one
meetings
and
sending
documents
around
I.
Just
it
made
sense
to
me
that
that's
the
sort
of
information
that
sounds
appropriate
for
a
cap
and
so
I
was
trying
to
kind
of
move
us
towards
one
central
source
of
truth
for
this
stuff.
E
Don't
see
any
other
answers,
but
I
have
a
point.
I
soaked
apps
are
becoming
critical
paths
for
the
success
of
this
project,
because
it's
the
aggregate
place
where
we
talk
about.
So
it's
basically
a
mini
views
of
one
piece
of
data
thing
that
we're
trying
to
preserve
here
and
as
many
things
are
in
architecture,
there
seems
like
we
have
a
lack
of
commitment
in
terms
of
people
working
on
this
caleb
has
invested
a
lot
of
engineering
hours
and
a
tool.
That's
or
lingo.
E
That's
extremely
well
documented
and
has
a
basically
a
CLI
that
can
be
applied
to
it
right
now.
How
do
we?
How
do
we
mobilize
people
around
one,
the
social
effort
of
getting
people
to
buy
into
the
gifts
as
a
whole,
because
that's
not
their?
How
do
we
get
the
automation
and
the
implementation
of
Caleb's
tooling?
So
it's
not
just
Caleb
working
on
this
solo
and
then
three?
How
do
we
actually
see
this
through
to
completion
in
a
reasonable
time?
Because,
right
now
we
have
no
commitments
on
any
of
that.
E
F
F
And
the
tool
makes
it
possible.
Someone
I
didn't
come
up
with
this,
but
someone
mentioned
like
a
kept
winter
is
possible
if
it
is
structured,
data
and
I
think
maybe
we
have
a
few
categories
of
caps
and
a
few
categories
of
Flint's,
but
when
driving
culture
changed,
you
implement
things
like
consistent.
C
F
That
it's
working
in
production
is
something
that's
useful
to
be
consistent
across
all
of
these
components
and
so
putting
it
into
account
like
consistency
of
down
Bay,
behavior
and
ability
to
do
so
is
useful
to
be
consistent
across
multiple
states,
and
so
that's
why
I
think
this
group
comes
into
play
and
the
making
it
a
gating
factor
inspires
those
who
work
with
it
to
get
frustrated
and
fix
things
that
don't
work
and
add
features
to
make
it
less
rooms.
Yeah.
D
So
if
we
just
socialize
it
amongst
the
gatekeepers
and
people
who
see
things
fly
by
like
Sigma
nice
and
the
release
team
suggesting
contributor
experience,
this
group
I
think
that
will
take
us
a
long
way
in
terms
of
making
sure
that
we
get
people
into
the
funnel.
And
you
know
we
can
also
communicate
to
the
other
farms,
community
meeting,
Bernie's
dead,
mailing
list,
etc.
I'm.
E
E
D
E
Means
there's
another
group
of
people.
You
should
socialize
this
way
for
sure
and
then
the
coding
aspects
of
killings
tool,
if
that's
going
to
become
the
de
facto
standard.
How
we
manage
these
things.
That's
an
engineering
for
me
to
have
engineering
rigor
around
that
and
kept
them
yeah.
It
works.
I
demoed
the
tool
in
Cuba.
It's
a
fantastic
tool,
even
in
its
early
stages,
so
I
would
love
to
see
somebody
volunteer
to
to
help
Kayla.
This
work
component.
B
A
I
feel
like
another
thing,
this
group
has
often
talked
about
his
needing
to
review
the
existing
backlog
of
capsules,
and
so
it
felt
to
me,
like
this
overlapped
with
that
goal,
by
prioritizing
everything
that
was
going
to
lay
it
in
114.
I
agree
with
Jago
when
I
I
think
when
I'm
using
the
terminology
of
land
I
am
talking
about
explicitly
showing
up
in
one
of
the
three
phases.
You
can
also
argue
that
if
we
want
to
draw
a
hard
line
that
when
we
talk
about,
we
really
need
to
stabilize
everything
that
we
say
we.
A
We
are
not
accepting
anything.
That's
attempting
to
land
as
alpha
that
we're
only
accepting
things
that
are
attempting
to
promote
to
beta
or
promote
to
stable,
just
just
some
thoughts,
but
I
still
like
I,
unfortunately
didn't
come
prepared
at
the
concrete
task
of
like
okay.
Here's
the
list
and
I
need
names
assigned
to
all
these
things.
But
I
want
us
to
get
to
that
point.
A
B
B
Within
within
the
enhancement
rate
that
take
a
look
at
it,
wasn't
there
before
in
the
old
community
repo,
was
it
or
was
I
missing
it?
No,
that
was
only
the
features
repo.
So
now
that
it's
seen
it
still
has.
Okay,
that's
good,
then
I
I'll,
pry
oriT
eyes
based
on
the
114
ones,
because
I
had
been
going
in
and
reviewing
them
myself.
That's
actually
how
I
got
suckered
into
missing
architecture
things
so.
A
C
A
A
We're
gonna
recruit
tomorrow,
based
on
the
outcomes
of
this
conversation
and
any
follow-ups
that
we
have
it's
again.
This
is
about
sort
of
scoping
and
trying
to
figure
out
what's
feasible,
but
do
you
want
to
be
realistic,
but
I
just
feel
like
I've
seen,
I
saw
so
much
figure
as
head
nodding
that
we
really
do
need
to
actually
do
something,
or
it's
just
continued
words.
Yeah
Jordan.
H
A
I,
just
but
until
there
is
like
automation
for
this
that
that
alone
would
take
probably
someone
one
whole
day,
that's
kind
of
what
I'm
saying
it's
like.
If
we
are
trying
to
use
the
kept
process
as
a
tool
to
like
improve
the
quality,
we
actually
have
to
be
ready
to
roll
it
out
before
that
guy
says:
I.
Guess
it's
software,
like
everything
else
like
it
just
be.
A
rollout
plan
need
like
training,
materials
that
all
this
is
not
going
to
work.
H
It
yeah
I
agree,
but
if,
if
the
alternative
is
let
the
things
that
are
currently
in
process
continue
without
considering
these
things
or
asking
those
questions,
I
would
I
would
take
a
copy
and
paste
the
three
new
things.
We
decided
questions
that
need
to
be
out
of
the
template,
copy
and
paste
that
and
like
put
put
them
into
every
existing
cap
and
ping.
The
owner,
like
I,
would
take
that
over
wait.
A
D
So
we're
about
out
of
time
for
this
topic
I
do
want
to
leave
adequate
time
for
the
scope
topic.
I
was
planning
to
take
a
stab
at
the
maturity
criteria.
I
will
try
to
do
that
in
the
near
future.
I
ended
up
getting
sidetracked
by
the
scope
topic
first.
So,
let's
move
on
to
that.
So
in
terms
of
follow-up
action
items,
do
we
have
a
volunteer
from
someone
to
update
the
template
or
do
we
want
to
come
up
with
the
criteria
first
and
then
update
the
template
so.
A
E
E
E
E
B
Not
not
what
did
we
do
before,
but
in
the
last
year,
just
to
give
everyone
on
the
same
page
with
background,
we
started
to
say
no
to
a
lot
of
features
and
to
safe
those
are
in
the
ecosystem,
and
then
we
worked
on
extensibility
plug
ability
and
things
like
that,
like
not,
every
new
cloud
provider
comes
in
we're
actually
moving
the
existing
ones
out,
but
we're
giving
a
mechanism
for
many
cloud
providers
to
be
in
the
loop.
There
were
lots
of
features
that
we
said.
B
No
we're
not
going
to
here
it's
better
to
do
that
with
CRD,
CRS
and
operators
of
your
own.
Then
it
adds
something
new
we've
been
focusing
a
lot
on
that
and
on
our
own
in-house
quality.
So
the
question
now
becomes-
and
we
haven't
documented
this,
but
we've
talked
about
it.
Where
does
kubernetes
end
and
I?
Think
that's
important
because
the
ecosystem
needs
to
know
where
do
they
begin?
Where
does
that
interface
happen
and
there
will
be
some
overlap,
but
where
is
that
that
space
and
what's
going
on
here?
B
Does
that
make
sense
that
that's
kind
of
the
question
that's
out
there
and
we
haven't
documented
it
I've
come
to
realize
that
not
everybody's
on
the
same
page
with
this
either
whether
it's
communicated
out
to
many
of
the
people
working
on
things
or
even
not
always
in
agreement
on
what
they
should
be
Tim.
You
said
it's
documented
somewhere
where.
C
D
D
The
system
specifically
and
then
there
were
some
recent
discussions
that
had
some
additional
I
think
good
good
points
that
were
raised.
For
example,
the
helm,
propulsion
CFL
Purple's
a
little
bit
Matt
dissipated
on
surfaced,
some
good
issues,
so
I
actually
went
last
night
and
and
yesterday
afternoon
and
collected
a
bunch
of
them,
so
I'm
gonna.
D
D
D
So
there
will
be
some
nuance
there,
but
I
did
actually
go
through
a
list
and
try
to
update
the
list
from
the
architectural
roadmap
document
in
terms
of
the
functionality
that
we
believe
is
in
scope,
and
you
know
I
think
we'll
need
some
high-level
guidance
as
well
as
some
lower-level
details
about
you
know
what
is
containerized
workload.
Execution
management
mean
what
is
service,
discovery,
load,
balancing
and
routing
entail.
D
You
know
what
is
included
in
the
declarative
resource
management
platform.
I
did
find
that
there
are
at
least
there
are
more
than
a
dozen
other
considerations,
rather
than
purely
technical
scope,
which
have
influenced
decisions
in
the
past
and
I
think
our
makes
sense
to
employ
decisions
in
the
future
as
well.
So
it's
not
going
to
be
like
a
completely
cut
and
dry
rubric,
I
believe
so.
B
So
there
were
two
angles
that
I
wanted
to
also
say
need
to
be
involved
in
this.
When
we
talk
about
kubernetes,
there's
kind
of
kubernetes
at
two
levels,
there's
kubernetes
kubernetes
the
thing
that
we
ship
on
that
release
cycle.
But
then
the
kubernetes
project
has
a
number
of
other
things:
whether
it's
mini
cube,
coop
control,
which
has
the
goal
of
actually
breaking
out
having
its
own
release
schedule.
B
There
are
other
things
within
the
umbrella,
and
so
when
we
look
at
this,
we
probably
need
to
address
both
of
them
right
both
what
is
in
the
kubernetes
org,
unless
something
within
that
orgasm
to
be
ecosystem,
but
grandfathered
in
and
I'll
use
composed
with
the
K
as
an
example
of
that,
and
then
there
are
things
you
know
that
are
more
core
like
what
falls
under
the
project
versus
what
is
kubernetes.
There's
a
difference
there
right,
and
we
probably
need
to
acknowledge
that
and
look
at
those
things
to
say.
B
You
know
what
this
is
in
the
kubernetes
project,
but
it
is
the
ecosystem,
like
everything
else
versus
things
that
we
say
are
well.
This
is
part
of
the
core
of
kubernetes,
because
we
we
have
a
little
bit
of
both
cases
and
do
we
say
while
things
like
compose
with
the
Kay
are
grandfathered
in
and
we
don't
want
new
things
like
that
in
the
project
or
are
new
things
like
that?
B
Okay
and
that's
kind
of
important
for
SIG's
when
seg
say
okay,
we
want
to
go
work
on
something
and
it's
not
part
of
core,
but
we'll
do
it
in
kubernetes
sig
and
it's
a
new
CLI.
Should
that
actually
be
said?
No
that
needs
to
be
out
in
the
ecosystem
or
is
that?
Okay
and
then,
how
do
we
position
in
that
scope?
Wise
to
say?
Is
it
official,
isn't
non
official
and
I
say
that,
because
somebody
actually
came
to
me
middle
of
last
year
and
said
hey,
can
we
get
this
thing
into
kubernetes
somewhere?
F
I
want
to
add
I
think
this
is
getting
more
challenging
over
time,
one
that
is
core
DNA
default
DNS
for
repo
and
project,
so
I
think
it's
not
limited
to
those
things
that
are
core
and
those
things
that
happen
being
Maori.
They're
grandfathered
in
as
the
kubernetes
project
gets
broken
into
more
and
smaller
components,
we're
going
to
a
more
complex
world.
C
Even
so,
I
think
we're
rehashing
history.
I
mean
we've.
Had
these
conversations
in
steering
and
in
arch
I
know
that
Brian
myself,
Tim
Hawkins
Joe
betta
I,
have
all
had
these
conversations
a
number
of
times.
I
think
what
we've
lacked
to
do
is
to
enforce
some
of
the
things
that
we
want
to
do
over
time.
The
carrot
and
stick
philosophy
has
not
applied,
especially
the
stick
like
what
does
it
mean
to
restructure
these
projects
so
that
they're
actually
lived
in
something
that's
understandable
to
the
external
people
that
has
not
occurred?
C
So
we
have
this
legacy
or
history,
but
we
have
conversed
about
it.
We
have
documents,
but
it's
not
as
cohesive.
So
there's
there's
a
running
history
of
knowledge
that
exists.
That's
partially
written
down
and
I
do
think.
It's
probably
worth
someone's
effort
to
you
know
formalize
it
a
little
better,
but
we've
had
a
problem
with
enforcement
from
a
steering
perspective.
We've
never
wanted
to
push
these
things
into
specific
locations.
E
A
Yeah
I
guess
to
touch
on
one
point
you
made
Matt
I
I
do
think
that
it's
I
also
share
the
concern
about
people
trying
to
get
things
into
communities
just
to
talk
about
it.
I
have
been
happy
to
see
what's
been
going
on
with
cloud
providers,
I
think
digital
ocean
coming
in
I
guess
really
Andrew
coming
as
a
representative
for
digital
ocean
and
taking
on
a
bunch
of
like
project
work
in
order
to
build
the
kind
of
trust
to
get
code
in
is
really
helpful.
B
Know
that
okay,
a
couple
things
first
when
it
comes
to
you-
have
to
have
done
sustaining
work
that
actually
kind
of
prioritizes
people
who've
been
around
and
letting
them
get
their
pet
features
in
rather
than
saying
a
scope
line
right,
even
if
I've
been
around
for
a
long
time.
If
something
should
be
squarely
in
the
ecosystem,
it
shouldn't
be
based
on
people.
B
It
should
be
based
on
the
scope
of
things
and
then
you
can
say:
okay,
you
know,
I
may
have
contributed
a
bunch
of
things
to
kubernetes
in
here,
but
this
particular
thing
I
want
to
do,
should
be
in
the
ecosystem,
so
I
need
to
go,
find
the
right
place
to
do
it.
There
I
would
like
something.
That's
maybe
a
page,
long
document
that
says
this
is
generally
what's
in.
B
This
is
what
should
go
in
the
ecosystem,
so
we've
got
kind
of
clear,
concise
guidance
and
then,
when
people
are
reviewing
caps
right,
they
can
use
that
to
say
based
on
this
document
over
here,
and
you
can
go
read
it.
This
is
what's
in
this
is
what's
out
so
that
thing
should
probably
go
live
in
the
ecosystem,
and
then
we
can
encourage
them
in
the
right
place
to
do
it.
There
I
have
another
thing,
but
it
looks
like
Aaron
wants
to
respond
to
what
I
had
to
say.
Well,.
A
Yeah,
what's
one
thing,
I,
don't
know
if
I
agree
in
general
that
it
biases
towards
people
who
are
near
the
project,
I
think
it's
Andrew,
who
was
huge,
showed
up
suggest
that
we
can.
As
you
know
us
here
in
this
room
and
the
state
can
help
guide
new
people
to
making
those
sustaining
contributions.
We
can
be
the
change
we
want
to
see.
A
Yeah,
like
I,
agree
with
Tim
I,
think
we're
really
cashing
his
tree
here.
I'm,
not
really
a
big
fan
of
pontificating
and
thinking
about
the
abstract,
what-ifs
I'm,
a
much
bigger
fan
of
us
operating
in
an
iterative
manner
as
a
project,
so
I'm
actually
like
big-picture
I'm
curious.
Why
this
is
so
important
like
if
there
are
any
massive
choices
that
can't
be
undone
helm
as
an
example,
came
into
the
project
and
then
also
left
the
project
right.
So
hang
out,
there's
that
number
two.
C
A
Extensibility
as
priority
number
one
above
reliability
and
quality
is
four.
Then
I
again
think
that
state
architecture
should
be
the
group
of
people
who
evaluate
every
potential
change
to
the
project.
With
this
rubric
in
mind,
right
like
for
a
given
cap,
is
it
actually
doing
something
that
has
that's
putting
extensibility
first
or
does
it
need
to
be
redone
so
as
to
align
with
this
priority,
because,
again,
Tim's
point
I,
think
we've
said
it
I'm,
not
sure
we
enforce
them.
Okay,.
I
Good
Matt
yeah,
it's
cuz,
I,
agree
with
era
and
I
I
prefer
getting
much
more
concrete
like
this
was
triggered
by
customize.
There
was
extensive
discussion
in
the
sink,
but
it
didn't
I
think
this
is
the.
There
was
a
feeling
that
this
didn't
get
a
meta
discussion
outside
of
the
sig
and
now
we're
coming
back
afterwards
and
race
in
the
larger
meta.
I
I'd,
be
happier
about
being
more
concrete
in
this
case
and
trying
to
narrow
down
to
whether
customized
is
out
and
then
use
this
as
an
opportunity
to
go
clarify
some
of
our
in
out
criteria,
which
feels
much
more
like
a
smaller
group
or
a
smaller
set
of
discussion.
Rather
than
like
the
larger
meta
discussion.
I
I
gotta
be
honest,
like
I,
don't
feel
like
we've
done
a
terrible
job
of
scope.
There
have
always
been
small
edge
cases
it's
getting
harder
now,
but
it
certainly
doesn't
seem
like
we're
broken
yeah.
B
So
what
I'm
asking
actually
for
is
the
documented
subsets
so
that
way
we're
all
on
the
same
page,
when
we
don't
document
it,
it
gives
it
open
to
some
wiggle
room
in
that
we
don't
have
a
place
to
point
people
to
either
I
mean
more
than
once.
I've
had
to
go
say
well,
we
discussed
it
over
here
and
you
want
to
go
to
the
meeting
minutes.
Your
honor
I
mean
actually
documenting
our
general
policy
and
scope.
B
I'm
happy
to
take
a
first
pass
at
that
and
get
others
to
review
it,
but
actually
just
to
have
it
in
writing.
So
we
can
share
it
with
people
and
tell
people
it
shouldn't
be
a
bad
idea
if
we
want
these
things
in
writing,
but
then
to
narrow
it
down
to
two
customize
which
what
spurred
this
on
it
was.
Actually
somebody
I
mean
I'm
the
one
who
fired
off
the
first
email,
but
it
was.
B
Because
the
okay,
no
errant
your,
but
why
is
kubernetes
gonna,
compete
with
the
ecosystem,
because
one
of
the
things
that
people
feel-
and
this
is
this
a
little
bit
feeling
is
if
it's
in
core
it
is
the
way
and
people
will
say,
but
that's
in
core
it's
the
way
and
therefore
don't
do
it
another
way,
and
so
once
we
get
outside
of
the
kubernetes
api
into
workflows
outside
of
it,
you
know,
so
we
create
something
we
declared
the
API.
B
What
do
we
want
and
then
the
API
you
know
kubernetes
goes
and
makes
it
so,
but
those
workflows
outside
of
it
right
people
have
a
lot
of
opinions
on
how
those
should
be
and
say,
gaps.
We've
had
I
want
to
say
it's
over
a
hundred
demos
of
tools
that
talk
to
the
api's,
and
many
of
them
have
come
up
with
different
workflows.
B
For
their
businesses,
where
apps
interact
with
the
API
to
do
management
things,
there's
a
lot
of
things
out
there
doing
a
lot
of
stuff
and
if
kubernetes
is
going
to
go
start
having
opinions
out
there
as
a
project,
people
are
gonna.
What
was
the
way
is
described
to
me,
the
common
denominator,
the
lowest
common
denominator,
starts
to
move
and
that
impacts
these
ecosystem
projects.
These
other
projects,
these
other
folks,
workflow,
and
so
should
that
kind
of
work
then
live
as
an
ecosystem
thing
alongside
the
other
ecosystem
projects.
B
F
Want
to
call
quick
attention
to
the
arbitrary
line
of
time
and
just
order
of
execution
I
think
that
many
of
these
same
arguments
could
have
applied
to
deployment
or
daemon
set
or
any
of
the
core
where
quotes
controllers
and
slowly,
because
the
people
who
arrived
in
the
time
that
they
arrived
it
went
into
core
and
it
is
the
way
it's
done
and
those
aren't
standard
across
kubernetes
installations.
I
think
there's
value
to
that
consistency
across
installation,
so
simply
because
the
kubernetes
community
didn't
get
to
something
in
that
order.
F
I,
don't
think
that
there
should
be
a
blanket
statement
whatever
exists
today
is
all
that
will
ever
exist
and
we
will
work
aggressively
to
move
things
out
or
I
think
there's
also
movement
in
both
directions.
There's
providers
are
moving
out
of
the
core
for
good
reasons.
There
may
be
good
reasons
for
selecting
two
corners,
so
I
just
want
to
call
out
that
we
are
at
a
point
in
time.
That
is
somewhat
arbitrary.
To
have
this
conversation
just
because
it's
coming
up
sorry
I
felt
yeah
sure.
E
E
B
Yeah
so
I
mean
so
when
it
comes
to
first
I
want
to
address
the
workloads
API
right,
because
I
think
that
actually
gets
into
how
things
have
changed
over
time
with
kubernetes
the
scope
that
we
had
and
the
way
we
reacted
to
things
a
year
and
a
half
or
two
years
ago
is
different
than
today
and
I
know,
because
there
was
talk
of
adding
another
object
to
the
workloads
API
around
application,
and
that
was
deemed
that.
Okay,
we
actually
need
to
do
that
separate.
B
Maybe
it
gets
in
and
the
reason
it's
even
a
sig
thing
is
because
it's
we're
only
touching
the
scope
that
has
to
do
with
interoperability
between
other
projects
and
so
rather
than
it
being
in
a
new
thing.
Work
load
controllers
coming
in,
we
actually
say
now
those
go
into
the
ecosystem,
because
our
scope
is
changed
right
that
that's
kind
of
how
we
do.
We
don't
say
we
always
done
it.
This
way,
we
actually
say
at
one
point:
well,
we're
gonna,
stop
doing
the
new
features
in
and
we're
gonna
be
more
about
interoperability
and
we're
gonna.
B
Ask
those
new
kinds
of
things
to
go
into
the
ecosystem
and
then,
if
something
really
hits
home
90
some
percent
of
people,
you
know
lots
of
people
are
using
it
then
we'll
look
at
whether
it
should
be
in
the
core
of
kubernetes
and
evaluate
it,
but
really
we
want
it
in
the
ecosystem.
This
was
kind
of
the
guidance
that
we
had
a
while
ago,
and
so,
when
I
look
at
it
this
way
and
then
I
look
at
the
ecosystem
and
I
say
well.
How
do
we?
B
Where
do
we
define
this
line
like
if
it
were
me
to
define
the
line?
I
would
say:
okay,
new
workloads
controllers
things
like
that
go
in
the
ecosystem,
unless
there
is
something
that
needs
to
happen
for
interoperability
and
the
same
thing
if
you're
going
to
interact
with
the
kubernetes
api
new
things
that
are
gonna
interact
with
the
kubernetes
api
or
new
things
that
deal
with
your
workflows
outside
of
the
kubernetes
api,
those
are
ecosystem,
but
the
existing
things
we
leave
where
they
are.
B
That's
where
I
would
probably
draw
that
line,
because
that
makes
a
clear
point
to
the
ecosystem.
That
says,
you
want
to
add
new,
tooling
and
how
I
work
with
things
outside
of
the
API.
That's
just
ecosystem
right,
new
things
that
do
that
is
all
ecosystem
new
controllers
in
kubernetes,
unless
there
is
a
darn,
good
reason
and
exception,
those
are
all
ecosystem
and
then
in
your
cap,
for
all
this
you've
got
to
justify
that
exception
and
the
reason
it
has
to
be
there.
B
Just
delay
around
what
what
J
goes
that
I
agree
completely
I,
don't
think
that
the
fact
that
we
have
built-in
deployments
has
ever
inhibited
anybody
from
building
their
own
workload
controllers.
If
it
makes
sense,
that's
fine,
I,
don't
think
we
have
an
obligation
as
a
project
to
be
completely
neutral
territory.
I
think
we
in
fact
have
the
opposite
obligation
to
find
and
choose
the
best
breed
of
solutions
for
customers
who
are
using
coronet
ease
and
to
not
do
that.
B
I
think
would
be
a
failing
of
leadership
project
I'm,
not
saying
anything
about
customize,
because
I,
don't
piƱon
on
it,
but
I'm,
saying
as
a
as
project
leaders.
We
are
obligated
to
look
around
the
ecosystem
and
look
at
the
things
that
are
the
best
ideas
that
are
working
best
for
people
and
bring
those
things
in
and
give
them
best
support.
B
Lastly,
Cabrini's
is
really
at
least
two
projects
at
this
point.
There's
all
the
AI
machinery
and
the
tools
that
use
to
host
and
run
API
is
until
used
access,
API
and
there's
the
kubernetes
sort
of
application
that
builds
on
top
of
all
of
that
and
I
think.
The
same
argument
holds
for
both
I
think
this
sort
of
emergent
distinction.
H
Jordan
last
word:
I
just
wanted
to
kind
of
call
out
the
different
dimensions
of
changes
that
are
made.
So
on
one
hand,
you
have
things
that
are
pretty
clear,
like
cloud
providers
where
the
entire
purpose
of
these
is
to
adapt
kubernetes
to
a
particular
vendor
or
a
particular
environment,
and
so
making
those
be
extension
points
and
be
done
out
of
court
makes
a
lot
of
sense.
H
On
the
other
hand,
you
have
like
matt
was
describing
ways
that
you
interact
with
the
api
things
that
there
are
very
basic
to
do
things
that
are
generic
and
aren't
focused
a
particular
vendor.
A
particular
integration
like
applying
labels
consistently
across
a
bunch
of
objects
or
taking
an
api
object
and
applying
an
api
patch
to
it
like
these
are
not
targeted
at
a
specific
vendor
or
specific
environment
there.
They
are
API
driven
interactions
and
to
look
at
some
of
those
things
that
need
to
be
done
and
say
well.
H
The
experience
around
these
is
bad
with
the
tools
that
communities
provides,
but
then
to
say
well,
but
we're
not
going
to
actually
improve
that
we're
going
to
let
the
ecosystem
improve.
I.
Think
that
misaligns
incentives
that
aligns
the
ecosystem
to
solving
pain,
points
and
communities
rather
than
as
add-ons
and
extensions,
rather
than
working
to
improve
those
aspects
of
the
tooling
that
is
part
of
the
communities
project,
so
I
think
characterizing
attempts
to
address
usability
issues
with
the
existing
communities
toolchain
as
competing
with
the
ecosystem.
I,
don't
bet
that
doesn't
make
sense
to
me.
B
One
of
the
problems
we
have
with
this,
though,
is
we
don't
have
anybody
with
usability
and
user
experience,
work
doing
these
evaluations,
there's
a
lot
of
our
opinions
who
come
here
right
and,
quite
frankly,
my
opinion
versus
yours
is
to
people
out
of
tens
of
thousands
of
people
who
use
it
and
looking
at
it.
Sorry
I
know
last
word,
but
even
when
we
think
about
our
workflows,
one
of
the
things
that
I
realized
was,
we
think
about
our
work
flows
through
CI
CD,
to
do
things
and
then
editing
objects
outside
of
it.
B
We
need
to
start
thinking
outside
of
the
DevOps
world
that
some
of
us
live
in
into
other
ways,
and
all
of
this
this
happens
and
when
we
think
about
the
workflows
that
we
do
in
the
experience,
we
do
we're
not
thinking
about
many
of
the
possibilities
that
are
out
there,
because
they're
not
core
to
us,
and
when
we
do
things
around
the
way
we
do
some
of
it.
How
does
that
hinder
or
or
help
some
of
those
things
and
I?