►
From YouTube: Real Time Working Group 2020-09-02
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,
real
time
working
group
september,
2nd
2020
phase,
one
still,
but
pretty
close
right.
So
I
think
we
have
two
issues
to
finish
before
we
get
to
phase
two.
So
I
have
the
first
item.
I
opened
an
issue
for
the
helm
charts
this
week.
A
I
don't
really
know
a
lot
about
helm,
film,
charts
and
how
they
work,
but
I
think,
like
it's
going
to
be
quite
easy
to
enable
embedded
mode
if
we
wanted
to
do
that
or
to
allow
embedded
mode
to
be
enabled,
I
think
it'd
be
like
a
little
bit
harder
to
enable
standalone
mode
where
it
can
be
independently
scaled
and
so
on.
So
I
guess
my
question
is
like
do
we
want
to
wait
for
distribution
to
schedule
this
like
and
no
one?
C
Yes,
I
I
don't
know
anything
either.
It
will
be
interesting
for
me
to
follow
along,
because
we
have
similar
questions
coming
up
right
now
as
part
of
the
image
scaling,
epic,
that
our
team
works
on,
because
it
will
also
it's
not
entirely
clear
to
us,
because
we
have
a
similar
change
in
dependencies
as
well
that
we're
looking
at
and
like
do.
We
need
to
update
the
help
charts
for
this
as
well
like.
Where
are
all
these
like
points
of
maintenance?
C
I
guess
that
now
have
to
be
updated
for
this
to
still
work
for
everyone,
so
yeah.
So.
A
A
So
I
saw
in
the
past
that
we
did
some
stuff
with
service
desk
in
our
team
in
the
portfolio
management
certified
team.
A
Actually,
quite
and
that's
why
I
think
running
running
action,
cable
in
embedded
mode
might
not
be
that
hard,
because
it's
two
environment
variables
that
need
to
be
set
running
in
standalone
modes
requires
a
separate
container
aside
from
the
web
service
container,
which
only
handles
websocket
connections,
and
I
think
that
could
be
quite
a
substantially
more
work.
But
then
the
question
is
like:
would
we
ever
want
to?
Would
we
ever
want
to
run
it
in
kubernetes
in
embedded
mode?
Maybe
on
the
staging
server
or
one
of
the
non-production.
B
Deployments,
I
guess
for
us,
we
won't
be
using
it
right,
because
the
plan
for
gitlab.com
is
like
totally
separate
containers,
it's
a
goal
right,
why
we're
doing
kubernetes
stuff,
but
for
maybe
for
customers
or
stuff,
but
yeah.
That
raises
another
question
like
we
aren't
really
like
testing
that
setup
ourselves
and.
A
So
I
think
I'll
split
this
issue
well
dj's
asking
if
we
if
he
wants
us
to
try
and
schedule
it
in
the
distribution
team,
I
think
maybe
we
can
split
it
and
take
the
easier
part
and
at
least
try
to
iterate
on
it
that
way,
and
then
we
can
look
at
running
it
in
standalone
mode
and
now
like
by
the
helm,
charts
in
the
future.
A
C
Yeah,
I
just
wanted
to
pick
this
up
again.
I
had
come
up
several
times
now.
We
so
last
last
time
we
think
we
talked
about
the
problem
of
tracking
whether
embedded
mode
is
enabled
or
not
in
as
part
of
usage
ping,
and
when
I
first
looked
at
this
it
it
looked
simple,
but
then
we
found-
or
maybe
it's
not
that
straightforward,
because
it's
not
just
an
ordinary
settings
key,
but
it's
set
in
the
environment
and
then
we
talked
about
okay.
C
Well,
maybe
we
can
look
at
prometheus
and
see
if
there
are
any
action,
cable,
metrics
and
then
kind
of
derive
from
this.
Whether
action,
cable,
you
know,
is
part
of
the
equation,
which
is
something
I
think
that
can
work,
but
there
was
that
the
blocker
is
that
we
do
not
have
any
action.
Cable,
metrics,
it's
my
understanding.
C
A
C
But
then
the
milestones
seem
a
bit
backwards
because
the
usage
ping
one,
which
I
was
supposed
to
pick
up
it
was
scheduled
for
this
milestone
13.4.
But
then
we
discovered
well
there's
the
blocker,
but
then
we
said
well,
it's
not
that
important.
So
it
can
be.
You
know
in
the
next.
I
think
it
was
like
two
or
three
milestones,
or
so
I
guess
that
extends
to
this
one,
because,
like
I'm
asking,
I
I'm
happy
to
work
on
this.
It's
just
like.
C
A
Yeah,
it
seems
like
a
shame.
It's
it's
these
last
two
issues
are
all
that
are
blocking
us,
completing
phase
one
so,
and
they
don't
seem
that
hard.
I
mean
we
have
a
precedent
for
building
in
prometheus
metrics
for
other
features.
So
it
seems
like
this
shouldn't
really
be
that
hard.
I
guess.
C
Oh
yeah,
okay!
Oh
that's!
No!
That's
great!
That
wasn't
entirely
clear
to
me.
That
is
really
just
those
two
that
would
block
us
from
concluding
phase
one.
No
totally!
No
got
it
fair
enough
I'll
I'll.
I
can't
promise
I'll
get
to
it
this
week,
but
I
I
can
do
it.
I
can
start
looking
at
it
first
thing
next
week.
A
C
B
A
No
so
helen's
part
of
phase
two,
but
it's
since
the
way.
The
way
I
think
this
is
working
is
since
the
delivery
team
are
focused
on
the
web
terminal
as
the
first
feature
they'll
move
into
kubernetes
when
they're
ready
to
work
on
action,
cable
and
real
time,
we
won't
have
the
helm,
charts
ready
for
that,
and
it
would
make
sense
to
try
and
get
ahead.
A
You
know
and
prepare
the
helm
chart
in
advance.
So
then
all
they
have
to
do.
I
guess
is
work
on
the
kubernetes
work,
the
kubernetes
deployment
to
actually
use
the
helm
chart
to
deploy
the
containers
in
theory
anyway
like
but,
as
I
said,
running
a
whole
separate
like
creating
a
new
part
of
the
helm
chart
just
to
run
the
action
cable
standalone
server.
It's
probably
a
substantial
amount
of
work,
especially
if
we
don't
have
experience
you
know
working
with
the
helm,
charts.
A
A
C
Under
scheduled
for.