►
From YouTube: 08.26.2020 SMH Community Call
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
If
you
are
so
inclined,
but
I
thought
it
might
be
nice
instead
of
just
staring
onto
like
little
black
boxes,
blank
boxes
with
names,
okay,
cool
we've
got
a
few
different
things
on
the
agenda
today,
so
I'm
just
gonna
go
through
them,
really
quick
and
then
we'll
have
folks
talk
about
them.
First,
we've
got
the
the
most
recent
service
mesh
hub
release,
so
we
can
kind
of
this.
Some
folks
in
the
soil
team
can
go
over
that
there
is
upcoming
upcoming,
open
service
mesh
support.
A
That's
the
new
service
mesh
that
the
microsoft
open
source
team
announced
and
then
in
flight.
We
have
aws
account
registration
and
mihai.
You
added
a
topic
here
about
the
limited
trust
configuration
so
we'll
go
through
all
of
those
and
if
other
things
come
up
folks,
just
please
add
them
on
there
and
then
we
can
keep
going
down
the
list
so
who
wants
from
the
solo
team?
Who
wants
to
go
over
the
the
release.
B
Sure
I
can
drive
that
and
scott
and
harvey,
and
anybody
else
can
chime
in
with
some
additional
details
to
highlight,
but
yeah.
So
we've
been
talking
about
an
ongoing
refactor
in
service
mesh
hub
for
the
last
few
community
meetings
and
that
landed
at
the
end
of
last
week.
There's
some
breaking
changes
to
take
note
of
some,
like
api
renames
from
mesh
service
to
traffic
target
mesh
workload,
to
workload,
access
control
policy
to
access
policy
just
to
be
a
little
bit
more
concise
about
what
objects
service
measure
is
operating
on.
B
In
addition
to
that,
we
have
added
support
for
istio
1.7.
We
have
added
support
for
multi-cluster,
subset
routing
in
istio
and
just
in
general,
built
a
more
extensible
base
for
adding
features
to
service
mesh
hub
over
time.
C
Yeah,
so
I
can
just
go
over
a
little
bit.
We
went
through
like
a
major
cleanup
of
the
code
inside
of
the
repository,
so
anyone
who's
looked
at
the
code
or
is
interested
in
contributing
should
be
able
to
find
a
much
more
consistently
structured
project,
and
it
should
be.
I
mean
we.
I
would
like
us
to
to
publish
some
development
guides
on
like
different
extension
areas
in
service
mesh
shop.
C
Where
are
the
places
to
do
what,
as
well
as
I
know,
we're
going
to
be
publishing
an
architecture
doc
that
that
goes
over
more
how
the
new
system
is
working
and
I'm
happy
to
answer
any
questions
about
that,
but
yeah
there's,
basically
as
far
as
the
apis
themselves,
they
haven't
changed
too
dramatically,
just
kind
of
cleaning
them
up
for
consistency's
sake,
and
I
think
we
still
might
have
some
api
changes
coming
in
the
next
few
somewhere
along
the
line.
C
I'm
not
sure
if
we
tagged
this
current
release
as
a
pre-release,
but
I
was
hoping
that
you
know
we
could
potentially
reserve
the
right
to
do
a
few
more
breaks
if
necessary.
Although
I
I
don't
think
they'll,
we
will
need
to
break
any
user-facing
apis.
C
We
may
break
some
of
our
internal
apis
like
discovery,
but
I
I
think,
we're
in
a
very
good
place
now
to
start
iterating
and
and
taking
on
some
of
the
more
complex
features.
C
There's
been
some
renames
of
the
apis
right.
Yes,
we
renamed
mesh
service
to
traffic
target
another.
One
of
the
key
points
is
that
the
service
mesh
hub
api-
that's
facing
users,
so
like
traffic
policies,
for
example,
are
no
longer
centered
around
our
discovery.
Objects.
Users
are
not
required
to
know
like
the
name
of
an
obj
of
an
internal
object.
That's
generated
from
service
mesh
up
discovery.
So
if
you
want
to
create
a
traffic
policy
that
applies
to
a
service,
you
will
just
select
it
by
this,
the
the
service
name.
C
That's
one
example
of
the
ways
that
our
apis
have
changed.
They've
they've
really
just
been
been
brought
to
be
simplified
and
a
cleaner
user
experience.
So
users
of
service
mesh
shop
should
only
have
to
deal
with
the
concepts
that
they're
familiar
with.
So
if
you've
installed
a
resource
to
kubernetes,
and
then
you
want
to
reference
it,
you
should
be
able
to
directly
reference
that
from
your
service,
meshup
crd,
without
having
to
know
the
internal
processing
and
discovery
mechanisms
that
service
mishap
uses.
D
C
Basically,
wherever
appropriate,
like,
for
example,
harvey
just
took
care
of
for
traffic
split,
we
want
to
be
able
to
traffic
split,
you
know,
shift
your
traffic
between
different
destinations.
We
you
know
in
that
spec,
there's
a
selector
to
select
what
you're
going
to
shift
two,
and
originally
it
was
just
kubernetes
service.
You
would
specify
the
service
internally.
We
would
map
it
back
to
the
discovered
traffic
target.
Now
we
also
support
a
failover
service,
which
is
another
user
created
object,
so
the
users?
C
Basically,
we
have
a
one
of-
and
you
can
extend
that
one
up
and
in
any
appropriate
place
where
you
know
it
can
either
be
a
coupe
service
or
a
failover
service,
or
something
like
a
service
entry
will
will
provide
extension
points
where,
where
appropriate,
there's
also,
we've
also
talked
about
allowing
users
to
directly
reference
mesh
services
if
they
feel
comfortable
sort
of
digging
into
the
internals
a
service
mesh
hub.
C
But
I
think
one
of
the
lessons
from
glue
was
that
forcing
that
on
the
user
or
making
that
the
first
class
citizen
is
problematic,
because
users
then
will
either
have
to
understand
the
internals
of
discovery
or
they
may
need
to
manually,
create
discovered
resources.
And
I
think
that
we
want
to
avoid.
That
is
not
a
great
experience.
D
Okay,
that
sounds
good.
Now
we
did
cut
a
release
of
that
refactored
code.
Is
that
right,
yep
yeah?
I
think-
and
there
have
been
some
at
least
momentary
differences
in
that
features
that
are
supported
by
that
code
versus
what
was
supported
in
zero
six
one,
joe
or
scott
somebody
does
you
wanna.
I.
E
C
E
C
F
So
one
question
on
the
service
piece
that
you
just
talked
about
scott
is
that
I
wasn't
clear
is
that
is
that
all
was
some
of
what
you
said
planned
or
they're
all
what
you
said
part
of
the
release
and
then
is
it?
Is
it
what
kind
of
documentation
is
the
documentation
just
in
the
code
itself,
or
is
there
other
documentation
that
we
can
look
at
for
some
more
details?
F
C
So
everything
that
I
just
said,
except
for
the
app
mesh,
is
available
in
the
current
release.
I
believe
our
docs
have
been
updated
to
reflect
basically
ported
over
to
support
all
of
the
refactors
and
we've.
I
think
we've
documented
the
extra
functionality
that
we've
added,
as
far
as
you
know,
documenting
how
to
extend
the
service
discovery
we
we
did
not
originally
have
like.
This
is
more
what
I
would
consider
developer
documentation
or
maybe
like
advanced
operation
there.
There
would
have
to
be
some
work
there,
but
we
should.
C
We
should
basically
talk
about
what
it
actually
means
and
get
into
the
details
of
what
you
guys
want
to
do
and
figure
out
the
way
we
can
best
support
that,
but
definitely
we'll
want
to
have
that
documented,
whether
it
means
changes
to
the
code
or
another
proposal
I
would
I
would
put
is
that
we
find
a
way
to
have
a
generic
crd
that
can
be
used
for
generic
service
discovery,
and
that
way
we
won't
have
to
always
extend
the
code
itself
and
create
new
apis
to
support
specific
backends
you'll
be
able
to
leverage.
C
So
you
know
an
external
dns,
they
have
this.
You
can
choose
the
provider
for
the
dns
info
and
it
can
come
from
what
they
call
the
crd
provider,
which
is
just
a
generic
crd
that
as
long
as
your
operator
provides
that
crd,
it
doesn't
really
matter
where
it
comes
from.
C
F
So
you
know
that
might
be
an
area
that
we
could
even
help
with
we
we
use
external
dns
exactly
that
way
for
some
of
the
exact
use
case
that
we
described
to
you
previously,
so
we're
very
familiar
with
that
external
dns
we're
very
familiar
with
the
sources
we've
contemplated.
Even
you
know,
seeing
if
we
could
add
maybe
our
own
internal
source,
but
we
never
really
pursued
it
that
far,
but
but
what
you
said
makes
perfect
sense
to
us
and
we're
very
familiar
with
that
right.
F
Okay,
we'll
look
at
we'll
look
for
some
of
the
the
documentation,
so
we'll
look
at
the
code
base
for
some
of
the
changes
you
mentioned
with
respect
to
the
these
extensions,
and
then
we
can
circle
back
or
put
some
questions
on
slack
if
it's
not
coming
out.
Clearly
we
understand
that
we
understand
the
developer
documentation
problem
a
little
bit,
so
I
understand
there
might
be
more
source
code
than
great
documentation
for
some
of
the
internal
stuff.
C
So
one
thing
that
I'll
say:
there's
actually
a
couple
of
videos
that
we
recorded
where
I
walk
through
with
the
team
as
they
were
on
we,
you
know
we
expanded
the
size
of
the
team,
that's
working
on
service
mesh
hub
and
there
was
some
onboarding,
and
so
I
actually
recorded
that
which
is
a
walk
through
discovery
and
networking
from
a
high
level,
but
going
through
the
actual
code,
and
we
can
share
that
with
you
make
sure
that's
in
the
dock
and
that
might
be
very
useful
as
well.
F
Oh
yeah,
that
sounds
like
it
would
really
be
great
if
it's,
if
it's
something
that
can
be
public,
that
yeah
send
us
some
kind
of
pointer
or
put
it
on
slack
or
whatever.
Whatever
way
it
works
for
sharing,
it
would
be
wonderful.
C
B
Yeah
sure,
not
a
ton
more
to
say
there
on
osm
support
other
than
we'll
be
bringing
it
in
the
next
release.
You
know,
osm
is
largely
built
on
the
smi
apis
and
we've
added
translation
support
so
that
we
can
do
some
basic
traffic
policy
on
top
of
osm.
D
B
Yeah
there's
an
issue
linked
there,
and
that
is
also
in
turn
linked
to
the
relevant
pr.
If
you'd
like
to
get
a
look
at
the
code
ahead
of
time,
but
otherwise
that
should
drop
in
release
073
coming
up
soon
or
oh.
B
A
Then
the
harvey
you
want
to
talk
about
the
next
insight,
the
aws
account
registration.
G
Yeah,
this
should
be
quick
more
to
solicit
any
feedback
if
that
exists
with
this
audience.
So
currently
we're
working
on
restoring
our
app
mesh
integration,
and
the
first
question
we
need
to
answer
is
what
is
our
approach
for
registering
aws
account
credentials
with
service
mesh
hub.
G
So
later
the
solo
team
will
meet
and
discuss
some
possible
approaches,
we're
thinking
about
using
the
built-in
eks
pod
identity
web
hook
as
one
method
for
enabling
eks
clusters
to
talk
to
the
aws
rest
api.
I'm
curious
if
anyone
in
the
in
the
crowd
has
any
thoughts
or
opinions
on
how
they
would
like
to
provide
these
credentials
to
service
mesh
hub,
like
other
alternatives,
include
simply
giving
us
the
secret
key
and
the
access
key
id,
and
we
can
persist
that
in
our
system.
But
there
are
some
security
drawbacks
with
that
approach.
D
He's
not,
but
that
is
that
approach
that
we
all
took
with
glue
that
anytime
we
worked
on
that
is.
That
is
one
one
that
I
suggested
that
we
explore
yeah.
C
It's
basically
the
ability
to
create
an.
I
am
role
associated
with
a
a
service
account
in
kubernetes
and
then
inject
that
directly
to
the
pod,
and
then
the
pod
can
use
that
to
build
it
to
as
it's
the
basis
of
its
credentials.
So
there's
no
need
to
create
a
an
access
key,
a
secret
key
that
you
know
store.
That
is
a
secret.
All
of
that
is
is
handled
by
amazon
yeah.
That.
C
53,
that
would
be
very
helpful
to
look
into
I'm
I'm
not
familiar
with
actually
how
they
do
it,
but
that
would
make
sense.
H
G
On
our
end,
one
drawback
to
this
approach,
it
may
require
service
mesh
hub
to
be
installed
on
an
eks
provision.
Cluster
there's
a
lot
of
magic
that
happens
behind
the
scenes.
I
think
the
mutating
web
hook
is
not
even
run
in
the
cluster
from
the
discussion
on
this
issue.
It
sounds
like
it's
running
somewhere
in
the
background.
D
Well,
eks,
it
is
installed
on
eks,
then
we
should
definitely
take
advantage
of
that.
If
it's
not
and
we
want,
I
think
my
opinion.
We
do
want
to
make
that
an
option
then
we'll
need.
I
don't
know,
we'll
need
some
kind
of
agent
or
something
right
running
in
the
uks
cluster.
To
do
that.
G
G
Right,
no,
it's
just
a
completely
manual.
There
are
instructions.
I
The
way
sts
works
is
that
you
configure
an
open
id
provider
that
you
trust,
and
then
you
know
jots
by
that
provider
can
be
exchanged
for
amazon
tokens,
so
there's
nothing
tying
it
specifically
to
eks.
Potentially
we
can
take
that
approach.
It
might
mean
more
setup,
upfront
setup
for
the
user
yeah.
That's
what
I'm
worried
about.
I
I
F
So
so
one
thing
I'm
not,
unfortunately,
I'm
not
that
much
of
an
expert
on
aws
credentials
and
whatnot,
but
I
think
one
thing
that
would
help
a
lot
is
harvey
if
you
listed
some
of
the
options
just
you
know
bold
list
of
some
of
the
options
you
considered
because
I
can
draw,
I
mean
our
team
can
draw
on
a
number
of
people,
including
some
of
our
it
groups
who
do
this
kind
of
thing
for
a
living.
F
You
know
to
get
some
opinions,
so
if
you
put
down
some
of
the
options
at
a
summary
level,
we
can
come.
Maybe
maybe
come
back
with
some
opinions
or
suggestions
or
some
gotchas
that
we've
been
covered
and
and
as
mihai
was
mentioning
with
the
ralph
53
we've
kind
of
done
something
along
the
lines
of
that
already.
So
if
you
need
a
reference
of
that,
we
could
throw
it
in
the
issue
as
well.
G
That
sounds
good
I'll
link
the
issue
once
we
create
it
with
the
input
from
the
solo
team
and
I'll,
let
you
know.
F
G
A
So
cool
mihai,
do
you
want
to
talk
about
the
item
you
added.
E
H
Okay,
so
we've
been
having
this
discussions
regarding
limited
trust
for
some
time
now
and
we'd
like
to
get
involved
and
to
first
of
all,
we'd
like
to
understand
what
is
already
possible
in
smh
to
get
limited
trust
working
and
we'd
like
to
get
involved
into
update,
getting
a
better
approach
on
that
if
it's
necessary.
H
H
Okay,
so
from
our
point
of
view,
it's
not
just
about
glue
it's
about
getting
workloads
in
different
clusters
to
communicate
with
each
other,
but
without
actually
having
to
change
the
route
certificates
in
the
clusters,
because
I
think
that
may
be
a
problem,
especially
if
there
are
two
organizations
involved
in
that
that
exchange.
D
H
Okay,
so
one
of
the
propositions
we
came
up
with
with,
but
we're
eager
to
hear
your
opinions
on
this
and
what
you
guys
have
done,
because
you
probably
did
more
digging
into
this.
Then
us
was
to
use
to
configure
the
ingress
gateways
in
each
cluster
as
sort
of
an
edge
proxy
where
that
does
tls
termination
from
the
request
in
a
remote
cluster.
And
then
he
initiates
another
tls
connection
to
the
service
inside
its
own
cluster.
D
H
Well,
this
that's
one
of
the
problems
because
we're
not
sure
how
we
would
pass
down
the
identity
to
this
one.
We
we
would
definitely
verify
that
the
identity
in
the
proxy,
so
the
proxy,
would
know
the
identity,
because,
when
we're
envisioning
this
as
an
mtrs
connection,
that
is
not
a
simple
dls
connection
from
the
workload
to
the
ingress
gateway.
H
I
I
The
other
option,
which
I
like
less,
is
that
the
proxy
will
have
the
ability
to
impersonate
identities
in
the
destination
cluster
and
will
generate
an
identity
representing
you
know,
service
a
on
the
other
cluster,
essentially
translate
the
identities,
and
the
problem
is
that
you
give
a
lot
of
power
to
a
component,
that's
on
the
edge
impersonating
identities.
So
it's
not
really
good
security
practice.
I
F
So
the
the
edge
proxy
is
the
only
one
that
has
the
client-side
identity.
It's
not
actually
it's
not
actually
available
to
the
workload
process.
Proxy.
I
That's
option
one
in
option:
two:
we
can
have
the
edge
proxy,
you
know
be
able
to
kind
of
impersonate
a
service
and
translate
the
identity,
but
I
think
that's
giving
a
lot
of
power
to
the
edge
proxy.
I
But
those
are
the
the
two
options
I
thought
about
and
I'm
curious.
If
there's
any
more
options,
I
didn't
think
about.
F
So
the
current
the
current
glue-
let
me
just
get
grounded
here
the
current
glue
implementation
of
this
does
more
of
the
the
first
form
or
it
doesn't
even
do
tls
mtls
from
the
client
side.
I
F
Okay,
because
it
wasn't
clear
from
the
documentation,
if
it
even
did
mtls
from
the
client
to
the
edge
proxy
and
just
tls,
it
looked
like
it
almost
did,
tls
from
the
client
to
the
edge
proxy
and
then
impersonated
was
impersonating.
The
service
is
for
the
client
and
then
appreciating
the
client
for
the
end
service.
I
F
C
We
discussed
the
possibility
of
building
an
identity
gateway
that
would,
you
know,
enforce
cross
trust
domain
identity.
I
D
D
D
But
you
know,
under
the
covers
surface
mesh
hub
is
orchestrating
the
rules
in
the
right
spot,
and
in
this
case
the
right
spot
would
be
the
edge
proxy
and
that's
where
the
enforcement
will
happen
not
at
the
actual
workloads
that
themselves,
which
is
what
happens
in
a
service
mesh
running
in
a
single
trust
domain
right.
F
D
D
If
you
have
different
trust
domains
and
they're
both
using
istio
both
using
spiffy
then
having
the
different
trust
domains,
you
don't
really
have
to
translate
identity
per
se,
but
in
in
the
the
worst
case
scenario
is.
These
are
different
means
and
different
identity
representations,
and
that's
where
this
solution
helps
solve
that.
F
H
F
H
D
If
it's
just
istio,
then
an
area
that
we
might
want
to
look
at
is
in
the
spiffy
federation,
and
so
you
can
exchange
trusted
cas
with
the
different
trust
domains
so
that
you
can
still
go
from
a
trust
domain
in
a
to
a
service,
running
trust,
main
b
and
still
have
the
connection
trusted
end
to
end
without
having
to
do
anything
special
at
the
edge
proxy.
D
So
I
looked
in
the
code
and
istio
is
the
proxies
are
able
to
call
out
to
a
bundle,
endpoint
and
pull
down
the
the
key
set,
but
istio
itself
doesn't
have
an
end
point
that
exposes
that.
D
But
yeah
the
proxy
verifies
that,
but
the
key
exchange
I
can
send
you
the
link,
but
it
is
able
to
look
up
from
a
trust
domain
bundle,
endpoint
yeah.
What
are
the
the
trust
domains
and
what
are
the
appropriate
certificates
to
go
along
with
it?
Let
me
find
you.
D
H
F
D
So
in
that
doc,
once
I
don't
know,
golan
is
being
ridiculous
for
me
right
now,
but
I
can
I
can
point
to
the
code
in
this
istio
that.
A
Let's
see
so
no
other
topics
outside
of
scott,
just
posted
the
post,
refactor
code,
walkthroughs
for
the
the
repository
slash
code,
walkthrough
for
the
discovery
and
the
networking.
So
that's
in
here
for
folks
to
be
able
to
see,
but
that's
it
on
topics
any
anything
else,
anything
else
you
want
to
bring
up
or
have
a
question
about
today.
F
A
Yeah
so
the
link
to
the
issues
there,
so
you
can
see
the
full
list
of
stuff
and
then
the
the
google
drive
links
are
it's
got
if
these
are
the
things
that
these
are
the
ones
that
I
looked
at
the
other
day,
they're
they're,
like
recorded
demos,
right
basically.
C
The
yes
exactly
screen
share
and
I'm
happy
to
do
another
session.
If
maybe
the
cisco
people
anyone
who's
interested,
wants
to
do
like
a
live
session.
We
can
totally
set
that
up.
F
Yeah,
that
might
be
very
interesting.
I
think
let
us
first
actually
go
through
what
you
already
have
and
then
then
we
can
be
more
specific.
If
there's
areas,
we
could
be
more
specific
about
what
areas
are
the
most
confusing
to
us,
and
we
have
at
least
understanding
of
so
that
would
be
good.
E
F
I
think
we're
due
to
just
on
that
last
point
due
to
some
pto
and
stuff
like
that,
we're
probably
at
least
two
weeks
out
before.
We
would
request
that
scott.
So
maybe
at
the
next
community
meeting
we'll
decide
on
on
that
and
and
if
so,
when
kind
of
thing
at
the
two
weeks
out.
A
Sounds
good,
then,
with
that
we'll
see
folks
in
two
weeks
and
for
those
going
on
pto
have
have
fun
wherever
you're
off
to
thank
you
all.