►
From YouTube: SIG Architecture Community Meeting 20180104
Description
A
Welcome
everybody
to
the
first
sake,
architecture,
meeting
of
2018,
it's
Thursday
January
4th
I
am
Jason
Raja
Mars
I
am
the
committee's
ambassador
from
Microsoft
and
co-leader
the
sig
with
Bryan
grant.
Today.
The
agenda,
if
you
are
looking
at
this
video
later,
is
available
at
bit:
dot
Lee,
slash,
sig
architecture
and
we'll
be
going
through
that
momentarily.
So
without
further
ado,
what
I
had
done
was
go
ahead
and
put
a
few
things
in
a
generic
bucket
of
status
that
we
need
to
discuss.
A
B
We
spend
some
time
discussing
this
in
steering
committee
yesterday
and
and
I
think
we're
getting
pretty
close
to
a
consensus
to
kick
the
dark
that
I
had
out
as
a
we
feel
like
it's
close
enough.
There's
some
discussion
about
whether
it's
or
per
se
or
sig,
sponsoring
multiple
orgs
that
lies
in
the
technical
details.
In
my
opinion
of
the
implementation,
and
we
want
to
kind
of
get
something
moving.
B
That
said,
a
couple
people
were
not
at
the
steering
committee
meeting
and
so
we're
gonna
wait.
A
little
bit
give
people
a
little
bit
of
time
to
calm
it
and
then
put
the
dock
out
for
a
full
public
on
it,
as
well
as
the
fact
we
need
to
add
a
FAQ
around
sort
of
like
what.
What
does
this
mean
if
I'm
a
cube
incubator
project?
What
does
this
mean?
B
A
B
I
mean
it's
available
like
there's
people
and
not
just
steering
committee
people
like
people
commented
on
it.
So
like
okay,
you
can
find
it
from
the
list
and
if
people
want
to
go
comment
on
it,
it's
just
that
we're
not
really.
It
needs
a
degree
more
polished
before
it's
ready
for,
like
the
mass
laughs
and
everyone
to
come
in
and
start
commenting.
Okay.
A
D
So
yeah
there's
that
so
I
can
cover
this.
So
there
have
been
a
to
do
outstanding
on
the
architecture
working
or
the
architecture.
Sagarika
texture
backlog
since
I
want
to
say
since
September
to
document
and
describe
API
review
process.
We
had
a
couple
of
resolved
things
around.
Like
formalized.
We
had
some
verbal
agreement
on
formalizing
a
few
constructs,
but
we
haven't
really
recorded
that
there
was
an
email
discussion.
Tim
brought
up
over
Christmas
around
having
a
meeting
for
a
guy
review.
D
I
think
that's
just
one
facet
I
had
the
to
do
to
resolve
some
release,
related
API
review
suggestions.
So
what
I've
done
is
I
pulled
the
other
doc
with
several
suggestions
in
there
I'd
like
people
and
say
architecture,
to
take
a
look
at
it
and
we
can
discuss
it
on
the
mailing
list
over
the
next
two
weeks
and
then
come
back
on
it.
I
think
most
of
the
suggestions
people
have
made
are
very
reasonable
ones.
D
The
meeting
is
probably
the
most
impactful
to
people's
time,
but
it
did
seem
like
there
was
a
there's,
a
lot
of
interest
in
people,
people
being
able
to
see
and
participate
and
discuss.
Api
review
in
a
larger
forum,
and
so
it
may
be
that
we
can
be
ready
to
trial
it
I'd
suggest.
Let's
just
have
the
discussion
in
the
dock,
for
people
who
are
interested
and
then
we
can
maybe
raise
that
as
a
separate
topic
up.
We
can
do
a
trial
one
and
see
how
it
works
and
then
go
on
from
there.
D
B
Thing
I
would
say
here
having
owning
like
new
API
surface
area
for
cloud
and
running
these
API
reviews.
We
have
found
over
time
that
the
meetings
turned
into
giant
time
sinks
and
building
tooling
to
do
essentially
common
error
detection
is
going
to
be
essential,
so
I
think
a
meeting
is
a
good
idea,
but
I
would
highly
recommend
that
we
practice
it
with
buildings.
Yeah.
D
D
So,
even
if
the
meetings
are
initially
about
more
education
and
discussion
and
then
gradually
become
more
of
an
automated
thing
or
we
when
we
reduced
the
need
for
it,
I
think
that's
a
I
think
it
is
valuable
to
treat
it
as
educational
and
about
fostering
communication
first
and
then
second
would
be
the
act
of
actually
resolving
the
kind
things
at
least
gives
us
an
opportunity
to
deal
with
that
feedback
right.
Yeah.
B
C
D
There
some
a
few
people
had
made
stabs
at
some
of
these.
We
it's
probably
a
undermined
area
which
is
there's
a
lot
of
conventions
we
have
that
could
be
enforced
pretty
easily.
We
just
haven't
put
the
work
into
it,
and
so
that
might
be
a
full
comment
between
both
sick
testing,
sick
and
Trebek's
and
Sagarika
texture
for
a
110
or
111.
D
To
do
more
automation
of
this
as
we
evaluate
the
load
on
the
reviewers,
something
that
I'll
put
that
in
the
dock,
any
other
high-level
things
that
I
want
we
can
I
would
prefer
to
do
most
of
the
the
suggestions
and
discussions
in
the
dock
I'll
make
sure
I'll
make
sure
that
we
have
Sagarika.
Texture
should
have
edit,
but
please
use
suggestions,
so
we
can
track
what's
going
on.
A
Alright,
so
the
next
agenda
item
is
to
talk
about
any
implications
from
an
architectural
perspective,
about
moving
to
a
3
release
cadence
per
year
instead
of
4.
There
is
a
discussion
going
about
this
on
the
mailing
list
for
community
stuff
and
I
just
wanted
to
make
sure
that
we
get
a
chance
to
talk
about
it
since
we're
one
of
the
stakeholders
in
that
for
sure
and
Tim.
If
you
want
to
lead
the
discussion
on
this
I'm
happy
to
take
over
note-taking
and
then
I'll
interject,
if
I
need
to
so.
E
During
coop,
con
Tim
Hawkins
had
given
a
talk
about
potential
changes
to
our
distribution
patterns
and
in
lieu
of
us
you
know
coming
up
with
a
formalized
long-term
plan
and
recognizing
some
of
the
constraints
that
we
currently
have.
The
idea
that
I
wanted
to
propose
and
sent
out
to
the
mailing
list
was
just
to
back
off
by
one.
We
do
everything
pretty
much
the
same
as
we
did
before.
It's
just
to
have
less
churn
as
part
of
our
yearly
process
right.
E
D
Argue
that
a
lot
of
the
churn
also
came
from
the
fact
that
koukin
is
in
key,
for
you
can
visibly
see
every
single
CN,
CF
projects
commit
count,
drop
down
and
that's
not
gonna
change
next
year
either.
I
think
Yukon
for
Seattle
at
least
is
scheduled
sometime
in
December,
and
we've
got
another
one
scheduled
in
China
in
November.
So
that's
going
to
be
pretty
significant
impact.
E
E
B
We
should
make
some
degree
of
like
theoretically,
cherry-picking
right
now
is
bugs
only
I.
Think
if
we're
gonna
move
to
longer
tables,
we
may
need
to
have
a
breed
of
like
cherry-picking
a
feature.
I
know
we
do
that
already,
but
something
a
little
bit
more
explicit
so
that
people
don't
feel
pressured
like
I
really
want
to
use
this
feature.
But
I'm
not
gonna
have
a
release.
G
G
D
Right,
the
other,
the
other
thing,
that's
the
only
big
consequence,
I
see
that
I
would
push
back
against.
As
a
result
of
this
is
our
existing
deprecation
policy
that
uses
releases
as
the
gate,
something
like.
We
only
support
things,
three
releases
back,
which
would
effectively
mean
that
every
feature
every
flag,
every
whatever
that
is
in
kubernetes
today,
right
now,
is
not
going
to
leave
it
until
next
year.
E
D
And
I
get
that
I.
Guess
it's
it's
along
the
theme
of
how
I
think
you
know.
One
of
this
six
mandates
is
to
help
us
really
clean
up
a
lot
of
protect
that
that
we've
incurred
along
the
way
to
get
kubernetes
to
where
it
is
and
so
the
effective.
We
can't
really
exercise
that
tech
debt
as
quickly
as
we'd
like
so
we're
gonna
have
to
be
a
lot
better
about
putting
in
really
bright,
visible,
defecation
and
do
not
enter
and
do
not
use
here.
D
A
Yeah
I
guess
that's
right.
Instead,
we're
gonna
we're
gonna,
be
shortening
or
lengthening
these
cycles,
but
that
doesn't
actually
say
anything
about
what
will
be
happening.
Besides
coding
I
mean
there's
aspirational,
thinking
about
people
getting
dachshunds
sooner
or
getting
more
tests
in
or
more
stability
more,
not
but
I
I
think
that
that's
I
think
that's
a
erroneous
assumption.
I,
don't
think
we
have
any
proof
to
to
say
that
you
know
the.
A
D
F
So
I
have
a
question
or
getting.
There
was
a
separate
but
related
discussion
about
heaven.
Lts
releases
of
kubernetes
so
probably
may
like
first
of
all,
I'd
like
to
understand
a
community
standpoint
in
communities,
and
we
probably
may
adopt
this
proposal
of
heavens
releases
per
year,
which
I'm
totally
supportive
of
so
we
probably
may
adopt
this
concept
of
having
two
losses
per
year
with,
for
example,
two
like
general
losses
and
one
LTS
release
and
LTS
release
can
be
at
the
end
of
the
year
and
it
will
also
incorporate
the
errants.
F
E
Want
to
explicitly
defer
that
conversation
until
we
just
have
the
first
logistical
conversation,
because
that's
a
broad,
much
broader
implications
to
process
and
workflow
and
I
also
want
a
time
box,
because
I
know
that
other
folks
are
here
to
talk
about
another
repo.
So
I
think
we
started
a
conversation,
but
I
think
it's
by
no
means
the
end
of
the
conversation
and
a
community
meeting
I
want
to
discuss.
E
F
E
A
F
D
A
Alright,
let's
go
ahead
and
move
on
I
have
a
just
a
generic
bullet
point
in
here
about
what
are
we
trying
to
accomplish
in
110,
and
this
is
really
just
a
quick
like.
Let's
give
this
eight
minutes,
give
it
to
that
like
what
are
there
any
specific
things
that
we
need
to
be
ensuring
that
we
deliver
in
this
release?
I.
E
A
A
G
D
Is
the
one
that's
like
the
obvious
one,
because
we
have
been
thinking
pretty
strongly
about
leveraging
flex
volumes
as
a
way
of
dogfooding
and
proving
out
the
extensibility
mechanisms
for
the
node
as
well,
as
you
know,
doing
our
best
to
not
add
things
to
cube.
But
then
the
point
that
was
raised
in
that
thread
I
think,
is
a
very
valid
one,
which
is
anything
that's
not
any
extension
mechanism.
D
That's
not
possible
on
a
virtual
cubelet
would
be
something
that
be
very
difficult
to
say
as
a
core
cube
function,
and
so
that
tension
will
remain
for
features
that
might
have
been
purely
extension.
Only
if
you
can
extend
ODEs
need
to
actually
go
back
into
the
core.
If
you
can't
extend
nodes
and
I
think
that
discussion
can
happen
in
suit
node
yeah.
C
D
I
I
was
channeling
as
much
of
Brian
as
I
could,
which
is
like.
The
right
thing
for
us
to
do
is
to
use
our
own
extension
mechanisms,
but
if
we
were
going
to
have
like
a
simple
core
like
we
have
to
preserve
the
compatibility
with
things
like
service
account
tokens
because
it
is
part
of
our
API
and
so
we're
there
were
discussions
at
cube
con
around.
Maybe
some
of
the
more
extensible
approach
would
actually
increase
the
burden
on
teams
and
people
deploying
kubernetes
and
so
I
think,
there's
just
a
little
bit
more.
D
A
H
H
So
we
asked
for
one
of
these
things
and
this
ended
up
being
a
proposal
for
a
generic
repo
for
all
sorts
of
different
kinds
of
test
frameworks,
and
that's
the
proposal
that
you
can
see
linked
in
there.
I
suspect,
if
the
thing
that
the
first
thing
that
you
discussed
today,
if
I
understood
that,
if
you
had
one
org
Pirsig
already,
then
probably
this
repo
would
have
just
been
made
within
the
CLI
org,
because
we'd
have
had
power
to
do
that.
H
A
H
It
depends
on
what
organizational
model
you
want.
So
if,
if
we
were,
if,
if
you
want
an
organizational
model
where
SIG's
control
their
own
destiny
more
than
they
appear
to
at
the
moment,
then
it
seems
to
me
that
you
know
from
this
just
a
vantage
point
that
I
have.
It
seems
to
me
that
SIG's
just
being
able
to
create
repos
when
they
do
things
would
would
be
very
sensible.
H
And
if
you
can
do
that,
then
you
don't
need
one
test,
repo
that
contain
what
one
test
framework
repo
for
all
test
frameworks,
because
it's
very
easy
anytime.
Anyone
creates
a
test
framework
to
just
well
we'll
have
a
repo
for
it
and
it'll
be
fine,
but
because
it's
so
difficult
to
create
git,
repos
right
now.
I
think
that
that
adds
to
that
that
adds
this
idea
of
oh
well.
H
D
Mainly
I'm,
just
like
putting
forward
my
few
stunts
that
I
think
this
is
a
good
idea
and
I
think.
The
reason
that
Hans
and
Gareth
are
coming
through
this
path
is
because
I
think
this
is
a
core
thing,
not
just
something.
That
starts
out
in
some
arbitrary
saying.
The
argument
has
been
made
in
the
past,
where,
if
somebody
wanted
to
add
a
new
piece
of
functionality
inside
of
kubernetes
kubernetes,
we
should
be
first
asking
ourselves
about
something
that
could
exist
as
a
separate
repo
and
a
integration
test
framework.
D
Clair's,
since
he
has
sort
of
maybe
stronger
opinions
on
the
testing
side
of
things.
You
know
from
a
sick
testing
perspective,
we
have
been
talking
about
having
a
Tim
step
up
and
take
more
of
an
active
role
in
guiding
as
practices
in
frameworks
for
writing.
The
tests,
as
a
lot
of
testing
time,
has
been
spent
on
what
we
do
with
running
the
tests
and
collecting
the
test
results
and
whatnot.
E
The
the
question
I
have
is
if
every
sub-elements
that
gets
worked
off
has
its
own
separate
testing,
which
isn't
this
really
a
bad
thing.
The
there's
a
lot
of
repetitive
code
that
will
be
generated
and
created,
and
the
idea
of
having
a
single
repository
is
to
reduce
the
amount
of
repetitiveness
and
potential
bugs
that
could
occur
and
I.
There
are
separate
frameworks
that
could
occur
at
different
granularities
and
we've
had
conversations
across
the
board
over
time
about
pushing
these
frameworks
for
lack
of
a
better
word.
E
I
hate
that
name
their
term,
but
into
a
common
location
and
I
know.
Brian
has
mentioned
it.
I've
mentioned
it.
Rumors
mentioned
several
other
people,
who've
worked
across
several
repositories.
The
tests
themselves
would
likely
live
in
the
main
line
of
whatever
artifact
they
were
being
used
to
test,
but
the
the
core
library,
/
framework
would
probably
exist
outside
of
that
and
could
be
vendored
in
appropriately
I'm.
E
D
E
There's
there's
a
counterpoint
to
that
which
is
the
vendor
in
sprawl
that
occurs
right.
If
you
were
to,
if
you
were
to
have
a
10
repose
forever,
all
the
little
things
I
think
having
a
general
catch-all
for
the
test
is
not
that
large
and
scope
right
and
we
could
add
things
as
needed
and
evaluated.
You
know
with
the
immediate
constraint
at
hand
right
which
is
like
they
need
to
get
their
stuff
done,
they'll
block
them,
get
them
unblocked.
D
Yes,
I
mean
practically
what
I'm
trying
to
understand
is
if
you're
arguing
for
this
repo
to
live
as
yet
another
one
of
the
staging
repos
where
it
exists
inside
of
the
main
KK
repo.
So
it
can
have
more
dependencies
on
code
in
there,
but
it
is
published
separately
as
a
more
constrained
repo
or
if
we're
sticking
to
the
proposal
of
we
want
this
to
live
entirely
as
a
separate
repo
that
is
not
published
from
the
KK
entirely.
E
As
its
separate
repo,
but
as
a
series
of
libraries
right
now
with
it
containing
one
library
but
a
potentially
expanding
in
scope
and
and
make
sure
that
that
scope
is,
is,
is
known
to
be
a
vendor
the
library
for
currently
their
integration
test,
but
could
be
more
broader.
All
integration
tests
and
all
intent
test
or
testing
utility
libraries.
H
Your
your
intent
or
your
understanding
of
what
you're
asking
for
I
think
it
does
line
up
with
my
understanding
of
what
we're
asking
for
I.
Think
one
of
the
back
and
forth
that
were
having
on
the
PR,
which
is
for
me,
is
on
a
screen
there
about
this
proposal
is
about
what
ought
to
be
allowed
to
be
vendored
in
to
the
new
repo
one
of
our
objectives.
H
We
want
to
avoid
those
loops,
so
in
fact,
for
our
framework,
because
all
it
does
is
call
things
out
of
the
CLI,
we're
pretty
sure
we
don't
need
to
vendor
anything
from
kubernetes.
So
for
us
we
would
be
very
happy
to
say
that
and
I
see
that
there
are
a
few
comments
from
from
Tim
here
saying:
oh,
you
know
you,
you
will
absolutely
need
something
or
something
else:
I
think
that
the
internal,
the
external
client
or
something
like
that
and
I
I
don't
have
the
context
to
to
understand
how
powerful
those
points
are.
E
What
you
were
just
saying,
if
you
have
utility
in
libraries
outside
of
the
scope
of
the
CLI,
which
is
basically
like
showing
to
test
it
all
right
and
that
actually
use
the
API
itself,
Yool
Yool,
absent
end
testing
framework
currently
leverages
the
internal
client
pretty
heavily,
and
eventually
you
would.
You
would
want
to
reference
the
external
client
if
possible.
E
B
B
H
Like
it's,
it's
not
useful
outside
of
the
context
of
kubernetes,
so
you
know
it's
not
a
generic
framework
for
testing
binaries.
It's
it's
a
framework
for
testing
kubernetes
clients
which
need
there
to
be
a
running
kubernetes
stack
of
some
kind.
We
need
there
to
be
an
API
server
and
@ct
in
this
kind
of
stuff.
So
you
know
philosophically
it's
certainly
related
to
kubernetes,
and
I.
B
B
B
C
D
Like
I
mean
I
think,
there's
lots
of
things
that
are
used
by
many
things
in
kubernetes,
that
don't
aren't
in
core
and
so
like
I
feel
like
there's
a
bar
there,
which
I
prefer
to
have
the
bar
of
not
putting
in
the
kubernetes
or
I,
must
absolutely
one
more
person
has
to
be
so,
and
we
should
reserve
that
for
things
that
absolutely
have
to
be
there,
I
don't
think
there's
any
like
there
has
to
be
an
advantage
that
is
thinking
across
the
entire
project.
To
do
that,
it
feels
like
right
either
ways
why.
H
D
Other
than
the
only
potential
thing
I'm
aware
of
is
copyright
and
CLA,
and
but
everything
else
I
mean
you
know.
We
depend
on
like
99%
of
the
NGO
ecosystem,
that
uses
docker
depends
on
F,
Sousa,
go
docker,
client
and
that's
never
been
an
issue
like
you
could
argue
that
the
bus
there
on
that
is
higher
than
anything
else
and
I
mean.
H
H
B
I
would
say
that,
like
look
at
look
at
PFLAG
great,
like
key
flag,
was
created
by
I,
can't
even
remember
who
and
then
largely
abandoned
and
then
x-men
SK,
13
sort
of
great
everybody
is
that
person
now
like.
So
this
stuff
happen.
If
people
move
on
the
fold,
is
there
and
and
I
think
that
I
think
I
come
back
to
the
like?
It
has
to
have
to
be
a
concrete
advantage
and
all
I
see
actually
right
now
a
disadvantage.
D
B
D
With
my
confusion,
though,
I
just
want
to
be
clear
about
one
rule
of
thumb
I
had
been
using,
which
maybe
isn't
we're
like
to
me.
If
I
squint
at
this
proposal,
it
looks
like
we
want
to
work
on
test
integration
frame.
We
want
to
work
on
the
test
integration
framework
package,
assuming
there
were
such
a
thing
inside
of
your
gratis
kubernetes,
just
like
there
is
a
test
e
to
e
framework
package,
and
so,
if
someday,
we
decide
to
extract
the
test
e
to
e
framework
package
out
of
the
kubernetes
kubernetes
repo.
B
A
B
D
Ahead,
Brennan
there
you
go
clay,
I
was
gonna,
say
I
would
be
ecstatic
if
the
e2e
framework
code
left
kubernetes
kubernetes,
like
all
the
the
stuff.
That's
like,
can
I
test
a
kubernetes
cluster,
like
conformance
all
of
these
things
like
there
are
plenty
of
things
that
would
love
to
be.
That
would
do
it.
I
think
that'll
be
great
for
a
cig
testing.
D
Work
like
those
are
things
that
they
just
happen
by
accident
of
history,
to
be
in
kubernetes,
kubernetes
and
ven,
during
something
from
cig
testing
or
rendering
something
from
kubernetes
testing
or
whatever
it
is,
does
not
seem
like
a
huge
obstacle
or
even
that
sure,
but
the
point
I'm
driving
at
is
just
so
not
everything
that
is
included.
Nettie's
kubernetes
today
will
eventually
be
considered
part
of
core
kubernetes,
as
we
look
to
extract
it
because
I'm
not
talking
about
signing
up
Gareth
to
extract
e
to
e
I,
know.
B
D
A
great
example
is
ete
is
kind
of
a
disaster
right
now
for
things
that
are
outside
of
cube
that
want
to
write
e
de
conformance
tests
like
service
catalog.
They
have
to
vendor
kubernetes
and
ete,
currently
pulls
it
in
the
entire
kubernetes
dependency
tree
because
of
poor
choices
we
made
with
dependency
packaging.
Someone
eventually
is
going
to
go
snip
that
it
hasn't
happened
yet
because
it's
really
only
service
catalog,
it's
a
serious
project
that
has
its
own
api's.
It
will
happen
in
the
moment.
D
It
does
we'll
need
to
we'll
probably
need
to
snip
those
different
and
they're
not
signing
up
but
I'm.
Just
saying
like
in
general,
we
will
have
lots
of
code
that
will
be
vendored
into
projects
in
kubernetes
that
are
not
incriminating
to
kubernetes
like
service
catalog
and
others.
That
are
testing
frameworks,
and
it
seems
like
a
very
natural
place
for
it
to
be
under
Sigma.
D
Ok,
what
I'm
hearing
then
actually
is
if
Gareth
can
hold
tight
until
we
actually
go
off
and
create
all
of
these
signals
and
Brendan
gets
his
dog
out
to
the
rest
of
the
world,
and
we
get
sign
off
on
all
of
that.
Then
I'll
totally
create
a
repo
and
in
the
orange
that
I
am
and
we
can
move
forward
from
there.
E
D
D
D
B
F
H
D
H
A
Okay,
so
will
I'm
gonna
definitely
put
it
on
office
hours
for
next
week
to
follow
up
on
this
and
find
out
make
sure
the
cig
testing
is
willing
to
take
ownership
of
that
and,
if
not,
then
we'll
redo
it.
But
let's
assume
that
everything's
just
going
to
march
forward
on
that
so
right
now
there
is
not
anything
else
on
the
agenda.
We
have
14
minutes,
I'm
glad
to
give
it
back
to
you
or,
if
there's
anything
pressing
we
can
discuss.
Let
me
know
right
now
and
if
not
we'll
quit.