►
From YouTube: Kubernetes SIG Cloud Provider 2018-07-25
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).
B
Started:
okay,
so
everyone
welcome
to
the
weekly
sig
cloud
provider
meeting
and
reminder
this
meeting
is
being
recorded
so
and
will
be
posted
to
YouTube.
So
this
is
all
this
is
all
public
and
we
have
the
agenda.
It's
been
dropped
into
the
end
of
the
chat
and
so
I
guess
we'll
start
off
with.
Is
there
anybody
who
is
new
to
the
meeting
this
week?
Is
there
anyone
who
hasn't
attended
mystic
cloud
provider
meeting
before
hi.
B
B
Okay,
well
so
we
have
a
pretty
light
agenda
this
week,
but
it's
also
a
fairly
important
one,
because
we
have
a
number
of
new
cloud
providers
who
are
who
have
sent
in
have
sent
in
poll.
Work
poll
requests
to
have
repositories
created
for
their
existing
cloud
providers,
and
so
why
don't
we
start
off
with
that?
We
can
begin
with
the
Baidu
cloud
and
the
representatives
there
can
possibly
introduce
themselves
and
talk
a
little
bit
about
their
cloud.
I
think
that
would
be
their
cloud
provider.
That
would
be
a
great
place
to
start.
Okay,.
C
So
hi
I'm
hunting
from
Baidu,
so
I'm
sorry
I'm,
actually
not
from
the
Baidu
cloud
team,
because
it's
a
4
a.m.
and
in
China.
So
my
friends
after
the
Baidu
cloud
team
asked
me
to
come
and
join
the
meeting.
So
in
case
you
guys
have
any
question
for
him:
I
can
forward
as
a
question
to
him,
but
I'm
not
have
a
deep
knowledge
to
to
to
their
products.
So
I'm,
sorry,
yeah.
A
This
is
what
we,
the
community
and
like
here,
is
some
sort
of
proof
that,
like
we're
a
legitimate
cloud
provider-
and
we
really
want
to
include
kubernetes
Marc
platform
and
so
the
three
cats
there
are
from
like
Baidu
cloud
Alibaba
and
digitalocean,
where
I
work
and
so
yeah
I,
don't
think
there's
anything
more
than
that.
I
think
really.
What
we
need
from
everyone
here
is
to
review.
It
know
that
the
process
is
still
in
progress.
A
One
thing
to
know
was
that
Chris
one
thing
to
know
was
that
before
we
talked
about
making
performance,
testing
and
documentation
a
stripper,
a
fireman
right
now,
in
my
opinion,
at
least
I-
think
this
should
be
a
strip
requirement
once
we
have
enough
cloud
providers
actually
doing
this
properly
and
I,
don't
think
we
do
right
now
and
so
in
the
future
that
will
probably
be
in
the
list
of
apartments.
B
A
A
The
next
item
is
also
mine,
too.
Okay,
we
talked
briefly
about
this
last
week
and
pretty
much.
We
said
we'll
talk
about
it
offline
and
then
reduce
it.
So
the
problem
around
this
is
the
load.
Balancer
names
in
kubernetes
is
very
cryptic
and
misleading.
So
right
now
what
we
do
is
you
take
the
letter
we
take
the
letter
A
and
then
append
just
nervous
UID
as
a
little
bouncer
name.
So
I
don't
know
what
the
history
behind
doing.
A
This
is
it's
probably
because
we
wanted
some
generic
name
that
works
with
every
cloud
provider,
and
so
a
colleague
of
mine
opened
a
PR
to
work
in
progress,
but
the
PR
essentially
ad
get
little
bouncer
name
into
every
cloud
provider
and
then
we'll
probably
default
the
service
UID
name
into
every
provider.
And
then
what
this
lets
us
do
is
every
provider
then
can,
on
their
own
time,
figure
out
some
way
to
migrate
into
a
more
sensible
name.
That
probably
includes
I
I,
don't
know
the
actual
service
name
or
something.
A
E
B
B
So
what
why
are
we
not
abstracting
this
and
just
pushing
down
the
implementation
to
the
cloud
provider?
Implementation
I
mean
it
seems
like
the
abstractions
should
still
be
the
place
to
get
that
name
and
then
the
when
that
interface
is
satisfied
by
the
individual
providers
that
that's
where
that
should
happen
there.
But
it
looks
like
we're.
Switching
from
the
general
provider
to
the
specific
provider
I
mean
I
could
be
reading
the
code
wrong,
yeah.
A
So
the
the
biggest
problem
around
this
is
that
you
have
to
be
really
careful
when
you
change
little
bouncer
names.
Cuz
like
you,
don't
want
to
break
anyone's
load
balancer
because
that'd
be
bad,
and
so
what
we're
trying
to
do
is
push
the
concern
into
so
like
right.
Now
the
method
get
little.
Bouncer
name
is
a
global
method
in
package
cloud
provider
and
right.
A
Every
provider
calls
this
global
method,
and
so
what
we're
doing
is
we're
just
pushing
the
method
down
to
entry
or
we're
doing
both
entry
and
out
of
treat,
but
we
have
to
add
an
entry
because
of
dependency
reasons.
Right
doing
is
like
the
the
cloud
provider
specific
method
for
getting
the
little
bouncer
name
is
just
a
copy
of
what
we
have
currently
keep
backwards
compatibility
and
then,
whenever
cloud
providers
want
to
change
it,
they
can
do
whatever
they
need
to
substitute
that
gotcha.
B
A
B
B
A
A
G
A
F
I
was
just
gonna,
give
a
little
history
about
it.
It's
the
problems
being
about
not
losing
a
lobe
answer.
If
the
user
already
has
a
load
balancer
and
a
secondary
problem
being
the
risk
of
collisions,
so
that's
why
we
don't
just
like
use
just
the
service
name,
for
example,
and
then
the
third
problem
being
what
was
the
third
problem?
Those.
B
F
G
F
G
B
B
B
So
the
so
the
next
on
the
next
item
on
the
agenda
is
the
the
documentation
cap
that
machine
I
have
been
have
been
working
on.
She,
unfortunately
wasn't
able
to
make
this
meeting,
but
I've
been
chatting
with
her
on
slack
and
she's,
saying
that
she's
going
to
push
that
as
well
as
an
end
and
testing
cap
tonight
or
tomorrow
at
the
latest.
So
we
should
be
looking
for
those
arriving
soon
and
once
they
land
I'll
make
sure
that
I
drop
those
into
the
end
of
this
into
the
slack
channel
for
people
to
review
and
I'll.
B
B
B
B
G
Me
just
once
again
Andrews
giving
me
feedback.
Thank
you
Andrew,
but
if
other
folks
could
please
take
a
look
at
this
cap,
I
I
would
really
appreciate
it.
It's
sort
of
trying
to
come
up
with
a
common
model
for
how
we
piece
together
each
cloud
providers
repo
with
the
main
kubernetes
repo,
how
we
do
build,
how
we
do
testing
this
is
pretty
central
to
our
lives
going
forward.
So
I
want
to
make
sure
that
everyone
is
comfortable
and
happy
with
what
we're
saying.
Walter.
Have
you.
B
And
I,
actually
I
should
look
at
this.
Have
you
tagged
Chris
Nova,
on
on
this
stock
on
this
cabinet
I
haven't?
If
you
think
he
should
look
at
it,
I
think
that's
a
great
idea,
yeah.
She
she
should.
She
should
take
a
look
because,
because
there's
there's
work
being
done,
you
know
kind
of
coincident
with
the
I'm
trying
to
remember
which
saying
we've
been
we've
been
working
with
your
board.
Just
think
that
is
I.
Is
it
the
cluster
API?
Yes,
the
close
for
API,
sig
and
they're.
B
So
there
was
talk
they
they
had
reasons
as
to
why
they
wanted
to
structure
their
repositories
that
way
and
so
making
everyone
aware
of
you
know
something
it
has
a
that
has
kind
of
the
the
way
to
reach
and
making
sure
that
if
they
have,
if
they're
places
with
a
interface
with
that
and
that
that
they
need
to
have
comment
on,
that
is
probably
a
good
thing.
If
you.
G
Could
ping
me
there
their
handle?
That
would
be
great.
The
other
thing
I
have
talked
a
little
bit
with
cig
release
and
with
cig
storage,
because
they
both
have
things
going
on
as
well,
and
so
this
is
why
I'm
trying
to
get
I
want
to
get
everyone
to
sort
of
sign
off
and
and
get
all
their
objections
heard.
And
so
we
can
come
up
with
one
unified
story
of
how
to
move
forward.
Yeah,
yeah,
I.
D
Give
a
little
reminder
to
the
cig.
Looking
at
the
features
repo
there
isn't
anything
specifically
labeled
with
Sig
cloud
provider,
but
doing
a
search
on
cloud
provider.
There
are
a
lot
of
things
and
I
know
what
the
the
cluster
API
and
other
things
going
on.
There
there's
a
lot
in
this
space.
So
if
there's
anything
that
you
wanted
to
call
out
for
upcoming
activity
related
to
1.12
and
have
the
release
team,
have
visibility
onto
just
make
sure
that
y'all
are
aware
of
the
feature
freeze
coming
in
a
week's
time.
July
31st.
B
Yeah,
were
there
any
features
on
the
cloud
provider
that
we
expected
to
be
to
be
coming
out?
I
guess,
I,
guess
the
load,
balancer
naming
would
be
a
feature
that
were.
We
would
be
expecting
the
land
and
1.12,
but
is
there
anything
else
that
that
people
can
think
of
that
would
be
going
into
the
cloud
provider
or
just
in
work
we're
doing
in
general?.
G
D
That's
definitely
something
I
have,
in
my
mind,
just
from
a
risk
management
perspective
on
the
release,
knowing
that
things
are
moving
around
and
ensuring
that
we
continue
to
have
good
test
coverage
and
reallocation
of
test
results,
because
we
don't
want
to
get
a
false
signal
as
we're
going
towards
release
on
112.
Something
major
is
not
right.