►
From YouTube: Argo Contributor Experience Office Hour 10th Dec 2020
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
A
That's
not
a
group
where
we
go
and
write
code
or
discuss
code.
That's
more
of
a
group
work
group
to
discuss
best
practices
across
tools.
That
starts
exactly
one
hour
before
this
one.
So
folks
are
pretty
much
joining
over
from
that
meeting
to
those
who
went
there
I'll
ensure
everyone,
at
least
in
red
hat,
has
an
invite
to
that
and
the
other
folks
as
well,
and
to
to
kind
of
move
from
there
to
what
we
would
be
discussing
today.
A
Is
that
so
we've
been
discussing
for
a
while
about
application
sets,
and
I
think
it's
a
good
time
for
us
to
start
considering
moving
application,
sets
into
argo,
cd
and
design
and
trying
to
try
to
see
what
that
first
class
delivery
or
release
of
application
sets
with
argo
city
would
look
like
we
may
come
up
with
the
time
frame
later
on,
I
think,
alex
and
jesse.
A
We
need
to
also
figure
out
that
if
we
want
to
talk
about
our
cargo
city
graduating
whether
it's
a
good
time
to
edit
now
or
later,
but
I
think
that's
a
different
conversation
so
yeah,
I
think
we'll
talk
about
application
sets
jonathan.
It
would
be
awesome
if
you
could
give
a
five-minute
introduction
of
application,
sets
in
general
kind
of
the
same
one
which
you
gave
to
folks
internally
as
well.
B
A
Do
awesome
so
if,
if
you
could
do
that
in
the
context
of
argo
cd,
if
you
could
introduce
application
sets
as
a
project
what
it
does
from
a
user
perspective,
and
then
we
could
go
ahead
and
talk
about
what
would
it
mean
to
bring
application
sets
into
argo
cd,
both
from
a
ui
perspective,
from
a
release?
Delivery
perspective
from
code
testing
perspective
everything
else,
we
can
have
the
discussion
on
that.
B
A
Yep
and
a
quick
thing
before
we
start
just
as
a
usual
tradition.
If
there
are
newer
folks,
we
do
an
introduction.
We
have
serena
on
the
call
from
red
hat.
Do
you
want
to
go
ahead
and
introduce
yourself
to
the
team.
C
Hey
sure
hi,
my
name
is
serena
nichols,
I'm
I've
been
at
red
hat,
for
I
don't
know
about
six
years,
and
I
have
had
my
background
is
actually
in
development,
ux
and
product
management.
So
I'm
joining
I'm
joining
these
calls
to
kind
of
look
at
this
more
of
a
from
the
user
experience
side.
I
think,
as
well
as
the
fact
of
how
things
end
up
fitting
into
openshift,
just
in
my
own
mind
going
forward
so
but
I'd
love
to
to
be
able
to
help
with
any
ux
related
comments,
questions
etc.
A
B
So,
let's
jump
to
here
so
yeah,
I
thought
I'd
start
out
by
giving
a
brief
introduction
to
application
sets,
for
those
that
are
unfamiliar
application
sets
is
a
currently
an
independent
project
from
argo
cd.
B
It
exists
in
the
argo
proj
labs
application
set
repo,
so
argo
project
labs
is
kind
of
the
incubator
organization
for
argo
targeted
projects,
an
application
set
is
one
of
those
projects.
It's
worked
been
worked
on
by
a
few
folks
in
the
community
and
essentially
it's
a
custom
controller
that
allows
you
to
target
argo
cd
applications
so
I'll
go
into
that
in
a
second,
but
everything
that
I'm
about
to
talk
about
you
can
find
in
the
really
nice
proposal
that
they
put
up
in
the
argo
cd
application
set
repo.
B
So
if
you're
looking
for
more
detail
than
the
brief
introduction
that
I
go
through
here,
definitely
check
out
this
proposal
in
the
application
set
repo,
which
goes
into
some
of
the
scenarios
that
we're
looking
to
support
some
of
the
design
decisions,
desired
features
and,
and
so
on.
B
So,
let's
start
out
by
looking
at
an
argo
cd
application.
This
is
the
standard
argo
cd
cr
that
we're
all
familiar
with.
It
allows
you
to
map
a
git
repository
so
in
this
pla.
In
this
case
the
standard,
argo
cd
example
repo
targeting
a
specific
revision,
so
just
head
targeting
a
specific
path
in
that
repository
guest
book.
In
this
case,
just
using
the
standard
cd
example
guest
book
and
well,
this
is
git
ops.
So
our
goal
is
to
take
kubernetes
resources
from
git
and
map
it
to
kubernetes.
B
Where
are
we
going
to
map
it?
We're
going
to
map
it
to
the
destination?
That's
specified
in
the
argo
cd
application
definition.
So
it's
going
to
my
local
kubernetes
cluster
in
the
guestbook
name
space.
But
one
thing
to
note
is
that
there's
really
only
a
single
destination
here
specified
and
a
single
source
specified.
B
So
that's
that's
that
design
constraint
of
the
argo
ce
application
is
kind
of
what
application
set
has
been
designed
to
help
solve.
The
proposal
that
I
talked
about
actually
addresses
a
couple
of
use.
Cases
that
are
best
that
are
a
great
fit
for
application
sets.
B
One
is
the
so-called
cluster
add-on
scenario
where
a
operator
a
cluster
infrastructure
manager
wants
to
deploy,
say
something
like
argo,
workflows
or
prometheus
operator,
the
kubernetes
resources
for
that
customize,
helm,
etc
defined
within
a
single
git
repository,
but
they
want
to
target
a
bunch
of
different
clusters
all
at
once.
So,
let's
say
as
an
organization,
they're
managing
say,
50
clusters,
100
clusters-
they
don't
want
to
have
to
go
in
and
create
and
maintain
a
bunch
of
different
argo
cd
application
crs
in
a
git
repository
using
something
like
the
app
of
apps
pattern.
B
B
Apps
workflows
and
prometheus
and
then
all
the
destination
clusters
that
they
want
to
deploy
to.
B
So
that's
the
cluster
add-on
scenario
where
you're
targeting
where
it's
kind
of
like
a
one-to-many
between
a
bunch
of
different
clusters,
the
other
that
the
application
set
proposal
goes
into
is
improving
mono
repos,
so
having
a
single
kubernetes
cluster
that
is
managed
entirely
by
a
single
git
repository
as
the
proposal
notes.
That's
the
primary
mode
of
operation
of
flux,
cd
and
this
would
an
application
set-
would
make
this
scenario
significantly
easier.
B
So
I'll
jump
to
the
actual
solution
as
proposed.
This
is
probably
there's
a
few
different
generators
which
are
ways
to
configure
what
is
actually
being
targeted
at
the
kubernetes
repo,
but
I'll
start
with
the
simplest
one
here
this
is
the
list
generator.
B
B
So
we've
got
a
repo,
you
know:
what
are
we
deploying
we're
deploying
stuff
from
this
git
repository
this
branch
or
tag
under
that
git
repository?
What
specific
path?
Well,
that's
the
guest
book
and
what
destination
well.
Here
we
start
to
see
that
it
looks
a
little
different
than
the
argo
cd
example.
I
showed
you
before
because
now
there's
this
parameter,
parameterized
url
value
here
and
then
there's
a
couple
others
here
and
here
so
the
argo
cd
application
cr
does
not
have
parameterized
values.
B
This
is
new
to
or
at
least
in
this
form
this
is
new
to
application
sets
and
what
this
parameterized
value
means
is
go
through.
What
is,
in
the
generator,
take
the
values
that
are
generated
by
the
generator
and
insert
those
values
into
the
templates
that
are
defined
in
the
template
section
of
the
application
set
cr.
B
So
in
this
case,
as
part
of
destination,
we're
targeting
a
server,
so
that
would
be
a
kubernetes
server
and
it's
parameterized.
So
we
need
to
fill
in
a
value
from
that.
So
what
application
set
is
going
to
do
is
pull
up
the
cr
it's
going
to
go
through
each
of
the
items
that
are
defined
here
and
one
by
one
turn
these
into
an
array
of
values
or
parameters
that
are
going
to
be
substituted
into
the
template.
So,
as
you
can
guess,
we're
targeting
three
different
clusters
made
up
ip
addresses.
B
Obviously,
unless
you
haven't
downloaded
them
so
engineering,
dev
engineering,
prod
finance,
prod
the
application
set
controller
is
then
going
to
create
an
argo
cd
application
one
for
each
of
these
sets
of
values
in
this
form
for
argo
cd
to
use.
So
I
don't
have
the
demo
set
up,
but
if
you
were
in
the
argo
cd
ui
and
you
created
this
application
set
cr,
you
would
now
see
three
different
argo
cd
applications
in
the
application
view
each
looking
like
this
for
the
most
part,
but
with
the
parameterized
fields,
fields
substituted.
B
So
essentially
this
allows
you
to
say
target
a
bunch
of
different
clusters
target
a
single
application
or
multiple,
but
this
specific
application
is
single,
a
single
application
against
a
bunch
of
different
clusters
by
only
defining
a
single
kubernetes
resource.
This
application
set
resource
so
adding
more
clusters
or
removing
existing
clusters
is
just
a
matter
of
adding
or
removing
items
from
this
item
list
here.
B
Yeah,
so
behind
the
scenes
it
works.
The
same
way
these
this
controller,
its
sole
purpose,
is
to
create
and
delete
the
argo,
cd
application
cr.
B
So
from
there
the
creation
or
deletion
of
the
application
cr
is
going
to
be
handled
by
the
argo
cd
application
controller,
so
application
cell
set
doesn't
do
anything
beyond
a
pen
beyond
create
edit
or
delete
argo
cd
or
go
cd
application
resource
from
there.
It's
up
to
argo
cd
to
handle
the
deletion,
recursively
or
otherwise.
E
B
Yeah,
it
adds
a
finalizer,
that's
the
current
behavior
good.
Thank
you.
B
So
that's
the
list
generator.
That's
the
probably
the
easiest
to
follow.
There's
a
couple
other
there's
a
cluster
generator
which,
rather
than
using
a
list
of
items,
that's
defined
in
the
application
cr.
It
has
the
ability
to
actually
look
at
the
clusters
that
are
defined
as
secrets
in
the
argo
cd
namespace
and
target
those
with
an
additional
filter-
that's
not
shown
here,
but
with
an
additional
filter
value
in
the
clusters
field
that
allows
you
to
further
further
target.
B
What's
what's
going
to
be,
I
have
resources
applied
to
it
and
then
finally,
there's
the
git
generator,
which
is
definitely
the
most
complex
and
also
the
most
interesting
of
the
three
generators.
B
In
this
case,
this
would
be
put
in
place
to
handle
something
like
the
monorepo
use
case
where
you
want
to
display,
or
you
want
to
deploy
a
bunch
of
different
applications
to
a
single
kubernetes
cluster.
What
this
is
saying
is:
okay.
Look
in
this
repository,
go
through
all
of
the
directories
under
add-ons
within
this
repository
that
meet
this
glob
and
for
each
one.
That's
found
use
that
as
a
value
into
the
template
for
the
applications
that
are
going
to
be
created
by
the
application
set
controller.
B
B
So
this
allows
you
to
once
again
with
a
single
cr
target,
a
kubernetes
cluster,
but
define
a
bunch
of
different
applications
again
against
it.
So
if
you
wanted
to
add
a
new
application
or
you
wanted
to
remove
an
existing
application,
it
would
just
be
a
matter
of
well,
you
wouldn't
even
have
to
edit
the
cr.
In
this
case,
it
would
just
be
a
matter
of
making
a
change
to
this
source
repository.
An
application
set
would
detect
that
and
then
make
the
required
changes
to
the
generated
argo
cd
applications.
B
Yeah,
so
that's
application
sets
as
it
exists.
In
a
nutshell,
like
I
said,
everything
is
defined
in
the
proposal.
Documents
that's
linked
on
the
repo
it's
nice
and
long
with
lots
of
detail,
so
definitely
check
that
out.
If
you're
interested
in
what
some
of
the
requirements
were
for
application
set
when
it
was
first
created
and
where
folks
have
said
they
want
to
see
it
go
in
the
future.
B
Any
questions
before
I
jump
into
talking
about
how
we
can
integrate
it
with
our
ocd.
F
Question
when
you
say
you
refer
to
the
part
or
base
name,
are
you
just
referring
to
a
bunch
of
customization.yaml
files
and
then
it
looks
into
the
base
and
then
pulls
out
the
name
from
there
or.
B
B
Yeah,
it
would
depend
on
which
resource
definition
tool,
the
or
resource
tool
the
user
was
using.
So
it
could
be
helm,
it
could
be
customized,
it
could
be
jsonet,
it
could
just
be
a
directory
of
kubernetes
manifests.
B
We
definitely
need
more
tests
to
verify
that
each
of
those
work
as
expected
with
application
sets,
but
behind
the
scenes
it
is
using
the
argo
cd
repo
server
to
pull
the
applications
from
a
repository.
So
the
logic
should
be
the
same
between
what
application
sets
is
seeing
and
what
argo
cd
repo
server
is
seeing.
F
D
So
I
don't
have
a
question,
but
I
wanted
to
say
just
a
quick
thank
you
for
this
presentation
on
application
set,
because
I
was
just
you
know.
I
was
not
really
following
what
the
project
is
doing
and
I
always
had
a
hard
time
understanding
what
it
is
doing,
and
so
this
was
very,
very
useful
introduction.
It
was
very
valuable.
Thank
you.
B
Awesome
yeah.
I
thought
you
did
a
really
good
job
with
the
presentation.
Thanks
awesome
were
there
any
other
questions
before
I
jump
into
what's
on
the
screen.
E
B
Yeah,
so
the
design
proposal
does
not
attempt
to
join
generators.
You
can
specify
multiple
generator
types
and
it
should
handle
them
properly.
Although
I
don't
know
if
there
are
any
tests
that
actually
verify
that,
but
when
you
do
specify
multiple
generators
together
in
the
same
cr,
the
values
are
kept
entirely
separate.
It's
just
additional
values
that
are
added
to
the
to
the
array.
There's
no
attempt
to
merge
or
join
those
values
that
doesn't
mean
that
it
couldn't
be
done.
It's
just.
It
hasn't
been
thought
through
on
the
proposal,
yet.
E
Okay-
and
the
reason
I
ask
about
it-
is
because
the
example
which
you've
shown
it
kind
of
lead
me
to
idea
that
maybe
we
want
to
kind
of
multiply
outputs
or
two
generators,
because
in
the
in
the
first
example,
we
have
generators
that
create
clusters
and
second
create
addons,
and
basically,
I
think
the
real
use
case
in
this
case
is
you
want
to
install
all
addons
from
the
repo
into
all
the
clusters,
so
you
want
kind
of
multiplication
of
cool.
Thank
you
absolutely.
B
Yeah
and
it's
and
I
think
the
when
they
put
the
proposal
together,
the
focus
was
on
defining
an
initial
set
of
requirements,
getting
those
set
in
stone
and
implemented
and
there's
definitely
lots
of
room
for
future
work
such
as
that,
and
I
believe,
even
that
specific
work
requirement
is
documented
as
future
work
within
the
proposal.
So
it's
definitely
thought
something
that
the
proposal
implementers
and
writers
discussed
and
yeah.
I
agree.
It
definitely
sounds
useful.
B
Cool,
so
I've
talked
about
what
the
application
set.
Cr
is
what
it
does
it's
a
controller
for
kubernetes.
So
it
sounds
like
we
are
interested
in
integrating
the
application
set
controller
proper
into
the
argo
cd
project.
So.
A
Jonathan,
if,
if
we
could,
if
he
could
take
a
pause
on
alex
jesse
or
somebody
one
of
the
maintainers,
if
you
could
go
over
what
your
expectations
with
respect
to
this
would
be
just
to
set
a
level
playing
field
for
the
whole
conversation.
And
then
we
can
get
back
to
this.
A
Think
in
yeah
I
mean,
I
think,
the
how
needs
to
be
figured
out,
but
I
would
say,
as
a
destination
of
the
whole
thing
like
when
we
started
argo
cd,
we
didn't
have
application
sets
now
that
we
have
it.
Where
do
you
see
it
going
from
your
perspective,
and
then
we
can
get
into
details
here?
That's
what
I'm
kind
of
looking
for.
H
H
So,
as
you
know,
we
have,
I
think,
we're
approaching
like
300
clusters
that
we
need
to
to
manage
and
right
now
we
have
a
like
several
different
ways.
People
are
doing
add-ons
in
there.
One
is
an
add-on
that
is
just
part
of
our
distribution,
so
to
speak.
So
when
we
do
a
new
release
of
our
kubernetes
clusters,
there
is
a
pre-canned
add-on.
That
is
just
that
version
is
tied
to
that
kubernetes
release
that
we
deployed
that's
very
inflexible.
H
H
Yeah
yeah
add-on
is
like
like
prometheus
operator
or
like
alb,
ingress
controller
or
argo
rollouts
or
argo
workflows
like
basically
something
like
you,
typically
they're.
Okay,.
A
H
Yeah
so
yeah
they're
kind
of
like
part
of
our
what
part
of
our
distribution
of
what
right
cluster
is.
So
so
that's
one
way
we
deploy.
H
So
the
the
problem
with
that
approach
is
that
it's
it's
very
tightly
coupled
to
the
release
of
the
kubernetes
distribution
that
we
do
so,
let's
say
we
roll
out
a
new
alb
ingress
controller
in
order
to
in
that
version
is,
is
not
great,
then,
in
order
to
roll
back,
we
have
to
you
know,
do
another
iks,
release
or
sorry
another
cabrini
distribution
release
and
then,
and
then
that
so
you're
locked
kind
of
locked
to
the
release
cycle
of
the
kubernetes
distribution
that
we
we
provide,
but
as
a
add-on
maintainer
like
as
like,
for
example,
I
work
on
rollouts.
H
Currently
I
would
like
to
release
like
at
my
own
cadence
and
on
disconnected
from
the
release
of
the
kubernetes
distribution.
So
I
need
to
you
know,
deploy
to
hundreds
of
clusters
at
my
own
cadence
and
and
have
the
ability
to
roll
back
if
necessary,
so
the
use
cases,
at
least
for
the
multi-cluster
one
is
to,
and
currently
it's
it's
I
script
a
lot
of
that.
So
I
threw
it
up
so
in
a
single
git
repo.
H
I
have
many
different
folders,
for
you
know
different
clusters,
and
so
I
would
abset
was
born
out
of
the
need
to
try
to
automate
that
somehow
and
formalize
it
into
like
a
spec
and
different
people
have
different
ways
of
automating,
and
this
is
trying
to
solve
that.
B
E
Got
it
I
wanted
to
just
quickly
mention
one
more
kind
of
use
case
for
upset,
and
this
is
more
interesting
for
application
developers
and
rvcg
administrators.
E
So
if
you
have
argo
cd
that
manages
hundreds
of
apps
and
used
by
like
a
dozen
of
teams,
then
configuration
of
hardware,
cd
itself
became
kind
of
an
asset,
and
you
want
to
store
it
some
somewhere
and
and
maybe
make
it
a
little
bit
more
serious
and
let
people
create
application
without
asking
administrator
to
you
know,
make
changes
in
urban
cj
so
and
right
now
there
are
just
two
ways
to
do
it
pretty
much
one.
E
Is
you
build
some
kind
of
automation
on
top
of
argo
cd
that
uses
circuit
cd
api
to
manage
it?
This
is
what
we
did
at
intuit.
So
we
have
some
so-called
dev
portal
and
dev
portal
kind
of
is
a
source
of
true
of
application,
so
it
has
its
own
database
and
basically,
it
creates
applications
using
its
own
logic.
E
That's
one
way
and
another
way
is
fully
declarative
management
of
argo
cd,
so
you
can
have
a
repository
which
has
a
bunch
of
fibo
cd
applications
and
config
maps,
and
all
that-
and
it's
like
these-
are
two
extremes.
Basically,
you
either
do
everything
by
hand
or
you
build
a
whole.
You
know
application
to
manage
ocd,
and
I
think
application
set
is
kind
of
middle
ground,
so
administrator
can
define
pretty
much
a
rule.
How
applications
are
created
using
website,
cld
and
then
the
users
to
use
it,
and
you
don't
have
to
build.
D
E
The
idea
was
that
you
know
generators
can
implement
like
real
use
cases,
how
you
can
manage
applications,
so
you
might
so
no
use
case.
The
real
convention
that
you
know
can
work
in
your
organization.
So
the
simplest
example.
You
can
say
my
developers
can
they
have
access
to
the
depot
they
can't
create
folders
without
asking
me
and
application
set,
is
configured
to
trust
that
repository
basically,
and
you
can
trust
some
particular
repository,
because
the
application.
B
E
Is
configured
to
create
application
and
deploy
these
applications
only
to
a
certain
cluster?
So
if
you
have
team
and
the
team
is
responsible
for
cluster
and
you
have
application
set
that
pull
applications
from
predefined
repo
and
deploy
into
the
cluster,
then
you
kind
of
done
you,
you
don't
have
to
worry
about
it
and
you
don't
have
to
as
an
argo.
E
To
be
honest,
I
would
I
mean
even
what
we
have
now
like
a
lot
of
effort
was
put
in
in
into
it
to
implement
it,
and
it
was
not
easy
at
all
so
and
it's
still
like
not
perfect.
Sometimes
we
as
our
city
administrator,
you
have
to
go
and
fix
something.
You
know
in
rbc
configuration
which
maybe
didn't
work
didn't
end
smoothly.
B
Cool,
so
the
question
then
becomes
so
we
agree
that
there
is
a
need
for
application
set,
how
application
set
should
work
has
been
well
defined
in
the
proposal
folks
have
gone
and
implemented
begun
to
implement
and
implemented
that
proposal.
B
The
generators
that
I
talked
about
the
list,
the
cluster
and
git,
which
should
cover
a
number
of
the
use
cases
that
are
included
in
the
proposal.
B
So
we
may
feel
at
this
point
that
it's
at
a
good
place
where
it
can
be
integrated
with
the
argo
cd
project
itself,
so
rather
than
the
source
code
living
in
the
application
set
repo,
as
as
like
an
incubator
project,
it
would
instead
be
included
with
the
argo
cd
project.
Proper
and
source
code
would
live
in
there
and
application
set
controller
would
be
deployed
as
part
of
a
standard.
B
Argo
cd
install
that's
about
I'm
gonna,
go
into
the
the
details
of
how
we
get
there,
but
that's
about
what
this
proposal
is
proposing.
It's
saying,
okay,
application
sets,
we
know,
there's
a
need.
We
know
that
it's
at
a
good
level
of
maturity,
but
there's
still
more
work
to
be
done.
So,
let's
discuss
what
it
would
take
to
move
it
into
the
argo
cd
project
itself,
the
source
code
and
the
functionality
that
the
kubernetes
resources
and
so
on.
A
My
my
only
question
there
would
be
that
we
should
also
discuss
multiple
parts
at
the
top
of
the
tree,
which
is
we
either
physically
move
things
or
import
that
as
a
controller
or
we
don't
move
make
any
movements
at
all.
We
just
you
know,
release
payload
also
include
the
app
sets
so
yeah.
I
think
if
you
could
just
go
over,
which
ones
you're
going
to
consider
now,
which
ones
could
be
a
later
discussion.
That
would
be
awesome
as
well.
B
Yep
sounds
good,
so
in
terms
of
how
to
say
were
there
any
other
questions
or
thoughts
before
I
jumped
into
the
nitty-gritty
details.
B
Cool,
so
it
then
becomes
a
question
of
from
a
technical
perspective.
How
do
we
move
the
code?
That's
in
the
application
set
repo
and
the
controller
itself
into
our
go
cd,
so
I've
kind
of
laid
out
a
set
of
steps
here,
they're
very
detailed.
I
would
say:
don't
let
the
level
of
detail
make
you
think
that
anything
is
set
in
stone.
B
I
find
it
personally
beneficial
to
kind
of
go
into
this
kind
of
detail
for
each
step
in
a
process
to
make
sure
that
I
fully
consider
the
software
engineering
details,
but
that
doesn't
mean
that,
like
this
is
the
way
it
will
be
done.
Think
of
what
I'm
proposing
here
and
this
document
in
general,
as
more
of
a
set
of
proposed
questions
or
discussion,
points
or
ways
to
query
requirements
or
options
that
are
in
our
collective
heads,
so
I'll
start
out
with
probably
what
would
be
required.
B
B
We
obviously
would
need
to
fix
any
lint
errors
using
the
same
rule
set
as
argo
cds.
Add
a
github
action
to
enforce
that.
That's
poor
request,
63
waiting
for
review
add
a
go
test
action.
We
don't.
B
We
want
to
catch
any
regressions
and
probably,
most
importantly,
if
we're
going
to
be
integrating
it
with
the
argo
cd
code
base,
we
need
to
reorganize
the
code
packages
in
such
a
way
that,
when
the
source
code
does
move
that
it
fits
nicely
within
the
existing
source
code
format,
that's
already
in
argo
cd,
so
probably
very
similar
to
the
way
the
components
are
already
defined
in
argo
cd.
So
the
application
controller
is
separate
from
the
so
that
the
api
server
separate
from
the
application
controller
is
separate
from
the
repo
server
something
along
those
lines.
B
B
Are
we
going
to
say
should
be
in
place
before
we
move
it
into
argo,
cd,
proper,
so
what's
currently
implemented
in
argo?
Cd
is
the
three
generators
that
I
showed
you,
that
was
cluster,
which
looks
at
the
argo
cd
secrets
that
are
defined
in
order
to
find
which
clusters
are
to
be
targeted.
B
So
that's
all
in
it
has
unit
tests,
for
it
there's
still
some
additional
functionality
in
the
proposal
that
is
in
progress.
That's
poor
request,
45,
which
implements
the
git
files
discovery,
which
is
probably
the
most
powerful
of
the
generators
to
be
implemented.
That's
still
in
progress,
so
as
kind
of
an
open
question.
B
We
have
the
option
of
waiting
for
that
to
be
finished
before
we
integrate
it
with
argo
cd
or
in
general.
If
there
is
functionality
that
we
would
like
to
see
or
like
a
minimum
level
of
functionality
that
that
that
our
minimum
maturity
level
for
that
functionality,
that
we
would
like
to
see-
and
that's
definitely
something
that
we
should
talk
about
at
this
stage,
my
personal.
H
H
A
question
the:
how
much
dependency
is
the
repo
server
currently
with
upsets
like,
for
example,
the
git
generator.
I
would
imagine,
needs
a
lot
of
functionality
from
the
repo
server
to
accomplish
its
generator.
So.
B
At
present,
it
calls
it
through
our
pc,
just
like
the
other
components
and
the
only
api
method
that
it's
calling
is
getpath
getpads
that
is
used
by
git
directory.
Now,
when
git
files
discovery
is
implemented,
that's
the
one
with
the
outstanding
pull
request
there
at.
I
actually
have
it
here
at
president.
What
they're
doing
is
just
calling
argo
cds,
I
think
slash
util
slash,
get
functionality
directly,
which
behind
the
scenes
is
a
combination
of
I
think,
goget
and
actually
calling
the
git
cli
directly
and
so
they're
doing
something
similar.
B
So
right
now,
portal
request
45
does
that,
but
what
we
would
need
to
do
is
implement
a
new
api
for
repo
server
that
handles
that,
rather
than
just
calling
the
git
cli.
B
Yeah,
so
in
terms
of
what
proposal
items
we
want
to
handle
at
this
stage,
my
take
is
that
it
sounds
like
folks
are
already
using
application
set
controller
in
their
environments,
which
is
a
testament
to
the
level
of
functionality.
That's
currently
there,
so
I
don't
think
there's
any
specific
functionality
that
would
block
integration.
If
anybody
has
any
differing
viewpoints,
it
would
be
good
to
share
them.
B
The
other
thing
that
I
would
note
in
terms
of
functionality
that
remains
one
open
question
for
us
is
essentially
once
application
sets
set.
Controller
is
running
as
part
of
a
standard
argos
td
install
where,
in
that
standard
standard,
argo
cd
install
will
be
running.
Would
we
integrate
the
application
set
controller
alongside
the
application,
cd
application
controller,
so
we
would
live
in
that
same
container
in
stateful
set,
or
would
it
just
be
an
independent
container
and
deployment
like
some
of
the
other
components
that
are
as
part
of
argo
cd?
B
So
this
one-
I
imagine
there
are
probably
more
opinions
on
my
personal
take
is
at
this
point
it's
probably
easiest
to
keep
it
separate,
so
just
creating
a
new
deployment
resource
that
whose
sole
purpose
is
to
run
the
application
set
controller
and
then
once
we've
finished
the
integration
to
consider
integrating.
B
Yeah,
so
essentially
that's
what
I'm
proposing
here,
keep
it
separate
for
now.
I
could
maybe
either
way
that
we
could
implement
it
with
the
application
controller.
Their
advantage
is
doing
that
there
are
trade-offs,
doing
it
likewise
for
keeping
it
separate.
So
at
this
point,
I'm
saying,
since
there
are
already
a
number
of
moving
parts
here,
it's
best
to
keep
that
particular
moving
part
frozen
and
then
to
consider
it
at
a
later
stage
once
everything
else
is
in
place.
B
By
the
way,
I've
shared
this
google
doc
in
the
agenda
and
it
is
like
a
standard,
google
doc,
so
feel
free
to
add
review
comments
on
the
side.
I
have
them
turned
off
at
the
moment.
Just
so
I
can
give
you
a
clear
picture,
but
here
or
in
slack
or
on
any
of
the
issues
in
applications
at
repo.
We
can
definitely
have
further
conversations
on
this.
B
So
we've
looked
at
quality
of
life,
improvements
to
the
source
we've
looked
at
what
functionality
remains
to
be
implemented,
so
next
up
is
testing
about
what
you'd
expect.
There
are
already
unit
tests
in
the
application
set
repo.
So
just
look
at
those
and
see
if
there
are
any
big
gaps
that
we
want
to
fill.
B
One
thing
that
the
application
set
repo
didn't
have
was
a
kind
of
ete
test
framework,
similar
to
the
way
that
argo
cd
handles
ete.
So
I
implemented
that
that's
pr66
and
if
you're
familiar
with
dargo
cd's
ede,
it
looks
exactly
the
same.
It's
essentially
the
same
api
context,
transition
with
when
to
actions
which
transition
with
then
the
consequences,
and
then
you
have
your
expects
and
so
on.
So
if
you're,
if
you've
written
argo
cd
to
e-tests
you'll,
find
the
exact
same
api
here,
so
that's
pro
request.
B
66
feel
free
to
jump
on
that.
If
you
want
to
see
how
that's
done
or
want
to
provide
feedback
on
implementation
details
once
that's
merged,
it
would
be
great
to
have
a
github
action
that
runs.
Those
I've
already
got
one
as
part
of
the
pull
request,
also
based
on
the
exact
same
way
that
argo
cd
is
doing
it
embedding
k3s
as
a
installing
k3s
as
part
of
a
github
action,
starting
up,
argo,
cd,
ete
and
then
starting
up
applications
at
ete
and
then
running
through
a
set
of
application
tests.
B
E
B
D
B
And
yeah
that
would
definitely
inform
to
what
degree
the
unit
tests
are
testing
the
functionality.
That's
in
there.
B
Okay,
so
that's
testing.
Next
up
is
the
final
stage
before
it
actually
gets
implemented
with
argo
cd,
proper,
simple
step
I'll
make
sure
that
absence
go
mod
is
equivalent
to
argo
cds.
B
So,
at
this
point
dealing
with
the
argo
cd
code
move
the
app
set
code
into
it.
Add
the
crds,
but
keep
them
separate
in
staging
update.
The
docker
file
add
feature
flags
to
a
set
code.
I'll
talk
about
that
in
a
second
ensure
it
builds
and
basically
do
everything
that
we
can
inside
the
standalone
pr
inside
the
standalone
branch
to
get
the
arc
ocd
plus
application
set
code
in
such
a
state
that
we
feel
that
it's
ready
to
merge
into
the
argo
cd
repository.
B
B
So
I'm
looking
to
avoid
a
big
bang
integration
for
obvious
reasons,
I'm
proposing
that
app
set
code
be
added
to
the
argo
cd
code
base,
but
behind
a
feature
flag.
B
So
the
app
set
code
would
live
in
the
argo
cd
code
base,
but
would
not
be
enabled
by
default
and
would
not
be
executed
as
part
of
a
standard
argo
cd
install
until
we
feel
it
is
ready
to
do
so.
What
does
it?
What
do.
A
B
Rather
than
at
this
point
having
it
the
code
move
into
argo
cd,
we
could
have
the
code
continue
to
live
separately
from
argo
cd
and,
at
this
point
just
ship.
The
application
set
image
as
part
of
a
deployment
that
is
part
of
the
standard.
Argo
cd
install
to
me
that
kind
of
feels
like
a
middle
step,
which
we
could
totally
do
here.
B
I'm
outlining
the
the
big
step,
which
is
it
would
be
great-
to
have
to
be
able
to
maintain
both
sets
of
code
bases
in
a
single
location
in
the
argo
cd
repo
and
handle
it
from
there.
But,
as
you
said,
as
you
commented
on
the
google
doc,
there
are
definitely
middle
grounds
to
this
that
are
less
integrated
than
what
I'm
talking
about
here,
but
also
easier
and
and
less
risk
yeah.
H
Thank
you
so
just
understand
that
proposal,
the
that
one
is
to
have
the
basically
bringing
a
knapsack
code
into
argo
cd,
build
the
image,
but
not
but
turn
it
off,
and
and
so,
if
people
need
it,
they
get
an
image
for
with
every
release
that
they
can
turn
on
in
their
own
environment.
Is
that
the
idea.
A
I
I
yeah
yeah
right.
The
one
by
me
is
effectively.
We
don't
move
any
code
around,
but
we
do,
but
we
what
we
effectively
do
is
in
our
install
yaml.
We
have
another
deployment
which
points
to.
G
A
B
A
E
E
Is
quicker,
we
don't
have
to
retest
the
whole
lcd
and
wait
for
like
20
minutes
and
at
the
same
time
I
think
the
user
would
not
like
to
manage
to
image
versions.
So
I
I
was
thinking,
maybe
argo
cd,
for
you
know
ci
process.
Could
you
know
import
upset,
maybe
as
a
library
and
build
embedded
into
our
cd
image.
E
So
we
still
have
one
image
and
that
image
has
you
know
built-in
binary
for
repo
server
for
controller
for
upset
and
then
user
can
obtain
and
start
the
port
that
you
deserve
cd
image
and
starts
upset.
C
H
I
want
to
point
out
that
these
approaches
will
only
work
until
we
need.
You
know,
for
example,
ui
integration
at
that,
at
which
point
basically
it
has
to
be
in
the
same
code
base.
I
think
right.
E
Yes,
you're
right,
but
I'm
not,
I
think,
it's
totally
up
to
contributors,
but
I'm
trying
to
point
that
it
will
be
easier
to
make
code
changes
in
uncertainty
positively.
Just
because
it's.
A
I
mean
so
so
I
think
from
even
a
ui
perspective.
We
could
we
could
potentially
design
the
ui
in
a
way
whether
the
ui
responds
to
certain
whether
the
ui
could
show
certain
screens
based
on
the
availability
of
application
sets,
because,
after
all,
it's
a
cr
based
thing.
So
if
it's
not
there,
it
pretends
that
it's
not
aware
of
it,
or
even
the
crd,
for
example,
so
yeah.
I
think
I
think
that's
one.
A
I
think,
but
that's
a
good
point,
that
if
you
need
a
good
ui
integrated
experience,
we
need
to
ship
it
together.
I
think
the
other
factor
I
need
to
I
I'd
like
to
put
in
is
that
we
may
consider
moving
the
code
in
here
or
we
may
not,
but
I
think
some
of
the
due
diligence
that
we
have
to
do
before
we
ship
the
image
as
part
of
the
release
remains
the
same
so
which
means
if
there
is
increased,
serious
testing
that
needs
to
be
put
in
that
remains
the
same.
A
B
A
Experiment,
yes,
and
so
I
think
on
that
we
need
to
have
a
separate
discussion
on
whether
that
should
go
through
the
process
or
we
or,
if
the
or,
if
you
all,
agree
that
we
could
move
it
in.
Just
as
a
separate
thing.
E
A
C
B
Yep
agreed
yeah,
so
I
alex
brought
up
the
idea
of
integrating
as
a
package
or
as
a
dependency
of
argo
cd.
That
would
definitely
make
it
easier
to
integrate
in
some
ways,
but,
as
was
mentioned
once
we
build
deeper
integration
between
argo
cd
and
that
project
proper
in
things
like
ui
or
cli.
B
E
B
Of
course,
there
are
many
components
in
argo
cd
that
are
separate,
but
all
exist
in
the
same
code
base,
application,
controller,
api
server,
repos
server,
and
so
on
so
it'll
be
a
question
of
you
know:
is
it
more
effort
to
keep
it
separate
or
is
it
more
effort
to
to
move
it
inside?
I.
B
Exactly
so
yeah,
I
go
into
lots
of
detail
here
about
how
to
essentially
make
that
move
as
risk-free
as
possible,
but
it
all
boils
down
to
use
feature
flags
on
the
app
set
code,
use
github
actions
to
make
sure
that
a
we.
We
don't
regress
argo
cd
itself,
of
course,
but
also
ensure
that
appsets
works
in
its
new
home.
B
Once
that's
done,
enable
the
github
actions
allow
them
to
fail.
The
build
fix
failures
enable
the
feature
flag
in
the
in
the
project
on
by
default,
so
that
would
be
equivalent
to
shipping
it
and
then.
B
Is
the
last
step
removing
the
feature
flag
supporting
code?
So
in
that
way
we
phase
the
transition
in
the
code
moves
in,
but
it
doesn't
run
yet
then
the
code
runs,
but
only
as
part
of
automated
tests
and
then
the
code
is
running
as
part
of
the
product
proper,
but
we
can
easily
turn
it
off
with
the
feature
flag
and
then,
finally,
once
we're
happy
with
that,
get
rid
of
the
the
ability
to
support
the
feature
flag
at
all
and
yeah.
B
That's
basically
the
idea
behind
the
stage
merger,
the
idea
of
actually
moving
the
code
in
and
handling
inside,
argo
cd.
After
that
there
are
a
few
more
items
which
are,
I
think,
fairly
self-explanatory.
B
Add
project
documentation
so
add
to
add
generator
examples
to
the
argo
cd
user
guide
and
then
start
looking
at
all
the
the
great
new
features
that
are
defined
in
the
proposal
and
that
other
folks
have
proposed
things
like
cli
integration,
things
like
ui
integration,
things
like
templates
within
generators
and
generator
filters
which
are
in
the
proposal
and,
of
course,
always
important
making
sure
it
scales
making
sure
it
performs
and
making
sure
it's
secure.
D
E
D
A
Thank
you,
jonathan
I'd
like
to
quickly
touch
upon
one
more
thing,
jesse
and
alex.
I
know
we
do
want
to
have
argo
cd
to
a
cncf
graduation
sometime
early
next
year.
I
think
I'd
like
to
figure
out
what
the
impact
of
pulling
this
in
would
be,
especially
from
a
security
perspective,
because
I
think
argo
city
has
gone
through
security
review
and
all
that,
but
this
hasn't
yet
so
we
should
align
our
timelines
accordingly.
I
think
that's
all
I'm
saying
so
that
that
doesn't
get
impacted.
E
Yeah,
maybe
you're
referring
to
so
there
is
a
action
item.
We
need
to
close
all
the
sneak
security
editors
and
we
plan
to
kind
of
do
it
by
end
of
you
know,
somewhere
in
january.
A
Right
but
then
does.
C
A
Up
a
new
kind
of
worms
in
that
conversation,
which
is
fine
because
this
is
getting
added
now,
so
we
might
want
to
align
the
timings
accordingly
I
mean
we
could
we
could
put
we
could.
We
could
potentially
be
a
bit
aggressive
and
pull
in
application
sets
in
that
and
in
that
same
review
as
well.
If
you
want-
or
we
could
do
it
later,
but.
H
D
Yeah
sure
sure
is
yeah,
but
I
think
we
need
to
I
think
at
or
someone
of
the
organization
of
the
github
organization
administrators
need
to
install
the
sneak
application
for
argo
approach
labs.
So
then,
then
it
will
be
possible.
H
Okay,
so
why
don't
we
start
doing
that
and
then
turning
that
on
for
app
set,
so
that
those
issues
will
get
resolved
ahead
of
time
before
the
merge?
A
potential
merger
with
the
code
base.
A
Got
it
so
so
when
we
right
so
so,
then
can
we
can
we
have
a
timeline
for
ourselves
where
we
would
have
the
merger
done
in
time
so
that
when
we
do
a
cnc
graduation,
this
goes
along
with
it
instead
of
or
or
is
that
necessary?
I
would
say
I
mean:
would
it
be
flagged
as
a
separate
project
moving
into
a
monorail
format,
if
you
do
it
later
on,
I
think
that's
something
which
I'd
like
to
know.
If,
yes,
then
it's
better
to
do
it
now
and
then
go
for
the
graduation
all
together.
H
I
think
it
I
mean
I
just
guessing,
but
you
know
if
it's
something
that
we're
distributing
as
part
of
the
argo
cd
regardless.
If
it's
part
of
the
code
base
or
not,
I
think
it
would
need
the
the
the
snick
to
be
passing.
H
The
upfront
work
of
just
making
sure
it
passes
even
as
an
independent
project,
then
when,
if
it
does
get
merged
in
time
or
if
it
doesn't
work,
I
think,
are.
D
D
That
rocd
is
part
of
right
and
I
think
so
so
most
most
of
the
issues
we
see
in
sneak
they
are,
they
are
actually
coming
from
north,
so
from
from
the
npm
ecosystem
and
some
or
the
other,
the
others
are
coming
from
upstream
debian
base
image
and
I
think
it's
it
does
not
scan
the
go
code
right
so
it
it
also
won't
scan
any
any
code
from
the
from
the
app
set,
but
we
could
what
we
could
do
is
we
also
have
a
sonar
cube.
D
So
that
also
does
some
static
code
analyzers
and
maybe
we
can,
we
can
integrate.
So
our
cd
is
integrated
into
sonar
cube
and
maybe
we
can
integrate
the
app
set
there
as
well.
So
we
can
get
a
feeling
on
if
there's
something
really
wrong
or
if,
if
no
bad
things,
big
bad
things
are
waiting
for
us,
then.
D
B
H
There's
not
there's
no
web
service
right.
I
think
it
might
not
be
bad
at
all.
H
E
I
guess
the
initial
initial
idea
of
even
having
cargo
approach
labs
was
to
just
avoid
having
junk
in
argo,
but
right
now
I
think
we
all
sure
we're
going
to
keep
working
on
upset
like
there
is
no
doubt
about
it
and
it's.
I
think
we
consider
it
as
just
a
you
know,
just
a
library
of
argo,
cd
yeah
and
it's
it's
not
a
separate.
You
know
it's
part
of
fargo
city,
so
I
don't
see
any
reason
going
right.
H
So
the
guidance
is
that
we're
not
we're
not
introducing
a
completely
new
independent
project.
Like
you
know,
argo
advanced
overlaps
workflows
is
this
part
of
the
ecosystem.
This
is
not
considered,
wouldn't
be
considered
like
another.
B
H
So
moving
it
into
our
go
project
is,
I
think,
within
the
I
think,
the
guidelines
that
we
set
ourselves
about
introducing
the
projects.
This
is
an
ecosystem
project.
H
H
He
actually
suggested
this
a
little
while
back
himself,
so
I
think
he's
you'd
be
totally
fine
with
it.
A
Yeah
that
one
would
be
good,
I
mean
if
you're
speaking
about
the
one.
I
had
a
conversation
with
him
this
week
that
are
there
any
screaming
issues
you
see.
That
would
stop
us
from
doing
that.
He
said
no,
so
he's
good.
Okay,
yeah!
A
H
There
is
we're,
I
know
we're
out
of
time.
You
quickly
get
confirmation
that
so
there's
a
there's,
a
feature
that
we
got
offered
in
github
called
github
discussions.
Have
you
guys
seen
this.
G
H
This
is
actually
something
kind
of
like
stack
overflow,
but
it's
you
know
native
to
good,
and
then
I'm
actually
I'm
kind
of
excited
about
this.
Integrating
or
turning
this
on
for
for
argo
proj,
because,
first
of
all,
like
all
the
questions
and
stuff
that
get
posted
will
be
searchable.
H
They'll
come
up
in
search
results
in
our
if
you
search
our
github
repo
for
things.
So
I
think
people
will
discover
answers
to
questions
because
they
probably
won't
search
stack
overflow,
and
I
think
we
can
funnel
a
lot
of
the
issues
that
are
typically
questions
or
support,
requests
into
discussions,
and
I
think
we'll
also
get
better
participation
from
the
community
because
I
think,
there's
less
of
a
context.
H
Switch
of
of
people
who
are
using
are
interacting
with
argo
project
repo,
but
also,
then
they
can
easily
go
to
discussions,
and
I
think
that
there's
a
good
I'm
assuming
there's
like
a
good
linkage,
but
like
the
ability
to
link
back
and
forth
between
issues
and
discussions
and
for
all
those
reasons,
oh
the
other.
The
other
important
thing
is
the
identities
of
people.
Helping
out
are
consistent
from
get
to
discussions
like
it's.
H
The
same
you
know
people
before
so,
for
all
those
reasons,
I
I'd
like
to
propose
turning
this
on
to
you
know,
to
kind
of
facilitate
discussions
in
any
objections
or
thoughts.
A
I
think
this
is
good
because
going
to
a
slack
chat
and
asking
somebody
something
having
an
answer
and
then
not
having
it
searchable
at
all
is
pretty
pretty
waste
at
times
it's
good
to
have.
You
know,
one-on-one
conversation
on
a
slack
channel.
That's
awesome!
I
think
I'm
good
with
this.
You
know
I
think
the
bigger
challenge
will
have
to
be.
A
I
mean
it's
not
a
challenge,
but
in
general
we'd
like
to
figure
out
how
do
we
bring
more
conversations
on
this
from
slack,
given
that
we
already
have
a
huge
number
of
people
there
but,
like
I
said
if
we
can
at
least
this,
if,
if
this
group
can
make
this
github
discussions,
chatty
enough
people
will
be
encouraged
to
come
here.
I
think
that's.
H
Right
right,
I'm
bringing
it
up
pierce,
because
we
have
a
lot
of
the
people
I
expect
to
be.
You
know,
helping
answer
your
questions
and
stuff
like
so,
if,
like
hanging
on,
I
think
I
you
know.
I
encourage
people
to
answer
questions
here
so
that
we
have
like
more
permanent
answers,
not
like
ephemeral
answers
that
disappear
after,
like
a
few
months
in
slack
so.
E
Yeah,
I
agree
pretty
much
every
day
we
go
through
github
issues
which
are
questions
and
ask
us
to
answer
them.
So
we
can
change
github
issue,
template
and
explicitly
ask
to
create
conversation.
E
H
Okay
cool,
so
if,
if
that
that
was
my
question
to
the
group,
is
that
if
I
can
turn
this
on
and
then,
if
like
encourage,
you
guys
to,
you
know,
start
answering
questions
and
encourage
others
to
use
it
for,
for
their.