►
From YouTube: Antrea Community Meeting 12/18/2019
Description
Antrea Community Meeting, December 18th 2019
B
A
All
right,
so,
you
should
be
able
now
to
see
my
screen
with
the
country,
our
milestone
page
perfect.
So
these
what
we
have
at
the
moment
in
our
pillow
deferred
zero
point:
zero
point:
two
zero:
these
are
the
open
issues,
I'll
start
with
the
easy
part
assessing
the
close
dishes.
So
let's
review
them
to
make
sure
we
are
good,
so
we
have
considered
kubernetes.
Network
policy
are
done,
including
the
testing
part
that
was
missing
the
bugs
that
we
found
around
the
u.s.
network
policies
have
been
found.
A
B
B
A
D
A
We
to
the
default
deny
ok
and
I,
guess
that
we
don't
have
yet
to
me
any
mechanism
Oh
to
report
this
back
to
the
user,
but
maybe
it's
not
a
big
deal,
because
I
guess
in
the
next
release
we
will
support
named
ports,
alright
and
network
policy
in
kinda
clusters.
Then
this
one
is
a
Mac,
the
documentation
bug.
We
already
discussed
it
in
the
past
meetings.
A
A
One
has
been
implemented,
running
and
reagent
of
the
bull
Osterberg.
This
was
a
sort
of
regression
that
Coby
found
document
an
image
for
deploying
octant
Indian
reactant
plugin
we
closed
down
one
on
this
one.
We
already
knew
that
this
bug
was
going
to
be
fix
it
and
that
the
minimal
ant
CTL
is
being
merged.
Perfect,
okay,.
B
A
So
I
said
I'm
sorry,
my
screen
I
said
I
swear.
I
was
seeing
this
one
was
purple,
I
thought
it
was
merged.
Now
it's
it's
red,
you're
right,
so
open
issues
ability
to
run
kubernetes
conformance
test
in
an
automated
fashion.
This
doesn't
need
to
be
aligned
with
the
release
right,
but
we
want
to
make
sure
that
we
have
it
done
before
the
release.
Perhaps.
A
B
A
B
A
B
There
were
two
things:
I
mean
if
one
is
a
bit.
My
dad
I
only
need
a
review
yesterday
before
so
that
I
think
we
can
is
working
on
looking
at
my
review
comments,
and
the
second
thing
is
even
if
we
do
merge
this,
even
if
we
postpone
the
release
and
merges
the
only
comment
we
have
right
now
is
a
version
command.
So
it's
not
like
super
useful
to
the
user
so
make.
A
B
A
C
Not
from
my
side
further,
they
are
fail.
Merge
that
pull
request
loud
stratify
issues.
For
example,
we
are
fixing
a
parking
and
loitering
Ciotti,
so
we
can
remove
the
still
say
idea
were
actually
when
you
restart
aging
the
appeal
at
forever.
Yeah
there's
a
small
feature.
You
can
see
it's
a
feature
like
we
started,
Sivaji,
ie
and
st
peter
knows
that
one
column
urged
that.
C
A
A
A
That
exactly
I
was
thinking
for
the
changelog.
We
might
want
to
have
that
here.
Okay,
so
if
we
can
do
that,
just
to
make
sure
that
everything
is
included
in
the
changelog,
that
would
be
great
perfect
say
that
I
think
that
we
can
close
down
on
0.20.
We
need
to
review
the
latest
merged
PRS,
ensure
that
we
have
an
issue
for
all
of
them
so
that
they
were
going
to
change
long
push
out
of
the
CLI
to
the
next
release
and
then
I
guess
that
we
will
be
done
right.
There.
B
A
All
right
so
looking
at
the
features
in
at
0.10
I,
don't
think
honestly
that
we
have
enough
feedback
on
octant
usage
on
octant
integration
on
the
octant
plugin.
Sorry
to
promote
it
to
beta
I.
Think
that,
following
the
following,
the
process
that
sal
adopted
in
upstream
kubernetes
before
promoting
a
feature
to
beta,
we
will
need
to
have
some
sort
of
feedback
right
to
say.
Okay,
this
feature
is
being
used,
it's
probably
a
little
bit
mature
and
it
can
be.
It
can
be
released.
I
I
believe
that
octant
should
still
be
alpha.
B
A
Right,
the
monitoring
CRD
is
what
is
your
feedback
instead,
let's
say
that,
of
course,
we
don't
have
user
feedback
I'm,
not
expecting
user
feedback,
but
from
our
experience
now
we
have
been
using
this
as
here
these
for
a
couple
of
months.
Now
their
structure
is
a
pretty
much
steady.
So
here,
let's
say
that
I
am
I.
A
A
A
Okay,
so
we
promote
monitoring,
see
are
these
two
beta
and
for
kubernetes
network
policies.
I
know
that
we
finished
the
implementation,
but
I
don't
know
if
we
can
call
those
a
beta,
because
we
are
still
lacking
named
ports
and
because
we
are
just
now
integrating
them
into
the
CIP
in
the
end-to-end
testing
and
the
running
the
conformance
tests.
Do
we
want
to
declare
them
bitter
now?
Do
we
want
to
wait
for
another
release?
A
A
B
A
A
A
A
A
B
A
A
The
CLI,
of
course,
okay,
aqua
and,
of
course,
the
CLI,
then
anything
else
that
we
were
mean.
We
really
needed
to
have
four
zero.
Three
zero
among
the
features,
because
we
had
I
noticed
that
in
the
past
week
there
were
a
few
activities
in
terms
of
announcement
proposals,
so
I
saw
that
some
were
added
from
different
people.
C
C
I
think
for
that
one
there
are
two
pathways
for
standard
entry.
Our
department
in
camp
ran-
probably
in
some
case
we
don't
do
encapsulation,
removing
other
notes
on
the
same
subject.
In
other
case
I
think
he
made
a
proposal
also
for
the
public
release
talking
to
Microsoft,
so
ghanchakkar
unique
a
and
we
wanted
to
his
policy
amendment.
C
I'm
not
sure
it's
much
too
high
for
the
other
three
or
not.
For
since
we
are
talking
to
Microsoft.
Probably
we
want
to
make
some
progress,
maybe
February
or
sometime.
We
should
have
a
motion
for
that,
and
also
for
is
why
I
think
we
should
look
at
that
and
then
probably
discuss
what's
right
interface
to
configure
deep
in
the
modes
since
we
have
Monica
Melton
are
like
opening
mode
IPSec
encryption,
you.
A
C
Okay,
which
one
specifically
for
actually
for
now,
we
are
many
talking
to
Microsoft
for
eks3.
You
want
to
come
all
the
way
to
policy.
Only
for
this
a
UV
light
network
for
connectivity.
E
C
You
say
I
think
only
son
is
right.
I
thought
that
when
he
made
his
proposed
icing,
he
he's
thinking
about
two
cases.
C
They
are
same
in
the
finale
Dennis
and
one
case
that
we
do
policy
on
me
another
case
we
do
routing
a
PD
notes
for
coastal
traffic.
They
are
similar
in
a
sense.
In
both
cases
we
don't
oh
great,
oh
great
following
so
probably
you
can
share
some
code
and
implementation
for
the
other
either
they
are
not
either
listen.
C
A
A
Let's
take
you
know
flying
perhaps
to
the
mailing
list,
which
is
a
tool
that
we
should
start
really
using
and
and
maybe
maybe
we
can
flush
out
a
little
bit
more.
What
we
need
to
do
there
and
figure
out
what
could
be
a
possible
deliverable
four,
zero,
three
zero
in
terms
of
the
announcement
proposals.
B
B
Basically,
basically,
the
request
was
to
use
annotations,
which
I
think
is
a
note
action
in
OBS
to
like
annotate
flows
and
make
it
easier
to
debug,
but
I
mean
that's
not
a
very
detailed,
like
feature
request
here.
So
that
is
right.
You
said
mentioned:
I
mean
identify
owner,
so
we
already
do
that
using
cookies,
we
have
a
pending
PRS,
which
is,
which
is
gonna,
be
merged
soon,
and
there
is
a
documentation
PR
which
is
gonna,
be
merge,
which
should
make
it
easier
to
understand
it
froze
and
the
note
action.
B
C
A
Okay,
so
we
wait
for
more
details,
because
I
initially
I
told
that
okay,
it
might
be
cool
to
know
notate
flows
with
the
correspond,
the
corresponding
the
network
policy
UID
in
kubernetes.
That
could
be
a
nice
idea,
but
the
proposal
itself
I
mean
it's
just
a
line.
So
it's
easy
to
parse
what
it
really
means
it
looked
like.
A
It
was
advocating
for
a
mechanism
to
expose
in
Andrea
to
notate
the
underlying
flows,
which
to
me
seems
a
little
bit
difficult
to
understand,
but
anyway,
so
we'll
we'll
wait
for
an
update
from
sure
and
we'll
see
what
a
Louie
disfavored
proposal,
the
other
one
that
I
wanted
to
talk
to
you
about.
Is
this
request
this
announcement
proposal
from
je
about
Prometheus
metrics
for
obvious
performance
and
routes?
So
the
je
has
a
very
simple
request
to
be
able
an
integrator,
CNI
performance
over
time
with
other
dashboards
in
a
KBS
environment
by
a
Prometheus.
A
So
I
know
that
a
copy
has
been
looking
into
this
as
well.
So
maybe
it
might
be
nice
to
see
what
we
can
do
in
a
way
that
we
can
roll
this
integration
progressively
and
possibly
deliver
something.
Even
some
just
some
tiny
bit
based
on
Jeff
just
from
from
zero
point
three,
so
is
this
something
that
you
deem
it
could
be
interesting
for
zero
point
three
or
maybe
these
kind
of
integrations
are
probably
it's
probably
a
little
bit
earlier
for
these
kind
of
integrations
and
we
will
still
maybe
more
focus
on
the
core
functionalities.
C
E
The
only
issue
I
would
bring
up
on
this.
One
is,
if
we're
talking
about
different
implementations
of
the
of
the
data
path
like
we
just
got
off
the
phone.
You
know,
Mellanox
is
interested
right
in
contributing,
or
you
know
other
folks
do
we
want
to
do.
We
want
to
abstract
out
the
taxonomy
of
like
what
types
of
metric
I
have
a
proposal
that
talks
about
what
we
want,
those
metrics
to
look
like
right.
So
there's
a
common
there's,
a
common
API
for
metrics,
no
matter
what
the
underlying
source
of
those
metrics
are.
A
I
agree
on
that,
and
indeed
from
other
conversations
that
we
had
in
the
various
channels
that
we'll
be
using
there
are,
there
are
two
things
that
are
relevant
to
this
kind
of
work.
One
are
the
metrics
that
we
want
to
collect,
defining
a
set
of
metrics
that
matter,
no
matter
what
we
are
using
in
the
backend,
and
the
second
is
then
defining
the
architecture
for
exporting
these
metrics
in
an
efficient
way,
so
that,
at
the
end
of
the
day,
then
end
up
into
into
parameters,
and
we
can
do
this
to
discussions
at
the
same
time.
D
A
Have
to
define
the
matrix
before
defining
the
architecture
in
terms
of
a
matrix.
If
we
look
at
typically
what
other
we
see
a
nice,
so
an
additional
solutions,
or,
generally
speaking,
other
infrastructure
software
reporting
to
Prometheus.
We
are
there
general
report,
the
information
about
the
runtime
state
of
the
system,
which
one
you
might
usually
think
about
it.
Let's
report
network
performance
statistics:
let's
report
packet
processing
statistics.
A
G
A
A
Okay,
so
let's
maybe,
let's
see
from
an
architectural
perspective,
I
don't
think
I
don't
know
if
we
want
to
go
into
the
deeper
dive
discussion
now,
because
I'm
pretty
sure
that
there
are
other
topics
that
we
want
to
discuss.
But
perhaps
one
thing
that
we
may
want
to
agree
upon
is
whether
we
want
to
have
entire
controller
to
be
centralized
collector
of
information
or
of
each
agent
separately
report
matrix.
There
are
pros
and
cons
in
both
approaches.
I
think
a
copy
that
you
already
looked
at
those
right
in
the
past.
Yeah.
A
A
The
point
I
want
to
be
honest.
My
only
point
is
that
I
want
to
keep
it
as
a
toggle
as
possible
from
unfair
development.
Basically,
I
don't
want
to
have
pieces
of
anterior
controller,
which
are
entirely
different
are
devoted
to
collecting
metrics
from
the
agents.
In
my
opinion,
if
we
want
to
have
a
centralized
controller,
then
we
may
want
to
have
a
dedicated,
a
dedicated
piece
of
software,
a
dedicated
container
that
maybe
can
run
as
a
part
of
the
entire
controller
deployment.
A
D
A
They
will,
they
will
have
something
else
to
collect
metrics
and
maybe
they
will.
They
won't
give
a
damn
about
from
ages
anyway.
So
a
good
point,
I
believe.
Let's
then,
let's
then
now
discuss
our
metrics
will
impact
the
probability,
the
architecture-
and
this
is
why
I
was
making
a
difference
between
the
metrics
that
are
about
the
health
of
the
system
and
the
metrics
that
are
about
the
dynamics
of
the
system.
So
sorry,
I.
A
Do
you
see
the
sorry?
Do
you
think
if
that
code
should
be
part
of
the
controller
agent
or
separate?
Yes?
So,
oh
you
mean
if
the
code
should
be
part
of
the
ant
reagent?
Yes,
I
think
you
know.
If
we
need
the
agent
matrix,
it's
one
way
one
finger.
If
we
need
OVS
matrix,
then
it
can
be
definitely
separate.
It
could
be
something
that
reads
from
obvious
and
sends
statistics
to
parameters
if
we
have
to
collect
the
agent
matrix
instead
instead
and
therefore
we
need
to
get
stuff.
A
That
is
only
on
the
agent,
it
could
be
the
agent
itself,
but
another
aspect
that
this
is
just
an
just
freaking
a
lot
because
I
have
not
validated.
This
is
whether
the
monitoring
CRD
will
be
helpful
in
this
case,
because
maybe
the
agent
metrics
are
already
there
in
the
monitoring
CRD
and
the
debt
CRD.
He
can
be
always
already
updated
periodically,
and
so
it
would
be
just
a
matter
of
having
something
that
exports,
that
data
into
parameters.
A
To
avoid
I
want
to
make
these
writing,
as
least
if
we
can
manage
to
write
zero
lines
of
code
and
everything's
working
I'll
be
perfect.
We
can
do.
We
cannot
do
that
with
zero
lines
of
code,
of
course,
but
I
would
like
to
keep
the
finger
as
orthogonal
as
possible,
because
at
the
end
of
the
day,
if
we
have
already
this
information
in
the
monitoring
CRD
and
we
want
to
export
the
same
information
into
kubernetes
into
premier-
sorry
doing
additional
logic
into
the
agent.
A
C
A
Right
I
mean
it
all
depends
on
the
nature
of
the
metric.
I
think
that
this
mechanism
of
level
exporting
CR
did
it
and
to
Prometheus
works.
If
the
data
are
three
much
static,
like
you
know,
they
are
updated,
like
with
the
frequency
of
minutes.
If
we
are
talking
about
the
data,
it
gets
a
pretty.
You
would
have
more
frequently
like
a
few
times.
A
B
A
G
A
B
A
A
Actually,
I
will
commit
to
let's
say
to
using
Prometheus
for
metastatic
data
that
we
define
the
define
and
static
and
commit
to
that
4:03
or
zero
for
at
least
four
to
have
something
to
get
started
and
I'm
in
the
meanwhile
define,
let's
say
which
metrics
rapidly-changing
metrics
we
would
like
to
collect
and
then
see
if
promise
is
still
good
or
if
we
need
to
implement
some
other
Lecter
at
the
end
of
the
day.
Let's
we
still
want
to
push
this
data
into
bromius.
A
What
changes
is
the
collection
of
the
collection
mechanism
that
we
wanted
to
that
we
want
to
implement,
and-
and
you
know
this
is
in
my
opinion-
because
at
the
end
of
the
day,
users
are
not
going
to
have
45
different
dashboards,
they're,
probably
avid
it's
just
a
graph
on
a
dashboard
that
is
a
populated
from
that
data
collected
by
parameters
at
the
end
of
the
day.
The
efficiency
and
the
scale
depends
on
how
efficiently
we
can
push
this
data
into
parameters
and
call
another
thing
that
I,
don't
remember
and
keeping
you
honest
here.
A
G
A
G
Offers
like
two
operation
modes,
one
of
them
is
where
Prometheus
is
following
the
the
pulling
the
the
metrics
from
from
the
app
from
whatever
the
service.
The
other
one
is
where
Prometheus
is
running
this
some
listener
and
the
the
the
app
is
responsible
to
push
the
data
towards
Prometheus.
They
discourage
using
this.
A
A
All
right,
so,
let's
agree
that
we
will
use
it
for
collecting
a
sort
of
static,
let's
say
static
data,
and
we
will
start
looking
at
the
monetary
since
erd,
for
defining
those
metrics
and
for
those
metrics.
We
will
implement
the
interface
where
the
agent
exposes
an
end
point.
It
could
be
the
agent
the
andrea
agent,
or
it
could
be
something
else,
but
in
maybe
in
this
case
since
is
very
simple.
It
could
be.
A
G
E
A
C
E
In
in
this
whole
discussion,
I
think
one
key
thing:
we
need
to
separate
not
only
what
static
and
what
state
of
the
system,
but
also
what
we're
good
with
receiving
a
sample
of
the
data
versus
where
we
need
every
capture
of
the
of
the
metrics
data.
A
lot
of
the
stuff
that's
been
done
with
Prometheus
and
calico
is
based
on
sampling
right.
So
the
the
monitoring
is
a
sampled
frequency.
So
so
the
scraping
can
be
adjusted.
You
know
based
on
scale
but
you're
still
just
getting
a
sampled
view.
C
B
A
A
The
second
step
will
be
to
consider
a
reliable
framework
for
exporting
than
extremely
dynamic
matrix
and-
and
this
will
completely
say
the
metric
export
part.
Then
the
cool
thing
which
could
be
a
long
term
shot
will
be,
would
be
more
about
troubleshooting
than
metric
collection,
and
it
will
be
how
to
integrate
all
the
other
work
that
we
are
already
planning
around.
Try
OVS
troubleshooting
into
the
whole
the
whole
free
ecosystem
of
observability
and
open
tracing.
This
might
or
might
not
be
feasible.
So
this
is
a
very
long
short
at
the
moment.
B
A
B
A
C
A
C
C
C
A
So
let's
say
that
at
the
moment
we
can
start
creating
an
initial
zero
point:
three
payload
with
the
CLI
name,
the
policy
support
named
port
support
for
network
policies,
and
then
we
put
we
put
something
for
Prometheus
in
scope
and
the
IPSec
tunnel
feature.
So
this
would
be
the
initial
period
for
zero
point.
3
under
on
did
I
forgot.
Anything
I
know.
B
A
Itself:
okay,
perfect,
so
we'll
add
that
to
the
to
the
list
too,
and
so
I
guess
that
this
concludes
the
discussion
around
0.3.
We
have
10
Minister,
Lee
Leslie
left
in
the
meeting
and
I
just
would
like
to
know
from
the
attendees.
If
there
is
a
any
bug
that
deserves
discussion
or
if
everything
is
under
control,
I
didn't
see
any
high
profile
discussion
around
bugs,
so
I
guess
there's
nothing
that
needs
to
be
discussed,
but
I
just
wanted
your
feedback
to.
B
A
D
D
Yeah
so
I
wanted
to
ask
about
the
name
put:
is
that
today,
what
we
do,
or
rather
sorry
the
support
that
you
know
if
you
want
to
have
a
name
port
in
network
policy,
and
there
are
multiple
boards
which
are
backing
the
same
name
forth,
but
by
different
port
numbers.
The
support
for
that
will
be
a
large
effort
and
also,
you
know,
require
some
changes
in
our
grouping.
I
have
some
proposals?
I
will
send
out
email
on
that
one.
D
The
other
thing
that
you
know
Gingin
and
I
offline
discussed
about
this
was
like
to
maybe
first
start
with
the
support
in
which
the
name
for
resolve
to
a
single
port
number.
So
that
would
be
like
you
know
how
that
can
be
done
within
a
week
and
I
also
noticed
that
the
community
then
to
enter
network
policy
in
conformance
test.
They
also
tested
in
the
same
way,
that
is
they
create
policies
when
the
import
and
pause
which
which
expose
that
port
on
a
single
port.
D
A
You
know
my
opinion
is
that
if
we
implement
these
format
with
a
single
port-
and
you
know
it
can
be
done
in
a
week-
it
is
fine.
But
then,
if
we
have
to
rewrite
everything
for
supporting
the
full
feature,
then
maybe
it's
not
the
case.
So
if
you
have
already
some
proposals
for
the
design,
maybe
let's
discuss
them
over
the
over
the
meaning
list.
Perhaps
some
member
from
the
community
might
step
up
also
to
help
with
the
implementation
and
review
perhaps
fully
and
which
you
know
it
will
be
great.
A
Honestly,
I
don't
want
I'm
I'm,
not
too
super
keen
in
implementing
the
solution.
That
is
just
good
enough
for
passing
the
for
passing
the
conformance
test.
The
reason
is
that
we
don't
know
how
we
users
are
going
to
use
it,
and
what
we
know
from
our
experience
is
that
users
every
little
habit
of
using
your
software
exactly
in
the
way
that
you
were
not
expecting
to
a.
B
C
A
A
A
E
On
the
website,
it
is
gonna,
be
based
on
Jekyll
and
I.
Think
that
we
can
have
the
markdown
translated
into
you
know.
Basically,
pull
have
the
documentation
pulled
from
github
right,
so
I
actually
brought
that
up
and
and
was
pretty
adamant
that
we
only
have
one
style
markdown
right
that
we
are
going
to
support
for
the
documentation.
That
way,
it's
the
same,
if
you're,
looking
at
it
from
the
repo
or
from
the
website,
and
so
what
we'll
do
is
just
set
up
a
import
capability
right
to
bring
it
into
the
formatting
of
the
website.
B
E
Absolutely
so
there
will
be
a
release,
a
build
and
release
process
right
for
the
website.
I
mean
it's
a
it's
a
statically
generated
site
using
Jekyll,
and
so
as
we
release
different
versions
of
the
website,
we'll
want
to
make
sure
to
be
able
to
toggle
a
collection
of
docs
that
were
related
to
a
particular
tag
or
okay.
B
What
my
question
was
because
I've
seen
that
in
some
projects
on
github
have
like
multiple
folders
inside
of
the
github
repository
with
like
T
1.1,
a
1.2
be
103,
but
if
we
build
the
website
statically
when
we
do
an
entry,
a
release
and
you
mean
for
the
documentation
at
that
point
and
I
guess
we
don't
really
need
to
do
that,
because
you
would
just
look
at
the
documentation.
What's.
E
A
E
A
E
D
A
Not
yet
I
deliberately
did
not
decide
it,
because
I
think
that
maybe
we
won't
want
to
have.
We
need
to
take
into
account
also
the
holiday
break.
So
I
was
thinking
that,
maybe
in
the
next
few
days
there
would
be
very
little
very
little
activity
as
I
believe
that
next
week,
at
least
in
the
Western
Hemisphere,
most
people
will
be
off.
So
maybe
we
can
set
a
date
after
Christmas.
Perhaps
if
that's
okay
for
you,
otherwise
we
can
try
a
tentative
date
now.
A
There
would
then
was
going
to
be
my
parting,
my
party
in
communication,
so
I'm,
sorry
so
next
week,
I
think
everyone
accepted
Coby
will
be
off
and
and
I
instead
and
therefore
would
cancel
the
meeting
of
Wednesday
December,
25th
and
I.
The
other
Wednesday,
which
is
January
1st
I,
think
it's
the
only
day
in
the
year
where
everybody
except
North
Korea
works,
doesn't
work
so
we'll
take
off
that
other
one.