►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Foreign
hey
good
morning,
good
afternoon
good
evening,
depending
where
you
are
so
welcome
to
the
harper
community
meeting
the
agenda
for
today
is
we're
going
to
be
demoing.
The
ptp
work,
the
work
that
we
did
for
to
deliver.
A
Okay,
everyone
see
my
screen
yep
great,
so
we
have
a
couple
events
coming
up.
I
think
most
people
know
that
there's
the
kubicon
event
coming
up
on
the
18th.
I
believe,
but
before
the
before
that
we
have
there's
a
cloud
native,
open
source
summit,
virtual
summit,
china
2020
also
it's
an
online
conference.
A
So
we
have
a
couple
talks.
There's
one
on
just
a
harper
update,
graduation
project
update
by
henry
and
all
these
talks
are
in
chinese
they're,
china,
time
zone
friendly.
So
please
check
them
out.
If
you
have
time
and
then
there's
a
deep
dive
on
the
31st
by
daniel
and
stephen
on
harbor
2.0
and
some
of
the
upcoming
features
in
the
harvard
2.1
and
then
there's
an
application.
Delivery,
multi-cloud
and
multi-cluster
by
henry
and
naming
is
also
one
of
our
maintainers.
C
A
Starts
on
the
18th,
I
think
we
have
two
tracks
with
two
maintainer
tracks:
there's
a
harper
intro
and
a
harvard
deep
dive.
So
please
check
these
out.
If
you
have
time
all
right,
yeah
steven,
do
you
want
to
share
the
work
that
we
did
for
p2p.
B
Hello,
everyone
I'd
like
to
you
before
we
do
the
live
demo
I'd
like
to
use
one
slider
to
describe.
What's
the
car
idea
of
the
p2p
prohibit.
B
Actually,
the
core
idea
of
the
p2p
preheater
filter
in
harbor
is
it's
very
simple.
I
think
the
main
idea
can
be
described.
Use
the
diagram
machine
here.
Under
the
harper
side
we
use,
you
know,
will
support
a
prohibited
policy
and
this
policy
you
can.
This
policy
will
behave
as
an
automation
pipeline.
That
means
in
this
policy
you
can
create
some
filter
or
criteria
to
define
which
artifacts
are
qualified
to
trigger
to
do
the
preheat
operation.
B
So
far,
there
are
five
criteria.
First,
you
can
use
the
re
repository
patent
to
defend
you
know
which
repository
you
know.
At
the
repository
level,
you
can
limit
limit
narrow
down
the
repository
list
and
then,
after
that,
you
can
also
use
a
tag
pattern
to
narrow
down
the
tag
list.
After
that
you
can
also
to
specify
if,
if
we
only
want
to,
you
know,
appreciate
the
send
image
and
we
also
support
vulnerability.
That
means
you
can
defer.
You
know
only
only
the
artifacts,
you
know.
B
Without
some
you
know
specified
severity
vulnerabilities,
then
they
can
be
preheated.
Also,
you
can
specify
the
labels.
So
after
you
create
these
policies,
specify
the
related
criteria.
Then
you
can
also
define
how
to
trigger
this
template.
We
support
you
know
manually,
you
can
directly
click
to
execute
to
the
policy.
You
can
also
set
a
schedule
to
theoretically,
you
know
trigger
the
policy
and
you
can
also
you
know,
set
it
as
an
event
based
because
even
based
here
we
for
you
enterprise.
B
That
means
we'll
watch
the
on
push
scan,
complete
and
unlabel.
Three
events:
each
event
will
try
to
evaluate
if
the
targeting
artifacts
are
matched
the
related
policies
that
that
policy
can
be,
you
know,
can
be
started:
okay,
yeah
after
the
policy,
the
output
is,
will
you
know
if
we
have
some
artifacts
to
preheat,
we
will
send
the
preheater
requests
through
api
to
the
supported
p2p
provider.
B
Then
the
p2p
pro
engines,
like
cracking
or
drag
flare,
will
check
if
the
artifacts
has
already
either
has
already
been
in
their
cache.
If
not,
they
will
start
issue
a
pull
request
to
the
harbor
and
you
know
put
the
content
into
its
cache.
So
when,
when
the
client
started
to
you
know,
pull
the
image
from
those
pwp
provider,
I
think
they
can
directly
start
it,
because
all
the
data
pieces
of
the
you
know
putting
content
has
been
in
the
cashier.
B
If,
if,
if
we
don't
have
such
you
know
a
preheat,
the
first
coffee
needed
to
you
know
connect
to
the
upstream
bridge
and
pull
into
its
cache,
so
that
maybe
you
know,
consume
some
temp
delay.
So
I
think
this
is,
as
you
know,
use
this
feature.
You
can
plan
your
deployment.
That
means
you
can
use
this
automation
pipeline
or
use
use
the
pre-preheated
product
to
specify.
B
B
So
as
a
system,
you
can
navigate
to
this
distribution
to
add
a
supported,
p2p
ng
instance
in
harbor.
For
you
know
for
next
connection.
Okay,
today
I'll
use
the
uber
cracker
as
a
target.
B
B
Okay,
there
will
be
here's
the
check
field,
no
detail
information
for
security
consideration
once
again:
okay,
click,
ok,
and
now
you
can
see
we
have
a
kraken
and
it's
this.
Is
it
it's
health?
So,
after
the
let
me
add
this
p2p
into
the
list,
then
any
project
admin
can
use
this
instance
so
error.
I
will
not
switch
any
column
because
we
can
reduce
some
time,
so
you
keep
you
under
the
admin
account.
B
B
B
To
me
create
kraken
skyview.
B
1.90
tags
are
narrowed
down
the
scope
to
such
artifacts,
and
you
can
see
you
can
also
create
enable
some
criteria
for,
for
example,
a
signature,
stability
and
the
labels
for
the
scheduled.
We
only
use
the
filters.
D
So
quick
question
stephen:
when
you
check
only
signed
images
so
signed
images
are
replicated,
can
the
signature
still
be
enforced
and
replicated
or
preheated
to
the
p2p
provider
or
not?
D
D
B
D
Okay,
got
it
got
it
so
the
signature
is
lost,
but
this
is
just
a
way
to
say
because
it's
a
way
to
say
if
your
image
is
not
signed,
don't
replicate
it,
but
nothing
else
got
it.
I
I
yeah
yeah
yeah,
it's
just
a
condition.
Yes,
it's
just
a
condition.
It's
a
condition
check,
not
anything
else.
Thank
you.
B
Yeah:
okay,
let's:
let's,
let's:
let's
first
create
a
schedule,
preheat
policy
and
we
can
use
the
customers.
Let's
create.
Can
you
stream
in.
D
B
Now
for
event
base,
you
don't
need
to
stress
you,
you
don't
need
to
specify
the
concrete
events,
we'll
check
the
output
on
plan
complete
and
unlabel
three
three
events:
we
will
automatically
to
two
to
two
eight
values
if
it
needs
to
be
updated,
yeah,
yeah,
yeah,.
D
Yeah,
oh,
we
should
actually
we
should.
We
can
be
better
and
worded
yeah.
We
should
yeah.
We
should.
We
should
put
a
little
question
mark
there
to
actually
add
with
the
documentation
what
that
means.
Alex.
B
Yeah
after
you
create
the
even
the
basis
there
will
be
information
I'll
show
the
demo
later.
Okay,
no.
D
A
B
So,
let's
first
create
a
schedule:
the
policy,
let's
as
if
now
it's
it's
utc
time.
I
think
it's
that's
three
minutes.
B
Three
minutes
right:
yeah,
it's
utc
time.
So,
let's,
okay,
this
will
check
the
idx
and
a
1.19
text
and
it's
scheduled.
You
can
see
the
term
it's
a
udc
tab.
I
think
it's
three
minutes
later.
It
should
be.
You
know,
triggered
okay.
First,
let's
create
another
one
like
a
menu.
B
Maybe
we
can
use
anyone.
B
B
A
B
It's
weird,
okay,
this
time
it's
a
success.
Actually,
let's
check,
what's
real
happen,
the
background
you
can
go
to
the
access
log
you
can
see
there
is
a
kraken
username
to
pull
the
use.
This
digest
to
put
the
resource.
B
That
means
kraken
has
got
the
request
and
it
has
issued
the
pull
request
and
a
success.
Okay
and,
let's
back
to
see
more
policy.
B
For
example,
let's
either
one
by
one
that
may
be
more
clear
this
time
we
add
the
only
thing
image.
Let's
see
what
happened,
I
don't
think
it
should
be
preheat
anything
you
can
see
it's
completed
very
quickly
because
no
artifacts
will
prohibit
because
the
1.8
11
is
not
it's
not
a
certain
image.
Okay,.
B
All
the
artifacts,
only
the
one
delta
of
15,
okay,
this
one
only
the
1.14,
is
send.
So,
let's
see
what
will
happen.
B
You
can
see
running
executive
is
matched
so
it's
super
hit.
Okay,
so,
let's
back
to,
let's
see
what
you
can
see
the
schedule
that
has
been
issued?
Okay,
I
just
created
a
schedule
policy.
After
the
you
know
three
minutes
now
it
had
been
issued.
Let's
check
success,
you
can
see
we
preheated
two
artifacts,
all
the
information
you
can
find
here.
B
B
You
can
see
it's
very
quick
because
because
all
the
ngx
artifact
has
high
severity
vulnerability.
So
if
you
use
a
lure,
there
will
be
nothing
to
preheat,
let's
adjust
to
the
sorry,
let's
suggest
to
the
policy
to,
for
example,
critical,
because
critical
right,
the
artifacts
has
very
high,
but
you
said:
oh
critic
up
can
be
preheated,
so
the
ngx
artifacts
can
be
prohibited.
Let's
see
what
happened.
B
1.14
is
matched
and
the
trigger
approaches.
I
need
to
click
clear
here.
If
the
artifact
has
been
in
the
cache,
even
we
send
the
pre-header
request
to
the
p2png.
They
will
directly,
you
know,
retain
okay,
the
retention
set
because
the
artifact
uses
you,
you
required
to
be
cash
ahead
already
there.
So
if
what
I
mean,
if
the
artifact
is
repeatedly
prohibited,
okay
here
we'll
create
a
task,
but
actually
from
the
p2p
provider
setup
they
will
not
usually
duplicate
the
pull
request.
So
this
is,
you
know,
because
the
artifact
had
already
been.
B
B
All
of
the
criteria
are
you
know
added,
so
that's
we
will.
This
is
all
the
condition
we
used.
This
is
the
manual
trigger
way.
B
B
Actually,
for
for
mentioning
this
policy,
there
will
be
only
one
artifacts
in
the
demo
candidates
in
the
demo
data.
It's
the.
B
We
have
so
many,
but
only
one
have
the
five
condition
this
one
one,
one,
two
four,
but
let's
see
what
will
happen
first
I'll
remove
the
first.
B
Now
we
have
event
based
right,
and
that
means,
when
the
push
happens,
all
the
scan,
complete
events
coming
all
you
know,
label
and
label
event
happen.
The
policy
will
be
automatically
evaluated.
If
there
is,
you
know,
artifacts
match
that
policy.
The
artifact
will
be
preheated.
Let's
see
what
happens
after
we
add
the
label
to
the
one
daughter.
B
B
I
think
this
one
will
match:
let's
add:
a
label
approved,
okay,
1.214
has
approved
a
label
and
has
no
vulnerability.
You
know
with
the
severity
critical
and
you
know
it's
ndx
and
yeah,
and
also
it's
a
send
okay.
So,
let's
back
to
the
prohibited
policy,
what
will
happen
this?
One?
B
A
B
Yeah,
it's
not
a
condition,
because
this
is
a
poor
action,
so
I
don't
think
the
immutability
will
influence
the
play,
the
the
p2p
per
heater
operation,
but
we
do
not.
We
did
not
use
the
immutability
as
a
condition
at
this
moment.
Okay,
okay,
what's
happened?
A
Yeah,
it
might
be
a
bug,
but
I
think
we
understand
the
idea
behind
it
is
that.
B
Yeah,
I
think
that's
even
the
pizza
is
a
fancy
part.
B
B
E
B
Yeah,
I
have
one
more
one
more
points
I
needed
to
measure.
As
you
know,
we
have
some
security.
You
know
configuration
here
in
the
project
level,
for
example
the
contact
pass.
That
means
check
the
signature
of
the
artifact
and
you
know
prevent
the
vulnerability
with
some
severity.
B
So
these
two
are,
you
know
similar
to
the
preheat
policy
right
to
the
similar
conditions,
depending
on
the
preheated
policy.
So
the
current
principle
is
if
the
a
similar
condition
defining
your
preheat
policy
conflicts
with
the
security
settings
different
in
the
product
level,
configuration
will
use
the
project
level
configuration
to
override
you
know
the
settings
you're
defining
you
know
in
the
pre-header
policy.
B
I
think
the
typical
cases,
for
example.
If
here
you
specify
specified
only
you
know
if,
if
the
severity
of
critical
and
above
the
the
image
will
be,
you
know
prevented
for
pulling
from
pulling
and
in
the
preheated
policy.
If
you
use
especially
a
very
low.
A
C
C
C
B
C
C
But
but
why
the
criterias
are
different.
B
We
introduce
additional
criteria
to
the
replication.
I
think
I
think
the
main
difference
on
main
concentration
is
the
different
scenario
of
replication
and
the
preheater
for
the
preheater.
That
means
the
artifacts
you
are,
you
know
you
are
planning
to
deploy
to
your
runtime,
but
the
replication
is
not
maybe
replicated
just
to
copy
your
artifacts
from
one
to
one.
So,
as
is
the
deployment
it
should
be
used
very
you
know
most
restrict
condition
to
make
sure
the
artifacts
are
put
into
their
deployment.
Runtime
environment
are
more
secure.
B
B
B
Replication
the
target
the
environment
of
replication
is
also
in
the
register.
Right
and
you'll
have
other
different
changes
to
make
sure
you
know
the
sucker,
but
this
one
is,
you
know
targeted
into
the
runtime.
They
are
using.
C
B
B
That
means,
for
example,
here
if
you
did
not
check
the
only
c
standard
signature
only
send
the
image,
but
in
your
prior
level
configuration
you
enable
the
content,
trust
checking
so
we'll
use
that
to
override
this
settings.
So
that
means
the
project
level.
Security
setting
will
have
high
priority.
That's
who's.
What.
C
B
B
Because
because
your
security
may
be
not
very
risky,
and
here
we
can,
you
know,
defend
additional,
more
security,
more
restrict.
For
example,
in
your
level,
you
just
lose
a
low
level.
That
means
a
low
level
above
you
can
you,
you
can
pull
right,
but
here
I
can
differ
most.
You
know
most
restrict
oh
yeah,
let's
say
the
different.
I
mean
I.
B
A
B
Yeah
yeah,
I
think
I
think
the
reason
is
similar
to
the
replica
because
you
in
the
product
level
configuration
you
can
set
some.
You
know
very
executive
every
now
to
risk
trigger,
but
I
can.
C
I
don't
think
it
makes
sense.
So
let
me
let
me
ask
you
so
when
you
calculating
the
vulnerability
level,
do
you
consider
the
white
list?
Of
course
I
I
complete,
I,
I
don't
think
it
makes
sense.
You
create.
You
know
different
policy
at
different.
C
Because
it's
the
same
person,
configuring
the
project,
security
policy
and
the
p2p
policy
if
he
set
the
vulnerability
level
to
a
certain
value.
That
means
he
thinks
this
this
image.
If
it
has
certain
vulnerability,
it's
okay
to
be
deployed,
it's
the
same
person
making
the
same
decision
on
the
same
criteria.
I
don't
think
we
need
no.
C
B
C
B
D
B
C
B
C
B
Your
case,
I
think
the
default
is,
if
you
enable
the
two
you
do
not
need
to
specify
you
just
you
know,
leave
you
do
not
need
to
set
any
value
here
and
we'll
read,
you
know
we'll
use
the
project
live
settings
so.
C
B
A
B
B
C
B
That
leave
the
possibility.
You
know,
I
think,
for
most
cases
you
can
keep
consistent
with
the
product.
But
if
you
want
to
preheat
aimed
to
your
part
of
of
your
environment
and
they
may
require
more
security
policy,
then
you
can
use
this
capability
to
to
you
know
to
increase
the
you
know
the
settings
right
to
increase
the
security.
E
So
you
mean
that
I
configure
security
policy
in
the
project
level,
so
even
I
I
I
think
stocks
and
the
settings
value
are
all
meaningless.
E
B
C
A
A
C
B
D
D
If
we
don't
allow
an
image
to
be
replicated
because
it's
not
signed
or
we
don't
an
image,
don't
allow
an
image
to
be
replicated
because
it
doesn't
meet
the
vulnerability
or
we
don't
allow
an
image
to
be
pulled
because
of
a
vulnerability
stage.
It
should
be
the
same
across
the
board
like
our
policy
like
if
you
can't
put
an
image
directly
from
hardware,
you
should
not
be
able
to
pull
an
image
from
p2p
policy,
and
it
should
be
one
sorry
from
p2p,
and
it
should
be
one
unified
way
of
doing
that.
B
B
B
D
Me,
let
me
let
me
walk
you
through
a
scenario
stephen
today.
If
you
try
to
rep,
let's
say
you
create
a
project
in
harbor
and
you
say
I
don't
want
any
image
with
vulnerability
higher
than
high
to
be
to
be
posted,
and
we
probably
need
to
take
this
discussion
offline
as
well.
But
you
know,
let
me
let
me
just
run
this
through
really
quickly.
D
D
D
A
Oh
sorry
interrupt.
I
think
the
ptp
allows
you
to
be
more
more
strict
right.
So
if
you
had
configured
something
in
the
project
settings
that
said
nothing
higher
than
highest,
for
example,
then
you
can
still
allow
the
pulling
images
with
severities
of
medium
criticality
or
high,
but
then
in
the
ptp
provider
policy
we
can
configure
that
to
be
more
strict
right.
So
yeah
you
can
block
more
images
from
being
pulled
to
the
p2p
price.
I
think
when
we
were
discussing
this
feature,
someone
had
brought
it
up
that
you
know
they
wanted.
A
C
B
B
Disagree
with
daniel
said
I
don't
first
project
level
configuration
folks
since.
D
Can
we
take
this
offline
in
slack,
as
well
as
in
private
discussions?
If
anyone
else
is
interested
in
being
part
of
this
discussion,
please
let
stephen
joe
know
that
way.
He
will
involve
you,
but
let's
set
up,
let's
set
up
a
another
meeting
for
this.
I
think
it's
worthwhile
to
have
a
dedicated
meeting.
That
way.
We
don't
keep
everybody
on
the
call.
B
B
B
Yeah,
I
need
to
you
know:
do
you
know
sex
to
the
contributor?
This
feature
is,
you
know,
contributed
by
the
p2p
work
group.
We
have
contributed
from
frank
cohn
from
monty
center.
Claude
cheney,
jung
from
alato
cloud
I
mean
paid
from
netease
and
you
have
from
dragonfly
team
and
the
shooter
from
vmware
for
ui
development
and
alex
for
pm
and
year
and
from
uber
provide
some
suggestions
the
best.
So
that's
yeah.
All
the
contribution
of
this
feature.
Great
sex.
E
B
B
Yeah,
this
feature
is
contributed
by
the
p2p
work
group
yeah
from
different
companies
and
from
different
projects.
You
know
frag
from
this,
in
the
clouds
change
from
allah
to
cloud
into
you,
yeah
minimum
pay
from
netease.
You
have
from
dragonfly
team
from
where
vmware
for
ui
development
and
me
and
alex-
and
we
have
a
year
one
from
uber,
cracker
retainer.
We
got,
we
got
some
advice
from
era,
so
those
are.
B
A
Thank
you
steven
for
the
presentation
for
the
demo
and
thanks
to
everyone
who
helped
on
this
feature.
Does
anyone
have
any
other
comments
or
questions,
and
we
can?
We
can
take
it
offline
for
the
issue
that
we
were
talking
about
so.
D
Please
stephen
job:
please
upload
your
slides
to
the
community
repo
as
well,
so
it
can
be
linked
from
the
notes.
Yeah,
okay,.
B
A
B
Yeah
first,
we
update
to
the
community
states
as
status
and
daniel
will
introduce
the
key
features
in
the
past
2.0
and
continue
to
you
know,
introduce
the
anchor
features
in
the
introduced
in
our
upcoming
2.01
release,
and
I
will
talk
about
some
community
features
like
a
pdp
under
the
extended
artifact
processor
from
cycloid,
and
also
one
slide
talk
about
our
other
features
in
the
roadmap.
So
that's
all
the
content.