►
From YouTube: Real-Time Working Group 2020-04-01
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
A
So
we
have
a
chance
tonight
to
establish
some
exit
criteria
and
I
thought
we
could
maybe
do
that
at
the
end,
because
there's
a
couple
of
things,
so
we
should
discuss
first,
so
I
have
the
items
so
I'll
yeah,
so
I
opened
an
issue
for
for
the
kubernetes
work
with
the
delivery
team
and
I
tried
to
break
it
down
into
tasks.
A
There's
one
task
missing
today
with
helm,
but
I
think
if
we
were
to
get
those
tasks
done,
we
would
be
at
the
stage
where
we
have
a
kipper
nineties
deployment,
where
the
feature
could
be
run
in
isolation
of
aside
from
everything
else,
and
it
could
be
measured
right.
So
we'd
have
some
kind
of
level
of
observability
over
us
and
unfortunately,
the
delivery
team
is
really
busy.
They're
working
on
the
psychic
project
export
queue,
work
which
they
have
completed
and
that's
on
production,
but
they
have
some
tidy-up
today
afterwards.
A
So
what
I
was
going
to
suggest
is
that
we
deploy
this
on
our
existing
application
nodes
and
feature
flag
it
to
some
really
small
projects
with
or
a
small
group
and
a
small
project
with
small
number
of
users
could
be
like
the
plan
project
or
something,
but
just
something
that
won't
put
a
lot
of
load
on
the
system
and
what
would
give
us
a
chance
to
have
like
a
known
quantity
of
users
and
measure
the
number
of
connections
measure
the
resource
usage.
And
so
what
do
you
think.
B
Yes,
yes,
I
rewatched
saving,
Christopher's
video
on
iteration
I
found
it
interesting
that
they
basically
said
being
blocked
by
another
group.
We're
having
another
group
nc
is
a
bad
thing,
so
I
would
say
whatever
we
have
to
do
at
Newport.
Let's
do
it,
even
if
we
have
to
figure
out
how
to
do
some
kubernetes
stuff,
myself,
I
think
that'd
be
cool,
so
you
have
less
dependencies
on
other
teams
future.
C
Or
what
yeah
the
initial
discussions
we
had
was
to
run
it
on
kubernetes
right
and
then
there's
it's,
because
it's
a
bit
block
right
now
by
the
delivery
team,
because
they're
working
on
the
project
expert
queue.
So
John
was
suggesting
that
how
about
we
run
it
on
our
existing
API
and
web
nodes.
It's
like
separate
Puma
process
in
the
same
notes,
but
then
just
feature
flag
it
to
like
a
specific
project,
so
it's
very
limited
in
low
risk
and
yeah.
So
what
do
you
think.
E
I'm
not
sure
that's
a
good
idea,
because
the
way
we
run
Puma
on
the
existing
nodes
is
that
we
we
run
it
as
part
of
omnibus
seal,
so
you'll
have
to
do
all
of
the
omnibus
integration
to
run
a
separate
Puma
service.
So
if
it's
a
fully
separate
Puma
service
it
will,
it
will
need
to
run
yeah
it'll.
Basically,
you
have
to
go
through
a
full
omnibus
integration
before
you
can
do
any
experiments
yeah,
but
we're
planning.
C
E
Stuff
right
away:
yeah
right,
you
know
it
with
with
with
the
kubernetes
deployment
I'm
trying
to
not
block
us
on
mommy
bus
and
I'm,
trying
to
not
use
omnibus
where
possible.
So
if
it's
a
completely
new
service,
we
should
start
it
with
the
new
pattern
and
not
try
and
do
the
the
old
pattern
first,
but
this
this
is.
This
is
just
to
run
the
WebSocket
server
and
not,
and
it
and
I
I
really
think
we
might
want
to
skip
Puma
as
a
WebSocket
server
and
and
go
right
to
the
the
go
line,
one.
E
C
Yeah
the
problem
with
that
is
that
they
go
service
or
the
binary
or
the
you
know
in
the
process
that
runs
the
WebSocket
server
doesn't
have
the
rails
contacts,
so
it's
not
so
for
it
to
work.
We
need
a
G
RPC
server,
which
kind
of
complicates
the
whole
thing.
So
we
still
have
to
have
this
G
RPC
server
that
boots
rails
and
then
the
go
for.
E
C
C
E
E
E
E
Just
because
deploying
a
go,
binary
is
significantly
easier
and
all
the
configuration
options
are
kind
of
just
gone
like
the
the
kind
of
the
kind
of
tuning
stuff
and
and
and
then
but-
and
it's
also
like
running
a
second
Puma
I,
don't
know
how
that's
going
to
interact
with
the
existing
rails
code,
so
you're,
basically
reusing
you're
having
to
reuse
parts
of
the
same
code
and
I,
don't
know
exactly
how
that
would
work
and
like
it's
it's
just
to
me.
It
feels
like
a
scarier
integration
than
just
running
a
separate
go
binary.
C
Yeah,
my
only
concern
with
the
any
going
straight
to
any
cable
is
the
you
know.
We
increase
the
complexity
of
the
initial
setup
like
even
if
we
go
kubernetes,
we
still
need
the
you
know
the
separate
fleet
of
G,
RPC
nodes
and
separate
fleet
of
the
WebSocket
server,
although
that
it's
a
bit
simpler
because
it's
a
circle,
binary
and
yeah.
E
C
F
F
E
There's
been
a
couple
of
times:
we've
talked
about
switching
from
switching
requests
to
the
API
to
G
RPC
anyway,
so
that,
because
it's
much
more
efficient
than
JSON
API
requests,
so
that
when
giddily
needs
to
talk
to
the
API,
you
can
use
G
RPC
instead
of
instead
of
JSON
requests
and
that
would
that
would
be
much
more
efficient
that
way,
so
we
kind
of
need
we
kind
of
wanted
it
anyway.
I
just
don't
know
what
the,
if
that,
that,
if
that
idea
ever
actually
got
turned
into
a
real
issue,.
E
C
C
Any
cable,
T
RPC
server
would
be
something
like
somebody
subscribed
to
this
channel
and
that
would
trigger
a
code
and
run
the
channel
class
and
find
the
right
action
and
do
authorization
and
all
that
so
and
then
the
response
goes
to
the
WebSocket
server
and
the
WebSocket
server
can
decide
if
it's
gonna
accept
a
connection
or
not
so
yeah.
Basically,
the
real
stuff
goes
to
the
ER,
PC
server.
Sure.
E
E
E
Yeah
we
we
need
to.
We
need
to
get
some
production
testing.
North
I
think
that
I
think
the
separate
Puma
is
fine.
It's
it's
just
gonna
be
a
little.
It's
just
gonna,
be
a
little
I
think
it's
gonna
be
a
little
more
work
to
integrate
into
the
omnibus
just
because
I,
the
it's,
the
omnibus,
is
a
tangled
mess
of
code.
A
But
like
it
would
get
us
from
where
we
are
now,
which
is
that,
having
a
feature
built
with
action,
cable
and
sort
of
feature,
flag
already
and
ready
to
ship,
but
with
like
the
infrastructure,
support
to
actually
having
something
we
can.
We
can
see
even
if
it's
only
on
a
small
project
somewhere
and
we
can
measure
the
impact
yeah.
G
E
No,
that
that's
actually
really
helpful
and
yeah
I
think
I
think,
starting
with
the
with
the
cloud
native
helm
chart.
If
that's
what
you're
talking
about
is
to
me
the
better
idea,
because,
like
long
term,
we
want
to
be,
we
want
to
be
able
to
run
this
in
kubernetes,
actually
even
short
term
I
think
it
would
be
better.
E
C
E
C
E
I,
don't
think
I
we
should
not
be.
We
should
not
be
blocking
on
that
team
at
all.
The
the
fact
that
we
have
anything
blocked
on
that
team
is
is
a
huge
problem
right
now
and
I
I
am
trying
to
encourage
more
people
to
do
the
do
the
kubernetes
work
themselves
and
just
use
the
delivery
team
as
a
code
reviewer
as
a
maintainer.
E
A
What's
like,
what's
different
about
the
cyclic
use
in
kubernetes
versus
this
I
mean
they
need
access
to
Redis
pops
up
as
well,
they
need
access
to
the
database.
Surely
the
the
home
charts
will
be
very
similar.
The
kubernetes
deployment
files
would
be
very
similar.
Config
files
like
we
would
have
a
basis
to
start
from
right.
Yeah.
G
E
G
A
And
it
ate
some
of
that
knee
agenda
by
the
way
the
conversation
and
got
lost.
So
if
you
wouldn't
mind,
I'd
and
just
I'd
appreciate
it,
but
so
that
brings
me
on
to
the
next
point
and
like
what
can
we
take
out
of
that
task
list
if
we
did
want
to
go
kubernetes
first
and
to
help
with
this
like?
There
are
a
few
things
that
like
I'm,
not
exactly
clear
on
like,
for
example,
docker,
ization
or
containerization
of
the
existent
application.
A
G
Yes,
we
have
a
set
of
images
that
we
use,
so
I'll
just
share
the
link
to
the
repo
for
those
there
you
go,
so
you
can
see
from
the
images
in
there
like
first
of
all,
how
we
typically
build
an
image
like
what's
in
common
between
them.
What's
different,
but
also
like
you
know,
you
mentioned
logging
to
standard
out
like
that's,
you
know
already
how
it's
working
in
in
these
ones
so
yeah
that
would
that
would
be
the
best
place
to
start
there.
G
A
Well,
you
know,
like
I,
don't
see
why
we
can't
start
to
pick
things
off
this
queue
and
have
it
a
certain
state.
Myron's
estimate
was
two
weeks
that
they
would
have
the
project
export
stuff
cleaned
up.
Let's
say
for
so,
we
could
have
it
in
a
decent
state
by
that
point,
where
there
wouldn't
be
too
much
work
to
do.
Yeah.
G
And
the
nice
thing
about
the
charts
is
like
once
once
you've
got
set
up
which
amazed
they
took
me
a
while,
because
I
had
the
wrong
permissions
in
GCP.
It's
really
easy
to
like
spin
things
up
like
that's
the
whole
point
of
them
right.
It's
really
easy
to
spin
things
up
scale
up
like
try
it
out,
try
something
else.
You
know
change
your
config
setting
and
just
like.
Have
that
automatically
applied
like
that's.
That's
all
sort
of
the
selling
points
of
this.
G
So
yes,
the
register,
nodes,
thing
I
think
is
a
bit
tricky
because
of
our
mixed
deployment
model
because,
like
the
Redis
nodes
currently
used
omnibus
and
in
future
we
don't
want
them
to
use
omnibus,
but,
like
you
know,
there
might
be
a
sort
of
issue
there.
If
you
want
to
add
new
one,
so
it
might
be
easiest
to
start
with
the
existing
ones
and
then
once
we've
got
it
further
along
talk
to
people.
G
If
we
need
separate
ones
or
more,
if
we
can
defer
that
decision,
basically
I'm
saying
we
should,
because
if
we
have
to
use
in
different
registers,
that's
the
same
amount
of
work
now
is.
It
would
be
in
two
weeks
pretty
much
right,
Heinrich,
it's
just
that.
If
we
don't
have
to
do
it,
then
we
should
probably
avoid
it.
A
And,
like
all
the
things
that
would
normally
hold
up
the
first
kubernetes
deployment
will
probably
have
been
figured
out
right.
Sean,
like
I
mean
like
service
discovery.
That's
the
thing
that
has
held
up
in
the
past,
though
I've
seen
hold
up
protesters,
but
that
would
have
been
established
right
because
we
don't
require
any
more
services.
Then
then
the
psychic
work
requires.
A
Okay,
cool
thanks
and
so
just
sorry
to
jump
back,
but
just
on
the
the
first
thing
we
spoke
about.
Is
there
any
value
in
in
doing
that
like
deploying
a
feature
behind
a
feature
flag
on
a
very,
very
small
project,
or
we
decided
that
that's
not
worth
worth
doing,
I
definitely
think
that's
worth
doing,
okay
cool!
Well,
it
looks
like
that
could
be
a
first
step
then,
because
that
would
give
us
some
information
about
action,
cable
and
I
perform
into
this
yeah.
C
We're
gonna
add
in
a
feature
flag
anyway,
so
like
no
extra
work
but
I
think
that
you're
at
the
start
of
the
call-
or
you
mentioned
like
trying
a
feature
flag,
small
project
on
the
existing
nodes
right.
But
we
can't
do
that
right
now,
if
we're
going
to
run
a
discus
yeah.
But
what,
since
we're
doing
a
Combinator,
if
we
can
still
do
like
the
you
know,
start
with
a
small
project
thing.
C
E
C
A
Cool
okay,
Cheers.
Okay,
thanks
for
the
discussion
yeah,
the
working
working
group
page
is
up,
so
you
can
have
a
look
and
we
should
establish
exit
criteria.
But
since
we
have
a
business
goal
for
the
group,
but
since
we
don't
know
which
way
we're
gonna
go
with
this
first
and
it's
hard
to
establish
exit
criteria,
so
I'll
open
an
MI
for
this
to
look
at
the
outcomes
of
this
discussion
into
the
into
the
working
group
page.
Don't.
G
Really
know
how
working
groups
work,
but
I'd
suggest
our
first,
like
milestone,
point,
is
to
have
some
kind
of
way
of
testing
this
out,
at
least
in
staging
I,
like
we're
testing
out
the
sidekick
kubinashi
stuff.
Now,
as
soon
as
we
can
get
to
that
point,
I'll
feel
I
feel
like
we're.
Definitely
getting
close
for
sure.
So
I'd
suggest
that's
probably
our
first.
G
D
G
G
I
mean
Heinrich
I
can
talk
to
you
separately,
maybe
tomorrow,
because
I
know
it's
sort
of
getting
late
for
you
and
also
I've
got
childcare
all
day.
Today,
apart
from
that
time,
which
is
now
so
limited
time
today,
I
can
talk
to
you
tomorrow
about,
like
you
know
what
I've
been
doing
there.
It's
not
it's
actually
quite
nice
as
a
development
environment.
There
are
a
few
quirks,
but
you
know
you
can
you
could
because
you've
already
done
some
work
in
omnibus
right,
so
you
can
then
make
a
decision
about.