►
From YouTube: k8s-infra-team's Bi-Weekly Meeting for 20200304
Description
k8s-infra-team's Bi-Weekly Meeting for 20200304
A
A
B
So
we
did
a
deployment
of
the
auditor
to
the
case.
Our
tax
pot
project,
the
project
and
it
is
working,
but
there
is
a
site
bug
where
it
doesn't
show
the
actual
details
of
unapproved
images.
So
I
need
to
fix
that
we
did
a
test
with
a
dummy
image
to
trigger
that
path
on
purpose,
but
so
it
did
detect
that
it
was
not
verified,
but
it
just
didn't
tell
you
the
actual
details
of
the
pub/sub
message,
which
is
pretty
bad,
so
I
need
to
fix
that
today.
B
B
The
auditor
also
ran
fine
for
two
hours,
but
the
job
was
killed
because
prowl
said
that
it
took
too
long.
It
took
over
two
hours
so
on
the
fifth
second,
after
the
second
hour,
it
was
killed,
but
it
will
run
again
today
because
we
have
a
daily
job
that
runs
just
every
day
as
a
sanity
check,
so
that
will
kick
in
it
kicked
in
yesterday
at
1:00,
something
p.m.
B
as
if
it's
hot,
so
it
will
kick
off
again,
I
presume
at
the
same
time
today,
so
in
about
5
hours
time
in
that
window
of
time,
I
would
like
to
fix
that
bug
the
auditor
and
also
probably
a
deploy
it
so
that
we'll
see
like
some
better
locks,
but
for
what
it's
worth
during
the
two-hour
run.
Yesterday
we
just
worked
as
intended
like
it
verified
all
of
the
the
thousands
of
images
that
did
get
promoted.
It
said
yeah
these
each
one
of
these
are
verified
because
I
see
it
in
the
promoter
manifest
repo.
B
B
C
B
There's
definitely
so
there's
definitely
a
phase
2,
because
I
mentioned
last
meeting
or
one
before
that
that
I
have
an
intern
coming
in,
so
I'll
have
to
tackle
some
of
these
long-standing
issues
that
we
have.
There
are
plenty
of
there's
plenty
of
work,
I,
just
can't
think
of
them
right
now,
top
my
head,
yeah.
C
D
A
Right
here,
okay,
so
from
the
last
week
we
have
only
one
topic,
which
is
the
immigration
to
terraform,
and
unfortunately
there
is
not
a
lot
of
progress.
I
started
doing
the
Kalu
of
the
port,
which
was
just
standing
and
I
feel
like.
We
need
a
little
bit
more.
The
discussion
for
the
architectural
design,
all
that
kind
of
changes,
so
the
I
will
spend
some
time
during
the
next
week.
Just
tackling
this
issue
and
let's
jump
into
the
open
discussions
and
actually
I,
have
two
topics,
because
I
started
the
process
of
moving
the
pair
of
project.
C
A
A
A
Car
great
because
I
told
on
our
last
meeting,
I
will
try
myself
to
focus
on
the
documentation
more
during
the
next
period
of
times,
so
I
will
spend
some
time
digging
into
his
into
this
and
improving
a
little
bit
of
our
documentation,
so
be
prepared
for
me
to
poking
you
guys
a
little
bit
more
about
this,
and
this
also
is
another
topic
from
me.
Is
the
audit
process
because
I
have
the
question
I
want
to
import
the
documentation
or
for
that
car
topic
at
the
beginning.
So
what
is
currently
the
process
of
the
auditing?
C
C
It's
mostly
I
am
but
not
exclusively,
and
I
would
love
to
see
us
audit
more,
but
we
need
to
make
the
audit
script
not
log
the
sorts
of
things
that
are
typically
changing
right,
so
IP
addresses
and
items
in
a
bucket
and
those
sorts
of
things
are
probably
not
good
things
to
audit
the
existence
of
a
cluster
is
a
good
thing
to
audit.
Now
you
get
into
like
the
number
of
nodes
in
that
cluster.
C
Well,
the
cluster
is
auto
scale,
so
that
can
change
and
like
if
the
auditor
ran
say
hourly,
would
it
be
triggering
a
pull
request
every
hour
when
the
auto
scaling
is
happening
like
that
seems
like
a
bad
idea,
so
the
audit
script
is
pretty
dumb
right
now.
What
we
would
really
want
to
do
is
look
at
the
results,
we're
getting
from
each
datum
and
filter
for
the
stable
information,
and
so
I've
left
that
I've
not
tackled
that.
A
C
Okay
right,
so
we
need
to
do
a
first-time
audit.
We
know
there's
a
bunch
of
permissions
and
things
that
are
that
are
wrong
today,
just
because
we've
been
a
you
know,
evolving
and
iterating
on
the
process.
So,
for
example,
we
have
an
open
bug.
Anybody
who
creates
a
project,
whoever
runs
the
insurer
staging
storage.
That
person
gets
added
as
an
owner
of
the
project
that
they
just
created
right.
C
So
we
need
to
actually
fix
the
tooling
to
say
after
you've
created
the
project
and
assigned
correct
ownership
to
the
admins
group
that
you
actually
remove
yourself
from
it
right
like
we
did.
We
know
that
bug
exists.
So
when
we
look
at
the
audit
log,
we'll
see
it's
not
a
log,
the
audit
dump,
we
will
see
you
know.
Linus
has
some
projects
and
I
have
some
projects,
and
you
have
some
projects
and
Christophe
has
some
projects,
and
so
we
need.
A
C
C
So
that
that's
the
only
reason
that
the
development
to
cluster
exists,
so
we'd
love
to
get
that
out
and
then
there's
this
old.
The
old
Google
only
cluster
still
has
two
things
running
it:
node,
perf
and
velodrome,
which
I
have
asked
those
two
groups
individually
to
figure
out
how
to
extricate
themselves
from
the
cluster,
and
that's
it
after
that.
We
actually
sort
of
declare
victory
that
our
utility
cluster
is
up
and
running.
C
Now
we
can
think
about.
Should
we
have
a
cron
job
that
runs
the
audit
right.
I
actually
am
very
interested
in
that,
but
to
my
earlier
point,
I
also
want
to
shift
attention
towards
the
harder
problems.
Now
once
we
get,
the
GCR
thing
done,
I
really
want
to
see
the
continuous
integration
and
the
boss
cos
and
all
the
stuff
that
ends
prod
and
sync
testing
have
done
moved
into
community
hands.
That's
the
next
big
goal,
and
maybe
scalability
after
that.
B
D
Kind
of
unclear
how
we
can
do
that
without
causing
some
downtime,
but
we
have
been
moving
to
the
model
where
we
support
different
teams
by
having
them
add
their
own
build
cluster.
And
so
just
as
a
sanity
check
with
this
group,
does
it
make
sense
for
us
to
look
in
the
direction
of
provisioning
extra
clusters
for
prowl
versus
having
prowl
attempts
to
use
the
triple-a
cluster,
but
my
thinking
being
that
crowd
jobs
tend
to
be
kind
of
noisy
neighbors,
and
so
it
was
unclear
to
me
that
it
made
sense
to
use
the
triple-a
cluster.
C
Oh
I
would
love
to
try
to
use
the
same
cluster,
especially
for
the
non-sensitive
stuff,
because,
honestly,
we
should
be
able
to
support
that,
and
if
we
can't,
then
we
should
go
back
to
the
developer
side
of
our
jobs
and
say
what
the
heck
guys,
let's
make
a
better
product
and
so
I
would
love
to
try.
That
comes
with
the
caveat
that
actually
I
have
no
idea
how
proud
really
runs.
So
you
know
we
will
look
to
the
folks
who
know
that,
for
as
experts
sure.
D
C
D
C
B
B
A
A
A
D
So
I
think
when,
when
you're
running
a
job-
and
it
needs
to
stand
up
an
internet
cluster,
the
way
it
does
it
right
now
is
it
gets
a
GCP
project
from
phosphorus
and
then
schedules
it
to
that,
and
so
we
would
need,
if
asked
us.
That's
set
up
in
the
CNC
FM
project
and
we'd
need
a
pool
of
projects
that
that
Rastas
instance
could
then
hand
out
to
jobs
that
want
to
run
end-to-end
tests,
so
they
could
stand
up
their
clusters
in
Vasquez,
provisioned
or
managed
project
that
lives
in
the
CN
CF
space.
D
So
a
a
way
we
could
maybe
crawl
before
we
walk.
There
is
to
consider
yes
like
maybe
moving
over
some
of
the
trusted
jobs
or
maybe
moving
over
jobs
that
don't
require
standing
up
an
entire
kubernetes
cluster
to
run
into
n
tests.
We
do
have
a
number
of
jobs
that
just
run
as
a
pod,
and
you
know
like
we
run
a
shell
script
or
build
something
you
know
or
things
of
that
nature
and
it
would
probably
be
easier
to
look
at
moving.
D
A
A
C
A
C
A
A
C
C
A
This
also
one
of
the
peers
or
issues
I,
don't
remember,
I
feel
like
there's
so
many
of
those
created
and
that
we
I
will
ask
him
and
I
will
discuss
with
him
at
the
next
Monday
topics
with
Segura
this
meeting
so
I
till
this
time,
I
won't
have
a
better
understanding
of
the
problem
or
some
better
knowledge
about
it.
I
hope
that
it
will
be
fixed
during
that
meeting.