►
From YouTube: k8s-infra-team's Bi-Weekly Meeting for 20201028
Description
k8s-infra-team's Bi-Weekly Meeting for 20201028
A
A
A
C
A
B
A
D
D
A
D
Comment
to
date,
we've
not
really
spent
any
time
not
much
time
trying
to
optimize
for
this.
At
this
point,
I
think
that
is
still
the
right
choice.
I
don't
think
it's
worth
the
energy
in
particular
to
try
to
drive
these
numbers
down.
There
probably
will
come
a
time
when
it's
worth
our
group
spending
time
on
that.
I
don't
think
that
time
is
now.
A
D
Work
so
one
of
the
things
on
my
to-do
list
is
to
do
a
slightly
more
detailed
projection
than
that
like
taking
advantage,
taking
into
account
the
slope
of
the
organic
growth
of
what
we
currently
have.
I'm
happy
that
we
haven't
significantly
changed
anything
in
the
last
few
months.
It
helps
me
to
make
that
projection,
but
it's
on
my
to-do
list.
D
D
A
B
Well,
I
opened
the
issue,
I
think
that
one
year
ago
or
something
but
since
I
was
the
only
one
using
it,
I
I
really
don't
care,
and
this
week
or
past
week
somebody
commented
on
the
issue
and
we
are
going
to
release
dual
stack.
So
I
think
that
it
will
be
a
bit
taught.
You
know
claiming
that
kubernetes
has
ipv6
and
our
web
page
or
these
things
doesn't
have
ipv6.
B
So
I
was
checking
into
the
into
someone
in
the
meeting
commented
about
the
next
steps,
and
I
was
checking
that
the
google
cloud
has
an
ipv6
termination.
So
I
don't
know
if
this
is
because
some
technical
limitation
or
people
not
stepping
up
for
doing
it,
because
I
I
can
have
time
for
implementing
this.
B
A
I
feel
like
there's
a
bun
yeah.
Sorry
go
ahead.
I
was
just
gonna
say
I
feel
like.
There
are
two
questions
here.
The
first
is
whether
or
not
our
dns
can
support
serving
ipv6
addresses,
as
well
as
ipv4
addresses
right,
yeah,
yes,
queries
which,
I
believe
it
can.
Second
question,
is
the
infrastructure
that
some
of
these
records
point
to
can
that
support
ipv6
the
the
issue?
The
comment
posted
in
the
issue,
specifically
references
act.kubernetes.io,
which
is
not
community-owned
infrastructure?
A
I
am
one
of
the
googlers
who
is
in
charge
of
responding
to
the
release,
engineering's
team's
requests
to
build
debian
and
rpm
packages
and
pushing
to
that
internal
repo,
but
what
would
be
involved
to
move
to
community
would
be
for
the
community
to
stand
up
their
own
repository
and
get
packages
there.
I
think
the
sticking
point
has
always
been
that
the
signing
keys
that
are
used
right
now
are
google's,
which
makes
the
packages
relatively
trustworthy.
A
A
B
A
D
I
don't
know
how
the
app
stuff
is
set
up
in
the
back
and
how
we're
exposing
it.
I
imagine
if
it's
through
this
normal
google
app
site,
then
it's
not
through
a
cloud
load
balancer,
but
through
a
gslb
or
a
gfe,
rather,
which
is
our
internal
version
of
the
cloud
load
balancer,
and
so
the
changing
of
that
config
would
be
more
difficult.
Now,
if
that's
already
exposed
on
v6,
I
mean
that's
the
question
antonio.
D
C
B
C
B
D
D
D
B
D
D
A
D
Yeah,
so
I
I
put
aside
a
bunch
of
time
over
the
next
few
weeks
I
told
aaron
this
this
week.
I
put
aside
a
bunch
of
time
over
the
next
few
weeks.
I
cancelled
a
ton
of
you,
know
internal
meetings
and
stuff,
because
there's
a
bunch
of
things
in
community
that
have
sort
of
languished
for
lack
of
attention,
so
I'm
trying
to
get
through
those.
This
certainly
can
fit
under
that
umbrella.
D
Antonio,
if
you,
if
you
want
to
try
it,
I'm
happy
to
take
a
look
and
do
some
manual
poking
at
our
end,
just
to
make
sure
that
everything
works.
The
way
it's
supposed
to
work,
but
also,
we
should
put
you
in
the
right
groups
that
give
you
the
authority
to
actually
go.
Try
these
things
so
that
it's
not
always
you
know
aaron
or
me
who
has
to
try
anything.
You
should
make
sure
that
you
have
an
appropriate
permission
that
you
could
actually
do.
B
A
Just
to
summarize,
where
we're
at
briefly,
we've
migrated
all
of
those
jobs
except
any
of
the
build
jobs,
and
that
is
because
the
build
jobs
currently
right
to
a
bucket
called
kubernetes
release,
dev,
which
is
owned
by
the
google
containers
gcp
project
which
doesn't
allow
outside
google
accounts
to
write
to
it,
and
we
also
discovered
there
was
a
kubernetes
ci
images,
gcr
repo,
which
is
locked
down.
Similarly,
so
we've
gone
through
and
created
equivalent
buckets
and
gcr
repos
over
in
kate's,
I
o
arno.
E
A
E
So
basically,
this
the
question
is
is
about
to
to
issue
I'm
facing
basically
the
current
pro
instance
running
in
the
google
owner
project.
So
the
idea
was
is
to
set
up
a
station
pro
instance
running
in
maybe
triple
a
or
any
non-google
gk
cluster,
so
we
can
identify.
The
pain
point
relate
to
the
migration
to
pro
to
the
yeah
to
the
pro
migration.
E
A
Okay,
right
right,
I
have
objections
to
the
idea
of
using
well
we'll
see.
I
I
personally
have
objections
to
using
forked,
repos
or
separate
orgs
for
testing
out
kubernetes,
kubernetes
and
kubernetes
release
changes.
This
came
up
in
the
github
management
meeting
where
my
microphone
wasn't
working,
but
essentially
it's
it's
not
clear
to
me.
What
that
increased
complexity
will
gain
us
that
using
branches
cannot
and
for
better
or
for
worse
once
you
start
using
a
repo,
that's
kind
of
off
the
beaten
track
and
doesn't
receive
production
level
traffic.
A
So
there
is
a
proposal
that
was
put
forth
a
couple
months
ago
through
sig
testing.
I
I'm
gonna
mess
up
who
proposed
it.
I
think
it
may
have
been
chi
zhang.
It
could
have
also
been
chow
dai,
I'm
not
I'm
not
sure
which
of
them
worked.
I
think
both
of
them
worked
on
it,
but
essentially
they're
trying
to
propose
using
a
staging
pro
instance
that
has
end-to-end
tests,
sort
of
automatically
open
up,
pull
requests
and
see
prow
exercise.
A
A
If
it
doesn't,
I
think
if
you
want
to
take
the
lead
on
setting
it
up
in
triple
a
or
elsewhere.
That
sounds
great
to
me.
Okay,
it
said
a
lot
of
words.
Let
me
tell
you
alright,
the
idea
of
using
a
staging
prow
instance
great.
That
sounds
good
to
me.
We'll
need
to
be
careful
about
dueling
prows.
My
my
experience
is,
if
you
point
to
prows
against
the
same
repo,
it
doesn't
necessarily
work
out
great
all
the
time.
A
A
F
A
I
I
think
he
was
still
slightly
uncertain
whether
or
not
kind
clusters
were
going
to
automatically
benefit
from
mir.gcr.io
or
whether
there
was
something
that
needed
to
be
configured
to
make
them
use.
Mirror.Gcr.Io,
oh
antonio,
just
since
you're
here
and
you're,
pretty
prevalent
and
kind
do
you
have
any
idea
where
that's
at.
B
A
So
so,
just
to
summarize,
where
I
believe
we're
at
is
that
all
gke
clusters
by
default
are
configured
to
use
mirror.gcr,
dot
io.
So
our
proud
build
clusters.
If,
when
they
pull
down
images
to
run
pods,
that's
that's
cached,
then
any
kubernetes
clusters
that
are
stood
up
via
cubeup.sh,
which
would
be
all
the
clusters
used
for
release
blocking
and
merge
blocking
jobs
are
also
configured
to
use
mirror.gcr.io
by
default.
A
So
if
a
job
runs
a
script
that
calls
docker
poll
or
whatever,
I
think
there
is
some
configuration
that
needs
to
happen
in
the
image
to
configure
that
instance
of
docker
to
pullpremier.gcr.io,
and
I
had
a
pr.
I
was
working
on
to
put
that
in
the
cubekins
image,
but
it
could
be.
Somebody
else
got
ahead
of
me
on
that.
A
A
F
A
We
have
enumerated
so
so
we've
enumerated
it
a
couple
ways.
I
still
don't
think
I've
caught
literally
everything
by
all
1700
of
our
jobs,
but
we've
enumerated
looking
through
the
kubernetes
code
base.
What
images
are
pulled
down
for
end-to-end
tests
and
we've
also
enumerated
by
looking
at
the
community
brow
prow
build
clusters
to
see
what
images
the
kubelet
is
pulling
down.
A
That
is
where
more
of
the
like
kubernetes,
six,
repos
and
stuff
run,
but
enumerating
another
script
that
looks
at
all
of
the
proud
job,
yaml
files
and
pulls
the
images
out
from
that.
There
are
very
few
docker
hub
images
that
are
unpopular
so
most
of
the
docker
hub
images
used
by
those
jobs.
Look
like
golang,
node
stuff,
like
that.
A
What
I
haven't
been
able
to
enumerate
would
be
any
script
that
runs
docker,
pull
as
a
result
of
those
jobs,
because
docker
poll
isn't
logged
by
kubelet
and
the
the
the
logging
for
the
gke
clusters
doesn't
pick
that
up
either
from
what
I
can
tell
so
that
we're
gonna
have
to
find
out.
My
my
anticipation
is
the
majority
of
scripts
that
do
that
are
probably
building
docker
images,
and
the
majority
of
those
jobs
run
in
gcp
is
sorry,
gcb
google
cloud
build,
which
is
also.
A
A
Yep
I
was
so
relieved
to
hear
that
they
decided
to
push
the
pause
button
on
the
image
retention
changes
which
don't
matter
to
us
at
all,
but,
like
honestly,
most
of
the
because
we
have
kates.gcr.io
the
majority
of
the
project
is
very
well
shielded
from
this.
It's
it's
more
like
the
long
tail
of
jobs
that
might
get
hit
by
this,
but
the
really
critical
stuff
is
going
to
work.
Just
fine.
D
A
A
A
A
I'm
pretty
sure
are
no,
you
probably
know
enough
to
make
them
migrate,
or
anybody
from
the
release
engineering
team
should
be
capable
of
doing
this.
I
know
I
saw
steven
ask
why
we
couldn't
do
this
and
I
said-
and
I
proposed
that
the
release
engineering
team
do
this
on
one
of
the
umbrella
issues
related
to
in
the
release
engineering
team,
taking
more
ownership
of
the
container
image
promoter
cloud.
A
A
D
I'd
like
to
add
one,
maybe
one
small
bump
there.
I
want
to
make
sure
that
the
documentation
for
the
end-to-end
business
of
promoting
images
is
up
to
snuff,
so
that
somebody
who
isn't
linus
or
me,
and
even
I
struggled
with
it
the
last
time
it
happened-
can
investigate
any
alert
that
goes
off
and
I'd
like
to
try
this
by
getting
somebody
who
isn't
linus
or
me
to
respond
to
an
alert
that
I
can.
E
C
C
D
That
is
a
great
answer.
Do
do
we
have
like.
We
have
google
groups
for
people
who
are
in
the
promoter,
maintainers
or
promoter.
I
forget
what
the
group
is
called,
but
we
can
look
it
up.
I
would
like
to
make
sure
that
there
is
ample
coverage
there
and
people
who
feel
like
they
are
responsible
for
it
like
if
that
alert
goes
off
last
time
it
went
off.
Nobody
looked
at.
D
D
A
A
A
Develop
a
proud
migration
plan,
I
think
arno
proposing
a
staging
instance
would
help
push
this
along.
I
have
I.
I
also
need
to
go
through
and
update
the
status
of
this
issue,
so
migrating
all
of
the
release
blocking
and
merge
blocking
jobs.
Like
I
said
we're
almost
there
greenhouse
the
bazel
build
cache
has
been
moved
over
setting
up
github
proxy
in
the
trusted
cluster.
A
A
We
have
set
up
post-submit
jobs
so
that
if
we
change
the
resource
files
in
the
appropriate
cluster
directories
for
these
clusters,
they
automatically
get
deployed
right,
and
this
is
specifically
what's
holding
back
migrating
all
the
police
blocking
jobs.
So
I
think
enumerating
how
we
then
get
to
setting
up
a
staging
prow
instance
and
what
it
would
look
like
to
shift
traffic
from
one
to
the
other
and
how
we
would
decide
we're
ready
to
do.
That
is
probably
what
needs
to
be
done
next
here.
E
E
A
D
Yeah,
I
know
justin
started
looking
at
that.
I
honestly,
I
think
we
should
this.
This
issue
is
probably
not
worth
the
paper
it's
written
on
right
now,
because
it
covers
too
much.
I
think,
there's
two
separate
tracks
here.
One
is:
how
are
we
going
to
set
up
gcr,
mirroring
container
image
mirroring
which
we
can
tackle
like
today
right?
We
could
start
that
work
today.
D
A
C
A
D
Yeah
and
I
don't
buy
the
six
month
clock
anyway,
like
we
are
a
significant
fraction
of
gcr's
bandwidth
right
now,
and
so
I
think
I
mean
a
significant,
but
we
are
a
noticeable
fraction
and
I
think
that
if
we
we
will
work
with
them
to
make
a
graceful
transition.
Let's
leave
it
there,
okay,
but
I'm
eager.
If
anybody
wants
to
try
to
start
figuring
out,
how
are
we
going
to
mirror
container
images
like
that
seems
very
approachable
now,
right
now,
the
gcr
is
in
the
is
in
the
community
space.
D
D
A
The
next
issue
is
about
moving
bosco's
projects
over,
so
these
are
the
the
projects
that
are
used
by
end-to-end
tests.
I
honestly
feel
like
I've
done
all
of
this.
Let's
see
yes,
so
there
is
no
way
to
create
a
template
and
then
create
a
bunch
of
projects
from
a
template.
So
we
have
a
script
that
basically
creates
the
projects
and
then
documents
the
quota
changes
that
had
to
be
made
to
those
projects
manually
by
a
human.
A
I've
documented
all
the
quotas
that
we
need
to
request
for
the
different
projects,
type
project
types
and
have
done
so.
This
includes
for
gpu
projects,
scalability
and
ingress,
and
so
the
only
like
follow-up
thing
I
can
think
of
is
if
we
get
to
the
point
where
we
want
to
start
doing
per
sig
billing
of
like
what
is
each
sig
using
or
consuming.
In
order
to
do
testing,
we
might
need
to
re-examine
how
we
tag
projects
or
maybe
have
projects
live
in
different
folders,
but
otherwise
I
think
this
is
done.
A
D
B
A
This
is
something
I
can't
do
with
the
terraform
files
that
we
use
to
create
our
clusters.
It
turns
out,
it's
really
painful,
if
not
impossible,
to
create
a
set
of
terraform
files
that
you
change
to
say.
Okay,
first
before
this
commit,
we
were
deploying
version
115
after
this
commit
we're
deploying
version
116.
A
A
E
Also,
a
little
warning
about
using
a
channel,
it's
destroy
the
cluster
because
the
last
time
trying
I
had
this
issue
using
the
current
state
of
the
terraform
file.
If
you
introduce
the
channel
in
the
current
cluster
it
may.
I
think
I
think
I
need
to
check,
but
I
think
if
the
art
form
will
recreate
the
cluster.
A
E
A
Okay,
what
I
have
had
to
do
in
the
past,
for
what
it's
worth
is
update
the
resource
manually
like
go,
go
change
the
resource.
However,
I
want
to
and
then
re-import
that
resource
into
the
terraform
state
file,
so
I
have
to
sort
of
manually
do
some
surgery
on
the
state
file,
or
I
have
to
put
things
back
into
it
before
terraform's
view
of
the
world
agrees
with
the
way
the
world
actually
is.