►
From YouTube: Kubernetes Federation WG sync 20180919
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
D
E
Well,
I
answered
this
question
on
the
comment
on
the
issue.
My
understanding
from
a
conversation
I
had
with
excu
builder
dowse,
and
this
is
in
Sprunt
in
response
to
my
having
the
same
question
that
that
everyone
else
seems
to
be
having
like.
Why
does
key
building
default
using
stateful
sets
and
the
answer
I
got
back
was
something
like
deployments:
do
not
guarantee
that
only
a
single
instance
will
be
running,
even
if
you
have
rough
with
this
equals
one.
D
C
B
I
think
you
missed
the
meeting
last
time
and
we
didn't
think
about
this
item
in
post
that
shall
we
had
a
discussion
about
this,
and
the
conclusion
was
that
the
latest
refers
to
the
latest
release.
So
whichever
is
the
latest
release
latest
will
point
to
that.
Cannery
is
the
one
which
is
actually
the
master
in
the
headmaster
and
there
would
be
released.
That's
version
with
the
lease
number
yeah.
D
So
I
tell
you
what,
as
an
action
item
to
follow
up
since,
since
there
was
still
a
question
president,
like
I'm
gonna,
be
making
some
some
polls
to
add
documentation
for
different
things
like
different
features,
etc
and
I
can
take
an
action
item
here
to
document
the
image
tag
strategy
so
that
we
don't
have.
We
don't
have
any
more
on.
You
know,
confusion
since
it's
not
written
down.
Does
that
sound
good
to
folks
yeah.
C
D
Okay,
III
made
an
issue
and
put
it
in
the
notes.
I'll
send
a
PR
for
that
one
later
today,
but
so
thank
work.
The
status
API
we
at
Red
Hat
were
having
some
like
internal
discussion
about
the
the
poll
that
you
made
Shashi
and
during
that
discussion
we
kind
of
realized
that
we
think
there
are
some
complications
with
propagated
version.
Then
work
correctly.
D
E
C
E
C
Yeah,
either
way
it
should
be
fine
defend
like
if
you
update
the
status
in
the
template,
I'd
like
it
to
be
easy
for
the
user
like
to
get
the
status
for
the
objects
like
tagging,
that
particular
objects.
So
if
it
is
a
separate
API
object
by
itself,
I
think
it
would
be
little
inconvenience
for
the
user.
That's
the
only
concern
we
had
actually
all.
E
Right
I
mean
if
we
step
back
for
just
a
second
there's
kind
of
like
two
decisions
to
make
and
they're
they're
related,
so
the
first
one
was
does
man,
it
does.
Collection
of
status,
happen,
sink
controller
or
not?
Okay
and
I
and
I
described
sort
of
reasons
why
putting
in
the
sink
controller
like
if
we
want
to
have
a
degree
of
separation
between
mic,
propagation
and
Status
collection,
because
some
features
that
might
use
the
status
might
not
actually
depend
on
propagation
like,
for
example,
DNS.
E
So
that
kind
of
suggests
that
we
need
to
make
a
decision
about
whether
we
want
to
have
that
dependency
or
not,
and
if
we
don't,
then
that
would
imply
collecting
status
separately
from
the
sink
controller.
The
caveat
to
that
decision
is
if
status
is
collected
outside
of
the
sink
controller,
then
there's
no
longer
a
way
to
coordinate,
updates
to
propagated
version
because
updates
the
status
will
affect
that
and
the
way
that
your
PR
is
written
today.
E
It
actually
coordinates
the
writing
of
the
propagated
version
so
that
it
can
know
the
version
of
the
template
after
the
status
is
written,
but
as
soon
as
it's
in
a
separate
controller
that
can't
be
coordinated
and
that's
what
would
influence
storing
the
status
separately.
If
you
can't
coordinate
the
propagated
version
right,
then
putting
it
in
separate
resource
allows
you
to
avoid
having.
E
So
I
mean
I
was
kind
of
bringing
this
up.
Not.
As
you
know,
this
is
the
way
we
need
to
go.
It's
just
we've
been
I,
think
we've
been
kind
of
at
least
I've
been
laboring
under
the
impression
that
we
do
want
to
avoid
imposing
dependencies
between
different
components.
In
this
case,
we're
you
know,
avoiding
that
dependency
is
going
to
impose
a
cost.
It
effectively
will
mean
that
we
need
separate
status
objects,
and
so
I
wanted
to
sort
of
raise
that
as
an
issue.
So
we
can
discuss
it
as
a
group.
E
D
B
Yeah
I
also
have
a
similar
opinion,
also
I,
think
user
experience
is
something
that
we
need
to
focus
on
now,
III
a
couple
of
months
ago.
I
think
this
dog
did
happen
in
that.
How
do
we
present
this
API
to
the
user
and
I
think
it
means
we
already
have
good
number
of
separate
resources
and
one
more
additional
resource.
I,
don't
know
I
mean
I
feel
like
it's
like
getting
like.
E
B
E
This
is
what
we
need
in
order
to
have
the
system
work,
I
think
if
we
can
sort
of
think
about
those
two
things
separately
like
this
is
what
allows
you
know,
push
propagation
to
be
functional
and
have
all
the
characteristics
that
we
want,
and
then
how
do
we
present
the
user?
You
know
something
on
top
of
that.
E
The
idea
that
the
API
has
to
be
just
like
that's
the
only
user
experience
I,
think
that
works
if
you're
dealing
with
things
that
are
kind
of
designed
for
Federation
we're
sorry
designed
for
kubernetes,
like
like,
like
deployments
deployments,
are
actually
kind
of
on
the
edge
of
that.
To
be
honest,
but
things
like
you
know,
replica
sets
or
pods
they're
simple
enough
that
they
work
well
with
the
Cuba
Nettie's
API.
Once
you
start
layering
like
more
complicated
semantics
on
top
I.
E
Would
argue
that
the
API,
as
a
user
experience
it
becomes
less
optimal
and
not
to
me,
like
Federation,
is
like
an
order
of
magnitude
more
complicated
than
most
of
the
things
that
are
part
of
core
kubernetes
and
so
I
think,
like
finding
different
ways
to
present
that
complexity
of
the
user
is,
is
maybe
a
better
approach,
as
opposed
to
trying
to
shoehorn
the
complexity
that
we
have
into
like
an
API,
and
that
could
be
I
mean
we
could
bring.
It
I
mean
just
like
off
the
top
of
my
head.
E
If
we
were
to
have
an
aggregated,
API
server
that
allowed
us
to
present
a
single
resource
per
like.
Instead
of
having
template
placement
override,
you
know
you
could
have
a
logical
API
resource
like
federated
X
that
actually
aggregated
all
that
information
together
has
different
sections
in
a
type
that
was,
you
know
it
would
effectively
write
different
resources
underneath,
but
the
user
would
just
see
one
and
not
just
an
API
version,
but
the
other
option
is
you
have
like
some
sort
of
you
know,
web
interface.
That
does
exact
that
same
thing.
E
E
D
I've
also
thought
about
a
an
idea
kind
of
similar
to
what
Meru
is
described,
although,
as
as
someone
with
deep
experience
on
aggregated
API
servers,
I'd
prefer
to
implement
it
with
this
with
another
CRD,
because
aggregated
API
servers
are
quite
expensive,
but
that's
another
discussion,
topic
I.
Think
I
think
the
main
point
that
I
would
I
would
focus
on
is
that,
like
I,
it
seems
like
it
might
be
more
usable
and
also
potentially.
D
Potentially
easier
to
like
adapt
existing
workloads
into
if
we
had
a
resource
that
encompassed
like
all
of
the
different
primitives
that
we
built
and
that
that
might
be
what
users
would
prefer
to
relate
to
I.
Do
think,
though,
that
we've
done
the
right
thing
in
terms
of
making
distinctions
between
the
primitives
so
that
we
already
we've
implemented
things
in
kind
of
a
decomposed
way.
D
E
B
We
were
thinking
that
the
status
can
also
be
collected,
which
is
part
of
template,
so
a
user
basically
needs
to
deal
with
only
two
resources
like
what
you
mentioned,
that
we
can
aggregate
all
of
these,
and
then
we
have
thought
about
that.
Also,
one
in
same
kind
of
a
thing
is
like
again
like
what
we
did
in
Federation:
v1
have
special
meaning
for
each
of
the
fields,
which
is
part
of,
say,
a
deployment,
the
source
and
present
that
that
itself
to
the
user
like
again,
but
it's
like
added
complexity,
you
partition
that
resource
again.
B
D
H
D
So
the
reason
that
I
ask
is
because
a
as
I've
been
thinking
through,
you
know
the
concept
that
maybe
there's
a
higher-level
resource.
That
is
what
the
user
relates
to.
That,
for
example,
forget
forget,
replica
scheduling
preferences
for
now.
Maybe
that
just
ties
together,
two
different,
shall
we
say
like
universal
primitives
of
like
template,
override
placement
status.
D
One
thing
I've
wondered
about
is
like
do.
Would
we
want
to
associate
like
higher
level
controllers
with
those
things,
or
would
we
want
to
keep
those
separate?
So,
for
example,
the
question
specifically
would
be
like
say:
I'm
gonna
make
a
higher
level
resource
that
has
the
UX.
That
I
think
is
a
little
better
that
incorporates
the
different
you
know.
Primitives
do
I
want
to
add
an
entanglement
with
that
and
like
a
higher
level
controller
or
do
I
want
to
keep
the
higher
level
controller
separate
so
that
I
can
switch
between
it
without
without
changing.
B
B
The
480i
types
you
mentioned
applies
more
generically
to
all
the
resources,
so
it
can
as
well
apply
to
any
arbitrary
resource.
What
the
where,
as
a
higher
level
controller,
might
be
considered
as
a
more
custom
implementation
or
more
specific
implementation.
You
are
given
API
type,
for
example,
for
Java
off
might
be
something
else
and
for
the
common
sense
and
it
doesn't
apply
to
any
other
type,
and
you
have
that
yeah.
D
B
Yeah
but
I
think
it's
good
that
we
actually
pick
started
this
talk
about.
You
know
presenting
more
easier
usable,
API,
maybe
a
different
group
for
a
different
layer
and
not
sure
what
to
call
it,
but
we
probably
can
take
it
as
a
next
step
and
to
conclude
the
talk
about
status
that
we
were
having
earlier.
If
this
is
our
next
step,
then
I
think
it's
okay
to
keep
status
and
since
it
is
more
salsa.
F
Yeah
Paul,
so
I
still
have
one
topic
and
I
have
just
the
append
18
coop
talk,
so
this
topic
is
also
key
logging
hurt,
but
because,
currently
in
additionally
true,
we
have
some
controllers
using
scene,
own
names,
so
only
print
a
lot.
Video
found
that
name
any
scene,
fells
logging,
logging
syslog,
but
actually
to
a
lot
of
a
front
different
controllers.
So
it's
very
difficult
for
teabag.
Currently
I
have
just
open
an
issue
and
I
got
some
answer
from
the
community
and
the
proposal
is
that
we
can
possibly
use
the
log.
F
Let
me
maybe
you
can
open
the
ticket
and
there
is
there's
this
solution
that
we
can
use
the
the
we
can
use
the
log
the
long
file.
Maybe
we
can
use
this
one
to
print
all
the
hotel
past,
so
that
is
coming
for
that
set
the
and
the
other
will
have
a
phobia.
Beach
fail
print,
the
log
suppose
this
kaaba's
for
debugging.
F
All
right
because
because
the
Federation
had
how
many
controllers
and
those
controllers
have
seen
name
named
as
controller
cool,
so
when
those
controllers
print
awesome,
logs,
viviĆ³
I'll
start
with
controller
go
as
the
file
name,
so
it's
difficult
to
say
which
controller
friendly
log.
So
it's
better
that
we
have
different.
D
F
F
B
E
F
Ok,
I
will
check,
but
colonel
yeah
I
found
that
in
urban
case
they
are
using
different
file
names
for
different
controller,
so
that
system
equalizer
that
the
log
will
we
will
print
out
with
these
different
file
names.
But
with
some
Norah's
comments
we
may
need
to
find
a
more
more
efficient
and
simple
way
to
handle
okay,
yeah.
E
E
B
D
E
B
E
E
I,
don't
think
it's
that
the
call
would
be
different.
It's
more
that,
like
ideally
in
my
perfect
world
you'd,
be
able
to
pass
a
flag
to
your
binary
and
it
would
determine
how
the
logging
was
performed.
But
what
I'm
seeing
suggests
you
actually
have
to
compile
the
binary
with
flags
that
then
it
influence
how
it
logs
am
I
missing.
Something.
E
It's
annoying,
but
I
mean
it's.
We
could
still,
it
would
be
that's
what
I
was
suggesting
like
you
could
have
a
debug
build
versus
you
know,
a
non
debug
go
and
I
would
just
have
different
levels
of
logging
compiled,
and
but
if
we
can
find
a
way
to
do
it,
just
a
runtime
or
like
you
know,
when
you
run
the
binary
you
set,
how
you
want
long,
your
it
I
would
be.
E
F
E
Ideally
I
mean
if
it's,
if
it's
something
that
can
be
influenced
that
way,
gray
just
like
my
concern,
is
that
when
I
was
looking
at
your
issue
having
the
past
like
trim
path
via
GCT
flags
like
that,
doesn't
suggest
that
we'll
be
able
to
do
that
anyway.
This
is
this
is
kind
of
like
just
a
technical
discussion
and
I'm
sure
we
can
sort
it
out.
Offline
I
mean
I,
think
the
look
we
all
would
like
to
have
more
useful
logs.
That's
that's
kind
of
my
take
away.
Yeah.
F
A
C
I,
discuss
about
the
column
chart
actually
so
I
think
yeah,
probably
if
other
seventh
and
I
look
at
what
we
have
I
can
have
a
look.
So
I
have
a
few
expectations
from
that
hand
chart
actually
so
mainly
it
was
like.
We
should
be
able
to
replace
the
method
that
what
we
are
using
currently
like
the
script
so
I
think
using
hands.
Art
I
feel
some
steps
are
not
done
by
that
and
chart
like
probably
and
then
joining
the
clusters,
which
current
script
is
doing.
I
think
we
should
write
a
wrapper
around
a
hand.
C
Chart
probably
it
would
be
easier
to
replace
the
current
deploy
operation
is
so
single
method
using
hand
shot
you
deploy,
otherwise
we
might
need
to
add,
like
user
documentation
using
a
hand
chart
for
now.
If,
if
we
can
find
a
way,
we
can
do
everything
using
am
sure
that
would
be
great.
So
that's
one
step
given
that
there
is
no
tests
in
CI
I
think
it
is
difficult.
Whether
whatever
changes
is
done
is
good
enough.
So
I
tried
pulling
it
manually,
but
I
need
to
assume
some
things
and
tried
doing
that.
I
was
not
successful.
C
D
What
we
felt
needed
to
be
done
further
on
the
helm
chart
in
that
pull
request
versus
as
a
next
step
and
I
guess,
Shashi,
one
I,
agree,
I
think
I
think
we
need
to
have
a
wrapper
script
like
you
suggests.
Do
you
do
you
think
that's
part
of
the
first
poll,
or
is
that
something
that
could
be
done
enough
follow-up.
E
C
F
Okay,
so
one
comment,
because
if
you
want
you,
the
charts,
please
make
sure
that
you
are
using
Cameron
to
ponton,
because
we
need
because
it
will
request
the
ham
need
to
handle
the
CRD
install
annotation.
So
that
means
because
we
need
to
make
sure
that
you
see
our
D
resources
will
be
pretty
first
yeah.
F
E
And
I
guess
I
would
echo
shock
she's
concerned
like
I?
Don't
I
don't
think
at
least
initially
the
helm
is
gonna.
Do
everything
the
deployment
script
does
and
I
think
the
goal
would
be
like
replacing
as
much
of
the
deployment
script
with
its
helm
equivalent,
but
recognizing
that
at
least
for
now
we're
still
going
to
need
a
wrapper
around
that.
E
And
part
of
that
I
think
is:
there's
there's
kind
of
a
separation
between
like
a
helmet
art
is
I
want
to
deploy
Federation
I'm,
the
user.
If
we
can
reuse
that
in
deploying
protesting,
CI
and
development
great
but
I
mean
these
are
I-
think
it's
important
to
know
that
they
are
actually
separate
use
cases.
The
user
may
want
to
join
arbitrary
clusters
for
development.
We
want
to
join
very
specific
clusters
that
you
know
we've
deployed
ourselves,
you
know
in
CI
or
whatever
so.
B
B
I'm
in
process
of
having
so
what
that
PR
does
is
a
simple
planner.
So
the
algorithm
of
distribution
of
job
for
parallelism
and
completions
is
quite
simple,
I'm
working
on
a
more
complicated.
Let
me
call
it
a
more
complicated
planner
which
can
do
the
job
planning,
observing
the
completions
and
parallelism
from
the
testers.
So
I
I
am
hoping
that
kicking.
It
can
also
learn
it
before.