►
From YouTube: Layer5 Community Meeting (Oct 23rd, 2020)
Description
Meshery Common Library Architecture presented by @michaelgfeller!
A
A
A
Sound
off,
if
you
would
in
the
chat,
if
you're
attending
kubecon,
if
you're
not
or
there
is
a
fee
and
it's
potentially
getting
in
your
way.
Let
me
know,
let
me
know,
there's
potential
ways
around
that.
So,
let's
put
kubecon
as
a
topic
there.
We
go
okay,
well,
it's
friday,
the
23rd
of
october.
So
next
time
we
meet
it'll,
be
just
in
advance
of
candy
day
or
halloween.
A
In
the
chat
is
linked
to
these
meeting
minutes,
I'm
not
sure
why
we
still
feel
compelled
to
put
that
in
there,
because
everybody
that's
on
the
call,
is
doing
a
fantastic
job
of
doing
exactly
what
you're
supposed
to
do
anyway.
So
do
we
have
any,
I
think
homero
you
might.
This
might
be
your
first
time
on
this
call
very
nice
to
have
you.
I
understand
that
your
audio
challenged
today,
or
rather
it'll
be
a
one-way
audio
discussion.
A
A
It
feels
like
it
was
this
week,
so
a
few
people
have
come
in
from
there.
We
we
had
a
couple.
People
come
in
from
three
o'reilly
workshops
that
have
been
given
over
the
last
two
weeks
and
that's
been
quite
pleasant.
People
are
taking
advantage
of
mastery
and
putting
it
to
use
speaking
of
people
putting
measuring
to
use.
A
There
is
there's
a
long
awaited
achievement
here.
I
guess
if
you
could,
if
you
can
call
this
an
achievement,
the
measuring
project
that
you
all
have
been
working
on
is
getting
noticed
and
it's
getting
noticed
without
any
without
a
lot
of
marketing.
I
would
say,
like
comparatively
to
other
projects
that
just
got
announced
last
week,
a
couple
from
hashicorp
that
are
open,
source
they've
got
you
know,
2,
000
or
so
stars,
because
they
have
a
big.
They
have
a
big
stage
to
announce
those
on.
So
it's
very
easy
to
collect
those
stars.
A
So
while
for
my
part,
I
would
hope
that
measure
would
have
just
as
many
a
couple
thousand
I'm
I'll
say
that
I'm
really
proud
of
the
500
that
are
there.
They
are
hard
earned
and
honestly
earned
they're.
Not
they
people
didn't
star
measuring
out
of
buzziness,
they
started
measuring
because
they're
intrigued
and
hopefully
it's
it's
helping
people.
A
A
A
A
Yeah,
I'm
trying
to
think
about
what
else
the
adapters
and
things
those
were
all
shown
in
in
both
of
the
talks,
so
your
work
has
been
recorded
and
shown
on
and
it'll
be
shown
on
stage
at
kubecon
and
so
I'll
be
sure
to
point
out
the
talks
so
that
all
of
you
can
beam
with
pride.
As
that
happens,
pretty
neat
okay
before
we
go
into
the
first
topic.
Now
is
the
time
to
solicit
additional
topics.
If
you
have
topics
to
chat
about
today,
just
drop
them
down
below
nikita.
A
A
B
B
And
then,
of
course,
there
was
the
discussion
about
libraries
and
then
abhishek
was
implementing
a
common
set
of
packages.
If
you
like
in
the
kuma
adapter
and
I
sort
of
thought,
it
would
be
a
good
test
to
see
whether
those
can
be
extracted
to
a
common
library
and
reused
in
the
console
adapter
code
and
that's
what
I've
then
been
doing
and
working
on.
B
So
now
we
have
another
common
library
called
measurey,
adapter
library,
which
is
used
in
one
branch
of
the
console
adapter,
which
is
up
as
a
pull
request
as
well,
and
of
course,
we
discussed
then
started
discussing
more.
You
know
how
the
purpose
of
common
libraries
for
measuring
how
they
should
be
designed.
B
The
advantages
and
disadvantages
and
then
abhishek-
and
I
working
together
on
on
this
presentation,
discussing
it
together.
So
these
are
some
sort
of
general
considerations
about
com,
libraries
in
general,
but
also
of
course,
for
measuring
and
there
by
no
means
conclusive,
and
so
I
think
we
go
through
these
slides.
I
saw
that
lee
has
added
some
comments.
B
There
are
a
couple
of
slides,
maybe
seven
eight
slides,
but
we
can
discuss
otherwise
when
you're
going
through
the
slides,
so
obviously
benefits
or
current
libraries
have
some
benefits
and
there's
also
a
reason
why
one
likes
to
introduce
com
libraries,
one
of
them
is,
of
course,
someone
would
like
to
avoid
code
duplication
one
would
like
to
implement
the
plumbing,
so
the
boring
bits
and
pieces
so
that
uses
of
the
library.
In
our
case,
for
instance,
the
measuring
adapters
developers
can
focus
on
implementing
adapter
specific
code.
B
B
And
then
there
is
also
the
benefit
that
if
you
have
a
common
library
that
the
users
of
those
library
get
updated
and
improved
functionality
for
free.
You
can
also
more
easily
address
securing
security
concerns
and
distribute
them.
And,
as
I
said
previously,
it
allows
developers
to
focus
on
the
non-common.
B
Aspects,
so
there
are
some
requirements
to
to
to
a
library,
to
any
com
library
actually
to
be
well
documented,
but
of
course
not
over
documented.
It
should
be
easily
understandable
to
be
easy
to
use.
It
should
enable
productive
development,
so
it
should
not
force
developers
to
use
something,
but
it
should
enable
them
to
be
able
more
productive.
B
It
should
be
minimal
as
minimal
as
possible,
so
that
you
don't
have
a
lot
of
maintenance
burden
in
in
this
library.
There
should
be
loose
coupling
between
libraries
and
modules
using
it
and-
and
there
should
also
be
sort
of-
like
you
know,
design
for
exchange
design
be
extra
designed.
For
extension,
we
designed
for
change
things
change
over
the
course
of
time
and.
B
But
of
course,
there
are
also
things
that
we
need
to
watch
out
for
with
common
libraries
with
any
library,
for
that
matter.
Others
can
become
dependent
on
common
libraries,
and
so
there
is
a
danger
or
a
possibility
that
common
libraries
become
a
bottleneck
for
necessary
changes
like,
for
instance,
adding
new
error
codes
or
updating.
You
know
the
library
version
or
something
that
it's
tempting
to
try
to
predict
all
possible
use
cases,
and
we
know
you
know,
that's
almost
impossible
and
generally
generalization
in
general
is
not
easy.
B
And
I
think
it's
both.
I
think
the
need
often
surfaces
in
in
the
modules,
and
it
might
be
a
good
idea
just
to
implement
it
in
the
module
and
then
see
whether
it
can
be
generalized
sort
of
from
the
bottom
up,
but
at
the
same
time
that
we
also
have
sort
of
like
guidelines
and
design
best
practice
or
good
practice
from
the
top,
so
that
we
we
have
a
plan
when
we
sort
of
develop
a
common
library
and
the
usages
of
it.
B
And
yes,
this
is
sort
of
you
know
the
dependency
on
hong
kong
libraries,
but
as
far
as
I
can
see,
we
already
have
that
now
because
they
live
in
in
measuring
code.
If
I
remember
correctly,
and
then
you
always
get
it
from
there,
if
you
implement
functionality,
but
then
of
course-
and
I
guess
in
our
use
case,
it
has
to
be
synchronized
anyway,
but
this
is
something
we
have
to
look
into
as
well.
B
Another
couple
of
questions
we
discussed,
like
you
know,
should
modules
that
are
using
com.
Libraries
like
the
measuring
adapters,
should
they
be
allowed
to
import
libraries
like
the
kubernetes
client
go
or
you
know
any
other
library
that
is
used
by
the
common
library
as
well
to
implement
missing
functionality,
and
I
think
that
should
be
allowed,
because
if
it
wouldn't
be
allowed,
I
mean
one
thing
is
to
to
sort
of
disallow
it.
If
one
has
a
good
reason-
and
another
thing
is
to
you
know,
how
would
you
enforce
that
anyway?
B
B
So
one
way
to
look
at
it
is
one
of
the
libraries
is
like
a
framework,
a
mini
framework,
so
it
is
used
by
implementing
use
case-specific
code
to
be
called
by
the
framework
and
the
machinery
adapter
library.
This
is
so
the
measuring
adapter
library
does
all
the
the
plumbing
around
the
grpc
api
and
code.
B
You
know
towards
tooling,
if
you
like
utilities
and
tools
that
is
imported
and
used
directly,
and
you
know
in
that
sense
make.
The
goalkate
is
more
such
a
tooling
library,
when,
when
I
was
sort
of
started
being
involved
in
this
in
measuring,
I
was
really
quite
confused
about
the
some
of
the
names
that
were
used
and
mesh
kit
showed
up
several
times
when
people
were
talking
about
coke.
B
It,
as
I
found
out,
and
so
it
was
discussed
to
rename
gokit
to
meshkit,
also
makes
it
a
little
bit
easy,
not
to
confuse
it
with
go
kit
kit,
which
is
the
go
kit
with
a
hyphen
between
the
go
and
the
kit,
which
is
this
middleware
library
that
we're
also
using-
and
I
think
that's
now
that
we
now
will
I've
understood
some
commentary.
So
I
think
in
a
issue
correctly
that
we
know
actually
ready
to
rename
goku
to
meshkit
at
some
stage.
B
C
B
So
this
is
a
function
now
in
the
measuring
adapter
library,
that
is
getting
service
ports
of
a
kubernetes
service
and
then
we
sort
of
discussed.
Where
should
this
live?
You
know,
should
this
be
in
the
measuring
adapter
library,
or
should
it
be
moved
up
to
the
meshkit
library?
And
if
then,
this
service
is
this
function?
B
B
And,
on
the
other
hand,
you
will
not
want
to
import.
You
know
code
from
the
measuring
console
adapter
in
in
the
measuring
adapter
library
and
to
avoid
circle
dependencies
and
then
problems
associated
with
that-
and
this
is
this
happens
quite
easily-
that
one
actually
that
that
one
creates
circular
dependencies
without
noticing
it.
B
B
B
I
personally
think
it.
You
know
we
can't
get
it
right,
the
first
time
anyway,
and
having
a
continuous
improvement
and
refactoring
in
a
careful
way,
of
course,
as
it
is
a
current
library
and
maybe
start
with
sort
of
like
two
adapters
using
it
in
the
first
round.
The
console,
adapter
and
kuma
adapter,
for
instance,
would
be
a
good
way
to
go
forward
and
then
discover
issues
and
advantages
and
disadvantages
with
this
approach.
A
A
B
D
B
B
That,
for
instance,
meshkit
should
not
import
the
measuring
adapter
library,
but,
as
we
have
discussed
now,
probably
sort
of
like
the
top
level
imported
kubernetes
client
goal
would
go
one
level
up
if
you
like,
but
this
is
sort
of
more
a
it's
not
meant
to
introduce
complexity.
It's
just
meant
to
to
introduce
a
mental
model
of
the
hierarchy
so
that
one
avoids
creating
more
complex
dependencies
and
especially
that
one
avoids
circular
dependencies.
B
B
B
A
This
is,
this
is
good.
This
is
good,
there's
some
things
to
talk
about
inside
of
here.
So
first,
I
know
that
for
some
of
you
that
for
whom
this
is
your
first
call
this.
Hopefully
this
is
intriguing
and
a
good
level
of
depth
to
tickle
your
noodle.
If
I
can
you,
I
could
get
you
get,
you
excited
get
you.
A
So
here's
a
link
to
the
presentation
that
my
who
was
just
presenting
there's
a
related
like
there's
another
topic
on
a
messaging
system,
that's
kind
of
related
to
some
of
the
same
design
principles
and
some
of
the
same
value
that
we
will
derive
as
a
project
through
use
of
a
common.
A
couple
of
common
libraries.
A
A
A
A
They
will
can
people
can
see
this
in
full
screen
mode.
Correct,
like
zoom,
occasionally
does
the
thing
where
you
go
full
screen
and
then
you,
okay,
there's
a
number
of
things
to
talk
about.
So
one
of
them
is
that
when
we
first
started
writing
measuring,
we
were
in
a
big
hurry
like
we
typically
are.
We
did
try
to
give
some
forethought
and
some
learnings
from
there
were
of
those
that
were
involved
at
the
time.
We
tried
to
make
sure
that
lessons
learned
in
other
projects
were
incorporated
here.
A
If
you
know
there,
there's
20
something
service
meshes
now
and
so
had
we,
you
know,
had
the
project
had
the
design
that
all
the
support
for
each
of
those
individual
service
meshes
and
interacting
with
them
in
different
ways,
because
they
all
have
different
apis.
They
all
want
to
be
provisioned
and
provisioned,
using
different
mechanics,
whether
that's
manifests
or
helm,
charts
or
using
their
cli
itself
or
other.
A
A
People
can
come
in
and
descend
upon
something
like
the
console,
adapter
and
reach.
You
know,
pull
it
up
from
the
depths
of
like
being
a
year
old
to
being
quite
quite
up
to
speed,
and
that
can
happen
independent
of
each
other.
So
the
this
is
one
when
you
step
back
and
look
at
this,
this
is
measuring
itself
and
its
architecture
is
micro
services
oriented
in
nature.
A
It's
the
same
as
similar
value
proposition
that
service
meshes
have.
If
that
doesn't
immediately
resonate
for
you,
I
it
may
not
come
to
come
see
me
I'll,
tell
you
why.
That
is
how
a
service
mesh
and
its
value
relates
to
the
same
concept
of
separating
concerns
so
on
the
adapters
themselves.
Well,
I'm
re-articulating
some
things
that
michael
said,
because
in
part
like
every
time
any
time
I
see
people
not
asking
some
questions
or
making
some
suggestions.
It's
I
consider
it's
kind
of
one
of
two
things:
it's
either.
A
I
don't
understand
what
you
just
said
so,
like
I,
don't
really
have
anything
to
add
there
or
two
it's
yeah,
I
get
it,
and
this
is
kind
of
boring
or
like.
Let's
go
to
the
next
thing.
My
hunch
is
there's
more
of
us
that
land
in
that
first
bucket
of
I
kind
of
get
what's
going
on,
there's
some
refactoring
to
improve
the
project.
A
There's
some
value
in
doing
that,
but
the
merits
of
one
direction
versus
the
next
okay
I'll
tell
you
now
that
what
we
have
done,
if
you
go
into
the
later
five
io
org,
the
the
set
of
repositories
that
measury
and
our
the
other
projects
here
are
built
on.
There's
43
repos
now,
which
is
kind
of
amazing
to
me,
but
one
of
those,
I
believe
is
carries
the
name
measurey
adapter
template,
which
only
speaks
to
the
pain
involved
in
not
applying
the
principle
of
dry
like
who
was
saying
driving.
Don't
you
know,
do
not
repeat
yourself.
A
What
we
ended
up
doing
was
well,
we
needed
to
make.
We
created
the
istio
adapter.
First,
then
we
needed
to
make
the
other
adapters.
They
need
most
of
the
same
code.
There's
some
there's
some
smaller
nuanced
differences
between
the
individual
meshes
they're.
All
generally,
you
know
they're
all
in
the
same
category
of
technology,
they're
all
service
mesh
they're
going
after
some
common
use
cases,
you
know
and
they're
different
too.
A
Really.
What
we're
trying
to
do
here
is
stop
repeating
ourselves,
stop
copying
and
pasting
code
that
we've
got
to
go
over
and
fix.
You
know
nine
times
over
now,
because
we're
about
to
have
a
ninth
adapter
for
the
nginx
surface
mesh
and
instead
work
on
a
prince
on
toward
that
dry
principle
and
trying
to
achieve
basically,
you
know,
essentially
almost
no
repetitive
code
within
each
server
measuring
adapter
and
another
way
of
articulating,
that
is
to
say
that
each
adapter
should
really
only
contain
service
mesh
specific
logic.
A
So,
if
you're
dealing
with
the
istio
adapter,
the
logic
that's
in,
there
should
really
be
specific
to
istio,
constructs,
galley
and
pilot
and
citadel
and
other
istio
specific
things
you
won't
find
elsewhere
and
that's
been
that's
part
of
the
goal
that
who
is
talking
about
it's
there's.
Another
important
reason
why
we'll
continue
to
have
adapters
as
separate
constructs.
A
A
A
You
can
that's
a
pretty
fairly
universally
supported
capability
across
any
of
the
service
meshes.
So
smi
defines
a
common
api
to
configure
traffic
splitting
and
any
of
the
seven
service
meshes
that
integrate
that
implement
smi
as
someone
consuming
a
mesh
and
using
it
and
wanting
to
do
intelligent
things
with
it,
you
can
either
make
a
choice
to
write
your
software
and
write
your
infrastructure
specific
to
that
mesh
or
not
or
use
this
abstract
layer.
A
The
challenge
with
any
abstract
layer
is
that
of
actually
what
was
talking
about
about
generalization
like
it's
hard
for
a
spec
like
smi
to
general,
generally
present
a
uniform
api
surface
and,
at
the
same
time
expose
all
the
va.
All
the
unique
differentiation
that
istio
or
mesh
or
linker
d
might
have
and
keep
a
uniform
interface
like
it
doesn't
by
the
way
it
just
it
does
a
lowest
common
denominator
set
of
capabilities.
A
So
so,
in
fact,
right
now,
smi
is
only
so
powerful
or
you
can
only
get
so
much
out
of
a
mesh
if
you're
using
smi.
Only
that
is
in
that
is,
in
contrast
to
what
we're
trying
to
achieve
here,
we're
intentionally
service
meshes
to
ex
exp
a
venue
or
vehicle
to
expose
their
differentiation,
their
unique
capabilities
by
putting
that
service
mesh
specific
logic
into
the
designated
adapter.
A
That
doesn't
mean
that
we
have
to
go
around
repeating
ourselves,
a
ton,
and
so
because
we
have
distributed
systems
concerns
here
and
because
the
there's,
a
couple
of
languages
that
we
focus
on
in
this
particular
project,
pertinent
to
this
conversation
is
go.
Golang
is
what
these
adapters
and
mesh
are
written
in.
Well
as
a
predecessor,
service,
meshes
or
client,
libraries
or
microservices
frameworks,
one
of
the
more
popular
ones
in
the
go
in
go
land
is
gokit.
A
A
A
Into
the
projects
it
turns
out
that
gokit
has
a
lot
of
what
we
need,
but
it
also
is,
is
only
takes
it
so
far.
There's
some
customizations
that
we
want
to
do
particularly
around
the
first
example.
That
comes
to
my
mind,
is
around
error,
messaging
and
logging
and
making
sure
that,
when
things
go
awry
that
we're
really
giving
people
a
great
experience
telling
them
what
specifically,
what
specific
error
occurred,
here's
the
unique
identifier
for
it:
here's
the
probable
cause
and
here's
suggested
remediations,
and
we
need
a
system
wherein
we
can
do
that.
A
A
A
A
Subsequent
to
that
will
be
a
common
adapter
library,
a
measuring
adapter
library
that
will
leverage
some
of
these.
You
know
that
error
messaging
system
and
things
that
are
described
here,
but
it
and
it
will
that
adapter
library
will
build
on
build
on
that
by
adding
in
support
for
provisioning
a
service
mesh
using
helm
or
downloading
a
service
meshes
release
packages
from
github
or
any
number
of
these
common
use
cases
that
we
we
find
we
have
need
for
across
the
adapters.
The
adapters
will
in
turn,
import
that
package
and
and
leverage
the
package.
A
Okay,
so
I
just
reset
everything
and
who
said-
and
I
don't
know
why
I
felt
compelled
to
do
that.
Rather
I've
got
a
couple
of
questions
or
I
do
know
why
I
felt
compelled
to
do
it
because,
because,
if
you're,
not
speaking
up,
then
you're
gonna
have
to
listen
to
me,
re-explain,
something
I
guess
here's
the
question
for
from
me,
you
know
to
everyone,
is.
A
A
E
So
if,
if
that
is
not
there,
then
the
adapter
code
will
be
restricted
to
not
use
a
couple
of
utility
functions
that
are
inside
musket,
like
like
the
generate
uid
functions
and
like
a
general
utility
functions
like
unmarshall
marshall
or
whatever.
Another
example
would
be
to
do
a
tcp
check
on
on
a
service
endpoint
or
something.
A
E
The
uu
yeah
yeah
totally
so
so
basically
uid
was
just
an
example,
so
something
that
is
so.
For
example,
I
have
a
functionality,
a
in
measure,
which
I
just
do
a
wrap
on
the
adapter
library
to
for
the
adapters
to
use.
Then
that
will
be
just
an
overkill
like
like.
Basically,
I
can
delve.
I
might
as
well
directly
use
the
functionality
in
the
adapter
instead
of
having
a
wrapper
function
inside
the
adapter
library.
A
B
I
think
why
shouldn't
it
be
allowed
to
import.
I
think
there
are
several
questions
and
or
some
possible
answers.
I
think
one
will
be
a
technical.
So
if
we
implement
the
same
functionality
say
which
is
uuid
generation,
should
it
should
we
use
that
or
should
we
be
allowed
to
use
another
one,
but
also,
I
think
another
discussion
or
reason
is
if
I
haven't
really
had
a
close
look
at
the
gokit
library,
if
it's
implementing
middleware
should
it
actually
be
from
a.
B
A
Is
yeah
you
know
what
well
maybe
I'll
suggest
this
just
because,
because
there's
five
minutes
left
that
this
was
that
it
might
be
suffice
to
say
this
is
wonderful.
This
is
exactly
the
type
of
discussion
and
and
presentation
of
concerns
and
considerations
that
that
we
needed
michael
it'll
get
people
thinking
on
the
subject
and
and
it's
good
to
give
everyone
on
the
call
a
bit
of
time
to
digest
and
comment.
So
I'll
go
re-articulate
that
same
question.
A
F
I
am
here
if
you
want
to
say
something
about
the
ghosts:
that'd
be
great
yeah,
please,
okay,
okay,
perfect
this!
This
week,
we
we
keep
a
workshop
on
on
measuring
the
workshop
was
based
and
the
topics
was
first
lee
was
given
a
an
overview,
what
a
separate
machine
and
what
measure
it
is
and
how
measuring
each
is
used
to
it,
uses
it
as
a
a
tool
for
a
service
mesh,
and
the
second
part
was
given
by
me
and
how
to
people
contribute
to
measuring
documentation.
Translation
project
because
is
was
was
an
event.
F
F
There
is
no
native
english
speaker
speaker,
so
that
was
the
overview
and
the
event
worship.
There
is
the
record
of
how
to
do
the
contributions
to
the
translation
of
of
measuring,
and
I
think
that
this
is
a
good
effort
for
the
rest
of
the
people.
That
is
not
from
from
a
country
that
speaks
english
to
give
representation
of
of
the
diversity
of
people
in
industry
and
life
and
around
liar
five
projects.
F
The
first,
the
first
step
that
we
are
working
on
is
only
to
translator
magdalen
files.
Yes,
and
we
receive
a
couple
of
of
con
of
pull
requests.
Some
of
those
are
already
merged.
During
this
this
weekend,
the
cause
evan
continues
working
on
on
something
called
a
sprint
contribution
that
we
consist
of
two
days
friday
and
sunday
and
saturday
sorry
from
assistance
working
on
on
doing
contributions.
F
I
can
assist
people
to
to
finish
the
that
process
and
during
this
week
weekend
or
during
internet
week,
I
think
I
going
to
discuss
with
sriti
about
how
we
can
implement
about
a
more
robust
way
to
to
allow
a
documentation
to
be
translated
into
another
language.
There
is
a
plugin
in
jekyll
that
we
can
use
and
we
need
to
to
discuss
for
the
next
week,
for
example,
what
ho
ho
that
blowing?
We
changed
the
architecture
of
our
missionary
documentation
and
maybe
over.
A
A
So
this
is
the
second
time
that
cc
or
that
costs
has
been
held,
and
it's
the
second
time
that
our
community
has
been
involved
in
teaching
a
workshop
and
and
much
to
my
much
to
my
delight,
jesus
and
I
got
to
meet
at
last
year's
workshop.
It
was
delivered
on
on
istio
and
it
was
supposed
to
be
how
to
contribute
to
istio
and
it
contributed.
A
Istio
is
hard
or
you
know,
people
are
busy
they're,
not
necessarily
there
to
try
to
help
grow
others
and
and
and
they
want
a
community-
it's
just
it's
hard,
it's
hard
to
contribute
to,
and
so
anyway
we
jesus
hung
around
and
has
been
active
in
the
community
since
and
has
been
growing
a
community
of
open
sourcers
in
mexico,
and
so
I'm
really
tickled
that
that
he's
he's
the
one
that's
delivering
the
workshop
this
year,
which
is
really
cool.
So
I
guess
that
means
probably
homero
next
year.
A
D
Yeah
hello,
so
I
have
not
been
on
this
call
before
and
yeah
I'm
missing
everyone.
I
am
from
india,
I'm
finally,
a
computer
science
student
right
now
and
I
have
like
I'm
quite
interested
in
working
with
systems,
cloud,
etc
previously
worked
on
some
of
such
projects
and
I'm
really
new
to
measuring
I'm
actually
exploring
the
idea
of
service
meshes,
etc,
but
I
found
it
pretty
interesting
and
this
presentation
was
almost.
I
think
I
didn't
understand
much
to
be
very
honest,
but
I
saw
that
what
you
guys
were
trying
to
do.
D
A
A
D
Yes,
so
I'm
not
sure
how
that
would
help
me
with
this
these
projects
that
you're
working
on,
but
I
can
still
talk
a
little
bit
about
that
so
yeah
previously
I
had
worked
like
just
this
summer.
I
was
working
on
a
net
psd
organization
on
my
gsoc
project.
It
was
regarding
fuzzing
of
the
networking
stack
protocols
for
net
bst.
It
was
mainly
oriented
towards
the
networking
stage,
as
I
said,
and
quality
assurance
of
that.
D
So
my
work
was
around.
I
would
say
it
was
at
the
intersection
of
understanding
how
networking
systems
work
and-
and
that
was
one
part
rather
was
working
with
quite
a
bit
amount
of
kernel,
kernel
subsystems
and
some
of
the
apis
that
kernel
exposed
so
that
sort
of
work
I
was
working
on.
There
was
one
other.
I've
also
worked
previously
with
samsung
research
on
5g
related
research
domain.
So
my
work
was
on
the
mac
layer
of
5g,
where
I
was
supposed
to
work
on
optimizing
some
function
of
the
max
scheduler
that
they
were
working
with.