►
From YouTube: Viktor on the topic of Flux integration
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
So
I
already
took
a
note
of
it
that
basically
it's
a
little
bit
Visionary,
because
what
I'm
describing
because
I'm
actually
describing
a
major
product,
an
Imaging
major
products.
A
Let's
start
with
the
first
part
from
initial
setup:
I
I
tried
out
flux
in
the
past
weeks
and
I
loved
its
approach,
that
from
a
single
CLI,
well,
two
steps
grab
a
gitlab
token
and
then
run
a
single
CLI
command
and
that
command
installs
flux
in
the
cluster
creates
a
gitlab
repo
and
sets
up
that
gitrabrepo
to
update
the
cluster,
and
you
can
run
this
command
any
number
of
times.
This
is
the
same
command
for
upgrades
and
everything,
so
they
made
it.
A
I
don't
get
the
word
now
anyway.
So
it's
a
very
nice
experience
that
is
seems
to
be
very
stable
as
well.
Now.
What
I
have
in
my
mind
is
that
we
decide
which
flux
version
we
want
our
users
to
have.
We
will
decide
which
flux
version
we
want
to
use
in
order
to
avoid
the
pitforce
of
gitlab,
managed
apps.
So,
basically,
gitlab
manages
the
flux
installation.
The
agent
installation
manages
flux
installation
as
well.
A
This
is
likely
not
the
MVC,
but
this
is
what
I
have
in
my
mind
for
the
longer
term,
how
we
do
it
that's
up
to
be
discussed,
but
this
is
what
I
have
in
my
mind
and
that's
part
of
that
initial
setup.
Now
this
level
of
initial
setup
doesn't
exist
with
the
agent
either
so
likely
that
needs
to
be
estimated
to
how
to
do
this.
Now
we
have
the
gitlab
CLI
very
likely.
We
can
expand,
extend
that
to
include
an
agent
installation
in
a
similar
fashion.
A
Here,
just
yesterday,
we
discussed
with
Target
it
might
worth
looking
into
the
flux
CLI
code,
how
they
make
sure
that
they
can
run
that
someone
can
run
the
same
command
several
times
and
it
won't
break
anything
and
the
same
command
does
the
upgrade,
so
it
might
worth
checking
whether
it's
just
a
crd
update
or
something
more
evolved.
A
This
might
be
useful
both
for
the
agent
for
the
our
own
approach
and
for
the
flux-based
approach.
So
this
is
the
initial
setup.
The
other
part
that
I
mentioned
here
that
setting
up
authorizations
managed
by
gitlab
I
think
one
of
the
strengths
of
our
current
solution
is
that
the
gitlab
managed
that
the
agent
configuration
specifies
where
it
wants
to
access
manifest
and
our
plan
on
the
multiple
manifest
project
access
basically
keeps
authorizations
within
gitlab.
A
So
it's
not
something
that
you
create
a
deploy
token,
and
then
you
have
to
manage
those
deploy
tokens
you
have
to
take
be
able
to
report
around
those
deploy
tokens
and
those
deploy.
Tokens
are
spread
all
around
gitlab
and
it's
really
hard
to
to
be
compliant
and
have
an
understanding
of
actually
who
will
have
access
what
projects
or
cluster
will
be
able
to
access.
A
A
A
really
minor
note
just
to
help
you
understanding
what
I
mean
I
think
on
the
second
tag.
Discovery
call
hodu
spoke
about
writing
a
custom,
Source
controller
for
gitlab,
and
that
included-
and
that
was
a
response
to
to
this
approach,
to
to
keep
authorizations
Within
gitlab
and
then,
basically,
all
the
authorizations
like
getting
containers
getting
the
Manifest
from
a
git
repo
could
be
handled
through
costs
and
through
the
agent
tunnel
and
not
other
requests
that
that
reach
gitlab.
A
So
that's
my
idea
there
what
I
mean
by
integrating
flux
finishes
up
to
authorizations.
Does
it
make
sense
this
way
too
Mikhail.
B
B
A
B
A
B
A
A
It's
just
natural
I
think
if
we
have
our
the
gitlab
docs
as
well,
describing
how
to
set
up
our
GitHub
Solutions.
B
Well,
I
can
only
I,
don't
know
repeat
what
I
said
before
I
think
that
integration
such
integration
would
be
clunky.
It
would
not
allow
us
to
really
provide
a
you
know,
seamless
experience
where
everything
just
works.
The
way
we
really
want
it
to
work
integrating
on
the
library
level
is
definitely
much
more
flexible
than
integrating
on
the
fluxos
API
level.
A
Yeah
cool
then
I
will,
if
you
want,
feel
free
to
to
stop
the
recording
and.