►
From YouTube: OCI Weekly Discussion - 2021-05-12
Description
Recording of the weekly OCI developer's call on 12 May 2021; agenda/notes here: https://hackmd.io/El8Dd2xrTlCaCG59ns5cwg?view#May-12-2021
A
Okay,
so
let
me
let
me,
shall
I
shall
I
start
okay
I'll
keep
this
I'll,
keep
this
short
and
sweet,
but
just
to
sort
of
introduce
myself.
So
my
name's
larry
cable,
I'm
a
recaptured
employee
of
oracle
and
I'm
an
architect
in
the
java
platform
group
oracle,
primarily
in
the
area
that
we
call
serviceability,
which
is
probably
the
dullest
area
of
the
java
platform
to
work
in,
and
my
current
role
within
the
gt
platform
is,
is
somewhat
bifurcated.
A
Serviceability
in
the
java
platform
covers
a
variety
of
things
like
the
debugging
apis,
the
java
management
apis
java
flight
recorder,
integrated
logging
capabilities,
dot,
dot
dot.
So
basically,
basically,
it's
all
of
the
visible
this
of
service
ability
and
visibility
into
the
function
of
the
jvm,
primarily
as
it
operates,
and,
of
course,
that
the
jvm
has
been
around,
for
you
know
about
half
of
my
actually
probably
two-thirds
of
my
career
and
in
in
pretty
much
over
that
period
of
time.
A
These
various
features
have
evolved
in
an
ad
hoc
fashion
and
in
a
fashion
that
makes
some
fundamental
assumptions
about
the
environment
in
which
the
jvm
operates.
Those
being
fundamentally
shared
namespaces,
like
you,
know,
uid
process
id
mount,
namespace,
networking,
namespace,
etc,
persistence
of
file
systems
beyond
the
lifetime
of
the
jvm,
etc.
A
And,
of
course,
all
of
those
all
of
those
axioms
are
no
longer
axiomatic
in
in
in
the
container
world,
which
causes
a
number
of
problems
for
for
at
least
three
personas,
who
I
will
attempt
to
represent
here
so
persona
number.
One
is
for
humble
serviceability
architects,
such
as
myself,
trying
to
build
a
language
time
that
will
operate
in
both
the
host
environment
and
a
containerized
environment.
A
The
the
second
persona
is-
and
this
is
another
one
that
applies
to
me,
also
as
a
cloud
vendor
who
wishes
to
provide
a
rich
telemetry
environment
in
their
cloud
for
customers,
deploying
applications
that
are
containerized
in
that
cloud
and,
last
but
not
least,
the
the
poor,
long-suffering
application
developer,
who,
who
also
has
to
build
their
applications
and
potentially
deploy
them
in
containerized
environments
and
and
where
all
of
these
personas
come
together
in
their
relative.
A
Misery
is
much
around
the
the
the
decoration
or
identity
of,
in
some
cases,
forensic
artifacts,
that
that
their
their
runtimes
create.
A
That
you
know
persist
beyond
the
lifetime
of
the
normal
or
exceptional
operation
of
their
their
applications,
and
what
that
really
boils
down
to
is
particularly
in
cloud
that
scale
is,
you
know,
I'm
I'm
in
the
jvm,
I'm
potentially
collecting.
A
You
know
useful
information
about
the
normal
or
abnormal
operation
or
termination
of
a
jvm
and
in
in
capturing
that
information
information.
That's,
as
I
say,
forensic
in
nature,
so
it
may,
it
may
normally
needs
to
exist
beyond
the
lifetime
of
the
of
the
the
system.
That's
creating
it.
I
need
the
ability
to
uniquely
identify
those
artifacts
or
that
meta
information
in
such
a
way
that
I
can
correlate
that
back
to
the
system,
the
system
that
created
it
now
in
a
sort
of
host
in
a
in
a
host
environment.
A
You
know
I
have
things
like
process
id.
I
have
location
of
the
the
jvm
etc.
The
version
information
from
the
jvm
and
you
know,
network
host,
name,
etc,
that
I
can
cons
up
some
sort
of
you
know:
identity,
tuple
that
I
can
capture
somewhere
in
either
the
artifacts
that
I'm
creating
like
a
core
dump
or
a
gc
dump,
or
an
error
log
that
I
can,
then
you
know
post
process,
consume
and
trace
that
back
to
the
system.
A
The
system
that
caused
it-
and
you
know
that's
a
fairly
trivial
problem
at
you-
know
order
of
magnitude,
one
system
or
ten
systems,
but
becomes
becomes
a
little
bit
uncomfortable
when
you
add
a
bunch
of
zeros
to
that
order
of
magnitude,
problem
and-
and
this
whole
thing
is
compounded
by
containerization.
A
So
while,
while
you
really
don't
want
your
runtime
system
or
your
application
to
be
too
intelligent
about
its
operating
environment,
but
obviously
you
know,
for
example
the
jvm
is
you
know
it?
Could
it
adjusts
its
memory
footprint
and
cpu
footprint?
According
to
you
know,
what
can
container
constraints
are
applied
to
it?
A
In
a
container
in
a
container
context,
so
you
know
obviously
process
id
is
no
longer
useful
right
and-
and
really
you
know,
extracting
extracting
the
path
for
where
the
jvm
happens
to
be
installed
in
in
a
container
isn't
very
useful
either,
because
really
what
I
want
to
be
able
to
do,
particularly
as
as
the
the
the
scale
increases,
I
want
to
be
able
to
say
that
this
version
of
a
service
or
application
deployed
on
you
know
in
this
particular
context,
and
this
particular
instance
of
that
deployment
was
the
was
the
root
cause
or
the
source
of
this
particular
telemetry
information.
A
And
what
that
really
boils
down
to
is
some
way
for
all
three
of
those
personas
to
be
able
to
portably,
and
you
know
reasonably
extract
the
identity
of
of
the
container
for
one
of
a
better
description
here,
image
and
also
the
instance
identity
of
that
of
a
particular
instantiation
of
that
of
that
container
and
with
those
two
pieces
of
information,
you're
then
able
all
three
of
those
personas
are.
Then
you
know
readily
able
to
capture
that
identity
and
persist
that
identity.
A
You
know
in
application
log
files
in
core
dumps
in
gc
files.
You
know
we
can
expose
it
over
our
management
apis
so
that
those
can
be
extracted.
A
You
know,
external
to
the
container
dot,
dot,
dot,
there's
a
plethora
of
ways
that
you
can
abuse
this
information,
but
there's
there's
really
no
there's
no
existing
portable
mechanism
for
for
determining
this
when
you're
in
the
context
of
a
container
and
so
really
what
what
I'm
looking
for
here
is
is
some
guidance
as
to
you
know
is
this
something
that
is
in
the
scope
of
the
of
the
runtime
spec?
I
mean.
A
Obviously,
this
information
is
available
in
the
image
manifest
at
least
the
digest
is
available
in
the
image
manifest
and
the
you
know,
the
the
the
runtime
engine
is
responsible
for
creating
the
container
instance
identity.
A
So
if
there
was
a
simple
language,
independent
mechanism-
because
I'm
not
I'm
not
I'm
not
just
here-
you
know
representing
java-
you
know
I
would
I
would
love.
I
would
love
because
a
lot
we
write
a
lot
of
our
internal
code
in
goang
for
our
sins,
so
it
would
be
nice,
it
would
be
nice
for
language.
You
know
run
times
in
in
any
language.
A
That's
that
finds
itself
in
a
container
to
be
able
to
extract
this
iden
this
you
know,
identity,
information
and
and
be
able
to.
You
know,
use
that
identity.
Information,
for
you
know
whatever
fair
means
or
foul
the
the
consumer
feels
sees
fit
to
to
to
use
it
so
that
that,
in
a
nutshell,
is
my-
is
my
elevator
pitch
we're
now
in
the
in
the
penthouse
and
okay.
B
So
a
lot
of
things
you
talked
about
are
in
the
scope
of
what
we
would
call
a
container
on
time
manager
as
opposed
to
a
runtime
engine,
okay
and-
and
the
reason
for
that
is
just
because
we
needed
to
put
one
together
for
kubernetes.
You
know
kubernetes,
of
course,
manages
pods
deploying
containers.
B
You
know
in
your
clusters
and
and
this
this
sort
of
stuff
has
to
be
done
all
the
time
there.
There
are
also
some
other
non-kubernetes
users
of
the
container
runtime
interface
that
they
do.
Some
very
similar
things
to
everything
you're
talking
about
docker,
for
example,
is
a
is
a
runtime
yup,
yup
container
runtime.
That
does
a
lot
of
the
stuff
you're
talking
about
so
there's
ways
to
I'm
not
sure
in
the
context
of
what
you're
talking
about.
How
do
you
launch
your
containers?
B
A
At
a
a
mega
corporation
such
as
oracle,
it's
all
of
the
above
right,
which
is
why
I'm
sort
of
desperately
desperately
looking
for
you,
know
a
standard
solution
as
opposed
to
you
know
a
per
a
per
implementation,
yeah
yeah.
B
A
Because
I
I
don't
want
to
end
up
having
code,
that's
you
know
grubbing
about
trying
to
determine
if
it's
running
in
kubernetes
or
docker
or
podman,
or
you
know,
cater
containers,
dot,
dot,
dot
right
right,
although
I
suspect
that
that's
probably
what
will
end
up
falling
back
to
you,
but
I
I
thought
that
this
you
know
was
a
an
issue
of
of
sufficient
interest.
A
C
I
think
I
shared
some
with
phil
a
couple
weeks.
Actually,
several
months
ago
now,
we've
had
people
from
the
diamond
framework
team
kind
of
asks
like
how
do
they
know
they're
even
running
in
a
container?
How
do
they
surface
this
so
later?
When
stuff
happened?
It's
not
just
enough
to
know
that
this
was
in
host
abcd3
like
it
actually
needs
to
be
something
they
can
know.
C
Oh,
what
you
know
whether
it's
in
azure
or
you
know,
standard
framework
or
it
could
be
at
azure-
could
be
aws
google
wherever
right,
how
do
they
give
some
kind
of
meaningful
information
to
know
that
they've
got
a
bunch
of
things
failing
it
all
relates
to
what
a
you
yeah,
an
architect
could
say
like.
Oh,
that
was
that
node
over
in
that
environment,
so
yeah.
A
A
You
know,
telemetry
sources
that
that
you're
you're
aggregating
somewhere
in
your
system-
and
you
want
to
be
able
to
you
know,
do
something
a
little
bit
like
you
know
the
open,
open,
tracing
kind
of
idea
where
you
can
do
end
to
end
exactly
that's
what
I
would
say
to
woof.
You
know,
and-
and
you
know
we
certainly
in
in
a
number
of
oracle
products.
We
have
a
thing
called
an
execution
context
id
that
we
a
bit
a
bit
like
a
thread
or
a
transaction
context
that
gets
propagated.
A
You
know
it's
out
of
band
between,
you
know,
let's
say
the
app
server
and
the
database,
for
example.
So
we're
then
able
to
see
that
you
know
request
xyz
that
came
through
the
app
server
that
went
through.
You
know,
connection
pool
five
to
the
to
the
database,
node
four
and
that's
where
it
fell
over.
You
know
we
have
the
ability
to
do
that
sort
of
correlation,
and
you
know
part
and
parcel
of
that
is
which
instance
out
of
this.
You
know
200
instances
of
version.
A
B
Pattern:
you're
you're,
coming
from
the
you
know
the
war
jar
you
know,
era
where
you
had
session
managers
that
you
know
for
for
java
instances
that
were
being
managed
at
a
web
portal
kind
of
thing,
yeah,
yeah
now
and
whoa
wait
a
minute.
I
just
woke
up
inside
a
container.
How
does
this
work
exactly?
I
understand
the
pattern
in
the
issue
and
there
are
a
lot
of
people
commiserating
with
you
right
now.
Yeah.
A
D
So
so,
just
to
throw
this
out
there,
I
I
posted
it
in
the
chat.
I
don't
know
who
all
has
the
chat
in
there,
whatever
way
you're
connected,
but
you
know
th.
This
is
the
total
other
end
of
the
spectrum.
The
colonel
community,
a
red
hat
developer,
has
been
iterating
on
this
patch
set
for
over
two
years.
D
So
I
don't
know
what
that
portends
as
far
as
when
it
will
end
up
hitting
the
the
kernel
someday,
but
it's
exactly
kind
of
the
the
solution
in
the
sense
of
like
ignore
how
you
got
here.
If
you
created
a
container
on
a
linux
kernel,
this
feature
will
generate
a
unique
identifier
that.
D
In
the
audit
system,
so
again
it
maps
process
id
on
the
host
to
a
unique
container
identifier
which
again
you
can
read
his
initial
proposal,
which
you
know
is,
is
basically,
I
think,
correlates
some
to
what
you're
talking
about
that.
There's
just
a
sense
in
which
how
do
you
even
decide
something
as
a
container,
because
we,
you
know
at
least
we're
in
the
oci
community.
D
D
True,
so
this
solves
it
in
the
sense
that
you
know
at
the
linux
kernel
level
you
end
up
with
with
an
identifier,
no
matter
if
you
came
through
kubernetes
or
docker
or
lxc
or
whatever
you
use
to
get
there.
A
There's
there's
still,
of
course,
the
issue,
then
of
correlating
that
kernel
identifier
with
the
you
know,
with
the
image
associated
with
it
right.
D
D
D
It's
not
done
yet
so,
but
yeah
you're
right.
It's
not
it's
not
an
entire
answer
to
your
query,
to
your
complication,
but
it's
it's
maybe
part
of
that
in
that
it
gives
you
an
identifier
which
can
then
be
combined
with
other
data,
and
I
who
was
that
in
the
chat
I
thought
that
was
a
you
know,
an
idea
of
a
metadata
services.
Kind
of
that
was
you
brandon.
A
Yeah
yeah,
I
noticed
in
the
chat
someone
mentioned
the
the
downward
api
in
in
kubernetes,
but
you
know
when
I
was
doing
a
little
bit
of
sort
of
pre-investigation
for
this.
I
noticed
a
couple
of
of
threads
in
the
kubernetes
world,
where
people
were
complaining
that
even
the
the
downward
api
doesn't
doesn't
expose
the
the
container
digest.
A
So
it's
not
so
it's
not
actually
possible
to
to
to
to
get
that
information
in
in
the
kubernetes
environment,
or
certainly
when
I
at
the
time
that
this
this
thread
was
created.
That
probably
wasn't
the
case
but
again
that
that
that
ends
up
with
you
know
a
dependency
on
your
on
which
container
you
know,
engine
runtime
environment,
your
your
one,
you're
you
know
executing
in,
and
you
know
we
do
it's
a
bit
problematic.
You
know
to
start
having.
A
C
Well,
that's:
where
is
it
something
you
can
like
dip
in?
You
know
where
some
of
the
masses
are
with
container
d
and
others.
It
was
not
to
your
point.
Yes,
there's
lots
of
different
hosts,
but
maybe
they
can
surface
them
consistently
also,
but
to
know,
because
inside
the
container
obviously
don't
know
that
the
digest
you
have
to
reach
out.
So
what
I'm
hearing
you
say
he's
like
who
am
I
you
know
what
what
image
am
I
based
on
and
then
there's
the
others?
I
think
what
environment
am
I
in?
C
So
if
you
have
the
host
id-
and
I
think
what
I
heard
you
phil
say
was
like
if
you
could
correlate
some
other
piece
of
data
says
well,
this
host
id
is
actually
associated
with
you
know:
vm
name,
you
know
22,
which
somebody
can
correlate
to
when
that
was
created
in
their
their.
You
know
cloud
diagnostic
scripts
or
something
you
have
enough
breadcrumbs
to
stitch
together
the
story.
A
It
it
seemed.
It
seemed
to
me
in
my
naive
world
view
that
that
you
know
the
the
the
entity
that
is,
you
know
responsible,
for
you
know,
basically
starting
starting
a
container
from
its.
You
know,
file
system
image
has,
you
know,
has
this
information
right
it
or
can
or
can
more
readily
find
that
information
than
any
code
running
in
the
container?
A
B
E
B
It
can
be
right,
yeah,
we
usually
talk
about
run
c
type
runtimes
as
runtime
engines,
as
opposed
to
container
runtime
right.
A
E
So
I
think,
from
from
the
perspective
of
the
runtime
specification,
the
thing
that
consumes
the
runtime
specification,
that's
run
c,
doesn't
have
any
knowledge
of
the
container
id
doesn't
have
any
knowledge
of
the
image
id
image
digest
image
layering.
It
doesn't
know
anything
about
that.
It's
handed
a
config
for
how
to
run
a
process
within
a
particular
root,
fs
that
it's
also
handed
okay.
Okay,
so
we've
got
to
go
up
stack
at
least
one
more
layer
before
we
can
get
that
interesting
data
that
you're
actually
after
okay.
B
So
I
was
thinking
I
was
really
pretty
cool.
What
phil
was
showing
that
we
could
there
there's
at
least
one
service
that
could
get
you
the.
I
didn't
know
that
that
looks
really
cool.
A
Cool
well,
this
has
been
useful
to
me.
It's
probably
not
been
very
useful
to
you
guys,
but.
B
No,
no,
it
definitely
is.
It
definitely
is
at
least
at
least
I've
unburdened
myself
so
like
it
may
be
as
simple
as
talking
to
the
guy.
That's
doing
doing
the
stuff
that
phil
with
phil
linked
and
asked
him.
If
he's
got
any
thoughts
about
integrating
with
the
container
runtimes
to
get
some
additional
information.
E
B
I,
as
mentioned
we've
got
metadata
for
this
stuff,
so
we
can
probably
do
it
right
at
the
container
runtime
level.
We
could,
probably
you
know,
provide
additional
information
exactly
okay.
If
I
knew
what
container
run
time,
you
were
using,
that's
what
I
know
you've
got,
you
might
have
a
plethora,
all
of
them
yeah
I
mean
and,
of
course,
from
from.
A
A
from
a
java
platform
perspective
we
have
to
support,
you
know,
maybe
not
all
of
them,
but
all
of
the
interesting
ones
right
for
for
some
definition
of
interesting,
which
is
you
know
a
lot,
so
you
know
we
can't
just
say
we
run
so
much
better
on
kubernetes
than
any
of
that
other
stuff.
That
would
get
us
in
a
lot
of
trouble
with
the
people
who
own
and
love
the
other
stuff.
A
So,
unfortunately,
we
have
to
be
a
little
bit
of
a
switzerland
here,
but
you
know
just
to
that
point
on
the
yeah.
I
agree
about
the
the
you
know:
host
data,
I'm
not
really,
I'm
not
really
suggesting
exposing
host
data
to
the
to
the
container.
A
I'm
really
only
suggesting
exposing
container
data
to
the
container,
so
you
know
once
once
you've
persisted
the
the
sort
of
container
and
instance
identity
in
in
any
sort
of
you
know:
external
artifact,
like
a
core
dump
or
a
gc
dump
or
an
error
file
or
a
log
file.
You
know
that
the
the
the
ex
the
exterior
ecosystem
can,
you
know,
can
provide
the
necessary
correlating
metadata
to
figure
out
that
you
know
this.
A
This
container
instance
actually
was
running
on
that
virtual
host
over
there,
because
that
the
the
thing
that's
doing,
the
correlation
upstream
has
both
access
to
the
the
container
information
and
also
access
to
the
to
the
host
information.
You
know
within
the
sort
of
trust
domain
that
that
that
would
operate.
A
A
Are,
you
know
universally
recognized
by
the
rest
of
the
ecosystem?
Right,
you
know,
from
from
the
repositories
down
to
the
you
know
to
the
nitty-gritty,
so
you
know
it
could
be.
It
could
be
any
arbitrary
two
poles,
as
long
as
it
was
possible
to
you,
know,
uniquely
identify
the
the
the
image
version
from
which
the
instance
was
executing.
That
was
responsible
for
the
creation
of
the
of
the
telemetry
so
and
if
you
have
digest.
C
A
Well
then,
that
comes
back
to
my
my
sort
of
point
about
who
who
does?
Who
knows
what
and
does
what?
So,
you
know
at
the
level
of
the
of
the
things
running
in
the
container.
You
know
they're
they're,
fairly
simplistic.
They
simply
emit
the
telemetry
that
they
would
emit
anywhere,
but
suitably
tagged
with
its
you
know,
identifiers
and
then
the
the
ecosystem.
Surrounding
that
you
know,
for
instance,
you
know,
let's
say
you've
got
some
sort
of
distributed
log
ingestion
system.
A
You
know
it
would
be
responsible
for
adding
the
the
additional
context
to
say
that
you
know
this,
so
this
log
stream
came
from
you
know:
node
54
and
available
availability
domain,
five
fault
domain,
one
right
host
three
right,
because
it
it
or
someone
downstream
from
it
has
you
know
sufficient
visibility
and
and
authority
to
to
extract
that
information.
C
A
Yeah
and
and
and
it
needs
to
it
eventually
needs,
I
think,
to
tie
back
to
to
the
the
the
image
the
image
and
the
instance
of
that
image
that
the
that
emitted
it
because,
particularly
for
you
know,
for
for
the
guys
at
the
at
the
sort
of
top
of
the
consumption
stack
the
the
app
developer.
You
know
who's
who's
building,
you
know,
building
containerized
software
and
deploying
it
on.
You
know
whoever
their
favorite
cloud,
vendors
cloud
or
or
container
runtime.
A
A
If
they
have
150
of
them,
it's
just
you
know
their
tasks
and-
and
all
of
this
always
tends
to
happen
in
failure
cases
where,
where
you
know
someone
someone's
job
sucks
sufficiently
because
they
have
to
go
and
figure
out
why
what
broke
where
when
and
why?
And
you
know
making
making
the
task
of
of
of
that.
This
of
forensic
or
pathology
investigation
harder
by
making
them
guess
or
do
you
know
an
order
in
search
of
all
the
possible
systems.
C
A
We
really
want
to
make
our
you
know,
serviceability
capabilities
when
containerized
as
as
consumable
as
possible
relative
to
those
features
when
running
on
a
on
a
bare
node.
A
Anyway,
I've
chewed
up
a
lot
of
your
guys
time,
which
I
greatly
appreciate,
and
thanks
for
for
some
of
the
the
informational
links,
I'm
gonna
check
this
one
out
and.
A
Yeah,
absolutely
we're
on
a
voyage
of
discovery
here.
Trying
to
to
to
to
you
know,
come
come
up
with
some
features
that
will
make
this.
That
will
make
this
functional
and-
and
I
I'd
really
like
to
see
it-
I
really
like
to
see
it
be
language
independent,
so
that
you
know
no
matter,
you
know,
even
if
you're
running
you
know
kotlin
or
closure
or
some
you
know
swift
in
a
container
that
the
the
it
doesn't
require.
A
You
know
major
machinations,
on
behalf
of
the
of
the
the
poor
developer
or
the
language
runtime
to
to
to
make
this
stuff
just
easy
to
consume
anyway.
I
I'm
done
if
you
guys
are.
A
Cool
well,
I
appreciate
I
really
appreciate
your
time.
Everyone.
It's
it's
been
a
pleasure.
Hopefully
you
you've
seen
the
last
of
me,
but
you
never,
but
you
never
know.
I
may
come
back
to
haunt
you
again.