►
From YouTube: Antrea Community Meeting 06/15/2020
Description
Antrea Community Meeting, June 15th 2020
A
A
Cody
is
prepared
as
something
very
interesting
for
conducting
this
retrospective,
and
the
second
topic
for
today
will
be
led
by
young
that
we
give
us
an
overview
of
the
design
for
cluster
Network
policy.
We
expect
them
to
have
about
15
minutes
for
users,
developers
and
community
questions,
so
I
think
it's
enough
for
introductions
and
I
will
just
end
it
over
to
Cody
for
starting
with
retrospective
Cody,
which
today
you
have
a
very
interesting
background.
B
B
You
may
have
seen
the
or
your
kids
may
have
seen
the
movie
Cars,
and
you
may
have
seen
this
illustration
in
the
movie
Cars,
but
this
is
actually
a
real
place
where
a
bunch
of
Cadillacs
are
buried
in
the
ground
and
and
they're
spray-painted,
so
some
crazy
art
fun
stuff
from
Texas
today
we're
gonna
do
a
a
retrospective
I
chose
a
fun
way
to
do
it.
Yeah.
If
you
don't
like
this,
maybe
that
could
be
part
of
your
retrospective
feed
back
to
me.
B
Maybe
we
can
change
the
way
that
we
do
it
in
the
future,
but
I'm
using
an
application
called
fun.
Retro
I
chose
a
murine
time.
Our
maritime
type
theme
kind
of
matches,
our
fishing
and
and
maritime
theme
with
an
tria
and
really
the
the
goal
of
this
is
to
provide
candid
feedback.
You'll
notice
that
when
you
provide
your
feedback,
it
should
be
anonymous
and
I
want
you
to.
Let
us
know
like,
for
example,
it
says
what
what
is
the
wind
pushing
ourselves
that
make
us
go
fast.
B
What
are
we
doing
well
is
what
that's
talking
about
what
anchors
are
holding
us
back?
What
do
we
need?
Those
are
things
that
we
need
to
improve
on
the
column.
What
rocks
are
ahead
of
us
that
risk
our
future?
These
are
things
that
we
need
to
avoid,
or
you
know
problems
that
that
we
can
perceive
now
with
this
project
that
we
may
want
to
shift
directions
and
then,
finally,
what
is
our
ideal
Island
destination
now?
This
is
kind
of
what
goals
we
wanted.
B
She's
objectives
we
want
to
achieve,
and
maybe
something
that
we're
not
doing
now,
and
so,
if
you
haven't,
had
a
chance
to
participate
in
this
I've
posted
the
link,
both
in
the
kubernetes
Eyck
Channel
and
in
our
in
our
chat
on
unzoom.
If
you
wouldn't
mind
clicking
and
share
some
feedback
with
the
rest
of
the
team,
would
I
I'm
gonna,
give
everybody
about
two
to
three
minutes
to
you
know
put
down
some
things
that
they
think
they'd
like
to
share
with
the
rest
of
the
team.
It
doesn't
have
to
be
long.
B
It
can
be
just
really
short
statements
about
about
the
project.
If,
typically,
you
want
to
talk
about
how
the
last
release
this
is
the
first
time
we've
done
it
so
I'm
kind
of
making
it
a
little
more
open
and
in
the
future,
we're
gonna.
Do
this
more
and
and
focus
it
more
on
on
the
last
release
that
we
did
right
so
that
we
can
kind
of
gauge
our
progress
and
our
overall
feedback
with
the
community.
But
it's
a
little
more
broad
this
time.
So
you
know
this
doesn't
have
to
be
specifically
about
the
last
release.
B
B
I'm
gonna
show
the
cards
I'm,
hiding
the
cards
right
now,
so
that
I
can
hopefully
encourage
some
original
feedback
and
once
I
show
the
cards,
I'm
gonna
then
enable
voting,
and
then
you
can
basically
give
six
total
votes
on
things
that
you
agree
with
and
and
we
can
get
an
idea-
maybe
some
areas
that
we
want
to
focus
on
as
a
team
I
hope
you
enjoy
this.
This
is
kind
of
a
fun
activity,
I've
done
it
some
other
places
and
let's
let
the
feedback
start
I'll
be
back
with
you
in
about
two
or
three
minutes.
B
B
B
C
B
B
Okay,
so,
basically,
what's
gonna
walk
feedback
after
one
minute,
I
should
have
done
that
while
we
go
but
anyhow
we'll
go
ahead
and
start
looking
at
the
feedback
that
we
had.
So
what
is
the
wind
pushing
ourselves
that
make
us
go
fast?
Someone
said
lots
of
progress
recently
on
CI
coverage,
EK
SG,
k
windows.
Let's
keep
it
going
in
that
direction,
so
they
got
two
votes.
B
Our
incredibles,
our
committers
are
incredibly
responsive
and
incredibly
skilled
and
dedicated
set
of
developers.
We
also
had
we
have
had
a
lot
of
flaky
tests
since
yeah
I,
which
makes
the
life
of
contributors
harder.
Hopefully
some
recent
patch.
This
will
help
mitigate
this
I
agree
and
I
would
be
curious
in
on
the
flaky
tests,
the
CI
in
terms
of
the
the
patches
are
we
talking
about
patches
to
dependencies
that
we
have
or
just
patches
to
the
core
product,
so
that
would
be
fun
to
get
some
feedback
on
that.
B
B
B
We've
had
a
very
fast
release,
cadence
until
now,
with
a
code
base
size
increasing
and,
as
we
have
had
more
complex
features,
I
think
we
should
consider
stretching
the
time
between
releases
to
at
least
six
weeks.
That's
an
interesting
piece
of
feedback.
I
think
we
should
talk
about
that
detachment
from
kubernetes
community.
We
need
to
be
more
involved
in
community
dynamics
like
what
Abhishek
and
Jay
are
doing
agreed
and
by
the
way.
Just
in
response
to
that
we
had
a
lot
of
people
join.
The
network
version.
B
We
are
adding
a
lot
of
awesome
features
packet
tracing,
Prometheus
metrics.
Can
we
find
a
way
to
showcase
these
features
to
the
community?
Maybe
using
a
series
of
short
YouTube
videos
I
think
that's
an
excellent
idea
and
commits
an
engagement
from
a
wide
variety
of
users
and
developers.
We
want
to
help
shape
the
future
of
Q
brandies
networking.
This
was
all
great
feedback.
What
I
would
like
to
do
is
take
this
feedback
and.
B
Basically,
four
things
that
actually
have
that
are
actionable.
We
can
add
these
as
agenda
items
in
our
future
community
meetings,
and
we
can
also
see
if
anybody
wants
to
sign
up
to
own.
For
example,
we
had
the
the
idea
of
creating
a
YouTube
video.
So
if
somebody
wants
to
own
maybe
a
particular
video
do
they
want
to
create
right.
We
can.
B
We
can
have
some
signups
for
that,
so
I
hope
you
found
this
useful
Salvatori
that
completes
what
I
wanted
to
do
tonight
in
terms
of
the
retrospective
and
I'd
like
to
do
this
on
a
on
a
cadence.
You
know
that
this
timed
with
each
release
so
that
we
can
keep
a
good
gauge
on
what
everyone's
thinking
and
in
the
community
and
what
they'd
like
to
see
happen
or.
B
E
A
B
Actions
in
those
shared
documents-
and
we
can
have
everybody
pitch
in
to
see
you
know
how
do
we
want
to
make
testing
better
or
how
do
we
want
to
create
content?
You
know
for
the
community
or
if
they
have
some
additional
ideas
on
exactly
how
do
we
get
more
involved
in
the
community,
for
example,
like
abhisheka
J
are
doing
I.
What
I
want
to
see
is
people
signing
up
to
actually
commit
to
to
doing
those
types
of
things.
A
B
A
E
A
B
That's
that's
configurable.
We
can
choose
whatever
we
want.
So
any
anyways
you,
you
know
anybody
can
log
into
this
fun
retro
by
the
way,
and
so,
if
you
have
feedback
on
the
way
that
you'd
like
to
see
this
retro
done
in
the
future,
I'm
all
ears,
let
me
know
if
you
want
more
votes,
less
votes,
maybe
some
more
columns
less
columns.
E
Observation
I
think
the
count
was
good
because
it
got
separation.
You
know
if
you
gave
one
vote
to
person
and
they
all
got
one
you
couldn't
prioritize,
but
it
strikes
me
that
you
need
to
maybe
disperse
the
votes
in
some
relation
to
the
number
of
attendees,
but
as
long
as
you
got
a
result
that
has
some
bubbling
to
the
top
that
you
know
maybe
you're
perceived
as
more
important
I
think
it
worked.
Okay,
I
also
did
a
screen
capture
of
this
deep.
A
F
F
I'll
probably
spend
you
know
around
20
minutes
to
talk
about
the
cross
and
our
policy
agents
I
design,
which
will
be
the
last
piece
of
the
cluster
level
policy
feature
we
want
to
ship
in
several
point.
A
so
I
believe
I'd
be
shocked
or
a
couple
of
weeks
ago
has
already
talked
about.
You
know,
class
level
policy
in
general,
so
I
wanted
to
pinpoint
some
key
differences
from
kubernetes
Network
policy.
As
far
as
an
sure
agent
is
concerned,
first
thing
is
see:
MPs
have
power,
tease
among
themselves
and
among
rules.
F
The
implication
of
that
is
the
conjunctive
action
flows
that
we
that
we
used
to
create
the
the
Yola
overflows
that
does
the
resubmit
action
now
needs
to
be
created
at
different
priorities.
You
know
in
OBS
table,
and
the
second
key
difference
is
that
the
CMP
rules
have
allow
and
drop
actions
instead
of
the
default
allow
for
kubernetes
Network
policies.
That
implies
is
that
the
well
conjunctive
action
flows
will
have
action.
F
Equals
drops
sometimes,
in
addition
to
have
actions
equals
resubmit,
and
the
last
thing
is
that
notif
or
isolation
is
sort
of
like
implied
by
crusts
and
our
policy.
So
the
rules
are
created,
as
is,
if
we
have
basically
no
ingress
and
egress
rules
would
apply
to
selectors
for
CMP.
Then
it
doesn't,
you
know,
imply
the
the
selected
parts
or
whatever
are
actually
isolated.
So
as
a
result,
no
isolation
flows
should
actually
be
created
in
the
egress
or
egress
default
table
for
cluster
level
policies.
F
The
next
slide
shows
you
know
the
a
little
bit
complex
idea
for
the
cluster
level
policy
priorities,
because
it's
sort
of
like
made
up
by
three
fields,
the
first
one
is
tier
or
category
I,
think
they
are
and
I
haven't.
You
know
agreed
on
what
we
should
probably
call
it
precisely,
but
this
is
something
that
we
are
not
introducing
in
0.8,
so
you
can
see
the
example
you
know
back
here.
F
It
doesn't
have
a
tier
of
category,
but
it
does
have
a
power
of
the
CMP,
which
is
a
user-specified
that
float
value
and
in
this
example
here
the
priority
is
one.
So
this
has
you
know
a
lower
it's
in
the
role
hierarchy
compared
to
the
tier
and
category,
and
even
after
that
we
have
a
poverty
of
the
rules
in
the
cluster
level
policy.
So
for
this
example,
because
we
have
two
ingress
rules
in
Corona
this
network
policy,
those
rules
has
no
presence
of
precedents
from
one
over
another.
F
But
in
this
case
you
know
this
allow
rule
on
the
first.
Allow
rule
actually
has
a
higher
precedence
over
in
this
rule.
This
is,
you
know,
basically
maintained,
as
you
know
how
those
rules
are
actually
written
in
the
cluster
level
policies.
Back
now,
with
those
in
mind,
I
want
to
share
a
pretty
worthy
slide,
which
you
know
describes
the
agent
design
for
class
net.
While
now
will
policy
in
a
nutshell,
so
the
first
thing
is:
we
have
two
tables
now
45
and
85.
F
F
So
initially
we
will
assume
five
unique
tiers
for
clustering
or
policy,
because
for
0.8
everything
will
be
created
in
the
deport
here.
That
means
that
we
will
be
basically
creating
all
action
flows
in
the
ten
to
thirteen
thousand
and
six.
This
wrench.
This
is,
you
know,
for
creating
all
the
action
flows
and
then
the
top
ten
and
bottom
10
power
tees
in
the
egress
and
ingress
tables
are
still
reserved,
for
you
know
other
users
in
the
future.
F
This
power,
it's
a
few
of
the
proofs
back,
is
basically
you
know
on
which
index
or
you
know
on
on
which
index
the
rule
is
created
within
the
CMP.
So
if
it's
the
first
ingress
rule
or
the
first
egress
rule,
the
priority
will
basically
be
one,
and
if
it's
the
second
rule,
the
power
will
be
two
and
so
on
and
so
forth.
F
The
last
thing
is
that
for
each
rule,
depending
on
the
action
of
the
rule,
we
actually
create
different
actions,
whether
it's
in
a
resubmit
or
drop
for
that
plus
the
network
policy
rule.
So
let
me
show
you
a
more
specific
example
of
this
suppose
we
have
one
CMP
and
it
is
created
at
priority
1.5
and
this
one.
You
know
as
a
reminder
all
CMPs.
Now
we
that
we
now
create
our
forcing
to
the
default
here
so
10
to
13
2006
is
the
default
error
zone
for
us
to
hold
all
the
CMPs
in
the
departure.
F
Now
we
have
power
to
equals
1.5,
so
the
power
it
is
in
between
one
inclusive
and
two,
not
inclusive.
All
those
priorities
will
be
created
within
you
know,
a
priority
zone
sort
of
say,
and
since
this
is
the
only
poverty,
that's
within
this
range
we
have
right
now
it
has
two
ingress
rules
and
one
egress
rules,
so
those
two
are
actually
off
the
exact
same
priority.
If
you,
if
you
think
about
the
tier
priority,
the
cmp
priority
and
the
rule
poverty,
so
those
two
rules
will
be
actually
created
at
this
OpenFlow
poverty.
F
Now
the
second
ingress
rule
will
be
actually
created
at
Authority.
That's
one
nor
to
that
now
suppose
that
we
have
another
CMP
its
power
to
1.2
and
there's
one
ingress
rule
to
this
cmp,
because
this
poverty
is,
you
know
higher
than
the
cmp
this
roof
or
needs
to
be
created
out
of
our
priority,
that's
higher
than
all
those
three
rules.
So
what
we
do
is
that
we
shift
the
three
rules.
That's
used
to
be
created
here
down
to
those
two
Oh
F
power,
T's
and
insert
the
rule
for
here.
F
Basically,
we
sort
everything
that's
in
the
same
priority
zone
and
put
it
there.
So
this
whole
struct
is
maintained
by
a
new
module.
That's
currently
being
put
in
the
agent
package
called
poverty
and
the
the
bad
module
only
maintains
you
know,
sort
of
the
mapping
between
the
overall
air
flow
and
the
priorities
that
we
have
in
Nigeria.
The
same
thing
will
happen.
F
Let's
consider
like
if
CMP
3
is
created
again,
this
is
of
a
higher
priority
than
the
CMP,
so
this
rule
5
basically
needs
to
be
created
at
an
even
higher
power
T
and
every
everything
that's
created
before
that
will
sort
of
like
shift
down.
In
that
sense,
let
me
pause
a
little
bit.
Does
anyone
have
any
questions
so
far.
F
Yes,
for
unique
poverty's,
yes,
this
is
this
is
the
limit
for
now,
but
for
later
we
will
consider
you
know
expanding
the
tiers
own
on
demand.
So
if,
on
the
default
here,
we
have,
you
know
too
many
priorities
that
we
couldn't
fit
in.
You
know
those
13,000
priorities.
We
will
expand
the
tiers
own
to
be.
You
know
greater
than
it
is
so
far.
A
D
F
Okay,
so
the
float
value
for
the
cmp
priority
is
that
we
want
to
sort
of
like
make
sure
that
if
we
want
to
insert
a
priority
between
two
existing
rules,
we
always
find
a
way
to
do
that.
So
if
we
create
two
CMPs
with
power
into
one
and
two
and
somehow
a
user
wants
to
create
another
cmp
that
has
authority
in
between
those
two
without
actually
you
know
modifying
the
current
CMPs.
You
can
always
pick
a
new.
You
know
float
value,
that's
in
between
those
two
which
serves
the
proper,
the
purpose.
G
F
G
F
C
F
Yes,
so
we
considered
sort
of
like
having
a
you
know
more
dynamic
model
where,
if
we
only
have
you
know
those
rules
will
create
it
at
the
very
top
and
we
shift
you
know
every
time.
That's
you
know,
a
new
thing
is
added,
but
we
sort
of
like
wanted
to
define
you
know
a
loose
sort
of
sort
of
hash
way
to
install
those
rules,
so
they
are
sort
of
spaced
out
nicely
for
at
least
for
you
know,
power.
It
is
0
to
100.
That's
there's
something
I
want
to
talk
about.
F
You
know
later
is
also
will
probably
you
know,
advise
user
to
create
power
teasing
between
0
and
100.
To
begin
with
that,
we
will,
you
know,
avoid
this
zone
being
too
congested
and
you
know
tend
to
overflow.
So
if
we
you
know
in
general,
crave
power
is,
is
in
between,
you
know,
0
and
100.
This
can
be
pretty
spaced
out
and
because
you
know
in
the
general
sense,
people
will
usually
be
creating
1.0
before
they
create
1.2,
we'll
also,
you
know,
make
sure
less
power
to
rearrangements
happens
in
this
case.
F
C
F
And,
and
for
this
you
know
for
this
table,
essentially,
if
we
have
any
algorithm
changes
at
all,
we
we
just
need
to
update
the
priority
module,
so
the
the
flow'ry
assignment
functions
functionalities
will
be
already
there.
So
once
we
update
the
priority
module-
and
we
just
you
know,
apply
and
share
again
on
the
new
priorities,
we'll
sort
of
just
be
reflected
in
there
seamlessly.
D
F
For
this
thing,
yes,
okay,
so
so
we
have
65,000
magic
power,
it
is
in
the
intro
table
and
you
know
at
the
very
beginning,
we
will
assume
that
there
are
five
tiers
which
can
be
added.
You
can
have
60
or
70
years,
and
you
know
there
are
some
new
rearrangement
that
needs
to
be
happen,
but
originally
we'll
assume,
there's
five
tiers
just
as
in
NSX,
and
you
know
when
we
divide
this
65,000
to
five.
This
is
you
know
what
we
have
for
a
single
sphere
to
begin
with.
Basically,.
F
It
it
depends,
I
mean
it
depends.
You
know
if
there
are
some
tears
that
it
has,
you
know
less
rules,
it
can
probably
be
shrinked,
but
you
know
if
we
want
to
support.
You
know
other
more
tears
later,
we'll
probably
want
to
think
about.
You
know
using
other
tables
as
well.
That's
something
actually
yeah
actually.
D
F
That's
something
easily
configurable,
but
I'm,
not
sure
you
know
for
upgrade
cases
if
want
to
consider
having
a
because
you
know
if
for
upgrade
cases,
if
we
support,
if
we
put
the
entire
table
for
the
different
tiers
on
now,
then
in
the
future
releases
we
definitely
have
to
you
know,
assign
war
tables
to
cm
piece
which
was
not
in
the
original
design
that
Jack
had
so
that's
something
I'll
probably
need
to
you
know.
I
would
probably
need
to
think
more
on
okay.
D
B
B
We
need
to
be
able
to
go
at
least
be
able
to
balance
I
guess
the
the
hashmap,
if
you
will,
or
the
the
way,
that
you're
dividing
those
zones,
because
I
think
it's
always
going
to
weight
toward
the
default
zone
having
the
most
policies.
I'm
sure
you've
already
feared
that
out
so
or
the
default
here,
having
the
most
the
most
policies
in
them.
B
And
so
64000
policies,
for
you
know
the
the
size
of
clusters
that
are
that
we're
starting
with,
should
be
sufficient.
You
know
we
need
to
do
some
calculations
on
on.
You
know
max
size
of
the
cluster.
If
we
you
know,
let
me
let
me
run
a
quick
back
to
the
napkin
on
that,
but
let's
come
back.
Let's
come
back
to
this
at
the
end
of
the
presentation,
I'll
think
of
the
yep.
D
B
B
You
know
you
could
have,
but
again
those
also
those
policies
are
distributed
right
because
one
pilot
you're
not
gonna,
write
individual
policies
for
every
pod.
You
might
write
a
policy
that
matches
you
know
10
or
15
or
20
different
pods.
So
I
think
that
you're
more
than
reasonable
on
on
your
limits,
but.
D
B
C
B
I
think
that
we
definitely
need
to
be
aware
of
that.
Also
remember
that
when
we
start
introducing
our
back,
not
every
user
will
see
all
the
other
not
will
not
necessarily
see,
especially
through
different
namespaces,
all
the
other
rules,
and
so
you
may
have
multiple
rules
spread
across
multiple
namespaces
with
the
same
priority
numbers
I,
don't
know
how
that
impacts,
your
table
and
your
calculations,
but
but
the
rules,
but
in
that
case,
would
share
the
same
priority
and
movie
pact.
F
Okay,
yeah
I
think
it
makes
sense,
but
we
for
the
cluster
now
will
policy
I
think
it
still
needs
to
so
for
the
other
across
level
policy.
That's
creating
the
cluster
if
there
are
on
a
same
poverty
and
we
sort
of
like
need
to
figure
out
a
way
how
to
deal
with.
You
know
if
those
two
rules
are
conflicting
because
we
have
in
allow
action
and
job
actions
now.
So
in
that
case
the
behavior
was
sort
of
like
being
quite
in
deterministic.
F
B
F
B
B
F
F
That's
some.
You
know
original
assumptions
we
want
to
make
for
the
0
that
I
release
is
that
all
the
CMPs
created
are
in
the
d4
tier,
which
means
the
action
flows.
We
will
be
installed
on
the
priority
ten
to
thirteen
thousand
essentially,
and
we
assume
that
no,
there
are
no
overflows,
so
we
have
almost
one
hundred
and
thirty
fun
grand
parties
to
accommodate
each.
You
know
basically
one
point:
zero
poverty
range
and
all
priority,
that's
greater
than
ninety
nine
point.
F
Zero
will
be
basically
mapped
to
the
last
zone,
so
the
users
are
not
advised
to
essentially
create
power.
It
is
over.
A
hundred,
as
that
will
make
you
know,
can
cause
congestion
congestion
in
the
last
power
it
is
on
and
within
a
power
it
is
own,
as
I
just
showed
it
in
the
in
example,
whenever
a
new
CMP
has
added
all
the
rules
in
the
same,
how
these
zones
will
be
resorted
to
ensure
the
correctness
of
power.
It
is.
F
So
this
is,
you
know
a
example:
I
took
from
a
working
testbed
of
the
current
implementation,
and
you
can
see
here
for
in
the
CMP
one
it
has
power
to
one
and
it
will
be,
you
know
basically
created
at
a
action
flow.
That's
at
you
know,
twelve
thousand
and
eight
hundred
and
seventy
six
and
all
the
matched
flows
will
be
created
at
a
top
priority
for
this
table.
So
no
matter
what
the
power
at
you
are.
F
So,
as
you
can
see
here,
a
new
conjunct
ID
that,
because
one
is
created
and
that's
off
a
higher
priority
than
this
one,
so
this
is
how
it
is
created
on
the
OBS
table
and
if
we
have
three
cluster
Network
policies
with
different
priorities,
this
is
basically
the
end
result.
It
will
be
gated
and
all
those
mass
flows
will
be
at
the
same.
You
know
high
priority
and
the
fine
grained
priorities
will
be
created
for
each
action
flow.
F
So
the
last
thing
I
want
to
add
is
some.
You
know
work
in
progresses.
The
first
one
is
we
on
the
agent
restore
keys.
We
want
to
enable
batch
OVS
flow
installment,
so
we
sort
of
liking
store
all
the
obvious
flows.
That's
you
know
in
between
the
agent
restore
in
one
time,
this
will
cut
the
traffic
disruption
time
to
as
minimum
as
possible.
The
reason
I'm
saying
that
is
you
know,
consider
we
have
a
case
like
this.
So
this
is,
you
know
before
the
agent
shutdown
we
have.
F
You
know
for
as
long
as
ten
seconds
now
we
want
to
make
sure
that
when
we
created
those
four
rules
for
this
run,
we
have
a
way
to
sort
of
notify
that
the
old
rules
on
the
previous
ones
can
be
deleted
at
once
as
well,
so
that
we
sort
of
you
know
just
patch
those
four
rules
in
batch
to
two
OBS
table
at
once,
and
the
old
rules
will
be
gone.
So
we
have.
You
know
a
through
move
update
from
the
previous
run
to
this
one.
F
Instead
of
you
know
having
on
rules
that's
created
at
different
priorities
that
can
be
no
conflict.
We
G
with
each
other
hand
around
in
between
those
two
rounds,
so
this
is
one
of
the
you
know,
improvements
to
the
to
the
restart
case
them
are,
you
know
actually
working
now
right
now.
The
second
thing
is,
and
the
second
thing
and
the
sourcing
is
basically
to
handle
the
cases.
If
a
power,
it
is
own
or
tears
on
overflows.
So
there
are
too
many.
F
You
know
power
it
is
created
on
in
those
stones
that
cannot
be
fit
with
the
original
assumed
numbers
and
then,
in
this
case
we
either
want
to.
You
know,
expand
this
on
somehow
or
use
another
table
for
for
installing
those
priorities
and
I
think
that's
it
I'm
open
to
any
other
questions
and
comments
in
terms
of
design,
I.
B
F
A
very
good
question
and
I,
don't
think:
I
have
checked
with
a
check
on
that
particular
question.
If
he
wanted,
you
know
basically
Tier
one
power
into
one
for
a
namespace
power
policy
to
be
essentially
the
same
power.
Yes,
Terra
one
power
to
one
for
custom
level,
policy
that
I'm
not
sure,
but
that's
basically
just
a
design
choice.
I
think
we
can
create
those
at
different
tables,
which
means
you
no
one
will
have
precedence
over
the
other
or
if
we
can
actually
create
those
at
the
same
table,
which
means
they
will
be
basically
the
same.
B
The
other
question
I,
had
you
talked
about
the
the
flows
conflicting
as
you
take
in
new
rules
is.
Is
that
mean
that
existing
flows
that
have
been
established
with
the
connection
tracking
could
eventually
stop
working
or
do
the
connections
have
to
cease
and
be
reestablished
for
those
new
rules?
Take
effect?
Can
you
elaborate
a
little
bit
more
on
that.
F
So
I
think
right
now.
The
implementation
on
this
thing
is
that
we
basically
took
a
of'
flow
object,
that's
stored
in
here,
and
we
retain
I
believe
you
know
all
the
fields
in
the
same
ofö
but
and
the
priority,
and
we
install
the
same
thing
at
the
different
priority.
So
I'm,
not
you
know
a
hundred
percent
sure
or
for
the
connection
tracking
things
will
be
still
maintained
on
that
I
think
maybe
when
you
can
give
a
little
bit
more
context
on,
but
I
I
think
you
know
on
the
other.
F
B
Well,
if
it
actually
breaks
the
connection
that
actually
could
be
an
advantage
for
long-running
connections
right
like
if
we
want
to
like
if
an
emergency
policy
rule
had
to
be
put
in
place
on
existing
CN
eyes,
that
connection
has
to
be
broken
before
the
new
rules
are
are
actually
adhered
to.
So
it's
like
that
actually
could
be
a
different
differentiator
mm-hmm.
B
C
C
B
C
B
C
F
Well,
I
think,
right
now,
the
how
this
is
implemented
is
that
we
sort
of
like
just
the
leader,
also
at
the
other
old
priority
and
add
a
new
flow
at
a
new
currency.
So
yeah,
maybe
the
the
pack
accounts
will
be
will
be
lost,
but
we
can
I
can
actually
see
if
we
can
do
any
sort
of
add
overrides
for
this
this
week,.
C
F
I
see
that's
a
good
question,
so
I
don't
think
right
now,
user
have
a
sort
of
like
central
way
to
get
all
the
current
priorities.
That's
you
know
used.
Maybe
that
can
be
a
sort
of
like
a
future
work
in
in
in
the
sense
of
you
can
use
this
or
and
control
command
to
get
all
the
personnel
policy
or
then
or
the
namespace
called
never
policy
priorities.
That's
currently
being
used
for
as
of
now.
If
user
wants
to
see
how
many
you
know
distinct
power,
it
is
he
or
she
has
been
created.
B
Until
we
until
we
get
a
UI,
you
know
like
for
this
of
some
sort,
it'll
be
analogous
to
writing
a
you
know
a
basic
program
right
either
the
users
gonna
have
to
plan
ahead
somewhat
on
the
use
of
their
their
priorities,
and
you
know
list
them
out
and
understand.
You
know
as
they're
creating
policies.
You
know
how
those
priorities
relate
relatively
to
other
things.
You
can't
really
I
think
do
reordering,
and
you
know
a
user
is
not
gonna,
be
able
to
comprehend
reordering
in
those
types
of
operations
without
some
type
of
visual
UI
indicator.