►
Description
KEP 1771 - Cloud Provider versioning scheme
Docs accuracy with Node Controller
Plans to test Cloud Provider feature gates
A
Welcome
to
the
2021
thursday
november
4th
sig
cloud
provider,
cloud
provider
extraction
working
group
meeting:
this
meeting
is
part
of
syd
cloud
provider,
kubernetes
and
cncf,
and
our
our
various
rules
and
policies
are
to
be
kind,
inclusive
and
respectful
of
others.
So
yeah,
please
do
that
all
right.
A
All
right
so
first
item
on
the
agenda
and
I
will
probably
repeat
this
in
the
main
meeting,
but
it
came
up
during
the
last
meeting.
This
is
a
quick
reminder.
We
do
actually
have
a
cap
called
sig
cloud
provider
1771
that
talks
about
the
correct
way
to
version
a
external
cloud
provider
release.
A
I
think
the
pertinent
part
is
that
the
major
and
minor
version
numbers
of
the
cloud
provider
should
be
tracking
the
kubernetes
version
they
intend
to
support.
Part
of
this
is
intended
to
make
it
easy
for
a
customer
to
understand
what
level
of
conformance
they're
getting
right.
So
if
you
say
that
you're,
if
you
say
that
you
are
conformant
approved
at
kubernetes
116,
then
we'd
like
your
version
to
be
say,
116,
to
match
the
kubernetes
to
116,
which
would
then
match
the
116
conformance
plan.
B
Yeah,
so
we've
been
doing
some
reviews
on
our
end
as
we
prepare
for
an
internal
security
review
of
some
of
our
stuff,
and
we
were
going
through
the
upstream
documentation
again
and
there's
this
line
in
the
cloud
controller
docs
that
says
you
know
the
node
controller
is
responsible
for
creating
node
objects.
When
new
servers
are
created
in
your
cloud
infrastructure
that
did
not
seem
accurate
to
us.
I
believe
that
would
be.
A
What
we
call
a
blatant
lie
just
for
everyone
on
the
call
to
be
clear
nodes,
and
there
are
a
couple
of
special
objects,
but
nodes
are
a
very
particular
special
object
in
that
they
are
not
created
by
users
and
they're,
not
complete,
created
by
contr
by
by
controllers,
either
not
sure
why
that
is
showing
up.
A
How
do
I
there?
We
go
sorry
about
that.
Generally,
whatever
your
deployment
system
is
or
possibly
your
your
node,
auto
scaler
is
to
create
the
actual
node
object,
and
only
once
it's
created,
then
the
cloud
node
controller
is
going
to
kick
in
to
actually
for
lack
of
a
better
term
populate
the
node,
but
it
isn't
actually
create
the
node,
because
it's
to
create
the
node,
it
would
have
to
be
polling
the
cloud
provider
and
as
far
as
and
we
we,
that
is
not
something
that
we
do.
A
We
assume
that
someone
will
create
the
node
object
and
once
the
node
object's
been
created
that
we
can
then
do
the
various
things
like
determine
what
its
ip
address
is
and
all
the
other
pieces
of
data
that
need
to
be
populated
in
the
node
object.
B
Okay,
cool,
I
guess,
like
the
are
the
docs
in
kubernetes
docs
or
something
like.
I
don't
mind,
making
a
pr
to
try
and
update
this
or
something
see
if
we
could
get
some
or.
A
Is
there
I
just
recently
had
another
bug
found
in
the
kubernetes
dock
to
go,
find
where
it
is
so
I
believe
it's
kubernetes
docks,
but
I
can
actually,
I
can
go
ahead
and
send
you
I'll
in
fact
I'll
just
update
the
the
meeting
notes
after
the
meeting
to
reflect
where
that
lives.
A
Awesome,
thank
you
elmiko
all
right
and
then
the
next
one's
yours
as
well.
B
Yeah
so
this
was,
you
know:
we've
been
doing
a
lot
of
tests
recently,
integrating
the
gcp
cloud
provider
into
our
releases
as
well,
and
this
you
know
so
mikhail
fidocin
who's
been
opening.
Some
of
these
bugs
he's
just
been
coming
across
a
few
bugs
as
he
goes
through
this,
and
I
just
wanted
to
kind
of
raise
the
issue
here,
just
to
get
a
little
more
attention.
B
You
know
I
mean
for
purely
selfish
regions.
At
some
level,
this
is
blocking
our
process
to
continue
creating
our
releases,
but
also
because
we'd
like
to
see
you
know,
we'd
like
to
see
the
cloud
providers
be
really
high.
Quality
100
agree
with
that.
A
So
one
one
thing
on
this
particular
bug:
I
took
a
quick
look
at
it.
I
haven't
had
a
chance,
it
seems
to
be
somewhat
sdk
dependent,
and
so
I
just
want
to
verify
that
it
is
dependent
on
the
sdk.
It
is
built
with
not
the
sdk
that
it
finds
local
to
the
user.
A
If
it's
local
to
the
user,
then
we
probably
need
to
do
some
sort
of
sdk
checks.
If
it's
the
build,
then
I
believe
we
can
probably
valid
verify
news,
as
is
so.
I
will
go
ahead
and
pick
that
up.
B
Awesome
yeah.
I
appreciate
I
appreciate
the
checking
on
that.
A
Nope
no
items.
Okay.
So
one
item
that
I
have
which
I
forgot
to
put
into
the
agenda,
I
found
a
a
volunteer
victim.
A
I
mean
volunteer
to
go
ahead
and
take
a
look
at
the
kk
cube
upscripts
and
try
to
create
a
flag
that
will
turn
off
the
cloud
provider
flags
in
the
cube
up
script
so
that
we
can
try
running
the
tests
in
a
particular
in
its
own,
proud
job
with
the
two
cloud
provider
check
fee
feature
gates
turned
on,
so
that's
the
regular
cl
cloud
provider
feature
gate
and
the
credential
provider
feature
date
as
it
stands.
A
The
cube
up
script
sets
the
cloud
provider
facts
which
will
cause
things
like
the
cubelet
and
the
cube
api
server
to
bomb
out
immediately
based
on
those
feature
gates,
so
it
would
be,
and
then
we
once
we
get
that
going.
We
should
then
get
a
list
of
all
of
the
tests
that
are
going
to
break
and
we
will
hopefully
then
have
a
list
of
work
to
be
done
before
we
can
move
those
feature
gates
to
beta
or,
if
we'll
find
something
else
wrong
and
have
to
yet
another
step
to
do.