►
From YouTube: Kubernetes sig-aws 20181102
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
Hello,
everyone:
it
is
November
2nd.
This
is
sick,
AWS,
our
bi-weekly
meeting.
We
have
a
fairly
light
agenda
today,
but
so
do
you
please
add
things
to
the
agenda
if
you
would
like
to
discuss
them
also
after
name,
if
just
so,
we
know
who
you
are
for
the
future
for
posterity,
otherwise,
I
suggest
we
can
jump
right
into
the
agenda.
The
I
rearranged
a
little
bit
so
first
up
on
the
agenda,
is
our
developer
error,
developer?
Alya,
an
issue
you
want
to
discuss?
Yes,
as
a
star
project.
B
I
think
Ilya
brought
this
topic
up
and
I
wanted
to
give
some
context
earlier
when
I
started,
building
a
cig,
AWS
charter
I
was
advised
that
I
should
not
try
to
add
tools
into
the
Charter
that
are
specific
to
a
platform
or
specific
product
like
he
cares,
and
we
also
had
a
discussion
about
adding
cops
as
a
sub
project,
but
there
is
interest
from
multiple
users
to
make
a
case.
Catalyst,
sub
project
and
also
Elia,
was
interested
in
thinking
about
this.
B
C
Yeah,
just
a
little
bit
firm.
Like
our
perspective,
we
never
really
wanted
to
do
like
own
this
as
a
tool.
It's
it's
more
of
a
community
project
from
our
perspective,
bringing
learned
a
person
from
the
works
who's
working
on
it,
I'd
like
to
continue
working
on
it,
but
it
seems
more
natural
for
for
the
project
to
have
a
more
neutral
home.
A
problem
of
perspective
of
the
active
contributors
also.
B
A
So
I
guess
I
have
less
of
a
problem
with
it.
Then
I
guess
other.
B
A
Kubernetes
orchestration
platform
just
like
GK,
is
a
closed
source,
open
closed
source,
kubernetes
orchestration
bottom
they're,
both
based
around
open
source
kubernetes,
but
they
are
not
like
usable,
fully
open
source.
I.
Think
that's
fair.
To
say
like
should
that
belong
in
the
in
the
community
and
I
I,
guess
my.
We
have
a
lot
of
things
that
work
with
proprietary
platforms
like
AWS,
alb
controller
right.
The
source
code,
for
that
is
not
open
source.
A
Just
like
we
have
at
GCE
I'll,
be
Trevor
and
like
G,
like
Google
cloud
platform,
the
gooks
are
googoo
boot
engine
is
itself
not
open
source
right.
So
we
definitely
talk
to
things
that
are
closed,
source
I,
don't
know
and
I
guess
the
other
point
would
be.
We
don't
have
another
place
as
far
as
I
know,
to
put
this
as
a
community
project
other
than
as
a
Cuban
at-6
sig
repo,
the
other
place.
A
A
Can
I
can
like
I
started
like
hacking
through
the
weeds
and
I
can
share
with
you
where
I
got
to,
which
is
basically,
you
have
to
set
up
the
CLA
bot
and
you
can't
set
up
a
CLE
about
today
without
we
just
can't
set
it
up.
Thank
you,
there's
all
sorts
of
stuff
that
has
to
happen.
It
I,
don't
know.
Maybe
the
procedure
is
better
now
and
it
felt
a
little
sad
that
it
was
just
the
CLA
book,
but
I
suggest
that
we
ask.
A
Let's
assume,
let's
assume
that
there's
no
objection
for
the
sort
of
project
level
like
do
we
like
it
as
a
Sogeti
best
project
like
can
we
get
consensus
that
if
there's
no
philosophical
objections,
would
we
take
it
as
a
as
a
cicada
best
project,
and
then
we
can?
Then
we
can
post
something
to
steering
or
something
I
say:
look.
We
have
this
project,
we
like
it
and
say
get
it.
We
got
it
approved
conditional,
oh,
but
I.
A
Freeze
though
we
got
it
approved
conditionally,
but
we
wanted
to
do
a
sanity
check,
whether
it's
appropriate
to
have
it
be
a
cicada
best,
project
risk
or
yeah.
So
I
guess
over
to
everyone
as
like,
do
people
feel
comfortable
with
it
being
a
secure
the
best
project
other
than
the
question
of
like
that
it
integrates
with
a
post
source
thing
just
like
if
you
like
g
k,
g:k
cutter,
would
have
the
same
objection
of
it
so
other
than
that
objection
tabling
that
rejection.
How
do
people
feel
bad.
C
Yeah,
we
just
just
a
few
think
started
contrast
with
the
with
the
GE
tools.
You
know
they're
part
of
the
Google
Cloud
SDK,
which
is
a
broader
project
which
has
historical
reasons
to
exist
on
its
own.
The
way
that
it
does
right
so
yeah
and
I
mean
I
think
from
from
the
sort
of
philosophical
perspective,
you'd
be
nice.
If
one
day
there
was
some
kind
of
a
universal
substrate
for
4cl
eyes
for
crazy
clusters
in
any
of
the
the
hosted
providers
and
for
that
being,
a
community
project
seems
like
an
operating
our
idea.
C
So
you
know
with
in
spirit
of
that,
and
you
know
what
do
people
think
really,
because
a
geek
es
kettle
is
currently
a
standalone
CLI,
just
because
there
isn't
like
a
central
place
for
for
SEO
light
to
realize
itself
within
the
community
or
as
a
kind
of
part
of
a
lot
of
wider
project
right.
There
is
cluster
cuddle,
but
it's
still
early
days
for
cluster
cuddle
and
it's
a
question
of
where
the
cluster
pool
sticks
around
for
no
longer
and
I
mean
it
sounds
like
it
was.
They
was
the
story
there
and.
B
D
B
C
A
Actually,
I
think
it
does
a
good
point.
We
do
have
coo
cuddle
plugins
now,
and
it
is
very
reasonable
that,
like
maybe
gke
cob,
maybe
g-cloud
the
gk,
each
cooling
might
move
to
a
Cupido,
plugin
right
and
then
same
way.
You
might
can
support
this
or
a
crew-cut,
a
plugin
as
well,
and
where
would
we
in
future
want
those
to
live?
What
do
you
want
them
to
live?
What
we're
doing
I
mean
so
in
from
that
one
of
you,
like
I,
very
much.
A
My
personal
view
is
we
should
on
the
on
the
community
like
health
issue.
Is
it's
better
to
have
it
in
a
community
on
repo
and
have
it
managed
through
the
SIG's
structure?
That's
the
structure
we
have
and
and
I
think
it's
a
good
thing
for
this
signature
to
accept,
I,
accept
and
so
I
think
I'm
in
paper,
I.
A
Think,
given
that
people
had
objections,
we
should
run
it
by
steering
or
whatever
the
appropriate
form
is,
but
if
people
are
generally,
what
we've
done
before
is
if
people
are
generally
in
favor
of
the
idea
of
bringing
as
a
repository,
maybe
with
some
reservations
around
around
that
philosophy
issues.
Then
we
should,
we
should
get
it
a
get
proceeded
preceding
our
sake
and
then
raise
that
issue
separately.
So
we've
done
in
the
past
as
a
straw
poll
of
anyone
that
objects.
So
I
don't
know.
If
anyone
has
any
particular
objections.
B
A
E
A
Great,
that's
wonderful,
so
I
have
a
when
I
break
up
the
issue.
Now
the
next
thing
on
the
agenda
and
then
we
can
discuss
the
ordering
of
where
they
won't
talk
about
it,
which
is
just
a
sick
cloud
provider,
which
is
a
different
sake
that
is
responsible
for
overarching
cloud
provider
stuff
or
things
that
integrate
with
provider.
In
the
same
way
that
sig
network
is
responsible
for
things
that
deal
with
networking
they
are
and
they
prime,
they
are
sake.
A
They've
already
been
looking
at
extraction
of
the
cloud
provider
code
from
criminals,
communities
into
a
new
component,
which
is
gonna,
be
called
the
Cloud
Controller
manager,
but
there
has
also
been
a
suggestion
that
we
fold
fold
all
the
existing
individual
cloud.
Six
sigchi
CPC
kws
sync
opens
accessing
these
fears.
I
think
you
see,
I
am
cloud
I,
don't
I'm,
probably
forgetting
some
people,
but
all
the
individual
clouds
sakes.
Essentially
under
sick
cloud
provider.
There
is
some
I'm.
A
There
is
some
debate
about
whether
what
we
don't
have
a
concept
of
sub
six
today,
so
they
can't
really
be
sub
six
unless
we
change
things
there,
but
they
would
certainly
like
carry
on
the
sub
projects
and
there's
a
I
brought
the
idea
that
we
have
a
sort
of
user
group
type
of
thing
going
on
here
as
well,
which
I
think
we
would
want
to
keep
so
some
sort
of
meeting
of
like
dedicated
to
AWS
or
primarily
focused
for
AWS
users,
but
I,
don't
know
how
other
people
feel
about
that
idea.
Primarily,
it's
happened.
A
B
And
while
the
open
start
team
has
decided
that
beyond
cloud
controller
manager,
whatever
extra
tooling
the
build,
all
of
that
will
sit
under
sick
cloud
provider,
so
their
cinder
integration,
Manila
integration,
Keystone,
everything
sits
in,
say,
cloud
provider,
sick
cloud
providers.
Binary
is
primarily
the
cloud
controller
manager,
and
so
we
have
many
other
binaries
that
we
are
really
saying.
This
is
our
going
to
be
at
first
alpha
release
and
kubernetes.
B
I
still
want
the
idea
of
Elise's
my
opinion,
a
sub
cig,
which
gives
us
the
independence
but
then
pushes,
through
the
into
end
testing
standards,
the
documentation
standards
and
the
external
CCM
that
we
are
already
working
on
and
after
release
mike
is
working
on.
It
I
think
that's
what
should
happen
and
that
does
require
a
discussion
in
Sec
architecture
or
six
six
steering
because
they've
never
done
it
before.
But
I.
B
E
A
I
am
inclined
to
agree,
I
would
say
one.
The
gotcha
is
that
the
sub
sink
concept
does
not
exist
and
probably
doesn't
like
that.
As
far
as
I
can
tell,
one
of
the
primary
objections
is
around
the
number
of
six
that
exist
and
I
don't
know
if
having
a
a
treat
of
six
would
actually
address
the
number
like
whether
they're,
counting
how
they're
counting
the
number
of
six
so
I
I
wanted.
I
wanted
to
make
sure
that
we
got
their
viewpoints
of
this
sake.
A
I
think
I
think
it's
probably
risky
to
do
right
now,
so
we
should
proceed
carefully,
but
I
think
we
can
make.
We
can
certainly
have
more
of
a
formalized
reporting,
structure
or
form
and
I
say
well
s
what
we
can
like
try
to
report
up
and
down
like
what's
happening,
a
secret
route
provider
and
into
this
group,
and
what
is
we
can
report
up
into
sick
cloud
provider?
What
is
happening
together?
Yes,
I
guess
that
would
be.
We
can
start
doing
that
act
as
if
we
are
at
the
new
structure
before
we
like
rock.
A
Think,
that's
that's
true.
On
a
lot
of
the
projects,
I
think
like
a
it's,
not
true
an
eks
cuddle,
for
example,
but
it
is
true
on,
for
example,
the
encryption
provider
right
like.
Why
are
it?
Why
is
the
GK
encryption
provider
different
that
GC
and
provider
different
from
the
a
device
encryption
provider
and,
if
like,
if
either
has
a
similar
thing?
A
You
know
like
I
and
I,
think
some
of
the
stuff
that
Seth
did
when
he
was
implemented
and
it
was
one-
is
probably
brought
up
some
interesting
ideas
that
we
should
definitely
move
back
into
the
GCP
encryption
provider,
GC
Google,
Cloud
encryption
provider
and
so
like
from
that
point
of
view,
projects
where
it
would
be
better
to
have
like
different
structures.
It
may
be
that
we
make
a
decision
as
we
go
right.
I
think
I
think
the
idea
of
having
an
overarching
sig
that
helps
people
collaborate
is
a
great
one
and
I
think
I
guess.
D
Is
there
anything
that
would
prevent
the
definition
of
such
a
sub
structure
within
their
current
limitations
of
the
sig
Charter
right
now?
Obviously,
you'd
have
to
create
a
new
state
Charter,
but
that
might
be
a
way
to
kind
of
formalize
that
structure
with
the
sub-project
ownerships
for
each
of
the
subgroups
kind
of
aligning
you
know
with
the
right
membership
and
I
think
that
might
be
a
way
to
address
kind
of
some
of
those
concerns
there.
B
I
do
know
that
there
is
some
tooling
dependency
in
kubernetes
org
in
community
and
how
sig
amell's
are
structured
is
structured,
because
today
the
hierarchy
is
one
sig
and
sub-projects
underneath
it
so
I
expect
things
to
break
if
we
try
to
have
a
one
sake
and
sub
six,
so
there
will
be
some
tooling
changes,
at
least
in
the
beginning
and
then
I
think
from
a
governance
standpoint.
The
committee
steering
committee
and
architecture
will
have
to
agree.
B
So
all
that
will
and
I
think
another
important
point
why
this
is
really
being
initiated
is
because
there
is
an
interest
to
reduce
the
number
of
six
and
that's
why
they're
doing
it
so
yeah.
This
needs
to
be
discussed.
I
just
think
that
sig
AWS
is
so
big.
There
are
so
many
users
I
get
the
point
about
democracy
and
opening
the
forum
for
all
cloud
providers,
but
it's
impossible
to
collapse.
Aws.
In
my
view,
sorry,
my
go
ahead.
E
A
A
And
we
would
still
I
think
I
got
some
of
it
and
we
can.
We
would
still
we'd
still
be
able
to
have
dedicated
meetings
under
the
sake
to
an
extent.
It's
like
inside
baseball,
I
think
like
yeah,
like
whether
you're
a
singer
or
not,
but
so
I
don't
want
to
like
to
spend
too
much
time
on
this
image
for
Reese.
A
Maybe
I
could
stop
and
we
have
other
things
on
the
agenda
now,
but
we
could
still
have
I
think
the
same,
like
a
cops
has
office
hours,
for
example,
that
cops
is
a
I
think
it's
technically
a
project
under
sink
toaster
lifecycle,
but
you
know
we
have
in
the
other.
It
was
meets
every
two
weeks
and
any
other
time
slot
every
other
week
we
we
spend
an
hour
talking
about
like
cops
and
they're,
like
a
user
group
in
developer
discussions
so
like
we
could
still
have
that
in
cups.
A
It's
not
cops
is
not
a
sake,
so
we
can
still
have
meetings,
for
example,
but
it's
it's
mostly
about
governance
and
structure,
oh
I,
unless
anyone
else
has
anything
to
add
I
suggest
we
we
carry
on
on
the
agenda.
The
discussion
is
also
having
a
sig
cloud
provider
I.
If
anyone
from
this
group
is
interested
in
kubernetes
white
cloud,
things
sink,
a
provider
is,
is
great
they're,
mostly
working
on
the
cloud
controller
manager
right
now,
but
yes,
I
want
to
make
sure
everyone
was
aware
of
the
discussion
and
thank
you
for
the
here.
A
Yes,
I,
like
the
idea,
Mike,
that's
a
guy,
so
mike
says
one
where
this
is
it
possible
to
have
a
quarterly
or
whatever
sake
where
it
includes
both
sake,
travel,
sig,
typewriter
and
cigarettes.
Having
a
joint
meeting
to
current
that
cooperation
and
collaboration,
which
I
think
is
a
great
idea,
I
think
you
know
those
sort
of
things
which
are
not
massive
structural
changes
but
like
let
us
dip
our
toe
in
the
water
and
see
how
it
goes.
I
think
might
be
a
great
business.
So.
B
The
other
context
to
add
there
Mike
is
AWS.
At
least
me.
Mike
and
Justin
are
regularly
involved
in,
say
cloud
provider.
We
go
to
their
egg
meetings
and
my
crew
was
also
on
the
call
is
moving
the
out
of
tree
CCM
and
we're
doing
the
Alpha
in
kubernetes
1.13,
there's
also
a
lot
of
interface
dependencies
for
the
CCM
in
code
kubernetes
and
OpenStack
Google
AWS.
All
three
of
us
are
working
on
one
PR,
that's
moving
those
dependencies
into
kubernetes
staging
right
now.
So
actually
we
have
a
ton
of
collaboration
around
that
cloud,
controller
manager
concept.
B
So
if
you
join
the
cig
cloud
provider,
meeting
every
Wednesday
you'll
see
that
we're
working
together
plus
we
are
also
we
did
a
documentation
cap
together
and
now
we're
working
on
how
to
standardize.
Etv
testing
for
CCM,
so
you'll
see
that
it's
already
happening
and
I
just
wanted
to
give
you
that
context.
A
B
Just
need
these
bugs
to
be
fixed.
We
don't
have
the
cycles
to
do
beta
for
NLB
in
113,
so
we'll
do
it
in
114,
but
I
would
love
for
someone
to
look
at
these
bugs,
especially
you
Justin,
just
prioritize
these
three,
and
so
we
can
move
forward
and
then
there
are
a
couple
of
features:
we're
working
on
an
e
to
e.
But
we
can
finish
that
by
q1
1.1
for
some.
A
A
A
A
Yes
looks
like
the
next
item
on
the
agenda
is
perhaps
even
more
controversial
than
the
previous
project
issues:
cluster
api
AWS
as
a
sub-project
initio
Jason.
Do
you
wanna
well.
B
I
think
I,
remember,
Chris,
know
about
proposing
this,
but
I
never
completed
the
process
to
like
make
it
happen.
So
I
wanted
to
bring
it
up
because
Jason
is
doing
all
the
work
and
we've
not
helped
him
at
all.
Hopefully,
that'll
change
going
forward,
but
I
just
wanted
to
talk
about
it
in
the
forum
and
see
if
there's
an
action.
What
should
we
do
or
does
it
belong
to
say,
cluster
lifecycle,
yeah.
D
So
I'd
say
it's
probably
not
overly
controversial,
actually
Justin,
where,
where
the
ownership
sits
really
doesn't
matter
much
to
me,
we
just
ended
up
creating
it
understate
cluster
lifecycle,
mainly
because
it
spawned
out
of
the
cluster
API
related
work
that
we
were
doing
as
it
stands
right
now.
We
do
have
anybody
that
is
in
the
sake.
D
Aws
leads
group
which
we
synced
a
while
back
and
may
need
to
be
rethink,
I'm,
not
sure,
but
as
as
approvers
on
the
project
by
default,
as
well
with
the
idea
that
the
problem
being
is,
you
can't
actually
have
a
sub-project,
it's
owned
by
two
different
SIG's,
so
wherever
it
sits
as
long
as
you
know,
the
right
collaborators
have
access
to
it.
You
know
it's
great
to
me.
A
D
A
Thank
this
is
the
sort
of
next
generation
of
tooling,
like
installation,
and
management,
tooling,
should
integrate
with
the
cluster
API,
and
there
will
be
plugins
for
GP
and
AWS
and
OpenStack
and
dissolution,
and
all
these
clouds,
and
but
there
will
be
a
consistent
at
kubernetes
api
on
top
of
those
I
think
it
feels
it
feels
almost.
It
feels
as
core
as
like
the
cloud
provider
code
in
future.
I
think
if,
if
it
didn't
have
a
home
like
sig,
a
DBS
would
definitely
be
the
home
for
it.
A
If
there's
some
additional
like
we
support
this
project,
but
even
if
we
don't
own
a
type
thing
and
should
seek
top
still
lifes
like
I'll
ever
disown
it,
we
will
happily
own
it
type
thing
we
should.
We
should
declare
that,
but
if
it
has
a
home
today,
then
I
think
that's
fine,
I,
don't
know.
If
there's
anything
we
could
do
further
in
is
she?
Oh?
No.
B
D
You
know
that's
going
to
be
the
real
challenge
you
know.
Ideally
there
would
be.
You
know
some
structure,
for
you
know
two
SIG's.
You
know
co-owning
a
project
to
kind
of
ease
this
type
of
burden,
but
you
know
similar
to
the
cloud
provider
thing.
You
know
we're
we're
limited
with
the
current
structure
that
we
have.
B
A
With
that
I
think
it's
actually
just
an
interesting
pattern
that
when
they
start
up
all
these
sort
of
projects
are
more
likely
to
be
like
most
their
peak
C
cluster
life
cycle,
clustering
right
things,
but
you
can
imagine
that
a
year
down
the
road
most
will
be
like.
Oh
there's,
a
new
AWS
way
of
launching
instances
or
whatever
it
is
that
you
guys
have
coming
right
and
like,
and
so
like.
More
of
the
work
in
future
will
be
like
more
aw
se,
unless
generic
so
I,
don't
know
if
I
don't
know.
D
Today,
it's
it's!
The
who
owns
the
repo
currently
sits
by
who
are
the
current
contributors
towards
the
sub
project
right
now,
so,
like
the
VMware
provider,
sits
under
the
vmware
related
cig,
but
because
most
of
the
contributors
have
been
under
stood
cluster
life
cycle
for
the
AWS
provider
so
far,
GC
p
and
OpenStack
that's
kind
of
why
they
fell
under
cig
cluster
life
cycle.
But
you
know
where
it
ends
up.
You
know
you
know
as
long
as
we're
you
continue
working
together
to
kind
of
build
this
thing
out.
It
doesn't
really
matter
much
to
me.
D
A
Think
we
can
be
bit
I
think
we
can.
We
can
start
a
list.
If
you
wanted
to
our
projects
we
would
underwrite.
So
if
they
lost
their
sponsorship,
I
suggested
life
cycle.
We
would
immediately
snap
them
up,
but
as
long
as
they
are
not
free
agents,
we
we
can
leave
them
where
they
are
I.
Think
next
item
they
on
the
agenda
is
from
k,
cool
offline
cops
to
plummet
into
take
a
risk
of
cloud
yeah.
F
Hi,
could
you
hear
me:
okay,
yeah,
I'm,
Cooper,
so
I'm
trying
to
use
cops
in
golf
club
because
there
is
no
eks,
so
I
have
to
dig
through
all
of
the
calls
out
to
the
internet
like
for
note
up
and
I'm,
not
sure
whatever
else,
but
there's
about
eight
things
that
I've
identified
as
docker
images
that
it
pulls
down
and
then
a
few
binaries,
so
I
just
tried
I
had
I
couldn't
find
that
it
within
just
the
the
cops.
F
The
cops
itself
so
I
had
I
dumped
it
into
a
terraform
plan
and
I
went
through
all
of
that
to
see
how
it's
actually
building
on
the
machines,
and
so
what
I'm
doing
is
just
replacing
those
calls
to
the
World
Wide
Web
to
my
local
nexus,
repo.
It's
so
that's
I,
don't
know
if
there's
any
effort
or
structure
to
go
for
AWS
gov
cloud
as
a
provider,
because
that
would
be
really
great.
A
A
A
Okay,
and
perhaps
if
you
opened
an
issue
on
cups
or
then
we
can
like
go
through,
but
I
would
also
try
to
I
don't
person
access
to
golf
club,
which
makes
this
difficult,
I,
think
I,
don't
and,
and
so
I
will
I.
We
can
sort
of
try
to
figure
it
out.
I
guess
there
is
some
beginnings
of
support.
I
think
there's
also
support
using
proxies,
for
example,
if
you're
willing
to
use
that
outfit,
but
that's
I,
set.
A
There's
there's
not
a
magic
flag,
there's
some
work
to
set
up
a
magic
flag,
but
it's
not
there
yet
and
I
know
that,
like
this
is
a
like
I'm
as
AWS
has
great
support
for,
like
private
as
three
buckets
for
example.
So
you
can
in
theory,
set
up
a
cluster
which
has
no
internet
access
at
all
and
just
that's
what
I'm
doing
yeah
the
dream
is.
The
dream
is
to
get
a
communities
cluster
to
boot.
I,
don't
know
if
anyone
has
actually
done
that
in
with
their
cops
or
not
well,.
A
A
I'm,
just
looking
at
the
ETS
people
and
see
if
they're
there
biting
but
they're
they're,
not
they're,
not
moving.
Okay,
thank
you,
I,
don't
know
if
anyone
else
has
so.
Yes
that-
and
you
come
along
next
week-
and
we
can
try
to
talk
about
in
more
detail
but
open
an
issue
and
we
can
talk
around
anytime.