►
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).
B
So
for
this
meeting
I
just
want
to
do
a
brief
update
of
the
hardware
2.0
progress
and
then
we'll
do
a
quick
demo
of
the
harp.
The
current
2.0
web
interface
then
we'll
take
some
questions,
and
so,
first
of
all,
you
know.
2.0
is
the
next
version
of
harvard
that
we're
releasing.
C
B
Like
mid
april
to
late
april-
and
basically
you
know,
we
call
it
2.0,
because
it's
the
next
iteration
of
harbor
and
it
will
support
other
cloud
native
artifacts
beyond
just
home,
charts
and
container
images,
and
so
you'll
be
able
to
host
things
like
synapse,
opas,
etc,
and
we
did
this
by
conforming
to
the
oci
spec.
So
there's
a
runtime
spec
and
there's
an
image
spec.
B
So
there's
significant
changes
in
the
harvard
architecture
on
the
engineering
side,
and
so
there's
going
to
be
a
big
change
on
the
apis,
and
so
the
upgrade
and
migration
is
a
big
effort
that
we're
working
on
currently
and
so
what's
done
already,
is
the
basic
artifact
module
some
of
the
features
like
retention
immutability,
I
think
replication
scanning
are
all
taken
care
of
and
garbage
collection
was
finished
recently,
actually
replication,
we're
doing
right
now,
application
quota
scanning,
upgrading
and
migration
and
then
we'll
be
doing
some
conformance,
there's
an
official
oci
conformance
test
for
registry
vendors.
B
A
By
the
way,
a
quick
update
for
everybody,
so
in
the
past,
we've
communicated
that
we're
going
to
ship
hardware
to
the
low
near
cubic
on
time
frame.
So
it
looks
like
you
know,
some
of
the
work
taking
longer
to
bake
than
expected
and
we're
gonna
push
the
the
release
out
by
a
couple
of
weeks.
So
we're
hopeful
that
we're
gonna
release
to
the
dough
by
end
of
april
and
there's
several
members
of
the
community
that
have
talked
about
wanting
to
come
in
and
help
us
test
and
validate
this.
B
Okay,
so
this
is
the
2.0
interface,
so
it
hasn't
changed
too
much
on
the
previous
1.0
for
the
1.x.
But
you
know:
we've
added
a
dark
mode
right
now,
and
so,
when
you
come
into
the
web
ui
most
of
the
modules
they're
still
there.
B
But
if
you
go
into
the
projects
tab,
so
I
have
a
project
here
called
oci.
The
purpose
of
this
demo
that
I've
created
a
repository
with
four
artifacts
and
if
we
drill
into
it,
we
can
see
artifacts
that
were
pushed
onto
harbor
from
different
tooling
there's.
We
use
the
synaptic
oci
client,
as
well
as
an
aorus
client
which
are
both
for
pushing
scene
abs
and
we
can
also
push
helm
via
helm3,
so
there's
a
chart
here.
B
This
is
a
basic
container
image
and
these
two
are
synapse
that
were
pushed
via
signature
and
ors.
You
can
tell
based
on
the
logos
that
we
we've
added
here.
A
So
if
we
play
hey
alex
really
quickly,
I'm
assuming
I'm
gonna
replace
the
logos
for
something
that
supports
dark
mode
versus
just
regular
mode.
Right,
like
the
logos,
are
need
to
be
inverted
as
well
like
the
helmet
logo,
I'm
assuming
they
have
a
dark
mode
logo
as
well.
That
that's
one
point
of
feedback,
so
we
need
to
make
sure
that
that
happens.
A
The
second
thing
is
under
tags.
What
it
is,
if
it
says,
image
or
chart
like,
for
example,
a
home
chart,
is
the
actual
name.
The
chart
is
see
the
capitalized
and
the
cena
bundle
is
an
acronym
right,
so
it
needs
to
be
capitalized
as
well.
So
let's
make
sure
that
the
actual
name
that's
under
the
tag
conforms
with
the
true
name
of
whatever
the
artifact
is
the
the
second.
C
A
The
second
thing
I
want
to
mention
for
everybody
is
in
the
past
when
hardboard
had
artifacts
in
the
repository.
If
you
didn't
have
a
tag
for
something
like,
for
example,
latest
or
version
1.2,
you
couldn't
release
it
in
the
ui.
Now
you
can
so
that's
actually
a
big
change
from
what
you
had
in
the
past.
Then
now
you
can
actually
see
all
artifacts
that
are
part
of
a
repository,
whether
that
have
a
tag
or
not,
and
it
will
make
it
a
more
usable
experience.
B
Yeah,
so
we're
going
to
do
a
fit
and
finish
for
the
ui
there's
lots
of
things
that
so
this
is
definitely
not
the
polished
version.
This
is
just
what
we
have
the
first
of
the
demo
right
now,
but
anyway,
yeah
going
into
an
artifact
right.
This
is
just
a
container
image,
so
you
can
see
the
biggest
change
from
the
previous
version
was
that
on
the
previous
ui,
every
row
within
the
repository
page
represents
a
tag,
and
here
we've
consolidated
all
tags
onto
a
single
artifactor,
so
the
tags
are
just
metadata.
B
One
of
the
problems
we're
trying
to
solve
was
on
the
previous
one
point
x.
Whenever
you
deleted
a
docker
tag,
you
end
up
deleting
the
image
digest,
which
means
looking
all
the
other
associate
tags.
So
by
creating
a
separate
artifact
struct,
another
data
structure,
we
were
able
to
separate
the
hardware
tags
or
the
docker
tags
from
the
artifact
itself
right,
so
you
can.
The
user
interacts
with
the
hardware
tags
without
actually
deleting
the
docker,
the
deleting
the
digest
so
on
on
an
artifact.
You
can
see
the
list
of
tags
that
is
associated.
B
You
can
also
add
and
remove
tags.
So
this
part
is
completely
new.
There's
some
extra
x
extra
attributes
here
the
architecture
os
things
like
that.
B
And
then
we
have
a
helm
chart
here,
so
you
can
see
all
the
attributes
from
the
helm
chart
that
was
pushed.
This
is
pushing
me
at
home.
Hum3
also,
you
can
add
tags
to
it,
do
scanning,
etc
and
then,
finally,
this
is
a
scene
app,
so
scene.
App
is
basically
a
bundling
of
images.
It
leverages
the
oci
image
layout,
so
it's
what's
called
fat
manifest,
which
is
a
json
that
bundles
together
a
bunch
of
a
bunch
of
container
images.
So.
B
So
this
scene
app
is
there
isn't
any
images
bundled
within?
But
if
it
had
images
bundled
within,
you
could
drill
into
it,
and
you
can
look
at
the.
For
example,
look
at
the
attributes
and
the
vulnerabilities
at
the
individual
reference
image
level.
You
can
also
see
the
the
scan
result
of
a
complete
bundle.
A
Hey
alex,
you
want
to
talk
a
little
about
the
discussion
we
had
yesterday
about
how
we
do
vulnerabilities
and
cena
bundles
when
they
are
referenced
versus
included.
B
B
It's
possible
that
you
know
we
can
only
scan
partial
xena,
we're
going
to
scan
parts
of
the
reference
images,
in
which
case
we
would
show
like
a
partial,
a
partial
success,
and
so
we
have
a
partial
success
in
addition
to
it,
just
a
success
or
a
fail.
B
Because
so
the
value
of
the
scene
app
is
the
reason
it
was
popular.
B
At
least
you
know
I
think,
last
year
it
got
a
lot
of
traction
because
it
allows
image
relocation,
so
it
solves
a
very
specific
problem
around
inventory
location,
which
means
that
you
know
the
cnap
bundle
itself
could
sit
somewhere,
but
the
reference
images,
the
reference,
the
reference
images
within-
could
be
relocated
to
another
private
registry.
B
Registry,
so
these
are
the
artifacts
that
we
can
host
on
harbor.
We
also
work
keeping
the
helm
charts
for
now.
So
this
is
home
charts
that
were
uploaded
via
char
museum.
This
will
most
likely
be
deprecated
at
some
point
and
we'll
have
all
harm
charts,
consolidating
a
single
place.
So
right
now
there
are
two
places
you
can
see
home
charts
here
and
within
the
repositories
as
well.
B
Just
coming
from
the
oci
image,
spec
and
there's
some
changes
like
the
labels
are
now
at
the
artifact
level.
Instead
of
at
the
tag
level
and
there's
also
some
change
to
the
behavior
of
tag
retention
and
quotas,
it's
a
little
complicated
I'll,
probably
go
over
that
for
the
next
community
meeting.
Once
that's
finished
up.
C
B
Don't
think
scanning
is
possible
for
home
charts
right
now,
at
least
the
scanner
that
we
have
right
now
so
the
scanning
for
the
scene.
Abs,
is
just
scanning
each
individual
reference
image
and
then
it
will
aggregate
those
into
a
single
report
back
to
okay
on
the
ui.
B
So
you
can,
you
can
drill
into
the
scene
app
or
you
can
draw
you're,
basically
drilling
into
an
ocean
index.
The
behavior
of
cnn
follows
the
behavior
of
ocean
index,
which
means
we
allow
viewing
at
the
individual
level,
but
we
don't
allow
actions
like
deleting
them.
B
Okay,
so
you
can't
replicate
a
reference
image
within
an
oci
index
unless
it's
outside
of
the
index
itself
right,
so
it
could
be
shared.
It
could
be
something
that
was
pushed
previously
prior
to
the
usa
index.
It
could
be
shared
if
they
existed
outside
outside
of
those
index.
Then
you
can.
You
can
operate
on
it
because
it'll
be
shown
separately
on
a
separate
line,
but
if
it's
a
part
of
those
index,
then
you
can
only
view
it.
You
can't
delete
it.
You
can't
scan
it,
etc.
B
C
B
Yeah,
definitely,
I
don't
think
we've
had
time
to
really
look
into
that
for
now,
because
most
of
the
effort
is
concentrated
on
making
sure
on
the
existing
feature
set
of
hardware
works
for
2.0.
So
that's
taking
up
a
lot
of
time,
but
the
next
step
yeah
to
expand
support.
We
always
lack
a
lot
of
things
like
tag
retention.
B
That's
also
missing
for
thumb
chart.
So
we
want
to
get
that
feature
parody
for
helm
char,
as
well
as
comparisons.
C
Yeah
we've
been
thinking
about
that
at
encore
as
well
kind
of
what
what
what
scanning
a
helm
chart
really
means
and
how
and
how
it
could
be
implemented.
So
that's
certainly
a
discussion.
I'd
be
interested
in
having
with
you
guys,
moving
forward
understanding.
C
B
B
So
that's
basically
all
I
have
for
this
demo.
I
think
some
of
the
apis
are
done
for
for
like
the
replications
and
quotas,
but
I
don't
have
a
lot
of
confidence
that
it
works.
So
you
know
for
this
community.
It
was
mostly
about
demonstrating
how
the
artifacts
would
show
up
on
the
harper
ui
and
some
of
the
debris
change.
B
All
right
so
does
anyone
have
any
other
questions
related
to
the
project.
C
B
So
it's
upgradable
from
the
previous
release,
we're
working
on
that,
but
the
api
has
basically
changed.
Yep
the
apis
have
been
bumped
up
to
to
the
next
version.
A
C
B
Oh
okay,
so
then
so
that's
a
demo
for
the
harbor
ui
2.0
and
then
for
2.0.
We're
also
going
to
be
releasing
an
operator
harbor
a
harbor
operator.
This
is
this
was
based
on
work
that
someone
else
had
been
doing
and
they
reached
out
to
us
to.
You
know,
to
open
source
the
operator
under
the
go
harbor
repo.
B
So
this
is
something
that
you
know
the
community
has
been
asking
for
for
a
long
time
and
you
know
we're
glad
that
someone
else
already
got
started
on
it.
So
if
anyone
has
interest
in
you
know
contributing
to
the
hardware
operator
or
just
giving
some
requirements
definitely
check
that
out,
we'll
probably
open
source
it
under
as
a
separate
project
under
the
go
harbor
repo
very
soon
in
the
next
week
or
two
probably.
B
So
this
will
help
us
address
some
of
the
current
shortcomings
of
you
know
the
docker
compose
or
the
helm
version
of
harbor.
You
know,
which
is
you
know,
lacking
in
high
availability,
right
and
certain
deployment
models,
so
the
harbor
operator,
which
is
divided
into
several
components,
will
have
you
know:
enterprise
grade
high
availability,
which
means
they
tree
for
the
redis
component,
h.a
for
the
pg
sequel.
B
So
that's
basically
the
two
big
announcements.
This
is
all
coming.
You
know
very
soon
in
the
next
month
or
so
2.0
in
the
operator.
A
Cool
well,
we
can
probably
end
this
call
early
if
nobody
has
any
concerns
or
anything.
Obviously,
I
actually
start
putting
him
up
the
finishing
touches
for
harvard
to
know.
If
anybody
has
cycles
to
help
us
either
we're
back
fixing.
Like
I
mentioned
earlier,
or
even
writing
some
documentation
or
validating
some
scenarios,
we
would
love
to
see
that,
obviously
we
want
to
get
more
and
more
of
the
community
engaged
zach.
We're
gonna,
look
to
you
and
some
of
the
other
partners
that
you
have
in
the
plugable
scanner
framework
to
validate
their
plugable
scanners.
A
Once
you
have
some
early
builds
of
of
the
of
the
release
so
ahead
of
time,
thanking
you
for
that
work
that
you
guys
are
gonna
do,
but
other
than
that
you
know
we
will
keep
moving
forward,
we'll
be
at
cubicon
in
in
amsterdam
and
and
hopefully,
by
end
of
april,
have
a
really
really
solid
release.
B
Sorry,
for
my
thing,
this
is
different.
I
mean
that
you
know
some
other
another
customer.
I
guess
had
some
requirements
around
scanning
build
packs
again
build
packs
which
are
not
built
with
you
know,
a
typical
application
manager.
So
I
don't
know
if
there's
something
that
you
know
we
could
talk
about
this
offline
zach.
B
This
is
they're
using
their
user
harbor,
but
they
can't,
you
know,
scan
their
proprietary
bill
packs
because
they've
been
using
claire,
and
so
I
told
them
that
you
know
with
the
plugable
scanning
framework
we
can
now
they
can
use,
I
mean
from
from
their
from
their
perspective
of
using
hardware.
They
can
use
any
scanner
that
works
right.
So
I
don't
know
this
is
something
that
encore
can
can
cover,
but
we
can
chat
about
that.
C
Yeah
yeah
for
sure
you
know
in
terms
of
our
road
map,
we
should
be
around
the
same
time
as
you
guys
will
be
releasing
the
2.0.
We
should
be
releasing
our
next
enterprise
version
of
encore,
which
will
include
windows,
image,
support
as
well
windows
scanning
and
then
in
the
future.
We're
also
looking
towards
support.
You
know,
like
I
said,
scanning,
helm,
charts
and
stuff,
so
they're
kind
of
those
language.
Those
packages
are
certainly
top
of
our
mind
for
some,
the
semantics
of
what
scanning
them
means.
B
All
right:
well,
no
thanks
for
attending
the
next.
The
next
community
will
probably
try
to
highlight
you
know
some
of
the
specific
differences
from
the
debate.
Change
from
the
previous
version.
Like
you
know,
the
behavior
around
attack
retention
and
quotas,
there's
definitely
going
to
be
some
changes
there
and
hopefully,
we'll
have
you
know
a
cleaner,
ui
and
yeah
all
demos,
pushing
some
artifacts
to
the
hardware
registry,
so
yep.