►
From YouTube: Kubernetes SIG Cloud Provider 2019-01-23
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
so
today
is
January
23rd.
This
is
the
by
with
we
fit
cloud
provider
meeting
I'm
Andrew
your
co-chair
and
yeah
reminder
that
this
is
being
recorded.
So
you
know
whatever
happens
is
meaning
you
will
be
putting
it
on
YouTube,
okay.
So
let's
get
started
yeah.
If
you
could
put
your
name
and
the
attending
list
on
the
agenda.
That'd
be
great,
just
for
record-keeping
sake
and
we'll
start
with
the
first
item
on
the
list:
Claire
or
114
relief
updates.
B
Hello
hi
everyone,
my
name
is
Claire
I'm,
the
114
enhancements,
lead
and
I
just
wanted
to
hop
on
this
leg,
to
introduce
myself
and
give
a
general
update
that
the
enhancements
freeze
is
January.
29Th
and
I
wanted
to
check
to
see
if
there
were
any
issues
in
communities
enhancements
that
this
SIG
is
hoping
make
it
into
the
114
release.
A
B
C
Have
a
question
that
I
believe
I
know
the
answer
to,
but
I
just
want
to
be
sure.
A
lot
of
the
work
going
on
right
now,
at
least
from
the
entry
providers,
is
happening
in
secondary
repos,
like
cloud
provider
asher
and
cloud
provider
GCP,
since
those
aren't
being
directly
consumed
bike
indicates
Kate's
repo
I
assume
that
they
are
basically
orthogonal
to
what
you're
asking
about
correct.
Claire.
B
Just
to
make
sure
I
understand
the
question.
These
are
issues
that
aren't
the
enhancements
repo
itself
there
in
other
repos
I've
only
been
looking
in
the
enhancements
repo,
specifically
within
kubernetes.
If
there
are
other
issues
that
are
not
linked
to
an
issue
in
the
enhancements
repo,
let
me
know
what
that
link
is
I
can
make
sure
it's
getting
tracked.
C
B
See
what
you
mean-
okay,
I
think
I
was
confused
about
the
question.
Yes,
if
it's
not
expected
to
be
shipped
in
the
114
release,
then
that's
okay,
and
it
doesn't
need
to
be
tracked
well.
C
B
C
B
A
Like
we
had
an
umbrella
issue
for
that-
and
we
did
have
a
cap
for
that
so
like
maybe
in
113
those
two
things
kind
of
qualified
but
like
we
decided
that
one
umbrella
issue,
this
kind
of
it
doesn't
really
do
a
good
job
of
like
capturing
what
every
other
provider,
like
all
the
providers
doing
at
once,
and
so
we
decide
to
split
it
up
and
then
not
realizing
that
splitting
it
up
meant
that
we
have
to
then
create
a
capper
provider,
so
we're
playing
a
bit
of
catch-up.
No.
A
A
Follow
up,
and
let
me
know
if,
if
the
release
team
like
does
need
the
temper
provider,
we
can
like
build
just
like
a
template
and
then
just
like
you
know,
add
a
really
like
simplified
kept
for
each
provider
and
then
go
for
with
that.
Yeah.
C
A
Okay,
all
right
cool
move
on
to
the
next
item,
so
the
next
thing
was
mine,
so
initializers
are
being
removed
in
114,
or
at
least
that's
the
plan
for
114,
and
so
apparently,
the
only
thing
that
is
using
this
alpha
feature
is
the
persistent
volume
label
admission
controller,
like
that's
the
out
of
three
version
of
the
persistent
volume
label
controller,
and
so
the
compromise
that
mediums
and
Jordan
came
up
with
was
that
we
would
add
the
remaining
call
provider
in
the
entry
admission
controller.
That
way
we
can
deprecated
the
usage
of
we're,
not
deprecated.
A
A
A
A
So
like,
if
so
dims
things
that
no
one
is
actually
using
that
feature,
because
it's
an
office
teacher
and
he
things
like
no-one,
actually
went
out
of
the
way
to
enable
it.
And
so
he
thinks
just
like
removing
the
usage
is
not
going
to
affect
any
users.
And
if
there
are,
they
can
always
just
like
to
switch
back
to
the
entry
image
controller
of
what's
case
near.
A
A
So
on
that
note,
I
may
have
a
PR
that
adds
a
mutating
admission
webhook
for
the
auto
true
version,
so
expect
appear
for
that
all
right,
and
the
next
item
is
open
line.
I
created
an
end-to-end
test
that
tests
the
node
deletion
logic
from
the
provider.
So
if
you
delete
a
node
on
the
cloud
provider,
then
it
should
delete
the
kubernetes
objects
of
the
node
object
on
the
community
server.
So
I
tagged
it
with
like
a
cloud
provider,
feature
tag
so
that
they
shouldn't
run
on
presubmit
or
shamanic
informants.
A
But
if
you
specifically
add
like
the
kinko
focus
for
cloud
provider,
then
it'll
run
like
all
the
cloud
provider.
Specific
tests,
and
so
I'm
gonna
talk
to
stick
testing
on
if
this
kind
of
testing
is
okay
to
add,
and
if
like
my
goal
here
is
like
there
should
be
some
tag,
we
can
apply
to
the
end-to-end
test.
That
kind
of
test,
like
the
generic
cloud
provider,
features
until
we
still
need
to
add,
like
grille,
bouncers,
no
registration,
TV,
labeling
and
all
that
stuff,
so
just
wanted
to
share
the
PR
in
case.
D
A
A
A
That
was
the
other
discussion
that
I
had
with
Ben.
Do
we
need
like?
Is
it
okay
to
have
provider
specific
test
entry,
because
the
entire,
like
testing
framework,
isn't
real
life?
I,
don't
know?
Is
it
like?
Do
we
want
to
go
out
of
the
way
to
build
to
support
it
out
of
tree
in
some
way,
like
I,
don't
know.
D
C
I
also
feel,
like
you
know
at
some
point
we
may
want
to
Haven
have
things
you
know
playing
devil's
advocate,
but
we
may
want
to
have
conformance
tests
around
this
sort
of
thing
right.
I
mean
I
can
certainly
see
a
conformance
test
that
says,
if
you
know,
kubernetes
will
react
properly
if
one
of
its
underlying
resources
like
nodes
disappears.
D
C
A
So
like
these
tests
require
okay,
so
like
what's
interesting
about
these
tests,
is
that
you
have
to
add
provider
feature
and
the
both
in
the
sorry
you're
testing
the
provider
specific
feature
like
on
the
actual
cloud
provider
interface
and
your
you
have
to
add
a
separate
interface.
That's
like
the
framework
version
of
the
cloud
provider
that
lets
you
actually
delete
the
node
and
so
like.
There
is
a
discussion
and
we
have
to
have
around
if
that
framework
provider,
for
that
specifically,
for
the
end-to-end
test
also
need
to
be
out
of
tree.
C
A
A
That
that's
more
like
a
note,
lifecycle
test.
This
is
more
just
like
validating
that
the
resource
is
also
deleted.
If
the
note
is
deleted
so
like
I
can't
imagine
it
being
conformance
because
in
a
completely
like
cloud,
if
the
cluster
is
the
conformance
assumes,
the
cluster
has
no
what
cloud
provider,
and
so
it
shouldn't
specifically
test
like
cloud
provider
features
I
call
into
like
the
GCE
API
or
the
AWS
API
right,
I
I.
D
Don't
think
that
the
I
think
we
did
said
of
conformance
test,
we've
agreed
so
far
are
able
to
pass
without
a
cloud
provider,
but
I.
Don't
think
that
that's
a
hard
restriction
like
we
could
certainly
add
persistent
volumes
to
conformance,
and
we
do
expect
conformance
to
expand
to
be
a
more
useful
subset
of
kubernetes.
Okay,.
A
E
E
But
this
is
happening.
So
if
you
know
different
people,
don't
share
their
opinion
or
say
word:
their
providers
need
to
be
in
the
documentation
is
going
to
be
somebody.
Documentation
is
going
to
a
side.
I
have
a
meeting.
This
Friday
I
think
you
follow
up
on
this
one.
So
I
will
have
more
information
on
the
concrete
execution
dates
of,
but
yeah
take
a
look
to
the
document,
because
the
category
names
good
word,
your
provider
should
be,
and
I
will
come
back
to
the
to
this
group,
with
updates
from
sig
Doc's.
A
B
So
I
did
reach
out
to
Aaron
and
he
did
get
back
to
me
around
the
question
for
having
a
cup
to
track.
Each
individual
cloud
provider
versus
just
cups
for
the
issues
in
kubernetes
enhancement
and
Aaron's
response.
Is
that
he'd
prefer
to
have
individual
cups
per
provider,
but
is
interested
to
hear
from
this
sig
on
what
would
work
best
for
y'all.