►
From YouTube: Ops Section Product Group AMA - Package
A
A
Hello
and
oh,
I
can
kick
it
off.
Kenny
yeah
go
ahead,
okay,
so
this
is
the
first
ask
ops,
the
experimental
ops
ask
me
anything
that
we're
going
through
at
each
section
and
today
we're
going
to
talk
about
the
package
stage.
So
we
have
a
list
of
questions
already
added
to
the
agenda.
So
thank
you
for
adding
those
and,
of
course,
we're
open
to
fielding
any
questions
that
come
up
that
aren't
there
so
feel
free.
I
think
we
can
go
through
the
agenda
and
start
to
tackle
the
questions.
B
I'd
love
to
yeah
and
thanks
for
doing
this
yeah.
My
question
was
about
the
effort
to
achieve
tier
zero
level,
reliability
for
the
registry
container
registry,
and
I
know
that
a
postgres
database
is
part
of
that
architecture
and
probably
for
good
reason.
But
I
also
know
relational
databases
are
often
a
single
point
of
failure
in
systems,
so
I
was
just
curious
kind
of
what
the
latest
thinking
is
on
that
and
how
we,
how
we
address
that.
A
A
lot
of
this,
the
conversations
around
the
tier
zero
availability
are
relatively
new,
so
the
one
one
of
the
things
that
came
from
it
is
we
open
this
issue
that
proposes
some
ideas
and
some
investigations
for
how
we
could
possibly
do
this.
We're
and
one
of
the
investigations
is:
how
do
we
make
the
postgres
database
99.99
available?
A
There's
not
been
a
ton
of
ideation
and
iteration
that's
gone
into
that
proposal
yet,
but
we
we
will
do
that
investigation
and
what
we're
trying
to
do
is
work
through
the
architectural
evolution
process.
So
I
know
jagorish
and
joan
are
going
to
work
on
a
blueprint
for
registry,
high
availability
and
they'll
take
into
account
the
investigation,
not
just
for
the
postgres
database,
but
we're
also
thinking
about
how
can
we
improve
the
redundancy
and
availability
of
the
auth
service
that
the
registry
reaches
out
to
and
any
other
dependent
services?
A
C
Do
you
want
to
yeah
so
in
an
effort
to
sort
of
give
other
members
of
the
team
opportunities
in
terms
of
architecture
tom's
actually
going
to
be
helping
out
with
the
architecture
blueprint
and
is
going
to
be
sort
of
guiding
tom
on
that,
so
that
he
has
opportunities
to
do
that
stuff
as
well?
So
I
just
wanted
to
add
that
in.
A
A
Yeah
well,
cost
is
definitely
top
of
mind
for
us
for
the
registry
because,
as
you
know,
for
com,
we
spend
a
lot
of
money
every
month,
just
on
storage
alone.
So
we
need
to
consider
costs
as
any
as
part
of
any
work
that
we
do,
but
I
think
you
might
be
referring
to
the
cost
of
actually
just
hardening
up
these
other
services
as
well
right
like
if
we
to
make
the
auth
service
highly
redundant.
What
does
that
cost
us?
I
think
that
we
should.
A
D
I
would
encourage
the
team
not
to
over
rotate
in
either
direction,
so
I've
seen
too
many
times
we're
organizations
they'll
say:
oh,
we
can't
do
this
because
it's
too
expensive
and
then
I've
seen
other
organizations
where
they
say
cost
is
irrelevant.
We're
gonna,
we're
gonna
spend
you
know
whatever,
whatever
we
need
to
to
get
us
to
six
nines
as
an
example,
so
like
really
coming
back
with
kind
of
like
that
view
of
it.
As
far
as
you
know
like
this
is
the
solution.
D
D
B
Yeah,
it's
probably
a
good
segue
from
that
discussion.
I
was
interested
in
tier
value
and
any
plans
around
that
in
package.
Some
of
those
same
recent
events
yeah.
I
think
I've
highlighted
that
there's
customers
that
would
be
willing
to
pay
for
additional
guarantees,
higher
slas,
better
disaster
recovery
type
features,
and
so
I'm
wondering
if
we're
thinking
down
that
road
at
all
yeah.
A
I
think
thanks
for
that
question.
We
are
thinking
about
it,
but
you
know
for
the
short
term,
I
don't
think
we're
going
to
be
adding
any
tiering
value
a
lot
of
the
things
that
we're
doing
for
the
registry
to
make
it
more
available
and
redundant
are
things
like
changing
some
of
the
infrastructure
or
improving
the
availability
of
the
that
op
function.
Those
don't
feel
like
tier
value.
Those
feel
like
core
things
that
we
should
do
unless,
like
christopher
mentioned,
there's
some
cost
associated
with
them
that
we
we
need
to
pass
forward.
A
The
container
registry
is
a
little
bit
tough
to
monetize,
because
it's
been
sort
of
a
commoditized
feature
like
if
you
look
at
the
market
jfrog
as
open
source
there
container
registry,
obviously
docker
hub,
is
charging
for
pulls
now.
So
it
seems
like
the
way
that
people
are
charging
for
container
registry
services
is
they're
charging
for
storage
and
they're
charging
for
data
transfers,
and
things
like
that.
That
could
be
something
we
do,
but
I
would
want
to
avoid
making
any
premium
features.
A
We
are
talking
about
with
some
of
these
enterprise
customers,
the
idea
of
creating
a
push,
pull
mirror
that
is
multi-cloud
or
on-prem
and
cloud.
Those
are
opportunities
I
think,
for
tiered
value,
but
there's
some
validation
into.
Is
that
one
or
two
customers
that
want
that?
Or
is
that
all
of
our
enterprise
sas
customers
that
want
that?
And
if
so
can,
is
there
something
that
we
could
do?
A
That
should
all
be
in
core,
because
that
every
developer
is
doing
that.
But
as
we
start
to
say
well,
we
want
to
connect
to
your
artifactory
repository
and
your
nexus
repository,
and
then
you
have
a
consultant
that
you're
paying
to
host
some
packages
on
s3.
Well,
that
sort
of
functionality
should
be
tiered,
because
that
is
more
focused
on
the
enterprise
customers,
and
I
really
see
that
value
starting
to
unfold
in
the
latter
half
of
2021.
When
we
may
start
to
tackle
that.
E
Yeah,
so
I
think
my
comment
was
this:
I
think
the
giddily
cluster
example
is
a
recent
example
that
might
be
illustrative
here
that
they
you're
right
tim.
Like
you,
don't
want
to
say.
Well,
you
can't
run
an
architecturally
sound
package
for
registry
unless
you
pay
us
money.
That
kind
of
goes
against
our
core
principles,
but
I
think
you
can
lean
on
that.
E
A
F
A
Yeah
there
are
definitely
there
will
be
questions
that
come
up,
especially
once
we
have
more
ability
to
do
things
like
potentially
mirroring
a
person's
com
registry,
there's
hard
costs
that
are
associated
with
that
and
additional
value
that
are
associated
with
that.
That's
why
I
think
those
are
opportunities
for
tiered
value
for
the
registry,
so
but
we'll
see
as
we
get
further
along
into
2021.
F
And
if,
if
you
can
think
of
the
right
cost,
metric
that'll
be
good
here
to
focus
on,
because
my
suspicion
is
that
the
the
amount
of
containers
and
the
amount
of
storage
spent
that
we
have
on
containers
will
far
exceed
the
cost.
That's
required
to
create
an
architecturally,
robust,
highly
available
package
system.
It
might
even
dwarf
it
in
lower,
if
not
less
than
one
percent
of
the
cost.
So
whatever.
A
Yeah,
that's
a
good
point.
I
I
don't.
We
have
a
cost
metric.
Now,
it's
just
looking
at
cost
of
storage.
I
think
we
can
improve
that,
especially
once
we
have
this
manifest
database
that
will
allow
us
to
you
know,
run
on
zero,
downtime
garbage
collection
and
also
know
much
more
about
how
the
registry
is
being
used.
It's
possible
that
we
may
come
up
with
a
new
cost
metric
or
a
better
way
of
looking
at
costs
that
right
now,
we
kind
of
just
have
a
total
number.
A
F
Yeah,
I
think
so
I
was
going
through
the
direction
page
by
the
way.
I
love
this
ema
and
it
sort
of
created
a
opportunity
for
me
to
dedicate
time
and
go
through
the
direction
page
again.
So
thanks
for
the
teachers,
I
saw
the
mention
of
aws
and
azure
on
the
competitive
landscape,
but
I
did
not
see
google
and
I
wanted
to
check
what
the
reason
was.
A
We
do
hear
about
that
more
regularly,
but
in
a
recent
survey
we
only
saw
about
three
percent
of
respondents
out
of
a
hundred
are
using
google
compared
to
like
it
was
something
like
25
or
30
percent,
on
git,
lab
and
and
on
aws,
and
then
artifactory
was
another
large
percentage.
So
it's
not
as
common
but
yeah.
We
do
hear
about
it
sometimes,
and
it
would
be
good
to
know
what
they're
doing,
especially
around
consumption,
pricing
and
storage
pricing.
A
I
think
that
they
have
and
scalability
they
have
a
lot
of
things
that
we
could
learn
from
there
on
their
packages
feature
it's
currently
in
invite
mode,
only
right
now
it's
an
alpha
and
they
offer
support
for
for
node
and
java.
They
support
maven
and
gradle,
but
it's
invite
only
right
now
and
so
it's
it's
not
a
fully
mature
product
and
I
haven't
heard
of
any
customers
or
users
using
it.
B
F
F
A
I
I
haven't
come
up
to
someone
who
said
that
they
they're
using
amazon
package
artifacts
or
google
packages
instead
of
us.
It's
usually
that
we
run
into
people
that
are
using
artifactory
or
sonotype,
but
the
thing
that,
though
I
would
say
azure
is
probably
the
furthest
along,
and
I
would
say
the
thing
that
the
cloud
providers
do
is:
they
obviously
have
high
availability
and
redundancy
figured
out
and
also
the
billing
around
storage
and
data
transfers
is
all
built
into
the
system.
A
Whereas
for
us
we
don't
have
the
those
mechanics
yet
or
the
ability
to
do
that.
So
I
think
that's
in
a
place
that,
as
we
start
to
think
about
being
able
to
purchase
additional
storage
and
display
how
much
storage
you're
using
it
for
a
given
container
repository.
I
think
we
could
learn
from
them
and
that'll
be
something
that
we
should
really
focus
on
over
the
next
couple
of
months,
especially
as
we
target
displaying
how
much
storage
is
being
used
in
march
and
april,
and
does
that
does
that
answer
your
question.
G
F
F
D
F
E
A
Yes,
for
the,
it
really
depends
on
the
level
of
adoption
of
the
customer,
so
for
the
container
registry.
Yes,
we
hear
that
very
often
that
people
want
to
be
able
to
have
better
tools
for
searching
and
filtering
for
a
while.
This
has
been
blocked
by
the
way
that
we're
storing
the
container
image
manifests
in
object,
storage
versus
postgres,
so
that'll
be
something
that,
as
we
move
towards
the
med,
the
postgres
database
will
be
able
to
unblock
those
searching
and
filtering
capabilities
for
the
package
registry.
It's
less
common.
A
If
he
knows
the
number
of
hand,
but
have
projects
with
more
than
let's
say
500
packages
or
more
than
a
thousand
packages,
so
we're
starting
to
hear
it,
I'm
starting
to
hear
from
our
customers
that
are
heavy
users
of
maven
and
npm
that
they
need
the
ability
to
to
search
and
also
have
a
programmatic
way
of
deleting
packages
as
well,
so
some
sort
of
policy,
but
it
hasn't
been
critical.
We
have
a
validation
issue.
F
A
I'm
the
research-
I
should
change
I'll,
add
a
note
to
myself
to
to
remove
that
item
from
the
direction
page.
We
haven't
really
been
using
that
ux
research
issue
we're
using
more
of
the
the
problem
validation
board,
which
has
the
list
all
of
the
list
of
issues
and
what's
in
motion,
and
then
that's
that's
much
easier
to
maintain
because
we
maintain
it
with
labels,
as
opposed
to
going
and
maintaining
the
ux
research
issue.
A
So
I'll
update
the
direction
page
to
change
those
links
and
then,
just
speaking
to
research,
we
have
a
couple
of
problem:
validation,
research
issues
in
progress.
One
is
around.
We
just
mentioned
search
and
deletion
of
the
packages
and
the
other
is
around
the
some
of
the
future
container
registry
work
around.
Do
these
enterprise
large
enterprise
sas
customers
need
to
be
able
to
a
push
pull
mirror
of
their
container
registry.
A
A
You
know
vip
customers
and
walk
them
through
what
themes
we
want
to
have
and
how
the
the
app
will
look
to
accommodate
those
use
cases,
and
we
originally
did
design
and
validation
of
a
new
container
registry
ui,
but
that
was
a
while
ago,
as
we
start
to
get
closer
towards
being
able
to
support
that
functionality.
We're
just
doing
a
a
revisit
and
a
solution.
Validation
to
make
sure
that
the
things
that
we
designed
a
year
ago
are
still
valid
or
nine
months
ago
are
still
valid.
A
E
Cool
I
had
the
next
one
thanks
tim.
One
thing
that
I've
known
from
the
start
of
package
is
that
we
kind
of
had
structured
the
group
to
pursue
this
vision
by
encouraging
community
contributions
of
package
formats
that
weren't
in
our
kind
of
like
top
priority
list,
and
I
I
can
recall
a
number
of
them
that
have
come
in
from
community
contributors.
But
I'm
wondering
what
the
team's
perspective
is
on.
How
successful
that's
been.
A
You
need
to
push
back
and
say,
and
you
know,
because
we
have
a
greater
appreciation
of
how
the
app
should
function
so
there's
some
challenges
in
it.
But
overall
it's
been
valuable.
Like
we
made
really
good
progress
on
the
composer
format,
I
know
we're
working
on
reviewing
a
debian
package
manager,
format
right
now
and
there's
some
interest
around
adding
in
support
for
cargo,
which
is
the
rust
package
manager
format.
A
So
I
think
the
more
that
we
do
of
these
the
better
we'll
get,
but
at
the
same
time
it's
not
turned
into
this
thing
that
oh,
if
we
get
a
community
contribution
for
a
new
format,
it's
done
and
turned
around
in
a
week.
It's
still
challenging,
it
still
takes
a
lot
of
back
and
forth,
and
a
lot
of
handholding.
H
And
I
can,
I
can
maybe
add
a
little
perspective
on
this
too.
I
I
think
it's
been
super,
like
it's
kind
of
like
a
double-edged
sword
where
adding
a
new
package
type
can
be
some
of
our
biggest
mrs
and
some
of
our
most
like
technical
changes
in
our
stage,
so
it
can
be
a
bit
jarring
to
to.
You
know,
work
with
a
community
member
through
such
a
big
process.
H
However,
at
the
same
time
you
know,
I
think,
we're
at
eight
different
package
types
right
now
and
we
have
many
more
planned.
So
certainly
we
can't
be
experts
on
you
know
everything
that
exists
like
I
can't
you
know,
we
don't
have
someone,
that's
a
nuget
expert
and
I'm
even
expert
and
an
npm
expert,
all
in
one.
So
it's
super
helpful
to
get
a
community
member.
A
There's
been
challenges
in
that
we've
had
to
learn
like
we
started.
We
had
a
community
contribution
for
a
composer
and
we
had
to
learn
all
about
composer
and
there's
a
lot
of
different.
You
know
composer
doesn't
have
packages,
they
they're
dependencies
that
are
hosted
in
source
control,
so
we
had
to
learn
about
how
that
works,
and
but
the
community
members
have
stayed
engaged
for
the
most
part,
the
people
that
end
up,
because
they
put
so
much
work
in
like
the
person
who
contributed
composer,
they're,
regularly,
updating
documentation
and
templates
and
they're.
A
G
I'll
just
add
in
too
to
reiterate
what
tim
and
steve
mentioned
in
in
chats
with
other
members
of
the
team.
I
think
they
would
say
similar
have
similar
comments
as
these
have
been
successful
in
the
past,
but
do
require
a
lot
of
engagement
and
involvement
time
from
the
team.
It
can
be
very
challenging
when
reviewing
these
large,
mrs
is
steve
mentioned
one
of
the
neat.
G
The
interesting
sides
of
this
is:
it
gives
us
an
opportunity
to
help
community
contributors
learn
how
git
lab
works
internally,
how
we
structure,
mrs,
how
we
approach
changes
breaking
things
down
into
the
smallest
iteration
possible.
So
that's
a
really
cool
side
of
it,
but
it
also
takes
time
from
the
team
to
an
investment
from
the
team
into
that.
So
just
wanted
to
reiterate.
E
Cool
we're
almost
that
time
and
I
want
to
just
add
a
closing
comment.
First
of
all,
thanks
tim
for
being
the
and
package
team
for
being
the
kind
of
guinea
pigs
in
this
new
experimental
process,
and
I
also
want
to
make
sure
we
take
an
opportunity
to
celebrate
that
the
package
team
has
been
like
wildly
successful
over
the
last
year.
You
guys
have
created
a
whole
new
stage
and
capability
and
landing
point
for
our
customers
where
we're
displacing
existing.
You
know
large
engineering
effort
products,
and
so
that
is
a
testament
to
your
efforts.