►
From YouTube: Che Community Meeting November 15th 2021
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
hello,
everyone
and
welcome
to
the
czech
community
called
today
is
the
15th
of
november
and
we
can
start
as
usual,
with
release
section
so
7.3
8.0
is
in
progress
and
about
upcoming
events.
We
can
say
that
this
this
week
the
account
will
happening
so
please
attend.
If
you
have
a
chance
and
for
the
topics
in
the
agenda,
the
first
one
is
from
ilya
about
the
trying
rabbid
action.
B
Yeah,
hey
folks,
so
yeah
I
wanted
just
to
you
know,
follow
up
on
the
discussion.
We
had
last
time
on
monday
regarding
the
enabling
trying
to
have
id
github
actions,
so
we
actually
put
probably
pretty
aggressive
deadline
to
have
it
all
done
by
in
a
week.
So
I
I
have
tried
a
couple
of
things
already,
apart
from
the
repositories
like
docs
and
bringing
sms
cooler,
plugin
registries
that
already
have
those,
so
I
try
to
add
it
to
dashboards
and
the
operator.
B
So
my
feedback
is
basically
that
on
dashboard
we
use
the
docker
hub
related
image
and
there
is
a
known
problem
with
image
pool
rate.
So
the
recommendation
here
is
that
we
need
to
move.
A
B
That
is
the
most,
so
in
our
dev
files
we
should
use
quay
as
much
as
possible
because
there
is
no
easy
way
to
fix
it
other
than
by
creating
manually
some
image
cool
secrets
in
in
the
developer,
sandbox
namespaces,
which
is
currently
not
automated,
and
for
the
operator.
The
feedback
is
basically
that
a
dev
file
refers
to
the
non-existing
nightly
image.
So
we
need
to
be
updated
and
yeah
that's
pretty
much
it.
C
So
a
few
remarks
from
from
my
side
that
they
are
on
this,
so
first
thank
you
for
introducing
all
these
it's
very
good
and
useful,
but
unfortunately
not
all
the
repositories
can
consume
it
in
proper
way.
For
example,.
C
Space
to
to
test
everything,
for
example,
for
chair
operator,
because
we
can
build
it
there,
but
we
cannot
actually
test
it,
so
it
doesn't
make
much
sense
right
now.
A
second
issue,
as
I
mentioned
previously,
it's
a
lot
of
spamming
and
yeah.
We
could
disable
that
commenting
stuff,
but
mostly
people
doesn't
do
that
and
as
existing
examples
shows,
for
example,
with
jedox
repository.
C
There
is
a
lot
of
spam
comments
really
a
lot
and
to
me
it
looks
like
a
serious
bug
of
this
github
action
and
I
believe
it
should
be
fixed
before
we
enable
it
in
every
repository.
But
again
it's
my
own
opinion
and
yeah
again.
Thank
you
very
much
for
introducing
all
of
this.
It's
really
good.
B
Thank
you,
okay,
thank
you!
So
alexander,
I
just
yeah
regarding
the
first
comment
about
the
not
possibility
to
test
in
like
entering
the
image
pool,
I
think
that
this
is
actually
exactly
the
treatment
we
would
like
to
get.
But
it's
like
an
open
question:
how
should
we
centralize
it?
Because
we
have
this?
B
We
have
this
document.
I
think
it's
called
some.
Some
kind
of
you
know
I
don't
remember,
but
it
just
like
dog
food
in
readiness,
whatever
like
when
we
rate
it
like,
at
which
point
we
can
use
service
for
dog
food,
and
this
was
like
for
our
internal
instance.
B
Maybe
we
need
something
similar
for
software
workspaces
opportunity.com
and
to
accelerate
your
pudding
and
identify
those
like
problematic
areas
where
we
cannot
like
entrance
use
our
hosted
instance
for
for
the
for
the
food
purposes
right
so,
but
we
still
need
to
stick
to
the
local
ide.
That's
an
open.
B
I
think
that
we
need
to
discuss
it
because
it's
really,
it
would
be
really
helpful,
in
my
opinion,
to
understand
what
what
are
we
going
to
do
with
with
the
problematic
repositories
for
that
we
need
a
docker
image
to
produce
proper
images
to
build
without
it
we
cannot
literally
tested,
and
regarding
the
second
comment,
well,
I
personally
don't
think
it's
that
dramatic
and
yeah.
We
can
just
disable
the
commenting
by
default,
and
I
haven't,
for
example,
heard
from
the
dogs
team
that
it
is
very
distracting
for
me.
B
It's
just
an
indicator
that
someone
pushed
to
the
user
repository
and
I
can
retest
it.
Of
course
we
can
improve
it
later
on
by
releasing
the
obsolete
comments,
which
are
just
could
be
quite
a
few,
but
I
mean
if
you
haven't
updated
the
pull
request
you
you
wouldn't
get
the
comment
if
it
is
like
distracting,
this
can
be
disabled
just
on
the
on
the
github
action
level
and
you,
for
example.
If
for
the
operator,
you
don't
need
it,
you
can
comment
in
the
pull
request
and
I
will
disable
it
and
let
us
check.
C
Yes,
thank
you
very
much
cbr
for
your
responses,
so
yeah
we
we
could
disable
it,
but
usually
developing
and
creating
pull
requests
requires
more
than
one
command
and
why
I
gave
such
example
as
kendall's
repository,
because
I
needed
to
respond
on
some
comments.
I
and
I
had
to
scroll,
scroll
and
scroll
all
of
these
comments
because
I
had
like
70
commits
or
something
like
that,
and
it's
really
huge
scroll,
but
by
just
this
opening
id
commands
just
open
it
and
look.
C
It
looks
very,
very
weird,
but
okay,
I've
got
the
idea
so
to
disable
it
while
the
settings.
Thank
you
very
much.
India.
Thank
you.
B
Okay
yeah.
Thank
you.
I
think
that
for
ron
also
added
an
issue
that
we
can
prioritize
update
the
existing
comment
instead
of
adding
a
new
one,
that's
a
good
one,
so
we
can
probably
add
it
for
backlog
in
the
next
sprint
and
regarding
the
feedback,
it's
like
an
open
question
like
what?
What
should
we
do?
B
A
C
C
So,
as
some
of
you
may
know
that
we
had
trouble
with
the
caches
in
our
operators
and
basically
to
avoid
the
om
problems.
We
increased
the
memory
limit
for
our
operator,
but
this
is
a
not
scalable
solution
and
only
work
around
while
we
prepare
proper
fix
and
the
proper
fix
is
basically
is
in
this
pull
request.
So
we
have
to
provide
a
custom
cache
function
for
our
operator,
which
was
done
in
this
pull
request.
C
But
the
problem
is
that
the
controller
runtime
framework
has
some
limitations
and
we
cannot
overcome
them,
because
this
is
how
the
framework
done
and,
in
the
end,
to
manage
caches
in
the
right
way.
We
have
to
filter
all
resources
by
labels
and
because
of
limitations.
We
cannot
put
oral
conditions
there,
so
we
need
to
have
at
least
one
label
on
all
the
resources
which
operator
could
read,
and
if
this
is
not
a
problem
for
the
resources
we
create
with
gear
operator
and
manage
automatically.
C
C
So
when
this
pull
request
is
merged,
the
right
way
to
to
give
such
resources
to
chair
is
to
add
this
label
to
the
existing
labels
list
for
the
resource.
C
But
if,
if
a
user
adds
a
new
resource,
he
or
she
should
add
this
label,
so
yeah
immigration
could
also
work,
but
the
operator
operator
restart
needed,
which
is
not
desirable,
desirable,
behavior,
sorry
and
yeah.
Also.
I
would
like
to
ask
the
question
about
the
label
itself,
so
we
decided
to
use
already
existing
label
to
to
make
the
transition
smoother
and
require
an
additional
instance
equals
here
label
for
user
defined
resource.
C
C
Label,
you
mean
the
food
or
chair
operator.
B
Yeah
I
mean
like
so
yeah
I
just
I
will
check
it
up
in
a
second
but
literally
or
for
the
development
sandbox.
I
think
average
ram
consumption
is
around
one
gig
for
the
operator
at
this
point
with
some
spikes
during
the
startup,
I
was
wondering,
like
with
the
label
introduction
cluster
with
this
singular
amount
of
namespaces.
C
Thank
you.
Yes,
this
is
a
very
good
question.
I
haven't
measured
this
data
but
from
what
I've
seen
while
testing
it's
a
lot,
because
I
start
the
limit
back
to
256
megabytes
of
ram
and
it
will
never.
It
was
never
exceeded
in
all
my
tests,
so
even
on
start
and
in
peaks.
B
It
would
be
interesting
to
test
it
on
yeah.
We
can
probably
follow
up
on
this
later,
but
on
something
around
like
5k
namespaces
set
of
500
and
yeah.
Just
was
wondering
based
on
this.
Based
on
this.
You
know
conversation
so
like.
How
much
will
we
save
if,
if
the
problem
could
be
simply
using
higher
limits,
if
it's
just
not
self-sufficient.
C
I
think
we
could
go
back
to
the
previous
values,
but,
okay,
let's
test
it
first
yeah
we
can
try
in
some
sandbox
or
arrange
pds
yeah
any
cluster
with
a
lot
more
namespaces
yeah.
Thank
you.