►
From YouTube: April 22, 2021 Ortelius Architecture Australia TZ
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
Hey
got
a
few
more
popping
in
here,
so
just
to
just
started
recording
on
this.
So
this
is
the
ortilius
architecture
for
the
australian
time
zone
on
april
22nd
we
kind
of
did
one
back
to
back
brad
and
I
and
a
few
others
did
one.
Last
week
we
decided
just
do
a
catch-up,
so
you
could
brad
could
invite
more
folks
from
your
side.
So
welcome
I'm
steve
taylor,
I'm
from
deploy
hub
one
of
the
main
contributors
to
the
artelias
project,
so
welcome
aboard
everybody.
B
We
really
appreciate
your
interest
in
our
open
source
project,
and
so
I
just
kind
of
like
to
to
throw
out
there
some
ideas
around
the
architecture
side
and,
if
you
so,
some
of
the
things
that
we're
looking
at
doing
from
the
architecture
standpoint
is.
B
B
We're
also
diving
into
the
dependencies
that
are
inside
of
a
like
a
container
image
so
like
what
are
all
the
python
modules
that
are
being
consumed
by
the
the
image
we're
going
to
do
the
same
for
go
and
probably
node.js
and
java
the
java
one's
a
little
bit
on
the
edge,
but
definitely
node.js
and
go
as
part
of
that
project
and
part
of
that.
B
That
scanning
for
the
service
catalog
is
finding
all
the
licenses
and
all
the
cves
that
are
in
a
inside
that
baked
into
the
image
at
that
level.
And
then
some
new
stuff
that
we
have
on
the
horizon
is
addressing
how
ortelius
can
fit
into
the
get
ops
world.
C
We're
familiar
with
it,
we're
not
by
all
means
pros,
but
it's
a
big
interest
to
us
and
it's
something
we
want
to
do
going
forward.
B
Okay,
because
some
of
the
one
of
the
projects
that
seems
to
be
popping
up
or
gaining
some
traffic
traffic
is
argo
cd
off
of
the
cncf
side.
B
B
B
So
one
of
the
things
that
we're
thinking
of
instead
of
kind
of
sticking
you
in
the
middle
of
a
ongoing
development
project
around
the
service
catalog,
would
be
to
have
your
group
focus
on
what
we
can
do
around
get
ops
and
how
we
can
take
the
data
that
artelias
has
and
drive
the
get
ops
process
around
that.
B
So
some
of
because
right
now
ortulius
has
a
deployment
engine
and
it
will
do
we
can
do
deployments
of
files.
You
know
regular,
like
jar
files,
your
files,
those
type
of
things
html
files
using
ansible
under
the
covers
to
sync
from
a
file
repository
over
to
your
endpoint.
B
B
File
for
the
driving
the
helm
part
because
ortilla
says
all
this
data
about
your
environment,
your
endpoints,
so
we
can
really
separate
what's
happening
as
you
move
through
the
the
pipeline
and
we
just
apply
different
data
to
those
helm
charts
over
and
over
now
I
go
close
the
door
because
the
dog
opened
it.
B
I'll
I'll
freeze
so
on
the
so
that's
kind
of
where
we
have
the
the
helm
charts
fitting
in
as
part
of
the
deployment
process,
the
override
files.
B
Now,
on
the
github
side,
it
gets
a
little
more
interesting
because
get
ops
is
focused
around
taking
like
your
deployment,
yamas
your
service,
yamas
secrets
and
those
type
of
things
and
throwing
them
all
into
one
big
repository
now
that
works
fine,
for
you
know
simple
what
I
would
call
monolithic
containers
where
somebody
took
their
java
application,
tomcat
and
containerized
it
and
pushed
it
out
to
a
kubernetes
cluster.
So
it's
not
really
a
microservice
architecture.
B
It's
just
one
big
container
image
running
so
things
like
the
git
ops
works,
really
easy
for
that,
because
you're
managing
a
small
number
of
deployment
yamls
in
the
get
repo.
Now
when
we
look
at
microservices
what
we're
seeing
is
about
six
about
eight
months
ago,
people
were
at
like
25
microservices,
most
people
that
we're
talking
to
now
are
at
the
100
to
200
range
of
microservices.
B
B
B
So
if
you
have
like
some
of
our
customers,
they
have
17
qa
environments,
you
know,
plus
all
your
development
environments,
plus
your
production
environment,
not
to
mention
all
the.
If
you
have
multiple
clusters
in
every
single
environment,
you
know
the
the
scale.
Just
you
know.
The
number
of
files
that
you're
dealing
with
and
and
those
pieces
kind
of
gets
out
of
hand
gets
unwieldy,
really
quick.
B
So
because
ortiz
has
this
data
that
we
can
apply
to
the
to
the
yama
files,
we
can
actually
start
doing
updates
from
ortillius
into
the
git
repo.
B
We
take
our
helm
charts
and
we
take
the
overrides
file,
create
that
and
we
let
the
gitops
operator
use
that
overrides
file,
plus
the
helm
chart
to
do
its
update
now,
if
it's
something
like
where
they're,
using
just
straight
deployment
files
or
straight
service
files
for
the
the
definition
and
then
we're
gonna
have
a
lot
more
of
these
files
that
we
have,
to
kind
of,
like
reverse
engineer,
go
and
substitute
the
the
data
that
we
have
and
then
reapply
it
to
the
git
repo
as
part
of
that
process.
B
So
some
of
this
is
going
to
be
research,
I
would
say
probably
50
50,
where
we're
going
to
need
to
need
your
group
to
do
some
research
around
like
flux,
around
argo,
around
fleet
and
whatever
the
other
get
ops.
Operators
are
out
there.
B
There
is
a
get
ops
working
group,
that's
coming
out
of
the
cncf.
They
meet
only
once
a
month
so,
but
there
is
that
resource
they're
starting
to
produce
some
some
documents.
B
I
don't
know
if
they're
trying
to
standardize
how
git
ops
is
structured
or
if
they're
really
focused
on
just
you
know,
trying
to
put
all
their
thoughts
in
one
place.
You
know
I
don't
know
if
they're
going
to
come
out
with,
like
a
standards,
group
or
standards
document
of
how
git
ops
is
supposed
to
work,
but
that's
going
to
be
some
of
the
research
that
you'll
need
to
look
at
from
your
side.
So
let
me
does
this
make
sense
for
any
interest
for
what
you
would
be.
C
C
B
Okay,
perfect
and
I,
and
as
far
as
like
the
ci
cd
pipeline
from
what
I
could
tell
it
around
the
get
ops
world,
it
doesn't
seem
to
matter
what
the
the
cicd
tool
is,
and
it
may
be
worthwhile
to
look
at
some
of
the
ci
cd
tools,
how
they're
interacting
with
git
ops,
because
we
may
be
able
to
use
their
solution
from
the
ortelius
side.
B
There
may
be
like
a
jenkins
plugin
to
say:
okay,
we
just
did
this
docker
build.
Now
we
need
to
go
ahead
and
update
the
deployment
yama
with
the
new
image
id.
For
example,
there
may
be
a
plug-in
in
jenkins
that
does
that
work
for
us
that
we
can,
we
could
adopt
their
methodology
at
that
practice.
I
think
code
fresh
is
doing
some
work
around
argo.
I
think
there's
a
demo
out
there,
which
shows
code
fresh
and
argo
kind
of
mirrored
together.
B
So
that's
kind
of
the
the
thought.
The
thought
process
that
I
have
right
now
about
what
we're
trying
to
achieve.
C
B
Be
it
would
be
the
so,
let's
say
it
would
be
the
the
customers
get
repo,
so
yeah.
So
let's
say
I
want
to
deploy
my
application
out
to
my
qa
environment.
B
What
ends
up
happening
in
the
git
repo
on
the
the
github
side
is,
I
believe
it's
called
an
environment
repository
which
you
go
and
toss
all
your
deployment.
Yamls
your
server,
seamless,
your
ingress,
all
those
different
kubernetes,
manifest
files
into
that
environment,
repo
and
then
on
the
other
side.
You
have
your
kubernetes
cluster,
which
has
the
argo,
which
has
the
get
ops
operator
like
argo
or
flux
running
in
it,
and
then
that's
configured
to
go.
Look
at
that
repo
for
updates.
C
Yeah
yeah,
okay,
cool!
I
know
flux
is
very
easy
for
that,
but,
like
you
said
everyone's
going
to
argo,
really
good
too
well,
we'll
try
all
of
them
and
and
report
back
the
research.
B
Yeah
and
in
some
like
argo,
just
came
out
with
a
they
just
had
a
release,
they're
calling
it
an
application,
control,
plane
or
application
sets
basically
they're
running
into
a
problem
with
the
number
of
files
that
they
were
needing
to
manage
in
the
environment
repository.
B
So
these
environment
repositories
live.
You
know,
they're,
just
like
your
source
code
repository,
but
they
contain
all
the
deployment
and
all
the
deployment
manifests.
So
that's
where
those
that
repository
lives.
It's
like
just
another
repository
that
the
developers
are
going
to
go
and
update.
That's
that
brings
up.
B
Another
point
is,
I
don't
know
who's
updating
these
if
the
developers
are
creating
these,
the
the
deployment
yamls
or
if
it
is
operations
so
or
if
it's
like
an
sre,
that's
doing
that
that
work
to
do
the
the
update,
so
I
really
don't
know
who's
actually
doing
the
updates
to
the
the
the
files
you
know
or
if
it's
automated,
like
we
were
talking
about
jenkins,
but
ortilius
has
all
this
metadata
that
we
can
that
we're
pulling
out
of
the
build
build
cycle
and
that
we
can
then
overlay
on
top
of
those
the
manifests
and
really
drive
the
process
very
cleanly.
C
Yeah
and
when
let's
talk
about
the
files
again
sorry,
so
I
believe
you
said
they're
jar
files,
html
files,
a
mixture
of
files,
do
you
use
or
the
customers
artifact
repository
like
artifactory
or
mixers
or
yeah.
B
So
the
in
in
the
get
ops
world
most
of
it
is,
is
focused
around
kubernetes.
So
we're
not
gonna
be
dealing
with
like
a
jar
file
deployment
into
a
websphere
cluster
or
something
like
that.
D
Makes
it
easier,
I
I
have
a
question
so
generally
for
repositories.
What
is
the
flavor
that
you
are
using?
Is
it
github
visit
gitlab
and
are
any
of
your
customers
using
the
tools
from
those
particular
companies
itself
like
github
actions
or
gitlab?
Has
their
own
ci
cd.
B
Yeah,
so
both
gitlab
and
github,
and
sometimes
you'll,
see
bitbucket
show
up
as
part
of
that.
But
what
ends
up
happening
is
on
the
ci
part
when
you
check
in
your
code,
you're
going
to
go
ahead
and
create
so
think
of
each
microservice
is
going
to
have
its
own
git
repo.
B
So
if
I
have
a
hundred
100
microservices,
I'm
going
to
have
100
git
repos
now
I'll
have
one
additional
101.
That
last
repository
will
be
the
repository
that
contains
all
the
deployment
manifests.
Files
for
kubernetes.
A
B
So
that's
where
they
kind
of
bring
together
all
the
microservices
into
one
place
that
they're
going
to
deploy
from
and
in
that,
because
what
the
the
goal
of
git
ops
is
to
be
able
to
have
a
a
recording
or
a
like
an
immutable
place
for
all
changes
to
come
from.
D
B
If
you
just
look
at
the
service
and
the
deployment
files,
if
you
separate
them
out,
you
have
200
files,
then,
in
that
repo,
just
for
one
deployment.
Now,
if
you
have
four
to
four
environments,
you
have
a
a
dev
environment,
you
have
a
test
environment,
you
have
a
uat
or,
and
then
production.
I
got
four
copies
of
that,
so
you
have
800
files
that
you're
managing
at
this
level.
B
So
and
that's
just
a
simple
case,
and
that's
where
the
the
get
ops
world
is,
I
don't
think
they
see
it
yet
the
the
scaling
problem
that
they're
gonna
have-
and
I
think,
they're
doing
some
tricks
to
minimize
number
of
files
and
kind
of
try
to
reuse
some
of
that
stuff.
So
you
don't
have
to
reinvent
or
read
recreate
everything
for
every
single
stage
of
the
of
the
life
cycle,
for
example,
so
they're
they're
doing
some.
B
I
think
some
tricks
around
that
front
and
that's
where
we
have
to
see
how
they're
doing
it
and
what
we
can
do
from
the
art
or
to
the
aside
to
go
ahead,
and
you
know
if
they're,
creating
like
a
template
and
then
they
have
values
that
they're
going
to
apply
to
the
template
that
we
can.
I
think
it
was
argo,
was
doing
a
templating
route
at
that
level.
B
B
And
you
know
the
the:
what
will
happen
is
after
we
get
the
research
done,
then
we'll
go
ahead
and
the
service
catalog
project
should
be
wrapped
up
and
we'll
be
able
to
start
coding
things
and
we'll
throw
some
code.
Your
way.
B
I
th
that's,
that's
robbie
is
a
pretty
good
idea
to
a
white
paper
or
even
some
high
level
design
docs.
You
know
on
the
recommendation
of
how
we
should
approach
this.
C
And
what
would
you
call
it
just
that?
What
would
we
call
this
document.
B
I
the
document
name
would
be.
I
would
almost
go
the
route
of
saying
automating
get
ops
with
ortelius
yeah.
B
And
there's
a
whole
there's
a
whole
piece
of
the
puzzle,
and
this
will
kind
of
come
into
your
question.
A
minute
where
who
is
the
git
provider?
Because
when
we
get
in
part
of
the
get
ops
process
is
to
deal
with
prs?
And
so
in
the
github
world?
They're
called
prs,
I
believe
in
the
gitlab
world,
they're
called
merge,
requests.
A
B
B
C
I
like
the
idea
of
the
the
rest,
api
or
any
sort
of
api,
because
then
you
can
any
of
the
actions.
You
just
call
that
api
anyway,
so
you
have
like
an
interface
where
it's
always
going
to
be
the
same,
and
you
don't
have
to
develop
something.
That's
let's
say.
For
example,
you
do
github
actions
and
then
okay,
okay,
now
I
need
a
jenkins
plugin.
C
Now
I
need
bitbucket
pipeline
and
if
we
have
the
rest
api
it
just,
we
will
adapt
those
tools
around
to
suit
our
framework,
which
seems
like
a
better
way
to
go.
B
Yep
exactly
totally
agree,
so
we'll
have
to
kind
of
identify
the
so
that
that's
kind
of
like
the
second
part
of
it
is
identifying
the
the
process
that
people
are
utilizing.
You
know,
are
they
like,
especially
like
on
the
jenkins
side?
B
You
know:
are
people
doing
the
docker
build
and
then
they
have
like
a
jenkins
plug-in
step
that
updates
the
deployment
yaml
with
the
new
image
id
and
then
do
they
call
go
ahead
and
call
a
github
action
to
create
a
pull
request
automatically
and
then
do
they
automatically
approve
and
merge
the
pull
requests
all
based
on
jacob's
pipeline.
C
Emma's
done
a
little
bit
of
work
around
that
with
like
the
commit
show
that
will
be
tagged
with
the
container
and
the
deployment
environment.
He
does
that
with
helm.
Don't
have
it
so
yeah.
You
might
have
some
good
ideas
around
that.
D
Yeah,
so
currently,
we
basically
do
all
of
that
using
helm
and
helm
file
which
we.
So
that
is
our
simplification,
since
we
don't
currently
use
argo
right
thinks
all
the
respective
helm
charts
at
one
shot,
verifying
based
on
what
was
the
previous
file
version
and
what's
the
current
file
version.
B
But
I
don't
know
if
that's
like
a
requirement
or
that's
the
way
most
people
are
going
or,
if
they're,
just
writing
pure
yama
files
and
dealing
with
maybe
a
an
argo
templating
mechanism.
That's
kind
of
the
the
unknowns
that
around
the
github
side.
D
So
one
of
the
things
we
currently
do
is
we
use,
so
even
in
helm
you
can
use
go
templating
in
order
to
simplify
the
whole
thing
and
we
would
write
functions
on
the
background
for
some
of
them.
So
probably
one
thing
we
can
do
is
consolidate
all
those
functions,
so
you
have
that
one
single
function
for
all
your
respective
repositories,
similar
to
your
environments,
repository
and
using
that
repositories
functions.
D
C
D
B
Because
we
have
all
this
data
and
when
we,
you
know
just
think
of
service
catalog
and
what's
coming
out
of
the
build
and
where
things
have
gone
and
what
the?
What
versions
are
where
we
keep
track
of
all
that
on
all
those
relationships.
So
we
have
all
tons
and
tons
of
information
that
we
can
utilize
in
the
github
solution.
So
if
it's
not
there.
D
C
And
in
terms
of
I
know,
we
don't
know
too
much
about
the
architecture
of
our
tv
show,
but
once
you
did
sort
of
come
up
with
a
solution,
would
this?
How
would
you
tie
that
back
into
the
autelius
architecture?
Like
I
know,
that's
a
very
rough
question
and
we
don't
know
yet,
but.
B
Right
so
what
we
would
need,
once
we
figure
out
what
people
are
are
doing
and
how
the
get
apps
operators
are
structured.
So,
let's
say
we're
gonna,
we'll
just
stick
with
argo.
We
know
that
argo
has
a
set
of
you,
have
to
we're
gonna,
go
ahead
and
update
a
deployment
yaml
file
with
like
the
the
image
tag.
B
Let's
just
keep
it
simple
that
we
may
then,
like
you
said
admit,
do
some
go
templating
to
go
ahead
and
and
some
go
programs
to
go
ahead
and
do
that
and
what
we
would
do,
then,
is
from
the
artelia
side
when
you
would
go
to
deploy
or
from
the
artelia
side
instead
of
deploying
through
helm.
B
We
would
actually
go
ahead
and
interface
it
to
that
go
program
to
go
ahead
and
update
the
the
deployment
yamo
and
then
the
next
step
would
be
probably
to
do
more
than
likely
create
a
pull
request
on
the
fly
and
then
get
it
to
a
place
where
people
can
look
at
it
from
a
pr
perspective
to
approve
and
then
merge
and
let
the
the
get
ops
operator
do
all
the
work
from
from
there
on
out
kind
of
what
I'm
thinking
yep
and
then
there's
one
like
on
on.
B
I
know
on
most
of
these
there's
a
kind
of
back
end
part
of
it.
So
let's
say
we
go
ahead
and
get
do
all
that
automation.
I
just
talked
about
there's
a
pr
out
there.
It
sits
out
there
for
a
week,
so
we
actually
got
it
staged
ready
to
go
but
somebody's
waiting
to
approve
it
and
and
do
the
merge
that
will
actually
need
another
hook.
Coming
back
from
the
the
get
ops
operator
saying
that
it
completed
that
task.
B
So
let
the
wait
catch
a
notification
coming
back,
so
we
can
record
that
what
we
thought
that
would
this
image
tag,
name
that
we
just
updated
actually
did
go
to
where
we
thought
it
was
going
to
and
it
got
completed.
So
we
can
record
that
that
relationship.
B
When
I
was
looking
at
argo,
they
had
what
they
called
a
notification
entry
point.
So
let's
say
you
wanted
in
the
example
is
around
slack.
So
after
a
argo
did
updated
the
cluster,
you
could
send
a
slack
notification
to
say
that
this
cluster
is
now
up
to
date
with
a
in
sync
with
the
to
get
repo.
C
Yeah,
I
think
it's
a
great
idea
to
research
first,
because
there's
a
lot
of
research.
C
C
B
There's
a
bunch
out
there
you
know
in
some
of
it
is
some
of
the
cicd
tools.
I
think
parts
of
them
are
going
to
go
away
like
on
the.
B
If
you
look
at
the
front
end
process
of
us
like
a
jenkins
pipeline,
you
know
where
you're
doing
the
build
and
you're
doing
like
a
unit
test
and
then
maybe
you're
going
to
do
a
deployment
to
development.
That'll
all
be
just
collapsed
into
like
a
github
action
or
a
google
cloud
build
we're
actually
doing
all
that
work
at
the
docker
build
time.
B
So
you
actually,
when
you're
doing
in
the
multi-layer
docker
build.
You
actually
would
be
running
your
j.
Your
your
unit
test
in
that
before
you
even
say
that
the
image
is
good
to
go.
You
know
you
can
go
and
actually
run
some
some
string
tests
or
unit
tests
at
that
level,
so
the
the
pipelines
are
going
to
get
smaller,
but
also
at
the
same
time,
they're
going
to
get
they're.
B
I
think
they're
going
to
get
more
towards
an
event-based
system
where
you
can
plug
and
play
events
into
the
whole
pipeline
process
as
well.
So
captain
is
one
of
those
event-based
ci
tools
and
it
looks
like
the
the
cn
cdf
is
moving
forward
with
an
events
based
sig
to
kind
of
tie
tie
together
these
different
orchestration,
ci
cd
tools
through
event
throwing
events
around.
So
it's
going
to
be
evolving
here,
pretty
quick,
I
think
around
the
pipeline.
A
B
Yeah
I.
C
I've
just
been
updating
the
the
google
doc
on
the
meeting,
minutes
etc.
In
terms
of
I
was
looking
through
the
github
as
well.
We
don't
seem
to
have
a
issue
for
get
ops.
I.
B
Have
not
created
one
yet.
I
wanted
to
make
sure
you're
on
board
and
we'll
we'll
go
ahead,
and
if
you
want
to
go
ahead
and
create
one
on
feel
free
I'll,
if
not
I'll,
create
one
tomorrow.
B
Then,
if
you're
not
part
of
the
the
artelias
google
groups,
please
join
that
because
it
gives
you
access
to
all
the
all
the
documents,
all
the
events
and
all
that
stuff.
B
So
it's
just
ortilius
dev
at
google
groups.com
is
the
email
address.
I
think
most
of
you
are
probably
going
to
be
on
there,
but
that
is
how
we
control
the
security
and
then
on
the
github
repo
side.
B
If
you
could
make
a
pull
request
against
the
readme
in
the
ortelius
artedious
repo
just
add
your
name
in
one
of
the
sections
you'll
see
like
different
sections
and
you
brad.
If
you
want
to
put
in
a
github
section
in
that
readme
when
you
do
the
pr
on
that
allows
me
to
pick
up
your
github
handle
and
set
up
the
github
security
from
there.
C
Sure
yeah
I
I've
I've
already
done
a
pr
to
yeah,
I'm
happy
for
the
yeah.
B
Yeah
and
then
that
way
we
can,
I
can
make
sure
when
we
get
to
the
next
phase
of
like
coding
and
things
like
that,
you're
in
the
right
teams,
and
all
that
all
the
github
security
is
all
set
up.
It's
it's
a
an
extra
step,
but
it's
weird.
I
can't
assign
I
issues
or
anything
like
that
to
people
that
are
not
part
that
have
never
done
a
pull
request
against
the
repo.
C
B
The
only
other
thing
I
have
is
the
next
meeting,
which
I
think
we
have
a
week
from
today,
but
let
me
double
check
it.
I
think
I
put
a
repeating
meeting
out
there.
B
Yes,
so
a
week
from
today
would
be
our
next
architecture
meeting
again
so
next
thursday
we
will
have
the
architecture
meeting
at
8
30
my
time
and
then
we'll
do
4
30
my
time,
which
is
the
one
we
just
did
today.
So
next
thursday,
we'll
have
I'll
do
two
meetings,
one
for
the
states
and
one
for
you,
folks
that
fits
better
into
your
time
slot
and
then
you'll
be
on
the
same
cadence
every
two
weeks
from
there
going
out
forward.
If
that
works.
For
you.
C
Two
weeks
is
a
good
cadence,
because
we
all
have
jobs
as
well.
So
I
feel
like
two
weeks
we
can.
B
C
And
I
was
gonna
well,
we've
got
tim
on
the
line
as
well
so
tim
and
I
have
done
a
lot
of
chat
ops
in
the
past,
so
I
thought
I
know
that
that's
parked
at
the
moment,
but
I
thought
maybe,
if
we
do
have
you
know,
we've
got
20
minutes
left.
Maybe
we
want
to
talk
just
briefly
on
channels
and
and
just
to
put
in
the
back
of
our
heads.
Maybe
what's
going
to
happen,
you
know
in
the
future
regarding.
B
Yeah,
so
my
thought
on
that
is
well
there's
a
couple
pieces
of
functionality
around
ortelius
and
chad,
ops,
one
is
this,
the
the
obvious
one
which
is
starting
out
kicking
off
a
deployment
at
that
level.
The
so
I
want
to
deploy
this
version
of
this
application
to
this
environment.
B
Pretty
simple,
there's
restful
apis
on
the
ortelius
side.
That
already
exists
that
you
can
hook
up
against
at
that
level
to
do
that
type
of
deployment.
The
other
thing
would
be
to
do
queries
about
what
is
you
know,
go
and
give
me
all
the
details
about
this
micro
servers.
That's
running
in
production,
so
go
give
me
the
service
catalog
details
from
that
that
standpoint.
So
that's
kind
of
what
was
the
give
me
the
the
is
between
one
deployment
and
the
next
deployment.
B
So
there's
there's
things
around
more
what
you
would
think
from
a
operations
point
of
view.
I
need
to
do
some
investigation
work.
Can
I
start
throwing
some
questions
at
a
a
chat?
Ops.
B
You
know
at
a
slack
channel
and
have
they
have
the
bot
return
me
some
information
that
I
can
start
doing
my
investigation
with
from
there
going
forward.
So
those
are
kind
of
two
worlds:
I'm
seeing
on
the
chat
up
side.
C
B
So
there's
yeah,
there's
a
yeah
there's
a
bunch
of
restful
apis
out
there
to
go
retrieve
information
from
artelias,
so
it
was
just
going
to
be
a
matter
of
which,
what
information
we
want
to
bring
back
and
interact
with
from
the
chat
up
side
and
then
from
there
we'll
make
sure
the
apis
are
available.
B
C
Yeah
and
tim,
are
you,
are
you
interested
in
get
ops
or
or
do
you
want
to
stick?
It
chat
ups
like
what
are
your
thoughts
or
even
if
you
have
time
to
do
anything.
A
I'm
definitely
interested
in
both
yeah.
I
guess
the
chat,
ops,
one.
We
would
need
to
better
understand
the
deployment
architecture
for
ortelius.
You
know
how
does
it
commonly
get
deployed
where
a
bits
and
pieces
is
going
to
fit
in
with
the
model
that
we
already
have
in
place?
A
But
I
understand
from
what
you're
saying,
but
that's
currently
parked
a
lower
priority.
So,
given
that
yeah
sure
we
can
progress
the
discussions
in
the
background,
but
it
sounds
like
it
upsets
the
primary
focus
at
this
point
in
time
and
that's
that's
fair
enough
cool
and
I
think
from.
B
A
getting
to
know
ortilius
that,
starting
with
the
get
ops
you'll
get
a
better
flavor
for
ortulius
overall
and
the
different
pieces
of
it,
and
then
from
there
the
the
chat
ops
will
go
a
lot
easier
to
to.
You
know
basically
build
out
the
language
set
that
we're
going
to
be
using
on
the
chat
up
side.
B
A
B
Exactly
so,
the
goal
would
be
to
simplify
the
whole,
get
ops
process
through
artelias.
So,
like
you
said,
if
you
want
to
revert,
you
want
to
go
backwards
to
a
commander.
If
you
want
to
go
back,
a
couple
commits
that,
through
the
chat,
ops
and
ortelius,
you
can
get
to
that
point
fairly
easy
without
having
to
jump
through
a
bunch
of
hoops
on
the
get.
C
C
Cool,
I
think,
that's
pretty
much
summarizes
yeah,
it's
a
good
understanding
of
what
what
we
want
this
group
to
be
doing
so
I'll
also
join
the
cncf
working
group
for
the
get
ops
as
well
just
to
see
what
they're
up
to.
Maybe
we
can
deliver
some
of
their
work
too.
B
Yeah
last
time
I
was
on
one
of
their
meetings.
It
was
at
11
a.m
or
like
noon
mountain
time,
which
would
put
it
at
a
god-awful
hour
for
you.
C
C
Okay
and
then
in
terms
of
the
white
packet:
well,
if
we
do
a
white
paper
or
architecture
diagram,
do
you
have
a
specific?
Do
you
want
to
make
that
template
then
add
us
as
a
contributor
so
that
it's
all
under
the
under
your
name
or
do
you
want
us
to
do
it
then
pass
it
to?
How
do
you
want
to
do
that.
B
It
doesn't
matter
to
me
we
if,
just
let
me
know
what
you
need
if
we
need
to.
If
you
want
your
own
repo
to
put
like
readmes
and
markdowns
in
there,
we
can
go
that
route.
We
could
do
it
off
of
the
existing
documentation.
B
All
of
the
user
guide
and
contributor
guide
are
all
markdowns
that
run
underneath
a
hugo
server.
So
they're
served
up
that
way,
so
we
can
actually
start
out
in
your
own.
B
If
you
want
to
do
a
get
ops
repo,
where
we
can
put
all
the
documentation
and
that
pieces
and
then,
when
you're
ready,
we
can
fold
it
into
the
documentation,
repo,
whatever
works
the
best
for
you
just
let
me
know
and
we'll
get
it
set
up
for
you.
C
Yeah,
I
think
personally,
I
would
like
to
just
give
her.
Even
I
think
it's
the
easiest.
What
do
you
guys
think.
A
A
B
Yeah-
and
I
just
like
I
said
I
need
you
to
yeah-
do
the
do
a
pr,
so
I
can
get
your
handles
underneath
the
organization.
B
Okay
and
if
you
could
put
your
handles
in
or
throw
them
at
me
through
discord,
either
way,
then
I'll
make
sure
that
I
get
get
everything
associated
with
the
right
repo,
okay,
yeah.
B
And
what
I
may
do,
brad
is
just
make
you
an
administrator
at
the
organizational
level.
Let
me
just
do
that
real
quick.
B
And
then
that
way
you
can,
if
anything
comes
up,
then
it's
like
middle
of
the
night
for
me
that
you
can.
B
B
B
For
some
reason
I
can't
find
it,
but
I'll
get
you
set
up,
so
you
you're
that
admin
at
the
organization
level
so
you'll
be
able
to
create
repos
and
manage
teams
and
stuff
like
that.
C
Yep
and
just
for
the
other
two
people
on
the
call
james
and
fireflies.ai
music,
we're
about
to
use
at
the
moment.
B
So
james
actually
is
in
the
states
with
me
in
albuquerque,
so
he's
with
our
side.
C
A
Not
particularly,
I
guess
it's
more
discussion
for
us
offline
in
terms
of
how
we're
going
to
structure
this
to
move
it
forward,
I'm
sure
we
can
deal
with
that
down
the
track.
C
F
C
C
So.
In
summary,
we
have
three
action
items.
I
joined
the
scenes
here.
Well,
we
all
should
really
join
that
group.
I'll
go,
get
up,
get
ups
issue
for
and
github
and
then
we'll
set
up
the
repo
for
the
the
get
up,
stop
orientation
and
etc
and
then
we'll
meet
back
next
friday
same
time.
B
C
C
C
Yeah
thanks
very
much
for
giving
us
a
friendly
time
as
well.
We
appreciate
it.
B
Oh
no
problem,
thank
you
all
for
your
interest
in
artelias
and
I
think
you're
gonna
have
some
fun
with
this.
This
project.
C
Yeah,
it's
very
exciting,
we'll
be
able
to
get
a
blog
going
from
it
and
we
can.