►
From YouTube: 2022-03-15 Object Storage WG
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
Okay,
that
should
work
all
right
well
welcome
to
the
object,
storage,
working
group,
synchronous
meeting:
this
is
the
america's
meeting
we
haven't.
B
A
In
two
weeks
I
think,
and
the
last
one
was
async
and
before
we
skipped
that
would
have
not
been
enough
attendance.
So
let
me
share
my
screen
here
and
we
can
go
through
today's
agenda.
There's,
I
think,
quite
a
quite
a
few
things
we
can
talk
about
today.
A
All
right,
I
assume
you
can
see
my
screen,
so
I'm
just
going
to
start
with
first
item.
I
thought
that's,
maybe
something
we
wanted
to
talk
about
sooner
than
later,
because
we
had,
I
think
marine
is
already
responding.
So
so,
basically
we
had
pushed
the
date
back.
Originally
the
working
group
was
supposed
to
wrap
up,
I
think
end
of
january,
and
we
had
pushed
it
back
to
the
end
of
march,
but
with
less
you're
still
out
until
early
next
month,
I
believe,
or
at
least
end
up
this
month.
A
I
think
if
we
should
probably
push
it
back
yeah
because
yeah
it
would
be
a
bit
abrupt.
It
would
at
least
be
good
to
kind
of
debrief
with
alessio
and
like
see
kind
of
what
next
what's
next
and
what
is
what
his
thoughts
are.
I'm
not
sure
what
the
yeah
extension
should
be
like
I
don't
know
if
there's
any
opinions
on
this,
so
I
thought
maybe
we
can
just
look
at
yeah
what
we
have
accomplished
so
far.
A
What
we
may
want
to
accomplish,
or
if
we
need
to
again,
maybe
pull
back
ambitions
a
little
bit
more.
So
any
any
thoughts
on
this
marine.
Do
you
wanna?
Do
you
wanna
say
something
about
it?.
B
Yeah,
I
think
I
think
we
still
are
finding
new
things,
and
we
are
still
looking
to
consolidate
some
of
the
knowledge
that
we
are
accumulated
over
over
the
period
of
the
working
group,
so
until
we
have
at
minimum
that
results
together
with
some
of
the
other
items
that
will
be
popping
up
soon.
I
don't
think
we
should
be
closing
this
down.
B
The
item
that
I
want
to
achieve-
at
least
I
from
my
side
at
the
end
of
this
working
group,
is
that
we
have
a
clear
idea
of
where
all
the
challenges
are
yeah
in
in
in
this
specific
topic,
so
that
we
can
work
on
resolving
some
of
them
in
a
timely
manner,
rather
than
when
it
becomes
a
problem
of
a
larger
scale.
B
Although
there's
something
to
be
said
about
the
fact
that
some
of
these
items
are
already
a
challenge
that
we
need
to
resolve,
so
I
think
we
should
definitely
extend
until
we
kind
of
run
out
of
knowledge
to
share,
which
is
not
the
case
yet.
A
Yes,
I
I
completely
agree
with
this.
It
would
feel
very
anti-climactic
if
we
would
stop
now
because
yeah,
like
you,
said
we're
still
working
through
some
of
the
kind
of
fundamental
stuff.
I
know
I
do
yeah
still
still
wrestling
with
that
and
yeah.
We
haven't
written
everything
down,
so
I
think
that
is
something
I
definitely
want
to
do
or
what
we
should
do
and
another
item.
A
I
thought
I
really
started
to
think
more
about,
but
I
would
definitely
need
help
with
from
inside
or
outside
the
group
is-
and
that's
maybe
maybe
a
good.
Oh
yeah,
thanks
by
the
way
for
mentioning
first
of
may
sounds
reasonable.
I
think
especially
around
that,
like
the
documentation
bits,
I
think
we
can
like
easily
get
done
the
next
couple
of
weeks
and
yeah
and
and
so
to
talk
about.
A
The
next
item
actually,
which
I
would
love
to
get
done
as
well
as
part
of
the
working
group,
is
what
we
had
called
kind
of.
I
forgot
who
brought
it
up.
I
think
it
might
have
been
you
marine
actually
like
what
are
the
kind
of
guardrails
we
can
put
in
place,
because
what
has
kind
of
gotten
clearer
to
me
like,
while
I
have
been
looking
at
yeah,
how
not
just
object
storage
but
like
how
uploads
in
general
work
currently
in
gitlab,
is
that
it
is
still.
A
It
would
be
very
unclear
to
me
still
as
a
developer
out
of
all
these
options
that
we
offer
for
how
uploads
can
be
implemented
both
from
a
developer
point
of
view,
but
also
from
an
admin
point
of
view,
because
we
have
like
a
couple
switches
that
relate
primarily
to
object.
Storage.
Like
is
this
something
where
we
can
look
to
reduce
complexity.
Maybe
it
feels
almost
like
we've
kind
of
built
ourselves.
A
A
very
large
castle
here
with,
like
a
lot
of
you,
know
like
interesting
settings
and
that
induces
a
lot
of
complexity
in
the
code
base
a
lot
of
different
combinations
of
how
things
can
operate.
A
So
I'm
wondering
do
we
even
want
to,
or
do
we
need
to
support
all
of
this
going
forward
and
because,
if,
if
we
don't,
if,
if
there's
like
room
here
for
simplification,
I
think
that
would
be
a
great
next
step
to
focus
on,
because
it
is
also
work
to
understand
it
all
and
document
it
all
right
yeah,
so
so
that
that
is
something
I
would
love
to
get
a
clearer
idea
about,
and
I
listed
three
very
specific
things
that
I
am
still
kind
of
confused
about,
and
I
I'm
not
sure
if
we
have
the
right
people
here
or
who
might
know
these
things,
but
and
we
don't
have
to
talk
about
them
in
detail,
I'm
just
going
to
quickly
touch
on
them.
A
The
first
one
was-
and
I
created
a
separate
issue
for
this
is-
and
I
think
that
was
the
first
thing
we
started
originally
to
kind
of
bake
into
workhorse,
as
an
optimization
is
what
we
refer
as
disc
buffering
where
we
receive
we,
we
go
down
the
default
route
in
in
workforce,
so
there's
no
explicit
handling
in
that
sense
in
terms
of
routing
a
particular
output
request,
and
we
basically
rewrite
the
multiplatform
request
that
comes
in
as
an
upload
to
cache
these
files
to
disk
and
workhorse,
and
then
we
hand
that
request
off
to
rails
and
arrays
basically
can
already
work
with
these
files,
rather
than
doing
that
itself,
which
would
be
more
expensive.
A
So
so
I'm
wondering
like
is
this
something
we
still
need.
I
mean
I
completely
understand
like
why
this
was
put
in
place
in
the
first
place,
but
if
there,
if
there's
an
option
to
replace
this
with
direct
upload,
say
everywhere-
and
I
don't
know
if
that
is-
but
I
wonder
if
we
should
even
still
have
this.
C
The
reason
we
have
it
is
because
I
was
building
fun,
stuffs
and
workhorse
and
the
there's
a
wreck
middleware
if
you
use
plain
rails,
where,
if
a
request
comes
in
that,
has
a
multi-part
file
in
it,
that
middleware
will
pull
out
the
file
and
store
it
into
a
temp
file
and
delete
it
at
the
end
of
the
request,
that
is,
a
functionality
of
wreck
and
very
early
on
in
the
history
of
workhorse.
We
added,
we,
I
think,
was
me
added
the
capability
for
workhorse
to
do
this.
C
Reading
writing
files
to
disk,
even
though
nginx
is
in
front
of
it
and
it's
already
buffered.
So
it's
relatively
fast,
it
was
meant
as
a
efficiency
thing,
and
this
had
nothing
to
do
with
object,
storage
or
uploads.
Well,
it
had
to
do
with
uploads,
but
nothing
to
do
with
object,
storage,
so
that
existed
and
it
still
exists
and
we
relied
on
it,
but
it
sort
of
became.
C
That's
why
it's
there.
It
would
be
really
nice
to
remove
it,
but
there
is
one
problem,
which
is
that
we
have
so
many
buckets,
and
we
don't
know
where
we
need
to
upload
things,
and
this
thing
makes
it
possible
for
some
things
where
we
don't
know
where
to
upload
them
to
just
put
them
in
a
temporary
directory,
and
then
the
rails
controller
decides
where
to
upload
them.
A
A
Can
can
I
ask
one
question,
though,
thanks
as
well
for
the
history
behind
it
so
rails
eventually
does
know,
though,
where
to
upload
it
right,
but
you
know
yeah,
so
why
can't
we
replace
it
this
mechanism?
A
In
the
same
way,
we
already
do
that
for
a
bunch
of
other
requests
that
actually
have
an
explicit
route
in
workhorse,
where
we
go
through
this
handshake,
where
we
first
authorize
with
rails
and
then
rail's
response
telling
workhorse
hey
here
is
a
url,
for
instance
like
where
this
file
needs
to
live,
then
still
workhors
needs
has
no
knowledge
of
where
it
needs
to
upload.
It
just
gets
a
url
handed
back
right.
A
So
basically,
what
I
I
guess,
what
I'm
suggesting
is
we
gitlab
should
know
what
kind
of
uploads
we
need
to
support
right.
Can
we,
until
we
have
maybe
a
more
uniform
mechanism,
just
add
an
explicit
route
for
all
of
these,
which
might
be
noisy
in
the
beginning,
but
at
least
it
would
be
consistent
and
reduce
the
code
path
to
just
one,
and
then
we
can
maybe
talk
about
condensing
this
into
you
know.
Maybe
they
don't
all
need
like
a
separate
authorization.
A
End
point
and
all
of
that
right,
that's
kind
of
what
david
is
still
looking
at,
but
that's
basically
what
I'm
suggesting
I'm
just
looking
to.
We
have
this
like
massive
matrix
of
ways
an
upload
can
take
both
in
workhorse
but
also
in
rails.
So,
if
you
multiply
all
of
these
out,
it
just
gets
you
get
to
the
staggering
complexity
and
I
think
you
need
to
look.
C
You
don't
have
to
convince
me
of
that,
but
I
think
for
this
particular
one.
We
have
to
do
a
lot
of
work
up
front
to
make
this
work
and
if
we
end
up
well,
because
we
need
to
find
all
the
roots,
we
need
to
map
all
the
roots
to
write
good
reg
x's.
For
them.
We
can
just
do
a
pre-authorized
request
on
every
post.
Well,
we
could,
but
that
would
double
the
number
of
posts
that
drills
has
to
handle.
C
A
C
So
I
I'm
not,
I
I'm
all
for
getting
rid
of
all
these
weird
flags
like
direct
upload
or
proxy
downloads,
or
it
it's
it's
scary,
but
this
particular
one.
I
I'm
not
sure
it
might
be
relatively
much
work
like
okay,.
C
A
Good
to
know-
and
I'm
I'm
not
saying
this
is
necessarily
the
first
one-
we
need
to
do
it's
just
something.
I
didn't
notice,
and
I
mean
this
is
actually
exactly
the
kind
of
feedback
I
was
hoping
to
get
because
it's
really
hard
even
to
yeah,
understand
at
this
point.
What
would
be.
But
what
are
the
trade-offs
here?
A.
C
I
think
there's
that
there's
a
spreadsheet
somewhere
that
we
have,
we
have
a
list
of
things
that
get
uploaded.
B
So
yeah,
so
the
reason
why
I'm
asking
for
this
is,
I
wonder
whether
we
can
like
stop
the
problem
from
expanding
further
by
knowing
the
the
items
that
we
currently
have.
And
let's
say
I
don't
know
sorry.
It
has
been
a
long
day,
so
I'm
gonna
use
some
direct
words.
Decree
right,
like
communicate
outwards
that
this
is
no
longer
an
option
like
you
cannot
be
adding
any
features
that
depend
on
this
and
we
could
even
maybe
fail
tests
if
someone
tries
to
do
this.
B
B
B
The
point
later,
but
you're
right,
you're
right,
that's
a
good
call-out.
A
Yeah,
I
guess
this
is
what
I'm
still
struggling
with,
is
what
what
is
the
recommendation
even
like,
if
you,
if
you,
if,
if
I'm
looking
to
add
a
new
upload?
What
should
I
be
doing
it's
like
not
clear
to
me
right
now
and-
and
this
kind
of
I
don't
think
I've
had.
I
think
I
had
it
linked
in
maybe
a
previous
sync.
I
think
it
might
not
even
be
possible
at
all
times
to
to
use
fences
direct
upload.
There
was
one
team
that
was
adding.
A
I
forgot
what
it
was,
but
they
were.
I
think
they
were
looking
to
encrypt
files
before
they
not
address,
but
before
they
upload
them
to
object,
storage
and
they
were
relying,
I
believe,
on
a
ruby
gem
to
do
that.
So
I
think
the
reasoning
then
was
well.
We
can't
use
direct
upload
because
we
would
have
workhorse.
A
You
know
do
that,
and
it
doesn't
do
that
right
now.
So
that's
why
they
kind
of
move
down
like
a
legacy
path
or
whatever
we
want
to
call
it
yeah.
It's
like
it's
like
I
don't
know.
There
might
be
other
reasons
right
why
this
just
doesn't
work
so
so.
C
I
think
we
need
to
know
where
we're
going
if
we
start
doing
cleanup
and
with
some
things
I
think
it's
easier
to
say
like
we
definitely
don't
want
this,
but
with
other
things
it's
it
depends
on
what
we
end
up
building
as
the
new
thing
in
the
case
of
those
encrypted.
I
think
those
are
terraform
state
files.
Yes
yeah,
I
don't
know
everything
I
just
read.
I
was
just
reading
through
the
requirements
issue.
Otherwise
I
wouldn't
even
know
what
I'm
talking
about,
especially
in
my
mind
the
terraform
state
files.
C
What
we
could
imagine
is
because
those
have
a
specific
route
is
that
they
get
a
workhorse
route.
That
says,
don't
touch
these
and
then
they
just
go
into
puma
and
puma
does
whatever
it
wants,
and
then
they
can
do
an
upload
from
puma,
because
I
don't
think
we're
going
to
live
in
a
world
where
all
uploads
are
done
by
things
other
than
workhorse
will
put
objects
into
object,
storage
because
there's
things
psychic
jobs
that
need
to
pull
and
push
files
from
object
storage.
C
Depends
on
how
big
these
files
are,
if
they're
reasonably
small,
then
I
don't
see,
I
don't
see
a
problem
with
that.
A
C
In
this
case,
we
we
have
this
encryption
stuff
and
right.
Okay,
the
application,
the
feature
one
in
control
of
when
the
file
gets
encrypted.
C
A
Support
for
encryption
in
workhorse,
so
outside
of
this
one
one
issue:
are
there
any
other
reasons
we
can
think
of?
Why?
Why
wouldn't
we
just
use
direct
upload
everywhere.
C
Yeah
most
of
the
time
we
do
one
direct
upload,
but
I
I
don't
think
this
terraform
state
file
thing
means
we
can't
have
direct
upload
for
everything
else.
This
is
not
the
disk
buffering.
The
problem
with
one
of
the
problems
with
this
club
is
that
we
need
to
do
a
handoff
from
workhorse
to
rails,
but
if
workers
doesn't
even
touch
this
multi-part
mime
thing,
then
it
doesn't
go
to
disk,
so
it
doesn't
matter
if
workhorse
and
rails
are
on
the
same
machine
or
not.
A
Yeah,
sorry,
I
was
jumping
around
a
bit
as
well.
This
was
my
last
comment
was
not
related
to
this
buffering
at
all.
I
was
kind
of
going
to
the
next
one
as
well
sort
of
already,
because
there
was
item
the
roman
numeral
two
here,
which
was
you
can
actually
also
disable
direct
upload
in
the
settings
which
I
was
like
dimly
aware
of
before,
but
I
was
also
wondering
like
why.
A
Why
would
we?
Why
would
you
allow
users
to
like
bypass
this
when
it
sounded
to
me
like
the
evolution?
So
far
has
been.
We
first
came
up
with
this
buffering,
which
was
like
an
immediate
improvement.
It
was
kind
of
this
like
one
size
fits
all.
Let's
just
make
outputs
faster
right
in
general,
outside
of
object
storage,
and
I
guess
then
the
next
bit
was
well
now
we
have
object
storage.
So
I.
B
Wouldn't
go
that
way
mathias,
not
not
because
there
is
no
logic
behind
what
you're
saying
there.
There
is
some.
The
thing
is
no
one
sat
down
and
said:
let's
figure
out
a
story.
A
Yeah
but
wait,
but
that's
not
what
I
mean,
because
what
I'm
trying
to
say
is
to
me
it
sounds
like
the
way
a
file
is
upload
is
very
much
an
implementation
detail.
Maybe
I'm
looking
at
it
wrong,
but
it
sounds
to
me
like.
If
I'm
a
user,
I
don't
care
how
a
file
is
uploaded.
I
have
a
file
and
I
want
it
to
end
up
being
an
object,
storage
or
in
a
local
storage.
B
So
you
have
rollout
reasons.
You
also
have
knowledge
as
well.
At
that
time,
right,
like
you,
have
parts
of
the
code
base
that
people
are
unaware
of,
don't
know
how
to
use
or
and
so
on,
and
so
on.
Don't
forget.
We
grew
as
a
company.
We
grew
as
an
application
as
well,
so
things
were
added
with
the
best
intentions
to
resolve
a
certain
issue,
whether
we
had
the
knowledge
to
resolve
it
in
one
way
or
another
is
also
a
question.
B
C
C
It
it
also
goes
for
some
of
the
others.
Like
background
uploads.
C
We
had
to
put
everything
change,
make
a
big
change
and
start
putting
everything
into
object,
storage,
and
sometimes
that
just
meant
well,
we
just
do
the
regular
carrier
way
thing
and
then
we
say
oops,
it's
it's
not
an
object.
Storage,
let's
create
a
psychic
job
that
puts
it
in
object,
storage
after
all,
and
that
was
the
fastest
to
build.
At
the
time
direct
upload
was
was
hard
to
implement
and
alessio
would
know
better
because
he
was
more
involved,
but
some
things
just
got
built
without
direct
upload
without
having
to
touch
workhorse.
C
Workhorse
was
in
a
separate
repo
and
in
workhorse
routes
is
a
pain
during
workhorse
development.
It's
still
a
pain,
but
it's
less
of
a
pain.
Now
that
it's
in
the
same
repo
and
just
spawning
a
psychic
job
was,
for
some
things,
just
a
faster
way
to
get
it
working.
A
All
right
got
it
okay,
so
it's
basically
a
similar
reason
right.
It
was
so
so
it's
it's
more
like
is
it
then
can
you
can,
I
think,
of
this
more
as
because
it
sounds
to
me
like
that,
it's
very
much
a
developer
story,
you're
telling,
but
but
these
are
user-facing
switches
right.
If
I'm
an
admin
and
I
run
gitlab,
how
do
I
make
this
decision
to
turn
on
yeah.
C
A
Guys
that
explains
a
lot,
though,
because
I
kind
of
misunderstood
these
as
they
exist
for
the
sole
purpose
of
admins.
Basically,
they're.
C
B
Just
again,
keep
in
mind
like
we
feature.
Flags
are
also
relatively
recent
thing
compared
to
some
of
these
items
as
well.
So
it's
it's
again,
one
of
those
things
where
tools
were
used
to
the
best
of
the
knowledge
of
the
developer
and
product
elite
who
needed
to
accomplish
a
user-facing
feature,
not
exactly
how
they
did
it
right,
like
they
needed
to
do
it
as
safely
and
as
fast
as
possible
to
accomplish
a
certain
goal.
Now
that
we
want
to
consolidate
some
of
these
things,
because
operationally
it's
actually
really
hard
to
support
this.
B
We
are
right
like
running
against
all
these
stories,
so
it's
not
a
linear
story,
so
to
speak
right
like
it's
a
lot
of
really
good
engineers
doing
what
was
best
for
that
moment
in
time.
B
To
not
expand
more
about
like
whether
backloads
out
back
background,
uploads
and
and
so
on,
like
needs
to
be
the
the
the
things
that
we
support.
It's
more.
B
A
A
Yeah,
I'm
pretty
sure,
not
100
confidence,
but
as
I
started
to
look
into
I'm
not
confident
at
all
about
anything,
I'm
saying
but
like
when
I
started
to
look
at
the
rails
implementation
yesterday,
it
seemed
to
me
that
direct
upload
and
back
this
background,
uploads
switch
or
these
two
switches
are
mutually
exclusive
on
direct
upload
when
it
is
enabled
overwrites
background
uploads.
That
would
suggest
that
a
lot
of
these
code
paths
that
support
background
uploads
wouldn't
be
enabled
for
says.
D
The
way
that
everything
works
when
it
operates
in
a
cloud-native
fashion,
background
uploads
do
not
work
period.
They're
gone,
they
don't
exist
when
it
comes
to
sas
when
it
comes
to
cloud
native,
and
that
has
been
from
the
get-go,
because
you
cannot
share
the
file
systems
so
that
functionality
is
well.
C
A
D
D
D
Direct
upload
where
available
could
be
used
because
you're
not
storing
it
to
some
temporary
file
that
may
end
up
at
one
of
900
instances
of
workhorse.
Okay,
that's
the
the
problem
with
ever
stashing
things
to
disk.
If
one
part
of
a
request
goes
over
there,
where
does
the
other
15
parts
go
right?
We
don't
know
necessarily
when
it
comes
to
the
way
things
should
work
in
cloud
native.
We
should
look
at
gitlab.com
as
an
example,
because
it's
driven
a
lot
of
some
of
these
decisions,
but
it
also
comes
down
to.
A
Got
it
okay?
No,
this
is
this
is
really.
This
is
really
good
to
know
that
that
was
certainly
not
not
clear
to
me.
I
I
knew
that
the
general
direction
was
direct
upload,
but
to
what
extent
or
whether
there's
still
some
kind
of
mixture
being
used.
I
wasn't
trying
to
clear
on
that.
So
that's
that's
good
to
know,
so
this
basically
yeah
to
kind
of
reverse
that
what
we're
saying
is
background
uploads.
If
at
all,
I
used
by
omnibus
uses
correct.
C
Not
the
same
thing
as
the
disk
buffering,
because
that
in
cloud
native,
the
workhorse
bot,
the
workhorse
container
and
the
rails
container
are
co-located.
So
they
do
see
the
same
file
system.
A
Would
be,
I
think
we
might
be
too
late
for
this
with
15-0,
but
wouldn't
be
a
simple
first
step
to
be
to
just
set
ourselves
kind
of
a
due
date
and
say
because,
because
we
know,
direct
upload
is
working
because
this
workout
says,
could
we
just
announce
like
deprecate
background,
uploads
and
announce
it
like
with
it
with
this
three
months
or
three
milestone
deprecation
process
right
so
that
we,
let
omnibus
users
know
if
you
have
this
enabled
do
not
enable
it
like
enable
direct
upload.
B
Okay,
okay,
matthias,
I
think,
you're
conflating
removal
with
deprecation.
We
can
announce
the
application
right
now
and
carry
it
as
long
as
we
want
right.
We
can
care
well,
not
as
long
like
we
need
to
set
the
due
date,
but
the
due
date
doesn't
need
to
be
15.0
in
15.0.
We
would
be
removing
it
if
we
were
ready
to
remove
it.
What
we
can
do
is
prepare
to
actually
announce
right,
set
the
deprecation
somewhere
so
that
people
get
the
announcement
and
that
announcement
carries
on
through
the
blog
post
through
all
the
various
channels.
B
C
But
we
may
not
even
need
to
tell
the
users,
because
it
could
be
that
direct
upload
works
everywhere.
So
we
can
just
always
do
direct
upload
and
not
tell
anybody.
B
I
but
I
do
wanna
I
would
do
want
to
leave
one
item
because
I
remember
this
conversation
like
deja
vu
started
like
screaming
at
me
all
of
a
sudden
we
talked
about
this
already.
We
talked
about
direct
upload
being
enabled
as
the
default
item,
and
I
have
an
issue
for
for
this.
I
don't
recall
this
being
mentioned.
B
It
doesn't
mean
that
it
wasn't,
but
I'm
just
leaving
it
here.
Direct
upload
on
is
the
issue
here,
and
there
has
been
a
bit
of
a
back
and
forth
in
that
issue
would
be
useful
to
actually
consume
that
issue
and
see
what
comes
out
of
it
again.
Keep
in
mind
that
this
is
oh,
my
god,
three
years
ago,
march,
14
2019.,
so
it's
still
open
things
have.
B
Of
course,
but
it's
good
to
understand
some
of
the
context
of
why
that
was
not
the
case
back
then,
apart
from
no
one
actually
went
and
did
it.
A
A
Okay,
yeah
right
right,
you
yeah
you!
You
brought
this
up
in
the
section
as
well.
Maybe
we
can
just
push
the
the
remaining
items
to
to
next
week.
If
that's,
okay
with
everyone
and
wrap
it
up
here,.