►
From YouTube: Kubernetes WG K8s Infra - 2019-07-10
Description
A
Okay,
hi
everybody
today
is
Wednesday
July
10th,
you
are
at
the
Katyn
for
a
working
group.
Bi-Weekly
meeting
I
am
Aaron
of
sick
beard.
I
will
be
your
host
today,
you're
all
going
to
adhere
to
the
kubernetes
code
of
conduct
by
being
your
best
selves,
and
you
can
go
watch
yourselves
doing
that
on
YouTube
later
when
I
post,
this
recording
I
will
go
ahead
and
post
the
agenda
in
chat.
I
figured
the
usual
thing.
A
B
A
C
C
A
Well,
just
let
me
know
in
chat
and
I'll
post
something
about
that
in
the
billing
issue
and
I
feel,
like
that's
kind
of
all,
I
want
to
talk
about
with
respect
to
building
this
week
unless
we
have
any
other
follow-ups.
There
was
other
stuff
about,
like
her
name
space
stuff
and
how
we
would
analyze
billing
for
storage,
but
I,
don't
think.
We've
made
any
progress
on
either
of
those.
Oh.
G
A
A
B
I
read
over
our
nose
PR
with
a
fine-tooth
comb.
I
had
a
bunch
of
comments
and
flags.
I
thought
were
missing,
which
I
guess
if
Christoph
transliterated
that
script
and
the
terraform
would
be
wrong
also
or
wrong.
Arguably,
wrong
I
was
hoping
that
we
could
get
agreement
on
the
script
being
the
the
API
that
I
know
so
that
if
we
have
agreement
like
this
is
what
the
cluster
we
want
to
look
like
looks
like
then
I
can
compare
it
pretty
easily
against
the
terraform.
That's
what
I
was
really
hoping
for.
H
Well,
sorry,
I
guess
it's
just
a
misunderstanding
from
what
we
had
the
last
time
we
met,
because
I
thought
we
were
going
to
focus
on
the
terraform
script
and
not
the
bash
script,
because
I
didn't
want
to
Arno
to
basically
put
in
a
bunch
of
work
to
fix
up
the
bash
script
if
we're
just
going
to
chuck
and
toss
it
at
least
like
the
high
level
direction
of
like
hey.
This
looks
acceptable
enough
for
us
to
change.
H
Settings
around
to
match
is
yeah
like
as
far
as
like
gke
specific
settings
I
these
even
the
settings
that
we
choose.
Even
if
we
like
go
with
this
script
once
we
start
actually
like
putting
stuff
out
there,
we
may
need
to
choose
non-default
things
for
a
particular
cluster
like
we
may
need
to
go
with
SSDs
for
prowl,
because
I
know
Prowse
clusters
just
converted
to
all
SSDs
where
they
were
previously
spinning
desks.
So
things
like
that.
H
May
change
where's
like
the
default,
maybe
just
spinning
disks,
but
then
specific
types
of
clusters
like
there
may
be
one
offs
that
we
need
to
change
and
alter
I.
Don't
know
I
scraped
like
from
that
from
the
terraform
perspective,
I
tried
to
make
it
readable
and
I
tried
to
make
it
like
with
comments
and
stuff,
and
I
tried
to
also
put
in,
like
actually
manually
specify
non
default
settings
so
that
Earth's
very
actually
call
out
what
the
default
is
and
like
be
explicit
about
the
default.
That
way.
B
Okay,
so
maybe
I
misinterpreted.
Last
time,
then
I
focused
on
getting
the
script
to
a
completion
point,
but
if,
if
we
agree
that,
that's
not
what
we
should
do
like
I,
don't
honestly
I,
don't
see
any
reason
why
not
to
use
terraform
other
than
I,
don't
know
it
well
enough
to
actually
review
it
meaningfully.
I
can
make
my
next
block
of
review
time
go,
learn,
tariffs
or
which
doesn't
seem
that
daunting
honestly,
but
I
have
to
go.
B
F
H
It's
in
it's,
the
GK,
like
the
namespace,
specific
usage,
stuff
and
dumping
that
out
to
bigquery
that
bit
was
is
still
in
beta
on
gke,
so
that
hadn't
made
it
into
the
beta
provider
yet
so
that
it
was
literally
like
the
week
that
I
was
working
on.
It
was
also
the
week
that
they
were
working
on
it
and
then
it
made
it
in
I
was
able
to
test
it.
Basically
like
the
day
before
I
put
the
PR
up
and
then
it
was
met.
H
It
was
that
head
and
then
the
publish
provider
was
published
a
few
days
later.
So
the
version
that's
in
the
sea,
biker
Kate's
cluster,
like
the
git
repo.
That
is
like
something
that
anybody
can
clone
out
and
it'll:
pull
down
the
right
versions,
the
providers
and
have
the
right
connections
to
things
to
to
make
it
work.
Okay,
so
the.
F
H
F
H
A
Wouldn't
say
it
was
just
you
that
interpreted
that
way.
Tim
I
thought
that
the
goal
for
this
week
was
to
get
to
the
point
where
we've
had
people
like
iterating
on
gaining
clusters,
often
really
exercising
this
and
I
feel
like
what
I'm
hearing
is.
We
haven't
gone
to
the
point
where
a
person
is
actively
standing,
a
cluster
up
and
putting
stuff
on
it.
Tearing
the
cluster
down
and
I'd
want
us
to
get
at
that
point.
A
I
am
very
sympathetic
to
the
amount
of
time
that
has
been
spent
on
the
bash
I'm,
even
fine
with
us,
just
like
landing
at
some
place
so
that
it
lives
somewhere
other
than
a
PR.
If
we
need
something
to
compare
against
as
a
reference,
I
do
feel
like
everybody
was
leaning
hard
towards
terraform
the
last
time
we
met
we're
still
leaning
in
that
direction.
Now
I
am
fine.
B
H
So
the
two
things
that
anybody
needs
to
be
able
to
test
this
out
is
access
to
the
test
project,
because
right
now
things
are
set
up
in
such
a
way
that
there's
like
oh
look,
there's
a
hard-coded
value
in
the
terraformer
config.
That
goes
go!
Do
it
in
this
project
so
that
you
don't
accidentally
mess
it
up
and
do
that
on
something
else.
So
you
need
access
the
test
project
and
you
need
access
to
the
state
storage
on
terraformed
I/o,
because
that
was
just
the
easiest
place
to
dump
the
state
storage.
H
H
B
F
H
A
H
B
B
I
J
A
J
B
A
J
B
You
mean
like
which
flags
we
want
for
all
clusters,
verses
which
flags
are
decided
per
cluster.
Exactly
I,
don't
know
the
answer
to
that
yet
I.
If
we
can
get
the
first
cluster
to
a
place
where
we
think
we're
the
first
cluster,
in
my
mind,
is
this
utility
cluster
that
runs
the
sort
of
mishmash
of
random
stuff.
H
B
A
A
Okay,
I
think
you
are
seeing
my
awesome,
dark
mode,
get
a
project
board,
and
so
I
talked
about
terraform,
and
this
is
sort
of
our
umbrella
issue.
But
this
is
really
what
we're
working
on
right
now
is
iterating
on
burning
them
cluster
and
recreating
it
in
some
automated
manner.
There
was
this
issue
here
about
like.
Should
we
be
doing
something
about
our
back
rolls
that
are
the
same
as
I
am
rolls
came
back
a
question
whether
or
not
this
was
the
same
as
using
Google
Groups
for
more
fine-grain
cluster
authorization,
I.
A
Kind
of
feel
like
what
is
this
sounds
like
tie,
tie
a
role
to
a
Google
Group,
but
this
doesn't
necessarily
describe.
But
what
things
should
that
role
have
access
to,
which
is
sort
of
what
I
was
led
to
believe
I'm
fine,
with
like
closing
one
issue
and
dumping
that
scope
and
another
thing.
But
am
I
capturing
what
we
think
this.
B
H
H
The
one
advantage
is
if
we
had
a
project
where
we
have
like
multiple
clusters
in
the
same
project,
but
we
only
want
to
give
people
like
we
want
to
give
to
people
different
access
to
different
clusters
within
the
same
project.
I
think
one
cluster
you
get
right
versus
another
cluster.
You
get
read
right.
B
And
well,
and
actually
because
yes,
it's
true
for
clusters,
it's
also
true
for
things
like
storage
buckets.
So
if
we
define
roles
for
the
I
am
side
of
things,
then
I
don't
have
a
fine-grained
way
of
saying
the
CSI
team
has
access
to
the
CSI
staging
bucket
and
the
core
DNS
team
is
exit
to
the
coordinates
bucket
and
not
the
vice-versa.
But.
B
G
H
You
know
it
also
gets
to
be
the
auditing
part
of
the
Triple
A
as
well,
because
you,
if
it
if
you're
handling
all
the,
are
back
permissions
on
the
cluster.
If
you
have
cluster
permissions,
you
can
also
elevate
other
people
into
it
and
mid
position
on
the
cluster.
Like
you
can
say,
hey
this
random
Gmail
account.
B
A
B
Have
no
objections
to
that
I
will
now
that
I
understand
the
difference
between
this
and
the
other
issue.
I
will
think
about
whether
the
handful
of
global,
universally
applicable
roles
make
sense
to
make
into
actual
roles,
even
at
the
organization
level,
which
we
can
then
just
inherit
to
all
projects,
it
might
actually
make
things
simpler.
Can
you
help
me
understand
what
the
difference
is
between
these
two
is?
She
is,
then.
This
is
about
the
enumerator.
Our
back
is
about
access
to
things
within
the
cluster
within
a
gke
cluster.
B
The
I
am
roles
are
about
the
access
to
cloud
resources
that
are
spread
across
different
projects.
The
best
example
that
I
can
come
up
with
is
the
artifact
admin's.
We
have
this
group
called
artifact
admin's,
which
is
ostensibly
people
who
can
help
unstick
any
situation
with
any
storage
project.
So
all
the
staging
projects
and
all
the
projects
and
what
we've
done
for
every
staging
project
is
just
grant
in
it.
Grant
that
group
access
to
the
bucket
that
we
create
where
and
the
the
axes
that
we've
granted
them
is
like
two
or
three
different
permissions.
B
B
B
B
E
H
A
A
A
F
So
the
the
thing
that
I
wanted
to
start
in
kids
was
because
there
was
a
lot
of
people
asking
for
stuff,
at
least
getting
to
a
point
where
they
have
a
staging
repository.
We
are
ready
for
that
part,
even
though
you
know,
for
example,
in
the
publishing,
but
we
would
like
a
greater
time
for
the
images
to
stay
there
before
getting
clear
for
sure.
So
that's
the
reason
why
I
wanted
to
you
know
get
that
process
going.
So
a
few
people
have
asked
for
the
staging
repositories
and
I
got
access
to
run
additional
scripts.
F
Yesterday's
and
I've
been
doing
that.
So
so
that's
the
good
news.
Then
there
was
also
a
talk
on
the
slack
channel
between
Amy
and
Linus
and
Jim
about
what
more
needs
to
be
done
to
actually
run
the
promotion
stuff
and
get
people
to
log.
You
know
the
shah's
for
a
you
know,
doing
the
update
the
promotion
from
the
staging
repositories
to
the
final
repositories.
F
F
K
Is
actually
one
more
thing
which
is
as
a
convenience
like
function
and
we
should
have
the
promoter
understand
how
to
reconcile
more
than
one
manifest
at
a
time,
because
the
current
situation
is,
if
you
were
to
try
to
add
a
bunch
of
new
manifests
for
newsagent
repos
for
the
promoter,
you
would
have
to
each
time
update
the
proud
to
say:
hey
use
this
manifest
I
think
that's
very
cumbersome,
so
we
don't
want
to
do
that.
So
there
is
an
open
issue
on
deja
tractor
for
the
promoter
on
this
topic.
K
I've
labeled,
this
and
other
stuff
related
to
e3
tests
as
priority
like
critical,
urgent,
so
I
think
those
are
the
remaining
issues
to
get
us
past.
The
gate
of
you
know
it's
guess
it's
widely
available
or
GA,
but
there's
also
one
other
topic.
That's
been
on
everybody's
mind,
I
think,
which
is
disaster
recovery
which
hasn't
really
been
fleshed
out
yet
so
one
part
of
that
is
actually
actually
the
other
side
of
the
same
coin
is
disabling
the
promoter
from
deleting
images.
K
That's
actually
really
easy
to
do
you
just
you
know,
move
that
code
out
from
the
binary,
so
it's
not
possible.
The
other
side
is,
you
know
in
case,
for
whatever
reason
we
need
to
restore
images.
You
know
disaster
recovery,
that's
like
another
topic,
but
I
don't
know.
Tim
has
express
concerns
about
having
to
have
that
in
place
before
we.
You
know
announce
that
it's
available
for
white,
you
know
consumption,
but
I
don't
know.
Maybe
you
could
elaborate
to
him
right.
B
What's
that
story
today,
this
story
today
is
at
least
mitigated
by
the
fact
that
we
have
one
source
repo
with
one
promoter
that
is
controlled
by
about
six
people.
Once
we
go
broader
like
the
there's,
a
I,
don't
know
how
many
people
have
access
to
the
credentials
that
prow
holds
that
the
promoter
can
push
I,
don't
know
for
sure
how
that's
secure
and
like
it
feels
to
me
like
the
chance
of
a
leak
of
those
credentials,
is
much
higher
now
and
honestly.
B
I'm
not
super
happy
with
where
we
are
today
anyway,
like
it
I,
honestly,
sort
of
ulcer
it
ulcerative
about
it,
and
so
the
the
sooner
we
have
a
story
in
place.
Even
if
the
story
is
simply,
we
have
two
promoters
that
push
to
two
separate
repos
and
one,
and
they
have
different
credentials
or
something.
You
know
I'm
not
sure
exactly
what
a
good
story
would
be
honestly,
given
that
GCR
doesn't
have
a
way
to
prevent
deletion.
K
B
Exists
today,
but
it
will
be
exacerbated
by
being
much
more
public.
The
credential
and
the
set
of
people
who
are
using
it
will
be
much
broader
or
the
set
of
people
who
will
be
having
access
to
it.
Maybe
I'm
wrong,
maybe
I'm
blowing
it
out
of
proportion.
I
feel
like
if
we
have
not
had
impetus
to
fix
this.
So
far.
If
we
go
live
with
this,
we
won't
have
the
impetus
to
fix
it
again.
E
A
Is
also
a
pool
of
like
six
ish
people,
I
have
a
sort
of
longer-term
interest
of
growing
the
size
of
that
pool,
although
we
can
figure
out
how
to
do
that,
while
restricting
their
access
to
secrets,
I,
just
I,
think
what
I'm
hearing
from
Tim
is
not
that,
like
this
moving
to
the
container
image
promoter,
would
require
us
to
invent
a
whole
new
disaster
recovery
disaster
recovery
process.
For
a
technical
reason,
it's
more
tim
is
concerned
that
it
may
be
more
likely
that
we
encounter
and
oops.
B
A
bug
in
the
promoter
or
a
malicious
attack
on
the
promoter
code
or
somebody
leaked
a
credential
or
whatever
it
just
feels
broader
and
I'm.
Trying
to
wear
my
responsible
adult
hat.
We
can't
go
back
and
shut
off
the
existing
repository,
but
I'm
really
sort
of
anxious
about
the
lack
of
sanity
here.
So.
A
B
Might
be
that
might
be
an
acceptable
answer.
It
might
be
simply
that
we
have
a
a
separate
registry
that
we
keep
as
a
snapshot
of
Kate's
Tadeo
from
you
know,
every
three
hours
something
I
think
I
would
accept
something
like
that.
As
an
answer.
I
just
want
somebody
to
have
written
it
down
and
said
here's
what's
going
on
and
if
God
forbid,
we
had
to
do
a
full
restore,
even
if
it's
manual,
here's
how
we're
going
to
do
it
just.
I
H
Yeah
that
that's
the
same
risk
that
we
have
with
all
the
credentials
that
we
have
but
like
there's,
there's
there's
ways
we
can
mitigate
that
in
prowl,
like
we
give
prowl
high
like
high
level
credentials
right
now,
anyways
like
it,
has
multiple
owner
keys
too,
who
are
github
like
our
entire
github
organization.
So
there
are
patterns
for
using
like
giving
very
sensitive
credentials
to
prowl
and
running
them
in
a
way
that
is
safe
and
running
them
away
from
the
PR
code,
running
them
away
from
the
build
code.
D
It
seems
like
there's
like
three
different
ways
that
we
can
tackle
this
well
accommodate.
We
could
do
all
three,
which
is
removing
the
deletion,
which
is
already
github
issue,
protecting
the
credentials,
and
then
the
third
one
is
the
snapshot
of
the
kata
Kas
registry
right.
Is
that
what
we're
kind
of
all
agreeing.
B
A
A
B
A
H
F
F
A
Yes,
so
so
you're
saying,
we've
opened
up
the
gates
for
everybody
to
have
a
staging
repo,
but
we're
gonna
be
really
selective
about
who
we
actually
promote
from
the
staging
repo.
Okay,
wrapped
up
in
this
I'm
hearing
an
assumption
that
we're
gonna
start
with
with
sub-project
artifacts
before
we
consider
promotion
of
components,
correct.
F
The
first
one
was
the
cube
cross
thing
right.
We
want
you
to
do
the
Q
cross.
So
let's
start
with
that,
we'll
run
through
the
whole
thing
and
make
sure
that
all
the
pieces
are
there
and
we
know
how
to
update,
for
example,
the
pro
with
the
new
Manifest.
Even
if
it's
by
hand
right
just
making
sure
that
you
know
the
golden
path,
isn't
there
and
then
we
can.
We
start
speaking
it
I.
B
B
We
can't
flip
the
vanity
name
until
everything
is
done,
which
means
that
in
the
meantime,
anybody
who's
using
the
promotion
will
be
using
a
name
that
isn't
the
vanity
name.
Does
that
make
sense?
And
what
I
want
to
not
happen
is
for
that,
like
the
the
physical
address
to
be
propagated
too
widely,
because
we
have
a
virtual
address
that
we
want
people
to
use,
and
we.
C
A
Think
I
hear
your
suggestion
DIMMs,
but
I
just
want
to
make
sure
like
my
my
goal
would
be
to
suggest
that
we
choose
something
like
cluster
API
as
the
prototype,
given
the
number
of
people
who
have
approached
us
from
that
sub
project.
But
I
heard
you
say,
like
people
who
aren't
working
on
this,
so
yeah
that's
got
suppose
would
be
fine
too.
A
B
Fine,
just
getting
a
few
external
people
to
say
yeah
this
process
doesn't
suck
because
if
it
sucks,
then
we
throw
it
back
at
lightness
and
tell
them
to
do
it
again,
but
I'm,
assuming
that
we're
not
going
to
get
any
sort
of
fundamental
disagreement
with
the
with
the
approach,
maybe
that's
a
bad
assumption,
but
I'm
hoping
I'm,
hoping
it's
not,
but
before
we
can
do
the
the
legacy
import.
We
we've
had
a
conversation
recently
too
about
how
we'll
bring
forward
all
the
legacy,
images
and
I
think
we've
got
a
rough
solution
to
that.
B
F
B
They
shouldn't
because
the
format
is
effectively
the
same
as
docker
right
today
you
have
dr
dot
io
/
vu,
/
foo
colon
tag,
and
so
we
would
have
Kate's
Duchy
CR
that
IO
a
/foo
slash,
foo
colon
tag,
so
it
shouldn't
be
syntactically
actually
closer
to
docker
than
what
we
have
today
from
what
I've
seen
every
all
the
image
pullers
that
I've
looked
at
are
fine,
with
both
models.
Now,
whether
we
want
to
add
arbitrary
subdirectories
beyond.
That
is
a
different
question.
I
mean.
F
B
It
by
giving
us
a
name
for
their
staging
repo,
okay
right,
so
today,
we've
got
about
8
or
something
we
should
probably
ping
the
owners
of
those
8
to
make
sure
that
they're,
okay,
with
those
names
being
the
names
at
which
they
get
published,
and
if
not,
we
can
make
one
clean
up
before
we
have.
You
know
80.
B
H
Here:
here's
here's
a
thought
when
we
did
so
when
we've
been
doing
these
things
in
the
github
management
sub
project,
we
created
an
issue
tent.
We
started
off
with
the
issue
template
first
because
we
didn't
have
documentation
and
we
didn't
want
to
teach
everybody
yet
how
to
do
it,
because
a
lot
of
the
parabola
stuff
was
in
flight,
so
people
create
an
issue
and
then
somebody
would
go
and
enact
that
considering
right
now,
we
still
need
to
like
somebody
from
our
side
still
needs
to
go
and
manually
run
steps
to
make
it
happen.
H
B
B
A
F
B
F
Have
a
problem
with
Stephens
email
address
some
basically
he's
trying
to
he
he's
not
able
to
access
all
the
resources
that
I
created
yesterday
for
the
release
test.
Infrastop,
so
he'll
need
help.
Debugging
I
suggested
if
somebody
else
other
than
Stephen
in
that
group,
Google
Group
go,
try,
try
it
out
and
let
us
know
if
there's
a
problem
or
not
so.
B
H
Had
a
I
just
like
cursory
read
the
things
I
think
he's
trying
to
access
the
entire
projects
dashboard
instead
of
just
the
GCS
stuff
and
we've
scoped
the
permissions
that
you
don't
get
permissions
to
all
the
things
in
the
project.
You
just
get
permissions
to
the
exact
things
you
need
for
the
exact
thing,
you're
doing
so
I
think
just
the
way
he's
accessing
it
is
is
wrong,
because
the
previous
system
has
way
more
permissive
permissions
and
for
what
it's
worth
I'm.
If.
B
E
F
F
B
A
H
Just
gonna
seed,
this
topic
I
think
maybe
we
should
dedicate
some
time
to
this
next
time.
I
think
the
meeting
as
it
was
today.
We
got
a
lot
done
and
was
very
helpful
to
to
to
get
through
the
things
that
we
got
through,
but
as
a
larger
concept,
I
was
looking
through
Kate,
Co,
/lib
and
I
started
feeling
like
wow.
This
really
feels
like
the
hack
directory
in
cake,
Hey
and
then
started
getting
really
scared.
I
don't
want
to
make
another
hack
directory.
H
My
personal
preference
would
be
like
it
write
it
and
go
right
and
go
right
in
like
super
like
POSIX
shell
or
like
a
make
files
like
keep
the
stuff.
That's
not
go
very
simple
if
you
need
something
that
is
more
complex
like
if
you
need
an
array
ready
to
go
would
be
my
my
assertion,
but
it
definitely
needs
a
bigger
discussion
right.