►
From YouTube: OCI Weekly Discussion - 2020-10-14
Description
The OCI weekly developer's call recording from Oct 14, 2020. Agenda and notes are here: https://hackmd.io/El8Dd2xrTlCaCG59ns5cwg?view#October-14-2020
A
A
Derek
okay,
all
right
great,
so
we're
all
pretty
familiar
with
the
docker
terms
of
service
stuff.
That's
been
coming
and
we've
been
discussing
it
quite
a
bit
around
the
various
impacts
and
what
does
it
really
mean
in
the
bigger
picture?
There's
the
deleting
of
content,
which
of
course,
I
don't
think
we're
really
too
worried
about
at
least
in
this
forum.
It's
six
months
and
hasn't
been
used.
Then
there's
a
larger
conversation,
fine
about
preserving
all
content.
A
It's
there
are
the
question
of
whether
they
should
be
getting
that
public
content
with
authentication
and
so
forth
is
an
interesting
question.
But
the
larger
thing
that
we've
been
kind
of
really
discussing
amongst
the
cloud
vendors
and
you
know
isvs
and
so
forth-
is
where
yeah?
What
does
that
reliability?
Look
like?
We've
talked
a
little
bit
about
there's
additional
challenges
because
when
you're
using
some
of
these
multi-tenant
services,
it's
docker
doesn't
know
whether
they're
coming
from
a
particular
customer.
A
So
it's
kind
of
evolved
into
a
larger
conversation
of
reliability.
It's
not
just
a
shared
cost
model
and
what
we
wanted
to
try
to
do
is
use
this
as
a
moment
to
kind
of
educate
customers
and
on
a
the
general
concern
around
reliability
of
public
content.
It's
not
that
public
content
itself
wouldn't
be
reliable,
there's
just
a
lot
of
connections
between
that
source,
the
internet
and
the
destination.
You
know,
we've
all
seen
them
in
you
know.
A
There's
I
want
to
say
the
majority
there's
lots
of
different
outages
that
have
nothing
to
do
with
the
particular
provider.
There
have
been
dns
outages,
there
have
been
cdn
outages,
there's
been
humans
involved
that
drive
trucks
and
backhoes
and
so
forth.
So,
to
try
to
put
a
better
context
to
this.
Like
I
said
we
wanted
to
write
this
article
and
it's
not
specific
to
docker
images.
A
The
well
docker
images
are
large.
That's
certainly
of
an
impact
they're
also
used
in
production
environments,
whereas
npm
you
get,
you
know
you
could
argue
debian
and
others
they're,
not
production
assets,
they're
assets
that
get
built
in
a
development
environment
and
get
tested
and
then
promoted
and
usually
they're
actually
delivered
from
some
local,
reliable,
relatively
global.
A
That
we'll
see
that
in
a
moment
source,
so
I've
been
trying
to
figure
out
how
to
to
best
message
this
and
we're
talking
about
writing
a
shared
article,
but
to
set
the
stage
a
little
bit.
I
did
in
my
typical
model,
wanted
to
share
a
couple
of
slides
that
show
kind
of
show
this
model,
and
it
hopefully,
is
just
a
reminder
of
the
stuff
we're
already
doing
today.
So
let
me
I
kind
of
jumped
right
in
there's
the
typical
hackendy
sign
in
please,
but
let
me
get
this
up.
A
A
It
looks
good
okay,
so
I've
been
trying
to
refer
to
this,
and
this
is
certainly
a
rough
sketch
the
first
time.
So
this
is,
you
know,
obviously
needing
some
some
help.
But
if
we
took
a
particular
region
and
I'm
just
going
to
pick
a
particular
region-
and
we
stand
up
some
compute
in
that
region
and,
of
course,
there's
lots
of
compute
and
I'm
talking
about
particular
app
per
se
and
of
course
in
our
world,
we
think
of
containers
running
on
that
compute
and
I'm
not
by
any
means
trying
to
get
into
the
serverless
conversation.
A
The
point
is:
there's
some
kind
of
compute
and
we
run
some
workloads
on
it
and,
of
course,
there's
some
kind
of
storage.
That's
some
kind
of
multi-tenant
storage
right.
We
don't
buy
disks
in
clouds
anymore.
For
the
most
part
you
know
we
buy,
you
know
access
to
resources
and
queuing
and
there's
some
kind
of
authentication
model.
That's
there
and
then
there's
this
networking
that
holds
that
whole
environment
together
as
well,
and,
of
course,
we
use
things
like
load
balancers
to
load
balance
across
these
workloads
for
various
different
reliability.
A
Scalability
all
the
id
reasons,
and
then
we
have
the
nebulous
cloud
with
things
like
dns
and
cdn
in
them,
and
we've
got
a
poor
user,
that's
just
connecting
through
the
local
isp,
which
we
all
seem
to
be
doing
these
days
so
great
they
connect
and
hopefully
through
dns.
If
it's
working
right,
they
get
routed
to
a
load
balancer
and
that
load
balancer
would
route
within
that
that
regional
area
of
a
workload
now
stuff
happens
right.
You
know,
containers
fail,
we've
designed
these
to
fail
is
supposed
to
be.
A
A
Those
are
things
that
we
do
in
our
environment
of
our
apps.
But
of
course,
there's
this
larger
infrastructure,
and
you
know
it's
not
often,
but
it
does
happen
where
a
cloud's
regional
infrastructure
can
fail.
You
know
there
might
be
some
storage
that
goes
out
and
a
whole
bunch
of
customers
are
affected
and
even
vms
that
are
trying
to
scale
up
are
affected
because
the
storage
infrastructure
might
be
out,
authentication
might
go
out
and
that
takes
out.
A
You
know
pretty
much
can
take
out
an
entire
region,
if
not
more
so
we
start
to
have
these
problems,
but
you
know
we're
like
okay,
that's
why
we
have
you
know
multi-region
availability
and
different
clouds.
You
know
we
there's
multi-region,
there's
zonal,
there's
all
kinds
of
different
ways.
The
point
is,
is
that
you
split
this
workload
up
across
two
locations,
because
even
when
the
humans
with
backhoes
or
storms
that
come
and
take
out
large
swaths
there's
another
one
nearby
and
that
can
keep
it
available.
A
So
our
customers,
you
see
that
the
cdn
the
dns
has
pulled
off
of
these
to
us,
and
now
it's
going
to
west
u.s
for
the
sake
of
argument
here
now,
if
we
zoom
all
the
way
out
and
that
same
customer
or
different
customers
around
the
world
are
trying
to
get
in,
they
can
get
routed
to
lots
of
locations
right.
So
that's
that's
kind
of
a
standard
model,
whether
they're
doing
all
of
that
or
not
it's
not
important,
but
you
know
you
can
route
between
a
lot
of
them.
A
The
question
is:
would
we
ever
build
a
system
that
has
some
central
dependency
on
some
particular
resource,
I'm
just
picking
on
australia
here
I
don't
know
why?
Because
if
australia
goes
out,
then
they're
all
out
and
there
really
isn't
anywhere
to
go,
because
you
now
have
this
critical
piece
of
the
system
that
has
taken
everything
out.
A
So
if
you
kind
of
think
about
what
we've
been
doing
with
public
content,
with
the
assumption
that
public
content
is
available
for
production
workloads,
why
is
it
we're?
Assuming
that
a
public
registry
is
a
central
point
of
failure
that
might
have
a
failure,
has
nothing
to
do
with
that
registry
itself
or
that
cloud
itself?
I
was
going
to
draw
pictures
of
cdns
and
dns's
in
there
that
could
cause
this
outage.
A
A
So
that's
the
preface
the
discussions
and
you
know
a
rough
outline
of
something
that
we
have
been
discussing
wanting
to
try
to
get
messaging
out,
because
there's
there's
two
phases:
there's
this
immediate
messaging.
What
do
we
help?
The
you
know
the
larger
community
of
customers
to
to
do
about
this,
because
docker
can
have
all
the
money
in
the
world
to
you
know
never
throttle
anybody.
They
have
no
ability
to
make
the
internet
reliable.
A
Is
this
a
moment
where
we
start
talking
about
what
the
long-term
models
should
be
so
the
thought
premise?
And
as
we
talked
more
about
this,
it
seems
like
something
that
shouldn't
be
any
particular
cloud
that
has
to
go
through
this
or
any
particular
isv,
whether
it's
you
know
github
and
brian's,
here
or
whereas
I
go
with
that.
That
should
take
on
the
story.
A
So
there's
a
short
term
of
an
article
that
we
would
get
out
to
help
customers
understand
the
the
positioning
on
it
long
term,
we'd
like
to
move
whether
it's
a
mirroring
solution
or
a
workflow
that
has
gates
so
that
we
don't
get
well
promoted.
Content
that
happens
to
break
everybody
also
work
through
a
mirror.
That's
a
longer
term
thing
that
we'd
like
to
figure
out,
hopefully
through
oci
what
we
would
do
for
the
next
year.
But
what
do
we
do?
For
you
know
the
pending
november
1st
through
the
holidays,
where
we're
all
locked
down.
C
B
C
I
think
at
least
from-
and
this
is
common-
I
think-
to
all
our
cloud-
customers
while
well
the
public
registry
or
while
the
public
registry
is
just
such
as
where
customers
are
pulling
images
from
many.
Many
customers
end
up
doing
what
we're
already
suggesting
they
should
do.
They
copy
those
images
into
their
private
registries
and
they
they
they
may
take
build
time
dependencies
on
that.
C
Yeah
yeah
and
they
are-
and
I
and
I-
and
I
say
that
with
some
put
some
grain
of
salt
here,
but
it
the
customer-
is
already
solving
this
problem
in
some
fashion.
Right,
that's
one
and
two:
they
all
have
varying
needs
as
to
why
they
have
to
solve
it
and
and
why
they
need
to
make
copies
of
what
they
do
with
it.
They're
doing
that
today.
So
anything
we
end
up
in
the
short
term.
Giving
guidance
on
is
going
to
be
simply
reinforcing
as
a
best
practice
look
do
that
because
it
makes
sense
right.
C
It
also
helps
docker
just
in
general,
but
that's
the
best
I
can
say
as
and
and
then
going
beyond
in
longer
term.
Obviously,
that's
not
something!
We
need
to
try
and
figure
out
right
in
a
second,
but
that's.
I
would
take
it's
kind
of
like
making
a
large
statement
to
try
and
tell
a
broader
container
industry
across
the
world.
It's
like
hey!
Here's
like
here's,
the
standards
body,
that's
going
to
help
you
like,
like
I'm,
not
sure
where
oci
plays
a
part
outside
of
sharing
and
talking
about
this.
C
C
That
second
part
is
going
to
be
a
more
thorny
problem
to
solve,
in
the
short
term,
giving
guidance
to
customers
saying
we're
aware.
This
is
how
it
could
be
here's
what
you
should
definitely
go.
Look
at.
That
seems
like
a
no-brainer
almost
right
we
should.
We
should
do
that,
because
many
of
us
are
probably
already
thinking
about
something
like
that.
B
So
omar
now
I
actually
have
something
concrete
to
say.
First
of
all,
I
think
you
know
you're
right
that
this
is
a
customer
problem
that
needs
to
solve
it
like
we
can
all,
as
cloud
providers
talk
about
how
to
help
and
standards
buyers
can
talk
about
various
ways,
but
the
other
the
customers
have
to
own
their
supply
chain,
that's
sort
of
the
point
and
control
their
supply
chain.
B
I
think
that
there
is
an
urgent
situation
right
now,
which
I
think
is
why
we're
here
talking
about
this.
You
know
if
you're
squinting,
look
at
oci.
Is
this
oci's
problem
or
business?
I
don't
know
I've
never
been
to
one
of
these
meetings
before
I
don't
know
what
the
scope
is,
but
this
is
definitely
a
place
where
everybody
who
is
worrying
about
the
problem
can
at
least
talk
about
how
to
provide
guidance
right
now
and
it
seemed
expedient.
I.
B
D
D
A
A
A
I
agree
so
if
you
look
at
and
again
this
is
in
the
longer
bucket,
so
I
want
to
be
really
clear
about
what
we're
talking
about
now
versus
some
options.
What
we
can
talk
about
in
the
future,
so
this
is
really
a
matter
of
buying
time
until
we
can
have
this
larger
conversation
which
to
michael
no
more's
point
is.
A
Is
you
know
if
you
look
at
most
other
package
managers,
the
package
you
pull
is
or
the
package
you
are
referencing
in
your
thing,
you
don't
actually
specify
where
which
registry
it
pulls
it
from
you're,
specifying
this
thing
and
then
separately,
there's
this
configuration
that
says
by
the
way,
use
the
public
one
or
use
this
private
one.
You
know
my
get
and
so
forth
and
that's
a
separate
configuration.
A
D
D
E
Let's
say
I
see
what
you
mean
yeah,
we
do
something
similar,
but
I
mean
it
solves
this
problem
for
just
building
go
apps
into
containers,
but
yeah.
We
we
have
an
environment
variable.
That's
basically
published
images
to
this
place.
It
doesn't
really
solve
the
pull
images
from
this
place
problem,
but
I
see
what
I
mean.
It's
kind
of
similar.
B
B
They
are
happening
in
production,
often
on
production
systems,
where
the
poll
is
happening,
the
last
possible
minute-
and
so
that
is,
you
know
bad
on
so
many
levels,
including
causing
you
know
significant
organizational
like
you
know,
bandwidth
strain
on
everybody,
especially
docker,
and
you
know
what
we're
trying
to
get
to
right
now
is
a
guidance
forward
to
help
people
mitigate
the
situation,
to
help
docker
not
get
melting
down,
be
melting
down
into
load
and
then
longer
term.
Yes,
alternative
approaches
to
building
whether
it's
the
tool,
the
client,
etc.
B
Then,
at
the
oci
level,
published
joint
guidance
with
a
bunch
of
signatories,
that's
sort
of
how
we
decided
to
come
to
this
meeting
and
we'd
love
your
part
to
be
part
of
that,
and
then,
in
the
longer
term
yeah.
I
think,
there's
a
digging
in
deeper
in
understanding
on
a
per
industry
basis
or
different
segments.
How
how
to
provide
that
guidance.
A
I
think
the
the
challenge
that
we've
had
is
look
in
the
scope
of
things,
we'd
love
to
say,
hey
doctor:
can
you
wait
till
february
pass
the
holidays
and
we'll
deal
with
this?
Then,
when
we've
got
a
better
solution,
that
assumes
endless
money
that
assumes
things
aren't
falling
over.
There's
lots
of
assumptions
in
there
that
just
are
just
not
reality.
A
So
we
wanted
to
not
leave
this
just
out
there
for
customers
to
have
random
failures
and
kind
of
create
lack
of
credibility
for
all
of
us
that
have
been
working
in
this
industry
for
so
long
because
there's
no
one
a
customer,
that's
going
to
get
a
failure
is
not
going
to
just
be
upset
at
one
entity,
they're
going
to
be
upset
and
when
they're
upset
it
doesn't
really
matter
which
direction
it
gets
faced.
So
it's
none
of
the
clouds
none
of
the
vendors
nobody's
going
to
win
in
that
situation.
A
So
what
can
we
do
proactively
to
help
customers
not
just
make
excuses
but
see
a
bigger
picture
of
something
and
kind
of
recognize
where
we're
at
this
isn't
just
related
to
to
docker
images
right,
the
there's
helm
stuff.
That's
been
going
on,
there's
npm,
there's
other
there's
all
kinds
of
package
manager,
problems
that
have
the
same
thing.
Brian
was.
A
A
You
should
definitely
consume
curated
public
content,
bring
it
into
your
environment
test
it,
and
then
you
know
work
from
there.
Every
cloud
in
isv
is
going
to
have
a
competitive
model
for
how
to
do
that.
There's,
probably
some
common
pieces,
some
kind
of
eventing
model.
Maybe
we
put
into
the
distribution
spec
that
we've
been
talking
about
for
a
while
that
lets
people
know
when
a
tag
has
been
updated
and
those
are
all
the
nuanced
conversations
of
things
that
we
can
talk
about
later.
F
F
F
If
you
had
showed
up
two
years
ago,
barely
any
registry
folks
were
here
because
we
weren't
working
on
distribution
yet
so
like
historically,
the
oci
hasn't
really
had
much
to
say
in
this
space
because
we've
been
doing
run
times
back
and
image
back,
I
I
guess
yeah
just
to
cut
to
the
chase,
I'm
still
struggling
like
I
I
want
to
participate
in
this.
I
think
it's
important,
I'm
still
trying
to
see
like
what.
F
Why
would
the
industry
look
to
oci
to
say
something
here
because
they've
never
come
to
us
before
about
like
this
is
mostly
a
cloud
platform
topic
implementation,
specific
topic.
So
I
again,
I
definitely
do
not
say
that
in
the
sense
of
like
you
know,
that's
not
for
us
to
do.
I'm
just
I'm
trying
to
figure
out
how
we
frame
that
as
like
that
we
all
of
a
sudden,
become
a
reliable
source
of
information
about
something
that
we've
never
really
covered
before.
G
F
Yeah,
I
mean
that's
that's
what
I'm
saying
like
at
this
point
in
time,
like
it's
a
great
like
coming
here
right
now,
like
you're,
you
look
at
the
participant
list.
We've
got
every
cloud
provider
registry
represented
here.
We
have
a
bunch
of
container
d
and
kubernetes
related
maintainers.
So
yes,
I
get
that
we're
all
here
and
we're
in
that
sense
we're
the
right
group.
I
guess
you
know
whatever
we're
authoring
like
yeah.
A
Right,
I
think
I
mean
I
I
have
been
more
involved
more
recently.
I
don't
have
the
history
that
you
know
you're
talking
about
the
runtime
image
spec
that
came
in.
Certainly
you
know,
just
as
I've
been
involved,
it's
there
has
been
a
you
know:
registry
focus
on
it.
So
when
we
were
talking
about
how
we
could,
if
the
whole
positioning
has
been,
this
is
not
just
a
docker
problem,
it
doesn't
matter
who
picks
this
up
most.
A
You
know
npm
had
problems
with
this
before
you
know
being
moving
into
github,
and
these
are
much
smaller
packages
right.
So
this
is
a
general
problem.
It's
only
getting
worse
if
we're
going
to
co-author
an
article.
So
it's
not
just
this
fractured
set
of
messaging
all
over
the
place.
Where
would
you
host
it?
A
F
Yeah
and
and
to
be
honest,
like
I'm,
not
at
all,
arguing
that
we
shouldn't
host
the
blog
post
or
any
any
of
the
what
I'm
worried
about
is
actually
maybe
the
longer
term
is
like.
I
don't
want
people
to
say.
Oh,
the
oci
is
going
to
provide
a
solution
to
docker
hub
rate,
limiting
which
you
know
again.
I
don't
think
anyone
here
thinks
that's
what
what
oci
will
provide
it's
just
it's
so
far
away
from
you
know
what
the
oci
has
on
its
plate,
but
I
I
guess
that's
what
I'm
saying
is
like.
F
A
F
Yeah
yeah,
and
maybe
I
need
to
think
about
that
more.
I
don't
want
to
just
ramble
about
because
I
really
don't
want
to
hold
this
up
from,
like,
I
think
the
short
term,
the
article,
the
you
know
some
guidance,
some
thinking
that
that's
going
to
be
valuable
and
useful,
and-
and
I
see
no
problem
with
hosting
that
I
guess
I'm
more
yeah.
F
H
In
the
helm
deprecation,
should
they
just
help
people
get
aware
of
it.
I
mean
in
a
way
it's
a
very
it's
a
kind
of
related
problem.
A
lot
a
large
and
apparently
increasing
number
of
people
are
using
helm,
deprecated
packages
that
are
being
terminated
in
in
a
month's
time
and
who,
whose
problem
should
this
be?
Who?
H
How
is
the
failure
of
communication
with
customers
actually
happened?
Why
are
customers
and
increasing?
I
mean
users
and
increasing
numbers
using
these
things
that
are
literally,
have
been
deprecated
for
a
year
and
about
to
be
turned
off.
I
mean
there's,
definitely
a
question
about
like
who:
how
do
we
communicate
with
users
in
the
sort
of
cloud
native
world
about
what
their
responsibilities
are
and
what?
F
H
F
A
I
also
think,
I
think,
to
be
to
be
practical
on
the
thought
process.
You
we
often
get
these
conversations
where
we
try
to
write
something,
and
then
somebody
says
well.
What
is
that
based
on
so
the
thought
was
if
we
can
write
this
high
level,
you
know
general
blog
post,
that
is,
you
know
in
a
neutral
body,
the
thought
being
oci
and
it's
co-authored
by
you
know
the
all
the
various
cloud
providers
and
isvs
that
you
know
to
contribute.
So
it's
definitely
coming
across.
A
As
you
know,
not
some
slanted
view
of
it
and
then
each
cloud
provider,
article
isv,
can
sorry
each
cloud
provider
isv
can
write
their
specific
article
referencing
it
for
like
hey
here's,
some
valid
thing
and
by
the
way,
here's
how
you
solve
this
in
our
environment.
So
this
way
it
gives
the
basis
for
github,
google,
aws,
azure,
so
on
and
so
forth.
Ibm
to
be
able
to
talk
about
this
is
the
basis
by
what
we're
doing
the
same
way.
A
Like
you
know,
container
b
is
out
there
docker's
out
there
there's
this
base
infrastructure,
everybody
knows
about,
and
then
it
gets
used
specifically
in
that
environment.
So
it
was
thought
to
be
like
a
framing
and
just
quickly
for
phil's
point,
because
I
obviously
was
rushed
in
part
of
the
way
I
said
it.
The
thought
is
that
we're
obviously
not
going
to
provide
a
solution.
You
know
the
fact
that
we
have
some
reference.
Implementations
is
interesting,
it's
more
of
what
should
we
do
like?
Is
there
you
know?
Should
there
be
a
separate
revenue
registry
configuration?
A
Should
we
have
a
mirror
spec?
Should
we
have
a
spec
on
promotion
workflow
that
maybe
we
don't
own
the
tools
for
promotion,
but
there's
probably
some
general
apis
that
as
content
moves
between
registries
and
the
signatures
need
to
go
with
it,
for
instance,
that
there's
some
stuff
that
we
can
enable,
so
that
you
know
github
and
circle
ci
and
labs
and
code
fresh
and
all
those
others
can
build
atop
that
as
well?
F
I
I
don't
know
if
justin
has
any
insight,
you
know
that's
data
based,
but
I
always
feel
like
I
mean
a
few
folks
have
said
early
on
in
this
call
that
you
know
folks
that
kind
of
are
further
down
the
learning
curve.
Already
you
know
use
some
some
common
practices
around
private
registries.
They
don't
pull
from
public.
F
F
B
I
wish
that
was
as
true
as
I
thought.
It
was
a
couple
of
weeks
ago.
We
are
uncovering
situations
where
customers
are
creating
kubernetes
yaml
files
with
docker
hub
urls
in
them
directly
for
specific,
like
common
shared
resources
and
common
sort
of
things
that
then
get
hooked
up
to
the
rest
of
the
system.
So,
okay.
A
Yeah
more
help
charts
the
town
charts
have
the
same
problem
because
helm
charts
have
this
embedded
registry
name
or
no
registry
of
the
faucet.group,
so
they
take
a
kubernetes
cluster,
they
say:
hey,
deploy,
prometheus
or
whatever.
All
the
different
projects
are
and
use
this
helm
chart
to
do
it
by
the
way
the
helm,
charts,
I'll,
pull
them
from
docker
hub
or
gcr
in
some
cases.
So,
even
though
we've
there's
like
three
ranges,
there's
the
core
services
that
all
of
our
clouds
run.
A
We
should
just
be
cleaning
those
up
and
we
we
do
find
some
places.
You
know
we
fix
those
up
like
that's
just
a
staple
there's,
no
reason
we
should
be
running
things
outside
of
our
own
clouds.
The
second
one
is
where
customers
run
workloads.
It
depends
on
the
service
aks.
You
know,
customers
tend
to
be
more
mature
about
it,
so
they
in
general
tend
to
know
better.
We
have
other
entry-level
services
like
app
services,
which
we
can
see.
A
You
know
what
they're
doing,
because
it's
a
multi-ten
service
and
you'd
be
surprised
how
many
in
fact
it's
gotten
better
over
the
years,
but
there's
a
lot
of
production
polls
pulling
directly
from
docker
hub.
But
the
one
that
kind
of
caught
me
by
surprise
is
the
one
that
michael
was
just
kind
of
referring
to.
Is
you
know,
people
take
they
take
their
communities
cluster
and
then
they
want
to
deploy
some
core
infrastructure
and
they
use
a
helm
chart
for
it
and
guess
where
it
references
it
from
some
public
resource.
I
J
I
Here
yeah,
I
was
going
to
ask
about
the
helm
chart
aspect
because
at
digitalocean
like
I'd,
be
surprised
if
we
had
a
customer,
that's
not
installing
a
public
help
chart
that
pulls
from
docker
like
it's
the
the
standard
and
for
a
lot
of
open
source
projects.
That's
now
the
only
documented
way
to
to
deploy
to
kubernetes
they
don't
they're,
not
publishing
raw
manifests
where
you
can
easily
go
and
change
the
repos.
I
K
I
mean
I'll
say
as
the
future
owner
of
helm
v2,
I
think
like
as
helm,
charts
move
to
v3
we're
gonna
have
to
solve
the
same
problem
on
registries.
Right
like
it's
exactly
it's
gonna
come
up
again
that,
like
you'll
need
those
helm
charts
closer
to
wherever
the
customers
are
and
not
at
whatever
the
the
future
source
is
which
might
be
more
distributed.
But
that,
like
you,
know
like
everyone
knows
like
that,
distribution
just
allows
for
more
failures
to
happen
in
the
wild
right,
more
distinct
failures.
A
You
know-
and
this
is
why
I'm
hopeful
the
you
know-
maybe
extracting
the
the
registry
name-
might
be
the
master
switch
that
solves
all
this
youtube.
I
can
change
these
things,
but
you
know
again
it's
like
just
glimpses
of
ideas
into
the
future
and
there's
lots
of
conversations
we'll
have
to
have,
but
we're
all
hearing
and
feeling
the
impact
of
it.
B
B
I
don't
think
that's
the
intent,
but
as
I
listen
to
the
various
comments
about
the
details
of
the
problem,
it
seems
almost
inevitable
that
the
solution
will
involve
changes
to
how
we
think
about
containers
and
the
clients
and
the
libraries
and
all
the
various
tools
around
it,
and
so
we're
going
to
need
to
have
that
conversation.
As
part
of
this
group.
It's
not
a
like
how
to
run
your
service
problem.
B
It's
a
how
how
containers
work
problem
as
part
of
a
broader
problem
to
be
sure-
and
I
think
that
you
know
I
agree-
that
we
need
to
have
a
different
industry
context
for
how
we
talk
about
the
whole
problem.
But
we
have
an
acute
situation
right
now
to
brian
goff's
problem
about
point:
sorry,
not
from
brian
goff
phrases.
Docker
wrote
an
article.
This
is
true:
we've
just
learned
over
and
over
again
that
our
customers
are
not
properly
aware
and
not.
B
B
L
I'm
just
going
to
echo
all
your
guys.
Sorry,
I
was
a
little
late.
I
had
a
existing
meeting
and
this
one
didn't
hit
my
calendar
until
laters.
Today
I
mean
I
imagine,
cormac's
already
covered
the
part
for
for
me,
so
I
mean
I
I
just
I.
I
only
recently
met
michael,
but
I'm
I'm
more
or
less
in
agreement
with
what
michael
just
said.
I
think
I
think
that
part
of
it
is
also
like
what
we're
seeing
and
I
don't
know
what
was
discussed
earlier
but
like
it's
not
just
us,
it's
basically
everybody.
L
You
know
it's
helm
and
the
the
ticket
that
I
read
this
morning
and
it's
you
know.
I
think
I
think
it's
also.
There
was
a
tweet
this
morning.
That's
like
you
know,
hanselman
was
was
talking
about,
serverless
is
actually
still
servers
and
free
software
is
not
actually
free
and
like
this
is
actually
it's
it's
bigger
than
just
containers.
It's
like
folks
have
trained
themselves
to
in
a
way,
that's
just
not
and
to
your
point
lasker
about
about
the
the
environmental
part
of
it
like
it's,
it's
really
it's.
L
L
If
you
look
at
the
the
helm
example
as
as
a
good
sort
of
marker,
is
that
like
people,
don't
read
the
docs
people
don't
the
by,
and
by
and
large
users
don't
read
our
blogs
and
by
and
large
users
don't
follow
us
on
social,
so
you
would
need
actual,
like
tooling
changes
and
breakages
for
people
to
actually
see
and
make
make
differences,
because,
as
until
that
happens,
it's
not
gonna.
You
know
things
aren't
gonna
really
change
and
the
thing
that
we
all
wanna
avoid
is
is
is
like
user.
L
There
will
be
user
pain,
but,
like
you
know,
on
what
spectrum
is
that
pain?
I
think
that's
the
that's.
That's
kind
of
the
part
that
we're
all
at
because
we've
we've
come
to
love
our
fast
inner
loops,
with
throw
it
away,
disposable,
sort
of
like
approaches
and
and
that
might
need
to
get
revisited
and
I
think
that's
bigger
than
just
containers
or
anything
else
I
mean.
L
Certainly
if
you
look
at
ci,
like
you
know
the
biggest
users
in
docker
hub
like
it's:
it's
because
they
they
use
docker
for
ci
and
they
every
single
build
they
keep,
and
they
do
that
for
they
do
that
because
they
think
they
need
it
or
because
they
can
and
some
of
them
do
it,
because
they
don't
care
to
delete
it.
But
I
think
that's
a
that's
more
than
just
a
a
registry
question
or
a
that's
like
a
software
engineering
question
like
what
do
you
need
for
those
things?
L
L
Yeah,
or
or
just
like,
maintainable
workflows,
it's
not
even
just
any
one
container
right
because
it
like
I,
I
think
you
could
probably
point
to
serverless
workflows
that
hit
this
problem
to
multi-container
workflows
that
had
this
problem
really.
Actually,
if
you
think
about
it,
like
rpms
and
devs,
have
this
like
any
any
binary
artifact
has
this
problem,
so
I
think
I
think
yeah,
it's
it's
it's
it's.
You
know
more
or
less
a
software
problem
and
a
workflow
problem
which
has
artifact
repositories
tied
into
it.
A
And
just
yeah
to
address
josh's
comment:
I'm
hoping
he's
somewhat
joking
about
it,
because
there
will
be
people
that
do
get
concerned
about
that.
You
know
the
idea
here
is
not
that
we
shouldn't
leverage,
you
know
open
source
or
public
content
and
in
order
to
make
sure
that
part
of
this
message
talks
about
that,
because
that
is
how
we're
getting
so
much
done-
and
you
know
in
relatively
comparative
times,
is
that
we
can
leverage
additional
infrastructure,
that's
out
there
and
components
and
software
and
codes
and
so
forth.
A
This
is
certainly
a
lot
more
than
what
do
you
call?
We
always
go
searching
for
code
snippets.
I
just
drew
a
blank
so,
but
the
question
is:
when
I
get
this
code,
even
in
well-intended
places,
it
doesn't
always
work
as
intended
or
update.
So
we
definitely
want
to
promote
the
ability
to
leverage
open
source
content
without
every
last
piece.
Every
last
human
change
made
having
a
dramatic
impact
that
can
take
out
the
world.
A
If
there
is
a
workflows
in
place
that
you
know
bring
public
content
in
given
to
into
a
customer's
environment,
allows
them
to
test
and
validate
before
they
deploy.
Then
it
takes
some
of
the
burden
off
some
changes
that
might
happen
upstream.
That
could
cause
downstream
changes.
It
certainly
takes
the
financial
burden
off.
You
know,
companies
that
are
stuck
in
this
position
that
are
just
trying
to
do
the
right
thing
and
help
an
ecosystem,
and
it
also
takes
the
burden
off
individual
contributors
that
are
trying
to
promote
something
that
oops.
I
tried.
A
I
made
a
well-intended
change.
It
worked
for
99
of
the
people
and
that
one
percent
that
it
didn't
work
for
turned
out
to
be
pretty
critical
to
some
pretty
critical
places.
So
I
think
it's
just
a
matter
of
a
maturity
of
the
life
cycle,
where
images
are
just
this
production
large
artifact
that
raced
ahead
of
the
problem
that
we've
already
been
seeing
in
npm
and
helm
and
others.
L
So
so
I
know
I've
talked
to
brian
about
you
know.
Working
I've
talked
to.
I
think
I
talked
to
michael
about
this.
I've
talked
to
a
bunch
of
you
individually
about.
We
should
get
around
some
of
these
things
and
and
and
put
some
some
work
against
them.
So
I
think
it's
it's
it's.
You
know
it's
all
of
these
things.
It's
not
just
any
one
thing,
but
there's
probably
investment
that
that
needs
to
be
made
and
some
call
it
boring
that
just
needs
to
get
done.
B
Hey
chad,
you
just
gotta
crack
up
like
you
talk
about
infrastructure,
plumbing
hard
to
get
people
to
work
on
that
kind
of
stuff.
At
google
we
have
exactly
the
opposite
problem:
people
love
to
work
on
infrastructure,
plumbing
and
we're
trying
to
get
to
work
on
end
user
facing
products
all
the
time.
So
it's
funny
like
well.
A
L
Also,
like
people
learn
off
a
blog
post
that
was
written
by
a
devrel
person
who
isn't
going
back
to
update
that
blog
post
for
the
thing
that
happened
next
right
or
they're,
like
you,
said,
they're
going
to
stack
overflow
and
that's
like
the.
I
think
our
docs
are
like
the
last
the
last
bastion.
When
all
of
the
more
digested
docks
fail,
then
they
come
back
to
the
deeper
docks
to
dive
in,
but
the
the
preference
is
for
a
pre-digested
dock
and
that
those
tend
not
to
get
reupdated.
B
Place
I'll
speak
for
one
of
the
cloud
providers.
We
really
hope
that
we
can,
in
this
instance
at
least
start
high-level
guidance
even
pointing
to
the
various
per
provider
for
isv
preventer,
detailed
links
or
whatever
and
give
customers
a
single
point
of
like
this
is
the
story.
This
is
how
you
work
with
it.
Here's
deeper
details
for
your
particular
cloud
provider
or
your
predictor
vendor
or
whatever,
as
I've
said
before.
I
think
this
is
topically
relevant.
B
B
A
Oh
well,
that
was
part
of
the
motivation,
quite
frankly,
is
to
give
some
credence
to
the
follow-up
guidance.
If
there's
like
we
each
have
customers
right.
Customers
are
going
to
be
running
on
our
clouds
they're
going
to
get
a
failure
couldn't
fail.
It
may
not
have
nothing
to
do
with
this,
but
they're
going
to
blame
this
problem.
A
So
when
they
start
reading
it,
we
want
to
be
able
to
provide
them
with
some
context
and
if
they're
distrustful
of
it
in
our
cloud
specific
articles,
rsv
specific
articles,
we
can
point
to
here's
this
article
that
talks
about
the
general
problem.
Here's
how
you
solve
it
in
this
platform,
I
get
worried
a
little
bit
over
and
you
know
we
can
talk
about
this
around
the
oci
kind
of
putting
links
to
the
various
vendors,
because
that
starts
to
get
a
little
weird
as
an
advertising
platform,
but
certainly
from
our
cloud
providers.
A
You
know
we
can
point
back
to
this
article,
because
the
customers
are
already
working
with
a
specific
cloud
they're
having
this
problem.
We
just
want
to
provide
to
your
point
nisha
some
validation,
that
this
is
not
a
broken
thing
because
of
docker
or
because
of
that
cloud.
Pacific
implementation
there's
a
general
pattern
to
follow
so
yeah.
D
M
A
I
hadn't
shared
it
yet
because
so
what
I
did,
because
there
really
isn't
much
there
what's
there
is
this
rough
outline
and
some
articles
and
a
section
because
I
I
wasn't
looking
to
write
this
myself
and
have
everybody
else
go?
Yes,
it
was
there's
lots
of
opinions,
there's
maybe
too
many
opinions.
So
I
was
trying
to
figure
out
if
we
can
get
some
kind
of
nominations
of
some
people
and
then
that
group
would
work
on
it,
because
this
is
obviously
not
something
we
want
to
take
like
a
year
to
get.
D
C
A
A
The
as
as
chris
mentioned,
this
is
probably
a
good
ocitob
conversation
kind
of
the
next
steps,
so
we
can
take
that
there
obviously
is
to
members
on
the
call
here
and
if
you're
interested
in
you
know
co-authoring
that
with
us,
please
let
me
know
and
we'll
we'll
take
it
to
the
tob
and
vote
whether
we
feel
like
it
is
or
isn't
the
right
thing
under
oci.
If
it's
not
we'll
find
another
place
like
we
do
want
to
get
this
out.
I
think
that's
a
clear
thing.
M
Yeah,
I
think
it's
rare
for
you
not
to
have
all
the
different
kind
of
clouds
and
folks
involved
in
container
land
that
are
part
of
the
tod,
so
it
makes
I
think
it
makes
sense
yeah,
no
we're
happy
to
help
like
once.
You
have
something
to
share.
Please
do
and
we
could
do
we'd,
go
through
a
formal
process
and
have
the
tob
vote
and
and
go
for
it
and
kind
of
treat
it
as
a
living
document
that
evolves
over
time.
B
All
right:
well
thanks
everybody
for
helping
talk
through
this
and
figure
it
out.
Steve,
really
thank
you
for
being
leading
the
conversation
here.
We're
certainly
very
grateful,
and
at
least
someone
on
my
team
at
least
most
people
will
be
involved
in
helping
out
so
we'll
be
in
touch
with
you,
steve
directly.
All.
A
Right
and
thank
you
and
I
want
to
also
say
thank
you
to
docker.
It's
like
this
is
a
hard
spot
for
them
to
get
caught
in,
and
you
know
it's.
I
think
they.
It's
certainly
a
problem
that
falls
on
their
shoulders
right
now,
but
it's
really
not
limited
to
their
problem.
Brian
was
joking
the
other
day
about.
Thank
you
for
handing
me
your
cogs
or
so
there's
some
joke
around
there
like
yeah,
and
it
was
like.
You
know.
Thanks,
wait
a
second
here.
Can
we
come
up
with
a
better
model?