►
From YouTube: Kubernetes Federation WG sync 20180117 part1
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
In
terms
of
agenda,
I
don't
have
a
lot
on
the
agenda
today.
Last
two
meetings:
we
actually
focus
the
discussion
around
the
v2
API,
which
also
led
to
some
discussions
about
use
cases
which
did
not
limit
themselves
to
Federation
alone.
Probably
some
new
space
is
also
spanning
the
overall
multi
cluster.
B
A
A
So
yeah
we
were
discussing
like
I
entering
on
the
stuffing
and
then
one
of
the
points
came
up
about
the
environments
which
are
important
to,
for
example,
red
hair
or
anybody
else.
Who
might
be
the
consumer
of
this
right
now?
Well,
they
might
intend
to
see
the
support
ejection
so
for
us,
for
whoever
it
is,
who
always
flow
so
which
is
and
sort
of
an
on-prem
version
of
gaiters,
and
some
features
like
ingress
infiltration
are
currently
supported
on
on
DC
alone.
A
A
B
Don't
think
being
prescriptive
helps
us
at
this
juncture,
at
least
with
regards
to
the
v2
API
I.
Think.
Certainly
my
goal
and
I
think
red
hats
goal
is
making
sure
that
a
v2
solution
is
modular
and
can
be
deployed
in
different
configurations,
depending
on
the
use
case,
which
would
mean
that
maybe
some
people
would
want
an
active
control
plane
that
was
dynamically,
making
scheduling
decisions
and
that
would
seem
to
be
always
use
case.
At
least
we've
also
had
other
customers
that
you
know
at
least
initially
one
something.
A
B
A
B
Yeah
I
think,
once
we
have
an
API
that
at
least
is
sort
of
the
base,
the
common,
the
common
element
for
all
this
stuff,
then
interested
parties
can
start
working
on
solutions
that
suit
their
use
cases,
hopefully
not
stepping
one
another
on
one
other,
duplicating
work,
but
also
not
compromising
what
they
need
in
favor
of
what
somebody
else
I
know
I
just
wanted.
My
cake
and
I
want
to
be
able
either
to
yeah.
C
I
think
Maru,
it
would
be.
It
would
be
useful
if
you
could
have
document
the
requirements
and
plans
you
have
because
a
pattern
that
I've
seen
developing
is
that
people
come
up
with
a
proposal,
and
then
you
come
up
with
a
bunch
of
reasons
why
it
doesn't
fit
with
your
plans
that
have
not
necessarily
been
clearly
expressed
before
so
I.
Think.
C
If
there
is
such
a
plan,
it
would
be
good
to
put
it
on
paper,
and
then
people
could
use
it
as
a
input
into
any
proposals
they
put
forward
and
take
it
into
account,
as
opposed
to
put
forward
proposals,
without
necessarily
understanding
what's
in
your
head
and
then
have
you
shoot
them
down
for
reasons
that
the
proposer
could
not
have
been
aware
of
before
putting
the
proposal
together.
Well,.
B
I
mean
I
should
say
that
I'm
not
intending
to
like
the
goal
here
is,
is
having
enough
separation
of
concern
that
people
can.
You
know
somebody
wants
to
do
something
new
that
nobody
else
is
doing.
They
can
do
it
without
having
to
worry
about
whether
it's
going
to
be
supportable
or
whether
it's
going
to
be
interfering
or
conflicting
with
what
somebody
else
is
willing
to
do
like
the
example
of
a
push
versus
pull
model.
I
just
want
an
API
that
you
know.
A
lot
of
people
have
defined
things
at
us.
B
You
know
with
authorization
and
hierarchical
name
spacing,
and
if
somebody
wants
to
implement
you
know
a
pull
controller
that
uses
that
they
can
do
that.
Somebody
wants
to
implement.
Re-Implement,
like
you
know
the
federation
control
planes
push
model.
They
can
do
that.
So,
to
my
mind,
it's
not
a
matter
of
enumerate
all
the
possibly
use
cases.
It's
a
matter
of
providing
sufficient
separation
concern
that
people
don't
have
to
worry
about.
You
know
whether
it's
going
to
fit
with
existing
things.
B
C
I
guess
I
guess.
My
concern
is
that
there
are
people
who
have
code
and
have
written
code
and
are
wanting
to
write
more
code
and
I
think
they
should
be
encouraged
to
write
code,
even
if
it
doesn't
fulfill
all
the
unspecified
or
undocumented
requirements
of
all
parties.
And
those
can
certainly
come
back
and
take
that
code
and
refactor
it
or
you
know
those
kind
of
things
in
or
reuse
it
in
ways
that
it
was
perhaps
not
originally
intended
for
I.
B
Yeah,
but
that's
I'm,
just
saying
that
the
world
to
me
is
changing
a
little
bit
and
we
are
making
progress
like
on
the
API
side,
just
a
matter
of
keeping
things
separate
enough
that
if
you
want
something,
you
add
something
to
support
that
rather
than
oh
I
have
to
actually
integrate
it
super
tightly
and
it
might
interfere
with
what
other
people
are
doing
like
I
guess
I'm.
My
headspace
is
maybe
a
little
bit
different
than
yours
and.
B
The
right
we're
working
on
that
like
they
have
something
we
have
basically
a
proposal
that
flushes
out
this
kind
of
decomposition
of
the
API,
and
it's
not
quite
ready
to
show,
because
we
don't
really
there's
some
sort
of
especially
around
integration
with
the
cluster
registry.
There's
a
few
gotchas
that
we
don't
really
want
to
impose
in
the
community
without
having
thought
about
it
and
not
impose
but
like
to
deliver
something
where
it's
like.
There's
a
little.
There's
too
many
unanswered
questions,
but
we
are
hoping
to
have
something
to
show
next
week.
Can
you.
D
B
A
B
C
Until
such
time
as
your
future
plans
are
fleshed
out
and
shared
and
then
used,
you
know
refactor
the
code
or
do
whatever
needs
to
be
done
to
accommodate
your
future
plans
with
as
little.
You
know
waste
of
effort
as
possible,
but
I
don't
not
be
able
to
align.
You
know
numerous
unspecified
future
plans.
B
Don't
think
anybody
is
trying
to
like
I,
think
I
I
think
we've
tried
to
be
explicit
that
we're
not
trying
to
block
any
contribution
anybody
can
do
whatever
they
want.
You
know,
certainly
there's
no
reason
to
say:
oh,
you
can't
do
that
because
we
have
this
new
API,
that's
going
to
be
doing
things
differently.
Look.
B
A
Yeah,
actually,
this
next
pointer,
which
I
have
highlighted
right
now,
this
sigh
I
put
explicitly
over
here
to
maybe
get
some
pointers
about
what,
for
example,
Red
Hat
is
doing
and
can
be
listed
out
over
here.
Maybe
but
a
simple
pointer
might
be
okay
and
or
there
might
be
a
nice
additions
with
respect
to
the
current
or
ongoing
work
which
probably
we
have
missed
out,
which
I
have
missed
out
in
the
same
out
in
this
backlog
that
can
be
dissipated
or.
D
I'm
sorry
I'm,
not
Shh
I
heard
two
different
things.
I
one
of
them
was
the
the
second
one
was.
So
that's
like
there's
a
desire
to
make
sure
that
we
understand
ongoing
work.
It's
happening
right
now
on
kubernetes
Federation
League,
though
right,
okay,
I
did
not
understand
what
the
first
one
was.
The.
D
C
A
short
ball
because
I
was
I,
think
you're,
probably
responding
to
what
I
said
that
there
was
not
a
concern
at
all,
okay,
a
concern.
That
was
more,
that
you
know
when
we
go
through
these
items,
for
example,
any
work
items
that
are
proposed
to
be
done
today
or
tomorrow
next
week
that
they
may
not
line
up
with
with
the
work
that's
happening
at
Red
Hat,
which
has
not
been
shared
with
the
community
yet
and
we
should
not
block
them
on
that
basis
and
Meru
is
a
suit.
C
C
I
can
think
of
very
easy
ways
to
reuse
whatever
we
might
build
today,
based
explicitly
on
a
push
model
and
for
a
cool
model,
I
mean
it.
Doesn't
it's
not
a
huge
gap
between
the
two,
but
we
don't
need
to
go
into
that
discussion,
so
that
was
that
was
the
main
point.
Not
not
any
accusations
of
Herbert
work
happening
at
reddit,
just
to
be
careful.
Okay,.
B
A
Yeah
there
is
one
point
like
in
discussion
with
Chevy
that
came
up
and
did
that
I
think
it
makes
sense
that
we
share
with
the
Perdition
work
group
at
least
I.
Think
it
also
makes
point
makes
a
point
to
share
this
in
that
multicast
community,
probably
next
week
that
you
want
to
talk
about
this.
So
there
was
a
yeah
you
can.
You
can
go
ahead:
okay,
yeah!
This
is
related
to
the
existing
regression
code
and
the
deployment
mechanism
or
the
CI
jobs
which
we
had
so
which
relies
on
deploying
multiple
clusters.
A
A
B
A
Yeah
kubernetes
anywhere
was
is
having
the
some
more
issues,
so
I
think
they
are
not
going
to
continue
further
in
that
line.
So
and
most
surely
most
of
the
folks
are
focusing
on
buster
API
right
now.
Okay,
but
they
exist
easier.
Jobs
are
still
using
communities
anywhere,
which
works
for
their
scenario.
The
previously,
when
I
attempted
to
introduce
multiple
cluster
deployment
using
combination
in
their
information,
we
happen
to,
like
we
needed
a
cloud
provider
support
in
the
clusters
that
was
not
possible
in
the
first
one,
so
that
was
called
at
that
time.
So.
B
If
the
cluster
API
is,
is
kind
of
a
I'm
assuming
based
on
what
little
exposure
I've
had
that
it's
kind
of
a
cloud
agnostic
API
for
provisioning,
alright-
and
my
question
would
be
like-
can
we
rely
on
the
maybe
maybe
kubernetes
I
mean
anywhere
is
kind
of
the
same?
I
was
just
concerned
like
this
doesn't
preclude
doing
local
deployment?
Doesn't
where
do
we
have
other
mechanisms
planned
or
not.
A
D
A
D
A
C
I
would
I
would
recommend
I'm
personally
a
little
frustrated
that
we've
been
through
so
many
different
ways
of
trying
to
build
clusters
trying
to
keep
up
with
the
you
know,
tool
of
the
day
and-
and
it
seems
before
the
tool
of
the
day
is
actually
stable
and
usable.
They
abandon
it
for
a
new
tool
of
the
day,
which
is
not
yet
ready,
and
you
know
I'm.
Just
being
blunt.
I
would
personally
recommend
that
we
just
you
know
this-
is
such
a
small
part
of
what
we
do
as
a
group.
C
I
would
strongly
recommend
that
we
just
wait
until
they
have
a
stable
solution.
That
I
mean
it
sounds
like
kubernetes
anywhere
is,
is
in
its
user
requirements,
and
an
implementation
description
is
what
we
need
for
it.
I
II.
It
deploys
using
standard
tools
across
multiple
clouds,
but
it
sounds
like
it
just
doesn't
work
if
I'm,
paraphrasing
what
you
said
and
they're
not
going
to
make
it
work,
they're
going
to
start
new
thing
called
something
else
which
they
going
to
make
work,
but
which
doesn't
yet
work.
D
C
A
A
So
I
add
a
little
to
this,
so
to
clarify
that
to
clarify
the
Federation,
see,
I
still
use
its
cube
up
to
bring
up
the
questions
and
there
are
open
PRS
which
are
she
did.
Maybe
some
of
them
are
integrated.
Also
did
disillusion
was
not
able
to
support
the
cloud
providers
correct
so
because
of
that,
these
our
condition
CI
jobs,
are
not
necessarily
working
on
Google.
It
is
anyway,
and
there
has
been
some
some
active
work
which
she
initiated,
and
some
of
the
config
is
also
supported
him,
who
let
kubernetes
anywhere
support
cloud
provider.
A
Some
mechanisms
are
who
could
be
provided
where
it
can
support
local
provider
so
that
some
necessary
step,
for
example,
you
know
done
provisioning
can
happen
in
that
mechanism,
but
that
work
didn't
finish.
That
is
still
open,
so
we
are
sort
of
in
transition.
We
are
not
completely
in
to
kubernetes
anywhere
or
we
are
not
completely
without
it.
Also
and.
C
Okay,
so
it
sounds
like
we
need
to
get
off
kuba
because
that's
been
in
the
process
of
being
deprecated
for
a
long
time
and
that's
why
we
initiated
the
kubernetes
anywhere
effort
as
far
as
I
recall.
So
it
sounds
like
we
just
need
to
do
the
best
we
can
with
the
kubernetes
anywhere
effort
sounds
like
we're
halfway
there.
We
just
need
to
finish
it
well.
I
went
to
half
way
some
of
the
way
there,
as
opposed
to
abandon
it
and
move
to
whatever
it
is
cluster
API
which
doesn't
work.
It
yeah.
A
C
A
A
It
becomes
easy
for
them
and
it
to
me
it
appears
like
one
way
of
doing
or
a
different,
more
organized
way
of
doing
what
we
are
doing
today.
As
of
now,
in
addition,
the
core
game,
so
the
foundation
API
server,
is
just
a
variant
of
the
little
secure
server
that
is
correct
and
example
of
that
API
server
builder
also
will
do
the
same
thing,
so
the
API
types
are
API
objects
that
we
exposed
to
that
would
be
pretty
similar
to,
but
currently
the
Federation
API
server
is
doing
so.
A
One
point
of
work,
or
one
way
of
moving
to
a
more
organized
stuff,
might
be
that
whatever
we
have
today,
we
can
we
can
migrate,
as
is
where
the
addition
API
server
still
exposes.
What
among
each,
we
can
call
it
be
one
of
perdition,
API
I
expose
to
the
same
types
and
all
those
supported
objects
which
are
currently
supported
and
start
using
one
of
the
suggested
or
prescribed
mechanism,
for
example,
ATS
ever
build
up.
So
does
this
make
sense
so
far
or
have
I
erred
somewhere?
I
can
leave
corrected
if
I
have
and
yeah.
A
So
the
next
step
would
be
so
far
once
per
step
for
being
migrated
to
us
prescribed
mechanism
like
this,
and
next
step
would
be
that
we
someway
modularize
whatever.
Currently,
that
Beeman
is
exposing,
and
the
third
step
would
be
that
we
migrate
from
here
in
some
fashion
or
some
mechanism,
where
we
don't
break
away
from
this
and
maybe
have
a
veto,
so
that'd
be
money
due
to
poor
conferences.
A
It
might
be
different,
API
servers,
aggregated
together
or
they
might
be
in
the
same-
and
this
so
far
is
talking
about
only
the
spec
of
the
API
and
exposing
that
the
controller's
and
control
plane.
Another
portion
of
the
control
game
it's
set
aside
as
a
bomb
yeah,
Paul
I,
think
you've
started
to
say
something.
Oh
no,.
D
D
Let
me
let
me
share
my
own
understanding
and
I
think
we're
saying
the
same
thing,
but
I
don't
want
to
like
put
words
in
API
server
builders,
a
toolkit
that
will
help
you
plunk
out
a
new
empty
API
server
and
a
new
API
groove
and
API
resources,
and
it
seems
to
be
very,
very
useful
for
bootstrapping
new
things
it.
It
definitely
has
promise
as
like
in
in
another
dimension,
unrelated
specifically
like
Federation.
D
It
seems
like
it
has
a
lot
of
promise
to
ease
making
me
Vickie
eyes.
I,
wouldn't
say
it's
like
a
total
solution.
Yet
in
this
and
stuff
like
once,
you've
funk
out
an
API,
it
seems
like
when
you
go
to
change
it.
There's
like
you,
you
have
to
start
doing
some
of
the
work
of
like
understanding
the
guts
and
internals
of
you,
I,
think,
which
one
is
that
it
seems
like
it's
really
good,
flunking
out
new
smart,
basically
right,
yeah
I'm
on.
D
C
Just
interrupt
for
a
moment,
so
that
sounds
like
it's
kind
of
one-way
I
mean
the
terminology
that
was
used
long
time
ago
is
like
these
one
one-way
case
tools
versus
round
trip
case
tool.
So
so
you
can
basically,
you
know
stamp
out
one
of
these
things,
but
then
the
ongoing
maintenance-
you
don't
get
as
much
support
from
the
toolkit
right
yeah,
that's
my
impression.
Quentin
yeah,
that
makes
sense
I
mean
that's
the
classic
problem
with
these
things
and
so
they're
yeah.
D
B
To
just
add
a
couple
things
to
that
I
think
one
of
the
niceties
is
that
it
actually
encapsulates
things
like
cogeneration,
so
but
a
project
that
was
depending
on
API
server
builder
would
not
have
to
have
the
end
of
the
build
infrastructure
that
we've
inherited
from
kubernetes
kubernetes
and
that
each
API
server
project
has
had
to
construct
on
its
own
and
also
going
forward.
I
see
the
potential
for
API
server
builder
to
be
kind
of
a
hook
into
common
testing
infrastructure.
B
So
rather
you
know,
we've
inherited
testing
infrastructure
from
Kay
Kay
today
in
the
Federation
repo
going
forward.
I
would
anticipate
that
there
is
common
infrastructure
that
is
integrated
with
the
project
via
API
server
builder,
so
that
you
don't
have
to
maintain
it
or
to
worry
about
Reeve
entering
it.
It
just
kind
of
comes
it's
kind
of
an
interesting
amalgam
of
like
library
and
tooling
I'm,
not
saying
it's
there
yet,
but
to
me
it
definitely
has
promised
for
the
the
path
were
charting.
C
Yeah,
my
observation
of
our
reliance
on
other
tools
from
other
teams
is
that
it's
being
a
bit
of
a
mixed
bag
of
success
and
failure,
and
and
these
things
are
often
deprecated
and
or
not
supported,
and
if
we
do
need
to
fix
bugs,
we
sometimes
struggle
to
get
merged.
I
would
say:
let's
keep
this
on
our
like.
A
Today,
if
you
call
it
the
daemon
Federation
API
that
we
sort
of
try
to
and
continue
evolve
or
support,
and
they
show
that
there
possibly
is
some
transition
by
using
some
similar
mechanism
loss
and
replace
or
similar
code
what
it
could
be
anything
so
that
we
have
at
least
some
idea
of
how
we
idly
transition
to
that
be
to
what
were
the
economy
between
which
probably
is
not
very
well
defined.
As
of
now
so.
D
A
What
I
was
trying
to
say
is
that
yeah
this
whatever
I
mentioned,
that
was
just
a
suggestion,
like
whatever
early
understanding
that
I
have
about
about
the
new
API
and
the
mechanism
to
create
new
API
server
and
all
this
stuff.
What
I
am
more
concerned
is
about
some
common
consensus
and
planned
about
current
API,
which
maybe
we
can
call
v1
and
its
evolution.
We,
whatever
Federation
v2,
might
look
like
or
might
become
so
the
evolution
I
would
want
that
to
be
at
least
some
idea
should
be
in
place
which
can
chalk
out.
Okay.