►
From YouTube: Monthly Internal Customer Call (July 2019)
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,
so,
if
the
I
have
the
agenda
open,
there's
a
couple
of
things
that
I
wanted
to
go
through
and
I'd
love
to
hear
from
you
if
you've
had
any
new
challenges
since
the
last
time
that
we
spoke
or
any
concerns
about
how
we're
prioritizing
things
so
I.
The
the
first
item
here
is
this
review
curtain
and
upcoming
milestones.
A
We
could
go
through
each
of
these
together.
I
think.
The
big
stress
that
I
guess
I
would
put
on
this
is
what
we're
working
on
now
is
we're
resolving
some
of
the
critical
problems
that
we've
had
with
NPM.
We
didn't
support
subgroups
users
couldn't
authenticate
using
the
get
lab
token
they
couldn't
identify
with
CI
job
token,
so
is
one
of
our
lowest
customer
sentiment.
Features
in
the
stage
was
NPM,
so
we're
working
through
resolving
those
and,
at
the
same
time,
we're
doing
what
we
can
with
the
container
registry.
A
Instead
of
deleting
all
let's
share
the
same
tag:
ID
and
we're
working,
we
are
just
wrapping
up
the
user
research
that
we
did
and
as
part
of
that,
we
realized
that
we
really,
as
far
as
what
we
show
in
the
UI,
don't
expose
a
ton
of
metadata
about
what
was
built
and
and
how
and
so
we're
working
on
a
data
model
now
and
then
translate
translating
that
into
what
the
UI
could
look
like,
but
at
a
high
level
what
I
consider
to
be
really
important?
There
is
we're
not
we
built.
A
Basically,
in
my
opinion,
we
build
what
docker
hub
was
and
as
in
a
quick
way,
and
it
works
really
well,
but
that
doesn't
really
take
advantage
of
what
gitlab
is,
which
is
you
know
you
could
build
it
with
CI.
You
have
your
source
code.
There
you
have
your
docker
file
all
living
in
one
place.
We
should
really
help
users
to
show
them
all
that
information
and
then
maybe
give
them
an
easy
way
to
navigate
between
those
things.
A
I'm
thinking
about
you
and
having
all
the
docker
files
that
you
updated
and
they're
all
built
by
pipelines,
it'd
be
great.
If
you
could
just
go
through
the
images
and
you
could
see
which
commit
given
dot,
image
or
tag
came
from
or
if
you
could
actually
see
the
dockerfile
right
there,
so
you
don't
have
to
dance
back
and
forth
between
projects
like
the
the
cng
and
the
CNG
mirror
project,
and
then
we
have
then
we're
working
on
some
additional.
Like.
Let's
see,
we
talked
about
home
actually
last
when
we,
when
we
last
spoke.
A
So
one
of
the
things
that
I
read
about
was
Microsoft,
announced
support
for
helm
in
their
container
registry,
which
and
I
was
speaking
with
one
of
our
users,
who
are
actually
using
the
container
registry
to
host
helm
charts
today
and
so
we're
gonna
try
getting
supporting
helm,
charts
within
the
container
registry
and
see
if
it
works.
There
might
be
some
small.
A
It
looks
like
there's
some
small
UI
changes
that
might
be
required
to
have
the
things
like
the
size
or
the
updated
date
be
populated,
but
in
terms
of
actually
hosting
the
helm
charts
there,
it
seems
to
work
fine,
and
what
else
are
we
working
on
the
and
then
the
the
big
thing
that
we're
working
on
is:
how
do
we
figure
out
how
to
take
the
container
registry?
These
small
updates
that
we're
doing
how
do
we
really
figure
out
how
to
make
it
so
that
it
scales?
A
So
we
could
do
online
garbage
collection,
so
we
could
set
retention
and
expiration
policies,
so
we
could
sort
the
UI
by
updated
date
and
we
could
solve
a
lot
of
the
pagination
problems
that
were
and
performance
problems
that
we're
having
and
then
Daniels
been
leading
those
conversations
and
it's
really
coming
down
to
do.
We
fork
the
docker
distribution
registry
and
just
treat
it
as
a
separate
service
and
and
iterate
off
of
that,
or
do
we
build
our
own
container
registry
I?
A
Think
what's
happening
now
is
where
we're
aligning
on
this
idea
of
forking
the
existing
docker
registry
code
and
then
making
changes
to
that
and
the
reason
being
that
they
already
solve
things
like
authentication,
they've,
already
solved
scale
they've
already
solved
integrating
with
the
docker
API
layer.
So
we
should
take
advantage
of
those
things
as
much
as
we
can
and
then
but
make
it
our
own.
So
we
could
actually
do
things
like
run
garbage
collection,
so
start
storing
the
data
and
then
start
being
to
surface
that
data
and
act
on
it
and.
A
But
yeah,
that's
that's
that
covered.
We
were
just
talking
about
that
today.
We
would
like
to
I
think
it's
a
really
great
way
for
us
to
contribute
back
to
the
open
source
community.
It's
just
right!
Now
we
have
such
a
small
team
and
to
do
that
well,
I
feel
like
we
might
need
a
few
more
people
get
more
engineers,
but
it's
definitely
something
that
we're
interested
in
and
if
it's
possible
we
would
definitely
do
it.
That's
a
good
point,
though.
I
could
reach
out
to
doctor
myself
and
tell
them
what
we're
going
through
and
see.
B
One
of
the
one
of
the
things
that
we've
been
doing
so
in
a
lot
of
cases
in
our
team,
we
deal
with
upstream
packages
that
sometimes
we
have
to
vendor
or
Fork
and
whatnot,
and
we
don't
necessarily
have
the
manpower
to
fix
things,
maybe
properly
or
in
a
generic
way
or
across
the
breadth
of
the
other
ones
as
well.
So
what
what
we've
taken
view
is
that
the
bare
minimum
we
ensure
that
an
issue
is
long
upstream
I
think.
A
B
B
Yeah,
it
depends
on
the
project,
so
sometimes
sometimes
it's
we
make
sure
to
log
the
issue
and
sometimes
I'd
say
more
more
often
than
not.
We've
we've
linked.
If
it's
a
small
fix
we
almost
always
upstream
ourselves
and
we've
had
a
lot
of
success
with
getting
those
taken,
I
would
say,
were
just
moderately
successful
with
like
a
grander
proposal,
writing
pushed
up
there
and
then
being
acted
on
those
tend
to
take
a
long
time.
So
there's
only
like
we've
been
doing
it
for
a
while.
A
B
B
B
I,
don't
think
we've
logs
any
we've
only
done
bug,
fixes
I,
think
ok
with
dr.
distribution
and
like
back
ports.
So
we
did
a
couple
back
ports
with
the
distribution
products
itself
where
they
were
just
small
things,
though,
like
they
would
add
in
like
new
Amazon
Regents
or
something
like
fast,
but
only
in
master.
B
A
We've
tried
we're,
you
know
we
have
the
NPM
registry
and
we've
been
able
to
get
the
NPM
team
on
a
couple
of
shared
calls
with
the
engineering
team
and
we're
just
started
talking
through
partnership
ideas
and
we're
doing
some
like.
We
have
plans
for
some
Co
marketing
or
we've.
We've
identified
a
few
things
that
we
would
like
to
change
and
they
seem
open
to
the
conversation.
A
B
I
wouldn't
say:
we've
we've
seen
anything
overly
engaging
over
there
from
pots,
certainly
other
things
we've
engaged
on
like
that
part
docker,
and
not
a
team
like
helm
and
stuff
like
that,
we
see
a
lot
more
engagement
on,
but
there's
some
things.
We
see
a
lot
less
engagement
on
this
well
right,
I
think
the
doctors
used
to
at
least
ours
after
time
at
least
get
commented
on
by
the
team.
B
Terms
of
store
likes
where
we
store
it
like
I,
don't
care
whether
the
chart
like
the
tar
Jeezy's,
which
is
the
chart,
is
stored
in
s3
or
American
teenager
registry,
like
in
the
container
registry.
It
eventually
be
probably
stored.
That's,
but
it's
kind
of
it
is
kind
of
cool
to
store
it
in
something
that
we
right
right.
In
the
end,
the
actual
contain
I
wonder
the
the
index
page
we've
determined
that
get
lab.
This
is
more
recent.
We've
determined
that
get
lab
pages.
It's
not
actually
great.
First,
storing
it
the
index
page.
B
So
I
don't
know
what
the
plan
is
for
the
container
registry
if
it
also
hosts
the
index
page.
But
what
we?
What
we
turn
determine
with
pages
is
that
there's
two
because
it's
written
by
CI
to
populate
pages,
there's
too
much,
there's
too
much
room
for
you
over
writing
each
other.
So
if
you
get
to
CI
builds
come
in
at
the
same
time
and
they're
updating
different
charts,
but
you
only
have
one
index
file
on
the
ends
like
one
can
undo
the
others
update
and
there
we
in
get
lab
in
our
CI.
B
We
don't
really
have
a
way
to
save
it,
don't
run
parallel
pipelines
at
the
moment.
Oh
that's
something
we
recently
run
into
as
we're
starting
to
amp
up
our
releases
that
we're
running
releases
of
within
seconds
of
each
other,
some
plans
to
run
different
patch
releases
or
a
security
release
and
we're
overriding
ourselves.
B
So
we're
actually
I,
don't
know
if
the
container
registry
would
fix
this
moving
it
there.
At
the
moment
we
have
plants
is
move
away
from
pages
for
storing
the
index
page
and
s3
for
storing
the
index
page
and
storing
the
in
this
page
in
gift
itself,
so
that
we
get
that
without
locking
and
that's
versioning.
A
B
A
That's
interesting,
I
wonder
if
you
would
get
the
same
benefit
the
same
benefit
from
using
the
container
registry
as
that
yeah
I'm,
not
sure
I
thought
I'd
share
this.
This
blog
from
this
Microsoft
developer,
where
he's
I
thought
I
would
share
it
here
we
go
and
where
he's
talking
about
using
them
as
the
Microsoft
container
registry
for
helm,
and
why
wait
why
it's
more
impactful
with
helm
v3,
which
I
guess
is
still
not
released
and
stable
yet,
but
there
by
I,
think
the
reasoning
is
they're.
A
Moving
away
from
tiller
and
they're
they're,
basically
saying
that
docker
is
intended
to
just
be
storage.
There's
no
reason
it
can't
store
these.
You
know
help
charts
might
be
and
and
we're
working
on
this,
so
maybe
what
we
could
do
is,
after
we
document
how
to
do
this
with
the
container
registry.
We
could
see
if
it
would
work
for
an
example
for
one
of
your
projects.
B
A
B
B
B
Just
tags
we
did
so
you're
thinking
in
terms
of
well
I
guess
somebody
is
just
one
of
the
things
like
metadata.
You
were
thinking
of,
raising
up
typing
yeah,
exactly
yeah,
so
we've
only
encountered
the
labels
once
and
that's
usually
when
we're
submitting
the
darker
is
to
a
third
party
like
some
sort
of
compliance
or
regulatory
type
of
thing.
B
In
our
case,
RedHat
often
you
couldn't
just
put
your
images
in
docker
hub
for
a
Red
Hat
instance
to
be
able
to
pull
them
down
a
default
doctor
on
Red
Hat
in
instead,
instead
of
pointing
to
docker
hub
by
default
points
to
Red
Hat's
own
thing.
In
order
to
validate
they
expected.
You
know
certain
types
of
labels
in
your
doctor
fall
and
stuff
like
that.
So
we
have.
We
have
used
labels
in
the
past,
but
not
for
our
own
benefit.
A
A
Okay,
I
make
I'm
yeah
and
I'm
wondering
if
we,
if
we
would
in
the
future,
if
you
could,
because
right
now,
you're
tagging
things
with
just
like
the
shorts.
But
if
you
could
have
a
label
that
says
like
milestone.
B
B
A
B
A
Oh,
the
other
thing
I
should
mention
is
some
of
the
integrations
we're
working
through
so
I.
Don't
think
this
one
affects
you,
but
the
next
one
we're
adding
is
Conan,
which
is
for
C++
development,
we're
in
the
middle
of
that
there
then,
after
that,
we're
doing
nougat
for.net,
that's
like
our
most
popular
requested
issue
and
then
after
that
I
think
I
was
planning
on
working
on
Ruby
and
just
because
and
I
just
found
out
that
we
have
sort
of
a
POC
that
was
done
so
I
think
and
I.
B
B
We're
just
for
caching
we're
just
using
artifacts
cash
and
get
loved
CI,
oh
okay,
and
we
use
like
Ruby
Ruby
gems
same
as
the
rails
project
and
then
get
get
it
stuffed.
So
you
can
use
you
can
have
your
Ruby
file
put
in
pull
in
from
get,
and
we
use
that.
Rarely,
though,
there's
some
security,
stuff,
I.
B
I,
don't
remember
if
it
was
caching
or
so
I
think
we
took.
We
took
a
look
at
it
and
it
was
more
that
we
need
it
to
do
for
the
dependency
proxy
part
to
work
with
it.
I
think
so
that
it
would
still
go
to
rubygems,
so
yeah
I
guess
caching
can
have
a
do
local
caching
of
like
the
normal,
ruby,
gems,
okay,
rather
than
having
to
build
a
project
for
each
one
person
that
makes
sense
I'm,
not
sure.
A
B
A
Yeah
that
that's
the
the
big
question
for
the
container
registry
was,
should
we
extend
the
dependency
proxy
and
just
make
use
that
as
the
new
container
registry,
because
it
already
has
dr.
pol,
has
the
caching
that
we
went
proxying
built
in
that
we
want,
but
I
think
we're
leaning
against
that
now.
So
that
might
delay
improving.
You
know
really
investing
in
improving
the
dependency
proxy.
While
we
invest
in
this
container
registry
work.
B
Yeah,
that
may
not
be
a
terrible
thing
anyways
because,
like
at
some
point,
we're
probably
going
to
get
rid
of
unicorn.
So
if,
if
you
delay
it,
the
prof
part
of
the
problem
might
go
away,
yeah,
that's
true!
Well,
how
is
that
process
going?
I
I
haven't
I
haven't
followed
up
on
it
at
the
moment.
Initially,
it
was
planned.
B
I
think
it
was
initially
planned
for
12
for
us
to
switch,
but
I
think
that
was
an
ambitious
plan,
because
I
haven't
seen
anything
proposing
it
recently
within
the
last
four
weeks,
but
I've
been
away
on
vacation
for
the
last
week
and
a
half.
That's
right,
maybe
maybe
it's
still
moving
ahead,
but
last
I
knew
it
was
scheduled
for
12,
but
to
switch
the
defaults
I
mean.