►
From YouTube: Kubernetes sig-aws 20180907
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
So
anyway,
if
folks
have
items
that
they
think
we
should
work
on,
feel
free
to
add
them.
If
folks
want
to
contribute
and
pick
any
of
those
items
off
feel
free
to
go
in
and
assign
yourself,
and
let
us
know
that
working
on
them,
the
Google
Doc,
is
linked
in
the
agenda
minutes
and
that's
all
that
I
have
there.
Unless
anybody
has
any
questions,
I.
B
Will
I
will
sync
with
you
afterwards
Kris,
because
I
am
back
filling
all
our
videos,
the
ones
that
I
have
I'm
missing
a
couple
and
I
don't
know
if
anyone
else
has
some
for
some
other
random
reason,
but
if
anyone
other
than
Chris
has
any
videos
please
do
reach
out
to
me.
I
have
almost
all
of
them,
I'm
just
missing
a
couple
and
apparently
supposed
to
upload
them
in
order.
Otherwise
people
get
unhappy.
B
A
B
A
C
There,
but
one
of
the
things
I
wanted
to
ask,
is
on
the
buttoning
up
for
the
sub-project
process.
I
have
pretty
much
cleared
the
process
for
the
current
four
sub
projects
and
I'm,
adding
two
new
sub
projects:
the
CSI
driver
in
the
club,
the
API
is
there
something
that
you
think
is
missing
for
the
existing
whole
sub
projects,
I.
A
C
Yeah
Adam
had
mentioned
that
changing
the
community
call
I
only
closed
the
CR
for
the
existing
ones
and
I'll
follow
up
on
the
other
two
and
close
them
this
week.
Okay,
cool,
okay
and
I
also
want
to
date.
The
action
item
on
the
Charter
I'll
share
the
Java
with
you
and
Justin
next
week,
and
then
we
can
open
it
up
for
everybody
else.
On
the
forum
in
the
next
meeting.
Okay,.
A
A
B
B
I
think
the
only
two
things
that
are
currently
sort
of
long
boiling
topics
are
whether
whether
masternodes
should
by
default,
be
included
in
load,
balancers
and
sort
of
the
various
options
for
that
to
give
people
the
choice
and
what
we
do
about
instances
there
in
the
stopped
State,
as
opposed
to
the
terminated
State,
whether
they
should
be
deleted
in
communities.
But
there
are,
if
anyone
is
interested
in
those
I
will
try
to
like
you,
can
search
the
github
issues
and
they
are.
There
are
active
discussions
going
on
on
both
of
them
in
the
communities.
A
C
Had
one
question
to
ask
about
the
encryption
provider,
there
was
a
request
from
a
customer
around
an
additional
feature,
whereby
is
the
master.
Key
e
is
not
essentially
if
they
don't
want
to
essentially
master
keys
provided
by
a
PMS
provider,
or
rather
the
tech
when
they
want
to
provide
the
master
key
for
the
secrets
to
be
encrypted
with
adding
that
feature
into
the
encryption
provider.
Was
a
request.
I
wanted
to
ask
people
if
there
are
other
customers
with
similar.
B
I
I
don't
know
on
the
Google
side
whether
we've
heard
that
if
it
it
really
be
worth
checking
out
the
Google
encryption
provider,
I
supports
a
comparable
flag.
I
guess
it
would
be
a
flag
right,
but
yeah.
It
doesn't
sound
like
a
terribly
hard
features
and
I
think
it'd
be
very,
very
valuable
to
people
that
I
guess
want
to
bring
their
own
key
a
montage
or
why
you
would
do
that,
but
doesn't
seem
unreasonable
to
do.
B
Yeah
I
think
the
the
gotcha
is
I,
don't
think
I
can
ever
I,
don't
think.
For
example,
we
have
a
way
to
do
key
rotation
away,
for
example,
so
they
can't
like
it.
You
know
they
is
if
they
want
to
do
that,
for
what
their
own,
like
compliance
reasons,
that
sounds
like
a
reasonable
feature
to
add,
not
terribly
difficult.
I
can
imagine.
There
are
other
features
coming
in
terms
of
I,
don't
like
key
variation
or
things
like
that,
but
yeah
those
which
will
be
trickier.
C
C
A
I
can
give
a
really
quick
update
on
the
cluster
API
AWS.
We
don't
know
what
it's
called
yet
work,
I
think
most
people
are
calling
it,
including
her,
which
I'm
sure
it
will
be
another
email
sent
out
about.
You
know
the
right
word
to
use
there
anyway.
A
One
of
the
big
things
that
we're
looking
at
now
is
how
we
handle
resource
mutation
in
AWS
via
the
cluster
API
controllers.
It
looks
like
there's
a
lot
of
talk
around
defining
some
sort
of
new
level
of
grouping
resources
together.
A
resource
set
might
be
a
good
temporary
word
to
use
there
where
one
or
more
resources
in
Amazon
are
idempotent,
leave,
mutated
and
either
created
and
one
fell
swoop
to
the
satisfaction
of
the
program
or
failed
halfway
through
and
then
I'm
done
along
the
way.
A
So
that's
sort
of
like
where
the
engineering
side
of
things
is
focused
right
now
is
figuring
out
the
right
way
to
solve
that
problem
and
then,
as
far
as
the
project
in
general,
we're
still
very
much
in
the
like,
submit
a
markdown
design
phase
of
things.
So
not
too
much
code
is
being
written
right
now,
but
this
is
very
relevant
to
to
the
sig
as
we
are
an
owner
and
it's
it's
kubernetes
new
amazon
and
again.
B
A
B
Guess
something
that
might
be
interesting
to
discuss
here
if
there's
nothing
else
is
there
was
a
lively
discussion
which
didn't
have
a
lot
of
input.
But
maybe
this
group
has
a
lot
of
input
on
it,
which
is
whether
we
should
use
cloud
formation
to
do
that
sort
of
resource
set
concept
where
we
create
a
set
of
resources,
so
the
tool,
the
tool
alternative
suggestions
that
either
we
can
directly
call
the
API
and
try
to
use
like
journaling
or
some
of
the
other,
so
native
xapi.
Some
of
the
address
api
call
support.
B
Idempotency
tokens
are
basically
implemented
ourselves,
the
resource
set
concept
and
then
I
think
Ilya
suggested
an
alternative
might
be
to
do
basically
to
create
cloud
formation
instead
of
manifest
I,
don't
know
what
the
word
is:
the
confirmation
thing
for
each
resource
set
and
have
just
to
hand
it
off
to
cloud
formation,
which
basically
does
a
lot
of
that
item.
Potency
or
effective
idempotency
for
you
and
I
believe
the
one
of
the
alb
cloud
providers
did
something
similar.
Sorry,
one
of
the
alb
ingress
controllers
did
something
similar
where
they
use
the
cloud
formation.
B
The
core
OS
ticketmaster,
one.
So
I
don't
know
if
no
it
didn't
was
it
the
other
way,
there's
land
or
one.
Does
it
land?
Oh
one,
did
it
okay,
so
I
don't
know
if
anyone
has
any
experience
with
programmatically
driving
confirmation
in
this
way
that
they
want
to
share.
But
that's
that
isn't
a
sort
of
topic
of
discussion.
It's
likely
that
I
think
will
happen.
Confirmation
and
API
access,
but
we'll
see
yes,.
A
Which
natural
segue
into
another
update,
which
is
speaking
out,
another
word
for
the
project
and
it
looks
like
variants,
is,
is
winning
so
I
think
we
could
start
to
safely
use.
That
word,
which
would
mean
that
we
would
have
two
variants
of
deploying
kubernetes
and
Amazon,
where
the
variants
are
different
avenues
in
which
we
mutate
resources
that
Justin
just
described.
B
B
And
the
other
one
is
auto
scaling
groups
versus
whether
a
machine
set
which
is
a
set
of
machines
is
materialized
as
an
auto
scaling
group,
whether
it's
materialized
as
and
independent,
a
give
us
instances,
in
other
words,
whether
we
push
that
behavior
down
to
the
80
for
safety
eyewear.
We
keep
it
in
commits.
Yes,
another
variant
up.
We.
B
Yes,
I
mean
you're,
actually
right,
that's
and
I
think
that's
the
the
basis
of
the
the
debate
is,
on
the
one
hand,
AWS
has
auto
scaling
groups
which
work
and
are
fairly
easy
to
use
and
have
the
advantage
that
they
sort
of
self
recover.
So
if
you
turn
off
all
your
machines,
they
come
back
but,
on
the
other
hand,
I,
then
the
different
implementation
they
mr.
an
auto
scaling
group
machine
set
would
almost
definitely
behave
differently
from
a
pure
kubernetes
machine
set
implementation.
So
that
is,
that
is
the.
E
E
So
I
think
that's,
probably
gonna
fight.
My
feeling
is
that
probably
tilts
the
I,
probably
tilts
the
answer,
and
then,
if
you're,
actually
doing
like
any
kind
of
scaling,
operations
up
and
down
you're
gonna
continue
to
run
into
the
same
thing.
So
you
can
turn
the
knob
on
the
ASG
to
get
the
cluster
size
to
go
up
and
down
pretty
efficiently.
But
as
soon
as
you
start
trying
to
like
manage
all
the
nodes.
Literally,
it's
it's
a
pretty
big
hassle.
You
effectively
end
up
kind
of
almost
reimplemented,
a
bunch
of
the
ASG
stuff.
F
F
In
detail
right,
because
if
you
would
the
EBA
route,
but
you
would
have
to
re-implement
a
lot
of
stuff
that
confirmations
that's
right,
for
example,
when
issues
happen,
you've
got
to
roll
back.
You
got
to
keep
state
right.
You
gotta
deal
with
the
eventual
consistency
you
gotta,
keep
owning
all
of
that
stuff.
Stuff
comes
into
picture
when
you
use
a
variant
right
so,
like
you
might
you
might
have
a
simpler
approach
if
you
use
confirmation
right
on
the
edge
I.
B
A
Can
you
hear
me?
Yes,
yes,
I
think
it's
Mondays.
We
did
it
on
Tuesday
last
week,
because
Labor,
Day,
yeah,
I,
think
I
think
it
might
be
prudent
for,
like
me
or
you
just
it
or
whoever
happens
to
be
I've,
been
with
calls
in
a
week
to
kind
of
help
drive
this
conversation
between
the
two
groups,
because
a
lot
of
the
points
that
like,
for
instance,
the
one
that
has
projects
made,
really
would
have
changed
the
discussion
on
the
call
on
Monday.
If
we
would
have
had
that
improving,
had
agreed.
A
Is
having
well
documentation
on
all
of
the
different
avenues
of
doing
something
I.
Remember.
We,
like
a
couple
of
months
ago,
wrote
up
all
the
different
ways
you
might
deploy
kubernetes
on
Amazon
I,
so
it
might
be
prudent
for
us
to
go
through
it
and
come
up
and
say:
okay
out
of
all
of
the
different
ways
you
could
use
the
cluster
API.
This
is
the
one
that
you
know
seems
to
be
working
the
most
efficiently.
A
A
Yes,
so
it's
mostly
under
seed
cluster
lifecycle,
because
that's
what
the
cluster
API
project
started,
but
on
Mondays
there's
an
Amazon
specific
cluster
API
implementation
call
that's
sort
of
like
the
office
hours
or
a
working
group
under
the
working
group
where
we
just
talk
about
code
and
these
sort
of
technical
concerns
that
we're
talking.
I
can
put
a
link
in
the
doc
but
I'm
going
to
meet
while
I
type.
So
I
don't
disturb
you
guys
in
the
keyboard.