►
From YouTube: Distribution Group Conversation (Public Livestream)
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
Hello,
everyone
welcome
to
the
distribution
group
discussion.
Conversation,
I'm,
DJ
I
am
a
senior
engineer
on
the
distribution
team
and
filling
in
as
interim
manager,
and
we
have
several
other
members
of
the
team
here
on
the
call
in
the
agenda
doc.
We
have
linked
to
the
slides,
and
so,
if
anyone
has
any
questions,
I
want
to
raise
the
team
right
away,
feel
free
to
jump
in
now.
Ask
question
otherwise:
I'll
maybe
highlight
a
few
things,
so
anyone
have
anything
they
wanted
to
shout
out
to
the
team
right
away.
A
And
if
not,
I
will
go
ahead
and
just
highlight
some
of
the
things
from
the
slide.
So
on
the
sixth
slide,
we
call
out
the
help
charts
our
accomplishments
for
the
past
two
months.
So
some
of
the
things
that
the
distribution
team
has
been
working
on
include,
we
got
support
for
the
new
beta
elasticsearch
indexer
that
you'll
abusing
we
have
support
for
that
in
the
charts,
so
that
was
added
in
we've
created
a
bootstrap
script
for
for
the
helm,
charts
for
booting
up
an
e
KS
cluster.
So
we've
already
had
one
for
gke.
A
We
created
one
for
EPS,
so
we're
working
towards
also
having
EPS
be
part
of
our
CI
runs
as
well
for
all
the
changes
going
into
the
charts.
So
that's
going
in
very
soon,
and
we
also
had
quite
a
quite
a
few
changes
going
recently
into
the
charts
revolving
around
support
for
the
Google
cloud
platform.
Support
for
the
Redis
memory
store
the
cloud
sequel
and
the
Google
Cloud
storage.
So
we
had
changes
coming
in
there
from
the
community
as
well
as
from
partners
and
recently
related
related
to
that.
A
B
You
should
be
better
yeah,
yeah
sounds
good,
so
the
elasticsearch,
it's
added
to
our
helm,
charts,
that's
pretty
cool,
so
that
works
by
default.
Are
we?
Are
we
also
adding
it
to
only
because
I
think
not
graph
Anna?
Are
we
adding
that
to
the
helm
church?
Are
we
adding
that
to
omnibus
and
fault?
I
saw
plans
added
to
the
helm
charts,
but
not
to
omnibus?
If
what
are
you
thinking
about
that,
so.
A
For
elasticsearch,
we
on
the
new
beta
indexer
for
elasticsearch
actually
went
into
omnibus
before
it
went
into
the
charts
so
that
new
indexer
is
already
there
and
shipped
with
on
the
bus.
The
the
addition
of
it
to
the
charts
was
a
follow
up
to
get
it
working
there.
Where,
in
the
charts
we
didn't,
we
weren't
able
to
use
the
previous
one.
The
new
one
is
able
to
use,
get
lead
for
indexing
so
prior
prior
to
being
able
to
use
that
the
new
one
we
weren't
able
to
provide
any
elasticsearch
support
in
the
charts.
A
So
that's
kind
of
why
we
called
it
out
here
in
terms
of
graph,
and
that
is
also
already
shipped
in
omnibus.
The
monitor
team
has
been
working
on
that,
but
there's
several
improvements
to
to
that
going
forward
and
at
the
moment
I
don't
think
we
have
at
least
it's
not
on
the
roadmap
to
include
it
in
the
charts
as
far
as
I've
seen
but
I.
Imagine
that
would.
That
would
be
something
that
would
make
sense,
of
course,
but
it's
not
not
currently
something
we've
seen,
we've
logged
or
taken
it
and.
C
We
haven't
officially
planned
that
one,
yet
we
need
to
scope
out
what
the
requirements
are
and
the
impact
that
would
have
as
an
optional
feature.
They
do
maintain
their
own
chart.
So
it's
a
possible
that
we
could
pull
in
their
charts.
We
have
to
see
whether
or
not
we
can
automatically
integrate
the
existing
Griffin
with
the
Prometheus
that
we
integrate
and
then
tie
all
that
together
with
OAuth
through
the
charts.
C
B
A
A
For
for
vault
I,
don't
know
that
it's
planned
for
the
chart
either
at
this
point,
so
we
have
had
plans
we
we
have
had.
We
do
have
issues
open
to
look
at
it
in
both
the
the
charts
and
the
Omnibus,
but
I
believe
they're
on
hold
in
both
in
the
Omnibus
we've
been
waiting,
basically
waiting
on
rails
updates
in
order
to
instead
focus
first
on
secret
management
and
making
use
of
the
new
features
coming
in
to
upstream
rails.
In
regards
to
that.
B
A
B
More,
what
you
were
you
yeah.
I
think
I
think
it's
really
important
for
us
to
kind
of
start
talking
about
the
indexer
when
we
refer
to
the
index
or
say
the
elasticsearch
index,
or
not
a
last
search,
because
I
think
it's
pretty
confusing
to
say,
like
it's
part
of
our
six
search,
part
of
the
chart,
yeah.
C
That's
why
I
put
down
the
elastic
search
they
actually
have
a
chart.
However,
a
large
deployment
is
required
for
that
and
there's
a
lot
of
back-end
understanding
of
how
everything
actually
deploys
and
that's
one
of
the
biggest
reasons
we
haven't
decided
to
actually
deploy
elastic,
search
as
a
service,
either
as
part
of
the
charts
or
as
part
of
omnibus.
Right
now
is
the
sheer
amount
of
orchestration,
that's
required
number
nodes
and
the
backing
resources.
B
C
C
A
Yeah
the
other
thing
to
bring
bring
up
with
the
graph
Anna
is
currently
the
implementation
in
any
of
us
is
being
led
by
the
monitor
team,
and
it's
just
the
the
integration
points
into
the
omnibus
that
were
heavily
reviewing
and
testing
right.
Now,
that's
that's
being
led
by
a
being
done
by
been
on
that
team.
At
the
moment,
cool
thanks.
D
A
Yeah,
it's
actually
any
time
you
you
need
to
engage
or
want
to
engage
one
of
the
distribution
engineers
in
in
a
call
with
a
customer
that
the
new
documented
process
is
the
way
to
go.
We
like
to
have
an
issue
open,
so
we
can
default
to
tackling
the
issue
or
having
multiple
people
look
at
it,
asynchronously
first.
A
So
the
issue
it's
documented
in
in
the
link
on
that
page,
but
the
issue
should
include
links
to
the
resources
necessary
for
us
to
come
up
to
speed
ahead
of
time,
but
but
also
it
provides
us
a
way
to
make
it
visible
what
our
engineers
are
working
on,
and
we
also
make
use
a
bit
of
the
time
tracking
and
issues
to
see
after
the
fact
how
much
time
our
engineers
are
spending
on
these
on
the
cult's
yeah.
D
I
think
I
think
the
process
is
I'm
glad
you
folks
have
documented
it,
because
I
know
that
I
felt
bad
in
the
past
stealing
Jason's
time
for
a
customer,
so
I'm
glad
that
it's
documented
and
that
time
can
be
tracked.
Is
there
some
kind
of
a
lead
time
that
should
be
required
to
recommend
it
for
these
things,
like
between
the
time
of
filing
an
issue
and
asking
for
help
on
a
particular
call?
What
what
kind
of
time
frame
should
there
be
in
there
I.
A
Think
we
definitely
want
a
lead
time,
but
of
course,
especially
when
dealing
with
support
emergencies
or
emergencies,
for
example,
we
still
we
still
like
to
have
the
the
issue,
but
sometimes
for
an
emergency.
For
example,
the
issue
might
come
in
after
the
fact,
so
we
could
document
what
went
on
and
add
to
spend
on
it,
but
but
I
would
say
I'm
just
throwing
this
out
there
I
don't
know
the
rest,
he
might
have
other
opinions,
but
for
non-emergencies
I.
Think
we'd
prefer
to
have
you
know
around
the
48
hour
mark,
probably
okay,.
D
A
D
A
C
Dj
said
there
are
occasionally
extenuating
circumstances
like
customer
outage
where
yeah
that's
an
emergency,
we're
totally
gonna
jump
on
that
as
best
we
can,
but
we
still
want
the
process
to
be
followed
in
the
end.
So
we
have
a
trail
and
everything
that
we
need
for
that.
So
yeah,
there
are
occasions
when
we
can
circumvent
that
lead
time,
but
it
will
not
be
a
general
rule.
No.
D
C
A
Yeah
so
in
terms
of
Omnibus
I,
don't
I
think
I
think
it
looks
like.
Maybe
you
have.
You
probably
already
have
an
idea
of
based
on
what
you're
already
saying:
that's
the
the
rails,
application
kind
of
is
there
by
default
and
everything
else
you
have
to
turn
on.
So
we
have.
We
have
rails
and
Prometheus
and
everything
that
supports
those
on
by
default
and
everything
else.
You
have
to
kind
of
go
in
and
configure
and
turn
on
in
the
case
of
the
charts.
A
It's
it's
mostly
based
off
the
same
approach
with
with
the
additions
that
we
we
added
any
anything
that
was
more
part
of
our
idea
to
production
story
when
we're
starting
the
charts
may
have
got
turned
on
so
in
the
face
of
the
choice.
Registry
is
turned
on
by
default,
for
example,
and
like
we
include
a
gait
lab
runner
in
in
the
chart
by
default
are
two
examples
of
additions
other
than
that
I
think
other
than
those
two
additions.
I
think
it's
it's
the
same
services
that
are
on.
We
also
happen
actually
in
the
charts.
A
It
is
just
in
terms
of
how
many
of
those
services
are
running
so
in
in
the
charts
we
default
it
to
being
somewhat
redundant
to
the
number
of
pods.
It's
running
so
there's
already
more
than
one
unicorn
pod
running,
and
it
already
has
an
auto
scaler
on
it
so
that
it
will
scale
up
if
it's
being
hit
with
water
resources
is
the
kind
of
the
bigger
difference
between
what
you
end
up
with.
If
you
just
install
like
omnibus
package,
and
when
you
get
up
you
end
up
with,
if
you
install
the
chart.
B
C
C
A
E
B
Thanks
to
a
tree
and
I'm
I'm
kind
of
repeating
there's
a
bit
of
overlap
between
all
these
between,
like
how
hard
is
it
to
add
it,
to
an
installation
what
is
manual
work
and
what
is
the
timeline
to
adjust
the
limitations
of
the
chart
so
I'm?
Sorry
about
that,
but
I
wonder
a
bit
and
I've
looked
a
bit
at
the
issues
but
forget
lap
pages.
Do
we
have
a
timeline
to
address
the
NFS
limitations.
C
B
A
It's
still
the
the
intent
is
still
not
the
intent,
but
the
expectation
is
that
that
still
won't
be
a
great
experience
unless
youth,
unless
you've
come
in
with
a
better
storage
solution
to
back
it
or
so
it's
really
the
one
we
shipped
with
the
chart
really
still
isn't.
Our
recommendation
for
production.
A
At
the
moment,
just
elaborate
on
that
a
little
bit
I,
don't
know
that
we're
aware
of
of
like
a
standardized
solution
for
that
I
think
there
are
a
lot
of
companies
in
that
space
that
have
have
have
solutions
they're
offering
customers.
So
it's
possible.
The
customers
might
be
running
those
solutions
in
kubernetes,
but
as
far
as
we've
seen
we
don't
have.
We
don't
have
a
clear
one
that
we
can
ship
by
default,
necessarily.
C
Right
away
from
where
it
was
when
we
started
to
work
on
the
charts
and
where
Postgres
and
really
any
state
full
set
was
at
that
time,
we've
actually
been
communicating
directly
with
the
developers
of
the
Postgres
and
rena
starts
upstream
to
be
able
to
better
meet
our
needs
and
understand
the
customer
workloads
that
we
actually
have.
So
that's
we've
seen
a
lot
of
things
actually
come
to
fruition
since
meeting
them
at
coop
con
in
Seattle
in
LA
in
December.
B
A
B
A
B
A
And
for
the
final
one
listed
here,
the
smart
card
authentication-
that
was
a
recent,
a
recent
addition
to
get
lab
and
and
only
of
us
that
we
did
actually
do
a
spike
in
attempt
to
implement
it
in
in
the
charts,
and
we
ran
into
limitations
with
the
nginx
ingress
controller
that
we,
we
still
haven't,
found
a
good
solution
for
essentially
at
this
point
we
have.
We
have
logged
an
issue
in
in
the
rails
code
base
and
in
our
rails,
India
lab
c/e.
A
That
would
provide
us
an
alter
of
option
by
allowing
us
to
use
a
different
domain
for
the
smartcard.
The
foundation
right
now,
you're
only
allowed
to
use
a
different
port
on
your
gait
lab
domain,
but
the
nginx
ingress
mostly
just
likes
to
open
port
80
and
port
443
and
any
additional
ports.
You
open
come
with
a
lot
of
caveats
that
have
been
interfering
there,
so
we
still
have
it.
We
still
have
it
as
a
continue.
A
B
B
C
Think
a
rewording
might
be
better
instead
of
saying
you
know,
limitation
in
comparison
to
the
limitations
of
the
chart
are
actually
listed,
because
those
are
things
that
that
are
a
part
of
the
total
get
lab
application
suite
that
we
can't
do
right,
we're
looking
to
improve
those.
We
have
roadmap
items
for
a
lot
of
them,
but
they're,
not
specifically
the
omnibus
can,
but
we
can't-
or
vice
versa.
It's
these
are
things
that
would
make
the
entire
experience
better
for
susat,
mins
and
users,
etc.
That
we'd
simply
aren't
able
to
do
yeah.
B
Maybe
that's
I
agree,
so
I'm
really
a
limitation
and
does
it
feel
like
that
I
think
we're
not
we
don't
have
to
be
so
go
so
far,
but
maybe
it's
good
to
say
like
hey.
This
is
like
what
you
manual
have
to
do
and
then
we
list
all
the
different
things,
all
the
different
components
of
gitlab
and
we
basically
say
hey.
This
is
automatic.
This
is
manual
and
we
link
to
the
relevant
pieces.
A
Think
there
could
be
better
communication
there,
because
some
of
these
we
actually
have
like
a
pretty
decent
story
for
and
some
of
them
we
don't
like,
for
example,
the
elasticsearch
service.
While
it
does
require
a
lot
of
resources
for
their
existing
charge,
there
is
an
existing
church.
That's
quite
easy,
easy
to
use.
So
it's
it's
like
there.
It
is
already
a
pretty
good
like
path
forward
there,
whereas
maybe
something
like
vault
isn't
as
clear
how
that
would
integrate
in
as
it
is
now
and
require
a
lot
more
manual
steps,
for
example,.
B
I
think
that'd
be
interesting
like
to
see
that
either
there's
an
issue
planned
for
it
or
there's,
there's
installation
instructions,
and
we
have.
We
now
have
two
projects
and
it's
kind
of
hard,
it's
hard
for
me
to
wrap
my
head
around
this
and
also
I
think
we
have
a
lot
of,
but
I
said.
The
underlying
problem
is:
there's
lots
of
customers.
They
just
follow
our
installation,
instructions,
I,
think
they're
done.
They
never
set
up
the
elasticsearch.
They
never
set
up
gräfin.
They
never
set
up
these
things
that
are
manual
and
I.
B
A
Yeah
I
would
say
it
looks
like
we
are
missing
a
few
things
in
the
limitations
right,
the
graph
Anna,
for
instance.
We
are
shipping
that
a
nominee
of
us
it
should
have
been
listed
here.
Another
one
that
isn't
listed
here
that
should
be
is
matter
most
as
well,
which
they
they
additionally
now
have
a
chart
ready
to
go
matter.
Most
does
as
well.
Yeah.