►
From YouTube: Kubernetes Federation WG sync 20181003
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).
B
A
B
A
B
A
B
Not
sure
if
the
same
thing
exists
with
Kuebler,
because
I
haven't
tried
it
out,
I,
just
half
an
hour
voice
on
your
comment
and
that's
what
I
did
remember.
I
did
have
a
chat
with
Shashi,
though
he
mentioned
that
this
should
certain
this
is.
This
should
be
fine,
but
the
reason
I
use
multi
clips
are
in
the
name
itself
was
to
provide
a
disambiguation
if
you
are
using
the
API
from
QC
PL,
which
I
am
not
sure
if
it
is
needed
as
of
now.
B
A
B
A
D
And
the
background
on
this
is
sometimes
we
have
resources
that
are
really
like
that
are
written
by
controllers
they're,
not
really
intended
to
be
written
by
users.
Maybe
there
can
be
read
by
users,
but
the
question
is:
do
we
put
that
data
in
spec
or
status
complication?
Is
that
those
things
are
treated
differently
from
an
API
perspective,
as
I've
discovered
the
hard
way
the
clients
tend
to
behave
and
unexpected?
Well,
they
behave
differently.
When
you
update
stock
versus
status,
you
have
to
make
a
different
call
to
update
stock
versus
status
errors.
D
You
get
back
when
say
a
resource
has
been
deleted
or
it's
been
changed.
It's
actually
different,
and
and
also
as
for
the
link
in
the
agenda,
we
really
want
to
be
calling
resources
status
status,
and
this
is
because,
when
we're
talking
about
like
say
we're
collecting
status
for
a
replica
set
and
our
resource
is
going
to
be
called
replica
status
and
then.
D
That
status
status,
the
type
will
be
replica,
set
status,
status
and
I
I,
don't
know
like
it's
kind
of
like
kind
of
a
pedantic
thing,
but
I'm
there's
enough
sort
of
there's
enough
rough
edges
around
this.
That
I'm
wondering
if
we
can
maybe
think
about
whether
the
proper
place
for
data
you
know
machine,
written
resources,
actually
spec
anybody
have
an
opinion
on
this.
B
B
Okay,
Maru,
even
before
this
PR
was
based.
I
am
sure
she
had
a
discussion
on
this
naming
scheme
and
how
exactly
to
deal
the
machine
between
data.
As
you
mentioned
it
so
my
suggestion
or
the
best
thing
I
could
think
of,
and
that's
what
I
said
sister.
She
was
that,
if
we
can,
we
can
figure
out
a
mechanism
where
we
can
have
a
specialized
API
and
that
APA
does
not
have
a
spec
for
status.
B
But
what
I
think
she
couldn't
figure
out
this
overriding
of
subverting
the
current
built-in
mechanism
of
for
auto
generation
of
clients
and
definition
of
the
cid
api's,
which
basically
revolve
around
the
spec
or
status.
So
the
option
was
to
either
use
spec
or
status,
so
I
think
he
went
ahead
and
used
status
and
then
chose
his
name
of
status
status.
So
the
other
simple
main
mechanism
might
be
just
you
spec
and
API
name,
we'll
have
to
figure
out
what
we
should
call
it.
It
should
be
different
from
the
Federated
type.
B
F
F
D
Kind
of
feel,
like
that's
kind
of
a
whether
that's
a
valid
concern
or
not,
given
that
we're
having
something
that
is
solely
intended
to
be
written
by
a
machine.
So
does
that
matter
where
we
put
stuff,
if
it's
solely
written
by
machine,
does
it
matter
that
we
put
it
in
this
back
instead
of
the
status?
That's
more,
the
concern,
I
guess.
F
A
Not
sure
if
I
understand
what
the
specific
concern
is
here,
is
it
the
name
of
a
type
called
status
status,
or
is
it
a
question
of
where
dated
like
I'm,
not
sure
that
I
understand
the
connection
with
where
data
should
be
stored?
So
I
wonder
if
we
can
just
like
identify
exactly
what
the
the
issue
is
that
we're
talking
about
these.
D
E
D
This
I
mean
in
the
case
of
the
status.
Our
initial
use
case
is
collecting
status,
so
can
be
used
by
the
scheduler,
and
so
arguably,
it's
almost
like
more
like
specifications
of
the
scheduler
than
anything
else.
I
don't
know
so
that's
kind
of
like
the
the
one
side
which
is
more
sort
of
related
to
the
type
definition
and
the
other
side
is
I,
noticed
that
there's
discrepancies
between
how
status
updates
fail
versus
how
spec
update,
sale
or
just
updates
to
non
status.
D
If
you
remove
a
resource,
you
would
expect
to
get
not
found.
If
you
try
to
update
that
resource
subsequently,
if
you're
updating
the
status,
you
actually
get
a
conflict
because
it's
been
removed
underneath
it
and
it
just
it
just
deals
with
it
differently
and
you'd
actually
have
to
follow
a
different
procedure
for
detecting
errors
and
I'm.
You
know
I've
gone
through
the
process
of
dealing
with
that
in.
D
A
A
A
Correct
as
an
example
and
in
terms
of
just
where
my
own
thinking
goes,
it
seems
like
this
is,
and
actually
to
put
that
a
pin
in
that
for
a
second
and
pay
to
paint
a
complete
picture.
So
I
think
the
scenario
is
say
that
you
have
a
federated
deployment
called
my
deployment
and
you
make
a
federated
deployment
status
resource.
A
As
far
as
I
am
aware,
that
is
exactly
like
what
we're
exploring
with
the
status
API,
where
the
the
the
declarative
nature
of
the
resource
is
that
it's
solely
that
you
should
collect
status
about
something
that
has
its
name
I,
get
that
that's
kind
of
an
unprecedented
and
maybe
odd
API
pattern,
but
in
the
sense
that
a
controller
discovers
that
information
about
things
that
are
happening
in
the
world.
It
seems
like
status
to
me.
Well,.
F
Can
I
just
make
an
observation?
The
rest
of
the
kubernetes
api
has
a
single
object
which
per
per
thing
I
mean
I'm
talking
in
general
terms
now,
and
that
has
a
speck
in
it
which
gets
written
by
various
different
things,
and
that
has
a
status
in
it,
and
those
are
two
different
kinds
of
information.
We
explicitly
elected
to
just
cut
that
thing
in
half
split
it
up
into
the
spec
in
one
object
in
the
status
of
another
object,
and
that's
where
the
name
clash
is
coming
from.
F
F
F
Federated
replica
set
right
and
a
normal
kubernetes
replica
set
has
a
spec
and
a
status
inside
it,
and
we
decided
to
take
the
at
least
some
portion
of
the
status
and
put
it
in
a
different
thing.
Called
a
federated
replica
set
status
now
is
what's
left
behind
all
just
spec,
or
does
it
have
so
far
needed
replica
said
only
that
doesn't
actually
have
its
own
status
as
well
as
a
potentially
associated
federated
replica
set
status.
Yeah.
A
That's
that's
a
good
point
and
that's
one
extra
complication
that
I
think
makes
tough
to
talk
about
this,
so
Quinton,
I,
think
what
you
have
in
mind
is
that
it
is
that
the
federated
replica
set
may
have
its
own
intrinsic
status,
like,
for
example,
observed
generation
that
a
controller
has
last
seen
of
this
particular
object
right,
that
is,
that
is
distinct
from
the
aggregated
status
data
for
the
resources
that
are
eventually
deployed.
That's
that's
what
you're
hitting
on
right
in
part
Elise
well,.
D
B
Yeah-
and
that
is
because
that's
the
CRT
mechanism
is
for
the
kubernetes
style
API.
So
all
the
machinery
and
everything
is
will
present
a
kubernetes
style
API,
which
will
inherently
have
a
declarative
state
and
at
any
given
point
of
time
in
the
current
state
of
the
system.
Well,
the
system
is
trying
to
achieve
that
decorated
state,
so
these
two
are
represented
by
seconds
later.
So
what
we
are
talking
about
is
having
our
API
a
little
different
from
this,
and
we
have
them
a
little
different
to
be
honest
and
we
have
this
machinery
so
I.
F
F
So
that's
that's
a
different
way
of
thinking
about
the
problem,
which
makes
a
lot
of
the
previous
discussions.
Problems
kind
of
go
away,
I'm
sure
might
introduce
some
other
problems,
but
it
certainly
solves
the
problems
under
consideration.
I
think
the
reason
we
separated
the
status
of
the
federated
objects
and
created
the
concept
of
a
federated
replica
said
status
was
because
we
couldn't
decide
what
that
status
should
look
like
and
therefore
we
didn't
want
to.
F
D
That
was
the
original
motivation.
There
was
an
additional
consideration
that
became
overriding
subsequently
Shashi
had
originally
proposed
that
the
status
be
actually
stored
on
the
federated
reader
federated
like
template,
and
when
I
was
reviewing,
it.
I
came
across
a
number
of
problems
with
that
proposal,
probably
the
most
important
of
which
is
the
way
that
we
determine
whether
resource
in
a
target
cluster
needs
updating
is
by
comparing
the
resource
versions
of
the
templates
and
the
overrides,
and
the.
F
D
D
F
So
there
are
composite
objects,
potentially
has
a
status,
not
so
it's
different
than
the
status
of
the
template,
just
to
be
clear,
fair
but
I
mean
if
we're
gonna,
be
storing
I
mean
when
I
creating
a
specific
instance
of
a
federated
replicas
sips.
That's
a
thing
right.
We're
talking
about
users,
yeah
right.
D
D
The
we
couldn't
store
status
directly
on
the
federated
representation,
though
like
the
template
as
I
was
discussing,
is
because
we
use
resource
versions
to
determine
as
one
component
of
determining
whether
a
resource
and
a
target
cluster
needs
to
be
updated
or
not.
If
we
start
storing
status
there,
we
actually
affect
the
resource
version.
We
break
that
versioning
mechanism
and
so
moving
the
status
into
a
separate
resource
was
a
way
of
avoiding
them.
Well,.
F
So
in
the
original-
yes
in
the
original
v1
implementation,
that
version
number
was
not
used,
we
actually
compared
the
specs
and
if
the
specs
different
we
updated
them.
So
yes,
I
mean
shouldn't
sure
that
that
problem
needs
to
be
resolved,
but
I
I'm
becoming
increasingly
worried
that
we
have
a
sort
of
a
disconnect
on
on
some
of
the
fundamentals
of
the
actual
API,
and
that
might
be
where
the
discussion
around.
Where
should
status
go
and
should
it
be
called
status
status
and
all
of
those
sorts
of
things
came
from
sorry.
A
I
think
it
would
pay
to
be
to
to
take
this
conversation
back
to
the
question
of
the
Shashi's
current
PR
I.
Think
the
question
is:
should
the
status
of
the
status
resource,
which
is
you
know,
the
plan
that
we
had
a
consensus
on
previously
to
explore?
It
is
the
work
that
he's
that
he's
done
at
this
point.
F
A
D
B
A
D
Sure
why,
like
kind
of
whether
or
not
this
is
what
Quintin
intended
I
got
the
sort
of
impression
that
status
on
a
resource
is
really
status
about
resource,
and
so,
if
we're
just
collecting
data
from
something
else
to
me
in
the
appropriate
place
would
be
in
the
stock.
And
if
we
want
to
collect
status
about
that
stock.
That's
a
different
story,
but
I
mean
we're
kind
of
misusing
this
stuff.
But
to
me
like
just
a
simple
rule
are
like
rule,
could
be
you're
collecting
status
about
this
resource
data.
Otherwise
put
in
this
box.
F
Marude
to
answer
your
question:
I
think
it's
more
confusing
to
have
it
inspect
that
in
status,
not
not
when
you
think
about
it
carefully,
as
you
have
just
done,
I
can
definitely
understand
the
sense
and
maybe
even
agree
with
you
that
spec
is
the
right
place
for
it.
But
if
you
have
to
try
and
explain
to
every
user,
why
are
we
putting
the
status
in
spec?
It's
going
to
drive
everyone
crazy,
I,
think
I
think
the
answer
is
to
not
have
it
in
either
because
it
doesn't
make
sense
to
have
it
in
either.
B
C
E
F
Okay,
because
because
we
can't
do
it
the
other
way,
we
know
what
the
right
answer
is.
The
right
answer
is
is
take
this
status
wrapper
away
on
the
inside
yeah
that
you
just
have
fields
they're,
like
config
map,
has
I
believe,
but
we
don't
know
how
to
do
that.
So
we're
not
gonna
do
that,
which
is
both
suggestion,
which
I
think
is
perfectly
reasonable.
D
I
mean
the
best
part
about
this.
Is
it's
not
actually
just
TT
if
it's
actually
triple,
because
we're
gonna
have
a
status
resource,
the
status
field
or
a
status
section
like
section
and
then
it's
at
its
field?
Because
you
can't,
you
know
we're
gonna,
be
pointing
to
a
list
of
or
a
slice
of
whatever
types
tab
them.
A
Did
add
something
to
the
agenda
hacker
this,
which
is
that
if
folks
recall,
we
had
a
discussion
recently
about
moving
the
cluster
registry
to
beta
and
one
of
the
action
items
that
came
out
of.
That
was
that
we
felt
that
it
was
like
very
odd
to
elevate
a
an
API
that
had
no
controllers
or
no
way
to
you
know
actually
use
the
the
records
in
the
cluster
or
I'm.
A
A
To
do
that,
and
one
of
the
things
that
I
did
that
I
wasn't
wanted
to
solicit
opinions
about
in
the
working
group
is
that
a
federated
cluster
has
status
fields
for
the
region
and
availability
zone.
I
took
those
out
when
I
basically
copied
federated
cluster
and
renamed
it
in
the
cluster
registry
PR,
because
I
felt
that
that
might
be
perceived
as
too
specific
to
Federation.
A
However,
I
think
that
if
we
remove
the
the
fields
from
that
resource
that
we
would
still
need
to
have
either
like
another
resource
in
Federation,
which
my
which
might
be
okay
or
a
or
find
some
way
to
store
this
information
on
the
I
think
I
wind
up
after
talking
with
Quinton
deciding
that
my
initial
cluster
cluster
connection
name
was
bad
and
I
think
I
renamed
it
to
cluster
credentials,
finding
a
way
to
store
it
on
that
resource.
So
I
I'm
sure
folks
would
like
a
chance
to
like
take
a
look
at
that
PR.
D
Whether
we
want
to
have
condition
there
was
a
recent
discussion
around
status
because
we're
actually
going
to
be
collecting
or
tchotchkes
from
posing
and
we
collect
all
status
for
any
given
resource
is
targeted
for
collection,
including
conditions
when
I
was
kind
of
concerned,
that
we'd
be
collecting
a
lot
of
textual
data.
Potentially
it
could
be
costly,
and
he
pointed
me
at
discussions
in
Cuban
Eddie's
to
suggest
that
conditions
are
actually
kind
of
deprecated
and
going
away.
D
A
A
A
A
Do
but
the
the
argument
against
them
is
that
if
I
can
go
out
to
tape
and
familiarize
myself
with
them
or
spool
it
back
into
memory,
was
that
treating
these
things
as
kind
of
generic
generic
datatypes
instead
of
specific
attributes
like
an
array
of
generic
conditions
that
have
a
name
and
a
value
is
less
useful
than
a
strongly
typed
API
about
the
different
attributes
of
status.
Yeah
I
guess
was.
F
Agree
with
that
argument,
I
also
have
never
understood
what
a
condition
is,
because
it's
a
difficult
thing
to
understand.
But,
yes,
my
comment
actually
just
to
clarify
was
that
it
is
reasonable
to
know
when
the
value
of
a
field
was
updated
when
it
was
last
probed,
etc.
I
do
agree
that
having
typeless
bundles
of
name
value
pairs
is
this
good
idea.
F
D
A
I
am
not
certain
whether
the
the
concept
of
like
conditions
are
deprecated
has
wormed
its
way.
All
the
way
through,
like
the
more
central
parts
of
the
community,
I'd,
be
happy
either
way
like
the
the
point
that
I
thought
was
worthy
of
discussion
is
that
we
had
these
strongly
typed
status
fields
for
federated
cluster
that
are
like
the
detected
region
and
availability
zone
of
of
the
cluster
and
I
chose
to
remove
those
fields
which
are
specific
to
Federation
from
this
very
similar
object
that
I
created
in
the
cluster
registry
P
R.
A
So
the
question
is
like:
do
we
think
they
should
go
into
the
cluster
registry
P
R?
Or
do
we
need
to
figure
out
how
we're
going
to
handle
that
in
Federation,
since
the
intent
I
think
was
to
replace
our
use
of
federated
cluster
with
this
new
concept
in
the
cluster
registry?
Okay,
can
I
just
clarify
something.
A
F
A
F
I
wasn't
looking
for
an
argument.
I
was
actually
just
trying
to
help
you
out
of
your
difficulty,
which
is
I,
I.
Think
they're,
not
I,
think
there
are
fundamental
properties
of
a
cluster
I
think
any
cluster
exists
in
a
region
and
possibly
availability
zone.
You
know,
maybe
those
are
not
known
or
irrelevant,
but
fundamentally
clusters
do
actually
exist
and
then
that
was
why
they
were
there.
I
wouldn't.
D
A
It's
a
sure
yeah
that
makes
sense
in
honestly,
Quinton
I
think
it
would
be
very
productive
to
like
to
have
that,
like
in
a
github
comment,
I'm
hoping
to
get
some
feedback
from
folks
like
outside
that
I
generally
don't
participate
in
the
working
group,
but
they're
interested
in
cluster
registry.
So
I
tell
you
what
I'm
going
to
I'm
gonna
make
a
comment:
they're
just
noting
that
I
removed
it.
If,
if
you
could
comment
with
your
stance
on
it,
that
I
think
that
would
help
to
drive
the
conversation
forward
here,
I
can
I.
F
F
Just
one
very
last
comment
on
on
the
idea
of
stripping
things
down
to
their
least
by
credible
form,
which
I
fully
understand
the
motivation
for
I
guess.
The
problem
is:
when
you
end
up
with
the
situation,
we
are
busy
trying
to
solve
right
now,
which
is
the
thing
that
was
dripped
down.
That
far
is
no
longer
useful
and
therefore
people
have
to
build
another
thing
and
therefore
never
use
the
first
thing,
which
is
the
cluster
registry.
F
I
mean
there
was
the
origin
of
the
work
you're
doing
now,
so
I
would
argue
somebody
else's
gonna
have
to
go
and
build
another
registry
that
tells
them
which
regions
and
clusters
they
cluster,
sorry,
which
regions
and
availability
zones
their
clusters
are
in
then
we're
gonna
end
up
in
the
same
situation.
We're
in
now,
which
is
nobody's
using
the
cluster
registry.
F
A
And
it
makes
a
lot
of
sense
to
me.
I
I
am
perfectly
fine
with
them
being
there
honestly
I'm
I'm
interested
mostly
in
getting
people
to
talk
about
it.
So
we
can
move
forward
on
this
thing,
so
I
will
put
into
the
the
chat
window
a
link
to
where
I
made
a
comment.
If,
if
Quinton
you,
oh
yeah
SIG's
service
catalog,
that's
me.
If,
if
you
can
comment
there,
Quinton
with
your
stance
or
other
folks
in
the
working
group
can
I
think
that
would
be
great.