►
From YouTube: Argo Contributors Office Hours Mar 3rd 2022
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
All
right,
good
morning,
everyone
welcome
back
to
the
contributor
meeting.
I'm
remington,
I'm
your
host.
So
let's
get
started.
The
first
legitimate
topic
is
triaging
and
discussion
primary
and
secondary.
So
let's
see
who
was
it
last
week
it
was
jan
and
michael.
So
do
you
guys
want
to
talk
a
little
bit
about
how
it
went
this
week.
B
Sure
I
can
talk
about
those
two
items
since
I
added
them.
One
is
using
lts
as
the
base
image.
It
sounds
like
someone
wants
to
be
able
to
build
their
own
argo,
cd
image,
suppose
it's
an
old
version
and
still
get
recent
security
updates,
so
they
prefer
an
lts
base.
I'm
not
sure
why
they
can't
just
edit
the
docker
file,
but
I
also
don't
really
see
a
reason
not
to
base
on
lts.
C
Yeah,
I
think
we
so
once
you
open
the
time
we
use
debian
right
and
like
debian
stable,
and
it
was,
it
was
very
old
and
they
were
us
like
ignoring
certain
fixing
certain
tvs
within
the
images,
and
we
we
decided
to
migrate
to
something
else,
and
I
think
we
discussed
the
rts
route
once
and
for
some
reason.
We
decided
against
it
and
to
follow
like
the
rolling
ubuntu
releases.
C
That,
like
the
two-point,
which
is
a
2.2,
is
using
a
now
unsupported
version
of
deviant
right.
E
I
just
found
the
issue
that
has
a
description
of
why
I
and
I
was
just
looking
for
it
in
background.
I
pretty
sure
I
remember
we
had
the
discussion
about
it
here.
So
we'll
have
to
read
it.
I
will
be
able
to
tell
you
right
now
like
why
we
decided
to
not
go
with
lts
but
movies
yeah,
and
maybe
we
can
suggest
one
more
thing
at
least
internally
at
intuit.
We
we
needed.
We
had
the
same
requirement.
E
We
wanted
to
use
different
base
and
basically
our
docker
file
give
me
one
second
to
double
check.
Yes,
it
has
an
argument
called
base
image,
so
basically
they
don't
have
to.
They
can
rebuild
it
without
even
changing
the
docker
file.
They
can
specify
docker
argument
based
image
and
you
know
use
whatever
image
they
want.
B
E
And
I'm
saying
the
suggestion,
like
there's
a
little
slightly
more
convenient
way.
They
don't
have
to
download
and
copy
and
edit
this
file
they
can.
Okay,
they
can.
I
mean
they
can
download
and
use
the
same
file,
but
instead
of
changing
it,
they
can
just
specify
docker
build
argument
called
base
image
yeah.
That's
it.
B
Yep,
okay,
I'll
respond
to
that.
The
second
item
I
linked
was
someone's
trying
to
make
it
easier
to
apply
customized
patches
to
helm
applications.
B
So
originally
folks
just
wanted
the
values
field
to
be,
I
guess
arbitrary,
yaml
type,
and
then
someone
tried
to
implement
it
realized,
that's
difficult
and
instead
introduced
a
new
string
field
so
that
you
could
apply
a
customized
patch
with
a
string
of
yaml
which
would
take
precedence,
and
then
I
said
well,
if
we're
going
to
do
that,
we
should
allow
multiple
iterations
of
customized
patches.
So
that
should
be
an
array
of
strings,
but
I
think
we're
getting
really
far
away
from
what
people
originally
wanted,
which
is
just
to
customize
patch
yaml.
B
So
I'm
wondering:
are
there
any
really
hard
blockers
to
just
supporting
arbitrary
gamble
in
a
values,
field
or
potentially
a
new
values?
Yaml
field.
E
Now,
okay,
I
I
do
not
know
if
we
want
to,
but
basically
I
was
thinking
that
if
we
work
on
introducing
this
values
field,
you
know
if
I,
if,
if
we
thought
about
that
use
case,
maybe
we
would
just
you
know
I
would
not
make
values
a
string.
I
would
just
make
it
an
object,
I
guess
and
then
it
would
be
possible
to
apply
in
any
type
of
patch.
B
B
I
think
this
is
an
old
issue
and
then
someone
tried
to
take
a
crack
at
it,
but
I
think
that
their
attempt
misses.
You
know
the
problems
that
people
are
actually
trying
to
solve
it.
It
over
complicates
the
solution
I
was,
I
was
kind
of
thinking.
B
D
E
Is
to
use
the
trick
that.
E
Container
both
template
uses.
Basically
you,
you
know,
like
input
template
in
continuous,
you
can
define
ports
and
ports
can
be
either
string
or
integer.
So
we
could
make
this
change
general
cd
cd
and
we
could
say
that
values
is
either
string
or
object,
and
it
would
be
like
a
very
small
breaking
change
and
it
would
not
be
a
breaking
change
and
not
so
much
code
changes.
So
in
theory
we
can
support
it
without.
E
You
know:
breaking
changes
but
yeah
yeah,
and
if,
if
I
commit
to
do
it,
they
would
do
it
this
way,
basically
the
same
schema,
but
we
will
lose
validation
of
the
field
because
we
will
have
to
just
remove
that
field
from
validation
schema
it.
It
would
be
like
where
you
could
would
be
anything.
You
know
right.
B
G
Templating
right
so
hell
myself
supports
the
templating
of
the
targets
like
good
templates
and
values
can
be
overridden,
so
if
they
declare
it
in
in
such
a
fashion
that
they
have
a
chart
study
among
the
values
of
table,
and
they
also
declare
the
templates
dot
ppl
files
and
they
can
pass
in
the
overrides
on
top
of
it,
then
I
don't
understand
what
is
the
necessity
of
adding
these
additional
fields.
E
I
believe
that
they,
basically
they
use
customize
to
generate
application,
jammers
and
those
applications
here.
Yamas
eventually
use
helm,
and
they
want
to.
I
I'm
just
imagining
that,
so
they
have
one
base
application
and
that
base
application
has
a
bunch
of
values
and
then
they
they
want
to
overwrite
one
of
the
values
in
in
one.
I
don't
know
in
one
environment.
G
Customers
also
has
something
like
a
field
from
and
two
field
path
where
we
can
mention
the
transformations
yeah.
E
E
Yeah,
so
I
guess
when
I
described
it,
I
realized
it's
kind
of
like
it's
an
edge
case.
It's
you
know,
you
only
want
it
if
you
use
customize
to
manage
applications
that
use
helm,
which
is
like
not
everyone.
Does
it
only
a
few
people
and
that's
why?
I
think
it's
an
argument
against
aging
field
because
it
would
be
you
know,
like
we
introduced
yet
another
field
into
already
big
crd,
so
yeah,
and
then
you
know
it's
it's
not
great,
because
we
have
like
a
ton
of
such
which
cases.
D
C
I
I'd
probably
be
confused
because
I
don't
use
hum
but
yeah.
So
no,
I
think.
B
Field,
I
think
if
all
of
our
docs
stayed
the
same,
except
maybe
one
line,
that's
like
hey.
If
you
want
this
to
be
raw
yaml,
you
can
write
it
as
roy
yaml.
Then
the
same
people
are
currently
using.
It
won't
be
confused
and
then
every
now
and
then,
when
someone
asks
for
the
future,
we
just
point
out:
hey,
there's,
there's
another
way.
E
Get
you
know,
kind
of
collect,
more
opinions
and
I
I
kind
of
I'm
I
I
want
to
implement
it
because
I'm
pretty
sure
it's
like
really
easy
to
do,
but
I
might
be
missing
something,
but
unless
I'm,
if
I'm
not
missing
anything,
I
want
to
do
it
because
it's
such
a
small
change
and
looks
like
unblock
some.
You
know
good
number
of
people.
F
I
I
don't
know
if
somebody
looked
at
this,
there
is
a
plug-in,
that's
a
helm,
customized
plug-in
that
basically
renders
the
chart
and
then
applies.
Customization.
Did
anybody
look
at
this?
Yes,
but
I
think
this
is
it's
even
it's
kind
of.
E
It's
like
they
use
customize
to
create
a
bunch
of
rubber
cd
applications
and
those
applications
later
on
uses
hell.
So
it's
like.
F
B
B
Okay,
I
think
this
dev,
if,
if
we
wanted
to
see
a
proof
of
concept,
I
think
that
this
dev
is
going
to
need
help
pointing
to
examples,
because
I
already
pointed
out
somewhere
in
argo
workflows
that
I
thought
showed
how
to
do
this,
and
it
wasn't
helpful
so
more
eyes
on
the
pr
and
like
helping
this
dev
implement.
What
we're
talking
about
would
be.
E
Okay,
I'm
I'm
responding
right
now.
In
my
opinion
I
want
to.
I
do
not
want
any
additional
field,
but
I
I
will
propose
to
reuse
the
same
field
and
being
and
jc.
You
know
you
know
that
people
who
I
know
might
object.
I
don't
want
this
person
to
re-implement
the
changes
and
we
reject
the
pr.
So
I'm
going
to
just
propose
an
enhancement,
and
you
know
and
ask
him
to
wait
for
at
least
one
more
thumbs
up
from
you
know,
from
someone
of
maintenance.
B
Cool
okay,
that's
that's
all
the
items
I
had
and
then
john
was
also
on
triage
yeah.
C
I
I
was,
but
I
wasn't
sorry
I
I
actually
had
some
days
of
pto
and
then
I
have.
I
have
nothing
to
add,
no
worries
glad
you
got
some
rest,
but
yeah
thanks
thanks
for
being
so
proactive,
michael
secondary,
I
I
should.
I
should
only
be
primary
when
you're
secondary
in
the
future.
A
All
right,
thanks
guys
so
yeah,
let's
move
on
and
pick
next
week's
moderators.
So
first
we
have
any
volunteers.
Otherwise,
we'll
just
go
down
the
list.
H
I
can
I
secondary
yeah,
it's
keith.
Oh.
A
Oh
thanks
you're,
your
head
wasn't
popping
up
on
zoom,
so
I
didn't.
I
didn't
see
it
thanks
and
then
did
you
volunteer
for
secondary
or
primary.
A
E
E
There
is
a
chance,
I
think,
to
simplify
how
we
release
the
process
of
releasing
of
argus
id
and
application
set,
and
we
can
improve
end
user
experience
so
right
now
we
have
this
kind
of
implicit
circular
dependency
between
argo,
cd
and
application
set
so
applications
that
import
arbo
cd
code,
you
know
going
types
and
then
this
code
is
used
to
eventually
generate
manifests
and
then
rcd
bundle.
This
those
manifests,
and
that
means
we
have
this
strange
set
of
you
know.
E
Things
we
have
to
do
to
release
argo
cd
and
application
set.
So,
for
example,
right
now
in
2.3
we
had
to
first
release
a
release
candidate
of
fargo
cd
and
then
application
set
bumps
version
and
kind
of
start
pointing
to
rbcd
release
candidate
and
then
yeah.
Now
now,
application
set
needs
to
have
its
own
release,
and
then
I.
C
I
think
that
may
that
may
be
a
reason
for
the
protogen
failures
cliques
of
me,
and
I
have
seen
probably
because
now
we
do
we
have
vendor
ago
city.
You
know.
D
C
It
ends
up
in
the
vendor
directory
and
there
was
the
the
failure
was
like
shadowing
of
the
application.proto.
E
I
Yeah
yeah
application
set
vendors,
sorry
application
set
vendors
in
argo
cd,
it
uses
the
app
application
type
and,
I
think,
probably
also
the
project
type,
but
the
other
thing
I
would
notice
that
the
application
set
controller
also
uses
other
parts
of
argo
cd
beyond
the
type
it
uses
the
get
client
code,
so
it
doesn't
call
the
repo
service
directly.
Instead,
it
uses
the
git
client
code,
like
the
git
dot
go
code.
I
It
also
uses
the
argo
cd
code
that
retrieves
cluster
secrets
and
the
argo
cd
code
that
retrieves
repository
credentials.
So
we
aren't
just
vendoring
the
application
set
controller,
isn't
just
vendoring
in
argo
cd
for
the
type
it
also.
It
is
also
actually
using
our
go
cd
code
itself
for
some
of
the
capabilities
of
the
application
set
controller.
So
we
would
presumably
need
to
do
something
about
that
code
as
well.
If
we
wanted
to
remove
that
circular
dependency,
yeah.
E
And
I
I
feel,
like
I,
I
think,
in
this
ticket,
I'm
just
proposing
kind
of
as
smallest
possible
step.
What
do
you
think
if
we,
basically,
if
we
just
drop
applications,
if
we
stop
using
application,
spec
and
application
set
controller,
would
just
trust
blindly
that,
whatever
is
in
the
template,
is
a
valid
application.
E
It
will
just
have
to
you,
know
deserialize
it
into
map,
and
that
map
is
anything
and
then
validation
still
happens.
But
during
the
moment
of
application
creation.
I
So
I
am
not
for
that,
but
before
we
get
to
that,
my
issue
is
that,
because
of
the
argo
cd
code
that
the
application
set
controller
uses,
I
don't
think
that
the
change
you're
proposing
would
solve
the
issue.
I
We
would
still
need
to
do
that
that
same
set
of
steps
until
we
remove
the
fact
that
the
application
set
controller
is
vendoring
in
argo
cd,
the
issue
being
that
if
argo
cd
changes
after
after
the
application
set
controller
is
released
like
let's
say
you
change
the
format
of
your
cluster
secrets
or
the
format
of
your
repository
credential
secrets,
the
code
that
the
application
set
controller
would
be
vendoring
in
would
still
be
using
the
old
argo
cd
code
for
interacting
with
those
objects.
I
I
Another
option
would
be
to
create
a
almost
like
a
sub
module
for
argo,
cd
and
application
set
controller.
So
just
move
like
the
the
cluster
secret
code
and
the
repository
credential
code
into
that
that
sub
module
and
have
our
go
cd
vendor
in
that
sub
module
and
have
the
application
set
controller
vendor
in
that
sub
module
so
that
they
both
have
a
dependency
on
a
shared
component
rather
than
the
application
set
controller
needing
to
vendor
in
all
of
our
ocd.
Actually,
the
problem
is
yeah.
Go
ahead.
E
I
Yeah,
but
we
probably
also
need
to
move
the
type
into
that
that
sub
module
as
well,
which
would
probably
be
a
bit
more
work,
although
it
would
have
the
advantage
of
like
if
other
standalone
independent
projects
wanted
to
consume
the
rcd
type
they
wouldn't
need
to
vendor
in
the
iocd
types
they
wouldn't
need
to
render
in
all
of
our
go
cd.
I
They
would
just
need
to
render
in
that
that
sub
module
that
a
subset
of
the
code
but
yeah
that
would
that
was
kind
of
that
would
be
it's
not
a
perfect
solution,
but
there
are
some
trade-offs
but
yeah
that
that
that's
how
I
could
see
us
removing
the
dependency
on
the
code
base
itself,
but
still
having,
but
still
ensuring
that,
when
updates
are
made
to
that
code,
like
let's
say
you
wanted
to
change
the
the
cluster
repository.
I
Sorry,
the
git
repository
secret
format
that
that
code
would
then
percolate
into
both
argo
cd
and
application
set
simultaneously
without
the
need
to
kind
of
do
the
dance
at
release.
Time
of
putting
out
release,
candidates
and
and
stuff
like
that,
move.
E
B
C
With
that
and
that.
E
D
I
my
questions
regarding
the
a
little
bit
of
future
project.
Regarding:
do
we
want
adding
the
additional
tab
on
the
ui
for
the
application
set?
So
if
that
is
a
plan,
I
think
it's
making
more
sense
to
treat
that
as
the
one
product
going
on.
So
I
also
support
that
idea
to
avoid
other
complications.
C
Yeah,
I
just
want
to
raise
one
one
issue:
that's
that's
not
directly
related
to
that.
I
wanted
to
bring
that
up
already,
but
didn't
until
now.
So
I
think
we
also
should
like
refactor
our
code
base
like
how
things
are
laid
out
in
the
in
the
repository,
because,
right
now
it's
it's
a
huge
mess.
Right
I
mean
you,
you
look
at
the
top
level
directory
and
it's
like
what.
D
C
All
this
right,
so
I
I
think
we
we
when
we
decide
to
move
in
application
set,
we
probably
should
move
things
around
a
little
like
I
mean
that
that
would
definitely
break
some.
C
E
Yeah-
and
I
I
can-
I
wanted
to
highlight
that
issue
because
it
feels
like
it's
like
a.
It
will
be
a
pain
it's
playing
right
now.
You
know
to
do
this
dance
like
bump
versions
and
have
giant
pull
requests
in
like
applications
at
first
in
and
then
in
our
cd.
So
basically
I
think
it
it's
like
a
tech
dev.
We
should
play
sooner
than
later,
so
maybe
maybe
we
can
work
on
it
in
the
next
two
to
four
years.
E
I
mean
we
can
postpone
it
again.
It's
it's
not
like
it's
super
urgent,
but
I'm
pretty
sure
we're
going
to
several
days
during
2.4,
because
there
will
be
some
changes
in
application
set
and
then
we
kind
of
have
like
two
teams.
Right
now
and,
like
you
know,
people
who
are
mostly
active
in
rbcd
and
people
who
mostly
active
implications
that
and
then
advocacy
people
would
have
to
ping
applications
that
people
wait
for
them
and
then
actually
know
it's
other
way.
I
Yeah
that
that
kind
of
the
issue-
I
I
I
think
that
everyone
agrees-
that
it's
not
a
great.
It
is
a
what
we
have
is
a
solution,
but
it's
not
a
great
solution,
because
it
does
require
a
lot
of
moving
parts
to
be
kept
in
sync,
which
is
never
a
good
thing.
I'm
sure
that
we
all
have
better
things
to
do
than
babysitting.
I
You
know
animal
manifests
or
babysitting
git
tags
in
order
to
make
sure
that
everything
works
so
yeah,
I'm
I'm
for
a
change
that
would
either
integrate
the
code
or
you
know,
reduce
the
coupling.
D
I
I
have
a
I
mean-
maybe
not
directly
like
in
this
topic,
but
in
a
way
is
I'm
just
thinking
about
the
future
of
the
application
set
so
right
now,
it's
more
generating
the
application
object
itself,
but
application
object
for
the
rlcd
contacts
is,
has
additional
sub
like
project
and
we
are
having
our
back
all
those
things
which
also
additional
crc
resources
managed
by
ocd,
I
mean
merging
in
the
same
place,
may
be
open
up
of
new
opportunity
to
enable
the
application
set
to
do
a
little
bit
more
to
making
the
whole
experience
to
be
easier
means.
E
I
feel
like
I
I
I
can't
I
agree.
I
I
think
I
proposed
this.
You
know
reduced
coupling
because
I
felt
like
it's
easy
to
do
and
then,
and
we
can
get
it
quickly,
but
if
we're
going
to
merge,
I
kind
of
forgot
that
we
discussed
previously
that
as
soon
as
sargo
cd
needs
to
have
api
for
application
set,
that
means
argo
cd
will
have
to
start
rendering
application
set,
and
at
this
point
it's
like
kind
of,
we
think
we
want
to
merge
them.
I
Yeah
no
issues
there
for
me
and
yeah.
It
would
be
a
matter
of
moving
the
code
in
moving
the
kubernetes,
manifest
in
setting
up
the
ede
tests
and
unit
tests
to
make
sure
that
they
still
work
with
the
bird
street
pill
yeah,
but
and
then
yeah
updating
some
package
imports,
probably
but
yeah.
That
would
that
would
be
the
work
that
would
be
required
and
that.
E
A
Thanks
alex
all
right
yeah,
so
moving
on
to
looks
like
the
last
topic,
regina
looks
like
you
have
a
issue
regarding
exposing
the
health
check
code
in
the
ui.
K
K
K
One
thing
was:
if
a
user
doesn't
have
access
to
view
the
cargo
cd
custom
resources,
they
will
be
able
to
view
custom
health
checks.
If
that,
like
isn't
intended
feature,
I
guess
this
is
you
in
general,.
E
I'm
pretty
sure
it's
useful
feature.
I
know
that,
like
at
some
point,
pasha
was
that,
from
you
know,
pasha
from
code
rash.
He
was
working
on
a
draft
for
rbc
settings
view
page.
So
at
least
it
would
help
administrators
to
see
the
settings
in
the
ui
and
they
don't
need
to
go
to
they.
Don't
they
won't
have
to
go
to
argo
cd
like
yaml
that
configures
it.
E
K
I
E
I'm
like
just
rereading
what
this
person
wrote.
I
think
he
is
end
user.
He
wants
to
see
you
know
like
he
just
wants
to
see
if
he
has
an
unhealthy
resource
and
then
it's
not
really
clear.
Why
is
it
not
healthy
and
you
want
to
kind
of
look
at
the
law
script
and
see
and
kind
of
guess
what
is
going
on
with
this
escape.
E
To
be
honest,
I
would
do
it
in
two
steps
I
feel
like
admins
must
see
it,
and
maybe
it
could
be
kind
of
not
the
perfect
experience
if,
like
end
user
need
to
go
to
settings
page
search
for
crd
and
then
search
for
health
check,
but
it's
maybe
good
enough.
You
know.
Maybe
there
is
no
need
to
have
it
in
front
on
the
application
details
page
and-
and
I
think
it
basically
admins
would
definitely
benefit
from
it.
E
And
then,
if
we
implement
the
settings
view
page
for
administrators
and
then
we
can
see
if
developers
still
insist
on
you
know
health
check
viewing
health
check
in
the
application
details
page
so
basically
yeah.
If
we
convert
this
issue
into
like
settings
view
page
and
make
sure
this
settings
view
page
at
least
has
resource
customizations.
E
K
At
the
bottom,
it
says
display
the
health
code
check
for
specific
object
on
the.
D
K
Tab
or
a
separate
like
a
new
health
checks
tab
do
you
have
an
opinion
like?
Should
it
be
there.
E
This
is,
I
think,
it's
it
might
be
there,
but
I
think
it's
like
step
two
in
my
opinion,
because
if
you
know,
if
we
do
it
there,
then
we
must
introduce
yet
another
our
back
rule.
I
guess,
because
it's
not
safe
to
you
know.
Maybe
someone
wants
to
keep
health
check
implementation
in
in
secret
or
I
don't
know
what.
If
there
is
a
vendor
company
that
you
know
they
treat
this
law
script
as
a
proprietary
code.
So
it's
and
we
don't
want
to
just
blindly
show
it
actually
same
thing
in
an
administrative.
E
Okay,
yeah,
I
was
trying
to
find
you
know
the
smallest
possible
step
we
can
do
to
at
least
you
know,
deliver
something
and-
and
I
felt
like
administrators,
you
know
settings
view
page
is
something
we
should
have
built.
You
know
from
beginning,
it's
like
as
administrator,
I
feel
like.
E
E
I
I
mean
right
now:
we
don't
have
this
page
at
all.
I
think
we,
okay,
maybe
maybe
some
settings,
but
they
did
I'm
pretty
sure
with
there's
no
okay
yeah,
I
mean
right
now:
it's
we
have
a
bunch
of
pages,
so
we
have
settings
page
and
it
has
repositories
certificates
and
I
guess
resource
customizations
page
is
missing.
So
if
we,
if
we
introduce
the
source
customizations.
E
J
I'm
by
the
way
alex
do
we
have
apis
ready
to
provide
this
type
of
information
to
to
be
consumed
in
the
ui
okay.
No,
we
don't
right.
E
E
Okay,
so
basically,
maybe
settings
page
is
the
same
level
of
complexity.
It's
like.
E
E
So
it
sounds
like
it
kind
of
yeah.
I
mean,
looks
like
a
good
feature
and
it's
we
will
not
have
to
do
almost
no
extra
work
to
have
it
in
the
next
to
event
step
because
you
know
if
we
build
a
new
api
and
then
you
are
back
for
administrators,
the
same
ipay
is
going
to
work
for
end
users
with
the
same
model.
E
E
I
guess
this
is
it?
Doesn't
it's
like
easy
to
work
on
this
feature
in
parallel?
You
know
if,
like
if
you
like
it
and
then
in,
I
would
not
call
it
like
the
first
priority.
We
had
this
security
and
cvs,
and
but
if
you
know
it
will
be
really
easy
to
review
that
code
and
just
you
know,
work
on
that
feature
in
parallel,
because
it's
a
new
additional
api
new
additional
ui,
no
need
to
like
unlikely,
you
will
have
much
conflicts
with
anyone
else.
K
Wants
to
help
out
with
this,
let
me
know,
because
I
I'm
not
as
strong
on
apis
but
front
end.
I
can
do
but
just
let
me
know.
E
Okay-
and
this
is,
I
think
it
deserves-
I
mean
it's
not
good.
First
issue
maybe
help
need
it
later.
I
will.
E
A
Thanks
thanks
regina
was
that
all
you
had
for
this
topic.
A
I'm
gonna,
I'm
gonna
assume.
Yes,
all
right.
Does
anybody
have
any
last
minute
topics
we're
getting
close
to
the
end?
But
if,
if
anybody
has
a
quick
one,
maybe.
E
E
It
is
really
not
a
bug
and
yeah.
So
just
one
of
our
internal
users
got
affected,
but
it's
because
they're
doing
something
strange,
it's
not
because
of
work
and
so
yeah,
and
I
guess
we're
just
waiting
for
I.
I
didn't
check
to
be
honest
recently,
like
we
need
to
finish
this
application
set
up
great.
I
think
there
is
open
pull
request
in
application
set
to
bumper
cd.
So
as
soon
as
it's
merged,
we
will
update
the
custom
application
set
version
in
argo
cd
and,
finally,
I
think
we
can
create
release.
So
basically,
that's
the
like.
E
A
Cool
thanks
alex
all
right
yeah.
So
if
there's
no
more
topics,
we'll
call
it
the
day
for
this
week
and
we'll
see
you
guys
next
week,
thanks.
Thank.