►
From YouTube: Kubernetes Federation WG Sync 20181205
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
I'm
not
entirely
convinced
that
the
item
on
the
agenda
is
actually
what
we
want
to
be
discussing,
given
that
Q
Khan
is
next
week
would
seem
more
productive
to
focus
on
what
work
items
we
want
to
complete
and
make
sure
there
will
coordinate
in
towards
their
getting
done.
I
know
people
are
working
on
demos,
presentation,
sort
of
stuff
and
working
on
things
that
are
beyond
cute
con
at
this
point,
I'm
not
sure
how
useful
it
is.
B
C
A
Yeah
I
don't
think
we
had
a
last
meeting,
so
we
could
maybe
just
discuss
an
administrative
detail
later
on
so
cute
Khan's
next
week.
So
presumably
meeting
is
canceled,
yes
and
then
often,
post
cube,
Kanna
meeting
is
cancelled
because
people
have
to
travel
or
they're
tired
or
they're
catching
up
or
whatever
I
mean
that's
the
general
convention
I'm
not
suggesting
we
have
to
follow
it,
and
then
we
have
pretty
Christmas
and
Christmas,
which
for
North
Americans
is
maybe
a
fraud
time.
C
Yeah
there's
another
item,
so
the
upbound
guys
who
released
that
crossplane
project
listed
it.
When
did
you
first
learn
they're
quite
keen
to
talk
to
us
and
tell
us
about
what
they've
done
and
also
find
out
what
we're
doing
and
etc
do
do
general
qlae.
So
we
can
do
that
in
the
Federation
meeting,
because
it's
basically
Federation
or
we
can
do
it
in
a
multi
cluster
meeting
I,
don't
really
feel
strongly
either
way.
I.
C
A
So
I've
added
two
items
to
the
agenda:
what
happened
in
cube
con
and
Crocs
playing
Q&A?
What
happened?
A
cube
con
can
just
be
organic,
but
for
the
crossplane
wine
Quentin,
if
you're
in
contact
with
them,
you
want
to
invite
them
yeah.
C
Yes,
I
have
invited
them
already,
Oh
kind
of
great
to
me
and
I
told
them
I'd
put
them
on
the
agenda.
They
they
almost
made
it
today,
but
they're
all
exhausted
after
the
big
launch.
Yesterday's
today
having
a
long
sleep
and
yeah
I
guess,
the
other
item
is
is
the
one
we
have
on
the
current
agenda,
which
I
think
we
decided
to
talk
about.
C
A
C
Day
sorry
I
didn't
interrupt
so
there
was
this
discussion
about,
perhaps
unifying
so
so
I
think
you
mister
meet
the
multi
cluster
meeting
yesterday
Meru
if
I
remember
correctly,
so
the
Google
guys
have
a
draft
API
for
federated
ingress,
which
they
kind
of
developed
independently
of
any
of
our
stuff,
but
what
they
I
think
we're
pleasantly
surprised
that
that
there
was
a
lot
of
duplication
and
so
there's
a
meeting
planned
for
the
next
few
weeks.
I
think
it
possibly
have
to
keep
calm
to
just
figure
out.
C
A
Would
that
be
something
that
cooks
above
an
ingress
resource,
because
I
mean
the
form
of
federated
resources
in
Federation?
V2
is
uniform
and
that's
not
to
preclude
something
higher
level.
Writing
I
like
to
prove
the
whole
idea
of
the
primitive,
so
does
Google
efforts
in
above
the
premise
or
is
it
play
ship.
C
So
it's
it's
a
bad
level
and
they
haven't
actually
implemented
it.
Yet
they're
just
proposed
an
API
which
looks
very
similar
to
our
current
federated
ingress
and
I
proposed
that
that
we
at
least
find
out
what
the
Delta
between
the
two
proposals
will.
You
know
are
implemented
one
and
therefore
posed
one
and
figure
out
whether
it
makes
sense
to
rather
unify
them.
They
have
a
single
API
either
by
adding
two
I
think
there
are
some
shortcomings
and,
if
and
I
think,
or
rather
Shashi.
C
You
missed
the
meeting
as
well
yesterday,
but
we
needed
some
more
detail
from
you
that
we
didn't
have
at
the
time.
I
think
there
are
one
or
two
key
features
that
they
need
and
want
based
on
their
customer
feedback,
but
they're
fairly
minor
and
it
seemed
like
they
could
very
easily
be
added
to
the
ingress
we
currently
have,
and
then
they
could
either
implement
their
own
controllers
or
they
could
use
the
ones
we
already
have,
and
we
didn't
really
discuss
that
much
but
at
least
at
least
try
and
unify
the
API.
B
A
A
B
C
C
And-
and
that
was
my
point
that
I
raised
yesterday
is,
is
you
know?
Why
are
you
implementing
a
new
thing
when
we
already
have
an
implementation
that
essentially
does
just
about
everything
you
want
and-
and
they
were
amenable
to
that
line
of
thinking
and
agreed
to
have
a
discussion
to
figure
out
what
would
need
to
be
added
to
what
we
already
have
to
fulfill
the
API
requirements?
I
mean
they
may
have
other
operational
requirements
that
have
not
yet
been
expressed.
C
You
know
they
they
it's
Google
only
and
it
is
going
to
have
to
obviously
I
assume,
running
gke
and
Google
Cloud,
and
maybe
they
don't
like
our
architecture
under
the
hood
or
something
and
I'm
just
making
up
stuff
now
but
I
think
that's
a
follow-on
discussion.
The
primary
discussion
is,
can
released,
unify
the
API
so
that
users
see
the
same
federated
ingress,
surface
area.
C
A
A
I
guess
I'll
coordinate
with
him
offline,
supporting
work
for
what
he
was
intending
to,
or
we
talked
to
me
about
doing
for
cube
con,
which
was
the
federating
of
resources
via
cube
hub
generic
overrides
and
swatch.
A
base
placement
are
both
toughies
PRS
and
provided
we
get
review
bandwidth
could
be
merged
by
cube
Khan,
it's
probably
a
fairly
substantive
UI
change,
but
hopefully
for
the
better.
In
both
cases.
B
B
A
A
The
first
change
is
generic
overrides
and
this
isn't
full-on
like
JSON
path,
but
it
just
means
that
there's
no
requirement
to
specify
the
path
to
you
override
and
the
type
config
and
any
path
can
be
overridden,
and
this
will
ensure
that
every
Federation
deployment
is
uniform
and
how
overrides
work
versus
allowing
users
to
vary
it
by
deployment
which
would
be
problem
for
support
ability.
Okay
and
the
other
one
was
the
addition
is
selector
based
placements.
A
A
And
that
will
also
allow
solar
funds
workaround
federating
resources.
The
discussions
I've
had
with
him
revealed
that
when
you're
federating
your
resource,
you're,
taking
an
existing
cube
resource
and
saying
I
want
a
federated
equivalent
having
to
explicitly
define
placement
was
problematic,
so
it
selector
based
placement.
That
means
you
can
just
set
an
empty
selector
which
will
select
all
clusters,
which
is
maybe
a
nice
default.
Yes,.
A
A
So
so
my
task
for
next
few
days
and
I'm
actually
off
for
10
days
and
that's
the
attendings
Yukon
but
I'll
be
trying
to
back,
sell
some
of
the
documentation
or
the
changes
that
emerge
in
the
past
month.
So
hopefully
and
people
come
Federation
v2
after
you
guys
get
fantastic
presentations,
Figg
working
groups
or
otherwise
they'll
have
something
that's
a
little
bit
friendlier
or
at
least
up
to
date
with
documentation.
C
A
C
B
C
A
So
I
should
say
like
my
eye,
why
was
the
one
that
raised
this
in
a
meeting
but
I'm
by
no
means
the
only
one
who's
I
think
asked
for
it
in
various
ones,
and
the
rationale
like
on
the
pro
side,
having
these
resources
or
having
the
different
parts
of
a
federated
type,
because
I
think
that,
regardless
of
how
it
representatives
resources,
we
need
a
template
that
represents
the
general
form
of
a
resource.
The
placement
decides
which
clusters
it
needs
to
be
put
in,
and
the
overrides
that
define
per
cluster
variation
and
status
as
well.
A
I
shouldn't
I
shouldn't
forget
that
when
status
was
being
implemented,
Shashi's
initial
approach
was
to
actually
put
it
on
the
template,
resources
and
I
pushed
back,
because
at
the
time,
I
wasn't
very
creative
and
in
thinking
how
that
would
be
possible.
Given
the
versioning
scheme,
we
had
so
those
four
things
whether
they
exist
in
a
single
resource
or
in
different
resources.
That's
that's
the
decision
not
like
what
are
the
components?
It's
just.
How
do
we
come?
How
do
we
actually
represent
the
components?
Yes
and
I?
A
Think
that
the
initial
like
discussion,
that
we
had
you
know
earlier
this
year
around
why
we
should
keep
them
separate,
was
centered
around
like
modularity
and
allowing
pieces
to
be
replaced
and
defined
separately,
evolved
separately
and
when
we
were
talking
architecture,
I,
think
that
made
a
lot
of
sense
and
and
even
if
I
think
it
was
a
useful
effort
to
have
them
completely
distinct
resources.
For
as
long
as
we
have
just
a
sort
of
Center.
A
A
And
if
the
user
wanted
to
vary
that
form,
they
really
would
have
to
fork
the
controller
and
create
it
themselves.
I,
don't
necessarily
think
that's
a
bad
thing.
If
someone
wanted
to
go
off
and
experiment
with,
you
know
different
form
of
these
primary
primitive
resources,
they
could
take
our
code
and
do
it
without
too
much
trouble
and
if
they
learn
things
that
suggested
changing.
A
C
So,
for
example,
a
human
could
create
something
halfway
down
the
paper
pipeline
like
a
what
would
be
the
right
like
as
an
ever
ridden
template,
for
example,
or
some
external
controller
could
generate
that
thing
from
whatever
github
or
anything
else,
and
then
the
rest
of
the
you
know
over
the
rest
of
the
controllers
would
be
oblivious
and
carry
on
doing
this
thing.
So
I
think
that's
a
I
think
that's
a
useful
model
if
we
didn't
end
up
getting
there.
C
If
we
ended
up
kind
of
essentially
building
something
that's
fairly
monolithic
anyway
and-
and
you
can't
replace
any
of
those
pieces
in
the
pipeline,
then
I
think
that's
unfortunate
and
I
think
it
may
be
an
argument
for
fixing
that
problem.
I
tell
you
what
my
two
concerns
are
one
is.
There
was
another
reason
for
decoupling.
The
various
pieces
templates
placements
override
status.
There
were
actually
other
things
in
the
original
design,
which
I,
don't
think
we're
ever
implemented,
and
that
was
around.
C
On
that
note,
and
after
the
fact,
when
you're
looking
at
the
pod,
you
don't
know
whether
you
can
move
that
point
to
another
load
or
you
know,
rescheduled
or
whatever,
or
whether
the
user
actually
requested
that
it
be
put
on
that
mount,
in
which
case
putting
it
on
the
load
is
not
really
an
option.
So
those
were
some
of
the
background.
The
second
observation
or
another
observation
is
that
these
these
primitives
were
not
really
designed
to
be
used
by
end-users.
C
A
So
yeah
I'm
gonna
try
to
go
through
all
of
your
concerns
because
I
think
I
don't
think
there's
any
blocker,
but
I
want
to
maybe
see
if
I
can
do
that.
You
thought
so
on.
The
idea
of
pipeline
I
think
that
that
my
my
view
at
least,
is
evolved
to
have
a
federated
type
and
it's
kind
of
logical
today,
and
it
consists
of
you-
know:
template
placement
override
status
resources,
essentially
a
federated
type
is
a
federated
type
and
it's
the
it's
all
the
details
that
we
need
to
be
able
to
reliably
propagate
to
memory
cluster.
A
That's
why
all
those
things
exist,
there's
nothing
precluding
they're
being
layers
above
the
boiled
down
to
this
fundamental
logical
concept
and
so
to
me
like
the
idea
of
pipelining,
we
don't
preclude
it,
you
don't
necessarily
need
it
for
what
we're
doing,
because
if
we're
gonna
propagate,
we
need
all
these
details
and
who
provides
them.
We
do
not.
We
don't
care,
it's
declarative
anybody.
You
can
write
QAPI,
whether
a
person
or
controller.
A
That's
where
the
data
comes
from,
isn't
the
important
thing,
but
I,
don't
I
think
over
the
past
year.
Certainly,
my
experience
has
been
that
the
logical
form
that
we
have
is
useful,
I'm
breaking
it
apart
into
constituent
pieces,
doesn't
like
like
removing
the
placement
and
I
can
allow
you
to.
You
know,
put
resources
into
clusters
with
any
degree
of
specificity.
A
Removing
the
override
doesn't
allow
you
to.
You
know,
provide
per
cluster
variation
right,
there's
different
ways
to
implement
it
for
sure,
but
I
mean.
What's
there
now
is
like
a
product
of
the
year
of
hard
work
and
experienced
by
everybody.
That's
contributed
so
granted.
We
certainly
could
use
user
feedback
well
anyway.
I
guess
my
my
TLDR
and
the
pipeline
concern
you
have
is
that
what
we
really
define
is
sort
of
the
endpoint
of
the
pipeline.
A
C
I
think
we
might
be
talking
past
each
other
and
I'm
wondering
whether
it
wouldn't
be
useful
to
go
back
to
that
original
diagram,
just
just
so
that
we
both
have
the
same
image
in
our
head
about
what
I
mean
about
a
composable
pipeline
and
and
I
can
totally
believe
right
now,
I
mean,
as
you
point
out,
I
think
a
propagator.
It
needs
the
template
under
placement
and
they
override
and
it
needs
them
all
in
specific
forms,
and
so
it's
dependent
on
everything
and
it
won't
work.
If
you
change
any
of
those
things.
C
I
think
that
might
well
be
true
in
the
current
implementation,
but
that
that
wasn't
the
original
proposal
and
I'm
not
I'm,
not
criticizing
what
we've
got
I'm
just
saying,
I,
don't
think
we
should
necessarily
throw
away
the
concept
because
we
implemented
it
in
a
way
that
didn't
achieve
the
goals
of
the
original
concept.
I
think
that
one
option
would
be
to
do
that,
throw
away
the
concept
because
we
implemented
it
differently,
but
another
alternative
would
be
to
realize
that
concept
and
maybe
Ricky.
Let
me
see
if
I
can
find
that
document
and
projected.
A
A
C
C
E
C
A
C
C
A
We
have
the
essentially
we
have
a
normalized
form
of
the
inputs
to
propagation,
so
we're
not
presupposing
that
these
decisions
are
made
by
anyone
in
particular.
So
we
what
I'm
suggesting
is
that
we
have
a
form
of
this,
but
that
we're
defining
what
the
proper
gate
needs
to
be
fed
with,
because
that's
kind
of
I
mean
whether
we
use
something.
That's
a
like
looks
like
the
cube
object,
or
it
looks
like
our
current
logical,
federated
type.
I
mean
just
a
different
form
of
the
same
thing.
A
We
could
as
well
explode
a
logical,
federated
type
into
individual
cube
resources
intended
for
member
clusters
and
in
fact
we
do
that
at
runtime.
But
the
idea
that
we
needed
to
to
actually
account
for
those
of
runtime
and
write
into
the
API
was
something
that
we
decided
not
to
do
not
saying
that
someone
couldn't
decide
to
do
that
and
write
a
different
propagator
driven
directly
by
you
know
a
resource
that
it
was
intended
to
peer
in
one
of
the
member
clusters.
A
But
I
mean
effectively.
If
you
want
to
be
able
to,
you
know,
have
a
pipelining
mechanism
that
cliff
made
I
mean
we
have
schedulers
today
that
will
make
cluster
placement
decisions
and
will
make
override
decisions.
The
RSP
scheduler
that
F
on
row
is
an
example
of
that
and
it
makes
those
decisions
and
then
it
just
writes
them
into
the
right
place
in
the
logical
federated
type,
whether
it
be
placement
or
overall.
So
we
have
something
with
the
characteristics
of
what
you're
describing
it's
just
implemented
in
a
different
way,
because
yeah.
A
B
You
should
have
a
valid
concerns,
I
think
I,
think
some
of
the
points
Quentin
raised
like
the
who,
who
is
doing,
which
changes
mainly
the
permission
related
stuff
like
whether
is
an
administrator
or
a
developer,
I
think
that's
a
valid
thing
like
we
need
to
be
able
to
distinguish.
I
was
the
actor
and
always
acting
on
those
objects,
so
I
think
if
you
can
I
think
from
a
developer
perspective,
single
ap
type
is
the
I
think
makes
a
lot
of
sense.
Now
it
isn't
too
much
of
complexity
to
maintain
a
lot
of
types.
B
A
Mean
I
think
for
I
think
there's
a
fairly
significant
benefit
for
the
user.
Today,
I
have
to
explain
to
a
user
what
the
different
parts
of
the
logical
federated
resource,
or
we
have
for
today
and
by
placement
override
status
and
if
I
wanted
to
know
what's
going
on
with
my
resource,
why
wasn't
it
put
into
a
cluster
where
do
I
find
that
information
now
and
then,
when
we
discussed
this
internally,
a
Red
Hat,
we've
been
sort.
A
It
from
the
user
perspective
and
going
okay,
I,
create
my
resource
and
then
there's
a
problem.
Where
is
the
problem?
It
was
driven
initially
from
trying
to
federated
Rd,
and
then
you
know,
somebody
who
didn't
I
didn't
have
of
experience
running
into
trouble
with
the
Sierra
t-nut
I
can
see
existing
in
the
underlying
clusters,
and
then
we
had
the
idea
of
putting
status
on
the
Federated
type
config,
indicating
whether
it
was
possible
to
federate
to
member
clusters
or
given
title
and
then
it
was
like.
Well,
how
would
we
troubleshoot
other
problems
like
if.
C
C
A
Sometimes
you'd
be
able
to
detect
when
you
instantiate
a
controller
that
member
clusters
would
not
be
able
to
be
propagated
to,
but
sometimes
those
those
problems
wouldn't
actually
be
detectable
until
we
tried
to
propagate
a
resource
and
how
would
you
discover
that
and
logging
is
certainly
one
answer,
but
I
don't
think
it's
the
only
answer.
So
the
idea
of
having.
B
A
Separate
like
as
much
as
I
was
you
know,
I
pushed
you
shashi
to
separated
into
a
separate
controller
and
a
separate
resource
for
technical
reasons.
When
I
was
considering
how
someone
troubleshooting
problems
with
propagation,
it
was
like.
Oh
that's
kind
of
ugly
I
have
to
know
you
know
my
federated
I
know.
I
have
to
really
internalize
what
a
logical
federated
type
is.
I
understand
that
probably
the
place
I
have
to
go.
Look
is
the
status
resource
if
Status
collection
is
even
enabled,
which
seems
kind
of
problematic.
A
From
the
perspective
of
diagnosing
problems
that
are,
inevitably,
you
know
Kirk.
So,
from
my
perspective,
putting
everything
in
one
place
means
that
it's
a
one-stop-shop
for
the
user.
If
they
want
to
change
something
about
a
federated
type
in
one
place,
they
want
to
discover
there's
a
problem
with
propagation.
It
can
be
in
one
place.
The
permission.
A
That's
definitely
something
I'm
I,
don't
want
to
ignore
the
challenge
of
separating
sorry
of
merging
the
types
is
we
no
longer
can
easily
just
apply
our
back
permissioning,
so
the
placement
would
be
determined.
You
know
a
separate
permissions
from
override
or
template.
I
think
that's
something
we
can
work
around.
If
and
when
it
becomes.
You
know
requirement
with
webhook
sonication,
so
I
don't
think
it's
not
precluding
that
possibility
by
merging
the
resources.
A
Similarly,
with
auditing
I
mean
there's
any
number
of
web
clerk
options
for
intercepting
requests
and
performing
secondary
operations
like
auditing
like
commissioning
so
I.
Don't
think
we're
precluding
that
just
that
we
we
don't
have
definitive
use
cases
for
that,
so
I'm
not
sure
like
deciding
to
avoid
simplifying
things
for
the
user.
I,
don't
think
we
have
good
news
cases
to
push
back
against
the
simplification.
At
this
time,
I
mean
if
people
want
to
develop
those.
Let.
C
Another
which
which
is
actually
driving
a
lot
of
the
stuff
which
is
you
know,
we
started
with
a
consolidated
API.
We
then
you
know
several
years
ago
in
our
country
member
three
four
years
ago,
Federation
t1
and
then
we
decided
to
stop
work
on
that
react,
attack
the
whole
thing,
break
it
up
into
pieces,
etc.
C
Then
we
didn't
actually
realize
the
goals
of
that
exercise,
because
we
ended
up
with
the
implementation.
We
have
now
almost
I
guess
close
to
four
years.
Three,
four
years
since
we
started,
we
are
now
changing
back
again
to
something
that
looks
remarkably
similar
to
the
one.
But
this
is
the
proposal.
C
Essentially,
in
the
meantime,
people
like
crossplane
have
gone
and
implemented
all
of
this
stuff
and
a
whole
bunch,
more
and
so
I
think
I
think
we
have
a
very
real
risk
here
that
the
world
leaves
us
behind
and
because
we're
so
busy
noodling
and
re
noodling.
We
still
have
alpha
api's
across
the
board.
After
three
and
a
half
years.
C
A
C
C
C
A
Difference
here
is
that
were
the
underpinnings
here
are
extremely
flexible
and
we
consider
eight
anything
and
we
can
do
it
without
writing
code
and
so
to
me
this
is
just
kind
of
like
cleaning
it
up
and
and
putting
it
in
a
position
where,
yes,
we
can
go
GA,
we
have
all
the
pieces,
we
have
all
the
functionality
and
we're
presenting
it
as
simple
a
form
as
possible.
So
to
my
mind,
this
is
like
this
is
kind
of
the
endpoint.
Everything
else
that's
come
before
is
enabled
us
prior
to
a
lot
of
the
work.
That's
long.
A
In
the
past
few
months,
it
was
riffle
to
evolve
the
form
of
the
federated,
the
logical
federated
type,
now
we're
we're
generating
them
in
such
a
way
that
evolution
is
actually
really
easy,
like
I've
implemented,
generic
overrides
and
selector
based
lights,
and
it's
a
matter
of
a
couple
days
in
previous
a
lot
of
the
underpinnings
like
the
underlying
changes
that
have
been
like
weeks
of
work.
So
I.
A
A
Versus
laborious
least
and
ones
doing
stuff,
so
so
the
my
way
of
thinking
is
simply
like.
If
we
can
get,
you
know
unified
if
we
can
clean
up
the
UX
prior
to
beta
and
GA
I
want
to
do
with
that.
Like
to
my
mind,
this
is
like
this
is
sort
of
the
last
period
of
time
where
I
could
reasonably
hope
to
make
this
change
and
not
impact
enough
people
that
it
would
be
a
huge
problem
and,
as
you
say,
would
be
like.
A
Oh
god,
there's
churn,
but
at
this
point
like
we're,
really
nasty
and
we
haven't
really
gotten
a
lot
of
mindshare
it's
starting
to
grow,
but
now,
to
my
mind,
it's
kind
of
Now
or
Never.
For
some
of
the
reasons
you're
saying
we
shouldn't
make
it
I'm
saying
we
really
should
we
should
do
it
now,
because
we
can't
you
know,
but
we
can
anticipate
being
able
to
do
it
going
forward.
I
just
I
want
a
better
user
experience.
A
C
C
C
A
I
mean
I'm
not
precluding
the
higher
level
stuff
at
all.
This
isn't
a
suggestion
that
we
need
to
just
focus
on
this
unified
resource
is
the
only
touch
point
for
Federation.
It's
mainly
that
I
want
to
unify
the
primitives
into
one
resource
so
that
anybody
who's
using
it
at
that
level
has
a
good
experience,
but
I
mean
if
you,
if
you've,
read
the
cross
plane
document,
they
mentioned
Federation
the
possibility
of
maybe
leveraging
it,
and
so
the
idea
that
it
would
maybe
be
something
that
you
know
I.
A
F
Good,
how
receptive
would
folks
be
to
leave
the
primitives
in
place,
as
we
have
them
today
and
create
a
new
resource
type
like
workload
to
to
correlate
to
the
cross,
plane,
stuff
or
federated
whatever?
That
is
constructed
with
the
primitives
in
it,
and
you
don't
really
work
with
the
lower
level
primitives.
You
just
work
with
this
as
the
implementation
for
the
push
reconciler
to
work
with
just
this
sort
of
combined
resource
and
it
and
leave
it
as
like.
A
push.
Reconciler
implementation
detail.
C
C
F
Sounds
to
me,
like
it
sounds
to
me
like
perhaps
having
a
new
resource
that
is
constructed
of
the
existing
primitives,
is
something
that
would
simplify
the
push
reconciler
as
it
all
would
only
need
to
work
with
one
resource,
and
it
makes
a
lot
of
the
details
that
have
been
brought
up
in
the
meeting
more
doable
and
easier
to
work
with,
on
top
of
making
the
user
experience
more
streamlined.
If
that's
the
case
and
the
existing
primitives
stay
intact,
there
could
potentially
be
a
way
to
have
it
be
leveraged
for
other.
Reconciling
mechanisms.
C
C
A
C
A
F
A
Why
would
consider
what
the
unified
resource
would
look
like?
It
would
be
an
API
type
with
the
same
details
that
are
currently
present
in
the
individual
resources.
If
someone
wanted
to
reuse
that
resource
and
specify
the
template
field,
but
not
place
when
there
are
variety
or
specify
the
placement
field,
there's
not
template
or
override.
A
How
is
that
really
like
a
problem
like
the
form
is
the
same?
It's
just
in
one
place
and
if
you
don't
want
to
use
any
one
piece
of
it
just
like,
if
you
don't
want
to
define
a
field
in
a
deployment
or
a
secret,
you
just
don't
set
a
value,
but
the
data
structure
is
the
same
for
the
fields
you
are
defining.
A
F
A
Mean
they're,
essentially
the
same
data
just
composed
so
I
I
think
you
know.
If
you
have
one,
you
don't
need
the
other.
If
we
decided
to
stick
to
individual,
primitive
resources
versus
a
unified
resource,
the
same
it's
just
simpler,
have
them
all
together
and
the
idea
I
mean
even
you're.
Talking
pipeline
requirements.
Sorry
go
ahead.
I
was.
C
Gonna
say:
I
need
to
drop
off
now,
unfortunately,
and
I
think
it
would
also
be
good
to
have
ear
fun
in
this
discussion.
So
we're
really
out
of
time.
Maybe
we
can
defer
to
those
of
you
who
will
be
in
Seattle.
We
can
talk
about
this
further
there.
There
are
a
couple
of
Federation
multi
cluster
meetups
and
presentations
and
things
so
they'll
be
performed
there.
If
anyone
wants
to
talk
about
it
and
then
we
can
catch,
you
know
continue
in
two
weeks
time
at
this
music.
D
B
D
Guess
one
last
point
on
that
is:
maybe
it
makes
sense
either
in
the
agenda
or
some
document
that
just
talks
about
the
two
approaches.
It
seems
like
that's
really
what
the
discussion
is
is
and
introducing
a
new
overarching,
type
or
kind
of
bundling
all
three
of
the
existing
primitives
into
a
new
type
right,
and
it
just
may
make
sense
to
document
those
two
approaches
and
just
start
listing
the
pros
and
cons
and
I
think
or
at
least
from
a
couple
weeks
ago.
D
F
A
D
Yeah
and
from
my
standpoint,
Maru
I
see
where
you're
coming
from
and
if
there's
really
no
one
using
the
primitives
today
or
they're
using
them
just
in
like
a
I,
have
environment
kicking
the
tires
great
now,
if
someone
is
using
them
and
we're
saying:
okay,
we're
gonna
make
these
big
changes
and
I
know
that
will
be
a
little
bit
of
heartache
for
them,
but
I
guess.
It's
also
expected,
since
its
alpha.
A
B
The
other
point
here
is
like
we
need
to
really
have
all
these
iron
level
API
to
be
something
close
to
like
multi
cluster
app.
It
is
not
just
federating,
maybe
maybe
we
need
to
include
some
concepts
like
how
they
forget
it,
maybe
in
what
order?
Maybe
true
use
the
case
from
a
multi
cluster
application
scenario,
but.
B
A
Resources
right
we're
talking
about
applications,
which
is
something
we've
touched
on.
We've
thought
about.
Maybe
using
like
the
application.
Crd
that
say,
gaps
has
been
working
on
seems,
like
you
know,
crossplane
as
they're
our
own
sort
of
ideas
about
what
an
application
is,
but
I
really
want
to
underscore
that
what
we're
doing
is
still
still
low
level
like
Zack
there'll,
be
one
type,
it'll,
simplify
it
for
some
users,
but
the
idea
of
scheduling
individual
resources
has
never
made
a
huge
amount
of
sense
like
scheduling
a
replica
set
or
deployment.
What
does
that
mean?
A
A
You
know
configuration
the
farm,
consume
outs
or
secrets,
and
if
we're
not
scheduling
that
entire
set
of
resources
into
a
cluster
and
rescheduling
it
all
into
another
cluster,
then
we're
not
really
being
that
helpful
in
my
mind
and
the
primitive
stuff
and
the
sink
controller.
That's
a
low-level.
That's
designed
to
you
know:
I
had
a
high-level
op
definition.
I
could
generate
logical,
federated
types
and
then
make
sure
that
would
make
sure
that
the
resources
individually
go
to
where
they
need
to
go
like
the
way
cube
is
architected
suggests
that
we
want
this.
A
You
know
type
base
controller,
but
that's
that's
not
sufficient
for
something
to
be
really
useful,
I,
don't
think
so
anyway.
I
think.
That's
me
violently
agreeing
and
way
too
many
words
and
I
to
me,
like
I,
think
we're
converging
on
something
where
the
lower-level
stuff
is
basically
done.
That's
where
I
want
to
be
I
want
to
be
like
the
sink
controller
and
a
lot
and
like
federated
types.
That's
that's
a
given,
that's
like
just
air,
and
then
the
community
can
focus
on
actually
building
things
on
top
of
it
that
are
genuinely
useful,
they're,
fun
yeah.
A
D
Can
I
just
go
back
to
that
question
that
I
posed
to
you
is?
Is
it
if
the
with
the
approach
of
introducing
a
kind
of
a
higher
level
resource
and
then,
if
the
lower
level
primitives
are
not
being
used
in
the
future
and
just
eliminating
them
so
kind
of
a
migration
strategy,
as
opposed
to
you
know
an
all-out
replacement
at
this
point?
What's
your
feedback
on
that
I
mean
what
are
your
concerns
with
taking
more
that
approach.
A
A
Me
having
to
maintain
two
separate
code
box,
given
the
size
of
our
development
community
is
problematic.
We
could
do
it,
but
I
kind
of
view
this
as
we're
making.
You
know
the
last
breaking
change
like
most
of
the
changes
up
till
now,
just
been
like
iterative
like
stuff
like
adding.
You
know,
engineer,
equation,
thoughts,
okay
or
sorry
so
watch
the
base
play
some
in
our
generic
overrides,
like
that's
more
additives.
This
is
this
is
a
fundamentally
breaking
change,
because
people
have
been
using
Federation
with
the
separated
primitives
they're
gonna
have
to
change.
A
They
do
it,
but
really
it's
just
copy
past
taste
like
take
the
field
you
used
to
have
in
your
place
and
resource
pull
it
into
unity.
I
mean
I,
guess
my
suggestion
would
be.
We
could
probably
create
a
capability
within
cube
pad
temporarily,
like
not
for
long-term
maintenance.
That
would
take
the
individual
resources
and
merge
them
and
we
could
maybe
gauge
interest,
but
I
guess
for
me,
it's
a
use
case
driven.
Do
we.
A
Who
are
genuinely
committed
to
the
existing
broken
apart
federated
type
scheme,
and
if
so,
we
can
find
ways
to
transition
them
to
this
new
way
of
doing
that,
if
not,
that
we
can
just
transition
but
yeah.
My
assumption
is
we
don't
have
anybody
using
this
in
production?
There's
a
resource
well
enough
to
deal
with
the
change
and
if
they
are.
A
Would
hope
they
would
speak
up
in
the
meetings
if
they're,
using
in
production
and
they're
not
engaged
in
the
community
they're
really
setting
themselves
up
for
failure
yeah
at
least
pre-beta
and
pre
GA.
It's
just
yeah.
It's
really
hard
to
use
something!
That's
evolving!
Underneath
you,
unless
you
have
a
stake
and
the
conversations
with
people
of
all
the.
D
D
B
But
in
case
of
Sun
I
think
it
only
partially
helps
the
rebalancing
would
still
not
work
out.
Only
in
the
initial
case,
maybe
we
can
just
distribute
the
jobs
nuts
it
rebalancing
would
still
not
work
later.
If
some
jobs
are
not
able
to
execute
for
completion,
we
couldn't
rebalance
into
another
cluster
because
of
what
they
call
immutable
fields.
Right
I
mean.
C
A
F
My
my
initial
suggestion
on
how
folks
would
be
receptive
to
that
idea
is
just
more
focused
around
kind
of
developing
a
compromise.
I
think
it
is
simpler
for
the
push
reconciler
to
work
with
one
consolidated
resource
and
there's
no
need
to
necessarily
unless
other
users,
as
the
points
are
brought
up,
unless
other
users
are
still
using
the
primitives
and
would
not
welcome
a
breaking
change
like
this.
F
We
don't
necessarily
have
to
support
using
primitives
any
longer
and
can
move
to
one
resource,
and
if
there
is
some
sort
of
hesitancy
around
just
removing
the
primitives
entirely,
then
maybe
those
can
be
moved
to
beta
and
call
it
good
and
those
can
be
published
to
a
separate,
API
repo,
but
potentially
for
no
one
to
even
use.
So
there
may
not
be
value
in
doing
that,
and
so,
but
if
there
is
that
hesitancy,
maybe
that
is
a
compromise
that
we
can
do
and
we
don't.
B
F
A
B
A
It
will
I
mean,
like
I,
said,
like
the
form
I'm
having
trouble
sort
of
providing
a
good
way
of
conceptualizing
this,
but
like
the
data
that
we're
using
doesn't
change
like
we
still
need,
you
know,
template
placement
override
those
still
exist
as
concepts,
but
instead
of
being
separate
resources,
they're
just
filled
in
one
resource.
So
to
me
it's
like
there's,
no
there's!
No,
you
can't
use
cases.
I
can
think
of
we're
having
those
in
separate
resources
versus
one
resource
provides
us.
A
You
know
any
benefits
like
I
shouldn't
say
that
they're,
the
only
one
that
I
can
think
of
is
is
the
permissioning
and
in
the
past
that's
been
one
of
my
justifications
for
keeping
things
separate.
Is
we
maybe
want
to
have
separate
barback
permissions
on
placement
override,
maybe
for
the
purposes
of
applying
policy
decisions,
but
I,
don't
think
like
the
fact
that
we
can't
use
our
back
directly,
we
can
always
do
web
validation
to
provide
differential
permission.
A
So,
to
my
mind,
that's
the
out,
like
the
one.
The
primary
reason
that
I
was
saying
things
needed
to
be
separate
like
beyond
anything
else
was
I
want
to
be
able
to
apply
different.
You
know
authorization
requirements
on
the
different
parts
of
a
logical,
federated
type
and,
to
me
the
whether
or
not
this
is
a
good
idea
really
just
hinges
on
the
people
believe
that
you
know
permissioning
can
be
accomplished
with
webhook
or
not.
If
you
can
then
not
to
me,
that's
a
walk,
but
that's
the
only
technical
reason
why
this
shouldn't
happen.
A
Everything
else
that
I've
heard
seems
largely
theoretical
and
that's
not
to
say,
I'm,
just
missing
it
I'm,
just
if
I
had
use
cases
that
were
like,
we
really
need
to
keep
them
sacra.
For
this
reason.
For
this
reason,
for
this
reason
you
know
we
have
users
that
want
to
do
this,
and
that
really
requires
be
structured
in
this
way.
They're
separate
resources,
not
to
me,
would
be
really
good.
Rush,
Nell
and
I
wouldn't
be
like
we
have
to
do
it
anyway.
I
just
haven't
heard
any
compelling
reasons
yeah.
A
So
in
the
intervening
time
between
now
and
the
19
I
would
encourage
everyone
to
to
find
justification.
If,
indeed,
you
have
an
interest
in
keeping
things
with
separate
resources,
so
I'm
yeah
I'd
like
to
be
convinced
I,
don't
want
to
feel
like
I'm
trying
to
impose
something
stupid
on.
You
know
unreasonable
on
everyone
that
makes
sense
yeah
and
yes
to
argument
about
those
I
guess
I've
thought
a
lot
about
it
in
my
hat
and
it's
good
to
finally
bring
it
out
of
the
open,
and
hopefully
we
can
find
consensus
over
the
coming
weeks.
B
I
think
we
all
do
agree
about
that.
One
point
at
least
like
there
should
be
an
API
which
consolidates
all
these
things,
but
whether
the
primitive
should
be
along
with
it.
That's
a
quite
a
contention
actually
yeah
I
think,
depending
on
the
usage,
maybe
we
can
remove
it
yeah
either
way,
I
think
yeah.
It
should
be
fine.
I
think
we
should
go
ahead
with
the
consolidated
type
representing
all
of
this
yep
yeah.
B
Let
me
apologize
first
I
think
I
did
miss
whole
one,
our
fruitful
discussion,
and
that
was
because
my
mind
clock
somehow
moved
that
daylight-saving
only
for
this
week,
because
I
attended
yesterday,
Sigma
Sigma,
stressing
at
11:00
somehow
I
thought
that
this
is
inaudible.
So
one
question
is:
was
Quentin
there
on
this
call
earlier
he.