►
From YouTube: Kubernetes SIG Cluster Lifecycle 20180123
Description
Meeting Notes: https://docs.google.com/document/d/1deJYPIF4LmhGjDVaqrswErIrV7mtwJgovtLnPCDxP7U/edit#heading=h.guuszpv89vya
Highlights:
- Reviewed the pull request backlog for kubeadm
- Discussed UX workflow for multi-master clusters
- SIG survey
- KubeCon sessions
- First KEP for cluster lifecycle
A
B
I
burned
through
some
of
the
PR
backlog
and
I
was
looking
at
a
bunch
of
changes
that
were
both
in
flight
as
well.
As
you
know,
some
other
changes
that
were
happening
on
the
cig,
API
machinery
front.
One
of
the
questions
I
had
but
regards
to
this
was
that
we
had
enabled
a
bunch
of
initializer
code
and
that's
kind
of
been
it's
still
alpha
and
I
think
it's
meant
to
be
deprecated
in
favor
of
mutating
webhooks
and
we
have
not
provided
I
know
we
have
enabled
now.
B
B
Yeah
there
was
refactoring
on
command
line
arguments
and
what
has
a
tendency
happened?
I,
don't
know
how
exactly
Lucas
was
tracking
this
type
of
stuff,
but
as
the
API
server
API
machinery
changes
it's
hard,
it
will
directly
impact
our
deployment
and
I
just
kind
of
lucked
out
that
I
was
able
to
see
some
of
this
stuff
fly
by,
but
the
order
of
argument
changes
and
not
percolated
through
cube
ADM
when
the
PRS
had
come
in
so
I,
don't
know
exactly
how
we
track
and
manage
some
of
this
stuff
over
time.
A
B
It's
just
a
minor
switch
but
like
there's
a
bunch
of
little
minor
things
that
add
up
to
be
a
bunch
of
flag
changes
and
you're
gonna
have
to
go
through
a
flag
day
right,
so
we'd
rather
have
those
changes
early
and
enabled
and
updated.
So
that
way
we
don't
have
to
like
have
a
special
day
near
the
end
of
really
psycho
everything's
broken.
A
Well,
everything
shouldn't
break
right
because
I
think
the
contract
with
flags
is
you
can't
just
delete
a
flag.
You
have
to
deprecate
at
first,
give
fair
warning
at
least
notes.
So
technically
we
should
be
able
to
use
old
flags
up
through
release,
see
the
changes
in
the
release,
notes
and
catch
it
on
the
next
release
and
not
actually
break
anyone.
I
don't
know
how
tightly
people
are
holding
at
that
contract
too,
though,
that.
C
B
It
did,
and
there
were
PRS
around
this
so
like
we
before
we
were
actually
had
some
admission
controllers,
enabled
we
didn't
have
all
the
bits
properly
turned
off
like
initializers
so
and
we
ripped
those
out
because
it
was
considered
alpha
right
and
we've
replaced
it
with
the
ordering
of
enabling
mutating
web
books
and
eventually
having
that
as
as
a
means
for
you
know,
future
mutating
webhooks
for
lack
of
a
better
phrase.
Yeah.
A
I
think
and
your
point
there
Craig
is
also
right
that
it's,
even
if
you
know
for
Flags
particular
if
we
have
sort
of
a
backstop
because
they're
supposed
to
promise
compatibility,
there
are
also
sort
of
behavioral
changes
that
people
other
SIG's
are
saying.
We
want
to
do
X
during
this
next
release
and
they
you
don't
make
that
change
in
one
place,
and
it
doesn't.
You
know,
typically
always
percolate
out
to
all
the
tools
right.
We've
had
this
problem.
A
The
past
with
you
know,
keeping
cops
up
to
date
with
different
emission
controllers,
keeping
gke
up
to
date.
Keeping
you
know
the
the
cube
up
stuff
today,
like
someone
will
change
stuff
in
one
place
to
get
their
tests
to
pass,
and
people
won't
necessarily
notice
that
it
needs
to
be
changed
in
all
these
other
places
for
consistency,
and
that
is
actually
one
reason
we
were
trying
to
push
cube.
Admin
is
if
we
could
make
that
be
one
place
that
people
change
it
and
everybody
gets
that
consistency
for
free.
A
That
will
be
great
and
if
not,
people
can
at
least
see
what
Cubans
do.
We
can
follow
that
so
I
think
maybe
part
of
this
is
we
should
try
to
start,
maybe
inching
our
way
towards
having
cube
admin,
be
a
part
of
the
PR
blocker
workflow,
so
that
people
are
forced
to
change
it
to
make
their
PRS
pass
and
merge,
because
I
thought
he.
B
B
Could
really
have
as
an
action
item
for
this
meeting,
someone
to
take
that
on
to
make
that
a
blocking
PR
job,
because
I
think
we're
at
the
stage
where
it
should
be
I
mean
to
be
honest.
I'd
rather
remove
cops
as
a
blocking
PR
job
after
what
happened
yesterday
and
enable
cube
ATM,
because
it's
a
more
commonly
used
across
provider
resource
well,.
C
B
That
part
has
partially
been
fixed.
I
think
I'd
have
to
take
a
look
at
the
PR
job
with
the
Ubuntu
Basel
stuff,
but
I
don't
I'd
have
to
sum
what
I
want.
We
need
a
person
to
take
ownership
of
blocking
PR
work.
I
know
Jacob
had
done
a
lot
of
that
work
before,
but
it
you
know
it
we're
like
a
rotating
volunteer
army
and
as
I
burned
through
the
backlog.
B
So
that
that
was
probably
the
biggest
API
stuff
that
I
had
noticed,
there's
a
bunch
of
other
PRS
I
was
going
to
walk
through
to,
and
I
was
also
going
to
talk
about,
possibly
using
tomorrow
as
a
kind
of
a
Flag
Day
to
go
through
the
backlog,
because
I
can't
apply
some
of
the
changes.
I
want
to
all
the
issues
and
make
sure
we
have
a
curated
backlog
without
kind
of
buy-in
from
some
of
the
people
who
can
be
executing
on
it.
B
So
I
was
thinking
tomorrow
might
be
a
good
day
to
just
do
a
Festivus
on
some
of
the
issues
that
are
there
and
try
to
get
like
a
sane
one.
Ten
list
crude
down,
because
there's
a
bunch
of
stuff
in
the
110
milestone
in
the
Canadian
repo.
That
part
is
not
really
I,
don't
think,
can
be
accomplished.
They're
kind
of
punting
off
hunting
off
so
I'd
like
to
trim
it
down
and
have
it
priority
sorted
for
what
we
can
actually
accomplish
in
110
and
make
sure
that
aligns
with
our
GA
doc.
A
That
sounds
great
to
me.
I
think,
as
you
said,
one
of
the
struggles
that
we
sort
of
keep
coming
back
to
is
sort
of
people
rotating
in
and
out
and
not
having
sort
of
consistent
sort
of
level
effort
level
of
effort
being
applied
across
the
project,
which
makes
it
really
difficult
to
figure
out
how
far
we're
gonna
be
able
to
get
the
next
milestone.
But
if
we
can
have
the
things
sort
of
priority
sorted
to
make
sure
the
people
that
are
working
on
things
are
working
at
the
top
of
the
list.
B
That's
kind
of
that's
the
way
I
operate
and
other
folks
can
attest
to
this
is
I'm
I'm,
a
big
fan
of
priority
sorted
lists,
so
I
make
lists
furless
just
because
that
makes
it
makes
it
takes
ambiguity
out
of
the
picture
right
and
that
way
anyone
can
jump
in
at
any
moment
in
time
and
see
the
backlog.
So
that
was
kind
of
my
proposal
for
tomorrow
and
for
today,
some
of
the
issues
that
I
went
through
that
some
of
the
PRS
have
been
merged.
A
Yeah,
that
sounds
great
I,
guess
I,
don't
know
how
it
looks
like
we
have
a
relatively
short
agenda
today,
so
one
option
would
be.
We
could
do
some
of
that
today
or
we
could
just
cut
this
meeting
short
and
let
people
know
to
come
tomorrow
if
they're-
maybe
not
in
this
meeting,
but
there's
not
a
whole
lot
left
on
on
the
agenda
today.
I.
B
Think
these
ones
actually
require
clarification,
so
it
would,
it
doesn't
hurt
to
have
the
broader
groups
for
some
of
them.
The
first
one
is
like
we
added
args
for
the
cuvette
DM
to
supply
a
pass
through
until
we
actually
have
like
component
config
in
place,
and
the
comment
that
Lucas
had
made
and
Ilya
had
also
made
was
that
we
kind
of
first
class
them
as
high-level
arguments,
and
maybe
we
should
have
them
as
a
gate,
because
they're
only
our
temporary
fix
and
I
wanted
to
get
feedback
from
folks.
A
B
B
D
D
B
D
A
Yeah
I
think
it
looks
like
both
Lucas
and
maybe
Illya
also
commented
on
the
poor
request
to
have
invites
a
person
to
the
sig
for
sort
of
more
higher
bandwidth,
in-person
discussion,
which
I
think
makes
a
lot
of
sense.
I.
Think
that's
relatively
common
in
other
SIG's,
also
like
as
we've
interacted
with
them.
If
you
send
them
something,
that's
sort
of
not
clear-cut
and
something
they
definitely
want
to
accept,
they
tell
you
please
show
up
at
our
sig
meaning
and
let's
talk
about
it
and
I.
Think
it's
fine.
A
If
we
sort
of
hold
that
same
line
where,
if
somebody
wants
to
send
us
code,
we
that's
great,
we
love
to
take
code,
but
we're
not
just
gonna
take
any
code,
and
if
it's
somewhat
controversial,
we
should
definitely
talk
about
it
right.
So
I
think
that
we
should
definitely
just
gave
this
PR
on
be
able
to
have
that
in-person
discussion.
Yes,.
B
I
agree:
I
think
what
happened
here
is
LG
TM
by
others.
First
and
I
think
they
were
looking
for
approval
and
then
there
was
a
conversation
afterwards.
So
the
I
think
it
was
the
order
of
operation
that
had
occurred
and
I
didn't
really
think
about
the
broader
implications,
but
I'm
definitely
cognizant
of
that
now.
So.
A
Well
and
that's-
that's
I
think
exactly
how
the
system
is
supposed
to
work.
That's
the
reason
we
have
approvers,
because
you
can
get
anyone
to
lgt
em,
but
they
aren't
necessarily
people
that
have
to
own
that
code
going
forward
right.
So
this
is
the
system
working
properly
where
they
didn't
just
get
their
code.
Merge,
because
anybody
in
the
Oregon
GTN,
but
it
came
through
us-
we're
able
to
then
make
sure
that
we
actually
want
it.
Yep.
E
B
C
The
way
it
exists
now
is
a
good
thing,
because
passing
those
like
making
those
customizations
on
the
command
line
are
not
traceable
by
any
means
and
I.
Also
I
would
probably
echo
what
Lucas
says
here.
This
is
for
someone
look
at
the
pier,
but
no
echo.
What
Lucas
says
is
that
you
know
too
many
knobs
to
turn
on
a
command
line
is
also
not
good.
D
D
B
D
B
D
B
D
I
could
I
could
I
could
talk
to
you
in
about
that.
I
know
him
in
person,
so
I
J
see
who
did
the
other
PR
so
yeah
I
can
talk
to
him
about
it,
I
suppose
I
suppose,
maybe
for
the
tanks,
because
tanks
aren't
even
exposed
in
the
config
file
right.
So
the
the
question
of
the
API
server
flags
etc
is
something
that
they
can
override
through
the
config
file,
but
things
aren't
available
for
the
config
file.
So
if
we
could
expose
the
the
Tate's
flag
in
config
file
that
might
make
sense,
yeah.
D
B
B
Okay,
so
I
will
take
ownership
of
this
one.
Next
one
is
a
TV
update.
There
was
a
recent
set
of
PRS
that
went
through
or
issues
that
went
through
saying
that
to
please
pick
up
3
to
14
this
one's
still
pending
on
a
rebase
I,
don't
know
if
the
contributors
here
in
this
meeting
or
not,
but
if
they
can
update
the
PR
and
update
it
to
3
to
14.
That
would
be
awesome.
B
Typically,
we
don't
skip
minor
versions
because
of
the
compatibility
of
the
is
not
supported
across
minor
reversion
minor
version
bumps.
So
if
we
went
from
3
110,
which
I
think
was
the
last
version
to
3
3,
we
would
have
an
incompatibility
across
versions.
Now
we
can
always
get
there
overtime
so
long
as
we
know
what
the
errata
list
is
and
we
documents
and
let
people
know.
F
B
B
This
is
kind
of
minor
if
this
is
just
people
dumping
stuff
this
this
next
one
relates
to
blocking
jobs
and
I
know
I
had
on
voluntary
volunteer,
throwing
truck
underneath
the
bus
with
regards
to
dealing
with
tests
in
front,
but
a
question
I
have,
and
this
this
would
get
us
into
a
lot
into
a
thorny
mix.
Right
I
know:
Lucas,
ideally
wanted
a
cuvette
DM
installs
to
run
the
scale
in
density
tests,
which
are
several
thousand
node
deployments.
B
A
B
Philosophy
is
when
Google
switches
their
defaults
to
qadian
based
installs.
That's
what
I'm
happy
to
switch
this
to
just
because
that
way
you
have
somebody
on
the
Google
side
who,
like
Wojtek,
who
is
monitoring
this
stuff
or
the
other
guys
in
Poland,
would
would
notice
and
be
able
to
directly
make
modifications.
A
That
sounds
fun
to
me.
We
have
a
Kris
Rousey,
put
the
doc
together
a
little
while
back
about
things
that
are
blocking
us
from
doing
that
on
GK,
and
one
of
them
is
dynamic,
Cuba
config,
which
is
slowly
inching
its
way
forward.
So,
like
other
people,
we
are
blocked
on
dynamic,
Cuba
config,
which
I'm
puffing
is
well
aware
of
so
I
think.
Hopefully
some
of
our
roadblocks
will
start
to
fall
away.
E
E
B
Think
what
I'll
save
this
one
till
the
end
we'll
talk
about
this
one
tomorrow
to
the
audit
logging.
This
is
from
our
side,
but
we
had
also
there's
a
section
inside
of
the
agenda
Doc's.
We
don't
actually
define
a
space
to
store
audit
logs,
a
location,
the
same
path
but
I.
Think
it's
pretty
important,
especially
as
we
go
to
GA
to
be
storing
the
audit
logs
for
kubb
ATM
cluster
for
diagnostic
purposes.
B
Don't
know
if
I
know
that
people
had
a
chance
to
look
at
Apogee
me
and
I
had
looked
at
it,
and
this
is
regards
to
like
how
we
kind
of
envisioned
a
feature.
Gated
workflow
for
a
master
type
of
join
and
one
of
the
questions.
I
think
we
had,
and
here
one
of
the
major
questions
was
whether
or
not
we
were
going
to
support
the
file
based
configuration
at
all
for
a
master
join.
B
So
I'm
not
exactly
certain.
There
was,
if
you
look
at
the
logic
in
here,
it
becomes
apparent
for
how
how
there's,
there's,
if
blocks
all
around
file
version
or
file
configuration
versus
grabbing
and
getting
the
secrets
and
config
map
information.
So
if
we
have
the
config
map
on
the
cluster,
why
would
we
use
a
separate
file?
And
if
we
had
config
map
and
secrets,
why
would
we
use
a
separate
file?
Okay,.
D
Right
so
yeah
I
guess
it
seems
like
yeah,
so
so
you're,
just
each
of
the
fermentation
detail
or
pal.
How
that's
done
really
right
so
I
mean
the
the
kind
of
thing
that
I'm
thinking
of
it
would
be.
It
would
be
great
if
we
could
do
but
I
think.
Actually.
This
is
already
possible
ready.
You
can
do
multiple
masters
if
you
supply
a
bunch
of
files
ahead
of
the
time
like
the
deserts
and
such
things
you.
B
D
So
yeah
and
the
mean
like
it'll,
be
yeah.
I
haven't
quite
like
the
James
dock
yet,
but
he
it
seems
like
he.
You
know
if
he
could
generate
the
certs
in
one
place,
which
is
not
one
of
your
latest
boxes,
which
could
be
like
your
laptop
or
something.
You
check
them
in
to
get
more
sunlight
and
then
then
apply
that
yeah.
D
Be
already
possible
it
just
sort
of
the
I
guess
one
one
of
the
things
is
that
give
a
diem
only
compiles
for
Linux
and
I've
been
asked
to
be
able
to
compile
a
cube,
a
VM
assets,
utility
or
whatever
for
for
any
other
platform
that
you
do
that.
But
this
is
a
separate
use
case.
Yes,
we
just
wanna
join
musters,
then
then
yeah
that
makes
sense
to
use
the
API
like,
but
like
what
do?
We
have
that
firebase
configuration
for
I.
G
So
basically,
the
the
PR
now
can
handle
different
scenarios.
One
is
that
you,
you
are
using
self-hosting
and
you
are
keeping
certificates
in
into
secrecy.
This
is
one
scenario
and,
and
and
basically
in
that
case,
join
join.
The
secondary
master
is
quite
easy.
It's
some
art
only
in
doing
the
cupola,
bootstrap
and
painting
the
node,
and
then
the
deployer
kicks
in
and
so
on.
G
But
what
I
did
is
is
that
I
implemented
also
the
support
for
other
use
case
where,
where
you
are
not
using
self
hosting
and
or
you
are
using
self
hosting,
but
we've
served
on
the
on
the
file
system
and
I
did
these.
In
that
case,
you
are
required
to
copy
certificate
manually
and
I.
Did
this
because
there's
terminal
fever,
so
self
falls
in
with
certain
secret
is
not
a
default
model
to
deploy
hood.
B
When
I
am
burned
through,
this
I
had
the
following
thought
and
feel
free
to
poke
holes
in
it
or
just
tell
me,
I'm
wrong.
I
thought
that,
for
the
ease
of
use
scenario
for
a
high
available,
cluster
I
think
there's
a
potential
for
us
to
be
opinionated
and
explicitly
say
that,
like,
if
we're
going
to
have
a
master
join,
it
will
be
self
hosted.
Otherwise,
we
have
documented
workflows
that
the
folks
can
use
if
they
want
to
do
the
ansible
based
Swizzle
Anor,
whatever
name
pick.
B
G
You
know
I
feel,
like
I
went
to
through
the
Jimmy
document
for
a
change
and
also
tested
the
approach
before
implementing
the
PR
and
what
what
happened
is
that
the
fact
that
kuba
mean
managed
some
coffee,
mobs
and
and
and
also
grape
talks,
tokens
and
so
on?
If
you
do
like
in
the
coop
in
the
Jimmy
tutorial,
and
you
execute
code
mean
in
it
many
times,
you
have
some
side
effort,
for
instance,
you
are
carry
creating
you're
creating
many
token.
G
G
The
the
man
was
set
up.
Those
are
the
set
up
without
the
the
secret
certificate
in
secret,
so
we
can
go
on
and
say:
okay,
let's
do
the
tutorial
at
the
end,
we
have
to
be
ready
to
support
people
that
makes
error
during
the
Toria,
because
there
is
a
bunch
of
steps,
if
you,
if
you
ever
kind,
is
also
an
issue
in
the
cupid
mini
rapport
where.
G
Different
people
try
the
tool
to
create
a
different
solution
or
based
on
a
sabor
or
different
automation.
Rules
for
doing
a
che
with
could
mean-
and
there
is
a
lot
of
discussion
and
and
also
some
real
solution,
for
instance
in
for
amazona
us,
where
you
cannot
use
the
an
IP
address
for
for,
for
the
other
side
address,
and
people
in
created
many
workaround
in
so.
In
my
opinion,
we
can
simplify
the
story,
and
this
is.
B
A
bad
way,
I
think
that's
probably
fair
topic
for
broader
conversation.
I
think
we
have
several
H
a
documents
but
I
think
I.
Think
a
distillation
of
you
know
a
finalized
version
of
this
specific
users
to
set
up
user
stories
in
a
simple
like
kept
style
format
would
probably
be
really
helpful
for
other
readers
too.
So
we're
not
familiar
with
it,
because
I've
been
in
this
mix
for
a
long
time,
so
I
know
the
different
flags
but
I
my
fuse
all
so
tainted.
D
B
B
G
B
B
If
you,
if
you
lose
the
whole
cluster,
then
it's
then
you
do
need
it.
That's
the
one
user
story,
that's
not
kosher
for
this
configuration,
but
the
we
might
even
recommend
folks.
We
could
have
that
as
like
part
of
an
errata,
and
we
could
recommend
folks
if
you
want.
You
know,
disaster
recovery
or
across
given
failure
domain
to
spread
your
masters
across
that
failure
domain,
which
which
varies
based
upon
provider
and
stuff.
G
A
Yeah
Tim
I
feel
like
I'm
leaning
towards
what
Fabrizio
is
saying
here,
because
I
think
you
know
sort
of
conflicting
advice.
One
is
you
should
keep
your
clusters
in
inside
of
a
failure
domain
and
have
locality
and
have
sort
of
different
clusters
in
different
flavor
domains
and
what
you're
saying
is
sort
of
the
opposite
of,
like
you
should
take
your
cluster
control
plane
and
spread
it
out
across
failure,
domains
well,
I'm,
sick,
I'm,.
B
B
But
it's
it's
all
about
constraint
management,
because
if
we
get
to
the
point
where
we
want
to
force
checkpointing
secrets,
then
we
have
to.
We
have
to
just
drive
that
home
as
a
resolution,
then,
as
for
this
state
space,
but
I
was
kind
of
trying
to
purposely
avoid
that
in
favor.
For
some
of
the
other
conversations
we've
had
with
regards
to
the
possibility
of
using
daemon
sets
for
upgrades
as
a
clean
solution
that
gets
us
out
of
the
conundrum
of
trying
to
manage
all
the
checkpointing
in
the
kublai
yeah.
A
I
agree:
I,
just
I'm,
not
sure
that
you're,
depending
on
who
you're
talking
to
if
you're
gonna,
be
able
to
convince
them
that
there
is
any
failure
domain
they
can
spread
across
where
they
wouldn't
be
able
to
turn
all
their
machines
off
at
the
same
time
and
come
back
I.
Think
for
some
people
it's
gonna
be
a
hard
requirement
and
maybe
something
like
arc
is
sufficient
to
solve
that.
But
you
need
to
be
able
to
sort
of
restart
your
cluster
if
you
turned
everything
off.
Yes,.
B
And
arc
is
one
possible
solution
that
we
propose
and
there's
other
other
things
for
data
center
style.
Failure
that
you
could
use
you
could,
you
know,
have
a
rectification,
controller
that
basically
blasts
out
with
cluster
API.
Whatever
tooling
did
you
where
you
have
so
all
of
your
state.
Four
clusters
is
always
a
good
ops
type
of
thing,
which
is
what
a
lot
of
people
do.
Yeah.
E
F
E
B
Those
are
all
the
major
issues
I
had
I
think
if
there
is
comments
once
the
cap
is
up,
I
think
netting
them.
There
would
probably
be
a
really
good
idea
for
other
folks
to
chime
in
we'd,
probably
want
to
let
that
percolate
to
get
more
feedback
and
probably
spread
the
gospel
we're
possible
outside
of
that
I
sent
links
to
folks
on
the
cluster
life
cycle
channel.
D
No
I've
not
booked
through
any
of
the
new
PRS
that
you
might
have
pointed
out,
but
the
the
one
thing
I
did
this
week
is
cleared
out
my
inbox
from
all
the
stale,
Coburn's
SPR.
Any
few
threads
so
should
be
able
to
get
back
on
track
with.
Was
they
be
the
new
stuff
right
and
because
I
had
like
too
much
stuff
in
my
inbox,
it
wasn't
trackable,
so
I
should
be
able
to
start
reviewing.
You
there's
Jordan.
D
B
B
So
that's
the
issue
backlog
and
not.
This
is
not
definitive.
This
is
the
query
that
Lucas
typically
used
for
managing
the
issue.
Backlog
of
things
that
went
through
the
main
repository
I
had
already
gone
through
Lucas's
back
along
the
PRS,
as
well
as
the
PR
list
that
specified
cuvee,
TN
and
I've
dealt
with
most
of
those
but
I'm
still.
B
What
I'd
like
to
do
tomorrow
is
go
through
the
actual
kuba
TM
repo
with
a
smaller
group
and
get
a
priority
sorted
list
of
what
we
wish
to
accomplish
in
110
and
try
to
make
that
resemble
reality.
That's
my
goal
for
tomorrow,
so
I
hope
to
come
to
that
harmed
with
some
of
the
distillation
I
have
so
far.
A
The
other
follow-up
from
last
week
is
the
sending
out
a
survey
for
cubeb
nga,
so
we
can
get
some
feedback
from
users
and
a
community
and
people
outside
of
our
sig
in
terms
of
what
they
think
should
be
blocking
ta.
So
we
can
maybe
not
take
that
as
gospel,
but
take
it
into
account
as
we
decide
what
we
think
GA
is.
We
still
don't
have
a
volunteer
to
drive
that
I,
don't
know
if
you've
seen
people
who
haven't
seen
it.
A
The
next
agenda
item
is
that
Phil
would
truck,
announced
the
meeting
last
Thursday
and
sent
out
an
email
also
with
a
survey
about
SIG's
and
how
SIG's
are
operating.
This
is
from
the
steering
committee
as
they're,
trying
to
figure
out
the
sig
structure
and
say
governance
and
I.
You
know
based
on
looking
at
that
survey.
It
probably
would
not
take
someone
very
long
to
create
a
Google
survey
and
send
it
out
for
kube
nga,
so
someone's
looking
at
looking
for
something
that's
sort
of
relatively
small
amount
of
time.
A
A
A
So
next
Dan
Cohen
from
CN
CF,
sent
out
an
email
a
couple
of
days
ago
about
cig
sessions
for
Q
con
EU
in
Copenhagen,
and
so,
if
you
guys
recall
what
we
did
for
the
North
American
cube
con
in
austin
was
that
we
did
an
intro
for
our
sake
and
lucas,
and
I
gave
like
a
35
minute
talk
to
an
overflowing
room.
We
did
not
sign
up
for
a
deep
dive,
which
I
think
was
probably
a
mistake,
and
so
I'm
kind
of
curious.
A
If
anyone
has
comments
or
suggestions
about
whether
we
should
do
both
whether
we
should
do
just
a
deep
dive
this
time
or
whether
we
should
stick
with
just
doing
an
intro,
if
you
guys
haven't,
read
Dan's
email.
The
point
of
this
is
basically
cube.
Con
is
a
great
place
to
find
new
people
to
join
sings.
A
Your
sig
intro
should
be
basically
an
introduction
to
your
saying,
maybe
a
quick
demo,
just
to
sort
of
talk
about
what
happens
and
what
people
are
working
on
in
the
sig
to
try
and
attract
people
to
help
join
you,
but
also
to
sort
of
inform
people
about
your
sake
as
they're.
Trying
to
sort
of
navigate
the
complexities
of
the
Cure's
community
in
the
humanities
project
if
they
at
least
understand
which
they
need
to
go
talk
to
you.
You
know,
that's
definitely
a
big
help.
A
Also
the
deep
dive
is
designed
to
be
much
more
of
sort
of
a
hands-on.
You
know
engineering
or
design
discussion
session.
It's
not
meant
to
be
a
presentation.
They
do
give
you
a
room
for
a
deep
dive
and
record
it,
which
is
different
than
the
intro
I.
Think
that's
strange.
It
feels
to
me
like
it's
backwards
like
it
doesn't
seem
as
worthwhile
to
me
just
to
record
somebody
drawing
on
a
whiteboard
and
doing
a
design
discussion
as
it
does
for
here's.
What
our
sake
does
please
come
join
us.
A
That
seems
like
it
actually
be
more
valuable
to
record
so
I'm
gonna
see
if
I
can
maybe
give
Dan
some
feedback
and
try
to
switch
those
around
or
at
least
also
record.
The
intros,
like
I,
said
I
think
we
were
maybe
remiss
not
to
do
a
deep
dive
last
time,
given
sort
of
the
amount
of
interests
and
the
things
that
we
were
presenting
in
other
sessions
and
I'm
curious.
If
people
have
comments
about
what
they
want
to
do.
A
Dan
also
mentioned
that
there
are
they're
giving
away
sort
of
speaker
tickets
for
up
to
two
people
to
lead
these
at
Q
come
and
so
I
also
wanted
to
throw
it
out
there
since
Lucas
I.
Did
it
last
time,
I'm,
I'm,
happy
to
say,
I
have
to
do
it
again.
If
somebody
else
wants
to
step
up
and
leave
these
I'm
happy
to
do
it
with
someone
or
let
someone
else
take
the
take
the
leader.
D
C
F
A
Well,
I
think
you
know
some
of
those
things
we
we
try
to
submit
separate
talks
for
like
it
in
Austin,
Lucas
gave
a
talk
about
Q
Batman,
which
was
more
of
a
deep
dive
on
that
topic,
and
we
were
trying
to
keep
the
sort
of
the
city
overview
to
be
more
high-level.
Like
you
know,
I
basically
presented
what
you'd
set
out
as
our
Charter
for
our
Sagan
said.
A
Here
are
the
big
big
things
that
our
cig
works
on
and
here's
what
we're
doing
and
then
Lucas
did
a
little
bit
of
talk
about
cube
admin
as
sort
of
one
of
the
projects
that
trying
to
accomplish
those
goals
and
I
think
that's
kind
of
where
we
want
to
keep
the
overview
as
not
like
the
overview
is
about
cube
admin
right.
The
overview
is
about
our
sig
and
what
are
saved
as
as
a
whole
and
cube
admin
is
one
of
the
sub
projects.
F
A
So
I
definitely
think
that
the
intro
should
I
mean
it
should
be
exactly
the
same,
but
it
should
have
sort
of
the
same
focus
of
I
assume
your
audience
knows
nothing
about
what
we
do.
Try
to
give
like
what
here's,
what
our
mission
is?
Here's,
what
we're
trying
to
work
on
and
and
maybe
sort
of
add
some
demo
to
that,
because
we
definitely
didn't
do
it
demo
last
time,
although
if
they
only
give
us
30
minutes,
then
there's
maybe
not
a
lot
of
time
for
demo.
A
What
we've
done
at
previous,
you
know
gatherings
where
we
were
able
to
sit
down
and
like
actually
tried
to
design
things
and
work
through
some
problems
where
we
have
a
room
set
aside
and
people
can
come,
join
us
in
that
or
or
sort
of
observe
if
they
aren't
part
of
the
sig
and
I
think
that
would
have
been
really
valuable
in
Cuba
con
Austin.
If
we'd
had
that
room
set
aside
and
that
time
where
people
would
all
show
up
yeah
we've
kind
of
tried
to
do
that.
That's
off
the
bar!
C
Was
really
helpful
in
in
Berlin
was
the
actual
full
day
breakout
I,
don't
know
how
feasible
it
is,
but
I
know
there
was
talk
about
last
time.
We
didn't
have
a
room
and
whatnot
and
just
kind
of
fell
by
the
wayside,
but
that
might
be
pretty
helpful
like
much
like
am
I
going
to
taco
bars
like
that
it
thinks
sitting
down,
might
be
helpful
with
a
whiteboard.
B
B
A
B
A
D
A
And
I
think
that's
one
advantage
of
the
the
deep
dives
is
a
that
it's
during
the
conference,
so
people
that
aren't
necessarily
gonna
be
in
Copenhagen
for
extra
days
on
either
end
will
can
be
there
for
the
deep
dive
and
be
they'll.
Give
us
a
room
right.
I'll
give
us
the
room
and
a
whiteboard
as
part
of
the
deal.
So
it
sounds
like
I
guess:
I'll
respond
to
Dan
and
tell
them
that
we
want
to
do
both
sessions.
I
A
A
A
It
was
a
Google
Doc
that
Jacob
had
written
up,
I
recast
it
as
a
cap
since
it
off
and
had
Joe
review
that
it
still
needs
some
work
like
this
is
definitely
a
sort
of
a
rough
first
draft,
but
it
does
sort
of
create
a
place
where
we
can
stick
other
caps.
I
know
that
we
went
through
and
created
a
couple
of
them
in
Google
Doc
form.