►
Description
The Distribution teams demos an upcoming change to the GitLab Cloud Native Helm Chart, that allows having seperate replicasets and resource requirements for the GitLab webservice, split out by ingress path. (For splitting git http traffic, from api traffic, from asset traffic for example)
A
A
One
additional
fleet
that
we'll
actually
have
is
an
internal
api
that
fleet's
job
will
explicitly
be
to
answer
all
the
internal
api
calls
from
italy,
gitlab,
shell
and
any
other
component.
That
actually
needs
to
speak
directly
to
the
api.
Therefore,
we're
not
going
out
of
the
cluster
and
back
in
for
that
traffic,
and
we
have
a
dedicated
set
of
nodes
that
we
know
is
coming
from
intra
component
communication.
A
A
I
have
a
default
which
will
basically
be
the
quintessential
catch-all
anything
that's
not
picked
up
by
one
of
the
other
paths,
the
api
which
will
catch
anything.
That's
under
slash
api,
get
which
actually
comes
from
a
comment
in
this,
mr
from
what
we
were
doing
for
past
testing,
although
I
can't
find
the
comment
at
the
moment.
A
A
A
A
I'm
gonna
go
ahead
and
run
stern
and
this
is
actually
selecting
all
because
all
I
did
was
use
the
app
label.
So
every
pod
that
is
in
the
web
service
chart
will
have
the
app
equals
web
service.
I
could
pull
out
a
specific
one
by
actually
using
a
label
that
is
declared
for
each
individual
deployment.
We
do
that
actually
by
an
additional
label.
That's
added
based.
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
This
is
a
classic
problem
and
it's
it's
primarily
because
I'm
actually
not
using
a
tagged
version
of
the
images
I'm
using
the
master,
because
the
nodes
will
think
that
they
already
have
that
image
without
pull
policy.
Always
it
will
just
reuse
the
one
that's
already
there
and
you
can
have
an
instance
where
it
has
pulled
an
updated
copy
on
one
node,
but
not
on
the
other
node.
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
If
I
describe
one
what
you'll
see
is
we
have
the
back
ends
defined
we're
going
specifically
to
the
service,
which
currently
has
this
service
ip
address.
If
I
do
this
for
each
one,
I
can
go
into
this
them
and
you'll
see
the
same
thing.
What
I
want
to
call
out
for
visibility
is
that
whatever
is
default,
whatever
fleet
has
slash,
actually
also
exposes
the
slash
admin
sidekick.
A
A
A
A
Okay,
what
I've
done
is
manually
edited
that
ingress,
I
didn't
add
the
chart
config
just
to
speed
up
the
process,
and
hopefully
this
api
path
or
this
path
will
be
more
correct
than
the
one
that
we
were
seeing
that
had
a
problem.
I've
pulled
up
the
logs
from
the
ingress
controller,
just
to
make
sure
that
we
see
that
it
gets
reloaded
and
we'll
be
able
to
figure
out
on
log
wrap
and
make
a
full
screen.
A
This
is
not
intended
to
be
a
part
of
a
major
chart
release,
because
the
way
this
is
done,
we're
actually,
inheriting
from
the
chart
properties
in
the
event
that
you
don't
specify
a
deployments
object,
you
will
get
a
default
object
that
gets
inserted
and
pull
all
of
those
values
in.
So
there
is
nothing
that
actually
changes
for
someone
who
is
directly
upgrading
from
not
having
this
configured
to
having
this
configured.
A
A
A
What
we've
actually
done
here
is
take
the
properties,
template
them
into
yaml
and
then
actually
read
that
yaml
back
in,
so
that,
instead
of
trying
to
do
merges
and
copying
values
which
we
know
inside
of
go
template
is
a
dangerous
thing,
because
deep
copy
isn't
present
until
later
versions
of
helm,
and
we
have
had
at
least
in
the
past
customers
on
versions
of
helm.
That
did
not
support
this,
so
we
couldn't
use
that
functionality.
A
A
Add
to
that
the
fact
that
deep
merge
doesn't
have
the
ability
to
actually
pull
a
quote
empty
value
from
the
source.
So
if
you
have
the
chart
level
setting
set
to
true,
but
then
you
have
an
individual
deployment
with
a
value
set
to
false,
the
false
will
actually
always
lose
because
it's
considered
empty.
A
A
A
A
I
don't
love
doing
this,
but
we
need
this
functionality
now
and
it's
not
even
in
3.4
of
help,
so
that
would
be
dragging
people
all
the
way
up
to
the
latest
version,
which
they're
probably
not
ready
to
do,
and
it
requires
additional
changes
to
sprig.
So
we
would
actually
have
to
go
three
layers
deep
in
api
there
to
get
this
functionality.
A
A
A
A
If
it
is
a
map,
it
will
then
recurse
into
that
map.
That
way,
we
can
do
a
deep
merge
following
this
overwrite
empty
behavior,
without
losing
anything
as
a
result
of
that,
you
don't
cleanly
have
a
way
to
nil
a
map.
So
if
that
merge
will
always
happen
with
all
the
keys,
you
can't
overwrite
the
map.
You
either
have
to
nail
it
or
not,
inherit
anything
which
means
not
defining
it.
At
the
end,
at
the
parent
chart.