►
From YouTube: 2020-11-16 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
B
B
Yeah,
hey
everyone,
so,
on
the
pages
side
we
started
on
thursday
or
on
friday,
I
guess
deploying
to
the
object,
storage
to
a
separate
bucket.
We
were
using
artifacts
before
today.
We
had
about
6
000
of
new
deployments
already
so
in
four
days.
Basically,
so
the
next
step,
as
camille
described
below,
will
be
immigration,
so
that
was
the
status.
C
B
End
of
december
sounds
reasonable
to
me
right
now,
but
it's
I'd
say
for
me:
it's
more
of
a
gut
feeling
that
estimate
which
I
did
so
basically
the
next
step
is
just
to
write
in
the
migration
which
at
the
moment,
doesn't
sound
that
big
and
running
it
in
the
production,
and
hopefully
there
will
be
not
not
so
many
problems
there,
but
can't
guess
at
the
moment.
Maybe
camille
has
something
to
say
here
right
now,.
D
So
gary,
like
I'm,
pretty
confident
that
we're
gonna
finish
migration
in,
like
in
the
13.7.
I'm
just
uncertain,
though,
like
two
different
timings
that
we
will
be
able
to
like
to
run
that
fully
during
okay.
D
Like
a
couple
of
weeks,
yes,
so
so
like,
there
is
even
like
fyi
from
me
like
in
the
next
section,
because
we
are
thinking
about
like
different
approaches.
Right
now
to
run
this
migration
in
the
production
to
like,
have
fully
con
to
have
full
control
of
this
migration,
because
we're
gonna
be
basically
migrating
a
ton
of
data.
D
So
we
actually
can
discuss
that
like
how
we
want
to
approach
this
migration,
because,
like
we
in
all
cases,
we
need.
We
need
sre,
help
run
that
but
like
we
are
now
working
on
details
like
how
we
want
to
approach
that.
So
we
have
this
more
details
like
next
week
to
start
asking
for
more
help.
D
A
D
So
brand
like
we
only
had
basically
discussion
on
the
github
pages
weekly
meeting
last
week,
and
vlad
is
right
now
working
on
the
details
and
step
and
iterations.
So
we
don't
really
yet
have
this
like
firm
plan
that,
like
I
could
give
you
link,
but
I
hope
we,
I
will
have
this
plan
like
next
week,
so
we
could
get
familiar
with
at
that
point
I
mean
the
next
week.
Basically
gonna
be
start
of
the
13.7
so
and
as
soon
as
that,
we
would
expect
some
results
would
be.
D
I
don't
know,
probably
like
second
half
of
the
december
or
like
maybe
second
week
of
the
december.
We
need
some
time
like
to
work
through
these
details
later,
so
it's
still
not
immediate,
but
I
guess
like
in
like
two
weeks
or
three
weeks
from
from
from
this
initial
conversation
like
next
week.
We
need
some
help
to
drive
that
with
you.
C
Okay,
I
will
interface
with
you
brent
and
make
sure
that
we,
you
know
you
stay
in
the
loop
as
early
as
possible
to
make
sure
we
can
get
help
from
sre.
I
would
also
say
that
if
we
get
close
to
the
holidays,
we
should
skip
and
do
it
in
january,
meaning
if
we're
not
gonna
like
at
some
point,
we
need
to
make
a
decision
that,
if
we're
not
going
to
finish,
say
before
the
second
week
of
the
summer,
we
should
just
pause
that
work.
Let
the
holidays
go
through.
C
Let
people
enjoy
their
time
off
and
then
continue
early
in
january
to
wrap
it
up
in
early
january,
just
in
case
we,
you
know
somehow
run
into
an
issue
during
the
migration
during
the
holidays,
and
it,
of
course,
will
happen
at
the
worst
possible
time
so
but
I'll
stay
in
the
loop
on
this
and
make
sure
that
everybody
is
is
connected.
So.
E
The
web
service
implementation
as
a
generator,
is
almost
done.
We
currently
believe
that
this
should
be
in
by
the
end
of
the
week.
The
biggest
thing
here
is
that,
once
this
is
done,
we'll
be
unblocking
the
rest
of
the
puma
based
fleets
from
migration
to
communities
where
we
are
seeing
some
other
problem.
E
E
We
do
have
reference
examples
going
in
we're
actually
taking
some
learnings
from
the
implementation
of
the
reference
architectures
into
our
documentation
right
now
and
actually
making
a
default
change
in
how
the
load
balancers
are
set
up.
We
should
be
bringing
that
math
across
into
the
official
documentation,
probably
within
a
week.
E
At
the
moment,
I
don't
have
anything
off
the
top
of
my
head
that
I
need
specifically
from
observability
or
the
sres.
Obviously,
once
we
have
that
metric
in
place,
I
would
strongly
suggest
that
you
know
those
teams
look
at
them
and
make
sure
that
what
our
observations
are
match.
Theirs,
we
primarily
have
based
off
of
what
production
is
using
for
the
configurations
as
a
learning
object
when
we
bumped
into
problems,
as
we
discussed
last
week,.
C
F
A
F
G
Yeah
I
just
wanted
to
raise
a
discussion
item
here
on
mineo,
basically
be
good
to
get
a
understanding
of
the
benefits
that
gitlab
would
experience
by
standardizing
and
centralizing
as
object
storage
as
the
only
method
of
interfacing
with
content
that
does
not
get
repositories
and
the
postgres
database,
mainly
because
from
a
customer
standpoint
you
know
in
a
single
note
experience.
This
is
an
additional
service
to
maintain
and
it
will
add
some
complexity
and
also,
of
course,
need
to
think
about
commissioners
and
standpoint
scaling
the
service.
G
Your
time
upgrades
how
resilient
the
service
is,
how
to
back
it
up
and
restore
it,
and
so
on.
So
it's
you
know,
I
would
say
it's
there'll,
be
increased
work
and
potentially
also
increase
complexity
in
the
stack,
so
it'd
be
good
to
understand
the
benefits
that
we
would
get
by
centralizing.
This
a
lot
probably
imagine
like
coconuts
and
things
like
that,
but
that'd
be
good
to
help
round
out
the
business
case
here
for
standardizing
and
moneo
and
shipping
it,
along
with
all
of
our.
G
Packages
so
yeah.
C
G
Yeah,
well,
I
think
the
proposal
was
to
ship
mineo
in
the
package
and
then
essentially
exclusively
use
that
for
all
content.
That
is
not
the
database
or
the
get
repositories
and
logs
right.
So
we
would
use
cloud
native
objects,
cloud
data,
job
traces.
We
would
use
it
for
uploads
we'd
use
it
for
right
all
that
content
and
we
would
no
longer
use
the
standard
posix
file
of
rewrite
anymore,
and
so
we
would
have
one
single
interface
for
all
of
our
all
that
content,
and
so.
A
B
G
Question
here
is
to
try
to
help
just
sorry.
It's
just
just
the
balance
on
the
other
side
of
it
is
that
it's
a
adds,
complexity
on
the
customer
side
and
troubleshooting
and
support
side
of
things,
and
also
we
have
no
service
to
worry
about
any
kind
of
care
and
feed
and
maintain
for
on
the
omnibus
side
of
things.
C
Isn't
that
complexity
kind
of
relative
right?
If
you
already
have
customers
that
are
using
object,
storage,
then
now
we're
supporting
object,
storage
and
politics,
and
at
some
point
one
of
these
things
is
going
to
get
less
attention.
So
I'm
not
saying
we
should
solve
it
now,
but
I
think
long
term.
The
right
decision
would
be
to
just
say,
object,
storage,
all
the
way
through,
not
necessarily
as
a
blocker
for
whatever
work
we're
doing
right
now,
but
I
I
would
recommend
that
we
just
choose
one
and
then
that
would
eliminate
you.
You
mentioned
code
tidiness.
C
That
would
certainly
eliminate
a
bunch
of
stuff
of
oh
if
you're,
using
this
do
this
and
if
you're
using
that
do
that
plus
multiple
backup
solutions,
et
cetera
et
cetera,
so
maybe
not
right
now,
but
I
long
term.
I
would
definitely
lean
in
support
of
just
having
a
single
thing
that
I
subject
all
the
way
through.
G
Yeah
and
I
can
be
able
to
just
to
continue
this
one
discussion
thread-
I
I
you
know
we
do
have
to
test
object,
storage
right
now,
but
we
use
external
providers,
of
course,
s3,
gcs,
etc,
and
I
think
it's
from
like
a
a
workload
standpoint
carrying
and
feeding
for
maintaining
and
shipping
many
hours,
probably
a
lot
more
than
the
work
we
do
in
testing
the
posix
file.
Input
output
within
my
sense
jason
would
probably
know
more
there,
but
you
know
at
least
from
a
distribution
standpoint
of
things
now.
E
Is
less
about?
Is
it
the
right
choice
down
the
road?
It's
about
documenting
and
understanding
where
all
of
the
engineering
work
is
going
to
be
coming
from,
and
why
this
decision
was
actually
made?
It's
not
going
to
be
a
small
change.
It's
going
to
be
a
highly
impactful
change
across
the
entirety
of
the
organization,
so
we
need
to
make
sure
that
it's
written
down
and
it's
planned
out.
D
D
Second,
like
how
we
handle
existing
data,
so
it
should
be
kind
of
transparent
to
users
using
that,
so
I
don't
know
somehow
somehow
we
instrument
menu
to
expose
existing
file
system,
maybe
behind
the
object,
storage,
interface
and
like
how
it
would
work,
then
there
is
like
all
these
aspects.
That
josh
is
mentioning.
I
think,
like
it's
pretty
big
sense.
D
To
be
honest,
but
on
the
other
hand,
if
you
would
be
able
like
to
to
make
it
only
way
to
access
on
the
right
side,
it
would
make
it
if
you
can't
be
better
but
maybe
like
we
should
start
with
the.
I
don't
know
architectural
blueprint
for
that,
and
I
try
to
gather
these
aspects
and
try
to
investigate
this.
G
Would
be
good
to
take
so
yeah
to
round
up
the
picture?
I
think
that
that
would
be
great,
so
I
can
help
get
that
blueprint,
rolling,
get
an
issue
open
and
start
the
dialogue
there
and
start
capturing
at
least
what
areas
want
to
make
sure
we
collect
in
this
across
it
across
the
whole
application
company.
D
It's
it's
interesting
because,
like
like
even
like
cloud
native,
it's
gonna
affect
like
our
arc
reference
architecture,
sizing,
probably
as
well
and
like
we
need
to
somehow
take
that
into
account
like
measuring
the
impact
of
menial
and
I'm
just
like
asking.
Then
another
question:
like
is
minion
the
best
solution
for
you.
There
are.
Maybe
there
are
better
solutions
to
object.
D
D
So
I'm
just
like
it's
pretty
challenging
like
thing
to
like
to
investigate
and
choose
the
right.
One.
A
Yeah,
I
agree.
C
But
no
sorry,
I
think
we
can
defer
this
to
the
blueprint
like
I
I
think,
as
a
working
group.
We
won't
concern
ourselves
with
this,
because
we
can
still
operate
with
politics
and
still
deliver
on
the
things
that
the
working
group
has
to
deliver,
but
then
tackling
this
given
the
how
big
a
project
it
might
turn
out
to
be
then
going
through
the
so
the
blueprint
route
is
probably
the
right
thing
to
do,
because
I
I
would
imagine
we
wouldn't
do
any
work
on
this
anytime
soon.
D
A
H
Yeah
just
fyi,
so
I
created
an
issue
to
kind
of
track.
Some
of
the
operational
responsibilities
of
supporting
the
first
gitlab
managed
instance
created
this
after
we
discussed
with
the
account
team.
Some
of
the
tactical
aspects
of
you
know
who's
first
of
mine,
for
supporting
this.
Whether
tickets
go
to
customer
support
for
first
and
then
when
do
they
come
to
infrastructure.
H
So
I
wanted
to
get
this
into
an
issue
and
the
goal
would
be
to
drive
alignment
between
the
various
teams
on
some
of
those
aspects
and
then
also
jerry
there.
I
know
we
had
a
few
open
questions
in
our
dock,
like
to
use
that
as
the
place
to
track
chasing
answers
for
those.
C
Yeah,
are
you
the
dri
here?
Are
you
expecting
me
to
be
the
ri
or
someone
else
at
the
ri.
H
C
All
right
yeah,
just
let
me
know
if
you
need
anything
from
me.
Obviously
you
have
other
info
folks
here
that
that
have
a
stake
on
this
as
well,
so
anything
we
can
do
to
help
answer
those.
C
That
is
everything
we
have
in
the
agenda
today.
So
unless
anyone
wants
to
raise
anything
else,
one
point
I
am
hopefully
this
week
going
to
figure
out
how
I
get
permissions,
to
update,
to
upload
to
youtube
and
I'll
stop
pestering
people
to
do
it
for
me,
so
I
just
need
to
find
30
minutes
to
chase
that
down
and
ask
the
right
person
and
get
my
access
taken
care
of.
So
I
can
upload
these
videos,
so
my
apologies.