►
From YouTube: Argo Contributors Office Hours May 12th 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
Hi
everyone
welcome
to
the
contributors
meeting.
I'm
leo,
I'm
gonna
be
your
host
today
and
let
me
start
by
sharing
my
screen.
A
All
right
so
as
usual,
starting
off
with
the
triage
and
discussion,
hemington
and
keith,
were
the
primary
and
secondary
for
the
week.
So
do
you
have
anything
to
mention
about
this
week?
Hammington,
okay,.
B
B
C
A
Okay,
all
right,
thank
you!
So,
as
usual
again,
so,
let's
decide
who's
going
to
be
primary
primary
and
secondary.
For
next
week,
any
volunteers
for
primary
and
secondary.
A
A
Okay,
let
me
simplify
this
I'll,
put
myself
as
a
as
primary
and
all
right.
Let's
move
on
okay,
so
next
topic
of
the
day
we
have
quite
a
few
first
one
with
michael,
basically,
is
something
that
we
discuss
together
but
I'll.
Let
you
michael
lead
the
way.
F
Yep
so
in
config
management
plugins,
the
users
are
allowed
to
pass
arbitrary
environment
variables
from
the
application
manifest
and
that's
potentially
a
problem
because
they
could
overwrite
or
write
environment
variables
which
cause
code
execution,
cause
malicious
behavior.
F
I
know
a
lot
of
config
management,
plugins
use,
git
and
git
has
just
a
ton
of
config
environment
variables
that
could
be
misused.
So
the
proposal
is
prefix
all
of
those
environment
variables
before
they
make
it
to
the
config
management
plugin
and
then
the
cmp
author,
if
they
want,
can
take
that
prefix
environment
variable
and
basically
remove
the
prefix,
so
they
have
to
at
least
know
that
the
user
is
passing
that
variable.
F
The
question
is:
do
we
have
a
deprecation
period
where
we
say
you
know
eventually
we're
going
to
prefix
all
these
environment
variables,
so
change
your
config
management
plugins?
Or
do
we
go
ahead
and
prefix
everything
now
and
just
write
up?
A
really
nice,
like
upgrade
note,
maybe
put
it
in
the
release
blog
that
people
need
to
update
their
cmps
since
it's
a
security
enhancement
leo-
and
I
thought
maybe
we'd
want
to
be
more
aggressive
and
go
ahead
and
prefix.
G
I
think
it's
appropriate
to
be
a
bit
more
aggressive
since,
like
you
said
it's
a
is
a
security
issue
and
you
know-
and
I
think
yeah
I
mean
the
earlier-
we
do
it,
the
the
less
people
will
be
affected
right.
A
I
I
think
I
agree
with
that,
as
we
are
facing
quite
a
few
security
issues.
I
think
if
we
document
this
well,
I
think
it's
gonna,
it's
gonna,
be
still
well
accepted,
but
again
just
my
opinion
and
I
think
it's
worth
hearing
other
people.
D
And
allow
a
little
bit
of
time
for
people
to
see
it
just
because
you
know
somebody
may
be
relying
on
it
and
you
know
they
just
happen
to
not
be
in
this
meeting.
So
is
it?
Is
that
discussion?
D
So
yeah,
I
think,
michael
I
I
think
I
would
advise
writing
up
a
little
bit
about
the
deprecation
and
what
it's
going
to
affect,
and
then
we
can
post
in
the
argo
channels
and
leave
it
open
at
least
a
week
or
two
to
let
people
come
in
and
say:
oh
actually,
we
use
that
or
whatever,
so
that
there's
not
going
to
be
a
surprise
for
them,
because
I
mean
the
other
on
the
other
side.
D
If
it's
for
2.4
the
potential
is
that
we
remove
it
and
then
people
yell
about
it
and
we
have
to
add
it
back
into
2.4.
So
I
guess
either
way
is
potentially
okay,
but
if
it's
not
going
to
delay
the
release
because
right
now
right
now,
nothing
else
is
waiting
on
for
2.4,
there's
a
bunch
of
other
stuff.
That's
waiting,
my
point
so
doing
a
deprecation
notice,
I
feel
like,
would
give
chance
for
people
to
bring
it
up
now,
rather
than
waiting
for
them
to
be
surprised
about
it
later.
F
Okay,
I
will
write
up
basically
upgrade
instructions
and
add
them
to
that
pr,
as
well
as
just
a
notice
that
we
can
put
in
the
slack
channels.
A
Okay,
cool
thanks
so
moving
forward.
Another
topic
from
michael
websockets
error
in
terminal
feature:
I've
seen
that
mikey
want
to
comment
on
this.
F
Yeah,
this
is
another
just
I'd
like
folks
to
take
a
look
because
I
know
virtually
nothing
about
web
sockets
and
this
is
a
fairly
high
profile
feature.
So
if
you
know
a
bunch
about
websockets-
and
you
can
look
at
like
chrome
network
logs
and
tell
what's
going
wrong
with
this
user
setup,
that'd
be
awesome.
A
I
okay,
I
I
read
about
this
and
I
I
had
the
impression
it
was
already
solved
by
the
our.
F
F
C
A
F
I
know
rc's
are
supposed
to
be
a
little
bit
feature
crazy,
but
we
have
one
user.
If
you
really
like
to
see
this
and
the
change
is
fairly
small
and
isolated
to
application
set
so
yeah
if
anyone's
opposed
to
cherry
picking
this
over,
let
me
know,
but
otherwise
I
think
we
should
just
go
ahead
and
do
it.
F
So
this
is
someone
who's
got
a
pr
against
master
for
the
get
lab
pr
generator
for
application
set
and
since
we've
already
cut
the
rc.
If
I
merge
this
pr-
and
I
think
like
I
haven't
reviewed
it
completely
yet,
but
once
I
do
I'll
merge
it
to
master
and
the
question
is:
do
we
then
cherry
pick
it
over
to
the
2.4
branch.
A
I
think
I
have
a
mixed
opinion
about
this.
It
does.
It
doesn't
look
like
a
super
small
change
and
it's
a
new
feature
right
and
that
is
coming
in
after
the
the
release.
Candidate
was
tagged.
F
Release
just
some
user
has
to
wait
till
2.5
to
get
this
feature.
How
much
they've
been
waiting
on
I,
so
it
looks
like
a
big
pr.
It
has
this
big
json
blob
and
it
has
some
big
test
stuff.
A
lot
of
that
is
just
tests.
The
real
guts
of
it
is
about
30
lines
of
code.
F
How
how
soon
do
you
think
you
can
get
through
the
pr
I've
already
given
a
good
first
pass,
and
I'd
expect
to
merge
it
this
afternoon.
A
A
Yeah,
the
more
we
add
the
slower
it's
going
to
be.
I
think
I
agree
with
that.
H
I'm
always
argued
for
being
more
strict
with
with
the
dates,
and
you
know
you
miss,
because
the
problems
once
you
start
delaying
your
release,
then
you
push
things
to
the
next
release
and
then
people
don't
want
to
wait
because
it's
longer
and
if
it's
strictly
with
the
dates,
then
you
know
it's
going
to
be
at
most
a
quarter
to
wait.
So
you
know
I.
D
I
I'm
convinced
by
henrik
and
loses
arguments
that
it's
probably
best
to
wait,
because
I
was
thinking
for
some
reason
that
that
it
wasn't
for
2.4.
I
was
thinking
of
the
next
one,
so
I
was
like
yeah.
I
don't
even
know
why
you're
asking
but
yeah
after
the
release
candidate,
since
it
is
a
new
feature.
D
I
think
I
agree
that
we
should
keep
it
separate.
I
mean
yeah.
A
All
right
thanks,
michael
okay,
so
moving
forward.
Then
I
think
this
was
added
by
you.
I
saw
you
typing.
D
So
I
had
two
issues
to
bring
up
from
people
that
weren't
able
to
join
and
they
asked
if
I
could
discuss
them.
So
this
first
one
is
the
introduce
our
back
based
approach
to
pod
logs.
D
So
the
the
issue
with
this
is
that
the
feature
included
two
sides,
one
for
basically
the
back
end
to
create
the
create
the
the
r
back
and
to
enforce
it
and
the
other
for
the
front
end
to
expose
what
was
happening
and
the
back
end.
Work
was
completed
and
merged
and
brought
into
the
rc,
but
the
ui
work
hasn't
been
done
yet.
So
there
is
some
potential
issue
there
where,
where
we
we
basically
it's
incomplete.
D
So
the
question
is:
either
we
pull
out
the
back
end
component
or
we
ship
it.
Knowing
that
the
we
basically
will
have
a
ui
error
until
this
is
fixed,
and
I
think,
michael,
you
took
a
look
at
this
and
you
suggested
that
we
just
move
forward
with
it
because,
even
with
the
even
with
the
log,
the
the
error,
the
ui
error,
is
essentially
that
you'll
get
an
unable
to
load
data,
internal
error
which
isn't,
as
you
know,
maybe
not.
D
It's
a
little
bit
of
an
ugly
error,
but
the
the
r
back
will
still
be
there
and
you
can
use
it
and
I
think
it
requires
a
feature
flag
to
enable
in
the
config
map.
Michael,
are
you
familiar
with
this
one.
F
F
D
So
so
yeah
I
mean
in
order
to
get
the
r
back
on
the
logs,
because
otherwise
they're
just
not
public
but
they're
available.
You
have
to
enable
the
feature
flag,
and
so
I
mean
my
instinct
here.
Michael
is.
D
I
would
probably
agree
with
you
that
that
I
would
probably
let
it
go
forward
and
maybe
you
know
add
a
little
notice
on
this
feature,
that
there
is
kind
of
a
known
issue
that
the
that
the
ui
error
isn't
as
nice,
and
since
it
is
an
opt-in
feature,
you
know
it's
like
people
aren't
going
to
run
into
it
on
accident
they're
going
to
have
to
be
looking
for
this
feature,
turn
it
on
and
then
maybe
once
the
maybe
once
the
ui
piece
comes
in,
then
we
could
think
about
enabling
the
feature
by
default,
rather
than
having
to
be
opted
only.
A
D
Yeah,
because
you
can
basically
not
enable
the
rbac
on
the
pod
logs,
and
so
if
that's
an
important
security
feature
you're
looking
for
it's
it's,
it
will
accomplish
that
task
in
the
ui
is
my
understanding.
It's
just.
The
ui
will
give
an
ugly
error
rather
than
a
nice
error
that
makes
it
really
clear.
What's
going
on
and
and
yeah
as
rishab
points
out,
yeah
the
the
the
documentation
was
added
in
as
well.
D
It's
it's
already
been
merged
and
it's
already
part
of
the
rc
and
regina
is
basically
just
like.
D
Oh,
I
didn't
realize
it
was
gonna
get
merged
because
I
don't
have
the
ui
piece
done
yet
so
I
feel
like
it's
incomplete,
so
she
just
wanted
to
flag
it
as
like
a
potential
issue
of
like
if
we
push
it
forward.
There
is
the
expected
behavior
of
basically
an
ugly
error
in
the
ui.
If
people
try
to
use
this
feature,
but
the
feature
works,
it
just
isn't
necessarily
totally
intuitive
from
the
ui
side.
D
F
A
E
F
D
Okay,
I'll
I'll
make
a
note
that
we
should
the
consensus
is
to
move
forward
and
to
add
a
release.
Note
so
I'll
ask
rachina
if
she
can
do
that.
A
D
D
Yeah,
this
is
one
that
somebody's
been
waiting
on
well,
the
way
they
talked
about.
It
sounded
like
a
long
time,
but
now
that
I'm
looking
at
the
pr
it's
15
days
ago.
So
this
this
pr
just
fix
is
a
fairly
small
fix
and
it
was
merged
into
notification
engine
on
april
27th.
D
When
is
notification
engine
brought
into
when,
when
is
that
put
part
of
the
release
like
when
was
the
cutoff
date,
because
we
were
just
trying
to
figure
out.
I
actually
thought
that
this
one
was
in
within
the
cut
off,
so
I
actually
don't
know
how
we,
how
we
deal
with
bringing
in
notification
engine
updates.
A
D
My
understanding-
and
I
could
be
totally
wrong-
was
that
basically,
this
was
essentially
picked
into
argo
cd.
I
don't
like
like
argo
cd
is
an
implementation
of
argos
senior?
Has
an
implementation
of
our
go,
see
notifications,
but
then
I
don't
know
how
we
actually
get
updates
into
argo
cd
when
notification
engine
is
updated,
and
so
it
felt
like
there
was
maybe
a
hole
in
understanding
like
how
often
that's
updated
like
looking
at
our
notification
controller
that
hasn't
been
updated
in
like
five
months
so
wait.
I
think.
E
The
notification
engine
is
a
dependency
in
it's
referenced
by
your
gogo
mod
and
then,
if,
if.
G
E
When
we
pick
up
a
newer
version
and
then
they
will
grab
the
you
know,
the
update
and
fixes,
I
think
notification
in
other
cities
is
a
thin
layer.
Basically
a
thin
wrapper
around
the
notification
engine.
D
So
we
basically
need
a
pr
to
update
the
version
of
that
package
yeah
if
so,
okay,
okay,
so
I
can
take
that
back
to
kevin
and
then
maybe
there's
just
like.
D
I
don't
know
when
we,
when
we
make
the
decisions
of
updating
those
underlying
versions
and
when
they
get
pulled
in
so
I
I
guess
I'll
just
ask
him
to
go
and
open
a
pr
on
argo
cd
to
update
the
version,
and
then
I
don't
know
if
there's
who
works
on
notification
engine
because
or
how
they
how
they
deal
releases
so
that
I
don't
know
this
is
just
a
whole
part
of
the
process.
I'm
not
super
familiar
with,
and.
D
So
I
guess
I
guess
I'll
just
take
well
yeah
when
are
the:
when
are
the
releases
like
I'm
looking
at
it
and
there
hasn't
been
a
release
on
notification
engine
since
november
2021,
so
yeah,
it's
fairly
old
and
in
terms
of
commits.
D
It
looks
like
we
have
quite
a
few
commits
going
back
to
when
that
previous
version
was
released.
So,
given
that
I
guess
we
need
to
so
I
guess
there's
there's
two
steps.
We
need
to
push
for
a
new
release
of
notification
engine
and
then
get
a
get
a
pr
to
update
the
package.
So
I
don't
know
who
can
cut
a
release
on
this?
I
guess
alex
or
ryota
hasn't
really
been
as
active.
Maybe
pasha
could
push
a
release
of
it.
D
A
We
have
a
similar
process
with
git
ops
engine,
so
basically,
I
can
tell
by
myself
when
I
work
on
something
related
to
the
to
a
change
that
requires
a
modifying
git
ops
engine.
I
I
take
care
of
the
whole
process,
so
I
I
go.
I
know
that
gitop's
engine
needs
to
be
released
and
I
know
that
once
that
is
done,
go
mod
needs
to
be
updated
to
the
the
released
version.
A
So
that's
usually
how
I
do
this.
If
the
notification
agent
follows
the
same
pattern,
yeah,
I
think
it's
a
process
that
we
need
to
follow.
Basically.
D
Okay,
I'll
take
that
with
kevin
and
and
just
tag
a
few
other
folks
on
the
issue.
I
think
I'll
just
create
it
as
an
issue
to
to
cut
a
release
and
reference
kind
of
all
these
items,
and
then
presumably
we
wouldn't.
D
G
G
D
So
that
means
we're
missing
one
two
three
four
five
commits
one
of
them
is
a
feature
for
pagerduty
integration
to
our
testings
onesie
and
then
two
are
bug
fixes.
So
there's
only
one
there's
only
one
feature
which
is
a
pager
duty
integration,
and
then
there
are
two
bug
fixes
and
an
additional
set
of
tests.
D
Okay,
so
let's
I
guess
we'll
we'll
get
a
pr
open
to
try
to
update
it
if
it's
not
doing
on
a
regular
release,
if
it's
doing
it
based
just
on
like
essentially
picking
out
a
commit,
then
you
know,
I
guess
we
would
just
evaluate
it
as
a
pr
and
getting
the
fixes
in
feels
like
a
potential
priority.
The
feature,
the
two
features,
which
is
the
pagerduty
integration
and
a
lot
list
of
triggers
in
notification
annotation.
D
Maybe
those
get
bumped
to
2.4
just
because
we're
we're
feature
frozen
right.
So,
okay,
so
I'll
I'll
work
with
kevin
to
get
the
pr
in
to
update
the
version.
D
And
then
we
can
have
a
discussion
about
if
we
want
to
cherry
pick
the
fixes
or
if
we
want
to
pull
the
whole
thing
in
and
I'm
not
familiar
with
that
part
of
the
code
base.
So
I'm
probably
not
the
best
judge
of
it,
and
maybe
somebody
else
can
weigh
in
so.