►
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Intro: Cloud Provider SIG - Chris Hoge, OpenStack & Jago Macleod, Google
The long-term goal of SIG Cloud Provider is to promote a vendor-neutral ecosystem for our community. New vendors providing support for Kubernetes should feel equally empowered to do so as any of today’s existing cloud providers. More importantly, SIG Cloud Provider is focused on ensuring a consistent and high-quality user experience across providers. The SIG acts as a central group for developing the Kubernetes project in a way that ensures all providers share common privileges and responsibilities. This Intro session will go over historical context, status, and direction of efforts currently underway. We will discuss documentation and code organization and offer an opportunity for participants to offer feedback and ask questions. We will also cover the support for all cloud providers to submit test results to testgrid, the shared infrastructure for recording and visualizing test results. Finally, we will cover the next steps and roadmap for the transition of in-tree cloud providers to external repositories.
To learn more: https://sched.co/HEhb
A
A
So
today
we're
gonna
go
through
a
little
history
and
background
there
there's
a
deep
dive
tomorrow
afternoon
or
we'll
go
into
more
detail
on
some
of
this
and
drill
into
some
of
the
more
complicated
bits.
So
if
we
skip
over
some
things,
rest
assured
tomorrow
late
morning,
there
is
another
cloud
provider
related
talk,
so
we're
gonna
go
over
what
code?
What
is
the
ownership
domain
of
the
sig
cloud
provider?
A
Some
of
the
sub
projects
and
working
groups,
governance
as
a
general
topic
and
I
think
we
decided
to
ditch
the
challenges
because
that
wasn't
fun
to
talk
about
on
Wednesday.
So
maybe
we'll
talk
about
challenges
tomorrow
and
have
some
question
time
so
way
back
in
2016,
we
found
ourselves
in
a
place
where
fast
movement
build
everything
into
kubernetes
kubernetes.
A
So
it
was
certainly
a
reasonable
place
to
start.
However,
as
more
cloud
providers
got
interested
in
also
wanted
to
be
in
the
kubernetes
kubernetes
repository,
it
became
clear
that
this
was
not
a
sustainable
direction
for
the
codebase
and
so,
as
happens
often
in
our
community.
Someone
makes
a
comment
in
a
github,
PR
or
unrelated
way
down
in
some
comment
thread
and
suddenly
that
comment
way
down
in
a
comment
thread
becomes
a
group
of
people
and
that
group
of
people
grows,
and
then
it
becomes
a
cig.
A
A
This
concept
of
the
cloud
provider
itself
being
down
there
somewhere
close
by,
was
baked
into
multiple
different
components
in
kubernetes.
So
cubelet
would
talk
through
to
storage,
for
example,
in
a
fairly
direct
way,
and
so
extracting
that
and
providing
that
interface
for
external
cloud
providers
becomes
kind
of
a
challenge.
A
How
do
you
improve
on
this,
and
so
fundamentally,
this
effort
began
as
a
an
attempt
to
consolidate
the
place
to
which
those
components
requiring
underlying
infrastructure
would
speak
into
a
single
cloud
controller
manager
that
has
all
the
cloud
provider
specific
junk
in
it,
and
this
provides
benefits
as
well
as
opening
the
door
to
growing
codebase
or
growing
support
for
cloud
providers.
The
release
Cadence's
then
freed
up
and
decoupled.
A
B
One
thing
that
you'll
notice
is
that
there's
a
little
bit
of
a
call-out
on
the
volume
controllers
here
and
that's
because,
as
we
continue
to
do,
work
as
the
community
continues
to
do,
work
on
OSI,
the
OSI
interface
and
drivers,
for
that
more
of
those
roles
are
going
to
fall
into
that.
And
so
you
know
those
those
functions
will
be
taken
over
by
the
by
the
CSI
drivers.
B
And
so
returning
to
the
situation
that
we
had
before.
We
have
all
of
these
clouds
that
want
to
participate
in
kubernetes
and
and
are
in
some
ways
integrated
into
the
kubernetes
codebase
and
with
the
cloud
controller
manager.
Each
one
of
these
can
be
separated
out,
they
can
be
encapsulated
and
they
can
all
be
standalone.
B
B
On
top
of
all
this,
one
of
the
major
goals
is
to
remove
all
of
the
existing
cloud
providers
from
community
/
kubernetes,
which
winds
up
being
a
very
big
task
for
a
number
of
reasons.
Some
of
them
are
related
to
the
code.
There's
some
providers
is
very
deeply
entwined
and
you
have
to
find
all
of
the
spaces
where
they
touch
inside
and
that
and
discover
how
you
can
break
break
those
dependencies
and
turn
then
and
and
handle
those
through
the
clear
interfaces.
But
there
are
also
social
aspects
to
that
yeah.
B
You
know,
as
many
providers
have
built
services
and
products
on
this,
and
there
has
to
be
a
migration
path
for
their
technology
and
for
the
customers
to
be
able
to
move
from
an
internal
provider
that
just
shipped
with
kubernetes
to
an
external
provider.
That's
going
to
require
these
these
these
providers
to
upgrade
their
kubernetes
clusters.
B
B
For
starters,
you
wind
up
with
a
cleaner
release
changelog
for
kubernetes
the
release.
Log
isn't
filled
with
lots
of
comments
about
particular
providers
that
you
know
may
not
be
of
interest
to
the
majority
of
users.
A
second
of
all,
is
you
only
need
to
install
what
you
need
and
so
you're
not
carrying
around
the
weight
of
every
other
provider
in
the
ecosystem?
Instead,
you're
only
concerned
about
what
you're
going
to
run
on
your
cloud
him.
B
Finally,
one
of
the
most
important
things
that
you
have
is
from
these
smaller
binary
sizes.
You
get
security
cloud
providers,
don't
have
to
include
thousands
to.
You
know
hundreds
of
thousands
of
lines
of
code
that
they
never
review
and
they
never
need
and
and
could
introduce
security
vulnerabilities.
So
this
is
a
you
know.
Overall,
the
work
that
we're
doing
is
bringing
a
lot
of
a
lot
of
benefits
to
the
community
at
large
and
for
all
of
the
users
to.
B
So
from
this
we
out
of
this
working
group,
we
grew
a
new
SiC
called
sig
cloud
provider,
and
so
this
sig
maintains
the
cloud
provider
interface,
and
so
this
is
the
the
code
that
the
sig
owns
for
the
benefit
of
the
community
at
large.
It's
also
maintaining
the
overall
architecture
for
the
cloud
providers
in
the
ecosystem.
It
owns
the
cloud
controller
manager
and,
in
some
ways,
owns
the
cloud
specific
controllers
too.
B
What
how
they
should
be
interacting
and
reporting
test
results
and
providing
documentation
and
maintaining
coding
standards
so
that
so
that
the
providers
don't
benefit,
but
their
users
benefit
also,
plus
it's
an
entry
point
for
for
other
SIG's
within
our
community
to
collaborate
on
all
sorts
of
cloud
provider
interests,
and
so
how
do
we
build
and
maintain
Doc's?
How
do
we
have
a
cluster
management
in
a
in
a
consistent
way?
How
do
we,
the
build-out,
testing,
infrastructure
and
reporting
on
that
testing
infrastructure.
A
So
we
talked
about
some
of
the
benefits.
One
area
that
we
got
early
feedback
on
was
that
building
an
external
cloud
provider
gave
you
didn't
get
the
benefits
of
being
in
the
kubernetes
or
all
the
automation
and
fada
bots
cannot
help
you
out
there.
Everyone
loves
fada
bots,
so
we
went
through
the
process
of
defining
what
are
the
requirements
for
getting
a
repository
in
the
kubernetes
organization,
and
essentially
it
boils
down
to
a
few
things.
A
One
is
just
some
indication
that
someone
is
using
your
cloud
provider,
some
user
experience
reports
some
indication
that
there's
traffic-
it's
not
just
two
people
in
a
basement
with
some
raspberry
PI's
and
have
an
explosion
of
50
million
cloud
providers.
Maybe
that's
a
different
kind
of
success,
but
it
wasn't
the
success
we
were
looking
for
at
the
time
in
the
first
round.
A
The
second
is
test
grid
integration,
and
this
is
super
cool.
This
is
both
a
requirement,
but
also
a
benefit
and
what's
interesting
about
it.
Is
that
the
our
good
friends
in
cig
testing
built
some
functionality
for
cloud
providers
to
run
conformance
tests
with
our
own
infrastructure
and
post
the
results
back
to
a
GCS
bucket,
which
is
consumed
by
test
grid
and
visualized
and
the
benefit
here?
A
Is
you
both
get
early
warning
that
someone
else
did
something
and
worked
your
distribution
of
kubernetes
or
that,
if
you're
being
a
good
citizen,
you
are
paying
attention
and
making
sure
that
your
changes
don't
work,
someone
else,
but
also
the
cig
as
a
whole?
We
can
keep
track
of
if
all
cloud
providers
go
wonky.
We
that
gives
us
one
signal.
A
If
only
one
goes
wonky,
it
gives
us
another
and
if
all
but
one
go
wonky,
then
that's
probably
the
third
kind
of
message
we
can
get,
which
is
just
providing
the
consistency
and
quality
signal
across
these
now,
even
more
distributed
groups
of
engineers
focusing
in
different
areas.
So
that's
super
exciting.
That
was
great.
Work
by
cig
testing
super
appreciative
of
that.
A
The
third
requirement
was
just
the
conformance
of
your
provider
that
it
passes
the
conformance
test.
It's
a
certified
distribution
of
kubernetes
and
there's
some
leeway
for
negotiation
here.
If
you
are
on
the
path
to
that
and
you
need
the
repository
to
get
to
there.
So
we
are
aware
of
this
chicken
and
the
egg
problem
and
totally
reasonable
humans
on
the
other
side
of
that
conversation.
A
So
if
you're
in
that
situation,
please
reach
out
and
we
can
work
through
it
and
then
documentation-
and
this
is
really
one
of
the
focus
areas
of
the
sig-
has
been
consistency
of
experience
across
these
providers.
And
it's
really
focused
on
the
end
user
and
this
portability
across
providers
is
really
critical
to
the
long-term
success
of
kubernetes
and
so
having
the
ability
to
discover
how
to
and
get
started
on.
A
A
provider
is
really
important,
that
that
be
a
consistent
experience
for
end
users,
regardless
of
what
the
platform
is,
and
this
is
really
important
both
to
for
the
community
to
avoid
lock-in
into
a
single
provider,
but
also
for
providers
to
avoid
lock
out.
If
your
installation
of
kubernetes
is
drastically
different
than
others,
then
you
may
likely
be
locking
out
potential
customers.
A
So
it's
important
in
both
directions
and
this
idea
of
consistency
of
user
experience
is
really
one
of
the
founding
principles
that
keeps
our
our
discussions
and
our
investments
on
track
and,
finally,
that
the
tech
leads
are
members
of
the
kubernetes
organization.
That
hasn't
been
a
problem.
Yet,
oh,
this
is
the
test
group.
This
is
a
screenshot
of
how
lovely
it
is
when
all
of
the
tests
are
passing.
I
will
note
that
I
cut
off
a
red
line
at
the
end
there
in
the
screenshot,
so
it
was
there.
It
does
provide
valuable
feedback
when
something
breaks.
A
It
is
useful
to
know
that
that's
there
and
test
health
is
super
important
to
understand
that
a
a
test
failure
is
actually
meaningful,
so
please
continue
to
invest
in
fixing
tests
when
they
go
wrong.
That
is
the
foundation
of
a
lot
of
the
velocity
that
we
can
continue
in
the
project
and
it's
worth
noting
that
this
is
actually
the
cloud
provider
OpenStack
and
so
Chris
and
colleagues
at
OpenStack
were
some
of
the
were
the
first
adopter
of
this
framework.
A
So
they
paid
the
Pioneer
tax
for
all
of
us
right
and
that
was
worked
by
DIMMs
and
that's
a
shout
out
to
dhimmis
for
that.
But
the
the
benefit
to
them
is
that
they
can
now
iterate
in
their
own
cloud
provider
and
they're
starting
to
deprecate
or
have
deprecated
their
entry
cloud
provider,
because
the
benefits
outweigh
the
cost
of
this
transition.
So
it
is
real.
The
benefits
we're
talking
about
are
real
and
code
ownership.
We're
gonna
go
through
this
fairly
quickly,
but
this
is
the
structure
of
the
code
that
is
owned
by
the
cig.
A
So
there
is
a
cloud
provider
directory
in
github
and
then
there
are
specific
cloud
providers
as
well
and
there
are
specific
owners
for
each
of
those.
So
there
were
some
concerns
early
on
that
enterprises
would
have
their
own
legal
requirements
on
where
this
code
would
live
and
if
it's
in
an
internal
or
an
external
repo,
there
are
options
there.
But
at
this
point,
I
think
all
of
the
cloud
providers
have
elected
to
have
this
repository
in
the
kubernetes
repository
yeah.
It's
not
it's.
B
Not
a
requirement
that
the
code
live
in
this
repository,
it's
more
of
a
benefit
that
you
gain
when
you
meet
those
requirements
that
we
laid
out
earlier
in
the
talk
and
you
and
a
provider
has
demonstrated
a
willingness
to
be
engaged
and
active
in
the
community
for
the
you
know,
for
the
benefit
of
the
larger
community.
You
know
this
is
something
that
we
offer
them
to.
You
know
help
their
users,
users
discover
where
the
code
is
and
to
help
their
developers
to
you
know
remain
in
within
the
kubernetes
development
ecosystem
and.
A
So
this
consistency
message
again
consistency
of
discoverability
documentation
and
there
is
a
revamp
of
some
super
janky
page
on
the
kubernetes
documentation
about
how
to
get
started
that
has
grown.
Who
knows
how
over
many
years
and
the
way
that
participation
in
that
page,
landing
page
to
give
initial
instructions
to
end
users
will
be
based
on
this
consistent
documentation.
So
so
right
back
to
some
projects
and
working
groups
there.
These
are
some
areas
of
focus
of
the
cig
and
if
you
are
interested
in
these
areas,
I
would
encourage
you
to
come
to
our
meeting.
A
So
one
is
this
cloud
provider
extraction
sub
project.
This
has
specific
leads
for
this
sub
project.
Both
Walter
and
Nishi
are
in
the
room
here:
chef,
taco
and
Nishi
D
for
those
of
you
who
only
go
by
github
animals
that
Nishi
d-
yes,
the
Nietzsche,
sorry
and
so
they're
here,
if
you're
interested
in
this
specific
project
reach
out
to
them-
and
this
has
become
super
complicated
as
Chris
alluded
to,
because
everything
is
moving
all
at
the
same
time.
A
So,
as
we
were
embarking
on
this,
these
storage
folks
were
working
on
their
own
efforts
to
decouple
various
layers
and
the
CSI
there.
There
are
all
these
C
star
eye
initiatives
of
containers,
something
interface,
and
so
this
is
the
storage
interface,
and
so
there
were
some
dependencies
and
some
collaboration
that
needed
to
happen
there,
and
so
the
effort
here
is
to
get
rid
of
everything
in
this
package
cloud
provider
in
kubernetes,
kubernetes
repository
and
move
it
to
the
top
level
cloud
provider
and
then
the
corresponding
cloud
provider.
A
Specific
repositories
sounds
simple,
turns
out
in
practice:
it's
actually
very
challenging
to
migrate,
installed
user
bases,
but
that
is
all
working
towards
this
removal
of
hundreds
of
thousands
of
lines
of
code
double
points
for
removing
code
this
year.
Other
areas
of
investment
are
there.
This
is
a
a
place
to
discuss
the
cross
cloud
implications
of
efforts
like
long-term
supports
in
kubernetes.
What
does
that
mean
across
different
cloud
providers?
Every
cloud
provider
has
concepts
of
LTS
every
OS
like
their.
A
A
Looking
for
stability,
I
feel
pretty
strongly
that
LTS
is
a
dangerous
path
to
go
without
really
thinking
it
all
the
way
through
to
the
end
of
what
happens
at
the
end
of
the
LTS
support
level,
you
either
migrate
or
fast
forward
through
lots
of
upgrades
or
something,
but
it's
not
enough
to
just
punt
it
to
that
moment
and
end
up
in
the
Python
2.7
and
3
dot
X
world.
So
we
need
to
have
those
conversations
and
they
need
to
have
representation
from
all
of
these
various
club
providers
and
how
it
fits
into
those
worlds.
A
Another
example
is
the
behavior
of
load
balancers,
the
behavior
of
VMs
and
the
states
that
they
can
have
in
different
cloud
providers
and
coming
up
with
consistent
ways
to
reason
about
those.
So
those
are
the
kinds
of
conversations
that
come
up
in
here,
the
other
one.
That's
really
interesting
is,
as
we
move
into
world
where
kubernetes
is
broken
down
into
more
and
smaller
components.
We
don't
move
to
no
problems.
A
We
move
to
new
and
different
problems
of
coordinated
upgrades
and
where
you
don't
have
a
single
tar
ball
that
can
be
extracted
on
any
cloud
provider
and
work.
We
have
to
provide
some
tooling
or
at
least
expectation
management
for
customers.
Where
do
they
find
the
other
pieces
that
they
need
or
DNS
is
a
different
CN
CF
project
is
now
the
default
DNS
solution
in
kubernetes.
B
What
we've
found
is
that
a
cig,
pert
cloud
provider
is
not
sustainable,
that
as
we
have
more
cloud
providers
wanting
to
enter
the
ecosystem,
there's
an
explosion
of
SIG's
and
we
could
very
easily
reach
a
point
where
the
number
of
cloud
provider
SIG's
is
larger
than
all
of
the
other
SIG's
that
aren't
cloud
providers,
and
so
one
of
the
intentions,
one
of
the
one
of
the
goals
in
the
Charter
of
this
of
cig
cloud
provider
was
twofold:
the
ownership
of
all
the
cloud
providers
under
one
sig.
This
is
still
a
work
in
progress.
B
B
You
know
we
would
have
to
find
some
way
to
have
a
smooth
or
engaged
migration,
and
but
it
presents
a
number
of
challenges
too,
because
we
have
a
lot
of
existing
cloud.
Sig's
and
they're
serving
a
purpose
not
only
for
maintaining
these
cloud
providers,
but
also
for
working
on
other
projects
like
cluster
lifecycle
and
providing
support
for
their
users
and
for
introducing
advanced
features
and
documentation
for
for
things
that
they
want
to
do.
And.
B
You
know
at
you
know
not
only
within
the
kubernetes
community
when
in
the
development,
but
also
at
events
like
this
we're
gonna
be
talking
more
about
that
tomorrow.
During
the
this
is
one
of
the
topics
of
the
deep
dive,
and
so
if
this
is
something
that
you're
interested
in,
we
encourage
you
to
come
tomorrow,
and
you
can
read
more
about
this
idea
of
sub
projects
in
this
community
issue.
B
Okay,
so
it's
time
to
wrap
it
up
and
see
what's
next,
and
so
we
are
we're,
we
were
close
to
the
end
of
the
talk.
So
how
can
you
get
involved?
We
have
we
have
bi-weekly
sig
cloud
provider
meetings.
These
are
at
1:00
p.m.
every
other,
Wednesday
I'm,
expecting
that
with
the
with
cube
con
and
then
the
holiday
coming
up
that
we
probably
won't
be
meeting
again
until
January
9th
is
what
it
looked
like
on
the
calendar.
B
We
need
help
still
with
the
code
migration
from
kubernetes
kubernetes
to
the
staging
repo.
This
is
really
the
big
development
item
that
we're
working
on
right
now
and
the
more
hens
we
have
on
this,
the
faster
it's
going
to
go
and
the
faster
we
can
start
moving
all
of
these
cloud
providers
out
of
entry.
B
You
know
completing
this
work
and
moving
on
to
new
and
other
interesting
problems
that
we
face.
We
have
a
slack
channel
its
cig
cloud
provider.
We
are
in
the
process
right
now
of
improving
documentation.
One
of
the
meetings
we
had
at
the
developer
conference
earlier
this
week
was
exactly
around
this
issue
and
we're
expecting
more
direct
collaboration
with
cig
docs
in
2019,
with
with
tasks
that
we're
going
to
show
up
with
to
to
achieve
during
the
development
cycle.
B
So,
tomorrow
we're
gonna
have
the
cig
cloud
provider.
Oh,
and
the
other
way
that
you
can
get
involved
too,
is
with
the
cloud
for
the
cloud
provider
extraction
we
also
have
or
those
we
have
bi-weekly
meetings
for
that
also
I
think
they're
their
weekly
meetings
on
Thursday
Thursdays
in
1
p.m.
Pacific
time
mm-hmm.
B
So
tomorrow
we
have
the
sink
cloud
provider
deep
dive.
This
is
going
to
be
in
at
10:50
in
room
3.
A/B
topics
will
include
cloud
top
excluded
everything
you
see
up
here,
the
cloud
abstractions,
what
the
various
cloud
controllers
actually
do:
the
migration
of
KCM
to
CCM
in
production
clusters.
This
is
actually
an
important
problem
to
solve
for
a
lot
of
the
providers
migrating
from
kubernetes
to
the
cloud
provider
addressing
technical
depth
as
well
as
talking
about
the
governance
updates
and
changes
for
provider
SIG's.
B
And
and
in
the
audience
is
Andrew
psych
him,
Andrew
and
and
Jago
were
the
the
the
kind
of
the
two
people
who
really
pushed
to
to
really
drive
the
creation
of
the
cig
and
I
want
to
call
out
Walter
Andy
she
too,
for
the
for
the
leadership
on
the
extraction
process.
You
know
that
their
work
has
been
invaluable
and
it's
been
really
fantastic,
working
with
all
of
them.
Wow.
A
C
B
D
A
E
D
One
of
the
advantage
is
that
that
brings
us
is
this:
KCM
has
a
nice
feature,
which
is
a
common
interface
on
what
a
controller
looks
like
so
that
you
can
just
add
controllers
as
long
as
they
meet
the
controller
interface.
So
once
we
get
the
CCM
up
to
that
point,
it
should
be
much
easier
to
add
things
like
an
a
lot
of
scaler
controller
to
the
CCM
and
also
to
be
able
to
do
things
like
use
the
controllers
flag
to
control
which
of
the
controllers.
You
happen
to
be
running
on
this
cluster.
A
D
D
But
for
Google
we
use
the
same
cloud
provider,
interface
or
implementation
of
the
interface
in
house
for
gke,
that
is
used
by
the
customers
that
do
kubernetes
on
GCE
right
or
on
GCP,
where
they're
running
they're
out
that
having
been
said,
there
are
a
few
things
we
do
throw
in,
we
GK
is
Phipps
certified,
and
so
it
has
nothing
to
do
with
the
cloud
provider
code.
But
we
do
add
a
special
version
of
one
of
the
libraries
that
has
been
Phipps
qualified.
E
The
interface
is
common,
just
like
Walter
said,
and
even
for
Amazon
we'd
probably
have
the
same
implementation
on
AWS
cops
for
a
cloud
provider
versus
eks.
The
difference
is
the
controllers
that
we
currently
have
out
of
tree
is
slightly
different,
so
like
we
do
have
node
controllers
and
service
controllers
for
load
balancers,
but
how
the
node
controller
works
on
gke
or
GCE
is
different
from
how
it
works
on
Amazon,
eks
or
AWS.
It's
because
how
we
discover
nodes
and
then
we
don't
have
a
route
controller.
E
Yet
in
the
out
of
tree
CCM,
which
is
already
implemented
in
Google
and
frankly,
OpenStack
has
many
other
controllers,
but
I
think
the
idea
is
the
same.
That
as
we
take
the
out
of
tree
code
out
of
tree
CCM
out,
the
controllers
will
kind
of
look
the
same,
but
we
will
add
very
specific
cloud
provider
controllers
into
the
code
base,
and
then
we
run
it
as
a
you
know:
a
daemon
set
or
an
API
object
on
the
master
node,
which
is
also
the
same
way
of
running
it,
but
the
controllers
are
different.
Does
that
and.
B
You
should
expect
to
see
the
code
that's
in
tree
to
not
really
be
worked
on
any
more
more
maintained
until
it's
actually
removed,
and
so
the
external
providers
are
going
to
they've
often
started
from
the
same
code,
but
now
they're
drifting
away,
and
you
know
becoming
more
advanced,
more
refined,
which
is
what
you
would
expect
and
was
actually
what
you
want.
You
want
to
find.
You
want
to
encourage
your
users
to
leave
the
entry
code.
C
A
There
are
no
specific
cloud
provider
conformance
tests,
and
one
of
the
goals
of
the
conformance
test
program
is
to
test
the
interface
and
not
the
implementations,
so
that's
kind
of
an
important
distinction
in
layering,
so
it
shouldn't
shouldn't
make
any
difference
and
me
she
has
a
follow-up
I.
Think.
E
We
discussed
this
in
the
dinner
yesterday.
We
did
start
to
look
at
all
the
tests
available
and
it's
just
so
big
that
it's
crazy
to
figure
out
what
tests
would
make
sense.
So
we've
been
working
on
it
as
a
joint
group
and
I
think
one
of
your
customers
has
worked
on
some
integration
testing
we'd
love
to
see
the
scope
of
those
tests,
because
then
we
can
start
from
there.
Yeah.