►
Description
Network Service Mesh PR Issue Review Weekly Meeting 2020-02-11
C
C
D
D
F
D
Can
we
just
spend
a
minute
or
two
before
we
go
to
the
project
bottom,
just
looking
at
how
how
many
old
PRS
we
have
like
you
know
older
than
two
months.
Normally
we
have
things
that
I
think
that's
sort
of
they
were
closed
already,
but
there
are
things
that
not
just
sitting
there
and
probably
are
irrelevant
already.
D
D
D
D
A
A
C
A
And
also
this
involves
workspace
management.
We
have
right
now
using
a
device
plug-in,
so
we
need
to
somehow
solve
this
issue
with
assignment
of
separate
subfolders
for
Mme
and
for
endpoint
UNIX
socket
to
be
securely
independent
one
from
another.
So
until
these
problems
will
be
solved,
I'm
not
sure
if
to
be
easy
to
get
rid
of
a
device
plug
yeah,
yeah.
F
You
know
effectively,
we
need
to
you,
know
effectively.
I
think
we
will
have
an
easier
time
getting
rid
of
device
plug-in
stuff
on
the
in
the
new
repos,
because
they're
actually
properly
modular.
You
know
there
would
be
major
major
major
surgery
to
get
rid
of
it
here
and
it
would
be
relatively
minor
surgery
to
work
in
that
direction.
E
D
I
mean
it's
state
for
half
a
year
here:
okay,
then
we
have
possible
store,
described,
okay,
I,
don't
think
that
we
should
go
through
each
each
and
one
of
them
I
tried
to
send
to
kind
of
send
some
messages
here
as
a
pink
like
okay.
We
still
need
this
one
so,
but
but
please
just
check
whatever
is
hanging
there
for
it's
hot
enough,
so
that
we
don't
like
anything
I
would
consider
anything
before
November.
So
everything
here
is
some
kind
of
questionable
for
why
it's
still
in
you
know,
ok
saying
this.
F
F
Usually
my
experience
is
it's
easier
go
from
right
to
left
from
left
to
right,
because
that
way,
as
you
discover,
you're
moving
things
to
the
left,
you
don't
wind
up
with
with
issues,
so
you
go
right
to
left.
You
look
at
things
like.
Oh
that's
in
progress.
You
move
to
the
in
progress
column.
Then
you.
F
It
was
a
to
do
comment
in
there.
It
turns
out
not
to
be
super
difficult,
and
this
this
literally
lets
us
get
rid
of
a
whole
bunch
of
our.
We
have
an
insane
amount
of
dial
machinery.
Currently,
this
literally
lets
us
get
away
from
that,
because
we
we
have
your
PC
dial
options
for
any
of
the
things.
That's
not,
though
you
might
want
to
turn
and
because
we
can
pass
that
in
to
the
constructor
for
the
connect
server.
Now
we
don't
have
to
go
use
our
own
bespoke,
dial,
libraries.
F
F
F
C
F
C
C
F
F
C
Actually,
the
current
Prometheus
integration
is
not
updated
to
support
path,
but
what
I
think
we
need
I,
don't
think
if
we
are
going
to
have
the
new
API
soon
it
doesn't
make
many
sense
to
update
the
integration
with
the
puffin,
then
add
the
whole
refactoring
it
doing
from
again.
So
maybe
we
need
to
directly
implement
that
after
having
the
new
API.
D
F
C
At
the
moment
it's
just
buy
pot
names,
namespaces
and
I
think
we
may
add
five
segments,
for
example,
in
order
to
distinguish
which
per
fee
is
the
metric
part
of
and
what
I
proposed
was
like.
I
think
I
didn't
write
about
it
in
the
issues,
but
we,
after
hearing
that
we
can
implement
some
collector,
that
if
you
point
to
two
points
from
the
path
it
can
collect
the
whole
matrix
in
those
segments
and.
A
F
Please
know
this
is
not
super
well
thought
out,
but
it
seems
to
me
that
you
basically
have
T
X,
you
know,
transmit,
receive
and
and
drop
are
probably
the
metrics
right,
because
coming
in
incoming
you,
you
have
received
outgoing,
you
would
have
transmit
and
then
you
know
drop.
Tells
you
how
many
of
the
things
you
receive
that
didn't
get
passed
on
to
the
next
pass
segment.
So
you
can
tell
the
difference
between
this
node
dropped.
Something
versus
I
lost,
something
in
a
wire
at.
C
F
C
Actually,
but
I
am
preparing
something
from
the
next
caller
from
community
Co
that
today
do
with
different
tools.
We
can
start
one
that
is
good
for
visualizing
once
we
have
everything
in
parameters,
so
we
can
have
a
good
observable
way
to
see
that
network
topology
and
see
the
packets
kong-kong
between
different
segments
and
etc.
We
can
discuss
that
in
more
details
in
the
community
meeting
later.
Maybe
this
is
separate.
This
is
just
for
the
visualization
itself.
F
Ronis
love
you,
you
probably
saw
the
so
there's
some,
so
we
do
have
some
ACOTA
summit
just
landed,
mockable,
mockable,
kernel,
stuff,
basically
mockable
that
link
pieces
and
then
the
sdk
kernel
repo.
So
hopefully
things
will
go
relatively
cleanly
from
there.
Is
there
anything
you
want
to
say
about
all
that
stuff.
E
D
B
F
B
F
Basically,
usually
you
use
UDP
for
DNS,
you
mean
the
three
transports.
I'm
aware
for
DNS
are
there's
UDP,
which
is
what
you
usually
use,
there's
TCP,
which
doesn't
get
used
as
often
you
know,
and
then
there
is
very
recently
DNS
over
HTTP
and
probably
want
to
make
sure
that
all
those
protocols
are
supported,
but
but
but
basically
look.
We
want
to
look
at
what
they're
doing,
probably
in
something
like
forward
or
to
see
like
how
they're
there's
getting
that
I
mean.
D
A
I'm,
a
bit
late
with
matrix
stuff,
still
working
on
it
plant
to
ablate
my
poor
quest
today.
So
what
else
idea
is
to
put
the
matrix
into
the
pop
segment?
So
I've
changed
my
pool
quests
in
some
areas.
It's
easier
and
less
code
varies
a
bit
more,
not
not
so
easy,
but
I
think
in
general
will
be
better
to
put
matrix
enter
into
the
path
itself.
A
F
Of
the
nice
things
about
premium
in
the
past
segment
itself
is
that
pod
always
has
the
option
of
refreshing
a
connection
at
any
point
right.
So,
yes,
there
are
timers
anything
used
to
refresh
before
a
certain
place.
They
could
always
refresh
early
and
that
can
essentially
allow
a
pod
to
pump
metrics
if
need
be.
So
if
you
think
that
something
is
wrong,
you
can
pump
your
metrics
and
find
out
what
the
metrics
are
telling
you,
which
is
that.