►
From YouTube: GitLab Group Environments GitOps Kubernetes Office Hours
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
B
I
yeah
there's
the
meeting
notes
and
that's
also
where
there's
a
list
of
seeking
Community
contributions.
If
that
would
be
necessary,
but
we'll
see
where
this
leads
us
yeah,
it's
recording,
but
we
will
upload
it
afterwards,
just
in
case
that
we
have
to
edit
something
out
or
yeah
something
goes
and
miss.
C
B
C
B
A
That
two
of
us
currently
here
team.
One
myself,
we
both
work
on
the
environments
group
and
this
group
is
responsible
for
the
commands
integration
that
we
are
here
for
and
for
data
form
Integrations
as
well,
where
I
would
say,
Teemo
is
our
primary
engine
within
the
company.
He
does
an
amazing
job.
There
I
would
just
start
speaking
about
our
roadmap
or
and
the
status
where
we
are
so
you
might
know
that
we
switch
to
flux
at
the
beginning
of
February.
A
A
A
B
It
would
be
helpful
and
maybe
what
is
also
helpful
if
you
take
one
step
back
a
higher
level.
What
your
group,
or
what
like
environments,
means
within
gitlab,
okay
or
or
more
as
like
a
vision
or
the
general
concept
of
what
you're
trying
to
achieve.
And
then
maybe
we
can
go
into
the
flux
area
or
the
kubernetes
area.
C
B
B
If
they're
searching
for
your
group
in
the
issues
to
understand
like,
what's
basically
the
purpose
of
this
entire
concept-
environments,
a
lot
to
many
people,
it's
a
very
generic
generic
word
yeah.
So
it's
also
even
interesting
I
think
for
GitHub
team
members
to
to
get
that
like
a
higher
level
context.
Thank.
A
You
yeah
so
actually,
there
was
a
lot
of
debates
on
the
name
of
the
group
and
there
were
two
strong
contestants
delivery
and
environments
unfortunately
delivers
taken
by
an
internal
team.
That's
why
we
ended
up
with
the
environment's
name,
but
actually
everything
around
how
you
deliver
your
applications
to
your
target
infrastructure
is
within
our
scope.
A
So
it's
a
relatively
broad
topic,
as
as
you
can
see
it's
platform
independent.
So
while
we
are
focusing
right
now
on
kubernetes,
the
domain
itself
is
not
kubensus
only
and
if
you
have
some
issues
in
gitlab
pipelines
using
environments
for
whatever
that's
as
long
as
it's
about
deploying
to
that,
whatever
infrastructure,
that's
our
area
as
well.
A
Of
course,
there
are
related
areas
that
we
work
together
with,
like
the
package
team,
who
manages
the
container
registry,
and
often
you
want
the
nuclear
container
Secrets
management
solution.
The
success
management
team
actually
pipeline
execution
team
who
owns
Secrets
management.
They
because
secrets
are
needed
in
different
parts
of
the
pipeline
for
deployments.
Often
they
are
needed
as
well,
but
overall,
the
what's
deployment
specific
or
delivery
specific.
That's
in
our
domain.
A
Definitely
this
is
a
good
good
question.
One
thing
is
that
I
we
see
one
misconception
often
when
we
speak
about
kubernetes,
which
is
people
think
that
they
should
reach
out
to
us
when
they
want
to
deploy
gitlab
to
kubernetes.
That's
not
us.
We
are
speaking
about
when
you
want
to
deploy
your
own
applications
using
gitlab
to
kubernetes
or
anything
else,
and
so
that's
it.
A
A
Really,
your
custom
applications
that
you
build
or
a
third-party
application
that
you
want
to
deploy
using
gitlab.
These
are
the
the
areas
that
we
own
and
we
built
the
terraform
Integrations
of
gitlab
as
well,
but
right
now
those
are
not
in
Focus
right
now.
Our
primary
focus
is
on
the
kubernetes
integration,
with
flux
and
with
the
agent,
and
we
are
slowly
moving
towards
environment
management
from
there,
but
great.
B
A
Exactly
so,
the
outside
division,
with
flux,
how
you
say
so
it's
very
important:
it's
an
integration
between
Agent,
K
and
flux,
often,
which
means
that
flux
does
the
github's
part.
It
knows
how
to
pull
a
source
and
how
to
apply
it
in
the
cluster
and
how
to
reports
its
status
within
the
cluster.
Now,
what
flux
doesn't
offer
you
a
UI
to
visualize
your
cluster
space,
and
we
want
to
do
that
in
gitlab.
A
A
Up
to
this
point,
this
looks
like
a
typical,
well-known
environment
widget
on
the
environments
list,
but
now
it
has
a
Commander's
overview
part
which
actually
shows
me
the
number
of
running
Port
spending
posts
exceeded
number
of
deployments
and
replica
sets.
In
this
specific
case.
This
is
already
filter
to
namespace.
That's
why
you
only
see
six
items
here,
because
this
is
my
flux,
namespace
actually,
but
I
could
change
it
to
a
different
name
space
and.
A
To
have
like
you
can
select
an
agent.
Basically,
you
actually
associate
an
agent
with
that
environment
and
after
that
you
can
pick
the
namespace
that
you
want
to
to
see
within
that
environment.
That's
the
idea,
so
this
is
what's
already
out
there
and
we
want
to
improve
it
further.
Actually,
let
me
go
back.
A
What
we
want
to
add
in
in
the
coming
month
is
one
more
badge.
Besides
the
health
badge
that
would
be
a
flux,
synchronization
status
badge,
which
is
a
I
think
great
addition
to
this
UI,
because
if
you
use
flux,
then
you
will
know
whether
your
deployment
is
out
of
date.
It's
just
syncing
or
everything
is
all
right.
A
A
Then
you
will
need
a
token
to
trigger
flux
from
CI
to
reconcile
a
certain
resource,
and
you
might
have
another
notification
for
flux
to
set
up
a
permit
status
in
the
gitlab
pipeline
and
so
on
and
so
forth.
So
you
need
quite
a
few
tokens
to
manage,
and
then
you
need
to
rotate
them
and
so
on,
especially
if
you
had
to
do
that
at
scale
that
that's
like
quite
Troublesome.
What
actually
Timo
did
the
book
of
the
job
there.
A
You
don't
have
to
rotate
those
tokens
this
today,
Works
only
within
the
same
project
where
the
agent
is
configured,
but
we
have
plans
to
extend
it
both
the
multiple
projects,
so
that
you,
you
can
have
a
single
agent
and
it
will
watch
other
git
repositories
for
updates
and
notify
flux,
and
we
would
like
to
extend
it
to
oci
registry
as
well.
Oh
in
case,
if
you
are
not
aware
of
that,
the
gitlab
container
registry
can
store
oci
images
too.
A
D
B
A
C
A
B
A
B
A
B
B
B
A
Actually
we
can.
We
can
yeah
I
thought
answering
that
as
well.
That's
totally
correct
flux
is
not
a
replacement
for
gitlab
agent
for
kubernetes.
They
will
operate
together
totally
correct.
The
agent
is
responsible
for
communicating,
at
least
towards
gitlab,
so,
for
example,
to
provide
that
UI
that
I,
that
I
shared
before
that's
done
by
the
agent.
Actually
that
UI
works
even
without
flux,
so
you
can
use
even
the
CI
integration
of
the
agent
and
that
UI
will
work.
A
We
want
to
add
flag
specific
things
that
UI
like
the
like
the
GitHub
synchronization
status,
but
the
UI
only
requires
the
agent.
What,
on
the
other
hand,
there
are
specific
flux,
specific
features
in
the
agent
already
like
this
token
management
and
the
notification
of
flux,
when
there
is
a
change
in
the
registry.
So
yes.
A
So
what
I
did
I
in
the
meantime,
I
opened
this
issue,
that
is,
to
fetch
and
render
cluster
sync
badge
on
the
environment
page,
and
what
you
can
see
here
is
an
example
setup
of
flux
where,
basically,
you
have,
the
flux
is
deployment
itself,
and
then
we
have
an
apps
customization.
That,
in
this
case,
has
three
applications:
it's
quite
gitlab
specific.
So
we
understand
what
we
are
speaking
about
when
it's
totally
made
up,
so
it
might
not
be
writing
and
then
the
raise
app
has.
A
Is
it
a
more
complex
thing?
It
has
a
preparing
environment,
customization,
a
pre-deploy
and
the
deploy.
And
finally,
we
end
up
with
typical
kubernetes
deployment
objects,
as
kinds
as
you
can
see
here,
and
what
this
wants
to
show
is
actually
that
here
the
class
name
is
is
not
a
class,
but
it
wants
to
be
the
resource
name
in
in
our
case,
while
it's
a
class
diagram,
it
shows
you
the
kind
and
a
label,
and
this
label
is
automatically
applied
by
flux.
A
We
want
to
read
that
status
field
and
our
current
idea
is
to
use
the
name
of
the
environment,
use
the
environment
slag
as
the
expected
name
for
the
flux
resource,
which
means
that
in
this
case,
for
example,
if
you
have
a
raise
up
environment,
then
we
can
show
you
the
status
of
all
these
resources
under
here.
And
similarly,
if
you
have
a
red,
a
cost
environment,
then
we
can
show
you
the
deployments
too
and
other
related
cubanus
resources
that
are
managed
by
this
customization
and.
A
B
A
The
the
primary
topic
with
flux
is
that,
like
a
single
application,
might
have
multiple
flux
resources,
as
you
can
see
here,
and
what
is
the
right
way
that
we
can
how
we
can
pick
one
that
we
can
look
for
the
status
field
and
and
then
see
how
it's
going
on,
but
I
want
to
go
to
the
seeking
Community
contributions
issues.
So
it's.
B
B
A
A
So
when
you
connect
to
a
cluster
using
agent,
we
have
this
drop
down
where
you
can
pick
existing
agent
configuration
files
or
just
type
in
whatever
you
want
new
agent
name,
and
if
you
want
to
pick
an
existing
one.
If
you
have
more
than
100
agents
here
agent
configurations,
then
actually
it's
not
easy
to
find,
and
we
only
should
we
only
fetch
the
first
100
agents.
So
if
you
have
more
agents,
it
won't
even
show
up
here.
A
This
is
select
drop
down
and
what
we
have
is
a
fix
is
actually
to
Simply
add
a
hub
text
that
we
only
support
hundred
agents
on
the
UI.
We
don't
want
to
change
this
because
we
think
that
if
you
have
100
agents,
you
likely
don't
want
to
do
it
over
the
UI.
We
recommend
using
gitlab
apis
to
to
manage
that
scale,
and
we
have
to
have
form
Integrations
for
that.
So
these
are
the
texts
that
we
would
like
to
show.
If
we
see
that
the
list
is
actually
huge.
A
In
our
case,
in
our
case,
it's
always
likely.
I
I
have
some
very
question
here,
asking
on
our
front-end
engineer
whether
I'm
correct
that
this
would
be
good
for
Community
contributions
and
that's
how
we
you
know.
Actually
it
was
Timo
who
added
it
but
Tim.
How
do
you
decide
that
you
should
add
this
label.
A
A
A
B
A
Go
so
for
for
adding
new
issues.
We
we
have
a
little
bit
of
review
on
when
we
add
the
label,
but
actually
we
never
removed
these
labels.
So
it's
not
a
proper
curation.
In
that
sense,
even
here
what
you
can
see,
that
I
ordered
it
by
updated
date,
descending
updated
date,
which
means
that
the
more
recent
ones
are
definitely
items
that
we
are
actively
looking
at
or
direct
we're.
A
Cases
like
using
your
custom
secret
service
account
with
the
agent
instead
of
the
automatically
generated
gitlab
agent,
that
has
a
cluster
admin
right
and
so
on,
and
then
we
link
to
this
default
values
file,
which
is
a
values
file.
It's
not
very
nice
so
to
say,
and
I
presume
that
people
here
have
seen
other
projects
that
use
hum
and
how
they
document
a
hand.
Chart
and
basically
what
we
would
like
to
have
is
to
add
a
typical
ham
chart
documentation
table
with
the
values
documented
to
the
readme
of
the
agents
chart.
A
B
That
that's
great,
maybe
one
question
I,
do
have
and
I'll
link
it
I
think
in
the
doc.
So,
if
I
take
away
the
seeking
currency
contributions,
label
and
I,
add
the
quick
win
label.
I
do
find
some
other
issues
that
might
be
actually
good
for
the
communities
also
pick
up
I'm
curious.
How
maybe
that
works
in
your
group
or
whether
they're
the
community
itself
is
also
okay
in
going
through
those
issues
and
see
if
they
could
pick
it
up.
A
E
B
C
D
Yeah
I
mean
the
first
one.
We
don't
need
to
look
at
it
because
there's
an
open
Mr,
but
in
general,
like
in
terms
of
quick,
win
and
seeking
Community
contributions,
I
think
lately,
we've
been
labeling
with
quick
win
instead
of
seeking
Community
contributions,
because
I
think
it's
more
General
and
I
think
I
got
this
advice
from
Lee
I'm,
not
sure
so.
I
think
the
ones
with
seeking
Community
contributions
are
are
the
ones
that
have
been
labeled
a
while
ago
and
just
not
replaced.
B
D
D
D
So
in
the
ancient
project
and
in
the
Asian
chart,
we
usually
try
them
like
either
me
or
Mikhail
like
it
when
they're
created
I,
think
we'll
both
have
notifications
on
so
yeah
they're,
usually
labeled,
and
have
some
context
also
for
the
chart
between
getting
Community
contributions,
Lately
from
some
nice
folks,
and
they
also
help
tryaging,
but
we
didn't
ask
them.
So
if
you,
if
you
feel
like
tryging
and
give
some
context
aspect,
questions
like
feel
free
to
do
so.
You're
super
super
happy.
If
you
do.
B
Okay,
if
you
want
like
we
could
go
through
some
of
these
issues
and
either
add
seeking
Community
contributions,
labels
to
make
sure
that
this
is
certainly
okay
and
actually
ready
to
be
picked
up.
Even
though
the
level
is
quick
win,
that's
what
we
sometimes
do
with
other
groups,
or
we
pick
a
couple
specific
ones
and
just
see
if
we
can
update
it
to
be
more
clear
so
that
it
can
be
picked
up
without
further
questions.
A
C
A
B
An
active
debate
right
now
in
an
issue
whether
we
should
remove
the
label,
because
in
theory,
everything
is
open
for
Community
contributions,
but
in
practice
not
everything
is
ready
to
for
someone
to
pick
it
up.
So
it's
more
this
implementation
guide.
Something
should
signify
like
work
for
ready
for
development,
but
then
it
gets
a
bit
tricky
because,
like
work
already
for
development
is
used
in
certain
groups
for
different
purposes.
So
we're.
B
D
Understand
something
to
the
workflow
label:
I
mean
in
our
group.
We
actually
use
those
once
they're
refined.
We
usually
label
them
with
ready
for
development.
They
may
not
have
an
implementation
guide,
though,
but
yeah
it
may
have
been
like.
The
broad
idea
is
clear
in
the
team
and
if
someone
wants
to
pick
this
up,
then
I
think
we
will
be
ready
to
give
an
answer
for
a
path
for
development.
It
may
still
requires
some
like
reaching
out
to
other
people
and
stuff,
but
yeah.
B
A
Yeah
I
think
the
the
the
issue
with
the
workflow
label
is
that
it,
it
might
be
that,
like
we
are
close
to
picking
it
up
ourselves
and
and
then
I
wouldn't
I
I
would
let
the
community
contribute
to
pick
something
else,
because
this
is
not
in
their
focus.
They
they
likely
can't
work
on
it
every
day,
as
actually
as
we
do
so
that
that's
not
really
in
either
of
our
interests,
because
we
are,
we
are
going
to
like
come
on.
A
Please
work
on
it
more
because
we
we
want
to
ship
it
why
they
are
like
I.
Do
it
besides
my
work,
so
that's
why
I
would
I
would
recommend
a
different
label
besides
the
workflow
label,
so
not
not
the
workflow
label,
but
something
else
like,
as
you
said
like
like
implementation
guide,
is
there
or
some
like
ready.
C
A
B
That's
a
good
discussion,
for
example
like
new
contributors.
They
need
that
label,
but
those,
for
example
like
Marco
here,
president
or
others
that
already
have
like
xano
more
contributions,
They
Don't,
Really
Care,
if
it's
good
for
a
community
in
the
sense
that
just
like
pick
something
up
and
they
will
collaborate
to
figure
out
if
they
can
help.
So
you
also
don't
want
to
alienate
those
that
want
to
go
beyond
whatever
is
labeled.
D
And
I
also
think
that
the
contribution
is
more
than
co-contribution,
so
someone
triages.
It
is
also
a
contribution
right
and
there
may
not
be
a
label
because
the
point
is
to
label
stuff,
and
so
it's
like
I,
don't
know.
If
someone
thinks
that
this
is
the
only
way
to
contribute,
then
it's
kind
of
limiting
but
yeah.
B
Maybe
we're
deviating
from
from
this
conversation.
That's
that's
well,
I
would
like
I
would
love
to
go
through
a
couple
more
issues
that
you
are
aware
of,
that
you're
really
like
open
to
again
coming
to
contributions
from,
and
maybe
people
that
are
watching
can
can
pick
it
up
with
some
extra
guidance.
D
C
A
D
C
D
Yeah
and
also
how
we
use
the
gitlab
release
feature
but
like
this
can
be
part
of
the
implementation
detail,
at
least
at
first.
You
know
to
figure
out
what
we
actually
want
and
yeah.
If
they're,
like
you
know
just
some
brainstorming
of
the
tooling,
we
have
available
what
gitlab
provides
out
of
the
box,
but
maybe
some
go-tooling
provides
what
bazel
provides
these
kind
of
things.
A
B
C
B
A
A
C
A
D
Yeah,
so
there's
this
this
case
when
a
an
API
call
is
being
proxied
and
it's
being
stopped.
It
usually
cancels
the
connection,
and
you
see
some
air
locks
there
in
the
message
in
the
description
like
you
know,
fail
to
read
blah
blah
blah
and
these
are
actually
naturally
errors.
So,
if
you
scroll
down
I
think
there
has
been
some
discussion.
A
D
Yeah
so
there's
some
some
watches
created
by
Cube,
CTL
or
whatever
tooling,
and
those
are
just
canceled
because
the
user
decides
to
cancel,
and
this
is
absolutely
fine.
However,
it
blocks
errors
and
the
idea
there
is
to
see
if
we
can
somehow
detect
if
this
was
a
deliberate
cancel
from
the
user
or
if
something
else
happened,
I'm
not
really
sure
how
how
and
if
it's
possible,
but-
and
that's
probably,
why
there's
no
implementation
detail
here.
C
D
A
B
A
A
D
B
D
A
A
D
Know
that
we
can,
we
can
quickly
it's
it's
one
that
is
actually
in
rails,
the
other.
Maybe
that's
good
to
know
all
the
other
code
bases
are
go,
but
here
we
for
so
if,
if
from
the
dashboard
that
Victor
showed
in
the
beginning,
if
the
user
makes
a
request,
that
is
proxy
to
the
kubernetes
cluster
Cass
will
authenticate
the
user
with
rails
and
for
this
a
cookie
is
required
and
this
cookie
is
being
encrypted
and
we
use
this
encrypter
in
the
gitlabcast
user.
D
B
D
A
B
A
No,
no,
it's
not.
Yes,
we
have
so
every
team
uses
weights
if
they
use
weights
in
a
different
way
likely,
and
we
have
our
own
way
of
weighing
things
here.
We
go
a
great
one,
basically
means
that
it's
a
trivial
change,
no
extra
investigations
needed
no
surprise
are
expected
and
no
collaboration
across
the
gitlab
teams
is
expected.
B
A
Yeah,
actually
we
have.
We
had
the
weight
when
when
we
move
something
to
ready
for
development,
if
that's
part
of
the
refinement
process
and
if
it's
in
a
blogged,
workflow
or
anything
before
ready
for
development,
they
don't
they're
not
expected
to
have
a
rate,
and
that's
why
there
might
be
issues
that
the
we
said.
It's
a
quick
win.
We
say
that
it's
seeking
Community
contributions
that
doesn't
have
a
weight
because
actually
didn't
run
through
our
formal
refinement
process.
A
A
D
Go
ahead
to
you
yeah,
so
we
talked
about
this
notification
where
gitlab
triggers
flux
to
ask
for
conciliation,
because
there's
updates
in
git
and
for
this,
this
flux
receivers
are
being
used.
It's
like
a
kind
that
the
notification
controllers
controller
acts
upon
and
it
exposes
a
web
hook,
and
this
webhook
may
have
different
kind
of
types
use
a
generic
type
which
allows
for
unauthenticated
triggers.
B
A
D
Yeah,
we
can
also
specify
this
what
I,
what
I
just
said
before
that
we
need
to
share
a
secret
between
the
eight
chains
and
the
receiver
object,
maybe,
and
that
we
need
to
implement
this
and
the
question
here.
That's
also
to
be
answered
and
I
don't
know
the
answer
yet
is,
if
you
want
to
use
one
secret
per
H
and
K
instance,
or
if
you
want
to
use
multiple
and
one
per
receiver
object,
because
we
have
one
receiver
object
per
git
repository,
that's
being
sent,
and
theoretically
every
get
your
pository
or
get
faster.
D
Receiver
can
have
its
own
shared
secret
with
HK
in
terms
of
security.
I.
Don't
think
that
this
brings
an
advantage,
because
the
parties
are
the
same
though,
if
you,
you
know,
if
one
is
leaked
well,
the
other
may
still
be
secret,
but
also,
if
you
have
access
to
one
chances
are
very
high
that
you
have
access
to
all
of
them,
but
maybe
it's
it
would
be
nice
for
some
security
folks
to
chime
in
here.