►
From YouTube: Antrea Community Meeting 08/24/2020
Description
Antrea Community Meeting, August 24th 2020
A
And
so
good
morning
today
is
tuesday
august
25th.
It's
still
monday.
It
was
24th.
If
you
are
the
united
states,
welcome
to
the
andrea
community
meeting.
For
today
we
have
a
fairly
packed
agenda.
We
have
a
few
different
topics,
as
you
may
have
noticed
on
the
vlog
channel.
We
first
need
to
do
need
to
agree
on
alternate
dates
to
not
lose
a
meeting
because
of
the
u.s
labor
holiday.
A
A
A
B
B
B
Get
some
up
and
moving
so
network
policy
v2.
We
have
been
meeting
for
about
two
months
now
and
the
meeting
really
started
off
in
a
fairly
ad
hoc
manner.
Jay
viaz
from
vmware
started
some
of
the
initial
conversations
with
the
network
sig
and
then
the
meeting
has
since
blossomed
into
a
full
subproject
of
the
network.
Sig.
B
So,
just
to
give
you
a
little
idea
of
of
what's
all
involved
here,
I've
included
a
a
link
and
I
will
post
this
to
the
andrea
kubernetes
slack
at
the
end
and
anson.
If
we
want
to
include
this
in
any
meeting
notes
I'll
make
sure
that
you
get
the
proper
information
here
at
the
end
of
the
meeting,
there
is
a
google
doc,
that's
tracking
the
subproject's
agenda.
B
B
However,
we
found
that
there
tends
to
be
a
preference
for
native
extensions
to
network
policy,
so
this
would
either
be,
for
example,
native
and
tria
policies
native.
You
know:
calico
policies,
native
civilian
policies
etc
for
protecting
the
cluster
as
a
whole.
So
if
I'm
a
cluster
administrator-
and
I
want
to
write
policies
that
have
a
global
effect
and
that
can
enforce
a
rule
set
across
multiple
namespaces,
for
example,
I
don't
have
those
capabilities
with
the
current
upstream
network
policy.
B
B
Where
is
this
here
we
go
so
early
on.
We
had
a
a
lot
of
user
stories
that
were
linked
in
so
just
to
take
you
down
through
this.
I'm
not
actually
going
to
go
into
these
specific
user
stories
tonight.
15
minutes
is
not
going
to
be
adequate
to
cover
that,
but
I
just
wanted
to
to
tell
you
with
a
very
kind
of
free-flowing.
B
D
B
Two
some
of
the
ideas
that
were
being
tossed
out
while
they
would
improve,
I
think,
the
use
of
kubernetes
and
specifically
in
securing
network
connections
within
kubernetes
but
may
or
may
not
have
been
within
the
actual
formal
scope
of
a
network
policy
api,
and
so
we
kind
of
had
an
initial
set
of
criteria
we
talked
about.
You
know
the
heaviest
weighted
being.
That
was
this
user
story
that
we're
actually
talking
about
even
api
related
what
it
you
know.
What
is
the
demand
for
that
story
right?
B
So
we
wanted
to
focus
on
consumers
of
network
policy
and
users,
but
we
also
wanted
providers
who
have
to
implement
these
stories
right
to
have
some
say
on.
You
know
what
is
actually
doable
and
and-
and
you
know,
how
do
they
have
it
prioritized
in
their
road
maps?
Is
it
compatible
with
v1?
Are
we
talking
about
you
know?
Are
we
talking
about
extending
v1
or
introducing
entirely
new
resources,
and
also
is
it
improving
usability?
B
We
also
talked
about
you
know
improving
multi-tenancy.
I've
got
that
layer,
although
that
was
a
lesser
concern
in
the
initial
scope
for
v2
policy,
and
I
listed
syntactic
sugar
because
we
talked
a
little
bit
about
syntactic
sugar.
A
lot
of
the
user
stories
that
were
coming
in
were
already
achievable
with
the
existing
network
policy.
B
However,
the
community
didn't
feel
that
either
it
was
clear
on
on
how
that
user
story
could
be
solved
with
existing
policy,
and
so
basically
it
would
you
know
we
could
improve
the
usability.
So
a
lot
of
the
syntactic
sugar
stuff
that
we
were
initially
thinking
about
really
might
just
fall
under
improved
usability.
B
We
wanted
to
create
an
uber
kubernetes
enhancement
proposal
that
that
really
spelled
out
the
the
overarching
goals
and
and
scope
of
what
we
wanted
to
accomplish
with
a
v2
policy.
In
addition
to
that,
so
that
we
wouldn't
get
stuck
in
one
cap,
we
wanted
to
break
out
the
individual
user
stories
where
it
made
sense
into
smaller
caps
that
could
be
adopted
and
approved
and
implemented
on
a
per
kept
basis,
so
that
we
could
make
incremental
progress
forward.
B
We
created
an
initial
readme
that
we
were
in
in
this
repository,
so
at
the
top
level,
this
repository
the
readme,
is
going
to
capture
essentially
that
ubercap
or
the
scope
and
and
objectives
and
goals
that
we
want
to,
and
also
even
more
importantly,
the
non-goals
of
this
group.
This
is
very
much
a
draft
in
progress.
We've
had
one
working
meeting.
Obviously
kubecon
was
last
week,
and
so
we
were
trying
to
balance
everyone's
schedule
with
that
and
with
trying
to
at
least
get
an
initial
draft
started
here.
B
B
B
We're
going
to
talk,
we're
going
to
you
know
actually
list
out
the
individual.
You
know
user
stories
we're
actually
going
to
talk
about.
You
know
some
implementation
direction
once
we
we've
captured
those
user
stories.
Another
important
piece
of
this
actually
is
the
the
sinkhole
templates
here
and
I
think
we
need
to
probably
better
define
this,
but
we
also
wanted
to
have
a
library
of
patterns
and
use
cases
of
existing
v1
policy
common
use
patterns
right
so
that,
as
we
think
about
v2,
we
also
have
something
to
compare
and
contrast
against
on
v1.
B
So
that
we
can
actually
have
an
you
know,
an
objective
say,
hopefully
of
whether
or
not
we
made
we
made
it
easier
or
more
or
more
usable,
and
so
we
have
a
separate
parallel
effort.
That's
actually
trying
to
capture
in
one
place,
all
the
patterns
that
are
commonly
found
for
doing
network
policies
using
the
v1
primitives.
B
Some
of
the
stories
are
not
clearly
articulated
as
as
yet,
and
so
one
of
the
things
I'm
doing,
for
example,
is
taking
some
of
these
stories
and
then
within
each
one
of
those
stories
we
are
we're
actually
creating
individual
kept
in
in
this
directory.
So,
for
example,
these
will
these
will
capture
the
user
story,
all
the
kind
of
boundary
conditions
and-
and
you
know
have
you
considered
what
the
impact
of
this
is
on
other
kubernetes
processes.
B
Okay,
so
I'm
gonna,
you
know,
wrap
up
kind
of
what
our
current
work
is
and
what
we're
doing
between
what
we
have
captured
in
this
repo
and
what
we're
moving
over
from
from
a
lot
of
the
commented
notes
here
right.
So
a
lot
of
this
is
still
in
the
process
of
being
moved
over
to
that
repository,
so
we
can
have
a
more
formal
process
on
tracking
changes
and
and
working
on
these
individual
caps.
My
my
action
for
our
community
is
take
a
look
at
both
of
these
documents.
B
The
omission
is
or
etc,
and
we'll
try
to
pick
that
up
and
and
what
we're
going
to
do
before
each
meeting
moving
forward
is,
on
friday,
we're
going
to
look
through
this
repository
and
the
issues
either
requiring
the
most
discussion
or
have
had
the
most
interaction,
we're
going
to
prioritize
and
use
the
our
open
forum
to
bring
those
up
for
discussion
so
salvatore.
I
think
I've
taken
at
least
a
full
15
minutes.
Are
there
any
questions
on?
What's
going
on
on
b2
that
I
can
answer
for
anybody.
A
Yes,
cody,
you
were
great,
actually
you,
I
think
you
took
exactly
15
minutes
and
30
seconds
so,
which
is
great
from
a
time
perspective,
and
I
think
we
also
have
time
for
a
couple
of
questions.
Actually,
I
I
have
a
question
which
is
probably
a
long
shot.
I
saw
one
of
the
goals
is
the
migration
from
v1
to
v2
apis
and
with
the
api
migrations.
A
One
of
the
problems,
typically,
is
that
users,
especially
the
ones
with
a
long
running
deployments,
tend
to
be
stuck
as
much
as
possible
on
the
older
apis.
So
since,
eventually
you
want
to
stop
supporting
both,
for,
I
guess
from
manageability
reasons,
what
is
the
plan?
Do
you
have
a
plan
already
for
easing
the
migration.
B
You
know
itself,
and
so
we
will
probably
have
as
part
of
the
implementation
of
this
project,
either
a
tool
if,
if
it's
a,
if
it's
a
a
policy
that
can
be
migrated,
automatically
write
a
tool
that
can
migrate
all
of
those
in
a
tool
that
will
basically
call
out
policies
that
need
manual
intervention
for
that
migration,
so
something
that
we're
definitely
thinking
about
from
a
scoping
perspective.
But
it
wouldn't
be
a
tool
that
is
native
to
any
particular
implementation.
B
Now,
one
other
one
other
thing
I'll
point
out
here
that
you
know
we're
trying
as
much
as
we
can
to
stick
to
api
related
things,
but
there
are
a
whole
slew
of
user
stories
that
deal
with
a
common
tool
set.
That
basically
makes
the
use
of
network
policies
easier
across
the
board
and
we've
even
talked
about
things
like
a
cli
utility.
B
E
E
Then
there
is
a
list
of
other
user
stories
which
kind
of
map
towards
some
sort
of
a
tool,
a
devops
tool
or
a
cli
which
would
you
know,
help
gain
more
visibility
or
which
is
similar
to
what
we
have
done
in
andrea,
the
the
querier
as
part
of
jake's
intern
project.
So
so
that
again
is
like
a
very
separate
scope
for
the
user
stories.
The
third
part
is
where
the
application
developer
focused
network
policy,
apis
user
evan.
E
E
That
should
help
in
the
migration
effort,
but
if
we
do
an
additive
v1,
then
I
think
a
lot
of
defaulting
and
all
that
can
come
into
picture
to
help
out
with
that,
but
those
decisions
are
not
yet
like
finalized.
I
I
you
know
on
my
side,
I
have
an
action
item
to
add
some
of
those
proposals
and
see
which
user
stories
require
v2
and
which
of
those
user
stories
can
be
done
in
an
additive
fashion.
A
B
Well,
one
is
not
too
late,
it's
not
too
late
jinjin
to
get
in
new
stories.
Two.
I
would
recommend
if
it's
a
story
that
is
either
not
cap,
it's
either
not
captured
in
one
of
the
docs,
where
you
want
to
clarify
one.
That's
in
one
of
the
docs
that
I've
referenced
and
again
remember
we're
in
the
process
of
migrating
a
lot
over
to
this
repo
just
post,
an
issue
with
with
your
user
story
and-
and
you
know.
B
C
E
E
E
C
B
Sure,
absolutely
yeah,
and
and
if
it's
something
you
want
to
discuss
with
me,
you
know
prior
or
abhishek,
you
know
call
meeting
we'll
we'll
get
that
discussed
and
but
you
know,
if
something
is
you
already
have
it
kind
of
lined
out
just
post
a
user
story
and
we'll
start
commenting
on
it
or
an
issue?
I
mean.
C
A
C
C
Yeah,
I
think
we
talked
about
this
before
for
some
time
since
we're
adding
more
features,
probably
do
some
adjustment
of
existing
api
groups,
especially
foreign
working
group.
Now
we
call
networking
but
actually
useful
used
for
many
messages
between
concerned
agents
and
the
controller
use
that
api
group
to
publish
a
computer
like
policing
group
to
agent.
C
For
now,
since
we're
adding
new
features,
we
kind
of
feel
a
little
harder
to
add
a
new
group
for
these
features.
At
least
we
should
use
some
way
to
adjust
these
in
groups
first
to
find
a
place
for
his
new
features,
and
then
we
have
some
discussion
on
front
over
that
google
doc.
I
think
shared
link
here.
I
just
created
youtube
for
the
proposals
that
agreed
on
that
google
doc,
which
they
were
saying.
I
will
keep
most
of
the
api
group
unchanged,
so
you
still
have
this
core
group.
C
Now
it's
for
common
types
and
they
still
landed
here
and
they
still
know
it
and
then
maybe
later
we
can
put
the
more
common
types
or
common
resources
there.
For
example,
one
possibility
for
this
grouping
on
just
one
example
here
and
that's
also
one
proposal.
I
want
to
propose
for
the
net
positive
v2
by
the
way,
to
have
a
separate
grouping
resource
to
define.
Any
groups
can
be
used
by
that
policy
and
in
our
case,
maybe
by
some
other
policies
and
then
yeah
for
the
current
networking
group
we're
injured.
C
We
can
start
to
add
new
in
my
mind,
layout
two
to
the
four
light
working
features
to
that
group.
For
example,
when
we
do
ipad,
maybe
we
could
put
ipad
resource
ipads
to
the
networking
group
and
when
you
do
as
that
policy
was,
can
you
say
all
these
voice
that
policy
there
and
even
for
this
know,
the
port
local
proposal?
I
think
we're
present
several
weeks
ago
put
it
can
also
built
in
networking
api
group
and
then
for
ops
and
the
system.
C
The
matches
we
just
keep
the
mind
changed:
whoops
for
all
the
of
staff
swap
shooting
capability
and
of
the
busy
stuff
we're
gonna,
have
chase
flow
crd
and
support
bundle
here
and
probably
have
more
of
features
there
and
for
system
is
more
for
system
level,
monitoring
and
runtime
information.
Okay,
we
have
monitoring
crd
and
we
saw
some
system
component
information
on
system
api
group
and
for
matches
as
well.
D
B
C
C
So
of
course
we
are
different
from
kubernetes
because
called
more
aspects,
but
if
they're
coolers,
because
only
have
one
network
group
for
all
the
local
networking
features,
so
I
kind
of
if
we
want
to
continue
with
final
grade
groups,
divinity
division
and
probably
even
for
all
system
and
the
metrics.
You
will
do
a
final
group
too,
and
also
for
some
good
metrics.
I
think
we're
just
following
some
conventions
include
by
smart.
I
think
inclusive
of
the
matrix
api
group
for
matrix
for
system,
I'm
not
sure,
chair
and
others.
C
F
F
C
C
B
No,
I
didn't,
I
don't
have
a,
I
don't
have
a
proposal
now
it
was
just
more
of
a
general
question,
the
only
other.
The
only
other
question
I
had
regarding
that
was
how
we
evolved
the
versioning.
I
guess
of
these
groups.
Right
are,
we
are
all
of
the
crds
that
are
composed
or
or
used
together,
right,
that's
isolated
into
their
groups,
and
then
they
can
evolve
at
different
rates
and
as
long
as
we've
accomplished
those
two
things
and
we
have
a
clear
separation
of
the
apis,
then
this
should
be.
B
C
Sure
I
think
the
actual
capacity
in
our
we
have
both
the
idea
and
the
rules
of
our
own
api
and
then
sometimes
the
crd
and
the
the
the
data
is
supposed
through
our
api
functionally.
They
may
fall
into
the
same
the
same
group.
For
instance.
We
cannot
really
use
a
single
group
for
both
the
id
and
the
api,
so
we
have
to
separate
them.
C
Here,
let's
talk
about
the
internal
group
a
little
more,
hopefully
you
guys
can
share
opinion
and
let's
just
choose
one,
so
no
matter
which
will
we
go
right?
We
still
want
a
separate
group
for
communicating
between
consumer
agents.
Since
we
cannot
use
internal.
I
think
the
team
here
propose
some
other
alternative
names,
for
example,
have
this
implementation
or
shorter
name
for
implementation
and
control
plan,
and
the
cp
also
show
them
for
contribution,
like
conceptual
internalizing,
that
is
from
solitary.
C
There
are
also
some
other
names
from
antonin
and
abstech
like
a
backhand
and
local
priority.
I
think,
according
to
australia,
we
kind
of
feel
this.
Syria
can
cause
some
misunderstanding
can
mislead
the
audience
because
they
can
mean
different
things,
so
probably
we'll
just
exclude
them
from
the
candidates.
C
C
C
B
C
B
A
Yeah,
I
I
think
that
we
can
probably
finalize
this
discussion
on
the
gita
bishop
and,
if
you
don't
mind,
I
will
use
the
last
20
minutes
of
the
meeting
to
introduce
a
new
topic
which
is
a
dnt
operator.
I
mean
it's
not
really
new,
because
we've
been
talking
a
bit
about
it
already
but
yeah.
Now
there
is
a
let's
say,
a
design
proposal
and
dantin.
Do
you
mind
to
present
it?
Are
you,
okay
with
presenting
it.
D
D
D
There
is
another
object
called
and
operator
city.
We
need
to
add,
because
it's
a
requirement
for
openshift
that
each
operator
needs
to
have
needs
to
own
its
own
crd,
and
it's
society
should
house
back
a
status
field
for
red
hat
certification
process.
We
and
we
need
to
confirm
that
the
operator
could
update
status
in
the
operator
cit
as
well
as
we
already
have
all
the
configurations
in
the
operator
copy
map.
D
D
So
I
think
first
it
can
validate
the
configurations
from
both
in
the
network
cid
and
the
config
map,
like
we
can
check
the
cider
format
from
the
networks
id
and
check
some
operation
options
in
the
copy
map
to
let
the
resources
running
also
time
operator
can
also
check.
If
the
new
change
need
to
be
applied
again
I
mean
it
can
compare
between
the
existing
configuration
and
the
new
calculation
like
if
only
a
cluster
network
site
setter
is
changed.
D
D
D
There
are
three
columns
for
the
status
or
cluster
operator
available
per
progressing
and
degraded.
So
you
you
can
see
in
this
picture
also
creators
how
to
have
shown
the
status
here
for
available.
It's
it
means
operator,
already
applied
a
configuration
that
is
matched
with
the
desired
configuration
for
processing.
It
means
some
resources
are
still
pending
to
be
created
and
for
the
degraded
it
means
some
invalid
calculation
or
and.
D
D
Here
is
a
workflow
for
the
operator.
Actually,
it
needs
two
controllers.
First,
why
is
the
config
map
controller?
The
other
is
a
power
controller
for
the
copy
map
controller.
It
will
watch
the
net.
As
I
just
said,
it
will
watch
the
network
cid
and
operator
copy
map.
If
there
is
any
change,
it
will
do
the
configuration,
validation
and
then
decide
if
it
needs
to
render
and
apply
manifest
to
create
and
share
resources
and
abstain.
D
D
Platform,
first
of
all,
as
enter
needs
a
node
fpam
controller.
To
be
enabled.
I
checked
on
an
existing
openshift
cluster
is
already
enabled,
and
also
for
a
cool
controller
manager
operator,
already
monitor
the
cluster
network
setter
from
the
network
cid
to
make
sure
that
no
spec
has
the
correct
pulse
setters.
D
So
it
should
be
fine
for
an
entry
with
the
node
pam
requirement,
also
for
the
overscan
module.
We
also
need
to
make
sure
it's
installed
and
loaded
on
the
openshift
node.
I
think
for
this
requirement.
We
need
init
container
in
android
agent
democrat
to
make
sure
the
oscar
module
is
already
loaded
as
a.
D
D
The
last
one
is,
we
can
make
the
entry
operator
as
a
general
generic
operator,
which
means
we
can
not
only
write
on
or
up
shift
cluster,
but
we
can
also
make
it
be
running
on
other
kinds
of
knowledge
cluster.
So
we
can
make
an
option
in
the
coffee
map
to
switch
between
openshift
and
other
lattice
cluster.
D
A
Thanks
anthony,
there
was
a
very
good
presentation.
I
only
have
a
quick
question
about
the
name
space
for
anterior
and
openshift.
This
is
not
related
to
the
operator.
It's
more
ready
to
achieve
deployment,
as
you
have
showed
us.
The
style
that
overshift
typical
approaches
uses
is
that
you
have
a
namespace
for
the
operator
and
then
another
namespace
for
the
resource,
that's
managed
by
the
operator.
So
I
wonder
if
we
want
to
have
a
dedicated
namespace
for
andrea
or
still
use
cube
system
in
opencl.
You
know
in
openshift.
A
D
D
E
A
Yeah
I
mean
I
don't
have
a
strong
opinion
either
to
me
any
namespace
will
be
fine,
it's
just
a
matter
of
sticking
it
to
the
conventions.
So
if
there
is
a
convention
to
use
a
distinct
namespace
for
each
for
each
operator,
then
I
will
probably
we'll
probably
do
that.
But
this
is
a
minor
point
and
I
guess
that
we
can
sort
it
out
even
later.
Is
there
any
other
question
concerning
the
operation
for
the
open
or
the
operator
or
deploying
andrea
on
overshift.
A
Hey
this
was
considered.
This
was
considered
actually,
so
we
will
start
with
openshift.
That
would
be.
That
would
be
step
one
and
that's
as
danting
clarified.
That's
because
for
openshift
it
is
mandatory,
for
you
know,
for
certification
purposes
to
get
an
operator
and
openshift
also
uses
cluster
operators
for
everything
pretty
much
so
there
will
not
be
a
an
elegant
alternative,
but
in
the
future
we
can
start
considering
operator-based
install
for
all
the
distributions,
I
would
say,
starting
with
the
on-prem
distributions,
like
your
kubernetes
on-prem,
but
then
also
moving
to
cloud
distributions
later.
A
H
H
It
shows
that
when
there's
a
config
map
update,
you
regenerate
the
manifests
and
then
you
have
to
restart
the
agent
pods
potentially,
and
I
want
to
ask
if
this
is
because
currently
in
andrea,
we
do
not
support
live
updates
of
the
config
map
as
an
example,
for
example,
if
you
today,
if
you
enable
prometheus
metrics
for
the
agent
to
the
controller,
you
have
to
restart
the
entry
agent
and
controller
parts
or
or
the
change
will
not
take
effect.
Is
that
why
you
have
that
kill,
hold
entry
about
the
option.
D
H
A
Thanks
thanks
anton
so
I
believe
that
this
could
be
all
for
today,
and
I
would
like
to
thank
everyone
for
attending
and
I
just
want
to
remind
you
that
the
next
meeting
will
be
exceptionally
in
a
week
time,
instead
of
two
weeks
time,
so
we
see
each
other
again
on
monday
august,
31st,
9
p.m,
pacific
time
or
if
you
prefer,
4
p.m,
for
a
4
a.m.
On
tuesday
1
september,
1st
gmt
all
right,
thank
you
very
much
and
have
a
good
one.
Everyone.