►
From YouTube: Argo Contributors Office Hours Oct 13th 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
And
so
this
is
what
we
have
for
today.
I
have
a
few
topics
and
before
we
start
I
guess
we
need
to
find
who's
going
to
model
the
discussions
next
week
and
something
back
from
previous
week.
It's
Jonathan
audio
here
to
give
feedback.
B
Yes,
can
you
hear
me?
Okay,
yes,
yep,
so
nothing
major
to
bring
up
here,
fairly
quiet,
so
answering
questions
and
triaging
issues.
None
to
raise
at
this
call.
The
only
item
that
I
did
want
to
bring
up
was.
There
was
a
feature
request
for
application
set,
but
it
looks
like
that's
already
on
the
agenda,
so
I
think
that's
it.
How
about
yourself
Leo
yeah
same
for
me.
Nothing
stood
out
this
week.
A
A
B
I
can
highlights
I
can
volunteer
for
the
second
secondary.
A
Okay
sounds
good.
Okay,
we
can
move
on.
Let's
start
his
discussions
and
I
guess
so
we
can
just
one
topic:
that's
the
new
feature
request.
Okay,
just
opened
it
here
and
I,
don't
see
who
proposed
it:
I'm,
assuming
Mike
or
Joshua
yep.
A
Yeah,
let
me
know
if
you
want
to
take
over
the
screen
or
I
can
just
keep
sharing
yeah.
C
C
We
want
to
talk
about
a
proposal
about
adding
an
optional
pool
model,
resource
delivery
mechanism
to
application,
set,
we're
really
looking
for
any
feedback
suggestions
and
as
well
as
guidance
from
the
Argo
CD
Community,
to
give
a
little
bit
more
background
context
to
this
proposal
in
open
cluster
management,
we
have
a
in-house
application
delivery
system
that
using
a
different
set
of
crds,
that's
currently
working
the
same
way
as
we
described
in
this
proposal.
C
We
have
users
and
Enterprises
that
prefer
this
hubspoke
or
pool
model
approach,
maybe
because
they're,
a
network,
networking
or
scalability
requirement,
and
we
want
to
slowly
migrate
them
from
our
in-house
solution
to
our
gocd.
So
we
know,
there's
a
there's,
a
demand
for
this
type
of
hubspoke
pattern
for
resource
delivery.
C
So
in
this
proposal
we
we
suggest
we're
suggesting
that
we
introduce
a
optional
way
for
application
set
resource
deployment
that
uses
this
pool
model.
So,
instead
of
the
application
set
generating
the
application
CRS
and
they
get
created
on
the
primary
or
the
Hub
cluster,
we
want
those.
We
want
to
generate
a
template,
wrapping
the
application
CRS
and
then
the
application
CRS
will
get
pulled
down
to
the
remote
cluster
and
then
each
remote
cluster
is
responsible
for
reconciling
the
application
CR.
C
A
So
basically
I
think
you
think
that
Argo
CG
is
installing
in
in
every
managed
cluster,
and
we
still
have
one
control,
plane,
cluster
and
and
something
that
copies
applications
from
control
plane
to
the
manage
cluster.
Is
it
the
ID.
C
Yes,
if
I,
if
I
heard
correctly
yes,
so
the
the
application
set
controller
is
on
the
Hub
or
the
primary
clusters
and
then
we
suspect
we
expect
there's
application
controller
on
the
manage
cluster
yep.
A
And
maybe
maybe
able
to
cover
it
but
is,
is
it?
Is
this
link
in
the
redirectional
like
okay,
like
in
other
words,
is
it
still
possible
to
see
all
those
applications
in
one
centralized
argosity?
Oh
no,.
C
Yes,
we'll
we'll
get
to
that
regarding
the
status
feedback,
you're
talking
about
Gathering
the
status
from
the
application
back
to
the
application
set
on
the
on
the
Hub
cluster,
and
we
do
have
a
mechanism
for
that
and
we'll
get
to
that
in
details.
Okay,
I.
C
Foreign
okay,
I'm
gonna
talk
a
little
bit
about
the
motivation,
so
actually,
as
I
briefly
mentioned,
the
current
Argo
CD
deployment
is
primarily
the
push
model.
We
have
the
centralized
cluster
pushing
towards
the
remote
and
manage
cluster
by
applying
the
resources
directly
to
them.
C
Okay,
so
the
benefiting
of
having
the
pool
model
adding
this
optional
cool
model
is
we
we
give
the
users
another
way
of
deploying
those
resources,
so
the
advantage
of
that
is
the
scalability.
C
It's
it's
quite
well
researched
and
document
that
the
hubspoke
pattern
offers
a
better
scalability
and
then,
in
terms
of
security,
we
don't
need
to
store
the
remote
clusters
or
manage
clusters
credentials
in
the
centralized
Hub
cluster,
and
it
also
reduce
the
single
point
of
failure
in
if
the
Hub
cluster
goes
down,
the
manage
cluster
can
still
continue
to
reconcile
against
the
get
repo,
so
another
motivation
is
Argo.
C
Workflow
is
also
looking
for
a
way
to
gain
multi-cluster
capability
and
if
we
can
follow
a
similar
approach,
that
will
give
a
consistency
on
both
sister
projects.
So
this
I
I
think
this
optional.
Pro
model
approach
is
kind
of
similar
to
the
current
existing
Argo
CD
apps
will
apps
so
we're
not
introducing
a
really
novel
pattern
as
well
before
I
continue
towards
the
proposal.
Any
question
regarding
the
motivation.
C
Okay,
I'm
gonna
talk
a
little
bit
about
the
proposal,
so
there
there
is
dependencies
regarding
this
future.
So
we
want
to
delegate
some
of
those
cluster
management
aspects
to
open
cluster
management.
C
So
you
need
to
First,
have
the
open
cluster
management
setup
so
in
in
this
optional
pool
model,
the
application
set
is
leveraging
the
open
cluster
management
API
for
their
cluster
inventory
and
the
ability
to
deliver
those
applications
from
The
Hub
cluster
down
to
the
remote
and
manage
cluster
or
shall
I
say
the
remote
manage
cluster,
pull
the
application
from
The
Hub
cluster.
C
So
but
again,
this
proposal
is
based
on
the
ocm
API,
but
we
we
welcome
any
suggestions
or
guidance
from
the
community
to
introduce
it
as
a
framework.
So
any
project
can
any
other
multi-cluster
Solutions
can
integrate
with
an
Argo
CD
similar
to
ocm.
C
C
So
one
of
the
one
of
the
first
thing
is
we:
we
have
to
import
the
open
cluster
management
API
that
gives
you
the
API
access
to
the
cluster
inventory,
as
well
as
the
workload
delivery
that
I
briefly
mentioned
above
so,
if
there's
a
if
there's
a
annotation
on
application,
set,
CR
or
or
like
a
spec
change,
but
for
now
I'm
I'm,
suggesting
we
put
a
annotation
for
now,
The
Hub
cluster,
with
the
application
set
controller,
will
evaluate
the
cluster
decision.
Resource
generator.
C
So
they'll
give
a
little
bit
of
background
on
the
cluster
decision
resource
generate.
This
is
a
this
is
a
generator
that
Joshua
contributed
from
the
open
cluster
management.
It's
a
duct
type
generator
that
can
look
at
any
any
CR
CRS
and
generate
the
list
of
clusters
that
way,
so
we
just
we
just
for
now.
We
picked
this
this
generator
because
it
has
a
roots
from
the
open
cluster
management
community.
C
So
we're
gonna
we're
gonna
talk
about
the
other
other
generators
once
we
have
a
better
idea
of
orbital
guidance
or
feedback
from
the
community.
C
So
once
we
evaluate
the
the
cluster
decision,
resource
generator
we're
going
to
validate
that
the
decision
against
the
Hub
cluster
so
using
the
ocm
API
to
make
sure
that
you
know
the
the
OC
the
environment
has
ocm
set
up.
It
has
the
ocm
cluster
inventory
and
has
the
ability
to
deliver
the
this
pro
model
workload.
C
So
if
per
application,
CR
that
generates
from
the
application
set
we're
going
to
wrap
it
with
on
what
we
call
a
manifest
word.
A
manifest
work
allows
the
remote
cluster
to
pull
whatever
payload
inside
the
Manifest
work
down
to
the
manage
cluster.
C
So
what
that's?
Essentially,
all
the
code
changes
we're
looking
for
in
in
the
application
set.
So
obviously
there's
as
I
mentioned,
there's
the
requirement
for
the
for
having
the
open
cluster
management
environment
set
up.
So
we
just
we.
C
We
expect,
in
order
for
the
application
to
be
able
to
reconcile
on
the
remote
cluster,
it
needs
to
have
the
application
controller
deployed
in
the
remote
cluster,
and
that
is
some
of
the
details
that
we
it's
related
to
this
proposal,
but
it
doesn't
require
any
additional
code
changes,
that's
linked
to
this
proposal
and
then
before
I
continue.
I
know.
This
is
quite
a
bit
of
details.
I'm
gonna,
stop
and
see.
If
there's
any
questions
or
comments.
C
C
We
provide
cluster
registrations
so
that
you
can
have
a
list
of
inventory
Lister
of
cluster
inventory
on
the
Hub
cluster,
and
then
we
also
have
the
work
distribution
API,
and
then
we
have
the
the
placement
apis
that
let
you
pick
the
different
clusters
that
you
want
to
deliver
to
the
workload
to
so
having
the
having
the
open
cluster
management
environment,
set
up
sort
of
delegates,
the
the
cluster
inventory
from
an
Argo
CD
to
another
project
that
is
more
focused
on
the
multi-cluster
aspect,
so
that
is
I
couldn't
powwow
on
the
open
cluster
manager
and.
C
A
C
It's
not
going
to
install
Argo
CD.
We
do
provide
an
add-on
framework
that
you
know.
If
someone
laps
I'll
go
CD
control
the
application
controller
in
an
add-on,
then
we
can
assist
in
terms
of
providing
that
application
controller
to
the
manage
cluster,
and
then
we
provide
the
life
cycle
allowance
that
the
application
controller.
C
But
the
main
point
of
having
the
open
cluster
management
environment
installed,
is
having
that
mechanism
of
pulling
the
the
payload
from
The
Hub
cluster
down
to
the
manage
cluster.
So
in
this
case
it
will
be
the
application
CR.
C
For
now
it's
it's
for
now
it's
the
application
set
controller,
because
that's
where
we're
planning
to
generate
these
manifest
Works
crapping
the
applications.
C
The
Manifest
work
API
is
based
on
the
kubernetes
work
API,
it's
a
it's
like
API
that
allows
for
delivery
of
workload
from
one
cluster
to
another
cluster.
So
it
also
has
the
ability
to
provide
the
status
feedback
that
you
you
asked
in
the
earlier
of
the
meeting,
so
you
can
Define
the
set
of
set
of
feedback
conditions
based
on
the
on
the
status
of
your
payload.
That
was
the
that
was
delivered
and
then
bring
it
back
to
the
hub
cluster.
C
So
you
have
a
centralized
view
of
all
the
different
other
different,
manifest
work
deployments
down
to
the
match.
Cluster.
C
So
in
terms
of
the
UI,
everything
is
driven
from
using
the
application
set,
so
the
Manifest
work
is
more
of
internal
working,
an
internal
library
that
supports
this
delivery
mechanism.
We
don't
expect
the
user
to
manually,
even
though
they
can.
We
don't
expect
them
to
mainly
edit.
This
manifest
work,
which
is
more
of
a
primitive
multi-cluster
workload,
delivery,
API.
B
A
C
Yeah
exactly
you
can
have,
we
can
have
an
additional
controller,
we
don't
have
to
use
application,
set
controller
and
the
reason
we
decided
to
prototype
or
suggest
an
idea
based
on
application
set
controllers.
As
I
mentioned,
we
have
the
cluster
decision,
resource
generator.
C
That
was
contribute
from
our
community
and
that
generator
looks
at
the
placement
API
and
then
it
picks
the
it
picks
the
the
cluster
targets
that
you
want,
so
that
so
we
see
this
a
nice
Synergy
between
the
cluster
decision,
resource
generator
and
the
application
set
and
then
generating
the
Manifest
work
in
the
application
site
controller.
But,
as
you
said,
it
can
be
a
separate
controller.
A
B
A
C
I
agree,
I.
Think
that's
a
that's
a
great
comment,
great
suggestion.
But
what
do
you
think
about
so?
Are
we
gonna?
Are
you
suggesting
we
Define
a
new
crd
that
can
sort
of
have
the
functionality
application
set
as
well,
but
it's
more.
A
I
think
maybe
and
I
might
be-
maybe
missing
something,
but
as
I
understand
it
is.
The
main
point
of
main
point
of
disintegration
is
to
eventually
to
create
a
manifest
works
here
and
then
open
customers
with
API
kind
of
users.cr
to
do
their.
You
know
the
rest
of
work,
I
mean
create
applications
in
Balance
clusters
and
copy
back
the
status.
So
I
was
hoping
if
we
have
a
controller
that
only
look
for
if
the
controller
that
manages
manages
and
we
see
the
applications.
A
B
C
It
got
it
I
understand
so
then
the
change,
then
the
application
set
controller
also
needs
something
like
oh
I'm
gonna
skip,
reconciling
based
on
this
annotation
on
this
spec
or
something
like
that.
A
Okay,
I
think
what
I
was
thinking
is
that
you
know
application
sets,
can
keep
generating
apps
in
control
plane
in
the
control
plane
cluster,
but
the
in
that
control
plan
cluster.
We
would
not
have
any
rpcg
replication
controller,
so
applications
that
would
just
create
applications
in
a
control,
plane
cluster
and
the
additional
controller
would
create
manifest
work.
A
Open
cluster
API
copy
uses
manifest
work,
CR
spec
to
understand
how
to
copy
applications
into
a
managed
cluster
and
then
manage
cluster
has
the
real
worker
that
does
the
work
and
you
got
it.
Yeah
that
was
I
might
be
missing
something,
but
that
was
you
know.
This
is
foreign.
C
So
one
of
the
issue
with
that
approach
that
you
just
recommended
it's
then
that
way
we
still
need
the
list
of
cluster
in
the
in
the
Argo,
our
goals,
CD,
control,
plane
and
part
of
part
of
this
proposal.
Is
we
we're
trying
to
delegate
you
know
those
away
those
credentials
from
scrolling
on
the
Hub
cluster?
C
So
when
the
application
said
controller
generates
those
applications,
it
actually
validates
to
make
sure
that
they're
in
the
application,
those
clusters
and
those
applications
are
valid
and
can
be
deployed
to
those
those
clusters
and
Argo
CD
control.
Plane
has
and
since
we're
not
really
adding
those
clusters
sort
of
speak
or
in
in
the
space.
One
of
The
Proposal
to
those
lists
of
clusters
are
not
added
to
the
Argo
CD
control
plane,
so
that
makes
it
a
little
bit
more
difficult.
A
This
is
the
cluster
decision
generator
partially
solve
the
problem.
Basically,
it
can
decide
to.
A
A
How
how
just
the
fit?
Basically,
how
I
understand
why
I
just
think
additional
controller?
It
won't
provide
the
best
possible
user
experience,
but
I'm
still
trying
to
find
a
way
like
if
we
could
maybe
make
application
set
a
bit
more
flexible
and
make
it
possible
to
generate
applications
by
putting
some
metadata
from
open
cluster
management
API.
A
B
C
Yeah
I
think
we.
We
definitely
welcome
that
approach
and
I
think
that's
a
great
idea
of
solos
sort
of
separating
the
the
this
requirement
because,
like
I
mentioned
the
the
importing
of
the
ocm
API
into
the
Argo
CD
main
project,
it
does
seems
a
little
bit
weird
and
too
too
couple
and
I
and
if
it
can
be
delegated
into
a
more
like
I,
don't
know,
maybe
like
an
add-on
type
of
title
project
in
a
separate
project,
and
it
makes
more
sense.
A
Yeah
I
guess
the
main
reason
I
think
we
in
rocg
most
of
the
changes
that
we
were
making
so
far.
It
was
kind
of
trying
to
make
it
extensible
and
even
we
have
plans
to
push
some
of
the
existing
functionality
of
pharmaceutical
into
accounts,
for
example
cluster
management
tools
that
we
have.
A
We
have
first
class
support
for
customers,
Hill
and
even
those
things
we
want
to
move
kind
of
outside
the
photography
in
into
adults,
and
you
know
and
we're
trying
to
keep
making
it
more
extensible
to
provide
still
first
class,
like
we
will
experience
okay,
but
maybe
now
I
think
we're
kind
of
getting
too
much
into
implementation,
maybe
I'll
just
maybe
it
makes
sense
to
continue
and
talk
about
the
list.
C
Yeah
I
I
think
we
basically
cover
Melissa
in
the
below
I
I
just
have.
If
you
scroll
down
a
little
bit,
I
just
have
a
simple
diagram
of
what
we
discussed.
So
the
application
set
control
lives
on
the
Hub
cluster
and
then
in
in
each
manage
cluster.
How
ACM
works
is
they
have
their
own
dedicated
namespace?
So,
for
example,
cluster
one
will
be
in
the
cluster
one
namespace
and
then
the
remote
cluster
only
has
access
on
that
classroom.
C
C
So
we
we
already
mentioned
the
you
know
in
details.
What
that
entails
so
in
below
I
gave
an
example
of
the
Manifest
work
that
we
are
planning
to
generate
so
in
in
the
first
you
you
can
see
sort
of
the
feedback
rules
that
is
part
of
the
spec
for
the
Manifest
work.
So
in
this
case,
we
we
just
Define
the
application
health
status
and
the
application
sync
status
as
a
as
an
example,
because
those
other
those
are
the
two
things
that
shows
up
when
you
do
a
clip.
C
Ctl
get
application
on
the
on
the
Argo,
CD
API,
and
then
the
the
workload
defines
the
payload
of
the
application.
So
we
have
the
so
the
application
that
it
generates
instead
of
applying
on
the
primary
or
the
help
cluster.
It's
it's
sticked
into
this
payload.
C
So
it's
so
this
payload
it's
meant
to
deploy
on
the
managed
clusters,
so
you
can
see
in
terms
of
the
the
destination
the
server.
Currently,
it's
it's
on
the
default
service.
So
it's
not
it's
different
from
the
a
regular
application
set
generator
application
where
the
destination
is
towards
a
remote
cluster
that
was
added
to
the
Argo
CD
cluster
inventory.
C
So
if
you
scroll
down
a
little
bit,
you
have
the
status
of
the
Manifest
work,
which
is
the
the
feedback
coming
from
the
manage
cluster.
So
once
it's
applied
and
then
the
application
CR
is
deployed
in
a
mesh
cluster.
Your
feedback
that,
in
this
case
it's
the
health,
is
healthy
and
the-
and
this
thing
status
is
sync-
and
these
are
the
these-
are
the
feedback
rules
that
we
we
cover
near
the
top
and
then
I
think
this
is
basically
it
on
the
proposal.
C
If
you
scroll
down
a
bit,
I
have
a
bunch
of
references
slang
and
in
a
video
POC
on
the
on
this
proposal.
B
C
Yeah,
yes,
that
is
the
that
is
the
an
open
cluster
management
agent
that
lives
on
the
manage
cluster
and
that
has
access
to
the
hub
cluster,
the
the
namespace
that
is
dedicated
to
that
manage
cluster
and
that
agent
will
pull
down
the
payload
that
way.
You're
correct.
B
B
C
The
and
the
agent
is
looking
for
the
the
Manifest
and
the
agent
on
the
manage
cluster
is
looking
for
the
Manifest
work
on
the
Hub
cluster
and
pull
down
the
payload
that
way.
So
there.
B
C
A
C
Will
go
through
something
called.
We
call
it
like
cluster
registration
process.
Basically,
it
goes
through
a
certificate
exchange
and
then
approval,
and
then
that
will
once
the
registration
is
done.
The
Hub
cluster
will
have
the
list
of
lists
of
managed
clusters
and
then
the
manage
cluster
will
continue
to
renew
the
the
certificates.
So
none
of
the
ones
once
the
registration
is
complete.
C
I
think
none
of
the
credential
is
actually
stored
on
the
Hub
cluster,
but
the
Hub
cluster
has
a
list
of
lists
of
public
certificates
and
then
but
the
remote
cluster
contains
the
key
that
is
never
transmitted
and
then
it'll
be
able
to
access
the
help
cluster
that
dedicated
their
dedicated
namespace.
That
way.
A
A
C
The
The
Hub
cluster
has
the
the
manage,
managed
cluster
CRS
yep,
so
there's
a
list
of
managed
clusters
and
it's
actually
that
managed
cluster
is
actually
created
by
the
by
the
remote
cluster
and
then
the
so
you
you
can
request
of
creating
this
manage
cluster.
It's
up
to
the
hub
cluster.
To
approve
this,
this
creation
right,
everything
yeah
you
can
create,
but
so
there's
a
sort
of
two-step
approval
process.
A
I,
just
one
idea
so
when
we
spoke
about
like
what
we're
trying
to
figure
out
if
there
is
a
way
to
avoid
importing
codes,
I
think
one
possibility
is
that,
let's
say
we
have
a
controller
that
Arbor
City
doesn't
know
anything
about
this
controller
but
controller
watches
applications
and
cluster
registration,
CRS.
And
so
every
time
when
application
is
created,
controller
creates
manifest
work
and
every
time
when
cluster.
A
Registration
CR
is
created,
the
same
controller
can
create
our
gocg
secret,
that
is,
that
has
metadata
related
to
this
cluster
and
so,
and
it
doesn't
even
matter
if
that
secret
has
no
cluster
credentials,
because
in
a
hub
cluster
we
wouldn't,
we
should
have
a
publicity
application
controller
either
way,
so
that
would
make
applications
that
happy
so
applications
that
would
think
that,
yes,
there
is
a
positive
straight
it's
registered
and
it
puts
you
know,
generate
applications
and
manifest
work.
Shares
will
be
created.
A
Yeah
I
would
definitely
recommend
it,
because
this
way
there
is
no
need
to
you
know
to
make
even
code
changes
in
obesity.
A
A
Alcohol
related
projects
made
it
into
our
approach.
So
basically,
article
Labs
is
a
kind
of
hole
for
experimental
projects
and
for
projects.
That's
kind
of
just
support
alcohol.
So
it's
not
it's
not
incubator.
It
can
be
just
a
permanent
home
for
projects
like
LBC
operator.
So
we
basically.
A
Operator,
as
example,
so
it's
mature
people
use
it,
but
we
made
a
decision
to
keep
it
in
our
GoPro
slabs,
because
you
know
it's
it's
a
perfect
place
to
host
a
project,
but
some
other
projects
that
anti-fica
Bluetooth
every
city
like
RBC
image,
updated.
For
example,
we
have
planned
to
or
even
applications
that
application
said.
A
Elsa
was
born
in
algebra's
labs
and
eventually
we
made
a
decision
to
just
merge
it
into
our
Google
CG,
because
they
are
too
Technical
and
it
was
the
inconvenience
to
get
the
keep
them
separate,
so
yeah
and
then
I
guess
this
project
that
integrates
my
auto
open
cluster
management,
API
and
ergocg
I
would
also
create
it
here
first
and
then
we
can
just
see
where
it
goes.
If,
like,
if
all
of
a
sudden,
everyone
uses
cyber
CG
with
this
project,
then
it's
a
candidate
to
make.
You
know
logically
server
CD.
A
C
I
think
this
is
a
great
location
and
thank
you
for
your
your
recommendation
and
your
feedback
and
yep
I
feel
like
if
we
can
have
a
repo
here,
that'll
be
great.
Yes,.
A
And
there
is
a
I
can
just
share
a
link
with
you.
I
wish
I
can
think
I
think
it's
in
maps.
A
A
documented
process
of
how
to
create
a
tripod
there
and
give
me
one
second
to
find
it
I'll,
find
it
and.
A
A
Okay,
I
think.
Okay,
this
we
have
no
time
for
other
topics,
and
this
is
it
I
think
it's
end
of
meeting
thanks.
Everyone
for
for
joining,
see
you
next
week.