►
From YouTube: 2021-05-24 Multi-Large Working Group Weekly
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
Okay,
welcome
everyone.
This
is
the
multi-large
working
group
24th
of
may
2001..
So
let's
kick
off
with
what's
been
done
and
john,
you
have
the
first.
A
Yeah,
sorry,
yes,
actually
a
great
achievement,
so
we
completely
disconnected
nfs
from
the
gillette.com
and
it
was
a
great
outcome
after
you
know
several
I
can
force
discussions.
B
Absolutely
and
then,
following
on
a
great
week,
we
got
the
api
service
100
migrated
running
on
production
last
week
as
well,
so
huge
milestone
there.
So
next
we
just
have
the
the
tidy
up
pieces
to
do
to
finish
this
migration
off
so
tidy
up
pieces
and
fine-tune
the
setup,
but
we
have
traffic
running
and
it's
looking
good.
C
B
Absolutely
absolutely
for
both
of
them
great
and
then
on
the
what's
happening
next,
so
in
delivery,
we're
planning
to
spend
june
paying
down
some
tech
debt
that
we
have
and
then
preparing
to
go
into
the
web
fleet.
So
we
just
want
to
make
sure
that
we
have
learned
everything
we
have
from
the
api
service
migration
and
get
things,
get
metrics,
updated
and
run
books
and
everything
in
place
before
the
web
moves
over
great
any
comments
on
either
what's
been
done
or
what's
happening
next,
no
great,
so
blockers.
B
So
these
are
kind
of
the
early
stage
as
we
get
closer
and
into
the
web
fleet.
We'll
certainly
have
additional
blockers
that
we
come
across,
but
we
have
a
few
that
are
already
known
so
just
to
share
those
for
visibility.
So
we
have
workhorse
graceful
shutdown
which
I'll
just
read
your
comment,
john.
Since
we've
been
on
the
issue,
so
it's
scheduled
in
for
14.1,
so
that
will
be
coming
in.
B
We
have
an
interesting
one
under
b,
which
is
we
need
to
find
a
way
to
configure
the
nginx
interest
to
support
web.
So
we
made
a
small,
short-term
change
which
allowed
us
to
migrate
the
api,
so
we'll
need
to
find
a
broader
way
to
handle
that
are
some
options
on
there
which
we'll
be
investigating,
but
there
is
a
request:
if
distribution
have
any
time
to
help
us
think
those
things
through.
If
you
have
any
other
ideas,
that
would
be
much
appreciated.
B
Okay,
and
then
c
is
is
a
potential
blocker,
so
we
don't
know
how
much
this
affects
the
web
yet,
but,
as
we
went
through
the
api
service
migration,
there
were
a
number
of
environment
variables
and
they're
not
settings
inside
the
application.
B
So
we
need
to
review
where
the
web
has
similar
settings.
It
seems
possible,
it
will
do
given
how
the
api
was
set.
So
those
would
be
good
ones
now
I
don't
know
jasmine.
You
want
to
verbalize
your
your
comment.
There.
C
Sure
so
we
do
have
an
open
discussion.
That's
a
follow-up,
we're
proposing
a
method
to
be
able
to
pull
those
environment
in
from
secrets,
basically
using
a
known
pattern
elsewhere
in
the
community
and
just
making
this
possible
for
you
folks
as
quickly
as
possible,
without
having
to
do
setting
of
environment
variables
in
a
unsafe
way.
C
We've
implemented
this
short
term
just
so
that
we
you
can
move
forward
with
production,
we're
not
writing
documentation
for
it
right
now,
because
we're
still
discussing
and
evaluating
what
I
do
want
to
note
is
that
this
is
something
that
is
actually
a
problem
overall,
because
if
we
have
to
deal
with
secrets
that
are
not
being
held
in
a
safe
manner,
it
doesn't
matter
if
it's
in
cloud
native
doesn't
matter
if
it's
case
doesn't
matter
it's
an
omnibus
in
omnibus.
C
If
it's
in
the
rb
file,
which
is
where
you
set
environment
variables,
it
then
actually
gets
written
to
the
file
system
again
under
the
run,
its
environment,
setup
and
then
you've
got
two
copies
of
it:
unencrypted
on
disk
right.
So
there's
a
long
running
epic
in
distribution
to
handle
these
kinds
of
things,
and
we
need
buy-in
from
the
entire
application
suite,
and
this
is
just
one
more
impact
of
that.
D
Jason
follow
a
question
to
that.
This
still
sounds
like
a
workaround
to
me
like.
Is
there
a
reason
why
the
application
itself,
so
you
know
either
through
a
config
file
or
through
setting
the
database,
can't
do
this
instead,
so
on
a
different
level.
D
The
reason
why
I'm
asking
that
is
we
we
are
going
to
have
to
automate,
hopefully
hundreds
of
environments.
So
if
I
have
to
go
or
the
team
has
to
go
and
do
these
things
separately
for
separate
situations
like
that's,
that's
gonna
be
overhead.
That
is,
is
really
high.
We
did
it
once
for
dot
com
and
it
was
already
high.
So
is
there
a
way
for
us
to
just
split
all
of
these
items
into
separate
issues
and
put
them
on
the
higher
level,
meaning
within
the
application,
rather
than
the
workaround
on
the
distribution
level?.
C
Correct
I'm
100
behind
you.
You
should
not
be
handled
this
way,
I'm
just
trying
to
make
sure
that
we
don't
block
it
like
that.
Comes
migration
anymore.
Then
we
absolutely
have
to
this
is
not
long-term
fix.
This
is
make
it
not
a
blocker.
D
Okay,
so
can
we
do
them
both
like?
Let's
make
sure
that
we
have
also
the
issues
created
for
this,
and
we
can
then
use
the
product
prioritization
process,
and
I
think
soon
this
is
going
to
become
blocker
for
others
not
only
for
dot
com.
E
B
B
Chun
should
we
maybe
go
through
these
and
work
out,
because
I
think
the
question
I'm
happy
to
do
the
splitting
out
just
make
sure
they
go
in
the
right
ownership.
Should
we
collaborate
on
making
these
land
in
the
right
place.
F
Yeah
I
just
wanted
to
kind
of
re-bring.
This
up
mark
had
commented
most
recently
about
bringing
somebody
into
the
conversation,
and
I
wasn't
sure
if
anybody
had
any
initial
thoughts
or
before
we
kind
of
move
forward,
I
figured
distribution
can
pick
it
up
if
needed,
and
I
guess
we
can
just
reach
out
if
we
have
any
problems,
but
if
anybody's,
post
or
json,
if
you
have
any
thoughts
on
this,
this
testing
that
we're
gonna
do.
C
C
D
I
would
like
to
see
delivery
participate
in
this,
aiming
like
not
necessarily
being
deleted,
but
definitely
like
taking
apart,
because
this
is
gonna
be
a
large
learning
experience
for
everyone.
B
Okay,
yep
fair
point:
does
anyone
feel
comfortable
us
doing
this
without
getting
involved?
Should
we
find
a
way
to
coordinate
the
three
teams-
and
I
guess-
quality
as
well,
at
least
for
guidance
right
on
how
to
do
this?
B
E
Yeah,
let
me
start
with
tim
zalman
he's,
probably
the
better
choice.
Zj
might
be
the
rep,
but
I
just
want
to
make
sure
tim's
aware
of
kind
of
what's
going
on
here.
Sure.
B
Okay,
that
makes
sense
all
right,
I'll,
open
up
an
issue,
so
we
can
at
least
start
in
fact
I'll
I'll
continue
on
here.
I'll,
add
a
comment
to
the
to
three
four
seven:
four:
we
can
sync
from
there.
F
Okay,
yeah,
I
can
I
can.
I
can
drive
this
too.
F
B
Great
are
there
any
other
discussion
points
that
people
want
to
bring
up.