►
From YouTube: Antrea Community Meting 05/10/2021
Description
Antrea Community Meeting, May 10th 2021
A
So
this
is
the
post
cubicle
instance
for
those
of
you
that
have
had
a
chance
to
attend
the
cubicle
in
europe
and
well.
The
main
news,
as
a
probably
you
know,
is
that
we
have.
There
are
some
project
changes
in
andrea,
some
rather
important
changes.
I
would
like
to
say,
but
I
will
probably
let
anton
go
through
these
changes.
B
Hi
thanks
salvatore
hi
everyone,
so
yeah
we're,
as
as
we've
announced
on
the
slack
channel,
we're
happy
to
announce
that
entry
has
been
accepted
as
a
cncf
sandbox
project.
So
I
mean
obviously
I
think
that
this
community
is.
The
community
has
been
aware
of
the
fact
that
the
entry
applied
as
uncertain
brock's
project-
and
I
think
the
acceptance
was
about
a
week
ago,
so
we're
I
think
I
can
say
that
we're
all
excited
about
this
change
and
yeah.
B
We
hope
it
will
bring
more
members
to
to
the
entire
community
and
more
users
as
well
with
the
extra
visibilities
that
being
a
sandbox
project
gives
us,
because,
worse
and
box
project
will
show
up
on
the
cncf
pages
and
we'll
also
have
some
office
hours
time
at
at
the
future.
Kubecons,
for
example,
so
yeah
I'm
very
excited
about
this.
B
And,
as
some
of
you
may
be
aware,
we
had
a
vote
on
the
slack
channel
in
the
last
week
or
so
ever
since
we
got
notified
that
were
accepted
into
cncf
sandbox
and
there
were
two
choices:
project
entria
and
entry
dash,
io
entry
io
for
the
names,
because
we've
had
those
names
reserved
on
github
for
a
while
now
and
it
seems
that
entry
io
got
three
times
as
many
votes.
So,
despite
salvatore
being
strongly
opposed
to
having
a
dash
in
the
github
organization,
name,
andrea
will
move
to
entry
dash
io.
A
Indeed,
now
I
have
to
reorganize
the
keys
of
my
keyboard
because
reaching
out
to
the
dash
with
my
little
finger
is
very
annoying
and
it
costs
me
a
lot
of
energy,
so
I'm
going
to
reorganize
the
keyboard,
my
keyboard,
for
that
I
mean
jokes
aside,
it's
been
a
great
news
for
the
project,
great
news
and
it's
probably
a
very
important
milestone
in
the
life.
So
in
the
life
of
the
project,
much
more
important,
I
will
say
that
the
1.0
release,
so
it's
truly
something
that
changes.
A
B
Oh
so,
by
becoming
a
cncf
project,
so
we
have
access
to
a
few
dashboards,
devstats
dashboard,
which
gives
us
information
about
the
health
of
the
project,
so
a
very
important
metric,
and
I
think
it's
good
that
you
bring
it
up.
Actually,
I
wanted
to
say
something
about
this.
A
very
good
important
metric
for
else
of
the
project
is
pr
pull
request,
engagement
time.
So
when
a
contributor,
especially
a
new
contributor,
opens
a
pull
request.
B
B
So
I
think
this
is
this
is
great
and
I
think
we
should
keep
keep
doing
what
we've
been
doing
and
even,
if
possible,
try
to
reduce
that
time
and
like
always,
make
sure
that
we
leave
a
review
or
a
comment
on
a
on
a
on
a
pr
when
it's
a
when
it's
open,
especially
by
a
new
contributor,
because
that's
really
what
helps
boost
contribution.
I
think
and
that's
why
the
cncf
is
actually
tracking
this.
So
I
think
our
90th
percentile
or
something
is,
is
five
days,
so
we
should
try
to
keep
that.
B
We
should
try
to
keep
that
time
low
and
see
if
we
can
avoid
leaving
prs
open
for
five
days
without
without
leaving
any
comments,
and
so
as
far
as
dashboards,
we
can
also
see
which
companies
are
contributing
to
to
the
project,
and
sometimes
they
try
to
determine
the
affiliation
of
each
developer
based
on
their
github
profile.
I
believe
and
github
history,
but
sometimes
they
get
it
wrong.
So
I
invite
you
to
look
at
your
affiliation
because
I
actually
got
an
email
that
it
should
have
been
updated
for
all
entry
contributors.
B
I
I
didn't
check,
but
you
can
check
your
affiliation
on
that
github
repository
and
if
it's
wrong,
you
can
open
a
pull
request
to
update
your
affiliation.
So
in
my
case
my
affiliation
was
wrong.
It
was
showing
as
my
previous
employer
and
because
so
many
contributors
that
had
missing
affiliation
information.
It
was
showing
my
previous
employer
as
the
main
contributor
to
entry,
which
obviously
is
not
the
case.
So
I
updated
my
affiliation.
I
think
that
the
person.
B
B
And
in
the
chat
I'll,
also
post
a
post,
a
link
to
the
github
issue
opened
by
the
cncf
to
to
keep
track
of
entry
as
on
boarding.
So
there
are
a
few
items
that
we
have
to
take
care
of
in
in
the
upcoming
weeks,
and
the
main
item
was
is
moving
to
a
new
github
organization.
So
once
that
item
is
is
taken
care
of,
I
think
the
rest
of
the
the
rest
of
the
items
are
going
to
be
pretty
pretty
quick
and
pretty
easy.
B
B
Oh,
I
guess
something
that
may
be
of
important
is.
I
believe
that
the
cla
needs
to
change
instead
of
having
a
vmware
cla
for
the
repo
we're
gonna
have
a
cnc
fcla.
So
I
expect
that
all
contributors,
including
the
ones
employed
by
vmware,
may
have
to
to
sign
the
cst
fcla,
or
maybe
your
your
company
already
has
like
an
umbrella
cla
for
for
the
cncf,
so
just
something
that
may
come
up
in
the
future
for
your
request.
B
They
have
both
a
dco
and
a
cla,
so
I
need
to
check
if
we
have
the
choice,
I
think
we'll
probably
just
get
a
dco,
because
then
no
one
needs
to
sign
anything.
You
just
need
to
ensure
that
you
sign
your
comments,
so
it
will
also
be
a
small
change
for
people
contributing
to
andrea,
but
it's
pretty
easy
change
right.
It's
just
when
you
git
commit
on
the
command
line.
You
have
to
add
an
extra
parameter.
A
B
B
B
A
B
A
B
All
of
this
needs
to
happen
within
like
the
next
months,
basically
four
weeks
to
six
weeks,
so
I'm
hoping
that
we
can
complete
the
github
move
by
the
end
of
this
week,
since
it
shouldn't
be
disruptive
to
to
people
too
much,
except
for
one
part
that
I
want
to
to
cover
in
a
second
yeah.
I'm
hoping
we
can
take
care
of
it
quickly,
because
after
that,
we
can
like
update
the
links
and
everything
and
and
and
move
on
from.
B
Sorry
about
ceip,
no,
the
ci
would
impact
see.
I
I
don't
think
so,
because
when
you
clone,
I
mean
something:
may
break
we'll
see
that
when
you
clone
the
repository,
it
will
still
be
able
to
clone
it
using
the
old,
the
old
address.
So
obviously,
over
time.
We
should
try
to
update
everything
to
use
the
new
the
new
web
uri,
but
we
can
take
our
time
doing
so
and
on
on
the,
I
think
we
also
have
like
some
web
hooks.
B
So
hopefully
you
guys
can
see
my
my
screen
so
as
part
of
that
move
to
a
new
github
organization,
we
should
also
update
our
our
go
module
import
path.
So
I
was
kind
of
thinking
that,
because
of
the
github
redirects,
probably
things
should
kind
of
like
keep
working,
even
if
we
keep
using
the
old
import
pass.
But
I
think,
as
part
of
this
move,
obviously
we're
moving
away
from
vmware
attend
the
organization.
B
So
here
this
would
be
the
new
import
path
or
we
can
switch
to
using
what
what
is
referred
to
in
the
golang
word
as
a
vanity
import
path.
So,
instead
of
using
the
one
which
is
kind
of
like
auto-generated,
based
on
your
github
repository,
you
can
choose
to
use
an
import
pass
based
on
a
domain
name
that
you
own.
So
in
your
case
we
use
entry.io.
B
So
instead
of
github.com.uselescentria,
we
could
switch
to
using
just
entry
dash
io
or
entry
dash,
sorry,
just
entry,
dot,
io
or
entry
dot,
io,
slash
entry
and,
if
I
mean
all
and
almost
say
all,
but
most
popular
cloud
native
projects,
things
like
kubernetes,
okay
native
I
mean
there
are
many
of
them
use
like
a
vanity
import
path
based
on
the
domain
name
of
their
website.
So
for
kubernetes,
it's
communities
dash.
I
o
right.
So
you
have
communities,
dash,
io,
slash
api
machinery
or
slash
api
server,
for
example.
B
B
B
I
think
that's
mostly
a
moot
point,
and
I
talked
to
a
few
people
about
this
and
I
don't
believe
it's
a
significant
concern
not
to
mention
anyway,
that
few
people
import
entry
out
io
in
their
packages
right.
That's
not
how
you
consume
entry.
You
consume
entry
as
a
docker
container
as
a
binary,
but
you
don't
like
it's
not
a
library,
typically,
that
you're
gonna
use
to
you're
gonna
use
as
a
module
in
other
projects,
and
the
second
objection
would
be
like
availability,
because
it
depends
on
being
able
to
to
query
some
metadata
information
from
anturia.io.
B
B
So
both
of
those
drawbacks
may
not
be
significant,
as
you
can
see
here
originally,
I
was
a
bit
against
leaning
against
using
a
vanity
url,
because
I
felt
it.
It
was
very
unlikely
that
we
would
ever
need
to
move
to
a
new
guitar
repository,
but
I
was
discussing
with
some
people
some
going
users
at
vmware
and
they
felt
that
using
a
vanity
import
pass
was
pretty
dope
and
definitely
look
looked
good
for
your
goaling
based
project.
B
B
Chan
commented
on
the
pr
and
suggested
that
we
use
entria
dash
io
slash
entry
instead,
just
in
case
we
put
other
projects
under
the
entry
ad,
the
io
github
organization,
for
which
we
want
to
also
use
a
vanity
url
chen
pointed
out
that
most
projects
do
something
like
this,
for
example
kubernetes.
So
you
have
kubernetes
slash
the
repo
name,
the
component
name.
B
E
E
But
do
you
think
the
since
I
actually
I
don't
know
so
I'm
just
asking
it
is
that
possible
the
the
projects
use
some
dot
io
of
given
category
or,
for
example,
they
are
an
independent
project
or
something
like
that
is
possible.
Maybe
they
are
a
very
popular
one.
I
don't
know
so.
I
run
those
freedom,
corporate
style.
E
B
I
also
think
that
it
doesn't
matter
too
much
in
our
case
because,
as
I
said
before,
we
will
not
consume
as
a
library,
but
then
the
same
can
be
said
of
like
kubernetes.
Obviously
we
import
kubernetes,
but
that's
because
we
we
reuse
some
of
the
communities
like
packages,
most
people
using
communities,
of
course
like
consume
it
as
as
as
containers
and
binaries,
and
not
not
to
build
good
software.
But
no,
I
think
there
is
no
nothing
preventing
us
from
from
using
a
vanity
import
pass.
B
B
Okay,
I'll
assume
that
people
are
okay
with
that
change.
Originally,
I
was
leaning
a
bit
against
because
I
felt
like
the
advantages
were
not
big
enough,
but
the
feedback
I've
received
is
that
people
think
it's
generally
a
good
idea
to
switch
the
vanity
import
path.
So
if,
if
you
have
an
opinion
that
you
couldn't
express
during
the
meeting,
please
like
comment
on
the
github
issue
or
if
you
find
like
a
other
related
project,
also
using
a
vanity
import
pass.
You
can
also
comment
on
the
github
issue.
A
I'm
pretty
sure
that
there
will
be
some
follow
up
on
this
conversation
about
vanity
import
puffs
to
me
you
know
personally,
it's
okay!
I
just
have
let's
say
that
I
don't
like
anything
that
starts
with
vanity,
but
you
know
probably
just
naming
it
that's,
okay
and
well,
so
we
don't
have
any
other
topic
for
today
at
least
no
one
came
up
proposing
any
other
topic
for
discussion
for
today.
B
Discussion,
I
didn't
have
time
to
open
an
issue,
I'm
planning
on
doing
it,
but
maybe
there's
something
I
can
just
put
out
there
for
people
to
to
think
about
and
and
we
can
see
how
people
feeling
a
bit
so
we're
trying
to.
I
don't
know
if
people
have
realized
that,
but
I'm
taking
care
of
the
entry
dot
dash
dot
iu
website
so
most
of
the
time
it
just
involves
either
updating
the
block
page
in
which
we
we,
we
publish
actually
I'll,
share
my
screen
again.
B
So
let
me
go
to
entry
io,
so,
most
of
the
time,
it's
just
about
updating
this
page,
which
links
to
blog
posts
about
entria
or
articles
about
andrea.
So
by
the
way,
if,
if
you're
aware
of
some
blog
about
our
entry,
that's
not
including
included
here
and
that's
recent
enough,
you
can
send
me
the
link
and
I'm
happy
to
add
it
here.
It
doesn't
matter
if
it's
in
english
or
another
language
we
with
links
to
some
blog
posts
in
japanese,
for
example.
B
So
if
it's
a
blog
post
in
in
mandarin,
it's
fine
too.
I'm
happy
to
add
the
link
and
the
other
part
of
updating
the
website
is
refreshing,
the
documentation.
Every
time
we
do
a
new
entry
release.
So
if
you
see
here,
we
have
a
bunch
of
releases
and
you
can
access
the
version
of
the
documentation
for
for
each
entry.
B
I
release
at
some
point
I
think
I'll,
remove
old
versions,
but
for
now
you
have
everything
ever
since
we
we
started,
including
the
documentation
on
the
website,
and
so
it's
been
a
bit
of
a
manual
process
for
me
to
update
the
documentation
with
each
release.
So
I'm
hoping
that
I'm
going
to
be
able
to
automate
this
process
more
in
the
future,
so
that
every
time
we
create
a
new
release,
tag
on
github,
this
documentation
is
automatically
updated
and
actually
we
have
the
version
of
the
documentation
on
the
main
branch
here.
B
B
They
see
an
issue
with
a
formatting
or
a
broken
link.
Anyone
can
submit
the
pr
to
to
fix
that
on
the
website
right
now.
It's
not
the
case
and
I
think
salvatore
can
confirm
because
at
some
point
he
wanted
to
update
something
in
the
website
and
it's
quite
a
process
to
to
do
such
an
update,
and
so
we
have
two
choices:
either
we
move
it
to
a
subdirectory.
B
So
these
things
tend
to
grow
the
size
of
a
repository
over
time.
It
can
reach
like
hundreds
of
megabytes,
which
can
be
a
bit
annoying
when
you
clone
it,
including
as
part
of
ci,
and
also
it,
creates
a
lot
of
comments
in
the
main
repo
that
are
specific
to
the
website
and
not
really
specific
to
the
entire
code
base
and
the
second
option
moving
it
to
its
own
website.
B
So
I
don't
expect
to
us
to
make
a
decision
about
this
right
right
now,
but
this
is
something
I
wanted
to
bring
up
and
I'll
be
opening
a
github
issue
about
this.
So
if
you
have
comments,
please
feel
free
to
speak
up
now.
Otherwise,
I'm
happy
to
have
a
discussion
on
the
github
issue.
Right
now.
I
don't
have
a
preference
myself.
So
it's
something
I
need
to
think
about.
As.
D
Well,
I
have
a
quick
question
anthony
so
so,
if,
if
let's
say
we
have
this
website
as
a
separate
repo,
is
it
not
possible
if
we
can
set
up
some
linking
mechanism
so
that
you
know
a
certain
page
of
the
website
is
a
hard
pool
for
on
the
entry
repos,
slash
blah
blah
blah.md,
and
then
it
just
displays
the
mark
down.
There
is
that
possible.
B
It's
possible
and
that's
what
I
would
do
the
problem
with
that
is.
If
someone
update
the
documentation
in
the
entry
website
is
it
they
don't
know
if
that
documentation
is
going
to
render
correctly
in
the
website,
so
it's
not
possible
to
make
a
change
to
the
documentation
and
then
look
at
what
the
website
is
going
to
look
like
as
generated
by
ci
before
actually
merging
your
pr
and
having
the
website
be
updated
through
that
kind
of
like
notification
mechanism
and
by
pulling
documentation
from
the
entry
repository.
B
So
that
was
ideally
that's
what
we
would
be
able
to
do
now.
It
may
not
be
an
issue
really
because
we
run
so
many
linters
on
the
markdown
files
right
now
and
by
the
way,
the
reason
for
running
those
linters
that
tell
you
that,
oh
you
have
a
missing
white
line
and
that
kind
of
stuff
is
to
ensure
that
the
markdown
is
going
to
look
good
on
the
website
and
it's
going
to
be
able
to
render
correctly
into
html.
B
We
can
go
with
it
and
see
what
happens
and
if
we
ever
run
into
issues
where
people
merge
some
documentation
and
then
the
website
cannot
put
it
and
render
it
correctly.
Then
we
can
think
of
a
an
alternative
solution.
That's
a
possibility.
I
think
it's
a
smaller
price
to
pay
compared
to
growing
the
size
of
the
entry
repository
by
by
adding
the
source
code
of
the
website.
D
B
Sense
but
yeah,
it
does
seem
that
most
projects
use
a
separate
repository,
so
yeah
the
possibly.
Is
that
the
way
to
do
it
for
us
and
if
we
eventually
need
to
move
the
documentation
over
like
in
the
case
of
kubernetes,
for
example,
I
think
the
documentation
is
everything
is
under
cuban
t,
slash
website,
then
that's
something
we
can.
We
can
do
for
the
long.