►
Description
The Ortelius roadmap for 2023 and a review of accomplishments from 2022 is covered in this TOC meeting.
A
A
A
So,
since
the
last
time
we've
met
this
happened,
there
has
been,
as
many
all
of
you
know,
a
shift
to
looking
at,
in
particular
open
source
security,
and
there
has
been
an
astonishing
increase
in
what
we
now
like
to
call
supply
chain
hacks
and
at
the
same
time,
the
supply
chain.
Hacks,
are
increasing.
Organizations
are
trying
to
modernize
to
these
to
more
complex
Cloud
native
architecture,
so
they've
got
pressures
coming
from
them
from
both
sides.
A
A
Finally,
and
if
you
think
about
what
we
have
been
doing
since
we
started
this
project
as
we
have
in
the
beginning,
we
started
collecting
deployment
metadata
about
everything.
That's
deployed
every
any
kind
of
object,
whether
it
be
a
microservice
or
a
data
database
object.
We
collected
where
it
was
being
deployed
to
we
collected
its
configurations
for
the
deployment
we
collected
where
the
helm
chart
was
so
we
were
collecting
metadata
about
these
pieces
and
parts
primarily
to
start
managing
the
drift
of
microservices
and
the
inventory
of
microservices
across
hundreds
of
clusters.
A
A
So
we
have
started
growing
the
the
ortilius
store,
what
I
like
to
call
an
Evidence
store,
Beyond,
just
devops
intelligence,
but
now
also
supply
chain
intelligence.
We
are.
We
started
down
this
path,
knowing
that
people
would
be
calling
us
and
saying,
how
do
you,
how
do
you
generate
an
application,
Level
s-bomb
in
a
microservices
environment?
A
A
So
we
have
now
a
way
for
ortelius
to
make
it
really
easy
for
folks
to
say:
where
is
this
particular
open
source
package?
Where
is
it
running?
What
versions
of
it
is
running
and
where
do
I
need
to
fix
it
instead
of
days
to
get
this
data?
Literally
now
it's
just
one
big.
It's
a
it's
a
big
query
against
the
database
and
because
we've
already
had
all
those
details
about
where
objects
were
being
deployed,
and
now
we
have
the
package
information
stored
with
that
this.
This
query
is
super
super
easy.
A
We
did
start
a
governing
board.
We
did
talk
about
that.
The
last
time
we
had
a
Toc
meeting,
Brian
Dawson
Steve
Taylor
utkar,
Sharma,
Sasha,
Wharton,
Emery,
Fred,
Sergio,
Canales
and
Siddharth
Parikh
make
up
our
governing
board.
This
is
our
second
year
governing
board.
Most
of
these
folks
have
served
one
year
and
utkar
Sharma
is
new
to
this
particular
year.
A
We've
seen
some
good
growth
we
have
had.
We
have
about
250
Google
group
members
that
some
of
them
are
active,
some
of
them
watch
what
we're
doing,
and
some
of
them
look
for
easy
pull
requests.
Basically,
we
have
about
718
followers
on
LinkedIn
we're
at
264
GitHub
stars
with
115
GitHub
Forks
in
October
we
participated
in
Oktoberfest,
had
24
pull
requests
and
for
the
year
we
did
203
total
pull
requests
in
2022..
A
A
Bionic
and
Vulcan
are
similar
tools
and
that
they
are
working
to
aggregate
data,
and
then
apparel
is
looking
really
more
at
the
infrastructure
and
auditing
the
infrastructure
and
tracking
changes
and
building
what
I
like
to
call
this
object
relationship
model
in
order
to
try
to
understand
how
an
application
is
acting
so
tied,
lift
is
the
only
one
that's
kind
of
outside
that
realm.
They
do
have
a
component
registration,
but
they're
really
focused
on
OS
package
inventory.
A
We
did
receive
a
grant
award
from
xrp.
We
are
working
to
build
a
immutable
s-bomb
Ledger.
We
have
had
some
early
success
in
getting
this
done.
We
have
a
POC
and
the
initial
design
work
kind
of
done,
so
it's
kind
of
you
can
demonstrate
it
a
bit
there's
still
quite
a
bit
more
work
to
do.
We
also
set
up
a
contributor
sponsor
program
to
reimburse
the
core
blockchain
contributors
with
that
75k.
A
We
built
some
new
Integrations
in
order
to
support
the
s-bomb
functionality.
We
integrated
with
Cyclone,
DX
and
spdx
formats,
and
we
use
sift
and
we
have
started
doing
some
work
with
backstage
to
pull
in
some
of
the
objects
or
the
the
registered
components
that
backstage
is
managing
into
our
database.
A
And
then
we,
where
really
this
year,
is
the
year
to
focus
on
adoption.
We
have
released
a
command
line
interface
to
support
any
type
of
CI,
CD,
tooling,
so
from
Jenkins
to
Circle
CI
to
Captain,
and
when
you
do
that,
if
you
want
to
include
the
s-bomb
generation,
that
command
line
interface
will
support
that.
A
What
we've
learned
is
that
not
a
lot
of
companies
actually
do
s-bomb
generation
and
even
if
they
do,
the
s-bomb
sits
in
that
text
file
at
the
build
directory
and
it
it
it's
not
consumed
so
that
CLI
interface
will
allow
folks
to
not
only
generate
an
s-bomb
but
consume
it,
and
we
we
really.
We
took
out
most
of
the
the
deployment
engine.
Initially,
we
had
the
ability
for
ortilious
to
do
deployments
and
now
we're
really
just
focusing
on
integrating
with
other
deployment
tools.
A
And
then
we
built,
we
do
have
a
true
kubernetes
architecture.
Now
open
source
contributors
can
contribute
in
any
language
they
want
and
they
create
a
microservice
for
that
particular
function
or
service.
So
we
had
to
build
a
new
Helen
chart
in
order
to
pull
that
together.
For
folks,
we
do
require
now
kubernetes
environment,
but
ortilius
now
can
be
downloaded
from
artifact
hub
using
Helm
chart.
B
B
So
one
of
the
first
steps
with
the
xrpl
is-
and
then
we've
been
working
through
this
for
quite
a
bit
of
time,
is
trying
to
figure
out
how
we
can
fit
into
the
xrpal
and
basically
nfts
which
what
what
we'll
be
using
for
the
storage
on
that
side.
So
as
soon
as
I
go
over
the
slide,
I'll
go
ahead
and
kind
of
dive
into
the
details.
There
we
have
been
having
meetings
with
red
hat.
B
So
the
driving
Factor,
where
this
actually
came
about
in
the
red
hat
world,
was
they
had
a
customer
that
had
a
closed
system
and
they
needed
to
do,
builds
and
run
things,
and
so
so,
basically,
they
needed
to
go
and
copy
oci
information
over
from
the
open
side
into
the
the
closed
side,
and
they
found
that
they
were
going
around
and
copying
all
these
different
dispersed,
80
bases
Registries,
like
npm
python.
You
know,
so
it
was
a
major
effort
for
them
to
kind
of
set
up
this
closed
system.
B
B
B
B
There's
no
framework
in
place.
Basically
what
happens
is
we
use
a
lot
of
just
some
a
lot
of
custom
JavaScript
and
some
jQuery
to
kind
of
create
the
front
end
that
we
have
going
on?
This
does
run
in
its
own
container
as
well,
so
you
kind
of
have
a
duplication
of
the
Tomcat
running
one
for
the
front,
end
side
and
another
one.
B
For
the
back
end
side,
we
do
bring
in
additional
JavaScript
packages
like
visjs
and
data
tables
that
allows
us
to
do
the
dependency
graft
and
some
you
know,
prettier
tables
in
the
front
end
along
with
that
we
have
our
our
back-end
microservices.
So
anything
new
that
we
have
been
written
writing
over
the
last
couple
years
have
been
python
fast,
API
programs
and
they
are
specific
restful,
API
endpoints.
So
this
is
conforming
to
a
more
true
rest.
Api
language
set.
You
know
the
crud
piece
we
use
SQL
Alchemy.
B
B
So
it
makes
it
easy
for
from
the
programming
perspective,
we
can
give
a
developer.
You
know
open
source
contributor
like
this
microservice
to
work
on,
and
they
can
do
it
totally
independent
of
everybody
else.
So
it
makes
it
really
easy
on
that
front,
as
we
expand
out
the
the
functionality
to
keep
things
moving
along.
The
database,
like
I
said,
is
postgres
and
both
the
monolith
and
the
microservices
read
and
write
to
the
database
over
jdbc
and
piodbc.
B
B
B
B
There
may
be
a
few
that's
missing
as
we
go,
but
for
the
most
part,
this
is
the
list
that
we've
kind
of
come
up
with
on
the
back
end.
This
is
where
it
gets
interesting
because
we've
been
working
with
the
the
xrpl
side
of
things
and
the
way
that
was
that
we're
implementing,
that
is
to
use
basically
nfts
to
store
our
Json
objects.
B
So
if
you
have
a
component
version
or
s-bomb
or
application
version
that
Json
would
be
stored
in
in
nft
storage
that
storage,
we
have
to
do
some
kind
of
tricks
on
it
to
minimize
the
amount
of
storage
space
that
we
have.
So
we
actually
are
going
through
a
process
of
normalizing
the
data,
so
we
just
don't
duplicate
it
all
over
the
place.
B
So,
for
example,
if
a
component
has
the
Apache
2
license
and
we
have
another
component
that
is
also
using
the
Apache
2
license-
we
don't
want
to
store
the
Apache
2
license
twice,
we'll
just
point
to
the
the
common
one
in
nft
storage,
some
of
the
things
that
we'll
need
to
do
because
ipfs,
basically
nfts,
aren't
searchable.
We
have
a
solution
that
will
create
a
searchable
cache
and
right
now
we're
looking
at
a
Rango
DB
to
act
as
that
cache
and
part
of
that
process.
B
We
would,
when
you
find
something
that
we
would
also
go
ahead
and
add
that
the
fully
denormalized
Json
object
back
to
the
cache.
The
reason
reason
why
we
were
really
highly
looking
at
the
Durango
DB
is
the
document
retrieval
you
don't
have
to
provide
like
a
predefined
schema.
You
can
it'll
basically
take
any
Json
that
you
want
and
we'll
figure
out
how
to
index
it.
We
may
need
to
add
some
additional
indexes
and
graph
connections
for
higher
performance,
but
right
now
we
can.
B
So
this
gives
us
that
that
capability
to
utilize,
The,
xrpl
Ledger
for
transactional
history,
plus
the
ipfs
nfts
to
actually
store
the
data,
so
this
is
going
to
be
one
way
that
we
can
go
ahead
and
do
our
kind
of
our
our
database
Solution
on
that
front.
The
other
way
that
we've
been
talking
about
is
the
oci
registry
Tracy
we're
calling
it
like
a
universal
object.
Some
object
reference.
B
So
basically,
what
we
would
need
to
do
is
treat
the
oci
registry
similar
to
the
nft
storage.
We
would
still
want
to
go
ahead
and
create
the
the
a
searchable
cache
and
be
able
to
have.
You
know:
go
fetch
things,
information
from
the
oci
registry
and
bring
it
back
into
as
Json
objects
into
the
orango
DB.
What
that
allows
us
to
do
is
have
either
or
of
the
database,
so
we
would
probably
end
up
with
two
sets
of
microservices.
B
So
if
you
need
to
go
get
a
component
version
from
ipfs,
you
would
go
ahead
and
call
that
component
version
microservice.
And
if
the
component
version
stored
over
in
the
oci
registry,
we
would
have
that
that
microservice
know
how
to
go
out
to
the
oci
registry,
bring
back
the
con
component
version
information
and
then
from
there.
The
the
end
result
between
those
two
Services
is
the
same
Json.
B
So
that's
kind
of
the
thought
that
we
have
it's
going
to
be
extra
work
to
do
two
sets
of
services,
but
at
this
point
the
red
hat
project
hasn't
even
been
like
approved
by
red
hat
and
the
extension
that
they
want
to
the
the
1.1
schema
for
oci
hasn't
been
adopted
by
the
community.
You
know
the
the
oci
folks,
so
I
think
the
oci
is
going
to
be
there,
but
I.
Think
it's
going
to
be
a
lag
probably
of
a
year
would
be
my
guess.
B
So
in
the
meantime,
I
wanted
to
keep
going
forward
with
the
xrpl.
At
that
front,
we
may
need
some
stuff,
the
the
postgres
database
to
hang
around
for
a
little
bit
and
the
reason
being.
There's
things
like
users,
groups,
access
controls,
the
the
domains.
Those
things
may
need
to
reside
in
inside
a
postgres
until
we
do
the
full
migration
at
that
level,
like
I
said
in
in
Tracy
slide
that
she
had.
B
This
is
like
the
new
architecture,
I'm
still
working
to
build
out
the
the
object
schemas
for
every
single
object,
so
we
can
actually
pull
everything
together.
That's
my
my
task
for
this
week
as
we
move
along
between
these
two,
but
the
idea
is
to
have
this.
These
separate
microservices
provide
us
the
abstraction
layer
to
the
back
end
database,
whether
it's
going
to
be
the
oci
registry
or
the
xrpl
side
of
things,
so
that's
kind
of
where
we're
at
with
the
new
architecture
Tracy.
Was
there
any
more
slides
after
that?
C
Have
so
many
questions,
yeah,
okay,
sorry,
it
was
I
should
have
been
writing
them
down
as
I
went,
but
it
ended
up
having
a
lot
more
than
I
anticipated.
So
first
off
I'm
really
trying
to
wrap
my
head
around.
Why
we're
dealing
with
blockchain
I
think
I
may
have
missed
a
memo
somewhere,
but
I
I
feel
like
look.
Why
are
we
going
this
direction?
What's
the
what's?
The
value
add
that
that
we
think
we're
getting
here,
yeah.
B
So
the
value
added
is,
we
want
to
have
a
an
immutable
history
of
everything
that
is
created.
So
if
you
do
a
build
a
new
microservice,
for
example,
that
basically
is
a
and
it's
going
to
be
we'll
just
take
the
simple
example:
it's
in
a
container
a
Docker
image
that
transaction
would
be
added
to
the
immutable
Ledger.
B
C
I
mean
I
totally
get
transaction
history,
super
critical
right,
I,
just
and
I'm.
Looking
at
at
this
site,
it's
you
know,
but
blockchain
is
not
known
for
being
fast,
especially
as
you
scale
over
time
and
that's
I
think
the
the
biggest
concern
that
I
would
have
not
being
an
expert
at
it,
but
just
seeing
what
people
are
trying
to
use
it
for
and
thinking
about
like
is
this
going
to
become
this?
C
Basically
massive
sandbag
and
the
other
thing
is-
and
this
is
the
concern
that
I've
had
in
one
of
the
many
reasons
why
I'm
a
little
bit
I,
don't
say:
I'm
anti-block
chain,
I'm,
just
highly
skeptical,
blockchain
It's,
just
sometimes
the
immutability.
Now
you
you
have
immutability
on
something,
that's
actually
a
mistake
right
and
so
and
and
unfortunately,
a
lot
of
these
industries
are
tied
to
bitcoin
or
cryptocurrencies,
and
so
it
as
an
industry
which
I
do
not
at
all
I'm,
not
associating
artelius
to
that.
C
Obviously,
but
the
sort
of
the
volatility
of
a
lot
of
that
development
because
of
the
cryptocurrency
nonsense,
is
potentially
impactful
so
I
just
I
guess
it's
you
know.
How
is
is
the
fact
that
you're
trying
to
do
the
xrl,
PC
and
oci
a
a
hedge
bet,
because
they're
kind
of
different,
because
I'm
just
trying
to
kind
of
see
what
the
direction
that
you're
going
here.
B
B
So
that's
the
main,
the
main
goal
that
we
have
now.
The
reason
why
we've
added
in
the
Rango
DB,
which
is
a
graph
database,
is
for
that.
Caching,
both
of
these
the
oci,
is
a
little
bit
better
with
the
searching.
It's
not
it's,
not
100.
You
know
they
do
have
search
queries,
but
it's
not
going
to
give
us
they're
not
going
to
be
as
flexible
as
we
need.
So
that's
where
we're
adding
in
the
orango
DB
as
a
caching
mechanism
for
exactly
what
you
said.
B
C
Okay,
I'm
certainly
not
going
to
second
guess
your
architectural
decisions
I
just
it
feels
putting
on
my
VP
of
engineering
had
it
just
it
feels
like
a
lot
of
complexity
is
I,
guess
the
concern.
There
was
another
question
that
I
had,
but
I
will
pause
in
case
I.
Don't
want
to
hug
all
the
time
got.
Other
folks
have
questions.
B
So
that's
one
of
the
things
that
was
the
bigger
selling
point
when
we
started
looking
at
the
The
Ledger
was
okay.
We
have
a
ledger,
that's
going
to
record
the
transactions,
but
the
more
important
part
is
like
Tracy
is
saying:
how
are
we
going
to
store
s-bombs
because
we
need
a
historical
point
of
view
of
when
an
s-bomb
was
created,
so
I
can
actually
see
for
this
component.
If
somebody
had
a
vulnerability,
did
they
fix
it?
B
And
that
gives
us
that
that
kind
of
view
of
things
talking
to
the
Encore
folks
they
said
they
were,
they
ran.
They
started
storing
s-bombs
just
for
the
the
certified
Docker
images
from
Docker
Hobb
and
in
two
weeks
they
had
three
gig
worth
of
s-bombs,
so
it
was
growing
extremely
fast
and
they
actually
turn
it
off
at
that
level
because
they're,
what
was
happening
is
they
do
a
build
and
they'd
repeat
everything
and
they'd
have
one
little
piece
that
changed
out
of
the
whole
picture.
You
know
you
change
one
one.
B
So
that's
one
of
the
things
that
we've
always
taken
that
Viewpoint
as
things
evolve:
As
We,
Gather
the
data
now
on
the
oci
side,
I'm,
not
100,
sold
on
Red
Hats
capabilities.
Yet
you
know
the
project
is
just
starting
off:
it's
not
even
an
official
project
in
in
Red
Hat.
They
I,
don't
even
don't
know
if
they
have
a
git
repo.
Yet,
but.
B
B
A
Mean
right,
if
they
yeah
redhead,
has
the
manpower
to
do
it
if
they
choose
to
because
and
that
we
don't
know,
if
that's
going
to
happen
and
on
the
blockchain,
we're
not
we're
not.
You
know
we're
playing
with
this
to
see
how
this
works
and
looks
the
open
source.
Community
has
learned
a
lot
about
blockchain
in
the
process,
which
is
kind
of
nice
too,
but
it
is
just
a
proof
of
concept.
A
C
C
So
that's
the
other
thing
is
you
know:
I
I
haven't
I
haven't
looked
recently,
but
I
assume
that
part
of
part
of
the
cost
of
doing
that
work
they're
going
to
not
absorb
because
it's
they're
just
going
to
make
it
work
for
the
red
hat
ecosystem,
which
means
then
we
have
red
hat
and
then
everybody
else.
If,
if
it
goes
in
that
direction,.
D
A
We
have
a
call
with
them
in
like
15
minutes,
but
what
we
probably
would
push
them
to
do
would
if
we
were
going
to
go,
that
way
is
to
make
sure
they
were
under
the
CDF
in
some
way,
even
if
it
was
a
sub
sub
project
of
ortilius
or
that
they
brought
it
in
as
a
high
level
project
before
we
would
move
forward.
So.
D
B
D
B
B
A
A
B
The
cost
the
cost
of
running
an
oci
registry
just
because
of
the
way
it's
it's
I
haven't
gotten
into
this.
The
specifics,
but
it
looks
like
and
just
a
quick
look
at
running
an
oci
registry
in
kubernetes
and
ends
up
just
being
a
volume
Mount
and
that
doesn't
give
you
the
the
distribution,
like
the
ipfs
side
of
things
where
it's
distributed
across
multiple
machines
and
stuff
like
that.
B
A
D
D
A
So
much
for
the
questions,
I
would
love
for
you
to
digest
some
of
this
stuff
and
do
a
follow-up
call
with
you,
maybe
in
a
month
to
see
where
your
head
is
on
it.
So
now
we,
you
see
some
of
our
challenges
and
what
we're,
how
we're
trying
to
kind
of
grow,
that
Hub
of
data
that
we're
tracking
and
what
we've
already
done.
We'd
love
to
be
able
to
show
you
what
we've
already
done
with
blockchain
as
well.
Okay,
all.
A
A
D
B
C
A
So
tomorrow,
I
will
I'm
going
to
send
out
a
follow-up
on
this
and
on
another
note
we
are
going
to
actually
build
a
proper
Toc
committee,
since
we
have
enough
open
source
developers
now
so
we'll
be
doing
a
proper
elect
election
for
Toc
members
and
Tara
we'd
love
to
have
you
stick
around.
So
just
keep
that
in
mind.
All.