►
From YouTube: SIG Architecture 20181025
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
Okay,
good
morning
afternoon
evening,
wherever
you
may
be
in
the
world
or
after
the
fact
watching,
this
historically
today
is
Thursday
October
25th
2018.
This
is
Kevin
Eddie's,
sick
architecture
and
I.
Am
your
co-chair
Jason,
your
Dumars
and
I
work
at
Google
and
we're
gonna
get
started
the
agenda.
Should
you
want
to
follow
along
after
the
fact
or
now?
Is
it
bit
dot?
Lee,
slash
sake.
Architecture.
We've
got
a
full
agenda
today
and
it
would
will
be
have
to
keep
to
our
time
boxes
or
we
won't
make
it
through.
A
If
somebody
could
be
the
note-taker,
that
would
be
great.
It's
really
hard
for
me
to
moderate
and
also
take
notes.
So
anybody
please
jump
in
you
should
have
edit
rights
to
the
document,
and
that
would
be
extremely
helpful.
So
without
further
ado,
let's
go
ahead
and
get
into
the
first
item
which
I'm
guessing
belongs
to
Erin
and
it's
the
conformance
test.
Prs
that
need
attention.
B
Sure
I,
don't
think
I
have
a
lot
to
talk
about
here
this
week.
I
suppose
I
can
share
my
screen
just
to
show
us
the
PRS
that
we're
talking
about
give
me
a
second
screen
sharing
is
disabled.
It's
no
big
deal
so
so,
basically,
there's
a
PR
ready
for
review
in
the
in
review
column
on
the
conformance
board.
I
can
poke
Brian
or
Clayton
about
that
later
today.
B
There's
also
an
issue
I'd
like
comment
on
we
mentioned
is
briefly
last
week,
where
there's
a
demon
set
test
that
just
straight-up
doesn't
make
sense
unless
there
are
multiple
nodes
in
the
cluster.
It's
marked
as
conformance
right
now,
but
it
also
skips
unless
they're
more.
There
is
more
than
one
note
in
the
cluster
and
we
kind
of
have
this
thing
where
we
don't
want
to
farm
its
tests
to
skip
for
any
reason.
B
So
the
question
is:
do
we
add
some
kind
of
tag
like
multi,
node
or
feature
multi
node
or
whatever,
to
decide
whether
we
should
keep
this
in?
Kick
this
out
so
on
and
so
forth?
I,
don't
think
we
need
to
talk
about
that
here,
but
I
would
like
discussion
from
folks
who
have
opinions
on
that
issue.
The
other
thing
I
want
to
call
out
is:
there's
a
PR
about
exposing
a
TTY
option
for
probes.
This
has
been
flagged
with
a
kind
API
change
raised,
my
eyebrows
because
it
involves
adding
a
field
to
v1.
B
Api
I
won't
go
into
the
details
of
that
because
I
haven't
looked
to
much,
but
it's
raising
my
eyebrow
I,
don't
know
if
anybody
here
has
looked
at
that.
But
I
would
really
like
you
to
take
a
look
at
that,
because
conformance
tests
do
involve
the
liveness
probes,
readiness,
probes
and
so
on
and
so
forth.
So
that
should
be
looked
at.
There
was
discussion
last
week
about
mixed
OS
clusters
or
what
it
would
take
for
Windows
containers
to
Gogi
a
that
is
not
something.
I
really
have
the
time
to
you
actively.
B
Shepherd
I
feel,
like
this
group
decided
that
we
needed
a
group
of
people
to
go
off
and
gather
the
requirements
of
like
differences
across
operating
systems.
I
don't
know
if
anybody
has
actually
taken
an
action
item
for
that
and
has
then
come
up
because
we
ended
up
canceling,
the
conformance
working
group
meeting
yesterday
due
to
lack
of
agenda.
B
So
I
don't
know
if
this
is
the
forum,
if
that
other
group
is
the
forum,
but
just
raising
that
if
somebody
cares
deeply
about
Windows
containers
going
to
GA
and
that
being
considered
part
of
a
certified
conforming
kubernetes
cluster,
they
should
take
ownership
of
this
and
drive
it
forward.
We
talked
at
length
about
this
last
week,
so
I
won't
go
further
into
it.
Do.
C
A
D
Right,
like
it's
gonna,
be
a
really
thorny
thing
to
solve
and
we're
gonna
have
to
at
some
point,
and
it's
just
a
question
of
whether
this
is
the
one
that
pushes
us
across
or
we
try
and
check
a
strategy
where
that's
not
necessary,
yeah
Nick,
it's
it's
just
like
anything
else,
and
so
right
now
my
strategy
is
to
say:
hey:
let's
try
and
push
for
conformance
on
hybrid
clusters
whereby
conformant
we
mean
you
know
as
much
of
the
tests
as
we
can.
We
run
on
Windows
and
the
rest
of
them.
D
We
run
on
Linux
and
we
only
say
that
for
now
we're
giing
with
the
notion
of
a
hybrid
cluster
as
opposed
to
a
Windows
only
cluster,
because
I
don't
want
to
be
in
position
of
watering
down
the
conformance
tests
by
turning
things
off.
If
it's
a
Windows,
only
cluster
and
then
I
think,
ultimately,
the
right
solution
is
to
have
the
profiles.
Discussion
and
you
know-
have
have
the
various
profiles
but
I
feel
like.
If
we
have
that
discussion,
we're
gonna,
be
it's
gonna.
Take
us
six
months.
D
E
D
E
But
I
think
you
know
we
can
start
small
with
something
where
we
have
real
concrete
needs
about.
I
am
worried
and
I
think
this
is
something
that's
that
bares
discussion
around
this
idea
of
a
hybrid
cluster
right
I.
You
know
the
fact
that
some
stuff
works
on
a
cluster
on
some
nodes,
but
not
across
all
nodes
is
I,
think
going
to
be
confusing
to
users,
so
I
think
it
might
be
worthwhile
to
sort
of
clarify
that,
with
respect
to
conformance
yeah.
E
F
There
is
actually
a
document
Joe
about
what
profiles
are,
and
actually
the
proposal
was
that
the
base
that
profiles
be
strictly
additive,
so
there
would
be
need
to
be
a
basic
profile
that
worked
everywhere
that
can
be
brought
up
again.
It
was
presented
previously,
at
least
in
the
conformance
working
group.
Dan
has
been
at
least
discussed
in
certain
architecture,
but
we
can
dig
up
that
talk
and
reshare,
but
that's
the
basic
concept
is
that
there
would
be
yeah
they
would
be
audited.
The
previous
the
original
proposal
was
both
additive
and
subtractive
and.
F
E
D
A
Things
bring
in
this
super
helpful.
Do
we?
This
is
something
to
we'll
get
into
in
a
second
in
terms
of
cig
Charter
review,
but
this
is
a
classic
example
of
there's.
Probably
decisions
to
be
made
here
and
right
now.
That
decision
belongs
first,
is
in
an
owner's
file
that
characterizes
what
tests
are
out
for
the
the
compartment
suite
it
should
we
be
starting
with
with
the
approval
layer
and
working
backwards
so
that
we
understand
what
actually
is
feasible
and
not.
Is
that?
How
are
we
going
to
handle
decision-making
in
this
I?
A
Don't
understand
at
some
point
that
will
decide
ei
profiles.
How
does
that
actually
get
implemented?
Who
who
approves
that
decision?
Who
actually,
who
is
a
person
in
an
owner's
file
somewhere?
That
says
no
writing.
E
Okay,
I
think
this
is
squarely
on
Sega
architecture
to
actually
define
what
conformance
is
and
I
think
that
means
what
the
profiles
are.
What's
in
and
out
of
the
profiles,
this
is
just
wondering:
what's
the
project
so
I,
we
can
make
it
a
sub-project
of
sega
architecture
in
some
ways
it
it
it
intersects
with
with
getting
the
Charter
done,
but
I
would
say
it's
it's.
Some
type
of
thing
related
to
this
group.
Well,.
B
B
I'm
not
sort
of
thing
to
say,
we
probably
need
to
just
have
a
sub
project
with
documented
owners
and
the
scope
of
what
they
have
so,
at
least
that
our
process
and
everything
is
documented.
It's
not
a
bunch
of
us
who
show
up
who
have
differing
in
opinions
and
the
people
of
the
week.
Those
already
there's
already
an
owners
file
for.
F
This
discussion
was
time
boxed,
which
is
a
good
segue
to
the
next
topic,
which
is
the
Charter.
So
we
started
on
a
charter
a
few
months
ago,
and
we
took
a
step
back
from
that
to
have
a
discussion
about
what
we
think
the
sub
projects
of
the
sig
should
be
the
most
critical
sub
projects,
of
which
conformance
is
one
of
the
proposed
of
projects.
Earlier
feedback
was
that
there
were
too
many
sub
projects.
So
with
some
discussion
we
consolidated
them
all
so
discussions
about
how
we
can
make
the
stake
more
effective
and
I
saw.
F
F
We
can
promote
those
people
who
are
actually
doing
the
work
to
be
approvers
and
we
can
also
on
board
more
reviewers.
We
have
enough
people
to
do
that,
and
I
would
like
to
do
that
for
the
other.
Similar
projects
as
well
like
kept,
has
been
a
project
for
some
time
and
Jase
probably
knows
this.
David
bet
better
than
I
do,
but
you
know,
features
was
moved
to
enhancements.
There's
work
on
a
way
to
move
the
caps
to
that
repo,
we're
talking
about
deprecating
the
legacy
proposals
process
than
just
fully
moving
the
cap.
F
But
you
know
we
need
people
actually
working
on
the
process
itself
to
move
it
over
the
finish
line.
The
other
two
sub
proposed
sub
projects,
so
that's
just
four
sub
projects
for
means
of
projects.
The
other
two
are
API
in
architectural
governance
we
have
a
set
of
API
approvers,
which
has
been
acted
for
some
time
and
again.
F
You
know
and
there's
one
topic
related
to
that
as
an
agenda
item
today
about
including
things
like
VIN
during
multiple
repos
feature
branches
staging
and
so
on,
figuring
out
how
what
direction
we
should
move
with
respect
to
our
code
organization
overall
and
making
that
happen.
That
is
definitely
an
area.
I
would
include
generating
code
in
that,
by
the
way,
that's
definitely
an
area
where
we
need
a
more
concerted
effort
by
people
interested
in
moving
that,
for
that's,
probably
the
most
understaffed
of
all
the
sub
projects
at
the
moment.
F
So
those
are
the
four
proposed
sub
projects
and
I
suggest
with
respect
to
the
Charter.
We
actually
just
start
with
focusing
on
two
sub
projects
and
the
basic
minimal
charter.
You
know
that
this
is
a
group
that
needs
to
address
cross-cutting
issues
across
the
project
and
actually
needs
to
get
stuff
done,
and
so
once
we
feel
those
sub
projects
are
moving
along.
Well,
then,
we
can
potentially
expand
to
other
activities,
but
I
would
propose
we
at
least
start
with
those
critical
sub
projects.
H
What
one
thing
that
has
occurred
to
me
is:
if
you're
looking
for
people
to
work
on
those
sub
projects
you're
competing
with
with
like
people
who
can
work
on
that,
can
also
run
or
lead
or
TL
or
care,
or
whatever
other
SIG's.
So
there's
a
limited
pool
of
people
they
can
taken
like
I'm
thinking
just
of
like
the
code
organization,
one
there's
only
so
many
people
that
can
have
meaningful
contributions
to
that.
I
I
think
there's
there's
a
lot
of
people
who
can
do
the
cat
wrangling
work
like
Erin
and
I
can
easily
pull
double
duty
on
that
aspect.
I
think
what's
a
problem
is
we
need
to
make
sure
that
we
have
a
clearly
defined
set
of
execution
items
that
we
can
solicit
the
community
from
to
make
sure
that
they
can
be
unblocked
to
be
able
to
execute
freely
and
also
get
those
parties
who
seem
to
talk
a
lot
about
this
topic
to
actually
be
able
to
commit
to
resourcing
some
of
the
execution
items
around
them?.
A
E
You
know
cut
through
some
of
the
indecision
on
this
stuff
and
actually
get
stuff
done,
and
you
know
and
I
think
you
know
that's
that's
kind
of
what
we
need
here
and
I
think
I
think
I'm,
hoping
that
once
we
get
some
of
these
processes
in
place,
we
can
actually
enable
more
people
to
step
up
in
more
ways.
I've
been
disappointing.
My
own
ability
to
devote
time
to
this
yeah.
A
I
had
a
percent
agree
I.
This
is
something
I've,
just
as
I've
seen
these
things
roll
out
over
and
over
again
that
having
a
documented
process
with
things
like
mentorship
and
advancement
to
reviewer
approver
having
those
preached
a
project
is
hugely
valuable
and
it
gives
people
an
idea
about
what
the
bar
is
to
succeed
and
to
move
forward.
I
also
feel
like
symmetric
donors
need
to
be
more
like
project
managers,
sometimes
and
really
staff
out
these
things,
as
opposed
to
being
the
person
that
does
all
the
work.
A
So
you
know
the
release
team,
classic
example
to
release
lead
I
used
to
do
all
the
work.
That
was
the
release
star
and
it
became
the
release
team
that
was
led
by
that
person.
It's
much
more
effective,
so
I
would
love
to
see
these
sub
projects
run
more
like
that
with
roles
they
get
staffed
and
those
staff.
You
know
those
roles
can
change
over
time
involved,
but
we
definitely
can.
We
can
not
be
relying
on
individual
heroics,
I'm
mister
we're
gonna,
fail,
yeah.
F
So
I
think,
with
respect
to
cutting
through
indecision
I,
don't
think
we're
paralyzed
by
indecision
on
at
least
three
out
of
four
of
the
sub
projects.
Api
governance
conformance
and
kept
I
think
there
are
very
concrete
things
that
could
be
done
to
push
those
over
the
finish
line.
We
could
ask
host
some
rolls
to
the
roll
board
to
say:
look
we're
looking
for
people
to
help
drive
these
things.
And/Or
help
do
some
of
the
lifting
you
know,
I.
F
J
H
F
I
want
to
do
a
time
check,
so
those
are
the
four
main
proposed
sub
projects
right
now.
The
sub
projects
listed
in
six
diamo
are
a
bit
of
a
grab
bag
of
stuff
that
no
other
sig
wanted,
but
I
think
these
are
the
actual
important
things
that
we
need
to
make
progress
on
for
this
sig
right
now
and,
like
I
said,
we
can
potentially
expand
to
other
things
later.
F
If
we
actually
do
feel
the
keys
are
in
good
shape,
but
this
seems
like
a
good
core
body
of
work,
so
the
other
issue
that
kind
of
came
up
in
the
Charter
discussion
or
one
of
one
of
the
other
main
things
that
I
think
needs
to
get
resolved
is
another
chair.
You
know.
Obviously
the
main
issue
we
have
with
the
chairs
right
now
is
that
with
only
two,
if
I
go
on
vacation
and
something
Prabhas,
it's.
F
We're
kind
of
left
without
people
to
drive
the
meeting,
so
what
I
would
love
to
see?
Is
someone
actually
step
up
and
help
with
some
of
the
organizational
work
of
the
sig
and,
like
many
other
roles
on
the
project,
you
know
people
who
are
already
doing
the
work
in
our
doing
a
good
job
were
more
than
happy
to
just
anoint
them
to
be
a
chair.
So
if
someone
does
actually
want
to
help
we'd
be
more
than
happy.
F
I
did
some
agenda
wrangling
this
morning
and
went
and
looked
through
the
tracking
boards
and
looked
through
open
issues,
tab,
API
change
or
open
jars
tag.
Api
changes
things
like
that
next
week,
I
want
to
do
a
review
of
what's
going
into
113
with
the
enhancement
spreadsheet
and
the
and
a
half
the
the
issues
flag
and
the
enhancements
repo
and
some
yield
and
DRS
and
such.
F
E
F
E
So
I'm
I'm
happy
right
now
to
get
involved
in
terms
of
like
so
that
we
don't
cancel
meetings
when
when
you
know
we
keep
things
moving,
I'm
post
cube,
con
I'm
gonna
have
more
time
and
more
freedom
to
do
this
stuff,
but
if
other
folks
want
to
want
to
get
involved
too
I,
you
know
I'm,
not
gonna,
try
and
lick
a
cookie
here
that
I
can't
eat.
Do
you
think
it
would
be
good,
though,
to
actually
have
you
know?
E
F
It
also
doesn't
need
to
be
the
same
person
every
week.
If
it's
not
going
to
be
a
church.
There's
some
other
participant.
We
can
say:
hey,
there's
nothing
on
the
agenda.
Does
someone
want
to
step
up
and
try
to
populate
the
agenda?
We
could
be
more
proactive
about
announcing
that
you
know
I
do
check
the
agenda
a
day
or
two
ahead
of
time
if
I'm
around
and
shockingly
I
did
actually
take
some
time
off
recently
but
yeah.
You
know
for
folks
who
are
interested
in
cig
architecture.
F
I
would
like
to
see
more
discussion
on
the
mailing
list.
You
know
we
have
a
couple
of
issues
that
got
put
in
the
agenda
today.
That
I
would
like
to
punt
a
mailing
list
just
as
an
example.
So
we
could
start.
You
know
pre
announcing
agendas
via
the
mailing
list.
If
we
can
get
agenda
and
place
more
than
24
hours
at
a
time,
and
that
would
surface
you
know,
potential
meeting,
cancellations
and
gaps,
and
things
like
that,
I.
E
F
That's
a
that's
a
fair
point,
I
mean
certainly
for
specific
questions.
We
can
try
to
make
a
goal
of
time
boxing
for
a
week
or
something
like
that.
You
know
like.
If
it
doesn't
get
resolved
on
the
mailing
list,
then
it
gets
added
to
the
meeting
agenda.
It
has
some
policy
like
that.
I
think
some
of
the
like
the
two
things
that
I
recommended
punting
to
the
mailing
list
seem
like
very
specific
technical
issues
that
should
be
resolvable.
E
A
E
I
think
some
of
this
is
boiling
down
these
sort
of
amorphis
questions
into
concrete
things
that
can
be
answered
or
proposals
that
can
be
approved
and
starting
to
move
it
from
sort
of
a
we're
talking
about
everything
to
we're
actually
talking
about
this,
that's
the
thing
that
we
need
I.
Think
in
my
mind,
get
better
at
yeah.
A
F
Yeah,
my
main
suggestion
for
that
is
that
we
defer
that
question.
You
know
if
we
think
in
terms
of
the
sub
projects,
there
are
clear
rules
for
participants,
reviewers,
approvers
and
owners
of
the
some
projects
are,
as
we
moved
folks
up
the
ladder.
If
we
can
actually
be
like
I
said
get
people
to
actually
help
do
the
work,
then
it
would
be
really
clear
what
their
status
and
authority
and
responsibilities
are
and
numbers
at
large.
You
know
I
think
for
the
people
who
attend
this
meeting.
F
If
we
can
get
the
API
review
process
going
and
that's
under
the
API
governance
sub
project,
then
you
know
we
can
get
a
broader
set
of
input
from
folks
across
multiple
states
in
the
project,
but
you
know
other
than
in
their
formal,
like
reviewer
approval
approval
approver
rolls
through
the
cap
process
or
through
the
API
review
process.
I
think
it
would
just
be
considered
input
more
or
less,
and
you
know
I
think
people
have
been
mostly
pretty
good
about
responding
to
input
from
various
people
on
the
project.
F
You
know,
as
per
the
mailing
list,
especially
we
do
need
to
get
better
at
actually
coming
to
a
decision,
though,
and
that's
one
thing
I
was
hoping
kept
would
to
help
us
do
is
make
it
clear
who
could
actually
approve
the
cap,
so
we
could
make
a
decision,
because
in
the
past,
with
the
proposal
process,
discussion
went
on
and
on
and
the
work
you
know,
people
just
gave
up
on
their
proposal.
They
went
and
wrote
the
code
and
it
got
merged
and
the
proposal
just
languished
so.
J
Tinnitus
topic
for
just
a
second
yeah
I
added
today.
Sorry,
an
agenda
item
which
was
to
three
propose
that
we
spend
time
in
this
group
every
week
or
every
other
week
to
scan
caps.
It
might
be
that
the
useful
thing
to
do
is
to
spend
say
10
minutes
a
week,
scan
the
current
caps
from
this
week
and
making
sure
that
we
agree
with
assignees
and
reviewers
can
we
is.
G
J
F
A
A
E
Some
of
its
automation,
but
some
of
its
authority
look
if
somebody
can
say
hey
this
cap
seems
like
it's
not
a
cross-cutting
cap,
you
do
it
do
this
or
this
cap,
I'm
gonna,
throw
it
back
to
you
like
you
know,
make
sure
that
so-and-so
is
ready
to
sign
off
on
it.
I
mean
like,
like
I,
feel
like
if
we
have
an
editor
that
feels
like
they
can
really
drive
this,
we
could
make
this
more
efficient,
I
think
there's
a
certain
amount
of
like
everybody's
kind
of
like
tiptoeing
around
on
stuff.
Well,.
F
Just
I
was
just
with
respect
to
automation.
I
was
just
saying
surfacing.
What
all
the
caps
are
is
the
thing
that
would
benefit
from
automation,
even
if
all
the
caps
moved
to
their
own
repo
they're.
Still,
some
caps
are
in
flight
and
key
are
some
caps
are
merged,
but
in
a
provisional
state
it's
just
hard
to
know
which
caps
are
actually
moving.
G
F
I
would
actually
like
to
punt
this
topic
to
next
week,
because
next
week,
I
do
want
to
look
through
over
all
of
the
proposed
1.13
features
and
I
also
wanted
to
see
if
that
matched
the
caps
and
the
API
reviews
that
were
in
progress.
So
that's
already
in
the
agenda.
It's
grayed
out,
because
people
were
getting
confused
by
populating
the
agenda
for
next
week's
orally.
But
that's
in
the
agenda
for
next
week
already
yeah
I
mean.
E
Just
real
quick
Eric,
the
way
that
I
see
it
is
that
the
caps
can
be
essentially,
you
know,
are
going
to
have
a
are
going
to
essentially
be
the
agenda
for
this
group
in
terms
of
things
that
we're
going
to
want
to
look
at
that
we're
going
to
want
to
surface
and
that
folks
are
going
to
focus
on
reading,
and
we
need
somebody
to
curate
and
manage
that
list,
because
that's
essentially
in
some
ways
managing
the
agenda.
This
group.
A
B
A
B
So
this
was
basically
was
it.
Last
week
we
were
talking
about
go
packages
and
external
use.
It
was
Tim
who
said
no
yeah
said
that
you
know
our
packages
really
in
kubernetes
kubernetes
shouldn't
be
used
externally,
even
if
the
go
API
is
designed
to
be
that
way
and
with
our
minor
changes,
we're
always
we're
always
breaking
go
api
compatibility
which
doesn't
work
with
mirco
modules
is
going
and
I
can't
remember.
Who
else
said
it
said
you
know,
as
we
move
these
things
out,
we're
gonna
be
the
consumers
of
our
own
stuff.
B
So
if
we're
always
breaking
things,
it
will
just
be
the
community.
That's
experiencing
these
pain
points
will
be
experiencing
these
same
pain
points
because
we'll
be
users
of
this
stuff,
and
so,
rather
than
get
to
do
that
conversation
last
week
it
was
more
of
okay.
How
do
we
go
about
doing
things
with
our
go
packages
so
that
they
were?
J
B
To
be
the
person
to
make
sure
if
I
carried
from
last
week
to
this
week
did
not
sign
up
for
more
you're,
not
gonna
catch
me
on
that.
Well,
what
what
should
we
do
as
a
next
step?
I
guess
is
the
question
that
I
would
ask,
because
I
don't
want
it
to
drop
again,
because
this
has
come
up
more
than
once
and
as
long
as
we've
got
next
steps
to
continue
to
carry
this,
and
maybe
people
signed
up
to
do
them.
We
can
at
least
take
it
the
next
step.
B
H
Be
a
bad
idea:
I
yeah.
Actually,
that
would
be
a
great
idea.
Yeah
III
think
we
should
accept
that
there's
not
going
to
be
a
instant
answer
here.
We've
got
a
lot
of
code
and,
as
we
make
it
more
accessible,
we
can't
break
the
existing
internal
usages
of
it
either.
So
this
isn't
the
sort
of
thing
where
you
can
flip
a
switch
and
it'll.
F
All
be
better
wait,
so
you
had
a
noble
proposal
about
where
the
steps
be
on
staging
yeah,
and
that
seems
very
relevant
to
this,
because
what
we
have
been
doing
is
moving
code
to
staging
and
we
want
to
copy
out
and
to
other
repos
to
be
consumed
and
other
repos.
But
we
are
still
directly
using
the
things
from
staging
within.
So
ever.
H
Basically,
because
people
didn't
see
the
light
at
the
end
of
the
tunnel,
people
saw
that
we
would,
we
would
be
we'd,
have
all
these
repos
and
if
you
wanted
to
give
it
anything
done,
you'd
have
to
make
a
change
in
a
repo
and
and
entered
into
the
Lin
drip
back
into
the
main
repo
right
and
like
there
was
concerns
about
testing.
Like
will
this
other
thing
work
with
this
thing,
so
I
think
I.
H
H
H
Things
and
run
tests
yeah,
so
that
would
that
was
my
that
was
my
take
in
that
document.
Initially
is
like
like.
We
should
just
have
a
bot
that,
like
there's,
there's
a
file
and
the
bot
like
automatically
vendors
and
assembles
I
still
think
that's
probably
doable,
but
it
didn't
catch
on
the
idea
to
catch
on,
for
whatever
reason.
H
H
H
The
feature
branch
we're
still
like-
we
still
got
a
little
inside
sorry,
I
must've,
missed
that
we're
still
twiddling
a
bunch
of
bits
and
we're
changing,
api's
and
doing
all
sorts
of
stuff.
So
the
feature
branch
is
still
necessary,
but
the
business
logic
doesn't
need
to
go
in
repo
because
it's
pretty
separable
okay,
tim
says
yeah.
C
A
couple
of
things,
so
the
bot
proposed
updates
for
external
repositories,
will
be
immensely
useful
even
for
the
the
things
that
we
have
mended
already,
so
we
can
start
I,
get
the
automation
working
and
then
we
will
be
able
to
turn
it
on
for
the
repositories.
You
know
that
we
break
out
of
staging
also.
So
it's
going
to
be
the
same
thing.
C
Look
at
the
external
repository,
merge
it
run
the
test
and
then
propose
a
bat
so
going
to
be
the
same
process
for
whether
it
is
a
vendor
repository
or
things
that
will
break
out
of
staging
right.
So
that
was
one
part
to
the
other
part
is
right
now
we,
this
question
also
leads
to
the
next
agenda
on
the
item
on
the
topic
where,
if
we
have
things
stuck
in
staging
perpetually,
we
won't
be
able
to
rewind
or
things
back
that
depend
on
things
and
staging.
H
C
The
problem
Daniel
is
that
we
have
to
support
the
v1
API.
For
example,
cinder
api
has
to
be
supported,
and
if
we
are,
if,
if
we
break
everything
apart
into
staging
repositories
and
then
put
that
code
and
and
write
another
code
in
another
repository
that
depends
on
the
staging
repository,
we
still
need
to
find
a
way
to
support
the
v1
cinder
API,
and
for
that
we
would
have
to
Reeve
enter
some
bits
of
it
back
in
to
the
KK
repository
and
that's
where
the
problem
is.
If.
C
Not
right
so
there
is
good
I
mean
I,
don't
see
a
way
out
other
than
having
a
cycle
or
having
a
completely
external
thing
that
saw
this
proposed.
Sod
and
other
people
have
proposed
I
put
a
link
to
that
too.
So,
but
the
problem
is
the
other
one
that
is
on
the
the
other.
For
the
external
controller.
That
delegates
to
CSI
is
that
it's
gonna
take
a
really
long
time
and
I.
C
C
F
C
F
F
H
Notable
voices
home
said
no,
no,
no,
let's
not
do
that
yeah.
We
never
reached
consensus
on
that,
which
is
why
we've
remained
in
this
state
but
I
I
guess
maybe
I
need
to
go.
Look
at
that.
Pr
work
carefully.
I
didn't
understand
why
it's
not
sufficient
to
rely
on
the
external,
because
we
publish
everything
and
staging
to
external
places.
So
right.
K
It
is
one
more
that
the
code
that
currently
supports
this
under
API
lives
in
tree,
and
so
while
we
are
straddling
the
divide
of
having
it
available
to
run
externally,
but
unless
we
on
a
release
boundary
say
you
know
what
cinder
isn't
supported
in
tree
anymore.
If
you
want
to
support,
you
have
to
run
this
external
controller
or
external
provider
on
that
boundary,
you
still
need
the
logic
entry
and
we're
trying
to
enable
running
it
independently,
yeah.
C
B
A
I
mean,
if
we're
talking
about
staging
and
we
want
to
deal
with
something-
that's
the
hard,
complicated
bits
which
is
what
we're
probably
getting
hung
up
on.
Look
at
client,
Co,
API,
an
API
machinery
and
what
our
development
workflows
would
be
like
if
the
authoritative
source
moved
out
of
tree
rather
than
being
in
tree
and
if
we
can
solve
for
those
cases,
I
I'm,
hoping
that
gets
us
90%
of
the
way
there.
H
G
E
E
H
H
In
it,
the
other
one
that
consists
of
all
the
generated
stuff
yeah,
that
one
would
depend
on
the
API
I
think
that
we
have
to
make
that
split,
because
we
want
people
who
are
providing
their
own
API
is
to
be
able
to
follow
the
client
go
model
to
produce,
to
offer
people,
clients
and
right
now.
Client
go
is
a
mix
of
things
that
are
per
API
and
things
that
are
universal
for
any
kubernetes
style
API.
H
C
I
talked
to
la
Vella,
but
in
general
it's
not
just
cinder.
It's
the
entire
external
product
stuff
is
hinged
on
the
fact
that
you
have
to
support
the
entry
volumes
and
we
need
a
good
solution
for
that,
and
this
might
help
there,
but
worst
case
we
have
to
stuff
that
other
proposal
that
Assad
has
mentioned
here
so
I
want
to
make
sure
that
people
actually
look
at
that
alternate
proposal.
C
C
K
C
A
Looks
like
we
have
hit
the
things
in
the
agenda.
This
there's
a
play
saloon
agenda
about
taking
this
on
the
mailing
list.
So
hopefully
the
owner
of
that
item
will
do
that
and
we
cannot.
F
A
A
C
Do
it
fix
it
I,
don't
care
how
I'm
ready
and
you
know
I
need
to
sign
off,
and
then
we
are
done.
No,
not
really
so.
The
first
problem
here
is
that
there
are
problems
in
the
G
log
itself
that
needs
to
be
fixed
so
that
you
know
the
simple
example
was
from
Tim
all
clear
where
he
wanted
everything
to
go
into
a
single
file,
and
we
don't
have
that
support.
So
we
have
to
fix
G
log.
C
So
to
do
that,
we
have
to
extract
G
log
into
third-party
directory,
fix
some
of
our
shell
scripts
to
be
able
to
support.
You
know
pulling
the
code
for
in
from
there,
so
the
good
news
there
is
G
log
has
never
had
an
update
for
a
really
long
time.
So
we
are
not
going
to
have
a
problem
trying
to
sync
things
into
the
third
party
anyway,
because
it's
stopped
completely.
So
that's
the
second
apart
then.
The
third
part
is
the
people
want
to
be
used.
C
So
we
can't
have
two
separate
logging
systems
active
at
the
same
time,
even
if
it
is
like
two
instances
of
G
log
living
in
different
packages,
because
you
know
we
won't
be
able
to
reconcile
the
logs,
because
some
logs
will
go
here.
Some
logs
will
go
there,
so
what
we
need
is
a
way
to
plug
in
plug
in
a
writer
into
G
logs,
so
it
can
write
to
wherever
you
want.
C
C
So
that's
why
I
structured
it
in
such
a
way
that
the
G
log
has
a
set
output
which
takes
in
a
writer
and
the
writer
essentially
writes
to
wherever
we
need
to
write
to
so,
for
example,
in
Justin's
case
he
can
use
that
writer
that
sends
that
to
tracing.
And
then,
if
you
want
to
leave
it
to
G
log,
we
can
leave
it
to
G
log.
C
If
you
want
to
write
to
standard
error
or
syslog,
we
can
leave
that
as
it
is
so
I
want
to
separate
the
top
from
the
bottom
and
the
bottom
can
be
replaceable.
You
know
command
line
options
or
whatever,
but
the
whole
idea
was.
We
should
be
able
to
layer
the
newer
API
that
Jim
wants
on
top
of
G
log
and
essentially
make
sure
the
people
who
are
writing
new
libraries
or
you
know,
even
we
can
do
a
good
first
issues.
Get
people
started
on
making
changes
to
the
KK
repository
to
use
the
new
logging
API.
C
So
that's
that's
the
end
goal.
So
so,
basically,
I
have
a
experimental.
You
know
whip
there.
It
seems
to
do
all
the
things
that
I
wanted
to
do,
but
I
need
to
break
it
up
into
things
that
we
really
want
to
do,
which
is
what
you
know,
for
example,
Tim
has
to
make
up
smile.
What
do
we
want
to
do?
Jim
and
Justin.
J
Okay,
I'll
take
the
blame
for
a
lot
of
things,
but
actually
I
guess
I
have
to
take
the
blame
for
glog
I.
Think
I
actually
did
write
that
immigration
I
think
it
dimmed.
If
I
can
summarize,
the
problem
is
there's
three
problems.
Glogg
has
some
bugs
or
shortcomings
that
cause
us
pain.
Klog
is
a
crappy
api
for
logs
and
you're,
a
crappy
implementation
for
logs
yeah,
and
and
we
can,
we
can
attack
those
three
problems
independently
and
I've
got.
We
got
two
separate
PRS
open,
one
of
which
attacks
the
glog
has
some
shortcomings.
J
We
can
work
around
those
that's
Tim.
All
éclairs
we
have
yours
which
is
glog,
is
a
crappy
implementation
of
logging
and
Hesburgh,
which
cycles
two
of
the
three,
and
we
have
the
other
proposal
that
starts
Justin
and
Sally
and
I
had
and
tossed
around
about
attacking
it
from
the
API
point
of
view
and
I.
Don't
think
doing.
Nothing
is
a
really
great
answer
at
this
point.
The
question
is
which
something
do
we
want
to
do
this.
J
Has
shortcomings
and
bugs
that
we
would
like
to
work
on
Tim
like
to
be
really
clear:
Dimon's
PR
I
looked
at
it
in
fair
detail
this
morning.
It's
not
horrible.
It
takes
the
glog
library,
which
is
not
that
big
of
a
library
forks
it
in
a
third
party
does
some
baloney
and
our
cell
scripts
to
make
it
be
findable
as
golang
glog
and
adds
a
couple
of
features
which
basically
over
right
and
all
the
other
blog
features.
J
H
C
C
L
Technically,
it
was
Eric
first,
but
I
think
it
is
important.
I
actually
want
to
go
much
further.
I
want
to
integrate
it
with
spans
in
the
sort
of
tracings
sense
of
the
word.
The
idea,
this
sort
of
rationale
being
eventually
we're
gonna,
want
to
do
something
like
open
tracing,
open
census.
Anyway.
That
requires
putting
all
these
fans
through
putting
context
information
in
there
that
they
note
to
do,
but
to
do
both
would
be
very
likely
to
duplicate
the
logging
information
and
the
tracing
information
on
that
assumption.
It
would
be
bad.
I
Tech
Merrick
and
myself
did
an
experiment
with
it
tracing.
It
does
not
work
in
a
watch
style
event.
Architecture
such
as
ours,
in
fact
it
fails
gloriously.
We
we
plumbed
it
through
api's.
Why
tick
and
I
know
the
gory
details.
We've
done
a
lot
of
work
on
it
and
we
just
ended
up
failing
if
you
could
find
a
different
method
that
allows
you
to
span
a
watch
and
I'm
well
I'm
game
of
all
years,
but
that
that
capability
is
not
a
requirement.
I
appreciate
the
invitation.
I
G
C
Excellent
question:
the
reason
is
that
see
advisor
currently
uses
G
log
right,
so
there
are
a
couple
of
more
references
to
G
log
within
our
vendors.
So
what
we
need
to
do
is
we
need
to
do.
The
third
party
here
first
make
sure
that,
with
all
our
scenarios
are
working,
fine
then
allow
the
third
party
G
log
to
be
used
by
whoever
needs
to
needs
it.
At
that
point,
we
can
choose
to
move
it
into
a
separate
repository
right
now.
C
B
I
was
gonna,
say
if
you're
still
using
something
like
go
down,
because
modules
are
GA,
it
just
flattening
and
I
haven't,
looked
at
go
modules,
but
I
would
expect
it
not
to
do
everybody's
all
dynamic
vendors,
I
haven't
looked
at
the
exact
details
of
what
a
sim
like
is
gonna.
Do
if
a
feeling,
it's
gonna
cause
issues
and
not
really
work
for
the
outside
consumers,
so
I
would
hope
we
can
come
up
with
a
better
long-term
strategy
for
this.
C
Using
that
where
we
need
it
Matt,
the
problem
with
that
is,
there
are
two
references
to
G
logs
one
from
the
main
G
log
and
one
from
ours.
The
flags
are
going
to
clash
number
one,
and
then
both
of
them
are
going
to
create
a
new
directory
for
each
one
of
those
packages
because
they
are
package
level
constructs
the
init
is
package
level,
so
both
of
them
are
going
to
create
a
new
directory
for
putting
their
own
logs.
H
With
where
we
want
this
to
eventually
end
up,
not
the
specific
implementation
details,
but
we
we
want
to
solve
the
three
problems
that
and
listed,
and
so
I
I
think
what
we're
kind
of
debating
here
is
just
what
order
do
we
want
to
tackle?
Is
in
and
like
what
is
the
the
best
way
to
get
there
so
I,
don't
think
anyone's
arguing
that,
like
forking
vlog
is
the
desired
end.
State
I.
J
Don't
think
that
you
know
I,
don't
think
it's
the
desired
end
state,
because
I
think
in
the
end
glogs
a
crappy
log
library
to
start
with.
So
we
can
replace
clogged
with
a
better
logging
library
if
we
can
insulate
our
users
from
the
fact
that
it's
using
vlog,
which
today
has
propagated
out
into
things
like
see,
adviser
and
has
propagated
out
into
clients
via
client,
go
I
mean
to.
H
F
C
Want
to
say
one
thing
before
we
wrap
up
that
doesn't
work
just
for
King.
Does
it
work
because
we'll
have
two
copies
of
G
log,
one
from
the
main
G
log
and
one
is
ours
and
if
both
cannot
go
into
yeah
yeah
I'm
claiming
the
same
this
thing,
so
the
the
thing
is
yes,
we
have
an
end
goal.
What
we
should
say
is
we
need
an
end
goal
where
we
have
an
external
external.