►
From YouTube: CDF TOC 10.27.20 - Ortelius Proposal
Description
Continuous Delivery Foundation (CDF)
A
A
B
B
G
A
H
H
G
H
I
G
J
G
It
so
all
the
or
or
ortilius
map
makers
out
there
are
they
able
to
sign
in
will
they
have
access
to
be
able
to
sign
in.
G
E
Yeah,
this
room
doesn't
require
authentication.
A
J
A
reminder
sign
yourself
in
if
you
feel
like
it
there
at
the
top
in
the
agenda
doc,
I
will
share
so
everybody
knows
what
we're
looking.
J
J
Cool
a
bunch
of
people
signing
in
all
right,
so
here's
our
agenda
for
today
start
with
the
ortelius
proposal
pretty
packed
agenda,
so
we
might
not
get
through
everything
sig
mlops
roadmap
carrie
is
supposed
to
be
joining
up,
terry's
on
the
call
to
discuss
the
published
sig
on
the
lobster
map
and
then
a
just
a
couple,
other
administrative
things
at
the
end
that
we
can
always
do
over
email
if
we
don't
get
to
them
all
right
with
that,
let's
jump
into
the
ortelius
proposal,
tracy
or
steve-
do
either
of
you
want
to
take
the
screen
back
over
and
present
as
we
talk
through
this
or
should
I
do
it.
G
Would
you
like
us
to
walk
through
the
proposal
or
you
want
us
to
get,
do
just
walk
through
a
demo?
What.
G
G
G
It
over
to
steve
and
then
he
can
walk
through
the
proposal
as
well.
J
Yeah,
but
just
at
a
high
level
as
steve
gets
ready,
I
guess
I'll
stop
screen
sharing,
so
you
can
take
over
ortelius
has
submitted
a
proposal
to
join
the
cdf
as
a
project,
so
steve
is
going
to
show
us
what
artelias
is
and
then
we
can
take
a
quick
look
at
the
proposal.
I
So,
just
to
give
you
some
background,
real
quick
one
of
the
goals
of
ortilius
is
to
focus
on
the
organization
of
microservices.
I
And
we
use
microservices
loosely
because
we
don't
care
how
big
they
are.
If
somebody
has
an
implementation,
that
is
a
a
websphere
earfile,
that's
serving
up
a
microservice
or
if
it's
a
lambda
function,
but
one
of
the
key
things
that
we
have
is
the
ability
to
organize
those
microservices.
I
You'll
see
in
the
proposal
where
we
talk
about
a
marketplace
where
we're
going
to
take
this
domain
hierarchy
and
expand
it
out
to
not
only
what's
internal
to
an
organization
but
what's
global
across
the
open
source
communities,
so
we've
actually
reached
out
to
los
alamos
labs
out
here
in
san
diego
national
labs.
I
They
have
a
program
that
were
I
gotta,
follow
up
to
see.
If
we
got
to
prove,
we
should
have
to
have
them.
Do
some
work
for
us,
where
we've
asked
them
to
go
and
find
in
los
alamos
and
sandia
and
universities.
What
are
the
domains?
I
What
are
the
microservices
what's
running
on
kubernetes
those
open
source
projects
that
are
out
there
and
let
us
know
about
them,
because
one
of
the
things
that
the
government's
really
good
at
is
hiding
things,
and
we
want
to
bring
this
forward
and
same
with
like
universities,
you
know
what
they
have,
because
what
we're
seeing
is
these
projects
coming
out
of
the
scientific
and
also
on
the
financial
side,
where
we
have
open
source
projects
that
are
going
up
against
public
data,
but
that
the
people
writing
it
don't
want
to
run
their
own
kubernetes
cluster
and
do
all
that
support
and
stuff
like
that.
I
They
just
want
to
keep
this
core
part
deal
with
the
scientific
aspect
of
it,
the
the
programming
and
then
make
that
available
for
people
to
to
consume.
So
with
the
domain
driven
design
we
can,
we
can
see,
we
have
many
different
domains
here.
This
example
is
just
some
raw
data
that
we
have
for
some
test
data,
I'm
going
to
jump
over
to
another
demo
here,
where
we
have
some
better
data
that
we
can
look
at.
I
So
what
we've
done
is
we've
really
looked
at
the
this
side
of
things
as
the
api
or
microservice
developers.
So
this
is
where
we're
going
to
be
cataloging
those
those
domain,
those
services
at
that
level.
We've
had
people
that
have
written
three
different
single
sign-ons
for
a
single
company,
and
then
they
decide.
You
know
they
figure
out
down
the
road
that
they
have
they're
trying
to
implement
three
different
single
sign-ons,
so
they
have
to
throw
two
of
them
away
and
then
rewrite
to
to
adopt
the
other
one.
I
The
goal
of
the
domain
driven
design
is
to
really
expand
across
business
silos.
So
in
this
case
we
have
our
email
service,
our
catalog
services,
our
cart
service,
etc.
I
So
this
is
the
the
the
the
domain
catalog
for
the
api
microservices
developer,
but
also,
if
we
look
at
the
consuming
side,
we
can
still
support
the
traditional
lifecycle.
The
dev
test,
prod-
and
this
is
where
our
integrations
into
the
the
the
ci
cd
tools
come
into
play.
As
things
move
down
the
pipeline,
we
can
refer,
we
can
reference
where
something
is
from
the
consuming
side
where
it
is
in
the
pipeline
as
well.
I
So
we
have
that
capability
as
part
of
that
process,
any
questions
on
domains
and
the
ideas
that
we
have
around
expanding
it
out
to
a
full
marketplace.
I
I
So
one
of
the
things
that
we'll
see
is
like
in
this
case
this
application
version
is
at
the
global
level.
I
So
this
is
like
at
the
highest
level
of
the
whole
catalog,
but
we
can
classify
it
down
at
that
level
to
the
the
different
levels
and
silo
it
out
based
on
our
domain
driven
patterns
over
on
the
right,
we
have
our
dependencies
like
in
our
test
data.
We
just
threw
a
few
dependencies
at
it
to
map
it
out.
These
are
all
component
versions
that
are
being
consumed
by
the
application.
I
So
what
we're
doing
is
we're
looking
at
it
from
the
application
consuming
versions
of
microservices
at
that
level.
If
we
go
and
take
another
look
at
it,
we
can
actually
see.
Let
me
move
my
screen
around
a
little
bit.
We
can
actually
see
our
domain
hierarchy
in
another
view
where
we
can
actually
drill
down
and
see
how
things
are
are
organized
at
that
level.
So
we
get
the
the
tree
view
as
well.
I
If
I
had
a
application-
or
I
mean
components
that
are
outside
of
my
domain,
I
can
be
the
consumer
of
them
and
through
the
security
model,
I
can
consume
them,
but
not
update
them.
As
part
of
that
that
process
this
layout
can
be
driven
through
not
only
the
the
ui
here,
where
you
can
move
things
around,
but
also
it
can
be
file
driven
and
it
can
be
produced
out
of
the
the
cicd
process
at
that
level.
I
So,
like
I
said,
we
have
the
the
application
consuming
the
components,
we'll
go
ahead
and
dive
into
components
themselves,
and
this
is
where
we're
going
to
see
who's
consuming
me
in
this
case,
I'm
my
component
name
is
a12,
I'm
being
consumed
by
the
demo
app
as
part
of
that
process.
I'm
gonna
jump
over
to
the
other
one,
where
we
have
some
cleaner
data
that
we
can
actually
look
at
here.
L
A
I
So
what
we're
gonna
do
is
if
we
look
at
our
starting
point
in
this
case,
let
me
go
ahead
and
zoom
in
a
little
bit,
so
we
can.
D
I
I
So
our
base
version
is
our
starting
point
and
the
developers
are
the
ones
that
typically
know
what
the
layout
is.
So
the
developers
will
give
us
that
information
and
let
us
know
that
their
application
is
at
this
starting
point
is
consuming
these
versions
of
the
microservices
from
there
on
out.
We
can
then
start
automatically
through
the
ci
cd
process.
I
It'll
start
self
maintaining
itself.
So
if
I
add
a
new
version
of
the
ad
service
as
a
new
build,
I
would
come
off
come
out
and
create
a
new
version
of
the
of
the
ad
service,
which
is
the
component
and
then
that
would
result
in
a
new
version
of
the
the
application
as
as
we
go
through
forward.
So
the
the
base
starting
point
is
the
information
that
we
need
to
grab.
I
We
are
working
on
some
ways
to,
I
would
say,
like
reverse
engineer:
kubernetes
cluster,
for
example,
or
one
of
our
our
team
members
is
working
on
dealing
with
aws
and
the
gks
over
there
scraping
things
out
of
that
to
to
come
back
to
our
starting
point.
One
of
the
problems
is
people
in
you
know:
they'll
try
to
use
like
a
namespace
for
grouping
services
together,
but
my
ad
service
may
reference
another
do
a
transaction
to
another
namespace,
for
example,
and
we
want
to
build
those
relationships
in
as
well.
I
So
it's
a
starting
point,
but
from
there
we
need
to
have
the
developer
look
at
what's
the
relationships
that
they
have
and
then
we'll
be
able
to
maintain
going
forward.
I
I
So
what
we'll
do
is
you
can
see
here
where
we
have
multiple
versions
that
are
coming
out
of
the
build
process?
So
if
we
dive
into
like
cart
service
here,
we
have
the
integrations
into
jenkins
and
the
ci
tools.
This
one
happens
to
be
circle.
Ci
is
where
it
got.
I
The
job
that
created
it
and
we
can
see
in
the
middle
is
our
component
with
all
the
consuming
versions
of
the
applications
that
are
consuming
this
version
of
the
cart
service.
I
Through
our
plugins.
We
want
to
grab
information
about
what
was
created
where,
where
did
it
go
so
this
was
pushed
off
the
quay.
This
is
the
digest,
the
the
tag
that
was
used
over
in
quay
and
the
commit
that
was
triggered
the
whole
ci
process,
because
we
want
to
link
together
what
a
developer
is
doing
to
what's
being
produced
and
then
from
there
once
we
know
that
this
is
being
produced.
I
In
this
case,
one
of
the
things
when
we
do
deployments
with
ortulius
this
case
we're
using
a
helm
chart
to
do
the
deployment
it
could
be
an
operator
it
doesn't
matter
to
us
under
the
covers,
what's
happening
as
far
as
deployment.
One
of
the
key
things
is
that
we
want
to
record
that
this
component
was
deployed
to
this
environment
and
keep
track
of
those
relationships
as
part
of
the
process,
some
other
things
that
we
we
grab
as
part
of
it
oops
we'll
we
can
store
key
value
information,
so
config
maps.
I
Any
of
that
information
that's
needed,
because
one
of
the
things
we
recognize
is
that
a
service
in
development's
going
to
have
a
different
configuration
to
make
it
act
differently
in
development
versus
qa
versus
production.
So
we
actually
have
a
way
to
keep
track
of
that
along
the
process.
And
again,
we
can
see
where
this
was
deployed
to
the
cart
service
went
out
to
two
different
clusters,
so
you
can
take
a
view
from
from
that
standpoint
as
well.
I
The
relationships
and
what's
happening
at
that
level.
So
with
that,
I'm
just
going
to
open
it
up
for
questions.
I
So,
in
this
case,
one
of
the
things
that
we
we
did
was
we
were
in
a
new
version
of
our
application
of
the
fourth
of
july,
and
the
one
thing
that's
changed
between
the
previous
version,
which
is
our
base
version,
is
just
the
cart
service,
and
this
is
key.
When
we're
looking
at
the
microservices
catalog,
we
don't
want
to
redeploy
everything
or
if
one
thing
just
changed,
we
want
to
keep
track
of
the
incremental
changes
and
artelias
is
able
to
do
that
at
that
level.
I
So,
when
we
deploy
to
the
the
hipster
store
cluster
between
the
version
91
and
the
base
version,
the
only
thing
that
changed
was
the
cart
service
at
that
level.
I
I
think
that
was
most
everything
that
I
wanted
to
cover.
Oh
there
are,
there
are
you'll
see
here
that
we
have
actions
like
that
home
chart
was
an
action.
This,
in
this
case,
there's
a
pre-action
that
we've
put
in
place
to
resize
our
gke
cluster
prior
to
deployment.
I
We
don't
run
our
our
cluster
all
the
time
for
our
little
demo
sandbox
environment,
so
we
have
a
I'll
go
off
and
resize
the
cluster
at
this
level.
This
allows
us
the
entry
point
to
deal
with
if
we
need
to
run
terraform
to
stand
something
up.
You
know
those
types
of
of
scenarios
as
well,
and
this
will
also
link
into
the
ci
process
as
well
and
the
cd
process
where,
if
we
need
to
go
and
update
a
status
or
let
somebody
know
that
something's
been
completed,
we
can
go.
A
I
So
tracy,
why
don't
you
walk
through
this.
G
Okay,
so
where
we
cut
where
it
was
this
was
born
out
of,
was
the
need
to
understand
to
have
some
visibility
into
the
cd
pipeline
when
it
comes
to
microservices
in
our
in
our
ci
world.
We
have
things
like
bill
of
material
reports
and
we
have
impact
reports
and
we
have
diff
reports,
but
in
a
cd
pipeline
that
is
based
on
microservices,
we
don't
have
those
things.
G
Unlike
a
api
registry,
where
the
that
information
may
be
maintained
at
a
cluster
level,
what
we're
doing
is
managing
it
above
those
clusters.
G
I
So
one
of
the
things
that
we
see
is
with
the
cd
foundation
that
it's
a
perfect
fit
for
ortelius
is
because
the
the
organization,
you
know
the
cd
tools
that
are
in
the
organization
artillious
fits
into
those.
We
do
have
some
work
to
do.
On
the
techton
side,
we
actually
ended
up
doing,
integrations
and
detect
on
through
a
third
party
which
was
puppet.
So
that's
one
of
the
things
that
we
have
to
puppets
relay.
I
If
we
look
at
the
the
central
hub
of
the
data,
it's
going
to
be
agnostic
to
the
the
cd
tools,
but
provides
that
visibility
that
is
needed
throughout
the
whole
pipeline
process.
Ortunius
will
provide
a
build
of
material
difference
in
impact
analysis
reports.
I
It's
going
to
have
its
own
pipeline
and
its
own
speed
to
production
as
part
of
that
process.
Some
of
the
things
that
we're
going
to
grab
out
of
their
the
ci
process
is
the
ability
to
really
get
the
hook
from
what
the
developers
are
changing.
We
want
to
know
what
the
developers
are
working
on
and
how
that's
going
to
affect
production
as
part
of
that
process.
I
The
other
part
of
it
is
going
to
be
on
the
microservice,
catalog
being,
like,
I
said,
being
able
to
share
this
information
not
only
in
the
in
a
single
organization
or
company,
but
bring
it
higher
up.
So
we
can
have
these
other
open
source
projects
that
are
out
there
that
are
doing
kubernetes
they're
doing
microservices
and
bring
those
into
the
the
hierarchy
and
get
them
organized
as
part
of
the
process.
One
of
the
things.
G
I
Yeah
just
to
tag
onto
that,
one
of
the
things
that
we
did
was
at
the
the
environment
and
the
endpoint
level.
We've
actually
separated
out
the
data
from
definition,
so
you
can
have.
You
could
define
key
value
pairs,
for
example,
for
the
different
environments
and
that
will
get
applied
at
deployment
time
to
the
home
chart.
I
I
Those
key
value
pairs
at
deployment
time
as
part
of
the
process,
so
it
makes
it
really
easy
to
really
organize
the
services
and
get
them
so
they
can
be
found
and
not
have
to
have
people
recreate
the
same
servers
over
and
over
again,
like
I
said,
we
only
want
one
single
sign-on.
We
don't
want
three
or
four
as
part
of
that
process.
I
One
of
the
things
like
I
said:
we've
we've
built
plugins
into
the
existing
ci
cd
tools,
jenkins
team
city
circle,
ci
cloud,
build
github
actions.
Puppet
relay,
like
I
said,
we're
going
to
making
a
more
generic
one
for
techton
as
part
of
that
process,
also
the
ability
to
support
not
only
microservices
but
the
hybrid
world
or
the
monolith
world
world.
I
When
we
look
at
a
monolith,
let's
take
a
web
sphere
ear
file,
even
if
it's
a
web,
your
file,
that's
outside
of
a
container
for
us,
it's
just
a
component
and
an
application
version.
So
it's
a
component
version
which
would
be
the
ear
file
and
then
the
application
is
going
to
going
to
consume
one
component
of
that.
I
So
that's
where,
because
of
that,
we're
going
to
be
able
to
support
not
only
companies
and
users
that
are
in
the
beginning
of
the
the
journey
to
kubernetes,
for
example,
where
they're
gonna
go
from
a
monolith
and
they
may
take
their
monolith
and
put
it
in
a
container
and
then
take
that
and
then
run
it
in
kubernetes
as
a
single
single
replica
set.
I
We
can
support
that
through
ortilius
or
if
you
have
1500
or
5
000
microservices,
that
are
making
up
the
the
application.
It's
just
a
matter
of
the
number
of
relationships
that
we
need
them
to
manage
at
that
level
and
and
artelias
is
designed
to
to
deal
with
those
complex
relationships.
I
Let's
see,
and
it's
going
to
give
you
whether
we're
focused
on
a
single
hybrid
or
for
in
the
microservices
we're
going
to
give
you
that
that
viewpoint,
and
also
when
we
talk
about
components,
components
can
be
like
I
said
like
the
traditional
monolith,
it
could
be
a
database
component
test
case
components.
A
security
can
scan
can
be
component.
I
Config
map
can
be
a
component
version,
so
all
those
pieces
that
make
up
an
application
can
be
tracked
from
cradle
to
grave
as
part
of
that
process,
so
so
just
to
go
through
a
quick
process.
You
know
you
do
your
your
your
push.
Ortulius
picks
up
that
information.
We
grab
what's
happening
on
the
from
the
ci
process,
we'll
go
ahead
and
create
those
new
versions
of
the
application
version
and
component
versions.
I
I
I
think
that's
most
of
it
some
of
the
things
that
we're
looking
to
do.
I
So
some
of
the
things
that
we're
looking
to
do
is
really
build
out
that
that
microservice
domain-driven
design
catalog.
We
really
want
people
to
be
able
to
share
and
collaborate
when
they
write
in
microservices.
I
I
We
have
a
few
lines
of
code
that
we
need
to
put
into
like
a
a
jenkins
file,
for
example,
and
the
same
for
like
on
the
the
tecton,
there's
a
crd
that
we're
working
on
at
that
level
to
be
able
to
plug
these
in
and
be
able
to
get
the
benefits
with
minimal
changes
to
the
pipeline
process.
N
Hey,
yes,
steve,
I
have
a
small
question
for
you.
So
right
now,
people
are
about
talking
about
the
microservices
world,
so
might
be
in
a
starting
point
when
we
have
totally
three
or
four
or
five
or
six
micro
services.
So
they
want
them.
They
want
to
leverage
the
kubernetes
name
spaces
for
that
might
be.
They
want.
Somebody
give
us
a
name:
space
for
dev,
environment,
dev,
name,
space
for
production,
environment
and
name,
space
for
staging
environment,
and
eventually
somebody
looked
here
off.
I
Yes,
so
one
of
the
things
that
you'll
see
is
when
you
have:
let's
take
a
dev
name,
space,
a
qa
name
space
and
a
prod
name
space.
It's
the
same
service,
so
the
same
microservice
that's
gonna
be
deployed
to
those
three
different
name:
spaces
in
the
same
cluster.
Let's
say
we're
running
it
that
way,
but
it's
gonna
be
the
same
com
in
our
world.
I
We
call
the
component
version
now
we
could
have
three
different
versions
of
the
same
microservice
running
at
at
each
stage
of
the
pipeline,
so
which
means
for
single
microservice.
We
have
three
three
versions
that
we're
tracking.
Now,
in
your
example,
we
have
four
or
four
to
six
microservices.
I
That
means
we're
up
to
18
different
versions,
combinations
that
we're
going
to
need
to
keep
track
of
all
those
relationships,
and
artelias
will
do
that
automatically.
Once
we
have
that
base
starting
point,
we'll
we'll
hook
into
the
cicd
process
and
start
self
maintaining.
I
I
You
know
the
theory
behind
it.
All
was
everything's
loosely
coupled
you
can
independently
deploy,
but
working
with
netflix
and
a
couple
other
companies
like
boeing,
we're
recognizing
that
there's
sets
of
services
that
are
need
to
be
tightly
coupled
and
we're
working
on
building
that
into
the
relationship
model.
J
Cool,
let's
do
one
more
question:
if
there
is
one
and
then
move
on
to
the
sigma
lapse,
I
want
to
make
sure
we
get
to
cover
that
one
too
today,
since
terry's
here
anybody.
F
G
So
right
now
I
would
say
that
our
primary
customer
is
it
service
companies
like
like
unisys,
where
they
have
they're
trying
to
build
like
a
foundational
level
of
microservices
that
they
can
reuse
to
create
new
applications
for
different
customers,
that
those
are
the
ones
who
came
to
us.
First,
the
cut
the
kind
of
customers
that
we're
talking
to
now.
It
seems
that
if
they
have
have
more
than
if
they
have
40
micro
services
they're
running
into
problems
that
they
can't
solve.
G
I
Yeah
and
what
we're
seeing
is
people
coming
to
ortelius
when
they
have
they're
getting
in,
like
you're,
saying
earlier,
the
the
four
to
six
range
of
of
microservices
that
they're
forward
thinking
enough
to
realize
that
they're
going
to
have
a
configuration
problem
really
quick.
So
those
are
the
early
adopters
of
ortelius
when
they're
they're,
just
getting
into
microservices
they've
got
some
in
going
and
they
want
to
go
from
and
it's
working.
They
got
four
to
six
now
they
want
to
go
to
20.,
and
how
are
they
going
to
do?
I
J
All
right
cool,
let's
yeah,
let's
move
on
to
the
agenda!
We've
got
the
proposal
from
steve
here.
I'll
drop,
another
link
to
it
again,
I'll.
Ask
all
the
members
of
the
talk
to
take
a
look
and
comment
on.
There
leave
any
feedback
you
have
for
ortelius
and
then
once
that
slows
down.
Actually,
after
just
a
couple
days,
we
can
call
for
a
vote.
G
J
All
right,
terry,
if
you're
still
on
the
call,
looks
like
you're
here.
Do
you
want
to
take
over.
H
So
I
I
wanted
to
just
start
by
talking
a
little
bit
about
what
the
what
the
underlying
problem
is.
That
means
that
we,
we
really
would
benefit
from
having
a
a
roadmap
for
mr
ops.
H
Now,
logically,
ml
ops
is
really
just
an
extension
to
devops.
So
it's
just
it's
just
saying.
Well,
we've
got
these
machine
learning
assets
that
we
we
need
to
carry
across
into
our
products
that
we're
we're,
building
and
deploying
which-
which
are
you
know,
operating
within
conventional
devops
environments.
H
But
what's
interesting
is
that
in
practice,
the
teams
that
are
working
with
the
machine
learning
aspects
of
the
solution
are
typically
teams
of
data
scientists
operating
in
isolation
from
the
rest
of
a
product
development
set
up
and
in
many
cases,
they're
they're
they're
teams,
who
are
pretty
much
fresh
out
of
university
and
have
perhaps
never
really
been
exposed
to
devops
or
cicd,
or
any
of
that
history
of
learning
that
has
gone
into
helping
us
know
how
to
deploy
assets
into
production
environments.
H
So,
as
a
result,
a
lot
of
the
work
in
the
ml
ops,
space
and
especially
around
mlx
tooling,
is
happening
completely
isolated
from
the
rest
of
software
development
and
so
we're
seeing
a
lot
of
having
to
reinvent
the
wheel
and
do
things
from
first
principles
and
make
a
lot
of
quite
basic
mistakes
just
to
to
to
get
simple
assets
into
production
environments.
H
So
so
the
the
idea
of
the
the
roadmap
was
to
try
and
have
one
central
place
where
we
could
properly
collate
all
of
the
requirements
for
ml
ops
solutions
and
then
communicate
those
to
to
customers
who
want
to
adopt
ml
ops
and
to
teams
who
are
trying
to
build
specialized
tooling
in
in
that
space
and
also
to
go
the
other
way
and
communicate
to
teams
who
are
building
existing
devops
and
ci
cd
solutions.
H
So
we've
we've
been
working
collaboratively
over
the
past
six
months
or
so
to
to
compile
the
first
cross
cut
of
requirements
and
and
those
those
we've
we've
put
together
as
a
first
draft
of
the
roadmap
document,
which
we've
we've
finished
compiling
for
2020
last
month,
and
this
is
now
publicly
available.
So
there
is
an
interesting
first
stab
at
what
is
an
ops
and
what?
What
is
it?
H
Not
so
that
the
document
itself
really
introduces
some
of
the
the
vision
for
ml
ops
and
the
drivers
behind
the
road
map.
But
then,
primarily,
it's
broken
down
into
three
main
sections.
So
so
the
first
section
tries
to
capture
the
the
core
challenges
that
are
involved
here.
So
these
are
the
the
fundamentals
that
we
need
to
be
able
to
address.
To
achieve
everything
we
need
from
ml
ops
in
the
future.
H
And
that's
in
the
form
of
a
table
expanding
on
each
of
the
challenge
areas.
Now.
The
second
section
then
goes
on
to
look
at
what
are
the
technology
requirements
necessary
to
address
each
of
those
challenges
and
to
look
in
generic
terms
at
how
you
might
address
those
challenges
with
pieces
of
specific
technology
and
again
we're
attempting
to
be
very
agnostic
in
terms
of
what
systems
or
solutions
are
involved.
H
The
idea
is
to
make
this
as
inclusive
as
possible,
and
then,
finally,
we
take
a
look
at
the
the
overall
picture
about
where
we
are
with
potential
solutions,
and
this
is
primarily
a
a
map
giving
you
a
feel
for
which
areas
are
already
fairly
mature,
which
areas
are
under
development
and
which
areas
are
still
effectively
unknowns
where
further
research
is
needed
and
a
lot
of
work
will
be
required
before
before
those
solutions
can
can
be
brought
to
the
customer.
H
So
obviously
there's
a
there's,
a
lot
of
information
in
here
and
it's
quite
junk
to
absorbing
in
one
go.
But
if
there
are
any
specific
questions
that
anyone
has
I'm
happy
to
try
and
address
those.
H
I
Yeah
this
is
steve
from
from
artelias.
Do
you
have
any
use
cases
that
your
like
initial
use
case
that
you're
focusing
on?
I
didn't
see
that
in
in
the
document.
H
So
basically,
what
we're
looking
at
in
the
road
map
is
trying
to
capture
if
you
like,
multiple
use
cases,
so
so
each
challenge
is
effectively
one
example
of
a
of
a
problem
or
use
case
in
in
the
mlap
space
got.
H
So
the
the
jenkins
x
project
has
a
an
ml
ops
component,
which
is
trying
to
align
to
the
roadmap
and
and
actually
providing
an
implementation
of
those
capabilities.
H
H
But
it
would
probably
be
sensible
to
have
a
communications
plan
around
this
and
you
know
to
try
and
do
some
outreach
getting
involved
in
various
conferences-
and
you
know
improve
the
messaging
overall
so
that
we
get
plenty
of
visibility
on
the
roadmap
but
encourage
people
to
contribute
and
join
in
next
year.
L
H
That
that's
correct
yeah,
so
we're
really
treating
ml
ops
as
a
a
generic
way
of
performing
any
ml
activities,
and
we
expect
that
a
customer
will
want
to
use
with
multiple
different
underlying
machine
learning,
libraries
and
frameworks
and
a
big
part
of
what.
What
we're
setting
out
in
the
roadmap
is
the
need
to
have
you
know
very,
very
agnostic
platforms
that
can
can
allow
you
to
deliver
solutions
that
incorporate
many
different
machine
learning
frameworks
and
and
integrate
those
with
existing
software
assets
in
a
in
in
production.
J
Announcements
all
right,
my
screen
should
be
back
up
here.
Landscape
updates
is
the
next
item.
Tracy.
You
want
to
chat
about
this.
One.
J
I'm
all
right
this
next
one
project
updates.
Do
you
give
the
context
on
the
newsletter
here
tracy,
while
I
switch
screens
over.
F
Yes,
yes,
the
cdf
has
a
monthly
newsletter
that
comes
out,
and
it's
typically
on
a
theme,
so
it
might
be
security
or
ml
ops.
I
think
the
upcoming
one
is
as
kind
of
highlights
of
cdcon,
so
recaps
of
some
of
the
best
talks
from
cdcon.
F
However,
one
of
the
things
we've
heard
or
we've
noticed,
certainly
with
folks
reading
the
newsletter
and
in
general
from
our
community,
is
that
people
want
to
get
better
updates
on
the
projects
and
and
what
sort
of
new
new
and
noteworthy
and
what
our
project
highlights.
So
we're
going
to
kick
off
a
new
section
which
will
be
project
highlights
for
cdf
projects
and
not
just
in
the
newsletter,
but
I
think
we're
going
to
look
for
other
ways.
F
We
can
promote
the
great
work
happening
in
these
projects,
either
through
social
talks
or
just
whatever
channels
we
can
use.
So
to
that
end,
it
would
be
great
to
have
a
way
to
receive
those
updates
or
for
folks
to
share
them,
but
yeah.
The
very
least.
This
will
go
into
the
newsletter
coming
out
next
week.
M
And
then
really
quickly,
also
on
the
same
vein
of
project
updates,
I'm
starting
to
work
on
the
annual
report
so
I'll
be
reaching
out
to
folks
so
that
we
can
have
a
pretty
robust
update
from
each
of
the
communities
for
that
report
as
well.
J
Awesome
thanks
tracy
and
jackie,
so
the
doc
I'm
sharing
now
is
the
one
where
we
were
collecting
the
project
updates
for
the
november
newsletter
looks
like
jenkins
just
got
filled
in
during
this
meeting
thanks
oleg
the
other
one.
O
Yeah
so
since
this
is
the
first
news
letter
to
this
such
updates,
what
is
the
time
frame
of
updates
because
yeah,
I
assumed
it's
approximately
one
month,
but
if
you
want
to
take
a
bigger
period,
it's
fine.
F
Yeah,
it
will
be
typically
monthly
updates,
but
roxanne
will
she'll
be
kind
of
curating
from
the
list
and
looking
how
to
best
frame
it.
So
it
comes
across
as
interesting
for
users.
L
J
L
J
Sure,
all
right
back
to
I
wish
there's
a
faster
way
to
switch
which
tab
I'm
sharing
back
to
the
agenda.
J
Pending
project
requests,
so
this
is
a
section
where
we
talked
about
adding,
is
kind
of
a
recurring
one
to
the
talk
meeting,
but
just
to
discuss
and
give
projects
a
chance
to
raise
any
requests
for
help
that
they
have
or
they
need.
We
get
some
examples
here,
tucked
on
a
couple
of
the
tacked
on
sub
projects,
got
some
awesome
logos
created
or
sent
out
requests
for
logos
from
the
lf
design
and
graphics
teams.
J
These
are
always
pretty
fun
and
contributors
love,
seeing
cool
logos
for
the
stuff
they're
working
on.
So
if
any
of
your
projects
are
interested
in
logos,
I
think
almost
everybody
has
a
logo
for
the
top
level
project.
But
if
you
want
kind
of
similar
ones
for
subprojects
or
anything
like
that,
then
you
can
go
ahead
and
open
issues
here.
J
We've
also
been
there
was
a
survey
a
while
ago
to
collect
any
other
kind
of
project
infrastructure
stuff
on
the
projects
you're
using
to
host
artifacts
or
run
ci,
or
anything
like
that.
So
that
way
we
can
surface
all
those
up
at
the
next
board
meeting.
So
if
you
need
any
help
paying
for
anything
like
that
or
getting
credits
or
anything,
you
can
either
shoot
an
email
to
me
and
I
can
raise
it
up
to
the
board
or
we
can
kind
of
discuss
it
in
these
recurring
sections.
J
F
Just
with
the
logos,
so
I
think
we're
good
to
take
the
detector
and
harven
dashboard
move
forward
with
those
I
think,
we're
yeah.
The
creative
team
is
pretty
familiar
with
spinning
out
the
cat
doing
different
things.
So,
if
folks
want
to
comment
on
those
for
any
other
ideas,
please
do
so
on
the
screwdriver
logo.
I
think
this
is
one
for
jeffen
we're
actually
looking
for
a
version
of
the
screwdriver
logo,
which
is
stacked,
so
we
could
put
it
on
our
case
study
page.
F
A
F
O
So
from
the
junkies
project
site,
we
have
a
pending
explanation
about
a
docker
hub
sponsorship.
See
a
docker
hub
has
changed
the
policy.
Currently
we
are
trying
to
get
the
sponsorship
from
docker
for
hosting
our
repositories,
but
if
that's
possible,
you
would
like
to
seek
sponsorship
for
that
and
yeah.
Second,
larger
topic
is
read
about
the
next
year:
infrastructure:
budgets,
yeah.
I
know
that
it's
a
bit
too
early
to
discuss
it,
but
it
would
be
great
to
start
planning
for
that,
especially
for
watch
setups
like
jenkins
infrastructure.
J
Sure
yeah,
I
know
a
bunch
of
people
at
google
and
microsoft
and
all
the
other
companies
involved
in
oci
are
meeting
with
dockerhub
regularly
to
figure
out
ways
to
mitigate
those
changes.
But
if
you
could
shoot
an
email
or
a
doc
or
something
just
the
summary
of
all
the
images
you're
hosting
on
docker
hub
today,
and
then
any
estimates
and
stuff
on
how
the
changes
would
impact
you.
We
can
definitely
start.
I
Dan
wasn't
tucked
on
having
the
same
issue.
J
Yeah,
the
catalog
is
kind
of
a
contribution
stuff
that
isn't
hosted
in
the
official
tectonic
repository,
so
it's
possible.
Some
of
that
stuff
is
on
docker
hub.
I
J
All
right
and
in
the
last
three
minutes,
white
papers,
tracy.
F
Yeah,
so
we've
got
a
number
of
different
things
on
the
ball:
the
ci
cd,
the
sorry
the
interoperability
working
group
are
probably
the
furthest
along
in
having
a
white
paper
where
they're
just
looking
for
reviewers
and
any
further
end
user
case
studies
and
then
there's
a
couple
of
kind
of
in
progress
documents
which
are
open
for
comment
and
we're
still
trying
to
work
out
how
to
shape
these
and
push
them
out.
J
Through
okay,
that
we've
got
two
minutes
left
on
any
other,
quick
questions
or
anything.
I
think
the
big
action
item
is
for
everyone
to
review
the
ortillius
proposal.