►
From YouTube: Che Community Meeting June 21st 2021
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
B
Yeah,
so
my
team
is
a
deaf
health
services
team
and
I've
got
two
people
who
are
mostly
working
on
the
naf,
how
much
tree
itself
john
kohler
and
jinfuan.
They
will
be
talking
about
the
davao
to
all
rights
tree
itself,
so
that
we
can
sync
up
on
that
john.
I
will
let
you
take
over.
E
John
and
elton
so
before
you,
you
yeah,
because
you
before
you
move
forward
with
the
presentation,
can
I
just
say
a
couple
of
words
just
to
link
that
so
because
in
j
we
already
have,
we
have
a
def
registry
and
that
registry.
So
we
are
currently
moving
from
the
file
v1
to
method
v2,
and
we
we
have
right
now.
I
think
we
only
have
one
def
file
version,
two,
so
the
but
the
the
thing
is
that
there
is
in
red
hat
another
effort.
E
So
there
is
a
new
team
that
is
mainly
driving
the
evolution
of
the
dev
file
with
other
companies
even
outside
from
reddot,
and
that's
what
elson
team
is
actually
doing
just
just
to
provide
a
context
for
who
is
not
aware
of
of
that
and
they're
also
responsible
for
creating
a
new
service.
That
is
the
dev
file
registry.
That
eventually
will
be
an
online
service
so
that
any
client
will
will
be
able
to
get
dev
files
from
hub.file.io.
E
E
The
our
default
registry-
oh
yeah,
so
I
will
let
john
go
ahead
with
the
demo
sure.
C
All
right
can
everyone's.
Can
everyone
see.
C
All
right
so
yeah,
let
me
just
give
a
bit
of
a
background.
Mario
nelson
already
kind
of
covered
it,
but
yeah
alison
jenkins,
and
I
were
from
the
dev
file
project,
default.io
or
github.comfile,
and
yeah
we're
responsible
for
the
default
specification
and
dev
file
associated
projects
like
the
default
registry
or
default
library
and,
in
addition
to
eclipse
che
defaul,
is
also
used
in
the
odo
cli
and
the
openshift
developer.
Console
and
yeah
aws
recently
joined
the
project
as
well,
which
is
nice
to
see
and
so
yeah.
C
Today
we
want
to
give
a
quick
overview
of
the
v2
dev
file
registry,
so,
let's
get
into
it
so
much
like
the
default
registry
in
let's
deployed
along
eclipse
j,
it
serves
the
v2
default
registry,
serves
file
stacks
and
samples
to
developer
developer
tools
and
so
a
stack
that
a
def
file
stacker
sample,
that's
based
around
the
default
2.0
spec
may
consist
of
any
number
of
files
like
a
default.yaml
plugins
deployment,
manifest
starter
projects,
etc,
really
any
number
of
files,
and
so
these
stacks
and
samples
are
treated
as
oci,
artifacts
and
stored
in
an
oci
registry.
C
C
Much
like
the
eclipse
jdef
file
registry
are
sourced
from
a
git
repository
so
for
the
default
registry
service
that
are
that
we're
managing
it's
deployed
from
github.com
registry
and
another
thing
to
add
in
terms
of
like
the
architecture
is,
it
consists
of
two
containers:
an
oci
registry
server
and
a
devfile
index
server.
C
So
an
oci
registry
server
is
just
a
reference
registry
implementation
from
cncf.
I
think
docker
recently
donated
a
few
months
back
and
the
default
index
server
has
three
functions:
basically,
first,
it
bootstraps
the
oci
server
with
dev
files
from
a
source
repository
like
the
dev
file,
slash
registry
repository
I
mentioned
earlier.
C
It
hosts
the
default
index.json
for
tools
to
consume,
and
it
also
provides
an
api
for
retrieving
these
dev
file
stacks
from
the
oci
registry
and
on
the
side.
Here
you
can
kind
of
see
the
a
rough
crude
drawing
of
the
relationship
between
the
stacks
and
the
github
repository
and
the
oci
artifacts
that
they
represent
inside
the
registry.
C
And
so
I
kind
of
touched
on
this:
just
now
was
the
index
server
and
it
it
hosts
the
default
registry
index
of
the
index.json
that
provides
metadata
about
the
dev
files
inside
the
registry,
and
so
this
is
based
on
the
index.json,
that's
used
in
the
jdef
file
registry
and
much
like
it.
It
provides
important
metadata
about
the
tools
about
the
default
entries
in
the
registry,
such
as
the
stack
name
associated
tags,
what
project
type
or
language
that
belongs
to
the
reference
to
the
artifact
itself,
etc.
C
C
First
off,
like
I
mentioned
earlier
default,
2.0
stacks
can
be
composed
of
multiple
files,
and
the
oci
spec
has
a
good
support
for
serving
multiple
files
as
a
single
distributable
artifact,
which
we
liked.
C
It's
also
got
good
support
for
inheritance,
which
the
default
2.x
back
supports.
It
can
support
multiple
versions
of
a
given
artifact.
It
allows
us
to
share
common
layers
across
stacks,
so
if
multiple
defile
stacks
or
samples
share
a
common,
artifact
or
file,
it
means
it
only
has
to
be
stored
once
on
the
registry
server
and
can
be
reused
across
multiple
stacks,
which
is
nice,
and
it's
also
got
good
support
for
multi-arch
artifacts,
which
we
again
want
to
support
in
the
future.
C
So
there's
three
types
of
death
file:
registries:
the
first
is
what
we
call
the
community
dev
file
registry
and
ken
mario
touched
on
this
just
a
little
earlier.
It's
at
registry.default.io
serves
default
stacks
based
on
open
source
projects,
its
main
consumer
right
now
is
odo
and
the
openshift
developer,
console
or
odc,
and
our
hope
is
that
che
can
consume
this
registry
as
well
in
the
future.
C
There's
also
the
idea
of
a
product
file
registry
that
various
organizations
can
build
file
registries
to
serve
vendor-specific,
dev
files
and
then
there's
also.
The
idea
of
you
know
bringing
your
own
or
deploying
your
own
default
registry,
and
so
this
can
be
deployed
on
any
openshift
or
kubernetes
cluster
via
olm
or
helm.
Che
could
also
consume.
The
olm
bundle
has
a
dependency
if
needed
if
they
wanted
to
deploy
their
own
default
registry
and
the
default
registry
library,
which
is
just
a
golang
based
library
for
interacting
with
v2
default
registries,
will
also
support.
C
So
now
I'm
going
to
just
switch
over
to
jingfu
who's,
going
to
give
you
some
a
bit
more
in-depth
information
on
the
registry
itself.
D
B
G
Yeah
cool
yep,
so
the
definite
registry
build
process
is
pretty
straightforward.
Therefore,
service
team
provides
the
vo2
and
the
only
thing
that
the
consumer
needs
to
do
is
to
pass
the
delta
registry
resource
folder
pass
to
the
field
to
the
delphi
registry.
Results
folder
partially
include
multiple
dell
file
entries
and
each
individual
device
entry.
It
can
include,
therefore,
the
yamo
icon
or
autoloop
configuration,
etc.
G
So
the
so
once
the
build
to
receive
the
path
the
build
will
generate:
embed.json
for
the
delta
registry,
according
to
the
delta
retrieval
resources,
and
for
more
details
that
bill
2
will
use
the
internal
integer
generator
in
that
internally.
That
generator
will
automatically
detect
and
pass
the
delta
registry
resources
and,
finally,
consolidated
consol
consolidated
everything
into
the
index.json.
G
So
after
that,
the
built-in
will
archive
the
delta
registry
resources,
because
we
want
to
see
more
space
on
delta
registry
set,
but
on
consumer
side,
consumers
doesn't
even
worry
about
anything.
When
connect
consumer,
we
will
have
consumer
extract.
Therefore,
retro
resources.
When
consumers
pull
the
resources,
everything
should
be
exactly
the
same
as
same
as
the
consumer.
Push
all
the
resources
to
the
developer
registry
set.
G
So
the
last
lastly,
the
build
will
build
the
device
registered
image
to
packing
data
json
on
the
device
registry
resources
based
on
the
delphi
registry
base,
image,
which
means
the
output
of
the
vo2
will
be
the
the
delta
registry
image
and
after
that
the
consumer
can
push
the
data
registry
image
to
any
docker
image
registry
that
consumer
specified.
G
G
So,
if
consumers
cluster
have
the
olm
install
consumer
can
use
operator
to
deploy
that
our
registry,
because
we
already
developed
the
delta
registry
crd
and
the
consumer
once
they
consume
reinstall,
the
operator
consumer
can
use
the
operator
to
create
and
manage
the
delphi
registry,
crd
and
consumer
installed.
The
operator
and
the
consumer
then
think
this
consumer
can
deploy
the
delta
registry
by
specifying
the
delphi
registry
image
that
we
build
on
the
previous
step
so
for
help
chart.
G
The
dell
file
service
team
provides
the
home
chart
and
consumer
only
need
to
install
the
home
ci
and
run
how
means
document
to
deploy
the
data
registry.
So
if
consumer's
cluster
doesn't
have
oil
installed
so
hand,
charge
is
really
useful
for
for
them
to
deploy
the
dell
file
registry
next
slide.
G
So
once
we
deploy
the
delphi
registry
successfully
the
then
we
will
have
a
way
to
interact
with
delphi
registry.
Currently
we
have
two
ways
to
interact:
interact
with
registry
first
one
is
a
registry
reset
api.
Second,
one
is
registered
library
which
is
written
by
go
language.
So
if
the
consumer's
product
is
written
by
go,
it's
very
convenient
for
consumer
to
directly
import
our
registry
library
to
interact
our
dell
registry,
for
example.
G
Currently
the
auto
already
integrated
with
our
file
registry
library
to
interact
with
our
public
developer
registry,
so
the
so
that
all
the
functioning
memphis
will
work
similarly
for
auto,
so
we
provide
multiple
functionalities.
For
example,
we
by
using
the
retrograde
api
or
library
we
can
list
dev
our
entries
with
filter
support.
G
Currently,
we
support
the
filter,
the
dell
functions
by
by
type,
but
in
the
future
we
want
to
support
a
filter
by
tag
and
the
filter
by
versions
and
consumer
also
can
use
use
our
interface
to
view
the
yamo
and
the
model
of
each
development
tree
to
see
more
details
of
each
default
entry
and
also
we
support
download
their
file
entry
to
directly
download
the
the
whole
entry
from
dell
file
registry
and,
for
example,
for
example,
for
for
the
consumer
auto.
G
So
the
delphi
retroviewer
is
a
current
project
that
we
are
working
on,
so
it
is
a
ui
for
browsing.
The
downfall
registry,
we
design
two
pages.
The
first
one
is
the
main
page.
Second,
one
is
delta
page,
so
main
page
is
used
for
viewing
the
registry,
so
consumer
can
filter
the
file
by
name
type
in
the.
G
And
the
default
page
teacher
can
view
the
data
file
and
download
the
starter
project
by
by
clicking
by
clicking
the
specific
starter
project
from
the
ui.
So
next
slide.
G
So
this
is
switch
out
of
the
the
main
page
that
I
talked
before.
So
we
can
see
in
the
main
page
we
have
consider.
We
testified
by
the
delta
energy
tax
and
also
in
the
search
bar.
We
can
specify
the
name
titan
description
once
we
have
the
searching
criteria,
we
can
directly
see
the
output
of
the
from
the
registry
and
they
usually
can
click
the
specific
delta
entry,
some
either
sample
or
stack
directly
from
here,
so
next
slide.
G
So
this
is
a
page
that,
after
we
click
the
specific
file
for
our
entry,
so
the
it
can
direct
us
to
this
page.
For
the
in
this
page,
we
can
see
the
icon
of
the
entry.
We
can
see
the
metadata
or
the
detail
information
we
can
see
the
actual
of
the
yamo
and
also
we
can
choose
the
starter
project
and
then
click
the
download
download
button
to
download
the
specifics
on
the
project.registry
and
next
slide.
G
So
this
side,
we
list
all
the
reference
material
that
we
thought
we
talked
about
today.
So
we
can
see
we
have
the
source
repository
and
the
documentation.
If,
if
you
want
to
check
more
details
of
of
the
topic
today
and
check
the
checkbook
here,
so
thank
you
so
much.
That's
a
demo
for
our
delta
registry
v2.
C
I
I
think,
we're
probably
about
to
say
the
same
thing:
jingfu
any
questions
or
comments
on
this
or
concerns.
J
I
Amy,
yes,
yes,
okay,
so
the
question
was
who
was
supposed
to
use
the
fire
registry?
If
this
is
as
I,
if
this
is
the
same
thing
for
for
che,
the
default
registry
should
be
used
by
developer
teams
and
should
be
a
registry.
But
you
find
that
five
of
projects
they
are
using
daily.
I
So
are
there
going
to
need
to
have
the
cube
admin
rights
to
modify
the
depak
registry
and
add
their
own
depth
fight
in
the
registry?
Or
is
there
something
that
would
simplify
that?
That
problem.
B
Yeah,
so
so,
in
order
to
get
on
new
dev
files
into
that
file
registry,
you
just
need
to
submit
a
pr
on
directory
source
because
there's
actually
a
build
process
that
john
and
jane
feel
mentioned
before,
so,
basically
that
we
actually
pull
from
the
registry
source
repro.
So
if
you
need
a
new
entry
to
be
added
to
the
device
3,
all
you
need
to
do
to
submit
the
pr
on
that
repro.
On
the
reference
page.
B
So
yeah,
so
if
you're
building
your
own
file
registry,
we
are,
we
will
be
creating
a
build
tools
for
you
to
like
build.
So
basically
you
can
point
to
your
own
registry
and
the
build
tool
doing
is
doing
the
same,
build
process
as
what
we
are
doing
for
our
public
community
industry.
That
allows
you
to
convert
like
a
regular
repro
and
then
convert
your
oci
based
directory
images.
After
that,
then,
you
can
use
your
hammer
or
operator
to
deploy
to
your
own
cluster
for
your
own
registry.
C
So
if
you
want
to
update
the
stacks
in
a
register,
you've
deployed,
you
would
need
to
just
update
the
deployment
on
your
cluster
to
to
reference
a
new
container
image
with
those
updated
dev
file
stacks
and
about
your
question
right.
Writing.
Kubin
writes,
so
you
would
need
kube
and
min
writes
to
deploy
the
registry,
but
you
would
only
need
necessary
permissions
to
actually
update
the
container
image
which
still
may
be
more
than
what
the
average
user
has
on
a
cluster.
C
But
you
certainly
won't
kuben
writes
to
deploy
the
helm
chart
either.
I
F
B
Yeah,
so
you
need
to
open
the
piano
for
sure.
We
are
working
on
the
contributing
md
to
basically
going
through
the
process
in
order
to
get
you
the
public
community
registry,
it
needs
to
like
there's
certain
validation
that
we're
doing
on
the
as
part
of
the
registry
bill
that
will
be
basically
validating
to
making
sure
that
the
that
file
is
actually
in
front.
B
We
will
also
have
some
extra
info
some
extra
requirement
in
terms
of
metadata
associated
with
it,
so
they
will
actually
show
up
on
the
registry
viewer
properly
and
also
the
tools
can
actually
carry
and
consume
it
properly
in
those
cases
so
yeah.
So
it's
mainly
submitting
pr
and
then
following.
I.
F
B
It's
actually
a
like,
because
the
there's
actually
two
things
right.
The
the
the
registry
itself
is
part
of
the
cncf
initiative
that
we
are
actually
applying
to
open
source
under
cncf
project,
so
it
will
be
governanced
by
the
cncs
cmcf
project
by
the
time
they
actually
go
to
sandbox.
Currently,
today,
is
it's
actually
whoever
that
is
actually
the
contributor
and
you're
right
today
is
still
right.
Hey
it's
the
main
contributors.
We
already
have
got
aws
joining
our
project
on
that.
So
it's
just
just
like
any
other
open
source.
G
B
F
So
that
was
question
number
one
number
two
was.
It
seems
to
me
that,
from
a
client's
point
of
view,
who
will
not
write
to
to
the
dev
file
registry
because
we're
that's
actually
a
special
case
right
j,
for
example-
would
probably
not
update
the
dfl
registry.
F
F
Is
there
a
plan
to
to
separate
what
is
essential
in
the
api
as
what
clients
need
to
function
and
what
we
need
to
er?
A
lot
of
the
things
I've
heard
now
seem
to
me
implementation
details
of
of
what
the
registry
should
be
right
and
not
what
what
j,
for
example,
would
would
use
for
j.
It's
probably
much
simpler.
We
don't
need
the
we
need
to
build
an
image
to
to,
for
example,
that's
a
for
me.
That's
a
an
implementation
detail
that
this
is
an
image
that
we
upload.
F
B
B
So
let's
say
if
you
are
a
particular
stack
that
you
want
to
supply
to
the
device
rs3,
the
default
itself
will
definitely
be
part
of
the
registry
itself,
but
if
you
actually
want
to
continue
control
the
the
the
container
itself,
you
can
actually
point
the
container
to
some
other
locations
for
which
you've
got
your
own
image
registry
for
it,
and
you
can
actually
deal
with
the
life
cycle
of
those
images
itself.
B
So,
from
the
shade
perspective,
when
you're
consuming
the
devil
registry
is
more
for
it's
more
for
getting
a
catalog
of
things
and
then
it's
similar
to
what
the
shape
that
fire
registry
that
you
have
today,
basically
a
cut
off
that
files
that
you
can
actually
access
to.
But
then
that
files
can
actually
point
you
in
terms
of
the
continuing
images.
The
dev
files
can
actually
con
points
to
other
locations
where
you
can
actually
pick
up
the
images
from
I'm
just.
F
Thinking
that,
for
example,
for
testing
setups
etc
would
be
much
easier
if
the
client
api
would
just
be
here's
an
api
description,
here's
a
socket
and
a
port
and
right
now
it
seems
like
the
whole.
It
needs
to
be
images
it
needs
to
be.
It
needs
to
be
an
oci
compliant
registry,
and
that's
just
setting
that
up
in
it
seems
like
a
lot
of
a
lot
of
complexity
that
isn't
needed
on
the
client
side
right.
So
I
don't.
F
B
Set
up
your
own
container
in
that
case,
right
you'll,
be
talking
to
your
registry
you'll,
be
just
calling
the
registry
like
there's
a
rest
api,
there's
a
library
that
you
can
actually
call
and
you
can
just
grab
it.
I
Maybe
we're
mixing
the
the
specification
of
the
api
and
the
implementation
like
we
have
in
in
java
you,
we
have
two
parts,
the
implementations,
implementation
of
references
we
did
so
this
would
be
the
oci
part,
and
we
have
the
the
the
specification,
which
would
be
how
you
talk
to
you're
talking
to
the
implementation
part
and
how
the
the
client
should
consume
it.
I
So
maybe
this
should
be
separated
in
two
different
things,
but
the
lca
part
would
be
something
that
is
more
specific,
more
of
an
implementation,
a
part,
whereas
the
way
you
will
be
describing
the
the
index.json
and
so
on
should
be
in
the
the
api
spec.
F
B
H
C
Just
to
I
don't
want
yeah,
I
don't
want
to
get
too
into
the
specifics
on
this
call,
but
one
thing
I
just
want
to
add
on
to
what
I
also
mentioned
was
that
the
operator
in
helmshire
in
case
it
wasn't
just
in
case
it
wasn't
clear.
The
operator
helm
chart,
also
managed
the
deployment
and
life
cycle
of
the
oci
registry
itself
too.
It's
not
something
that
needs
to
be
deployed
separately
or
something
that
needs
to
be
pointed
to.
H
And
it
was
covered
at
the
front,
but
I
just
want
to
reiterate
like
why
are
we
talking
about
this
today?
Che
has
a
fairly
impressive
list
of
languages
that
it
supports.
There's,
like
you,
know,
20
or
30
dev
files,
but
it's
a
chase
specific
resource
and
they're
all
basically
maintained
by
the
the
che
team
with
you
know
a
little
bit
of
external
help,
we're
now,
hopefully
talking
about
at
least
three
teams,
two
vendors.
H
Hopefully
that
grows,
but
you
know
we
essentially
share
a
set
of
dev
files.
So
if
somebody's
using
one
of
the
other
tools-
and
they
come
up
with-
you
know
a
dev
file
for
some
other
language,
it
would
just
be
consumable
by
che-
and
hopefully
you
know,
share
the
load
of
maintaining
them,
but
also
increase
the
you
know
the
number
of
languages
and
patterns
supported.
H
D
D
B
Right
so,
okay,
so
there's
variable
things
so
to
answer
your
first
questions
that
that
file
just
like
before
that
file
can
be
part
of
the
project
itself,
so
the
default
definition
is
can
be,
can
be,
can
be
stored
into
a
git
repository
or
something
as
part
of
the
project
results.
And
then
the
project
within
the
dev
file
can
refer
to
your
parents,
because
that's
part
of
the
default
tools
back
and
the
parent
can
be
pointing
back
to
your
community
one.
B
If
you
actually
don't
want,
don't
need
too
much
control
of
your
project
and
you
can
you
can
just
reference
a
parent
onto
existing
stack.
Then
you
can
just
say:
hey,
I'm
a
driver
made
for
navigation.
I
just
use
an
existing
site
and
you'll
inherit,
what's
currently
on
the
public
registry
itself.
So
so
that's
how
you
actually
link
it
back
to
a
particular
community
results.
B
Now,
if
you
actually
want
to
detach
from
it
like
when
you're,
creating
a
data
flower
registry.
Today
I
mean
I
mean
when
you're
creating
a
project
that
contains
that
file.
You
can
choose
to
say
I
just
want
to
clone
what,
which
is
like
makes
basically
making
a
copy
of
the
entire
of
the
entire
defile
instead
of
calling
as
a
parent
and
you
kind
of
detach
it
from
the
the
life
cycle
of
the
community
registry
itself.
B
So
that
means
you've
got
a
couple
of
ways
to
to
reference
it
and
you
don't
need
to
have
the
default
tree
around.
If
you
want
to
project
to
be,
you
know
to
be
self-contained
in
a
sense,
so
we
need
to
use
parents
yep.
So
if
you're,
referring
to
a
particular
committee,
then
you'll
be
having
stored
at
that
file
as
part
of
your
project,
and
you
can
just
call
parents
on
that.
J
I
have
a
question
it
might
be
more
from
mario
florado.
So
what
will
this
look
like
for
offline,
like
air
gap,
support
or
things
where
we
are
manipulating
like
urls,
for
example,
single
host
deployments
like
and
when
we
build
the
dev
file
registry?
There's
a
lot
of
stuff
that
goes
into
the
entry
point
where
we,
you
know,
modify
urls
and
stuff
like
that.
B
Yeah,
so
we
actually
got
an
item
explicitly
for
doing
offline
support.
We've
got
a
proposal
on
that.
I
can
point
you
to
that
item
yeah.
So
there's
a
design
on
that
this
hasn't
been
completed
yet,
but
yeah,
so
we've
got
a
design.
Basically,
what
it
does
is.
B
We
are
actually
doing
tricks
on
the
on
the
registry,
build
side
as
part
of
the
registral,
where
we
are
actually
pulling,
for
example,
starter
project
and
your
project
will
be
packaging
except
within
the
oci
register
itself,
and
then
changing
the
link
to
point
to
the
ocr
registry.
So,
by
the
time
that
client
is
actually
consuming
it,
then
it
will
be
just
returned
referring
to
resources
within
the
ocean
registry
itself.
B
Let
me
find
that
item
and
I
can
actually
you
can
take
a
look
at
that.
Okay,.
H
H
Yeah,
I
just
want
to
mention,
like
all
of
these
things,
jay
has
a
history
of
you
know,
figuring
out
how
these
things
need
to
work
and
how
to
do
offline
support,
and
you
know,
should
defiles
be
in
projects
or
not.
Several
tray.
Architects
were
involved
in
the
v2
and
I
I'd
like
to
think
we've
done
a
good
job.
D
B
Yeah
some
of
the
deaf
hours,
some
of
the
defiles
within
the
half
hour,
history
were
originated
yeah,
we
just
created
it,
and
some
of
them
are
going
to
be
replaced
by
the
middleware
team,
something
that,
for
example,
the
node.js
one
is
actually
kind
of
owned
by
the
middleware
team
and
quackers
one.
The
middleware
team
also
modify
that
also
as
well.
So
the
the
model
that
we're
trying
to
make
is
yeah
just
trying
to
to
get
the
runtime
team
to
actually
own
it
because
they
are
the
most
family.
B
With
the
stack
itself.
I
yeah,
I
think
myron
mentioned
before,
there's
certainly
requirements
for
the
images
that
she
needs
to
be
done
in
order
to
do
that,
I
think
the
best
way
to
handle
this
is
to
if
there's
hr
requirements
on
the
images
making
sure
we
actually
work
with
the
middleware
team
when
they're
preparing
for
that,
and
they
take
that
into
consideration.
E
Just
to
do
you
have
any
so
how
does
authentication
work
so
do
you
have
do
you
have
authentication
or
do
you
have
any
plan
to
add
authentication
for
the
public
registry.
B
Or
there
for
prior
advisory,
because
we
do
have
authentication
plan
for
for
private
advisory
for
public
registry
there's,
it's
all
open,
there's
no
authentications
needed.
B
Yeah
for
the
private
one
yeah,
I
think
we
do
have
an
item
for
authentication,
go
back
and
do
a
check,
but
but
yeah
that's
definitely
will.
G
E
B
For
example,
in
in
the
case
of
a
vendor-specific
registry,
they
may
decide
that
you
need,
let's
say,
a
right-hand
login
or
something
to
access
those
images.
So
that
is
the
type
of
authentication
that
we're
looking
for,
but
I
don't
think
we
actually
talk
about
authenticating
when
accessing
the
actual
registry
itself
like.
B
If
that
is
actually
a
requirement,
we
can
talk
about
it
and-
and
we
can
add
it
to
to
the
list
as
well,
but
currently
what
we
are
aiming
for
is
more
for
in
case
your
the
images
that
your
dev
file
is
referring
to
is
actually
hiding
behind
login.
Then
that's
the
authentication
that
we
were
looking
for
and
based
on
the
last
discussions
on
kapoho
call.
I
think
the
that
is
actually
geared
towards
most.
Ladies,
the
tools
actually
when
trying
to
accessing
the
images,
then
that's
where
the
authentication
occurs.
B
A
All
right,
this
is
honestly
a
huge
topic
and
very
exciting
that
it's
happening
any
other
questions.
A
J
I
was
just
wondering
about
like
next
steps
on
the
chase
side,
mario
or
flora.
How
do
you
want
to
go
about
this?
Should
we
have
another
call
with
tim
and
delson
and
the
team,
or
should
we
just
discuss
it
in
the
cabal
and
do
something
else,
or
what
do
you
think.
B
E
No,
it's
just
that.
I
think
I
already
saw
that
the
cold,
so
that's
like
I
was
wondering
I
was
looking
at
the
calendar,
but
I
already
set
up
a
call
for
this
week
with
you
eric,
so
I
will
double
check
if
actually,
I've
invited
everyone.
E
But
yeah
so
we'll
we'll
send
out
the
the
email
yeah.
I
wanted
the
plugins
team
actually
to
be
to
talk
with
the
that
file
registry.
The
file
services
team
to
start
discussing
about
how
we're
going
to.
A
So,
as
you
can
see,
there's
nothing
else
on
the
agenda
today,
but
I
kind
of
felt
like
I
skipped
over
the
releases
section.
So
if
anybody
has
anything
to
say
about
releases,
please
jump
in
otherwise
we
can
jump
into
team
updates.
If
anybody
has
any.
A
A
All
right,
I
think,
that's
it
for
today.
Thank
you
all
and
keep
the
conversation
going
and
matter
most
of
course,
and
we'll
see
you
next
monday.