►
From YouTube: GeneralMeeting10-19-21
Description
October 19th 2021 General Ortelius meeting. Thoughts on Hacktoberfest, Ortelius Microservice Visionaries and the upcoming Governance Board is part of this conversation.
C
E
F
A
A
G
All
right,
great
all
right,
so
the
general
community
meeting
we
generally
cover
what
is
being
done
in
the
other
two
working
groups,
so
I'll
just
go
quickly
over
the
three
projects
that
the
ambassadors
are
working
on.
We
are
close
to
the
end
of
our
election
process
or
our
nomination
process.
I
will
tomorrow.
I
will,
I
think
we
have
this
week.
G
If
we
don't,
if
I'm
supposed
to
shut
the
nominations
down
I'll,
do
that
on
wednesday
and
I'll
get
the
election
process
set
up
so
I'll,
send
it
send
out
the
actual
voting,
and
if
you're
in
the
google
groups,
you
will
receive
a
invite
to
join
the
voting,
and
if
you
don't,
it
means
you're,
not
interested
in
voting.
So
that's
how
that
works.
G
I
think
that
we
have
I
haven't
looked,
but
if
we
have
an
issue
with
enough
people
in
nominating
themselves
for
the
board,
I
will
push
that
out
before
I
obviously
close
the
nominations.
We
are
working
on
our
december
8th
meeting
or
our
summit.
I
guess
you'd
call
it
a
contributor
summit.
I
believe
we
have
two
more
openings
for
speakers.
G
So
if
you're
interested
in
speaking,
grab
a
slot
and
we'll
probably
we'll
be
recording
that
in
november,
so
we
have
some
time-
we
still
have
time
to
think
about
it,
and
then
we
have
of
course
hacktoberfest
going
on,
and
I
think
that
is
pretty
much
the
three
things
that
we've
been
focused
on.
We
do
have
a
a
group
of
you
who
are
working
on
the
the
live
office
hours
and
I
think
that
is
moving
forward.
G
So
we've
got
quite
a
few
things
that
kind
of
up
in
the
air
they
haven't,
we're
still
juggling,
but
I
think
by
the
end
of
this
month,
most
of
that
stuff
will
be
over.
At
least
the
elections
will
be
over.
The
hacktoberfest
will
be
over.
We
can
focus
on
our
december
8th
event
and
getting
our
live
office
hour
meetings
going.
H
A
So
if
there's
any
topics
that
you
want
us
to
like
research
or
any
specific
groups,
you
want
us
to
talk
to.
Basically,
it
ends
up
being
the
main
it'll,
be
the
company
sponsored
or
company
contributors
to
the
the
linux
foundation,
which
deploy
up's
one
of
them
and
then
also,
if
you're
like
on
a
governance
board
or
any
of
those
things
you
get
invited
it's
one
of
these
invite-only
type
of
events.
A
G
A
A
A
G
So
the
the
other
thing
I
I
have
just
for
this
group
to
think
about
in
terms
of
on
the
architecture
side,
we
had
originally
talked
about
put
adding
to
the
roadmap,
and
this
is
something
that
the
governing
board
was
going
to
be
very
helpful
with,
because
we
usually
have
to
solve
these
problems
in
the
community,
and
I
think
there
are
discussions
that
need
to
have
deeper
thought
in
them.
Originally,
we
were
thinking
about
after
the
service
catalog.
G
What
would
be
in
our
roadmap
is
a
git
ops,
integration
which
I
think
is
really
really
important,
but
we
have
had
come
users
now
reaching
out
to
us
about
building
service
to
service
relationships
and
steve
has
started
working
with
one
company
and
building
that
out
it
would
require
basically
some
plug-ins
so
steve.
Could
you
just
briefly
go
over
what
you're
doing
with
tominos.
A
So
what
we
have
is
the
text
file
microservice
is
producing
one
endpoint,
which
is
where
you
can
grab
the
text
file
from
the
database,
and
it
consumes
one
other
microservice
which
is
validate
user.
And
then,
if
we
go
over
to
the
validate
user
microservice,
it
doesn't
consume
anything
else.
It
just
produces
the
validate
user,
microservice
endpoint.
So
what
ends
up
happening?
Is
we
have
these
relationships
between
microservices
at
a
restful
api
standpoint,
what
you're
producing
and
what
you're
consuming
now?
A
What
I've
done
on
the
deploy
up
side
is
I've
added
in
another
table
to
start
tracking
these
relationships
to
producers
and
consumers?
This
it's
just
a
small
little
table.
It
basically
has
the
verb,
the
endpoint
and
then
I
think,
maybe
the
description
or
something
like
that
really
really
basic,
but
it
allows
us
to
map
the
relationships
across
the
application,
everything
that
an
application
is
consuming
and
producing
and
all
that
stuff
and
you
get
these
nice
maps.
H
A
And
the
way
we
get
this
data
is
we
as
part
of
our
our
cli?
You
have
to
provide
us
as
part
of
the
build
process
you
when
you
do
like
a
docker
build.
We
need
to
get
two
files
we
need
to
get
to
the
the
producing
file
and
the
consuming
file
they're
just
json
files,
so
like
in
the
example
I
gave
the
text
file
a
microservice.
A
What
you
produce,
for
example,
is
pretty
easy
to
figure
out,
because
we
have
our
swagger
file.
We
know
through
the
swagger
documentation
what
your,
what
endpoints
we're
gonna
end
up,
exposing
from
that
level
figuring
out
what
you're,
gonna
consume
is
gonna,
be
a
little
harder
because
it's
based
on
the
language.
So
if
you're
in
java,
you
have
to
look
for
certain
java
methods
to
do
http
calls
if
you're
in
node
you're
going
to
have
a
different
structure.
A
That
code
code
scanning
occurs
when
you
do
your
docker
build.
So
as
when
you
do
your
docker
build
what
you
have
is.
Typically
you
have
you.
Do
your
docker
build
in
the
context
of
a
workspace
and
that
workspace-
and
this
doesn't
matter
it's
regardless
of
the
pretty
much
the
ci
cd
tool.
They
all
have
this
concept
of
a
workspace,
but
basically
that's
where
your
git
repo
has
been
checked
out
to
so
you
have
all
the
source
code
available
for
you
to
go
ahead
and
scan
at
that
level.
A
H
A
A
F
A
Yeah,
so
we're
so
the
other
way
to
look
at
this
is
on
the
back
end.
So
if
you
had,
let's
say
like
kiali,
you
know,
kiali
is
going
to
give
you
the
transaction
graph
on
the
back
end
side
in
your
kubernetes
cluster.
So
if
you're
using
istio
and
cal
and
kali
you'll,
you
can
see
that
the
text
file
microservice
is
calling
over
to
the
validate
user
microservice.
A
G
A
G
A
A
Yes,
so
as
part
of
part
of
the
ci
process
in
the
pipeline
process,
when
ortelius
needs
to
be
inserted
into
that
process,
so
we
do
a
our
cli
gets
inserted
after
the
docker
build,
and
actually
it's
technically
after
the
docker
push.
We
do
our
call
over
to
ortilius
to
grab
the
information
and
push
it
up
to
our
database.
A
G
F
G
F
G
F
F
G
F
G
F
G
Figure
out
which
of
those
projects
that
we
would
push
out
there
for
the
community
to
start
working
on,
but
since
we're
still
a
small
community
we're
not
as
big
as
tincans.
Obviously
I
think
that
we
it's
easier
for
us
to
come
to
some
agreement
of
what
that
roadmap
is
going
to
look
like,
and
I
think
that
one
isn't.
It
fits
that
problem
fits
in
our
in
what
we
do
in
terms
of
mapping.
F
D
A
A
A
So
we
need
to
take
a
focus
and
just
knock
that
out
and
get
the
service
catalog
out
the
door
and
move
on
now.
Some
of
the
stuff
on
the
service
catalog,
like
the
helm,
charts
and
the
chart
museum,
are
lining
up
with
the
get
ops
piece,
so
things
are
overlapping,
which
is
good.
We're
only
doing
them
once,
but
we
just
need
to
get
some
of
this
just
off
our
list,
and
so
we
can
move
on.
F
G
G
F
G
F
G
H
A
Brad's
been
working
on
that
because
he
needs
it
from
the
the
good
op
side
and
ugeball
has
been
talking
asking
about
it
because
he
wants
to
write
that
get
the
documentation
firmed
up
around
the
new
install
process.
So
what
we
we
just
need
to
get
that
out
there
I'm
supposed
to
have
a
meeting
with
brad.
A
F
C
C
While
you
were
talking
so
as
far
as
I
understood
the
the
solution
that
you
are
looking
for
is
kind
of
similar
with
the
current
modern
apm
tools
like
app
timings
or
dynatrace,
because
they
start
tracing
the
transaction
from
the
end
user
side
by
just
inserting
a
javascript
or
an
sdk
to
the
application
and
follow
it
to
the
the
latest
backend
like
the
db
or
something.
So
we
know
that
we
need
an
entrant
transaction
flow
to
figure
out
in
here
right.
C
A
A
So
what's
in
running
in
your
dev
state,
coming
out
of
ci
could
have
a
new
required
parameter
where
what's
running
in
production
is
the
older
version
that
it
doesn't
have
that
required
parameter.
So
we
can
use
this
data
to
diff.
Not
only
the
differences
between
you
know
what
is
making
up
an
application,
but
also
dive
deeper
into
the
relationships
about.
You
know
somebody's
going
to
break
backward
compatibility
on
a
an
end
point
who's
affected
by
it
type
of
thing.
A
F
F
G
Much
hidden
there's
there
are
many
hidden
points
in
microservices,
because
the
transitive
dependencies
are
not
are
not
clear,
so
you
think
about
you,
know:
jfrog
made
their
living
off
of
tracking
transitive
dependencies
from
a
code
scanning
point
from
a
build.
You
know
a
monolithic,
build
we're
looking
at
doing
similar
things
in
a
microservices
world
and
that's
where
those
scanners
are
going
to
be,
I
think,
will
be
a
very
interesting
feature
and
what
we
have
to
decide
as
a
group
is
what
we
want
to
take
on
for
next.
F
G
D
G
F
G
F
C
C
Okay,
thank
you.
So
I
was
just
a
little
bit
feeling
alien
here,
so
keeping
mediocrity.
So
I
I'm
turkey,
I'm
an
I.t
professional
here
in
turkey,
working
as
the
head
of
it
ops
in
one
of
the
largest
software
companies
in
turkey
named
logo
software,
and
I
have
been
working
with
the
microservices,
the
managing
services,
with
using
microservices
and
devops
tools
and
processes
for
like
more
than
five
years
and
still
trying
to
learn
and
expand.
C
C
C
Science,
so
I'm
hoping
we
hit
him
in
these
calls.
I
I'm
still
trying
to
convince
him
about
just
putting
his
name
on
the
the
data
part.
I
see
just
two
names
there
and
I
keep
telling
him
so
there's
an
opportunity
here.
Why
don't
you
get
in
and
try
to
contribute,
so
I'm
in
the
middle
of
the
way.
So
I
think
he
will
be
here
soon
great.
G
C
G
Well,
they're,
now
that
we
could
have
a
team
of
university
folks
working
on
data
science,
then
you
know
we
have
a
lot
of
data
and,
as
as
we
start
bringing
in
all
of
this
data
about
these
other
transitive
dependencies,
we
have
even
more
data.
So
we
haven't
there's
an
interesting
proposition
out
there
for
the
data
science
side
and
I
think
arvin
you've
looked
at
the
better
display
of
our
data.
All
of
those
topics
are
really
really
critical
for
us
and.
I
D
G
G
That's
that
alone
is
pretty
powerful
information,
so
the
data
science
part
because
then
you
we
could
then
start
thinking
about
this
idea
of
risk
levels,
and
you
know
even
creating
kind
of
like
in
github.
You
can
star
a
project
that
you
like,
you
could
potentially
start
automatically
start
a
microservice
that
has
a
lot
of
dependence
or
is
impacting
a
lot
of
applications,
but
never
breaks.
G
C
Okay,
can
I
have
a
question
just
a
quick,
quick
one.
I
guess,
since
I
don't
know
the
tool
very
well
until
now,
are
we
keeping
track
of
the
incidents
in
the
scope
of
ortelius,
because
some
of
my
time
I
have
just
spent
a
little
bit
time
on
the
ai
upside
and
in
that
project
we
were
trying
to
bring
up
some
intelligency
on
on
the
incident
history
of
the
applications.
C
G
H
F
G
That
that
says
how
many
tickets
were
opened
on
it
or
because
we
don't
always
know
just
because
the
tickets
open
doesn't
mean
it
was
a
real,
a
real
problem,
but
we
could
certainly
add
integrations
to
incident
tools
to
take
that.
To
get
that
information
we
ourselves
would
would
not
be
a
support
desk,
but
we
should
be
able
to
integrate
into
that
in
the
in
the
future.
If
that's
something
that
we
feel
would
be
a
useful
piece,
and
I
think
it
would
be
because
of
that
kind
of
data.
G
G
D
G
A
A
We
had
the
cves
that
the
microservices
has
in
it
the
licenses.
Those
are
all
other
data
points
that
we're
starting
to
collect.
So
we
can
collect
anything
that
we
want.
We
can
start
collecting.
You
know,
apm
information,
you
know
summary
apm
information.
You
know
number
transactions
per.
Second,
for
example,
we
can
bring
that
in
so
any
of
that
data
that
we
want
to
collect.
A
The
one
thing
that
will
be
a
little
bit
tricky
on
the
the
machine,
learning
and
ai
side
is
we,
the
the
patterns,
are
going
to
be
harder
to
find
because
we're
going
to
be
looking
at
more
relationships
and
then,
instead
of
patterns
that
existing
in
a
large
data
set.
So
that's
going
to
be
the
interesting
part
when
we
look
at
it
from
an
ml
and
ai
perspective
is
how
we
can
leverage
those
tools
with
the
smaller
data
set,
but
also
be
able
to.