►
Description
Plans for finishing the working group, PR Review, KEPs
A
Hi
welcome
to
the
january
13th
2022
sig
cloud
provider,
cloud
provider,
extraction
working
group
meeting.
As
always,
these
meetings
are
intended
to
be
inclusive,
polite
and
considerate
of
all
one's
fellow
contributors.
So
you
know,
please
do
so.
We
we
follow
all
of
the
standard
rules
of
the
cncf
kubernetes
as
regards
to
behavior.
So
with
that,
let's
go
ahead
and
get
started.
El
mico.
I
believe
you
have
two
prs
that
you
need
reviewed,
one
of
which
is
on
me.
So
I
apologize.
A
B
B
A
A
A
So
we
had
a
long
discussion
about
six
months
ago
and
with
six
storage
and
came
to
the
conclusion
that
the
way
we
wanted
to
move
forward
on
this
was
to
find
an
easy
way
to
allow
cloud
providers
to
have
web
hook
a
standardized
web
hook
to
deal
with
this.
So
I
went
ahead
and
I
wrote
a
cap
that
basically
described
how
we
could
extend
the
ccm
to
be
able
to
run
web
hooks,
and
let
me
be
really
clear
because
there
was
a
little
bit
of
contention
on
this.
A
A
So
I
know
we've
had
multiple
people
who
thought
they
were
going
to
be
able
to
but
life
intruded,
and
it
hasn't
happened
at
this
point.
It
is
by
far
one
of
our
two
longest
pulls,
and
so
I
thought
it
would
be
good
to
bring
it
up
and
see
if
anyone
had
particular
feelings
about
trying
to
get
this
to
happen.
C
C
A
C
A
A
C
D
Think
that
I
think
the
intention
was
like
we're
gonna
like
we're
gonna,
build
that
one
web
hook
in
controller
manager
but
like
to
build
that
web
hook.
Specifically,
we
have
to
add
the
initial
wiring
in
the
controller
manager
to
support
webhooks
at
all
so
like
yeah.
Maybe
this
is
the
best
for
it,
but.
C
Initially
yeah
I
mean
I
see
that
I'm
just
I'm
just
trying
to
point
out
that
running
the
web
hook
in
the
controller
doesn't
to
me
seem
super
essential.
So
if
this
is
really
blocking
progress,
are
we
willing
to
compromise
and
say
let's
just
build
a
simple
web
hook
that
people
can
use
and
you
have
to
forget
how
to
run
it
and
if
anybody
wants
to
step
up
and
make
that
easier
great.
But
let's
keep
moving
forward.
E
C
E
A
B
E
So
I'm
happy
to
take
some
of
this
work,
and
I
we
had
this
conversation
before
like
I
just
can't
take
the
entire,
like
you
know
like
a,
I
don't
think
I
can
own
the
entire
like
building
out
of
framework,
but
I
could,
if
we
can
split
this
up
into
you
know
like
smaller
pieces,
and
you
know
I'd
be
happy
to
take
like
proof
of
concept.
Web
hook
type
thing
that
seems
much
more
doable
with
less
time.
A
A
It's
as
odd
as
it,
I
think
the
tagging
is
all
the
same.
It's
a
it's
a
question
of
filter,
filtering
it
and
getting
the
tack
right.
So
I
believe
it's
a
question
of
looking
up
the
the
persistent
volume
determining
whether
it
is
a
legacy,
persistent
volume
and
then
getting
a
cloud
provider,
specific
value
which
is
going
to
be
put
in
the
tag,
so
that,
I
believe,
is
what
what
is
cloud
provider
specific.
I
think
the
impactful
of
writing
the
value
to
the
pv
is
the
same
for
everyone.
D
So
walter
I'm
wondering
if
so
I
do
agree
like
this-
is
important
because,
like
we
would
be
breaking
some
storage
stuff.
If
we
didn't
have
this
right,
but
I'm
wondering
for
like
124,
because
the
deadline
is
coming
up.
Do
you
think
we
should
spend
some
time
now
and
like
actually
maybe
like
list
all
the
caps
in
flight,
including
this
one
and
then
stack
rank
them.
A
E
D
D
E
C
A
A
A
No,
it's
fair.
It's
just
my
thought
had
been
that
if
we
wanted
to
get
what
you
were
mentioning,
which
is
not
an
official
automated
test,
we
could
get
something
into
tests.
The
to
run
run
the
the
standard
tests
with
our
credential
provider,
but
that's
a
lot
easier.
If
there's
a
a
official
ins
official
version
of
that
image,.
A
A
G
F
D
F
B
D
A
We
need
something
we
can
argue
whether
it's
a
cap
or
not,
I
have
talked
once,
is
stephen
augustus,
who
ran
away
like
in
fear
with
the
things
that
we
were
going
to
want
from
sig
release
as
part
of
this
effort,
but
yeah.
I
do
actually
think
this
is
I
I
don't
know
if
that
means
it
is
a
cap,
but
this
is
clearly
a
cross
sig
effort.
A
Okay,
so
I
had
jd
working
on
it,
but
jd
has
since
left.
So
from
my
perspective,
just
there
are
a
few
action
items,
so
the
first
is,
I
would
very
much
like,
and
there
is
a
pr
I'll
pick
it
up
and
move
it
forwards,
but
there
is
a
pr
to
allow
testing
to
turn
off
cloud
provider
in
kk
for
in
the
cluster
up
script.
A
A
Dealing
with
those
tests,
in
my
mind,
comes
down
to
one
of
three
items.
One
of
three
paths
forward
so
path,
one,
the
easiest
is
they
say
we
don't
need
this
test
anymore,
delete
the
test,
I'm
guessing,
that's
not
where
we
most
of
these
will
land,
but
it
is
certainly
an
option
option
two
is
the
the
belief
is
that
tests
shouldn't
require
anything
cloud
provider
specific
which
means
that
someone,
preferably
the
sig
who
owns
the
test,
needs
to
investigate
why
the
test
is
failing
and
work
out
how
to
make
it
not
fail.
A
A
Obviously
we
want
networking
to
restart
properly,
but
that
you
know,
assuming
that
the
the
vm
is
set
up.
A
particular
way
is
a
particularly
cloud-provided
specific
task
and
then
the
third
option-
and
this
is
where
lkg
clicks
in
is
we
say
look
this
test
is
cloud
is
or
is
believed
to
be
sufficiently
cloud
provider
specific
that
we
think
we
could
just
move
this
code,
this
testing
into
a
cloud
deployment,
or
at
least
you
know
the
the
reference
implementation
and
that
we
will-
and
this
is
where
lkg
gets
a
little
complicated.
A
Awesome
all
right
so
yeah.
I
definitely
think
that,
by
the
way,
when
I
mentioned
earlier
that
it's
one
of
the
two
long
poles
in
my
mind,
that
is
the
other
of
the
two
long
poles
and
I
think
it's
actually
probably
probably
pretty
important
that
we
at
least
get
the
list
of
tests
that
we
believe
to
be
a
problem
generated.
D
D
A
Yeah
and
the
other
thing
is,
while
I
do
think,
the
controller
manager
leader
migration
is
important,
it's
already
at
beta
right
right,
and
so
theoretically,
you
know
if
it
doesn't
move
to.
If
we,
even
if
we
don't
make
ga
criteria
this
time
around,
it's
there
are
two
more
releases
before
it
becomes
a
blocker.