►
From YouTube: Kuberentes SIG Testing - 2019-07-02
Description
A
And
I
am
Eric
here,
I'm
going
to
post
a
link
to
the
meeting
notes,
makes
you
wanna
check
them
out,
and
this
is
going
to
be
recorded
and
all
that
so
it'd
be
nice
and
we'll
post
it
on
the
web
for
every
all
of
your
friends
to
watch.
So.
First
on
the
agenda,
we
have
Miranda
talking
about
the
group's
system
design
for
the
rerun
button
authorization.
Do
you
like
to
start.
B
B
B
Okay,
so
just
to
give
an
overview
of
my
project.
Basically
the
button
that
I'm
working
on
is
this
one.
That's
pointed
to
and
right
now,
if
you
click
on
it,
it
shows
you
a
pop-up
that
has
a
command
that
you
pasted
into
the
terminal.
That'll
rerun
the
test
for
you,
and
so
only
people
with
cluster
access
can
do
that,
and
so
basically,
the
goal
here
is
to
come
up
with
a
safe
way
to
trigger
directory,
runs
and
also
an
efficient
way
to
specify
who
can
trigger
these
reruns.
B
And
so
what
we
have
now
is
we
have
an
option
to
allow
anyone
to
rerun
any
tests.
That's
the
allow
any
one
flag.
We
also
have
a
global
whitelist
of
users
who
can
rerun
any
job.
We
have
a
way
of
checking
just
the
same
as
with
pre
submits
has
foo,
and
we
have
the
same
thing
as
before.
Anyone
with
roster
access
can
we
run
any
job,
but
what
we
don't
have
is
a
way
to
specify
groups
of
people
who
can
rerun
and
get
a
job.
B
So
we
want
to
do
this
efficiently,
and
so
basically,
the
question
is:
what
I
choose
github
teams
or
to
make
our
own
sort
of
groups
configuration
the
pros
of
github
teams?
Are
that
they're
already
made
for
us?
It's
less
work,
there's
a
nice
UX,
but
it
creates
more
dependence
on
github
with
our
own
groups.
We'd
have
more
freedom,
but
it
would
also
be
more
work.
So
I
was
just
wondering
like
before.
I
implement
this.
If
anyone
has
any
preference.
C
D
That
we're
trying
not
to
create
a
tight
coupling
there
I
know
that
we'd
like
to
have
an
option
to
use
different
authentication
systems.
Though,
and
if
we
tightly
coupled
to
github-
and
it
depends-
we
can't
really
I
guess
the
alternative
is
either
creating
something
the
type
of
github
or
create
something
that
is
just
accepts
any
user
names.
And
then
we
can
have
an
art.
You
know
our
own
bespoke
system,
honors
files,
the.
E
B
A
Sort
of
feel
like
there's
a
little
bit
of
precedence
for
using
github
teams
as
a
authorization
strategy
like
the
sticky,
LG
TM,
feature
I.
Think
if
I
recall
correctly
use
this
a
github
team
and
I
mean
in
general
to
the
extent
that
we
have
authorization.
It
all
seems
to
depend
on
github
and
right,
like
we
use
that
to
determine
whether
or
not
you
can
LG
TM.
F
A
D
D
Okay,
I
think
that
makes
I
think
that
makes
sense.
The
main
use
case
for
this
right
now
is
for
jobs
that
we
can't
don't
have
other
triggering
mechanisms.
Mechanisms
like
the
like
presum,
it's
already.
It
can
use
that
reuse,
the
test
of
new
logic
to
determine
if
users
trusted
so
I
guess.
This
is
just
for
other
ones.
E
D
B
C
D
G
I
guess
one
of
the
things
is
for
us:
we
generally
have
for
every
repo
there's
a
post
admit
that
like
publishes
images
and
one
of
the
things
that
people
always
want
to
be
able
to
do
is
manually
trigger
another
publish
when
something
fails.
I
don't
want
to
restrict
that,
like
I
want
to
find
a
design
that
doesn't
have
us
listing
groups
of
people
everywhere.
That
also
doesn't
require
that
people
have
right
access
to
all
these
repos
and
top-level
owners.
G
G
A
So
how
about
like?
We
have
the
definition
of
the
job
and
we
have
a
set
of
people
who
are
able
to
control
the
definition
of
the
job.
It
seems
like
we
could
use
that
set
of
users
as
people
who
can
rerun
the
job
right,
because
essentially,
if
I
approval
rights
to
make
an
arbitrary
change
to
the
job
definition,
I
can
basically
do
whatever
at
once
anyway,
and
so,
therefore,
it
seems
like
that
might
be
a
good
set
of
people
to
be
able
to
rerun
the
job.
I
mean.
D
A
But
we
couldn't
I
mean
we
certainly
seems
like
we
could
make
that
the
case
I
mean
the
the
two
things
right.
I
mean
basically
where
the
job
is
to
find
it
seems
like
they're
either.
If
someone
is
going
to
have
write
access
to
the
git
repo
or
they
are
going
to
have
their
gonna
be
in
an
owner's
file,
I
would
assume
I
mean
I,
guess
technically
they
could
write
the
tied
config
that
doesn't.
D
Yes,
I'm
thinking,
even
if
we
did
assume
that
the
like
agreed
owners
or
people
that
should
be
able
to
run
these
jobs,
that's
not
sufficient,
probably
like.
We
want
other
people
to
be
able
to
rerun
some
types
of
posts
in
a
job.
So
we're
going
to
need
some
other
level
of
specification
to
say
that
these
teams
or
these
individuals
can
run
the
jobs,
does.
G
G
G
G
A
D
D
A
Don't
think
it
should
be
the
rude
owners
file
I
feel
like
it
should
be.
All
of
the
owners
for
the
I
feel
like
I,
just
followed
the
scan
like
if
we're
going
to
go
with
owners.
I
feel
like
if
I
define
a
job
where
I've
defined
the
job
there's
a
whole
nesting
of
owners
files,
and
we
should
allow
anyone
who
has
approval
rights
to
that
job
to
be
able
to
rerun.
It
I
think
we're
saying
to
the
repo
another
job,
yeah
I,
don't
think
that's
the
right!
A
G
A
G
Yeah,
like
I,
mean
I,
guess,
there's
like
we
don't
even
have
there's
there's.
No,
we
don't
even
have
a
way
to
enforce
that,
like
not
a
generic
way
to
enforce
the
specific
directory
use,
the
only
directory
that
contains
pre,
submits
or
post
investors
right,
like
I,
feel
like
to
support.
What
you're
saying
is
a
lot
of
background
I.
D
A
Guess
to
me
it
sort
of
feels
like
a
good
first
step
would
be
to
just
have
a
raw
list
of
teams.
There's
whatever
just
have
a
list,
and
then
we,
you
know
to
sort
of
have
the
functionality
and
right
to
some
eventually
somewhere
or
something
is
going
to
call
a
function,
and
it
gets
a
list
of
users
that
are
allowed
to
rerun
this
job.
And
then
we
will
validate
that
the
authenticated
user
is
in
that
list,
and
so
we
can
over
time
it
make
the
implementation
of
how
we
get
that
list
of
users.
A
More
complicated
and
correct.
I
sort
of
feel
like
a
good
process,
would
be
to
just
go
to
simplest
thing,
which
might
be
to
declare
a
list
of
users.
I
would
say
for
the
whole
proud
deployment,
as
opposed
to
allowing
each
job
to
specify
different
people
that
can
rerun.
That
seems
kind
of
is
more
complicated
than
necessary.
That
was
already
included.
That's
already
done,
yeah
and
so
I
would
potentially
just
you
know,
start
with
that,
and
then
we
designed
the
thing
that
we
actually
want,
and
then
we
start
implementing
that
I.
Think.
A
About
come,
what's
the
next
step?
Well,
I
know,
but
it's
int,
but
essentially
I
feel
like.
We
are
saying
that
this
might
be
it.
It
sounds
like
we
are
saying:
oh,
that
is
too
complicated
or
something
I
whatever
my
suggestion
is
being
rejected
as
being
too
complicated,
but
I
feel
like
if
we
already
have
the
basic
use
case
in
I
feel
like
we
should
be
thinking
about
the
eventual
state.
We
want
to
get
you
rather
than
you
know.
What
is
the
most
efficient
thing
to
hack
in.
G
Yeah
I
guess
I
mean.
Am
I
comment
about
a
couple
complexity.
There
was
less
about
like
efficiency
and
speed,
but
more
like,
like
we
currently
make
absolutely
no
statement
about
checking
your
configures.
You
get
in
the
first
place,
or
how
do
you
do
that
or
how
you
federated
inside
of
that,
like
that's
an
entirely
new
set
of
concepts,
it
doesn't
exist.
We.
A
About
if
we
extend
the
proud
job
itself
or
the
I
mean
to
me,
this
I
mean
potentially,
if
we
had.
If
we
had
the
proud
job
config
as
the
CRD,
we
could,
you
know,
have
a
field
that
says
what
teams
and
or
individuals
are
allowed
to
rerun
it.
And
so
then
we
could
just
check
that
whenever
someone
attempts
to
rerun
a
job
or
yeah
go
ahead.
Okay,.
C
D
D
G
D
G
H
A
D
B
A
A
So
the
job
config
is
kind
of
just
a
config
map,
the
mo
file,
whereas
the
prowl
job
of
itself
is
a
custom
resource,
that's
uploaded
into
the
kubernetes
api,
and
so
that
thing
right
now,
it's
gonna
have
like
a
pod
spec
or
build
spec
or
a
pipeline
spectrum.
We'd,
add
a
field
to
say
like
rerun
list,
or
maybe
rerun
teams
and
rerun
users
or
whatever
we'd
have
some
fields
there.
A
In
addition
to
the
other
ones
that
specify
who
can
rerun
it,
and
so
every
time
we
create
a
job
we
will
then
maybe
would
there
can
be
some
amount
of
you
know.
People
experimenting
with
different
ways
to
populate
that,
but
basically,
every
time
we
create
a
job
using
pj
or
trigger
or
whatever
it
will
populate
that
field
when
it
creates
the
crowd
job.
G
D
D
A
If
we
can
I
think
I
think
as
I
said,
I
don't
I.
Don't
think
this
would
be
part
of
this
thing,
but
I
think
it
would
be
and
I
think
we
are
more
or
less
out
of
time,
but
I
think
it'd
be
useful
to
think
about
moving
our
jobs
into
a
see
it
like
defining
a
CRD
for
our
job
config
as
opposed
to
just
having
to
eat
in
a
config
map.
I.
D
C
A
But
I
think
that
I
think
if
we
had
that,
then
we
could
sort
of
say
what
you
know.
If
there's
like
the
template
config
that
we
spawn
the
job
from
then
we
can
have
the
list
of
authorized
rerun
users
attached
to
that,
and
then
that
would
enable,
because
I
agree
Steve,
that
it
is
awkward
to
do
that
since
for
every
job,
since
it
might
be
out
of
date,
and
it's.