►
Description
- MS/Azure Rep? Craig Peters leaving.
- GCP - Patching vendor for CCM.
Use /third_party, like k/k does
Backport to k/k, pin dependency to a certain commit (hash version)
- Please get 1.23 KEPs in early
Need alpha version of webhook server KEP.
kubelet credential provider to Beta
controller manager migration updates?
Overloaded KEP review with requests coming late. Deadline is ________
- GCE-PD Volumes and in-tree Tests (@jpbetz, @mattcary, @leiyiz)
Need to make sure that test signal is reported back into k/k
Need to integrate and test cloud-provider-gcp against k/k at sufficiently high frequency, and with sufficient automation
A
A
B
B
A
B
Awesome,
I
don't
remember
the
name,
but
I
do
seem
to
remember.
There
was
one
person
who
responded
to
craig's
email
from
microsoft,
saying
that
they
would
be
willing
to
do
some
step
up
and
then,
in
the
last
full
full
cloud
provider
meeting
we
did
have.
I
think
a
product
manager
from
microsoft
show
up
and
actually
agree
to
take
a
bunch
of
the
tickets
and
appropriately
distribute
them
among
microsoft.
C
Yeah,
we
do,
I
think,
have
a
pretty
insane
approach
to
this.
We
just
needed
we
needed
to
get
a
change
in
that
was
in
kubernetes,
and
it
turns
out
that
now
that
122
is
out,
we
can
just
do
the
bump
to
122,
and
this
just
works
out
naturally
using
a
pretty
straightforward
approach.
So
we
don't
have
to
do
anything
anything
odd.
B
A
A
B
Or
something
for
one
time,
I
think
that
would
be
valuable,
but
I
think
we
should
also
be
spending
some
time
thinking
about
what
we
believe
the
graduation.
The
ga
graduation
criteria
should
be,
I
think,
to
date,
all
of
the
testing
on
controller
manager.
Migration
has
been
manual
testing
by
either
google
or
amazon.
A
C
A
D
D
Volume
type
in
order
to
do
this,
though,
you
have
to
install
the
pdcsi
driver
in
your
cluster
and
that's
not
something
that
people
want
to
do
in
upstream
kubernetes,
so
instead
we're
going
to
install
it
in
the
cube
up
inside
of
cloud
provider.
Gcp.
Okay,
great,
like
that
all
sounds
good.
The
wrinkle,
though,
is
it
turns
out.
There
are
hidden
load-bearing
uses
of
gcepd
or
in
for
particular
tests
to
assume
you
have
a
default
storage
class
and
a
cloud
provisioner.
D
The
most
notable
is
there's
a
stateful
set
test
so
like
these
are
tests
that
are
not
in
storage
and
they
aren't
pegged
you
know
as
a
gce
pd
test.
So
our
our
plan
is
actually
to
remove
those
tests
from
the
kind
of
mainline
end-to-end
tests
that
are
runners,
part
of
kubernetes
and
run
those
out
of
the
cloud
provider
gcp.
D
B
B
D
B
B
B
C
Yeah,
so
just
just
to
kind
of
echo
back
what
I
heard
everybody's
saying
so
we've
got
these
tests
in
kkk
in
kk
that
either
intentionally
or
unintentionally
depend
on
cloud
fire
specific
stuff.
So
those
tests
are
going
to
have
to
be
turned
off.
When
we
turn
off
the
cloud
provider
specific
stuff
in
kkk
that'll
make
sense
we're
instead
we're
going
to
have
to
run
those.
We
don't
want
to
lose
that
test
signal
entirely
and
that's
where
this
gets
really
interesting.
C
So
what
we
want
to
do
is
turn
those
tests
on
in
cloud
provider
gcp,
but
of
course
those
aren't
going
to
be
blocking
for
any
changes
in
kk
anymore.
So
you
know
the
code
that
actually
could
cause
a
breakage
will
now
not
get
a
pre-submit
check
on
kk
itself
right
if
you
change
stateful
set
in
some
breaking
way,
you're
not
going
to
find
out
later
until
cloud
provider,
gcp
picks
up
that
version
of
kk.
That
has
the
breaking
change
and
then
detects
it
yeah.
C
So
I
think
that's
we
are
doing
the
kind
of
what
we're
doing
in
cloud
provider.
Gcp
right
now
is
trying
to
improve
our
testing
so
that
we're
aggressively
checking.
You
know
the
latest
changes
in
kubernetes
and
seeing
if,
if
there's
anything
breaking
there,
when
we
integrate
it
with
quadratic
gcp,
that's
kind
of
a
somewhat
ortho
orthogonal
project
to
this
like
when
that
comes
online,
then
we
would
get
that
signal
would
get
at
least
communicated
more
aggressively
into
the
cloud
provider
gcp
team.
C
D
Yeah
I
mean
I
can't
argue
with
that.
Of
course,
I'm
concerned
that,
like,
if
I
mean
you
know
if
this
is
like
a
bunch
of
grungy
stuff,
that's
like
always
traditionally
very
hard
to
actually
get
done
and
get
consensus
on.
I
mean
I
think
the
main
thing
is
like
we
really
need
to
get
this
on
by
default
in
123..
We
originally
wanted
all
by
default
in
121.
D
D
So
yeah
I
mean
I
agree
with
you,
but
I
guess
this
means
like
if
this
will
have
some
urgency
to
try
and
figure
out
by
trying
to
get
consensus.
On
that
I
mean
my
plan
is
still
to
turn
migration
on
by
default,
and
then
the
breaking
test
will
give
us
incentive
to
fix
things
like
if
we
wait
for
there
to
be
like
consensus
on.
D
B
B
So,
as
in
yeah
a
couple
examples,
one
we
can
leave
the
tests
running
in
the
old
state,
so
we
get
some
coverage
in
kkk,
even
if
we
have
to
set
some
some
sort
of
turn
off
some
some
some
normally
you
know
ga
fla
ga
feature
flags
or
whatever
it
takes
to
get
the
old
behavior,
and
then
we
can
enable
those
tests
in
in
gcp
work
towards
getting
them
all.
Passing
then,
once
we're
all
passing,
we
may
want
to
do
something.
Like
I
don't
know
even
fork.
B
I
mean
basically
set
create
a
release,
a
release
of
the
gtp
repo,
and
then
we
may
even
I
mean
as
ugly
as
this
is,
and
I
hate
the
sound
of
it.
We
may
even
just
on
the
what
I'll
call
the
main
line
or
f
or
or
or
rapid
branch
we
might
even
manually
fold
in
the
features
while
we
try
and
get
the
stuff
joe's
working
on
done.
But
I'm
just
saying
like
I
think
the
first
thing
is
understanding
their
policy,
then
working
out
how
we
can
minimize
the
cost
of
that
policy.
C
D
Yeah,
yes,
so
there's
not.
We
have
I
we
kind
of
briefly
looked
through
it's,
I.
I
don't
think
it's
actually
huge
like,
as
I
said,
there's
a
couple
of
staple
sets
ones
there's.
You
know
obviously
a
bunch
in
storage,
but
I
think
that's,
okay,
because
that's
sort
of
known
to
be
off,
I
mean
yeah,
so
I
guess
so
I
don't
don't
think
we're
going
to
solve
this
here
is
to
meet
the
the
good
person
to
start
to
with
this.