►
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
Oh,
oh,
so
this
is
a
chance
for
us
to
sync
up
and
where
we
are
with
the
kubernetes
migration.
For
me,
this
will
be
a
little
bit
of
kind
of
catching
up
with
what
you've
done
so
I
hope
it'll
be
useful
for
you
to
also
just
review
like
exactly
what
we're
trying
to
get
out
of
this,
but
then
may
need
to
work
out
like
what
what
makes
sense
to
pick
up
next.
A
B
Both
those
I
think
I
think
on
the
to
lean
side,
we're
doing
pretty
well
right
now
on
the
monitoring
side
and
I
think
we
could
be
doing
better
with
our
dashboards
and
things
like
that.
I
added
a
comment
in
the
agenda
about
that,
but
other
than
that
I
think
yeah
I
mean
we
could
just
focus
on
the
next
steps
for
migration
and
and
kind
of
focus
on
the
areas
where
we're
unblocked,
because
I
think
for
some
of
the
flea
types
were
completely
blocked.
Until
we
see
changes,
improvements
in
the
application,
mm-hmm.
A
B
Yeah
sure
so
this
status
of
this
hasn't
changed
and
blocked
for
a
while.
Now
this
epoch,
specifically,
is
about
unmounting
shared,
manifest
Server.
We
actually
have
two
NFS
servers,
one
for
what
we
call
shared
storage.
It
essentially
is
just
storage,
that's
shared
between
the
front
end
and
the
back
end
and
the
sort
of
a
catch-all
storage
for
shared
storage,
the
other
is
pages
and
pages,
is
used
for
the
backend
storage
for
the
pages
fleet.
That
is
also
mounted
everywhere,
B
and
F.
B
That's
this
particular
epoch
is
focusing
on
the
shared
NFS
mount
and
it's
blocked
on
two
issues.
One
of
them
is
traces,
and
the
other
is
this
caching
layer
that
we
use
for
artifacts
that
one
I
think
will
probably
resolve
easier
than
the
traces
one.
The
traces
one
there's
some
discussion
about
how
to
make
that
a
bit
more
performant.
It
sounds
like
or
not
sure.
Well,
that's
gonna
happen,
possibly
Grady
they're
dedicated
by
this.
B
You
know
dedicated
ready
server
for
this
I,
don't
know
where
it's
gonna
end
up,
but
I
don't
expect
this
to
be
resolved
soon.
I
would
say,
like
probably
no
sooner
than
the
next
two
releases,
but
we'll
see
so
that's
kind
of
where
we
are
now
and
what
this
does
is
it
blocks
us
on
some
cues
that
depend
on
manifest,
so
we've
been
focusing
right
now
on
identifying
cues
that
depend
on
NFS
doing
our
best.
B
B
B
A
A
And
then
my
great
urgent
other
are
shards
complete,
which
that's
great
ok,
so
we've
got
some
of
the
question
head
around
they're
listed
as
not
started,
so
the
migrate,
urgent,
cpu-bound
shard
and
migrate
capsule
shard.
Neither
of
those
has
an
epic
at
the
moment.
As
far
as
I
could
tell,
unless
age
went
leaked,
yeah.
B
I
mean
five
minutes
ago:
you're
right
I,
just
created
one
you're
gonna
ask
I
just
created
one
for
urgent
cpu-bound.
It
doesn't
have
issues
associated
yet,
but
it'll
probably
follow
the
scene.
You
know
it's
the
same
issues
for
the
previous
charts.
I
put
on
item
number
four
in
the
agenda.
If
you
click
on
that
urgency,
P
you
bound
think
that's
the
epoch,
but
I
haven't
added
the
issues
for
it.
I
think
this
one
makes
the
most
sense
to
to
get
going
on.
We,
you
know
Sean's
been
helping
out
with
this,
and
it
sounds
like
that.
A
B
I
did
open
up
the
charts
issue
for
being
able
to
set
the
HPA
configuration
for
each
shard
separately,
and
this
is
something
that
came
up
during
urging
to
others.
Skarbek
pools.
Remember
that
we
were
kind
of
messed
around
with
this
I
like
to
get
that
completed
before
we
do
the
next
migration
and
I
think
that's
something
that
we
can
just
pick
up.
You
know
because
we
yeah
we
can
just
we
can
just
submit
an
mr2
charts
to
do
this.
I
think
that's
it.
B
C
B
D
B
Okay,
I
wanted
to
just
touch
base
to
ask
if
you
think
before
I
do
the
code
changes
I
want
to
make
sure
that,
like
as
the
maintainer
you're
gonna
accept
them?
So
if
you
think
it's
a
good
idea,
I
will
I
will
go
ahead
and
submit
NMR
for
that,
while
I
have
your
ear.
The
other
kind
of
blocking
issue
is
this
dependency
proxy
issue,
which
is
for
b1
in
the
agenda
and
I
guess
you're
not
on
the
agenda.
B
D
D
D
Since
you're
not
blocked
on
actually
making
the
migration
right
now,
it
does
like
we
have
issues
that
are.
They
need
to
be
done
in
this
milestone
or
very
early
in
the
next,
because
we're
blocking
you
from
actually
achieving
your
okay
are
in
point
where,
as
a
production
request
is
we're
gonna
need
this
soon,
it's
kind
of
like
a
priority
flag
for
us.
What
comes
to
what
production
needs
now
versus
what
they'll
move
soon?
Oh
cool.
B
Yeah,
that's
it
for
sidekick
and
then
I
mentioned
for
completeness.
I
mentioned
the
blocking
issues
for
the
get
and
WebSockets
fleet,
as
well
as
the
web
in
a
P
I
for
gettin
WebSockets
the
blocking
issues
there.
We
have
the
charts
issue
for
supporting
the
separate
database
endpoint
for
sidekick
and
web
service.
I
think
Jason
you're
familiar
with
this
one.
B
B
A
B
B
I
think
we
can
just
take
this
up
again
and
see
and
and
then
web
api
is
the
last
one
and
the
TLDR
of
that
one
is
like
we're
completely
blocked
until
we
fix
pages
and
share
manifests,
there's
really
no
no
way
around
it.
Both
the
web
in
the
API
fleet
must
have
the
pages
and
a
fast
mount,
and
until
they
just
supports
object
storage,
that's
just
completely
blocked,
poof.
D
I
can
interject
on
the
pages
thing,
I
100%
agree.
That
pages
needs
to
have
object,
storage
and
we
should
not
need
NFS
for
all
of
these
things.
What
I
will
inject
is
you
have
done
this
in
some
degree
already
on
the
sidekicks
and
technically
there
is
kind
of
a
way
to
use
the
extra
volumes
behavior
to
inject
the
dedicated
NFS,
just
a
little
pain
to
this
file
system.
I'm,
not
saying
I
love
it
I'm
saying
it
may
be
a
way
to
unblock
pending
further
updates
from
that
team.
Yeah.
B
B
B
So
these
are
yeah,
so
the
first
one
had
cluster
logging
visibility.
The
logs
from
our
kubernetes
cluster
are
not
going
to
elasticsearch
they're,
only
going
to
stack
driver
and
this
yeah.
This
kind
of
sucks
I
mean
like
we
typically
use
elastic
search
for
all
of
our
logging.
Going
to
stack
driver
is
a
pain,
and
also
only
only
a
select
number
of
people
can
do
this
and
call
me
a
sorry's
right
now:
canoeing,
it's
not
actually
for
fauna,
annotation
or
deployments
actually
I.
Don't
know
how
important
this
is.
C
C
B
Adding
more
traffic
to
registry
canary
this
is
one
that
I
would
like
to
do,
though
Amy
the
way
that
so
we
have
what
is
called
the
canary
stage
in
the
main
stage.
The
canary
stage
is
a
subset
of
virtual
machines
that
service
requests
that
have
a
cookie
set
in
your
browser
that
says
David
canary
equals,
true
or
certain
request
paths.
So
if
you
go
to
get
web
or
give
up
or
get
con
like
infrastructure,
you're
going
to
automatically
be
routed
to
this
subset
of
VMs,
we
do
this
NH
a
proxy.
B
Currently,
the
registry
service
is
also
using
this
request:
faith
based
routing
because
the
registry,
it
doesn't
have
cookies.
So
it's
a
sign
age
to
be.
You
know,
like
your
browser,
so
when
you
do
a
doctor
or
pool
or
doctor
push,
if
the
path
matches
a
certain
like,
you
know,
red
X,
then
we
brought
it
to
this
canary
name
space
in
our
kubernetes
cluster.
Currently
it
receives
very
little
traffic
and
we've
talked
about
just
starting
to
use
a
percentage
of
traffic
instead
of
these
hard
couldn't.
B
A
B
B
So
what
we
decided
to
do
was
just
tap
the
number
of
pods
like
set
the
minimum
and
the
maximum
to
the
same
number,
and
that
meant
that
we
had
a
very
like
little
backlog,
but
we
would
just
work
through
it
quickly
and
then
we
would
continue
on.
Since
then,
this
misbehaving
queue
has
been
moved
off
of
discharge.
So
we
wanted
to
reevaluate
something
we
discussing
the
marryin
to
reevaluate.
Turning
on
auto
scaling
again,
and
also
with
like
setting
HPA
per
charge,
which
is
the
earlier
charts
issue.
B
I
think
we
can
probably
reevaluate
this
to
general
improvement
to
dashboarding
4k
eights,
like
you
had
the
dashboarding
for
Cooper.
Now
these
sucks
right
now
and
I.
Think,
like
you,
don't
have
an
issue
that
will
prove
it,
but
probably
should
maybe
we
could
improve
it,
a
bit
mm-hmm
karma.
Can
you
say.
B
B
C
A
A
B
D
B
D
Forgive
me,
let
me
give
you
a
look:
not
just
playing
Schrute
SSH
I'm,
talking
slightly
more
controlled,
we're
familiar
with
and
have
access
to
a
number
of
operating
systems
that
support
and
spawn
and
spawn
has
full
name
spacing
patterns,
so
you
can
actually
fully
jail.
The
entire
process
set
out
yeah.
B
B
B
Like
yeah,
yeah,
I
think
we're
looking
at.
We
were
looking
at
for
a
first
iteration,
the
most
boring
thing
possible,
which
would
be
just
to
leverage
existing
terraform
existing
chef,
separate
VMs,
but
like
I
I'm,
not
super
convinced
and
I
would
agree
with
you
like
they're,
probably
better
at
least
feel
about
it.
I
don't
know
it's.
B
D
B
B
A
C
B
C
Easy
like
if
any
businesses
made
the
release
management
process,
super
easy,
like
I,
mean
I'm
being
seriously
like
take,
for
example,
deployments
happen
in
kubernetes
within
ten
minutes,
whereas
the
point
to
the
same
fleet
of
servers
takes
over
a
30.
So
there's
stuff
like
that,
I
think
if
anything,
there's
just
general
tooling
improvements
that
we
could
do
but,
like
you
know,
jars
highlighted
the
primary
ones
here.
A
C
Any
preference
as
to
what
we
primarily
work
on,
if
maybe,
if
we
want
to
start
exploring
other
things
outside
of
our
application,
we
could
start
maybe
looking
at
that
stuff,
I
job
and
I
spoke
to
each
other
at
one
point
and
I
was
thinking
we
can
potentially
move
over
PG
bouncer.
You
know,
because
that's
the
stateless,
supposedly
a
stateless
application
service
that
you
know
everything
connects
to
that.
D
Yeah
one
of
the
things
that
that
our
team
is
it
wants
to
investigate
further
is
using
osei
registry
for
that
the
support
is
coming
along
much
better
in
3.2
plus
of
Hell
itself,
and
we
as
a
product
really
need
to
dig
into
that
and
how
we
would
tie
a
Helmer
industry
into
our
existing
OCI
comply
in
container
registry,
because
very
basically,
anyway,
it's
just
a
manifest
difference.
So
being
able
to
do
that,
get
us
away
from
pages
still
has
our
resilience
in
the
backing
storage,
but
also
gives
us
the
fleet.
There's
ONC
of
running.
B
B
C
C
B
Good
I
was
gonna,
say
I
was
gonna,
say
like
I.
First
I
really
liked
the
auto
rollback
and
now
I
do
not
like
it
because
it's
it's
caused
some
surprises,
and
it
makes
you
a
little
bit
lazy
because
you,
like
you,
see
the
rollback
and
you're
like
okay,
everything's,
fine
I'll,
take
my
time
and
fix
the
problem.
But
while
you're
fixing
it
someone
else
were
just
something
and
but
it
breaks
again
so.
C
C
It
doesn't
automatically
rollback.
Helm
is
just
going
to
sit
there
until
the
next
deploy
is
successful,
so
we're
gonna
have
some
thrashing
pods
constantly
trying
to
start
up
over
and
over
again
and
well
that's
kind
of
low
on
the
performance
hog
scale.
It
is
kind
of
worrisome
that
we're
going
to
have
something
screwing
with
our
metrics,
because
we're
going
to
have
two
deployments,
that
of
say
sidekick,
attempting
to
run
one
will
be
running
and
one
will
be
attempting
to
run
at
the
same
time
and
that's
going
to
make
our
metrics
look
a
little
weird.
C
I'm
another
I
know
we
have
an
issue
for
this
somewhere,
but
if
there
are
issues
with
helm,
we
don't
we
have
poor
visibility
into
it
during
the
CI
job.
Currently
we
have
to
really
dig
into
our
metrics,
or
we
have
to
be
on
the
cluster.
Looking
at
why
a
pod
is
failing
for
X
reason,
there's
nothing
in
our
Seattle
CI
logs.
That
says:
hey
we're
rolling
back,
because
we
failed
because
of
this
specific
thing
caused
the
problem
it'll
be
nice.
C
C
C
Like
we've
got
the
necessary
pod
logs,
so
we
could
look
at
why
a
pod
failed
to
start,
and
we
of
course
have
the
timing
data.
So
we
could
look
at
the
right
timing,
which
all
that
happens.
It's
just
it's
it's
difficult
to
there's
a
lot
of
work
involved
to
troubleshoot
it
as
all.
So
if
we
can
make
that
more
seamless,
that
would
be
a
huge
nice
to
have.
A
B
Yeah
I
agree,
I
think
like
as
far
as
the
next
shard
for
sidekick.
We
can
definitely
work
on
the
stuff
in
parallel.
I
think
any
of
these
other
issues.
We
don't
really
have
any
from
where
I
stand.
We
don't
have
any
p2p
Tuan
issues
or
if
we
do
they're
kind
of
they're
being
worked
on,
so
nothing
that's
would
prevent
us
from
doing
things
in
parallel.
Okay,.
B
Config
yeah,
because
I
think
this
is
probably
I
mean
we
can.
We
can
work
on
some
things
in
parallel,
but
yeah
I
think
getting
that
done
and
also
laying
the
groundwork
for
the
urgency
PU
bound
migration,
which
is
just
like
creating
the
note
:
terraform
doing
the
analysis
for
how
we
want
the
SPECT
it
initially
and
then
later
finding
out
that
respect
it
completely
wrong
and
then
changing
it
ten
times.
A
B
B
We
probably
should
have
taken
the
more
conservative
approach
and
over-provisioned
and
turning
off
auto
scaling
and
then
introduced
auto
scaling
for
the
other
shards
we
do
have
auto
scaling
enabled
and
we
actually
do
scale
up
and
down
between,
like
even
on
peak
I,
don't
know
if
we're
doing
the
scaling
very
efficiently,
but
it's
happening
and
it
seems
to
roughly
correlate
with
like
peak
traffic.
You
know
like
it
looks
decent,
but
the
fact
is
is
that
what's
our
sidekick
boot
time
right
now,
spare
back?
Is
it
Jay.
B
D
Been
running
master
from
about
five
days
ago
off
with
that
or
off
of
a
auto
deploy
branch
that
had
it
and
I
made
sure
that
that
mr
was
was
set
with
picking
the
auto
the
boy
you
should
have
this
functionality.
This
greatly
increases
the
speed
of
the
dependencies
container.
It
reduces
the
CPU
load,
reduces
reduces
the
I/o
load
so
that
that
god-awful
contention
when
sidekick
is
churning
is
not
there
anymore,
but
you
still
have
to
wait
for
once.
The
dependencies
are
good.
D
C
While
you're
demoing
a
mage's,
I
added
a
few
items
to
the
other
issues,
it's
been
a
long
time
desire
for
both
the
distribution
team
as
well
as
delivery
to
see
if
we
could
scale
based
on
metrics
instead
of
our
current
method
of
scaling,
which
is
based
on
CPU
utilization
and
there's
an
issue
somewhere
for
that.
I.
Don't
know
where
it
is,
and
then
Alessio
recently
created
an
issue
to
discuss
what
we
could
do
to
make
deployments.
A
C
D
We
definitely
need
to
break
that
down
mostly
because
the
way
custom,
metrics
patterns,
work
inside
of
kubernetes
often
require
some
extra
implementation.
That's
not
natively
supported,
so
there's
a
number
of
things
we'll
have
to
do,
and
we
do
have
an
issue
over
on
the
charts
trying
to
figure
out
how
we
can
do
that
and
what's
required
to
make
it
actually
function.
So
that's
probably
gonna
be
an
epic
that's
going
to
spend
at
least
two
milestones
right.
C
A
C
C
D
And
I'm
really
happy
to
see
they
like
that
level
of
difference
here,
because
if
you
look
at
the
oldest
the
youngest
pod
that
you
have
there
I
think
you
saw
it
at
57
seconds.
If
you
scroll
up
a
ways,
your
terminal,
when
you,
when
it
finally
showed
up
it,
showed
up
as
the
youngest
one
at
50
seconds
old,
57
seconds
old
and
running
so.
B
A
B
B
C
B
C
C
B
Other
than
sidekick,
we
need
to
console
agent
running
in
the
cluster,
because
we
use
console
dns
to
figure
out
the
database
replicas
endpoints
and
the
reason
why
we
didn't
need
this
from
sidekick
was
because
I'd
take
only
uses
the
primary
database.
So
it
only
connects
to
one
database
endpoint,
just
the
primary
for
everything
else.
They
also
have
like
internal
load
balancing
where
they
connect
to
like
a
bunch
of
replicas.
B
C
B
B
So
so
for
some
background
for
Amy
we
have
we
use
PG
bouncer
as
a
database
puller,
and
we
have
a
PG
bouncer
for
the
primary,
which
is
a
standalone
like
PG
bouncer
fleet,
and
then
each
replica
also
has
a
local
PG
bouncer
that
is
used
as
a
connection.
Puller
that's
installed
locally
alongside
a
Postgres
and
the
PG
bouncer
we
need
is
that
one
so
I,
don't
I,
don't
think
that
would
help
store
that
right.
I
guess
not
that's
unfortunate,
but
I
think
you'd
be
good
to
get
this
console
thing
running
anyway.
B
A
Great
and
we've
got
quite
a
few
of
their
sort
of
lower
priority
issues
if
we
could
get
them
into
issues
on
an
epic
saz
makes
sense.
That
would
be
great
a
particularly
interesting
that
one's
government
you
mentioned
about
the
scaling
based
on
metrics,
like
I,
think
that's
going
to
have
some
long
term,
like
that's
gonna,
be
really
important
at
some
point.
So
that's.
C
Going
to
benefit
a
lot
of
people,
but
it's
gonna
require
a
lot
of
coordination
with
distribution,
because
we
need
to
make
sure
that
the
whatever
solution
we
come
up
with
is
usable
for
self-manage
installs,
plus
our
use,
IQ
live
account,
so
I
think
we're
going
to
see
the
need
to
improve
our
charts
before
we
are
able
to
take
advantage
of
it.
Like
Jason
said
it's
going
to
be
a
multi
milestone
situation.
I
think
all
of
us
are
thoroughly
interested
in
seeing
that.