►
From YouTube: Argo Contributor Experience Office Hour 25th June 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
Okay,
so
one
more
time,
good
day,
good
evening,
good
morning,
all
right,
I'm
looking
for
a
list
of
attendees
today,
I
don't
think
anyone
joined
for
the
first
time.
But
let
me
know
if
you're
joining
for
the
first
time-
and
you
want
to
introduce
yourself
and
all
right.
C
Oh
sorry,
I
was
on
mute,
hey,
hey
everyone.
My
name
is
doreen
carmichael
on
the
red,
hot
openshift
support
team
here
in
denver,
jan
and
william
and
regina,
invited
me
and
and
hoping
to
learn
more
about
that
argo
city
project
from
the
cncf
side.
Glad
to
be
here.
Thank
you.
B
B
And
we
we
do
have
s
cat,
yellow.
A
All
right,
so
we
had
two
topics
so
far
and
yet
I'm
not
going
to
share
actually
yeah.
I
will
share
my
screen
because
I
will
need
to
show
the
first
topic
is
for
me.
So,
as
you
remember,
I
think,
two
weeks
before,
like
two
weeks
ago,
we
spoke
about
enhancing
our
ocd
process
and
I
guess
the
development
of
of
the
project.
A
So
if
you're
curious,
I
think
you
can
review
that
pr
offline
and
you
know,
provide
your
comments,
but
basically
pull
request
includes
few
changes
that
we
can
do
to
improve
the
process
plus
it
has
owner
files
and
in
that
meeting
I
feel
like.
I
just
wanted
to
kind
of
highlight
things
which
I'm
still
you
know,
I
still
don't
know
answers
to.
Basically
it
appears
that
it's
not
so
easy
to
find.
You
know
to
create
a
good
set
of
owner
files
in
in
the
code.
A
A
Basically,
components
are
spreaded
across
different
packages,
and
so
I
had
to
kind
of
sprinkle
different
owner
files
in
I
come
up
with,
I
think,
seven
owner
files
and
I'm
looking
for
your
feedback.
Basically,
if
you
have
a
better
idea
how
you
know
which
names
should
be
in
these
files
and
where
files
should
be
located
itself,
let
me
know
please
yeah
and
I'm
kind
of
personally
still
not
satisfied
he's.
It
looks
like
you
know,
random
files
here
and
there
so
in
gpg
package.
I
know
jan
wrote
it
that's
why
I
put
it
his
name
here.
A
At
the
same
time,
gpg
is
not
in
just
that
folder,
it's
just
a
utility
folder
with
few
gpg
functions
and
yeah,
but
I
think
this
is
the
best
I
I
I
could
do
all
right.
So
this
is
that's
the
first
thing
and
next
I
kind
of
the
document
describes
the
process,
but
in
the
pr
kind
of
description
I
just
added
a
summary
of
things
that
we
can
do
if
that
pr
is
merged
and
and
then
we
would
have
to
you
know
if
we
follow
the
process
describing
that
pr,
we
would
have
to
do
this.
A
You
know
four
things
kind
of
one
we
would
have
to.
Finally,
you
know
come
up
with
the
end
date
for
current
milestone,
since
we
agree
we're
kind
of
agreeing
to
release
every
three
months
and
don't
you
know,
kind
of
not
to
and
basically
release
every
three
months,
no
matter
how
much
we
achieved,
and
next
we
agreed
that
we
supposed
to
have
assignee
for
every
pull
request
and
jan
found
an
awesome
plugin
for
github.
Basically,
I
looked
at
this
plugin
github
action.
A
And
next
we,
basically,
if
we
want
to
release
you
know
and
who
follow
the
new
procedure
during
testing
of
that
release,
we
would
have
to
go
in
the
past
and
try
to
assign
prs
to
all
sorry
assign
maintainer
to
all
merged
players
so
far,
and
we
would
have
to
work
on
a
milestone
draft
for
the
next
release.
B
I
I
love
it,
so
I
think
it
goes
into
the
right
direction,
except
for
a
couple
of
nitpicks.
I
thought
nothing
that
I
would
disagree
with
and
yeah
as
to
say
the
the
owners,
the
owners.
D
B
D
B
Everything
else
yeah.
A
And
I
guess
maybe
owners
should
at
the
at
least,
if
you
creation
of
this
owner
files,
it's
kind
of
it's
pretty
much.
You
know
a
request
for
your
help
and
yeah
yes,
and
if
you
don't
want
to
to
be
an
owner,
just
you
know,
comment
in
the
pr,
and
so,
if
you
in
that
file,
that
means
you
kind
of
get
more
freedom
and
you
know
and
responsibility
yeah.
So
you
will
be
pinked.
B
Yeah,
but
so-
and
I
think
it
so
I
mean
github-
will
automatically
do
a
review
request
right
for
the
for
the
owner.
That's
I
assume.
B
But
I
think
it's
important
so
whenever,
whenever
you
feel
like
you
can't
review
that
on
your
own,
you
always
also
have
the
freedom
to
request
a
review
from
another
maintainer
right.
So
you
can
always
ask
for
help
for
a
second
set
of
eyes
or
whatever.
So.
E
That's
right:
do
they
enforce,
I
forget
if
they
require
an
owner
to
review
it
before
it
can
be
become
merged.
I'm
asking
from.
A
E
Okay,
because
I
I
think
it
was
the
helm,
chart,
repo
or
or
maybe
the
brew
repo
where
something
enforced
it,
but
I
don't
know
if
that
was
a
bot
or
if
it
was
good
that
but
okay
now
just
just
curious
how
good
that
handles
it.
D
A
I
will
double
check
yes
and
update
that
description.
E
A
All
right
how
about
the
end
date,
so
I
was
like
there
is
no
date
yet
proposed
here,
but
I
was
thinking
to
just
you
know
check
when
we
started
working
on
on
this
milestone
on
this
release,
2.1
and
then
just
add
three
months
and
and
use
it
as
a
date
and
something
might
not
fit.
I
don't
think
we're
moving
as
quickly
as
you
know.
Basically,
maybe
we
over
committed
already,
and
I
would
just
you
know
I
would
just
suggest
to
move
whatever.
A
D
A
A
Okay,
if
there
is
no
like
objections
right
now,
so
I
think
I
will
update
the
end
date
for
that
release
and
I
won't
be
able
anyway,
to
say
what
fits
and
what
won't
fit
right
now,
but
before
we
move
something
to
the
next
release,
I
think
we
will
have
a
discussion
in
in
the
same
meeting,
maybe
next
year,
next
week
or
week
or
two
next
week.
Does
it
sound
good
to
everyone.
A
All
right,
yeah,
cool,
okay
and
any
objections
if
I
go
through
merged
pull
requests
just
to
kind
of
just
to
remind
what
it
is
about
it's.
The
next
point
is
mostly
about
testing,
so
we
kind
of
when
we
were
discussing
the
process.
We
were.
We
agreed
that
we
just
need
someone
committed
to
test
the
change
before
it
get
merged
and
I
feel
like
we're
proposing
to
use
github
assignee
pr
assignee
to
do
that.
So,
basically
we
would,
I
would
go
for
all
pull
requests
and
try
to
assign
a
maintainer.
A
It
might
be
obvious
to
assign
you
know.
If
basically
depends
on
the
change.
I
think
we
will
have
to
sync
up
offline
and
find
someone
who
can
be
signing
for
the
pr
going
forward.
All
pr's
who
have
assignee
and
this
plugin
can
github
action,
can
help
us
to
do
it
yeah
so
and
and
then
once
we're
ready
to
test.
A
I
think
we
will.
I
describe
the
process
here
in
the
document.
Basically,
I
think
we
can
just
use
github
to
filter
all
pr's
assigned
to
current
milestone
and
I'm
proposing
to
that.
Assignee
will
go
through
hpr
and
just
do
basic
testing.
You
know
if
pr
is
trivial,
you
might
just
you
know,
decide
that
testing
is
not
needed
at
all
and,
basically
just
add
a
label.
A
A
Yeah
awesome
and
yeah
I
feel
like
yeah.
Basically,
we
kind
of
spoke
about
it,
and
this
is
just
the
way
to
you
know
how
it
can
be
implemented
all
right
and-
and
I
think
the
last
point
it's
right
here-
I
kind
of
found
this.
I
come
off
as
these
four
check
boxes
that
we
must
check
before.
We
assume
that
release
is
done,
so
one
is
to
make
sure
that
all
merged
prs
have
this
verified
label.
A
So
it's
easy
way
to
say
that,
yes,
we
went
for
all
the
changes
and
we
know
what's
in
the
release
and
we
tested
it
and
next
we
need
to
don't
just
don't
forget
to
don't
forget
to
update
roadmap.
So
it's
not
difficult
to
do
just
have
to
be
done
on
time
and
we
need
to
make
sure
we
have
kind
of
plan
for
next
release
and
the
draft
for
release
after
next
release
is
kind
of
yeah.
Just
to
again
don't
pass
one
until
the
last
moment
and
I'm
thinking
that
maybe
we
can
just
basically
copy
paste.
A
F
So
I
have
one
question
with
respect
to
this
verify
thing,
so
somebody
who
verifies
so
they
would
probably
make
sure
that
enter.
End-To-End,
end-to-end
tests
are
passed
and
that
specific
feature
is
working.
So
is
it?
Does
that
mean
it's.
A
I
mean
we
supposed
to
like
it
is
supposed
to
be
like
executed
and
supposed
to
pass
on
every
pr
merge,
and
this
is
mostly
to
kind
of
make
sure
that
let's
say
two
people
worked
on
on
features
and
both
feature
works
independently,
but
at
the
end
of
release
we
might
get
some
last
minute
problem,
not
even
a
bug
it
can
be.
A
You
know,
maybe
we
need
to
slightly
change
ui
to
accommodate
like
two
fields
instead
of
one,
so
it's
yeah,
it's
kind
of
manual
testing
to
go
yeah
manual
testing
to
look
for
something
we
missed
during
implementation,
yeah,
and
this
is
kind
of
required
because
we
technically
follow
water
waterfall
model.
So
it's
not
like
we
don't
release
rcd
continuously.
We
pretty
much
break
master
a
little
bit,
make
it
less
stable
and
then
closer
to
end
of
release.
A
We
make
it
more
and
more
solid,
with
focus
on
fixing
bugs
and
last
step
is
to
go
through
everything
we
change
and
make
sure
it
all
makes
sense.
You
know
yeah
makes
sense
yeah
and
we
had
a
lot
of
like
not
just
not
basically,
like
I
heard
many
times
that
no,
we
must
ensure
that
you
know
everything
is
stable
and
don't
merge
quote
that
break
stuff
but
kind
of
historically.
A
All
right,
that's,
I
think,
that's
it!
That's
all
I
had
so.
In
that
token,
thanks
for
commenting-
and
I
will
I
see
what
you
suggested
basically
nitpicks-
and
I
agree
about
one
paragraph
here-
the
paragraph
we
spoke
about
it
before,
but
we
kind
of
we
need
to
come
up
with
a
process
of
how
we
we
need
to
come
to
agreement
of
how
we
handle
prs,
that
we
didn't
plan
to
work
on
yeah,
and
this
is
much
better
than
when
I
wrote
it.
A
B
I
I
still
have
the
commitment
on
my
play
to
to
write
the
process,
for
you
know
so
to
to
not
get
that
many
unplanned
contributions
before
we
said.
Yes,
that's
something
we
we
want
to
do
right,
so
the
this
enhancement
proposal
process
and
the
the
project
board
we
are
using
now
but
yeah.
I
I
have
not
yet
come
around
to.
A
Write,
okay,
I
think,
looks
like
I
think
we
can
move
to
the
next
topic
and
yeah.
That
next
is
topic
is
from
here.
I
guess
you
want
to
discuss
the
proposal
to
support
rbcd
applications
in
different
name
spaces.
B
Right,
I
I
just
wanted
to.
I
I'm
not
sure
if
I
want
to
discuss
this
in
depth
online,
but
I
just
wanted
to
bring
it
to
to
our
general
attention
so
I've
written
a
proposal,
so
that's
linked
at
6409
and
yeah.
I
had
some
some
more
to
to
come
up
with
a
poc
to
actually
prove
that
the
proposal
can
work
so
and
generally,
the
question
is:
do
we
do
we
want
this
in
general?
So
do
we
do
we
want
to
allow
application
resources
to
exist
outside
the
ago
city
namespace?
A
A
So
the
idea
here
that
let's
say
we
have
a
cluster
and
that
cluster
has
many
tenants
and
argo
cd
serves
that
cluster
and
installed
into
this.
You
know
basically
into
that
same
cluster,
which
it's
serving
and
we
want
to.
Let
tenants
create
argo
cd
applications
in
their
own
namespaces
right
and
arguably
you
would
notice
these
applications
and
do
the
work.
You
know
right.
A
E
D
B
So
the
goal
is,
I
think,
I've
also
written
it
in
the
proposal.
Yes,
so
only
the
argo
cd
control
planes
cluster
is.
E
You
have
that
man,
okay,.
A
Yeah,
so
I
kind
of
I
don't
have
strong
opinion
yet
at
least,
but
I
kind
of
it
what
I
one
reason
why
I
I
wanted
to
think
about
some
other
approaches.
Basically,
I
know
that
some
users
would
never
be
able
to
enable
it
and
this
that
user
is
basically
our
company,
because
we
run
many
argo
cgs
in
the
same
cluster
in
different
time,
spaces
on
on
purpose.
B
You
can
actually
so
if
you
so
the
you
can
restrict
the
poc
doesn't
doesn't
do
that
yet,
but
you
could
restrict
the
name
spaces
to
watch.
Oh
you
think
yeah
and.
A
B
Know
yeah
so
base
so
in
general,
so
the
the
watcher
is
either
on
a
single
name,
space
or
all
name
spaces
right.
So
I
think.
D
B
No
difference
so
no
no
shade
between
that,
but
yeah
you
can.
You
could
apply
logic
to
to
say:
okay,
this
instance
just
watches
for
stuff
in
in
these
name
spaces,
and
I
guess,
if
you
have
multiple
argo
cds
running
on
the
same
cluster,
you
you
would
also
have
restricted
it
using
arbuck
kubernetes
arabic
to
to
just
certain
name
spaces,
probably
I'm
not
sure
but
yeah.
I
think
it
would
be
possible.
A
At
least
in
the
court,
you
definitely
can
you
can
just
have
like
a
filter
or
something
in
in
the
gold
code,
all
right
and
yeah.
I
guess
maybe
we
can.
We
can
compare
this
approach
with
another
approach
and
just
list.
You
know
prostate,
like
pros
and
cons.
So
basically
another
way
to
do
that
is
to
kind
of
implement
exact,
same
logic,
but
in
a
in
a
labs
project
in
a
in
a
kind
of
in
an
additional
crd
and
that
crd
would
list
it
would
watch
for.
A
Basically,
the
clg
would
produce
applications
in
argo,
cg,
name
space,
and
that
approach
is
described
here.
I
think
you
yeah
again
mentioned
that
yeah
yeah.
A
So
basically
we
have
an
alternative
and
I
think
we
consistently
created
it
almost
at
the
same
time
and
that
proposal
is
not
to
change
our
ocd
but
to
create
a
new
crg
and
that
clg
lives
in
a
non-argosy
named
space,
but
produces
applications
in
argosy
name
space
and
it's
kind
of
I
maybe
I
can
at
least
disadvantages
of
that
approach
that
I
see
and
can
I
can
try
to
compare
it
to
young's
approach.
So
the
main
disadvantage
here
is
that
it's
not
first.
A
Basically,
it
requires
additional
installation,
like
users
would
have
to
opt
in
and
install
that
controller
into.
You
know
into
the
into
each
cluster
that
manage
argo
cd,
one
by
one
kind
of
in
every
cluster
and
ui.
There
will
be
no
ui
support
for
that
users
would
see
applications
created
by
appsource,
but
they
wouldn't
know
you
know.
Ui
would
not
give
any
hint
on.
Why
like
who
created
that
application.
E
A
Disadvantages
of
that
approach,
comparing
to
jan's
proposal,
because
in
this
in
case,
if
we
just
built
in
into
argo
cd,
mostly
we
can
have
you
know
ui
and
we
can
have,
and
it
just
requires
less
steps
to
to
install
it,
but
another
kind
of
basic.
What
I
think
advantages
of
that
approach
is
so
we
do
is
that
we
do
not
make
rbcd
code
more
complex,
it's
kind
of
it.
Let
us
this
approach,
let
us
separate
that
logic
into
a
separate
project,
and
it
has
one
more
important
advantage.
This
I
mean
using
that
controller.
B
Yeah,
but
maybe
but
maybe
it's
not
an
either
or
maybe
maybe
it's
you
know,
I
mean
the
app
source
controller
as
as
you
mentioned,
has
some
advantages
like
targeting
remote
clusters,
but
so
when
it
just
produces
like
application
crs
right
so
actually
yeah.
I
agree
they.
They
could
work
together
right.
So.
D
B
B
B
And
actually
so
the
the
changes
are
not
that
complex
in
that
we're
required
to
make
this
work
in
the
poc.
So
if
you,
if
you
look
at
the
at
the
pr,
I
mean
sure
there
are
lots
of
files
changed.
D
E
E
How
how
did
the
art
back
change
when
authorizing
like
applications
that
now
have
can
live
in
different
name
spaces
like
and
have
the
same
name.
E
B
That's,
that's.
That's!
That's
a
problem
I
haven't
solved
yet,
but
the
the
new
application
name
would
be
namespace
dash
application,
except
for
the
for
the
applications
that
exist
in
the
argo
cd
namespace.
They
can
be
referred
without
namespace,
but
everything
else
would
have
to
be
prefixed.
D
D
D
A
B
B
A
list
of
names,
so
it's
it's
a
list
of
namespaces
where
applications
are
allowed
to
be
created
in
in
order
to
associate
to
the
pro
into
the
project.
So.
A
And
I
feel
like
maybe
that's
the
main
difference
kind
of
from
from
a
user
perspective
between
app
source
and
and
applications
in
all
namespaces,
because
upsource
would
force
you
basically
in
absorb.
You
cannot
even
specify
which
namespace
you
want
to
deploy
to.
It
will
be,
as
you
know,
in
third
from
location
of
upsource
cr.
A
D
E
I
it
does
seem
actually
I
mean
I
have
to.
I
have
to
look
at
the
this
john's
proposal
a
little
closer,
but
I
think
it.
It
is
kind
of
trying
to
solve
the
self-service
where
users
want
to
create
eso.
B
E
B
So
the
the
use
case
or
the
the
original
use
case
behind
this
is
like
give
a
user
a
name
space
right
and
have
let
him
create
an
application
sierra
in
that
and
he
can.
He
can
create
his
his
own
or
her
own
ro,
cd
application
declaratively,
maybe
maybe
even
have
something
like
give
them
a
git
repository
where
they
can
store
an
application
cr,
and
this
gets
recoincided
by
another.
I
would
say
the
application
like
a
management
account.
B
A
I'm
curious,
let's
say
if
we
decide
to
build
upsource
approach,
but
basically
don't
create
it
as
a
labs
project,
and
you
know
just
supported
first
class
in
argo
cd.
Would
it
I'm
just
thinking
like?
Are
we
going?
Would
we
come
up
with
exact
same
design
like?
Do
you
think
it's
better
to
let
users
create
upsource
crs
in
their
namespaces
and
argo
cd
itself
should
notice
the
crs
and
infer
an
application
from
you
know
from
that
cr
kind
of
create
application
in
its
own
namespace,
based
on
apps
sources,.
F
B
E
Work
yeah,
you
won't
be
able
to
great,
so
the
app
source
doesn't
allow
you
to
select
the
project,
nor
does
it
allow
you
to
select
the
destination,
and
so
it
would
only
allow
you
to
to
play
in
the
namespace
in
which
the
app
squares
resides.
A
A
A
And
this
way
you
kind
of
solve
your
problem,
like
users
will
see
applications
and
they
still
have
ability
to
create
applications,
but
they
lose
flexibility.
They
won't
be
able
to
specify
destination
anymore.
Destination
must
be
named
space
of
an
absorption
yeah,
and
would
you
still
like
that
proposal
or
not
or
it
would
be.
B
I'm
not
quite
sure
if
so
maybe
we
we
even
try
to
solve
different
problems
right.
D
E
E
I
think
if
we-
the
we,
probably
don't
want
to
have
like
multiple
ways
to
accomplishing
the
same
use
case
if
if,
unless,
unless
they
have
certain
clear
advantages
to
doing
one
in
pros
and
cons,
but
so
far,
I
I
haven't
seen
a
big
enough
difference
between
the
two
approaches
to
I
think
justify
doing
both,
because
I
think
that
would
just
create
confusion
to
end
users
to
decide
what
is
the
right
way
to
achieve
their
use
case
for
self-service
when
I,
what
I
do
like
about
appsource
is
that
the
crd
spec
is
not
is
intentionally
restrictive
to
to
fit
into
the
model
of
the
the
the
self-service
that
we
were
aiming
for
and
that
like.
E
If
I
can
create
something
this
in
my
name
space,
I
can
only
affect
the
namespace
that
that
it
resides
in
and
so
the
the
the
same
problems.
I
think
you
were
trying
to
solve
with
the
project
kind
of
doing,
restricting
and
set
up
in
the
correct
way
and
then
not
allowing
them
to
we
would.
We
would
have
to
then
enhance
the
projects
to
enforce
that
restriction.
Those.
D
E
E
So
here's
here's
one
of
the
things
so
with
the
application
outside
argo
cd
namespace
would
a
project
have
to
be
created
by
an
admin
for
each
namespace
and
then
because,
basically
the
project
is
is
kind
of
like.
B
D
A
I
see
what
we
I
feel
like
honestly.
I
even
I
I
don't
have
still
strong
opinion,
but
I
guess
maybe
we
should
just
ask
users
and
come
up
with
a
comparison
in
you
know.
We
have
only
one
proposal
by
you,
so
we
can
add
that
comparison
here
and
just
ask
people
what.
Basically
there
is
with
upsource
it's
a
little.
Basically
they
don't
they
lose
ability
to
specify
destination
but
upsource.
A
Let
you
have
control,
plane,
argo
cd
and
basically
you
can
create
upsource
crs
in
a
target
clusters.
I
think
that's
kind
of
an
nn
and
then
we
maybe
should
ask
the
question
in
in
our
select
channel
and
ask
users
to
comment,
because
I
don't
see
any
other
way
to
yeah
to
me.
It's
like
just
different
way
to
implement
almost
the
same
thing
and
this
minor
difference
not
minor.
Maybe
for
some
users
it
could
be
a
big
difference
in
you
know
in
in
features
that
this
approach
has
provided
and
then
just
see
which.
A
E
Right,
but
I
also
I
the
reason
I
asked
about
the
projects
is
because
the
again
it
kind
of
relates
to
the
r
back.
So,
for
example,
if
they
do
go
to
the
same
project,
we
our
our
oidc
bindings,
are
actually
tied
to
projects
which
then
means
that
many
people
or
many
groups
would
be
in
the
same
project
being
able
to
sync
apps.
Unless
you
also
then
create
many,
many
role,
sorry
roles,
I
guess
one
role
per
name.
E
A
A
Config
controller
configuration
and
basically
it
relies
on
kubernetes
are
back,
so
we
kind
of
we
can
safely
assume
that
if
someone
created
appsource
in
a
namespace
we're
assuming
that
that
person
can
manage
that
namespace
and
then
upsource
administrator,
you
know
someone
who
has
admin
access
can
configure
a
convention
in
appsource,
controller
settings
and
convention
might
look
like.
Oh
if
you
notice
an
application
in
namespace.
A
That
looks
like
something
something
my
service
name:
production,
you're
supposed
to
create
a
project
called
my
service
and
on
the
fly,
add
namespace
whitelist
that
namespace
and
a
project
and
it's
safe,
because
we
are
assuming
that
if
person
have
permissions
to
create
upsource,
that
person
kind
of
proves
that
you
know
that
namespace
can
be
controlled
yeah.
So
that's
the
whole
idea.
It's.
E
Yeah
and
the
other
thing
that
the
right
right
now
I
I'm
kind
of
leaning
towards
apps,
my
preference
is
leaning
towards
appsource,
because
I
do
think
some
of
the
project
capabilities
that
we
we
may
want
to
allow
for
self-service.
In
fact,
some
of
like
today
with
argo
cd
there's,
some
parts
of
the
project
are
self-serviced
by
by
not
the
the
argosy,
the
administrator
meaning.
A
person,
for
example,
can
generate
tokens
as
long
as
they're.
E
A
member
of
the
the
the
oedc
group,
but
anyways
where
I
was
going
to,
is
that
the
app
source
crd
may
leave,
give
us
room
in
the
future
to
to
kind
of
give
more
permission
indirectly
through
the
crd,
that
that
might
not
be
possible
with
overloading
the
application
objects.
E
I'm
not
sure
if
that
might.
What
I
was
saying
came
through,
but
I
think
it
gives
us
more
flexibility
if
the
self-service
use
cases.
What
we're
trying
to
aim
for
with
the
app
source.
A
Too-
and
I
I
wanted
to
say
that
yeah
I
I
kind
of
just
the
disclaimer-
I
created
the
absorption,
it
was
kind
of
in
my
head
for
a
while,
and
I
didn't
really
I
was
not.
I
was
trying
to
build
it
and
could
not
complete
and
recently
in
our
team
we
have
an
intern
who
was
looking
for
something
to
work
on,
and
so
I
just
created
the
bare
minimum
description.
A
But
now,
if
we
you
know,
if
we
have
that
proposal-
and
we
really
want
to
compare,
I
think
I
feel
like
I
should
write
a
real
proposal
for
upsource
as
well
and
and
then
we
have,
you
know
kind
of
material
to
compare.
So
I
will
do
it.
I
will
convert
the
ticket
and
you
know
just
provide
more
details
in
the
proposal.
E
Okay
yeah-
this
is
this-
is
something
red
hat
users
are
also
asking
for
right.
Is
that
the
case.
B
But
yeah,
I
think
this
this
the
one
for
for
this
is
is
much
older
right.
I
think
I've
I've
heard
people
complaining
about
that
since,
since
I
started
with
the
community
so.
A
B
A
A
A
A
B
B
A
Using
the
using
the
meeting
for
you
know
to
try
ash
hash
incoming
feature
requests,
and
we
basically
don't
have
time
to
do
it
today,
all
right-
and
I
guess
next
time
maybe
we
should
do
it
first
and
then
move
to
to
the
topics
yeah.
A
William's
turn
it's
supposed
to
be
william,
william,
are
you
fine
to
do
it
for
next
week.
A
A
F
Yep
yeah
because
we
have,
because
we
have
some
seven
to
eight
minutes.
I
just
wanted
to
talk
about
that.
I
mean
long
back.
We
discussed
about
a
a
new
logging
package
for
argo
cd.
I
think
I'll
come
up
with
further
details
in
the
next
meeting,
but
we
were
discussing
about
issues
with
loggers.
I
mean
currently
we're
using
loggers,
and
many
people
complained
about
about
the
augustine.
F
Logging,
everything
to
std,
airlocks
error
logs,
so
yeah,
probably
I'll,
come
up
with
more
information
in
the
next
week.
But
I
thought
is:
is
there
some
discussion
that
or
is
it
some
something
that
somebody
else
is
also
thinking
about
or
any
idea
about
it.
A
D
F
Yeah
and
yeah-
probably
I
can-
I
can
put
next
yeah-
probably
I
can
put
more
context
so.
The
issue
that
many
people
have
reported
is
that
I
think
we
have
two
to
three
issues
on
argo
cd
where
people
were
asking
about.
F
They
are
using
some
kind
of
log
monitoring
tools
and
argo
cd
puts
all
of
the
logs
into
the
stda
error
stream
so
that
when
they
look
the
argo
cd
logs
in
their
monitoring
tools,
they
see
everything
in
the
std
error
and
they
do
not
see
anything
in
the
htd
info
or
something.
And
the
reason
for
this
is
we
are
using
loggers
and
they
did
not
want
to,
and
they
do
not
want
to,
even
in
future
make
an
enhancement
that
the
logs
would
move
to
different
streams.
F
So
I
I
try
to
spend
some
time
on
this
and
see
if
we
can
do
it.
But
when
I
try
to
write
a
hook
on
top
of
a
log
grass,
it
seems
that
it's
I
mean
it's
creating
some
kind
of
additional
time
for
agassi
to
process
all
those
things
so
just
wondering
if
we
should
look
at
a
new
package
or
we
should
look
at
the
hooks.
E
Easily,
allow
you
to
change
the
the
output
stream
to
to
something
else.
B
A
Look
for
an
alternative
maintenance
project
and
I'm
kind
of
maybe
I'm
not
suggesting
we
do
it,
but
since
it's
in
maintenance,
it's
safe
to
fork
it
and
do
whatever
we
want
in
the
fork.
It's
another
option,
because
if
it's
in
maintenance
mode,
that
means
you
know,
we
won't
have
to
upgrade
it
anytime
soon
and
we
can
just
as
a
stopgap.
We
can
change
how
you
know.
D
F
A
F
I
think
I
think
only
for
somebody
who
are
completely,
I
mean
someone
who
completely
relies
on
their
monitoring
tools
to
understand.
What's
going
wrong,
only
for
such
people.
E
F
B
Yeah,
so
you
you,
can
you
can
you,
can
you
can
change
the
the
default
output
stream
right?
But
you
you
can't
separate,
like
on
a
lock
level
basis.
E
Oh,
oh
okay,
I
understand
so
the
ask
is
that
we
log
most
of
this
or
everything
to
like
standard
out,
but
then
only
errors
go
to
standard
there.
Yes,
okay.
I
understand
that
like
yeah,
I
don't
I
don't
know
if
progress
supports
that,
but.
F
Yeah
so
so
I
I
spent
some
time
long
time
back
and
then
people
keep
tagging
on
that
issue
and
asking
for
the
progress.
So
I
thought
okay
I'll
spend
some
time
next
week
and
I'll
bring
this
topic
but
yeah,
because
we
had
some
five
six
minutes.
So
I
just
thought
I'd
set.
E
C
A
And
we
might
have
a
candidate
already.
There
is,
I
think,
project
called
k.
Look
and
basically
we
had
so
the
idea
of
the
project.
It's
like
an
interface
that
has
adapters
to
other
logging
solutions
and
we
had
to
use
it
in
github's
engine
because
you
know
gitlab,
they
didn't
like
bluegrass
either
and
they
asked
to
remove
it
and
replace
it
with.
I
think
it's
called
k
log.
Basically,
we
can
find
that
detail
in
in
github's
engine
itself
and
k.
Log
is
under
the
kubernetes.
F
I
think
and
jan
posted
that
that
statement
from
logarithms.
A
A
F
Api
yeah,
probably
I'll,
come
up
with
some
comparison.
Comparisons
of
different
things
that
are
available
by
next
week.