►
From YouTube: 07.01.2020 - Service Mesh Hub Community Meeting
Description
Meeting Info
https://www.solo.io/blog/service-mesh-hub-community-meetings/
C
B
D
B
Since
we
have
a
good
chunk
of
questions
here
might
be
good
to
go
over
those
first
okay.
Well,
we
can
go
ahead
and
get
started
cool.
So
first
things.
Actually
one
topic
from
last
time
was
and
I
think
John
I
think
you
may
have
brought
this
up
on
like
how
how
are
proposals
handled
or
you
know
if
you
have
an
idea
or
suggestions,
so
you
were
gonna,
take
that
and
I
do
and
I
believe
you
put
some
stuff
together.
D
Sure
so
we've
put
up
some
issue
templates
and
there
is
one
for
feature:
extensions
where
you
can
give
a
you
can
provide
a
motivation
for
the
problem
and
you
can
provide
a
proposed
solution.
I
think
that's
optional.
You
might
just
present
a
problem
and
try
to
solicit
some
solutions
from
the
community,
but
I
think
for
now.
That's
a
good
starting
point
and
if
we
need
additional
like
real-time
communication,
the
service
mesh
hub
Channel
in
our
public
slack
is
a
good
place
to
do
that.
E
B
E
E
B
E
I
mean
the
only
I
think
the
only
thing
that
came
up
last
week,
which
I
guess
will
do,
is
probably
not
something
we
want
to
are
able
to
write
down.
But
why
do
you
want
to
design
doc?
When
do
you
don't
when,
when
when
don't
you
need
one,
you
know
those
kind
of
things.
You
know
how
big
you
need.
How
big
is
the
feature,
so
I
guess
that's
more
will
be
handled
more
ad
hoc
based
on.
If
it
looks
big,
maybe
a
doc
is
needed,
if
not
maybe
not.
F
You
can
I
think
right
now,
it's
a
bit
it's
a
bit
informal
and
we
can.
We
can
take
it
up
where
you
said
that
hot
there
might
be
opportunities
for
us
to
schedule
meeting
also
and
just
and
just
do
it
in
real
time
and
then
just
afterwards.
So
right
now,
let's,
let's
figure
out
what
works
best.
I
mean.
If,
if
you
have
an
area
that
you
want
to
contribute
to
and
it's
a
good
idea,
then
I
mean
let's
I
don't
want
to.
We
don't
want
to
put
too
many
hurdles
in
the
way.
Okay.
B
E
Yeah
I
so
I
think
a
little
bit.
We
kind
of
talked
a
little
bit
about
the
first
one.
Just
now
was,
and
last
week
we
we
talked
about
a
road
map
and
stuff
like
that,
so
I
was
trying
to
dig
and
understand
and
get
a
whether
there's
any
sort
of
formality
or
like
a
designated
sort
of
list
of
target
areas
or
a
mapping
of
things
to
releases
or
anything
like
that
and
I
wasn't
expecting.
There
was
but
I
was
wanted
to
ask
if
I
was
missing,
something
and
I
think
from
the
discussion.
E
We
just
had
we're
mostly
tracking
things
via
that
issues
list
via
the
feature
enhancements
and
the
that's
the
amount
of
formality
that
we
want
or
need
right
now
is
that
is
that
really
the
correct
understanding
or
if
there's
more
there's
stuff,
I'm
missing?
That's
the
key
I
wanted
to
understand.
If
there's
more
information
available,
I
just
missing
it,
then
then
please
point
me
to
it.
C
G
G
Do
two
different
extents
to,
and
you
know
the
more
information,
because
I
feel
like
Steele
has
so
many
different
ways
you
can
use
it
and
part
of
the
trade-off
that
service
mesh
hub
makes
is
about
nailing
down
conventions
and
like
where
are
areas
where
we
can
simplify,
where
we
don't
necessarily
need
the
complexity,
and
you
know
getting
that
feedback
so
understanding.
What
are
you
know
the
priorities?
G
Really
everybody
here,
you
know
and
and
and
see
if
we
can
get
align
them
and
or
just
even
discussing
so
it's
just
knowing
that
stuff
is
super
helpful
to
us.
Even
if
you
guys,
you
know,
don't
necessarily
want
to
do
all
the
work
it
takes
to
open
and
curate
an
issue
come
talk
to
us
on
the
slack.
That's
really
the
best
way
and
we'll
make
sure
that
those
issues
get.
E
Right
yeah,
it
makes
sense,
I
mean
it's.
Do,
has
a
lot
of
knobs
and
buttons
I.
Think
from
our
perspective,
there's
others
from
Cisco
on
the
call
that
they
can
speak
up,
but
I.
Think
from
my
perspective
and
in
Cisco's
perspective,
the
biggest
interest
isn't
necessarily
connecting
is
tienes.
Do
this?
Do
this?
Do
is
a
well-established
Dart.
E
Bart
might
not
be
the
right
word.
It's
can
be
completely
complicated,
so
our
interest
is
more
when
you
expand
beyond
is
do
you
have
sto
with
other
environments
and
other
meshes,
so
our
biggest
interest
is
trying
to
make
sure
there's
kind
of
flexibility
there
with
respect
to
service
mash
hub
being
able
to
embrace
those
other
environments
and
I
know
you
spend
a
lot
of
time
with
the
app
mission
over
the
last
few
weeks
trying
to
get
that
in
so
that's
an
example.
G
Let
me
ask
you:
are
we
and
we're
talking
about
managing
multiple
when
you
say
multiple
environments,
you
really
mean
like
different,
like
a
hybrid
set
of
meshes,
so
I
have
different
meshes
and
I.
Have
different
control
like
heterogeneous
control
points.
Is
that
yeah
you
weren't?
Okay,
yes
yeah!
So
how
will
service
my
sharpey's
approach,
the
problem
of
heterogeneous
control,
plane,
yeah.
E
Absolutely,
and
as
I
mentioned
last
week,
it's
not
I,
wouldn't
it's
less
about
the
control
point
itself
and
it's
more
about
the
fact
that
those
environments
have
different
potential.
You
surely
have
different
administrative,
you
know
boundaries
and
possibly
have
different
security
and
networking
boundaries
too.
So
how
do
you?
How
do
you
kind
of
bridge
across
those
boundaries?
Well,
while
combining
some
of
the
the
great
functionality
service
meshes
in
general,
provide
right.
F
E
G
E
I
mean
you
know
from
the
perspective
of
us
trying
to
understand
if
the
rest
of
the
community
has
alignment
with
our
interest
having
a
clear
and
concise
roadmap
helps
with
that,
but
I
also
understand.
You
know
we're
just
starting
with
this
as
a
community,
so
you
know
it's
a
little
ad
hoc
and,
and
that
makes
it
allows
it
to
be
more
flexible,
which
is
fine,
yeah.
F
E
Well,
I'm
more
on
the
front,
end
exploratory
side
of
engineering,
so
I'm
not
able
to
give
you
actually
production
environments.
Other
people
are
dealing
with
those
kind
of
interfaces,
but
from
the
perspective
of
what
I'm
interested
in
yes,
I'm
interested
in
I've
met
with
this.
Do
I'm
interested
with
this
do
with
Winker
D
I'm
sort
of
interested
in
all
those
and
I.
Don't
necessarily
have
a
priority
right
now,
because
I'm
trying
to
look
at
it
more
holistically,
but
there's
probably
people
on
my
you
know:
marketing
and
product
teams.
F
That
make
sense
yeah
and
we
can
go
into
more
detail.
I
think
that
generally
the
abstractions
that
we're
setting
in
place
in
in
the
architecture
right
now,
our
intent
is
to
have
those
abstractions
covered.
Those
those
these
cases,
both
from
generally
but
Sir,
how
the
surface
mesh
operates
in
terms
of
communicating
order,
different
networks
going
through
different
gateways,
doing
at
times
transformations
and
and
then,
of
course,
like
the
way
that
serves
much
helps
these
these
types
of
things.
So
we
have
the
mesh
service
abstraction.
F
We
have
the
virtual
mesh,
abstraction
and
mesh
workload,
abstraction
and
those
fit.
You
know
hard
before
you
have
but
they're
a
lot
of
work
on
getting
getting
those
concepts
that
we
have
in
service
obstructions
that
were
using
in
service
my
job
to
map
up
with
what,
for
example,
AWS
that
much
uses
so
there's.
Definitely
the
foundational
piece
is
in
there
in
the
architecture.
G
If
I
can
just
add
to
that,
so
what
Chris
is
talking
about
is
we
have
an
internal
abstraction
I,
don't
know
how
familiar
everybody
is
with
the
like
internal
design
of
service
mashup.
But
basically
the
idea
is
to
have
an
API
that
is
portable
across,
although
you
know
different
meshes,
but
that
can
be
difficult
like
I
think
we
kind
of
saw
from
SMI
that
if
you
go
over
the
lowest
common
denominator
approach,
things
get
tricky.
G
So
I
think
that
we're
we're
still
working
with
the
idea
that
your
API
will
know
about
your
environment.
I
mean
I,
I,
think
that
makes
sense
to
us
because
the
people
who
operate
the
environment,
like
those
are
the
concepts
they
know.
You
know
if
they
write
a
Cooper
nettie
service,
that's
kind
of
what
they
want
to
put
reference
to
in
their
llamo.
G
You
know
this
is
this:
is
kind
of
the
the
guidance
for
the
thinking
that
we're
at
right
now,
just
in
this
example
and
if
they're
running
on
App
mesh
they'll
they'll
want
to
put
in
you
know
their
AWS,
Arne's
or
whatever
resource
selection
can
be,
you
know
whatever
they
already
have
in
another
llamó
file.
That
makes
sense
to
bring
it
in
and
not
necessarily
have
to
map
that
for
us,
and
then
we
have
this
internal
abstraction
that
you
know
kind
of
aggregates
everything
together
in
the
system.
G
Under
these
you
know
mesh
service,
most
workload,
virtual
mesh
and
you
know-
does
does
essentially
a
computation
there's
like
a
big
translator,
piece
inside
that
you
know,
translates
from
input,
resources
and
environmental
data,
that's
collected
through
discovery
and
then
outputs
the
resources
for
the
corresponding
mesh
type.
So
we
can
support
simultaneously.
You
know
SEO
and
APIs
running
together.
That's
like
the
overall
model
and
I
think
what
we're
finding
now
is
actually
a
huge
part
of
the
value
of
service.
G
Mashhad
is
actually
that
it's
it's
it's
putting
something
on
top
of
those
service
meshes
so
right
now,
Harvey
is
working
on
getting
in
our
support
for
failover,
and
this
is
actually
going
to
introduce
a
failover
CRD,
that's
kind
of
like
a
kubernetes
service
and
your
services
can
talk
to
that
and
their
traffic
will
automatically
failover
and
we're
able
to
do
that
because
we
own
the
underlying
sto
destination
rules.
Virtual
services
envoy
filters
all
that
stuff.
G
So
the
idea,
then,
is
like
the
what's
the
portability
of
that
across
different
meshes,
because
I
think
that's
the
real,
like
that's
the
API,
that
the
user
is
going
to
want
to
wrap
their
hands
around
and
it's
it's
that's
really
constrained
only
by
the
feature
set
that
they
implement
today.
So
sto
is
just
kind
of
by
far
the
most
ready,
but
really
I.
Think
that
we're
not
you
know
that
it's
got
the
the
largest
number
of
features
that
allow
us
to
do
this.
G
F
G
G
E
F
It
plays
out,
but
there's
there's
definitely
a
complimentary
fit
there
all
right
if
something's
about
sto
exposes
its
API,
which
we
primarily
use,
but
it
also
exposes
a
break
glass.
Go
around
these
to
control.
That
kind
of
console
Kinect
does
something
similar
at
mesh.
Doesn't
do
that
right
now,
Akuma
I'm,
not
actually
sure,
but
so
the
surface
mesh
is
when
they
become
more
mature.
G
I
also
wish
you've
always
here,
because
I'm,
maybe
a
Tom,
can
comment
on
this,
but
I
believe
that
envoy
are
actually
working
on
an
extension
that
allows
you
to
plug
in
multiple
control
planes,
and
this
is
kind
of
the
the
next
step
for
awesome,
so
that
you
can.
The
problem
with
my
awesome
today
is
that
it
requires
you
to
go
through
this
model
at
the
control
plane.
That
envoy
can
really
only
have
one
control
plane
and
so
for
service.
G
Mashhad,
let's
say
to
configure
watson
filters
we
need
to
go
through,
is
do
to
do
it,
but
I
believe
they're
currently
working
on,
I'm
not
sure
the
name
of
the
feature
but
they're
working
on
a
way
to
make
envoy
open
to
multiple
control
points-
and
you
know,
is
steel-
will
probably
be
the
first
ones
to
support
it.
Just
like
that.
G
H
G
I
E
So
I
can't
speak
for
all
Cisco,
but
we
do.
We
have
projects
in
Cisco
that
use
this
deal.
We,
my
group,
is
more
about
designing
solutions,
including
this
do
and
I
don't
so
we
have.
We
have
both
users
of
this.
Do
we
have
products
that
sort
of
integrate
with
this
do
and
as
I
mentioned
before,
our
interest
is
more.
This
sort
of
intermesh,
multi,
environment
kind
of
scenario,
but
other
people
from
Cisco
can
comment
if
they
have
more
specific
details
that
went
out.
G
Yeah
I
asked
because
it
I
just
think
it's
like
I,
said
before
there
are
opinionated
decisions,
we're
actually
working
through
a
bit
of
a
refactoring
of
the
code
right
now
inside
of
service
Misha,
and
it's
it's
giving
us
an
opportunity
to
vet
a
lot
of
the
assumptions
that
we
made,
and
this
was
when
we
originally
wrote
it.
It
was.
It
was
actually
a
bit
earlier,
I
mean
really
when
the
work
started
on
this
it
was
it
was
more
than
a
year
ago
and
since
then,
a
lot
of
the
like,
there's
just
a
lot
more
users.
G
There's
a
lot
of
uses
built
up
during
that
time
and
so
I
think
it
would
be
helpful
to
hear
some
feedback
about
like
what
are.
What
are
what
I?
What
I
really
want
to
know
is
what
are
pieces
of
this?
Do
that
you
find
you
don't
need
to
configure,
but
you
you
feel
like
you
do,
or
you
know
things
that
you
wish
were
automated
from.
You
wish
things
that
you
don't
want
to
control.
If
that
makes
sense,.
H
Sorry
not
two
seconds
I
just
want
to
say:
Johnny
I
was
incorrect
and
I
just
found
this.
This
envoy
github
issue
I
sent
it
in
chat
with
the
accompanying
design
doc
about
proving
me
wrong
about
how
the
v3
transport
is
supposed
to
accommodate
it's
supposed
to
help
to
accommodate
that
exact
situation.
This.
F
E
C
C
C
C
B
F
C
Through
the
GUI,
so
it's
it's
for
the
customer
to
configure
you
don't
have
to
use
it.
So
customers
have
their
some
customers,
have
their
own
ingress
gateways
and
don't
want
its
do
or
don't
want
any
kind
of
service
mesh,
but
it's,
but
they
see
what
they're
doing
it's
at
least
through
a
GUI
level.
Gosh
I.
G
Up
until
now,
service
Mushaf
has
pretty
much
been
focused
more
on
the
east/west
use
case.
You
know,
we've
we've
discussed
how
we'll
address
ingress
and
it's
definitely
on
a
road
map,
but
I
just
feel
because
you
know
yeah
well.
I
I
wish
I'd
eat
was
here
because
she
could
talk
more
about
like
the
overall.
You
know
how
those
decisions
were
made,
but
yeah
I
I
think
that
we're
focusing
on
the
mesh
use
case
because
ingress
is
a
bit
of
a
solve.
You
know
it's
a
more
tried-and-true
thing.
G
There
are
a
lot
of
solutions
in
the
space
where
mesh
like
we
looked
at
the
AP.
Is
that
our
current
out
there
for
mesh
and
we
thought
that
none
of
them
really
fit?
You
know
we
looked
at
the
lack
of
interoperability
and
we
saw
a
problem
there.
So
you
know
that's.
My
guess
is
that
why
those
were
prioritized.
G
G
E
We've
tried
it
more
from
you
know
the
demo
kind
of
scripts
and
you
know
getting
started
stuff.
We
haven't
dug
in
much
beyond
that.
We're
starting
to
you,
know
we're
starting
to
trying
to
dig
in
a
little
bit
more
do
some
things
that
may
not
be
directly
described
in
your
documentation
but
again
I'm,
not
I'm,
not
I,
never
expect
to
be
a
user
community
directly
with
this,
so
might
be
others
that
you're
really
asking
right.
A
I've
been
using
go
service.
My
job
I
mean
I
work
in
the
same
team
as
John
on
this
project,
so
I
found
find
it
to
be
really.
You
know
easy
to
install
configure
and
do
various
traffic
prompting
and
things
like
that.
One
question
which
I
had
was:
do
you
plan
to
support
any
centralized
blogging,
telemetry
connection,
a
collection
most
metrics,
and
things
like
that?
Is
that
something
in
which
is
it
in
your
roadmap?
Absolutely.
G
I
believe
next
quarter,
we're
going
to
be
focusing
on
and
like,
and
this
is
would
be
something
I
think
to
help
get
feedback
for,
but
basically
a
feature
set
around
observability
and
just
like
you
have
a
centralized
control
plane
for
controlling
your
mesh.
We
also
want
a
centralized
control
plan
for
observing
the
mess,
so
that's
definitely
yeah.
If.
A
A
Correctly
talk,
you
know,
I
know
that
a
lot
of
the
you
know,
traffic
in
which
I'm
doing
is
going
in
specifically
to
just
one,
is
to
your
cluster
out
of
looking
at.
You
know,
comedians
doing
some
logging
and
things
like
that
on
that
not
concentrating
on
the
other
clusters.
If
I
fly
a
lot
of
the
then
basically
collect
everything
which
goes
to
the
different
clusters:
Aspen,
not
just
the
management
roster.
B
G
B
E
But
Betty
one
we
would
kind
of
got
a
little
off
track
from
the
question,
so
I
think
one
of
my
my
second
question
was
really
about
service.
An
endpoint
discovery
and
I
noticed
I
do
see
in
the
enhancements
some
references
to
improvements
or
changes
or
additions.
You
want
to
do
there
and
I
was
trying
to
get
a
sense
of
where
you're
at
with
that,
because
that's
also
an
area
of
interest
for
us.
We
have
some
thoughts
that
might
be
useful.
E
It
may
want
to
propose
them,
but
I
want
to
understand
what
the
current
state
of
things
are.
So
is
it
all
captured
in
those
issues,
because
a
lot
of
the
issues
are
fairly
like
there's
one
that
say:
hey
we're
going
to
do
a
restrictive
Federation,
but
no
there's,
no
clear
understanding
of
what
that
means
or
is
and
how
it
directly
relates
to
service
discovery.
Yes,.
B
D
E
I
mean
so
yeah,
you
have
lots
of
different
places.
You
may
want
to
discover
service
and
end
points,
so
the
VM
case
is
an
example
right.
You
know,
you
know
you
have
a
VM,
you
want
to
discover
services
from
the
VM,
it's
not
necessarily
tightly
tied
to
a
cluster,
and
it
might
only
be
tied
to
a
match
by
the
fact
that
you
have
an
envoy
in
the
VM
in
some
way.
So
you
have
to
do
something
there.
E
Okay,
app
mesh
has
a
different
view
of
how
services
get
discovered
and
a
tight
they'd
like
to
tie
things
to
cloud
map.
So
that's
a
different
different
way
to
discover
we're
toying
with
some
other
stuff
that
it's
an
open
source
that
has
some
networks
and
services
and
endpoints,
so
we're
kind
of
figuring
out
how
that
might
link
in
here.
So
I
guess
it's
really
just
trying
to
understand.
You
know
where
you
wrap,
where
you,
where
you
want
to
go.
I.
E
Think
Dominic
brought
this
up
last
week
about
the
fact
that
currently,
it's
very
tightly
tied
to
you
know
kubernetes
service
and
discovery
of
a
kubernetes
service,
but
it
doesn't
need
to
be
right.
It
could
be,
you
know,
tied
to
anything
right
that
provides
I
saw
one
of
the
issues
I
brought
up
was
console,
so
I
assume
it's
not
DK
on
that
issue,
but
I
assume
when
you
say
you
want
to
link
to
console
that
you
want
to
specifically
linked
to
the
ability
for
console
to
represent
services,
and
maybe
some
endpoint
mappings
behind
those
services.
E
So
it's
really
there's.
There's
need
for
this
in
numerous
different
environments
that
mesh
console
some
proprietary
work,
all
those
kind
of
things
so
I
just
trying
to
understand
what
you
had
before
we
launched
into
trying
to
suggest
hey
what
about
this
environment?
Let's
go
figure
out
how
we
do
this
specifically
with
that
yeah
sure,
let's
go
figure
out,
maybe
develop
a
very
flexible
protocol.
Perhaps
you
know
everything
can
be
pushed
and
I
don't
have
any
specific
ideas.
E
G
Actually,
in
Glu
have
already
implemented
discovery
for
console
ec2.
A
variety
of
different
backends
and
Lewis
has
informed,
to
a
large
extent,
the
model
that
we
have
in
service
Missha
or
insurv,
especially
we
import
definitions
and
a
variety
of
backends
into
this
mess
service.
Crd
that
we
have.
So
if
you
look
at
your
mess
services,
you'll
be
able
to
see
what
you
will
see
like.
All
we
have
to
do
is
basically
implement
the
interface
for
the
corresponding
back-end,
but
the
the
architecture
the
system
is
already
and
the
API
are
already
accounting
for
this.
Okay.
G
Although
the
discovery
right
now
is
only
plugged
into
kubernetes
yeah,
we
will
be
adding
in
more
for
like
like
cloud
map
and
console.
That's
exactly
where
we're
gonna
bring
the
domain,
and
probably
you
know
a
little
bit
cleaned
off
for
the
newer
API
is
that
you
know
lose.
Implementation
is
a
little
bit
older
and
you
know
it's
it's
more
for
an
ingress
use
case
and
it's
built
for
glue.
G
You
know
the
blue
control
plane
so
we'll
bring
it
in
for
a
service
mashup,
but
yeah
I
think
you
can
definitely
look
at
glue
to
see
how
glue
is
doing
it.
Look
at
the
glue
upstream
and
there's
documentation
for
all
of
those
what's
usually
required
is
that
the
user
has
to
provide
a
secret
that
gives
us
a
credential
that
we
can
use
to
access.
You
know
any
kind
of
bad
weather,
it's
console,
it
could
be
the
AWS
API,
it
could
be
I,
don't
know.
G
You
know
a
zookeeper
instance
where,
however,
people
are
defining
their
service
registry.
The
the
nice
thing
about
kubernetes
is
by
running
on
kubernetes.
We
can
just
use
our
service
account
to
access
that
data,
but
for
an
external
service,
but
once
the
credentials
provided
service,
my
shop
is
going
to
treat
all
that
stuff
like
it
doesn't
know
or
care
where
it's
running
on
the
backend.
E
F
Did
some
work
around
building
the
abstraction
for
not
everything's
a
cluster
right
and
being
able
to
discover
things
running
in
a
pitch
which
doesn't
mean
necessarily
kubernetes?
Some
of
that
will
be
some
of
that.
Those
foundations
are
already
the
assumptions
that
there
will
be
other
sources
of
record
for
what
it,
what
is
in
a
service
mesh
those
started
to
lay
the
foundation
for
them.
Okay,.
E
B
You
guys
want
to
get
to.
We've
got
three
other
questions
here:
Tim
and
Dominic
and
John,
or
not
John,
dang
or
not
on
this
call,
but
we
could
we'd
at
least
discuss
them.
So
there's
a
little
more
content
context
and
then
take
them.
Take
them
up
next
meeting
to
if
they,
if
they
have
follow-on
questions,
so
Tim's
got
one
on
multi
cluster
management
as
practice
for
integrating
with
coop
config
in
multiple
cloud
types
seems
to
be
something
surface
mesh
hub
hasn't
tried
to
solve.
Is
that
the
case?
And
is
there
any
plans
or
interest
there?
B
F
G
E
How
I
can
get
information
from
it
and
discover
things
from
it?
So
I
think
that's
the
sort
of
macro
question
now,
specifically
he's
probably
also
thinking
a
little
bit
about
some
challenges
that
I
think
even
Pavin
hit
this
week.
We're
trying
to
get
service
mesh
hub
to
play
nice
with
an
sto
that's
installed
on
AWS
has
some
challenges
because
of
the
way
I
am
works
and
the
fact
that
you,
you
need
a
coop
config,
but
you
can't
just
generate
the
cuca
fig
that
works
easily.
E
So
I
think
again
trying
to
speak
to
Tim,
but
I
think
there
were
sort
of
you
know
two
macro
questions.
One
I
mean
two
two
questions
at
very
different
ends
of
the
spectrum.
I
want
to
sort
of
just
you
know:
here's
some
words
from
you
about
your
thoughts
of
a
cluster
registry.
How
you
know
how
you,
how
you
see
it?
What's
your
view
of
it
and
what,
where
you
think
you
might
want
to
keep
service
mesh
hub
or
move
service
mashup
to
so
that's
sort
of
the
high
level
thing.
E
D
Provide
some
context
on
this,
so
for
the
immediate
question
of
how
do
you
register
an
e
KS
cluster
as
long
as
so
you
can
do
it
manually
with
the
mesh
CTL
cluster
register
command
as
long
as
the
user
running,
that
command
has
is
using
a
queue
config
with
the
cluster
admin
privileges
that
should
work.
It
should
just
work
as
in
the
current
state
of
service.
Mesh
of
the
alternative
way
is
to
register
your
clusters
automatically
in
this
sort
of
discovery
like
fashion,
so
you
can
provide
service
mesh
of
your
AWS
credentials.
D
There
is
a
setting
CRD
where
you
can
configure
service
mesh
up
to
automatically
discover
eks
clusters.
There's
certain
parameters
like
you
can
provide
a
region,
you
can
provide
tags
and
it
will
just
go
and
figure
out
any
eks
clusters
that
exists
in
those
regions
with
those
tags
and
it
will
automatically
register
those
with
service
mode,
so
I
think
with
with
cloud
providers
are.
D
This
is
going
to
like
your
macro
question,
I
think
for
cloud
providers
if
they
usually
provide
some
sort
of
entry
point
to
list
out
all
of
the
kubernetes
clusters
or
any
for
any
other
compute
platform.
You
might
be
operating
and
service.
My
job
can
hook
into
that
api,
given
the
credentials
that
the
user
provides
us
and
we
can
go
and
do
that.
Cluster
registration
or
a
VM
registration
automatically
for
the
user
and
we'll
expose
some
sort
of
configuration.
So
the
user
can
tell
us
which
of
their
entities.
D
E
G
G
G
From
from
the
service
account
and
it
imports
it
back
into
the
original
cluster,
so
I
think
what
the
question
is
about
is
when
you're
actually
bootstrapping,
you
have
to
use
a
local
coop
config,
because
you
know,
and
and
it
becomes
then
this
question
of
ok,
let's
save
my
standard
setup
if
I
have
a
10
cluster
set
up,
this
is
just
what
I'm
reading
into
it
could
be
all
face.
But
if
I
have
a
10
cluster
setup-
and
you
know
now-
you're
telling
me
that
I
have
to
run
ten
individual
registration
commands,
you
know
well
like.
G
What's
what
are
the
conventions
around
that?
How
do
we
plant
the
support
from
the
user
experience
side?
Because
the
the
answer
is
that
on
the
back
end,
we
do
have
an
implementation
on
how
to
address
this
and
I.
Think
it's
it's
on
our
you
know
for
the
user
facing
side,
how
does
a
user?
You
know
without
a
tremendous
amount
of
pain.
You
know
maybe
there's
a
point
at
which
we
actually
define
a
llamo
file.
That
has
a
list
of
your
clusters
and
group
configs,
and
we
can
just
process
that
you
know
just.
E
G
G
B
F
When
we
were
talking
about
it
and
Misty
has
a
way
of
running
the
envelope
proxy
in
a
VM.
That
I
believe
is
connected
over
the
same
network
to
the
control
plane,
and
then
it
does.
Some
automation.
I
mean
you're
supposed
to
do
by
hand.
Actually
this
your
Docs,
they
can
do
this
by
hand,
is
to
generate
thinner
the
the
correct
certificates
and
so
forth.
So
this
is
probably
something
that
we
can
automate.
I
would
say,
which
is.
F
This
might
be
a
great
segue
to
like
what
are
the
things
that
we're
working
on
right
now
and
what
are
the
next
upcoming
things
from
more
of
a
technical
standpoint,
maybe
Harvey
so
we're
working
on
the
failover
fell
over
feature,
which
I
think
is
pretty
close,
are
pretty
close
and
then
there's
some
things
around
fixing
up
the
the
multi
cluster
routing
things
like
there's
a
issue.
That's
been
open
for
a
little
bit
that
I
think
John
Dame,
a
brace
about
doing
riding
with
subsets
subset
based
routing.
F
So
we
need
to
close
that
gap
and
then
I
think
automating.
Some
of
the
DNS
stubbing
and
you
know,
set
up
so
those
there's
a
handful
of
these
little
some
low-hanging
fruit,
things
that
we've
known
about
for
a
bit
that
we
want
to
tackle
pretty
pretty
quickly
here.
But
then
you
know
bm's
be
an
automating.
Some
of
these
sto
edges,
steel
cases
are
always
up
for
always
up
for
discussion.