►
From YouTube: Kubernetes sig-aws 20170728
Description
Recording of kubernetes sig-aws meeting held 2017-07-28
A
Hello,
everyone-
and
this
is
CJ
WS-
please
make
sure
that
you
fill
in
the
attending
the
the
meeting
document
that
we
have
here.
Please
write
your
name
there
and
we
have
a
few
agenda
items
that
I
added.
So
please
add
your
own.
If
you
want
to
be
able
to
discuss
it,
so
I
wanted
to
make
sure
we
have
something
to
discuss,
especially
some
things
from
last
week.
I
want
to
make
sure
that
we
continue
following
them
and
one
of
the
things
that
we
have
is
to
make
custardy
required.
A
B
A
C
A
A
A
Anybody
seems
shocked
this
one
all
right,
so
the
next
one
that
I
have
here
is
friendly,
ELB
name.
As
you
guys
know.
Now
we
use
the
UID
that
a
DLP
name
and
then
we
kind
of
hash
it
take
out
the
dashes
and
stuff
like
that
and
then
trim
it
to
32
characters.
So
we
wanted
to
see
if
we
can
discuss
a
little
bit
Oh
what
we
can
do
about
making
you'll
be
names.
A
little
more
friendly
and
I
I
put
a
little
blurb
up
there
on
the
possibility
of
but
I.
B
Is
the
name
of
the
EOB
itself
is
not
ideal?
We
do
add
a
tag
as
of
a
couple
of
versions
ago,
so
there
is
a
tag
which
has
a
friendly
name.
The
sort
of
three
challenges
that
always
come
up
on
any
proposal
are
the
fact
that
you
have
to
be
careful
not
like.
We
have
to
think
what
you
do
if
there's
a
collision
between
two
Yogi's
with
the
same
name.
B
A
A
You
know
have
a
template
almost
standardized
model
that
you
can
always
search
for
the
kubernetes,
vo
bees
and
then
have
your
service
name
and
namespace
are
used
to
be
able
to
find
them
and
then
have
a
chunk
of
the
UID
to
be
able
to
differentiate
it
for
other
ones.
They
have
the
same
namespace
and
you
know
if
you're
running
multiple
kubernetes
clusters
in
the
same
code,
it
I,
if
you
guys
want
about.
D
B
I
think
so
I
think
the
clever
bit
of
your
suggestion
is
to
ignore
the
the
which
gets
around
a
lot
of
the
problems
is
that
you
use
a
large
portion
or
a
portion
of
the
UID
yeah,
and
so
we
use
enough
that
you
would
argue
there.
It
is
unlikely,
Clyde
and
I
think
that's
reasonable
and
then
there's
enough
of
the
namespace
and
naming
you
put
in
the
first
eight
characters.
Then
you
give
people
an
idea,
I
think
that's
a
nice
compromise
and
it
gets
around
the
conflict
like
we
cannot
give
it
in
practice.
B
E
E
The
annotation
in
that
case
does
like
I
do
like
the
idea
of
having
ELB
names
actually
be
sensible,
but
it
doesn't.
This
I
mean
this
also
happens
with
with
cloud
formation
templates
right
like
cloud.
The
ELB
names
in
a
CloudFormation
template
are
based
on
the
name
of
the
template,
so
that
actually
is
an
information
leakage
out
to
in
some
ways,
yeah.
E
A
B
A
A
B
A
A
B
B
E
E
I
mean
like
you,
can
do
the
annotation
as
you
create
the
thing
and
then
once
the
name
is
set,
you
know
it's
set
and
we
just
document
that
I
mean
there's
not
a
great
place
to
surface
warnings
to
actually
let
people
know
hey
like
you
know,
we
didn't
do
this
right,
I
mean
we
can
do.
Events
which
would
show
up
in
cuoco,
describe
sister
describe
service
yeah.
D
A
E
E
E
B
B
E
E
That's
ongoing
right,
because
essentially,
what
you
want
to
say
is:
hey,
there's
a
condition
that
that
we
have
a
Mis
configuration
in
the
in
the
in
the
service,
something
that
you
should
be
aware
of,
and
then,
if
they
correct
that
service,
that
condition
goes
away
right,
I
stay.
We
don't
have
an
idea
of
generic
conditions
for
objects.
If.
B
E
Is
that
events
roll
off
right?
So
if
you
did
this
right,
you
have
a
little
and
then
you
know
a
day
later
you
actually
describe
the
thing
won't
show
up.
So
it's
this
this
idea
of
like
how
do
we
actually
have
a
persistent
condition
that
we
attach
to
an
object
without
spamming,
the
event?
Because
if
you
could
say
well
we'll
just
log
it
every
15
minutes
right
and
it's
like.
E
A
B
A
B
B
Feel
like
I,
feel
like
the
proposal
that
Lewis
made
is
sound
in
the
use.
The
annotation
put
some
bytes
of
the
UID
in
there
to
ensure
no
collisions.
There
is
a
procedure
for
avoiding
collisions
and
for
adopting
existing
ones.
We
will
we
could
log
an
event.
There
are
issues
with
lucky
with
just
logging
an
event,
but
there
was
apply
across
the
system
and
I
think
people
are,
there
is
a
win.
You
do
have
a
window
where
you
notice
your
DOB
has
a
funky
name
or
doesn't
have
the
name.
D
F
A
A
B
Is
that
we
ignore
it,
we
do
the
same
thing
baby
nor
it
today
we
we
only
look
at
that
flag
on
on
create,
although
we
also
then
pick
the
subnets
appropriately.
So
it's
probably
a
bad
idea
to
change
it.
I,
don't
know.
If
there's
a
way,
we
can
block
that
I
guess
there
is,
but
we
would
presumably
I
see
that
an
admission
controller
or.
E
That's
the
event
stuff
there's
this
idea
of
marking
events
of
sort
of
it
is
an
event
series
stayed
ongoing
and
finished,
and
so
that
you
can
collapse
these
things
and
you
can
sort
of
like
periodically
report
a
state,
an
error
state
and
then
being
able
to
see
that
so
this
this
comes
up
a
lot
when,
like
let's
say,
you're
trying
to
deploy
a
pod
and
it's
having
a
problem,
pulling
an
image
right,
it'll
keep
you
trying
to
pull
that
image
over
time.
It's
an
error
back
off
type
of
thing
right.
E
It's
a
similar
type
of
thing
right,
there's
some
sort
of
long-term
thing
that
somebody
has
to
make
some
change
to
fix,
or
something
else
has
to
sort
of
come
together.
So
so
you
know
I'm
thinking
that
the
wheels
are
turning
here.
Is
that
do
we
have?
Is
there
a
need
for
a
generic
sort
of
pr2
event,
which
is
sort
of
like
object?
Conditions
that
you
know
are
ways
to
surface
configuration
errors,
warnings
that
that
you
know
users
might
want
to
know
about
that,
can
be
caught
at
admission
time
or
we
don't
want
it.
E
B
A
B
B
Would
be
less
bad
because
we
would,
we
would
not
have
to
actually
call
out
to
the
cloud
provider
to
tell
whether
the
annotation
had
changed
but
like
the
admission
control
are
currently
tags
volumes
with
their
zones,
and
that
is
very
unpopular
because
it
makes
an
AWS
API
call
in
seven
eight.
Oh
there's
already
an
AWS
admission
controller,
the
the
volume
one
tags
when
you
create.
B
A
B
E
I
mean
like
here's.
The
thing
what
we
really
want
to
do
is
essentially
subclass
the
the
service
so
that
we
can
actually
add
a
bunch
of
sort
of
strongly
typed
fields
to
it.
We
don't
have
the
mechanisms
to
do
that
because,
like
like
web
api's
right
but
but
so
much,
everything
that
we've
been
doing
so
far
is
about
the
spec
side
of
it
and
hansung
this
back
with
some
domain-specific
things.
This
would
be
enhancing
status
with
something
that's
domain-specific
and
so
I.
E
You
know
there
may
be
people
that
barf
at
this,
but
I'm
just
throwing
the
idea
out
there.
You
talk
about
the
status
in
the
object
itself
and
I'm
the
spec
well,
and
so
so
logically,
the
annotations
that
we
have
now
are
extending
this.
The
spec
part
of
the
service
object
right
there
in
an
annotation,
but
like
from
the
users
point
of
view
this
this
would
logically
slot
into
the
spec
if
we
had
a
way
to
extend
spec
in
a
domain-specific
way.
E
Okay,
right
so
to
be
able
to
reflect
these
error
conditions,
or
these
warnings,
that's
logically,
belongs
in
the
status,
and
so
the
detract
roughly
is
that
the
user
right
spec
the
system's
right
right
status.
We
can't
do
that
because
this
is
all
domain-specific
to
AWS,
and
so
perhaps
the
way
to
do
it
is
that
there's
a
set
of
annotations
that
the
user
writes
that
are,
you,
know,
spec
annotations
and
then
there's
an
annotation
or
two
that
the
that
the
system
rights
which
are
status,
annotations
and.
B
A
B
D
B
And
so
one
of
the
changes
that
was
made
I
think
for
OpenStack
was
that
they
pushed
down
the
node
objects
themselves
rather
than
the
node
names
into
the
ensure
load
balancer
function
of
the
cloud
provider,
which
actually
is
really
handy
because,
for
example,
on
AWS
it
means
we
don't
said
like
Mac
the
names
to
the
ADA
basic
instance
IDs,
because
they
are
right
there
in
the
node
object.
Oh.
B
There
were
two,
so
there
are
two
yes,
there
are
two
things
for
that
rice
is
one
of
which
is
that
the
master
needed
to
be
able
to
resolve
the
name
to
the
node.
That's
gone
away.
If
you
change
the
reconciliation,
the
resolver
order,
the
other
one
which
remains
a
problem
is
the
cloud
provider.
Api
is
primarily
defined
in
terms
of
node
names
and
AWS
is
defined
in
terms
of
instance,
IDs,
and
it's
hard
to
do
that.
Mapping.
F
B
So
that's
that's
the
gotcha
and
yes,
so
it
would
be
if
we
had
if
we
could
watch
the
nodes.
For
example,
we
could
presumably
like
know
when
a
node
when
it
was
a
new
node
or
we
could
use
the
UUID
and
we
I
think
we
should
use
the
node
ID
wrote
in
the
note
name
or
we
should
just
get
the
node
object,
but
but
there's
a
lot
of
long
term.
Like
see
cloud
type
discussions
to
happen,
there
I
think.
B
E
A
D
E
B
In
there
that
there's,
if
anyone's
looking
for
something
to
submit
like
you
know,
one
to
get
their
teeth
into
communities,
I
saw
that
there's
a
healer
in
progress
for
kms
for
GCE
kms
support
for
the
sed
encryption
there,
and
that
would
be
a
logical
one.
Once
that
series
merges
to
add
the
a
diverse
equivalent,
and
so
we'll
dig
up
the
link
for
right
for
that.
Pr
I
always
think
about
doing
it,
but
it
is
also
a
nice
way
to
get
into
the
race.
If
someone
is
looking
for
yeah.