►
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
Hello
today
is
Tuesday
December,
18
2018.
This
is
the
standard,
sig
clustered
life
cycle,
meaning
it
looks
that
Robbie
is
not
here,
but
he
has
a
bunch
of
things
in
in
the
notes
that
he'd,
like
first
discussed
the
first
thing
there's
listed,
there
is
discuss
major
takeaways
from
the
conference.
I
can
start
it
off
and
then
sort
of
cede
it
to
a
bunch
of
other
folks,
I
think
the
most
common
takeaway
I
had
we
even
had
separate
discussions
on
this
topic
is
that
the
community
is
still
growing
very
fast.
A
Most
more
than
half
the
people
in
the
audience
for
all
the
sequester
level
talks
we're
new
to
kubernetes
in
general.
What
was
also
kind
of
the
theme
is
they
didn't
understand
the
state
space
of
tools
and
where
one
tool
and
intellectual
began
there's
just
general
confusion
there
and
I
will
stop
talking
and
let
other
people
chime
in
about
their
take.
B
I
think
I'll.
Second,
your
comment
about
there
being
confusion
around
what
tools
exist
in
why
and
where
they
fit
in
the
ecosystem
and
a
lot
of
the
conversations
I
had
were
around.
Where
does
Cuba
TM
begin
and
and
other
tools?
You
know
where
does
cue,
baiting
amend
and
other
tools
began?
Where
does
cluster
cluster
API
fit
into
the
ecosystem?
And
all
of
that
stuff?
B
C
Am
actually
I
think
that's
right
and
I
I
would
I'd,
say
I'm
super
excited
by
the
fact
that
I
feel
like
we're,
making
a
ton
of
progress
in
having
to
find
those
components,
I
guess
or
whatever
you
want
to
whatever
the
word.
I
use
a
better
where
the
components
but
yes
and
I
think
that
will
help
address
the
issue,
and
we
have
this
sort
of
stack
of
modular
pieces.
And
then
you
know
cops
is
a
combination
of
them
and
cube
spray
is,
and
other
tools
are
right.
I.
E
A
little
bit
later,
this
is
about
Cube
comments.
The
Closer
lifecycle,
yep,
the
interesting
tool
that
I
saw
come
up.
A
bunch
is
kind.
It
was
funny
to
see
that
pop
up
in
a
bunch
of
different
places,
but
I
think
that's
still
like
we're
still
looking
at
how
to
use
that.
As
far
as
a
cluster
lifecycle
conversations,
there
are
a
lot
of
conversations
I
had
with
random
people
on
the
floor,
who
were
just
sort
of
interested
in
upgrading
upgrading
of
clusters,
managing
clusters
and
a
lot
of
noise
was
made
about
cluster
API.
A
C
Don't
know
if
we
could
make
some
form
of
adopt.
Adoption
is
pretty
hard
like
adoption
of
an
existing
cluster
into
two
is
pretty
hard
I,
don't
know
if
we
could
do
a
works
80%
of
the
time
tech
to,
or
at
least
like
give
you
some
guideline
on
like
this.
This
might
help.
It
is
like
a
tough
problem.
I
think.
A
Migration
tools
like
workload,
migration
tools
like
that
actually
bleed
traffic
over
and
am
evil
way
like
Andy
Goldstein,
did
a
great
talk
called
clusters
as
cattle
last
coop
gun.
Not
this
not
this
last
one,
but
the
one
before
that,
where
we're
basically
pieced
together.
Some
different
tools
to
base
allow
folks
to
migrant
work
loads
in
a
piecemeal
fashion.
For
me
to
be,
and
that
that's
a
highly
useful
thing
to
get
people
off
of
you
know
a
legacy
environment.
A
E
C
Jeff
and
I
finally
showed
our
work
on
that
on
operators
or
I
had
a
Power
are
suggesting
for
how
to
do
add-ons
and
I.
We
took
my
that
later.
I
wanted
to
apologize
to
the
sig
for
not
having
got
our
ducks
in
a
row
to
be
able
to
talk
about
our
prior
sig
meeting
before
showing
our
work
at
coop
Gong,
which
is
not
the
way
we
intended
to
do
it,
but
that's
how
it
happened,
I'm
afraid,
I'm,
sorry,
yes,
so
there
was
that
I,
don't
know
if
cool,
oh
yeah
watch
that
video.
That
sounds
great.
D
One
of
the
things
I
really
liked
was
a
continued
discussion
about
cube,
ABN
and
I,
really
felt
like
cube
ATM,
you
know,
ties
the
room
together,
like
a
good
rug.
You
know
there's
so
many
now
that
it's
now
that
it's
basic
is
GA,
so
many
people
are
building
on
top
of
it
and
I
think
that's
really
wonderful.
A
That's
probably
like
I
think
one
of
the
highlighted
pieces
too,
is
that,
like
I,
think
the
community
in
general
is
really
really
appreciative
of
the
work
that
we're
doing,
because
it
is
hard
to
do
this
stuff.
It's
exceedingly
hard
for
folks
to
manage
it
on
their
own
and
in
in
the
absence
of
having
a
fragmented
sort
of
ecosystem
of
vendor
itis
tools.
Being
able
to
rely
on
the
community
is
actually
super
helpful.
A
Once
twice
three
times
next
one
is
a
new
meeting
protocol,
just
sort
of
like
a
PSA.
When
we
join
the
meetings,
it'll
auto
record
I
don't
have
to
the
person
who's
a
chair
can
be
the
host,
and
then
they
can.
You
know,
mute
your
butpeople
as
needed
and
it'll
automatically
be
recorded
and
someone
else
is
responsible
for
Auto
uploading,
the
videos
which
would
be
nice.
It
also
prevents
the
accidental
my
kid
clicked
on
this
thing
and
added
it
to
our
video
playlist.
A
I
know
folks
were
aware,
but
at
one
point
in
time
we
actually
had
some
cat
videos
decided
sequester
life
cycle
had
nothing
to
do
with
me.
I
was
X
X
people
who
are
on
this
thing,
we're
chairs
in
the
sig
and
their
kid
had
taken
over
their
phone
and,
of
course,
you
know,
watch
that
later
add
it
to
the
list.
So
we
have
to
get
all
the
pass.
Is
that
right?
Exactly
so?
A
E
A
D
Was
asking
because
I
would
like
to
figure
out
how
what
the
process
is
for
getting
the
correct
zoom
set
up
for
the
mini
cube
meetings
right
now?
In
the
past,
we
were
doing
it
on
hangouts,
which
of
course,
isn't
available
to
the
great
number
of
people.
So
you
know
we
need
to
zoom
and
I.
Just
am
not
sure
how
other
than
yeah
yeah
yeah.
A
A
B
A
C
But
essentially
we
would
like
to
propose
this
as
a
way
of
managing
add-ons
that,
hopefully,
will
be
usable
by
all
the
tools
and
so
make
sure
that
everyone,
in
this
sake,
is
on
board
with
that
would
hopefully
be
Amin
Amin
able
to
that
goal.
I
was
going
to
do
a
Google
Doc
share
it
with
a
group
sort
of
sketching
the
the
approach
letting
people
comment.
Point
out,
failures,
shortcomings,
all
of
that
and
then
I
guess.
C
The
next
step
would
be
to
do
a
kappa,
don't
even
know
if
we
need
a
cap,
but
I
guess
we
probably
do
so.
It's
not
clear
yet
exactly
where
these,
where
the
add
ons
would
end
up
living.
So
it
may
be
that
we
don't
even
need
a
repo
if
most
of
the
code
goes
into
coop
builder
controller,
runtime
and
then
each
individual
component,
but
I
do
think
likely
we'll
have
to
figure
out
somewhere
that
our
add-ons
are
going
to
live
if
we
were
ever
to
get
rid
of
the
communities
communities
cluster
directory.
C
F
A
Both
is
probably
the
answer
I
mean,
like
typically
sequester
lifecycle
owns
this
particular
kept
in
general.
That's
the
way
it's
sort
of
run
is
like,
but
you
don't
prevent
and
other
folks
from
sort
of
commenting,
but
we
are.
We
are
responsible
for
driving
it
through
execution
and
completion.
So,
but
one
of
the
things
that's
important
to
understand
within
the
career
days
community
is
that
once
you
create
a
cap,
I
think
with
the
new
process.
That's
nice
is
because
we
have
owners.
It
will
sort
of
bit
rot
on
the
vine
by
sort
of
sidelined
comments.
A
It's
just
as
it
doesn't.
Architectural
II
diverge
from
the
rest
of
the
community,
so
I
think
harvesting
architecture
owns
the
final
say.
If
you,
you
know
if
they
want
to
stop
something
from
working.
Otherwise,
it's
up
to
our
discretion,
has
a
cig
to
executed
things
and
given
the
nature
of
this
up
being
outside
of
the
core
I
think
it's
totally
our
discretion.
A
A
C
I
wasn't
proposing
going
everything
I
would
work.
You
know
over
the
next
month,
I
guess
to
produce
that
Google
Doc
and
put
it
on
the
agenda,
and
then
we
could
let
people
start
having
at
it.
But
yeah
I,
don't
I,
don't
there's
any
particular
rush
to
be
honest
other
than
the
fact
that
we
want
to
get
rid
of
that
custard
Rattray
at
some
stage,
I.
A
H
Hello,
so
concerning
this
project
during
the
coop
corn,
I
had
some
discussion
with
Benjamin
and
James
of
kind
concerned
and
the
possibility
of
divorces,
but
we
decided
that
the
Scopes
of
current
project
and
QB
tmjd
cluster
are
a
bit
different
at
this
point.
For
instance,
QB
GM,
the
ng
cluster,
has
a
focus
on
multiple
node
local
clusters
and
support
for
remote
docker.
So,
for
instance,
it's
used
by
six
scheduling
some
scheduling
folks
for
module,
no
testing.
It
can
be
used
also
for
projects
like
rook,
where
multiple
nodes
can
also
be
important.
H
The
project
will
have
the
proper
releases
from
now
on,
but
one
problem
that
still
remains
here
is
that
kind
of
the
name
of
the
project
is
not
very
well
chosen
and
the
idea
is
to
highlight
its
purpose
and
how
it
differs,
for
instance,
from
mini
cube
is
to
rename
it
to
multi.
Cube
I
actually
was
suggesting
this,
the
jimothy
at
keep
corn
after
this
talk,
but
well
as
far
understand,
there
needs
to
be
a
procedure
for
that,
and
folks
need
to
agree
if
this
should
really
be
done.
A
Iii
would
think
maybe
we
want
to
hold
on
a
renaming
for
like
a
time
period
for
like
the
next
six
months,
just
because
of
the
potential
conflicts
that
could
arise
from
the
different
tools
and
how
they
would
want
to
overlap
and
relate
I.
Think
the
Venn
diagrams
now
are
not
purely
overlapping
but
I
think
as
time
progresses
they
will
overlap
and
there
also
be
a
confusion
of
discovery
right
I'm
not
opposed
to
the
idea
in
general,
once
we've
kind
of
settled,
but
I
think
it
might
cause
more
confusion
than
benefit
in
the
near
term.
A
J
So
Tim
we
talked
at
Q
Khan
about
so
with
mini
cube.
We
just
started
basically
a
couple
of
months
ago
and
coming
in,
we
saw
that
mini
cube
was
never
really
like
super
actively
part
of
the
conversations
and
in
the
community,
and
I
would
like
to
learn
more
about
like
how
to
fix
that
decides.
Turning
up
here
showing
up
here.
A
Some
folks
who
have
worked
on
the
Covidien
project
as
well
as
other
folks
inside
of
except
you
know,
vmware,
as
well
as
the
cluster
api,
coppa
project
or
cluster
api
AWS
provider
provider.
Ews,
follow
a
similar
sort
of
labeling
conventions
for
how
we
manage
everything
and
it
falls
in
line
with
basic
upstream
semantics,
but
everything
basically
gets
a
priority
in
a
milestone
and
a
set
of
standards,
labels
that
actually
exist
across
the
whole
project,
but
we're
very
we
triage
on
inbound
right
and
a
lot
of
times.
A
A
But
the
reason
we
do
this
is
for
clarity
and
also
for
focus.
You
know
so,
if
I
get
hit
by
a
bus,
randomly
playing
in
traffic
I'd
be
clear
to
any
external
observer
to
understand,
what's
the
highest
priority
or
item
for
a
given
release
milestone,
and
it's
also
clear
to
like
for
person
who
is
coming
in
new
or
fresh
to
the
project,
what
what
areas
are
good
to
contribute
to
now.
A
The
one
thing
that's
kind
of
missing
from
this
sort
of
implicit
structure
is
being
very
explicit
about
it,
as
well
as
denoting
some
some
practices
that
we
do.
For
example,
even
though
you're
assigned
a
person
might
be
assigned
to
an
issue
that
doesn't
actually
mean
that
they
are
the
one
sole
person
that
is
executing
on
it.
A
If
somebody
else
is
scanning
the
backlog.
Don't
pick
up
that
item
right
that
items
not
a
good
one
for
you
to
work
on
because
there's
already
patches
to
the
flight,
so
hopefully
I've,
given
you
the
50,000
foot,
TL
DR
view
of
it,
but
I
absolutely
do
think
we
should
codify
this
into
potentially
the
community
repository.
So
if
you
go
to.
A
A
Do
think
we
should
probably
start
to
codify
this
underneath
the
cig
cluster
lifecycle
repository
and
you
might
want
to
call
it
something
like
can
triage
conventions
or
something
like
that.
Maybe
I
can
start
the
document
and
solicit
feedback
from
other
folks.
But
hopefully
this
will
kind
of
there's.
Probably
there's
a
lot
more
detail
to
all
this
too,
that
we
kind
of
do
as
part
of
sort
of
management
of
projects
or
sub
projects,
but
that
way
it
can
give
like
a
unified
feel
across
of
all
of
the
different
sub
projects.
A
G
A
I'm
slightly
confused,
like
we
need
to
do
a
a
cig,
wide
revaluation
of
what
belongs
inside
of
the
communities
site
in
part,
because
I
don't
believe
that
that
should
live
there.
I
think
you
having
links
to
call-outs
to
the
github
repository,
makes
a
ton
of
sense
for
documentation,
but
I,
don't
think
actually
putting
me
a
bulk
set
of
mainline
docks
into
Corinne.
Adiz
website
makes
a
ton
of
sense
for
that
stuff.
Okay,.
D
I
think
the
one
of
the
big
problems
that
I
would
like
to
sort
out
this
next
quarter
is,
is
our
documentation?
Basically
are?
How
do
we
are
our
onboarding
experience
for
new
users
and
one
of
the
big
problems
is
documentation
and
that
we
do
have
conflicting
documentation
between
the
two
websites?
We
shouldn't
have
two
different
websites
for
documentation:
I'm,
not
terribly
opinionated,
on
exact
on
where
it
is,
but
there
should
only
be
one
that
we
officially
maintains.
G
D
G
A
D
J
Okay,
okay,
so
before
we
pointed
out,
we
can
we
can
clean
up
our
own
ducks
and
then
and
then
do
the
repointing
and
then
I
mean
hammock,
and
we
can
just
jump
on
these.
These
dogs
issues
yep
Luke,
was
the
only
one
who
needs
to
look
at
it
and
thanks
by
the
way,
under
this
point
for
handling
these
I
didn't
have
any
idea
that
this
exists.
J
G
A
G
G
Wanted
to
point
out
that
we
have
a
couple
of
pending
peers
that
already
like
implements
certain
parts
of
what
we
want
to
do
with
kind
and
the
first
PR
is
by
Fabrizio.
It
implements
the
multi
node
configuration
and
I
guess
since
Ben
is
here.
Maybe
we
should
discuss
like
this
is
probably
planned
for
next
year,
because
I'm
also
PTO,
but
right
now,
by
the
way.
So
my
point
here
is
that
we
probably
should
like
punt
everything
out
for
the
next
year,
but
I
just
wanted
to
say
like
what
status
we
have
currently.
G
Keep
this
deep
oil
for
crimes
and
I
tested
it
locally
kind
of
once,
but
I
need
to
test
it
in
another
way
and
that's
crystal
sailors.
After
we
get
these
two
pianos
in,
we
can
actually
replace
the
the
current
cube
ATM
test,
for
instance
those
that
test
specific
branches
like
the
master
one,
the
one
twelve
one,
the
one
thirty
one
I
think
we
can
replace
those
and
add
upgrades
are
gonna
need
special
attention.
That's
like
the
next
stage.
I
Multi-Node,
probably
not
I,
think
we
need
to
discuss
a
little
bit
more
about
how
the
internal
should
work
like
the
functionality
is
there
I
can't
want
to
change
the
design
a
little
bit,
we'll
probably
get
the
cube
tested
player
in
multi
knows
a
little
if
he
I
was
hoping
to
have
it
this
year,
but
I'm
I'm
not
gonna
rush.
It
versus,
like
you,
know,
winding
up
with
a
bunch
of
technical
debt.
This
early
did.
M
A
A
The
only
thing
that
I
think
is
broadly
applicable,
that
I
can
think
of
is
part
of
a
conversation
we
had
with
the
cluster
API
working
group
at
KU.
Khan
was
that
I
think
it's
totally
okay
for
four
pieces
of
cluster
API
to
fragment
and
then
coalesce
and
fragment
and
coalesce,
as
we
start
to
get
more
maturity
and
experience
with
some
of
these
different
provider.
Implementations.
A
But
I
do
think
that
before
we
go
through
promotion,
phases
and
I,
don't
know
Robby
love
the
issue
that
we
should
definitely
have
like
a
really
8
or
D
Duke
work
across
different
providers.
I
can
follow
up
on
that,
but
I
thought
that
that
is
a
general
PSA.
That
I
think
is
worthy
of
the
broader
sort
of
announcement.