►
From YouTube: Harbor Community Meeting - Aug 11, 2021
Description
CNCF Harbor's Community Zoom Meeting
A
Okay,
hello,
everyone,
my
name
is
olympus
and
I'm
the
community
manager
for
harbor
today
is
august
11th
and
that's
our
community
meeting
for
the
european
and
china
time
zone.
Welcome
everyone,
and
today
I
I
see
two
topics
at
it
and
let's
go
them
one
by
one
proposal
for
tracing.
Do
we
have
can
on
the
call.
B
In
this
release,
I
propose
a
have,
I
propose
to
add
a
the
feature
of
distributed
tracing
for
harbor,
and
this
is
my
proposal
and,
as
we
can
see
the
background
for
why
we
added
the
tracing
for
hubble.
Is
that
because
the
modern
application,
the
tracing,
is
a
very
key
features
for
applications
online
to
debugging
and
for
also
it
can
help
to
improve
their
performance
and
and
such
kind
of
thing
and
we
and
for
what
the
applications
observability.
B
There
are
three
pillows,
the
log,
the
matrix
and
the
tracing
and
the
hubble
already
have
the
logs
and
the
matrix.
So
we
just
added
the
last
pillar
of
tracing
in
this
feature,
and
so
we
in
this
release,
we
plan
to
add
tracing
for
the
component
of
a
hubble
core,
harbor
job
service
and
regis
control,
because
this
three
component
is
a
very
important
part
for
hubble
and
we
need
to.
B
B
B
They
are
also
have
some
standard
for
tracing
is
the
most
popular.
Is
the
open
tracing
standard
and
and
the
open
sensors
by
the
open
tracing
and
the
open
sensors
they
will
merge
into
one
project?
Is
that
is
the
open
telemetry?
Maybe
the
library
may,
the
third
party
library
may
be
less
than
that
about
it?
I
think
the
open
tracing
is
the
future
of
what
the
open
tennis
story.
Open.
Telemetry
is
the
future
of
tracing
and.
B
B
So
this
is
one
reason
we
choose
it
and
that
maybe
someone
don't
know
the
difference
with
the
tracing
and
the
logs
and
the
metrics
and
the
metrics.
Let
us
all
know
the
overview
states
of
the
system
and
the
tracing
focus
on
one
request,
so
it
can
help
us
to
locate
the
rule
of
course.
Why?
Why
the?
Why
something
wrong
happened
and
the
notes
in
the
tracing?
We
can
also
log
some
informations
in
the
trace,
and
there
are
some
difference
between
the
logs,
because
the
logs
record,
all
the
information
happened.
C
B
It
also
need
more
resources
than
distribution,
so
we
cannot
always
open
the
profiling
parts.
We
can
always
open
the
distributed
tracing
on
our
service,
and
this
is
the
proposed
to
purpose
how
to
implement
it.
The
first
thing
we
need
to
add
some
configurations
in
our
hubble
config
file
like
this,
and
there
are
different
kind
of
things
we
need
need
trace.
The
like.
B
We
mentioned
the
progress
like
http,
client,
igp
server
and
the
way
we
can
use
in
this
kind
of
snap
pads
to
wrap
our
http
server
and
http
client
and
for
our
call
we
have
a
middleware,
so
we
can
using
this
this
just
studio
code.
We
can
use
this
kind
of
code
to
add
a
middleware
in
our
call
and
in
each
component
we
wanna
add
the
trace
we
can
use.
B
B
B
C
B
C
A
B
A
C
A
C
B
B
But
from
this
perspective
it
is
really
helpful
to
improve
the
software's
improvement,
because
you
know,
where
is
the
bottleneck
and
you
can
just
to
improv
and
to
improve
your
bottleneck,
and
it
will
help
to
improve
the
the
whole
performance
and
the
impact
when
tracing
is,
I
think,
is
it?
Can
the
impact
is
less
than
one
to
five
percent?
B
A
A
I'm
asking
because
I've
I've
hit
that
issue
in
the
past
we
enabled
tracing
of
one
component,
and
it's
like
it
was
using
quite
a
lot
of
resources
which
not
everyone
wants
to
spare.
So
is
there
a
mechanism
how
you
can
turn
it
on,
for
example,
for
for
specific
deployment,
and
you
can
test
something
then
in
production,
for
example,.
B
The
the
data,
how
many
data
you
are
organizing,
is
controlled
by
a
lot
of
things
like
you,
you
can
reduce
the
data
as
you're
tracing
your
code
and
also
you
can
not
not
like
I
got
mentioned
to
add
the
sampling
rate
rate
sample
rate,
and
we
can
also
because
we
have
a
a
queue
in
the
library
to
receive
the
data
and
send
back
by
batch
this
data
and
send
it
to
the
tracing
server
or
something
like
this.
We
can
have
some
improvement
in
this
to
reduce
the
impact,
but
we
cannot.
B
B
A
A
C
C
Okay,
that
makes
sense
yeah.
I
think
that
was
the.
I
remember
that
was
the
question
in
the
very
beginning
that
was,
the
context
is
like
the
open.
Telemetry
is
like
a
framework,
it's
almost
like
a
cache
or
it
collects
the
data,
and
then
they
want
to
analyze
and
visualize
the
data
with
their.
You
know
existing.
B
A
D
D
D
So
what
is
cosine
cosine
is
a
part
of
six
star
project
and
provides
container
signing
and
verification
with
oci
registry
integrations.
So
you
can
go
into
the
cosign
repo
to
get
some
details
and
basically
it
just
can
provide
a
sign
of
verification
and
oca
artifact
and
push
the
signature
as
oci
artifact
into
the
distribution
so
carefully.
Coal,
sun
height,
is
first
production.
D
Cosine
and
can
the
cosine
signature
are
stored
in
oci
distribution
next
to
the
container
image,
and
we
usually
can
adjust
the
pool
of
approach,
the
signature
like
other
artifacts
and
but
so
okay,
let's
just
start
with
gold.
So
this
proposal
is
one
to
support
cosine
and
in
harbor
and
after
support,
all
the
existing
functionalities
can
be
applied
to
the
sun
artifact.
D
So
in
addition
to
that,
because
we
do
not
want
to
manage
public
keys,
so
harper
cannot
verify
the
signature.
That
means
that
we
do
not
support
signature
verification
in
amazon.
Also,
we
can
now
support
as
cosine
current
cosine
green
is
to
remove
the
signature
from
the
register,
so
why
we
do
not
support
it.
That
is
the
cosine
clean
leverages.
The
type
ap
deletion
api.
So
this
api
is
not
a
required
implementation
that
defined
by
the
ocs
bike
and
harbor
so
far
does
not
implement
it.
D
D
Because
of
the
sequential
of
the
approach
operation
cosine
purchase
the
signature
firstly
and
then
push
the
artifact
to
harbor.
So
this
is
hard
for
harvard
to
build
the
relationship
between
the
signature
and
the
artifact,
and
I
also
list
some
personas
on
user
stories.
So
cosign
is
the
operation
for
any
user.
Who
has
the
darker
purge
formation
of
fiber,
so
anyone
who
can
push
a
image
into
harbor
he
can
push
a
cosine
signature
to
harbor
as
well,
and
I
let
just
list
some
user
story
here.
D
After
if
someone
pushed
a
cosine
signature
to
harbor,
the
the
project
amine
can
can
delete
the
signature
void
of
the
ui
or
pi
or
gc
and
artifact,
as
well
as
it's
called
signature.
Things
like
that.
So
let's
go
to
some
details
so
before
I
have
a
detailed
implementation
implementation,
I
want
to
have
a
definition
about
the
accessory.
D
C
B
C
A
D
So
by
default,
harbor
will
support
cosine.
So
that
means
you
do
not
need
to
specify.
I
specify
any
parameter
in
this
installation
step
like
this
cosines
you.
You
do
not
need
it,
what
you
needed
just
to
install
fiber
and
then
hybrid
support,
cosine,
and
but
if
you
just
specify
the
to
use
an
arduino,
so
it
means
that
hardware
support
powers
more
than
cosine,
so
in.
In
addition
to
that,
hardware
will
provide
two
different
kinds
of
signature
policies
to
block
user,
to
prove
and
sign
the
artifact.
D
So
this
is
the
first
one
design
so
in
the
future,
if
we
decide
to
support
only
one
signer
in
one
deployment,
so
we
should
define
some
behaviors
like
if
user
switch,
the
signer
from
not
3
to
cosine
or
cosine
2
non-cosine
harbor,
should
we
remove
all
the
signatures
data
from
database
on
under
the
backend
and
the
artifact
reference
and
cosine
signatures
are
started
as
a
separate
artifact
in
the
ocean
register,
but
just
with
the
weak
reference
with
its
name.
So
as
this
picture
shows
that.
D
D
So,
but
to
guarantee
the
signatures
will
not
be
garbage
collected
by
the
registry.
Harbor
has
to
build
up
the
relationship
between
the
closest
signature
and
the
subject
the
artifact,
so
I
want
to
introduce
a
new
table.
That
means
that
name
is
artifact
access
accessory
the
most
important
that,
while
you
hear,
is
that
we
have
one
id
to
indicate
the
subject
artifact
id,
which
the
signature
belongs
to
and
with
this
reference
harbor
will
knows
the
relationship
between
signature
and
artifact.
D
D
I
just
list
the
the
cosa
signature
blob
payload
here,
it's
a
it's,
a
single
signing
for
mine
and
the
single
signing
for
might
is
defined
by
redhead.
So
if
you
want
to
know
something
about
this
payload
details,
you
can
go
to
this
link.
To
see
details
I
mean
we
can
see.
There
is
the
one
key
name
dark
manifest
digest.
D
D
D
D
D
D
D
So,
let's
back
to
the
cosa
signature
payload,
we
can
see
there's
one
key
that
named
the
docker
reference
and
it's
while
you
have
the
has
the
endpoint
information.
I
I
just
confirm
confirm
which
the
constantine
the
cosign
client
will
not
use
this
attribute
to
verify
the
process
in
nature.
That
means
you
can
replicate
the
the
signature
to
any
harbor
instance
and
the
cosine
verification
flow
will
not
break
another
feature
about
the
garbage
capture
so
because
that
harbor
knows
the
relationship
between
the
the
signature
and
under
the
artifact.
D
Other
features
will
not
have
much
impact
at
least
there's
several
behavioral
differences
between
navi
and
cosine,
then
the
first
one
is
so
for
the
currently
designed
of
harbor
you're,
not
related.
If
you
just
assign
an
image
with
not
free
and
then
with
the
hardware
result
not
enabled
the
image
will
act
as
unsigned.
D
So
this
is
the
current
design
of
harbor,
but
for
cosine
the
the
behavior
is
different.
If
you
use
a
sine
image
with
cosine,
unless
a
user
remove
the
signature
from
the
artifact,
the
image
will
always
be
act
as
sign,
and
another
big
difference
here
is
that
bob
about
the
sun
type
target
noun
3
attaches
the
signature
to
this
image
type,
but
cosine
attached
the
signature
to
digest.
D
This
is
the
a
big
difference.
I
will
give
you
an
example
like
we
we
have
two.
We
have
one
emmy
letter
is
the
hollow
word,
but
we
have
two
texts.
We
want
every
two
for
naturally
formattery
we
can
sign
the
v1
tag,
but
v2
is
is
einstein,
but
for
cosine
we
just
assign
the
hollywood
repository
so
the
that
all
of
the
types
we
want
on
v2
act
assigned.
So
I
just
list
the
one
atom
to
be
to
be
discussed
about
the
sign
type.
D
D
D
D
D
D
D
D
C
C
If
you
had
some
discussions
with
you
previously,
it
feels
like
you
know
where
we
have
to
manage
the
the
verification
right.
We
have
to
either
support
the
management
of
the
keys
directly
or
integrate
against
kind
of
a
kms
to
manage
keys
on
harper,
and
that's
just
it
kind
of
goes
beyond
what
harper
is
trying
to
do.
I,
like
the
the
docker
content,
trust
framework
around
pki
around
public
key
infrastructure
right
you
just
it
turns
on
a
flag
and
the
pushing
the
image
with
you
know.
Dtc
turned
on
is
basically
just
an
entry.
B
C
Logs
in
and
draining
another
adb
here,
you
know,
first
of
all,
we
have
to
manage
the
relationship.
You
know
with
the
accessory
artifact
to
bind
the
image
to
the
signature
and
then,
once
again
it
feels
like
we're
going
through
what
we
did
to
support
oci
right,
all
the
all,
the
behavior,
creating
policies
and
garbage
collection
and
everything
we
just
have
to
think
about.
C
You
know
making
this
we
we
have
to
think
about
tuning.
You
know
the
paver
harbor
to
accommodate
for
for
the
signature,
and
I
feel
like
cosine
has
you
know
without
without
the
existence
of
us
of
a
spec
right,
they've
sort
of
just
thrown
this
work
to
the
registry
implementers
and
it's
possible
that
various
registries
that
are
attempting
to
use
cosine
would,
you
know,
come
up
with
their
own
implantation
and
the
artifact
ultimately
does
not
get
persisted
correctly
with
the
signature
right.
C
The
whole
point
is
to
be
able
to
replicate
an
image
with
the
signature
intact,
and
I
just
I
don't
know
I
I'm
very
I'm
not.
Let's
say
I'm
discouraged,
I
think,
there's
opportunities
here,
but
I
think
you
know
instead
of
rushing
in
to
implement
this
right
away,
we
should
you
know
we
should
keep
like
you
said
we
keep
keeping
a
watchful
eye
on
whatever
everything
else.
That's
happening
right
in
the
process
of
w2
and
I'm
kind
of
wondering
what
does
integrating
cosine
with
tuf
mean
exactly.
C
C
Solution
that
you
want
during
employment
during
deployment,
and
then
you
know
we're
also
you
know
kind
of
thinking
about
do
we
is,
is
the
the
accessory
right.
The
the
signature
artifact
is
that
something
you've
exposed
to
the
users
to
the
ux
at
all,
or
is
that
just
something
that
sort
of
like
metadata
right?
C
But
it
has
to
be
closely
tracked
and
tied
to
the
artifact,
or
do
you
treat
that,
as
you
know,
if,
if
we
have
to
treat
this
as
a
special
artifact
right
think
about
what
that
means,
that
means
we
obviously
have
to
add
some
additional
logic
to
the
back.
End
right,
add
a
bunch
of,
if
else
or
whatever,
to
to
make
sure
that
that
does
not
get
exposed
to
the
ux
and
that
you
know
all
the
different
policies,
around
retention
and
immutability.
C
These
would
not
apply,
or
these
would
apply
to
the
signature
right,
but
in
a
very
specific
way.
I
don't
think
we
want
to.
You
know
like
some
of
the
things
that
the
use
cases
wanted
to
talk
about.
I
agree
with
him.
I
don't
think
we
want
to
implement
someone
to
like
the
cosine
functionalities
around
copying
and
cleaning,
because
it's
just
very
I
mean
it's
very
proprietary.
It
feels
like.
I
don't
know
if
it
makes
sense
for
harvard
and
from
that
logic,
but
for
us
you
know
we
have
to
think
about.
C
Do
we
allow
the
user
to
to
modify
the
signature
right?
Do
we
allow
do
we
allow
him
to
attach
multiple
signatures?
What
happens
if
you
push
the
same
artifact
with
different,
multiple
times
right,
but
with
different
signatures?
How
is
that
treated
in
harbor
right?
There's,
just
a
lot
of
different
use
cases
to
think
about,
because
the
nature
of
what
a
signature
is
and
how
it's
it's
tied
to
the
image
has
completely
changed.
C
C
So
you
know
they're
they're,
positives
and
negatives,
with
both
approaches,
so
we're
just
trying
to
evaluate
whether
we
should
look
into
supporting
cosine
at
all
right.
So
this
pull
request
is
a
design,
it's
a
design
pr
under
the
community
repo.
So
I
would
appreciate
if
everyone
can
take
a
look
and
add
your
thoughts
if
you've,
if
you
have
come
across
this
issue
and
have
been
thinking
about
been
thinking
about
notary
or
if
you're,
watching,
cosign
and
think
about
some
of
the
experiences
right
of
managing
the
signature
and
like
well.
C
C
Solving
them
the
biggest
the
biggest
so
this
whole
project.
The
motivation
for
this
for
looking
into
cosine
was
you
can't
replicate
a
assigned
image
to
another
registry
so
from
one
heart
to
another.
You
can't
do
that
because
the
basically
the
the
domain
right,
the
fqdn,
is
embedded
into
the
signature
itself.
So
when
you,
when
you
replicate
it,
it
gets
broken
and
right
there.
So
there's
this
effort
to
improve
notary
to
build
a
notary
for
the
multi-registry
world,
and
you
know
it's:
it's
been
an
active,
it's
an
active
community.
C
You
know
they
they're
kind
of
they're
a
little
bit
frustrated
right
and
I
think
that's
what
you're,
seeing
in
other
organizations
right.
A
lot
of
companies
have
to
have
the
requirements
to
ship
signed,
artifacts
right,
they
need,
they
need
province
for
their
customers,
indicating
hey.
This
is
indeed
signed
by
microsoft
or
sun
by
aws
or
some
by
google
or
whatever,
and
I
think
that's
what
that's.
Basically,
where
you
know
cosine
six
store
came
from.
C
It's
there's
an
urgency
to
solve
this
issue,
but
you
know,
unfortunately,
we're
sort
of
at
a
crossroads
or-
or
you
know
thinking
about
supporting
this-
I
mean
I
don't
want
to
do
it
just
purely
to
solve,
supporting
you
know
replicating
to
sign
image.
If
it's
a
lot
of
work
to
us
and
if
it
you
know
if
it's
inferior
to
notary
in
every
other
way,
it
doesn't
make
sense
to
me.