►
Description
Agenda
Harbor 2.0 status update
bug status till RC milestone
69 opened (https://github.com/goharbor/harbor/issues?q=is%3Aissue+is%3Aopen+label%3Atarget%2F2.0.0)
FC build for early access and testing: https://storage.googleapis.com/harbor-builds/harbor-offline-installer-v2.0.0-build.3252.tgz
Harbor 2.1 plan introduction
2.1 feature suggestions - https://github.com/orgs/goharbor/projects/1
non-blocking GC's proposal needs reviewing:
https://github.com/goharbor/community/pull/133
CNCF SIG-Security - Harbor Project self assessment
P2P Working Group - Integrations Between Harbor and P2P Providers
Demos
Deploy harbor to local cluster (Kind) with operator - ZiMing Zhang
step by step guide: https://github.com/goharbor/harbor-operator/pull/32
please have a try, feedbacks are welcome!
p2p demo - Steven Zou
Overall introduction
Discussion Topics:
A
All
right,
hello,
everybody
and
welcome
to
the
hardware
community
meeting.
This
is
the
united
states
version
it's
the
8th
of
april
and
as
always,
it's
a
recorded
meeting.
So
please
adhere
to
the
cncf
code
of
conduct.
I
have
a
relatively
short
agenda
today,
so
let's
go
through
it
really
quickly.
So
I'll
go
ahead
and
share
my
screen.
Let
me
know
if
you
all
can
see
this
so
we're
making
excellent
progress
towards
the
hardboard
to
the
door
right
now
we're.
A
I
think
we
have
about
50
bugs
left
and
there's
a
couple
more
back,
bashes
left
by
the
team,
but
essentially
there
is,
if
anybody
is
looking
to
try
it
out,
there's
a
release
candidate
and
can
give
you
access
it's
right
there
on
the
harbour
community
meeting
notes.
So
it's
the
second
item
second
item.
So
if
you're
interested
in
trying
out
hardware
go
ahead
and
download
the
link
check
it
out,
file
some
bugs
or
come
and
fix
some
bugs
help
us
write
dogs
would
love
any
type
of
effort
from
the
community.
A
I
forgot
to
mention.
We
have
a
new
community
meeting,
notes
and
agenda
no
more
presentations.
All
our
agenda
is
going
to
be
on
this
hardware
wiki,
so
you
can
visit
it.
You
can
we'll
have
all
the
historical
context,
but
you
also
added
links
up
at
the
top
to
the
old
community
details
page
and
the
old
recordings
that
that
we
used
to
have
second
hardware.
2.1
planning
is
happening
right
now.
A
That
means
we're
looking
into
a
couple
of
the
features
that
we're
going
to
introduce
into
the
one
I
mentioned
it
a
couple
weeks
ago.
Proxy
cash
is
a
number
one
feature
and
then
non-blocking
garbage
collection
is
a
number
two
feature
so
we're
looking
at
both
of
them.
You
can
view
this
pull
request
here
to
kind
of
look
at
the
the
proposal
on
on
some
of
these
items.
A
In
addition
to
that
in
the
earlier
community
meeting
and
you'll
be
able
to
view
that
on
youtube
at
any
point
within
the
next
week,
or
so,
we
had
ximing
basically
showed
us
a
step-by-step
guide
for
deploying
hardware
to
a
local
kind
cluster,
using
the
operator
that
we
have
developed
well,
mostly
ovh
cloud
developed
it,
but
the
hardware
team
has
been
contributing
to
it
significantly.
Since
then,
I'm
going
to
skip
the
last
item
there,
because
I
want
to
show
it
in
a
second
the
the
other
thing,
and
maybe
this
is
worthwhile
adding
to
the
agenda.
Jonas.
A
If
you
want
to
to
add
that
double
grade
as
well,
I'm
putting
here
on
the
chat,
so
you
can
edit
it
as
well,
but
we've
been
going
through
the
cncf6
security
assessment.
This
is
an
assessment
of
hardware
and
it's
feed
for
graduation
from
a
lens
of
security.
This
is
a
huge
document.
It
has
a
ton
of
content
and
it's
very
important
for
also
practitioners
of
hardware
and
I'm
going
to
take
you
to
a
couple
of
very
important
items
here.
A
There's
this
under
operations
and
system
design,
you're
going
to
find
a
lot
of
things
around.
You
know
how
hardware
is
architected,
the
different
options
that
we
made
and
the
different
requests,
and
you
see
a
lot
of
comments
here,
like
the
security
architects
are
looking
into
hardware
they're.
You
know
they
probably
posted
two
300
questions
so
far
and
we're
just
going
through
them
and
answering
them
both
here
in
slack
on
private
messages
and
this
table,
which
is
the
breakdown
of
access
tokens
and
creds,
is
super
important
to
understand
harbor
from
a
security
standpoint.
A
What
are
all
the
different
pieces?
The
hardware
interacts
with
from
access
tokens
and
encryption
keys
and
how
they
connect
to
each
other.
So,
for
example,
if
you
want
to
learn
how
robot
credentials
are
created
well,
this
is
a
jwt
token,
with
custom
claims
that's
signed
by
the
private
key
of
harbor.
How
is
the
private
key
or
hardware
created?
That's
item
number
one.
It's
a
it's
an
xo
509
certificate
for
the
publicly
and
the
private
key
is
for
96
bits.
A
We
generate
your
installation
and
you
can
rotate
it
if
you
do
x
y
z,
so
this
is
from
an
operation
standpoint.
These
are
critical
things
that
someone
needs
to
understand
on
hardware
and
this
table
illustrates
all
the
different
pieces.
For
example,
one
new
feature
of
hardware
2.1
to
the
daw-
and
I
mentioned
it
that
probably
about
a
month
ago-
is
that
we're
going
to
enable
ssl
for
hardware
core
service
to
hardware
core
service
communication.
So
there
are
seven
such
services
we're
going
to
create
a
certificate
for
each
one.
A
It's
going
to
be
an
x,
509
tls
certificate,
so
the
customer
has
to
provide
it,
but
there's
a
way
that
you
can
replace
it
by
replacing
the
crt
and
dot
key
in
the
designated
paths
in
kubernetes
is
a
secret,
but
in
docker
compose
it's
going
to
be
a
file
with
restricted
permissions,
so
super
super
valuable,
there's
a
lot
of
other
things
here
that
are
valuable.
I
encourage
anybody.
That's
a
practitioner
of
hardware
and
interested
in
learning
and
understanding.
Hardware
is
great.
A
Look
at
that
boom.
Thank
you,
jonas,
and
we've
learned
that
anybody
can
update
this.
Actually,
the
reason
why
we
went
with
github
is
because
certain
countries,
specifically
china,
hackem,
did
not
work
so
github
does
work
without
ssl
and
without
vpns,
so
so
that
that
that
that
basically
offered
a
better
choice
for
us.
So
the
next
thing
I
want
to
show
is:
we
have
a
document.
A
Actually
I
need
to
link
to
the
right
things
right
here
that
basically
talks
about
the
integration
between
the
different
between
hardboard
and
the
different
peer-to-peer
providers.
That's
basically
we
should.
I
don't
know
why
we
didn't
add
it
to
the
notes
earlier.
I
just
sent
it
to
you
right
now.
Jonas,
maybe
you
can
add
it
now
too,
but
this
basically
talks
about
the
architecture
of
enabling
hardware
to
operate
with
peer-to-peer
technologies
like
kraken
and
dragonfly
and
how
we're
going
to
enable
pushing
images
to
these
different
architectures.
A
If
it's
too
long-
and
you
don't
want
to
read-
let
me
kind
of
tell
you
the
two
main
things
of
this
number:
one
is
we're
going
to
operate
on
a
provider
model.
So
every
time
you
want
to
enable
a
new
provider
for
p2p,
whether
it's
dragon
fly
or
kraken,
or
even
something
else,
you
add
them
into
hardware.
You
provide
a
url,
possibly
some
set
of
credentials
and
they
connect
to
hardball
once
they're
connected,
they
almost
behave
the
same
way
as
as
replication
providers.
A
So
if
you're
familiar
with
replication
providers
and
and
I'm
logging
in
right
now,
my
ui
you'll
notice
that
if
we
want
to
enable
replication
the
first
thing,
if
you
try
to
create
a
rule
that
the
first
thing
you
need
is
an
endpoint
right.
So
there's
no
endpoints
here.
So
let
me
go
ahead
and
create
an
endpoint.
A
So
if
I
create
an
endpoint,
I
give
it
a
name,
a
description,
a
url,
and
then
I
give
it
an
access
id
and
secret
and
that's
how
you
connect
to
an
external
registry
same
way
that
will
connect
to
an
external
provider.
That's
a
p2p
provider.
So
it's
not
going
to
have
any
difference,
so
let's
go
ahead
and
look
at
that
in
a
quick
demo.
So
so
here
stephen
joe
one
of
our
maintainers
was
going
through
this
you'll
notice.
A
Sorry
guys
I
apologize,
I
lost
my
my
slot
there
you
go
so
so
over
here.
One
of
the
things
that
steven
is
showing
you
is
that
under
distributions
and
that's
going
to
move
under
administration.
Eventually
you
have
instances
which
is
the
same
thing
as
the
as
the
endpoints
for
registry
replication
that
we
used
to
have
before
and
then
there
you
can
basically
add
the
different
providers
that
you're
gonna
have
so
he's.
Actually
gonna
go
through
and
create
a
provider
right
now.
So
look
at
the
instances
and
look
at
this.
A
This
ui
is
very
similar
to
adding
a
replication
target.
You
tell
as
what
provider
you
want.
You
give
it
a
name,
you
give
it
an
endpoint
and
then,
if
there
is
authentication
behind
it,
you
enable
that
and
then
once
you
enable
it
you,
it
will
basically
be
able
to
accept
pre-heating
images.
So
how
do
you
preheat
an
image
today?
Because
this
is
a
and
it's
a
work
in
progress?
A
You
basically
come
and
find
an
artifact
in
hardware
and
you
click
the
preheat
button,
and
once
you
do
that,
that
artifact
will
be
pushed
to
the
peer-to-peer
core
service
and
then
the
peer-to-peer
network
will
push
it
to
the
different
areas
where
based
on
policy,
where
it
needs
to
be
distributed
in
the
history
tab.
We
will
show
you
exactly
the
history
like
this
image
was
preheated,
or
this
image
wasn't
preheated
and
so
on
and
so
forth,
but
we
don't.
So.
This
is
where
the
history
is
shown.
However,
we
don't
want
to
stop
there.
A
We
want
to
enable
preheating
the
same
way
that
we
enable
replication
today,
so
in
replication
today
we
give
you
a
lot
more
freedom
in
terms
of
how
can
you
replicate
an
asset
in
hardware?
So
if
we
actually
go
back
to
replications,
we
allow
you
to
provide
some
filtering
or
by
tag
by
label,
and
the
resource
won't
really
matter
that
much
after
harvard
2.0.
A
But
to
give
you
a
little
bit
more
flexibility
into
deciding,
you
know
what
resources
do
you
want
to
replicate
and
where
should
they
go
and
the
same
way
and
the
same
policy
and
the
same
flexibility
in
terms
of
defining
this
logical
name,
space
that
you
want
to
preheat
with
peer-to-peer
is
also
going
to
happen.
So
I
look
for
that.
Our
goal
is
to
have
maybe
possibly
a
minimal
viable
product
for
peer-to-peer
integration
with
hardboard
2.1
and
finalize
it
before
cubicon
emea,
which
is
in
mid-august,
so
that's
kind
of
where
we
are
any
questions.
A
Tiannon
you're,
our
only
your
our
main
guest
here,
everybody
else
is,
he
knows
all
these
things,
so
hopefully
these
things
are
interesting
and
are
valuable.
I
think
you
know
2.1,
with
the
focus
on
edge.
We're
going
to
make
introducing
this
integration
between
dragonfly
and
kraken
is
gonna,
be
important,
and
hopefully
everybody
finds
it
interesting.
C
A
C
A
C
A
I
think
we'll
one
of
the
we
were
very
hesitant
on
pushing
everything
in
three
in
hardware,
so
we
want
to
make
it
as
a
plugable
model
where
there's
an
interface
they
implement
it
and
you
bring
them
along
just
like
we
did
with
scanners.
So
I
don't
think
they
will
be
part
of
the
core
product,
at
least
not
initially,
but
they
will
be
fully
supported
by
hardboard
since
we're
testing
with
them
as
well.
A
C
B
A
B
C
I
don't
think
it's
a
joke
at
all.
In
the
oci
discussions
around
the
artifact
specification,
we've
literally
been
throwing
around
the
idea
that
this
is
the
next
generation
of
s3,
which,
honestly,
I
think
the
distribution
protocol
is
kind
of
a
garbage
s3
replacement.
If
you
were
setting
out
to
build
a
replacement
for
s3.
This
isn't
where
you'd
end
up,
but
it's
kind
of
funny
that
we
brought
the
whole
container
ecosystem
back
to
well.
This
is
just
a
thing
that
stores
things.
So,
let's
just
let
it
store
anything
yeah
buckets.