►
From YouTube: Kubernetes SIG Cloud Provider 2019-02-06
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
A
A
B
So
I
can
kick
this
one
off.
So
in
the
first
sig
meeting
of
2019,
you
were
kind
of
picking
up
discussions
from
from
keep
on
around
how
we
want
governance
model
to
look
like
for
the
provider
six,
and
so
we
had
kind
of
slept
it
as
like.
Let's
write
some,
let's
write
a
proposal
and
see
what
ideas
you
can
get
talked
to
some
folks
in
steering,
and
so
there's
some
idea
circulating
around
right
now
and
so
most
of
the
ideas
are
in
the
proposal.
B
I
think
we're
still
a
pretty
long
way
off
in
terms
of
like
I
feel
like
there's
a
lot
of
alternatives
and
a
lot
of
a
lot
of
things,
we're
not
considering
as
part
of
this
migration,
but
he
had
some
ideas
and
she
had
added
a
bunch
of
stuff
to
the
proposal.
Misha,
do
you
want
to
kind
of
talk
a
bit
about
some
of
the
ideas
you
put
in
there
and.
C
So
the
idea
is
to
allow
the
SIG's
to
operate
as
user
groups
where
they
can
continue
to
meet
abaya
zoom
on
a
bi-weekly
basis
and
solve
user
issues,
but
in
terms
of
how
the
out
of
tree
features
are
released
or
other
things
in
terms
of
quarterly
community
updates
or
github
labels
and
notifications.
There
are
some
suggestions
in
terms
of
organizing
these
sub
projects
better
also,
if
you
think
about
six
dot
llamó,
where
all
the
projects
are
listed
today,
there
is
a
way
whereby
the
sub
projects
are
under
siege.
C
Aws
or
sig
IBM
or
cig
VMware,
and
the
proposal
here
is
probably
we
just
prefix
the
sub
projects
with
the
provider
name
and
then
list
all
of
them
under,
say
cloud
provider
just
to
make
the
organization
of
this
proposal
simple
and
not
build
any
new
systems
or
sub
projects
under
each
of
the
providers.
So
it's
just
a
proposal
and
I
think
it
might
work
fine
in
terms
of
what
we
are
trying
to
achieve,
but
obviously
it
requires
inputs
from
all
the
sig
leads
and
discussion.
C
We've
also
added
a
table
that
talks
about
you
know:
do
you
agree
with
the
overall
idea
and
if
you
could
just
put
in
your
inputs,
give
your
feedback
and
then
say
yes
or
no,
then
we
can
make
some
progress,
even
if
it's
a
no
at
least
we
need
to
know
what
is
bothering
people
and
right
now
we
don't
feel
like
we're
getting
that
information.
Hence
this
is
a
stab
at
that
to
get
either
form.
B
But
yeah
you
raise
a
good
point,
though.
Like
me,
you
don't
have
I
feel
like
in
this
meeting.
At
least
you
don't
have
all
the
stakeholders
in
place
to
actually
make
a
decision
on
meeting
so
I
feel
like
we
need
to
either
go
to
all
the
provider,
sig
bi-weekly
meetings
and
bring
it
up
there
or
something
else.
A
A
Yeah
lots
to
be
in
because
we're
trying
to
make
channel
the
request
from
the
steering
committee,
the
deed
you've,
been
reduced,
the
number
of
things
and
the
voice
more
providers
things,
but
we
don't
quite
understand
what
value
folks
are
getting
out
of
it.
So
Andrew
and
and
Misha
is
that
something
you're
willing
to
reach
out
to
those
it's
a
pretty
short
list.
So
we
can
split
it
up
or
you
guys
can
send
the
same
email
to
the
nine
people.
I
think
we're
talking
about
yep.
B
A
Talking
things
too
directly
email,
the
sig
leads
for
AWS
GC
ppm
or
whatever
the
ones
that
are
listed,
okay
and
just
ask
what
value
they
get
out
of
it.
It's
not
even
leading
question
that
maybe
that
state
doesn't
need
to
exist.
It's
just
a
question,
you
know
what
do
you
get
out
of
it?
What
what
benefits
do
we
need
to
replicate,
and
then
we
could
have
a
sub-project
of
type
user
group
or
something
maybe
that's
enough?
Maybe
we
get
Dan
Kahn
to
say.
E
And
at
some
point,
I
think
it's
actually
pretty
important
to
publish
this
I
am
and
I'm,
not
even
sure.
If
the
the
cloud
provider
mailing
list
is
the
appropriate
place,
but
maybe
the
larger
communities
mailing
list
you
know,
there's
we
can't
expect
everybody
who
has
a
stake
in
this
to
be
attending
these
meetings
or
for
us
to
drop
in
on
their
meetings
and-
and
so
you
know
at
some
point
once
a
plan
is
closer
being
implemented.
I,
don't
I
would
necessarily
call
a
bike
shedding
to
get
community
feedback.
You
know
by
by
and
large.
E
You
know
before,
making
a
large
change
like
this,
because
it
will
impact
not
just
listing
owners
and
the
sick
needs.
But
you
know
it's
gonna
have
an
effect
on
the
people
who
are
participating
in
those
and
on
the
you
know-
and
you
know
it's
gonna
trickle
down
to
the
users
who
are
depending
upon
those
platforms,
yeah.
D
The
statement
of
our
representative,
yes
mailing
sick
leads,
are
the
users
and
I
know
in
the
VMware
cig.
We
are
starting
to
build
traction
where
those
guys
rarely
appeared
at
first
but
I.
Think
in
the
last
meetings,
we've
consistently
had
users
showing
up
and
I
do
know
that
there's
a
community
of
those
who
who
look
at
the
videos
and
don't
show
up
at
the
meetings
to
just
because
of
time,
zone
issues
and
yeah
we're
seeing
the
same
thing
of
this
traction
building
in
our
slack
channel
too
yeah
yeah.
A
And
I
think
from
the
perspective
of
the
CN
CF,
it
is
critical
to
maintain
direct
contact
with
those
end
users
for
the
CN
CF
to
continue
to
grow
and
expand
and
maintain
a
relevant
relationship
with
their
users.
So
I
think
if
we,
if
we
can
aggregate
into
a
clear
and
consistent
ask
of
CN
CF
ad
cube
cons
for
slack
channel
and
whatever
those
mechanisms
are
that
people
depend
on
and
use
to
communicate
with
their
end
users.
A
E
E
Experience
yeah,
you
know,
maybe
you
know
maybe
some
of
these
efforts,
instead
of
being
part
of
the
larger
you
can
become.
You
know
more
more
something
as
part
of
the
an
expanded
developer
experience,
because
really
you
know
this
is
this
is
one
of
the
areas
where
we're
we're
trying
to
reach
out
and
bring
people
in.
As
you
know,
if
kubernetes
is
a
kernel
that
provides
a
place
to
plug
in
different
functionality,
you
know
the
providers
are
going
to
be
bringing
a
lot
of
that
functionality
and
having
a
sanctioned
developer
venue
for
them
to
participate.
A
We
should
capture
that
light,
so
your
focus
is
on
the
contributor
side.
Mine
is
on
the
end
user
side
in
the
direct
interaction
with
folks
who
are
trying
to
run
their
own
workloads
on
some
provider
and
just
want
somewhere
to
go
and
ask
for
guidance
yeah
both
of
those
are
valid,
but
it's
it
suggests
that
there's
probably
more
than
the
ones
we
think
of
right
here.
Right.
D
E
And
there's
you
know
they're,
you
know
there
are
things
like
you
know
like
right
now
at
cube
con.
We
have,
you
know,
you
know,
six
are
given
an
intro
on
a
deep
dive
and
I.
Don't
know
what
everyone
else's
experiences
are
from
this,
but
from
the
OpenStack
site
we
typically
treated
the
intro
as
how
do
you
get
started
using
it
as
a
consumer,
and
you
know
we
want
that
to
be
more
user
base.
Then
we
try
to
make
the
deep
dive.
E
C
C
So
I
also
wanted
to
bring
up
another
perspective,
so
I
opened
a
recent
issue:
thats
related
to
olive
tree
featured
releases,
so
in
sagaie
ws
we
always
use
the
update
session
in
queue
con
to
talk
about
the
new
sub
projects,
we've
added,
and
then
we
move
them
through
alpha
beta
and
GA
cycle.
Just
like
the
entry
features,
we
want
to
follow
that
release
cadence,
but
then
it's
becoming
cumbersome
for
anybody
for
the
cig
release
team,
primarily
that's
focused
on
entry
features
to
start
focusing
on
out
three
features
as
well.
C
So
in
some
ways
the
sick
providers
need
a
release
cycle.
They
also
need
to
follow
a
testing
cadence
and
a
documentation
cadence
which
is
sort
of
a
out
of
tree
sorry,
entry
best
practice,
and
then
it
also
relates
to
the
cube
concessions
that
are
done
for
the
users
who
show
up
plus.
If
you
look
through
the
documentation
that
we
done,
we
are
also
suggesting
that
none
of
the
slack
channels
none
of
the
zoom
sessions,
the
bi-weekly
sessions-
need
to
be
collapsed.
C
A
F
There's
one
thing:
I
was
thinking
the
other
day
about
you
know
as
they
are
today
fooling
make
sense.
Because
of
the
you
know.
If
we
look
at
the
status
quo,
we
see
that
in
its
pretty
much
people
working
just
on
providing,
you
know
the
basic
infrastructure
services
to
run
kubernetes
on
the
platform.
But
if
you
look
at
the
ecosystem
for
kubernetes
I
think
we're
going
to
see
in
sq
layers
get
adopted
and
we
get.
You
know
two
more
people
using
the
softer
and
more
traditional
shops
trying
to
do
more
integration.
F
New
companies
coming
up
trying
to
do
more
integration
for
specific
platforms
or
with
their
own
software
on
a
specific
platform.
I
think
you
know
the
venue
for
developers
to
reach
out
to
people
working
on
a
specific
platform
with
that
knowledge
of
the
platform
being
AWS
as
your
VMware
or
whatever
it.
It's
gonna
be
very
important
if
we
take
that
away
like
from
not
necessarily
just
a
weekly
meeting,
but
you
know
the
entire
structure
that
brings
the
sake
with
it.
F
I
still
think
we
should
find
a
way
and
probably
Jagger
you
mentioned
talking
with
Christopher
and
CN
CF-
see
if
there's
a
way
to
get
to
a
point
where
we
expand,
not
just
not
just
saying
maybe
just
calling
a
different
way,
but
a
in
a
way
to
have
a
user
group
or
a
developer
group
for
our
specific
platform
would
make
more
sense
than
just
you
know:
folding
everything
under
a
single
umbrella
and
just
you
keep
the
status
quo.
Basically
I
think.
A
Those
are,
those
are
good
points
and
I
think
we
have
a
general
sense
of
what
the
benefits
are,
but
I
just
want
to
make
sure.
We
actually
ask
people
instead
of
going
with
the
assumptions
and
what
we
can
dream
up
so
I
think
that
will
help
close
the
loop
and
then
we
can
come
up
with
a
concrete
proposal
and
get
backing
from
the
CN
CF
for
our
proposal
and
take
that
back
to
the
SIG's,
because
I
think
you
know
the
burden
is
on
us
to
make
sure
we
meet
the
needs
and
make
it
better.
A
B
Actually,
the
next
three
items
are
all
mine,
so
I'll
try
that
place
through
them
fast,
so
the
first
one
is
ignoring
nodes
in
the
cloud
controller
manager.
So
there
was
a
use
case
that
came
out
where
someone
is
running
the
virtual
key
on
a
cluster
that
runs
a
cloud
controller
manager
and
the
cloud
controller
manager
is
deleting
the
node,
because
the
virtual
cubelet
doesn't
it
doesn't
send
heartbeats
and
updates
its
status.
A
For
it
yeah
I
did
my
immediate
reaction
is
the
having
felt
pain
in
the
annotation
to
field
the
promotions
and
I
can't
remember
one
seven
to
one
eight.
Maybe
I
can
remember
what
it
was.
The
annotations
become
part
of
the
API
and
my
my
question
to
push
on
this
a
bit
harder
is:
is
it?
Is
there
a
way
to
make
it
a
field
somewhere
that
won't
change
and
isn't
swappable
yeah.
B
So
that
was
kind
of
following
up
on
so
on
the
second
point
there
Jordan
had
mentioned
some
media
is
part
of
like
a
longer
term
solution.
We
may
want
to
give
like
every
cloud
controller
manager,
an
ID
and
and
every
node,
an
ID
so
that
we're
correlating
like
this
set
of
CCN
should
always
register
at
these
set
of
nodes,
and
we
can
yeah
and
like
we
can
embed
that
into
like
a
into
the
node
API
and
actually
make
it
like
a
legitimate
field.
B
But
obviously
that's
gonna
require
like
writing
a
cap
and
doing
more
work,
but
I
feel
like
do.
We
want
to
take
a
shortcut
and
add
the
annotation
for
the
particular
case,
or
do
you
want
to
just
like
full-stop
closest
PR
and
you
know
think
more
long-term
and
and
implement
something?
That's
gonna
satisfy
more
requirements
when
bored
I
guess,
like
that's
kind
of
the
question
I
wanted
to
ask.
B
A
I
think
I've,
given
away
my
through
my
nonverbal
communication
I
just
find
every
time
we
take
this
shortcut
or
do
something
for
now
or
now
becomes
forever
yeah
and
then,
when
we
change
those
API
is
we
end
up
breaking
people
during
upgrades,
and
this
is
erodes
the
trust
of
the
upgrade
process.
So
it's
not
I
I'm,
almost
sure
we
could
get
something
to
work
in
practice,
but
it's
not
the
steady
state.
That
is
the
problem
with
any
of
these
annotations
with
a
growth
path.
A
B
Okay,
it's
truly
like
we're
stuck
with
like
even
with
low
bouncers,
like
we
have
a
bunch
of
these
like
alpha
beta
few
annotations
that
are
just
stuck
there
and
no
one
touches
them,
because
it
would
break
a
lot
of
stuff
if
you
did
so
make
sense
or
even
worse,
like
maybe
it
wouldn't
break
anything,
but
nobody
knows
right
yeah,
so
it
seems
like
we
need
to
probably
talk
to
sick
node
2
for
this
and
see
what
changes
we
want
to
make
two
nodes
to
make
this
happen.
Okay,
that
sounds
good
to
me.
One.
C
C
C
C
Just
that
the
interfaces
yeah,
the
interface
today
doesn't
have
a
heartbeat
implementation,
but
also
because
we
don't
know
how
the
backend
it's
different
for
Fargate
for
yes,
I,
we
don't
know
how.
What
is
the
best
manner
to
integrate
this
provider
specific
feature
and
I
just
believe
that,
because
not
every
provider
has
an
integration
with
service
infrastructure,
they
should
figure
out
how
they
want
to
do
it
right.
B
Okay,
so
so
what
I'm
getting
at
it's
like
it
doesn't
seem
like
the
use
case
is
common
enough
for
us
to
build
anything
in
like
in
the
court
reef
or
this
so
temporary
workarounds
can
happen
using
my
custom
controllers,
but
to
kind
of
like
address,
use
cases
like
this
more
and
more
like
in
a
more
general
context.
We
should
see
what
we
can
do
to
the
u1
node
and
have
something
in
actual
API.
Okay
sounds
good
to
me.
B
So
the
next
item
cloud
provider,
end-to-end
test,
so
I
added
the
first
cloud
provider
and
killing
test.
As
part
of
like
that
testing
framework,
we
wanted
to
do
for
cloud
providers,
so
I
appeared
an
issue
that
kind
of
lists
out
some
of
the
other
and
to
intestine.
So
I
think
this
needs
a
little
bit
more
grooming
I
need
to
go
through
all
the
end-to-end
tests
we
have
and
see
like
which
ones
we
actually
should
cover.
B
I
know,
there's
a
lot
of
like
GK,
specific
ones
that
are
embedded
in
there
somewhere,
but
I
think
it'd
be
great.
If
we
can
generalize
them
a
bit
more,
so
we
can
run
them
on
more
providers,
and
then
providers
can
like
kind
of
run,
this
test
suite
when
they
start
moving
from
like
entry
to
auditory,
so
they
can
have
a
little
bit
more
confidence
going
forward.
B
B
Well
done
Andrew!
This
is
awesome
thanks,
alright,
so
next
one
just
wanted
to
give
a
quick
status
update
on
the
provider
extraction,
work
that
you
see,
Mike
and
Walter
and
I
are
working
on
so
phase
one
we're
still
on
phase
one,
which
is
to
stage
all
the
cloud
providers.
That
way
we
can
publish
them
out
two
out
of
two
providers
if
they
want
to-
and
this
kind
of
gives
us
that,
like
seamless
migration
between
entry
and
out
of
tree,
the
blocker
for
staging
or
repository
is
to
remove
the
entry
dependencies.
B
So
like
the
provider
packages
can't
import
anything
can't
import
entry
package.
Otherwise
we
can't
export
it
into
an
external
repo,
so
we're
going
through
all
the
dependencies
break
them
out
we're
about
70
percent
done
and
I'm,
hoping
that
by
114,
we'll
have
all
the
dependencies
out
and
if
you
great,
if
we
can
stage
at
the
for
114
I,
don't
most
likely
I
think
well
how'd
the
dependencies
remove,
but
we
won't
get
to
the
staging
part,
but
we'll
see
how
that
goes.