►
From YouTube: 2021 04 28 Sharding Group Sync
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).
C
B
B
C
C
I
think
this
can
be
relatively
short.
There
was
a
long
call
in
the
morning
already
with
the
engineering
team.
You
know,
it's
recorded
feel
free
to
rewatch
it.
The
notes
are
below.
I
just
thought
I'd,
give
you
the
sort
of
the
short
overview
for
efficiency,
so
there
was
some
discussion
on
the
work
that,
before
I
start,
is
that
agreeable
to
everybody
here?
C
C
C
I
think
there
was
also
some
some
sort
of
good
discussion
around
is
sharding
or
application
level
charging
going
to
be.
The
cure
all
for
every
problem
that
we
face
with
database
scalability
and
I
think
we
kind
of
align
on
the
fact
that
that's
not
the
case
right.
There
are
many
other
things
that
also
need
to
happen
that
we
are
aware
of,
and
the
sort
of
working
working
group
database
scalability
will
address,
but
the
focus
of
the
the
team
or
this
specific
group
of
people
is
to
work
on
a
sharding
based
solution.
C
So
it's
the
way
I
phrased
it
is
it's
not
like.
We
shouldn't
do
sharding
and
just
charting,
but
it's
like.
We
should
attempt
to
do
this
and
then
many
other
things
you
know
to
help
with
our
scalability
right,
but
we
should
remain
focused
on
sort
of
what
we're
being
asked
to
do
here,
which
is
to
work
on
on
charting.
C
C
There
was
a
sentiment
that
vertical
application
level
shardings
the
fact
of
the
same,
taking
all
of
the
ci
tables
and
putting
them
into
separate
a
separate
logical
database
has
overall
more
certainty
associated
with
it,
as
in
you
know,
I
think
the
team
feels
confident
that
that
is
something
that
could
be
done,
but
that-
and
that
makes
it
a
good
sort
of
fallback
solution
right,
whereas
the
more
interesting
and
maybe
also
more
beneficial
approach
right
now
is
the
horizontal
application
level
shining.
C
You
know
we
learned
a
lot,
but
you
know
if
that
ends
up
being
blocked
or
impossible
right
now.
You
know,
then
that
may
be
the
next
thing
to
investigate
that
has
more
more
certainty.
Can
I
make.
D
C
E
Yeah,
why
are
people
stuck
in
this?
Why
are
people
stuck
in
sharding
is
the
only
solution
like?
Are
they
folks
in
this
group
not
reading?
What's
going
on
in
the
database
capability,
where
we
outline
all
these
options,
you
know
what
I
call
entity
or
service
split,
which
is
the
thing
that
you
just
mentioned,
or
the
time
decay
stuff
like
there
are
people
working
on
those
problems
so
like
this
seems
to
be
a
repeating
theme.
I've
heard
this
comment
over
the
last
10
days,
or
so
that.
C
E
C
E
We
should
make
sure
they
read
the
working
group
page
so
that
they
find
it
in
writing
that
it's
happening
elsewhere,
and
we
should
also
ask
them
to
keep
track
of.
What's
going
on
in
the
in
the
working
group
like
these
are
related,
but
you
know
some
of
us
attend
both
things.
I
know
not.
Everybody
does
and-
and
we
actually
don't
want
everybody
to
be
in
the
working
group
meetings,
because
that's
a
lot
of
people,
but
we
should
definitely
make
an
effort
to
or
they
should
make
an
effort
to
keep
up
with.
What's
going
on.
A
Yeah,
that's
a
good
yeah,
that's
a
good
point
so
because
I
I
was
not
in
the
apac
media,
but
we
mentioned
multiple
times
that
there
are
two
streams
in
this
working
group.
One
is
of
course,
clearly
charity.
The
other
ones
are
working
on
other
proposals,
the
data
patterns.
So
please
help
to
reiterate
this
to
the
team
that
there
are
another
group
of
people
working
on
the
other,
the
other
stream.
D
I
I
have
this
story
about
like
why
we
get
a
lot
of
database
stuff,
because
when
you,
when
we
talk
starting
without
starting
like
on
database
and
like
this
already
implies
a
lot
of
like
the
search
page
first
space
for
the
solution
that
you
are
looking
at.
It
implies
a
lot
of
like
database
patterns
and
like
approaches
for
solving
this
particular
problem.
So
I
I
think,
like
we
actively
try
to
like
move
this
understanding
beyond
the
database.
Databases
just
one
of
the
data
stores,
but
really
it's
like.
D
B
Yeah
and
gary
to
give
some
feedback-
and
I
don't
know
if
this
is
the
answer,
but
I
think
it's
an
answer.
I
think
part
of
the
reason
the
focus
may
seem
like
it's
solely
on
charting
right
now
is
we
really
only
have
two
and
a
half
people
working
on
it?
I
know
I
understand
yeah
and
I
I
think,
there's
concurrent
stuff
going
on
right
with
the
web
hook.
Logs
investigation,
that's
being
done
they're.
Also
in
parallel
to
investigating.
Can
we
shard
that
away
to
another
database
they're
also
looking
at
the
time
decay.
B
E
E
We've
implemented
some
of
them.
If
there
are
more
patterns,
we
should
by
all
means,
submit
them
and
say
hey.
You
know
I
thought
about
this
and
give
us
two
examples
for
however
many
and
off
we
go
right.
So,
on
the
one
hand,
nothing
says
in
stone.
On
the
other
hand,
I
want
them
to
be
aware
that
there
is
all
this
work
happening.
So
you
know
yes,
we
are
looking
at
bigger
picture
anyway,
so
I
think.
C
It
cuts
both
both
ways
right,
it's
like
when
people
start
like
onboarding
into
this.
They
start
thinking
about
the
problem
space
right
and
then
they
start
like
saying
like.
But
what
about
this
concern
and
that
concern-
and
this
concern
over
here
right
and
then
I
think
the
the
one
thing
is
to
say
like
yes,
you
know
this
is
something
people
think
about
right,
but
also
to
say
this
specific
group
here
will
look
at
this
subset.
You
know
of
of
problems
right
and
there
are
other
people
doing
other
things
right,
yeah,
that's
my
point
right.
C
E
Just
that
the
reading
is,
there
seems
to
be
a
certain
amount
of
nervousness
of
nervousness
of.
Are
we
only
doing
sharding?
Because
you
know
there
is
a
bunch
of
other
things
we
can
do,
and
I
just
want
them
to
be
aware
and
sort
of
be
at
ease
with
the
fact
that
yes,
yes,
look
at
the
five
things
we're
working
on,
and
so
they
they're
not
like.
Oh
my
god,
here's
this
box,
we
put
you
in
here
and
anyway,
yeah.
D
Yes,
I
I
think,
like
it's
tricky
because,
like
we
all
understand,
the
horizontal
is
harder
vertical
is
easier,
but
also
there
is,
I
think,
like
this
kind
of,
like
I
guess,
simplification
of
the
problem
that,
like
we
try
to
do
something
that
is
easier
and
more
comfortable
where
horizontal
is
harder
and
less
comfortable
on
doing,
but
also,
I
think
it
also
kind
of
tries
to
answer
some
of
the
needs
of
the
product
development
and
that
er
kind
of
like
hard
to
do
with
the
vertical
way.
D
So
I
guess
like
we
are
still
in
the
face
of
like
getting
to
this
mindset
of
like
truly
trying
out
something
that
is
fully
uncomfortable
yet
and
kind
of.
We
know
that
we
can
do
vertical.
We
know
how
we
could
do
it.
We
know
like
how
it
would
work,
how
you
would
maybe
even
scare
that
I
mean-
maybe
it's
not
written
in
the
words
exactly,
but
I
think
everyone
has
very
good
perception
how
it
would
look
like
and
like
what
would
the
consequences
of
running
that,
but
not
like.
D
We
have
like
a
very
little
of
the
knowledge
how
it
would
do
if
we
would
do
horizontal
one
so
right
now.
I
think
I
see
this
as
a
challenge
like
on
tuning
on
something
that
is
harder
to
think
to
use
this
proof
of
concept
time
to
do
this
kind
of
discover
of
like
something
more
complex,
maybe
maybe
different
like
in
the
execution
and
if
it
really
like,
doesn't
work
out.
We
we
didn't
have
like
a
fallback
with.
I.
D
D
C
C
I
think
that
will
be
really
good,
but
I
think
we
need
to
be
mindful
to
not
spend
a
super
long
time
on
it
when
just
for
the
sake
of
it
right,
if
it
gets
clear
that
it's
it's
not
the
right
way,
we
need
to,
we
need
to
you
know,
remain
a
bit
flexible,
but
I
agree
I'll
move
on
so
tong.
C
You
know
sort
of
just
does
it
is
kind
of
my
my
my
perception
so
he's
using
the
multi-database
support
in
rail
6.1,
and
this
is
now
maybe
too
enthusiastically
phrased
so
camille
needs
to
correct
me.
He
has
kind
of
put
a
project
already
onto
a
different
shard,
but
it
breaks
in
weird
ways
right.
The
ids
are
wrong
right,
all
of
those
things,
but
he's
kind
of
done
a
bit
of
this
already
right
and
that's
quite
interesting
just
to
to
see
you
know
to
like
understand
what
breaks.
C
D
D
I
I
think,
like
one
of
the,
why
I
think
it's
like
very
important
point
is
like
we
actually
managed
to
put
some
data
on
another
chart
in
another
context,
and
now
the
question
is
like
how
we
can
randomly
access
the
data
from
various
places
and
like
continue
saving
the
data,
and
this
is
where,
like
a
lot
of
this
complexity,
is
really
in
this
proposal.
So,
yes,
like
there
is
gonna,
be
a
lot
of
things.
C
We
should
we
should
share
that
as
a
as
a
win
for
the
team
in
the
next
working
group
to
demonstrate
that
you
know
there
is
a
lot
of
activity,
not
overselling
it,
but
but
I
think
showing
that
this
is
a
thing
that
has
happened.
C
Okay,
so
the
action
items
actually
like.
I
think
the
team
is
now
fully
aligned
on
focusing
on
continuing
the
horizontal
application
level.
Charting
database
level
charting
is
shelved
the
vertical
chart
level
vertical
application
level
charting
is
the
fallback
option,
and
so
uric
and
camille
and
tong
will
raise
more
issues
in
the
epics
that
investigate
some
of
these
next
steps
for
the
for
the
poc
assign
dates
to
them
as
they
see
fit,
and
then
maybe
we
need
a
clean
up
session.
C
You
know
to
like
get
the
the
epics
in
a
better
state
at
some
point,
but
here
we
are
that's
kind
of
like
a
put
like
a
summary
in
here.
That's
the
that
happened
in
apac
kind
of.
A
D
No,
only
horizontal
signing
would
start
by
the
top
level
namespace
yeah.
Instead,
like
we,
we
start
by
the
function.
We
could
say
like
ci,
all
the
ci
tables
go
into
separate
database,
but
it's
also
kind
of
risky.
D
On
the
other
hand,
because
gitlab
is
like
very
interconnected
set
of
the
features,
so
it
gets
risky
about
like
the
concept
of
resiliency,
for
example,
if
let's
say
this
chart
with
the
ci
data
goes
down,
it's
very
likely
that
majority
of
the
github
will
not
function
as
well,
because
we
fetch
status
cells
and
data
in
many
places
from
this
chart.
So
now
to
answer
simply
your
question.
A
No
thank
you
so
just.
D
A
Thank
you
just
a
slight
caution
that
I
think
what
part
of
what
a
city
is
looking
for
is
the
ability
to
scale
across
multiple
regions
or
a
group
of
customers.
So
we
need
to
keep
that
in
mind
of
our
solution.
Design.
C
Yeah,
so
the
that's.
Why
also?
I
think
this
is
one
of
the
factors
why
what
we're
doing
now
is
focused
on
that
right,
but
this
is,
this
is
has
uncertainty.
It
may
not
be
feasible.
Ultimately,
we
don't
know,
and
then
another
option
would
be
what
what
can
you
describe,
but
it
has
exactly
those
downsides
where
that
may
become
really
hard
right.
So
it's
another
thing
to
to
take
into
account.
Yeah.
D
Idea,
it's
like
it
might
end
up
that
it's
not
feasible
or
like,
like
it's
gonna,
be
too
complex
and
then
like
we
gonna
have
like
the
fallback,
which
we
know
that's
gonna
work,
but
it's
gonna
have
different.
B
Cool,
thank
you
yeah,
and
so
in
my
opinion-
and
this
may
be
a
little
too
blunt,
but
we
need
to
solve
the
database
scalability
problem
before
we're
worried
about
features
and,
and
that's
kind
of
a
request
of
sids
right
and
again
being
super
blunt
here.
But
we
have
a
wall,
that's
in
our
future
and
although
we
don't
want
to
paint
ourselves
into
a
corner
with
some
of
the
solutions
we're
looking
into,
we
need
to
solve
the
scaling
problem
first
and
then
be
concerned
about
some
of
the
other
requests
that
are
coming
down.
So.
D
Yeah,
so
I
guess
like
really
like
what
we
end
up
with.
It
really
depends
on
the
execution
complexity,
because
I
I
don't
know
like
what
we
end
up
with.
It
really
depends
on
many
factors
right
now
that
we
need
to
evaluate-
and
I
I
don't
really
have
anything
else,
but
I
think
like
there
are
so
many
sites
really
like
to
discover
yet
that
we
are
not
aware
at
this
point.
C
Okay,
should
we
move
on
to
some
of
the
items
that
are
relevant
for
this
meeting?
C
Okay,
so
I
just
I
saw
jerry's
comment
on
yet
more
definitions,
and
I
opened
an
mr
already
that
I'm
going
to
work
on.
I
think
there
are
some
things
missing
in
our
terminology
right
now,
right
that
we
should
clearly
define
among
those
is,
you
know
like
what
does
vertical
application
level
charting
mean?
What
does
horizontal
application
sharing?
What's
table
partitioning?
What's
working
vertical
partitioning,
I
think
we
should
just
add
them.
C
My
suggestion
would
be
to
like
give
it
give
it
a
try
right
and
then
I'll
ping
like
jerry
for
initial
review
on
this
and
come
here,
and
then
we
can.
We
can
get
that
merged,
but
I
think
that
would
be
useful
for
me
because
there's
a
lot
of
terminology
that
is
used
very
specifically,
I
think,
having
clear
definitions
helps.
E
So
you
know
this
is
why
I'm
like
racially
opposed
to
using
partition,
because
it
means
different
things,
and
so,
when
we're
writing
automation,
we're
going
to
make
assumptions
and
we're
going
to
name
variables
and
we're
going
to
do
a
bunch
of
things
and
now
we're
going
to
unleash
automation
on
multiple
database
clusters.
So
the
more
specific
we
are-
and
I
mean
I-
I
wrote
a
comment
somewhere
about
this
whole-
I'm
not
going
to
mispronounce
this
masefu
thing
of
you
know
how
the
terminology
should
meet
it.
E
It
does
become
important,
so
I'm
I'm
all
in
favor
of
being
as
specific
as
we
need
to
and
as
clear
as
we
need
to.
I
know
the
industry
says
partitioning
for
a
bunch
of
stuff,
but
it's
like
it.
It's
going
to
mean
different
things
to
us
or
very
specific
things
to
us.
So.
C
A
I
agree
yeah.
I
agree.
We
need
to
work
on
the
terminology
or
glossary
it's
it's
important
for
this
working
group.
A
I
do
want
more
comment
there,
but
fabian
please
just
check
out.
If
that
makes
sense,
I
don't
know,
but
just
for
your
reference.
A
Okay
next
item
is
my
actually
receive
the
staffing
confirmation
that
both
adam
and
euric
will
be
able
to
start
on
the
maintenance.
But
there
is
another
thing
I'm
still
working
on.
I
should
have
answered
today.
That
is
a
slide
optimization.
A
I
mean
not
a
slide,
actually
a
big
optimization,
so
I
should
have
a
confirmation
today.
I
also
go
now.
You
know.
A
And
next
one
is
also
my
just
a
question
if
we
want
to
keep
running
this
us,
emea
friendly
meeting
because
looks
like
the
apac
session
is
quite
productive
for
the
engineers.
C
Yeah
so
my
con,
my
gut
feeling
is
this
they're.
Today
they
serve
different
purposes
on
some
level.
It's
like,
I
think
the
engineers
had
engineering
discussions
about
specific
things,
and
I
think
that
was
productive
for
them
and
fun,
and
this
one,
I
think,
is
more
making
sure
that
we
are
all
aligned
right
and
getting
some
more
organizational
things
out
of
the
way
right
and
sometimes
maybe
this
meeting
may
not
be
needed,
and
maybe
engineers
don't
necessarily
need
to
attend.
C
B
Yeah
and
this
this
meeting
I
mean
we're
30
minutes
in
so
clearly
we
had
things
to
talk
about
so
I'd
say:
let's
keep
it
for
now
and
if
there's
nothing
to
cover,
then
we
can
cancel
ad
hoc
there's
I
added
stuff
and
I
put
the
wrong
date
on
it
below
about
just
organizational
things
like
making
sure
our
pocs
are
four
weeks.
You
know
communicating
from
the
working
group
communicating
them
up
making
sure
that
the
team,
the
actual
individuals,
understand
the
expectations,
I'm
happy
to
keep
posting
them
here.
B
As
long
as
they're
being
read,
async
and
then
all
you
know
multi-modal
communication,
I
can
put
them
in
our
slack
channel
too
to
make
sure
it's
covered
everywhere.
So,
and
so
I
prefer
to
keep
this
cancel
when
we
can
and
I've
made
the
engineers
optional
on
this
one,
and
I
will
communicate
that
out
again
in
the
channel
jerry
plus
one,
my
feedback.
There.
A
B
And
then
fabian,
you
brought
up
a
point
about
updating
the
scalability
working
group
like
celebrating
the
work
that
york's
doing
about.
I'm
sorry,
is
it
tong
on
separating
out
the
database
and
showing
what
breaks
spectacularly
totally
agree?
There's
some
things
I'd
like
to
get
more
efficient
on
because
it
seems
like,
and
other
people
have
been
joking
about
this,
like
we
have
to
update
the
status
of
specific
things
repeatedly
with
different
groups,
and
then
this
is
one
of
them.
B
So
I've
got
some
ideas
on
how
we
can
be
more
efficient
with
some
of
the
requests
that
have
been
out
there
like
the
due
dates
and
confidence
level.
Those
are
easily
scriptable
from
individual
issues.
I
know
you
have
a
you
put
in
their
preference
for
estimates,
so
you-
and
I
can
sync
up
on
that-
to
make
sure
that
we
are
much
more
efficient
on
this,
because
I
really
hate
manually
updating
status
when
we
can
automate
it,
and
I
I
don't
like
repeating
work
just
so.
We
can
fit
a
format
for
different
meetings.
C
Well,
I
think
yeah,
I
agree
with
you
my
take
on
this
is
that
I
am
willing
to
show
the
the
responsibility
of
a
lot
of
this
stuff
so
that
the
people
who
actually
need
to
do
the
work
can
get
on
doing
the
work,
and
you
know,
but
having
fewer
update
meetings
necessary
and
increasing
the
overall
confidence
that
we're
on
track.
I
think
we'll
help
with
that.
B
Yeah,
I
I
hope
that
the
database
scalability
working
group
will
be
reduced
to
weekly
in
the
very
near
future,
because
I
I'm
seeing
diminishing
value
in
the
do
twice
a
week.
Now
that
we're
kicked
off
and
actually
doing
things.
I
think
there
was
just
a
lot
of
interest
up
front
and
that's
why
we
have
the
twice
a
week,
but
I'd
like
to
get
us
to
once
a
week.
E
Yeah
I
read
that
epic
savion
and
I
are
now
working
our
way
through
that,
but
so
I
saw
the
diagram.
It
says
two
databases
and
uninstall
of
omnibus
to
use
that
do
you
need
production
data?
I
believe
the
answer
to
be
yes,
but
do
you
need
it
in
both
instances
or
do
you
need
one
instance
with
production
data
and
then
some
other
empty
instance?
E
These
are
the
kinds
of
neat
details
I
need.
Also.
Infra
is
really
not
all
that
good
at
managing
an
omnibus
instance.
We
don't
do
anything
on
our
nervous,
so
we
need
to
figure
out.
You
know
do
I
we
can
give
you
the
database
instances,
that's
relatively
easy
for
us,
and
then
we
can
give
you
a
box
and
then
you
can
put
omniboost
and
do
whatever
you
need.
So
I
I
don't
know
those
are
the
kind
of
details
that
I
think
we
need
to
work
out.
E
So
we
can
provision
database
clusters.
We
can
get
to
production
data
in
one
or
more
of
those
clusters
and
then
we
can
figure
out
how
we
do
the
rest
of
the
stack
as
it
relates
to
whatever
testing
you
need
to
do,
and
the
reason
why
I
asked
about
the
databases
is
because
it
you
set
two
instances,
but
if
you're
going
to
chart
it
some
portion
of
that
it
sounds
to
me
like
we're.
E
C
Yeah
no,
I
apologize
for
the
lack
of
detail
right.
It's
not
100
clear
to
me
exactly
what
what
is
needed.
I
think
that's
the
discussion
to
be
to
be
had
right,
so
thanks
for
for
raising
it,
so
my
my
understanding
is-
and
this
is
more
from
my
geo
background
right-
it's
like
people
need
to
be
able
to
like
push
their
their
code
into
an
environment
where
it
doesn't
mess
up,
staging
right
and
so
a
simple
deployment.
C
You
know
where
I
don't
think
people
are
interested
in
the
scaled
architecture
of
any
kind
right
in
terms
of
like
multiple
application
nodes
or
this
kind
of
stuff.
I
think
that's
not
so
important
at
this
point.
I
do
think
that
the
that
it
will
require
multiple
database
servers
right
and
I
think
one
of
them
or
like
anything
that
is
not
the
main
database
server,
can
probably
be
empty
at
the
beginning
because
it
will
be
used
for
creating
new
stuff
right
or
migrating
things,
so
it
will
require
a
certain
amount
of
control.
C
I'm
honestly-
and
this
is
maybe
something
for
camille-
I'm
not
even
sure
if
in
the
beginning,
we
do
need
production
data
on
that
right,
because
if
it
is
about
testing
out
certain
sort
of
behaviors
early
on
right,
then
maybe
making
up
some
data
and
moving
it
around
on.
There
is
sufficient
right,
but
I
think,
ultimately,
you
want
a
subset
of
the
production
data
to
test
it
out
to
make
it
more
more
real
right-
and
I
just
said
omnibus,
because
that
is
my
understanding
of
what
these
these
boxes
would
need
to
provide
right.
C
If
that
is
provisioned
differently,
I
don't
think
it
matters
as
long
as
people
know
how
to
get
their
code
running
on
this.
So
that's
the
my
level
of
detail.
I
can
work
with
the
team
and
get
more
on
what
they
require
at
the
beginning,
because
I
would
like
to
keep
this
also
like
to
make
it
simple
to
get
this
right,
not
a
like
data
access
request,
three
months
later
kind
of
kind
of
thing,
but
yeah
like
I
can.
I
can
work
on
the
details
of
what
people
really
need
to
test
this
out.
D
D
Because,
like
I
mean
like
to
be
honest,
like
we,
don't
expect
to
like
the
performance
to
differ,
whether
you
use
many
or
like
single
database
servers,
truly
right
like
it's,
not
gonna,
be
much
of
the
difference.
So
this
is
step
one
we're
just
gonna
be
fine
like
with
omnibus
or
whatever
else
eat.
Love
is
and
just
use
the
same.
D
My
perception
about
the
production
data
was
that
at
some
point
at
the
end
of
the
demo,
I
would
like
to
get
to
the
point
that
we
can
actually
run
that
on
the
production
data
to
show
like
how
it
behaves
on
an
actual
data.
It
could
be
staging,
it
could
be
production.
It
doesn't
really
matter
that
much,
but
I
think
requirement
is
really
like
to
have
substantial
amount
data
big
enough.
E
D
Vm,
probably
gonna,
be
enough
to
connect
like
to
run
omnibus
because,
like
the
database,
server
are
gonna,
be
substantially
bigger,
but
they're
not
gonna,
be
a
ton
of
heavy
processing
on
the
application
site
right
in
there.
So
I
think
really
like
the
requirement
is
like
get
production
or
like
substantial
size
of
the
data
to
really
like
to
check
how
it
works
on
the
big
data
set,
how
we
can
move
that
around
what
functions
do
the
break,
because
there
is
a
challenge
on
modelling
all
of
the
features
with
our
fixtures
on
the
development
environment.
D
C
D
D
E
E
We'll
have
to
make
sure
that
you
can
create
logical
databases
inside
this
thing
so
that
you
can
fit
having
these
multiple
buckets
and
then
the
the
only
thing
and
I'm
gonna
I
will
try
to
speed
this
up
is
we
will
need
to
get
securities
permission
to
plot
production
data
in
this
environment,
and
that's
that
actually
also
entails
the
question
whether
you
want
to
be
able
to
do.
You
need
to
run
the
yeah.
E
I
guess
you
need
to
be
able
to
log
in
and
do
all
sorts
of
things
through
the
ui
to
be
able
to
do
this.
The
reason
why
I'm
saying
that
is
because
it
makes
it
a
little
bit.
Security
gets
pickier
if
there
is
some
way
for
you
to
hit
this
endpoint
from
through.
You
know,
from
from
your
web
browser
anyway
I'll
work
on
those
details.
I've
already
given
steve
and
brent
the
heads
up
that
this
request
was
coming,
so
we
were
kind
of
expecting
it.
So
I'm.
D
Not
an
issue
we're
gonna
figure
out
security,
like
expectations,
I
think
we
can
even
live
without
address
out
of
the
vm.
We
may
only
have
like
some
in-
and
maybe
I
don't
know-
maybe
we've
defined
like
maybe
it's
in
through
ssh
or
whatever
I
don't
know
like,
like
we
can
figure
out
a
way
to
lock
this
down.
C
D
E
Yeah
we
we
can
certainly
do
that.
The
other
thing
is,
I
am
assuming
you'll
want
an
easy
way
to
reset
this
from
time
to
time.
Yes,
okay,
so
what
we're
doing
to
do?
That
is.
E
We'll
be
using
cfs
which
allows
me
to
clone
and
give
you
a
clone,
and
then
you
can
destroy
it,
and
then
you
can
just
sort
of
go
back
and
forth
as
you
will,
since
we're
not
testing
for
performance
right
now.
That
should
not
be
like
once
we're
ready
to
be
more
serious
about
it.
Then
we
can
move
to
the
benchmarking
environment
and
you
know
test
with
actual
production
like
hardware
and
all
that
so.
C
D
D
So,
like
so
like,
I
think,
like
we
are
fine
with
that.
They're
really
like
the
problem
is
like
what
there
is
describing
like
accessing
production
data
in
the
like,
in
a
way
that
we
can
manipulate
that
with
this,
it's
like
requires,
like
just
community,
but
I
think
we
are
fine
for
these,
like
two
or
three
weeks
more.
So
it's
not
super
urgent.
E
Yeah
and
like
I
said,
I'm
still
gonna
we're
gonna
start
getting
moving
on
it,
so
because
it's
sauce,
then
it's
upset
and
then
they
need
to
validate
and
verify.
Then
they
run
tests
against
the
environment,
so
it
takes
yeah.
I
would
say
two
weeks
minimum,
but
I'll
have
a
more
detailed
update
and
an
issue
associated
with
it.
Next
time
we
meet.
A
D
A
Before
everybody
leaves,
I
have
a
good
news
to
share
just
confirmed,
so
the
staffing
change
dealer
will
join,
dylan
will
join
us
and
we
will
need
an
item
to
join
us.
A
Yes
and
camille,
camille
craig
and
I
we
have
talked
about
the
dylan
for
a
few
days
already.
C
C
A
A
B
C
D
And
even
they
are
being
engaged
today
with
for
work.
So
I
I
would
just
assume
like
that
that
I
can
just
wrap
up
what
he's
doing
and
just
kind
of
slowly
transition,
but
like
joining
our
meetings
and
like
keeping
him
sonic,
and
I
think
it's
going
to
occupy
more
and
more
of
his
time
even
like
before
exactly
what
is
happening
right
now
with
the
yorick
yeah.
A
A
D
D
Like
fabian,
for
you,
it's
like
a
zero.
It's
still
like,
like
you're
still
gonna,
be
working
with
them
just
on
the
different
teams.
Exactly.
A
And
it's
it's
also
good
for
tom,
because
now
both
steeler
and
the
car
are
in
apac,
so
they
have
one
part.
I
didn't
know
that
yeah,
so
they
have
somebody
to
to
talk
to.
C
Sounds
great,
I
think
that's
all
on
the
on
the
agenda.