►
From YouTube: Enablement 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-
it
is
the
top
of
the
hour,
so
we
can
go
ahead
and
get
started
today.
Is
the
group
conversation
for
the
for
the
enablement
section?
My
name
is
Eric
Brinkman
I'm,
the
interim
director
for
a
product
for
the
enablement
section
and
then
I
wanted
to
give
a
big
shout
out
and
thanks
to
chunda
who's,
our
enablement
section
engineering
director
for
assisting
with
a
lot
of
the
slides,
I,
don't
know
Chun.
If
you
want
to
say
hi
hi
everybody
good
mommy,.
A
B
D
So
right
now
we
are
running
on
dev.
For
two
weeks.
The
configuration
on
Def
is
like
the
same
number
of
workers
unicorn,
but
we
are
running
four
times
more
threats
than
on
unicorn,
so
we
have
I,
probably
free
and
half
more
capacity
in
terms
of
the
processing,
the
requests.
We
don't
find
like
any
problems
right
with
ronique
on
death.
We
actually
this
week,
enabled
Puma
on
the
ops
key
table
dotnet
with
help
of
the
turf.
D
C
C
D
Are
on
site
key
for
in
the
multi-threaded
mode,
but
I,
it
seems
to
me
like
working
fine,
at
least
from
our
testing.
We
did
not
change
any
configuration
since
it
was
enabled,
so
it
is
surprising,
that's
why
I
mean
we
need
a
little
more
validation
with
changing
different
configuration
settings.
But
it's
what's
very
promising.
At
this
moment,
Thanks.
E
C
C
A
A
A
C
A
The
goal,
so
the
epic
epic
description
is
a
great
summary
here,
which
is
essentially
letting
users
hit.
You
know
one
one
URL
and
then
kind
of
arbitrating
between
the
two
of
those
two
based
off
of
between
their
primary
and
their
geo
deployment
based
off
of
what
can
serve
content,
the
quickest
based
on
where
they
are
in
the
world,
so
once
this
is
enabled
and
we
get
geo
on
comm,
which
is
just
another
gitlab
instance.
Obviously
we'll
take
advantage
of
this
feature
thanks.
A
F
G
Let
me
unpack
that
just
a
little
bit,
there's
a
couple
couple
questions
in
there.
It
sounds
like
kind
of
going
backwards
from
the
OpenShift
question.
We
are
working
to
understand
the
access
changes
that
we
need
to
make
our
permissions.
There's
a
person,
that's
working
on
that
specifically,
but
I,
don't
think
is
on
the
call
right
now.
It's
it's
an
ongoing
thing.
We
we
make
changes.
Then
we
find
new
new
issues
that
we
need
to
to
address
as
OpenShift
progresses,
but
there.
G
We
have
issues
when
we
upgrade
where
services
don't
start
and
stop
in
the
right
order
or
services
say
they're
stopped,
but
they're
not,
and
things
get
stomped
on
we're
making
great
progress
on
that
Jason
I
think
you
are
on
the
call.
If
you
want
to
talk
a
little
bit
more
about
sort
of
the
specifics,
we're
seeing
with
the
operator
and
helm,
help
us
kind
of
paint
the
picture
a
little
better
sure.
H
Yeah
I'm
here
so
we've
been
trying
for
a
while
now
to
develop
an
operator
that
handles
the
actual
life
cycle
of
the
application
instance
itself.
What
we've
run
into,
however,
is
when
we
integrate
that
operator
and
deploy
that
through
helm
into
kubernetes,
we're
starting
to
see
a
problem
where
helm
and
its
way
of
converging
all
the
settings
and
making
or
that
the
state
matches
what
it
expects
does
not
align
to
what
we
are
expecting
it
to
actually
deploy.
So
we
have
kubernetes
doing
some
of
the
work.
H
We
have
helm,
trying
to
reconcile
everything,
and
then
we
have
our
operator
in
between
the
two
going.
Well,
it
should
be
paused,
helm
told
it.
It
should
be
paused,
but
kubernetes
hasn't
paused
it
yet,
and
then
it
gets
paused
and
then
he'll
unpause
it
and
the
kubernetes
tries
to
posit
again.
In
the
meantime,
the
wrong
pods
are
starting
in
the
wrong
order.
F
G
C
Yeah
we
we're
struggling
a
bit
with
elasticsearch.
We
still
don't
have
proper
repo
search
on
comm
and
it
looks
like
it
will
get
more
important
over
this
in
the
future.
For
example,
you
could
imagine
for
comm,
we
offer
the
possibility
to
kind
of
we
have
other
develops.
We
allow
you
to
bring
your
own
cluster.
Maybe
we
offer
clusters
in
the
future,
who
knows,
but
maybe
we
offer
the
option
to
manage
your
logs
as
well.
C
Should
we
should
we
double
down
and
make
sure
that
we're
experts
at
elasticsearch
and
I'm,
not
sure
that
should
come
in
the
form
of
a
team
or
experts,
but
I
think
right
now,
where
we
don't
have
enough
people
who
are
really
good
at
that
and
I
wonder
how?
Where
is
whether
that
is
a
shared
concern
and
how
we're
gonna
solve
it?.
A
I
can
give
my
thoughts
and
then
Shawn
would
love
to
hear
your
thoughts.
Aren't
really
anyone
else
in
engineering
as
well.
So
my
thought
is
in
just
a
level
set
for
everyone
else
on
the
call
or
who
may
be
watching
is
that
elasticsearch
right
now
is
driven
out
of
our
create
stage,
which
is
actually
in
our
dev
section.
So
it's
not
in
enablement
today
and
the
primary
reason
that
we
made.
A
A
Right
now,
there's
a
number
of
initiatives
going
on
with
with
respect
to
elasticsearch,
one
of
the
first
of
those
is
enabling
elasticsearch
foreget
lab
comm.
Unfortunately,
it
doesn't
come
for
free.
We
have
to
run
infrastructure
to
handle
the
index
size
for
elasticsearch.
There's
a
there's,
an
issue
that
I've
pasted
in
the
agenda,
doc
that
kind
of
outlines
some
of
that
and
where
that,
where
that
lies,
with
respect
to
our
infrastructure
teams,
priorities
I,
think
you
know
to
maybe
succinctly
answer
your
question
said
I
think
we
should
consider
a
team
that
is
focused
on
elasticsearch
I.
A
Don't
think
that
it's
maybe
getting
the
right
amount
of
prioritization,
and/or
visibility
and
focus
right
now.
The
other
thing
to
consider,
too,
is
that
we
we
just
refactor
the
dogfooding
coach
product
manager
in
the
enablement
section
into
an
infrastructure
p.m.
that's
going
to
work
more
closely
with
infrastructure
engineering
team
tell
prioritize
and
to
bring
a
bit
more
of
like
an
ROI
driven
approach
to
prioritization
there.
This
is
something
that
they
could
also
take
on
as
well,
so
that
could
be
a
consideration.
A
C
I
think
that's
also
happening
is
the
normalization
of
deviation
like
we're
now,
looking
at
the
cost,
we're
looking
at
ROI
looks
search
on
get
Lancome
for
a
repo
is
broken.
It's
not
okay,
we
host
people's
repos.
They
should
be
able
to
search
those.
So
just
the
fact
that
we're
talking
about
ROI
and
cost
tells
me
that
in
this
case,
we
just
don't
realize
how
bad
of
an
experience
is.
It
is
we're
teaching
people
at
get
map
like
hey.
You
have
to
download
the
repo
locally
to
even
search
in
it.
C
Now
we
don't
have
to
do
that
anymore
because
we
fix
it
for
ourselves,
but
that's
not
an
experience.
That's
acceptable
to
our
users
and
I
think
we're
as
a
company
we're
kind
of
we'll
put
our
head
in
the
scent
of
how
big
of
a
problem
this
is
for
our
users
and
how
unacceptable
this
is
compared
to
likely.
We
want
to
be
up
there
with
the
best
of
the
solutions.
I
think
we
are
in
every
single
way,
except
for
this.
C
Yeah
and
I'll
take
this
to
the
p.m.
enjoy
the
product
engineering
meeting
to
review
as
well.
Both
both
things
like
hey
do.
We
need
more
experts
here,
I
think
we
we
should
focus
on
this
run
hiring,
but
also
why
why
do
we
see
it
as
acceptable
having
search
broken
like
what
I
think
it's
the
normalization
of
the
aviation
like
we
didn't
have
it,
we
assume
we
have
a
good
product,
so
apparently
we
can
live
without
it
and
I.
Don't
think
that's
the
case.
A
Yeah
I,
I
guess
I
would
just
say
one
thing:
I,
don't
think
that
I've
made
the
statement
nor
anyone
on
that
product
team
has
made
the
statement
that
the
repo
search
is
acceptable
and
so
I
think
it
just
comes
down
to
one
maybe
reprioritizing
some
things
and
to
driving
more
focus,
thereby
maybe
we
could
make
a
working
group
on
elasticsearch.
That
could
be
an
example
to
kind
of
get
this
a
little
bit
more
focus
in
priority
in
the
short
term,
so
I'll
consider
doing
that
and
taking
actions
that
go.
C
A
I
J
Go
ahead,
I
would
I
would
also
be
happy
to
take
that,
so
I'm
I'm
the
senior
PM
for
ecosystem.
I
just
started
in
the
deck.
We've
got
a
couple
of
notes
on
this
and
I
just
started
last
month
we're
just
starting
to
build
out
the
team,
so
we've
got
a
scope
of
work
that
is
going
to
include
all
of
our
third-party
integrations.
So
there's
a
little
bit
of
a
nuance
there
in
that
sometimes
they're
pretty
integrations
actually
makes
sense
directly
for
the
purpose
of
the
product
like
there
are
a
core
feature.
J
So,
like
we've
talked
about
open
shift,
integration
like
open
shift
is
a
core
part
of
how
we
deploy
stuff
right,
so
that's
or
how
we'd
like
to
be
able
to
deploy
things
right.
So
that's
not
an
ecosystem
concern,
but
things
like
the
integrations
with
JIRA
so
we'll
be
handling
third-party
integrations
with
products
where
our
customers
need
to
see
these
to
be
able
to
adopt
the
product.
J
We're
also
over
time,
looking
to
expand
in
into
managing
and
nurturing
our
api's
and
building
out
really
great
SDKs
to
allow
for
future
development
by
outside
organizations
and
then,
in
the
fullness
of
time,
we'd
like
to
look
at
building
a
marketplace
as
more
integrations
are
out
there,
helping
to
make
a
more
robust
marketplace
for
our
customers
to
be
able
to
discover
those
and
integrate
them,
but
their
installation.
So
we're
starting
small
we've
got
a
small
team.
That's
getting
stood
up.
We've
got
two
hires
that
are
starting
in
in
the
beginning
of
September
and
November.
J
We've
got
a
couple
more
offers
that
we're
looking
to
send
out.
We've
got
a
both
of
those
are
back
end
engineers
and
we've
got
one
more
front-end
engineer,
opening
that
we're
looking
to
fill,
and
then
we
have
an
engineering
manager
role
that
we
may
have
filled
we're
in
the
process
of
figuring
that
out
to.
B
B
Up
so
the
the
offer
we
just
developed
yesterday,
so
we
are
hoping
to
send
out
today
or
tomorrow
if
it's
gas
approved
cool.
J
B
G
J
So
we're
hoping
we
can
have
that
team
really
roll
in
here
in
the
next
couple
of
releases
as
far
as
kind
of
our
first
steps,
because
this
is
a
brand
new
team,
we've
got
a
global,
optimization
issue
that
we've
opened
up,
so
we're
looking
to
maybe
borrow
ahead
to
kind
of
bootstrap
that
team
and
get
them
started
and
then
I've
put
together
a
scope
of
work.
That
is
primarily
focused
right
now
on
JIRA
integration.
J
C
J
Native
integration
so
integrations
that
have
happened
inside
the
get
lab
codebase
so
places
were
we're
writing
code
inside
of
get
labs,
EE
and
EE
that
goes
out
and
integrates
with
another
product,
as
opposed
to
in
other
companies
and
products
where
you'll
see
third-party
integrations
that
are
just
like
a
plug-in
or
they're
from
another
place.
When.
C
J
That
distinction
so
I
think
there's
if
I'm
from
reading
it
correctly
like
there
are
the
things
that
you've
listed,
that
we're,
maintaining
and
managing
ourselves.
I'd,
also
like
to
think
of
anything
that
another
company
is
reaching
inside,
of
get
lab
and
adding
to
our
product.
That's
still
native,
like
it's
still
something
that
we
own
and
I
think
the
distinction
lies
in.
There
are
going
to
be
places
where
there
are
organisations
that
are
building
integrations
in
their
product,
which
are
hitting
the
get
lab,
api's
and
right
now.
J
C
I
agree,
I,
think
you're.
Thinking
about
this
right,
I
think
it's
important
to
have
a
distinction
between
the
free
integrations
that
we
as
a
company
are
super
focused
on
and
all
the
other
integrations
and
both
of
them
live
in
to
get
lab
code
base
or
both
of
all
of
them
are
native,
but
not
all
of
them
are
things
like
we
invest
time
in
and
I
think
native
kind
of
might
put
some
people
on
the
wrong
foot
where
they
think
it's
something
we
maintain
so
I.
C
J
So
I
think
that's
a
tough
one
that
that
I
haven't
really
gotten
to
spike
that
deep
into
and
I
think
there
is
a
there's,
a
really
broad
discussion
around
what
that
needs
to
be.
There
is
definitely
an
approach
to
it
that
can
can
be
monetary
and
so
to
kind
of
level
set
with
everybody.
The
the
idea
of
a
marketplace
that
is
monetary
is
a
place
where
there
are
a
lot
of
approaches
to
it.
J
C
Have
everyone
else,
I
think
here
we
got
to
be
very
careful
of
confusion
and
I
I'd
call
seeing
you
I
think
because
we're
open-source
things
work
very
different
than
from
proprietary
companies,
and
so
because
her
open
source,
it's
much
more
likely.
People
can
add
it
to
the
product
and
you
lose
the
the
monetary
aspect.
C
You
don't
get
money
back,
but
I
think
that's
a
a
thing
we're
doing
in
place
of
a
marketplace,
so
I
think
well,
for
example,
never
have
a
marketplace
so
make
sure
that
we
stay
aligned
there
and
that
we
don't
waste
a
whole
bunch
of
time
on
things
that
might
really
distract
from
where
we
need
people
to
focus.
Sure.
J
Yeah
and
I
was
just
trying
to
get
everybody
on
the
same
page,
because
it's
kind
of
a
confusing
topic
and
there's
also
a
very
different
approach
to
it,
in
which
you
can
think
of
a
marketplace
which
does
kind
of
take
away
from
the
monetary
aspect
as
being
a
central
place
for
discoverability
of
other
products
that
work
in
in
common
in
work
well
with
our
product,
making
it
more
of
a
it's
almost
just
documentation
around.
How
do
I
find
these
things?
How
do
I
integrate
them
with
my
product?
C
Yeah
I
think
we
already
have
that
it's
our
partners
page
and
that
could
use
some
love
so,
instead
of
trying
to
so
I'd
focus
there
making
sure
that
page
is
better
and
it's
more
discoverable
like
there's
I,
think
20
API
clients
on
there
20
CLI
clients,
I,
cannot
tell
which
one
is
maintained.
That
will
be
very
worthwhile,
so
consider
iterating
there
a
bit
instead
of
starting
a
new
initiative,
make
the
existing
thing.
K
K
J
Thinking
through
like
what
the
possible
reach
of
an
integration
can
be,
and
then
I
think
the
other
piece
of
it
is
is
going
to
be
what
is
the
biggest
driver
as
far
as
possible
deal
size
or
impact
to
our
overall
revenue.
There
are
definitely
some
some
integrations
that
are
going
to
be
used
by
a
smaller
set
of
customers,
but
those
customers
are
much
larger
and
vice
versa.
J
So
we've
got
some
things
like
we've
gotten:
a
ton
of
requests
for
thinking
of
smaller
ones
like
some
chat
integrations
like
so
some
chata
integrations
are
gonna,
have
less
impact
on
large
deal
size,
but
they're
gonna
have
a
broader
impact
on
a
larger
set
of
customers,
and
then
we've
got
some
like
portfolio
management
and
workflow
management
tools.
There
was
a
ton
of
discussion
in
the
last
couple
days
around
ServiceNow
integration
and
serve
now.
J
J
Oh
and
I
will
let
Eric
get
a
great
note
in
there
right
now.
That
is
definitely
JIRA
is
the
top
priority,
Jura
Jenkins
and
github,
or
really
our
biggest
ones.
We've
been
talking
around
Salesforce
integration
and,
like
I,
said
I
just
did
a
ton
of
research
on
ServiceNow
I
think
that's,
probably
one
that's
potentially
coming
up
on
this
sleeve
as
well.