►
From YouTube: Kubernetes Federation WG sync 20180404
Description
See this page for more information: https://github.com/kubernetes/community/blob/master/sig-multicluster/README.md
A
A
A
A
D
C
Okay,
so
on
the
agenda
asked
for
the
meeting
notes
about
taking
notes.
Quinton
did
put
something
I
think
he
has
put
the
same
thing
in
montigue,
less
toxic
meeting
notes
also
that
we
need
to
prepare
of
an
years
roadmap.
It's
not
specific
to
the
stuffings
of
a
loan,
but
we'll
be
good
at.
We
can
probably
think
about
what
we
intend
to
be
rocking
in
long
term
and
not
necessarily
restrict
to
that
description
to
this
meeting.
C
B
I
think
that
it
would
be
good
to
put
a
road
map
together.
We
might
we
might
find,
as
we
go
through
the
agenda
today,
that
we
may
have
some
ideas
floating
around
for
like
the
next
one
or
two
months.
That's
probably
a
good
place
to
start,
and
we
can.
We
can
build
on
that,
provided
that
we
have
similar
visions
for
at
least
what
we
want
to
do
in
the
next
few
months.
B
C
Okay,
so
so
I
was
in
the
process
of
after
after
we
had
the
consensus
and
the
cited
that
we
will
work
in
the
same
type
or
possibly
in
different
groups.
If
there
are
items
which
we
want
implement
a
very
different
and
different
controllers
in
that
case,
so
the
main
item
I
mentioned
in
the
last
meeting
was
that
I
would
be
focusing
on
and
trying
to
implement
an
automated
loop,
something
similar
to
what
is
there
in
tradition
v1
as
of
now.
C
So
there
are
two
things
which
I
need
to
implement
to
API
is
basically
so
one
is
reddit,
its
data
status
and
the
other
one
is
the
scheduling,
but
for
the
given
resource
so
I'm
trying
to
do
that
for
deployments
first,
and
my
intention
is
that
for
a
picker
sets
also,
it
will
be
pretty
much
similar.
So
there
were
a
couple
of
thoughts
that
came
to
my
mind.
I
have
I,
have
I,
have
tried
generating
code
for
federated
status
as
individual
resource
for.
C
Template
so
we
have
a
federated
status
as
one
resource,
just
like
placement
or
and
overrides
intently.
What
it
stores
is
similar
to
placement
status,
which
is
of
the
type
which
is
equivalent
to
the
status
in
the
template
type
and
that's
stored
against
each
cluster
in,
in
view
off
to
the
scheduling,
there
is
some
place
where
we
need
to
advocate
this
also.
So
there
are
two
three
different
ways
we
can
represent
the
status.
One
is
singular
resource
which
is
of
federated
status
for
each
type.
Another
is
individual
resources
which
are
resources
per
cluster.
C
C
C
So
the
other
other
thought
is
that
the
way
it
is
implemented
in
v1,
we
can
do
it's
very
similar
to
that.
Also,
if
the
way
it
is
implemented
in
v1
is
that
the
status
is
read
is
read
in
the
same
Deacon
sign
loop,
it
is
persisted
in
memory
and
it
is
collectively,
then
represented
in
the
Federation
object.
So
in
that
case,
so
what
I
mentioned
is
two
approaches.
One
is
one
status
fee
or
one
status
effect,
which
is
which
stores
only
individual
status
fields,
probably
some
ex-wives.
E
C
F
E
E
B
So
I
think
we
might
be
talking
about
a
couple
slightly
different
things
here,
so
I
or
fun.
If
I
understand
correctly,
what
you're
talking
about
is
a
way
to
get
at
the
status
of
the
actual,
for
example,
replica
sets
that
are
scheduled
in
the
individual
clusters
right
and
there.
There
are
two
different
types
of
views
that
we've
talked
about
previously.
That
you've
touched
on
here
that
people
might
want.
B
One
of
them
is
the
view
where,
like
you
want
to
have
a
view
of
status
that
doesn't
expose
you
to
the
details
of
what's
happening
in
each
cluster
that
is
similar
to
like
Federation
v1,
where
the
status
information
is
just
like,
like
basically
summed
and
put
into
the
status.
That's
the
same,
one
is
the
b1
type,
and
then
there
are
there's
another
like
on
the
other
end
of
the
the
spectrum
there.
There
are
folks
that
want
to
have
like
a
list
of
in
cluster
X.
This
is
the
status
of
this
replica
set
in
cluster
Y.
B
This
is
the
status
of
this
replica.
Center
right
am,
I
look.
Are
you
with
me
so
far?
Yes
and
so
I
I
think
that
this
and
I
think
Maru.
You
may
be
understood
or
fun
differently
and
if
I
understand
you
correctly,
Maru
you
were
talking
about
status
of.
Is
this
propagating
correctly
right
is
X
or
Y
resource
propagated
into
the
clusters,
where
it's
supposed
to
be
correctly.
E
To
my
mind,
status
is
always
just
for
the
user
right,
it's
not
something
you
would
actually
consume
in
any
way,
shape
or
form.
It's
basically
summary
information
and
then
I
wanted
to
actually
have
information.
Drive,
scheduling,
I
would
derive
that
from
the
actual
state,
rather
than
relying
any
persistent
state.
So
to
me,
they're
just
kind
of
separate
things,
regardless
of
how
its
implemented
in
d1
right.
B
B
I
and
I
I
think
we've
talked
about
this
before
so
do
we
need
to
talk
about
here
whether
this
is
a
valid
idea,
or
do
we
just
need
to
talk
about,
since
we
don't
expect
everybody
to
agree
on
every
single
thing?
What
we're
the
right
place
to
put
it
is
is
so
that
we
don't
have
to
block
one
another
from
doing
the
things
that
you
think
we
need.
C
That
yeah
yeah
I
thought
I
thought
murder
was
gonna,
say
something
so
Maru
I
differ
a
little
bit
on
your
view
that
I
did
not,
or
maybe
I
did
not
clearly
understand
what
you
meant.
You
said
that
status
probably
is
not
consumed
by
the
system.
It's
only
for
the
users
view,
or
it's
useful
only
to
the
user.
According
to
me,
status
can
also
be
consumed
by
the
system
as
the
feedback
from
from
underlying
clusters.
If
we
are
building
an
automated
system.
C
E
There's
two
pieces
to
us:
there's
status
in
the
underlying
cluster,
like
the
replica
account
of
a
replica
set
or
a
deployment,
for
example,
betting.
That's
an
attack
that
would
be
consumed
by
a
scheduling
component.
What
I'm
suggesting
is
that
the
aggregated
replica
count
there's
that
consuming
the
aggregated
serialized
like
written
to
the
API
value.
It's
almost
guaranteed
to
be
out
of
sync
a
good
chunk
of
the
time
and
therefore
like
if
I
was
a
scheduling
component
rather
than
watching
a
local
resource,
which
is
the
computed
result
of
the
underlying
cluster
status.
E
Instead,
I
would
want
to
have
a
watch
on
the
underlying
clusters.
Replica
sets
or
deployments
and
I
would
read
their
statuses
and,
as
they
changed,
I
would
update
my
in-memory
representation,
because
that
would
be
the
only
useful
way
to
do
scheduling.
So
my
suggestion
is
serialized
aggregated
status
in
the
Federated
API
is
useful
for
a
user
to
have
a
sense
of
what's
going
on,
but
I.
Don't
think
that's
good
enough
for
scheduling
purposes.
Does
that
make
more
sense,
yeah.
C
It
doesn't
so
how
I
understand
this.
What
you
are
saying
is
that
actual
feedback
is
about,
for
example,
if
we
say
they
complete
something
in
the
case
of
a
replica
set
monitoring
the
pods,
the
actual
parts
of
each
question,
what
they
are,
that
might
be
the
feedback
to
the
shilling.
You
know,
rather
than
the
status
section
in
the
of
the
individual
replica
sets
in
the
question
right.
I
think
I.
Think.
E
We're
I
don't
know,
maybe
I
was
mistreating.
You
before
you
were
talking
about.
The
thing
that
was
I
think
was
confusing
me,
as
you
were
talking
about
status
like
federated
status
in
the
same
context,
is
scheduling,
to
my
mind,
they're,
solving
different
problems.
One
is
determining
you
know
how
you're
gonna
propagate
things
and
the
other
is
giving
feedback
to
the
user.
E
But
in
terms
of
like
where
you
get
an
indication
of
what
the
replicas
count
is
any
given
cluster
like
I'm,
not
suggesting
you
watch
pods
I'm
suggesting
you
watch
because
I
think
we
they're
just
a
miscommunication
I,
think
I'm
guessing
what
I'm
talking
about
was
what
he
originally
said
and
I
just
misunderstood.
You
so.
B
The
question
of
what
the
input
the
scheduling
is
aside,
I
I,
do
think
it's
very
useful
to
have
status
some
different
concepts
of
status
so
that
we
can
easily
like
present
users
with
the
status
that
you
know
it
might
be.
It
might
be
out
of
date,
just
like
any
other
kubernetes
resource
might
be
out
of
date
at
some
point,
but
having
a
way
for
a
user
to
query
a
resource
and
see
oh
okay.
Well,
last
time,
last
time
this
information
was
current.
B
C
Something
that
we
agree,
I
agree
to
what
you
are
saying
all
and,
as
I
mentioned
to
me,
currently
the
use
use
of
statuses
to
the
users
and
a
possible
feedback
to
the
scheduler
we
can.
We
can
have
review
of
the
same
thing
when
when
I
copy
implemented,
but
yeah
I-
think
I
did
mention
this
earlier.
Also
that
most
of
the
concepts
that
I
am
going
to
implement
in
this
scheduling
type
is
very
similar
or
are
borrowed
from
we've
an
implementation.
So
it's
not
very
different
from
that.
Yeah.
B
That
makes
sense
to
me
and
from
what
I
stick,
what
did
I
understand
about
like
the
use
cases
and,
like
you
know,
just
places
that
books
on
Huawei
side
are
coming
from
in
terms
of
how
they
think
about
it?
It
makes
sense
to
me
that
I
would
look
like
like,
like
an
in
this
particular
case,
that
your
vendor
would
be
most
interested
in
something
that
looks
like
a
b1
status
I,
so
here's
here's.
What
I
would
suggest
is,
let's
put
these
different
flavors
of
status
into
two
different
API
groups,
and
they
could
be.
B
Let's
see,
I
are
fun
when
we
were
talking
about
this
earlier
I
kind
of
made
up
names
you
we
could
have
like,
we
could
have
like
aggregated
dot
status,
that
Federation
Kade
Co
for
like
aggregated
flavors,
and
we
could
have
exploded
dot
status,
top
Federation
decades
that
IO
for
people
that
want
a
list
of
in
cluster
X.
This
is
the
status
of
the
resource
and
in
close
to
Y.
This
is
the
status.
What
folks
think
about
that
I.
C
B
B
So
do
we
want
to
choose
names
for
these
things
now
or
a
that?
That's
probably
not
as
super
great
use
of
time.
If
we
can
maybe
just
agree
for
now,
then
we'll
put
them
into
distinct
API
groups.
That's
probably
the
best
outcome
from
this
discussion.
Her
finding
is
that.
Do
you
think
that
satisfies
you
for
now?
Yes,.
C
B
That's
that's
a
good
question,
so
I
would
I
would
say
that
it's
probably
best
to
have
two
separate
controllers,
so
one
can
do
one
can
maintain
like
the
status
that
looks
like
v1
and
one
can
maintain
the
exploded
one
and
then
we
don't
have
to.
We
don't
have
to
have
one
complicated
thing
like
we
can
have
to
slightly
less
complicated
things.
I
guess.
C
D
C
B
The
we
we
had
the
repo
donated
to
kubernetes
SIG's.
There
was
a
thread
on
the
on
the
mailing
list
for
this.
That
Brian
wound
up
removing
the
lists
from
where
it
looks
like
there's
some
legal
hurdles
that
were
missed
before
we
donated
the
repo
there's
a
helpdesk
ticket
open
with
the
CN
CF
helpdesk
to
sort
through
them,
but
they
they
asked
if
we
would
temporarily
move
the
repository
back
to
Murray's
user,
something
that
I
found
to
be
interesting,
which
I
personally
hadn't
picked
up
on
at
all
in
two
different
SIG's.
B
We
are
gonna
work
through
this
and
there's
like
I
said
it
helpdesk
ticket
open,
but
basically
the
process
wasn't
very
well
defined,
so
I,
don't
I,
don't
know
what
the
ETA
will
be
after
this
meeting,
I'm,
probably
going
to
see
if
I
can
get
a
feel
for
what
that.
What
that
might
be
I
don't
have
an
immediate
answer
now.
Maru
is
that
is
that
a
concise
enough
synopsis
of
the
email
thread
yeah.
C
B
B
B
G
F
D
C
Okay,
yeah.
Well,
while
doing
this
I
also
stumbled
across
I
was
like
I
haven't
because
I
have
personally
not
Xcode.
This.
Has
anybody
actually
explored
the
usage
of
Kubizek
cube
CTL
against
the
new
API
like?
Does
it
roll
out
of
the
box
because
we
are
using
the
open,
API
spec
or
there
is
some
stuff
needed
or
probably
when
we
make
it
CRD,
then
yeah.
B
What
you'll
be
able
to
do
in
the
future
is,
if
you
write
like
an
aggregated
api
server,
you'll,
be
able
to
implement
the
colonizer
interface
in
the
api
server
and
get
the
column
values
directly
from
the
api
server.
Instead
of
pulling
down
an
open,
API
schema
and
doing
it
based
on
open
api
I.
As
far
as
I
understand
it,
that
would
allow
you
to
do
more
flexible
things.
Then
you
could
accomplish
an
open
API.
B
G
B
You
can
you
can
with
an
aggregated
API
server,
do
the
same,
open,
API
trick.
The
problem
is
that
with
open,
API,
you're
you're
limited
to
pretty
simple
JSON
path.
Expressions
and
you
can't
you,
for
example,
like
you,
wouldn't
you
wouldn't
be
able
to
pick
out
like
a
list
of
conditions
in
status
that
were
true.
B
C
B
It's
it's
not
extraordinarily
flexible,
it's
very
basic,
but
the
advantage
of
doing
open
API
is
that
you
don't
actually
have
to
write
code
now.
One
thing
that
I'm,
not
certain
about
is
whether
you
would
be
able
to
eventually
do
very
custom
columns
server-side
when
you're
using
a
CR,
D
or,
if
you're
limited,
intrinsically
when
using
a
CRT
to
open
API.
B
That
said,
I
think
that,
like
it's,
it's
very
important
to
us
at
Red
Hat
that
you
should
be
able
to
add
new
types
to
being
supported
by
Federation
in
like
the
most
basic
way
for
you
want
to
model
templates
overrides
in
placement.
It's
very
important
to
us
that
you
should
eventually
be
able
to
do
that
without
writing.
Any
code
or
by
writing
is
small
amount
of
code
as
possible,
and
it
seems
to
indicate
like
that
that
seems
to
pull
us
in
the
direction
of
CRT.
C
C
I
think
this
was
this
for
sure
she
did
raise
one
PR
today,
so
what
she
you
want
to
talk
about,
the
PR
that
you
know
another
race
today
and
maybe
that
discussion
already
happened,
not
sure
for
the
wider
audience
we
can
have
that
yeah!
Okay,
I
can
go
about
it
like
we
had
a
general
wish
like
we
can
override
any
fields.
Okay,
that's
like
in
future,
if
at
only
if
user
wants
to
override
some
particular
field,
it
need
not
warrant
changing
the
API.
That
was
my
view.
C
C
So
that
was
my
view
and
how
and
that's
what
I
did
as
a
PR
and
but
as
explained
by
Meru
I
think
there
is
some
lot
more
advanced
topics
which
are
going
on
like
in
this
particular
field.
I'm.
Not
quite
sure
of
that.
So
maybe
Meru
can
explain
that
particular
thing
about
the
override
what
he
has
envisioned
in
the
future.
E
E
It
doesn't
really
allow
fine-grain
behavior,
but
in
thinking
about
like
oh,
what
would
it
take
to
implement
the
fine-grain
behavior
like
we
talked
about
like
strategic
merge
and
that
sort
of
thing
I
came
to
the
conclusion
that
we
don't
actually
have
a
solid
use
case
for
modifying
arbitrary
fields
like
we've
discussed
it
and
we're
like
well
architectural
yeah.
It
would
be
very
nice
from
the
user
perspective
to
do
that,
but
we
haven't
had
anybody
clamoring,
oh
I
would
really
like
to
be
able
to
override
arbitrary
fields
like.
E
Maybe
it
is
a
requirement,
but
we
haven't
had
anyone
actually
asked
for
it.
We
just
kind
of
hypothesize
that
it
might
be
useful,
so
in
the
interests
of
just
simplifying
for
prototyping
I,
just
got
it
back
to
like
replicas
or
maybe,
for
you
know,
config,
Maps
and
secrets.
You
can
just
specify
completely
different
values
versus
the
ones
supplied
in
the
template.
E
So
that's
why
it's
like
it
for
prototyping
I.
Do
think
that
strategic
merge
is
like
that's
a
better
way
to
do
it
if
we
do
want
arbitrary
overrides,
but
I
would
suggest
that
that's
a
lower
priority
than
getting
everything
else
working
until
we
have
people
yelling
about
it
like
there's
a
lot
of
other
bigger
priorities,
I
think
that
should
be
implemented.
Yeah.
C
I
kind
of
agree
with
you
I
think
that's
good
enough
like
this
was
one
of
this
Sarah
arose
like
because
of
maybe
design
versus
the
implementation
like
I
felt
like
okay,
there
is
some
missing
link,
so
that's
why
I
tried
to
solve
it,
but
otherwise
it's
fine
I
think
the
summer.
If
we
can
document
like
this,
whatever
that
inflate,
we
will
try
to
use
in
either
the
design
or
some
in
in
somewhere
in
the
issue.
C
I
agree
with
that:
I
think
I
understand
the
current
situation,
but
somehow
we
need
to
make
some
process
or
some
temporary
thing
to
be
in
sync.
Having
this
kind
of
problem
I
think
there
are
a
lot
of
folks
watching
and
they
want
to
get
into
contribution
mode,
but
I
think
it's
going
to
be
very
difficult
for
them
to
pitch
in
right
now,
yeah.
E
E
Teams
working
on
push
reconciliation
at
the
moment
sounds
like
Huawei
wants
to
work
on
status
and
scheduling,
and
the
coordination
point
will
be
the
API
and
I
think
we
can
I
mean,
to
my
mind,
like
small-scale
development
effort
documenting
everything
is
just
expensive
this
as
we're
trying
to
just
solidify
it,
so
it
could
be
maintained
by
more
than
a
closely
but
in
the
near
term,
I
think.
The
only
way
to
work
is
just
to
have
people
coordinating
really
closely.
E
If
you
wanted
to
work
on,
you
know
if
you
care
about
push
reconciliation,
come
talk
to
the
redhead
guys
and
we'll
sort
you
out.
If
you
want
to
work
on
scheduling
behind
all
the
guys,
they'll
sort
you
out,
but
I,
want
to
work
on
the
liner
like
little
detail
of
any
one
given
piece
I
mean
either
you
can
work
independently
and
your
point
of
contact
is
the
API
or
are
you
gonna
have
to
be
in
close
contact
until
we
actually
get
something?
That's
that's
possible
to
work
independently
without
potentially
stepping
on
one
another.
E
In
the
near
term,
like
the
starting
point
is
simply
like
having
a
note
saying
if
you
want
to
work
on
push
reconciliation,
talk
to
these
guys,
if
you
want
to
work
on
this
work,
talk
to
these
guys
and
gives
like
emails,
point
of
contact
or
slot
candles
or
whatever,
and
as
far
as
like
the
API,
we
should
probably
make
sure
that
people
from
any
given
group
there's
points
of
contact,
and
you
know
if
there's
a
any
issue
requiring
consensus.
We
have
like
a
limited
set
of
people
that
can
actually
arrive
at
that
quickly.
C
On
the
other
hand,
what
do
I
be
that
there
is
some
amount
of
overlap
and
scheduling,
implementation
and
the
push
for
any
consideration
that
yeah
it
is
and
true,
but
what
about
I
just
create
a
simply
group
in
that
slack
channel,
and
they
can
mean
I
mean
whoever
wants
to
get
input
or
share
or
talk
in
that
anywhere.
All
of
a
sudden
there
I
mean
all
of
us
means
whatever
five
six
four,
then
those
people
are
often
on
this
side
of
now.
Does
it
make
sense.
B
I
found
six
channels
to
be
a
very
good
place
to
do
that,
coordination
and,
like
group,
visible
discussion,
it
sounds
to
me
like
we
should
either
as
far
as
like
directing
books
that
might
be
new
to
the
the
subject
matter
or
that
are
looking
for
ways
to
collaborate
and
help.
I
think
it
sounds
like
we
either
need
some
addition
to
the
read
meet.
That
explains
who
you
should
talk
to
for
a
particular
area
or
have
issues
with
what
people
are
working
on.
B
E
I
agree:
I,
just
don't
think
it's
that,
like
I,
think
the
idea
that
you
just
come
by
and
decide
what
to
do
and
start
submitting.
Prs
is
not
valid
right
now,
I'm,
not
saying
we
don't
want
to
get
there,
but
I
mean
this
is
not
something
that's
maintainable
wasn't
intended
to
be
maintainable
getting
there
is
gonna
involve
a
lot
of
concerted
effort
by
a
small
group
of
people.
Anybody
who
wants
to
contribute
will
have
to
become
very
familiar
with
those
people
rather
than
just
reading
an
issue.
E
B
That's
fine
as
long
as
there's
a
way
that
I
can
tell
that
by
looking
at
the
readme
or
looking
at
issues.
It
doesn't
to
me
how
to
present
him,
but
I
think
that
we
should
explain
what
we
discussed
in
the
last
beat
of
the
conversation
here
around
like
what
level
of
readiness
is
this
Filippo
at
in
terms
of
accepting
new
collaborators
and
like
what
are
people
working
on
at
this
moment
as
long
as
that's
presented
somewhere,
that
I
can
find
and
add
about
it
by
looking
at
the
github
repo
I'm
happy.
C
The
other
point
is
actually
why
we
were
thinking
that
we
should.
We
should
define
at
least
some
listed
work
items
because
there
are
such
as
she
mentioned.
There
are
set
of
people
who
are
ready
to
contribute,
I.
Think
some
new
guys
enjoying
today's
meeting.
Also
I
see
somebody
named
yeah,
the
new
phase.
Do
you
want
to
introduce
yourself?
And
if
you
are
looking
forward
to
contribute
I
mean
it
would
be
ascertained.
H
C
I
I'm
also
from
abandonment
lever
and
we're
just
basically
tracking
Federation
and
considering
you
know
how
how
we
can
potentially
contribute
in
the
future.
Obviously
we
don't
have
a
lot
to
add
in
the
discussion,
but
we're
following
the
you
know
closely
and
hoping
that
many
r
futures
things
solidify
that
there's
you
know
areas
where
we
can
be
helpful,
contributing
back
or
or
potentially
using
it
in
the
future
for
our
own
stuff.
But
right
now
it's
kind
of
exploration.
C
C
Yeah
I
did
also
publish
what
I
am
focusing
on.
I
mean
it's
just
like
a
work
item,
nothing
to
not
write
on
the
time
put
here,
and
my
intention
was
that
at
some
location
we
can
at
least
have
a
maintain
the
document
which
can
say:
okay,
who's
got
one
more
time
closer,
so
that
we
don't
step
on
each
other's
feet.
C
C
J
Also
wanted
to
bring
up
a
point
that
her
phone
was
kind
of
making
about
having
conversations
and
slack
I
think
you
know
for
everyone's
benefit.
If
we
could
like
keep
those
conversations
and
either
these
the
multi
cluster,
sig
channel
or
perhaps
I,
don't
know
if
there's
support
for
like
working
groups
like
channels
for
more
focus
scooter,
there
is.
Maybe
we
can
create
one
for
something
like
this,
that
we
could
all
collaborating
yeah.
B
J
K
V1
v2
I
noticed,
there's
still
confusion
for
users
as
to
like,
what's
happening
with
v1
and
where
we're
at
the
p2.
You
can
see
that
just
in
the
questions
in
the
in
the
channel
and
will
have
some
presence
of
Q
Khan
in
a
month
to
give
an
update
but
I
mean,
is
it
time
to
say
something
about
v1,
given
the
amount
of
people
that
are
actually
working
on
it.
K
K
E
I
mean
there's
still
confusion
around
its
status,
I
mean
it
never
moved
beyond
alpha
which
effectively
means
unsupported,
and
yet
there's
Doc's
on
you
know
the
cube
doc
site
that
suggests
it's
a
fully
supported
part
of
cube
and
I
mean.
Maybe
you
ever
read
me
somewhere,
but
I,
don't
think
the
docs
that
I
think
most
users
would
view
as
official
have
any
indication
of
that
status.
We've
had
blog
posts.
We
have
cube
con
presentations,
we
I
don't
think
it's
ever
been
called
out
that
this
is
not
supported
and
I
do
think.
K
E
E
B
K
I
mean
I
think
in
terms
of,
if
you
view
it
as
a
product
being
able
to
say
at
this
date,
users
should
be
able
to
do
XYZ
I.
Think
that's
more
compelling,
even
if
the
functionality
said
is
much
reduced.
At
least
there's
a
there's,
a
story
to
tell,
and
at
the
same
time
we
should
be
able
to
say
that
without
cycling,
ongoing
efforts
to
explore
this
space,
which
I
think
you
guys
are
still
heavily
involved
in
well.
K
So
I
would
suggest
that
be
an
action
item.
At
least
I'd
like
it
to
be
an
action
item,
because
right
now,
I,
don't
think
anybody
from
Red
Hat
is
going
to
be
present
at
cube
con
to
give
to
sig
update
I'm
I'd
like
to
I
can
do
that,
but
I'd
like
to
be
specific,
and
you
know,
encourage
people
about
what
our
our
efforts
are.
Yeah.
B
B
I
think
that
we
have
fairly
limited
time
left
before
cube
con,
so
it
sounds
like
something
that
we
need
to
agree
at
least
have
a
preliminary
agreement
broadly
in
terms
of
like
the
next,
the
first
couple
milestones
of
Federation
v2
and
what
we
want
the
messaging
to
be
in
the
sig
update,
so
that
Christian
has
time
to
prepare
something
around
it.
Okay,.
C
C
B
C
Okay,
so
yeah
before
this
people
are
talking
about
yeah,
defining
work
items
and
long
distribution.
I
think
what
Maru
suggested
is
that
we
might.
We
can
probably
only
broadly
differentiate
whether
they
are
doing
it
right
now,
and
new
users
would
have
to
get
in
touch
with
so
then
dividual
es
or
the
folks
who
are
basically
looking
on
the
either
so
model
do.
Would
you
be
able
to
update
maybe
couple
of
lines
about
this
in
the
v3,
and
maybe
you
get
an
idea,
people
who
might
be
contact
if
anything
does.
E
That
that's
I
think
that's
fine
for
a
starting
point
and
I
mean
I'm
happy
to
list
the
items
we're
working
on
the
points
of
contact.
If
you
want
to
submit
a
PR
that
defines
what
you
want
to
work
on
the
points
of
contact,
I
mean
it's
just
to
get
out
just
to
hole,
requests
and
I
would
say
that
at
least
initially
I
would
encourage
you
to
just
target
the
the
types
the
primitives
that
we're
working
on
propagating
and,
what's
hang
that's,
ultimately
how
you
want
to
do
it?
C
To
focus
how
the
scheduling
ideally
also
should
not
so
that's
how
it
is
also
represented
in
that
Quintin
stuff
Quentin
of
mr.
work
flow,
so
the
shilling
controller
is
probably
different,
which
basically
gets
the
feedback
from
the
clusters
which
objects
that
is
still
not
concluded,
I
mean
and
how
it
does.
It
also
is
open
question,
but
the
intention
is
that
this
regular
can
basically
update
the
three
primary
or
the
basic
resources
for
the
given
type.
C
A
E
E
C
Yeah
see
our
intention
is
also
to
first
try
out
simpler
things
and
then,
if
it
doesn't
implementing
the
simpler
stuff
doesn't
really
satisfy
the
use
case
that
we
have
then
try
to
go
level
up
for
effect,
section
or
whatever
to
implement
the
same.
But
our
focus
is
that
first,
we
try
to
implement
whatever
we
are
intending
to
implement
in
the
most
simplest
way
possible.
C
C
Okay,
guys
so
yeah
yeah,
one
more
thing
before
we
before
we
I
it's
more
suitable
for
both
iynched
a
she
for
this
meeting
to
be
on
Monday.
The
set
sound
okay
for
us
to
the
phone,
so
we
we
actually
have.
We
teach-
are
you
making
next
day
morning
on
on
Thursday
morning
from
the
audience
so
late
nights
on,
but
in
this
case
sorry
this
is.
This
is
our
first
equation,
Thursday's
difficult
for
us
I.