►
From YouTube: 2021-02-01 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).
A
Second
food,
so
the
pages
migration
was
completed
last
week
with
a
bunch
of
improvements
to
speed
it
up,
and
I
think
alejandro
is
the
sre
assigned
to
getting
this
done
in
production
and
from
what
I
saw
on
the
issue,
we're
just
waiting
on
like
approvals
and
a
review
to
kick
it
off.
So
hopefully
that'll
get
done
in
short
order
and
we
can
kiss
nfs
goodbye
forever.
B
Yeah,
let
me
let
me
know
if
that
approval
doesn't
go
forward.
I
saw
the
ask
I'll
keep
tabs
on
it,
but
I
might
I
might
drop
it
tomorrow
so
in
if
it
hasn't
gone
forward
by
to
like
in
our
one-on-one
tomorrow,
I'll
go
ahead
and
review.
A
It
all
right
yeah.
I
know
that
alberto
was
wrapped
in
incidents
all
day
so
but.
D
Yeah,
my
my
apologies,
as
I'm
ran
a
few
circles
this
morning.
I'll
get
the
link
in
here
in
a
minute,
but
essentially
we
are
looking
at
a
possible
solution
to
do
the
automation
for
the
pages
and
oauth
authentication
so
that
we
can
properly
enable
access
control.
We
have
a
methodology
play.
We
just
need
to
do
a
full
investigation
of
it
and
how
it
impacts
some
of
the
other
oauth
consumers.
D
F
Jason,
can
you
edit,
like
I
tried
to
take
the
notes,
but
you
were
too
fast
and
my
cat
is
rustling
behind
me,
so
I'm
distracted.
A
All
right,
camille.
E
Sorry
I
had
another
meeting
and
I
kind
of
came
right
now,
but
we
kind
of
like
spent
a
little
a
few
moments
more
with
vladimir
on,
like
disconnecting
serving
the
migrated
data
to
users
from
migrated.
So
migration
is
like
completely
background
process.
That's
gonna
happen
that
we're
not
gonna
expose
any
users
to
migrated
data
and
we
can
decide
when
we
actually
do
that
and
we
can
kind
of
also
roll
out
that
asynchronously
with
the
percentage
rollout.
E
E
A
So
I
guess
once
a
migration
is
done
or
at
some
point
where
we're
confident
we
can
just
flip
the
switch
and
migrate
and
sort
of
show
that
data
to
users.
Yes,.
E
E
Can
decide
whatever
we
want
to
do
like
there
is
a
ability
to
mark
a
specific
project
or
like
the
percentage
rollout
or
like
full
rollout.
Like
I
mean
we
will
decide
that
like
when
we
start,
we
will
see
like
how
the
actual
data
migration
gonna
look
like
and
how
what
what
additional
steps
we
need
to
take.
But
it's
flexible
on
that.
A
All
right,
I'm
gonna,
ask
them
for
something
really
stupid,
but
since
I've
seen
random
stuff
happen
before
do
we
have
an
issue
for
that.
So
we
you
know
six
months
later.
We
don't
assume
that
the
other
hand
actually
enabled
that
like
can
we
make
sure
that
we
at
some
point
say
hey.
Did
we
remember
to
flip
that
switch.
E
I'm
gonna
ensure
that,
as
part
of
this
issue,
there
is
a
checkbox
that
says
that
we
serve
migrated
data
because,
like
I
mean
migrating
data
without
surfing
this
later,
it's
kind
of
pointless.
A
A
C
Okay,
so
I've
got
this
discussion
item
here.
It's
today
is
the
first
day
of
the
new
fiscal
year.
I
hope
you
all
received
your
champagne
and
had
that
in
your
morning
or
afternoon.
We
we
have
certainly
a
lot
of
important
things
to
to
kick
off
in
the
beginning
of
the
year,
and
what
I'm
proposing
here
is
that
we
adjust
the
scope
and
kind
of,
in
a
nutshell,
end
up
exiting
this
work
group
earlier,
but
with
a
reduced
scope.
C
The
reasoning
for
this
is
really
to
shift
some
of
our
focus
to
some,
I
think
related
issues.
C
One
of
them
is,
is
jerry's
going
to
be
starting
off
kind
of
the
the
third
round
of
of
moving
us
towards
the
database
scalability
and
in
really
database
sharding,
and
so
we're
at
the
point
where
we
we
definitely
need
that
to
to
actually
achieve
basically
sharding
in
production
at
the
end
of
it,
and-
and
hopefully
this
this
tribe
will
will
get
us
there
and
then
and
then
there's
some
other
new
initiatives
like
gitlab
private
is
kind
of
an
interesting
one
where
that's
an
initiative.
C
That
is
not
fully
at
the
point
where,
like
we're,
you
know
full
steam
ahead
and
implementing
it,
but
it
certainly
looks
like
that.
We're
headed
that
way.
It's
on
the
company
okrs
it's
on
the
product
and
engineering,
okay,
ours,
it's
an
infrastructure,
it's
it's!
You
know,
we've
basically
been
asked
to
make
room
for
it,
and
so
that
and
and
other
things
here,
basically
whatever
pose,
is
we've
talked
about
the
nfs
work
like
we
just
obviously
need
to
finish
that
and
and
not
not
deviate
from
from
that.
C
That's
a
great
success.
There
suggests
that
we
keep
the
work
that
we've
targeted
for
helm,
because
that
that
really
is
critical
in
supporting
a
lot
of
these
other
efforts,
but
the
the
other
three
and
I'm
kind
of
going
off
of
the
order
of
the
deliverables
that
we
have
on
the
working
group
page
suggesting
that
we
remove
operator
stateful
modes
and
day,
two
automation,
it's
not
that
those
things
aren't
important
or
need
to
get
done.
C
I
think
for
each
one
of
them
there's
a
balance
of
how
timely
is
it
relative
to
our
other
initiatives
for
one
of
them
the
stateful
knows,
I
think,
there's
there's
still.
C
I
think,
there's
there's
some
remaining
question
of
the
best
way
to
to
approach
that
versus
you
know
the
the
evolution
of
kind
of
managed
services
we
can
integrate
with
and
everything
and
then
the
the
last
item
there
is
that
since
jerry's
going
to
be
facilitating
another
working
group,
we
really
should
switch
to
another
facilitator
to
primarily
focus
on
the
kind
of
creative
work.
That's
left
for
for
helm.
So
so
I'll
stop
talking
here
and-
and
I
would
love
to
get
more
insight
and
or
opinions
or
thoughts
on
this.
G
I
have
a
question
about
the
health
charts
work
remaining
work
for
the
home
charts,
so
looks
like
the
two
items.
There
are
moving
the
gilab.com
nodes
for
web
api
and
also
pages.
So
is
that
operational
work
or
is
that
development
work.
C
So
I
think,
there's
a
combination
of
of
work.
That's
still
left
in
correct
before
I
think
marin.
You
know
a
little
bit
more
about
this,
but
the.
But
as
far
as
you
know,
the
the
distribution
work
as
far
as
what
the
full
support
of
all
of
those
hosts
within
the
helm,
charts
is
the
first
part
of
it
and
then
actually
implementing
it
into
production
is
the
the
second
part
of
it,
but
there's
still
work
left
in
both
of
those
areas.
I.
C
C
And
if
I'm
wrong
on
that
and
it's
just
infrastructure
work
solely
remaining,
then
then
maybe
that
is
something
we
can.
We
can
address
to
make
sure
that
that
we're
not
suggesting
that
there's
work
elsewhere
if
it
doesn't
exist
so.
G
In
conjunction
with
the
other
work
that
we've
got
going
on.
Okay,.
C
Yeah,
and
also,
I
think
I,
like
you,
know
another
thing
I
you
know
I
mentioned
this
is
not
necessarily
a
value
statement
on
any
of
these
things,
but
the
there's
also
this
understanding
and
recognition
that
there
is
operator
work
that
is
going
to
continue
regardless
and
that
is
really
important
for
the
product
but
like
having
it
necessarily
noted
in
this
working
group,
isn't
particularly
adding
anything
else
to
the
importance
of
it.
So.
D
In
regards
to
the
the
items
in
infrastructure
and
what
needs
future
changes
in
helm,
charts
some
things,
we're
learning
as
we
go
towards
the
larger
deployments,
specifically
regarding
scaling
patterns
and
things
like
this.
But
I
can
tell
you
that
it
looks
like
most
of
the
functionality
is
in
play
and
we're
able
to
schedule
production
items
pretty
quickly
when
it
comes
to
distribution,
specific
work,
and
we
have
members
of
the
delivery
team
who
are
showing
evidence
of
being
capable
contributors
directly
to
the
charts
themselves.
F
So
I
would
also
like
to
suggest
that
we
don't
remove
the
state
for
workflows
that
we
need
to
migrate,
because
that
is
going
to
be
very
important,
not
only
for
dot
com
but
for
others,
whether
it's
private
or
someone
something
else.
The
only
thing
I'm
currently
not
certain
about
is
whether
we
need
to
think
about
database
on
kubernetes.
F
That
is
something
that
I
don't
think
many
people
do
well
by
the
time
we
get
to
answer
that
question.
We
have
quite
a
lot
of
work
to
do
to
make
these
type
of
things
ready
for
production
workloads,
which
includes
yeah
multi-large,
whatever
kind
of
setup
you
want
to
do
like
it's
a
completely
different
story.
F
When
you
say
to
someone
bring
your
own
database,
everything
else
you
can
use
with
this
single
setup
of
kubernetes
compared
to
yeah,
I
just
do
state
less
and
then
italy,
plus
ready,
plus
postgres,
plus
plus
plus
you
don't
need
to
think
about
for
kubernetes.
So
my
suggestion
would
be
to
keep
the
stateful
notes
as
part
of
this
group.
D
D
F
D
F
A
So
then
force
is
what
we're
saying
that
some
stateful
targets
seem
to
be
fairly
straightforward,
giddaly
and
redis
being
two
candidates
that
we
that
we
do
think-
and
I
agree
with
that
assessment,
but
leaving
postgres
for
who
knows
when,
for
all
intents
and
purposes,
because
that
the
moving
parts
on
that
one
are
are
rather
complicated.
A
Like
italy
and
redis
make
a
lot
of
sense
to
me,
because
single
process
either
talking
to
memory
or
talking
to
this
big,
very
stable
thing.
So
should
we
use
then
in
steve's
proposal,
keep
nfs
keep
the
helm
stuff
keep
stateful,
but
being
very
selective
with
just
saying.
Italy
and
red
is
postponing
progress
for
some
time
in
the
future
splitting
out
operator
into
the
tone
thing,
because
it's
a
rather
complex
beast
so
that
might
spawn
another
working
group
or
be
a
separate
project.
C
I
mean
what
we
called
multi-large
in
our
infrastructure
and
the
the
more
immediate
thing
that
is
turning
up
in
fy
22
is,
I
don't
know
I
guess
multi-mediums
or
multi-smalls
as
far
as
like
gitlab
private,
the
but
being
able
to
I
mean
I'd,
say
especially
italy.
Being
able
to
move
that
into
kubernetes
seems
like
it
makes
a
lot
of
sense.
C
I
think
the
with
red
is
to
a
certain
degree,
but
certainly
for
postgres,
we'll
have
to
see
how
things
go
with
with
gitlab
private,
but
I
mean
there's
a
very
real
possibility.
You
know
that
we'd
be
looking
at
managed
service
integration.
You
know
for
that,
but
we
have
to
see
how
that
you
know
I'm
jumping
way
ahead
into
a
project
that
hasn't
even
started
yet,
but
just
from
a
scaling
standpoint
is
is
probably
somewhat
likely
so
yeah.
I
agree
with
that
change.
I
think
that's
that's
reasonable.
B
So
when
we
started
this,
I
think
I
forget
the
timing
of
this,
and
this
is
just
my
recollection
and
and
christmas
being
in
between
here
but
like
I
thought.
The
idea
was
that
we
would
get
this
done
so
that
galact
private
was
feasible.
Do
we
think
we
can
move
forward
with
gitlab
private
independent
of
helmand
operator
being
available,
or
is
it
that
we're
changing
scope
because,
like
we
have
other
things
to
focus
on,
but
this
work
still
needs
to
get
done
and
by
the
way
the
deadline
is
now.
C
April
well,
so
maybe
I'll
go
from
the
maybe
I'll
go
from
the
last
item
there
so
that
there's
not
a
deadline
for
gitlab
private
around
april.
There's
a
there's,
a
sales
milestone
around
that,
but
there's
there's
quite
a
few
different
options,
so
we
we
don't
need
to
deliver
gitlab
private
by
april.
I
know
that's
that's
been
I've
that
has
been
noted
in
the
in
a
number
of
of
conversation
or
it's
been
brought
up
in
a
number
of
conversations.
So
I
think
there's
a
lot
of
okay.
C
B
B
And
like
I'm,
just
trying
to
figure
out
like
how
best
to
help
in
this
situation
so,
like
obviously,
there's
still
some
work
on
the
development
side,
it
sounds
like
there's
still
work
on
the
infrastructure
side.
G
B
B
So
john,
maybe
work
with
marin
to
figure
that
out
would
that
be
a
reasonable
request.
G
Yeah,
okay,
yeah
america
me
just
think
offline
to
see
what
makes
best
sense
here
to
find
a
new
facilitator
for
this
working
group.
B
C
So
as
a
as
a
next
step
here,
jerry-
and
I
will
create
a
nnr
and
share
that
with
the
group-
and
we
can
continue
to
have
some
some
conversation
around
this
just
to
get
the
get
the
change
right
so
that
basically
starting
you
know
next
week-
and
we
can
we
can
have
it
addressed-
should
be
the
the
target
here.
B
A
F
A
That
is
all
on
the
agenda.
Thank
you.
Everyone
have
a
good
one
and
please
order
me
some
mexican
food.