►
From YouTube: Antrea Community Meeting 06/21/2022
Description
Antrea Community Meeting, June 21st 2022
A
A
A
We
don't
have
any
pre-scheduled
meeting
in
today's
agenda.
So
today
it's
going
to
be
purely
open
discussion.
I
don't
know
if
any
team
member
has
a
any
topic
regarding
features
bugs
or
anything
else
that
they
would
like
to
bring
up.
If
you
have
any
topic
to
discuss
for
today,
please
go
ahead.
B
I
just
want
to
mention
one
thing
in
recent
releases:
I
I
saw
that
some
issues
are
related
to
interaction
of
futures,
for
example
egress
and
anthropology,
and
perhaps
there
are
some
other
conflicts
between
other
futures.
So
I'm
thinking
about
refactoring
the
current
end-to-end
test
on
kind
of
platforms,
so
that
we
can
test
all
future
tests.
B
So
previously
we
have
three
three
specific
tests:
we
one
with
entry
process,
disabled
and
the
one
with
pro
entry
process
and
the
process
oh
enable
and
the
last
one
with
narrow
policy
antenna
process,
disabled
so
and
and
for
other
test
features
like
the
service
external
ip.
We
use
another
approach.
We
we
just
test
this
feature
in
every
inherit
builds,
but
the
the
test
will
mutate
the
configuration
and
then
this
test
this
test
will
be
tested
in
all.
B
This
is
the
case.
We're
testing
all
builds
and
also
traffic
control
is
tested
in
this
way.
So
there
are
two
styles.
One
is
create
a
new
build
and
specific
for
this
test,
but
this
will
generally
will
produce
some
redundancy,
because
many
cases
that
are
not
related
to
this
feature
are
tested
repeated
repeatedly.
B
B
So
this
tip
so
features
like
search
external
ip
and
traffic
control,
which
are
not
enabled
by
default,
will
be
tested
in
this
one
and
also,
if
they,
if
they
have
been
graduated
to
beta,
they
will
also
be
tested
in
the
made.
The
the
original
core
build
this
without
any
update
to
the.
B
Future
gate
configuration
so
and
and
for
every
future
we
will
have
tested
at
least
once
in
this,
build
when
to
to
see
when
they
are
disabled.
The
other
functions
will
not
be
impacted
so
that
that
was
that's.
The
thing
I
want
to
mention
in
this
meeting
so
for
in
the
future
and
for
futures
like
need
some
specific
environment
configuration,
for
example,
multicast.
B
I'm
thinking
that
maybe
it
should
also
be
tested
in
in
this
field.
Build,
I
see,
features
like
modcast
just
need
one
extra
physical
interface,
and
this
can
also
be
done
by
updating
the
kind
test
bed
set
up
in
script
to
to
just
by
by
just
adding
one
step
to
attaching
another
virtual
interface
to
all
kind
of
nodes.
A
Generally
speaking,
I
believe
that
your
idea
makes
a
lot
of
sense,
and
I
wonder
if
our
reason
for
having
a
end-to-end
tests
without
proxy
and
with
the
proxy
is
just
historical
or
whether
there
is
also
some
other
reason
for
you
know
for
the
old
way
for
the
current
way
of
doing
testing.
A
B
A
Yeah
then
I
I
have
another
question
on
this:
if
you
can
you
go
through
service
external,
like
ptes2.go,
because
you
should
do
the
current
code
is
enabling
the
feature
gate
on
demand.
Let's
say
for
running
this
test,
but
do
we
also
disable
it
when
the
test
completes
or
do
we
keep
it
enabled
for
the
rest
of
the
test.
B
B
A
That's
right
so
I
mean
I
think
that
this
is
a
surely
a
good
improvement.
The
only
thing
that
I
will
check
is
that
if
there
is
a
if
there
is
any
condition
that,
when
testing
with
all
the
feature
gates
enabled
would
lead
to
some
tests
being
always
skipped,
for
instance,
I'm
looking
for
example,
let's
look
at
this
code,
it
will
be
skipped
if
untreated
test.
So
this
means
that
if
also
the
I
entry
ipam
feature
feature
is
enabled,
then
this
test
will
always
be
skipped.
B
That's
this
is
a
little
different.
This
he'd
use
this
name,
but
it
actually
checks
another
flag,
because
this
this
is
a
history
issue
and
ipam
means
the
flex
flexible,
ipam
test.
It
will
only
be
set
when
the
test
is
wrong.
On
a
specific
test
bed
with.
B
A
Is
are
there
other
questions
regarding
the
proposed
the
the
work
that
shawn
is
proposing
here.
A
A
So
thanks
thanks
a
lot
for
bringing
this
up
anything
else
from
the
team
for
today.
A
All
right,
so,
let's
go
just
with
the
announcements.
As
we
know,
last
week
we
released
the
andrea
1.7
you
can.
You
can
check
the
changelog
and
release
notes
for
all
the
new
features
that
have
been
included,
and
I
just
wanted
to
mention
that
now
we
have.
This
is
the
first
release
from
the
tear
repository
which,
which
provides
all
the
network
network
flow,
vcb
features
which
are
provided
with
andrea.
A
A
You
can
consume
network
flow
visibility
also
from
the
anterior
repository,
but
that
will
be
the
same
feature
set
as
anterior
1.6
for
all
the
new
features
that
we've
added
in
this
release
cycle
they're
only
available
from
the
tier
repository
and
network
flow
visibility
features
will
be
removed
from
the
entry
repository
during
the
andrea
1.8
release
cycle
and
from
that
point
on,
they
will
be
exclusively
consumed
from
the
tier
repository,
and
that's
that's
pretty
much
all
yeah.
You
know,
then
you
can
you
can
share.
A
C
C
Documenting
course
clusters,
but
listen
we
talk
about
any
way
to
virtualize
the
flows.
I
mean
harvest
dashboard
that
can
show
flows
in
multiple
clusters
and
then
maybe
somewhere.
Even
we
don't
do
you
know
we
would
if
we
don't
run
a
central
electric
solution
and
but
some
way
to
you
know
cause
a
individual
cluster
to
do
project
writing
for
a
single
cluster.
A
It's
it's
not
easy
and
the
problem.
The
problem
with
this
approach
is
that
we
will
need
to
have
the
grafana
dashboard
connect
to
every
sort
of
selector
of
the
cluster
it
wants
to
connect
to,
because
the
idea
basically
is.
There
is
no
real.
Let's
say
that
the
unfair
flow
visibility
or
tia
doesn't
have
any
explicit
knowledge
of
multi-cluster.
So
there's
no
central
data
storage
for
flows
belonging
to
multiple
clusters,
but
each
cluster
has
its
own
database
storing
flow
of
data,
then
from
the
leader
cluster.
A
A
With
the
dashboard
is
populated
with
the
data
from
the
selected
cluster,
then
you
know,
for
instance,
then
you
switch
to
another
cluster
and
then
you
have
the
same
dashboard,
which
is
instead
populated
with
data
from
another
cluster.
I
think
that
that's
your
that's
the
requirement
that
you're
expressing
is
that
correct.
A
No,
I'm
just
saying
that,
to
the
best
of
my
knowledge,
I
do
not
know
if
these
can
be
implemented
in
grafana
without
having
to
reconfigure
the
graphanapod
itself.
This
is
something
that
perhaps
we
can
check
with
the
team
working
on
flow
visibility
to
understand
whether
this
can
be
done
or
not.
C
So
yeah
I
I
don't
mean
we
need
to
design
here
and
just
want
to
check.
What's
your
soft
skill.
B
C
Definitely
probably
we
can
have
the
team
to
spend
some
time
to
invest.
C
You
must
get
different
options
here
and
I've
heard
from
you
either
we
have
a
graph
or
not
to
you
know,
prove
information
from
different
from
their
stores
in
different
clusters,
or
maybe
we
also,
maybe
you
can
also
consider
to
run
click
house
in
a
central
class
yeah.
I
think
engineer
probably
we
said
we
want
to
keep
the
data
store
and
the
drug
container
in
single
cluster.
A
Yeah
that
that's
that's
originally,
that's
that's
exactly
what
we
wanted
to
have.
We
wanted
to
have
the
data
stored
in
a
single
cluster.
The
thing
is
that
doing
keeping
the
data
stored
in
a
single
cluster
will.
Surely
it
has
some
skill
concerns
because
you
know
now
we
will.
B
A
We
will
have
multiple
flow
aggregators
writing
in
the
same
clinical
systems.
Then
we
will
need
we
will
need.
We
will
surely
need
some
database
schema
changes
to
take
into
account
the
the
fact
that
every
flow
also
has
a
cluster
identity.
So
that's
something
else
that
we
need
to
add
to
the
data
schema.
I
mean
that
would
be
probably
relatively
easy,
but
at
the
moment
the
main
concern
is
about
the
scale
implications
of
having
a
number
of
clusters
writing
in
a
database.
A
Okay,
yeah,
let's
I'll,
find
let's,
let's
find
out
if
we
can
have
a
solution
where
we
can
see
data
on-
let's
say
cluster
by
cluster,
by
switching
by
pointing
graphana
to
different
clickhouse
server.
Otherwise,
if
that's
not
feasible,
then
we'll
have
to
revert
about
thinking
the
solution
about
about
having
a
single
database
for
all
the
clusters.
A
All
right-
and
so
I
guess
this
can
be
probably
a
short
meeting
for
today,
and
I
would
like
to
thank
you
for
joining
this
call,
and
we
will
have
our
next
meeting
on
wednesday
july,
the
6th,
not
tuesday
july
the
5th
as
usual,
because,
again
monday
july,
the
4th
is
a
public
holiday
in
the
united
states.
A
So
there
will
be
an
interesting
presentation
to
to
here-
and
I
guess
that's
all
for
today,
so
I
wish
everyone
a
good
a
good
afternoon
a
good
morning
or
a
good
night.