►
From YouTube: Kubernetes Federation WG Sync 20181107
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).
E
D
It
just
to
me,
make
more
and
more
sense
to
really
explore.
You
know
meeting
this
use
case
using
Federation
v2,
and
so
why?
If
you
look
at
history?
Oh
it's
simply
a
collection
of
kubernetes
resources,
just
like
any
other
application
that
we
would
run
in
kubernetes-
and
you
know,
sto
is
very
similar
to
kubernetes-
is
getting
to
a
point
where
it's
beyond
just
okay.
How
do
I
run
and
manage
a
single
sto
service
mesh?
Okay?
How
do
I
go
ahead
and
have
them
meshes
across
all
of
my
clusters?
D
D
We
not
only
want
to
be
able
to
manage
sto
control
plane
across
all
of
these
different
clusters,
but
now
unify
the
capabilities
of
sto,
so
that
I
can
create
a
federated
route
rule
and
know
that
if
I
say
that
service
a
cannot
talk
to
service,
B
and
I
want.
You
know
every
instance
of
that
particular
service
pair
in
each
of
my
clusters
to
follow
that
same
rule,
I
could
create
a
you
know,
a
federated
destination
rule
and
know
that
that
rule
is
going
to
have
that
consistency
across
each
of
my
sto
service.
D
D
Federated
sto
and
just
a
quick
note
on
what
you're
seeing
here
is
so
I
I've
created
a
repository
called
FET
v2
manifests
and
within
there
I've
got
the
federated.
Sto
manifests
the
documentation.
These
demo
scripts,
probably
a
few
other
things
as
well
and
and
I'm
in
the
process
and
I
have
open
an
issue
on
sto
IO.
D
So
if
you
go
to
the
sto,
iOS
do
documentation
site
if
you're
unfamiliar
with
it,
and
basically
this
height
right
here,
you'll
see
that
here
for
docs
and
their
setup
and
tasks
and
so
forth,
and
there
is
a
section
somewhere
here.
That's
maybe
it's
under
examples,
yeah
enabling
multi
clusters
and
there's
a
few
different
options
here,
and
my
hope
is
that
we
can
gain
enough.
My
chair
to
need
to
have
this
type
of
documentation
exists
here.
D
D
So
what
about
existing
solutions?
So
not
only
was
I
exploring
Federation
v2
to
address
this
use
case,
but
I
really
started
within
the
ischial
community
and
saying
okay
well,
what's
out
there
and
what
what
I
came
across
was
a
lot
of
solutions
and
again
you
do
it
back
to
the
sto
documentation
site
and
see
this
for
herself
as
a
lot
of
the
solutions
that
I
have
found.
D
Most
of
the
solutions
that
I
found
was
extending
the
sto
mesh,
and
so
the
what
I
didn't
like
is
that
it
still
consisted
of
a
single
control
plane
and
the
users
that
I
talked
to
as
I.
That
out.
This
use
case
is
that
a
single
control
plane,
just
it
will
not
work
for
production
use
cases
and
so
I
went
with
those
solutions,
I
immediately
kind
of
put
a
cross.
Next
to
him
and
said
you
know
this
is
this
is
an
issue
that
needs
to
be
addressed.
D
Another
thing
I
see
with
the
solutions,
is
there's
this
emphasis
on
being
able
to
have.
You
know
service
a
and
mesh
a
of
cluster,
a
talk
to
service
B
and
mesh
B
of
cluster
B
does
kind
of
cross
mesh
cluster
communication
of
services
and
again
I
kind
of
go
back
to
my
use
case
and
what
I'm
getting
is
that
that's
not
as
a
common
of
use
or
a
requirement
that
there's
more
interest
in
having
kind
of
a
standard,
cookie
cutter
approach
to
say?
Okay,
this
is
how
I
manage
kubernetes
I
have
a
kubernetes
instance.
D
You
know
across
you
know:
what's
it's
40
50
of
them
50
kubernetes
clusters
across
the
world
and
each
of
my
applications
that
I,
deploy
or
attended,
deploy
or
kind
of
contain
within
that
cluster
and
pretend
you
know
many
of
them
exposed
and
kind
of
front-end
using
an
ingress
or
kubernetes
service
that
there
wasn't
really
much
of
a
need
to
say:
I
want.
You
know
a
service
in
one
cluster,
be
it
to
be
able
to
communicate
with
a
service
in
and
another
cluster,
not
to
say
that
that
doesn't
exist
at
all.
D
But
it's
just
not
as
common
as
the
need
or
the
desire
to
say.
I
want
a
very
simple,
cookie
cutter
type
of
approach
for
my
cluster,
the
applications
that
run
on
the
cluster
any
type
of
services
that
run
in
the
cluster
and
services.
You
know
one
of
those
services
being
like
a
mesh
service,
I
kissed,
you,
you
know
and
I,
don't
really
see
a
consensus
for
solving
the
problem.
D
Now
I'll
share
this
this
presentation
with
the
community
and
that's
actually
a
link
to
to
a
presentation
that
has
several
other
links
to
all
the
different
documents
like
design
Docs,
as
well
as
some
preliminary
repos
for
tools.
You
know
one
of
the
tools
is
a
kind
of
a
configuration
sync
across
sto
meshes,
but
one
of
the
things
or
what
I
see
is
that
there,
the
community
SEO
community,
is
trying
to
come
to
a
consensus.
D
You
know
and
I
say:
should
there
be,
because
you
know
I
I
think
there's
different
use
cases
out
there
and
I
don't
know
if
there's
necessarily
one
approach
that
meets
all
of
those
use
cases,
and
so
I'm.
Trying
with
with
this
approach
of
federated
is
do
is
to
stay
true
to
this
use
case
that
I've
described,
and
one
of
the
reasons
is
I.
Think
it's
it's
a
fairly
common
use
case,
and,
and
so
you
know,
there
may
be
four
or
five
different
ways
that
people
want
to
manage.
D
Iste
of
meshes
across
their
different
clusters
manage
their
applications
running
across
their
kubernetes
clusters,
but
I
think
this.
This
one
that
I'm
focused
in
on
it
is
is
one
of
the
most
common
and,
if
so,
I
think
it
could
be
good
for
the
Federation
v2
community
sto,
as
well
as
the
consumers
of
these
technologies.
You
know
I,
say
where's.
The
beef
is
that
you
know
if
you
spend
some
time
to
look
at
some
of
the
solutions
out
there
you'll
see
that
there's
no
real,
strong
community
behind
any
one
of
the
solutions.
D
You
know,
you'll
see
that
there's
not
really
much
uptake,
really.
No
users
that
are
starting
to
gather
around
and
and
again
kind
of
coming
back
to
Federation
v2
is
one
of
the
things
that
interested
me
was
that
you
know
the
strong
community.
That's
behind
Federation,
v2
I've
been
doing
the
open
source
stuff
for
about
eight
years
now
and
I
know
how
important
community
is.
D
You
know-
and
so
what's
so
special
about
the
Federation
about
federated
sto
and
I'll
jump
right
down
to
four
since
I
just
mentioned
in
just
reiterate,
you
know:
I
really
appreciate
all
the
help
from
the
community
even
being
able
to
get
to
this
point.
You
know
I
could
do
it
by
myself.
That's
for
sure,
and
so
I
really
appreciate
everyone's
help
and
I.
D
Think
that's
just
a
testament
to
you
know,
to
the
possibility
of
federated
sto
is
that
you
know
there's
a
lot
of
really
good
folks
here
in
the
community
that
not
only
helped
get
me
to
this
point,
but
I
think
can
help
take
the
solution
even
further.
But
let's
go
up
to
number
one,
the
consistency
right
again.
If
I'm
thinking
scale
I,
don't
I
don't
want
any
one
offs
and
so
I
don't
want
a
one-off
for
sto
to
be
able
to
manage
sto
and
to
manage
any
of
my
sto
enabled
apps
right.
D
I
want
to
be
able
to
create
federated
rules,
federated
virtual
services,
federated
gateways,
any
of
those
custom
sto
types
and
know
that
every
instance
of
that
particular
service
across
my
clusters,
running
on
an
sto
mesh.
Have
the
same
rules
are
exposing
the
same
front-end
in
the
same
fashion,
whether
it's
cluster
one
or
if
it's
cluster
100,
you
know,
number
two
I
think
is
really
important,
as
well
as
some
of
these
other
projects
that
I've
seen
you're
having
to
try
to
wrap
your
mind
around
more
tools,
different
types
that
you're
unfamiliar
with
and
how
do
these?
D
You
know
how
are
these
types
constructed
and
what
I
do
like
about
the
Fed
v2
is
that
if
you
understand
what
it
config
yeah,
it's
very
simple
abstractions
with
templates
placements,
overrides
very
easy
to
understand
and
and
then
any
of
the
types
that
are
federated.
It's
like
oh
I,
know
what
a
config
map
is
well.
A
federated
config
map
is
the
equivalent
right
and
so
to
me,
that's
it's
really
important
to
have.
D
You
have
a
very
easy
way
to
ramp
up
as
a
user
or
even
a
developer
for
fed
for
Federation,
v2
and
federated
sto,
and
so
from
an
SEO
standpoint
again
using
the
sto
custom
types,
whether
it's
a
virtual
gateway
or
a
gateway.
I
know
that
the
Federated
virtual
gateway
is
is
its
equivalent
and
I
know
that
it
pretty
much
looks
and
feels
the
same
way.
D
The
Federated
counterpart
as
it
does
a
standard,
sto,
custom
type
and
I
think
that
again
is
really
important
to
kind
of
break
down
the
barriers
of
getting
ramped
up
on
federating
sto
or
any
other
application.
Within
that
you
want
a
federated,
you
know
and
I
say
number
three,
the
best
of
both
worlds.
Not
only
do
I
get
that
uniformity,
but
we
also
know
that
there
are
times
that
you
need
to
have
differentiation
to
mate.
You
know
to
have
one
offs
here
there
and
I.
D
Think
you
get
the
best
of
both
worlds
with
fed
with
Federation.
V2
is
not
only
do
you
get
the
uniformity,
but
you
know
with
overrides.
You
know
for
a
particular
cluster.
Let's
say
one
of
my
clusters
in
this
example
that
I've
been
providing
is
a
development
cluster
and
I
want
to
use
different
secrets
or
different
service
accounts,
whatever
it
might
be,
or
different
configurations
in
my
config
map
I
had
that
flexibility
with
overrides,
you
know
in
one
of
the
use
cases
that
I
would
like
to
solve.
D
Next
is
upgrades
and
I
think
doing
live,
upgrades
ice,
I've
started
to
test
it
and
then
ran
into
just
challenges
and
the
challenges
that
aren't
with
Federation,
v2
or
federating
I
mean
this
is
a
challenge
just
within
trying
to
do
this
on
a
single
match
and
what
it
is
is.
As
this
tio
releases,
you
just
get
a
whole
new
giant
manifest
that
includes
all
of
the
sto
types
to
install
this
deal
from
scratch.
So
there
are
no.
D
D
You
know
prioritize
and
fix
open
issues.
I
think
Meru
is
probably
seen
me
open
up,
20
different
issues
and
some
of
them
I
need
to
go
back
and
either
close
or
just
expand
upon,
and
there
are
some
issues
that
have
been
addressed
or,
as
I've
been
going
through
this
process
and
again,
I
really
appreciate
all
the
help
for
them
from
the
folks
that
have
been
helped
get
us
to
this
point.
D
D
All
right
demo,
let's
go
back
to
the
demo,
really
quick
and
see
where
we're
at
here.
Let
me
just
kind
of
scroll
back
to
where
I
kicked
off
and
I'll
just
talk
through
this
really
quick
and
so
I
do
have
this
simple
run
demo
script
first
thing
that
that
we
do
is
we
federated
Ischl
kubernetes
resources
needed
things
like
cluster
roll
cluster
roll,
binding
custom
resource
definition,
you're,
probably
familiar
that
5v2
has
has
these
core
types
like
secrets
and
deployments
and
so
forth,
and
for
anything,
that's
not
core.
D
D
There
is
this
issue
that
I
opened
up
issue
number
three:
five:
four:
where
I
need
to
go
ahead
and
update
these
two
service
accounts
or
basically
a
service
account
per
cluster.
You
know.
So
let
me
pause
for
a
second
and
just
talk
about
we're
on
that
here.
So
before
I
ran
this
demo,
you
know
I,
essentially
just
followed
the
the
Federation
v2
user
guide
set
up
a
couple
kubernetes
clusters.
D
Every
cluster
that
essentially
Federation
b2
manages
there
is
a
service
account
that
is
created,
that's
used
so
that
the
Fed
v2
API
can
actually
go
out
and
create
the
target
resources
in
those
clusters
as
needed,
and
what
I
found
with
issue
3
v
fours
is
that
there
was
a
permission
that
the
target
account
or
target
service
account
did
not
have,
and
so
so
yeah
so
I
have
to
go
ahead
and
basically
update
those
two
and
this
issue.
If
you
see
it,
it's
already
been
discussed,
and
it's
just
a
matter
of
implementing.
D
You
know
this
do
is
Creed
wants
to
have
its
own
namespace,
so
we
create
a
namespace,
and
then
we
install
federated
sto
and
installing
federated
sto
is
a
single
manifest
that
consists
of
a
ton
of
different
kubernetes
resources,
custom
resources
and
so
what
I?
What
I
did
is
I
took
the
standard,
sto
manifest
and
just
converted
all
those
resources
into
the
Federated
equivalent.
D
D
And
then
the
last
piece
of
the
installation
is
a
federated
horizontal,
Pato
scalers
and
one
thing
that
I
had
to
do
in
a
standard,
sto
installation
manifest
instead
of
just
stopping
at
the
horizontal
Patil
scalers.
The
installation
then
continues
to
proceed
with
creating
the
sto
custom
types
like
a
gateway,
virtual
service
and
so
on,
and
so
forth
route
rules,
or
what
have
you
and
I
had
to
basically
cut
the
installation
out
there,
because
what
we
need
to
do
what
you
don't?
D
What
you
see
here
is
going
back
and
federating
those
specific
custom
types
so
again
using
the
cube
fed
to
federate
command
and
federating
the
Gateway,
the
virtual
service,
all
that
good
stuff-
and
you
could
see
here
right.
So
all
these
custom
sto
types
that
need
to
be
federated
and
essentially
what
that
coupe
fed
to
federate
command
does
on
the
backend
as
it
creates
the
federated
federated
type
config.
It
creates
a
CR,
D
and
Murray
did
a
really
awesome
job.
D
I
appreciate
you
creating
that
that
functionality,
one
other
thing
that
I
had
to
work
around,
which
I
think
this
is
just
a
temporary
work.
Rob
from
the
feedback
that
I
got
from
Meru
is,
as
part
of
the
installation
is
sto,
creates
these
mutating
webhook
configurations
and
the
initial
mutating
webhook
configuration
has
I,
think
it's
a
CA
client,
sir
that's
empty,
and
as
one
of
the
control
plane
components
called
pilot
install,
it
creates
a
service
account
grabs
the.
D
The
TLS
assets
and
I
think
it's
the
CA
cert
that
it
takes
and
then
updates
patches,
The,
Associated,
mutating
webhook
configuration
with
that
TLS
material
and
what
I
found
was
kind
of
thrown
me
for
a
loop.
Is
that
I
initially
federated?
Let
me
tell
you,
I
put
configuration
and
and
I
just
wouldn't
see
it
update
and
I
just
and
then
finally,
autonomy
I
was
like
well,
you
know
the
way
that
Federation
v2
works
is
if
you
create
a
federated
resource
there.
D
You
know
there
and
you
try
to
go
ahead
and
change
the
target
resource
associated
a
federated
resource.
It
will
just
revert
it
right
back
all
right
as
a
synch
controller
says
wait.
You
know
this
propagated
versions,
change
the
constants
are
sort
of
different.
Let
me
go
ahead
and
revert
it
back
and
so
said:
oh
wait,
a
second!
Let
me
not
federated
and
then
it
worked,
but
from
talking
to
Meru
it
sounds
like.
Maybe,
instead
of
I
just
need
to
change
the
template.
D
So,
instead
of
looking
at
I
think
it's
a
version,
we're
gonna
look
at
generation
instead
and
see
if
that
solves
the
issue,
and
if
so
then
I'll
close
out
this
u3
thing,
and
then
you
know
I'm
just
checking
the
pods
and
make
sure
everything's
running
here
and
see
that
you
know
the
sto
control
plan
consists
of
several
different
components
and
for
cluster
1
and
cluster
2
they're.
All
up
and
running
I'm
checking
that
the
mutating
webhook
called
the
sto
sidecar
injector.
Is
there
I
label
the
default
namespace
and
I'm
labeling
it
with
an
injection?
D
It's
the
injection,
enabled
that
tells
a
sidecar
injector
to
go
ahead
and
inject
the
Envoy
or
the
sto
proxy
sidecar
for
every
pod
that
gets
instantiated
and
then
to
really
test
this
to
you
to
make
sure
that
it's
working
if
they
deploy
some
application
and
so
the
standard
sample
application
is
book
info.
There's
others
in
the
community.
But
this
is
the
most
common
and
most
well
documented.
So
I
go
ahead
and
create
the
book
info
application.
You
can
see
that
it
consists
of
several
different
services.
D
D
Sto
used
to
just
use
the
kubernetes
ingress
to
expose
services
outside
of
the
cluster
within
that
change
got
about
four
or
five
months
ago,
and
there's
these
sto
custom
types
called
the
gateway
in
a
virtual
service
that
are
used
to
now
expose
services
outside
of
the
mesh
and
cluster.
But
let's
just
and
so
really
quickly.
D
We
we
create
the
we
federated,
the
virtual
service,
that's
needed
for
the
book
info
gateway,
just
like
what
we've
done
throughout
this
demonstration,
and
then
we
create
the
book
info
gateway
right
doing
that
we
essentially
expose
a
front-end
outside
of
the
massive
cluster.
You
see
that
they
exist
there
and
then
the
last
piece
is
actually
test
right,
and
so
because
it's
gke
gke
gives
me
load
balancer
ip's.
This
is
for
the
cluster
one
SVO
book
info
gateway,
and
this
is
for
cluster
two.
D
But
before
I
test
that
which
the
tested-
and
it
looks
like
it
succeeded
here,
I
want
to
just
make
sure
that
these
pods
are
up
and
running
okay,
so
that
is
for
cluster.
One
change
the
context
to
cluster
two
good
and
let
me
just
curl
these
myself
just
to
make
sure
that
they're
good
all
right
I
did
it:
200,
okay
from
cluster
ones,
book
info
gateway
and
for
cluster
two,
and
what
we
can
do
if
you'd
like
to.
Let
me
go
ahead
here
and
is
there
a
chat.
D
D
E
D
The
next
thing
I'm
going
to
do
so
at
this
point,
walk
you
through
using
Federation
to
get
sto
control,
plane
up
and
running,
deploy
a
sample
application.
That's
been
federated
rights
across
the
two
clusters
that
make
up
my
Federation
and
what
you'll
see
here
with
a
sample
app
again
is
kind
of
the
common
demo.
You
see
every
time
I
refresh
for
the
most
part,
you'll
see
different
ratings,
or
this
is
part
of
the
review
service.
Excuse
me,
there's
a
reviews.
V1
v2
and
v3,
and
very
simply
v1
has
no
stars.
D
As
I
mentioned
in
earlier
occas,
federated
SCO
is
not
just
about
okay,
we've
got
things
running.
We
can
have
this
uniformity
for
multiple
instances
of
sto
control,
plane
and
the
applications
that
run
on
this
deal,
but
actually
using
that
the
sto
features
right
and
I'm
going
to
demonstrate
just
one
very
simple
feature:
Rob
rules
to
say
you
know
what
I
I
want
to
only
you
know.
I
want
to
basically
have
all
traffic
go
to
V,
one
of
the
reviews
service,
and
so
you
know
within
non
federated
world.
D
Alright,
and
so
basically,
what
we're
seeing
here
and
again
this
if,
if
I'm,
very
new
to
Federation,
this
all
looks
very
familiar
to
me,
because
I
would
create
a
virtual
service
and
my
virtual
service
would
look
just
like
the
Federated
equivalent
the
spec
template
right.
You
know
the
the
other
thing
that's
new,
with
the
Federated
equivalent
of
the
virtual
service
is
there's.
You
know,
there's
the
virtual
service
placement
that
goes
with
the
federated
virtual
service
placement
that
goes
with
the
federated
virtual
service.
D
Right
and
I'm
creating
these
federated
rules
and
federated
sto
custom
types,
the
same
way
that
I,
would
you
know,
create
them
if
they
weren't
federated
using,
could
cuddle
create
again
that
kind
of
going
back
to
that
user,
workflow
and
user
experience.
This
is
all
very
familiar
to
me.
I'm
not
having
to
you
know,
have
my
mind,
explode,
trying
to
figure
out
new
ways
of
doing
things
and
new
types
that
I
have
to
deal
with,
just
to
be
able
to
federate
this
deal
and
work
with
any
of
the
federated
functionality
that
this
deal
provides.
D
D
D
There
was
one
more
thing
that
I
wanted
to
demonstrate
that
I
had
working,
but
recently
the
multi
cluster,
DNS,
API
change
and
so
forth,
and,
and
so
one
of
the
things
I
want
to
do
next-
that
actually
had
working
up
until
the
recent
changes
was
that
okay,
this
is
awesome.
Let's
say:
I
have
three
or
four
or
five
or
more
instances
of
this
book
info
application
that
I'm
using
it
to
simulate
a
real
application,
but
I
don't
want
to
expose
write.
Five
of
these,
you
know
use
being
able
to
use
the
multi
clustered
DNS
capabilities.
D
D
Just
sayin
see
all
my
users
see
a
single
front
end
and
and
what
I
was
doing
to
test
was
okay.
Let
me
take
one
of
them
down.
Let
me
try
upgrading
one
of
the
applicants,
all
that
stuff
was
working
and
it
was
basically
hitless
and
so
that's
kind
of
the
one
piece
that
I
want
to
get
working
again
to
just
kind
of
finalize
it.
The
demonstration,
then
again,
as
I
talked
about
in
the
presentation
is,
is
I.
Think
the
next
big
kind
of
sub
feature
under
federated
sto
is
is
a
federated
sto
live
upgrades.
D
If
we
can
show
okay,
not
only
can
you
do
a
live
upgrade
of
your
application
like
book
info?
Okay,
you
know
if
I'm
a
user.
Okay,
that's
a
very
interesting,
but
if
I
could
go
ahead
and
say
we
can
basically
shift
you
know
all
your
traffic,
all
your
users
to
you
know
one
data
center,
one,
that's
running
history,
oh
and
your
book
info
app
and
is
Tio's
running
upgrade
cluster.
D
You
know
this
teo
control
planning
cluster.
You
know
test.
It
really
quickly
then
shift
that
traffic
back
and
have
everything
work
and
then
shift
all
the
traffic
to
the
new
version
of
this
do
and
the
new
version
of
the
application
upgrade
cluster
one
and
then
get
it
back
to
normal,
where
it's
shared
between
both
of
those
I
think
is,
is
is
really
powerful,
but
I
will
I'll
end
it
there
with
asking.
If
there's
any
questions.
D
You
know
one
last
thing:
I
did
want
to
mention
on
a
personal
note.
It
is
so
I'm
part
of
the
cloud
CT
organization
within
Cisco
and
base.
Our
whole
organization
is
being
eliminated,
so
so
I'm
in
the
process
of
trying
to
find
something
else
within
Cisco
and
outside
of
Cisco
and
I'm,
hoping
that
I
could
find
something
that
still
allows
me
to
work
on
Federation,
v2
and
or
at
least
cloud
native.
So
do
me
a
favor,
keep
me
in
mind.
If,
if
you
do
see
any
opportunities
or
get
always
direct
message,
me
I'd
appreciate
it.
F
B
B
D
D
Do
a
quick
search,
see
if
there's
something
out
there
I'm
like
oh
well,
there
is,
and
so
there's
an
issue
out
there
for
helm
to
support
Federation,
but
it
was
an
issue
that
was
open
probably
about
a
year
ago
and
as
I
read
through
it,
it
looked
like
it
was
really
geared
towards
that
v1
and
and
so
I
just
kind
of
added
to
the
issue
to
say:
hey,
you
know,
Federation
v2
is
really
you
know
starting
to
gain
traction,
and
you
know.
Would
you
consider
that
v2
never
heard
anything?
D
And
it
looks
like
the
issue
is
just
kind
of
gone
stale
anyways,
so
I
would
I
would
really
like
to
see
the
capability
within
helm.
Where
you
go,
and
you
say
how
I'm
template
create
and
you
know,
and
it
just
creates
a
federated-
have
a
federated
equivalent
of
a
standard
manifest
at
home
that
generate
yeah.
F
Definitely
that
would
definitely
be
doable.
I
mean
before
now.
We
haven't
really
been
looking
at
generating
stuff
dynamically,
but
as
soon
as
we
get
into
being
able
to
convert
an
existing
resource,
then
any
resource
at
helm
is
going
to
be
able
to
apply.
We
can
just
convert
it
before
application
to
the
Federation.
One
yeah
I
think
it's
doable
and.
D
D
Manually
is
painful
time,
consuming
tedious
work
and
really
air
prone
I
mean
I.
I
probably
would
have
saved
myself
hours
and
hours
just
from
the
air
prone
standpoint,
let
alone
having
to
manually,
convert
the
stuff
over
and
it'll
help
us
with
the
the
whole
lifecycle
right.
I
mean
people
after
a
period
of
time
and
work
that
they
don't
want
to
do
like
having
to
do
this.
Tedious
work
of
converting
over
these
manifests
its
ends
up
sitting
in
the
back
burner.
D
People
don't
want
to
do
it
and
so
having
that
tool,
it's
gonna
make
the
you
know
the
ongoing
management
of
being
able
to
support
the
next
version
of
this
teo
right.
This
I
know,
for
me
personally,
is
like
okay.
The
next
version
it
is
CEO
comes
out.
If
I
it's
some
kind
of
tool
that
I
could
just
you
know,
simply
convert
over
that
whole
list.
I
mean
take
a
look
at
the
manifest
and
you'll
see
really
quickly
how
long
it
will
manually
take
to
do
that.
C
This
is
John
here,
I
totally
agree
with
Dan
on
this.
The
recently
started
testing
Federation
in
our
bad
metal
cloud,
and
it
was
you
know
it
sometimes
feels
like
it
would
be
nice
to
have
that
even
to
a
vice
versa.
For
example,
a
customer
does
not
want
Federation
in
the
what
to
go
back
to
like
using
their
world
conflicts
and
if
we
can
reverse
it
or
from
a
federation
back
to
an
isolated,
namespace
or
YC,
I
would
somehow
be
able
to
cut
off
the
link
from
Federation,
taking
away.
C
And
the
radical
namespace
was
one
thing
to
be
wondering:
if
that's
something
you
can
work
on,
but
I
totally
hear
having
such
a
tool
to
actually
at
least
convert
the
standard,
configs
and
yam
aspects
to
a
federated
one.
Is
it's
kind
of
going
to
be
much
helpful
for
the
customer
at
least
because
then
you
don't
have
need
and
expertise,
and
you
know
like
real
human
labor
in
making
that
conversion
for
each
one
of
them.
C
D
And
to
me
that
would
be
priority
number
one
for
like
the
next
step
of
development,
because
you
think
about
it
is
is
what
I
did
is
I
federated
the
sto
installation
manifest
which
you
look
at
that
and
your
mind
wants
to
explode
and,
and
that's
just
in
the
sto
installation,
manifest
that's
generated
from
the
helm.
Template
generator
we're
getting
what
the
exact
home
command
is.
But
if
you
look
in
this,
your
release
and
I'm
happy
to
kind
of
CD
into
the
directory
and
show
you
all.
D
This
stuff
is
there's
a
few
different
demo
manifests
or
TLS
no
tlf,
and
then
there's
just
tons
of
directories
of
different
examples.
Where
I
gave
the
example
of
just
doing
the
virtual
gateway
service
route,
rule
federating
that
but
there's
a
ton
of
different
examples
and
samples
and
sample
applications
like
I
mean
if
we
can
have
this
tool,
it
wouldn't
be
all
that
difficult
to
go
ahead
and
say
all
right.
D
C
It
is
kind
of
the
documentation
doesn't
mention
that
use
case,
but
it
would
be
nice
because
then
you
know
that
way.
The
Federation
control
plane
sits
at
one
cluster
and
it's
kind
of
just
a
feedback
right
now.
All
the
examples
are
same
cluster
two
and
cluster
one,
and
we
were
trying
to
say:
hey.
Can
we
separate
out
one
cluster
to
just
two
Federation
work
and
keep
the
rest
of
the
cluster
is
like
any
other
cluster
I
mean.
F
D
D
D
A
F
To
do
it
too
I
mean
I
was
kind
of
holding
off,
because
you
said
every
command
is
is
kind
of
half-baked
at
present
yeah
thanks,
but
it
doesn't
actually
generate
validation.
It's
kind
of
not
but
I
mean
really.
We
can
just
release.
You
know
cavity
right,
it's
not
necessarily
gonna
be
fully
functional
until
we
decide
to
get
to
a
beta
or
something
so
there
if
everyone's
already
taking
responsibility,
I'm
happy
to
have
him
do
that
yeah.
A
A
F
The
next
step
will
be
taking
a
resource
or
even
a
namespace
and
say
I
want
the
Federated
equivalent,
either
the
amel
or
actually
converted
in
the
API
to
me
that
I'd
like
to
get
to
that
point
before
we
get
to
know
one
just
because
a
we've
kind
of
proved
at
the
API,
and
we
have
all
the
pieces
in
place,
and
we
have
enough
ease-of-use
that
you
know
I,
don't
really
feel
bad
giving
it
to.
Somebody
can
use
its
current
one.
It's
really
for
advanced
users.
Only
ok,.
A
F
I
have
a
little
bit
of
a
mixed
feeling
about,
because
you
don't
actually
have
you
know,
people
who
are
committed
to
using
it,
for,
like
I
mean
we
have
more
people
coming
on
board
now,
but
at
least
on
the
Red
Hat
side,
we've
really
been
focused
on
getting
enough.
Both
information
like
educating
users
and
getting
something
we
can
deliver
into
customers
hands,
because
what
really
we
really
want
is
feedback.
Any
absence
of
feedback
getting
a
road
map
together
is
like
just
you
know,
crystal
ball.