►
From YouTube: Kubernetes Integrations with the Agent-GMT20211103
Description
Kubernetes Integrations with the Agent
A
So
hello,
everyone,
I
link
this
presentation
to
the
docs
as
well,
so
you
can
access
it.
I
didn't
prepare
with
the
demo
specifically
because
there
is
a
demo
that
I
had
last
week
or
two
weeks
ago,
so
you
can
just
watch
that
it
shows
how
it
shows
the
advent
setup
of
the
kubernetes
agent.
But
what
I
would
like
to
speak
here
mostly
is
kind
of
a
comparison
with
the
certificate
based
approach
and
as
by
now
many
of
you,
I
hope
know
we
are
going
to
deprecate
the
certificate-based
approach.
A
This
lecture
requires
that
it
came
from
seeds
to
do
it
as
soon
as
possible,
so
we
are
a
bit
of
a
rush
there
and
I
want
to
make
sure
that
you
are.
You
are
ready
for
this
change
and
and
and
discuss
what
you
need
from
from
us,
for
example,
to
make
you
ready.
So
if
you
have
never
seen
the
quest
agent,
these
are
the
primary
resources
that
I
would
recommend
to
to
look
at.
You
are
always
welcome
on
our
slack
channel
with
questions
or
suggestions
or
feedback,
and
let's
dig
into
it.
A
A
The
colors
are
totally
arbitrary,
I
would
say,
with
minor
meaning
red
means
that
there
is
some
issue
around
that
or
not
or
is
not
available
with
the
connect
cluster
with
certificate.
The
issue
is
that
it's
it's
loved
and
used
often
with
self-managed
customers,
but
it's
actually
almost
a
no
hope
for
gitlab
sas
customers,
because
it
requires
cube
api
access
and
even
if
you
can
buy
at
least
only
the
gitlab
ip
addresses
security.
A
Often
fights
back
on
this
and
they're
definitely
not
happy
with
that
integration
and,
as
a
result,
that's
why
it's
red
the
agent
was
designed
in
order
to
avoid
this
and
to
make
sure
that
we
can
provide
an
integration.
That's
ready
for
every
setup.
That's
aimed
actually
for
expert
users
as
well,
because
the
other
option,
the
other
issue
with
the
cluster
certificate,
was
for
which
it
wouldn't
be
red,
is
that
it's
not
very
flexible
and
doesn't
provide
many
use
cases,
but
on
that
certificate
we
built
features
for
four
years
now.
A
So
there's
a
huge
amount
of
knowledge
on
your
side.
Often
on
that
feature
set,
you
know:
gitlab
managed
clusters,
for
example,
that
is
probably
loved
by
many
many
users,
especially
in
development
environments,
because
it
creates
namespace,
creates
service,
accounts
pretty
automatic,
and
you
might
not
use
this
for
production
workloads,
but
you
can
use
it
for
everything
on
production
and
that's
great
here.
We
have
a
big
red
on
the
agent
side
because
we
don't
have
a
workaround
for
gitlab
match
clusters.
A
Yet
I
would
say
this
is
the
biggest
shortcoming
of
the
agent
approach
and
we
are
actively
ideating
on
on
what
else
we
could
offer
probably
won't
have
anything
by
the
end
of
this
milestone,
but
I
hope
that
by
the
time
self-managed
customers
start
to
upgrade,
which
is
as
far
as
I
know,
around
three
months
delayed
by
that
time.
I
hope
we'll
have
an
author
to
offering
build
on
top
of
the
agent
as
well.
A
A
Here
I
just
mean
pool
based
deployments,
that's
something
that
was
requested
by
quite
a
few
people.
This
is
the
trendy
one,
something
that
can
be
an
interesting
kind
of
marketing
hook
for
for
many
many
users,
and
now,
even
with
the
industry
standard
definition
of
bitops,
we
can
support
those
workloads.
A
So
that's
that's
why
now
we
can
do
that
with
the
agent
I
highlighted
ci
cd
as
well
with
the
agent
and
that's
very
important-
that
many
of
our
integrations
are
built
around
github,
ci
cd,
and
you
might
think
that
that
works
only
with
the
certificate-based
connection.
But
this
is
not
true.
We
have
something
called
the
cic
tunnel
with
the
agent
where
you
can
actually
reach
from
a
gitlab
ci
job
to
your
cluster
run.
A
Any
commands
even
promoters
queries
if
you
want
so
not
just
cube
cuts
and
apply,
but
any
command
that
requires
the
cluster
connection
from
gitlab
ci.
We
think
that
this
is
an
amazing
feature
for
many
reasons,
once
this
shows
that
it's
really
an
in
bitlab
integrated
product,
it's
not
just
another
githubs
tool
out
on
the
market.
A
The
reason
for
that
is
because
it's
a
big
question
whether
or
not
it's
a
product
or
it's
a
set
of
templates,
but
the
biggest
issue
there
on
the
agent
side
is
that
currently
we
don't
support
auto
deploy.
Yet
this
is
we
want
to
have
at
least
a
documented
way
how
users
can
use
autodeploy
with
the
agent
in
a
few
weeks
and
the
next
milestone.
I
we
want
to
change
the
template
so
that
autodevops
is
fully
supported
in
an
agent-based
connection
as
well.
A
The
final
thing
is
security
integrations
as
soon
as
the
agent
is
just
the
connection
layer.
Other
teams
are
building
features
on
top
of
it
as
well,
and
something
that
did
not
exist
ever
with
the
certificate.
This
approach
are
actually
security
integrations
like
the
syrian
network,
security
policies,
integration
right
now,
container,
host
security
that
was
already
used
and
the
container
scanning
is
being
released
by
the
container
security.
B
A
C
A
A
A
I
don't
know
how
much
you
know
kubernetes,
but
basically,
when
you
deploy
the
agent,
it
requires
a
service
account
and
by
default
everything
that
you
run
through
the
agent
uses.
The
agent
service
account
itself,
so
even
from
cic
tunnel,
you
might
have
an
agent
in
your
pastor.
That
is
almost
a
cluster
admin.
It's
not
required,
but
it
has
kind
of
extensive
rights.
Let's
say
for
whatever
reason,
and
then
when
you
run
a
ci
cd
job
by
default,
it
will
have
the
same
rights.
A
This
is
something
you
probably
don't
want,
especially
not
in
a
even
moderately
sized
enterprise
setup
where
trust
is
not
the
main
issue,
but
actually
it
is
an
issue.
So
in
those
situations
you
want
more,
you
want
to
restrict
the
permissions
available
for
the
agent,
and
this
is
where
we
are
splitting
the
tiering,
which
means
that
in
core
you
will
be
able
to
use
all
the
features
using
the
service
account
of
the
agent
in
your
cluster.
A
A
I'm
just
reading
the
other
questions.
Sorry
I
I
will
move
on
and
then
let's
get
back
to
it
at
the
end,
because
there's
a
lot-
and
I
might-
I
might
want
some
of
them,
for
example,
next
one
next
one
around
custom
management
project
template
it's
already
supported.
We
might
not
merge
it
yet,
but
again
the
customization
project
template
runs
through
gitlab
ci
cd,
as
github
cicd
is
supported
by
the
agent.
The
cluster
management
project
template
is
supported
by
the
agent.
You
just
have
to
say
that
I
can
quickly
show
you
the
setup.
Actually.
A
A
This
project
that
I
usually
use
for
demos,
it's
an
it
it's
an
almost
stacked
custom
management
project
template
actually
this.
This
is
the
job
that
comes
from
the
project
template
and
I
only
added
this
one
line
here.
Use
context,
and
the
only
thing
I
have
to
do
is
to
set
the
context
to
an
agent
context,
and
basically
this
will
be
the
the
approach
for
auto
auto
deploy
as
well.
A
A
So
what
what
you
have
to
understand,
if
you
really
want
to
discuss
this
and
want
to
be
ready
for
the
customers,
is
that
it
has
a
totally
different
mental
model
than
the
certificate-based
approach,
and
this
is
what
I
would
like
to
explain
a
bit
more.
What
I
mean
by
that
with
the
legacy
approach
you
could
attach
a
cluster
at
specific
levels.
You
had
to
think
about
that
in
advance
that
I
will
attach
this
cluster
here
there
or
there
you
couldn't
move.
A
You
couldn't
attach
the
same
cluster
to
two
projects
you
could,
but
you
have
to
be
careful
like
not
to
have
applications,
and
so
so
that
was
that
was
a
tricky
bit
and
then
the
given
owner
managed
the
connections
with
the
agent-based
approach.
Everything
is
at
the
project
level
for
the
agent
connection
itself.
We
always
set
up
a
connection
at
the
project
level,
but
then
we
can
share
that
connection
with
other
projects
and
groups.
A
Open
it,
so
you
can
share
the
ci
channel
provided
by
an
agent
another
project
and
again
it
happens
in
the
code,
so
the
agent
configuration
repository
holds
the
configuration
for
that
specific
agent
and
there
you
can
see
that
share
this
connection
with
other
groups
or
other
projects,
it's
a
very,
very
different
mental
model
than
what
you
are
used
to,
because
here,
once
again,
everything
is
at
the
project
level.
That's
where
we
set
up
the
connection,
that's
where
the
main
admin
interface
is
for
that
agent
connection.
A
That's
that
targets
likely
platform,
engineers
or
sres,
and
then
we
plan
to
have
other
views
of
more
lightweight
and
not
less
and
less
operational
views
for
for
the
shared
connections
at
other
groups
and
other
projects
where
developers
are
just
interested
whether
the
deployment
is
out.
What
is
it
status,
etc,
but
they
might
not
be
interested
in
many
other
things,
like
all
the
events
happening
in
the
cluster
and
so
on.
A
A
A
So
that's
it!
One
interesting
thing
here
is:
how
do
how
do
you
upgrade
agent
k
today
because
it
has
to
upgrade
separately
of
gitlab?
Of
course,
today
we
already
guarantee
that
agent
k
is
compatible
with
at
least
one
minor
version,
plus
minus
of
your
gitlab
version,
but
very
likely
we
are
compatible
with
even
more
in
a
wider
spread
of
version
ranges,
so
you
can
just
upgrade
gitlab
first
and
then
you
can
upgrade
agent
k
instances
afterwards,
as
the
update
happens
in
code.
Actually,
you
can
upgrade
even
your
agent
k
you
can.
A
A
Once
again
how
to
set
up
given
this
thing
first,
you
have
to
install
this
cast
together
with
gitlab.
That
happens
once
only
so
you
don't
need
it
for
every
cluster.
Then
you
have
to
register
an
instant
agent.
That
means
today
we
it's
a
four-step
process.
We
want
to
simplify
by
removing
the
first
one,
but
basically
you
get
up
the
token,
and
then
you
have
to
install
agent
k
together
with
the
token
into
your
cluster,
and
you
can
use
you
can
configure
the
agent
connection
afterwards.
A
A
I
think
cluster
image
scanning
is
being
rolled
out
as
we
speak,
but
basically
these
are
the
existing
features,
and
here
you
can
see
that
the
cic
channel
is
free
and
premium,
given
the
the
pricing
strategy
that
I
quickly
discussed
and
on
the
roadmap
first
of
all
seriously.
My
top
concern
now
is
that
I
see
a
few
high
value
items
on
the
third
base,
integration
that
we
don't
have
for
the
agent
base
like
bit,
lab
managed
clusters,
auto,
deploy
and
the
simplicity
of
that
integration.
A
A
With
the
gitlab
manage
clusters
alternative,
we
don't
have
a
good
idea
yet.
So
that's
a
big
big
question
mark
and
the
ease
of
use
is
on
our
roadmap,
which
means
that
we
consciously
aimed
this
integration
for
expert
users,
because
we
think
that
if
we
can
serve
expertise
as
well
later
on,
we
can
add
more
higher
level,
defaults
features,
etc
to
help
beginner
users.
A
As
a
result,
we
know
that
this
feature
is
actually
loved
by
many
sres
and
and
and
people
who
are
familiar
with
kubernetes
but
is
very
harder
to
use
for
somebody
who's
not
familiar
with
governance.
So
that's
a
known
shortcoming
or
weakness.
Let's
say,
and
we
want
to
work
on
that,
independently
of
the
deprecations,
what
we
saw
as
a
as
the
current
biggest
work
that
we
want
to
fix
is
actually
observability,
because,
with
the
service
integration,
we
have
the
deploy
boards
and
metrics
integration
and
all
that
stuff
with
aging.
A
We
don't
have
any
of
that,
and
even
though
deploy
boards
were
so
to
say
not
much
praised
by
the
users.
I
interviewed
at
least
a
minimum
support
around
that
is
needed
and
we
are
looking
into.
How
could
we
do
it
fast?
Because
the
current
application
we
remove
we'll
move
them
to
deprecated
as
well.
We
don't
remove
anything
so
this
this
was
the
quick
intro
and
now,
let's
get
back
to
your
questions
so
john,
I
did
I
managed
to
answer
your
question.
Yeah.
D
A
It
is,
it
is
a
few
things
as
well.
I'm
currently
writing
an
announcement
blog
post
about
this
deprecation,
that's
aimed
towards
our
users,
so
I
try
to
be
extremely
empathetic
with
them
that
I
know
this
is
scary
at
first
like
we
are
deprecating
features
that
they
might
have
so
and
there
I
try
to
provide
all
the
links
as
you
suggested,
and
you
are
more
than
welcome
to
to
provide
feedback
on
that.
I
will
try
to
quickly
look
up
the
merger
quest,
so
I
can
I
can
link
it
here.
E
E
The
on
the
ui
side,
for
you
know
clean
handling
of
it.
That
is
one
question
and
the
other
one
I
had.
I
I
don't
really
remember
fully,
but
there
was
there
was
a
way
to
to
set
up
two
projects
to
define
that
configuration
and
that
didn't
work
for
me,
so
one
part
was
one
part,
was
the
connection.
Another
part
was
the
manifest
directory
that
to
be
monitored,
and
that
didn't
work
for
me.
So
I
had
to
have
both.
I
had
to
have
both
things
in
one
project.
A
Yeah,
let's
start
with
the
ui,
specifically
the
one
that
you
mentioned,
and
I
think
they
are
very
fit.
It's
not
highly
prioritized
on
the
roadmap,
given
all
the
necessary
work
here
on
the
applications.
If
you
look
at
the
uis
in
the
kubernetes
page,
it's
a
mess.
It's
everything
you
it's
really
hard
even
to
find
the
agent-based
integration
page.
So
we
are
first
fixing
that
then
we
want
to
provide
it.
A
We
want
to
make
it
easier
for
the
shared
group
level,
sharing
and
project
level
shared
ci
cd
tunnel
connections
to
have
some
insights
at
the
group
level
and
the
project
level,
where
you
can
even
show
that
this
is
the
cube
context
you
should
use
etc,
but
specifically
deleting
connections.
We
are
aware
of
that
as
well.
A
It's
just
further
out
in
the
future.
Okay
for
setting
up
things.
Probably
it's
a
bit
misleading
that
we
have.
We
have
two
things.
One
is
the
dictionary
that
we
use
and
the
other
is
what
it
means
in
practice.
In
terms
of
dictionary,
we
have
a
configuration
project,
a
manifest
project
and
an
application
project.
A
If
I
remember
well
in
reality,
the
configuration
and
the
manifest
projects
are
the
same
for
for
the
pool
based
approach
for
push
base.
You
can
share
the
connection
and
it
doesn't
matter
but
for
the
pool
base.
They
have
to
be
the
same.
We
don't
have
a
good
idea
yet
how
to
how
to
handle
the
permissions
issues
around
taking
manifest
from
a
different
project.
So
that's
why
we
are
not
even
we
wanted
to
look
into
it
in
the
next
month,
but
probably
we
won't
do
it
for
a
few
months
now,
given
even
this
deprecation.
A
F
A
G
Cool,
if
I
have
the
next
and
it's
it's
more
triggering
a
discussion
or
a
potentially
decision,
I
think
we
are
we're
we're
seeing
we're
challenged
with
some
kind
of
dilemma
here
from
an
sa
perspective.
I'm
I'm
currently
talking
about
the
job
of
the
the
solutions
architect
when,
when
we
are
demoing
kubernetes
integration
today
and
for
the
the
last
couple
of
years,
even
we
were
following
that
third
based
approach,
obviously,
and
a
big
emphasis
of
every
single
demo
was
the
observability.
G
Well,
we
kicked
in
autodeploy,
we
had
the
deploy
board.
We
had
the
metrics
that
kind
of
stuff.
We
were
scaling
up
and
doing
things
like
canary
deployments,
and
this
is
all
all
these
things
are
under
one
word
that
is
called
observability,
and
this
is
not
available
with
that
kubernetes
agent
approach
today,
and
I
totally
agree
with
the
statement
that
you
made
victor
that,
at
the
very
least,
when
gitlab.com
says,
is
the
development
platform
pretty
much
the
search-based
approach
for
security
concerns
of
ops
teams
is
that
in
the
water.
G
So
I'm
kind,
I'm
somewhat
tempted
to
say
that
we
actually
quickly
need
to
rethink
what
we
demonstrate
and
communicate
to
prospective
customers
as
quickly
as
we
possibly
can,
and
I'm
also
tempted
to
say
that
we
should
be
stopping
that
kind
of
demo
approach
that
we're
doing
now,
because
we
are
practically
misleading
or
showing
something
that
is
lacking.
Enterprise
readiness
and
we
we-
and
this
is
this-
is,
I
think,
a
call
to
action
specifically
for
the
sas
here.
G
We
need
to
replace
that
with
something
I
don't
know.
Yet
what
that
something!
Exactly
is
what
we
could
easily
demonstrate
that
has
some
eye
candy
and
is
compelling
in
the
first
place
and
that
and
and
equally
attractive
what
what
we're
having
today.
But
I
think
we
should
really
kind
of
make
it
make
a
significant
step
in
the
next
couple
of
weeks
to
rethink
what
we
demonstrate
and
how
we
communicate
that
I'm
happy
to
hear
any
disagreement.
E
A
G
Says
I
I
wouldn't
care
from
an
sa
perspective
talking
to
enterprise
customers,
I'm
I'm
not
so
much
concerned
about
the
deprecation.
If,
if
the
third
based
approach
of
interacting
with
the
kubernetes
cluster
isn't
showing
enterprise
readiness,
then
by
all
means
deprecated,
but
we
just
need
to
deal
with
that
situation
and
yeah
and
that's
the
task
at
hand.
G
I'm
pretty
harsh
on
that,
but
but
I
I
think
it's
better
to
make
a
significant
move
as
quickly
as
we
possibly
can
when
we
think
it
is
not
kind
of
sustainable
as
an
enterprise
solution,
then
we
should
kind
of
equip
ourselves
to
progress
here
and
to
show
and
present
it
in
a
way
that
is
leading
towards
a
proper
enterprise.
Adoption.
G
F
Thanks
victor,
I
wanted
to
confirm
you
had
kind
of
showed
the
present
or
the
slide
of
how
everything's
communicating,
and
I
just
wanted
to
confirm
that
the
runner
is
actually
reaching
out
through
caz
into
the
agent.
How
does
the
runner
validate
that
the
project
or
the
runner
should
have
access
to?
The
thing
is
that
using
the
our
jot.
A
You
would
see
all
the
contacts
that
were
injected
by
gitlab
and
gitlab
injects
so
gitlab
knows
which
projects
have
access
to
specific
agents
using
the
reverse
index
on
on
the
gitlab
db,
and
we
inject
those
contacts
specifically
into
your
ci
environment
into
running
environment,
and
it
has
a
token
as
well.
So
it's
not
let
me
see,
I
jump
talking
or
anything
like
that
and
after
that,
that's
how
it
authenticates
with
class.
F
Gotcha
cool,
thank
you.
I
can
try
to
speed
through
my
my
other
questions
too.
I
given,
I
didn't
realize
that
the
kate's
agent
and
caz
communication
was
bidirectional,
so
I
was
curious
as
to
why
you
know
some
of
the
things
that
we
get
with
the
certificate
based
which
allows
bi-directional
isn't
permitted.
A
Yeah
the
thing
is
that
certificate
doesn't
allow
bi-directional,
so
certificate
base
only
allows
gitlab
to
reach
out
to
the
faster
the
plastic,
and
that's
right:
that's
why
the
agent
has
support
for
network
policy
alerts,
because
then
the
alert
comes
from
the
cluster
towards
vietnam,
but
nevertheless
I
try
to
answer
the
question
here
is
that
many
of
the
features
that
we
have
are
actually
not
enterprise
ready?
I
would
agree.
A
What
I
learned
is
that
it's
it's
not
ready
for
productions,
because
it's
perfect
when
you
set
up
a
cluster
and
at
the
first
days,
it's
very
handy
and
so
on,
but
but
nothing
if,
if
you
had
needs
a
bit
more
serious
usage
around
that,
so
the
use
case
is
valid.
We
know
that
it's
valid
deploy
boards
validated
for
us,
but
our
implementation
for
short
from
the
user
requirements.
F
My
my
last
one
I'll
just
verbalize-
I
I
think
the
work
that
we're
doing
in
the
space.
I
think
it's
the
right
direction
to
take.
It
makes
a
lot
of
sense,
historically,
we've
kind
of
attached
ourselves
our
cd
strategy
to
kubernetes
and
now
that
we're
changing
and
deprecating
some
of
these
capabilities,
like
from
an
observability
perspective.
I
think
it
really
hinders
our
ability
to
have
a
continuous
deployment,
vision
and
strategy,
and
I
yeah
I'm
hopeful
that
we
can.
F
A
Yeah,
I
wouldn't
go
into
deployment
direction
now,
because
we
had
this
course
now
for
different
reasons.
I'm
super
happy
to
discuss
it
with
you.
The
truth
is
we
don't
have
a
strategy
there.
Yet
we
we
identified
many
pain
points,
but
we
are
still
looking
into
into
it
in
more
detail
by
running
ux
research
and
everything
along
those
lines
and
the
I
would
love
to
start
working
on
it.
Probably
early
next
year.
B
Yeah
thanks
again
victor
do
we
have
any
field
marketing
issues
and
promoting
the
new
agent.
I
had
the
opportunity
to
attend
cubecom
in
la
just
a
couple
weeks
ago,
and
while
we
had
the
booth,
we
didn't
have
any
physical
callouts
to
promote
the
agent.
So
I
know
cubecom
in
europe
is
in
may
2022
and
I
think
it
might
be
a
really
good
idea
to
highlight
that
agent
at
the
booth
or
even
have
a
talking
session
by
a
customer.
I
So
the
answer
is
well.
I
couldn't
attend.
Kubecon
apologies
for
that,
the
we
are
working
on
assets.
There
are
actually
a
couple
of
assets
already
out
there
about
the
kubernetes
agent
plus,
something
that
is
coming
up
in
december
is
a
webinar
we're
working
with
field
marketing
and
we're
going
to
put
out
a
git
ops,
webinar
on
write,
doc,
bright
talk
and
that's
going
to
be
promoting
the
kubernetes
agent
as
well
somi-
and
I
are
working
on
on
anything
related
to
marketing.
Git,
ops
and
agent
is
very
much.
B
I
I
And
I
I
it's
kind
of
I'm
referencing
that
and
lowering
the
set
of
questions
in
the
document
about
get
ups,
because
the
I
think
we
touched
on
this
last
time.
I
spoke
to
you
guys,
so
there
is
a
github's
working
group
with
at
the
cncf
and
it's
very
much
kubernetes-centric,
and
so
my
my
question,
lower
in
the
document
is,
is
github's
just
for
kubernetes,
or
I
mean
it.
I
So
I
think
if
we
position
ourselves
that
way,
we
have
a
an
advantage
over
we've
works
and
and
companies
that
are
just
focusing
on
kubernetes
right
with
with
our
positioning.
You
know
we
can.
You
know.
Kubernetes
is
just
one
of
the
targets.
You
know.
If
you
want
to
update
low
balancers
security
groups,
databases,
you
can
still
do
github's
workflows
with
with
with
us
compared
to
other
competitors.
I
B
A
I
A
The
reason
for
that
is
manifold,
actually
one
is
it
provided
quite
a
few
features
out
of
the
box
like
pruning
of
resources
and
didn't
have
to
develop
all
those
things.
It's
way
more
modern
than
the
code
base
that
comes
from
arbor
cd
and
was
put
into
bitups
engine.
As
a
result,
it
has
much
less
20
less
dependencies.
A
I
don't
remember
whether
20
percent
is
the
file
size
or
the
number
of
dependencies,
but
I
remember
it
was
around
20,
so
it
has
a
very
different
model
as
well.
Like
argo
city
uses
labels
for
everything
here
you
have
the
inventor
inventory
policy
and
inventory
object
that
provides
more
flexibility
as
well.
So
there
are
quite
a
few
things
that
can
we
see
at
our
youtubes,
but
now
we
use
clients.
C
C
A
A
A
I
A
A
A
I
F
C
A
H
A
A
I
would
recommend,
if
you
need,
if
you
try
it
out
and
have
questions
more
technical
once
then
go
to
the
f
cubans
agent
channel.
If
you
have
more
questions
about
the
direction
or
have
feedback
from
users
or
questions
then
come
to
s
configure,
because
their
the
whole
team
is
ready
and
available
for
to
help
you.