►
From YouTube: SIG Architecture community meeting 20180125
Description
B
A
So,
basically,
as
I
was
looking
at
the
external
izing
of
the
cloud
provider,
work
that
we're
doing
it
looks
like
it's
gonna
move
out
to
be
a
container
running
in
the
cluster
somewhere.
That's
the
design
that
that
I
saw,
which
means
that
it's
not
gonna
be
able
to
access
that
metadata
server.
That
is
present
in
all
clouds.
For
information
like
IP
addresses,
nodes
and
stuff,
like
that,
has
anybody
else
looked
at
the
design
and
I
think
there's
gonna
be
performance.
A
A
B
D
Ok,
thanks
Jay,
that's
all
I
wanted
I.
Think
it's
great
I
think
this
might
be
to
suggest
that
having
them
pull
it
together
as
a
kept,
would
be
really
useful,
just
to
sort
of
have
a
document
written
or
take
their
documents
that
they
already
have,
and
we
can
because
this
is
by
definition,
something
that's
gonna
cross
a
bunch
of
different
SIG's
just
the
way
we
have
sig
structured
right
and.
C
D
I'm
sorry,
my
mistake
so
then
probably
extend
the
extend
it
with
this
level
of
detail.
Okay
or
at
least
go
over
the
design,
yeah
I
I,
with
the
nitty-gritty
details.
I
want
to
talk
without
them
here,
necessarily
but
running
it.
Cluster
is
different.
I!
Don't
let's
talk
about
it?
Yes,
they're
on
yeah.
C
So
we
should
try
to
get
that
scheduled
so
also
coming
up
in
the
schedule,
cluster
API
and
those
folks
in
trying
to
work
on
making
the
cluster
lifecycle
tools
more
portable
they're
interested
in
feedback
on
the
API
to
make
sure
it
follows
conventions,
and
things
like
that,
so
they
requested
to
come
on
the
next
office
hours
meeting
in
two
weeks.
So
I
don't
know
if
we
have
time
to
do
both
that
and
cloud
provider,
but
I
would
also
be
fine
with
scheduling
cloud
provider
during
a
regular
meeting.
If
we
need
to
yeah.
E
E
B
C
An
api
group
name
was
suggested
that
I
found
surprising.
I
actually
went
to
go.
Look
at
what
group
names
we're
actually
using
the
in
at
the
api
conventions
to
see
what
guidance
it
provides.
Sadly,
the
guidance
is
lacking
in
this
area.
It
just
says
that
we
reserved
the
empty
group,
which
is
the
original
core
b1.
C
All
the
single
word
groups
like
apps
and
anything
dot,
k,
dot,
IO,
slash
whatever,
so
this
definitely
falls
into
that
ladder
pattern,
but
there's
no
for
their
guidance
about
how
deep
hierarchy
should
go
or
what
how
the
group
should
be
named.
Like
what
information
should
you
be
trying
to
convey
in
the
name
we
have
so
I
pulled
up
the
list
of
existing
groups?
There's
a
link
in
the
notes
TOC.
There.
C
F
Say
that
the
novelty
of
the
admission
registration
admission,
those
were
explicit
because
those
are
part
of
the
machinery
of
omission
not
actual
admission,
and
so
we
wouldn't
want
someone
to
be
confused
that
those
two
were
like
actual
admission
plugins
themselves.
That's
like
be
here's.
The
list
of
the
mission
is
in
the
omission
group.
Omission.
Registration
is
how
you
register,
but
that's
a
background
detail
so
I,
don't
we
this.
C
I'm
just
saying
the
acronym:
if
people
cannot
understand
the
maximum
that
maybe
shouldn't
not
have
used
the
acronym
but
effectively,
the
pattern
we
were
shooting
for
is
first
of
all
things
that
were
concise
because
we
don't
want
to
make
it
too
cumbersome.
Although
you
know
now
that
we
have
so
many
extensions
I
guess
we
did
feel
is
necessary
to
clarify
the
scope
with
K
test
I.
C
Oh,
that's,
fine
I
just
want
to
make
sure
we
have
really
clear
guidance,
so
my
personal
feeling
is
it
conveying
the
domain
is
the
most
important
thing,
and
the
architecture
of
how
that
is
implemented
is
a
less
important
thing
for
users
of
that
I
too
actually
have
to
be
concerned
about
so
I
don't
want
to
get
into
that
pattern.
I
think
it
might
be.
C
F
C
So
anyway,
before
I
consents
to
have
this
PR
approved
I
need
someone
to
actually,
whatever
our
decision
is
about
the
guidance
to
actually
go,
create
a
PR
to
the
API
conventions,
so
that
this
kind
of
question
just
answers
as
a
salt.
Next
time,
like
every
time
in
the
past,
where
I've
asked
for
this
well,
not
every
time
like
Jordan
is
pretty
good
about
going
to
document.
This
I
think
that
was
Jordan.
That
was
gonna,
speak
up,
so
Jordan
says
he'll.
Do
it
I'll
believe
him,
but
anybody
else
I'll
say
you
know.
G
F
C
C
So
the
direction
we're
going
in
a
separate
discussion
which
I
don't
have
time
to
get
into
today,
because
I
can
I
have
to
lead
at
9:00
as
well,
is
we're
creating
a
formal
notion
of
sub-project.
Well
I
have
to
read
Aaron's
last
message
to
see
if
he
still
agrees
with
me
by
work,
so
the
hierarchy
will
be
either
cig
and
under
SIG's
there
can
be
multiple
sub
projects
and
those
sub
projects,
regardless
of
what
their
name
they
have
some
domain.
The
domain
is
what
should
be
the
name
of
the
group.
C
E
Yeah,
that's
a
fair
argument:
I
guess:
I!
Guess
the
counter-argument
might
be
one
if
you
using
a
particular
API
group,
it's
kind
of
handy
to
kind
of
know,
who's
in
charge
of
it,
and
secondly,
it
makes
the
ownership
of
naming
a
little
more
distributed
in,
like
we
don't
have
to
have
a
central
committee
approving
these
things
in
a
what
is
essentially.
C
A
global
namespace:
well,
we
do,
we
do
have
to
have
a
global
namespace,
though,
like
the
reality
is,
there
is
a
global
name
space
and
we
have
there
is
our
Ashley
is
at
least
one
list
and
probably
multiple
lists
checked
in
to
the
code
base
there.
That
doesn't
need
mean
there
needs
to
be
central
approval
unless
there's
an
escalation
like
this,
like
that,
the
convention
is
not
clear.
E
C
D
I
agree,
I,
I
think
back
to
early
times
at
Google,
when
when
there
was
actually
a
single
person
Marissa
at
the
time
who
is
in
charge
for
the
top
level
URLs
and
making
sure
that
things
didn't
get
out
of
control
when
Google
itself
was
exploding,
it
feels
like
that
I
think
having
some
group,
probably
the
API
folks
that
has
like
hey.
You
know
if
you
pick
this
name,
there's
a
good
chance
that
people
will
confuse
it.
This
other
concept,
I
mean
it's
too
easy
to
actually
sort
of.
D
G
D
G
E
Yeah,
that's
that's
another.
Perhaps
argument
for
hierarchy
where
you
know,
policy
within
the
networks
of
namespace
is
reasonably
self-explanatory
and
policy
within
the
storage
namespace
with
you
know
that
the
word
policy
is
the
same,
but
it
clearly
means
different
things
and,
and
it's
pretty
obvious
what
the
distinction
is.
Yeah.
G
Maybe
some
of
the
difficulty
is
this
is
a
policy
around
pods
which
don't
exist
in
a
group
and
we've
never
had
to
come
up
with
a
name
of
a
group
for
pods,
so
yeah
like
if
we
came
up
with
storage
related
policy,
if
that
one
under
storage
case
I/o,
that
would
make
sense
to
me
I
I,
don't
I'm!
Sorry,
what's
it
called
us,
is.
C
C
F
C
C
G
G
That
that
does
seem
like
it
would
kind
of
become
a
magnet
for
undifferentiated
policy.
But
if
we
try
to
be
judicious
about
like
is
this
a
different
social
system?
Is
this
the
network
subsystem
or
volume
or
storage
subsystem
then
go
into
those
groups?
Then
this
can
kind
of
be
the
policy
for
pods
and
things
in
the
core
API
group,
maybe
that
don't
a
clear
other
home
I
am
Not
sure
I.
G
C
G
D
D
C
When
I'm
gonna
ask
for
actually
as
I'm
gonna,
say
sorry
I'm,
gonna,
punt
this
back
and
and
say
the
guidance
is
it
needs
to
be
a
domain
dot.
K
does
do
one
word,
no
deeper
hierarchy.
Don't
include
the
mechanism,
don't
include
the
sig
or
sub
project
and
don't
name
it
after
the
resource
itself.
Like
pod
security
policy
is
too
narrow,
like
we
could
never
add
another.
This
group
if
they
were
called
that
and
I,
don't
want
to
set
that
as
a
precedence
that
people
should
name
it
resource
dot,
something
that's
too
confusing.
C
E
Thanks
but
just
to
be
clear,
I
mean
the
advice
that
you've
just
given
about
no
hierarchy
and
one
word
and
all
of
that
stuff.
It's
not
clear
to
me
that
we
have
consensus
on
that
in
this
group,
I
mean
as
a
one-off.
You
know
John
Locke.
This
thing
it
seems
reasonable,
but
it
doesn't
sound
like
that
is
the
advice
we've
agreed
upon
in.
E
G
Think
it's
a
guidance
for
this
particular
object
where
we
have
one
top-level
object
and
we're
trying
to
figure
out.
Should
we
start
a
new
group
to
contain
exactly
one
objects,
something
like
our
back,
where
you
have
a
collection
of
like
six
different
top-level
types.
I
think
the
nesting
still
can
make
sense,
but
we
want
to
avoid
single
object
groups.
E
C
We
have
we
have
a
list
of
a
bunch
of
groups
and
I'm,
not
super
happy
with.
You
know
all
of
them.
Obviously,
we've
changed
stretch
for
multiple
times
that,
and
you
know,
in
order
to
move
fast
to
just
grew
organically,
so
we
have
tons
of
examples.
I,
don't
know
how
many
more
examples
really
need.
I
think
our
back
dot
authorization
could
have
been
different.
I
mean
it
could
have
been
spelled
out
a
little
bit
more
like
role
based
authorization
or
RB
authorization,
or
something
right
like
it
didn't
have
to
be.
C
Nested
authorization
is
kind
of
part
of
the
domain
I,
but
it
the
way
it's
written,
it's
hierarchical
which
I
don't
want
to
get
into,
and
it
sounds
like
it's
associated
with
mechanism
rather
than
domain
right.
So
it's
kind
of
muddled.
The
intent
of
the
convention,
which
you
know,
admittedly,
was
not
well
documented.
C
C
Implementation
of
lower
levels
of
the
stock
in
the
same
group
just
because
they're
in
a
related
debate,
so
I
think
that
is
maybe
a
fair
question.
That's
still
open,
you
know
I,
we
know
with
respect
to
the
cig
thing.
Yes,
every
one
of
these
groups
should
be
owned
by
some
sub
project
of
some
sick,
like
it
shouldn't
be
overlapping,
multiple
states,
but
the
name
of
the
city
absolutely
should
100%
should
not
be
in
the
name
like
we
should
not
be
start.
C
B
F
You
wanted
clarification,
what
it
was
yes,
so
it
suggests
we
were
talking
about
something
called
application,
and
there
was
an
argument
put
forward
that
it
would
be
easier
to
get
consensus
by
putting
it
into
the
core
API
as
an
alpha
than
it
would
be
as
a
CID
I
was
a
little
skeptical
of
that,
because
I
felt
like
that
means
that
Sierra
DS
aren't
doing
a
good
job
of
coming
up
with
her
own
process.
You
know
the
concern
would
be
like
we
could
do
this
scaredy
and
then
F
people
F
to
migrate.
F
G
F
Anything
about
that
going
forward
in
order
to
prevent
people
from
feeling
like
in
order
to
make
progress.
They
have
to
do
a
core
API.
It's
it
is
I.
It
is
putting
ourselves
first
in
some
cases
where
we're
like.
Oh,
we
can
put
this
in
core,
because
I
can
talk
to
the
stick
and
get
consensus,
but
it
then
puts
us
in
a
model
where
then
we
have
to
go,
legislate
a
bunch
of
stuff
on
a
per
decision
basis.
We
want
teams
to
be
empowered,
but
because.
C
That's
a
good
thing
that
maybe
we
should
get
that
added
to
the
TA
criteria
or
CRD,
but
I
also
think
it's
a
question
of
what
does
being
in
coordinating
with
respect
to
that.
You
know.
Obviously
what
is
core
even
but
if
we
wanted
it
auto
registered
by
default,
for
example,
but
it
still
be
implemented
as
a
CRT
yeah.
F
It
was
really
be.
It
was
really
whether
doing
the
C
or
D,
because
we
don't
have
versioning
for
it.
It
was
gonna
cause
us
a
problem.
We
did
want
to
move
it
and
I.
Think
I.
Think
that's
I
think
there's
a
good
set
of
arguments
that
if
CR
DS
aren't
good
enough,
we
have
to
make
sure
good
enough
anyway,
and
so
I.
D
Would
actually
make
the
suggestion
that
if
the
controller
that
uses
a
resource
is
not
part
of
core,
then
the
resource
itself
is
not
part
of
core
I.
Think
if
we
look
at
ingress
I
think
you
know
ingress
just
being
a
pure
schema
and
nothing
else
with
the
advent
of
CRTs.
We
would
have
done
it
differently
today,
then
then,
back
then,
and.
D
D
D
And
I
think
it's
totally
acceptable
for
us
to
say
here's
the
set
of
CR
DS
that
are
expected
to
be.
You
know,
part
of
a
cluster
that
needs
profile.
X.
You
don't
have
to
install
those
I
mean
it's
similar
to
like
you
know.
You
know
necessary
add-ons
like
you
have
to
have
DNS
or
stuff
breaks,
but
you
really
don't
have
to
have
DNS,
but
really
you
do
right.
I
mean
we
could
have
a
set
of
series
that
are
in
the
same
same
boat,
yeah.
D
D
C
Real
actors,
I've
accepted
the
fact
that
people
will
just
go
use
qulet
and
that's
fine,
and
we
should
make
that
work
eventually.
Once
we
get,
you
know
other
problems
behind
us
anyway.
I
have
to
run
thanks,
yeah,
so
Jordan.
If
you
can
come
up
with
some
ideas
and
ping
me
by
slack
sure,
and
then
we
need
to
try
to
get
this
guidance
checked
in.
So
we
get
cure
these
questions
over
time.
Obviously,
I'll.
E
H
H
Here's
the
thing
some
time
ago,
when
I
was
there,
was
a
proposal
to
be
able
to
specify
a
time
zone
when
you
schedule
a
cron
job.
I
was
reviewing
the
futures
that
we
want
to
land
for
sig
HAP's
last
week,
and
this
struck
me
again
because
from
the
beginning,
I
was
a
little
bit
reluctant
to
it
the
idea
of
having
any
kind
of
notion
of
time
zones
in
a
cron
job.
Currently,
if
you
specify
a
cron
job,
you
just
specify
it
has
run
based
on
a
regular
con,
like
you
do
in
the
Linux.
H
But
apparently
there
are
users,
not
that
many,
a
part
as
well
that
I'm
interested
in
being
able
to
specify
a
time
zone
when
the
job
will
be
actually
triggered,
but
the
problem
with
that
there
are
several
problems.
First
of
all,
none
of
the
times
that
we
represent
in
the
cluster
is
in
any
way
timezone
dependent.
It's
always
one
and
only
single
time
for
everything.
Every
time
related
information
that
we
present
in
the
cluster.
H
The
other
issue
is
that
if
we
decide
to
include
the
time
zones,
actually
that
will
force
the
distributions
to
actually
ship
with
our
time
zone
database,
which
is
a
problem
by
itself
again
knowing
home
hug
huge,
problematic
time
zones
in
general
are
in
every
single
programming
language
and
for
every
single
administrator
out
there.
So
I
brought
this
topic
on
Monday,
say
gaps
and
the
outcome
was
that
nobody
much
complain
if
I
would
be
interested
in
rejecting
it.
H
F
B
I
mean
I
get
the
use
case,
partly
because,
if
you
have
federated
clusters
across
multiple
times,
oh
look:
you
want
to
run
an
EOD
job
or
an
EOD
ETL
job
that
runs
at
5
o'clock.
You
know
to
sum
up:
the
day's
work
and
you've
got
multi-cloud.
You've
got
an
E
major
that
needs
to
run
at
a
certain
time
in
another.
Another
I
mean
how
do
you
yeah.
G
I
mean
those
were
all
the
use
cases
presented
and
I
think
the
the
fact
that
you
can
accomplish
this
from
the
outside,
and
some
of
this
was
discussed
in
the
issue.
You
know
if
you
want
daylight
savings
time
based
runtime.
Well,
you
can
annotate
those
con
jobs
and
then
have
a
controller
that
you
write
that
has
its
own
daylight
savings
time
database
that
you
provide.
That
goes
and
sets
the
run
time.
It's
possible
I
think
it's
difficult
to
require
every
distribution
to
provide
all
the
databases
and
things
required
to
support
it
in
core.
So.
I
So
I'm
gonna
jump
in
here,
though,
because
from
the
outside
looking
in
and
as
somebody
who
says
all
right,
I
want
to
go.
Do
that
you
just
said:
go
write
a
controller
now
I'm
gonna
go
out
and
find
somebody
who
is
actually
capable
of
writing
a
controller
and
I'm,
probably
only
gonna
find
a
handful
of
people
who
even
know
where
to
find
the
docs
are
today
and
and
maybe
a
handful
more
who've
done
it.
It's
really
hard
to
find
people
who
are
comfortable
doing
what
you
just
described.
That's
a
really
high
barrier.
I
D
Operator
to
go,
do
that's
hard
all
right,
so
when
we
say
write
a
controller,
we
don't
mean
that
anybody
who
wants
to
do
this
needs
to
write
a
controller,
just
meaning
that
this
can
be
done
on
the
outside.
It
can
start
as
like
a
sub-project.
We
can
suss
out
all
those
issues.
If
this
wants
to
be
like,
like
it
doesn't
have
to
be,
like
everybody
writes
their
own
controller.
It
just
means
that
an
outside
controller
can
do
this.
People
can
install
it.
They
can
read
the
caveats.
G
F
D
I
Move
it
into
core
all
right,
so
we
don't
just
want
to
close
this.
We
want
to
encourage
the
person
to
carry
out
the
innovation
outside
of
core
to
try
to
suss
out
the
issues
to
distribute
it.
That
way.
We
want
to
be
able
to
have
a
solution
we
can
point
to
in
the
meantime,
and
we
want
to
encourage
the
person
to
go,
do
this
and
give
them
this
kind
of
overall
path
forward.
Rather
than
saying
we're
not
going
to
do
it
here,
because
it's
a
bad
idea
right
and.
G
I
J
D
I
think
there
is,
you
know
the
whole
incubation
process
has
taught.
Us,
though,
is
that
we
don't
want
to
promise
that
hey.
This
is
a
sort
of
you
know
on
Rails
sort
of
path
to
getting
stuff
in
court.
Just
you
know,
say
hey
if
this
can
be
done
outside.
Let's
do
it
outside.
You
know,
under
certain
circumstances,
this
this
may
pave
the
way
to
moving
stuff
to
core,
but
but
that's
on
a
sort
of
case-by-case
basis.
Yeah.
H
H
I
And
and
I
can
relate
to
this
I
wrote
it
a
distributed
calendaring
app
years
ago
and
had
to
deal
with
time
zones
and
distributed
and
I
never
want
to
do
it
again,
but
I
do
notice
something
here.
Maybe
if
I
can
pick
it
one
other
little
thing
in
this.
Is
you
know
this
is
two
issues
we've
talked
about
today
about
start
outside
and
bring
it
in
there's
the
CR
d2
moving
something
into
core,
and
now
this
and
it's
a
common
theme,
we've
kind
of
talked
about.
I
D
Been
talking
about
this,
probably
for
six
months
to
a
year,
I
mean
this
was
a
big
topic
at
the
leadership
off-site.
Was
that,
like
a
year
ago
now
something
like
that?
It's
something
that
we've
been
talking
about
again
and
again
and
again,
I
think
you
know
finding
new
ways
to
to
get
this
message
out
there,
but
the
whole
idea
around
you
know
the
the
layer
diagrams
that
Brian's
been
talking
about.
I
Yeah
I've
heard
it,
but
I
keep
having
to
bring
it
up
in
other
places
where
others
haven't
heard
it
or
they
really
haven't,
got
the
message
that
it's
for
real
and
that's
the
thing
I'm
here
I
hear
it
all
the
time.
But
it's
a
lot
of
other
people
I
run
into
who
aren't
in
this
meeting,
which
is
just
a
handful
of
people
who
are
the
usual
suspects?
Who
who
don't
seem
to
realize.
D
That
and
that's
what
in
in,
in
my
mind
the
our
ability
to
actually
make
that
real
hinges
on
our
ability
to
say
no
and
our
ability
to
say
no
to
things
is
only
over.
The
last
couple
of
months
has
really
gotten
to
the
point
where,
with
the
steering
committee,
with
a
certain
amount
of
legitimacy
behind
SIG's
like
this
one,
we
finally
have
the
ability
to
to
in
a
real
way
say
no,
where
we
didn't
have
before
and
so
I
think.
D
B
Know
I
I've
run
into
this
buzzsaw
myself
now
a
few
times,
and
this
is
something
I'm
hoping
the
steering
committee
will
find
a
way
to
address.
This
is
that
the
the
authority
of
SIG's
seems
fine
until
you
try
and
go
out
and
propagate
something
in
the
wild
and
then
suddenly
it's
it
turns
into
a
melee
and
we
need.
We
need
some
sort
of
way
of
avoiding
that
that
sort
of
churn
that
happens
every
time
something
process
changes,
because
this
sort
of
thing
is.
B
We
all
feel
confident
that
there's
you
know
consensus
we've
talked
about
it,
there's
open
opportunities.
There's
videos
I
mean
everything
under
the
Sun,
but
then
you
get
out
and
discuss
it
in
a
while.
Then
people
have
like
wait.
What
and
it's
this.
Is
this
a
really
serious
problem?
This
is
gonna
block
our
velocity
in
a
lot
of
different
ways.
Unless
we
solve
how
to
get
this,
this
information
down
and.
D
I
think,
fundamentally,
it's
a
communication
problem,
and
so
you
know
some
of
the
contribute
stuff
like
the
I've
been
trying
to
push
and
I
have
to
write
a
cap
on
it
on
a
community
site,
really
sort
of
motivating
that
you
know
caps
themselves
or
one
way
to
communicate
this
but
I.
You
know,
Aaron
has
run
into
this
bus
as.
J
Well,
if
a
website
is
not
the
solution
to
a
communication
problem,
it's
clear
and
consistent
messaging,
it
would
be
helpful
to
have
a
document
to
point
to
that.
You
can
refer.
People
to
and
I
would
I
would
maybe
to
attempt
to
ask
somebody
here
to
answer
Matt
for
his
question
in
that
regard.
It
can
be
something
that
those
tails
nicely
with
this
whole
idea
of
categorizing
a
project
into
core,
not
core
associated,
and
along
with
that,
you
talk
about
how
cool
it
is
that
you
can
do
all
this
stuff
outside
of
core.
J
So
it's
not
really
that
big
a
deal
that
you're,
not
core
I,
think
I've
heard
a
general
like
I
was
in
The
Hague
API
missionary
session
at
coupon.
It
was
a
totally
packed
room
with
the
messaging
of
start
with
CR
DS
definitely
came
out
there
unless
you
care
about
versioning
and
became
doing
the
CRD
thing
outside
of
core.
So
the
message
is
getting
out
in
small
piecemeal
ways,
but
it's
about
like
a
consistent,
talking,
point
documented
somewhere
to
make
sure
everybody's
kind
of
saying
the
same
thing
do.
B
We
need
major
position
papers
or
something
some
sort
of
way
of
saying
this
is
the
this.
Is
the
direction
we're
going
on
in
core
out
core?
Like
I
mean
the
thing
is
I
feel
like
Brian
is
brian
has
poured
so
much
blood
into
this?
Well
I'm
surprised
he
has
any
blood
left
in
him.
After
doing
all
the
work
on
this
stuff,
it's
like
there
seems
to
be
high
level
of
communications
good
enough
I,
I.
J
We're
actually
making
decisions
now,
so
you
know
we
are
sort
of
building
up
this
body
of
case
law
and
I.
Think,
like
yeah,
we
had
everybody
kind
of
communicate,
no
more
new
features
in
the
Leadership
Summit
last
year,
and
this
community
takes
time
to
change.
There
are
those
of
us
who
feel
like
we've
been
saying,
is
over
and
over,
but
I
think
to
Matt's
point.
This
is
about
new
comers
who
haven't
been
hearing
this
over
and
over
being
able
to
point
them
to
a
documented
on-ramp
would
be
helpful
and
and.
D
You
know
that
that
are
almost
not
discoverable,
so
I
something's
got
to
change
there,
I
mean
in
terms
of
the
way
we
do
wide
communication
and
and
there's
no
there's
no
silver
bullet,
but
I
think
over
time
we
can.
We
can
start
to.
We
can
start
to
actually
have
the
canonical
places
to
look
the
canonical
ways
to
communicate,
make
things
look
official
and
make
sure
that
everybody's
on
the
same
page?
It's
it's
not
an
easy
problem,
though
yeah.
J
All
right,
it
was
super
cool
that
Anthony
yeah
got
up
on
stage
at
KU
come
on
and
one
of
the
keynotes
was
about.
Like
look
at
coop
Mehta
controller,
you
don't
even
have
to
write
no
code
to
write
your
own
custom
controller
to
do
your
own
custom
bit
of
functionality.
So
I
think
we're
like
messaging,
that
particular
point
piecemeal
here
and
there
for
sure
about
the
power
and
extensibility
of
kubernetes
and
how
or
really
is
solidifying
and
there's
so
much
you
can
do
outside
of
court.
J
It's
just
reinforcing
that
and
making
sure
we
do
kind
of
have
that
documented,
but
I
like
maybe
I'm
yeah
agreeing
with
Jason
boom.
You
don't
necessarily
have
to
have
a
full
on
policy
document
every
single
time
that
I
feel
like
we're
getting
to
the
point
where
enough
case
law
is
building
up,
I
want
to
make
sure
there's
a
clear
and
consistent
document.
You
can
point
newcomers
to
to
TLDR
instead
of
having
to
have
them
show
up
to
this
meeting
all
the
time.
Well,.
B
D
D
No
but
I
think
some
of
this
is
that
we
do
need
something
like
Alexis
Nexus
for
like
some
of
our
stuff,
because
again
it's
you
know,
it's
spread
everywhere,
I
think
if
we
do
have
some,
you
know
index
that
pulls
this
stuff
together
that
at
least
I
think
that
fills
a
gap.
It's
not
the
whole
solution,
though.
B
Yeah
I
think
that
there
needs
to
be
big
cases.
Essentially,
the
you
know
the
Brown
versus
the
Board
of
Education
type
decisions
that
we
document
and
make
it
clear
that
these
are.
These
are
the
way
in
which
we're
adjudicated
in
any
given
situation
like,
for
example,
if
you
come
to
us
with
a
new
addition
to
core
here's,
the
things
that
you
should
probably
review
as
things
that
we've
rejected
in
the
past.
So
you
have
an
idea
if
you're
likely
to
get
even
project
rejected
early,
so.
J
I
mean
to
Matt's
point
he's
noticed
two
things
of
the
same
variety
in
this
meeting.
I
would
maybe
think
that
if
we
as
a
group
notice
the
same
thing
happening
meeting
after
meeting
which
we
could
do
by
going
through
the
meeting
notes
and
looking
at
it,
we
could
kind
of
notice
when
the
same
question
is
being
asked
to
often,
but
I
also
think
that
those
who
are
coming
to
ask
the
questions
will
go
back
out
and
talk
about
their
decision.
You
can
organically
spread
this
message
as
well
yeah.
I
Yeah
I
guess
I,
don't
know
that
there
is
one
overall
great
way
to
get
to
the
masses,
because
there
are
a
lot
of
people
who
are
Drive
buyers,
or
are
there
a
little
bit
of
a
difference,
distance
and
I'm
not
sure
the
best
way.
I
mean
people
have
tried
it
with
planets.
There's
now
some
of
these,
and
we
probably
have
like
a
weekly
thing.
If
there's
something
written
up
that
somebody
gets
thrown
to
a
weekly
there's,
just
all
these
little
ways
of
communicating
out
to
Damasus
and
I'm
not
sure
the
best
way
so
so.
I
They
set
a
precedence
of
go,
create
your
own
packages
and
created
the
tooling
and
shared
that
tooling,
with
GoGet,
and
things
like
that
that
people
are
now
building
on
to
get
more
features
in,
but
they
very
early
on
set
a
pattern
and
precedents
for
doing
that,
and
kubernetes
very
early
on
set
up
kind
of
a
pattern
of
precedence
of
do
a
lot
of
stuff
in
core
and
I
know.
One
of
the
things
that's
been
brought
up.
Is
you
know,
folks,
like
a
Google
say:
well,
I
can't
go.
I
Do
it
elsewhere,
because
I
don't
have
a
place
that
I
can
contribute,
because
I
got
carte
blanche
with
the
kubernetes
project,
but
not
elsewhere.
So
I
want
to
get
in
core,
because
it's
the
only
place
that
I
have
permission
to
contribute
it
and
they're,
not
the
only
company
that
are
like
this
and
yeah.
J
I
J
So
I
must
have
jumped
I
added
some
bullet
points
to
something
that
must
have
meant
something
totally
different
I
just
wanted
to.
Let
this
group
know
that
I've
started
implementing
the
whole
concept
of
stuff
projects
and
how
they're
assigned
to
SIG's
I
created
an
issue
in
community
and
I
tagged
it
with
the
steering
committee.
I,
guess.
J
State
architecture
to
let
me
do
that
right
now,
using
this
handy-dandy
and
I
created
a
straw.
Man
implementation,
where
formatting
is
hard
I'm
trying
not
to
slime
like
changing
the
formatting
of
the
entire
readme,
just
to
accommodate
this
new
set
of
information.
But
if
you
have
any
thoughts
on
either
the
content
of
the
sub
projects
that
I
assigned
based
on
the
spreadsheet
that
Brian
granted
the
first
pass
at.
J
So
this
would
have
been
all
the
repos
under
kubernetes,
kubernetes,
incubator
or
kubernetes
helm
I
just
assumed
that
there
was
an
owners
file
there
and
then
assign
that
to
say
based
on
his
designation
and
then
at
Matt's
suggestion.
I
also
just
took
a
complete
guess
at
what
the
workloads
API
project
might
look
like
from
the
perspective
of
which
owners
files
encompass
all
of
the
code
that
has
to
do
with
the
workload
api's.
J
So
we
have
some
strong
men
of
what
this
would
look
like
from
both
its
presence
in
a
machine,
readable,
yamo
file
and
in
readme
files
that
people
can
go
look
at
when
they
have
questions
like
home.
What
what?
What's
the
home
sub
project?
Who
does
that
belong
to?
What's
this
workload
API
to
some
project,
I.