►
From YouTube: 2018-01-29 Rook Community Meeting
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
There
are
some
issues
openin,
but
there
are
a
few
things
that
are
kind
of
just
housekeeping.
A
A
Yes,
so
so
there
is
now
a
new
web
hook
on
pull
requests,
though,
to
enforce
a
DCO
developer's
certificate
of
origin,
and
what
that
really
means
is
that
every
commit
means
to
say
signed
off
by
someone.
So
if
you
look
at
this
commit
he's,
you
know,
Jarrett's
material
should
say
signed
off
by
Jared
watts
and
get
has
built
in
support
for
that,
because
that's
the
model,
Linux
and
other
open
source
projects
use.
So
if
you
say
git
commit
dash
s
small
s,
then
it
will
add
your
email
to
the
commit
to
every
commit.
There's.
A
C
A
Need
to
do
that,
that's
a
different
model,
that's
a
CLA
model!
That's
where
you
actually
have
to
get
permission,
and
they
will.
You
know,
verify
you
and
where
we
follow
a
DCO
model,
it's
a
different
model.
Okay,
so
so
they're,
okay,
with
D
Co
they've,
been
able
dit
on
this
repo
and
I
believe
on
the
operator,
kit,
repo
and
so
those
have
to
now.
A
A
There
are
a
bunch
of
pull
requests
that
are
open.
That
probably
need
to
be.
The
commits
need
to
be
amended,
so
you
can
well
yeah.
So
if
you
have
multiple
multiple
of
those
that
multiple
commits
you
can
probably
rebase
and
then
edit
or
reword
each
of
the
commits
or
if
it's
just
one
commit
you
can
probably
do
I
get
amend,
yes,
I
believe
we'll
fix
it
had.
A
A
The
other
item
is
that
there
is
no
license
scanning
happening
using
fossa,
so
that
I
got
enabled
to
which
really
means
that
every
time
you
add
any
dependency
in
go
or
you
add
any
project
that
is
somehow
referenced
from
the
rook
project
and
operator
cat
I
believe
now
that
this
this
BOTS
will
check
all
all
recursive
dependencies
and
their
licenses.
So
it
knows
how
to
parse
the
license
files
in
each
of
the
repos
and
look
for
look
for
you
know
GPL
or
other
other
issues
with
licensing
and
that
scam
is
now
enabled
on
master.
A
A
It
has
false
positives,
so
I've
seen
already
a
bunch,
so
you
can
go
into
the
scan
and
then
you
know
disable
them
or
ignore
some
of
them.
I
ignored
one,
and
then
you
know
some
we
don't
have
control
of
like
kubernetes
brings
in
some
code
from
I,
don't
know
where,
but
it
does
the
whole
recursive
dependency
check
so
so
that
one
I,
you
know
I
believe
the
the
Linux
Foundation
and
the
CN
CF
we're
okay
with
making
that
not
a
required
check,
but
but
it
is
a
check
in
anyway.
So
you
should
see
it
happen.
A
A
I
Lincoln
is
yeah,
yeah
yeah,
you
should
I
an
ice,
I
could
have
sworn
and
I
was
I
could
have
sworn
that
I
was
enabled,
but
I'll
verify,
but
with
with
Chris.
So
that's
that's
the
that's.
The
other
one
I
think
I
mentioned
so
contributing
the
contributing
file
has
to
change,
to
have
all
the
new
rules
about
signing
and
everything
else.
A
We
have
to
add
a
badge
Chris
brought
that
up.
Let's
see
if
I
can
find
it
so
governance
contributing
code
of
conduct
at
this
one.
We
have
to
go
through
some
process
to
get
best
practice
this
process
here
and
it's
actually
a
fairly
long
process,
but
we
have
to
go
through
it
to
get
a
badge
of
you
know:
core
infrastructure,
best
practices
and
it's
a
requirement
for
CNCs
projects.
So
it
includes
that
includes
things
like
you
know,
licensing
showing
on
our
on
the
rooked
at
I/o
webpage.
A
A
I
think
I
believe
creating
new
projects
will
be
restricted
and
but
it
it
should
work
like
like
it.
It
hasn't
it
has
in
the
past.
I
just
don't
know
what
all
the
I
don't
know.
What
all
the
implications
are.
I
haven't
looked
at
github
permissions
in
a
while
in
terms
of
what
is
possible.
What's
not
so
I'll
follow
up.
They
have
some
guidelines
around
that
and.
A
A
A
A
A
I,
don't
know
exactly
when
it
starts,
but
you
know,
given
that
it's
CN
CF
is
applying
as
a
whole
as
a
whole
organization.
I
think
it'll
it'll
probably
get
a
fair
amount
of
participation,
which
is
nice
so.
A
E
A
A
E
A
Iii,
don't
I
I'm,
saying
I,
don't
think
it
makes
sense.
It
is
it's
probably
an
option
if
we
wanted
to
but
I
don't
I,
don't
think
immediate
means
do
so
well,
I'll.
Ask
them.
I've
asked
him
before
and
I'll
ask
them
to
help
upgrade
us
to
full
slack
thing
and
I,
don't
think
we
lose
any
of
the
history
so
anything
that
was
in
the
past.
This
should
still
be
there
when
it
happens.
Another.
E
A
Good
good
question:
they
have
a
really
large
cluster
of
their
metal
machines
and
Jenkins
and
CI
and
and
both
arm
v8
and
Intel,
so
I
think
we'll
we'll
get
the
thread
going
to
move
all
of
CI
4
to
that
infrastructure.
They
have
there's
actually
a
whole
team
in
charge
of
that,
so
that
that
would
be
really
awesome.
A
A
They
have
a
dashboard
that
shows
all
the
projects
and
how
they're
being
tested
rook
should
go
on
there
too,
so
we'll
well
we'll
get
that
going
to
and
then
there's
similarly
for
the
documentation
they
allocate,
they
allocate
dollars
for
hiring
technical
writers
to
help
document
projects.
So
we
should
think
about
how
to
use
that
effectively.
We
can
probably
get
a
couple
of
technical
writers
to
help
document.
Oh
you
know
all
the
stuff
around
Brooke
and
improve
the
documentation.
C
A
E
Speaking
of
consciousness,
do
we
can
use
newbies
or
anything
like
party
like
for
slot
or
yeah.
A
D
A
Getting
to
production
getting
to
v1
and
then
getting
more
production
deployments
of
it.
It's
probably
what
I
would
look
at
the
multiple
backends
is
likely
to
it
to
be
a
another
another
topic.
So
those
are
the
things
that
come
to
mind.
I
think
it's!
It's
really
a
measure
of
maturity
and
community
around
it
right.
D
E
A
A
So
I.
Don't
think
that
I
think
if
somebody
in
the
community,
you
wanted
to
write
a
back-end
first
for
worked
and
and
they're
more
than
welcome
to
it.
So
it's
an
open
project.
I
haven't
nobody,
has
stepped
up
at
this
point
and
said
with
firm
commitment
that
they're
doing
that
so,
but
nonetheless,
I
think
you
know,
as
has
a
talk
of
a
project,
we
should
think
about
how
that
could
happen
and
I
could
see
it
happening.
B
B
A
Yeah
yeah,
so
so
so
yeah
a
lot
I
mean
this
is
an
important
step
in
the
right
direction
and
I
think
that
there's
definitely
gonna
be
more
and
more
to
do
here
and,
and
that
comes
out
of
this,
but
I
wanted
to
highlight
some
of
the
things
that
I
was
told
about
just
just
this
weekend,
actually
so
so
I'll.
Well,
let's
keep
talking
about
this
I'm
sure,
there's
gonna
be
more
and
more
to
do.
A
B
B
B
D
D
B
So
I
didn't
talk
to
design
doc,
yet
in
my
core
request
that
would
also
need
to
be
done
and
the
documentation
and
yet
a
release
notes
because
it
well
yes
to
change,
to
deployments
that
Steve
or
I
think
it
was
Steve.
First,
it's
yeah!
Well,
it's
breaking
and
yeah!
Well,
the
big
question
really:
yes,
I
think
Travis
said
it's
really
the
right
way
to
go.
B
A
Have
not
had
a
chance
to
look
at
it
in
detail,
but
I
was
curious.
If
this
is
something
that
you
know,
we
believe
is
gonna
help
solve
some
of
these
issues
that
we're
seeing
with
Mon
failover
and
if
it's
the
right
path
going
forward.
I
know
there
is
you
know
a
full
sets.
Are
you
know,
there's
more
work
to
be
done
in
them
on
stateful
sets
themselves
painting
and
all
this
work
that
the
coronaries
community
talks
about,
but
so
so
I
don't
know
if
Travis
enjoyed
have
you
guys
looked
at
this
in
more
detail
and.
B
B
B
A
B
A
E
So
I
have
a
PR
I.
Would
change
monitor
from
replica
set
to
deployments
and
I
think
that's
gonna
break
well.
The
only
thing
that
is
different
is
from
Jenny
from
Richmond
said
to
the
user
deployment.
If
that
cursed
Murch
do
you
do
you
thing
will
be
easy
for
you
to
to
adapt
that
genius,
or
would
it
make
sense
for
you
to
for
me
not
to
touch
that
the
monitor
part?
You
know
it's.
B
Kind
of
why
I
wrote
my
comment:
I
think
it
was
one
of
the
first
commas:
I
wrote
there
or
they
only
and
first
contact
I
hear
it
doesn't
make
sense
to
go
for
deployments
what
we
made
more
or
less
want
to
switch
to
stateful
sets.
So
the
question
is,
we
are
really
if
we
want
to
go
for
deployments
or
state
forces,
because
if
you
change
it
now
to
stay
for
their
two
deployments
and
a
week
laid
out
that
the
state
forces
stateful
such
stuff
is
ready,
we
can
edit
work
twice.
E
The
reason
why
I
brought
that,
because
some
it
looks
like
you
brought
a
lot
of
you-
have
some
unknowns,
especially
the
monitor
mode
map
and
the
DNS
and
so
I'm,
not
sure.
Maybe
you
have
better
kind
of
estimator
when
this
your
work
would
be
complete.
But
if
it
takes
let's
say
longer,
then
I
probably
don't
want
to
hold
on
this
PR,
because
this
is
this
will
affect
upgrades.
So
it.
A
B
A
A
B
E
What
I
can
do
is
that
I
can
modify
the
PR
and
instead
of
use
deployment
use
replica
set
just
for
the
four
monitors
it
is
gonna,
be
using
a
replica.
The
Stifel
sets
sorry,
but
it's
gonna
be
treated
like
a
deployment.
I'm
not
gonna,
do
any
of
the
persistent
volume
stuff
I'm,
not
gonna,
do
any
of
the
templating
stuff
that
you
have
it
just
pretty
much.
Just
change
the
resources
from
public
asset
to
stay
for
set.
B
B
A
B
Is
less
of
a
problem
if
you
change
everything
else
that
is
currently
a
replica
so
to
a
deployment
like
no
STIs
but
yeah,
as
per
some
says,
if
we
leave
the
months
out,
I
can
simply
put
in
my
state
for
so
and
I.
Think
I
should
be
ready
if
I
get
enough
feedback
and
also
about
health
checking.
If
you
really
do
it
by
thought
by.
A
B
D
B
D
D
B
A
B
D
E
B
A
D
A
A
A
There
might
be
an
opportunity
to
do
the
you
know
the
nested
CRT
approach
here
to
help
clean
it
up,
but
I
think
saying,
astute
a
concept
of
a
storage
cluster
and
all
the
knows
that
should
be
part
of
a
storage
cluster
and
their
devices
is
applicable
to
all
backends
and
even
affinity,
rules
and
placement
rules
or
anything
specific.
A
A
storage
cluster
I
believe
is
a
very
useful
construct
to
have
common,
and
then
it
gets
more
specific
from
that
point
onwards,
pools
and
storage
classes
and
had
their
relationship
and
all
that
stuff
I
think
can
be
common
for
certain.
Certain
parts
can
be
common
and
then
going
from
there.
You
know
when
you
start
out
an
object,
store
and
others.
It
starts
to
get
more
and
more
specific.
D
And
a
couple
things
I
feel
like
I
ran
into
when
I
was
writing.
This
design
is
so
one
you
know
at
what
level
do
we
share
the
code?
Is
it
at
the
CRT
level
or
is
it
below
that
at
the
code
level
and
then
the
other
one
was
if,
if
we're
using
CR
DS
with
all
the
sub
parts
out,
we
can't
declare
different
status
like
alpha
beta,
stable
at
those
sub
parts.
It
has
to
be
at
the
for
the
whole
CR
D
level.
D
A
D
D
A
A
A
And
I'm
not
saying
we
should
I
mean
it's
some
little
syntactic
sugar,
but
I
think
that
discussion
needs
to
be
reconciled
as
well
the
image
how
many
images
we
have
I
I
think
we're
down
a
path
of
saying
there
is.
There
will
likely
be
just
a
very
small
outline
based
rook
operator,
maybe
all
playing
base,
rook
operator
image
and
then
a
back-end
specific
image.
I
like
Steve's
comment
about,
can
we
make
the
Mon
check
happen?
You
know
differently.
B
A
A
D
A
So
I
think
I
think
keeping
continuing
on
just
getting
to
the
point
where
it's
a
design
that
we
can
all
rally
behind.
It's
probably
the
next
step,
even
if
even
if
it's
we
only
check
in
a
design
doc
at
this
point,
but
don't
actually
start
doing
the
work
at
all
I
think
that's
okay,
I
mean
I
started
a
security
design
dog
and
you
know
there's
no
work
on
it
at
this
point,
but
we
can
probably
get
help
around
doing
some
of
this
work,
but
it'll
be
I.
C
A
A
B
E
Yeah
so
III
being
looking
at
the
upgrade,
how
we
can
implement
an
automatic
update
right
now
and
first
of
all,
I
went
through
the
upgrade
Docs
right
now
and
they
were
broken
mainly
because
we've
been
adding
stuff
on
on
master
branch
that
no
longer
apply
like
any
new,
changing
the
manifests
and
all
that
stuff,
and
also
due
to
other
and
other
issues,
I'm,
not
sure
I
suspect
it's
related
to
the
whole
big
image,
change
that
we
did
instead
of
us
building
it
and
getting
it
so
op.
For
some
reason.
E
The
operator,
when
you
just
upgrade
the
operator
is
it
deemed
the
cluster.
You
know
it
a
mess
up.
The
cluster
I
get
a
hundred
percent
PGs
unknown.
Now
this
is
running
a
mini
cube,
one
or
cluster,
so
I'm
not
sure,
if
that
that
has
something
to
do
with
it,
but
a
by
just
a
brilliant.
The
operators
I
get
that
even
the
image
clusters
is
is
intact
and
it.
C
B
B
E
Was
my
next
question
so
I
know
well,
I
know
c1
makes
makes
it
up
with
7-7
upgradeable
and
hopefully
our
beta.
So
we
should
I
think
we
should
do
things
that
would
require
the
upgrade
process.
The
automatic
address
awesome
easier,
so
things
about
changing
resource
from
work,
I
said
to
stay
for
said
or
or
replaces
to
deployment
in
the
case
of
OS
DS,
that's
gonna
be
make
it
very
challenging
and
an
impromptu
to
issues
so
I
would
like
to
you
know
if
you
solve
this
now.
E
B
E
That's
my
concern.
The
manual
steps.
Okay,
guys
wanna,
know
another
thing
that
when
I
bring
up
is
support
force
for
Queen
81.6
I
am
proposing
it
to
drop
it.
Everything
is
because
one
462
CPR
I
know
it
doesn't
have
to
do
anything
about
rook
upgrade,
but
when
user
a
break
kubernetes,
they
have
to
you
know,
do
a
migration
and
there
will
be
a
lot
of
borneo,
attachments,
TPR.
That
needs
to
be
migrated
and
that's
a
manual
process.
E
A
E
A
E
A
A
E
B
B
A
C
I'll
try
to
figure
that
out
in
my
early
thinking
in
terms
of
splitting
implementation,
it
seemed
like
the
implementation,
for
it
was
all
linked
together
and
it's
not
a
massive
change
either,
but
I
don't
see
a
great
way
to
split
it,
but
the
design
feedback
and
making
sure
we're
solid
before
we
go
forward.
You
know,
for
the
feedback
from
Sebastian
would
be
pretty
wise.
Yeah.
A
B
A
B
A
A
To
converge,
that's
a
very
good
point.
What
let
let
me
take
a
pass
at
it
and
then
let's
come
back
together
and
talk
about
it,
I,
don't
think
we
have
time
that
now
we
have
three
more
minutes.
Yeah
though
I've
been
worried
about
the
same
thing,
so
maybe
we
can
discuss
a
little
offline
and
then
come
back
with
a
proposal.
Yeah
how
to
converge
sounds
good.
Okay,.