►
From YouTube: Kubernetes SIG Windows 20210803
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
All
right,
hello,
everybody
and
welcome
to
the
august
3rd
2021
iteration
of
sig
windows,
kubernetes
community
meeting.
As
always,
these
meetings
are
recorded
and
uploaded
to
youtube.
So
please
be
sure
to
adhere
to
the
cncf
code
of
conduct.
A
Okay,
get
started,
see
if
there's
some
more
intros.
I
see
a
couple
of
people
who
are
either
new
or
haven't
seen
in
a
while
on
the
call.
If
anybody
would
like
to
you
know
just
say:
hi
share
what
you're
working
on
or
anything,
please
go
ahead.
A
Not
we
can
go
into
the
announcements.
I
don't
really
see
anything
for
the
announcements
here
today.
1.22
should
be
releasing
this
week
like
tomorrow.
A
A
All
right
does
not
look
like
it,
so
we
can
go
right
into
the
agenda.
I
think
the
first
issue
was
something
that
a
follow-up
from
last
week
that
aravind
was
pretty
involved
in
so
maybe
I
will
skip
that
one
and
see
if
arvin
just
joins
a
little
bit
late
and.
A
Oh
okay,
so
yeah
we
can
go
over
this.
We
have
some
updates
from
the
microsoft
side
about
this.
A
So
for
everybody
who
is
new
to
this
issue,
I'll
try
to
summarize
what's
going
on
here,
but
if
anybody
has
more
like
can
do
a
better
job
feel
free
to
interrupt
me,
but
during
some
testing
our
event
and
other
folks
at
red
hat,
found
that
if
you
have
local
container
users
in
the
container,
if
you
have,
if
you
start
that
same
container,
you
target
that
local
container
user
in
two
separate
pods
that
those
two
container
user
containers
can
access
each
other's
projected
volumes,
which
is
not
how
it
suppose.
A
I
think
that
this
was
uncovered
by
some
changes
for
how
to
lock
down
the
projected
volume
tackles
on
linux,
and
the
question
was:
can
we
do
something
similar
on
windows
or
what
what
do
we
do
here
or,
and
so
there
was
some
investigations
that
were
happening
a
while
ago
kind
of
internal
to
microsoft,
to
see
what
we
could
do,
if,
if
anything
at
the
os
layer
or
if
we
needed
like
or
what
we
need
to
do
here,
brendan
or
muzz,
do
you
want
to
kind
of
summarize
things
or
should
I
go
ahead
and
share
what
the
findings
were.
C
Yeah,
I
could
help
summaries
so
yeah.
Basically,
you
know
and
when
you
know
like
the
the
disconnect
here
comes
from
just
the
differences
in
the
architecture
between
windows
and
linux,
and
you
know,
and
the
differences
between
file,
permissions
and
user
types
in
windows
and
linux.
C
So
the
suggestion
here
that
we
had
is
instead
of
assigning
specific
user
permissions
to
files,
or
you
know,
assigning
specific
user
permissions
like
we
were
like
what
is
being
done
in
linux.
C
The
code
running
in
the
container
should
assign
the
users
in
the
container
to
a
set
of
well-known
groups,
so
that
you
know
users
across
different
container
workloads
can
just
limit
access
based
on
these
well-known
groups.
It's
not
a
perfect
solution.
It's
just
kind
of
like
a
workaround
that
exists
and
works
today
to
actually
implement
a
full
feature.
Chair
full
change.
C
You
know
a
solution
that
works
for
in
the
same
way
that
linux
does.
It
would
require
kind
of
a
fundamental
change
to
the
way
windows
containers
work
in
general,
and
we
just
you
know,
need
to
continue
investigating
to
see
whether
or
not
that's
actually
worth
it
for
the
scenario
or
whether
or
not
the
workaround
works
for
people.
A
Yeah,
so
I
think,
following
up
on
last
week,
I
think
that
we
should.
I
think,
that
there
was
question
raised.
Should
we
update
docs
with
a
warning
just
describing
this
behavior,
and
I
think,
since
we
don't
have
a
kind
of
a
like,
definitive
way
of
fixing
this.
Yet
I
think
we
probably
should
update
the
docs
somewhere
to
to
update
this
and
also
follow
up.
I
think
also
in
our
kind
of
internal
investigations.
A
We,
like
anything
that
we
change
at
the
os
layer
will
probably
take
you
know
many
months
to
to
come
out
just
that's
just
the
nature
of
some
of
these
windows
server
issues
and
and
fixes
there.
There
may
be
things
that
we
can
do
in
the
cubelet
to
you
know,
manipulate
the
host
to
create
those
groups
and
and
wire
things
up.
We'll
continue
some
investigations
with
that,
but
for
for
now
I
think
this
is
probably
the
behavior
that
we
can
expect.
A
So
we
should
just
so
we're
going
to
want
to
document
this,
and
just
let
people
know.
C
Yeah,
I
think
the
answer
at
the
moment
is
definitely
documentation
yeah,
especially
while
we're
doing
the
investigation.
I
think
what
we're
going
to
be
doing
is
updating
some
of
the
msdn
pages
on
windows
containers
alongside
possibly
some
kubernetes
documentation.
A
I'll
fill
in
the
notes
after
that
yeah
does
anybody
have
any
questions
about
this
or
for
anybody
like
brendan.
D
A
So
I
think
at
least
the
plan
right
now
is
to
update
the
docs
to
say
more
or
less
what
you
just
said
said
hey.
If
you
have
windows
nodes
in
the
mix
this
may
you
you
may
see
this
behavior.
The
any
cubelet
changes,
I
think,
would
be
still
kind
of
exploratory
to
see.
If
we
can
harden
this
a
little
bit
by
having
the
cubelet
set
up
those
well-known
groups
on
on
the
host
machine
to
and
pass
that
information
along
to
the
container
start
to.
A
I
think
better,
solve
this
issue
or
solve
this
issue
more
akin
to
how
it
works
on
linux.
But
that's
that's
just
that
would
be
experimental
or
exploratory
work
right
now.
D
E
So
right
now
it
breaks
if
you
do
set
these,
because
it
does
the
c
mod
to
change
the
ownership.
Is
that
something
we
should
explore?
Removing
since
it's
a
current
limitation
so
that
folks
can
apply
usernames
or
do
we
want
to
leave
it
as
it
is,
and
then
do
this
exploration
to
see
if
we
can
solve
it
in
a
better
way.
A
I
don't
have
I
I
guess
I
don't
have
enough
data
to
see
what
or
to
make
a
decision
out
of
it.
Yet
I'm
curious,
I
guess
folks,
on
this
call,
are
how
often
are
people
running
with
run
as
username
with
local
container
users?
Is
this
something
that
functionality
that
people
kind
of
want
to
work
even
with
known
limitations?
Is
this
functionality
that
people
would
rather
see
blocked
because
of
this
potential
data
leak?
I
guess
I'll
leave
it
up
to
or
we'll
leave
it
up
to
some
discussion.
E
I
guess,
knowing
that
it's
a
limitation,
I
I
tend
towards
to
unblock
the
scenario,
but
I
would
want
to
get
like
auburn's
opinion
and
some
other
folks
who
have
also
run
into
this,
because
I
think
they
at
least
in
openshift.
They
seem
to
run
into
this
quite
a
bit.
B
Yeah,
I
can
talk
about
the
openshift
side
yeah,
so
what
we
had
to
do
was
implement
a
patch
to
skip
the
tone
if
it's
or
yeah
skip
the
tone
for
windows,
because
we
have
a
mission
controller,
that's
causing
these
bad
settings
to
occur
for
our
windows,
pods.
B
It
is
a
little
hacky,
so
yeah
yeah
it
was
a
hack
to
get
us
going
yeah.
I
can
follow
up
on
slack
with
that.
A
E
Maybe
we
should
do
some
exploratory
to
figure
out
if
we
can
do
use
this
user
group
kind
of
work
around
and
see
if
that's
a
feasible
option,
if
that's
a
feasible
option,
move
forward
with
that
to
unlock
and
then
because
I
think
that
would
be
the
better
path
forward
if
it
does
work.
Otherwise,
I
would
say
we
probably
want
to
just
remove
the
check
and
make
sure
it's
well
documented.
A
Oh,
my
machine's
being
kind
of
slow,
so
I'll
update
the
notes
afterwards
with
everything
we
just
css
all
right
anything
else
about
this,
or
should
we
move
on
to
the
next
agenda
topic?
A
Okay,
next
is
I
wanted
to
re,
bring
up
a
discussion
about
the
proposal
that
ravi
had
going
about
how
to
identify
windows
pods
for
during
the
api
server
admission
time
and
one
of
the
well.
This
is
a
work
in
progress
for
the
implementation,
or
this
is
the
issue.
Here's
the
where's,
the
draft
so
for
some
background
here
during
122,
the
replacement
for
pod
security
policy
went
into
alpha
and
at
the
time
there
was
a
an
open
question
about.
A
How
do
we
identify
windows
pods
so
that
we
can
add
windows,
specific
policies
and
also
prevents
linux
specific
policies
from
rejecting
windows
pods?
During
that
there
was
a
lot
during
those
discussions
there
was,
I
think
it
was
kind
of
deferred
to
segwindos,
to
figure
out
a
way
to
identify
the
windows.
Pods
and
ravi's
been
working
on
a
proposal
revolving
around
runtime
classes.
A
So
I've
been
following
this,
this
enhancement
proposal
and
it
seems
like
or
my
take
on
it
is
that
everybody
who's
involved
is
okay
with
runtime
classes,
thinks
that's
the
right
thing
right
way
forward.
The
questions
now
are
just
a
little
bit
about
specific
behaviors
and
actions
which
we
can
definitely
sort
out
kind
of
as
we're
doing
the
implementation,
especially
since
this
will
progress
through
the
feature
stages.
A
Does
anybody
have
any
I
wanted,
since
I
think
this
is
the
way
that
things
are
leaning,
I'd,
encourage
everybody
to
take
a
look
at
this
and
make
sure
that
this
will
work
for
everybody's
scenarios
or
not.
You
know,
break
or
block
any
critical
use
cases
here.
Ravi.
Do
you
have
anything
you
wanted
to
to
say
about
this
or
how
comments
about
how
this
is
going.
D
Yeah,
so
I
think
I
have
some
updates
that
I
need
to
give
about
this.
Jordan
has
been
reviewing
this
pr
like
last
week,
and
this
week
there
were
a
couple
of
points
that
he
brought
up
the
first
one,
and
both
of
them
are
like
sort
of
points
that
we
have
stressed
earlier.
D
One
is
related
to
blocking
the
users
from
creating
parts
which
just
have
node
selector
and
tolerations,
and
this
is
what
like,
I
was
thinking
initially
and
I
think
mark
james,
like
I
think,
argan
the
rest
of
the
folks
had
some
concerns
if
this
would
fly
well
with
the
the
community
and
jordan
brought
at
the
same
point.
D
So
one
thing
that
I'm
thinking
about
now
that
we
have
agreed
upon
saying
that
we
can
use
node
selector,
even
at
the
cubelet
level,
to
deny
the
admission
of
forms.
I
think
I'm
I'm
leaning
towards
having
that
backward
compatibility
in
place.
So
it's
it's
a
trade-off.
The
and
the
trade-off
is
between
breaking
users
versus
how
to
do
things
correctly,
in
the
sense
that
we
know
that
runtime
classes
can
be
created
only
by
admins,
and
they
only
have
privileges
to
add
the
node,
selectors
or
tolerations.
D
So
I
say
I
think
I
can
retract
on
that,
considering
that
most
of
the
people
are
are
already
using
the
node
selector
plus
run
plus
tolerations,
and
we
are
going
to
use
cubelet
to
reject
the
admission
instead
of
doing
it
at
the
container
runtime
level.
I
think
it
is.
It
is
sort
of
okay
unless
you
have
other
opinions.
D
That
is,
that
is
number
one
number
two
is:
how
are
we
going
to
deal
with
higher
level?
Workload?
Controllers
is
another
point.
The
jordan
brought
up,
so
the
runtime
classes
at
a
high
level
would
mutate
the
the
pod
objects
only
like
they
do
not
touch
the
the
higher
level
controllers.
D
For
example,
a
demon
set
or
a
deployment
controller,
which
has
a
port
template
the
runtime
class
admission
plugin,
which
actually
mutates
the
part,
is
not
going
to
work
on
those
higher
level,
controller
or
workload
objects.
So
jordan
has
given
a
scenario
where
this
could
fail.
D
So
since
the
runtime
class
admission,
plugin
is
not
going
to
touch
the
workload
templates
by
the
time
we
reach
the
pod
security
admission
plugin
while
validating
the
workload
part
template
would
not
have
those
node,
selectors
or
tolerations,
so
that
is
going
to
cause
a
problem
is
what
jordan
says.
I
have
given
couple
of
ways
through
which
we
can
solve
the
problem,
but
jordan
is
sort
of
not
convinced
using
both
the
approaches.
One
approach
that
I've
mentioned
is:
can
we
mutate?
D
D
The
second
part
is
having
the
pod
security
admission,
plugin
query
the
runtime
classes
and
then
see
if,
if
it
is
actually
if
the
workload
template
is
actually
using
a
windows,
runtime
class
or
not,
so
jordan
is
also
against
that
because
he
wants
to
keep
the
validating
admission,
plugin,
stateless,
so
meaning
he
does
not
want
any
other
object
to
be
used.
But
in
a
way
we
are
having
a
static
configuration
to
exclude
certain
runtime
classes
in
the
pod
security
admission
plugin.
D
So
I
do
not
know
if,
if
having
the
admission,
if
having
the
runtime
classes
queried
dynamically,
instead
of
having
the
static
configuration
is
going
to
be
that
back.
That
is
where
I'm
sort
of
having
discussion
with
jordan.
So
those
two
are
the
contention
points
and
I
believe
I'm
I'm
fine
with
the
the
the
first
one
where
we
are
going
to
where
we
are
still
going
to
allow
users
to
provide
tolerations
and
node
selector
and
cubed
rejecting
based
on
the
node
selector.
D
But
the
second
part
is
something
where
I
think
I'm
waiting
for
inputs
from
jordan
and
if
you
guys
have
any
inputs,
please
put
it
on
the
comments.
D
I
hope
I'm
clear
till
now.
If
not,
I
can
try
explaining
it
again.
A
Yeah,
the
one
one
thing
that
I've
been
thinking
of
this
whole
time
is
like
there
are
like
so
many
you
know,
pod
specs
or
even
like
sample
files
out
there
that
do
just
use
node
selectors
to
target
os.
So
I
think,
having
that
almost
like
fall
back
to,
I
was
still
allowed
with
dancing.
Tolerations
would
probably
be
good.
Like
you
mentioned,
it's
a
trade-off
between
you
know,
inconvenience
and
backwards
compatibility
versus
correctness
and
security.
So
I
think,
there's
always
a
balance
between
those,
but
I
think
I'd
be
okay
with
yeah.
D
Yeah
just
to
add
to
that
point,
I
think
this
also
gives
ground
stream
distributions
a
way
to
do
it
in
the
sense
that,
like
we
are
not
being
prescriptive
in
the
community,
but
if
the
downstream
distributions
would
still
like
to
use
the
node
selector
to
reject,
they
can
write
a
web
hook
or
something
to
be
much
more.
Prescriptive
is
what
I'm
thinking.
A
D
Yeah
like
ideally,
it
could
have
been
better
if,
if
you
can
reject
it
at
the
the
api
server
level
itself,
but
I
think
we
have
been
supporting
it.
So
I'm
fine
doing
that.
A
Yeah
and
then
for
the
for
the
second
point,
I
think
yeah
we're
going
to
just
want
to
keep
working
with
with
liggett
or
jordan
here
about
this
he's
kind
of
the
subject
matter
expert
for
a
lot
of
these
in
kubernetes
kind
of
writ
large,
and
then
I
personally
don't
have
much
experience
with
this.
So
anybody
from
red
hat
who's
already
experimented
with
all
of
this
is
probably
like
well
kind
of
just
use
your
learnings
to
do
what,
hopefully,
is
the
right
decision.
A
But
yes,
I
think
I
think
again
ever
this
is
this.
Is
this
can
be
quite
complicated,
so
I'll
ask
kind
of
anybody
who's
interested
to
take
a
look
comment,
see
all
the
comments
see
what
the
discussions
are
happening,
see
what
the
trade-offs
are
for
each
approach
here.
D
Yeah,
the
other
thing
that
I
will
also
do
is
I'll
set
up
a
meeting
like
say
if
we
cannot
reach
a
conclusion
in
the
on
the
github
vr,
I
think
I'll
set
up
a
meeting
with
jordan
and
sigoth
folks
and
then
invite
the
community.
If
anyone
is
interested,
please
please
feel
free
to
join
that
meeting
and
then
we
can
discuss
there.
A
Yeah,
I
thought
that
would
be
good
and
I
think
it
is
good
that
we're
that
this
was
started
when
it
was
started,
because
I
think
now,
folks,
like
jordan,
have
the
time
to
review
it.
Whereas
if
we
waited
a
couple
weeks,
I
could
see
this
kind
of
just
missing,
not
having
bandwidth
for
viewers.
So
thank
you
for
driving
this
early
robbie.
D
A
No,
I
think,
we'll
continue
to
discuss
this
at
the
next
couple
of
meetings
and
then,
like
you
mentioned,
it
would
might
be
good
to
just
say,
put
a
date
on
and
say
if
we
don't
have
consensus,
let's
set
up
another
breakout
meeting.
A
All
right,
jay,
I
think
yeah
next-
is
about
the
burrito
server.
F
Yeah
that
and
then
I
was
also
I
know-
friedrich
isn't
gonna,
make
it
and
I'm
pretty
heads
down
on
some
stuff
and
a
meme
is
here,
and
I
know
he's
heads
down
on
some
good
proxy
stuff,
so
I
was
thinking
probably
not
a
good
day
for
the
sig
windows,
pairing
stuff,
at
least
not
a
good
day
for
me
to
drive
it
really.
So
if
someone
else
wants
to
drive
it
or
if
we
want
to
cancel
today,
I
think
that
would
be
my.
F
F
So
you
know
when
you're
building
windows
nodes,
as
you
always
need
to
do
right
with
images,
because
you
can't
we
can't
redistribute
windows.
It's
we.
We
have
this
concept
of
putting
all
the
windows
binaries
into
http
servers,
so
that
image
builder
can
just
build
the
operating
system
image
easily
from
that.
F
So
we
do
this
downstream
and
we
talked
a
few
meetings
ago
about
doing
this
upstream
and
everyone
was
in
agreement
and
so
perry's
taken
our
hour
downstream
and
sort
of
made
an
upstream
friendly
version
of
it.
You
know
that
isn't
specific
to
vmware
or
anything,
so
I'm
pretty
happy
with
it.
F
I
haven't
tested
it,
but
I
was
just
talking
to
him
offline
and
asked
him
if
he
had
any
opinions,
because
I'm
not
sure
where
to
put
this-
and
I
feel
like
devtools-
would
be
a
good
place
to
carry
it,
but
I
don't
mind
putting
it
in
sig
windows
tools
either.
I
just
feel
like
sig
windows
tools
might
be
not
use
like
in
the
dev
tools.
F
We
could
probably
use
it
directly,
and
so
it
would
be
a
part
of
our
whole
automated
thing
and,
and
we
we're
probably
pretty
close
to
being
able
to
run
the
dev
tools
in
ci
as
well
now,
and
so
I
feel
like
that
might
be
a
more
natural
home
for
it.
But
I
I'm
okay
putting
this
in
sig
windows
tools.
F
F
Yeah
so
there's
a
first
pass
at
a
very
simple
http
server
in
image
builder
itself,
I
was
hesitant
james.
Let
me
know
if
this
is
a
good
idea
to
leave
it
an
image
builder
I
I'm
down
for
it.
I
just
feel
like
getting
something
like
this
with
as
much
code
as
it
is
into
image.
Builder
might
also
be
dumping,
something
in
there
that
we
aren't
100
sure
how
how
long
it's
going
to
live
there
and
all
that.
F
E
F
Like
we
don't
have
two
tabs
two
places,
so
we
should
you
know
it's
a
good
point.
It's
like
we
need
to
get
rid
of
the
one
in
image
builder
or
put
this
in
image
builder.
What
do
you
think
like
what?
What
does
any
would
it
does
anybody
care?
I
I
don't
have
a
strong
opinion,
I'm
just
trying
to
think
of
what's
what's
the
place
where
it's
gonna
be
the
most
natural
fit.
A
Advantage
of
sig
windows
tools,
even
though
this
is
small,
is
we
do
have
like
a
docker
hub
account,
set
up
and
have
ci
that
publishes
container
images
to
that.
G
A
F
F
D
I
F
Okay
yeah,
I
agree,
so
I
will
put
a
semaphore
issue
in
image
builder
right
now
that
says
move
you
know
graduate,
because
it's
in
the
hack
directory
right,
the
original
one
I
made
so
I'll,
make
a.
F
Yeah,
I
I,
I
think,
there's
a
tgik
episode
where
we,
where
we
used
image
builder,
live
and
showed
people
how
to
build
windows,
images
that
you
could
look
at.
That
would
the
other
example
the
the
whenever
you
run
image
builder
with
windows,
you,
you
kind
of
point
it
at
some
http
endpoints
and
right
now,
if
you
grep
around
in
the
code,
it
it
hard
codes,
those
endpoints
to
the
gcr
dot,
io
kubernetes
releases,
I
think,
and
so
kind
of
by
default,
it's
already
using
a
it's
all
using
already
using
a
burrito.
F
I
F
No,
the
only
difference
between
the
burrito
and
and
the
s3
is
what
you
just
mentioned
right,
which
is
that
s3
is
the
burrito
right.
I
mean
you,
don't
need
a
container
to
run
it
as
an
http
server,
because
because
gcr
is
an
http
server,
essentially
right,
so
the
burrito
basically
is
a
docker
container
and
the
docker
container
is
executable,
but
the
only
thing
it
does
is
serve
up
all
the
binaries.
I
I
mean
I
have
to
kind
of
talk
you
to
a
little
bit
for
what
we're
doing
for
our
k2
right.
I'm
sorry
by
the
way,
I'll
turn
this
camera
on
too
so
well,
we're
talking
about.
We
were
doing
4k
2..
We
ended
up
making
all
those
binaries
into
a
scratch
image
and
we
just
push
those
up
into
docker
and
I'm
just
proposing
why,
if
that's,
how
that's
working
with
the
linux
side
of
things
like?
Why
do
we
need
this
http
server?
I
E
So
so
image
builder
there's
a
couple
different
ways:
you
can
get
your
binaries
one
is
via
url,
so
you
just
say:
url,
here's,
here's
where
cubelet
lives
and
go
go,
make
a
query
and
download
it.
The
other
way
it
works
is
via
rpm
packages
for
linux
or
or
apt-get
or
whatever
it
is
your
distro
uses,
and
it
will
go,
do
the
same
thing
and
then
the
and
then
it
also
works
with
tar
images
for
some
of
the
containers
that
are
images
for
the
linux
side
for
windows.
E
There
aren't
images
for
a
lot
of
these
things,
so
we
basically
just
go
to
a
url
and
download
those
those
euro,
the
the
components
so
gcr,
you
know
dl
dot,
k8s,
dot,
download
and
you
download
the
cubelet
and
q
proxy
and
so
and
those
are
the
it's
hard.
E
The
default
is
to
just
go
to
dl.ks.io
and
download
those
components,
but
you
can
swap
in
you
know
your
own
url
path
that
you
want
for
that
for
those
things,
and
so
that's
that's
what
this
burrito
is
for
is
to
you
just
swap
out
that
url
and
it
will
go
and
get
them
from
your
own
components.
So
you
might
have
signed
versions
of
all
those
components.
F
We
then
share
that
file
into
the
kublet
into
the
windows
node
as
like
a
shared
file
using
vagrant,
and
that
makes
our
vagrant
developer
tools
much
more
coupled
to
vagrant
than
they
need
to
be
right
right
so
being
able
to
just
have
so
so
it
actually
supports
the
image
builder
use
case
that
james
talked
about,
which
is
where
a
vendor
wants
to,
but
it
also
supports
that
developer
use
case
also
where
we
want
to
be
able
to
like
people
without.
I
I
I
F
In
these
two
scenarios,
like
a
customer-
that's
running,
for
example,
a
kubernetes
product
like
from
day
one
and
they
haven't
ever
run
a
docker
container
before,
like
those
people
exist
right
and
it's
like
they
want
to
get
the
product
up
and
running,
and
the
first
thing
they
need
to
do
is
build
a
windows
ova
and
it's
like
you
know:
how
are
they
going
to
do
that
like
we?
Don't
have
a
we
haven't
solved
that
internally
here
at
you
know,
I
mean
like
we,
we
we
do
publish
things,
but
it's
like
you
know.
F
You've
got
customers
in
air-gapped
environments
and
not
every
customer
runs.
It
runs
a
registry
but
yeah
I
mean
for
the
happy
path,
you're
right
like
for
the
happy
path
and
image
builder,
just
download
from
gcr.io
right
like
who
cares
right,
but
it's
more
of
a
downstream
thing
that
it's
a
downstream
problem
that
that
a
lot
of
us
have
and
it
hits
air
gapped
customers.
But
it's
also
an
upstream
problem
for
developers
who
aren't
running
their
own
docker
registry
locally
or
anything.
We.
I
See
I
mean
all
every
air
gap
customer
has
their
own
registry
and
we
always
make
your
mirror
scripts
to
put
push
crap
in,
and
I
don't
know
I
just
have
never
seen
it,
but
we
also
have
an
arc
82.
We
also
do
we
have
runtime.
We
have
like
runtime
air
gap,
guitar
files
that
we
then
dumped
in
as
well.
I
don't
know
that
it's
also
a
lot
of
stuff
going
on
inside
of
that
project,
whatever
just
talking
it
out.
I
I
Going
into
a
new
structure
too,
you've
got
a
new
yaml
structure.
It
says
this
is
that
now
this
is
an
example
of
gamma.
This
is
how
you
do
it
when
we
just
did
the
same
thing
with
docker
files
and
we
just
had
run,
go
curl.
This
thing
put
it
in
and
be
done
with
it
right.
So
we,
I
don't
know
it's
six
one
way,
half
dozen
the
other,
but
it
just
seems
weird
that
whole
new
structure
people
already
understand
doctor
files
and
there's
already
registry
stuff.
That's
already
there.
F
A
I
wonder:
do
we
have
like
a
sig
windows,
devtools
version
of
the
burrito
like
I
could
see
what
luther
was
describing
and
just
having
like
a
container
image
that
has
everything
being
useful
for
sig
windows
tools,
that
image
builder
can
pull
from
for
kind
of
people
who
just
want
to
get
up
and
get
a
cluster
up
and
running,
but
maybe
the
sig
windows.
Dev
tools
is
where
it's
a
little
bit
different
and
you
can
point
it
at.
You
know
tip
of
tree
artifacts
for
everything
for
for
this,
but
I
would
see
it.
I
So
for
me
I
wouldn't,
if
I
was
going
to
build,
if
I
had
a
docker
registry,
then
I
was
we're.
Gonna
put
an
image
and
we're
gonna
put
it
up
there
into
say
some
cube
hub
account
and
that's
the
that's.
The
get
started
one
right
and
then
I'm
a
developer
and
I
wanna
make
my
own.
I
would
just
do
a.
I
would
just
do
a
luther
slash,
cube
image
whatever
burrito
and
I
would
push
my
own
and
then
I
would
just
point
to
that
right.
So
I
would
still
have
docker
available
to
me.
I
F
It's
actually
non-trivial
to
host
your
own
doctor
registry
inside
of
a
hypervisor.
When
you
don't
know
what
the
hypervisor
is
like,
it's
actually
harder
than
you
might
think
right
like
I,
you
know
we
tell
customers
to
run
their
own
harbor
registry.
I
mean
harbors
sort
of
was
supposed
to
be
the
solution
to
this.
Also
like
the
upstream
solution
to
this
also,
I
mean
I
think,
that
you're
going
to
move.
F
F
It's
feels
it's
it's
strange
to
me
that
there's
so
many
things
that
solve
this
part
of
this
problem,
but
there's
nothing
that
solves
the
whole
problem
in
the
way
that
we
need
it
solved
for
windows
like
it's,
it's
really
annoying,
but
but
if
you
actually
dig
into
it,
there's
actually
no
there's
actually
no
actual
solution
to
this
specific
problem.
That.
F
G
E
Yeah,
so
we
rebuild
everything
from
source
and
sign
it
all
and
then
host
post
them
on
a
url.
So
you
can.
You
can
go
download
this
cube
like
a
cubelet
binary,
that's
signed
by
microsoft.
It's
at
I've
read
the
exact
website,
but
yeah.
So
so
we
just
re-host
them
and
we
put
them
on
store.
It's
a
storage
account.
So
it's
basically
a
web
website.
It's
just
like
gcr.
We
basically
mirror
the
gcr
endpoints,
but
we
just
build
and
sign
everything
source.
A
Yeah
but
then
our
so
we
have
we
build
golden
images
for
the
vms
that
get
deployed
as
part
of
the
cluster,
and
then
we
do
cache
a
bunch
of
those
like
any
versions
that
are
still
supported
for,
like
the
different
components,
container
d.
You
know
the
kubernetes
binaries
and
everything
those
get
cached
on
the
golden
image.
So
then,
that
no
provisioning
it
pulls
it
out
of
there
and
clears
the
cache.
A
A
F
F
E
We
we
build
a
vhd
per
kubernetes
version,
and
so
then
those
versions
are
cached
on
the
vhd.
A
F
Yeah
one
way
that
we
use
ours
is
in
in
again
in
the
air
gap
scenario.
We
actually
run
image
builder
in
a
container,
so
we
take
image
builder.
We
run
it
in
a
pod
and
then
we
run
this
alongside
that
pod
so
that
the
image
builder
pod
can
directly
run
and
then
on
loopback
pull
down
the
bits
that
it
needs,
which
means
that
we
can
easily
patch
images
that
way
by
just
putting
a
new
binary
in
the
container
and
then
image
builder
will
directly
since
it's
running
in
a
container.
And
it's
writing.
F
F
On
on
our
own
on
our
end,
but
we
also
are
going
to
publish
windows
binaries
to
our
own
harbor
vmware
hardware,
registries
as
well,
so,
but
we're
still
for
ci
and
for
for
ci
and
for
for
air
grabbed
installations.
We
still
want
to
be
able
to
build
the
images
that
way.
F
D
I
think
it
also
helps
in
the
dev
cycle
right
so
like
say,
if
I
have
to
patch,
I
have
to
push
it
to
a
registry
and
then
download
it
and
then
use
it.
Instead,
I
can
just
update
the
the
patch
binds
you
put
it
in
the
http
server
and
then
use
it
to
be
served.
So
I
think
that's
like
these,
like
even
now
we
do
both
in
openshift
I
mean
not
for
not
for
windows
components,
but
some
of
them
some
of
the
core
control
plan,
components
which
are
linux,
containers.
D
It's
it's
so
easy,
so
much
easier
to
build
that
locally
and
then
test.
Those
changes
then
make
those
changes,
push
it
to
a
registry
and
then
use
docker
to
docker
or
another
runtime
to
test
those
changes.
So
that's
one
advantage
that
I
can
think
of.
F
D
D
The
windows
manifest-
let's
say:
if
you
have
a
windows
manifest
I
mean
for
us
all,
the
control
plane
components.
They
do
not
run
as
windows
containers,
so
the
all
the
windows
components
on
the
node.
They
do
not
run
as
containers
right.
So
it's
it's
sort
of
easier
but
safely.
If
we
go
to
the
privileged
container
support-
and
they
say
if
we
have
manifests
for
them
an
image
manifest,
not
every
container
is
responsible.
I.
I
See,
I
guess
let
me,
let's
just
show
you
for
context
on
what
our
use
case
is
yeah,
so
you
do
have
to
run
those
process
use
on
the
windows
host,
we're
pulling
them
down
in
a
burrito,
that's
an
image
and
then
we're
untarring,
those
executables
on
the
host
and
then
executing
them
right,
so
we're
using
we're,
basically
just
using
it
as
a
as
a
you
know,
target
gz
storage.
You
know
in
http
start
to
see
storage
so
correct.
Sorry,
I
just
want
to
be
clear.
I
I
F
Let
us
run
the
to
put
http
functionality
in
there
and
then
you
would
have
the
best
of
both
worlds
world,
but
the
image
pack
folks
said
they
didn't
want
to
do
that,
because
because
the
idea
would
be
that
you
could
yeah
like
pack,
everything
in
a
container
and
then
the
container
itself
has
an
end
point
and
then,
if
people
wanted
to
do
what
you're
doing,
which
is
just
pull
the
thing
down,
unzip
it
and
copy
a
file,
they
could
do
it,
but
they
could
also
just
serve
it
on
an
http
endpoint,
but
the
only
open
source
tool
that
is
really
sort
of
ideal.
G
G
E
Yeah
yeah,
I
think
this
is
you
know.
How
do
you
distribute
your
binaries
and
every
vendor
is
going
to
maybe
have
a
different
solution.
The
most
basic
is
via
an
http
server,
and
then
I
think
this
particularly
involves
like,
if
you're,
using
an
http
server
on
the
baseline
and
you're
doing
it
in
an
offline
mode
or
a
gear
gap
scenario.
This
this
is
enables
you
to
get
up
really
quickly,
but
you
could
potentially
solve
it
with
other
solutions,
kind
of
the
way
that
jamie
and
ross
have
proposed
as
well.
F
Yeah,
I
mean,
I
think
it
sounds
like
okay,
so,
but
notwithstanding
that
it
sounds
like
folks
are
okay
with
it
being
in
tools
and
don't
really
think
it's
a
good
fit
for
dev
tools.
I
I
kind
of
agree
with
that,
so
I'm
just
gonna,
I
put
a
semaphore
in
there
to
to
close
the
right
now.
It
lives
in
image
builder.
So
I
put
a
semi4
in
there
to
kill
that
off
and
once
once
we
move
it
over.
F
And
are
folks,
okay
with
skipping
the
pairing
today
or
does
somebody
else
want
to
lead
it.
F
Ameem
is
joining
the
windows
effort
by
the
way
he's
worked
a
lot
in
cig
network
stuff
with
us
and
so
just
wanted
to
introduce
a
meme
to
everybody
and,
let
folks
know
he's
working
on
hardening
the
calico
stuff
in
the
dev
environments
and
yesterday
I
pushed
up
a
change
to
split
the
calico
note
installation
into
two
phases,
and
I've
talked
to
the
calico
folks
and
they're
willing
to
take
that
upstream.
F
So,
if
somebody's
looking
for
a
quick
pr
to
get
involved
with
calico
windows
upstream
on
the
calico
front,
feel
free
to
reach
out
to
me
and
I'll
point
you
all
at
the
issue
or
I'll
just
put
the
issue
in
slack
right
now.