►
From YouTube: Kubernetes WG K8s Infra - 2021-04-14
Description
D
D
C
D
C
C
It'd
be
easier
if
I
could
just
pay
it
to
one
country,
but
as
an
american
they're
like,
let's
be
sure
you
it's
like
trying
to
donate
to
a
charity.
For
example,
if
I
donate
to
a
new
zealand
charity,
I
get
new
zealand
benefits
right
off,
but
if
I've
done
it
but
it,
but
it
doesn't
show
up
on
the
american
side.
If
I
donate
to
an
american
charity,
it
doesn't
show
up
on
the
new
zealand
side.
So
it's
funny
things
like
that.
C
Because
it's
how
they
calculate
things
like
in
new
zealand,
if
you
own
a
business
and
you
withdraw
profits
out
of
it,
the
company
pays
a
certain
percentage,
and
then
you
only
pay
five
percent
tax
on
that.
But
when
the
u.s
come
us
sees
it
they're,
like
you
only
paid
five
percent
taxes,
you
need
to
pay
up
to
your
larger
amount.
They
don't
count
all
the
other
taxes.
D
B
B
B
Oh,
I
have
an
issue
with
my
zoom
client.
I
can
share
the
screen.
I
don't
have
the
credential
to
ask
someone
else
to
share
the
screen
yeah
this.
B
C
Yes,
that
we
we
needed
to
get
a
group
created
and
figure
out
what
that
group
needed.
I
think
the
group
has
been
created,
but
we
may
not
have
the
correct
permissions
yet
it
might
be
useful
to
to
pair
with
someone
who
does
have
full
access
and
we
try
to
access
those
things
and
figure
out
that
precise
list
of
how
to
access
that
data.
A
B
B
But
the
the
issue
is,
I
can
basically
share
my
screen
because
my
zoom
client
I
mean
I
basically
have
a
kind
of
a
bug.
I
don't
know
what
exactly,
which
means
if
you
can
share
your
screen,
that
would
be
great.
B
B
B
Gk
cluster,
we
have
for
the
moment
all
all
of
the
gk
cluster,
the
biggest
and
triple
a
are
managed
with
terraform
and
transform
store
the
state
in
only
one
bucket.
So
I
propose
we
split
this
bucket,
and
basically
I
mean
we.
We
separate
those
states
in
different
buckets
and
I
was
I
was
supposed
to
push
something.
B
B
So
I
paused
the
progress
april
justin
barbara,
submit.
I
think
two
weeks
ago.
B
B
B
B
E
Yes,
we
requested
a
temporary
project
and
it
was
we
created
the
issue
in
121
and
aaron
now
marked
it
for
us
for
122..
C
We
are
looking
at
setting
up
some
registry
replacements
and
artifact
replacement
software
that
it'd
be
good
to
have
a
place
to
host
it
while
we're
collaborating
on
it
and
probably
gcs,
and
what's
it
called
the
the
google
container
registry
and
the
appropriate
buckets
and
stuff
underneath.
C
B
F
So
I
would
say
that
this
needs
to
be
near
near
prod,
prod
identical,
so
anything
that's
running
in
our
k2
artifacts
prod
should
be
running
in
this
to
test
it
out.
F
So
that's:
okay,
yeah,
that's
gcs,
gcr
gar,
any
container
vulnerability,
stuff
the
ability
to
run
the
prow
instances
like
they
mentioned
and
and
dns
at
the
bare
minimum.
F
E
B
E
B
Great,
we
don't
really
need
to
meet.
Basically,
you
can
basically
look
and
at
the
repo
and
submit
the
pull
requests
similar
to
what
we're
doing
for
the
break
cluster,
because
we
manage
the
breaker
story
to
our
form,
so
you
can
submit
the
project
and
the
different
services
you
need
with
terraform
and
like
assigned
to
me,
I
will
do
the
review
for
you
and
we
can
iterate
for
that.
C
So
what
I
haven't
worked
much
with
the
new
terraform
folders
and
stuff
yeah.
There
are
some
steps
to
take
to
our
documentation
around
that.
C
B
C
Thanks
for
that,
arnold
we've,
the
ii
group
is
working
with
kate's
infra
working
group
on
helping
create
a
reducing
cost
for
distributing
kubernetes,
because
we're
sitting
at
60
to
sometimes
80k
a
month
on
distributing
those
images
and,
as
we've
been
looking
at
various
solutions
and
putting
stuff
together,
I
noticed
that
the
sid
release
and
the
sig
the
release
engineering
are
looking
at
similar
processes
and
solutions,
and
I
thought
it
would
be
good
to
find
a
way
to
consolidate
those
conversations
into
a
working
effort
and
so
part
of
this.
C
This
is
bringing
together
suggestions
from
stephen
and
laurie
that
I've
had
directly
with
them
with
the
different
infrastructure
boards
and
the
kubernetes
artifact
management
cup.
That
seems
to
be
the
overarching.
C
F
It's
it's
older,
it's
older!
Actually,
I
think
I
think
that
it
was
initially
drafted
by
brendan
and
justin
santa
barbara,
and
I
think
at
the
time
this
was
near
the
inception
of
working
group,
kate,
sinfra,
and
there
wasn't
really
any
sig
release
review,
given
that
there
is
a
point
somewhere
in
the
middle
that
we
meet
that
it.
That's
like
there
are
two
concerns:
one
is
maintaining
the
infrastructure
and
the
other
one
is
is
delivering
the
the
artifacts
themselves
onto
the
infrastructure.
F
So
I
would
see
I
would
see
maintaining
the
infrastructure
as
being
within
the
purview
of
of
working
group,
kate's
infra
and
the
mechanism
for
delivering
artifacts
onto
the
infrastructure
is
within
the
purview
of
release,
engineering
and
sig
release.
Overall,
so
there
is,
will
be
a
midpoint
that
we
meet
at.
I.
I
think
that
in
your
updates,
you
mentioned
that
you'd
be
the
person
on
point
for
artifact
management.
F
So
I
think
that
first
steps
here
at
least,
is
establishing
ownership
in
a
real
way
to
say
we
will
we'll
assign
you
the
enhancement
issue
to
own
the
cap
and
sig
release
will
help
you
review
as
well
as
working
group
kate's.
Infra
to
move
a
real
plan
forward
because
we've
got,
I
think
we
we
have
a
lot
of
people
kind
of
as
you've
as
you've
summarized
here.
We've
got
a
lot
of
people
saying
the
same
things
in
different
places
and
we
should
all
be
in
the
same
room
for
it.
F
So
I
would
say
that
at
least
from
the
delivering
things
onto
the
infrastructure,
conversation
should
be
happening
in
the
release.
Engineering
meetings
and
the
creating
the
infrastructure
conversation
should
be
happening
in
working
group
gates.
Infra.
F
G
Talking
with
the
with
the
artifacts,
are
we
talking
binary
artifacts
only
or
is
it
a
mixture
of
binary
artifacts
and
the
gc
gcr
or
the
container
images?
Basically.
F
Yeah
for
sure,
so,
for
me,
artifacts
means
the
binary
artifacts
anything
that
would
be
landing
on
artifacts.case.io,
which
could,
in
the
future
include
devs
and
rpms
right.
So
from
the
sig
release
side,
we
care
about
the
container
images
we
care
about
the
binary
artifacts
and
we
care
about
the
debs
and
rpms.
The
debs
and
rpms
are
currently
not
in
community
control
they're
delivered
by
ben's
team
at
google.
So
there
is
a
an
opportunity
to
move
more
of
that
into
kate's
infra.
F
G
Where
do
you
see
the
the
current
container
images
being
in
that
scope?
Basically,
is
it
separate,
or
is
it
being
integrated
into
artifacts
that
capes
that
I
owe
later
on.
F
F
So
this
is
a
reasonably
good
time
to
choose
a
good
name
and
decide
where
things
live.
We've
already
done,
one
cut
over
from
from
the
google
containers
location
over
to
kate's
artifacts
prod
for
the
for
the
container
images.
D
So
I
would
like
to
help
out
here.
I
got
I'm
invited
to
look
at
this
and
help
out,
and
so
what
I
would
like
to
ask
this
group
is
if
we
could
swarm
around
a
dock,
a
google
doc
shared
with
everybody
here,
just
to
initially
set
up
some
of
the
key
questions
around
ownership.
D
If
there
are
options
that
we
take
some
time
to
spell
out
the
pros
and
cons
of
different
options
and
just
write
them
down,
so
everybody
can
look
at
them
and
then
decide
path
forward.
That
works
for
everybody
like
around
some
of
these
ownership
questions
and
and
then
just
set
up
set
a
solid
foundation,
and
then
I
think
we
can
come
up
with
the
steps
to
work
to
work
together
in
the
two
groups,
where
there's
no
dependent,
you
know
no
blocking
going
on
and
then
there's
also
transparency
like.
D
If
we
need
to
have
a
line
of
ownership
between
release
engineering
and
this
group,
then
then
everybody
knows
what
that
line
is
what
it
means
they
can.
They
can
go
to
that
dock
and
look
at
it
if
they
forget
and
that
we
also
use
one
of
the
other
community
meetings
to
provide
the
discussion
about
progress
and
like
what
comes
next.
F
So
I
I
would
say
that
I
would
say
that
I
think
that
the
doc
that
we
should
swim
around
is
the
cap
and
I'm
happy
for
hippy
and
his
group
to
work
on
kind
of
forming
jumping
through
the
cap
and
what
was
written
and
turning
into
what
we
envision
it
being
in
the
future
and
then
having
the
release.
Engineering
group
do
a
review.
F
I
think
that
right
now,
the
time
that
we're
at
least
on
the
stig
release
side
we've
got
you
know,
we've
got
a
few
balls
up
in
the
air
that
people
are
also
involved
with,
whether
it
be
the
release,
cadence
stuff,
whether
it
be
like
triage
overall,
and
I
want
to
make
sure
that
we
we
spend
the
right
amount
of
time
on
this.
F
I
think
that
hippie
and
and
his
team
has
already
put
together
a
ton
of
good
information.
If
it's
in
a
cap,
I
think
it's
a
good
place
for
us
to
to
thoroughly
review
it.
Yeah.
F
D
That
makes
I
just
didn't
know
if
there
needed
to
be
any
sort
of
like
investigative
questions.
You
know
that
you
want
to
actually
tease
out
over
time,
brain
dump
and
then
push
into
the
cap.
It's
up.
It's
really
how
you
all
prefer
to
work.
We
just
go
with
that.
I
guess
in
the
github
issue
and
pull
requests.
This
makes
most
sense.
F
Yeah,
the
cap
is
an
alpha
status
right
now,
and
it
has
been
so
for
I
think.
As
long
as
it's
existed,
the
the
last
change.
The
last
change,
I
think,
was
the
merge,
and
I
know
that
I
know
that
justin's
group
for
cops
uses
artifacts.kates.io.
F
I
was
planning
on
figuring
out
how
we
could
start
using
that
in
release
engineering
as
well.
But
if
it's
going
to
change
we
should
we
should
discuss
it
so
so
hippie.
How
about
this?
I
will
I'll
the
the
the
enhancement
issue.
I
will
sign
that
to
you
and
just
let
you
all
jump
on
it
for
a
while,
and
then
we
can
meet
up
again
and
and
talk
about
the
next
steps
for
the
proposal.
F
F
D
F
F
On
the
board,
so
I
think
we
we
want
one
succinct
document,
so
people
because
essentially
what's
been
happening
is
people
have
been
filing
the
same
issue
across
multiple
years
about.
F
At
it
would
be
it'd
be
like
go
look
at
the
gap,
so
I
think
I
think
we
we
work
on
cleaning
up
that
cap.
Sig
release.
G
F
Release
engineering
do
a
do,
a
thorough
review
of
that
and
then
we
plan
timeline
and
the
work.
D
If
I
recall
correctly,
sorry
sorry,
I
was
just
if
I
recall
correctly,
there
were
you
had
collected
the
related
issues
in
that
board,
maybe
around
the
holiday
break
time,
and
then
there
were
three
kepts
right
that
were
relevant
and
I
think
you
were
going
to
consolidate
into
this
one.
F
F
Whoever
has
the
the
screen,
can
you
drop
over
to
the
the
board
again.
F
So
yeah,
so
looking
looking
at
all
three
of
these
right,
we,
I
think
we
want
to
be
a
little
clearer
on
the
language
around
artifact
management.
I
honestly
open
these
placeholder
enhancement
issues
for
the
sake
of
having
a
number
to
assign
to
the
cap
when
we
change
them
to
the
new
versions.
So
these
issues
are
pretty
sparse
right
now.
F
We,
I
think
we
want
to
be
a
little
bit
clearer
on
the
language
of
artifact
management,
because
here
we're
explicitly
talking
about
the
artifact
management
infrastructure
and
not
necessarily
the
day-to-day
management
of
the
artifacts
for
sub-projects
and
for
maybe
core
kubernetes
right.
The
publishing
packages
thing
is
like
it's.
I
because
I
see
this
as
like.
I
see
the
artifact
management
one
as
a
as
a
umbrella
cap,
as
it
were
right
where
publishing
packages
and
and
image
promotion
are
are
aspects
of
it,
but
they
they
are
big
enough
to
be
their
own
caps
right.
F
So
I
see
a
bunch
of
cross-linking
happening
here
with
the
infrastructure.
The
artifact
management
infrastructure
kept
being
kind
of
the
the
starting
place
from
the
image
promotion
perspective
we
have
already
delivered
and
linus
is
on.
The
call
has
already
delivered
that
artifact
that
image
promotion
functionality.
F
The
next
piece
that
I
would
like
to
do,
at
least
from
the
day-to-day
management
side,
is
consolidate.
The
is
consolidate
the
ability
to
do
image
promotion,
as
well
as
the
ability
to
do
artifact
promotion.
So
if
you
look
in
sig
release,
sorry
the
the
k
release
repo,
let
me
there
is
a
tool
called
k-premo.
It
is
incomplete
today,
but
k-premo
would
serve
to
consolidate
the
work
that
justin
did
for
file
promotion,
as
well
as
the
work
that
linus
did
for
for
image
promotion.
F
Now,
I'm
also
sorry,
I
linked
it
in
the
zoom
chat,
which
I
should
have
put
in
the
meeting
notes,
which
I
will
do
in
a
second.
But
the
idea
with
k-premo
is
that,
like
we
kind
of
want
to
we've,
been
doing
some
gardening
work,
essentially
on
k-release
and
pulling
out
some
of
the
things
that
made
sense
as
as
separate
libraries
into
different
repos.
So
we're
kind
of
still
working
through
this
refactoring
of
of
the
of
the
repo.
F
But
the
end
state
would
be
having
a
tool
that
we
could
use
for
both
container
image
promotion,
as
well
as
as
well
as
as
well
as
file
promotion.
F
So
yeah,
so
that
that
day-to-day
management
piece
I
would
say
that
that
is
release
engineering,
okay
and
I
will
yeah
it's
it's
release
engineering,
but
I,
while
I'm
doing
some
gardening,
I
want
to
think
about
the
way
I
want
to
plant
the
way
I
want
to
plant
certain
things,
but
I
would
welcome
help
on
those
tools
as
well.
D
Maybe
we
have
a
call
to
action
on
that
as
part
of
starting
to
communicate
this
plan
a
little
more
broadly.
Maybe
that's
one
of
the
first
little
bullet
points
that
we
share.
F
I
Kind
of
related
to
this
topic,
like
we
have
this
csi
proxy
under
kunan,
his
csi,
and
we
generate
binary
and
right
now
it
can
be
pushed
to
using
the
cloud
build
to
push
to
release
kind
of
no,
not
what
it
is
staging
strange,
repo
right
right.
I
show.
I
So
you
mean
you
can
help
to
push
it
to
release
repo.
G
F
As
far
as
I
know,
someone
please
correct
me
if
I'm
wrong.
As
far
as
I
know,
anyone
who
has
a
staging
repository
today
that
only
uses
it
or
explicitly
uses
it
for
binary
artifacts
there
is,
is
not
an
automated
process
to
bring
those
binary
artifacts
from
a
staging
place
to
a
production
place.
The
production
place
would
be
artifacts.kates.io,
so
what
someone
could
do
if
they
had
a
staging
project?
Not
every
project
has
a
staging
project
for
gcs
right.
F
If
what
they
could
do
is
do
something
similar
to
what
cops
is
doing
and
and
kind
of
go
through
that
file
promotion
process.
But
I
would
like
the
file
promotion
process
to
be
cleaned
up.
People
actually
have
to
understand
how
to
do
the
file
promotion
process
and
it's
not
as
clear
as
it
could
be
today.
F
F
We
have
a
kate's,
artifacts
cni,
I
think,
or
staging
cni,
as
well
as
a
cri
tools,
one
because
we
produced
the
cni
plugins,
ci,
plugins
and
cri
tools
as
part
of
the
core
packages
for
a
kubernetes
release.
We
needed
separate,
we
needed
like
a
production
place
to
pull
those
from
as
well.
So
I
think
that
the
way
that
we
are
doing
it
today,
at
least
on
on
for
sig
release
and
release
engineering,
would
go
away.
F
The
way
that
justin
is
doing
it
for
cops
right
now
would
sort
of
move
towards
being
the
canonical
way
to
do
it,
but
we
need
to
we
need
to
thumb
through
the
documentation
that
exists
today
and
then
be
really
good
about
notifying
people
about
how
to
do
it.
It
is
not.
It
is
not
easy
or
clear
to
do
today
as
as
compared
to
the
image
promotion
process.
I
Okay,
so
what
we
can
do
for
now,
like
waiting
for
some
documentation
and
also
do
we
have
the
like
the
permission
to
promote
or
there's
some
people
need
to
like.
F
Yeah,
so
you
would
process
that
yeah
so
the
way
that
it
works
right
now,
if
you
were
to
do
it,
the
release
engineering
way
is
you
would
get
a
separate
prod
like
bucket
to
take
your
to,
and
then
you
would
get
permissions
for
that
prod,
like
bucket
the
ideal
way
is
for
them
all
to
live
in
a
prod
like
bucket.
That
is
a
sub.
You
know
you
have
a
subdirectory,
a
csi
subdirectory
to
that
bucket
and
you
would
get
you
wouldn't
necessarily.
F
You
wouldn't
have
permissions
to
prod,
but
you
would
have
permissions
to
approve
the
the
the
the
manifests
for
your
file
promotion.
I
Okay,
so
what's
the
so,
what.
F
F
B
I
mean
it's
just
a
long
balance
redirecting
to
the
gcs
marketplace.
The
load
balancer
doesn't
live
inside
in
the
kitchen.
B
G
F
The
past,
and
if
you
want
to
go
that
route,
you
could
yeah
give
me
a
second
I'll
I'll
dig
those
up.
A
D
So
I
wonder
if
y'all
want
or
need
help
setting
up
some
of
the
writing,
because
I'm
happy
to
help.
If
you
want
it,
we
could
go
through
the
issues
in
that
project
board
and
get
through
a
lot
of
those
quite
quickly.
I
think,
just
by
focusing
on
it
and
then
use
those
cards
to
develop
the
cap,
taking
the
bits
and
pieces
and
updating
them
based
on
the
current
vision
and.
F
I
so
I
think
I
like
I
like
that,
but
as
a
follow-up
step,
maybe
I
think
that
the
a
lot
of
those
issues
include
cruft
from
the
past.
That's
maybe
not
true
anymore,
so
I
would
love
to
see
what
the
current
vision
for
folks
that
are
actually
working
in
kate's
infra
today
is
before
we
start
digging
up
the
past
too
much.
F
Okay,
yeah
yeah,
but
let
me
not.
G
C
I
think
we're
missing
some
of
the
key
voices
on
this
call
and
I
wonder
if
it's
not
good
to
actually
just
find
a
time
that
works
specifically
for
this
particular
sub.
Well,
it's
a
sub
project.
It's
a
pretty
creepy
thing
that
maybe
we
can
go
through
that
board
and
clean
that
up
with
lori's
help
and
the
right
people
on
the
call
to
get
us
headed
in
the
right
direction.
D
G
D
Sorry,
I
didn't
mean
to
interrupt.
I
did
interrupt
you,
I'm
sorry
for
cutting
you
off
earlier,
but
in
any
case
you
know
just
separating
that
stuff
in
that
session,
and
then
everybody
can
learn
and
get
a
shared
context
from
that
conversation
about
how
this
idea
evolved
from
long
ago,
and
that
can
be
useful
and
then
we
merge
with
an
updated
set
of
things.
F
So
I
have,
I
have
an
idea,
or
I've
had
an
idea
for
a
while
now
that
I'm
not
ready
to
speak
publicly
about,
but
this
moves
it
in
the
right
direction.
So,
let's
talk
after
work.
B
Another
I'm
sorry,
but
is
it
possible
to
have
a
separate
meeting
for
this.
D
B
B
F
B
B
Want
to
move
forward
like
this
right
now
and
basically
we
just
90
minutes
until
the
end
of
the
meeting.
So
my
my
id
and
that's
just
my
id
about
this
subject,
we
should
just
basically
build
a
new
community
group
at
the
end,
but
the
first
thing
to
do
is
just
doing
just
just
to
maybe
improve
the
cab
to
align
with
the
ultimate
goal
like
improved.
E
From
so,
we
spend
a
lot
of
time
looking
through
all
the
information
gathering,
and
it
is
everywhere.
So
what
we
could
do
is
start
summarizing
what
we
know
and
also
there's
a
lot
of
work
that
we
already
started
and
reach
out
with
different
stakeholders
about
possible
solutions,
and
we'll
summarize,
all
of
that,
and
once
we
have
a
good
summary,
then
we
call
that
meeting
get
lorry
get
stephen
and
everybody
that
have
an
a
stake
in
this
help
us
to
flesh
out
where
we
need
to
go
with
it.
With
that.
D
It
looks
like
you
have
a
few
things,
so
we
talked
earlier
about
the
central
place
for
this
to
be
communicated
well,
two
central
places,
this
working
group
and
the
release
engineering
group.
Are
you
now
suggesting
that
we
actually
move
those
conversations
into
that
cncf
community
discussion
or
are
they
through?
I'm.
F
F
The
people
who
are
interested
in
doing
the
next
thing-
and
I
think
one
of
the
next
things
will
be
to
clean
up
the
cap
and
get
all
those
people
who
are
interested
to
clean
up
the
cap
together.
So
I
think
that
now.
F
B
All
right
I
mean
basically,
maybe
the
idea
of
having
a
community
group
at
the
sensor
level
is
not
something
we
want
to
do
right
now,
but
we
should
have
a
place
where
we
can
gather.
I
mean
everyone
can
gather
and
basically
collect
those
information
and
talk
about
this,
because,
basically
in
just
one
meeting
we
can
we
can
talk
about
everything.
D
Well
right:
well,
I
won't.
I
won't
join
any
meeting
where
we
talk
about
everything
I'll
leave,
but
because
that
sounds
terrible,
but
my
suggestion
here
is:
if
we're
gonna
involve
a
lot
of
stakeholders,
it's
very
easy
and
saves
us
a
lot
of
time.
D
If
we
just
come
up
with
a
very
lightweight
communications
plan,
because
not
everybody
will
read
the
slack
channel
right,
you
know
this,
so
you
know
just
like
a
regular
cadence
of
updates
based
on
the
highlights
how
things
are
progressing
and
then
they
have
it
and
we
keep
it
very
short
sweet
to
the
point.
But
I
think
by
doing
that,
we
will
save
ourselves
a
lot
of
potential
things
that
are
nice
happening.
D
F
D
D
B
F
C
I'm
going
to
cover
burno's
topic,
really
quick,
it's
just
the
central.
We
probably
need
to
get
together
with
the
right
people
to
make
sure
we
have
access
to
the
bigquery
and
the
reports
that
we
go
through.
C
I'm
still
not
certain
how
to
access
those
I'd
love
to
pair
with
someone
who
is
has
been
part
of
generating
those
so
that
we
can
ensure
that
we
have
the
correct
access
to
understand
the
the
cost
structure
underpinning
the
reports,
so
that
we
can
ensure
that
this
work,
we're
doing
does
reduce
the
cost
and
redistribute
it
across
all
of
the
different
cloud
vendors
that
are
donating
credits
to
the
to
the
cncf.
B
Also,
if
you
I
mean
yeah,
there's
an
issue
about
this
already.
I
think
aaron
martian,
that
this
slack
channel
thread
like
this,
basically
that
residual
is
kind
of
complicated
about
permission
so
we'll.
I
think
everyone
is
still
investigating
these
those
things,
but
I
feel
like
this
can
be.
Do
I
think
I
can?
Basically,
I
can
maybe
help
you
see.
C
We
can
try
to
do
it
asynchronous.
I
found
that
for
some
of
these
items,
because
we
don't
know
what
we
don't
know
like,
we
can't
access
it.
So
when
there's
someone
who
has
access
and
you
try
to
access
it
as
someone
who
doesn't
have,
we
can
actually
identify
the
permissions.
So
in
these
instances
and
identifying
permissions
historically,
we
have
had
two
people
pairing
together
to
identify
what
is
lacking.
C
B
I
think
the
first
thing
we
should
basically
do
right
now
is
identify
the
permission.
You
need
that's
the
first
thing
to
do:
yeah
yeah,
I
think
yeah
for
basically
I
think
you
have
a
separate
google
group
for
that.
So
the
first
thing
to
do
is
just
identify
the
permission
you
need
and
we
can
iterate
from
that.
C
We
now
have
the
permissions
the
we've
signed,
the
the
pii
information
yeah
access
it,
so
we
should
be
good
to
go
ahead
and
grant
that
whenever,
whenever
we
figure
out
what
those
permissions
are.
B
B
So
we
can
either
end
up
in
the
meeting
right
now
I'll
go
over
the
board,
basically
milestone
planification,
because
I
feel
like
in
10
minutes.
We
can
go
over
the
old
board
for
the
next
price.