►
From YouTube: Real-time Working Group 2020-04-22
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
All
right
here
we
go
so
this
is
the
fortnightly
working
group
meeting
for
the
real
time
working
group
couple
items
on
the
agenda
so
Sean's,
not
here
yet
soul,
skippers
and
yep
go
straight
to
the
second
announcement,
which
is
that
Heinrich
and
Mathias
collaborated
on
an
epic.
The
description
which
serves
as
a
kind
of
design
document.
Would
you
agree.
A
Cool
yeah
and
I
noticed
that
Mathias
had
some
discussions
around
performance,
like
he's
open,
quite
a
few
issues
to
do
with
memory
usage
and
that
kind
of
thing
and
he's
also
had
a
conversation
with
Nate
in
the
Ruby
on
Rails
performance
training
channel
on
slack,
which
I
think
is
worth
reading
and
but
yeah.
This
epic
will
gather
together
some
of
the
infrastructure
stuff
that
we're
doing
as
well,
but
the
feature
works
in
a
different
epochs,
so
I've
linked
both
of
those
from
the
working
group
page.
A
So
yeah
I'll
kick
off
for
the
first
item,
so
some
of
the
plan
team
have
expressed
an
interest
in
learning
about
docker
and
getting
involved
in
the
docker
work
and
I'm
kind
of
wondering
maybe
Ben
would
know.
Is
there
any
training
material,
any
kind
of
guidance,
best
practices?
Anything
like
that
is
there
any
prospect
of
you
know
having
a
DRI
for
this
kind
of
thing
that
we
can
ask
questions
of
anything
like
that.
A
A
Cool
yeah,
so
we
were
thinking
about
so
honey.
You
were
saying
you
would,
and
you
have
an
item
in
the
agenda
for
this-
that
you
would
do
do
the
omnibus
changes
in
parallel,
giving
us
the
option
basically
of
running
this
on
existing
nodes.
While
we
do
the
darker
work,
yeah.
B
I
was
just
thinking
like
because
somebody's
like
owning
the
Duggar
and
coordinators
work
anyway,
so
like
next
step,
I
could
work
on
so
yeah.
At
least
we
have
these
two
options
available
for
us
yeah,
because
we
could
even
start
with
the
omnibus
or
staging
right.
If
you
know,
if
we
really
want
to
get
it
early
and
omnibuses
done,
we
could
start
with
omnibus
for
the
staging
and
wait
for
kubernetes
a
bit
later
or
something
like
that.
A
Okay,
so
what's
the
status
of
the
Omnibus
work,
they're
like
what
I
mean
by
the
looks
of
things
when
we
address
training
and
it's
possible
that
the
darker
work
goes
much
faster
than
we
expect,
but
given
what
we
have
to
start
with,
it
could
take
quite
a
while.
So
it's
the
idea
that
we
would
start,
then,
with
omnibus
and
deploy
that
tap
servers
and
do
the
thing
that
we
said
about
application
layer,
isolation
excusing
feature
flags
or
something
like
that.
B
Yeah,
it
could
be
possible
that
we
go
that
route
like
deploy
in
the
app
notes
using
our
Nicholas,
though
you
know,
I'm,
not
I,
don't
I
am
Not
sure,
like
maybe
infra,
has
the
final
say.
If
you
want
to
do
that
or
not
wait
for
kubernetes
or
maybe
when
we
start
working
on
kubernetes,
we
can
get
a
general
idea
of
whether
like
it's
gonna
take
longer
or
is
it
gonna,
be
any
really
quick
or
something
like
that.
A
A
C
A
B
A
Okay,
cool
I
don't
jump
around
too
much,
but
do
we
have
anyone
on
the
call
who's
acquainted
with
the
CNG
projects,
the
basically
our
existing
collide
native
darker
images?
A
D
Yeah
I
was
just
reading
through
some
of
the
memory
issues
that
were
spun
out
of
this,
and
it
looked
like
the
just
so
I
understand
the
state
of
things.
The
high
memory
consumption
just
by
running
action,
cable,
was
falsely
reported
and
I
just
wanted
to
verify
that,
as
of
now
we're
not
planning
on
I
guess
preemptively,
implementing,
like
artificial
constraints,
on
what
we
can
use
WebSockets
forward
to
the
future.
D
B
B
Like
limiting
the
WebSocket
nodes
can
do
like
everything,
what
classes
we
load
or
something
just
do
you
know
save
memory,
and
but
it's
still
very
early
in
discussions
and
I'm
kind
of
leaning
towards
not
doing
that,
because
it's
just
really
the
rails
monolith,
it's
difficult
to
get
like
boundaries,
and
it's
really
hard
to
tell
I
mean
you
load.
An
issue.
Class
issue
depends
on
you,
know,
issuable
and
all
the
other
mentionable
and
just
you
know
really
hard
to
define
boundaries
there.
B
That's
still
the
plan
and
Camille
was
also
looking
into
other
ways.
We
could
save
memory
not
by
a
certain
period
because
with
any
cable.
Actually,
it
was
kind
of
a
false
yeah
call.
This
horse
assumption
that
we're
gonna
save
memory,
because
it's
a
go
process.
I
think
it
was
forgotten,
but
a
lot
of
like
people
in
the
discussion
that,
if
we
use
any
cable
we'd,
actually
have
to
spin
up
a
sibling
process,
a
JRPG
server
which
puts
the
wrong
whole
race
up.
B
So
it's
kind
of
the
same
thing,
and
so
Camille
was
looking
into
other
ways.
We
could
save
memory,
which
is
like
starting
a
parent
process
and
then
forking
another
process
for
Puma
Puma
web
and
another
process
for
Puma
auction
cable.
Something
like
that.
So
we
could
take
advantage
of
prop
em
right
and
similar
to
what
we
do.
It's
like
a
custard
I
think
yeah.
D
Okay,
cool
yeah,
I'm,
totally
supportive
of
whatever
approach
we
take
I
just
want
to
make
sure
you
don't
put
like
artificial
limits
on
it
out
of
the
box.
I
think
we
do
need
to
measure
and
get
that
observer
ability
in
place
and
understand
implications
for
scale
just
so
we
can
project
out
costs,
and
things
like
that,
so
I
know.com
profitability
is
increasingly
important
so
like
we
just
basically
need
to
understand
the
financial
implications
at
scale
as
quickly
as
possible,
but
we
can't
do
that
until
we
get
something
small
out
so
yeah
I'm.
A
B
Yeah
this
in
the
logs,
they
were
like
logging
like
the
regular
Puma
server,
was
consuming
one
gig
and
the
action
cable
was
consuming.
1.5
gig
like
for
no
reason
at
all,
and
it's
apparently
like
this,
the
calculation
problem
or
something
not
sure.
But
if
you
actually
look
at
the
RSS
and
whatever
low-level
numbers
and
they're
actually.
D
As
matthias
made,
this
comment
that,
like
he
said,
I,
find
the
alarming
that
we
have
a
sophisticated
pipeline
deployed
for
this,
and
it
didn't
signal
as
change
that
we
didn't
like
detect
the
memory
increase
caused
by
action
cable
at
CI.
So
it
should
be
addressed
and
fits
well
into
our
product
roadmap,
which
is
good,
so
I
guess
we're
trying
to
make
sure
that,
like
we
have
some
built-in
checks
for
memory
consumption
in
the
bill
pipeline,
sir,
which
I
think
is
a
good
thing
to
have.
But
it
is
interesting
that
we
didn't
catch
it.
B
A
A
So
I
think
I
have
a
copied
in
yeah
captain
issues
so
Gabe.
We
might
want
to
prioritize
in
the
plan
team
that
prima
darker
ization
issued
that
I
created
because
I'm
not
sure
they'll
be
I'm,
not
sure
they'll
be
work
directly
out
of
this
one.
We
might
have
some
issues,
but
given
that
we'll
have
to
identify
the
right
people
and
resources
like
to
actually
help
the
team
take
on
the
docker
ization
work
should
probably
prioritize
it.
D
Prioritized
I
mean
we
can
we
can
move
it
into
the
backlog
or
right
for
development
and
keep
it
up
as
soon
as
it
the
planning
breakdowns
done
and
we
know
who's
going
to
work
on
it.
A
I'm
having
some
trouble
running,
those
talker
images
in
individually
locally,
like
I,
can
run
the
whole
thing
using
docker
compose
but
like
there
are
a
lot
of
open
questions
about
that
stuff,
and
maybe
we
could
try
to
improve
the
documentation
for
other
teams,
like
the
Korea
team
will
be
coming
behind
us
to
to
do.
You
know,
build
even
more
stuff
on
WebSockets
in
the
future
and
might
be
useful
information.
Yeah.
D
I
agree
with
that:
do:
can
we
pair
somebody
who
knows
a
lot
about
it
so
that
we
don't
I
mean
we?
A
B
A
B
D
CK
is
a
like
a
alternate
setup
for
development
that
uses
tower
containers.
So
it's
not.
Actually
these
containers
aren't
really
practically
like
distributed
to.
You
know
for
production,
news
or
anything,
but
it's
mostly
for
development.
So
if
they're
a
complete,
a
completely
different
set
of
docker
files
or
images
but
but
I
think
that's
what
they
use
mostly
Mathias
and
Camille
and
the
other.
So
they
got
it
working
on
jck.
So.
A
A
Okay,
no
more
items,
so
that's
it
for
today
I'll
organize
these
every
two
weeks,
because
every
week
feels
like
a
bit
much.
If
nobody
else
has
any
items
to
add,
we
can
finish
here.