►
From YouTube: Argo Contributors Office Hours Aug 24th 2023
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
Hi
everyone
welcome
to
the
contributors
meeting
I'm
gonna,
be
your
host
today,
I'm
Leo
I'm,
starting
off
with
triage
discussion.
Last
week
we
had
myself
and
Justin.
I
I
took
a
look
at
the
at
the
issues
this
morning,
I,
nothing
major.
The
only
thing
that
stood
out
for
me
was
the
this
particular
issue
here.
So
the
user
was
complaining
about
increasing
CPU
into
2.8
right.
So.
A
Asked
for
things
and
discuss
a
little
bit
with
Michael,
so
they
and
he
provided
the
people
file.
So
it's.
C
A
The
problem
that
he
is
facing
is
related
to
the
div
calculation
and
I
replied
back
to
him,
saying
that
I
suspected
once
the
cash
is
rebuilt
in
2.8.
The
situation
would
be
normalized.
I
just
wanted
to
bring
it
up
to
ask.
If
someone
in
the
chat
in
in
this
call
had
similar
Behavior
with
2.8,
we
are
running
2.8
heading
to
it
and
we
didn't
notice
a
general
increase
in
CPU.
So
is
anybody
else
facing
issues
with
2.8.
D
B
A
See
exactly
what
are
the
functions
that
are
taking
a
lot
of,
but
this
is
CPU.
D
Right
CPU
yeah,
but
but
the
reporter
also
complained
about
mem.
Oh
no,
it's
only
CPU.
Sorry,
then
yeah.
A
A
C
A
E
A
Adjusting
is
not
in
the
call,
it
seems
no
okay.
So
let's
collect
the
next
person
on
triage
for
for
next
week.
We
don't
have
a
lot
of
people
in
the
call
cool
thanks,
Dad
I'll.
F
A
All
right,
okay,
so
with
that
out
of
the
way
we
have
one
topic
for
discussion,
which
is
a
proposal
by
may
I,
see
her
in
the
call,
so
they
you
want
to
say
a
few
words
about
this
proposal.
Yeah.
E
Thank
you,
a
major
from
YouTube
and
yeah
today.
Second
I
want
to
share
this
proposal
of
self-service
notification
for
Argo
CD,
and
so
we
can
seek
the
feedback
and
recommendations
from
our
contributors.
So
I'll
start
with
the
summary
and
the
motivation
and
Zach
will
cover
the
proposal.
So
in
some
the
summary
is
so.
This
proposal
will
enable
application
team
to
have
their
own
configuration
of
Argo
CD
notifications.
E
So
we
also
call
it
a
cell
service
notification,
so
the
application
team
will
be
able
to
receive
notifications
from
the
default
configuration
as
well
as
their
own
configuration.
So
the
motivation
behind
this.
As
of
now
the
configuration
for
argosity
notification,
is
centrally
managed.
Only
Argo
City
admin
can
make
notification
configuration
changes
so
what
application
teams
use
pager,
Duty
V2
for
their
notification
service.
E
So
when
there
are
many
application,
teams
want
to
use
page
or
Duty
V2
for
their
notification
service.
They
all
have
to
go
to
Argo
CD
admin,
and
this
does
not
scale,
and
there
are
also
teams
want
to
control
their
notification
templates
and
triggers,
so
they
are
independent
of
what
argosid
admin
has
configured.
So
we
want
to
enable
application
team's
ability
to
config
their
own
notification
configuration
and
Zach.
Do
you
want
to
start.
C
C
This
does
add
kind
of
a
new
configuration
style,
Togo
CD,
where
the
notification
we
would
basically
teach
the
notification
controller,
how
to
interpret
the
configuration
for
apps
like
how
basically
teach
it
our
goes
to
these
command
line
flags
for
the
list
of
namespaces
to
use
to
that
are
allowed
to
basically
have
apps
in
them,
and
then
the
notification
controller
would
look
at
the
metadata
dot
namespace
of
the
app
and
find
the
statically
named
config
maps
and
secrets
that
coincide
with
the
app
and
use
that
for
the
notification,
configuration
and
secrets,
and
then
it
would
still
also
use
the
default
configuration
that
lives
back
in
the
Argo
CD
namespace
as
well.
C
And
then,
if
we
scroll
down,
we
kind
of
look
at
the
use.
Cases.
I
think
that
kind
of
explains
it
more
directly
as
well.
C
Let's
go
down
this
little
bit
to
the
use
case.
So
basically
the
can
you
just
scroll
down
a
little
bit
more
Leo.
E
C
So
the
first
use
case
is
what
may
win
over
the
pager
Duty
one.
The
examples
kind
of
make
it
clear-
and
the
main
thing
to
point
out-
is
that
so
this
application
here
is
living
in
the
name
space,
some
namespace.
Now
we
have
the
config
map
and
the
secret
as
well
that
live
in
the
exact
same
namespace
as
the
application.
C
So
the
notification
controller
would
then
go
and
find
those
two
configurations
and
and
use
those
for
notification,
configuration
yeah,
that's
kind
of
the
general
implementation
and
if
you
scroll
down
a
little
bit
farther
to
the
bottom
of
this,
the
other
use
cases
that
we
talked
about
would
be.
You
know,
custom
templates
and
custom
triggers.
You
know
users
just
wanting
to
change
the
message
format
or
you
know
what
gets
triggered
on
on
a
particular
thing.
Like
Mae
mentioned,
there
are
some
security
considerations
that
we
thought
about.
C
C
The
Argo
CD
admin
is
basically
expected
to
use
the
apps
in
any
namespace
to
permit
the
users
to
deploy
applications,
config
maps
and
secrets
in
their
team's
namespace.
It
kind
of
extends
the
multi-tenancy
by
namespace
Design
for
just
applications
and
possibly
additional
items
of
configuration
today.
Just
being
notifications,
notification,
configurations
and
secrets,
the
risk
consideration
is
basically
that
you
know.
Argocd
has
a
few
different
ways
to
configure
things.
Some
of
them
are,
via
you
know,
app
projects.
Some
of
them
are
via
app
spec,
stuff
environment
variables.
C
This
kind
of
adds
a
whole
new
pattern
to
giving
users
the
ability
to
self-serve
or
self-configure,
but
it
does
align
itself
with
apps
have
any
namespace.
C
We
basically
also
went
through
a
couple
Alternatives,
they
all
seem
to
be
I,
don't
know,
let's
get
Upsy
and
drift
a
little
bit
more
away
from
the
kubernetes
ecosystem
and
kind
of
go
more
into
Argo,
CD
API,
Style
versions.
So
we
kind
of
liked
the
we
liked
the
proposal
of
using
a
more
get
Ops
kubernetes
native
configuration
pattern
that
could
be
extended,
possibly
to
other
config
items
within
Argo
CD,
but
the
the
three
Alternatives
here
would
be
allowing
self-service
notifications
to
be
configured
by
the
API
segmented
by
projects.
C
This
isn't
very
good
opsy.
We
could
associate
notification
configs
with
an
app
project
instead
of
the
application's
namespace.
It
could
still
be
git
Ops,
but
you
know
there
would
be
different.
It
depends
depending
on
how
we
Associated
the
config
to
the
app
and
then
notification
configs
with
an
application
directly
so
basically
add
the
notification
config
stuff
to
an
application
itself.
C
Instead
of
you
know,
using
the
applications
namespace
to
pull
those
configs
and
secrets
from
yeah,
so
just
kind
of
looking
for
feedback
on
what
people
think
of
adding
this
new
ish
configuration
model
to
Argo
CD.
A
Okay,
thanks
Zach
thanks
May
any
comments
on
the
proposal,
so
the
the
main
idea
is
to
add
the
ability
for
application
developers
to
drive
subset
of
configurations
in
their
application
not
having
to
depend
on
Argo
City.
That
means
to
do
so
any
comments
any
concerns.
Anyone.
D
I
I,
like
this
I,
think
it's
just
the
natural
evolution
of
anything
in
any
namespace
right
I
mean
if
we,
if
we're
looking
into
the
future,
we
we
may
even
at
some
point
in
time,
have
repositories
in
the
namespace
sort
of
like
repository
configurations
and
namespaces,
or
something
like
that.
So
yeah
I
I
was
just
wondering
like
if,
if
we'd
be,
to
impose
any.
D
Like
if,
if
we,
if
we
thought
about
like
extending
what
we
have
in
app
project
now,
like
you
know,
we
can,
we
can
restrict
in
the
app
project
the
destinations,
and
you
know
the
repositories
that
are
allowed
to
use
and
stuff
like
that,
and
do
we
want
like
if,
if
we
bring
this
to
to
users,
basically
all
this
kind
of
configuration,
how
have
we
thought
about
like.
D
Restricting
them
to
what
they
are,
what
they
will
be
allowed
to
use
from
notifications
configuration.
Let's
say
you
know:
when
that
application
is
targeted
to
project
Foo,
then
they
only
are
allowed
to
use
the
pager
Duty
service
and
not
whatever
is
configured
in
the
notifications
controller,
as
as
methods
of
configuration
yeah.
So
that's
something
we
thought
about,
or
so.
C
So
I
don't
necessarily
know
if
it
applies
the
notifications,
config
per
se.
So
with
this
proposal
and
maybe
you're
aware
of
how
regular
notifications
work
so
Norm,
we
still
have
the
default
config
that
lives
in,
like
the
admin
side
right.
C
The
applications
could
individually
subscribe
to
right,
but
as
far
as
the
Restriction
of
like
Argo
CD
doesn't
have
the
concept
today,
even
of
being
able
to
like
do
individual
like
if
I'm,
if
I'm
understanding
a
question
correctly,
they're
basically
saying
don't
allow
users
to
use
a
particular
notification
service
within
their
self-service
config
map,
correct
yeah.
B
B
D
So
just
and
it
it's
maybe
it's
restricted
to
particular
very
important
apps
that
you
know
that
you
definitely
want
your
manager
or
whatever
receive
an
SMS
if
it's
done
and
so
yeah
just
like
to
prevent
some
because
you
hand
out
control
to
the
user
of
of
all
this
stuff
right.
B
D
You're
right,
I'm
I'm,
not
very
I'm,
not
very
well
versed
in
how
notifications
actually
work.
So
it's.
C
C
That
that's
fair
and
I
think
with
the
proposal
today
that
doesn't
exist,
you
would
have
to
basically
teach
Argo
CD.
The
support
like
notification
engine
today
is
basically
a
whole
separate,
Library
a
whole
separate
project
that
can
be
used
for
anything
and
I'll
go
see
just
uses
it
as
its
own
controller
and
it
the
Argo
CD
itself
has
no
concept
of
what
anything
in
that
config
map
is
today.
C
So
that
would
I
like
it
that
that's
almost
like
a
new
permission
right
into
our
back
model
around
that.
That
would
have
to
be
tied
to
the
project.
But
then,
then
you
have
to
teach
Argo
CD
what
each
cert
you
know
all
the
services
that
are
supported
and
for
notifications
and
Etc
and
I
I
mean
it
would
be
doable,
but
I
I,
don't
know,
I,
don't
know
if
it's
worth
it
without,
like
other
people
requesting
the
feature,
I
guess
yeah.
D
F
And
it
could
work
similarly
to
the
way
app
projects
currently
restrict
apps
in
external
namespaces.
We
just
have
an
Argo,
CD,
Central
namespace
thing,
a
config
map
or
whatever
that
contains
those
restrictions
and
people
can
put
whatever
config
they
want
in
their
namespace.
But
that
doesn't
mean
the
notifications.
Controller
is
going
to
respect
it
right.
F
So
I'm
not
exactly
sure
what
kind
of
restrictions
would
make
sense
for
notifications
controller.
But
let's
say
it's
you're
only
allowed
to
push
to
pagerduty.
F
C
F
B
C
A
F
It's
fine
to
add
a
note.
That's
just
like
you
know.
We
understand
that
at
some
point
we
may
introduce
stuff
in
any
namespace
and
that
stuff
needs
to
be
restricted.
According
to
certain
rules
like
we
understand
that
we
could
enforce
those
restrictions
either
by
adding
new
fields
to
have
project
or
just
new
fields,
to
other
config
maps
in
the
central
Oregon
CD
namespace.
That's
where
all
the
rules,
Come
From,
sure.
A
Which
brings
me
my
next
question.
Well,
so
this
proposal
is
is
providing
the
example
of
pager
Duty
right
yeah,
but
if
we
want
to
have
additional
configuration
to
be
consumed
by
rdocd,
would
this
proposal
be
preparing
for
that
or
this
is.
C
This
proposal
covers
the
use
case
100
for
notifications
engine
from
a
technical
perspective,
so
users
have
full
control
of
the
config
map
right
they
they
can
do
anything,
but
it
lays
the
I
don't
want
to
use
the
word
foundation,
but
because,
because
from
a
technical
implementation,
there's
no
other
thing,
but
it
lays
the
idea
of
moving
other
configuration
to
self-service
within
the
namespace
of
the
application.
It
sets
up
that,
like
idea
for
things
other
than
notifications
to
live
in
the
same
namespace
that
the
app
lives
in.
C
A
E
A
All
right
anything
else,
any
other
comments
regarding
this
proposal.
G
C
So
they
don't
merge
technically,
they
run
you
can
think
of
as
running
in
parallel.
So
because
there's
this
concept
of
global
notifications
as
well,
where
the
admin
can
basically
an
application,
doesn't
have
to
subscribe
to
the
notification,
but
the
admin
can
basically
apply
a
global
list.
That
applies
as
well.
So
basically
it
just
runs
the
two
config
maps
in
a
loop.
You
can
think
of
it
right,
it'll
process,
the
one
send
all
the
notifications
and
look
at
the
default,
send
all
the
notifications
that
match
and
then
go
on
about
its
way.
C
So
technically,
if
they
had
two,
they
had
the
same
Services
it
would
send
them
twice.
I
see
I,
see,
okay,.
C
A
All
right
thanks,
May
thanks
Zach
thanks
everyone
for
comments.
Let's
go
on,
let's
see
yeah.
This
was
the
only
topic
for
the
day.
If
anyone
has
a
last
minute
topic,
you
want
to
discuss.
If
you
please
feel
free
to
do
so,.
A
G
A
Explain
what
is
this
George
basically.
H
When
they
will
multi-source
report
was
added,
the
rollback
was
disabled
for
multi-source
applications.
If
you
scroll
down
a
bit,
you
will
see
some
pictures
about
the
final
status.
Basically,
this
PR
enables
the
rollback
feature
for
applications
based
on
Multi,
multiple
sources
that
currently
is
disabled.
So
it's
just
for
asking
a
review.
If
it's
possible.
H
D
D
H
A
All
right
thanks
thanks
George
for
letting
us
know,
yeah,
as
Michael
said,
we
need
a
lot
of
lots
of
hands,
especially
in
the
review
area
or
for
the
project
all
right.
Anything
else.
B
B
So
there
was
an
issue
which
was
brought
up
a
couple
of
weeks
back
in
contributors
meeting
related
to
this,
where
the,
where
the
resources
with
sync
waves
are
not
getting
cleaned
up
properly
due
to
during
sync,
because
it
follows
the
creation
order,
even
when
we
perform
a
premium
of
the
resources
So.
Based
on
the
discussions
from
the
issue.
B
I
was
thinking
of
introducing
a
reordering
logic
in
get
Ops
engine
so
that
during
sync,
we
prune
the
higher
order,
resources
first
and
also
add
a
weight
so
that
the
resources
are
actually
diluted
before.
Moving
to
the
next
wave.
Just
wanted
a
feedback
on
this.
A
With
this,
with
this
sync
waves
that
there
is
already
an
ordering
applied
in
github's
engine,
not
sure
how
that
is
reflecting
Whenever,
there
is
a
prune
did.
B
B
A
B
D
I
think
there's
like
I
think
there
is
two
scenarios
right
like
because
I
remember
there
was
a
part
recently
about
the
deletion
order
when
sync
waves
are
used
and
I
think
there's
a
difference
in
behavior
when,
when
you
so
there's
two
scenarios
right
one
is
you
delete
the
application
in
a
cascading
manner
so
that
all
resources
will
be
deleted
and
then
there
is.
D
B
Yeah
true,
so
when
we
delete
the
application,
the
resources
are
deleted,
in
reverse
order
of
the
sequence.
D
Yeah
no
way
I
was
finished
thanks.
Sorry,
so.
A
All
right,
and
are
you
willing
to
to
pick
up
this
task.
B
A
D
Yeah
I
I,
guess
it's
it's!
It's
totally
awesome.
If
you
do
that,
I
mean
you
know.
It
just
makes
sense
from
my
point
of
view,
at
least
that
even
in
those
scenarios
where
resources
are
deleted
from
git
and
also
that
all
is
obeyed
right.
B
B
If
we
wait
for
resources,
especially
during
cleanup.
C
A
Yeah,
we
already
have
issues
with
finalizers,
while
the
leading
resources,
sometimes
so
we
are
for
pruning
them.
First,
to
my
blog.
C
Well,
would
you
I
don't
know
because
really,
if
you
think
about
it,
maybe
you
wouldn't
actually,
because
if
you
consider,
if
you're
doing
waves,
your
wave
five
would
be
like
your
higher
priority
one.
So
maybe
some
people
would
want
it
to
go
in
the
in
the
right
order.
So
if
wave
five
is
like
your
production,
environment
and
wave,
one
is
your
non-prod
and
you
want
to
delete
some
people
might
actually
want
to
delete
non-prod.
First.
A
C
A
Foreign,
so,
for
example,
if
you
have
five
waves
and
then
wave,
not
five,
but
three,
maybe
simplify
right,
yes
and
then
wave
two
has
a
resource
that
was
deleted,
so
so
how
this
should
proceed.
C
D
A
C
Applied
I
think
the
logic
for
deletion
should
be
configurable,
with
a
reverse
option
and
a
forward
option
depending
on
how
people
are
using
waves
right.
So
if
you
want
to
go
revert
like
just
have
a
config
that
says
prune
order
or
something,
then
it
would
check
wave
three
if
anything's
deleted.
If
you
have
it
in
reverse,
then
go
to
wave
two.
C
If
anything
is
deleted,
then
go
to
you
know
the
last
wave
and
that
way,
if
anything
gets
you
know
stuck
or
ordering
is
important
there
on
the
pruning,
they
would
do
that,
but
I
think
I
think
for
the
prune.
That
should
be
a
configurable
option.
Just
due
to
you
know
some
people
using
waves
for
different
environments.
G
I
I
also
wonder
if
you
remove
certain
waves
and
that
causes
your
service
to
be
down.
You
probably
want
to
still
continue
and
delete
other
waves,
because
just
the
services
in
a
bad
state,
for
example,
if
you're
second
wave
is
I,
don't
know
a
little
balancer
or
something
like
that
and,
like
you
know,
that
your
service
is
down
foreign.
D
The
wave
behaves
like
it
waits
for
this
for
that
way
for
all
the
resources
to
become
sweet
and
healthy
right
and
then
Collision
that
just
doesn't
make
sense,
I
guess,
but
we
should
just
follow
that
reverse
order
and
probably
I
use
the
you
know
foreground
deletion
procedure
like
just
wait
until
the
API
tells
you
okay
go
ahead
this
this
has
been
deleted.
A
A
A
D
Let's
say
you
delete
a
resource
that
belongs
to
wave
five
and
you
delete
a
resource
that
belongs
to
wave
three
and
you
build
delete
a
resource
that
belongs
into
wave
one
like
all
all
with
one
commit
you
remove
them
from
git
right,
then
it's
just
like
the
one
that
was
in
five
gets
deleted.
First,
then,
three,
then
one
right
like
just
in
that
order
I
think
there's
nothing
much
more
to
to
the
deletion.
It's
just
like.
A
D
B
D
B
D
C
A
All
right,
okay,.