►
From YouTube: Marin/Maria-Kubernetes Agent discussion
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
Yeah,
so
you
asked
me
about
the
need
for
a
kubernetes
agent
as
we
have
it
written
now.
There
is
a
definite
need
to
change
things
up
from
what
we
have
right
now,
which
is
this.
I
forgot
how
we
called
it,
but
you
connect
your
kubernetes
cluster
and
add
it
to
your
project
and
so
on.
A
It's
very
inflexible
doesn't
allow
you
to
to
change
things
on
the
go,
doesn't
have
any
trail
behind
configuring
things
right
like
you've,
configured
in
the
interface
and
that's
a
bit
wonky,
and
we
definitely
have
the
need
for
the
agent.
A
A
Yeah
now
it's
not
only
about
the
features
it's
more
about.
What
is
the
company's
direction
with
this
right
now
everything
is
being
like.
Wherever
I
read
about
kubernetes
agent,
you
have
notes
that
say
something
like
this
is
an
experiment
or
we
are
working
on
gathering
data
on
whether
we
are
going
to
be
using
something
like
this
right.
A
To
see
the
adoption
and
so
on,
the
challenge
here,
though,
is
in
order
for
us
for
specifically
for
gitlab.com
to
use
something
like
this.
It
would
require
a
significant
investment
of
time
and
significant
redoing
of
what
we
have
right
now,
and
it
would
require
a
significant
collaboration
between
infra
and
and
in
the
your
team
working
on
this,
which
might
not
be
the
same
path
that
your
team
is
taking
on
implementing
features
and
so
on.
A
But
even
if,
if
it's
the
same
path,
it
still
requires
a
delay
in
in
the
work
we
are
currently
doing
in
actually
doing
the
migration
of
gitlab
on
gitlab.com
to
kubernetes.
So
we
started
with
something
a
year
ago.
The
cass
agent
just
isn't
rolling
out
now.
So
there
is
this
discrepancy
in
time
right
so.
B
A
Might
be
a
good
time
to
talk
about
how
we
could
use
this
as
we
finalize
the
the
work
we
are
doing
at
the
moment
of
migrating
the
stateless
services,
and
maybe
that
can
be
the
point
where
we
can
reevaluate
where
we
can
evaluate-
and
this
is
where
I'm
mostly
confused
right.
That
might
be
the
point
where
we
can
evaluate
whether
it
makes
sense
for
us
to
start
working
with
the
team
and
like
changing,
actually
everything
we
did
so
far
to
adapt
it
towards
towards
this
this
goal.
A
A
B
Course
yeah
I
have
so
many
questions,
I
will
say
them
and
then
we
can
pick
and
choose
okay.
Yeah
first
question
is:
what
use
cases
would
you
see
your
team
having
using
the
agent
for
I.
A
B
B
What
specific
use
cases
would
you
see
your
team
using
the
agent
for.
B
B
A
Your
specific
use
case-
I
could
see
us
using
the
agent
for
is
githubs.
That
is
the
basically
what
we
are
doing
right
now
with
our
own
custom
solution
with
with
ci
and
and
helm.
So
the
problem
here
would
be.
We
will
have
to
probably
use
a
helm
operator
connected
to
cass,
to
use
our
own
helm
chart
that
we
then
deploy
to
gitlab.com.
A
So
we
don't
so
we
have
our
own
project
that
gets
the
gitlab
helm.
Chart
applies
the
configuration
that
we
need
for
gitlab.com
pulls
the
secrets
from
various
places
connects
to
various
services
to
actually
do
some
work
to
prepare
the
helm
chart
for
deploy,
and
then
it
connects
to
the
kubernetes
cluster
and
rolls
out
the
the
changes
that
we
made
from
within
the
charts,
basically
and
yeah,
and
rolls
it
out
to
the
kubernetes
cluster,
making
it
available
on
github.com.
Basically,
so
that's
what
it
the
project
basically
does.
A
B
Is
that
for
like
the
migration
as
part
of
the
migration,
or
is
it
the
like
final
process?
I.
A
Yeah
exactly
so,
I
wouldn't
call
it
final
necessarily,
but
this
is
gitlab.com
deployment
process
on
kubernetes
right,
so
we
are
not
married
to
the
project
itself.
Again,
like
I
said
it
was
built,
as
is
a
is
a
need
that
we
had
that
we
couldn't
fill
with
anything
else,
and
I
think
we
are
all
ready
to
change
it,
but
once
we
complete
the
migration
for
sure
right
now,
it's
working
it's
working
for
us
really
well,
so
migration
is
taking
the
priority
of
any
changes
in
there.
B
And
would
you
use
in
the
new
world
after
automation,
after
migration,
would
you
use
the
agent
to
automate
stuff,
so
would
you
say
in
my
dev
environments,
I
want
to
deploy
changes
from
a
manifest
project
automatically.
A
Probably
not
that
way,
mostly
because
one
of
the
other
dog
fooding
requirements
that
we
have
is
that
we
use
whatever
the
distribution
team
builds
to
install
gitlab.
So
what
our
customers
are
using
to
install
gitlab
itself
is
what
we
also
use
for
gitlab.com,
which
would
mean
that
we
either
have
to
use
the
helm
chart,
as
is
so.
That
means
we
need.
The
only
need
we
have
right
now
is
then
to
drop
a
manifest
of
some
sort
in
a
place.
A
That
would
be
a
collection
of
configuration
and
interactions
with
other
projects
and
then
push
that
to
helm
chart,
and
I
know
for
a
fact
that
distribution
is
also
working
on
a
gitlab
operator.
That
will
actually
be
the
thing
that
will
be
handling
the
lifecycle
of
gitlab
inside
of
the
kubernetes
cluster.
So
the
operator
is
supposed
to
be
that
controller
of
everything
that
is
happening
in
the
cluster.
Now
the
challenge
comes
from.
A
No,
no!
No!
No!
No!
That's
that's
a
different
thing,
so
the
agent
that
you
you're
talking
about
in
the
in
cass
is
what
would
actually
communicate
with
the
operator
inside
of
the
cluster.
A
B
A
A
Kubernetes
operator
is
something
similar
to
agent
k
inside
of
the
cluster
that
actually
sits
also
in
the
cluster
and
does
some
operations
based
on
the
input
that
goes
into
the
into
the
operator.
So,
theoretically,
what
you
could
do
again,
this
is
just
theoretically
based
on
how
I
understand
it,
you
could
have
your
projects
and
manifest
inside
of
gitlab
and
cass
would
be
able
to
pick
that
up
talk
with
its
agent
agent
k
and
then
agent
k
would
be
able
to
talk
with
your
operator.
Basically,
you
would.
A
We
wouldn't
have
the
need
to
figure
out
how
this
connection
between
gitlab
and
operator
would
function,
because
we
would
be
able
to
leverage
costs
and
agent
k
communication.
So
basically,
this
would
end
up
being
a
communication
pipe
more
than
anything
else
for
us,
so
that
that
is
where
I
think
things
become
very
valuable.
B
B
So
is
helm
related
is
something
is
going
away
right,
something
is
getting
deprecated
that.
A
You
can
connect
your
project
to
the
helm,
charts
sorry
to
the
helm,
installation,
but
the
problem
is
you
can't
configure
anything
so
by
that
going
away
actually
with
cass,
we
would
have
more
options
to
to
actually
use
that
integration
going
forward
again,
depending
on
what
the
direction
of
installation
go
goes
into
right
like
if
we
remain
with
the
vanilla
helm
chart
for
us,
as
it
is
right
now
for
us,
it
would
be
much
more
difficult
to
use
it
because
we
have
a
layer
on
top
that
allows
us
to
work
with
multiple
clusters,
and
that
is
what
currently
doesn't
exist
inside
of
gitlab.
B
A
B
What
level
of
configuration
do
you
think?
Would
agent
k
or
cars
need
to
tailor
for
many
meters
and
what
type
of
configuration.
A
We
we
have
additional
set
of
complexities
there,
where
we
actually
deploy
gitlab.com,
which
means
yes,
we
are
working
on
gitlab.com,
that's
where
our
repositories
are.
That's
where
you
know,
like
general
work
happens,
but
actually
the
actual
deployment
that
we
do
happens
on
a
separate
github
instance.
Because
of
that
dependency
right
like
you,
you
have
to
have
a
separation
of
concerns,
because,
if
something
breaks
from
gitlab.com,
if
there
is
a
bug
and
so
on,
you
cannot
deploy
gitlab.com
which,
which
can't
work.
A
So
for
us,
it's
very
important
that
that
integration,
whatever
it
is,
is
very
flexible
so
that
it
can
actually
communicate
to
a
certain
api
when
necessary.
So
I
could,
I
could
imagine
a
case
where,
theoretically,
you
would
be
able
to
add
a
cass
service
right,
connect
to
the
cast
service
on
gitlab.com
itself,
right
to
pick
up
some
configuration
and
so
on,
and
and
maybe
work
with
the
agent
in
the
cluster.
A
But
then
we
would
also
need
redundancy
that
would
allow
us
to
replicate
that
same
behavior
on
our
separate
instance
in
order
to
make
sure
that
we
can
right.
So
basically,
agent
k-
as
I
see
it,
theoretically
should
be
working-
should
be
accepting
connections
from
two
sides.
A
Almost
almost
equally,
there
are
workarounds
there,
but
I'm
I'm
just
like
brainstorming
right
now
as
well.
There
are
workarounds
how
we
can
do
this
differently,
but
the
point
is:
we
need
to
have
an
option
where
some
work
happens,
on
gitlab.com,
sure,
verification,
testing
and
so
on,
but
the
actual
rollout
and
change
rollout
has
to
happen
on
a
completely
different
one.
B
So
by
mentioning
rollout,
I
I'm
thinking
now:
how
does
the
agent
fit
in
our
existing
functionality,
because
cicd
already
has
incremental
rollout,
and
you
have
a
lot
of
flexibility-
configuring
stuff
there?
How
does
the
agent
help
you?
How
does
it?
What
role
would
it
play
in
this
in
world?
Would
it
be
redundant?
B
Would
it
add
some
benefits
if
yeah.
A
I
think
the
question
would
be
best
asked
for
your
team,
because
that
was
my
initial
thought
as
well
like
I
thought
we
already
had
some
flexibility
there,
so
especially
with
ci
ci
is
super
flexible,
so
it
allows
us
to
do
all
of
these
things
now.
The
difference
that
I
understand
is
ci
has
to
connect
to
the
cluster
externally,
while
agent
k
is
already
inside
of
the
cluster
and
uses
an
established
safe
connection.
A
So
from
that
side
it
actually
removes
all
of
the
configuration
all
of
the
insecurity
that
you
have
within
ci
and
solidifies
it
within
the
the
framework
we
set.
So
from
that
side,
if
cass
ends
up
being
successful
on
agent
k
and
ends
up
being
solid,
I
can
actually
see
that
for
for
kubernetes,
specific
use
cases
actually
replacing
the
the
ci
cd
flexibility
and
working
together
with
it,
rather
than
replacing
it
right,
maybe
being
another
level
of
like
another
connector
for
ci
cd.
That
will
allow
us
to
do
the
cd
parts
of.
B
You
would
have
ci
cd
talking
to
a
agent
k
and
and
then
to
kaz,
and
then
this
would.
A
B
A
A
You're
working
on
your
feature
right,
you
have
your
ci
running
running
some
tests,
running
some
visual
verifications
and
so
on,
and
then
you
have
you
want
to
push
this
forward
through
cd
right
within
the
same
interface.
You
you
don't
really
want
to
have
a
change
of
like
now
go
to
this
page,
where
you
can
see
this
happening
now
within
the
same
interface.
You
want
to
say
all
right
now
I
want
to
roll
it
out,
which
is
the
cd
part.
So,
within
the
same
interface,
your
connector
would
talk
with
cass
cass
would
goes
agent
k.
A
Something
out
on
staging,
for
example,
staging
goes
well
and
it
tells
you
like
hey.
I
succeeded
with
my
work
and
you
would
do
more
ci
stuff,
you
would
probably
I
don't
know,
do
another
very
qa
set
of
things.
Maybe
you
would
run
an
automated
qa.
We
we
do
run
that
already
as
well,
and
that
would
allow
you
to
you
know,
get
the
result
of
whatever
was
happening
in
staging
is
okay,
and
then
we
would
again
connect
to
cass
and
say,
like
hey
roll.
This.
A
Until
we're
done,
but
obviously
through
this
pipe,
what
you
would
also
want
to
see
is
you
send
some
requests
for
hey
when
you're
deploying
collect
these
type
of
metrics?
For
me,
I
need
memory.
I
need
cpu.
I
need
rps
rps
or
something
like
that
and
as
this
thing
gets
done
like
you
would
get
that
feedback
back
and
you
would
be
able
to
do
something
with
that
continue.
B
A
Yeah
and
within
multi
within
those
environments,
you
can
still
have
multiple
clusters,
so
it
works
on
multiple
levels.
You
can
have
like
a
staging
environment
that
has
a
cluster.
You
can
have
production
environment
that
has
a
cluster,
but
what
actually?
For
us,
what
happens?
Is
our
staging
environment
has
four
clusters.
A
B
A
I
don't
like
I'm
only
looking
into
it
now.
I
don't
know
how
much
it
can
actually
do,
but
from
from
my
like
general
understanding,
we
don't
need
or
want
specifically
to
configure
multiple
agents,
at
least
not
for,
let
me
think,
would
we
even
want
to
configure
more
than
one
class
for
all
of
our
environments?
A
B
B
Because
at
the
moment
and
that's
the
ux
problem,
I'm
facing
you
have
agents,
you
have
one
agent,
it
has
a
configuration,
then
you
have
a
manifest
project
where
you
describe
what
they
say.
You
want
this
agent
to
deploy.
You
have
to
go
to
your
manifest.
Configure.
Add
your
configuration,
you
have
to
install
your
agent
with
its
configuration
and
then
you
also
have
to
link
these
two.
B
A
Like
a
long
time
ago,
before
ci
was
an
integrated
product,
we
had
a
separate
ci
then,
and
it
was
a
horrible
user
experience
because
they
had
to
do
exactly
what
you're
saying
and
no
one
wanted
to
do
it,
because
it
was
complicated.
B
My
question
is:
okay,
you
are
the
operator
you
have
control
of
the
agent.
I
am
the
developer.
I
have
control
of
the
manifest.
I
have
to
come
to
you
and
say:
can
you
add
my
manifest
to
your
agent?
How
do
I
know
you
have
an
agent?
How
do
I
know
there
is
an
agent
concept?
I
don't
so
I'm
basically
trying
to
somehow
simplify
that
as
a
next
step.
B
So
the
npc
is
going
to
be
this
complex
configuration
by
our
conversation,
I'm
thinking,
maybe
we
could
use
cause
to
some
level
to
configure
multiple
agents
and
say
I
don't
know
somehow
assign
manifest
projects
automatically
depending
on
availability
of
clusters.
Would
that
be
something
feasible
or
desirable?
A
So
I
I
don't
know
how
to
answer
that
question.
I
guess,
because
I'm
missing
more
information
on
how
cars
actually
works
or
like
what
kind
of
options
it
has.
But
basically,
if
you
go
to
our
repository
right
now,
we
maybe
that
will
help
to
explain
like
how
we
certain
we
do
things
right
now
at
this
moment.
So
we
have
a
single
repository
called
casework,
kate's
workload,
slash
gitlab
com,
so
that's
one
project
in
this
one
project
we
have
all
of
our
manifests
for
different
environments
for
different
clusters.
A
A
All
right,
so
this
is
the
configuration
that
we
have.
This
is
the
general
configuration
that
is
shared
between
all
of
the
environments,
all
of
the
environments
pull
from
this,
because
there
is
stuff
that
we
absolutely
want
to
be
the
same,
but
there
are
specific
things
where
we
have
to
override
things
because
they
are
related
to
the
environment
like,
for
example,
what
is
the
host
name
which
address
to
use
right
like
which
credentials
to
use
for
this
specific
environment?
A
And
you
would
see
that
for
all
of
these,
like
staging
production
production
canary
pre?
So
these
are
the
start,
values
and
so
on
and
so
on.
Basically,
we
have
a
level
that
is
shared,
and
then
we
have
a
level
on
top.
That
is
unique
for
your
configuration
correct
now
you
won't
be
able
to
see
much
in
this
pipeline.
A
A
If
you
take
a
look
at
this,
this
is
our
actual
deployment
pipeline
for
production,
or
no,
not
only
for
production.
The
whole
deployment
pipeline
right,
like
within
the
same
repository
we
do
some
verification
again,
but
now
against
environments,
so
that's
different
from
gitlab.com.
This
is
ops.
We
are
actually
talking
about
real
workloads
that
change
things
right.
In
this
case,
we
just
verify
that
things
are
what
we
want
and
expect
them
to
be,
but
then
you
have
this,
which
is
a
non-production
deploy.
A
If
I
were
to
open
any
of
these
pipelines,
the
only
thing
that
distinguishes
to
which
environment
things
are
going
to
go
is
the
code
that
we
wrote
that,
where
we
said,
if
it's
non-prod
deploy,
then
open
up
this
manifest
file.
Do
it
like
this
like
mangle
it
like
this
and
then
go
connect
to
this
cluster,
and
here
are
your
credentials
on
how
you
connect
to
this
cluster
that
gets
done
all
succeeds.
We
run
some
qa
right
and
then
we
start
running
other
deploy.
A
So
this
is
a
canary
deploy
same
thing
right,
pull
from
the
same
ball
of
mods
untangle.
It
add
some
unique
flavor
to
it.
Connect
to
this
specific
cluster
with
this
specific
same
thing
for
production
deploy.
Now,
if
you
think
of
it
that
way,
what
we
actually
do
here
is
we
connect
with
one?
No
one,
two,
three
four.
Now
let
me
talk
about
environments,
one
two,
three,
four
different
environments,
which
is
between
three
to
four
different
clusters:
okay,.
A
A
I
don't
know
how
that
oh,
I
know
why
I
don't
want
to
complicate
things,
but
production,
for
example,
has
one
two
three
four
clusters
as
well,
so
it
is
many
to
many
relationship
environment.
Many
environments
connect
to
many
clusters
as
well
at
the
same
time.
So
now,
if
you
think
about
it
from
the
ux
perspective,
if
we
go
and
say
I
want
to
either
add
a
single
cluster
connection
between
gitlab
and
kubernetes,
that
would
be
very
inflexible
for
us
and
we
would
be
only
only
able
to
use
it,
for
example,
for
pre.
A
A
A
A
And
it
has
one
manifest
exactly
exactly
and
staging
same
here
I
mean,
I
guess.
Actually
you
can
see
it
here.
The
best
right
this
is
staging.
This
is
our
staging
environment.
It
has
the
main
cluster.
So
this
is
the
I
think
regional
cluster,
and
then
it
has
three
clusters
that
have
arizona
clusters
used
exactly
the
same
configuration
as
the
original
they're
just
being
rolled
out
in
a
different
order.
A
I
think
I
think
you
would,
I
think
you
would
because
the
redundancy
you
have
with
multiple
clusters
is
there
for
you
to
have
other
sorts
of
control,
but
you
almost
never
in
these
cases,
want
to
have
differences.
There
are
cases
where
you
want
differences
between
them,
a
b
testing
and
so
on
and
so
on,
but
that
is
a
bit
step
further.
That
is
more
like
review,
apps
type
of
thing
than.
B
They're
not
as
not
common
but
they're
different
use
cases.
There
are
different.
A
So
I
would
be
quite
happy
if
we
had
a
single
environment
that
we
can
configure
and
we
can
have
the
flexibility
of
rolling
that
same
thing
now
to
multiple
different
clusters,
with
the
same
configuration
and
then
think
later
about
how
we
can
do
like
separate
right
like
how
can
you
override,
for
example,
one
cluster
would
receive
different
configuration
or
different
codes
so
that
you
can
actually
do
some
a
b
testing
and
so
on.
But
that
is
step
too
far.
I
think.
A
B
B
You
have
four
clusters
yeah
and
at
the
moment
you
have
to
specify
in
the
manifest
project
which
agent
is
going
to
deploy
your
changes
so
for
I
guess
which
of
the
four
clusters.
So
if
you
want
to
deploy
your
changes
for
all
four
clusters,
you
would
have
to
go
to
all
four
agents
and
say
this
manifest.
I'm
looking
into
this
manifest
in
an
alternative
experience,
you
say
to
cause:
this
is
my
staging
environment.
This
is
my
manifest.
B
The
agent
to
the
manifest
yourself
and
deploy
changes
yep.
Does
it
sound
a
realistic
scenario.
A
It
sounds
like
an
not
ideal
scenario,
but
scenario
that
would
be
the
most
consumable.
Let's
put
it
that
way
because
imagine
like
in
all
these
automation,
we
have
to
have
manual
steps
or
steps
additional
configuration
to
make
certain
decisions.
That
would
be
a.
A
B
Okay,
so
you
wouldn't
mind
by
this
level
of
automation
or
I'm
gonna
say
you
could
have
some
configuration
too
for
a
cause
and
to
control
what's
happening.
A
Obviously,
like
you,
you
will
definitely
need
to
say
to
to
cause
which
clusters
and
how
to
connect
to
them,
like
that
that
you
can't
avoid
in
any
case,
right,
like
things,
are
not
going
to
materialize
out
of
thin
air,
but
what
I
would
not
want
to
do
is
have
to
like
go
myself
and
then
install
agent
manually
four
times
or
three
times.
Additionally,
after
I've
already
told
you
how
to
connect
to
the
cluster
and
what
kind
of
permissions
you
have,
you
should
be
able
to
do
that
yourself.
A
A
Oh,
it's
a
completely
different
use
case,
at
least
that
I
see
okay.
Autodevops
is
like,
in
my
opinion,
very
much
a
simplified
view
of
all
of
this,
like
you
would
probably
not
work
with
multiple
clusters
like
we
do.
You
probably
have
a
single
cluster
that
would
have
multiple
environments
on
its
on
itself,
so
you
would
have
staging
you
would
have
production
and
all
of
that
in
one-
and
let
me
put
it
this
way.
A
I
I
see
at
least
I
see
auto
devops
as
day
one
operations.
I
just
created
the
cluster,
and
I
just
created
my
project.
I
want
to
connect
them
and
let's
just
get
things
running
right,
I'm
not
thinking
about
the
load,
I'm
not
thinking
about
anything
specific
there.
My
loads
considerations
are
with
how
big
of
a
cluster
I've
provisioned
or
you
know
like
what
kind
of
location
the
application
I'm
running
on
it.
A
This,
where
that
we're
building,
is
not
only
day,
two,
it's
like
basically
day
three,
but
let's
call
it
day
two,
because
that's
a
standard
term
day
two
operations,
which
is
we
already
have
a
successful
business.
We
already
have
certain
traffic.
Now
the
problem
is
we're
running
at
scale,
so
we
want
more
flexibility
with
more
clusters,
because
larger
cluster
doesn't
mean
more
performance.
For
us,
it
might
more
performance,
for
us
means
multiple
clusters
of
a
certain
size
for
various
reasons.
B
A
It
would
be
good
to
share
our
talk
with
with
your
team
as
well,
mostly
because
everything
I'm
telling
you
right
now,
I'm
coming
from
a
very
superficial
understanding
of
cause
and
what
supposed
to
be
doing
and
what
the
goals
of
of
them
are.