►
From YouTube: Cartographer Office Hours - Dec. 6th, 2021
Description
00:00 Intro and welcome
01:36 When to RFC, when not to RFC?
10:39 Informers doing a lot of things the controller does (PR #424)
28:40 Discussion: how to update RFC 014
The purpose of this meeting is to discuss architecture-changing ideas (in the form of RFCs) and provide in-depth support to the community of Cartographer contributors.
You can continue the conversation by adding comments to the RFCs PR: https://github.com/vmware-tanzu/cartographer/labels/rfc
Agenda: https://docs.google.com/document/d/1ImIh7qBrOLOvGMCzY6AURhE-a68IE9_EbCf0g5s18vc/edit?usp=sharing
A
A
The
goal
of
this
meeting
is
twofold:
first
to
to
try
to
have
a
more
educated
space
to
answer
questions
from
the
community,
you
know
technical
questions,
how
to
use
cartographer
for
specific
use
cases
and
also
how
to
extend
the
project
and
propose
ideas
or
discuss
ideas
that
that
eventually
could
extend
the
the
how
or
the
base
use
cases
of
the
tool
or
how
how
things
are
done
currently
right.
So
the
first
thing
is
to
decide
who
could
serve
or
help
with
note-taking.
A
B
C
D
B
Basically,
that's
the
idea
right
and
the
specifics
of
that
is
present
some
observability
about
what
parameters
are
available,
but
the
the
broader
general
rfc
that
I'd
have
to
generate
before
I
started
that
work
would
be
an
rfc
on
being
able
having
good
observability
into
the
system
and
it's
a
great
story
and
it's
one
I'd
love
to
write
something
up
about,
but
probably
I'm
used
to
incrementing
from
the
other
direction
or
what?
If
I
add
this?
B
What,
if
I
add
this,
does
this
start
to
build
up
something
right,
rather
than
something
that
feels
a
lot
more
waterfall-like,
which
is
what
a
general
rfc
sort
of
feels
like,
because
rfcs
tend
to
need
to
be
more
specific
than
use
cases
right.
They
tend
to
need
to
also
include
a
likely
implementation.
B
D
I
don't
think
an
rfc
has
to
include
implementation,
like
it's
really
just
a
request
for
comments
about
anything
if
that
makes
sense,
and
the
question
is
kind
of
like
how
can
you
use
that
format
for
like
requesting
feedback
on
a
proposal
from
a
lot
of
people
to
drive
progress
in
the
project?
And
so
if
you
have
something
that
you
want
to
work
on
more
iteratively,
you
know:
could
that
be
a
bunch
of
small
kind
of
easy
to
put
together
rfcs
that
work
towards
a
direction
or
a
higher
level
rfc
that
says
you
know.
D
I
think
we
should
move
in
this
direction
in
general
and
I'm
going
to
work
on
some
small
parts.
You
know
what
do
folks
think
about
that
right.
It
it
shouldn't
dictate
how
you
kind
of
work
forward
and
make
progress.
It's
just
communicating
that
you're
going
to
do
that
if
that
makes
sense,
with
whatever
granularity
that
you
want
to
use
as
a
tool
to
be
able
to.
You
know,
move
forward
in
that
way.
Does
that
make
sense
so
like
like?
D
If
you
want
to
work
on
something
you
know
where
you're
not
sure
where
the
end
goal
is,
but
you
know
just
just
capture
that
in
an
rfc
that
says
you
know
this.
This
is
where
I
think
we
should
be
in
some
amount
of
time
or
here
a
few
places
we
could
be
and
I'm
going
to
work
towards
it
here
and
then
maybe
some
smaller
rfcs.
If
you
feel
like
you
need
reviews
on
the
individual
pieces,
you
know
maybe
not
chat
with
chat
with
your
team
and
figure
out
what
the
people
agree
with.
B
D
Yeah,
I
think
other
kinds
of
projects
have
like
you
know.
Kubernetes
has
a
cap.
Python
has
a
pep
right
like
they
have
different
ways
of
proposing.
You
know
new
changes
that
they
don't
necessarily
call
rfcs
but
they're.
You
know
in
a
sense
the
same
kind
of
process
right
if
we
need
a
better
name
for
it,
because
we
feel
like
it
implies
too
much.
Ietf.
B
No,
that's
fine!
No
I'm
just
it's!
I'm
just
observing
the
historical
context
or
baggage
that
I
walk
in
with
right,
which
is
I've
always
assumed
that
invariably
in
the
ietf.
If
you
want
to
find
out
what
tag,
what
what
state
of
a
protocol
anything
like
that,
you
go
and
look
at
the
rfc,
and
that
is
canonical
to
what
actually
got
implemented
all
right.
So
I
think
I
just
bring
that
baggage
along.
I
think
other
people
might
too,
but
they
may
not.
We
may
just
want
to
be
clear
about
it
all
right.
D
B
E
Something
I
often
like
is
when
a
project
takes
the
time
and
effort
to
outline
what
their
first
principles
are
in
terms
of
like
these
are
the
things
that
are
core
to
the
design
of
the
way
that
we're
building
the
project
and
any
future
decision
always
gets
easier
to
review
in
the
context
of
those
principles
so
like
as
long
as
you
agree
that,
like
okay
cartographer
is
going
to
be
choreography,
then
you
can
judge
everything
else
down
the
line
about.
Okay.
E
Is
this
choreography
at
least,
however,
we've
defined
choreography,
just
as
it
turns
a
single
example
out,
but
then
those
principles
can
be
extremely
broad
or
sort
of
more
specific
to
a
domain,
depending
on
what
you're
actually
trying
to
achieve
like
the
broad
principles,
often
end
up
being
more
useful,
because
they're
more
likely
to
stand
the
test
of
time
over
change,
as
opposed
to
specifics,
will
likely
evolve
like
how
service
accounts
work
today
will
likely
be
different
than
how
they
work
tomorrow.
It's
different
than
how
they
worked
yesterday.
B
I
think
I
think
we're
we're
pushing
pretty
hard
at
the
moment
to
get
those
broad
principles
in
we're,
trying
to
get
a
positioning
statement
done
into
our
docs
and
we're
doing
an
architecture
sweep
just
to
basic
outline
of
architecture
and
the
orientation
behind
that
which
again
highest
not
the
highest
level
but
a
high
level
without
getting
into
the
nitty-gritty.
So
that's
coming
so
it's
it's
good
that
you
say
that
because
we
felt
like
that
was
important
that
we're
doing
some
of
it.
So
that's
some
alignment.
F
This
is
just
one
example,
so,
but
the
topic
as
a
whole,
I
think,
came
out
of
something
you
talked
about
a
meeting
last
week
about
just
our
informers
have
started
to
have
to
do
a
lot
of
the
work.
The
controller
does
like
matching
workloads
and
deliverables
to
supply
chains
and
deliveries
in
order
to
know
which
workloads
need
to
re-reconcile
on
the
change
to
a
supply
chain,
for
instance,
and
now
when,
like
a
service
account,
changes
has
to
do
know
which
workload
is
using.
F
That
service
account
to
re-reconcile
to
enforce
that
one
three
reconcile,
and
that
means
it
has
to
know
all
the
cascading
logic
of
like
if
the
workload
specifies
the
service
account,
follow
that
one.
If,
if
it
doesn't,
then
if
it's
specified
in
the
supply
chain
that
matches
it
and
that's
the
service
account,
the
change
then
reconcile
the
workload
and,
if
not
go
back
to
the
default
service
account,
and
so
it's
a
lot
of
controller
logic
that
feels
like.
F
B
There
is
a
sense
that
this
is
knowledge
that
could
already
be
established,
maybe
even
in
memory
all
right
about
how
things
relate,
but
one
of
the
nice
things
about
the
design
you
have
right
now
is
this
entirely
re-entrant
and
state
is
not
something
that
has
to
be
established
through
the
through
the
reconciles
of
the
existing
objects.
It's
just
as
it
comes.
B
However,
I
wonder
if
there
are
parts
of
this
that
could
be
broader
and
cause
reconciles
that,
maybe
maybe
we
have
more
reconciles
so
that
some
of
that
logic,
especially
the
ones
about
making
default
decisions,
falls
back
into
fact.
We
have
more
reconciles
and
we
exit
the
reconcile
as
early
as
we
can
so
that
so
that
we
limit
informers
to
just
mappings
that
are.
B
B
B
What's
actually
going
on
one
of
the
problems
we've
had
during
testing,
for
example,
especially
when
we
just
did
retries
and
back
offs
was.
It
was
very
hard
for
us
to
work
out
what
cause
you
know
and
whether
we
actually
fixed
the
problem
or
we
just
hadn't
wait,
waited
long
enough
to
back
off,
not
to
be
the
thing
that
was
solving
it
all
right.
If
you
don't
wait
long
enough
for
back
off
to
go
just
like
a
minute
and
then
you
try
something
it
should
resolve
in
a
few
seconds,
and
if
it
doesn't,
then
you
know.
B
E
E
The
I
mean
fundamentally,
the
the
reconciler
is
the
authoritative
source
of
what
resources
are
relevant
to
a
particular
resource,
that's
being
reconciled,
so
it's
basically
in
the
reconciler.
If
you
look
up
a
specific
resource
to
do
something
with
it,
then
that
state
is
meaningful
or
if
you
need
some
state
to
reflect
back
onto
your
status,
then
like
that
resource
is
meaningful
and
the
pattern
I've
used
in
the
past,
which
has
worked
fairly
well,
is
to
basically
define
for
a
particular
resource.
E
What
resources
do
you
want
to
track
and
then,
whenever
one
of
those
resources
gets
nicked
and
get
the
informer
event,
then
basically
do
that
reverse
mapping
and
then
figure
out.
Okay,
here
are
all
the
resources
that
were
tracking
that
resource
and
then
eq
them
into
the
the
work
queue
for
the
reconcile
event
process
so
effectively.
What
that
means
is
that,
in
your
controller
logic
or
in
your
reconciler,
you
can
basically
say
track
this
resource
track,
that
resource
track
this
third
resource.
E
B
I
get
some
clarity
on
what
you
mean
by
sure
by
track
that
resource.
Currently,
we
track
a
kind
we
do
not
track
any
details
about
which
one
it
is.
Is
that
what
you're
suggesting
that?
Maybe
you
go
further
and
track
which
resource?
Specifically
you
care
about,
put
it
in
something
that
the
mapper
can
then
reverse
later.
E
Yeah,
so
it
it
could
be
anything
that
makes
sense
for
you
specifically
or
for
the
project
like
in
my
experience
like
I
actually
created,
and
actually
this
is
even
like
cribbed
from
work
that
happened
in
canada.
They
actually
have
a
tracker
object
that
is
sort
of
maintaining
that
relationship
and
the
engineers.
E
E
There's
also
something
called
a
object:
tracker
from
client
go.
That's
a
little
bit
different,
but,
like
aside
from
the
specifics
of
the
implementation,
like
the
general
pattern,
is
that
you
can
basically
define
the
objects
that
you
care
about
as
part
of
your
main
reconcile
loop
and
then
sort
of
use
that
to
sort
of
create
that
in-memory
mapping
of
what
are
the
resources
that
you
care
about
for
this
other
specific
resource,
so
that
when
you
get
those
informer
events,
it's
basically
just
a
map
look
up
rather
than
actually
executing
business
logic.
F
Yeah
we've
talked
about
doing
that
in
the
past.
I
think
that's
what
kpac
does
that's
what
yeah.
I
think
I
think
I
brought
that
up
in
the
past
and
I
don't
it
does.
It's
definitely
a
little
tricky
here
because,
like
in
our
instance
like,
for
example,
if
a
service
account
is
defined
in
the
workload,
so
we're
going
to
want
to
reconcile
on
changes
to
that
service
account.
F
F
To
like
it
feels
weird
to
like,
in
that
instance,
go
and
look
up
all
the
roles
and
role
bindings
that
might
affect
it
and
also
if
new
ones
are
created
like
a
new
role.
Binding
is
created
that
would
affect
the
service
account.
You
wouldn't
learn
about
that,
and
so
it
feels
like.
We
would
need
some
sort
of
mix
of
what
we
have
now
and
what
you're
describing.
E
I'm
going
to
just
suggest
that
the
reconciler
loop
is
actually
a
better
place
to
do
that.
Lookup,
because
those
lookups
have
the
possibility
of
failing,
and
if
that
lookup
fails,
then
in
the
reconcile
loop,
you
have
the
queue
and
it
will
basically
reschedule
that
turn
or
that,
like
that
event
or
that
request
to
be
processed
again,.
E
F
E
E
D
B
B
Another
principle
that
we've
been
trying
to
use
is
not
to
end
up
in
back
off
when
it's
something
that
requires
user
interaction.
Anyway,
again,
that
was
just
so
that
we
could
predict
it.
I
don't
know
whether
other
people
agree
with
that.
I
just
felt
right
for
us,
so
we
go
in
to
back
off
when
there
are
exceptions
or
network
partitions
and
those
sorts
of
things.
Those
are
things
that
we
can
resolve,
and
so
it
just
seemed
logical
that
you
would
try
to
resolve
all
of
the
other
problem
possible
problems.
E
The
other
danger
there
is
that
the
rbec
resources
are
not
the
authoritative
source
permissions
within
the
cluster,
and
there
are
other
ways
of
making
access
to
control
decisions
that
you
won't
have
visibility
into.
So,
like
you
still
have
to
handle
the
case
where,
all
of
a
sudden,
you
do
have
permission,
there's
no
resource
to
watch.
To
know
that
you
now
have
permission.
B
Okay,
I
think
that
doesn't
remove
the
I
mean
we,
we
might
just
be
able
to
lighten
this
up
with
something
more
ostensibly
something.
That's
just
more
like
user-facing.
Look,
if
you
don't
have
it
right
by
the
time
a
developer
is
using
workloads,
then
they're
not
going
to
work
and
they're
going
to
have
to
reapply
them
and
if
you
do
anything
to
break
them
in
the
meantime,
they'll
also
end
up
with
a
problem
when
they
have
to
reapply
their
workloads
to
get
anything
to
happen,
and
that's
not
the
worst
thing
in
the
world.
B
E
E
C
B
C
C
B
E
Certainly
it
would
be,
I
guess
I
think
it's
cue
builder,
with
the
name
of
the
channel
which
encompasses
controller
runtime.
Okay,
you
would
certainly
find
people
there
with
opinions.
Often
times
like
you'll,
find
a
lot
of
opinions
on
some
things
or
you'll
either
get
no
response
at
all,
but
it's
definitely
a
good
place
to
try
things.
A
Thank
you,
scott
for
your
conclusions.
This
is
great
any
objection
to
decision
any
comment.
I
don't
think
so:
cool
yeah
next
item.
I
think
it
was
proposed
by
washuma,
but
I
I
don't
see
him
on
so
regarding
how
to
update
the
rfc
with
the
change.
The
rfc
14
will
be
changing
this
discussed
previously.
So
I
don't
know
if
anyone
has
a
comment
on
this.
A
B
E
B
C
H
H
I,
I
guess
just
confirmation.
My
intention
was
to
take
the
last
thing
that
the
last
implementation
that
we
talked
about
last
week,
which
is
detailed
in
the
comments
of
the
rfc
and
just
write
those
into
the
proposal,
make
that
rc17
and
probably
put
a
comment
on
here
to
say,
like
hey
rfc17,
is
meant
to
supersede
this.
You
know
if
you
make
a
pull
request
to
just
stick
the
word
withdrawn
on
this.
B
B
H
H
B
Okay,
I
just
I
think
that
we
can
do
that.
All
of
what
you
just
said
there
with
keeping
the
14
and
keeping
the
pr
history
as
well
and
bring
it
to
our
repo
and
and
just
rebate
point
the
pr
to
that.
I
believe,
that's
possible,
maybe
maybe
you
and
I
can
spend
five
seconds
trying
that
before
we
bump
another
one
unless
and
everyone
thinks
I'm
over
sensitive
to
the
idea
that
the
pr
the
rfcs
change
their
id
for
the
same
intent.
That's
the
only
thing,
I'm
sensitive
to
all
right.
C
B
Yeah
I
mean
you
can
literally
merge
it
into
a
branch
locally
right.
Instead
of
domain,
you
can
say,
accept
this
pr
into
same
name
locally.
All
right,
that's
the
same
name
on
origin
is
what
I
really
mean
there,
but,
but
you
know
whatever
works
for
you,
whatever
works
for
you,
it's
just
I
felt
like
keeping
the
number
was
was
more.