►
From YouTube: 2020-08-03 Multi-Large Working Group
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).
B
A
To
see
what
you
think
about
the
proposal,
I
didn't
continue
working
on
it
until
I
get
your
opinion
whether
this
is
the
place
or
not
like
I
didn't
know,
where
else.
To
put
it,
I
thought
that
this
was
a
good
location,
so
once
I
get
feedback
from
from
you
and
from
mac
I'll
continue
merging
it
or
moving
it
somewhere
depends
on
that.
B
Yeah,
so
apologies
marin,
you
sent
me
a
slack
on
it
and
I
meant
to
get
back
to
it
and
I
never
did
so.
I
will
get
back
to
it
today.
A
Yeah,
not
the
problem,
it's
it's
not
gonna,
be
a
make
or
break
situation
for
us
immediately.
So
it's
okay
marin.
C
I
was
just
wondering
like
I,
I
just
read
through
the
changer
and
I
just
from
the
notes
from
last
week
it
seemed
like
you,
you
wanted
to
drive
a
pretty
major,
is
probably
not
the
right
work,
but
significant
change
in
the
way
that
we're
we're
developing.
You
know
towards
kubernetes
support
it.
Just
as
I
read
through
that
it
didn't
seem
like
it
was
kind
of
direct
or
aggressive
is
not
the
right
word,
but
it
just
didn't
seem
like
direct
enough
to
drive
that
change.
I
don't
know
it
was.
A
Not
sending
the
message
that
we
were
discussing
right,
like
that's
what
you're
saying
okay,
so
the
reason
for
this
is,
I
was
considering
the
location
where
I
placed
this
so
depending
on
whether
this
is
the
place
we
want
to
have
it
or
not
like
I
have
to
have
the
language
that
fits
the
rest
of
the
explanation
right
like.
If
we
are
going
down
the
handbook
route,
then
I
can
have
a
different
type
of
language,
but
then
I
need
to
figure
out
how
to
connect
that
with
our
regular
processes
as
well.
A
That
is
the
mostly
the
reason
and
that's
why
I
stopped
there
and
not
improved
things
further
until
I
get
feedback
from
from
from
mac
and
christopher
to
see
whether
this
is
even
the
the
the
way
we
want
to
drive
this
message
forward,
because
we
don't
have
a
good
medium
for
this
right
now,
for
these
type
of
things
and
the
documentation
that
is
written
in
there
is
shipped
with
our
products
and
our
community
contributors
are
also
using
it.
So
it
makes
makes
it
a
bit
harder
to
drive
the
type
of
message
we
exactly
wanted
to
drive.
A
A
Up
well
all
right.
The
next
item
is
get
the
pages.
Think.
In
short,
there
are
two
proposals
right
now.
One
is
suggested
by
camille
on
using
zip
and
the
other
one
is
a
different
approach,
which
is
using
more
or
less
existing
systems
that
we
have
and
a
bit
more
of
a
not
a
complicated
route,
but
a
different
route
to
what
the
zip
proposal
is
suggesting.
A
So
basically,
the
decision
was
made
that
the
engineering
manager
of
release
team
ends
up
deciding
based
on
the
input
of
from
engineering
which
direction
we
want
to
take
chris.
If
you
want
to
speak
up,
you
have
also
an
item.
B
Yeah
just
more,
I
know
that
last
week
there
was
a
little
bit
of
confusion
around
kind
of
the
reasoning
behind
why
the
architecture
was
chosen.
So
there's
one
particular
comment
that
kind
of
summarizes
it
there
minus
the
it's
already
done,
because
it's
not
done
obviously
so
just
want
to
point
that
out
in
case
anybody.
Any
questions.
A
Great
thanks
for
that.
So
I'll
just
add
one
other
thing
that
I
think
the
timeline
is
what
will,
in
my
opinion,
win
here,
like
whichever
one
is
less
complex
and
and
gives
us
that
shorter
timeline
is
probably
what's
going
to
be
chosen,
but
let's
see
both
of
them
are
not
as
straightforward
as
I
expected
or
hoped
for
rather
I
kind
of
hoped
code
will
magically
appear
out
of
thin
air
and
resolve
the
problem,
but
unfortunately
it
doesn't
work
like
that.
B
Anytime,
you're
moving
storage,
it's
never
simple
or
trivial,
very
exactly
just
just
throw
that
assumption
out
of
the
way.
A
D
Yeah,
I
was
just
wondering
about
any
ideas,
so
I
think
we
have
a
pretty
good
idea
for
the
implementation
would
look
like,
but
as
it's
always
the
case
is
the
migration
of
whatever.
Is
there
already
that's
going
to
be
a
painful
thing?
Is
this
something
that
we
are
thinking
that
the
application
will
magically?
Do
you
know
when
somebody
requests
something?
Then
the
thing
gets
moved
or
whatever,
or
is
it
an
expectation
that
infra
folks
are
going
to
be
driving
this
on
some
sort
of
long-term
effort
to
manually
or
semi-automatically
move
stuff.
A
One
is
suggesting
like
once,
we've
written
the
codes
things
will
just
work
without
a
lot
of
interaction
from
the
operators,
but
the
other
one
is
suggesting
more
of
a
semi-automated
process
where
things
will
work
transparently,
both
ways
and
there
will
be
a
migration
part
that
someone
will
have
to
someone
will
have
to
make
a
decision
to
do
so.
That
is
the
fundamental
I
think
when
it
comes
to
process
fundamental
difference
between
the
two.
D
A
The
dri
of
this
will
probably
answer
better.
I
know
from
my
side
that
I
authorized
the
account
to
spend
at
most
this
week
in
flashing
out
to
the
plc,
so
decisions
should
be
made
soon.
A
Okay,
soon,
probably
this
week
or
next
week.
I
don't
exactly
know
all
right.
D
I'll
keep
an
eye
on
it,
just
because
yeah
just
want
to
make
sure
we
don't
get
slammed
with
unexpected
work
like
this,
because
these
things
that
you
tend
to
drag
the
life
out
of
infra
folks
at
times.
B
Yeah,
but
I
think
I
think
it's
the
key
input
is
is
what
the
migration
strategy
is
and
what's
the
pain
associated
with
it.
So
I
think
that's
that's
part
of
the
inputs.
We
need
I'm
not
quite
as
optimistic
as
marin
is
to
make
a
decision.
I
think
we're
probably
a
couple
weeks
out,
but
I
think
that's
why
we
need
the
additional
feedback
on
the
migration
strategy.
A
Okay:
okay!
Well,
I'm
glad
that
you're
the
pessimistic
one
this
time
around
so.
A
Yeah,
just
the
the
thing
here
is
from
from
my
view,
we'll
have
to
pay
the
price
somewhere.
So
it's
either
going
to
be
like
a
way
like
probably
a
more
complex
development
strategy,
or
it's
going
to
be
a
simpler
development
strategy
with
a
bit
of
or
some
involvement
of
people
operating
these.
So
it
it'll.
D
What
I'm
trying
to
get
at
is
not
that
one
choice
is
better
than
the
other
just
so
that
we
know
as
soon
as
possible,
on
the
infrasight
to
be
ready
for
it
and
carve
out
cycles
if
we
need
to
so
in
in
some
ways,
I'm
in
favor
of
something
similar
in
the
software,
because
it
gets
us
there
faster
and
then
do
some
finite
manual
work
right.
This
is
not
a
forever
thing.
D
We
just
need
to
get
it
done
and
move
on,
but
that
will
have
an
effect
on
folks
on
call
and
all
that,
so
just
so
that
it's
not
something
that
suddenly
comes
from
left
field.
It's
like
oh,
turns
out.
We
have
all
these
migrations
to
do
so
I'll,
keep
an
eye
on
it
and-
and
you
know,
steve's
fight
of
the
world
is
in
the
working
group.
So
he
is.
He
has
awareness
as
well.
D
Christopher,
what's
the
less
optimist
in
the
notes,
all
right,
mary,
you
have
the
next
one
ci
jobs.
A
Sorry,
christopher,
like
this
is
like
a
very
unique
opportunity
for
me
to
be
more
optimistic.
All
right,
next
item,
ci
job
logs,
not
much
progress
last
week
or
apart
from
the
code,
has
been
merged.
I
spoke
with
jegosh
and
he's
expecting
to
do
a
phase
rollout
this
this
week
to
see
the
first
impact
of
how
does
this
code
actually
behave
so
a
lot
of
progress
there
or
good
progress?
I
think
there.
D
Cool
all
right
we're
going
to
ignore
the
four
item,
because
it
was
a
dumb
question
for
me
that
had
already
been
answered
in
the
very
first
time
so
what's
happening
next,
I
will
continue
to
track
nfs
work,
which
actually
leads
perfectly
into
my
one
item.
My
first
item
for
discussion,
which
is
I've
been
looking
at.
You
know
there
were
questions
last
week
and
I
have
been
thinking
about
how
we
track
this
work
in
a
more
cohesive
way
versus
just
the
notes.
E
D
I
think
I
will
create
the
same
tag
on
both
hierarchies
and
then
we'll
have
two
boards
and
then
we'll
just
have
to
sort
of
squint
our
eyes
to
put
both
of
them
together,
because
I
think
because
the
the
only
issue
there
is
perhaps
keeping
track
of
dependencies,
but
we
can
still
do
that.
I
think
the
the
work
is
self-contained
enough,
that
it
won't
be
a
major
undertaking,
so
I
will
do
that.
D
I
thought
that
was
way
up
in
the
future,
so
I
wasn't
worried
about
it
too
much,
but
I
know
there
there
are
some
internal
conversations
about
it.
My
own
sense
right
now
is
that
this
should
not
be
a
high
priority
item.
Like
there's
a
ton
of
work,
we
can
do
without
worrying
about
this
and
there
is
a
significant
amount
of
work
on
the
on
the
data
stores
team
right
now,
as
it
is
to
add
any
kubernetes
related
stuff
right
now.
C
I
mean
I'd
say
the
thing
that
I
agree
with
is
making
sure
that
we're
like
iterating
forward
in
in
manageable
steps
that
that
allow
us
to
get
things
done,
and
I
think
kind
of
a
little
bit
of
undertone
I'm
hearing
there
is
that
there's
enough
for
us
to
do
with
the
stateless
services
still
ahead
of
us
that
if
we,
if
we
remain
focused
on
those
we'll
be
able
to
actually
get
that
done
before
we
move
on
to
attacking
stateful
services
and
moving
in
there.
C
A
Is
a
bit
more
arguable
in
my
opinion,
but
I
can
put
redis
there
if
you
want.
B
It's
it's
all
standard
services,
it's
not
something
that
we
need
like
a
specific
development
change
on,
or
at
least
we
haven't
recognized
development
change.
At
this
point,.
D
Use
for
stateful
services,
and
so
it's
been
done
and
we
know
of
some
products
that
do
this.
I
just
this
is
really
a
question
about
priorities
of
something
that
I
can
just
walk
into
a
meeting
and
say:
look
yes,
we
know
it's
in
there.
It's
probably
going
to
be
sometime
in
the
future.
We
have
other
work
to
focus
on
right
now.
C
Gotcha,
I
imagine
marinade,
is
a
good
point
about
radish,
so
I
guess
I
guess
it
depends
on,
and
this
is
where
certainly
rely
on
the
rest
of
you
and
your
your
knowledge
of
this.
Of
specifically
how
you
know
the
the
use
case
that
we
have
within
get
lab
for
redis
as
to
whether
or
not
within
you
know
within
get
lab
where
we're
really
using
it
in
a
stateful
or
state
less
service.
C
You
know
fashion
because
you
could
argue
either
way
depending
on
what
the
the
use
case
is
there,
and
I
think
we
should
just
be
clear
on
which
you
know
which
bucket
it
falls
into.
A
Yeah,
I
think,
because
it's
split
between
like
we,
we
have
different
types
of
services
that
we
use
redis
for
so
one
is
almost
like
a
second
database
for
us
because
if
it
degrades-
and
if
it
goes
out,
it
will
take
us
a
longer
time
to
rebuild
like
we
would
be
really
slow.
We
will
be
operational
but
really
slow,
but
we
have
the
other
two
sides
of
radius
that
we
are
using
that
even
if
it
goes
out,
we
can
recover
recover
fairly
quickly.
A
So
that
part
like,
even
if
it's
in
kubernetes
and
not
highly
available,
that's
another
point,
we
would
be
able
to
operate
it.
I
believe,
but
the
question
here
is:
do
we
want
to
splinter
our
energy
right
now
when
we
know
that
we
have
quite
a
lot
more
from
the
application
side
to
go
and
talk
about
this?
I
would
argue
no
at
least
not
in
the
next
three
months,
maybe
in
the
next
six
months.
D
I
agree
with
you,
and
I
think
also
these
are
not
the
types
of
notes
that
were
scaling
up
and
down
constantly
right,
so
the
need
for
those
to
be
in
in
kubernetes
is
less
pressing
than
the
rest
of
the
stack.
So
again
it
was
a
stabilization
question
because
I've
been
part
of
an
aka.
I've
been
in
a
couple
of
conversations
where
folks
were
asking
about
this,
and
my
leaning
was
towards.
Let's
not
worry
about
that
this
minute.
D
A
D
Yeah
yeah
agreed
cool
and
then,
unless
there
are
any
other
items
for
discussion,
the
one
follow-up
item
that
I'm
going
to
chase
this
week
is
to
see
if
on
all
the
the
other
deliverables
that
we
have
for
the
working
group.
If
there
is
anything
else
that
we
can
bump
up
in
priority,
because
right
now
we're
super
focused
on
nfs
and
we
know
that's
a
huge
blocker,
but
there's
probably
progress.
D
We
can
make
in
other
areas,
so
I'll,
see
I'll
flash
those
out
and
then
bring
those
back
to
to
this
group
next
week,
and
then
we
can
make
some
decisions
on.
Yes,
we
could
paralyze
but
we're
busy
anyway,
this
quarter
so
we'll
leave
it
for
q4
or
whatever,
but
at
least
we
expose
those-
and
we
understand
where
we
can,
if
cycles
become
available,
where
we
can
invest
what
we
can
invest
in
so.
A
D
A
I
see
that
andrew
is
here
as
a
representative
of
product
right
now,
so
I
think
we
are
covered
on
that
side.
I
just
thought.
Maybe
it
would
be
interesting
to
see
the
areas
we
are
covering
right
now
who
the
exact
product
manager
is
because
that
affects
prioritization
process
significantly,
so
we
could
like
have
andrew
and
the
product
manager
help
us
out
there.
B
I'd
recommend
getting
coordinating
with
andrew
pre-meeting
and
getting
them
to
show
up
for
the
specific
ones
you
need
them
engaged
in
unless
it's
like.
You
know
that
they're
going
to
be
engaged
for
you
know,
weeks
on
end,
I
just
pulling
in.
B
Generically
is
not
a
recipe
for
success
in
my
book.
C
F
A
F
B
And
and
while
we
will
get
it
off
a
dot
com
quickly,
we
can't
necessarily
force
customers
right
so
like
depending
on
where
they
are
in
their
life
cycle,
particularly
if
they
made
a
huge
investment
in
nfs
storage.
Us
asking
them
to
migrate
may
not
be
the
the
right
decision.
At
that
point,.
B
It
could
be
three
months
could
be
three
years.
I
that's
the
part.
I
can't
really
give
you
better
visibility
to
it.
So
that's
something
probably
andrew
united
and
maybe
josh
should
talk
about
offline.
Is
it's
like
you
know
if
if
we
have
a
specific
transition
strategy
here,
what
does
it
consist
of
as
a
year?
Is
it
you
know,
and
from
that
perspective.
F
Yeah
I
mean
we
can
dive
into
specifics
later,
but
our
strategy
is,
we
can't
really
force
them
off
what
they
are,
but
the
next
opportunity
whether
somebody
sets
up
a
new
architecture.
We
will
slide
it
in
there
then,
but
we
can't
yank
them
off.
Yeah
yeah.
B
Recommendation
for
new
customers-
absolutely
that's
one
thing:
it's
just
more
of
you
know
like
whatever
just
made
a
big
investment
fast.
D
I
think
for
that,
for
the
reference
architectures
we
will
find
out
if,
with
the
changes
to
you
know
with
the
removal
of
nfs,
is
the
if
the
non-nfs
option
has
any
performance
implications
for
the
rest
of
the
stack
that
is
contained
in
the
reference
architecture.
We
may
end
up
that.
We
end
up
tweaking
them,
but
I
honestly
don't
expect
that
to
be
the
case,
because
the
bulk
of
the
app
is
still
not
like
that's
not
pages
right.
D
Okay,
let
me
rephrase
that
I
assume
we're
going
to
run
the
reference
architectures
without
nfs
to
see
what
their
baseline
performance
is
and
whether
the
numbers
that
we've
determined
are
the
steps
in
the
configuration
makes
sense,
and
unless
we
see
any
major
deviations
like
plus
minus
10
of
performance,
then
I
would
probably
leave
them
as
they
are
and
not
worry
about
it
too
much.
The
only
other
area
where
I
think
there
may
be
some
influence
to
them
is,
as
we
work
out
the
transitions
from
you
know
the
one
reference
architecture
to
the
next
step
up.
D
We
may
find
that
we
may
need
to
do
to
do
some
tweaks
to
them,
because
we
can't
find
a
way
to
transition
from
one
to
the
next
online,
and
so
we
may
go
back
and
say
well
if
we
do
this
third
thing
and
change
the
reference
architectures
to
use
this,
then
that
transition
can
be
a
slam,
dunk
versus
oh,
we
we
do
need
that
downtime.
Does
that
make
sense.
D
So
we
know
what
the
reference
architectures
look
like,
what
we,
I
don't
think,
we've
ever
done,
and
one
of
the
outputs
from
this
working
group
is
figuring
out.
How
do
you
transition
from
one
to
the
next
without
impacting
customer?
You
know
the
uptime
of
the
instance,
so
we
don't
know
yet,
but
it's
still,
I
don't
think
the
changes
would
be
so
significant
that
we
need
to
significantly
change
what
they
look
like
like.
I
expect
maybe
a
couple
of
handbook
updates,
but
nothing
super
major.
F
Cool
yeah,
the
only
thing
he
asked
is:
let's
notify
the
team,
because
the
folks
working
on
the
reference
architecture
are
all
on
this
call
they're
nearly
a
tanya
and
then
jason.
So
I'm
asking
like
we
know
nfs
and
now
but
like
if
there
are
other.
You
know
next
ones.
Next
candidates,
then
please
loop
us
in
early,
so
we
can
account
for
it
and
test
for
it.
That's
what
I'm
asking.
D
Oh
cool
still
definitely
one
of
the
main
topics
for
discussion
here
and
I
think
all
the
stakeholders
that
are
interested
in
those
reference
architectures
are
here,
but
I
can
definitely
make
sure
to
keep
you
all
in
the
loop,
even
if
it's
out
of
bound,
if
we
run
into
something
specific.
A
Mike,
how
do
you
keep
track
of
changes
in
in
the
application
and
how
the
service
is
behaving
right
now,
outside
of
this
working
group,.
F
We
we
moved
the
the
so
we
used
to
have
the
self
self-managed
scalability
working
group
that
has
moved
to
a
asynchronous
board
update
and
a
billy
weekly
triad,
so
we're
tracking
the
work
stream
there
instead
and
collaborating
with
the
day-to-day
operations
of
the
distribution
team
is.
That
is
that
the
are
you
asking
on
the
process.
Are
you
asking
on
the
technicalities
of
testing
stateless
yeah.
A
But
yeah
both
because
the
things
that
are
coming
down
the
pipeline
right
now
are
registry
is
going
to
have
a
dependency
on
a
database.
Prefect
already
has
a
dependency
on
the
database.
All
of
those
things
affect
the
reference.
Architectures
well
gitlab.com,
significantly,
obviously,
but
I
can
see
it
also
coming
down
the
reference
architecture
route
as
well,
and
I
like
in
the
conversations
I
didn't
really
necessarily
see
where
that
fits
with
what
your
team
is
doing.
F
We're
testing
mostly
scale
but
there.
If
there's
data
integrity
and
like
lost
cash,
cash,
invalidation,
stateless
things,
then
we
should
discuss
it
and
make
sure
we
test
it.
I
I
don't
know
I'm
not
close
to
ground,
so
maybe
maybe
tanya
or
nelia
can
help
chime
in
there.
If
you're
doing
anything,
there.
D
E
D
All
right
no
blockers
this
week,
so
thank
you.
Everyone
see
you
next
week.