►
From YouTube: Kubernetes Federation WG sync 20180207
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
Yeah,
when
we
broke
off
they
were
there
was
thought
that
we
might
give
a
little
more
thought
around
the
same
issues
and
then
sync
up
for
again
so
and
one
more
one
more
stuff
cause
acquaintance,
suggested:
salon,
proximity
and
probably
aunt
approximately.
So
we
can
talk
about
that.
Also,
if
time
permits
or
Quinton
have
you
been
able
to
put
something
I
think
you
mentioned
that
you
might
yeah.
B
C
D
B
B
You
have
clusters
on
opposite
ends
of
the
world,
possibly
even
in
different
cloud
providers,
which
provides
you
with
a
very
low
failure,
correlation
but
very
high
latency
and
typically
what
you
do
is
you
say,
I'm
happy
with
in
some
sub
range
of
that
range
for
these
two
resources
and
then
the
scheduler
can
can
schedule
accordingly.
So
to
answer
your
question
Meru
in
that
case,
what
you
would
just
say
is
that
I
specifically
wanted
to
be
in
the
same
cluster,
and
then
the
scheduler
will
do
that.
B
B
Tbd
I
think
I
would
imagine
that
one
would
want
multiple
of
these
things
and
they're
kind
of
symmetrical
in
the
sense
that
if
you
have
a
config
map
and
a
replica
set-
and
you
want
them
to
be
in
the
same
cluster
and
then
it's
not
clear
whether
it
should
live
in
the
replicas
set
or
in
the
config
map.
So
you
know
one
way
is
to
put
it
outside
in
a
kind
of
a
binding
thing,
but
we
could
put
it
in
either
of
the
two
you
instead
also
imagine.
B
E
B
You
know,
is
part
of
the
same.
Node
important
is
a
pod
on
a
different
node
in
the
same
rack
and
like
what
is
your
network
architecture
looked
like
inside
your
data
center
and
all
that
stuff.
So
there's
a
lot
more
scope
for
arguing
about
what
the
sensible
points
on
the
on
the
continuum
of
proximities
are
in
the
case
of
kubernetes.
B
I
think
it's
a
much
less
complicated
thing
in
the
case
of
federation,
in
the
sense
that
your
units
or
clusters
they're,
pretty
big
things
and
they
by
definition,
set
aside
an
availability
zone
right
now
and
there's
no
way
of
having
a
cluster
span.
Availability
zones
and
I'm
not
sure
they
ever
sorry,
not
availability
zones,
regions
and
I.
Don't
think
we
will
ever
have
single
clusters,
spamming,
different
regions
and
that
that's
an
explicit
kind
of
stated
goal
of
kubernetes
and
similarly
yeah
I
mean
I,
think
it.
B
You
know,
there's
a
huge
difference
between
in
cluster
networking
and
cross
cluster
networking
and
cross
cloud
provided
networking.
So
there's
no
argument
that
there's
a
big
step
function
there,
whereas
there
are
a
lot
of
arguments
about
you
know
if
you're
on
the
same
node.
Is
that
like
lower
latency,
then
in
the
same
rack
or
not,
is
it
significant
if
you're
in
the
rack
next
door?
Is
that
significantly
slower
than
being
a
same
rack?
B
And
so
it's
a
lot
more
blurry
in
the
case
of
committees,
whereas
here
it's
pretty
obvious,
the
speed
of
light
comes
into
play
pretty
quickly?
Yes,
even
you
know
both
being
on
the
East
Coast
versus
being
on
the
east
and
the
west
coast.
You
know,
there's
a
pretty
big
Delta
there
of
you
know
tens
of
milliseconds,
so
most
people
care
about
whether
they're
like
on
the
east
and
west
coast
or
both
on
the
west
coast.
B
E
Party
foul
so
I'm
trying
to
resolve
in
my
head
whether
like,
if
about
putting
the
kind
of
correlation
like
stickiness
or
gravity,
into
a
resource,
whether
like
when
we
talk
about
placement
and
also
like
in
the
continuum
that
we
discussed
on
Monday
of
at
the
simple
uninteresting
end,
is
like
declarative.
No
policy
at
the
other
end
of
the
spectrum
is
like.
B
B
B
If
you
specify
a
proximity
relationship
between
many
things,
does
that
mean
that,
like
the
does
that
explode
into
like
a
proximity
between
every
pair
of
things
in
that
group?
Is
that
founded
by
the
same
range?
Maybe
it
is-
and
maybe
there
is
a
useful
abstraction
that
users
will
like
and
be
able
to
use,
there's
there's
another
complication
which
I
haven't
really
spelled
out
yet
and
we
don't
have
any
strong
feelings
about.
But
you
know
when
you
have
a
federated
resource.
B
There's
a
sort
of
subtle
difference
between
I
want
this
replica
set
in
the
same
cluster
as
every
one
of
the
shards
of
my
sorry.
I
want
this
conflict
map
in
this
in
every
one
of
the
same
clusters
as
my
shattered
replica
set.
So
that
seems
like
a
reasonable
requirement
versus
I
want
my
conflict
map
somewhere
in
the
same
region
as
all
of
my
replica
set
shards
for
example.
B
So
if
this
federated
thing
lives
in
a
given
region,
because
my
constraints
on
that
say
that
it
all
needs
to
fall
in
the
same
region,
then
my
other
thing,
config
map,
let's
say
or
snapshot
or
whatever
it
happens,
to
be-
should
be
in
the
same
region
as
those
things
so
yeah
I
mean
we
need
to
figure
out
that
level
of
detail
but
I
think
before
we
even
get
there.
We
need
to
decide
whether
this
concept
of
a
proximity
scale
is
useful.
F
That
argument,
I
think
that
you
know
there's
sort
of
different
uses
this
years
right,
there's
like
there's
like
the
minimum.
B
And
so
that's
that's.
How
I
came
up
with
this
idea
of
the
proximity
scale
thing
and
and
and
this
stuff
I
kind
of
dreamed
up
long
long
ago
in
the
context
of
AWS
and
have
run
into
this
problem
several
times
since
then,
and
eventually
so,
did
it
there
internally
and
then
also
did
it
in
the
context
of
Google
services.
B
Because
implicitly,
I
know
those
two
clusters
are
close
enough
together
for
me,
then
either
policy
could
decide
that
I,
don't
that
I'm
not
allowed
in
there
or
they
might
not
be
capacity
in
there
and
then
everything
kind
of
this
there's
much
less
code
for
automated
kind
of
decision-making.
But
if
you
express
in
simple
terms
what
your
actual
constraints
are
that
you
know
I
want
to
be
in
different
clusters
in
the
same
region,
but
I
don't
care
which
region.
Then
then
the.
B
Then
the
scheduler
can
and
the
policy
can
influence
precisely
where
you
end
up
going
within
the
policy
constraints
and
the
availability
constraint
or
other
capacity
availability,
constraints,
etc.
So
that
was
sort
of
thinking
behind
it.
But
I
agree.
There
are
at
least
three
or
four
somewhat
discreet
use
cases,
but
rather
than
come
up
with
a
different
solution
to
each
one,
it
seems
intuitive
be
preferable
to
come
up
with
a
unified
solution
that
can
answer
all
of
those
in
a
fairly
simple
way.
I.
D
Think
I
heard
about
the
implementation
complexity
for
simply
those
chances,
but
I
I
agree
that
this
is
sort
of
it
does
solves
like
it
solves
everything.
You'd
want
to
do,
I,
think
I'm,
just
concerned
about
the
user
experience
I,
hope
the
iterating
might
a
simplified
model
of
this
for
simple
use
cases
maybe
backed
by
more
complicated
I.
Think.
B
D
I
think
I
mean
there's
gonna,
be
utility
in
the
context
of
scheduling.
I
was
kind
of
thinking
in
a
more
restricted
sort
of
sense
of
if
I
had
an
environment
that
wasn't
actually
doing
like
dynamic
scheduling,
but
was
applying
policy
and
you'd
have
a
case
where
the
policy
is
misapplied,
maybe
because
the
labeling
is
bad
or
something
such
that
you
know
the
config
map
would
say.
D
Oh
you're,
going
to
these
clusters
and
they're
replica
set
you're
one
of
these
clusters
and
those
would
be
disjoint
mm-hmm,
and
that-
and
this
would
be
a
way
of
the
users
expressing
something
that
the
policy
engine
could
consider
and
say:
hey.
There
seems
to
be
a
problem
here:
I
try
to
impose
placement
on
these
two
resources,
but
there's
a
dependency
here.
This
won't
be
mad
if
I
do
stick
yeah.
B
E
It's
gonna
ask
like
what,
where
you
saw
this
falling
relative
to
policy
I,
think
that's
this.
A
very
interesting
distinction
to
kind
of
you
know
further
tease
out
the
distinct
like
the
differences
between
like
something
that's
a
primitive.
That
says
this
thing
goes
here
versus
policy
that
says
things
like
this
can
only
go
here
or
conquer
space.
Yeah
like
layer
I
want
these
things
to
go
wherever
they
go
together.
So
I.
E
B
And
I
see
torrents
on
the
call
I
don't
want
to
preclude
OPA
or
or
a
policy
engine
from
be
used
for
application
deployment
requirements,
necessarily
I.
Think
I.
Think
one
could
you
know
with
one
could
allow
a
application
deployer
to
specify
in
the
OPA
language
the
kinds
of
constraints
they're
interested
in
and-
and
you
know
that
would
possibly
be
somewhat
at
odds
with
the
API
I.
B
Don't
know,
maybe
it's
more
to
general
language
for
that,
but
so
when
I
talk
about
policy
and
application
deployment
requirements,
I'm
talking
about
it
from
a
requirements,
point
of
view
not
from
the
implementation
point
of
view,
I
think
you
could
actually
implement
both
of
them
using
something
like
OPA
or
both
of
them
using
an
API
which
is
essentially
what
we
do
right
now.
I
mean
we
have
things
like
quota
and
our
back
and
things
which
are
essentially
policy
users,
don't
specify
they're,
our
back
or
their
quota.
B
C
Think,
as
a
reasonable
I
mean
I
think
the
word
like
the
policy
engine
becomes
useful
is
when
you
have
like
multiple
parties
that
need
to
collaborate
in
some
way
on
like
the
decision
that
gets
made
around
like
placement
or
overrides
or
whatever
right
so,
where
you've
got
like
developers,
mezzanines,
I'm
intent
and
the
administrative
administrators
buying.
Some
like
controls
over
how
placement
should
work.
I
need.
A
C
Way
of
combining
those
things
to
like
run
the
system,
and
so
that's
where
that's
where
the
policy
engine
becomes
useful
because
you
can
program
it
on
the
fly
right.
It's
not
hard-coded!
That's
for
the
power!
You
can
yeah
make
those
decisions
on
the
fly
so
that
that's
what
I
would
sort
of
keep
in
mind
so
I'm
all
for
like
having
these
he's
like
developer
intent,
specified
and
then
also
having
the
ability
to
kind
of
add
in
the
policy
engine
when
you
want
to
have
that
like
control
over
composition.
So.
B
Yeah
I
agree:
I
guess
the
other,
perhaps
useful
distinction
without
going
over
too
far
into
the
weeds
is,
is
that
we
have
a
reasonable
understanding
of
application
deployment.
Technical
requirements,
like
you
know,
I,
want
these
things
close
together,
I
want
them
far
apart,
etc.
These
are
mostly
technical
considerations,
I
think.
As
soon
as
you
step
into
the
policy
world,
many
companies
have
weird
policies
that
are
very,
very
difficult
for
us
to
anticipate
and
they
tend
to
end
up
wanting
to
write
them
in
pretty
sophisticated
languages
and
and
that's
where
sort
of
a
fairly.
E
E
B
E
F
B
Think
we
touched
on
that
at
the
beginning
of
the
call
and
and
I
don't
think,
we've
decided
yet
I
think
we
could
go
either
way,
and
you
know
maybe
the
simplest
starting
point
is
to
have
them
external
to
the
objects,
either
in
the
placement
constraints
or
as
a
separate,
API
type
that
gets
consumed
by
the.
If
there
is
an
automated
scheduler
could
get
consumed
by
those
schedulers
and
then
at
some
point
we
might,
you
know,
incorporate
it
into
one
of
the
other
ones,
and
at
least
we
can
iterate
fast
and
then
do
do
stuff.
E
Some
of
these
ID
is
without
having
to
without
a
user
having
to
pick
take
all
of
them.
So,
for
example,
that
we
had
some
of
these.
If
we
had
the
affinity
concept
as
its
own
resource,
you
could
potentially
apply
that
to
another
resource
that
would
describe
something
like
helm,
charts
or
there's,
there's
a
number
of
other
things
that
are
kind
of
in
the
some
same
space
that
we
can
make
addressable
in
a
resource
that
encapsulated
this
thing.
So
I
think
that's
another
reason
to
at
least
start
with
it
being
a
distinct
idea.
E
D
Not
to
tangent
too
far,
but
when
I
think
about
when
I
start
to
think
about,
like
any
of
defining
defining
a
resource
that
collects
other
resources
for
the
purposes
of
you
know
determining
how
they
should
be
deployed
in
the
proximity
basis.
I
also
started
thinking
well,
once
I've
collected
those
resources
together,
you
know
if
you
select
or
whatever
I
could
also
define
like
things
like
rollout
strategy,
like
the
concept
of
like
I'm,
going
to
reapply
this
application
there's
a
new
version.
You
know.
B
B
You
know
in
kubernetes
you
can
just
go
and
upgrade
a
update,
a
config
map,
for
example-
and
you
know
everything
that
reads-
that
config
map
kind
of
gets
the
update
and
it's
not
entirely
when
each
one
of
them
does
and
it's
not
chaotic,
like
Canaria
changing
config,
whereas
those
are
very
common
things
in
a
multi
cluster
scenario.
You
would
definitely
want
to
like
change
your
config
in
one
pass,
see
if
it
works,
and
if
it
does,
then
you
know
roll
the
new
configure
to
other
clusters,
so
I
think
I.
B
E
E
B
Yes,
closely,
aligned,
but
not
the
same
thing,
yes
yeah
and
you
may
even
find
that
it
is
got
some
crossover
with
policy,
I'm,
not
sure
yeah.
Just
a
thought.
I
know
it
places
like
Google.
There
are
actually
kind
of
like
global
policies
like
you
do
not
roll
out
software
to
all
data
centers
at
the
same
time,
and
that's
kind
of
something
that
groups
like
sre
like
to
enforce
globally,
whereas.
E
Communication,
so
I
am
gonna
drive
I,
never
look
like
a
professor.
If
you
tried
I'm
sorry
to
break
this
to
you,
let
me
draw
it
on
the
whiteboard
now,
and
so
everybody
else
can
see
it
because,
like
this
is
this
is
not
good
enough
to
like
show
but
I'm
thinking
about
these
three
things
that
we're
kind
of
dancing
around
and
I,
don't
know
how
they
relate
to
one
another,
but
it
seems
like
they
do
somehow
so
there's
the
affinity
concept
like
resource.
E
G
E
B
Similarly,
you
may
have
declarative
statements
in
your
policy,
saying
that
you
know
we
we
put
stuff
in
Europe
for
these
reasons,
or
we
put
stuff
in
Google
cloud
for
these
reasons
or
whatever
so
I'm,
not
sure
that
the
declarative
placement
thing
is
super
useful
there
other
than
the
fact
that
it
is
the
way
you
specify
both
of
the
above
other
things,
I
don't
know.
What's.
E
D
Well,
I
could
be
both
I
mean
in
a
simple
system
where
you're,
not
enforcing
administrative
policy,
and
you
just
want
to
say
I
want
this
stuff
to
go
into
this
cluster.
The
clarity
of
placement
is
just
like
it's
a
primitive
way
of
accomplishing
that
call,
and
then
you
can
certainly
have
tools
on
top
of
it
to
take
other
factors
into
consideration
and
I.
Think.
Ideally,
they
all
boil
down
to
this
declarative
place,
but
I
think
would
I
think
that's
what
you're
saying
Quinton
as
well
right,
like
yeah.
D
D
B
B
If
you
want
to
allow
more
powerful
constraints
or
more
generalized
constraints,
like
you
know,
put
it
in
a
PCI
compliant
European
cluster,
then
your
and
don't
put
it
somewhere
where
I
don't
have
quota
and
don't
put
it
somewhere
where
there
isn't
availability
of
resources,
then
your
constraint
satisfier
has
get
more
complicated,
but
but
it
only
has
to
get
more
complicated
if
you
want
to
support
those
kind
of
constraints.
So
if
you
just
say
we
don't
do
those
we
only
some.
We
only
support,
tell
me
the
names
of
the
clusters.
B
D
B
You
know
I
didn't
I
didn't
actually
mean
to
dominate
this.
All
conversation,
I
just
done
some
stuff
in
the
document.
I,
don't
know.
If
there's
anything
else,
people
want
to
talk
about
today
and
you
were
gonna,
go
away
and
think
about
stuff
and
maybe
come
back
with
some
insightful
insights
and
and
I
think
Maru
the
same
it
did
you
guys
everything
you
wanted
to
like
share
beyond
this,
or
is
this
conversation
going
in
roughly
their
direction?
You
wanted
it
to
I.
E
Think
this
conversation
is
going
in
the
direction
that
we
wanted
it
to.
This
has
been
extremely
useful
today,
for
me
at
least
I
I.
Unfortunately,
I
had
to
spend
yesterday
concentrating
on
another
area
of
my
professional
life,
and
so
was
not
able
to
spend
time
thinking
about
this
about
the
discussion
that
we
had
on
Monday,
but
this
is
this
is
definitely
going
in
the
direction
I
had
expected
to
spend
some
time
thinking
about.
E
B
A
But
after
the
meeting
last
time
what
I
have
been
thinking
and
I
have
not
been
able
to
wrap
my
head
around
that
this,
like
we
already
talked
about
that,
we
have
at
one
end
of
the
spectrum
us
until
just
something
placement
associated
with
a
particular
object.
For
example,
there's
replicas
that
you
want
to
specify
that
this
should
be
placed
interests
away
and
not
because
to
be.
E
A
Can
be
mapped
like
what,
if
I
think
in
terms
of
placement
as
a
resource,
it
can
directly
directly
be
mapped
to
the
resource
it
wants
to
be
played.
It
wants
to
place
using
object
reference,
but
that
seems
to
me
that
in
that
case,
and
this
portion
of
information
can
in
fact
be
in
the
same
resource
and
the
object
itself.
B
A
Yeah
so
then
I
have
been
thinking
that
maybe
we
can
have
something
like
if
there
is
a
possibility
that
both
the
direct
objects,
that's
kind
of
a
thing
could
be
there
in
the
placement
objects
or
object
or
multiple
objects
that
we
have
been
talking
about,
which
certainly
overrides
any
other
parallel
information,
which
might
also
be
there
like
label.
Selectors
can
be
there
or
like
what
you
described.
A
Affinity
of
kind
of
stuff
could
be
there
all.
These
are
parallel
information
which
can
be
part
of
same
placement,
object
or
different
objects,
but
the
direct
object,
drift
kind
of
a
placement
elective
overrides
everything
else,
so
particular
if
it
exists,
if
it
doesn't
exist,
then
controllers
or
whoever
is
implementing
the.
B
B
It
just
becomes
yet
another
constraint
in
the
constraint
graph.
That
means
I'm
too
philosophical
about
it,
but
yeah
wouldn't
I,
wouldn't
want
us
to
have
a
strict
hierarchy.
Where
you,
you
know,
only
one
thing
applies
to
a
given
entity
and
you
know:
there's
a
hierarchy
of
them
and
the
most
one
overrides
everything
else.
I
think
they.
Where
there
are
conflicts,
one
could
certainly
imagine
some
things
taking
precedence
over
others.
A
Does
that
make
sense
why
I
mentioned
this
is
because
if
we
say
probably
define
five
different
kind
of
placement
objects
or
I,
don't
know
mean
call
hello
yeah,
we
still
here
yeah,
it
does
I,
you
yeah,
so
why
I
specified?
That
is
that
if
we
have
that
kind
of
hierarchy-
and
it
is
explicit
in
that
case,
the
most
simple
cases
might
be
pretty
simple
to
implement,
whereas
the
more
complex
cases
can
be
handled
by
more
sophisticated.
B
Next
to
some
other
thing,
cetera,
so
I
think
that
is,
and
maybe
that's
the
distinction
you're
trying
to
make
is
absolute
constraints
can
be
tied
directly
to
the
particular
resources.
This
thing
needs
dirt,
or
this
thing
needs
to
go
in
this
cluster,
as
opposed
to
this
thing
needs
to
go
in
the
same
cluster
as
a
certain
thing
and
I
don't
care
which
cluster.
B
Stomach
that
thing
and
I
guess
that
maybe
gets
back
to
what
Marie
mentioned
sorry
I
did
promise
to
shut
up
and
I'm,
not
doing
that
very
well,
but
I'll
I'll
try
a
little
harder,
but
Maru
you
mentioned.
You
know
you
just
want
these
things
to
be
co-located.
I
think
that
was
a.
What
you
expressed
is
a
simple
requirement,
but
is
it
the
case
that
you
don't
want
to
specify
exactly
where
they
co-located
croute
would
just
be
a
matter
of
okay.
B
Okay,
but
but
you
do
recognize
the
distinction
between
specifying
that
resource,
a
and
B
both
need
to
go
into
cluster
X,
which
is
an
absolute
constraint
and
which
doesn't
give
policy
or
placement
any
flexibility
to
choose
somewhere
else
to
put
them,
which
is
different
than
resource.
A
and
B
need
to
go
into
the
same
cluster
Emma,
don't
care
which
one.
D
B
D
B
D
We
need
to
be
able
to
have
it
on
a
per
resource
basis,
so
that
if
I
want
to
apply
some
sort
of
placement
or
affinity
or
any
other
of
these
different
parameters
that
we're
talking
about
for
a
given
resource
via
policy
engine,
it
needs
to
be
a
canonical
place.
To
put
it
and
a
placement
reserved
seems
like
a
poor
fit.
D
D
It
seems
complicated
enough
that,
having
having
the
attributes
directly
on
a
resource
not
only
not
solely
but
for
the
purposes
of
enabling
policy
application
and
maybe
you'd
have
to
you'd,
have
the
resource
based
one
would
be
flexible
for
the
user
and
you'd
have
the
resource
based
way
of
applying
those
rules
so
that
it's
tractable
for
a
policy
engine?
Does
that
make
sense.
Yeah.
B
I
think
I
understand
you
I
think
I
think
we
maybe
need
to
make
a
distinction
between
one-to-one
relationships.
We
have
a
one-to-one
relationship.
You
can
either
put
the
thing
inside
the
resource
because
there's
only
fundamentally
a
one-to-one
relationship,
so
you
need
to
stick
it
in
there
and
status
might
be
a
good
example.
B
What's
going
on,
it
can
just
read
the
resource
and
it's
got
all
the
information
there,
but
then
has
the
downside
that
you
know
we
have
to
agree
and
it's
the
core
resource
and
all
that
stuff.
So
therefore,
we
might
split
it
out.
I
think
we
should
see
that,
as
distinct
from
the
case
where
we
actually
have
something
other
than
a
one-to-one
relationship
where
we
fundamentally
want
this.
B
This
thing
to
be
shared
amongst
multiple
resources
and
whether
that
is
a
place
director
to
say,
like
all
of
these
things
are
subject
to
the
same
placement,
for
example,
or
whether
it
is
a
proximity
requirement
saying
that
these
things
need
to
be
proximate
to
each
other
I
think.
In
that
case,
we
don't
have
much
choice
other
than
to
factor
it
out
because
of
the
fact
that
it's
not
a
one-to-one
relationship,
and
this
we're
going
like
duplicate
stuff
around
the
place.
Yeah.
D
I
mean
I
think
the
distinction
you're
making
is
worthwhile
to
me
it's
kind
of
whether
it's
a
separate
resource
or
in
the
same
resource.
In
this
case,
it's
like
the
key
factor
is
the
fact
that
it's
a
one-to-one
placement
resource
might
apply
to
many
resources.
Yeah
we're
talking
about
Warren,
know
a
one-to-one
relationship
so
that
there's
a
canonical
place
to
put
a
policy
decision.
Yeah.
B
And
I
guess:
if
one
goes
overboard,
you
could
imagine
a
case
where
you
know
you
have
these
single
monocle
thing,
whether
it's
a
placement
who's
also
approximately
come
stranger
whatever,
and
you
could
actually
have
a
controller
that
goes
and
pushes
it
into
all
the
you
know
duplicates
it
into
a
bunch
of
actual
resources,
so
so
that
everything
else
can
only
see
the
I.
Don't
know
it's
just
a
crazy
idea,
but
denormalize
it.
It
has
that.
A
A
The
the
plus
side
that
I
saw
for
this,
like
what
I
was
also
mentioning,
that
the
best
information
about
where
the
object
goes
specifically
with
the
object
of
our
object.
This
is
all
the
other
things
we
are
talking
about.
If
none
of
them
exists,
they
can
still
be
enforced
by
using
maybe,
for
example,
policy.
Engine
externally
decides
which
object
goes
where
based
on
the
labels
or
whatever,
and
then
just
enforce
of
this
on
an
object
basis.
So
this.
A
B
Well,
I
mean
one
solution
is
to
just
not
resolve
conflicts
and
just
say
there
is
no
solution.
So
if
you
have
conflicting
constraints
and
there's
no
solution
that
can
satisfy
all
the
constraints,
you
just
say:
there's
no
solution.
Sorry,
so
that's
the
that's
the
lazy
way
out
of
it
and
Apple
where
there
was
policy.
That
said,
you
can't
go
in
a
and
the
user
said.
B
I
want
to
go
in
a
then
you
just
say
sorry,
there's
no
answer
that
gives
you
both
of
those
so
we're
screwed
and
in
other
cases
you
can
try
and
drop
some
of
the
constraints
in
preference
to
others,
so
that
you
can
find
a
solution
and
that's
a
classic
kind
of
constraint.
Resolution
problem
is
you
take
some
of
the
constraints
and
you
throw
them
away
until
you
find
a
constraint
graph
that
you
can
solve,
and
that
implies
a
priority
of
the
constraints.
D
B
Absolutely
so
debugging
unsolvable
constraint,
networks
is
a
is
a
thing
and
and
it's
there
are
reasonably
straightforward
ways
of
communicating
like
which
constraints
conflicted
and
therefore-
and
you
can
even
come
back
with
a
set
of
you
know.
If
you
drop
this
constraint,
then
everything
would
work.
So
this
is
the
thing:
that's
you
know,
throwing
a
spanner
in
the
works
or
you
can
have
systems
that
drop
that
those
automatically.
So,
for
example,
what
would
be
a
good
example?
B
Yeah
I
mean
one
example
might
be
if
the
user
said
they
wanted
in
this
cluster
and
we
maybe
the
policy
said
all
your
stuff
goes
in
another
cluster,
then
it
would
be
technically
feasible
to
just
say
that
overrides
the
other
one
and
wins
so
you
drop,
you
drop
the
users
requirement
to
go
into
cluster
a
and
you
stick
him
in
cluster
B.
Instead,
in
that
particular
case,
I,
don't
think
it's
very
useful
way
of
doing
it,
but
there
are
other
examples
where
it
is
useful.
B
Which
perhaps
we're
at
a
time
where
we
should
continue
another
time?
Discussion,
though,
because
this
is
all
super
useful,
okay,
I'll
see
if
I
can
find
another
20
minutes
in
the
next
week
to
flesh
out
that
darker
a
little
more.
But
it
sounds
like
there's
a
general
agreement
that
it's
not
a
completely
ridiculous
way
forward
and
we
need
to
flesh
out
the
details.
That's
the
case.
I
will
try
and
do
that
feel
free
to
comment
and
add
your
thoughts
there
as
well.
In
the
meantime,
yeah.
B
E
B
Frightened
your
job
ADA
should
get
in
the
room
and
have
a
wall.
You
can
come
up
with
the
most
esoteric
metaphors,
alright,
just
guys
and
welcome
to
all
the
new
people
we'll
see
you
tomorrow,
I
guess
for
the
Montana
wins
multi
cluster
next
next
week
do
we
have
another
one
of
these
on
Mondays
the
next
we.
E
B
A
B
A
B
Be
useful
here
fun
if
you've
had
the
time
is
to
to
actually
just
sort
of
change
tech
for
a
moment
and
and
have
a
look
at
what
the
outstanding
concrete
dues
are,
that
we
have
right
now.
I
know
you've
been
waiting
through
all
the
Federation
issues
and
identifying
things
that
can
be
fixed
now
and
all
that
do
we
want
to
maybe
on
Monday.
If
you
have
time
to
kind
of
prepare
that
I
could
do
that.
Just.