►
From YouTube: Kubernetes SIG Federation 20170706
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
A
C
D
Think
in
terms
of
agenda
I
think.
B
D
To
the
bottom
of
like
what
we're
doing
going
forward
is
more
important
to
me.
The
last
meeting
called
into
question
the
approach,
the
current
approach
of
implementing
a
federation
control
plane
to
distribute
applications,
multiple
clusters
and
unless
we've
decided,
that
is
a
viable
solution
going
forward.
I'm,
not
sure
the
relevance
of
stateful
sets
of
jobs
or
any
other
additional
ap
is
to
that
control
plane.
D
D
E
I'm
going
to
disjoint
I
missed
the
last
few
minutes
of
the
last
meeting
and
I
was
on
vacation
before
that.
So
I
got
a
bit
of
catching
up
to
do
so,
I'm
curious,
so
how
many
people
are
there
or
how
significant
are
the
concerns
that
the
current
approach
is
not
viable,
I
mean,
given
that
it
has
been
going
for
some
years
now
and
it's
being
pretty
widely
reviewed
and
presented
at
conferences
and
whatever
none.
E
What
are
the
it's
not
clear
to
me?
What
the
specific
problems
are
that
we
need
to
resolve
that
are
not
resolvable.
In
the
current
context,
I
mean
it's
clear
that
there
are
a
set
of
outstanding
issues,
so
authorization
is
well
being.
You
know
right
at
the
top
of
the
priority
list
for
some
months
now,
it's
not
a
year
when
I'm
statement,
and
we
need
to
resolve
that
issues
that
we
think
we
cannot
resolve
with
the
current
sort
of.
D
Architecture
and
design
I
mean
the
baseline
reason.
We're
having
this
discussion
is
because
it
seems
that
Google
does
not
consider
it
a
viable
solution
and
is
going
to
pursue
alternatives,
and,
given
that
you
know
they
have
smart
people
working
on
this,
they
have
concerns
that
are
presumably
legitimate
and
they
didn't
think
they
could
overcome
them
with
a
reasonable.
You
know
time
and
investment
budget
and
to.
E
Do
we
have
I
mean
I
had
a
discussion
with
Christian
and
Michael
ago
and
I
asked
them
specifically
that
question
and
that
wasn't
the
impression
I
got
from
them.
So
is
there
anyone
from
Google
who
can
confirm
or
deny
what
maruja
said,
but
that's
I
think
that's
not
from
Google.
What's
the
most
polluting.
B
B
I
apologize
if
I
am
so
I
think
the
challenge
that
we're
having
right
as
we're
going
into
care
planning
as
we're
looking
at
current
investment,
a
lot
of
the
Federation
API
issues
around
version
skew
around
solving
a
lot
of
the
customer
related
issues
to
seem
really
tough
to
funds,
or
maybe
not
the
easiest
way
to
solve
it
by
going
in
through
the
Federation
API.
So
we're
looking
at
alternatives
right
area,
I,
don't
know
the
speaker,
sorry
who's
all
right!
This
is
a
Jessie
brown,
sorry
I'm
pretty
new
on
the
team.
F
B
Google,
correct,
okay
and
I've
been
involved
in
a
lot
of
the
the
planning,
as
we've
been
trying
to
pull
this
together,
and
so
it's
not
so
much
that
word
we're
abandoning
Federation
API
as
where
we're
not
investing
in
it
right
now
and
we're
trying
to
make
sure
that
there
is
ongoing
support
for
it
in
the
community.
Right
as
we
continue
to
try
to
solve
these
issues
in
a
way
that
seems
more
tractable
for
us.
B
The
ability
to,
for
instance,
route
traffic
in
a
partitioned
or
jurisdiction
way
right,
where
all
traffic,
for
instance,
within
Switzerland,
would
stay
within
Switzerland
for
certain
customers
that
require
it
or
the
ability
to
route
traffic
between
clusters
in
a
clear,
concise
fashion.
That's
controllable
and
meets
customer
needs.
A
lot
of
the
feedback
that
we've
been
getting
from.
Customers
is
the
current
ways
to
hard
to
figure
out
and
could
potentially
go
wrong
or
make
some
uncomfortable
anyway,
and
want
a
more
explicit
way
of
being
able
to
route
and
low
bounce
yeah.
E
And
so
is
that
just
for
me
to
understand
it
is
the
proposal
to
do
not
have
a
federated,
so
one
way
I
can
imagine
of
addressing,
that
is
to
extend
the
API,
for
you
know,
federated
ingress
or
whatever
it
happens,
to
be
to
explicitly
kind
of
accommodate,
more
sophisticated
routing
logic
and
another
one
would
be
to
tackle
it
in
a
completely
independent
of
the
Federation
API
way.
So
is
your
thinking
to
do
the
latter,
rather
than
the
former?
E
B
A
big
reason
for
reaching
out
to
the
sig
as
well,
and
why
why
we
came
in
last
time
is:
is
there
a
clean
and
easier
way
of
handling
this?
That's
not
an
external
tool
is
external
way.
The
easiest
we're
looking
for
information
to
an
alternatives
right
now
we're
in
the
middle
of
like
trying
to
prototype
and
figure
out
an
alternative,
because
we
think
it
might
be
worth
pursuing
right,
because
at
least
that
is
some
of
the
feedback.
We're
getting
from
customers
is
maybe
an
explicit
tool
to
just
configure.
E
C
B
E
Okay,
I'm
just
trying
to
sort
of
wrap
my
head
around
where
the
thinking
is
right
now
you
know
forgetting
about
Federation.
For
the
moment
you
know
we
could
I
guess.
Instead
of
kubernetes,
you
could
have
a
bunch
of
independent
tools
which
which
used
to
configure
load
balancers-
and
you
know
certain
replicas
and
whatever
else,
but
we
didn't
do
that.
We
created
an
API
abstraction
for
creating
creating
sort
of
generic
load,
balancers
and
ingress
and
whatever,
and
then
you
know,
controllers
under
the
hood-
to
go
and
set
up
the
relevant
cloud
provider
infrastructure
to
do
that.
E
C
You'll
also
join
difficult.
Does
it
require,
like
a
long-running
controller
for
ingress,
we
needed
along
any
controller
in
Coweta,
so
I
think
without
saying
the
controller
module
with
this
it
means
there's.
No
one
time
configuration
that
you
set
up
the
Creator
static,
IP
details,
I'll
rule
calling
rooms
and
stuff.
You
don't
need
a
nominating
controller.
C
E
E
A
It
suddenly
discussion
v-neck
with
that
with
users,
is
to
realize
that
some
users
have
a
lot
of
clusters
and
integrate
with
them
through
integrate
and
deploy
through
their
own,
either
their
own
CIPD
pipelines
or
tools
that
are
external
to
Federation
and
that's
their
preferred
way
of
managing
multiple
clusters.
So
in
that
view,
is
it's
kind
of
developed
that
in
itself
have
been
alternatives
to.
C
This
cubic
line
led
by
bogs
this
some
people
are
integrating
in
spinnaker
there's
reflux.
They
need
so
like
a
lot
of
people
and
people
have
been
internet
tools.
Isn't
mister
haven't
open
cysts.
So
a
lot
of
people
have
already
solved
big
medical,
aesthetic,
language
problem.
By
other
ways,
we
can
totally
integrate
with
them
better.
I
they
provide
different
architectures
I
choose
one
I.
D
Think
the
advantage
of
those
types
of
solutions
is,
you
don't
have
to
worry
about
federating
individual
types,
because
you're
just
talking
to
individual
clusters
and
the
users
can
worry
about
versions
to
you
in
a
way.
A
identity
can
similarly
be
kind
of
like
handled
whatever
user
way
the
user
wants,
and
so
it
just
cuts
out
a
lot
of
complexity.
So
I
think
for
me,
like
we
will,
is
kind
of
raising
a
lot
of
concerns
around
the
support.
D
Ability
of
the
existing
solution
have
caused
Red
Hat
to
sort
of
reevaluate
whether
we
want
to
continue
supporting
a
Federation
control
plan.
The
existing
model
I
mean
there's
a
lot
of
different
I
mean
we
have
one
on
the
roadmap.
You
know
we
have
to
solve
a
versions
to
issue.
We
have
to
figure
out
how
to
deal
with
Federation
preferences
and
those
are
kind
of
probably
just
some
of
the
two
largest
scale
issues,
but
there's
also
the
issue
of
like
how
do
we
evolve
over
time?
D
D
E
E
So
you
know
having
large
numbers
of
clusters
and
deploying
you
know,
applications
similar
applications
into
many
of
them
and
having
those
applications
in
some
cases
needing
to
communicate
between
clusters
and
keeping
all
of
the
configurations
synched
up
and
moving
capacity
around
when
you've
deployed
it
into
the
wrong
place
and
etcetera,
etcetera,
etc.
So
I
have
many
years
of
experience,
running
application
large
distributed
applications
across
multiple
clusters,
using
the
approach
which
I
think
you
described
earlier,
and
it
has
many
many
many
problems
so.
D
E
Which
is
how
we
did
things
with
Google,
so
I,
don't
know
what
box
is
proposal
is,
but
but
many
of
the
alternatives
you
know,
look
more
like
the
world.
Even
if
you
just
have
got
a
single
cluster.
There
was
kind
of
the
world
before
kubernetes.
We
have
these
procedural
methods
of
pushing
software
out,
and
then
you
have
more.
The
kubernetes
model,
which
is
I,
would
typically
or
typify
as
a
de
character
model
where
you
specify
what
the
desired
world
looks
like,
and
then
you
have
a
long-running
process
in
the
form
of
kubernetes.
E
D
As
I
understand
it,
you
basically
have
Kiev
applier
has
a
controller
running
in
each
cluster
and
it
targets
a
git
repo
and
it
specific
path
within
that
repo
and
it
basically
synchronizes
the
kubernetes
configuration
like
the
animal
whatever
with
cluster
state,
and
so
you
don't
have
a
centralized
model.
Necessarily
you
can
certainly
have
that
can
be
one
layer
of
a
pipeline
final
layer
of
the
pipeline
that
actually
gets
the
configuration
applied
to
a
cluster,
and
if
you
wanted
to
layer
things
like
policy
or
you
know,
authentication
authorization
all
that
sort
of
stuff.
E
Okay,
so
the
idea
I
mean
I've
done
that
before
as
well,
and
essentially
what
you
end
up
with
is
that
something
wants
to
generate
all
that
configuration
just
end
up
in
github
or
wherever
else,
and
typically
it
does
that
based
on
the
state
of
the
clusters.
So
does
it
does
some
calculations
and
figures
out?
E
You
better
go
and
update
that
configuration
which
involves
you,
know,
doing
more
calculations
and
and
running
some
scripts
and
doing
whatever
and
then
updating
whatever
isn't
get,
and
then
the
controllers
per
set
out
all
you
have
an
automated
system,
which
does
that
which
is
essentially
monitoring
the
clusters
figuring
out
whether
the
the
desired
state
in
each
cluster
is
actually
correct.
Given
the
current
state
of
the
world,
and
then
you
know
applying
those
changes
and
you
very
quickly
end
up
with
Federation.
E
D
The
question
is
whether
that's
a
use
case
that
dominates
the
other
use
cases
for
propagating
applications
to
multiple
clusters
and,
to
be
honest,
we're
seeing
more
people
who
have
relatively
static
setups,
who
are
doing
like
they
want
a
mirror.
You
know
multiple
data
centers
or
they
want
to
template
clusters,
so
they
can
now
give
a
specific
cluster
state
to
each
customer,
we're
not
necessarily
seeing
people
who
are
wanting
really
dynamic,
quick
propagation
of
workloads
across
clusters.
E
Yeah,
that's
that's
fair
enough
observation,
I!
Guess
what
I'm
not
that
familiar
with
this
is
what
exactly
the
problems
are
that
we're
facing
at
the
moment.
I'm
not
aware
of
any
particularly
difficult
problems
that
we
face
with
the
current
setup,
but
maybe
I'm
being
naive
or
stupid,
or
something
but
I'm
I'm,
not
sort
of
aware
of
significant
problems.
So.
D
A
Necessarily
focusing
on
burden
queuing
issues,
it's
difficult
to
see
where
the
Federation
control,
one
of
the
fetish
controllers,
could
have
resolved.
For
example,
a
one
of
the
cases
with
a
replica
set
progression
between
versions
where,
if,
if
a
federated
replica
set
would
have
been
spawned
on
some
of
these
clusters
and
the
clusters
are
at
different
versions,
we
would
not
have
been
able
to
converge,
essentially
at
all
we'd,
be
in
some
infinite
loop.
A
That
was
one
of
the
cases.
The
other
is
just
a
general
case
of
if
we
are
to
take
Federation
and
run
it
as
a
service
within
like
a
managed
offering
at
Google
we're
not
talking
about
one
year
with
haibach
like
two
years
and
typically
users
will
want
to
plug
in
whatever
kubernetes
version
they
want,
and
managing
upgrades
of
underlying
clusters
really
has.
Now
we
have
to
start
kicking
the
version,
skew
problem
seriously
and
all
this
we
have
to
do
this
over
to
baby
I
and
then
that
kind
of
begs
the
question
is
qadi.
A
Really
the
right
API,
when
all
we're
doing
for
the
most
part,
is
just
kind
of
replicating
objects
into
multiple
clusters.
It
seems
that
there's
a
simpler
way
to
achieve
that,
without
forcing
a
federated
controller
to
have
to
introspect
into
every
single
aspect
of
the
core
kubernetes
api,
so
that
that
was
one
of
the
main
issues
that.
H
Is
not
aspect
and
also
about
the
operational
aspect,
concern
right
many
people,
many
many
people
are
coming
to
Federation
because
they
find
the
equivalent
or
federated
success,
and
they
don't
really
want
the
complexity
of
running
another
control
place.
So
it's
one
of
the
reasons
why
taking
a
look
at
the
use
cases
in
trying
to
you
a
lightweight
tools
to
them
might
be
a
good
idea.
I
mean.
F
I
think
it's
reasonable
to
say
that
there
really
are
two
different
complexity
levels
here:
right,
there's
I
have
three
clusters
and
ten
apps
do
I
need
a
separate
control
play
to
solve
that
problem
and
those
people
most
people
might
if
the
control
plane
solves
all
the
problems,
but
at
the
same
time
they
are
incentivized
and
there
are
advantages
to
simple
solutions
to
those
problems.
And
thirdly,
I
guess
the
question
comes
up
through
at
what
point.
At
what
point
does
that
solution?
F
E
Of
the
reasons
so
go
ahead
and
sort
of
the
main
reason
that
Huawei
is
interested
in
this
is
because
we've
already
hit
those
limits,
and
we
have
many
customers
with.
You
know
hundreds
of
clusters
and-
and
there
are
other
customers
I've
spoken
to
who
plan
to
build.
You
know
thousands.
Potentially
you
only
have
to
think
of
the
retail
industry.
You
know
large
retail
chains
of
which
have
thousands
of
stores,
each
of
which
has
you
know
a
rack
in
the
corner,
with
a
bunch
of
servers,
doing
a
bunch
of
things
and
they
want
to.
E
E
E
I
guess
my
implicit
assumption
and
we
can
certainly
have
another
look
at
this
to
see
whether
it's
valid
is
that
that
if
the
big
complicated
problems
are
the
kind
of
more
necessary
ones
to
solve,
you
know
three
clusters
and
ten
applications
as
Clayton
mentioned.
This
is
not
something
that
needs
any
real,
significant
solution,
so
it's
actually
the
other
ones
that
are
interesting
to
me
and
once
you've
solved
those
the
bigger
problems
and
then
then
you
kind
of
have
solved
the
simpler
problems
as
well.
E
D
E
D
D
Federation
control
plane
I'm
going
to
have
to
you
know
if
I
have
three
clusters
and
I
want
to
have
a
reliable,
Federation
control.
Plane
I'm
going
to
have
to
have
you
know,
active
passes
on
the
control
plane,
maybe
on
at
CD,
like
it
kind
of
seems,
super
complicated
to
me
for
the
small
use
case,
so
I
guess
I'm
not
entirely
convinced
that
solving
it
for
large.
These
cases
really
is
going
to
provide
good
solutions
to
smaller
use
cases,
but
I,
don't
honestly,
think
those
small
use
cases
are
important,
I.
Think.
D
If
you
have
a
few
clusters,
you
shouldn't
be
using
Federation.
You
should
definitely
be
using
like
he
requires
something
simple
right,
so
I'm
not
suggesting
that
we
serve
those
use
cases
I'm.
Just
you
know,
I
have
100
clusters
and
I
want
them
to
be
all
the
same
versus
I
have
a
hundred
clusters
and
I
want
to
be
able
to
migrate
workloads
between
them,
based
on
utilization
and
all
kinds
of
other
things.
Those
are
the
two
use
cases
that
I
think
are
important
to
solve.
So
in
this
country.
I
Yeah
I
guess
one
of
the
things
I'm
curious
Quentin
for
your
perspective
on
is
you
know
when
I
look
forward
on
Federation
and
I,
see
where
the
existing
machinery
is
moving
around
aggregators
and
custom
resource
definitions
and
even
third
party
API
servers
a
bit
like
you
see
in
the
Service
Catalog
effort,
one
of
the
weird-looking
challenges,
I'm
thinking
about
when
I
look
at
the
existing
Federation
control
plan
is
like
we
would
have
customers
that
say,
I
like
Federation
or
something
like
it,
but
I
want
to
be
able
to
support
my
custom
resource
definitions
or
whatever
have
a
successor.
I
The
third
party
resources
were
or
I
also
want
to
be
able
to
support
federating.
My
third
party
API
server
that
upfront
of
it
in
the
aggregator-
and
you
know
the
things,
that's
a
challenge
to
me
and
the
current
Federation
model.
Is
you
end
up
having
to
tell
all
these
users
who
go
and
write
something
that
they
not
only
have
to
write
there?
Their
third
party
API
server,
but
they
need
to
go
write
their
third
party
iterator
or
it's
unclear
to
me
when
all
the
potential
use
cases
that
have
around
custom
object?
I
Definitions,
if
there
is
a
one
size
fits
all
type
of
Federation
model
for
it.
So
I
guess
one
of
the
things
I'm
curious
about
is
when
you
look
at
the
use
cases
that
we
always
seeing-
and
you
mentioned
like
a
retail
one.
For
example,
like
are
you
hearing
customers
asking
you
similar
questions
throughout
like
how
would
I
integrate
things
that
I
brought
in
via
the
aggregator
or
anything
else
that
might
happen
in
the
communities
ecosystem?
I
E
E
E
I
Like
a
practical
example
of
what
I'm
thinking
right,
it's
like,
let's
assume
I,
want
to,
let's
assume,
there's
a
customer
user,
that's
identifying
the
Service
Catalog,
it
says.
Ok,
that
seems
like
a
useful
way
that
I
can
write
brokers
that
can
provision
applications
into
my
clusters.
And
so
then
the
natural
question
is
well.
Ok,
I
want
to
federate
the
service
kettle,
because
I
want
to
go,
create
service
instances
in
each
one
of
my
clusters
and
I
went
bindings,
but
then
my
underlying
broker
can
go
provision
in
that
cluster
so
like.
I
If
you
choose
to
provision
services
in
the
cluster
say
via
the
catalog,
instead
of
just
doing
direct
tube
control,
you
know
run
style
deployment
stuff
like
very
quickly.
You
render
this
question
of
shoot.
I!
Guess
we
need
to
build
a
federated
service,
catalog
and
I'm.
Just
thinking
like
as
the
ecosystem
around
cube
grows
and
the
say
the
core
cube,
API
becomes
locked
down
more
and
more
like
if
you
start
to
invest
federaciĆ³n
as
a
way
of
managing
all
these
clusters.
I
I
D
Not
just
for
like
new
types,
but
I
mean
behavioral
changes
in
existing
types.
If
you're
just
talking
about
you,
know
templating
or
simple
propagation,
it's
not
an
issue,
but
I
mean
we
already
have
problems
around
demons
that
you
know
they
add
rolling
update
or
what
did
they
do
recently
in
it,
and
so
I
mean
there's.
We've
discussed
this
in
the
past.
How
Federation
control
plan
is
currently
implemented
is
in
a
constant,
like
race
that
we're
losing
with
cube,
adding
and
implementing
new
features
to
existing
types
or
adding
new
types.
D
E
Yeah
sure
and
I
haven't,
you
know,
thought
deeply
about
the
newer
aspect
of
the
way:
kubernetes
evolving.
You
know
the
ecosystem,
etc.
I
agree
I
mean
particularly
I.
Think
the
discussion
around
what
Derek
mentioned,
how
to
make
sure
that
we
don't
make
it
difficult
for
people
to
consume.
You
know
customizations
and
additions
to
kubernetes
and
its
general
ecosystem
is
a
very
worthwhile
thing
to
think
about,
and
I
don't
have
off
the
top
of
my
head.
A
perfect
answer
to
your
questions.
E
I
can
imagine
a
few
potential
approaches,
but
we
would
have
to
take
some
some
real
examples
and
try
and
figure
out
what
they
mean,
how
they
work.
It's
not
clear
to
me:
I
mean
I.
Guess
some
of
the
stuff
seems
to
be
inherently
complex,
I
mean
if
you,
if
you
want
to
deploy
something
across
multiple
clusters,
and
you
want
to
set
up
load
balancing
between
them
and
you
want
to
have
that
dynamically
managed
based
on
load
in
the
clusters
or
traffic
flows
or
whatever.
B
I
think
that's
been.
The
challenge
we've
been
having
is
the
a
lot
of
the
use.
Cases
are
quite
a
very
specific
configuration
or
data
test
back
and
order
for
it
to
really
be
useful
and
just
use
a
really
bad
analogy.
It's
like
trying
to
work
on
a
watch
through
a
keyhole
sometimes
and
that
the
API
doesn't
really
fit
all
the
different
use
cases
and
there's
no
way
of
getting
data
through
or
in
in
a
clean
way
without
doing
weird
stuff.
Sometimes.
B
What
you're
describing
sure
so,
for
example,
with
jurisdictional
jurisdiction,
specifically
one
use
case
that
I
ran
across,
is
that
most
customers
actually
care
more
about
preventing
data
from
leaving
a
specific
cluster
from
the
jurisdiction
perspective.
Then
they
necessarily
care
about
specific
data
getting
routed
to
that
cluster
100%
of
the
time.
So
a
key
part
is
setting
up.
Jurisdiction
is
not
so
much
just
configuring
specific
ingress
rules,
but
also
making
sure
that
egress
rules
are
strictly
enforced
and
validated.
B
So
that's
something
that's
very
specific
to
jurisdiction
and
probably
also
very
specific
to
their
specific
jurisdiction
needs
trying
to
modify
like
a
single
data
object
and
making
it
handle
that
and
then
also
making
sure
that
it's
actually
working
correctly
is
I.
Don't
think
it
fits
the
the
API
model
very
well.
Well,.
A
A
A
F
I
want
to
highlight
that
that's
actually,
a
really
important
point
is
that,
like
a
lot
of
Federation
cases
tend
to
be
extreme
one
direction
or
other
they're
hard
problems.
They
bred
different
people
are
going
to
choose
applications
that
are
federated
around
the
world
that
have
to
need
certain
capabilities
or
features
of
the
underlying
platforms.
So
when
we
think
about
the
Federation
abstraction,
we
don't
actually
have
a
model.
That
is
an
inside-out
abstraction.
F
E
F
Opposed
to
provide
our
generic
provider
abstraction
so,
for
instance,
storage
paper,
the
details
of
the
different
storage
mechanisms.
If
you
are
in
a
scenario
where
you
actually
needed
to
take
advantage
of
very
specific
storage,
API
versus
behaviour,
it's
unlikely.
The
cute
persistent
volume
mechanism
would
work
as
a
loose
analogy
to
the
same
thing
for
global
load,
balancing
or
global
DNS
routing
and
distribution.
F
So
I
can
certainly
say
that
there
will
be
certain
cases
where
it
is
more
profitable
or
useful
for
someone
who's
made
a
choice
on
a
particular
technology
to
build
an
integration
that
fits
cleanly
with
global
federation.
Even
if
global
federation
isn't
the
one
providing
that
feature,
and
we
should
stand
in
the
way
of
that
yeah.
E
I
mean
this
is
this
is
actually
a
discussion
that
sort
of
is
independent
of
Federation,
and
this
whole
discussion
came
up
in
the
context
of
ingress
yeah
and
there
was
I
think
a
conclusion
where
one
should
be
able
to
use
something
like
ingress
in
a
platform
independent
way
and
then
explicitly
break
out
of
that
and
say:
okay
I'm
now
into
the
non-portable
portion
of
the
ingress,
where
I'm,
configuring,
nginx
or
I'm
configuring
load,
balancers
or
whatever
and
I
get
more
powerful
stuff.
But
my
application
fundamentally
becomes
non
portable
yeah.
F
E
I
think
the
same
applies
to
Federation
by
Frank.
Rizzo
in
grease
is
a
good
example.
So
this
is
nothing
stopping
you
at
the
moment
from
creating
a
federated
ingress,
which
you
know,
configures
load,
balancers,
specific
stuff
in
your
ingress
and
provided
that
all
your
clusters,
you
know,
use
those
kind
of
load
balancers
that
will
propagate
into
the
clusters,
and
so
the
most
private
stuff
should
work
and
then
because
anything
in
the
model,
although
that's
a
creep,
is
that
or
you
can?
B
Was
their
interest
and
going
over
maybe
in
a
separate
venue,
some
of
the
specific
these
cases
and
maybe
bringing
storming
on
ways
of
solving
this
we've
got
a
significant
list
and
I
think
it
might
be
helpful
for
the
community
to
sit
down
and
talk
about
them.
Maybe
not
in
the
context
of
this
meeting,
maybe
a
email
discussion
or
on
a
doctor.
Thinking
like
that.
E
Yeah,
my
gut
feel
is
that
we
that
a
doc
discussion
by
itself
is
not
ideal
but
similarly
sitting
in
a
meeting
where
we
haven't
actually
got
a
concrete
list
of
things
to
talk
about
an
address
and
either
sold
or
not
solve.
It
is
also
not
ideal.
So
I
guess
perfect
in
my
suggestion
would
be
that
we
actually
prepare
an
agenda
of
specific
things.
We
want
to
try
and
figure
out
solutions
to
known
problems,
and
then
you
know
have
a
fairly
formal,
impersonal,
BC
discussion
to
address
those
or.
J
Even
a
face-to-face
other
six
do
it
this
way
to
do
a
high-throughput
discussion
on
a
series
of
gnarly,
complex
topics.
Red
hat
will
fly
engineers
out
to
Google
if
you
want
to
meet
them
great
campus
in
Mountain
View
much
your
mother
other
folks,
but
this
is
it's
a
good
way
to
avoid
this
dragging
out
over
a
couple
of
weeks
and
to
just
get
together
and
figure
it
out
cool.
E
J
A
E
E
E
Think,
because
a
single,
a
given
company
decides
not
to
invest
heavily
at
any
point
in
time
in
something
Federation
or
anything
else,
for
that
matter
doesn't
necessarily
mean
that
other
companies
will
not
want
to
and
should
not
be
allowed
to
so
I
mean
we
certainly
have
like
a
strong
set
of
incentives
to
continue
investing
this
in
this.
We
can
obviously
do
it.
You
know
in
proprietary
stuff-
or
you
know,
outside
of
kubernetes,
but
we'd
prefer
not
to
if
we
can
contribute
it
to
the
broader
community
in
a
sort
of
mainstream
part
of
kubernetes,
but.
A
I,
don't
know
that
anybody's
suggesting
that,
but
I
think
it's
like
if
your
cig
lead-
and
you
want
to
continue
pursuing
this
within
the
cig,
scoping
or
like
answering
a
lot
of
what
naruse
questions
were
in
terms
of
addressing
the
issues
for
one
a
many
of
them.
He
brought
up
in
the
engineering
worksheet
assigning
people
on
them
and
trying
to
determine
how
much
work
is
involved.
If,
if
the
goal
is
to
bring
state
starts,
Federation
API
to
production,
I
would
think
that
would
be
a
priority.
Are.
E
Totally
and
we
have
people
we're
certainly
willing
to
invest
in
problems
that
we
believe
exist,
we
have
to
run
the
stuff
in
production
to,
but
if
you
don't
know
they
exist
or
if
we
don't
think
that
they're
valid
concerns,
then
then
you
know
we
may
not.
We
may
choose
not
to
invest
them,
yeah
working,
clear
that
list
and
figuring
out.
What
to
do.
You
know.
I
So
I
think
one
of
the
things
I'd
like
to
see
is
just
like,
and
maybe
the
Google
folks
are
calling
us
all.
Those
like
right
now,
I
feel
like
there's
an
easy
thought
that
Federation
would
solve
all
your
problems
that
spanned
all
your
potential
clusters,
like
I,
think
for
the
comments
that
we
was
talking
about
it,
but
you
can
more
critically
identify
what
what
set
of
problems.
E
Yeah
and
equally
validly,
and
it's
I,
guess
useful
every
couple
of
years
to
step
back
and
just
you
know
with
a
blank
sheet
of
paper
and
say:
is
there
a
you
know
now
that
we
know
more
than
we
knew
sometime
ago?
Is
there
a
significantly
better
way
of
solving
these
problems
and
one
could
make
the
same
argument
for
in
us-cuban
Eddie's?
Should
we
step
back
and
say
you
know,
did
we
go
down
the
wrong
path
here
somewhere
and
and
should
be
back
up
and
do
things
differently?
E
And
also
you
know,
we
have
different
people
in
this
group
have
different
sets
of
experience.
I
have
my
background
in
sre
and,
and
you
know,
running
very
large
systems,
but
I
don't
have
a
lot
of
experience,
running
very
small
systems,
so
the
people
doing
that
might
be
able
to
provide
some
valuable
inputs
that
I
may
have
less
insight
into.