►
From YouTube: Package: Internal Customer Meeting 06-25-19
Description
First Package internal customer meeting. We discussed recent and upcoming milestones and had a quick deep dive into the container registry and how images are built/versioned.
A
What
we
really
want
is
this
separately
actually
Alex
and
I
just
recently
met
for
doing
some
user
research
on
the
container
registry
and
we've
been
meeting
with
folks
from
the
infrastructure
and
distribution
team
as
well
to
help
drive
what
our
needs
are
there
as
well.
So
thank
you
Alex
for
your
help
to
differ
two
times
in
in
one
week.
I
really
appreciate
it.
A
Okay,
so
two
quick
highlights
so.
First
item
on
the
agenda
is
reviewing
features
from
the
past
release.
This
is
pretty
small
for
us.
Actually,
you
know
we're
just
building
up
the
package
team
now
and
the
changes
we
may
eventually.
Let
me
pour
look
the
kickoff
dock.
Sorry
I'm,
like
five
minutes
late
to
every
meeting
today,
so
in
twelve
Oh.
What
we've
released
was
I'm
just
scrolling
down.
A
A
Dmitry
did
some
work
on
the
dependency
proxy
to
enable
it
by
default
per
group,
and
we
updated
some
container
registry
API
permissions.
But
this
past
release
was
really
our
first,
our
last
release
without
having
a
fully
dedicated
team.
So
you
know
what
now
we're
starting
to
pick
up
momentum
in
the
upcoming
release
in
12:1.
We
are
working
on
a
bunch
of
different
features
here,
so
we're
working
on
a
new
package
manager
for
c
and
c++
called
Conan
Conan,
and
we
are
enabling
NPM
packages
to
be
at
the
subgroup
and
group
level.
A
It's
currently
blocking
JavaScript
developers
and
we're
adding
in
some
fixes,
for
maybe
you
all
have
encountered
this
problem
with
the
container
registry.
If
you
have
any
special
characters
in
your
project
or
branch
name,
it
actually
breaks
the
connection
to
docker
so
we're
where
we
don't
have
a
solution
for
it,
but
we're
documenting
how
you
do
solve
this
problem
on
the
platform.
So
that's
something
that
we're
working
on
this
release.
A
No,
for
me,
okay,
the
big
thing
that
we're
trying
to
work
towards
now
and
I
mentioned
the
user
research
that
we're
conducting
is
trying
to
figure
out
a
path
towards
lovable
or
complete
for
the
container
registry.
We're
currently
not
storing
any
of
the
data.
We
have
storage
problems,
so
we're
figuring
out
what's
the
best
architecture
for
that
moving
forward,
and
how
does
that
impact
our
development
timelines
and
the
future
features?
So
let
me
actually
I
should
have
linked
that
issue
here.
A
A
I
just
link
to
the
user
research
issue
in
the
chat
that
were
working
through
and
what
we're
trying
to
uncover
and
what
some
of
the
questions
were
asking
are,
and
it
links
to
the
YouTube,
video
private
YouTube
videos
as
well
of
actually
conducting
interviews.
So
the
goal
is
to
talk
to
three
to
five
internal
users
and
seven
to
ten
external
users
and
build
on
hypothesis
about
how
users
are
using
the
container
industry
and
where
we
need
to
be
in
the
next
three
six.
Nine
twelve
months.
A
A
So
I
just
had
actually
Alex.
Maybe
you
could
ask
this
question
or
answer
this
question.
We
were
thinking
a
lot
about
keeping
the
image
around
like
storing
these
approved
images
that
we're
working
on
what
happens
if
an
image
is
deleted,
like
the
Blessed
image
for
a
given
milestone,
is
it
has
been
deleted?
B
A
A
I'm,
just
trying
to
you
know
as
we're
thinking
through
how
we
do
sort
of
retention
and
storage
policies
I'm,
seeing
our
competition
owl
does
in
the
way
that's
expected
like
go
harbor,
you
select
the
images
that
you
want
to
keep
and
and
they
get
stored
and
everything
else
will
get
drops,
but
I'm
wondering
for
us.
What
is
the
artifact
that's
important?
Is
it
the
docker
file
or
is
it
the
image
and
if
it's
the
image
or
tag
tag
damaged?
B
I
mean,
if
you
so
as
things
are
today,
if
we
decided
to
clean
up
things
today
and
start
expiring
images
it,
we
would
only
really
be
able
to
delete
the
tag
itself,
because
there's
no
garbage
collection
on
the
registry
right,
so
it
wouldn't
really.
It
wouldn't
really
make
sense
for
us
to
do
anything
like
that
until
we
had
a
garbage
collection
mechanism,
because
otherwise
we
would
just
be
irritating
our
customers
for
no
reason.
C
B
A
B
Versions,
so
you
know,
if
you
had
say
nine
point
five:
while
it
would
run
all
of
the
same
commands
to
build
it,
you
would
perhaps
end
up
with
a
different
base
image
from
docker
hub
or
whatever
upstream
image
you
use
and
sometimes
well
you
so
tell
sometimes
things
just
don't
work
quite
as
you
might
expect
right.
So
rebuilding
an
image
from
so
long
ago,
various
dependencies
might
have
changed
or
become
more
more
difficult,
I
mean
I.
B
A
A
B
The
docker
file
itself,
like
the
steps
that
would
run,
wouldn't
necessarily
change,
but
if
you're
pulling
in
like
you
know
a
Linux
image
from
upstream,
then
it
might
now.
You
can
tag
those
things
too.
So
in
theory,
if
everything
was
tagged,
the
way
it
should
be,
then
it
would.
It
would
be
the
same
right
if
you
go
and
you
pull
in
the
you
know
boon
to
image
for
1404.
You
know,
that's
probably
not
changed,
but
you
know
you
can't
can
be
certain.
You
know
we're
not
in
control
of
that.
A
Okay,
that
that
clears
up
some
questions
that
Daniel
and
I
were
asking,
which
is
what
is
the
key
artifact
for
the
container
registry?
Is
it
the
docker
file,
or
is
it
that
do
we
need
to
store
images
thinking
about
a
future
of
state?
You
know
a
year
from
now.
What
is
the
important
artifact?
Is
that
the
image
or
is
it
the
docker
file,
and
it
sounds
like
it's:
both
I
mean.
B
It's
both
yeah.
The
thing
is
is
like
with
deleting
images
ever
you
can
never
be
certain
that
the
customer
can
go
back.
We
might
be
able
to
be
certain
for
our
own
stuff.
That
would
require
you
know,
investigation
testing
for
sure,
but
like
for
a
customer
like
you
can
never
be
certain
that
they
would
be
able
to
go
back.
Okay,.
A
B
Know
images
I'm
not
a
hundred
percent
sure
I.
Only
this
was
closed
today
and
so
I
read
up
on
it,
but
pretty
much
we're
just
we've
decided
to
use
one
repo
for
all
of
our
images
and
then
tag
them
appropriately
with
you
know
like
what
what
the
image
is
so
right
now
we
have
an
image
of
the
chef,
repo
and
I.
A
B
The
tag
with
the
tag
of
the
SHA
I-
imagine
you
can
see
this
because
we
put
everything
publicly
yeah,
it's
public.
So
right
now
we
have
a
chef
repo,
so
we
have
an
image
for
the
chef
repo
and
underneath
that
we
have
tags
for
the
commit
jaws
and
then
one
latest-
and
you
can
see
in
here
that
the
latest
has
the
same
tag
as
one
of
the
commit
shots
or
one
of
the
commits
shot,
tagged
images.
A
B
B
I
mean
you,
you
latest
is
like
the
standard
really
in
the
docker
world.
You
can
pretty
much
assume
that
any
image
you
use
that's
publicly
available
will
have
a
latest
tag.
That
is
indeed
the
latest
version
and
then
usually
they'll
also
have
other
version
tags.
Since
we
as
infrastructure,
don't
do
versioning
of
these
kinds
of
things.
A
One
thing
I
was
thinking
about
is
the
idea
of
for
tags
using
the
comitia
and
then
having
the
cut
again
future
concepts,
but
the
idea
of
a
label
where
you
could
label
something
as
latest,
but
the
image
is
actually
tagged,
always
because
most
of
the
builds
are
happening
from
CI.
It's
easier
to
to
tag
it
with
the
comitia
and
then
have
the
idea
of
like
now
from
the
UI.
You
could
add
a
label
and
then
the
label
will
be
latest
yeah.
B
A
B
Obviously
this
just
started
like
today,
so
that'll
be
changing,
I'm
sure
right
now
we
just
test
to
make
sure
the
docker
build
works
correctly,
but
I'm
we
will
definitely
be
moving
on
to
a
to
a
situation
where
it's
all
done.
I,
what
I
would
imagine
would
happen
is
if,
if
we're
building
it
off
of
master,
then
it
would
tag
it
as
latest
because
we're
building
it
off
of
the
master
branch
or
whatever
we
choose.
B
A
B
A
B
A
We
could
do
that
because
then,
if
we
come
up
with
sort
of
our
approach
and
then
that's
built
into
the
product-
and
we
start
to
think
that
way
that
this
is
the
way
that
people
this
is
the
way
that
the
industry
should
be
doing,
tagging
and
builds
and
and
promoting
and
things
like
that,
along
with
their
repos,
it
I
think
having
that
combined
opinion
could
be
really
valuable
for
us.
Yeah.
B
I
think
that
the
way
you
do
your
docker
images
is
going
to
be
a
pretty
personal
decision,
regardless
of
where
you
work
right.
I
mean,
if
I'm
doing
something
for
my
personal
project.
I'm
gonna
have
very
different
needs
than
somebody
like
the
infrastructure
team
here
or
the
distribution
team
in
general.
B
So
I
think
that
would
be
very
similar
for
the
customer.
I,
don't
know
that!
There's
one
true
way
to
do
it
I
think
it's
all.
You
know
what
works
best
for
them
and
that
may
or
may
not
be
the
same
thing.
We're
doing.
I
was
afraid
you
were
gonna
say
that
yeah
yeah
I
mean
cuz
like
for
us
like
we
don't
like
I
said
you
know
with
the
shah's
we're
doing
that
because
don't
do
versioning,
we
don't
tag
our
our
repos.
A
C
A
A
So
yeah
yeah
big
thing
I
mean
just
to
walk
through
that
slide,
quick,
the
container
registry
I
mentioned.
You
know
we're
really
trying
to
solve
this
problem
about
how
to
do
in
mine,
garbage
collection,
which
we
currently
can't
support,
and
we
use
a
lot
of
storage
for
the
container
registry.
Forget
lab,
comm
I
think
it's
over
1.6,
petabytes
and
growing.
So
we
need
to
figure
out
how
to
solve
that
and
then
the
once
we
can
do
that.
Then
we
really
want
to
solve
the
problem
of.
A
How
do
you
retain
you
know,
retention
and
expiration
policies
and
then,
once
we
are
storing
the
data,
we
can
improve
the
UI,
so
I
don't
know
if
you've
walked
through
the
container
registry
UI
right
now.
But
if
you
have
more
than
10
images,
it
becomes
pretty
hard
to
use
and
pretty
it's
it's
hard
to
discover
images,
you
can't
sort
or
filter.
So
those
sorts
of
things
will
be
things
that
we
want
to
add
in
the
future
and
then
a
separate
Avenue
is
the
package
registry,
which
is
basically
just
we
have
one.
A
We
want
to
work
blocked
in
a
lot
of
in
a
few
ways.
Right
now
for
NPM-
and
we
have
a
lot
of
negative
customer
sentiment
for
that
that
we
want
to
resolve,
and
then
we
want
to
add
in
net
new
package
managers
which
supports
our
customers
and
then
finally,
that
may
be
I,
don't
know
how
much
we'll
get
to
it
in
the
next
six
months,
but
improving
the
dependency
proxy,
which
allows
people
to
cache
and
proxy
their
images
and
blobs.