►
From YouTube: KCP-Edge Community Meeting, February 23, 2023
Description
Andy Anderson informed the community of a) a new logo for kcp-edge, b) addition of elements to contributing.md, c) creation of a Quickstart.md guide, d) acquisition of the kcp-edge.io domain, and e) posting of the docs.kcp-edge.io using GitHub pages. Mike Spreitzer and Jun Duan debated the merits of edge event propagation using different approaches such as resyncing. Jun Duan showed how to use kubebuilder directives to override plural names for API objects. Braulio Dumba and Fabrizio Pandini discussed the work starting on the kcp-edge packaged development environments - potentially inspired by a PR from Fabrizio in kcp for building a kcp playground. Braulio introduced requested comments on metrics needed to measure kcp-edge-specific processes involving components like syncher from kcp. Mike discussed his proposal for the internal interfaces for the placement controller.
A
Share
our
agenda
if
you're
following
along
I'm,
looking
through
GitHub
repository
with
the
agenda
okay,
so
before
we
get
started,
let's
go
over
the
code
of
conduct
as
contributors
maintainers
in
the
cncf
community
and
in
the
interest
of
fostering
an
open,
welcoming
Community.
We
pledge
to
respect
all
people
who
contribute
through
reporting
issues,
posting
feature,
requests,
updating,
documentation,
submitting
pull
requests
or
patches
and
other
activities.
A
We
are
committed
to
making
participation
in
cncf
community
harassment,
free
experience
for
everyone,
regardless
of
level
of
experience,
gender,
gender
identity
and
expression,
and
sexual
orientation,
disability,
personal
appearance,
body,
size,
race,
ethnicity,
Age,
religion
or
nationality.
Basically,
in
a
nutshell,
just
everybody
try
to
be
nice
to
each
other
here,
appreciate
it
all
right.
So,
first
up
on
the
agenda,
I
had
a
couple
items:
I
wanted
to
share
with
the
rest
of
the
community
open
to
feedback.
A
If,
if
anyone
has
any,
the
first
ish
item
here
is
come
up
with
some
ideas
around
what
our
logo
should
be
like
paying
homage
to
the
original
kcp
logo
that
was
is
available
in
their
repository
came
up
with
something
that
looks
a
little
like
this.
Well,
it
does
look
like
this
and
the
the
byline
here
is
to
be
consistent,
so
in
terms
of
interfaces
heterogeneous
in
terms
of
coverage
and
scalable
in
terms
of
deployments
of
edge
configuration
management
of
edge
configuration,
and
so
you
can
see
the
lines
here
denote.
A
You
know
they're
standard
throughout
the
colors
change,
therefore,
being
heterogeneous,
and
of
course
this
goes
on
for
some
unlimited
number,
as
you
can
see,
it
fades
off
into
the
distance.
So
I
thought
this
was
pretty
well
captured.
What
the
essence
of
what
we're
trying
to
accomplish
here
at
kcp
Edge,
and
so
that's
what
I
built
accordingly
didn't
make
some
updates
to
the
contributing
document.
There
are
still
more
things
that
need
to
be
done
here,
but
as
as
work
in
progress
here.
A
This
gives
us
at
least
the
basics
of
what
we
need
in
order
to
start
operating
and
contributing
from
others
around
the
community
see.
We've
also
have
developed
some
The
kcp,
Edge
doc
site.
So
docs.kcp-edge.io
will
take
you
here
and
within.
We
have
a
bunch
of
MDS
that
have
been
converted
over
to
use
the
Jekyll
minimum
Minima
theme.
That's
part
of
github's
pages
implementation.
We
did
buy,
we
purchased
the
kcp-edge.io
domain,
and
so
we
do
have
the
ability
to
write
documents
to
it.
That
you
know
will
support
our
our
work
in
the
future.
A
A
B
B
You
know,
there's
there's
a
lot
of
cases
where
people
kind
of
copy
code
without
paying
close
attention
to
how
much
they
want
to
copy.
What's
there
versus
make
it
their
own,
and
there
are
a
few
different
patterns
for
writing.
Controllers
and
I
see
a
lot
of
something
that
doesn't
make
a
lot
of
sense
to
me
and
it
it's
around
resync.
So
resync
is
something
that
an
Informer
will
do
and
what
it
means
has
changed
over
time.
B
Back
in
the
midst
of
time,
a
resync
and
re-list
were
the
same
thing
and
there's
a
pointer
in
here
or
a
copy
of
a
picture
from
an
old
book
that
talks
about
lack
of
communication
and
re-list
to
solve,
covering
for
the
Informer
not
noticing
changes
informers
have
evolved
since
then,
and
they
now
without
any
need
for
any
kind
of
a
resync.
You
know
cover
for
communication
outages,
that's
through
the
the
way
they
use
a
list
and
watch
and
resource
versions.
B
C
B
Method
on
the
Informer
we
can
tell
about
a
new
client.
The
client
can
Implement
three
methods
for
being
notified.
Incrementally
of
changes,
there's
a
method
for
object,
Edition,
a
method
for
object,
update
and
method
for
object,
deletion
and
resync
is
an
operation
in
the
Informer
where
it
runs
through
all
the
clients,
or
you
can
resync
on
clients
individually
and
invokes
the
add
method
for
every
object
that
exists.
B
It's
not
getting
new
information
from
Upstream,
so
this
picture
here
about
communication
outages
is
outdated.
It's
not
what
resync
is
doing
today,
and
so
this
gets
to
a
question.
There's
a
related
thing
here,
which
is
in
a
controller.
You'll,
sometimes
see
controllers
that,
and
so
the
controller
pattern
right
is.
B
It
involves
using
informers
to
keep
the
controller
eventually
consistent
or
aware
of
some
Upstream
collection
of
objects,
and
it
has
a
work,
queue
of
references
to
objects
and
then
a
collection
of
workers
that
DQ
object,
references
and
work
on
them,
and
if
the
worker
runs
into
trouble,
there
are
generally
two
forms
of
trouble
trouble
that
is
potentially
transient
and
trouble.
That's
not
transient!
If
it's
a
problem,
that's
not
transient!
That's,
for
example,
a
bug
in
the
code.
B
The
logic
will
simply
log
an
error
and
be
done
with
it
be
done
with
that
object
reference.
If
it's
something
that's
potentially
transient,
however,
it
may
log
an
issue
and
it
will
recue
with
a
delay
the
object
reference
so
that
it
gets
retried
later
some
controllers
will
re-queue
a
reference
for
a
limited
number
of
times,
and
so
one
pattern,
for
example,
that
you
see
is
controllers,
are
designed
so
that
for
some
transient
problems,
it's
not
picked
up
by
the
retry.
It's
picked
up
by
the
resync.
B
So
if
you've
got
a
controller
that
retries
for
a
limited
number
of
times-
and
it
happens
to
do
this
for
a
reference
to
an
object
that
has
been
deleted,
the
resync
will
not
save
your
butt.
So,
in
my
opinion,
the
superior
pattern
for
writing
a
controller
is
don't
bother
with
resyncs
and
don't
limit
the
number
of
retries.
B
D
B
Well,
I
mean
if
you,
if
it's
not
zero,
then
there
is
a
resync
and
you
have
to
think
you
know
if
I've
got
a
large
number
of
objects,
you
know,
and
ultimately
we
are
concerned
with
scaling
here.
Okay,
this
is
one
of
the
reasons
I'm
not
a
fan
of
resync
is
when
you're
dealing
with
a
large
number
of
objects,
it's
going
to
dump
a
huge
number
of
object,
references
in
that
work,
queue
and
so
you're
going
to
have
a
big
spike
in
work.
That's
actually
not
going
to
do
you
any
good
anyway,.
E
B
F
B
To
be
I
mean
I
haven't
fully,
you
know,
read
this
document,
it's
it's
clearly
outdated.
It
seems
to
be
concerned
with
dropped
events
which
you
know
informers
handle
today
through
the
use,
the
carefully
used
of
list
and
watch
and
the
way
they
handle
our
resource
versions.
So,
there's
no
problem
with
dropped
events.
F
Here,
I
think
it's
not
talking
about
Job
events,
and
this
document
is
exactly
talking
about
resync,
not
released.
It's
not
talking
about
a
drop
of
event.
It's
talking
about
this
segment
circumstances
where
the
event
happens.
Not
there
not
that
often,
in
that
case,
resync
is
useful.
That's
the
point.
The
picture
is
making.
F
Yeah,
it
has
a
outage
there
because
it
wants
to
compare
the
scenario
where
the
we
are
the
first
one
and
the
second
one,
which
is
the
ad
driven
and
the
edge
triggered
level
driven
Logic.
The
output
is
there
for
demonstrating
the
two
differences
between
the
one
and
the
two,
but
for
the
the
third,
the
third
one.
F
The
third
item
that
emphasized
stuff
is
the:
if
we
read
the
strategy
three,
you
can
see
that
even
the
last
sentence
that
even
if
the
application
run
every
runs
very
stable
and
does
not
lead
to
many
important
events.
I
think
that's
the
point
where
resync
is
necessary,
so
this
picture
is
exactly
talking
about
resync,
not
talking
about
release.
B
F
C
F
Let's
see,
let's
say
that
the
thermostat
in
that
house
is
responsible
to
stand
the
event
back
to
the
country
plane
saying
that
oh,
my
current
temperature
is
far
away
from
the
desired
temperature.
You
know
at
this
time
the
control
plane
will
try
to
bring
the
the
current
temperature
back
to
desired
temperature
for
some
reason.
F
Let's,
let's
imagine
for
some
reason.
This
event
doesn't
happen.
That
often
because
say
when
the
let's
say,
let
me
say
that,
let's
say
when
the
let's
say.
For
some
reason,
the
design
of
the
thermostat
is
not
that
perfect.
It
only
notifies
the
control
plane.
The
duration
between
the
desired
temperature
and
the
current
temperature
is
the
difference
is
larger
than
five
degrees.
Only
when
that
happens,
it
notifies
the
control
plane.
F
In
that
case,
resync
will
help
because
control
plane,
periodically
recue
the
event
into
the
better
fifo,
so
that,
even
if
there
is
no
event
triggering
the
control
Loop,
the
control
plane
is
still
able
to
but
tightly
bind
the
desired
temperature
to
the
current
temperature.
So
that's
what's
used
for
the
everything
here.
B
F
B
B
B
So,
let's
just
work
through
that
work
through
that
example,
with
actual
kubernetes
API
Machinery.
If
I
have
a
controller
that
needs
to
react
to
the
current
temperature,
there
would
be
an
API
object
that
holds
the
current
temperature
and
Informer
on
that
API
object.
Whenever
there's
any
change
in
the
current
temperature,
the
Informer
would
notify
its
client
whether
that
change
is
big
or
small.
F
The
thing
is,
the
thing
is:
kubernetes
only
have
control
in
the,
as
you
said,
I
only
have
control
on
API
object.
It
doesn't
have
the
control
and
external
World,
which
is
controlled
by
kubernetes,
if
the
thermostat,
for
example,
is
designed
in
such
a
poor
way
that
it
only
generated
events
when
the
difference
is
more
than
5
degrees.
That
will
make
the
entire
system
performance
to
be
degraded
degraded,
but
Google
ads
can
do
better.
Even
if
that
event
is
rare,.
B
Api
Machinery
is
fundamentally
not
based
on
events.
It's
based
on
State,
so
if
you've
got
a
thermostat
that
only
updates
its
state
in
the
API
machinery
when
it
makes
a
big
change
and
that's
the
only
channel
into
this
controller,
then
resync
doesn't
help
you
I
can
see
how
resync
helps
you.
If
this
controller
has
another
Channel
to
something,
that's
not
API
objects
right.
If
you
have
some
other
sort
of
stimulus
to
the
controller,
that's
not
Cube
API
objects,
then.
Yes,
you
may
want
to
periodically
sample
that
other
sort
of
input.
F
B
F
F
No
there's
no
such
second
Channel
when
I
say
when
I
say
when
you
say
the
fine,
fine
grain
temperature
I
think
what
do
you
mean
is
I
said
what
I
mean
there
is
the
existing
and
the
known
status
which
is
stored
in
the
in
the
in
the
store
of
the
Informer
say
the
Informer
knows
that
desired
temperature
is
20
degrees,
so
it
tries
to
bring
whatever
current
state
to
20.
Degrees
cannot
wait
for
the
degree
the
the
not
not
wait
for
the
decide,
not
wait
for
the
current
temperature
to
drop
below
15
degrees.
F
B
F
B
B
F
F
B
D
A
Understood
I
was
trying
to
link
that
back
to
kcp
Edge
in
general.
I
think
what
we're
going
to
do
is
we're
going
to
move
on
to
I
would
like
to
get
a
to
get
June
and
bralio
to
talk
about.
What's
going
on
in
their
backyards,
June
had
some
experience
with
glitches
in
the
crd
and
API
resource
schema,
so
I
wanted
to
have
them,
explain
that
and
then
we
can
get
on
to
I
know.
We
have
Fabrizio
here
and
bralio
has
some
work
to
do
with
him.
So
June.
F
It's
it's
actually
using
a
singular
form
name
and
because
of
this
I
cannot
correctly
access
this
single
placement
apis
using
the
client,
I,
initially
I,
don't
know
what's
happening
so
I
post
this
question
to
the
agenda
at
your
seek
for
help
from
a
community,
but
later
I
actually
figured
out
how
to
solve
that,
because,
because
we
are
using
computer
tags
in
the
comments
of
of
the
single
placement,
API
definition
I
can
explicitly
explicitly
specify
what
are
the
plural
form
names
there.
So
I
did
that
and
it
is
now
fixed
well.
A
F
C
F
B
C
C
A
A
D
D
B
D
A
E
Also
I'd
like
to
start
to
to
discuss
about
the
requirements
for
for
the
PLC
in
timeout
of
the
infrastructure
in
the
and
the
dev
deployment.
So
this
is
the
yeah.
The
this
figure
is
just
illustrating
yeah
yeah.
What
we
are
planning
for
for
the
for
for
the
POC,
so
it's
just
like
discuss
some
of
the
points
of
the
infrastructure
requirement.
So,
for
example,
here
we
have
so
from
from
this
comment,
so
it
seems
like
we
have
only
one
one
Center
and
the
and
and
then
there's
so
in
in
dash.
E
Here
we
are
going
to
be.
We
are
going
to
be
simulating
multiple
sinkers,
just
using
a
single
kubernetes
Clause
per
se
and
so,
and
the
likes
of
double
check
so
for
the
for
the
edge
server
provider,
workspace,
all
the
components
who
will
be
implemented
as
in
this
process,
and
it
is
my
understanding,
correct.
B
B
B
B
You
know
it's
it's
a
relatively
small
detail,
but
at
some
point
we
would
probably
benefit
from
putting
them
together
and
sharing
some
things.
Just
using
shared
informers
gets
you
a
shared
informal
Factory
gets
you
sharing
of
those
local
caches
of
the
monitored
objects,
so
I
think
we
we
want
to
get
to
the
point
where
those
four
boxes
in
the
edge
service
provider
workspace.
Those
are
four
controllers
in
One
controller
manager,
process.
B
As
as
big
as
is
practical
without
being
a
problem
in
terms
of
requiring
a
lot
of
development
or
more
money
than
we
can
afford,
so
in
particular,
I
think
this
means
one
kcp
server
process,
only
for
all
the
center
stuff
and
for
Edge
clusters.
You
know
make
them
as
cheap
individually
as
cheap
as
we
can
start
off
with
real
ones,
because
they're
in
some
sense,
don't
require
developing
a
simulator.
B
E
Okay,
okay,
so
so
for
for
the
for
the
for
the
dev,
the
the
deployment.
So
the
scale
is
not
an
issue
so,
but
for
the
large
scale,
the
deployment
that
we
we
want
to
do
so
in
the
in
the
last
POC
that
we
did,
we
had
we,
we
had
a
center
and
so
and
and
the
edge,
and
we
had
a
caucus
Pras
that
we
we
will
put
in
front
of
them
a
load
balance
to
spread
the
load.
E
A
D
So
yeah
I
think
literally,
you
also
did
some
experiment
in
the
past.
With
the
this
idea
of
somehow
sharing
a
cluster.
We
multiple
sinkers
to
somehow
simulate
some
kind
of
scale,
so
I
wonder
if
we
can
still
have
this
cybered
approach
or
some
clusters
are
real.
These
are
small
clusters,
Adar
k3sk,
3D
kind,
and
some
of
them
are
somehow
simulating
some,
maybe
100
of
clusters
using
the
sharing
the
the
Sinker
as
I.
Think
you
already
experimented
a
couple
of
months
back
and
I.
Yes,.
C
E
B
B
Me
of
something
we
haven't
talked
about,
which
is
the
treatment
of
namespaces
in
TMC.
They
translate
the
the
workload
name.
Space
does
not,
you
know,
become
the
same
name
in
the
P
cluster.
It
gets
encoded
to
include
both
the
source,
namespace
name
and
the
source
workspace
identity
for
Edge.
We
don't
want
that.
We
want
the
source
workspace
name
to
translate
exactly
to
the
namespace
name
in
The
Edge,
which
I
think
means
we
can't
Multiplex
in
into
one
HP
cluster.
D
B
A
second
thought
is:
maybe
we
don't
have
to
do
that
at
the
start,
but
I,
you
know
I
I,
think
if
you
think
about
the
the
needs
of
Edge,
multi-cluster
I
think
you
know,
the
idea
is
that
the
pattern
you
see
in
the
center
is
a
pattern
you
want
to
Stamp
Out,
multiple
copies
in
the
edge
and
I
think
it
makes
sense
to
have
the
name
spaces.
State
names
stay
the
same.
B
B
D
Yeah
consider
also
this
picture
that
you
have
right.
You
could
have
multiple
this
workload
management
workspace,
where
you
could
have
workload
the
name
space
in
in
all
of
them,
and
you
could
have
any
space
with
the
same
name
in
all
of
them,
and
then
you
could
have
potentially
overlapping
placement
that
will
send
to
the
same
cluster.
They
are
going
to
have
a
conflict.
B
B
You
can
have
multiple
Edge
placement
objects
that
Direct
subsets
of
workload
or
parts
of
workload
or
maybe
think
of
workloads
as
additive
right.
A
workload
is
some
objects.
You
can
send
one
workload
to
a
p
cluster.
You
can
send
two
workloads
to
a
p
cluster.
You
can
send
three
worklets
to
a
p
cluster
and
if
those
workloads,
all
those
are
some
of
those,
if
two
workloads
happen
to
put
objects
in
the
same
name-
space-
okay,
they
chose.
D
B
B
D
B
I
yeah
I
guess
we
need
to
talk
about
it
more
I.
My
opinion
is
that
the
you
know
a
workload
looks
like
ordinary
kubernetes
stuff,
which
includes
both
namespace
and
non-newspaced
objects,
and
the
users
are
aware
of
the
namespaces,
so
a
user
who
puts
something
in
you
know
namespace.
You
know
I
know
you
know
my
system
right,
expects
it
to
be
running
a
namespace.
My
system
in
the
HP
cluster.
G
Maybe
yeah,
if
I
can
maybe
just
yes
give
a
thought.
It
seems
to
me
that
changing
the
names
of
the
namespace
on
the
TMC
use
case
makes
sense,
because
it's
highly
related
to
the
assumption
that
the
parts
the
workloads
running
in
the
physical
cluster
will
see
the
context
of
kcp.
So
the
parts
themselves.
You
know
that,
don't
precisely
what
you
would
need
to
change
in
the
edge
case
that
don't
see
the
physical
cluster
environment,
they
see
the
kcp
environment.
G
So
even
if
we
change
the
the
name
of
the
namespace
and
the
physical
side,
you
know
to
mongolite
it's
not
a
problem
because
it
doesn't
bring
inconsistency.
It's
just
you
know
hosted
in
some
other
namespace
that
the
Pod
internally
knows
that
he
I
mean
sees
his
workspace
as
being
the
the
kcp
workspace.
So
I
tend
to
agree
that
if
you
cut
this,
you
know
feedback.
You
know
this
communication
back
from
the
part
to
kcp,
because
you
are
in
Edge
use
case.
G
Then
it
becomes.
You
know,
inconsistent
and
the
two
objects
I
mean
the
view
of
the
world
that
the
two
objects,
the
deployment
on
kcp
side
and
the
pod
on
physical
cluster
sign
the
view
of
the
way
of
the
world.
They
have
will
become
different,
and
it
seems
to
me
that
that
probably
cannot
work
that
does
it
make
sense.
Yeah.
D
G
Yeah
we
had
a
discussion
with
with
on
another
topic
with
someone
else
today,
which
makes
me
think
that
the
whole
point
is
really
ensuring
that
either
we
have
the
whole
world
of
upstream
or
the
whole
world
of
Downstream.
But
any
mix
of
those,
even
through
some
sort
of
you
know,
opened,
windows
or
or
leaking
will
bring
a
very,
very
painful
yeah.
B
E
Okay,
so
for
us
our
fabricities
is,
is
in
the
course
I
just
would
like
to
clarify
that.
So,
besides
creating
a
large-scale
deployment,
so
we
also
want
to
create
a
Dev
test
like
it
is
installed
for
for
people
to
play
around
with
with
this
environment,
and-
and
you
have
already
done
a
very
nice
playground
for
for
kcp
and
and
that
YouTube
demo
I
think
Catholics
are
gone
so
and
then
maybe
that
that
we
could
extend
that
to
deploy
the
common
components
that
you
will
need
for
for
the
kph.
C
H
Can
you
hear
me
yeah,
first
of
all
thank
you
for
inviting
me
and
for
the
feedback,
so
I'm
catching
apple
with
what
you
guys
are
doing
it.
So,
okay
has
been
designed
like
I'm
learning,
I
need
to
spin
up
an
environment,
change
them
and
fast
and
and
easily,
and
so
what
I
saw
is
that,
oh,
there
is
a
great
work
in
the
test
framework
of
TCP,
so
kcp
program
is
just
a
yaml
that
used.
That
is,
is
a
proxy
to
use
everything
that
is
in
the
test
framework.
H
C
E
H
It
worked
well,
in
my
opinion,
long
term.
This
kind
of
thing
work
well
only
if
we
can
make
the
playground
the
way
the
project
used
to
create
its
own
end-to-end
test,
I
I.
Basically
I
already
have
a
fixer
that
that
you
can
use
to
create
end-to-end
test,
and
so
this
will
make
basically
the
playground
automatically
maintaining
and
align
with
the
rest
of
the
project.
H
If
we
use
it
for
the
test,
but
yeah,
it
is
a
journey,
so
first
feedback.
It
is
a
tool
it
is
there.
It
helped
me
to.
It
is
helping
me
to
to
to
learn
and
I
think
that
other
can
appreciate
it
as
well.
In
my
mind,
at
least
for
my
mind,
it
is
easier
to
represent
my
mental
map
in
a
schema
like
this
or
a
map
of
a
schema
like
this
to
a
Toyama,
then
to
map
to
a
list
of
imperative
code
to
the
cattle
bind
the
kind
create
and
whatever.
H
So,
of
course,
you
have
to
know
both
of
them,
but
when
you
have
to
you,
want
to
repeat
the
fast,
the
yaml
is
much
faster
and
to
to
get
things
done.
So
if
you
want
to
use
it
to
expand
it,
it
is
there
I
offer
a
digital
Community,
because
I
think
that
people
can
find
it
useful
and
I'm
really
happy.
If
someone
will
helping
me
to
keep
this
Pro,
this
DCd
Agro
so
happy.
E
E
E
Per
se,
so
we
we
have,
we
had
a
discussion
about
how.
How
are
we
gonna
deploy
this
abstractions
so
now
what
we
want
to
to
collect
per
se,
so
by
so
in
the
discussion
that
I
I
had
yeah
with
with
mic
offline.
So
those
are
some
of
the
metrics
that
you
we
discussed
when
the
collect
the
singer
support
the
communication
with
the
thinker
with
the
API
server
and
and
then
then
the
latency.
E
So
how
how
long
I
write
text
to
how
long
it
takes
a
single
to
to
to
to
do
the
right
on
on
object
per
se,
so
I
I
have
I
have
to
do
questions.
So
do
we
have
what
are
the
additional
metrics
that
we
may
want
to
collect
on
the
infrastructure
and
also
if
someone
in
the
community
has
experience
of
collecting
metrics
from
from
the
sink
or
you
can
give
any
input
or
maybe
because
of
contribute.
E
A
E
G
G
G
B
Okay,
yeah,
let
me
share
my
screen.
This
is
internal
apis,
so
of
the
placement
translator
so
in
the
edge
mcpoc
architecture
that
we're
working
on
there's.
There's
a
proposed
process
called
placement
translator,
which
has
four
responsibilities
and
it
connects
to
it,
consumes
the
output
of
the
so-called
scheduler
for
Edge
scheduler,
which
has
one
more
responsibility
so
really
there's
five
parts
of
the
job
really
of
translating
an
edge
placement
problem
into
a
collection
of
TMC
placement
problems.
B
It
is
to
maintain
the
customized
workload
copies
in
the
mailbox
workspaces
and
then
the
final
job
which
I
put
in
an
interface
called
placement
projector,
which
is
to
maintain
the
TMC
placement
objects
that
correspond
to
each
Edge
placement
object,
so
we're
late
in
our
time
here.
So
I
probably
should
not
try
to
go
through
in
any
detail
or
much
detail
here.
There's
a.
A
B
Right,
okay,
so
you
know
I
tried
to
think
about
how
these
Pro
different
parts
could
interact
within
one
process.
With
some
reasonable
memory
and
CPU
efficiency.
You'll
see,
some
attention
has
been
paid
to
incrementality.
What's
mutable?
What's
not
you
know
the
usual
sorts
of
things
when
you're
designing
internal
interfaces?
B
Yeah,
probably
you
know,
shouldn't
shouldn't,
try
to
go
through
in
great
detail.
One
other
thing
I'll
call
out
is
the
relation
to
another
issue,
which
is
in
the
current
mailbox
controller.
It
computes
or
derives
the
mailbox
workspace
names
in
One
Way,
which
is
has
a
problem
with
both
character
set
and
length.
It
computes
the
mailbox
workspace
Name
by
concatenating,
the
the
sync
targets,
workspace,
relatively
I,
think
logical,
cluster
ID
and
the
sync
Target
name
and
sync.
B
B
G
Maybe
just
a
question
about
the
uid,
the
use
it
which
is
down
of
the
uid
think
Target
uid
on
the
TMC
is
mainly
a
ways.
A
question
of
you
know,
security
of
checking.
You
know
being
sure
that
if
the
Sim
target
has
been
deleted
and
a
new
sync
target
has
been
recreated
with
the
same
name
at
the
same
place,
which
in
fact
doesn't
really
represent
the
same
sinker.
To
show
that
we,
we
don't,
you
know,
act
with
it
as
it
as
if
it
was
the
same
singer
so,
which
is
why?
A
All
right,
so
just
cleaning
up
here,
I
think
we've
exhausted
all
the
topics.
We
have
some
good
first
issues
listed
in
the
in
the
issue
list.
Let's
say:
if
you
can
go
there,
determine
if
there's
something
that
you
want
to
pick
up.
Please
do
so
and
look
for
help
from
those
that
are
assembled
here.
I
think
it's
interesting.
A
So
we'll
get
we're
starting
to
make
some
progress
here,
some
traction.
So
let's
continue
the
good
work.
I
think
it's!
The
POC
is
only
about
a
little
less
than
five
weeks
away,
so
I'll
just
keep
an
eye
on
it
in
the
next
revision
or
the
next
community
meeting.
We'll
go
through
in
a
little
more
detail
what
those
use
cases
are
to
expand
upon
about
a
little
bit
further
of
what
the
product
of
all
these,
this
work
is
going
to
to
look
like
all
right.
Everybody.