►
From YouTube: kubernetes sig-aws 20190614
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
Friday
June
14th.
This
is
sick,
a
dress
I
am
your
moderator
facilitator,
just
in
Santa,
Barbara
I
work
at
Google,
a
reminder
that
this
meeting
is
being
recorded
and
what
we
put
on
the
Internet.
Please
be
mindful
of
our
code
of
conduct,
otherwise,
I
pasted
a
linked
to
the
agenda
into
our
chat.
We
actually
have
almost
nothing
on
our
going.
Nothing
on
the
agenda.
B
So
hey
I'm,
Jay
pipes,
I
recently
joined
the
eks
team
at
AWS
and
I
really
am
just
interested
in
how
myself
personally,
as
well
as
other
folks
on
the
eks
team
and
broader
at
AWS,
can
assist
you
Justin,
as
well
as
anyone
else,
who's
in
sick,
AWS,
soon-to-be,
ug,
AWS
or
not
really
sure
how
all
that
works.
Yet
still,
but
yeah
I
mean
the
questions
that
I
have
for
you
just
are
primarily
around
you
know
how
come?
B
How
can
we
assist
you
and
future
leads
and
are
there
housekeeping
type
tasks
that
get
annoying
that
we
can
take
off
your
plate?
What
are
some
of
the
most
important
things
from
an
AWS
outward
communication
perspective
that
I
can
help
facilitate
whether
that's
you
know
coordinating
with
internal
product
folks
with
regards
to
roadmap
or
whether
it
is
sort
of
outside
of
eks
outside
of
AWS
getting
help
on
on.
You
know
tutorials
and
things
like
that,
whatever
it
is,
so
that's
kind
of
what
I'm
I'm
looking
for
is.
A
Well,
thank
you
so
much
Jay
and
welcome,
and
thank
you
for
that
very
kind
offer.
That's
great
I
am
super
happy
to
hear
that
I
think.
Yes,
by
way
of
background
the
cig
AWS
that,
as
a
cig,
is
likely
to
fold
on
into
sig
cloud
provider
to
try
to
achieve
greater
sort
of
harmony
and
homogeneity
amongst
the
different
cloud
provider,
implementations
and
the
current
plan
is
that
sig
AWS?
What
can
the
will
murder
will
transform
into
a
user
group?
I?
Don't
think
you
are
it's
I,
don't
think
it's
the
case.
A
You
don't
yet
understand
that
you
I
think
it's
the
case
that
no
one
understands
it,
because
user
groups
are
still
going
through
the
approval
process.
So
it's
all
very
much
like
a
work
in
progress.
But,
yes,
the
intention
is
that
sigit
of
us
is
sort
of
unique
in
that
it
is
more
user
facing
much
more
user
facing
than
other
sakes,
which
tend
to
be
more
development
focused
and
sig
can
provide.
It
will
likely
be
the
more
development
focused
stream
and
user
group
will
be
the
more
user
facing
Streatley.
A
A
The
in
those
issues,
I
are
bound
to
be
a
huge
number
of
duplicates
and
but
also
some
nuggets
of
things
that
we
really
should
address,
and
maybe
we
should
go
through
a
section,
and
maybe
we
should
like
any
help
with
charging.
Those
is
always
very
welcome,
and
maybe
we
should
try
to
do
a
session
where
we
actually
go
through
and
do
that
on
video
or
something
like
that
to
help
people
understand,
didn't
get
everyone
up
to
speed
today
once
day.
Well,.
B
Yeah,
that
would
certainly
be
useful
for
newcomers
like,
like
myself,
I
think
you
know
I've
kind
of
just
started
out
with
some
documentation
contributions
and
reviewing
a
number
of
things
coming
into
the
sig
docks
and
kubernetes
website,
and
that
kind
of
thing.
But
at
the
same
time,
I've
I've
wondered
how
you
sort
of
prioritize
and
select
the
the
best
things
to
kind
of
put
your
focus
towards
just
because
there
there
is
a
sheer
volume
of
incoming
issues
and
pull
requests
water
water.
Maybe
some
of
the
tools
that
you
use
like
I've,
asked
dims.
A
Ultros
s
but
yeah
I
think
what
you're
doing
sounds
great
in
terms
of
like
looking
at
the
docks,
I
think
when
you
start
looking
when
you,
if
you
reach
the
end
of
the
like
obvious
things
like
once,
you
go
into
the
issues.
I
imagine
you
will
find
a
whole
another
set
of
challenges
in
there.
If
that's
that
to
me,
is
like
a
I,
it's
it's
sort
of
a
getting
started
way
and
then
I
think
code.
A
If
you
the
same
thing
in
and
the
other
repos
like
the
Cuban,
a
cigs
ones
related
to
AWS
I
suspect
there
are
fewer
issues
outside
of
I.
Think
most
issues
tend
to
have
been
first
in
KK,
but
they,
the
fix,
might
well
be
in
a
different
repository
and
yet
those
and
looking
at
the
code
and
reviewing
the
code
and
fixing
things
if
you
want
to
and
surfacing
those
are
it's
something
that
everyone
can
do
and
is.
A
B
A
A
B
A
A
B
A
And
okay,
and
today
it's
like
the
km/s
encryption
provider
right,
but
once
we
pull
the
cloud
provider
of
tree
there
should
be.
There
should
be
no
eight
of
us
code
entry.
There
should
be
no
in
KK
there
should
be
no
cheesy
code
entry
right
and
there
will
be
nothing
of
relevance
to
say,
give
us
or
a
sig
glamour
rider
in
open
source.
Pretty
sense
if
they
were
strand
has.
B
A
Release
team
tends
to
do
that,
but
what
has
happened
recently
is
the
every
PR
that
merges
gets
a
release,
note
block
and
those
are
sort
of
aggregated
by
the
release
team.
Who
then
typically
will
produce
like
a
first
draft
and
then
like
ask
the
various
seeks
to
go
and
like
polish
them
and
prioritize
them
and,
like
say
like,
within
your
sake
like
which
ones
are
important,
which
ones
they're
not
oh,.
B
A
But
yeah
the
I
think
understanding
what
we
should
thinking
about,
what
we
should
put
in
there
and
and
how
we're
gonna
I
forget
things
from
other
and
other
repos
is
really
interesting
and
might
be
a
nice
extension
of
the
docs
work
and
then
the
other
thing
is,
you
know
you
mentioned
tutorials
I
think
tutorials
are
great
because
they
really
sort
of
preempt
a
ton
of
issues
and
a
ton
of
like
Docs,
it's
a
nice
way
of
structured
Docs,
and
then
it
avoids
a
bunch
of
challenges.
So
yeah.
A
B
The
policy
I
mean
the
the
last
thing.
I
think
we
want
to
do.
Is
you
know
just
meaning
the
eks
team,
though
I
I,
think
the
last
thing
we
want
to
do
from
just
an
open
source
contribution
perspective.
It's
just
like
just
be
constantly
like
just
pushing
a
WI
specific
stuff
up
into
the
common
repositories.
B
What
is
the
policy
on
things
like
the
the
website
and
documentation
with
regards
to
cloud
providers?
Specific
content,
as
it
generally
been
well
we're
trying
to
remove
those
cloud,
specific
cloud
provider,
specific
things
and
put
them
in
a
different
area,
or
we
just
let
as
as
many
different
examples,
and
you
know
let
a
thousand
flowers,
bloom
kind
of
thing,
I
think
I
I,.
A
Sort
of
that
was
sort
of
a
de-facto
position,
and
we
also
let
some
commercial
links
go
on
there
as
well
like
there
was
a
huge
list
of
like
800
ways
to
install
kubernetes
like
the
different
companies.
Serena
I,
think
I
think
we've
now
removed
that,
because
most
of
them
are
perfectly
out
of
date
and
like
the
companies
themselves,
70
points
like
their
one
o
virgin
of
whatever
it
is,
but
that's
right.
A
It's
we
do,
for
example,
if
load
balancers
are
only
implemented
by
cloud
providers
like
do
we
not
have
low
balancer
documentation
on
the
website.
That
seems
silly
to
me,
but
if
it's
like
how
to
use
the
AWS
VP,
CC
and
I
provider,
on
the
one
hand
it's
a
good
C&I
provider,
we
should
document
how
to
use
it.
On
the
other
hand,
it's
like
eww
a
specific
right,
but
it's
it's
just
CNI
provider,
even
though
it
only
runs
during
one
particular
cloud
right
now,
so
I
think
getting
involved
in
that
question.
A
B
Because,
there's
that
fine
line
right
I
mean
we,
we
want
to
produce
documentation
and
tutorials
and
all
this
stuff,
that's
the
most
benefit
to
the
end
user
and
gives
people
the
most
information.
But
at
the
same
time,
from
an
AWS
team
perspective.
We
don't
want
to
just
you
know,
be
just
constantly
throwing
AWS
specific
stuff
over
the
wall,
and
you
know
focusing
only
on
AWS
things
right.
A
A
B
A
C
C
B
Are
maybe
a
suggestion
instead
of
the
weekly
sig
AWS
or
not,
instead
of
but
in
addition
to
the
sig
AWS
weekly
meetings?
Would
it
be
useful
to
have
kind
of
like
either
like
a
bug,
triage
sort
of
power
hour
or
day,
or
something
like
that?
Where
we
just
kind
of
do
a
bug,
smash
or
triage
smash
kind
of
activity,
I
actually.
A
B
A
A
I
think
that'll
be
great
and
I
think
the
activities
I.
We
can
think
about
like
how
best
where
we
should
put
said
backlog
and
how
best
to
like
what
should
our
outputs
be.
I.
Don't
have
any
great
answers
right
now,
it's
easier
in
some
of
the
like
that
single
purpose
repos
right
like
so
cluster
API,
has
a
backlog
and
it's
fairly
straightforward
because
they
don't
have.
You
know
lots
of
other
projects
in
there,
but
we
can
look
at
exactly
how
they
do
it.
B
I
see
there's
a
few
people
on
the
chat,
but
anyway
yeah
I
mean
I.
Don't
really
have
too
many
other
questions,
if
you
think
of
things
that
you
know
housekeeping
items,
that
kind
of
thing
that
are
just
annoying
that
we
can
help
with
don't
hesitate
to,
let
me
know
either
on
slack
or
failing
list
or
whatever
thank.
A
You
and
I
think
I
believe
most
people
have
permission
to
do
most
grooming
activities
like
not
directly
in
Qatar,
but
you
use
the
slash
commands
like
labels
to
get
us
I
think
works.
I,
don't
think
you
can
move
things
as
you
milestones,
but
you
can
certainly
try
and
then
be
rejected,
and
then
we
can
fix
it
up
or
give
your
permission
type
thing,
but
I
I'm
not
sure
exactly
what
permissions
people
have
them
don't
have,
but
yeah
the
bots.
We
try
to
stay
away
from
the
github
direct
permissions.
A
A
It's
just
I
know:
I'm,
you
have
permission
to
apply
no
GTM
other
than
/lg
TM,
for
example.
Well,.
A
A
Approvers
should
not
be
allowed
to
apply
the
labels
directly
because
it's
sort
of
too
easy
to
do
by
mistake,
so
we
eat
the
way
you
do
it
is
you
make
a
comment
which
says:
slash
approved
for
/l
GTA,
no
I,
don't
know
that
I
think
I
actually
have
permission.
I
would
like
not
to
have
permission,
but
that
is
a
separate
issue
that
is
being
worked
through,
but
the
I
like
the
proposal
next
together.
This
meeting
should
be
issued,
triage
issue,
PR
triage
room,
a
session
or
one
dot.
A
Yes,
116
good,
not
off
by
one
all
right.
Do
we
have
anything
else?
If
that's
I
think
it's
a
great
post
one
at
Thank,
You
Jay,
and
if
there's
nothing
else,
should
we
there's
nothing
else
in
the
agenda?
I,
don't
know
anything
else.
They
would
like
to
bring
up
or
Jay
anything
else.
You
want
to
cover
there.
Nothing.
D
D
A
Yeah
definitely
well
I
think
that
should
definitely
be
something
that
we
would
have
to
figure
out
in
terms
of
in
terms
of
the
triage
I.
Don't
think
anyone
I
have
no
idea
how
to
implement
that.
So
maybe
a
good
way
would
be
to
start
and
open
an
issue,
and
we
can
make
sure
to
look
at
it
and
discuss
it
next
time,
I,
don't
think
I've
seen
ideas
and
how
we
would
implement
such
a
things.
I.
D
A
A
Yeah,
if
there's
other
issues,
please
yeah,
it's
gonna
be
interesting.
I!
Guess
we
should
in
that
triage
we
should
figure
out
like
what
repos
we
should
try
to
look
at
because,
like
this
issue
feels
like
I,
don't
know
how
we
would
solve
it,
but,
like
this
issue
feels
like
something
that
could
go
on
the
open
source
roadmap,
but
isn't
is
in
a
different
repo
than
it's,
not
in
KK
so
and
it
was
that
there
wouldn't
be
on
the
list
of
the
ones.
I
would
immediately
think
to
go
to
either.