►
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: Windows SIG - Michael Michael, VMware & Patrick Lang, Microsoft
The chairs for SIG-Windows will provide an update on the efforts to bring Windows to Kubernetes and talk about our future roadmap. At the end we will have a Q&A session centered on requests by the community.
To learn more: https://sched.co/Irku
A
So
this
is
not
a
traditional
conference
talk,
so
we
wanted
to
kind
of
provide
an
update
to
what
our
special
interest
group
is
working
on
and
then,
after
that
update,
we
want
to
talk
to
you
guys
and
understand
the
scenarios
that
you
guys
want
to
bring
to
windows.
Some
of
the
use
cases
figure
out
how
many
of
you
guys
are
running
containers
in
production
windows.
A
What
your
roadmap
is
going
to
look
like
as
well
as
give
you
an
opportunity
to
make
asks
to
the
community
as
well,
as
you
know,
come
back
and
ask
you
guys
to
come
and
get
involved
come
and
help
us
test.
This
write
some
features
or
write
documentation,
so
we're
a
fairly
small
sig
compared
to
every
other
sig
in
the
kubernetes
community.
So
the
more
people
that
come
and
join
us,
the
more
customer
voice
that
we
have
there.
A
A
So
so,
let's
get
started
here,
like
I
mentioned
to
do
a
few
community
effort
updates
kind
of
make
you
guys
aware
of
the
progress
we've
made
and
where
we
are
today
and
then
we'll
move
on
to
a
discussion
in
q
a
so
starting
in
early
2016.
We
kind
of
formed
the
sig
with
a
singular
effort
to
be
around
bringing
windows,
server
and
windows
server
containers
into
kubernetes.
A
When
we
formed
the
zig,
aprenda
and
red
hat
were
the
the
first
contributors
and
we
kind
of
took
it
all
the
way
to
alpha
in
december
of
16
here
in
seattle
actually,
and
that
was
basically
think
of
this
as
a
proof
of
concept
that
was
that
was
there
to
kind
of
rally.
The
troops
show
what
was
possible
and
we
were
able
to
bring
a
lot
more
folks
from
the
community
to
come
and
join
us
so
that
we
could
continue
towards
our
beta.
A
That
was
a
year
later
in
december
of
17
and
with
the
beta
we
had
true
capabilities
on
windows
with
kubernetes,
so
you
could
have
storage,
you
could
have
networking
and
we
had
a
couple
of
cni
plugins
like
ovn
and
ovs
that
were
already
working,
and
then
we
also
had
a
lot
more
feature-rich
capabilities
from
the
container
subsystem
that
microsoft
was
providing
with
docker.
So
you
guys
could
start
testing
your
workloads
start
bringing
applications
into
windows
and
making
that
possible
to
test
and
then
fast
forward
to
one
year
later
and
where
we
are
today.
A
B
Okay,
there
we
go
yeah
and
so
so,
basically
like
over
the
last
year,
microsoft
has
put
out
two
different:
what
they're
calling
semi-annual
channel
releases
of
windows
server,
but
that
what
we
were
doing
was
working
with
the
community
to
find
the
areas
where
windows
was
lacking,
and
we
need
to
do
things
like
improve
the
storage
and
networking
support.
And
so
we
did
that,
basically
in
concert
with
a
few
different
kubernetes
releases.
So
if
you
look
at,
I
think
it
was
built
either
1.9
or
1.10.
B
Well,
we
had
to
make
changes
to
the
os,
and
then
you
got
those
lined
up
with
the
kubernetes
releases,
and
so
you
know
all
those
changes
really
kind
of
came
together
in
our
first
long-term
release,
which
is
windows
server
2019,
which
is
what
we're
recommending
as
like
the
viable
platform
for
this
stuff
going
forward
and
there's
still
more
more
improvements
happening
to
work
better
with
some
of
the
different
network.
Plug-Ins
like
the
stuff
around
calico
and
flannel.
Do
you
have
that
on
the
next
slide?
B
People
are
putting
things
together
on
linux
and
we
need
to
figure
out
what
the
right
set
is:
that's
going
to
work
best
between
the
windows
and
the
links
environment,
because
you
know,
as
we
already
mentioned,
the
goal
is
not
to
you
know,
replace
linux
or
something.
The
goal
is
to
have
an
environment
that
really
lets.
You
run
all
your
apps
in
one
place,
so.
A
A
So
when
the
1.13
release
train
was
going
on,
our
initial
ambition
was
to
go
stable
with
1.13
due
to
a
variety
of
reasons.
Some
of
it
is
testing
stability.
We
had
to
port
a
lot
of
our
testing
infrastructure
to
to
the
kubernetes
ci
engine.
We
just
didn't
make
the
cut,
so
our
current
plant
release
is
with
1.14
in
march
of
2019..
A
Now
that's
not
a
done
deal.
There's
still
some
risk
in
us
getting
ga
at
that
release,
which
is
why
we're
asking
you
know
more
folks
of
you
guys
to
come
and
join
us
that
way,
we'll
make
that
increase
the
likelihood
of
that
happening.
So
what's
some
of
the
committed
work
that
we
have
so
our
first
and
foremost
commitment
is
that
you'll
be
able
to
put
windows
server
nodes
into
kubernetes
and
you'll,
be
able
to
schedule
windows
server
containers?
A
A
Hyper-V
isolation
is
still
in
alpha,
so
we're
strictly
talking
about
windows
server
containers.
If
you
want
to
use
hyper-v
isolated
containers,
you
have
a
limitation
of
one
container
per
pod
and
it's
still
in
alpha.
So
you
know
be
aware:
if
you're,
if
you're,
trying
that
scenario
on
the
networking
side,
flannel,
host
gateway
and
vxlan
will
be
available
by
that
target,
time
frame,
ovn
and
ovs
will
be
available
as
well
as
wind
bridge
and
wind
overlay.
A
Those
are
kind
of
the
the
new
generation
of
the
wind
cni
and
where
that
effort
has
transitioned
to
and
then
you'll
be
able
to
do
layer,
three
networking
using
top
of
rack
switches.
So
that's
our
committed
work.
This
is
where
we
have
members
of
the
siege
that
have
committed
in
doing
some
of
this
work.
A
Some
of
the
work
that's
still
under
design
right
now,
but
haven't
really
committed
resources
include
the
group
managed
service
accounts
if
you
guys
are
not
familiar
with
the
feature.
That
is
the
ability
to
provide
an
identity
for
a
container
running
on
docker
and
windows,
so
that
that
container
can
access
external
resources
like
a
file,
share
or
a
database
and
have
an
identity
that
can
be
authenticated
and
authorized
against,
and
then
hybrid
cluster
support.
That
kind
of
has
a
couple
of
different
items
under
it.
A
A
So
we're
that's
kind
of
a
new
thing:
that's
coming
into
the
kubernetes
community
and
we're
working
with
the
team
to
ensure
that
if
you
have
a
workload,
that's
either
windows
or
linux,
you
don't
need
to
go
and
put
all
the
magic
sauce
inside
your
pot
specifications
and
your
yaml
files
to
kind
of
indicate
where
your
workload
needs
to
land.
There
has
to
be
some
smartness
in
the
cluster
that
can
identify
hey.
This
is
a
windows,
workload
landing
on
a
windows.
A
A
So,
post
ga-
and
you
know
we
mentioned
1.15
plus
there-
there
is
no
real
target
time
frame
because
these
are
so
far
out,
but
some
of
the
things
that
were
we're
going
to
work
on
is
microsoft
has
been
putting
a
lot
of
investments
around
the
cri
and
container
the
implementation,
and
that's
something
that
we
want
to
see.
Light
up
for
for
windows.
A
The
hybrid
v,
isolated
containers
is
something
that
we
definitely
want
to
bring
out
to
to
stable
and
ga
release
as
well,
and
we
have
a
ton
of
partners
and
cus
and
customers
are
interested
in
both
caligo
and
other
storage
and
network
providers
and
we're
working
with
them
to
to
release
those
on
kubernetes
as
well
and
the
last
is
you
know,
demon
sets
so,
as
you
guys
are
familiar,
there's
no
privilege
mode
on
windows.
So
a
lot
of
the
demon
sets
are
out
there.
A
B
But
tomorrow
we're
actually
meeting
with
the
conformance
working
group
specifically
around
defining
what
basically,
how
we're
going
to
test
and
communicate
windows
support,
because
it's
something
that's
going
to
be
optional.
Not
all
customers
are
going
to
use
it,
but
we
want
to
make
sure
that
the
conformance
testing
still
sort
of
validates
the
quality
of
your
kubernetes
deployment
overall
and
then
they're,
probably
going
to
add
another
profile
that
says
and
here's
windows
as
an
additional
feature.
B
So
that
way
you
can
make
sure
that
it's
working
well,
regardless
of
what
cloud
you're
going
to
run
it
on
and
so
we're
basically
trying
to
get
that
right,
baseline
of
tests
set-
and
this
is
something
that's
relatively-
I
mean
this.
This
is
a
new,
a
new
development
for
kubernetes
conformance.
So
there's
going
to
be
a
lot
of
that.
That's
going
to
be
where
we're,
where
personally,
I'm
spending
most
most
of
my
time
over
the
next
couple
months.
Getting
that
done,
because
that
way
we
can
make
sure
that
you've
got
the
quality.
A
Yeah,
so
if
we
were
to
look
at
our
priorities,
number
one
priority
is
getting
all
our
tests
and
all
the
investments
we've
already
made
to
be
super
stable.
So
a
lot
of
the
new
development
needs
to
take
backseat
to
getting
everything
stable
without
stability
and
passing
all
the
tests.
You
know
we
can't
really
release
so.
A
So
the
last
few
slides
here
so
give
you
guys
an
update
on
flannel,
because
I
know
a
lot
of
you
guys
are
interested
in
that.
So
you
know
when
we're
looking
at
it
from
a
production
standpoint.
Most
of
you
guys
have
given
us
feedback
that
you
know
you
want
a
cni,
that's
going
to
be
supported
both
on
windows
as
well
as
linux,
and
something
that
you're
already
working
with
and
flannel
seems
to
be
the
obvious
choice
that
we
heard
from
you
guys
so
host
gateway,
supporting
flannel
for
windows
just
got
released
a
few
days
ago.
A
So
that's
out
there
it
is.
It
is
working.
You
can
go
ahead
and
start
testing
it,
and
we
have
a
few.
A
few
partners
like
rancher
that
already
released
support
for
this
with
windows,
server
containers
on
the
vxlan
front.
That
work
is
underway.
The
team
is
working
on
the
validation
and
the
last
few
things
are
needed
before
they
start.
You
know
doing
their
end-to-end
testing
and
and
the
goal
there
is
to
merge
the
prs
sometime
in
the
middle
of
the
first
quarter
or
next
year.
A
So
if
you're
looking
at
the
timeline,
when
we
go
ga,
we
will
have
flannel
both
vxlan
and
host
gateway
supported.
Now
there
are
some
updates
to
windows,
server,
1903
they're,
going
to
make
flannel
better.
There
are
some
bugs
that
we've
encountered
around
leaking
endpoints
and
dns
propagation
and
some
scalability
items
around
the
subnet
config.
The
team
is
aware
of
those,
and
microsoft
is
doing
a
great
job
of
educating
us
on
every
step
of
the
way.
What
they're
working
on
so
a
lot
of
these
are
going
to
be
updated
in
1903.
A
Now
we
understand
that
server
19
is
the
long-term
servicing
release,
and
a
lot
of
you
guys
might
want
to
adopt
that.
So
microsoft
is
going
to
work
on
backboarding
some
of
these
bugs
and
features
back
into
19.
No,
that's
not
a
committed
thing,
but
you
know
they're.
You
know
we're
working
with
them
and
making
sure
that
the
long-term
service
in
branch
of
windows
has
all
the
updates
that
are
necessary
for
you
guys
to
be
able
to
run
production
level
workloads
with
flannel.
B
Okay,
yeah,
so
so
for
those
of
you
that
haven't
tried
deploying
anything
yet
on
windows.
One
thing
that
I
wanted
to
mention
was
sort
of
a
couple
of
the
the
things
around
the
the
experience
of
actually
deploying
things.
So
yesterday
I
had
an
entire
session
that
that
we've
got
a
there'll,
be
a
recording
available
for
and
then
I'll,
probably
also
post.
B
B
Scheduler
and
all
and
all
those
typical
pods
there
you're
still
going
to
have
the
windows
nodes
there
that
are
running
there,
and
so,
when
you're
deploying
stuff
today
you
want
to
be
sure
to
use
node
selectors,
which
let
you
pick
what
operating
system
a
deployment's
going
to
going
to
run
on,
because
if
you
try
to
deploy
something
like
you
know,
your
ingress
controller
using
nginx,
which
is
using
a
linux
container
and
it
inadvertently
gets
scheduled
on
a
windows
node.
Well,
that's
not
going
to
work
and
vice
versa.
B
That
might
you
know,
go
from
one
node
to
another,
as
things
fail
over
the
taint
would
prevent
the
linux
applications
from
accidentally
showing
up
on
the
windows
node,
but
the
tank
can
can
prevent
that
and
then
so,
when
you
go
and
deploy
your
windows
application,
you
just
put
a
node
selector
and
a
toleration
in
there,
and
then
it
will
still
run
on
windows.
Just
fine,
but
that's
a
way
that
you
can.
You
know,
sort
of
segment
the
workloads
out
and
make
sure
they
run
on
the
right
os.
A
B
Now.
You've
got
a
whole
lot
of
load
over
on
this
controller,
that's
going
to
have
to
make
calls
over
the
network
over
to
your
container
registry
to
find
out.
Is
this
a
windows
or
linux
image
there,
and
so
these
are
the
sorts
of
things
where
it's
like.
If
this
is
you
know
something
that
you
want
to
help
with,
you
know
we
would.
We
would
love
to
have
any
help.
That's
there,
because
that's
not
a
windows
development
project.
B
I
know
that
I've
seen
some
templates
that
people
have
used
on
linux
have
really
low
memory
limits
of
via,
like
one
or
two
hundred
megs,
that's
not
going
to
work
on
windows
just
to
start
a
container
you're
going
to
need
at
least
300,
and
it's
not
that
300
megs
are
going
to
all
be
in
active
use.
It's
that
the
windows
services.
B
B
And
what
and
that's
given
you
you
the
benefit
of
well,
you
know
most
applications
aren't
going
to
crash
if
you
change
your
kernel
version,
but
unfortunately
nobody
on
the
in
in
the
windows
team
had
had
had
designed
that
early
on
and
so
the
user
mode
applications
need
to
be
able
to
run
on
the
same
kernel
that
they
were
built
on.
So
if
you
build
your
container
on
a
windows,
server,
2019
machine,
it
needs
to
run
on
a
windows,
server,
2019
machine
and,
if
you're,
using
an
older
version
like
1709
or
1803
the
same.
B
The
same
is
true,
and
so
that's
why
the
hyper-v
isolation
is
going
to
be
so
important
for
us
to
finish,
because
that's
going
to
allow
you
to
update
your
windows
notes
first,
but
then
it
will
just
bring
up
the
kernel
for
the
container
that
needs
it
at
that
older
version.
So
that's
going
to
give
you
that
backwards
compatibility.
So
you
can
move
the
windows
notes
forward,
even
if
your
apps
haven't
been
rebuilt
in
containers,
yet.
A
A
B
A
Cool
all
right,
so
we
can
move
into
some
q
a
but
right
before
we
start
that
I
just
want
to
get
a
quick
survey
out,
so
how
many
of
you
guys
are
running
windows
containers
in
production
today,
irrespective
of
what's
your
orchestrator
any
of
you
guys,
someone
all
right
how
about
pre-production
or,
like
you
know,
testing
and
validating
okay,
I
love
you
guys
how
many
of
you
guys
are
using
kubernetes
to
win
those
containers
in
the
in
that
same
ecosystem,
a
few
guys
so
awesome.
I
would
love
to
actually
see
you
guys
in
the
segas.
A
D
B
So
so
the
question
was:
which
features?
Can
you
use
inside
the
containers
and
then
image
downloading
speeds
and
the
image
download
speeds?
Okay,
yeah?
So
one
of
the
things
we
did
for
the
image
download
speeds
is,
if
you
look
at
the
containers
that
microsoft
is
publishing
for
windows,
server
2019
and
later
we
actually
moved
them
onto
another
service.
B
B
If
you
look
at
the
windows,
server
2016
and
like
extract
it
with
tar,
there
were
actually
duplicate
files
in
there,
and
that
was
because
the
way
that
the
file
system
layout
worked,
it
couldn't
do
sim
links
on
the
fly
as
it
was
extracting
it.
We
fixed
that
in
half
the
image
size
in
windows
server,
I
think
it
was
1709
or
1803,
and
then
we
trimmed
out
even
more
files
that
were
not
needed
for
server
2019,
and
so
I
think
the
download
over
the
last
couple
years
has
gone
from
something
like
five
gigs
down
to.
B
What
are
we
at
one
point?
One
point:
six
gigs
and
so
we're
continuing
to
to
move
that
down.
Further,
nano
server
is
a
lot
smaller,
but
of
course
it's
because
everything's
been
ripped
out
a
lot
of
the
apis
that
you're
used
to
may
not
work
their
nano
server,
and
so
I
think,
we'll
be
able
to
get
a
little
bit
more,
but
in
terms
of
the
download,
the
download
and
on
disk
size
for
like
server
core,
I
think
it's
probably
not
going
to
be
another
like
order.
Magnitude
drop,
we're
going
to
be
seeing.
A
And
there's
a
couple
of
other
points
on
that,
so,
if
you're
using
a
public
cloud
provider,
obviously
with
their
own
registries,
then
you
know
the
locality
there
will
help
if
you
guys
have
heard
the
announcements
hardboard.
The
registry
is
now
a
cncf
project,
so
we'll
be
working
with
them
to
make
sure
that
the
window
support
is
is
is
top
notch.
C
B
B
C
B
Yeah,
so
that
one
was
added
in
windows:
server,
2019,
it's
more
like
what's
in
the
windows,
10
client,
and
so
I've
talked
to
some
people
that
are
doing
things
like
game
servers
where
they
need
a
little
bit
of
directx
apis.
You
know,
they're,
not
you
know
doing
full
gpu
rendering,
but
they
may
need
to
calculate
some
3d
meshes
and
things
like
that
and
that
that
can
work
in
that
new
windows
image
that's
available,
and
is
that
something
that's
at
preview?
Or
is
that
at
production
right
now,
which
one.
B
Okay
yeah,
so
I
think
that
one
went
out
with
server
2019
as
well.
Yeah
yeah,
it's
in
the
same
container
registries,
but
that
has
a
little
bit
more
capability.
So,
if
you're
looking
at
things
where
you
need
to
be
able
to
use
more
of
the
windows,
directx
or
other
rendering
apis
to
do
things
like
document
conversion,
that's
what
that
image
is
really
tailored
for.
E
B
G
G
G
G
G
So
so,
if
we
wanted
to
deploy
flannel
with
vxlan
on
one
side,
we
can
have
easily
with
cnip
plugin
and
demon
set.
We
can
deploy
that
on
the
linux
nodes,
but
on
windows,
it's
quite
more
complicated.
What's
the
best
approach
to
that
with
the
lack
of
support
with
demon
set,
are
we
supposed
to
bake
that
in
the
image
or
post
provisioning
scripts
or
whatever
to.
B
Yeah
I
mean,
I
think
we're
so
I
mean
the
general
approach.
Is
that
you're?
You
still
need
to
have
a
configuration
management
system
on
the
windows
notes
and
whether
you're
doing
that
with
something
like
powershell,
dsc
or
ansible,
or
or
whatever,
whatever
tools
you
want
out
there
or
if
you're,
just
rebuilding
images
and
redeploying
them
with
terraform,
I
mean
in
all
those
cases,
you're
still
you're
going
to
need
to
be
able
to
install
your
container
runtime.
B
B
As
far
as
demon
sets
go,
I
I
don't.
I
don't
see
that
working
on
windows,
it's
not
a
committed
feature
on
the
roadmap
for
daemon
sets
with
privileged
support.
So
if
you
just
need
something
running
on
every
node
like
let's
say
you
wanted
to
set
up
like
a
local
caching
server
or
something
that
would
work
fine,
because
it
doesn't
need
privilege,
but
as
far
as
actually
you
know
being
able
to
to
use
containers
as
a
distribution
mechanism
for
things
that
need
full
privilege
to
the
host.
G
Okay,
so
last
quick
question:
we
were
talking
about
speeding
up
the
download
of
the
images
with
cdn
caches
and
everything
or
a
local
decor
registry.
Actually,
I
think
that
there's
like
some
requirement
right
now
with
the
base
image
from
windows
to
be
hosted
on
the
on
the
host
microsoft
servers
like
the
server
core
that
we
cannot
cache
locally.
No.
B
B
B
Server
core
adds
a
whole
bunch
of
software
to
it
and
then,
when
they
go
and
push
to
another
registry,
they
have
to
upload
all
the
server
core
images,
because
now
all
of
a
sudden
they've
got
a
you
know
a
three
gig
upload
instead
of
just
uploading,
the
delta,
which
may
only
be
a
few
hundred
megs,
and
so
that
that's
why
we've
got
those
separated
out
as
foreign
layers.
So
that
way
they
actually
go
back
to
that
cdn.
If
you
need
to
push
to
a
private
repository
in
your
environment,
you
can
do
that.
There's.
B
I
can't
remember
if
it's
a
client
or
if
it's
a
docker
config
flag,
but
you
could
set
that
and
then
you
can
override
and
push
it
into
your
private
registry.
So
if
you've,
if
you've
got
something
like
docker,
docker
trusted
registry
or
harbor
or
or
likely
key,
then
you
then
you
should
be
able
to
push
to
that
and
use
that
in
your
environment
and
that's
perfectly
fine.
We
just
try
to
block
that
behavior
by
default,
because
we
don't
want
people
basically
breaking
the
tree
and
always
downloading
everything.
D
D
H
One
thing
we
have
tried
is
like
be
able
to
configure
a
daemon
set
and
then
have
a
very
small
sort
of
a
host
privilege
proxy
that
you
bring
up.
You
know,
through
your
host
configuration
mechanism
to
to
have
the
demon
set
container,
basically
delegate
some
of
the
privileged
operations
to
this
host
process
proxy.
Do
you
guys
or
does
anyone
have
a
comment
on
why
that
may
not
work
or
things
that
would
break.
B
A
B
H
A
I
mean
that
there's
also
other
things
that
you
know
smart
things
that
could
happen
right.
For
example,
envoy
containers
sidecars
could
be
there
and
do
an
authorized
call.
You
know
maybe
using
certificate
based
and
authentication
to
a
process.
That's
running
on
the
host
and
you'll
be
able
to
get
host
privileges.
A
That
way,
so
there's
a
lot
of
things
that
someone
could
do
to
kind
of
delegate
that
access
to
something
else
we
just
haven't
had
time
to
explore
them
by
the
way
deep
has
signed
up
very
recently
to
help
us
on
the
managed
service
accounts
work.
So
if
you
guys
are
interested
in
that,
you
know
we're
putting
him
on
the
hook
for
that
all
right.
So
one
last
question
and
then
we'll
go
outside.
C
This
last
question
is
so
building
on
the
hyper-v
isolation.
Do
you
guys
see
a
future
for
alcohol
linux
containers
on
windows,
so
the
use
case
scenario
is
sort
of
similar
to
azure
notebooks
and
be
able
to
run
sort
of
both
linux
and
windows.
Containers
on
windows,
host
leveraging,
hyper-v
isolation
and
using
kubernetes
to
orchestrate
all
that.
B
I
mean
I
think,
it's
something
that
that
would
be
technically
possible,
but
we
would
need
to
be
very
careful
about
how
we
approach
it,
because,
right
now
the
scheduler
and
kubernetes
is
designed.
Where
you
know
each
node
can
run
only
one
thing,
and
you
know
so
the
common
idea
of
like
well,
you
know:
can
this
node
run
both
you
know
amd
64
and
arm
64
code
like
technically.
Somebody
could
do
that
today
with
qmu,
but
it's
not
something
that
the
scheduler
is
designed
to
do
and
so
running.
B
Multiple
os's
on
the
same
host
is
something
where
it's
like,
even
though
the
container
run
times
underneath
may
be
able
to
do
it.
We
would
need
to
work
very
closely
across
a
lot
of
groups
like
sig
architecture
and
sig
node,
to
figure
out.
You
know
how
you
would
want
to
enable
that
scenario,
just
because
it's
not
something
that
it's
not
something
that
we
could
do
just
within
the
scope
of
one
sig.
B
It's
something
where
you
need
to
build
an
engineering
consensus
across
lots
of
groups
and
convince
them
that
that
it's
the
right
thing
to
do
and
given
that
most
most
people
are
working
with
cloud
providers
that
make
it
very
easy
to
add
and
remove
nodes.
Then
I
would,
I
would
think
that
they
would
be.
It
wouldn't
be
their
top
priority.