►
From YouTube: Configure team meeting - 02-11-30
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
B
B
Yeah,
you
know
my
my
wife
and
I
we
you
know
we
started
going
to
bed
at
like
11
and
then
midnight,
and
now
it's
one
now
it's
1
30
or
2.
B
C
B
A
B
E
E
It
the
weekend
was
super
hard,
like
40
plus
degrees,.
E
E
It
happens
several
times
a
year.
I
guess,
and
I
mean
if
you
look
inside
of
the
continent-
that's
much
worse.
It's
14
next
to
the
ocean
and
over
there
in
the
desert,
don't
go
there.
B
B
B
B
I
think
we'll
get
started
looks
like
marie
yeah
welcome
everyone
to
the
configure
team
meeting
for
monday
november
30th,
let's
dive
into
it.
So
I
see
that
maria
was
asking
if
we
have
a
private
if
the
private
live
stream
is
automatically
uploaded
to
youtube,
but
not
it's
not
in
the
playlist.
B
My
understanding
is
that
we
have
to
manually
add
these
to
the
playlist
and
then
victor
helpfully
pointed
out
the
folder.
I
just
wonder
if
so
then
like
right
now
we're
not
we're
not
live
streaming.
Correct.
A
So,
basically,
just
by
adding
the
rack
to
the
name
of
the
meeting,
these
are
automatically
picked
up
by
a
script
and
added
to
that
folder
that
I
linked
to.
So
I
even
I
yeah,
I
even
removed
the
the
text
from
the
from
the
header
of
the
page
that
says
that
live
stream,
and
this
is
the
youtube
playlist
to
the
archives.
So
I
would
say
that,
let's,
let's
just
use
this
link
in
the
future,
I
added.
B
B
Yeah,
that's
great
cool,
so
yeah,
let's,
let's
dive
into
discussion
items.
So
the
first
thing
was
that
maria's
item
for
the
week
is
the
terraform
state
details
page
in
virgin
version
management,
ui,
she's,
hoping
to
scope
the
discussion
break
down
the
issue,
open,
dev,
specific
issues
and
close
the
design
issue
and
hopefully
get
everything
100
ready
for
development.
B
A
Yeah,
I
can
give
you
more
details
as
well,
so
this
is
about
the
state
listing
having
actions
in
this
state
list.
The
issue
that
that
we
would
like
us
to
scope
here
and
split
into
multiple
issues
are
about
the
details
section.
So
a
single
state
details,
everything
included,
including
even
the
versions
and
everything
there.
B
Okay,
I
see
so
and-
and
I
think
that
I
think
that's
where
I
maybe
got
a
little
bit
lost
because
it
all
looks
like
it's
like
the
same
page
right
in
in
a
sense
we're
we're
talking
about
the
state
listing
page.
But
it's
there's
it's
progressive
right.
So
we
we
we
currently
have
the
state
list.
A
A
B
A
Just
in
case
you,
you
might
not
be
familiar
with
the
designs
actually.
This
is
why
I
joined
the
meeting
today.
So
if
you
scroll
down,
you
can
see
two
comments.
I
will
read
my
comment
because
that's
what
I
understand
better.
So
there
are
four
steps.
Basically
one
would
be
just
state
details
page
with
this
top
top
level
state
information,
the
top
level
state
information
is,
if
you
look
at
at
any
of
these
details,
views
there's
just
state
name.
A
A
I
would
like
to
add
the
the
second
item
as
well
in
my
list,
which
is
the
the
diversions
table,
which
I
would
say
the
at
the
core
of
of
of
this
page
it.
This
is
that
probably
misled
nicolas
as
well,
because
this
is
very
similar
to
the
versions
list
to
the
state
list
view,
and
this
is
just
the
table
without.
A
In
the
first
step,
I
would
add
the
the
actions
as
we
did
with
the
with
the
state
listing,
but
these
are
already
actions
of
a
given
version
except
for
comparison,
and
then
there
is
a
fourth
item,
which
is
not
that
very
important,
because
we
actually
have
these
actions
in
the
in
the
state
list
view.
A
B
No
yeah
yeah
like
you,
you
definitely
oh.
So
what
am
I
doing?
I'm
gonna
copy
this
out
of
here
into
the
definition
of
done
here
so
and,
and
I'm
wondering
so,
is
that
so
are
these
in
priority
order,
like
of
what
you
would
consider
to
be
highest
to
lowest
priority
right
now,.
A
That
that
was
my
idea,
but
it
has
happened
already
quite
a
few
times
that
when
the
discussion
started,
it
turned
out
that
better
prioritization
exists.
So
I
okay,
it's
not
setting
stone
at
all.
B
Right
and
then,
okay,
so
so
I'm
just
gonna,
I'm
just
gonna
go
over
just
one
more
time,
so
we've
got
state
details,
page
of
top
level
state.
That's
just
like
the
basic
state
information
that
we
already
have
in
the
database,
we're
just
displaying
it
on
the
state,
the
top
of
the
of
the
page
and
there's
a
versions
tab.
The
versions
table.
F
B
Okay,
so
we
would
need
to
delete
it
and
store
it.
Okay
and
then
there's
the
version
step
with
the
versions
table.
That
was
the
thing
that
I
got
confused
on
where
you're
seeing
a
very
similar
set
of
version
changes
likely,
we
can
reuse
a
lot
of
the
components
that
we're
using
for
the
the
listing
page.
B
Then
there's
actions,
we
have
individual
actions
for
the
state
versions.
So
we're
saying.
A
That's
a
really
good
question.
I
was
just
searching
those
as
well.
I
I
remember
some
designs
around
that,
so
I
can
try
to.
B
D
I
commented
I
commented
on
one
such
design
earlier
today,
it's
probably
still
in
my
email.
I
can
find
it.
B
Okay,
yeah,
I
I
guess
I
guess
what
I'm
saying
is
that
might
again.
I
just
spoke
with
her
this
morning.
What
what
I,
what
I
think
she
is
intending
is
that
we
do
this
progressively,
where
we
first
do.
You
know
this
iteration
has
no
actions
and
then
a
subsequent
iteration.
We
add
that
in
there.
A
That's
it
correct,
but
it
should
be
your
job
to
decide
on
the
right
split
of
the
issue
and
it's
not
maria's
job.
So
if,
if
emily
says
that
we
have
all
the
back-end
apis
there,
we
know
how
to
put
it
together.
It's
it's
a
matter
of
minutes
to
put
even
the
actions
on
the
on
the
versions
list.
Then
we
can
just
have
it
in
a
to
do
as
a
checkbox
and
we
don't
need
a
separate
issue
for
it.
But
actually
the
the
job
today
with
this
discussion
is
to
have
multiple
issues
scoped.
B
D
Oh,
the
other
one
is
the
other.
One
is
a
list
of
versions.
A
H
I
would
almost
want
to
treat
that
more
like
we
treat
like
if
you
look
at
like
repository
files,
you
know,
there's
a
file,
a
name.
The
commit
message
like
the
little
blurb
of
commit
message
from
the
last
commit
and
last
updated,
and
that's
it
to
do
anything
with
the
file
you
have
to
click
through
to
the
file.
So
I
almost
wonder
if
we
shouldn't
kind
of
keep
that
so
that
these
two
views
are
a
little
less
similar.
A
This
this
is
not
this
the
goal
of
this
discussion.
I
understand
your
worries,
as
I
see
many
of
you
being
confused
maria
run,
the
interviews
and
during
the
interviews,
this
did
not
emerge
as
leading
to
confusion.
B
G
You
need
some
way
to
choose
the
two
versions
that
you
need
to
compare,
so
you
need
a
list
but
like
the
commit
message
and
the
pipeline
is,
is
that
all
associated
with
the
state
or
is
it
still
there's
no
connection
and
it's
tiger?
Nowhere.
F
The
pipeline
should
be
linked
well,
the
build
actually
the
job,
specifically
that
that
ran
the
update
should
be
linked
now
and
from
that
we
can
get
to
the
pipeline
and
to
the
commit
and
merge
request.
So
it's
a
bit
of
a
few
hoops
to
jump
through,
but
the
link
should
be
there.
B
Okay,
so
it
sounds
like
so
it
sounds
like
we
need
some
way
to
be
able
to
compare
the
two,
so
we
need
a
listing
in
order
to
actually
to
to
get
to
the
high
valued
component,
which
is
the
comparison
right
to
me.
That's
that's
the
that's.
The
high
value
in
this
that's
correct
is
the
actions
really
that
valuable,
or
is
this
just
redundant?
It's
like
I'm
here
makes
sense
for
me
to
be
able
to
have
some.
I
can.
A
Yeah,
I
would
say
that
the
remove
remove
a
specific
version
is
a
valuable
one.
So
if
you,
if
you
put
out
some
credentials
that
you
shouldn't
add
to
your
trunk
from
state
five
and
you
want
to
remove
it,
that's
that's
really
valuable
one,
something
that
actually
I
don't.
I
would
like
to
put
in
premium
as
it's
a
security
feature,
so
that's
clearly
a
valuable
one
for
download
json.
B
B
I
I
and
I
I
say
this
I've
I
talked
with
maria
this
morning.
She
was
asked
me
what
what
I
thought
about
something
that
she
came
up
with
it
looked
like
it
was
kind
of
like
like
these
expander,
you
kind
of
expand
these
different
sections.
I
can't
remember
what
the
ui
element
is
called,
but
she
was
had
each
resource
and
you
could
expand
to
see
the
create,
update
and
delete,
but
does
anyone
know
more
than
I
do
about
that?.
H
H
Yeah
because
the
I
kind
of
pitched
a
few
approaches,
one
was
to
do
textual
dipping
with
sordid
keys.
It
works
okay,
it's
still
a
little
bit
hard,
especially
if
you're
gonna
have
a
lot
of
changes
to
see
exactly.
H
What's
changing
you
kind
of
have
to
dig
to
figure
out
what
you're
looking
at,
because
there's
like
context
lines
are
hard
to
find
so
then
kind
of
the
idea
of
structural,
initially,
just
having
three
sections
create,
update,
delete
and
the
sum
like
kind
of
the
summary
of
how
many
resources
under
each
are
being
affected
and
then
expand
it
and
see
the
the
types
of
resources
under
the
types
you
could
see
the
names
and
then
under
the
names,
see
all
the
attributes
being
changed
and
just
be
able
to
drill
down
the
idea
there
in
my
head
was
you
could
have
the
unexpected
or
the
yeah.
H
H
A
Get
caught
up,
I
I
think
I've
seen
it
in
in
her
weekly
plans
that
she
has
designs
based
on
your
discussion
from
last
week,
and
I
guess
that's
what
she
showed
to
nicholas
as
well,
but
I
haven't
seen
it
either.
B
All
right,
so
that's
sounding
really
exciting.
Generally,
it's
it's
also
sounding
like.
Maybe
that
that
we
should.
We
should
segment
that
off
into
a
second
iteration
of
this
page,
because
it
sounds
like
it's
not
settled.
B
You
know
in
terms
of
definition
of
done,
one
through
four
as
being
iteration
one
and
then
once
the
version
comparison
is
settled,
then
that
would
be
iteration
2.
G
I
think
a
lot
of
it's
going
to
be
a
rewrite
well
because
you
have
to
build
a
whole
new
page
with
a
route.
So
all
of
that
and
then
the
download
and
remove
and
lock
and
unlock,
are
all
associated
with
the
state.
Not
the
version
correct,
so
we'd
have
to
make
new
actions
for
all
of
those
in
graphql.
H
A
G
Okay,
yeah,
we
can
update
sorry
I'm
looking
at
the
definition
of
done
the
download
we're
working
on
now,
which
I
think
can
be
reused.
The
delete
currently
deletes
everything,
so
it
deletes
the
state
in
all
versions
and
we
need
a
new
delete
that
just
deletes
a
single
version.
G
So
well
is
I
guess,
if
it's
me
by
myself,
no,
it's
not
gonna
happen,
but
if
multiple
people
are
working
on
it,
I
think
it's
possible.
A
Actually,
I
can
even
imagine
that
delete
misses
some
back
end
work
as
well,
because
we
had
a
very
quick
chat
with
tiger
last
week
about
that.
What
I
would
like
to
have
is,
when
you
delete
a
version,
delete
it
in
the
database
and
be
sure
that
there
was
a
version
that
was
dated
by
xy,
so
for
compliance
reasons
that
this
could
be
important.
So
we
just
delete
the
the
version
from
the
object,
storage
and
mark
that
recorders
deleted.
A
H
A
B
G
Yeah-
and
I
would
say
we
might
want
to
update
the
design
for
that
as
well.
I
would
I'd
make
it
a
separate
item,
because
when
I
first
saw
it,
I
thought
it
was
pending
deletion
and
there's
really
nothing
there
communi.
As
far
as
I
can
tell
it's
communicating
that
it's
still
there,
but
in
reality
it's
not
there,
so
it
needs
to
be
communicated
that,
like
it's
not
recoverable,
even
though
we're
showing
you
data,
that's
there
there's
no
way
to
actually
recover
the
files,
because
they've
been
deleted.
A
H
H
You
know,
and
and
this
is
where
I
would
also
put
the
you
know
so
and
so
deleted
two
months
ago,
you
know,
or
one
day
ago,
like
you,
can
kind
of
repurpose
this
information
and
there
won't
be
a
commit
associated
it'll,
be
manually,
updated
so
and
so
deleted
it,
and
when
they
did
there's
no
there
won't
be
a
pipeline.
Resources
will
be
zero
like
there's
nothing.
It's
gone.
A
If
I'm
thinking
about
the
secular
perspective,
that's
why
we
want
to
keep
the
line,
the
record
itself,
that
there
was
something
happening
and
if
we
remove
even
the
pipeline
and
commit
details
there,
it's
like
how
will
you
figure
out
what
happened?
You
just
know
that
who
did
it,
but
you
don't
know
what
was
behind
it.
H
You
make
a
really
good
point.
There
may
also
be
a
case
for
like
allowing
someone
or
maybe
even
requiring
someone
to
specify
a
reason
for
deletion
so
that
we
can
display
that
too
yeah.
H
G
Yeah,
that's
what
I
well,
I
would
say
if
we
want
to
just
have
a
delete,
that's
just
delete.
We
can
kind
of
move
forward
with
that,
but
if
we
want
to
have
this,
you
know
very
outlined
process
of
what
can
be
deleted
and
what
can't
be
deleted.
And
how
do
we
track
deletions?
I
I
would
say
that's
more:
it
maybe
needs
more
investigation
and
a
different
design.
A
B
Yeah,
okay,
so
so
so
what
if
we
yeah?
You
know
and
I've
I've
updated
the
iterations
here.
So
so
are
we
saying
that
we'd
want
another
iteration
where
it's
like?
So
this
is
three,
and
this
is
four,
so
we
take
out
remove.
C
G
B
Okay
is
that
is
that
what
we're
imagining,
how
I
just
updated
it
that
we
first
ship
the
ability
to
download
and
unlock,
and
then
we
ship
removal
of
the
state
version
or
deleting
of
the
entire
state.
B
B
Okay,
so
so
deleting
here,
because
our
our
concern
is
that-
and
the
reasoning
here
is
that
so
the
reasoning
is
that
there's
some
complexity,
potential
complexity,.
A
Would
even
say
like
we
should
we
should
we
should
research
it
with
maria,
like
from
my
side
as
well?
What
is
the
problem
there
really
that
our
users
have
and
we
can
ship
the
right
like
what
matt
just
proposed
that
when
somebody
wants
to
date,
we
have
to
ask
for
a
reason:
that's
a
pretty
reasonable
idea,
I
would
say,
and
we
should
ask
it
from
our
users.
What
is
the
reason
behind
asking
for
this
feature
and
after
that,
they'll
be
more
clever
on
it?.
H
A
H
Don't
have
anyone
else,
I'm
just
watching
watching
victor
victor
typing
on
iteration
one,
that's
gonna,
add
a
thought
here
to
state
file
size.
This
is
this,
along
with
other
other
pieces
of
this,
of
this
page
are
going
to
be
like
they're
actually
belonging
to
whatever
the
latest
version
is.
B
B
All
right
cool
on
to
the
reverse
tunnel
and
we
are
running
a
little
over
time
so
but
let's
dive
into
it.
B
Victor,
do
you
wanna?
So
basically
I
have
you.
You
were
curious
about
what
is
the
end
user
experience,
what
should
be
set
up
in
ci
and
what
what
currently
exists,
that
we
could
leverage
to
sort
of
drive
towards
a
mvc.
A
So,
given
that
we
would
use
the
ci
for
deployments,
my
expectation
would
be
that
almost
everything
that
we
have
today
works,
except
for
gitlab
managed
clusters,
because
gitlab
managed
clusters
create
their
own
service
accounts
and
namespaces
and
all
that
stuff,
so
that
won't
work,
but
otherwise
all
the
existing
gitlab
commands
information
integrations
with
environments
and
review
apps
would
just
work
out
or
works.
This
is
my
expectation
based
on
my
understanding
of
this
feature,
but
I
did.
D
D
Gitlab
will
just
have
a
separate
set
of
credentials
for
for
internal
use,
just
like
it
does
now,
but
it
would
be.
You
know,
going
over
the
cass
bridge
or
gas
tunnel.
D
Like
that,
like
cass,
would
have
well
agent
k
in
the
end
would
control
exactly
what
gitlab
can
do
on
one
hand
and
what
the
ci
can
do
on
the
other
hand
and
like
so
that
would
there
would
need
to
be
some
sort
of
support
on
that
side.
Maybe
to
pick
an
account.
H
E
I
just
wanted
to
add
that
I
have
left
a
comment,
so
where
should
I
paste
the
link
here?
Maybe
I
have
left
a
comment
a
while
ago
about
the
the
options
that
we
have
three
months
ago
about
the
options
that
we
have
to
for
authorization,
and
I
think
we
can
start
with
it
just
uses
its
own
identity,
but
I
don't
think
it's
a
good
good,
long-term
solution.
E
I
think
it
should
for
each
individual
job
from
ci.
That
is
accessing
things.
It
should
have
a
separate
group
that
it's
using
to
access,
or
maybe
group,
should
be
pair
pipeline
or
pair
project,
maybe
per
project
yeah,
and
then
it
can
use
the
administrator
can
use
airbag
to
say,
okay,
this
ci
can
do
this.
The
ci
pipeline
can
do
this
stuff,
and
this
ci
can
do
this
stuff,
and
this
should
all
be
configurable
via
the
configuration
for
the
agent.
E
Either
we
put
them
in
place
or
the
administrator
puts
them
in
place.
If,
if
it's
us,
then
it's
also
a
separate
setting
to
make
us
put
them
there,
depending
on
some
configuration
like
a
separate
thing,
the
agent
does
it
as
well,
but
it's
a
separate
kind
of
process
to
put
her
back
there.
But
then
this
feature
of
proxy
doesn't
know
about
this.
E
It
just
makes
the
access
and
uses
the
right
identity
to
make
the
call,
and
then,
if
airbag
objects
are
there
to
pass
or
if
something
is
not
right
like
this
job
is
not
authorized
or
something
it
will
fail.
B
So
I
yeah
I
just
want
to
take
a
second
welcome,
graham
to
the
conversation
graham
we're
we're
actually
discussing
the
reverse
tunnel
right
now,
we're
discussing
what
what
an
mvc
would
look
like,
not
just
to
kind
of
give
you
context.
I
know
that
you
commented
a
little
bit
on
this,
so
we're
trying
to
talk
about
what
a
what
a
mvc
would
be
the
most
basic
level.
B
So
I
guess:
does
anyone
have
so
if
we're
trying
to
come
up
with
an
iter
like
iteration,
one
of
this
like
what
what
are
we
thinking?
Can
we
leverage
deploy
tokens
for
this?
Is
that
what
were?
I
think
I
saw
a
discussion
about
that.
E
It's
about
giving
an
identity
to
a
build
and
making
sure
cast
can
understand
who,
if
this
identity,
if
this
talking
for
this
identity
is
a
valid
token
and
then
authorize
so
authenticating
the
access
and
then
now
checking
if
it's
authorized
to
perform
an
action
on
the
in
the
cluster
and
and
also
obviously
actually
implementing
the
tunneling.
E
E
Yes,
it's
a
token
to
talk
to
car
that
will
be
used
to
talk
to
cars,
but
it
will
be
used
by
cube
ctl
and
it
will
think
it's
talking
to
cars
to
keep
renters
api
but
yeah.
It
will
because-
and
it
will
get
this
token
and
it
will
understand
which
build
which
pipeline
is
talking
to
it.
I
think
it
should
be
possible.
With
this
token,
I
I
hope
because
well,
if
not,
if
it's
not,
then
this
token
is
not
fit
for
for
this
job.
E
D
Yeah
that
sounds
like
mvc
as
long
as
we
also
offer
the
ability
to
turn
it
off
on
the
agent
site.
Well,
it's
off
by
default
yeah
exactly
so
it
would
be
yeah.
I
guess,
and
then.
A
E
D
E
I
thought
this
is
this
needs
to
be
in
the
agent's
configuration
and
we
need
to
tie
what
project.
What.
A
E
Project
and
job
right
and
what
permissions
later
so
then
this
ci
job
gets
this
token
injected
and
cube
keeps
still
configured
for
that.
B
My
thought
is
to
come
up
with
the
I
feel
like
we
got
a
little
bit
caught
up
in
the
private
repo
discussion
about
how
it
was
all
connected
and
configured
and
authorized
with
this.
Can
we
just
assume
the
most
reasonable,
deep,
like
default
path,
just
assume
the
most
simple
thing
and
just
make
that
work?
B
E
I
don't
know
if
the
if
ci
tokens
already
have
that
then
okay,
but
then
cass
needs
to
understand
that
this
job
is
allowed
to
actually
make
this
call.
So
it
needs
to
have
some
knowledge
to
authorize
the
request.
It
can
authenticate
the
request,
but
then
it
needs
to
authorize
it
and
that's
where
we
need
the
link.
E
We
can
cut
the
scope
here
and
say
for
the
same
repository:
all
jobs
are
authorized
just
like
what
we
did
with
the
manifest
access.
So
if
you
have
everything
in
your
one
repository,
then
okay,
it
just
works.
E
And
can
also
be
enabled
by
default,
and,
yes,
I
think
that's
the
most.
A
E
B
Yeah,
I
mean
I
mean.
Obviously
what
people
are
going
to
want
to
do
is
they're
going
to
want
to
well,
maybe
I'm
assuming
this
incorrectly
but
they're
going
to
want
to
have
agent
repositories
and
then
they're
going
to
have
all
their
projects
that
they
want
to
deploy
through
their
their
agent
right.
That's
where
we
want
to
go,
but
is
the
most
simple
first
step
to
just.
Do
it
all
in
one
repo,
and
then
we
can
sort
of
basically.
A
A
Then
you
are
project
level.
If
you
can
once
we
have
group
level
agents,
then
we
have
to.
We
have
to
have
a
an
answer
to
these
questions
that
that
mikhail
asked
here,
because
but
at
that
point
we
have
to
figure
out
how
to
do
that.
I
Sorry,
sorry,
if
I
can
just
jump
in
and
add
a
few
thoughts
as
well,
I'm
just
talking
about
project
and
group
projects
and
everything
I'll
freely
admit.
I've
been
reading
everything
that
has
been
happening
on
all
the
issues,
but
mostly
just
kind
of
taking
in
people's
thoughts
and
feelings,
because
I
think
the
problem
space
is
probably
a
lot
more
complicated
than
my
specific
use
case,
but
I
just
wanted
to
provide
some
ideas,
thoughts
that
you
may
want
to
consider
that
make
some
of
these
decisions
easier.
I
I
A
lot
of
these
points
before,
but
I
think
they're
just
worth
repeating
a
few
different
things,
at
least
from
my
perspective
and
and
thinking
from
the
perspective
of
probably
more
advanced
kubernetes
users
and
kubernetes
adopters,
and
things
like
that
who
were
experienced
with
githubs
and
bits
and
pieces.
A
few
things.
C
I
Try
and
keep
in
mind,
I
think
one
kubernetes
one
of
the
great
things
about
kubernetes
is
that
you
can
deploy
things
the
same
thing
even
multiple
times
in
isolation.
So
I
think
we
should
never
be
scared.
If
the
answer
to
something
is
you
have
to
deploy
more
agents
or
if
you
have
to
deploy
the
edge
of
more
than
one.
So
it's
especially
important
when
you
consider
permission
models.
We've
got
like
three
or
four
auto
devops
apps
that
we
probably
want
to
run
in
the
same
cluster.
I
I
have
no
problems
deploying
agent
k
or
cass
or
whatever
it
is
probably
agk.
I
guess
multiple
times
like
it
only
uses
what
50
megabytes
100
megabytes
worth
of
memory
or
whatever,
but
if
it
keeps
my
sanity
in
terms
of
permissions
model,
saying
like
if
it's
like,
I
can
easily
don't
have
to
worry
about
like
trying
to
do
this
big
grid
of
mapping
and
trying
to
understand
why
I
would
happily
take
the
hit
of
like
an
extra
two
or
three
casts.
That's
like
an
extra
100
to
200
megabytes.
I
Two,
following
on
to
that
is
be
careful
of
this
constant
idea
and-
and
this
will
vary
across
people,
and
it
varies
across
company
philosophy
and
company
size,
but
the
concept
of
going
back
to
your
option
operations
team
is
a
bottleneck
in
large
companies.
So
I
worked.
A
company
used
to
work
out
was
very
large.
They
had
massively
large
kubernetes
deployments.
They
didn't
want
the
ops
teams
to
be
a
bottleneck.
You
know
they
wanted
to
be
able
to
give
namespaces
to
development
groups
and
they
could
do
whatever
they
want.
I
So,
following
on
from
that,
I
don't
wouldn't
expect
in
that
size
company,
where
you
have
thousands
of
developers
to
go.
I
need
to
go
and
talk
to
the
operations
team
to
configure
a
cat
like
to
you
know,
set
up
the
castle.
They've
only
got
one
cast
running
and
for
a
thousand
development
teams,
and
I
have
to
go
talk
to
them
about
permissions
and
stuff
that
just
simply
wouldn't
happen.
They'd
just
simply
go
hey.
You
guys
got
a
gitlab
there's
like
a
thousand
development
teams.
You
just
each
of
you,
go
to
podcast.
I
I
I
I
would
say
it's
the
opposite,
and
if
you
make
something
for
smaller
companies,
they're
probably
only
going
to
have
one
namespace
anyway,
so
cluster
wide
can
still
be
a
single
namespace
for
them,
and
the
final
thing
I'll
say,
and
I
and
I
think
once
again,
I
think
this
is
something
we're
kind
of
depending
on
different
uses
of
everything,
but
I
don't.
I
would
try
for
my
personal
workflows
and
everything,
to
avoid
what
I
call
click
ops.
I
do
not
want
to
go
into
a
user
interface.
I
I
do
not
want
to
have
to
click
and
add
permissions
via
that.
I
cannot
automate
that
I
cannot
track
that
in
any
history
or
anything
like
that,
so
especially
for
a
company
like
gitlab,
I
think
it's
really
important
how
we've
demonstrated
anything
at
the
company
changes
through
a
merge
request,
whether
it's
a
documentation
on
the
website
or
whether
it's
granting
access
to
a
user.
I
hope
anything
we
do
with
cass
makes
that
same
model
user
interface
for
people
who
aren't
familiar
with
git
as
an
option
perfect
underneath
you
know
all
that
kind
of
stuff.
I
If
it's
doing
git
commits
perfect,
not
a
problem,
but
please
just
make
sure
you
don't
make
anything
mandatory
click
offs
so
that
I
can
still
can
just
control
everything
through
good.
So,
as
I
said
those
points
I
don't
think
necessarily
solve
that
problem,
but
I
just
know
with
the
use
case
talking
about
how
do
we
handle
private
repos
accessing
different
cases
and
things
like
that?
I
Don't
be
afraid
at
least
to
start
with,
until
we
get
more
users,
really
understanding
it
and
using
it
to
just
say,
simple,
simple
model
you
know
talking
about
the
cass
agent
has
to
be
a
project
level
agent.
We
have
no
concept
of
group
group
agents.
Maybe
that's
what
you
start
with,
and
you
say:
okay,
we're
just
going
to
push
that
away
for
a
moment,
because
we
know
it's
more
difficult
and
we
keep
a
very
simple
secure
model.
Repo
cast
repo
cast
fair
enough.
I
You
might
have
to
deploy
cast
more
times
than
you're
comfortable
with
that's
not
great,
but
it's
not
bad.
For
a
first
start
and
from
there
we
can
kind
of
start
to
like
edge
out.
You
know
what
what
is
the
actual?
You
know
boundaries
around
them.
That's
just
my
my
thinking
from
gitlab.com
infrastructure
side
of
what
we
do
and
you
know
what
we're
interested.
E
In
I
think
it
all
makes
sense,
so
I
was
talking
about
the
ui
to
add
group
level
agents
only
because
there
was
a
similarity
of
how
you
do
it
with
the
users.
Like
you
people,
you
know-
and
I
was
also
assuming
I
guess
wrongly
before-
that
if
your
configuration
project
is
within
a
group
that
it
makes
the
agent
a
group
level
agent,
but
that
was
a
wrong
assumption.
I
think
actually.
A
I
have
a,
I
have
a
use
case
for
group
level
agents
that
I
learned
from
users.
I
don't
want
to
push
it
right
now,
because
I
don't
agree
with
graham
that
first
we
should.
We
should
focus
on
a
project
level
approach
which
there
are
probably
plenty
of
users
there
who
can
start
using
the
agent
and
we
should
gain
adoption
and-
and
we
have
to
make
sure
that
the
agent
works
for
them
just
for
for
the
sake
of
of
information.
The
use
case
is
very
simple:
I've.
A
I've
interviewed
a
few
companies
where
the
setup
is
that
they
have
a
group,
and
the
group
defines
a
namespace
because
they
have
multiple
microservices
in
separating
into
projects
under
that
group,
and
they
just
want
every
microservice
to
to
be
deployed
to
that
same
namespace,
basically
to
that
same
group
and
that's
how
they
want
to
organize
their
setups
and
that's
how
they
that's
why
they
criticize
gitlab
manage
clusters
as
well,
because
they
it
doesn't
allow,
even
if
they
set
a
group
level
cluster,
there's
no
group
level
namespace.
A
Basically
that
goes
together
and
that
they
could
just
say
that.
Okay,
I
want
to
deploy
to
the
group
level
name
space,
not
to
the
project
one.
So
that's
that's
the
use
case
that
I've
seen,
I
would
say,
without
asking
in
four
interviews
out
of
five,
I
was
into
either
that
not
for
three
interviews
out
of
five,
so
I
don't
know
how
common
it
is,
but
clearly
there
are
a
few
companies
at
least
where
it's,
but
this
is
the
approach.
A
I
Services
they
could
have
a
hundred
and
you're
right.
It
is
tricky
for
us
with
the
gitlab
managed
to
have
stuff
and
other
bits
and
pieces
like
it,
wants
to
try
and
create
name
spaces
which
works
well.
But
actually,
when
we
come
to
that
conversation,
there
is
actually
three
different
areas.
We
need
to
probably
think
from
a
mental
perspective,
to
bring
together
a
gitlab
group,
a
gitlab
environment
and
a
kubernetes
namespace,
because.
F
I
Are
three
separate
concepts
that
we
kind
of
make
this
we
kind
of
try
and
match
them
together,
but
they
don't
always
match
together
one
to
one.
So
when
we
come
to
that
conversation,
I
think
we
need
to
talk
about
what
those
three
things
mean
and
to
each
other,
because
I
think
that's
big
part
of
the
problem
is
an
environment.
Well,
like
environment
is
production,
but
it's
like
to
us.
Production
is
four
different
clusters,
or
production
could
be
multiple
name
spaces,
so
we
there's
this
and
and
a
group.
I
F
A
D
B
All
right,
so
I
guess
I
guess
we
hone
at
all
what
what
a
potential
mvc
would
look
like.
B
Are
we
a
little
bit
closer,
we've
limited
it
to
a
single
project,
project
level
configuration
we're
considering
using
the
ci
job
token.
B
There's
still.
I
still
feel
murky
on
how
the
delegation
or
the
coordination
happens.
I'm
guessing
there's
probably
some
discussion
on
that
in
the
issue.
Already
victor,
do
you
feel
like
we
can
we'll
need
to
continue
talking
about
this?
I
assume
quite
there
yet.
A
D
I
Okay,
the
multiple,
so
my
my
first
thinking
is
it'd,
be
great
to
just
say
you
can't
have
multiple
agent
k,
instances
per
project
and
that's
probably
a
reasonable,
at
least
first
starting
point,
however,
and
I
can
even
for
our
use
text,
we
have
four
clusters
in
our
production
environment,
so
we're
going
to
need
multiple
agents.
So
it's
not
really.
I
We
can't
limit
that
too
much,
at
least
not
for
very
long,
but
at
the
same
time
I
mean
that's
the
bigger
question,
but
you
could
argue
if
I
have
four
agents
one
on
each
of
my
four
clusters:
they're
all
at
the
project
level.
I
would
expect
you
know
whenever
I
do
something
into
the
project
level
to
basically
all
four
of
those
case
pass
agents
to
be
basically
consuming
that
right.
It's
still
a
whether
it's
multiple
sorry
agent
k,
not
cast
agents.
A
D
I
I
D
Yeah
the
problem
with
having
it
at
the
price
like
single
project
and
like
protected
environments
and
all
that
is
that
the
conflict
file
lives
in
the
project
itself
and
if
you
create
a
branch
changing
the
project
file.
Well,
I
guess
it's
always
on
the
main
branch.
It's
always
right
from
the
main
branch
anyway.
So
that's.
D
I
And
I
think
that
folds
into
the
other
there's
an
issue:
we've
got
open
to
change
environments
from
being
about
a
branch,
is
an
environment
to
a
file
glob
in
a
repo
as
an
environment,
which
is
another
that
that's
got
a
whole
other
range
of
issues
as
well.
But
that's
another
important
thing
for
manifests.
Terraform
things
like
that.
We
always
do
environments
is
everything.
I
Is
what's
real
and
environments
live
in
subdirectories
or
files
underneath
that,
whereas
the
branch
model
at
the
moment
works
well
for
review
sites,
I
think
you
know
you
create
a
branch,
create
a
review
site.
That's
great,
but
you
know
the
the
master
protected
environments
is
on
the
master
branch,
but
in
different
folders.
So
that's
part
of
that
as
well.
B
So
so
I
unfortunately
need
to
drop,
but
I
we
didn't
get
into
the
agent
breakout.
Do
people
want
to
continue
with
that
on
their
own?
I
feel
bad
that
I
have
to
drop.
B
B
We
could
always
do
async.
I
was
mainly
concerned
about
just
the
road
to
get
into
production
the
agent.
Maybe
we
can
just
discuss
that
into
async.
I
Look
from
the
infrastructure
side,
which
probably
can
give
you
the
biggest
insight.
I
think
the
big
road
map
now
is
getting
all
the
observability
in
place,
everything
that
was
highlighted
that
needed
to
be
done
in
the
initial
readiness
review
for
those
who
haven't
seen.
I've
opened
another
branch
on
the
readiness
review
for
basically
the
second
readiness
review.
I've
put
the
pieces,
I've
done
in
there
just
you
know,
because
I.
I
Wanted
to
get
them
documented,
I'm
on
pto
from
the
end
of
this
week,
but
to
be
honest,
a
lot
of
the
pieces
that
need
to
be
done.
I'm
not
the
expert
on
anyway.
We
have
a
sre
observability
team
of
like
six
people
and
I
will
I'll
make
sure,
there's
a
channel
open
there
for
you
guys
to
sync
up
and
have
a
chat
and
just
work
through
that
can
help
you
work
through.
All
that
I
think
most
of
it
is
simple.
I
It's
just
like
getting
some
service,
getting
our
prometheus
to
start,
scraping,
cass
and
then
getting
some
dashboards
and
slos
and
slis
all
the
liquid
stuff.
But
once
again,
that
team
can
probably
talk
you
through
how
and
help
you
go
through
all
that
and
then
I
think,
just
a
final
readiness
review
and
you're
probably
ready
to
go.
I
I'll
make
sure
the
kubernetes,
the
terraform.
I
I
think
all
these
bits
and
pieces
are
done,
so
it's
all
ready
to
go
just
someone
from
delivery
will
need
to
basically
change
like
cass,
enabled
to
true
in
the
helm
chart
to
deploy
it
into
production,
so
I'll
make
sure
everything
is
handed
over,
but
really
just
focusing
on
observability.
I
think
century
integration
was
another
thing
which
is.
C
I
D
E
E
Sorry
once
one
thing
we
just
need
the
names
and
slack
channels.
Please.
I
Yeah,
no
I'll
I'll
go
to
them
and
do
it
like
an
introduction,
say:
hey
look.
You
know
these.
This
is.
They
know.
They've
they've
looked
at
the
readiness
review
already,
so
they
so
I'll
just
give
them
a
heads
up
and
then
I'll
also
do
it
on
your
side
I'll
give
you
the
manager,
slap
channels.
You
know
they're
all
really
helpful
that
they
know
much
more
about
this
stuff
than
me,
so
that
will
probably
getting
down
very
quickly.
D
So
I
haven't
seen
the
second
readiness
review
so
just
well
we're
all
here.
Is
there
anything
that
is
currently
blocked
by
us
so
or
is
it
all
on
infra
at
the
moment?
Is
there
anything
that
we
need
to
do
to
facilitate.
I
From
my
side,
mostly
not
most
of
it
is
like
infra
needs,
you
know,
infra
has
to
set
up
fluent
logging
patterns
or
prometheus
scraping,
or
things
like
that.
Most
of
it
is
blocked
on
infraside.
Certainly
all
our
repos
are
open,
so
you
know
there's
nothing
stopping
yourselves
from
putting
in
the
merge
requests
to
do
that.
So
that's
why
I
think
maybe
just
discussion
with
that
team.
I
You
wanted
some
stuff
in
the
only
other
thing
was,
I
guess,
if
you
have
things
that
want
to
come
into
13.7,
then
you'll
need
to
just
after
13.7
is
released,
just
make
sure
a
quick
message:
delivery
team
just
to
make
sure
that
they're
updating
13.7
in
the
the
if
there's
helm,
chart
changes
as
part
of
13.7
making
sure
the
delivery
team
rolls
that
out
as
well.
E
I
Or
at
least
the
number
you
feel
is
reasonable,
because
we
do
have
things
like
internal
rate
limiting
and
stuff
which
you
may
hit
might
be
good
to
know,
because
what
limits
that
you
have
ahead
of
time.
E
So
I'd
like
to
discuss
quickly
something
else
which
is
the
protect
team
is
trying
to
extend
and
the
victory.
This
is
mostly
for
you.
I
guess
the
protect
team
has
been
trying
to
extend
the
agent
and
cars
with
some
functionality
to
scrape
alerts
from
hubble,
which
is
a
service
on
top
of
cilium,
to
extract
to
observe
traffic.
That's,
that
is
in
the
cluster,
and
they
have
some
very
rough
prototype
to
get
it
get
the
stuff
and
just
print
it
to
the
console
in
agent
k.
E
A
I
think
it's
a
good
thing
for
multiple
reasons.
One
is
that
if
you
go
forward-
and
I
think
we
will
go
forward
as
soon
as
possible,
with
the
reverse
tunneling
review-
apps
are
solved
in
the
current
state.
You
can
get
review
apps.
If
you,
you,
don't
use
manifest
projects,
but
you
can
get
review
apps
in
a
push
manner.
A
The
other
reason
is
that
we
definitely
want
to
encourage
security
features
because
they
are
really
good
selling
point.
So
it's
it's
good
for
us
as
well.
If
you
have
security
features
supported
through
the
agent
that
that's
great
for
us
and
the
third
point,
I
even
think-
and
I
might
be
wrong
here-
that
this
might
help
with
the
reverse
stone
as
well,
because
here
we
we
are
reaching
out
from
gitlab
towards
agent
k.
So
this
is
this
is
the
work
that
we
plan
to
do
like
two
months
ago.
No,
it's
not.
E
No,
this
is
the
from
the
cluster
to
github.
Okay,
we
will
be
sending
data,
but
it
does
actually
help
with
reverse
tunneling,
because
I
had
to
do
a
huge
refactoring,
which
is
done
now
to
split
everything
into
tiny
bits.
Smaller
bits
and
the
reverse
tunneling
will
fit
very
nicely
into
this
new
infrastructure
called
infrastructure,
so
it
kind
of
indirectly
helps
there
yeah.
A
E
Cool,
so
can
we.
I
was
trying
to
create
an
epic
for
that
to
track
this
work,
because
they
may
be
a
little
bit
of
work
needed
on
the
rails
side
of
things
and
also
I'm
trying
to
have
a
blueprint,
architectural
blueprint
very
like
small,
simple
one,
because
it's
affecting
not
just
us
but
other
team,
or
even
teams
in
the
future.
So
I
want
to
have
a
architectural
document,
even
if
it's
a
very
like
simple
document,
so
to
track
all
that
and
coordinate
all
that.
E
E
And
this
is
all
I
had
I'm
planning
to
record
a
short
video
to
talk
about
this
new
structure.
In
addition
to
the
document
that
I
have
already
just
to
like
do
a
three
minute
overview
or
something
but
yeah,
I
think
I
don't
have
any
other
things
to
discuss
right
now.
Thank
you.
E
E
Okay,
then,
have
a
good
day
morning
or
evening.