►
From YouTube: CNCF SIG Runtime 2020-03-19
Description
CNCF SIG Runtime 2020-03-19
A
C
D
B
I'll
go
ahead
and
start
then
hi
guys
means
RIA,
Bhatia,
I'm
part
of
Microsoft's
and
I've
been
partial
kulit
since
the
inception
of
the
project.
So
yeah
we
raise
the
price
that
we're
gonna
present
to
you
guys,
or
it's
also
nice,
because
I
know
the
TOC
has
so
many
things
to
do
so.
It's
cool
that
now
cigarette
there's
a
thing
called
cigarette
time
and
we
can
kind
of
filter
or
discussions
through
you
guys
because
yeah
we
really
want
to
see
this
project
move
forward.
B
C
D
Hi
am
I
unmuted?
Yes,
I
am
I'm
Quinton
I'm,
also
a
co-chair
here
and
I've
been
involved
in
the
TSE,
pretty
much
all,
rather
the
sense
here
pretty
much
since
the
beginning
and
was
on
TSE
for
a
while
and
yeah
just
here
to
help
where
I
can
I
might
actually
have
co-sponsored
virtual
couplet
back
in
the
day,
if
I
remember
correctly,
so
very
good.
F
C
G
Sorry
I'm
so
yeah,
my
name
is
Eric
Rd
I'm
somebody
who's
just
been
you
know.
I
guess
now
lurking
around
the
kubernetes
ecosystem
for
bit
saw
this
new
sick.
You
know
was
interested
in
continuing
runtimes
been
following.
You
know
some
of
the
other
projects
as
well
from
cata
to
Nabilah
and
yeah.
Just
sorry
about
my
kids
in
background,
but
yeah
I'm,
just
you
know,
excited
to
learn
more
and
see
what
yeah
it's
the
roadmap
for
the
sick.
F
H
F
H
I
J
K
C
L
C
B
Okay,
can
you
see
my
screen
yeah
I,
think
perfect
yeah,
so
hi
guys
I'm
a
virtual,
complete
query,
maintainer,
so
yeah,
let's
just
I,
have
a
lightweight
PowerPoint.
A
lot
of
our
links
are
in
the
PR
that
we
have
in
the
CNCs
project,
but
I
just
want
to
start
the
discussion
and
kind
of
see
what
we
need
to
do
to
get
to
the
status
to
incubation
size.
That's
kind
of
the
goal
for
us
today:
okay,
so
introduction
to
virtual
for
folks
that
don't
really
know
about
it.
It
was
created
in
December
2017.
B
So,
instead
of
reinventing
the
wheel.
Well,
we
decided
to
make
a
simpler
version
of
what
the
couplet
could
be,
and
so
it
gave
us
a
lot
more
flexibility
into
kubernetes
and
allowed
us
to
really
decide
what
it
meant.
When
you
get
a
pot
of
kubernetes,
you
get
the
pod
status,
there's
a
couple
of
things
that
we
didn't
really
need
like
capacity
for
a
node
or
like,
but
we
didn't
need
capacity,
the
sense
for
the
workload
and
that's
how
you
understood
how
much
the
pod
release
went
out
to
so
yeah.
B
So
that's
why
we
decided
to
create
it
and
after
that
we
were
also
working
with
a
company
called
hyper
SH.
That
company
no
longer
exists,
but
they
a
lot
of
them
are
kind
of
now
around
whether
it's
an
Ali,
Baba
or
other
places
or
Microsoft,
and
their
some
of
they
were
still
kind
of
working
on
the
project.
I'm
past
that
we
also
got
more
people
involved.
So
there's
a
lot
more
providers
now
today,
since
when
are
you
release
when
your
release?
B
So
when
your
lease
we
released
everything,
so
every
provider
went
out
at
once.
We've
done
that
now,
I'm
at
wend,
auto,
which
is
really
really
really
important,
because
now
we
don't
really
have
to
keep
track
of
providers
and
they're
allowed
to
do
what
they
need
to
on
their
own.
But
we
created
a
governance
policy
for
providers,
so
we
can
support
them
within
the
project,
but
it's
more
like
us
supporting
them
as
an
organization
rather
than
through
a
release
process,
so
yeah.
So
some
stats.
B
We
have
five
core
maintainer
zhan
per
virtual
couplet
and
one
per
maintained
which
has
no
graduated
or
not
he's
he's
there.
But
he's
not
part
of
the
crony
haters
cuss
anymore,
so
we
leave
companies
friendly
Netflix
off
VMware.
We
have
someone
from
another
company
that
doesn't
want
to
be
named
from
that
company,
that's
cool
and
then
we
have
ten
project
maintainers.
So
this
is
that
provider
situation
that
I
was
talking
about
before
we
have.
B
Every
project
or
provider
has
their
own
repo
within
virtual
qubit
itself,
and
we
ask
that
there's
one
to
two
people
from
that
provider.
That
list
out
their
names
give
us
their
emails
and
they're
kind
of
the
point
of
contact
for
that.
So
we
call
them
project
maintainers.
We've
done
33
releases,
we're
currently
on
the
1.0
1.1,
which
released
on
December
2nd.
We
have
monthly
office
hours
its
to
being
really
quickly
than
it.
B
B
And
as
projects
been
going
on
for
now
like
three
years
so
yeah
and
then
eight
official
providers
in
the
repo
and
then
five
unofficial
providers
that
we
know
about
so
these
are
like
the
IOT
edge
provider.
This
is
kind
of
like
yodels
provider,
Netflix's
provider,
VMware's
provider
and
then
I
think
there
was
one
more
which
we
forgetting,
but
these
are
just
the
ones
that
we
know
about.
B
People
have
the
ability
to
go
in
and
kind
of
if
they
want
to
fork
it,
they
can
and
create
their
own
provider
or
a
lot
of
people
are
just
using
us
in
private
and
their
own
companies,
and
it's
just
it's
sometimes
difficult
for
us
to
know
about
it.
Even
if
they
create
an
issue.
You
know
exactly
know
what
company
they're
coming
from
but
yeah.
This
is
what
we
know
so
far
and
always
open
to
figuring
out
more
so
progress.
B
Basically,
if
compute
they
have
their
own
compute
notion
to
move
with
kubernetes,
so
to
get
that
API,
they
created
virtual
couplet
and
any
time
they
need,
like
a
virtual
couplet
note
or
whatever
it's
actually
spitting
out
to
their
meso
s--
underlays.
So
that's
really
interesting
the
way
that
they
created
that
flexibility.
It's
not
open
sourced
today,
but
there's
a
really
really
good
talk
that
we
did
at
last
the
last
coupon
around
what
Netflix
is
doing
with
Titus.
B
So
if
you
guys
want
to
learn
more
and
kind
of
understand
what
they're
doing
they
went
really
really
in-depth
at
our
last.
So
it's
the
virtual
couplet
on
intro
session,
the
last
coop
card,
so
go
ahead
and
check
that
out.
So
we
split
up
the
providers
to
the
out
of
the
tree
now
we're
in
maintenance
mode
and
we've
done
a
lot
of
how-to
talks.
We've
done
talks
with
bocce
court,
we're
in
Netflix
any
partner
that
we've
had
and
any
maintainer
really,
which
has
been
awesome.
B
We
have
an
understanding
within
like
as
your
example
for
what
it
should,
what
the
customer
experience
is,
and
we
kind
of
hold
that
to
a
high
standard,
and
everybody
else
has
the
ability
to
and
the
flexibility,
to
figure
out
what
that
and
experience
looks
like.
So
that's
why,
when
it's
hard-
and
we
talk
about
the
virtual
cool
product
in
general-
we've
enabled
a
couple
things
and
it's
up
to
the
providers
to
go
further
like
an
evil
networking,
an
equal
volume
support,
and
things
like
that.
So
this
is
our
definition
for
them.
B
It's
to
provide
the
backend
plumbing
necessary
to
put
forth
the
support,
the
lifecycle,
management
of
cause
containers
and
supporting
resources
in
the
context
of
kubernetes.
They
must
conform
to
the
current
api
of
a
virtual
kulit
and
they
must
kind
of
write
their
provider
in
a
way
that
it
doesn't
have
access
to
the
API
server
and
it's
a
well-defined
callback
mechanism
for
getting
data
back
like
secrets
and
config
maps.
B
It
could
turn
on
your
lights,
it
just
code,
so
it
could
really
do
anything,
so
they
must
figure
out
how
to
what
it
means
to
create
a
pod
update
about
pod
get
pod
status,
get
pods,
get
no
conditions
little.
It
gets
a
little
wonky
there,
the
operating
system,
whether
it's
Linux,
Windows
or
etc.
These
are
things
that
communities
exposes
and
we
allow
providers
to
also
expose
the
same
things
within
virtual
people
would
no
daman
pod,
endpoints,
Dilli,
pod
and
then
american
variables
config
maps.
B
No,
for
example,
no
one's
done
like
no
David,
endpoints,
DNS
names
and
more
so
in
a
CI.
We
created
our
own
notion
of
networking.
It
doesn't
go
through
kubernetes
networking,
but
it
does
I
mean
it
works
through
kubernetes,
but
in
our
the
way
that
we
do,
it
is
completely
different
from
what
you'd
expect
in
a
note
in
a
cluster,
but
for
our
customers
it
looks
basically
seamless
which
was
our
goal
within
adjure
itself,
and
so
these
are
kinds
of
the
things
that
every
provider
has
to
go
through
to
build
out
that
experience.
B
This
is
what
the
interface
looks
like
so
super
simple.
Now
this
is
what
we
kind
of
hand
off
to
people
providers
and
then
adopters
that
are
in
production
usage.
So
these
are
the
ones
that
we
just
know
about,
and
here's
tenfold
more
just
because
a
lot
of
these
or
we're
like
cloud
providers,
for
example
right
and
we
have
a
lot
of
customers
that
were
tracking
internally,
that
we
can't
exactly
talk
about,
but
that
are
there
and
I
know
like
VMware
not
be
aware,
but
Amazon
also
has
them.
They
have
virtual
people.
B
H
So
I
work
at
a
little
like,
like
I
said
before,
and
when
we
present
our
provider
at
conferences,
we
got
a
lot
of
questions
of
well.
How
conforming
is
it
with
kubernetes?
And
so
we
started
looking
into
this
and
at
the
beginning,
I
thought.
Well,
since
virtual
cubular,
there's
a
library
essentially
that
we
can
use
to
build
providers
conformance,
is
something
that
is
very
much
provider
specific.
So
these
numbers
really
only
apply
to
our
provider,
somebody's
AC
eyes.
Providers
conformance
might
be
different
because
they
implement
things
on
the
back
end
very
differently.
H
Some
of
the
places
where
our
provider
is
weak,
for
example,
is
in
the
support
of
downward
api.
There's
a
lot
of
downward
api,
s--
and
n
tests.
So
we're
hoping
to
get
those
pushed
back
up
into
virtual
Qibla
for
anyone
to
use
and
help
out
the
other
providers.
Essentially
in
supporting
that
was
that
functionality
so
yeah
virtual
keyboards
made
it
really
easy
to
actually
get
our
product
out
and
right
now.
Just
as
a
note,
we
are
not
open
source.
B
Here's
an
example
for
what
people
have
to
add
to
their
pod
deployments
or
their
deployments
in
general
I'm
to
get
to
spin
out
to
virtual
couplet
for
Elise
Dodger.
So
we
use
toleration
and
taints,
and
if
you
have
the
the
Reiki
you're
able
to
spin
out
to
virtual
couplet,
we
don't
automatically
spin
out
anybody
to
virtual
couplet.
B
So
when
you
create
a
create
a
deployment
and
you're
within
a
guess
or
just
say
his
engineers
in
the
house-
and
you
have
Urgell
it,
we
will
never
automatically
spin
you
out
just
because
it's
the
virtual
doula
is
different,
and
so
not
everything
if
you
haven't
tailored
new
deployment
for
what
works
like
you,
don't
have
daemon
sets.
You
don't
have
maybe
use
specific
metrics
or
things
like
that.
We're
never
gonna
do
that.
It's
always
a
user
choice
and
that's
very
explicit.
That's
the
recommendation
would
give
to
everybody
it's
user
specific.
B
They
need
to
understand
what
they're
doing
here
and
then
the
way
if
people
want
to
fill
up
their
notes,
for
example,
and
they
do
have
a
deployment
that
does
want
to
spin
out
to
virtual
Google
it
eventually
for
a
birth
scenario.
That's
when
they
could
go
in
and
to
like
node
affinities
and
basically
they're
able
to
spin
out
to
her
chocolate
if
things
are
tits,
if
things
happen
and
that's
the
way
that
we
end
up
doing
it
so
so
yeah,
that's
basically
it
from
my
side.
B
It's
a
lot
about
that
flexibility
and
being
able
to
kind
of
a
lot
of
people
are
using
a
virtual
couplet
to
match
their
current
infrastructure
with
kubernetes,
because
they
have
all
this
old
infrastructure
and
they
want
to
continue
to
use
it.
It
works
well,
but
they
want
their
organization
to
move
forward
in
terms
of
how
they
develop
and
how
you
deploy
workloads
and
that
lifecycle,
and
they
see
the
industry
moving
towards
kubernetes
and
so
virtually
gave
them
a
nice
middle
ground
where
they
don't
have
to
completely
overthrow
everything.
L
Have
a
question
because
I'm
this
is
the
first
time
I
really
seen
this
I
need
to
go.
Watch
those
videos
from
Cooper
recommended,
but,
oh
so,
for
node
affinity
with
this.
Is
that
mostly
for,
like
debugging
people
can
see
what
node
they
actually
ran
on?
There's
like
a
problem
or
how
does
how's
that
used.
B
It's
not
specifically
for
Apollo
Wow,
it's
been
so
long
since
I've
decided
the
way
I
remember
using
it
was
for
when
I
wanted
to
spill
over
to
virtual
do-boy.
So
basically,
we
said
that,
like
only
in
virtual
Kubla
like
there
is
a
certain
thing
it
only
in
particular
the
other
nodes
reached
capacity.
Basically,
then
you're
allowed
to
spill
over
to
earth
to
the
virtual
q1
node.
So
that's
the
way
that
we
used
it
I'm
sure
there's
other
ways
that
folks
can
use
it.
Okay,.
L
B
Okay,
so
if
you
know
you
actually,
we
add
which
Hardware
you
actually
land
on.
Can
you
is
there
a
way
of
finding
that
out?
No
like
down
to
where,
like
that?
So
this
is
up
to
the
provider,
so
original
cube
will
expose
the
node,
so
we
will
expose
the
CPU.
We
will
expose
some
sort
of
node
capacity,
but
usually
it's
ridiculous.
Usually
it's
like
three
terabytes
and
like
X
whatever
for
CPU.
So
it's
not
very
realistic,
but
we
do
have
an.
B
There
is
a
place
where
we've
been
able
could
realize
again
to
say
like
when
you,
when
you
talk
about
the
OS,
that's
where
you
can
put
Linux
or
Windows,
etc.
You
could
expose
the
actual
capacity
through
kubernetes.
If
you
wanted
to,
but
usually
on
the
back
end,
we've
seen,
a
lot
of
providers
have
larger
pools
of
resources.
But
if
you
wanted
to
specifically
tie
in
your
back
end
to
your
front
end,
you
could
do
that
purees
lets
you
do
that
already
and
virtual
cool.
B
C
A
question
so
you
mentioned
that
in
terms
of
people
migrating
to
kubernetes
are
using
this
to
replicate
more
their.
What
it
would
look
like
running,
kubernetes
right
so,
but
are
there
any
other
use
cases
for
people
who
you
know,
I've
already
decided
to
move
to
kubernetes
and
they
have
all
of
their
infrastructure
into
an
NES
or
even
going
forward.
C
B
Folks
that
where
do
you
have
all
the
infrastructure
on
a
lot
of
folks?
So
when
we
think
about
larger
organizations,
we
think
about
people
that
have,
and
we
can
talk
about
a
smaller
use
case
too,
but
for
folks
that
logic
or
drainer
enterprises
or
companies.
A
lot
of
folks
have
their
own
compute
notion
within
their
to
you.
So
they
to
folks
and
we've
seen
it's
all
over
where
people
are
building
out
teams,
specifically
just
for
kubernetes,
so
they're,
building
out
infrastructure
like
their
infrastructure,
Ops
teams
or
whatever,
and
those
are
the
folks
that
touch
kubernetes.
B
Now
they're
representing
a
virtual
public
routine,
and
that
cluster
could
fly
anywhere
and
could
resist
resemble
X
ematic
capacity.
But
they
don't
care
about
that.
They
don't
need
to
care
about
that,
and
so
they
don't
have
to
think
about
no
Daria's
cluster
errors.
That's
up
to
another
team
to
figure
that
out
and
if
something
happens,
they'll
automatically
move
over
workloads,
so
they
can
do
two
different
bridge
equivalent,
but
up
behind
Road
you
could
what
you
do.
D
I
still
have
a
kind
of
a
gap
in
my
understanding
here
so
so
baked
into
all
sorts
of
parts
of
the
kubernetes
api.
Is
this
concept
of
a
node,
so
you
can,
for
example,
request
that
containers
beyond
different
nodes
or
the
same
load,
and
that
has
you
know
specific
meanings
and
all
the
load
balancing
is
sort
of
across
pods.
D
You
can't
sort
of
wave
your
hands
and
just
make
it
go
away
as
far
as
I
can
tell,
but
I'm
curious
how
all
of
that
stuff
actually
works
like,
for
example,
auto
auto
scaling.
Presumably
I
mean
it
deals
with
the
concept
of
nodes
and
you're
running
out
of
nerds,
and
you
need
scale
and
all
that
stuff
doesn't
work
either.
B
Yeah
so
and
I
wish
Bryan
was
here
so
he's
our
kind
of
I
would
say
engineer
on
the
project.
We'd
be
able
to
go
through
all
that
with
you,
I,
don't
know
where
he
is
right
now,
but
I'm
gonna
give
it
my
best
shot
from
from
basically
user
and
more,
like
PM
centric
view
of
what's
going
on
here.
What
we
do
is
we
basically
do
our
best
to
we
fault
towards.
If
things
work
in
kubernetes,
we
wanted
to
look
like
kubernetes
as
much
as
possible.
B
So
when
your
things,
when
you're
thinking
about
things
like
auto
scaling
and
you're
thinking
about
things
like
load,
balancing
as
much
as
possible
at
the
surface
layer,
they
look
the
same
to
the
user
and
the
way
that
the
user
would
describe
these
things
in
pod
deployments.
So
the
way
that
you
describe
audited,
auto
scaling
etc
is
the
same,
but
you
still
have
to
even
when
you
have
like.
If
you
have
multiple
kinds
of
nodes
in
your
cluster,
that's
why
we
have
no
definitive
that's
why
we
have
taught
teens
and
Toleration.
B
So
if
folks
are
able
to
kind
of
pick
which
nodes
they
want
things
to
run
on
right
with
that
notion,
we
do
the
same
thing,
so
we
treat
virtual
kulit
as
a
node
from
the
users
put
standpoint.
It's
just
what's
happening
on
the
background
like
that,
doesn't
get
exposed
to
the
user
at
all.
So
it
does
look
like
just
a
note
in
kubernetes
the
way
the
how
and
we
are
asking
like
how
do
we.
This
is
a
very
good
question.
B
H
It's
an
expansive
question
and
one
that
we've
actually
worked
with
throughout
all
of
our
work
on
our
provider,
at
least
so
just
to
give
you
a
quick
background.
Our
provider,
when
you
submit
a
when
a
pod,
gets
dispatched
to
the
virtual
cubelet.
Our
providers
spins
up
a
virtual
machine
in
the
cloud
in
the
background,
and
your
container
is
run
on
that
virtual
machine.
Actually.
H
So,
in
order
to
make
that
work,
for
example,
the
downward
api,
the
plan
is
there
well,
once
the
machine
comes
up,
we
when
dispatching
the
pod
to
the
machine
to
run
there,
will
overwrite
environment
variables
or
create
environment
variables
that
have
the
specs
of
that
machine.
So
your
container
or
your
pod
running
on
that
virtual
machine,
sorry
I'm
good
I,
just
want
to.
D
Interrupt
you
tricky
I,
understand
all
that
stuff.
Okay,
all
right!
What
I
don't
understand
is
I
mean
there
are
lots
and
lots
of
examples.
I
can
give,
but
here's
a
basic
one,
yeah
I
launched
a
deployment
and
I
say
that
I
want
each
of
the
pods
in
the
deployment
on
a
different,
node,
yeah,
okay
committees.
Scheduler
then
tries
to
do
that.
A
B
A
D
Assume
what
what
I
want
as
a
user
yeah
I,
have
a
bunch
of
capacity
to
run,
containers
right
and
right
now,
unbeknown
to
me
and
I,
don't
really
care
it's
living
in
a
bit,
so
it's
living
in
a
juror
container
or
whatever
it's
called
and
all
I
want
to
do
is
run
my
pretty
standard
deployment.
That
says
don't
run
these
pods
on
the
same
machine
just
run
the
more
different
modes.
B
Meaning,
that's
that's
basic
in
the
mindset
of
you're
using
kubernetes
with
multiple
nodes
like
it
depends
on
your
cluster.
If
you
wanted
to
have
a
multiple
node
cluster
with
a
virtual
couplet
I
mean
you
could
technically
do
that.
If
that's
here,
if
that's
what
you
want
for
your
organization,
you
could
do
that
for
juku,
but
is
really
the
way
that
users
will
use
it
and
do
use
it.
It's
very
specified
and
they
have
a
really
good
reason
for
why
they
want
to
spend
a
virtual
cupola.
B
B
We
are
looking
at
things
like
if
you
want
to
be
well
taught
like
if
you
want
to
make
sure
that
your
high
availability,
et
cetera,
that's
really
up
to
the
backend
and
the
provider
to
provide
that
in
another
way,
and
those
are
still
use
cases
that
we're
working
towards,
for
example,
AC
I
would
probably
already
do
that,
but
in
this
scenario
like,
why
would
you
want
to
run
things
on
multiple
nodes?
I
guess
is
the
crux
of
the
question,
and
can
we
solve
that?
D
B
B
Able
to
do
that.
Actually,
we
could
give
users
that
like
if
we
did,
that
in
a
CI
or
euros
provider
or
something
we
could
use
an
environment
variable
or
something
like
that
to
express
that
you
want
a
high
availability
like
set
for
this.
You
want
it
to
be
I,
don't
know
times
three
to
make
sure
it
goes
on
three
different
machines,
and
we
would
do
that
in
the
background
and
what
you
would
see
in
the
front
end
like.
B
We
get
a
million
questions
not
really
like
yours,
but
more
like
what,
if
I
wanted
to
put
a
virtual
couplet
on
a
satellite
like
what,
if
I
wanted
to
spend
out
like
Hugh's
kubernetes,
is
my
control
plane
for
all
of
these
different
kinds
of
machines
across
my
home
or
my
business,
etc?
It's
the
the
creativity
of
people,
just
kind
of
it's
up
leveled
with
this
project
and
I,
think
that's
something
really
amazing
and
yeah.
It
doesn't
exactly
work
with
kubernetes.
B
B
D
When
you're
running
on
a
virtual
culet,
for
example,
h
a
so
that
the
mechanisms
that
kubernetes
provides
for
AJ,
like
no
affinity,
saying
I,
don't
want
my
containers
on
the
same
node,
because
they
don't
wanna
failed
same
time,
doesn't
work
so
I
guess
like
what
are
we
left
with?
If,
if
we
set
out
to
create
and
kubernetes
api
on
top
of
a
different
container
Orchestrator
and
the
communities,
api
substantially
doesn't
work.
What
do
we
have.
B
That's
a
strange
way
to
look
at
it.
So
basically,
like
virtual
cool,
it
isn't
boiling
the
ocean
with
what
it
can
do
it
understands
who
it
is.
It
understands
that
it's
providing
first
workloads,
it's
providing
an
abstraction
providers,
can
implement
those
things
if
they
feel
like
they
need
those
for
their
unuse
like
Netflix,
can
go
ahead
and
implement
whatever
they
need
for
the
API,
and
it's
working
for
them
today
to
make
sure
that
their
workloads
are
spun
out.
B
The
way
they
need
to,
but
they're
using
like
Netflix,
is
currently
using
this
because
they
have
virtual
pool,
but
they're
using
kubernetes
are
using
the
API
because
they
were
given
the
ability
with
this
project
to
get
the
flexibility
they
needed
for
their
structure.
Saying
that
kubernetes
is
the
end-all
for
everybody's
intra
is
just
not
going
to
be
and
the
entire
api.
B
B
We're
not
saying
that
we
know
we're
doing
everything
Cooper
dyes
can
do,
but
the
things
that
you're
talking
about
with
no
toleration
it's
like
we
can
still
do
those
if
you
have,
for
example,
if
you
have
a
special
like
GPU,
enabled
node
there's
somewhere
close,
you
don't
want
to
run
on
that
right
on
that
node
you're,
gonna,
save
it
off
for
the
specialized
workloads.
That's
exactly
what
we're
saying
we're
two
people
is
think
of
it
as
a
different
kind
of
OS
or
a
different
kind
of
operating
system.
B
What
we're
doing
here
today
is
that
enough.
Are
we
debating
like
the
core
premise
of
vertical
it
or
are
we
debating
what
we
need
to
get
virtual
couplet
towards
incubation,
because
we're
already
in
the
Sancia
so
I'm
trying
to
figure
out
like
how
we
can
get
to
incubation,
I
guess
and
if
it's
making
those
work?
Those
specific
use
cases
that
we
hold
as
virtual
coulomb
are
clear.
I
thought
they
I
mean
we
leave
it
a
more
flexible
for
a
provider.
B
D
D
We've
got
some
performance
percentages
and
those
are
useful,
but
we
also
know
that
conformance
and
it
covers
a
relatively
small
portion
of
the
kubernetes
api.
So
so
we
really
need
to
understand
like
as
a
usual
normal
user
of
kubernetes,
like
how
much
if
it
actually
works.
If
I,
if,
if
I
ran
it
on
an
online
virtual
cubelet
and
how
much
just
simply
doesn't
work
anymore,
I.
B
D
B
To
each
provider
to
do
that,
like,
depending
on
the
providers
and
the
way
functionality
you
make,
they
make
on
a
daily
basis
like
it's
very
up
to
them
and
how
they
explain
that
to
their
users
a
lot
of
them.
They
understand
it's
slightly
different
from
the
what
they're
gonna
get
from
a
normal
car,
a
node
and
it.
So
what
my
question
is:
how
do
we
do
that?
It's,
like
conformance,
is
the
way
to
figure
out
what's
in
kubernetes
right
and
that
was
kind
of
a
programmatic
way
to
figure
that
out.
B
B
B
D
So
the
comment
Brian
grant
made
in
the
PR,
which
is
that
the
windows
people
have
had
they
had
similar
problems.
They
wanted
to
support
Windows
containers,
Patrick
I
think
was
the
main
person
there,
and,
and
so
they
had
to
go
through
the
whole
of
kubernetes
and
figure
out,
like
which
parts
of
it
work
when
I'm
using
a
Windows
container
and
which
parts
of
it
don't.
Ok,.
D
Not
I
mean
I
understand
that
that
you
can't
vouch
for
any
given
providers,
implementation
of
the
interface
but
I
think
the
interface
itself
fundamentally
limits
a
certain
amount
of
stuff
I
mean.
Presumably
you
have
a
kind
of
a
reference
implementation
of
a
provider
at
the
moment
and
there's
also
certain
limitations
that
the
interface
itself
creates.
D
If
there's
no
way
to
allow
the
kubernetes
scheduler
to
do
anything
than
schedule.
A
pod
onto
this
large
group
of
nodes
that
are
hidden
underneath
the
virtual
cubelet
there's
a
whole
class
of
things
in
kubernetes
that
don't
work,
it
kind
of
doesn't
matter
who
the
provider
is
that
that
functionality
is
not
available
in
the
API
in
the
virtual
cumulative,
eaj
and
so
I
think
that's
the
kind
of,
and
that's
what
we're
I'm
around
us
for
I
think
a
long
time
ago.
Maybe
in
October
I,
don't
remember
exactly
when
he's
coming.
B
The
thing
we
can't
do
it
the
same
one
would
detail
unless
we're
doing
a
per
provider
like
our
interface
is
so
simplistic.
We
could
copy
and
paste
the
interface
in
that
and
describe
every
like
all
the
methods
we
have,
but
that
wouldn't
be
super
useful
for
anybody,
because
you
can
go
and
go
in
a
github
page
and
look
at
our
interface
and
see
what
we
support.
I.
Think
one.
D
B
Now
through
euros
provider-
and
we
were
gonna,
do
kind
of
like
a
write-up
on
what
that
meant
and
that's
kind
of,
and
we
were
gonna,
do
it
in
the
format
that
Windows
wanted
that
windows
had
before
and
that's
something
we
can
definitely
do
is
okay,
yeah,
and
if
that's
it,
then
that's
that
makes
sense.
It's
just
that
doing
it
per
provider.
B
It
just
like
the
reason
I'm
saying
this
is
like
it
doesn't
make
a
lot
of
sense
from
the
virtual
public
perspective,
because
every
and
like
it
doesn't
make
sense
for
end
users,
because
every
end
user
is
using
a
different
provider
so
going
through
yodels
and
going
through
any
like
just
as
you're
just
yodel
it'll
sure
it
I'll
give
you
some
sort
of
sense
that,
like
almost
everything,
can
kind
of
work,
but
like
it's
so
specific
provider
that
we're
not
going
to
be
getting
what
an
end
user
would
be.
Looking
for,
like
my
understand.
B
That's
why
I
would
ask
us
to
look
at
this
from
a
different
perspective
and
look
at
virtual
couplets
core
and
what
we
offer
there,
but
think
of
it
in
a
different
way,
instead
of
conformance
like.
Can
we
do
that
because
we're
still
like
and
I'm
going
to
get
back
to
this,
like
we're,
not
part
of
the
kubernetes
project
like,
and
there
is
a
reason
we
did
that,
because
we
were
so
different
from
kubernetes.
B
So
is
there
a
different
set
of
ideals
that
virtual
Kubla
can
make
as
a
project
understanding
that
we're
meshing
in
two
different
infrastructures?
Whether
it's
me
says
whether
it's
ACI,
whether
it's
something
else
to
kubernetes
like
I
we're
bringing
the
value
of
kubernetes
to
everybody,
but
the
way
that
we
do.
It
is
slightly
different
to
for
end-users,
so
I'm
just
asking
if
we
can
like,
because
if
we
can
read
out
that
documentation,
I
have
no
problem
doing
it.
I
just
don't
think
it's
gonna
be
useful
for
anybody
other
than
us.
What.
L
B
And
we,
actually,
we
have
a
lot
of
that
in
our
repo
in
like
in
our
and
our
Google
Drive,
and
things
like
that.
I
can
clock
that
up
on
a
readme
and
virtual
kublai,
we've
done
a
lot
of
like
you.
You
can't
do
daemon
sets
again.
If
a
provider
decides
to
implement
them,
you
can
do
daemon
sets,
but
it
will
be.
The
notion
will
be
different
from
what
a
kubernetes
user
would
expect.
You
can't
do
private
networking
and
some
of
the
providers
you
can
in
a
CI
like
it's
just
I'd.
H
So
users
can
know
that
also
I
just
want
to
say
that
virtual
cubelet
is
something
that
fundamentally
does
redefine
what
a
node
is
even
kubernetes
and
as
a
result
of
that,
if
you,
if
you're
redefining
whatever
know
of
what
a
note
is
and
how
a
node
behaves,
I
think
that's
a
you're
fundamentally
by
the
nature,
doing
that
you're
breaking
down
the
abstractions
and
certain
things
like
node
affinity.
Well,
what
does
that
mean?
H
Well,
it
means
something
to
a
regular,
curb
Nettie's
cluster,
but
you're
doing
something
specialized
here,
because
you
couldn't
get
it
out
of
kubernetes
originally,
and
so
our
whole
point
is
like
yeah:
you
can,
you
can
say:
node
affinity
doesn't
work,
but
why
would
you
even
want
to
mess
with
affinity
in
this
type
of
system,
you're
building
a
specialized
system
using
kubernetes?
And
this
is
a
building
block
that
allows
you
to
do
that.
So
if
there
are
other
examples
there
I'd
love
to
hear
about
them,
but-
and
we
can
talk
more
about
that-
seems.
L
H
Yeah
I
think
that
the
much
like
a
container
a
lot
of
the
backing
and
implementations
are
ephemeral
and
so
reproducing
that
you
can
run
the
same
thing,
but
you're,
never
gonna
have
things
that
are
persistent
after
your
container
or
pod
goes
away.
It
is
it's
a
different
way
of
looking
at
it.
Much
like
in
serverless,
for
example,
I
think
there
are
a
lot
of
parallels
there
you,
you
might
run.
You
know
a
lambda
function
in
Amazon,
but
being
able
to
run
it
again
and
reproduce.
H
H
H
Reproducibility
comes
out
a
little
bit
different
in
fundamentally
a
lot
of
this
stuff
that
we're
building
is
server
list
systems,
whatever
that
might
mean
to
you
and
so
a
lot
of
the
guarantees
of
an
old.
We
have
the
infrastructure
we
can
SSH
into
nodes.
Just
goes
away
fundamentally
and
that's
a
good
thing,
but
it's
a
new
working
yeah.
D
That's
that's
the
fundamental
premise
here
and
my
first
question
is
going
to
be
of
the
functionality
and
of
the
API
in
kubernetes,
which
parts
of
it
are
gonna
work
correctly
and
which
parts
of
it
should
I
either
not
use
or
I
need
to
relearn
how
they
use
because
they
work
differently.
I,
look
at
that
page
that
goes
up
on
the
screen
a
moment
ago.
It
doesn't
cover
any
of
that.
D
It
covers
a
bunch
of
as
your
container
service
features
that
are
or
are
not
accessible
through
this,
if
I
understood
correctly,
so
that
that's
the
fundamental
question
and
and
I
I'm
not
suggesting
that
the
answer
has
to
be
100%
of
kubernetes
works,
but
I
need
to
be
able
to
find
out
what
works
and
what
doesn't
work
and
I
don't
seem
to
have
a
way
of
doing
that.
Yet
the
conformance
tests
are
some
way
towards
that,
but
they
actually-
and
this
is
not
the
fault
of
this
project-
this
is
the
fault
of
the
conformance
test.
D
H
Sounds
like
to
me
that
you
yeah,
you
want
more
stringent
documentation,
but
without
so
exact
API
level.
Just
so
I
understand,
API
level,
documentation
of
what
features
don't
work
when
you
create
a
pod
when
you
create
a
daemon
set
or
when
you
create
a
specified,
node
affinity
or
something
like
that.
That.
D
D
We're
out
of
time
now,
so
we
I
think
we
might
have
to
do
some
offline
follow-up
here,
I
hope
and
yeah.
We
didn't
get
on
to
the
rest
of
the
agenda.
Unfortunately,
but
I
think
this
was
important.
Hopefully
it
was
educational
to
everybody
and
yeah.
Let's
perhaps
take
us
offline,
I,
don't
know
if
we
want
to.
Can
we
wait
two
weeks
before
we
continue
the
conversation
or
should
we
schedule
something
separate
from
the
next
meeting.
C
B
C
B
A
B
D
B
B
I
I
agree
with
that.
We
were
I
mean
we
were
doing
and
that's
why
we're
going
through
conformance
testing
right
now
pretty
adult
and
the
bigger
question.
True
and
that's
like
oh
I-
wanted
I
never
apply
in
that
thread.
But
the
bigger
question
for
me
was:
does
this
like?
Does
this
align
with
every
single
provider
and
how
is
this
gonna
be
useful
for
anybody
else
and
if
we
can
answer
those
questions,
I
am
100
like
I
am
happy
to
do
the
documentation
and
and
I'm
sure
it
will
be
useful.
B
D
My
mind
that
you
can
conceptually
create
a
table
where
you
know
down
the
left
hand.
Side
is
all
the
kubernetes
features
and
across
the
top,
is
all
the
existing
providers
and
then
and
say
these
providers
support
correctly
support
these
features
of
the
kubernetes
api
and
there
will
probably
be
huge
bands
across
that
table
where
none
of
the
providers
do
and
those
are
actually
cases.
B
C
G
D
C
Let
us
know,
let
us
I
mean
yeah
yeah
and
we
didn't
have
time
to
do
the
the
road
map
so
I
think
if
you
schedule
meeting
next
week
well,
you
might
be
able
to
talk
about
that
and,
if
not
then
we'll
talk
about
it
in
in
the
next.
You
know
today,
whatever
the
two
week
cadence
that
we
have
does
that
make
sense.
Yeah.