►
From YouTube: February 4, 2021 Ortelius Architecture Working Group
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
So
I
threw
the
link
to
our
working
group
doc
in
the
chat
and
today's
media.
We're
gonna
go
over
the
application
sets
and
what
they
mean
to
us.
So
in
a
little
more
detail,
I
did
write
up
a
document
about
how
it
kind
of
fits
in
with
our
world.
C
Document
is
your
document
in
google
docs.
B
But
one
of
the
things
I
I
went
through
the
basically
the
concepts
of
what
we
have
going
on
in
in
the
I'll,
never
find.
B
So
one
of
the
things
that
when
I
went
through
and
was
looking
at
what
they're
talking
about
between
argo
and
spinnaker,
one
of
the
things
I
and
I
kind
of
knew
this
go
going
into
it
was
terminology-
is
throws
a
whole
new
loop
in
this
ball
game
and,
I
think
chrome.
You
ran
into
that
as
well.
When
you're,
when
you're
listening
to
the
to
the
recording,
you
know
the
the
term.
Application
is
just
reused
over
and
over
in
different
contexts.
B
So
just
a
high
level
in
the
the
where,
where
I
kind
of
see
the
get
ops
and
the
argo
cd,
which
is
a
get
ops
based
implementation
coming
from
the
angle
that
they're
looking
at,
is
initially
around
the
deployment
of
a
single
image
into
a
kubernetes
cluster.
So
it's
deploying
a
monolith
into
kubernetes
and
because
they're
deploying
a
monolith,
they
were
calling
that
an
application.
B
The
same
thing
happened
in
the
netflix
world
netflix.
They
were
deploying
vms,
basically
or
ec2
instances
out
to
aws
and
those
were
the
applications
so
those
pieces
of
their
monolith
running
as
what
they
would
call
an
application,
because
it's
actually
on
a
ec2
instance.
C
Steve
could
ask
a
question:
yep.
Does
argo
cd
have
a
get
ups
operator
of
its
own.
B
C
B
And
that's
how
come
you
could
see?
Argo
cd
married
up
with
like
code
fresh.
B
B
Code
fresh
has
is
like
us,
they
have
their
own
deployment
engine,
but
they
are
more
of
a
pipeline
that
is
trying
to
conform
to
the
gitops
model.
So
they
let
argo.
Do
the
underlying
sync
of
the
of
the.
B
Cluster,
so
one
of
the
things
that
I
found
interesting
is
on
the
argo
cd
side.
What
they
look
at
is
what
they're
calling
manifests.
B
You
could
have
a
deployment
manifest,
which
is
actually
going
to
be
the
yama
for
defining
the
basically
the
container
image
and
the
pods
to
kubernetes,
and
then
you
have
a
service
manifest,
which
is
all
the
networking
pieces
to
connect
the
inbound
with
the
the
pod.
So
those
are
typically
packaged
together.
They
may
live
in
separate
files,
but
that
is
what
they're
they're.
That's
the
only
like
relationships
that
they
kind
of
have
is
is
pulled
together
at
that
level.
B
So
a
manifest
in
kubernetes
is
going
to
be
a
chunk
of
yaml
code
that
defines
the
inputs
to
a
particular
kubernetes
resource,
so
a
deployment
manifest
is
used
to
define
your
pod
a
service
manifest
is
used
to
define
your
ingress
and
egress.
B
You'll
have
config
map
manifests
that
define
configuration
parameters
and
there's
a
whole
another.
There's
other
sets.
B
Yes,
they're
all
they
could
be
smashed
together
in
one
big
yaml
file
or
they
can
be
broken
out
into
individual
yaml
files,
but
they
all
live
within
the
environment
repository
and
what
the
the
environment
repository
is.
The
repository
that's
being
used
to
do
the
deployments
from
and
succinct
to
so
what
ends
up
happening?
Is
you
have
your
source
code
repository,
which
is
your
golang
or
python
code
that
is
separated
from
the
deployment
part
of
it,
which
is
called
the
environment
repository?
B
Yes,
they
in
the
in
our
in
the
argo
cd
world
in
order
to
keep
a
check-in
of
a
source
code
from
triggering
a
deployment.
Even
though
the
the
build
hasn't
completed,
you
have
to
break
it
into
two
different
repositories
in
order
to
get
the
the
triggering
to
work
in
the
right
order.
B
B
No,
what
it
is
is
a
triggering
chain.
So
when
you
have
a
source
code
change
coming
in
that's
going
to
trigger
an
action
in
the
repository
when
you,
when
you
check
in
source
code,
the
action
that
you
want
to
execute
is
creating
the
image,
which
means
you
have
to
go.
Basically
compile
your
code,
create
your
image
and
publish
your
image
to
a
repository.
C
C
B
B
Concept
was
already
fixed
by
razer.
So
what
happens
in
this
get
ops
world?
Is
you
need
to
be
able
to
separate
the
data
from
the
definition,
even
though
you
want
it
to
be
immutable
and
hermetic
in
order
to
roll
out
to
hundreds
of
clusters
that
have
unique
information,
you
have
to
basically
separate
out
the
that
information
and
because
you're
in
the
git
ops
world
every
time
you
make
a
change
to
the
environment
you're
going
to
actually
trigger
out
another.
You
end
up
in
a
circular
loop
as
part
of
that
process.
B
So
what
the
application
sets
in
argo
cd
are
trying
to
do
is
dealing
with
configuration
and
it
it's
really
trying
to
separate
data
from
definition
and
do
like
a
templating
process.
But
it's
very
hard
when
any
time
you
touch
the
environment
repository
things
all
of
a
sudden
start
taking
off.
B
So
the
concept
of
application
sets
in
argo
is
really
focused
on
what
they
call
generators
templates
and
the
sync
policy.
B
B
So,
in
this
case,
they
want
to
install
a
set
of
identical,
manifests
across
all
clusters,
for
example
install
the
same
helm
chart
across
all
clusters,
so
that's
one
other
use
cases
that
they
have
that
the
application
sets
through
the
generator
and
the
templates
can
be
used
to
push
in
data
into
the
helm,
chart
some
of
the
other
ones,
the
same
helm
chart
but
different
values
for
every
cluster.
B
Let's
see,
I
want
to
deploy
multiple
versions
to
the
to
the
multiple
namespaces
with
different
configurations.
Those
are
the
types
of
things
that
they're
really
trying
to
address
is
how
to
get
this.
This
metadata
into
a
template
with
it's
still
all
being
hermetic
and
all
and
get
and
saving
all
the
the
history
and
everything
like
that
is
what
they're
trying
to
achieve.
B
So
that's
where
the
the
application
set
comes
from,
but
it
really
has
nothing
to
do
with
relationships
between
applications.
It's
just.
B
B
B
We
handle
that
very
easily
because
we
tie
the
data
to
a
component
application
environment
endpoint.
We
don't
have
the
data
tied
to
the
actual
implementation.
So
we
don't.
We
don't
push
data
into
a
helm
temple
a
helm
chart,
for
example,
we'll
take
our
data
from
ortilius
at
the
application
component,
whatever
level
it's
coming
from
and
create,
what's
called
an
overrides
file
that
will
allow
us
to
override
any
of
the
values
that
it's
already
in
the
existing
helm
chart.
So
because
of
that,
we're
able.
C
B
B
Base
definitions
of
the
of
the
component
like
in
the
base
definition
of
a
component.
We
have
the
image
shot.
The
image
tag,
the
registry
that
it
was
pushed
to,
so
that
information
will
get
pushed
into
the
helm
chart
as
an
overrides,
so
we
never
have
to
go
in
and
update
a
helm
chart.
We
actually
just
pass
in
the
data
into
it
as
part
of
that
process
and
helm
is
a
great
templating
engine.
It's
based
on
goaling
and
golang
has
a
very
strong
templating
process
engine
built
into
it.
C
B
I'd
have
to
look
at
that
because
one
of
the
things
argo
and
chrome
found
this
as
well.
Argo
is
not
a
ci
cd
tool.
That
literally,
is
a
right,
a
sync
tool.
B
C
And
could
we
then
take
our
override
file
in
our
helm,
chart
generate
the
helm,
chart
and
push
it
to
them.
B
C
B
Have
to
figure
out
at
the
where
the
the
application
set
is
is
storing
this,
this
additional
data,
as
part
of
that
I
don't
know
if
it's
in
their
ui
or
or
how
it's
getting
managed
and
how
they're.
B
Basically
after
you
apply
a
let's
say,
you
have
to
apply
a
a
new
name,
space
name
as
part
of
your
like,
in
this
case,
install
the
same
helm
chart
with
different
values
for
every
cluster.
I
don't
know
what
ends
up
happening
on
the
get
repo
side
if
they
are
actually
checking
in
something
just
for
that
cluster
to
let
it
sink,
and
then
they
go
on
to
the
next
cluster
and
wait
for
that.
So
they
have
this
big
serial
process
that
has
to
happen
because
it's
all
up
against
the
same
repo.
B
I
don't.
I
didn't
get
into
the
exact
implementation
that
they
did.
B
One
last
thing
on
argo:
they
really,
they
did
say
they
need
the
aggregate.
They
call
it
aggregation
of
applications
and
application
set
for
as
a
future
requirement
as
part
of
that.
So
they
are.
They
are
looking
at
this
concept
of
an
aggregation
at
some
point.
B
C
Why
it's
much
better
last
statement
steve
when
they
talk
about
the
aggregate?
The
aggregation
of
applications.
Is
that,
like
full-on
solutions
that
are
being
pushed
out
like
a
release,
train.
B
No,
it
let
me
go
to
there.
B
B
Yep,
oh,
that's,
generators,
get
generators,
cluster
generators.
B
Yes
and
like
they
have
these
templating
engines
and
we
may
be
able
to
pass
them
the
data
for
these
templating
engines.
C
Okay,
so
I
think
what
we
should
do
is
get
put
together.
If
you
can
have
some
ideas
of
what
benefits
we
can
bring
to
argo
and
then
I'll
circle
back
around
with
the
argo
team
and
ask
for
an
if
we
can
do
a
follow-up
call
and
let
them
know
what
we're
thinking.
B
B
D
B
I
believe
so
yeah
it's
gonna
be
keep
this
thing
in
in
and
that's
the
whole
git
ops
concept
is
keep
git
is
going
to
be
the
desired
state
and
always
bring
even
though
these
tools
can
do
overrides,
but
the
the
the
concept
behind
git
the
get
ops
is
git
is
going
to
be.
My
desired
state.
Make
my
cluster
look
like
my
desired
state.
C
So
I'm
writing
a
blog
right
now
for
our
blog
blogathon
on
the
pros
and
cons
of
git
ops
and
it's
in
the
blog
directory
in
our
google
docs.
So
if
you
guys
want
to
take
a
look
at
it,
give
me
some
feedback
that
would
be
huge
and
I
think
it
defines
get
ops
fairly.
Well,
I'm
also
doing
a
presentation
for
skill
up
days,
which
is
on
the
25th,
and
I
I
did
did
a
presentation
on
it.
C
So
I'm
learning
as
well
learning
and
talking
about
is
really
hard,
but
it
covers
some
of
these
topics
that
steve
just
covered.
So
this
is.
B
C
B
So
one
of
the
things
on
argo,
their
their
what
they
call
a
deployable
unit
is
the
smallest
deployable
unit
is
going
to
be
a
manifest
of
some
sort.
So
it
could
be
a
service
manifest.
It
could
be
a
pod
manifest
a
deployment
manifest
a
config
map
manifest.
So
that's
what
they're
they're
looking
at
and
that's
because
and
the
reason
for
that
is
that's
the
smallest
unit
in
kubernetes-
is:
are
these
different
objects
in
kubernetes?
B
So
just
keep
that
in
mind.
So
if
you
check
in
you
know,
10
different
deployment
files
into
your
environment,
repository
and
three
of
them
have
changed.
They'll
go
ahead
and
send
those
three
out
as
part
of
the
process.
B
B
And
in
the
spinnaker
world,
like
I
was
saying
when
we
first
started
talking
is
there
in
their
world
an
application
is
defined
as
a
deployable
unit
and
what
that
deployable
unit
can
be
basically
any
manifest
and
the
way
they
actually.
B
Let's
say
you
want
to
do
wordpress,
so
wordpress
needs
now
the
wordpress
container
image,
but
also
it
may
need
like
a
mysql
container
image
as
well.
So
there's
two
container
images
that
need
to
be
deployed
for
wordpress.
B
What
you
would
do
is
you
put
both
of
those
into
either
a
single
home
chart
or
a
single
deployment
yaml
file,
and
because
you
have
and
that's
the
way
they
do,
their
their
grouping
is
by
the
developers
actually
put
concatenating
together.
These
ammo
files
into
basically
one
big
one
that
will
be
passed
to
spinnaker
to
do
the
work
of
deploying
it
over
to
the
cluster.
C
B
No
and
I
I
did
not
get
into
exactly
how
spinnaker
is
storing
or
referencing
those
those
manifests,
I
would
imagine
that
it's
either
going
to
be
a
pointer
to
a
manifest.
That's
in
a
repository
or
you
have
to
like
upload
it
into
the
spinnaker
tool.
A
So
it's
got
a
couple
of
different
options:
it
can
either
be
configured
inline
actually
in
the
pipeline
or
it
can
use.
I
think,
external
pipeline
repository
storage
I'll
see
if
I
can
dig
out
the
documentation
on
it
better
than
when
I
was
looking
at
it
previously.
It's
got
two
ways
of
doing
it.
B
Yeah,
that's
what
that's
kind
of
the
feeling
I
got
around,
how
they're
doing
it
as
well,
and
you
end
up
having
a
different.
B
I
don't
remember
if
they
call
it
a
job
or
a
workflow,
but
let's
say
you
want
to
go
to
to
qa.
You're
gonna
have
a
qa
job
that
defines
for
this
this
deployment.
This
is
the
the
manifest
that
I
want
you
to
use
for
qa,
and
then
you
define
another
job
for
production.
B
That
is
totally
separate
from
the
qa1
that
you
have
to
then
redefine
to
go
to
the
production
part
of
the
world
and
I
believe
they
can
chain
together
one
job
to
the
next
job
as
part
of
that,
but
in
at
the
end
of
the
day
they
don't
have
any
concept
of
aggregation
either
because
they're
doing
all
the
the
grouping
of
resources
at
the
manifest
level.
B
B
Like
I
said,
the
spinnaker
is
more
traditional.
You
can
think
of
a
jenkins
jenkins,
x,
type
of
thing
along
those
lines
the
pipeline.
So
it's
not
going
to
be
outside
of
that
those
concepts
that
we
already
know
so
I've
just
brought
in
what
we
have
on
the
artillia
side.
So
to
bring
everybody
up
to
speed
for
us,
we
actually
look
at
a
deployable
unit
as
actually
a
source
code
change.
B
So
when
somebody
actually
checks
in
a
coding
change,
you
check
in
some
python
code,
you're
going
to
create
a
new
artifact
and
that
artifact
is
what
we're
going
to
track
the
artifact
being
a
container
image
or
you
know,
ear
file.
War
file
doesn't
really
matter
to
us,
but
basically
in
the
world
of
kubernetes,
we
equate
a
component
to
a
container
image,
kubernetes
services
and
config
maps.
B
So
when
somebody
defines
their
deployment
via
helm,
they
kind
of
give
everything
that's
needed
to
make
this
container
image
run
so,
whether
it
be
the
the
config
map,
the
service
definition
or
the
the
the
pod
definition
itself.
B
So
we
work
at
the
basically
the
helm
chart
and,
like
I
was
saying
we
pass
in
all
the
data
into
that
at
at
deployment
time,
so
we
do
have
that
separation
at
that
level,
so
every
every
source
code
change
will
create
a
new
container
image,
typically
through
the
build
process
which
in
turn
creates
a
new
version
of
the
component
in
artelias.
B
When
we
look
at
an
application,
it's
a
set
of
component
versions.
I
didn't
get
into
too
many
details
about
domain
driven
design
and
that,
but
that
does
overlay.
On
top
of
that,
we
also
do
versioning
of
the
application
versions.
B
So
if
you
create
a
new
component
version,
that's
then
you
have
a
previous
version
application
we'll
go
ahead
and
create
a
new
application
version
as
well.
This
gives
us
that
incremental
history
chain
that
we
can
traverse
through
the
relationships.
F
Got
a
question
for
the
group,
but
I'll
wait
looks
like
landon
had
an
update
to
show.
B
So
we
can
have
a
different
point
of.
F
B
All
right,
so
we
could
take
a
different.
We
have
different
points
of
view.
What
component
versions
are
application
version
consuming
from
the
component
side?
Who
am
I
affecting
the
blast
radius
as
tracy
calls
it?
B
We
have
not
built
that
in
to
the
whole
process
and
that's
where
I'm
I'm
thinking
of
what
we
would
call
them
as
component
sets
where
we
can
type.
We
can
actually
group
together
a
set
of
of
tightly
coupled
services,
call
them
a
component
set
and
then
an
application
can
actually
consume
either
a
component
version
or
a
component
set
version
as
part
of
that
process.
B
Now
the
one
of
the
things
that
we
have
to
look
at
is
if
we
want
to
allow
a
component
set
to
incomplete,
to
include
a
component
set
itself
and
kind
of
do
that,
nesting
that
I'm
still
out
and
the
jury's
still
out
on
that
one.
It
does
add
a
level
of
complexity,
and
I
don't
know
if
people
need
that
right
away,
so
just
to
clarify
some
terminology,
since
both
argo
and
spinnaker
are
missing
the
relationship
management
in
those
tools.
B
B
B
Less
confusion
between
the
the
different
tools,
so
my
recommendation
would
be
we
rename
application
a
product
and
we
implement
component
sets
as
tightly
coupled
relationships
between
components
and
consuming
some.
I
did
lay
out
some
relationships
here,
so
you
can
kind
of
see
kind
of,
like
from
a
database
perspective
how
things
are
associated
to
each
other.
I'm
not
going
to
go
through
all
the
the
detail
as
part
of
that,
and
then
I
did
try
to
to
kind
of
draw
up
the
concept
that
we're
looking
at.
So
in
this
case
we
have.
B
B
C
C
B
Yeah
this,
this
shared
component
would
be
referenced
in
two
places.
So
let's
say
you
need
to
add
a
new
key
value
pair
to
the
shared
component.
You're
going
to
go
have
to
find
every
single
repository
that
has
that
definition
for
that
shared
component
and
go
ahead
and
update
it.
There.
C
And
when
they
do,
when
they
push
it
out,
then
do
they
push
product
a
a
safer
way
would
be
possibly
to
push
product
a
out
to
its
own
name,
space.
B
B
Right
right,
so
this
this
shared
component
would
end
up
in
two
different
name:
spaces
all
and
the
reason
why
they're
doing
is
they're
trying
to
do
iso
isolation
around
security,
the
our
back
security
and
the
cluster.
So
in
this
is
why
I've
seen
there's.
You
know
correct
me
if
I'm
wrong,
but
you
know
people
want
to
keep
all
the
traffic
for
product
b
in
this
basically
one
world
and
all
the
traffic
for
product
a
in
its
own
world.
B
That's
why
they
do
the
implementation
that
way
at
the
name
space
level.
Even
though
you
can
have
name
space
in
namespace
communication,
most
people
start
out
doing
you
know
putting
their
they
think
of
that
as
their
runtime
environment.
That
namespace.
A
C
C
B
So
that's
kind
of
the
what
I've
kind
of
digested
crumble.
I
think
I
took
care
of
everything
I
saw
in
your
email.
Did
I
miss
anything.
E
I
think
so
everything
is
taken
care.
There's
the
sharing
part
there.
That
was
like
a
bit
confusing
how
they're
like,
after
definition,
I
don't
think
that's
necessary.
The
sharing
of
the
application.
It
was
a
is
completely
different.
So
the
basic
point
is
that
we
need
a
logical
grouping
of
the
services.
So
that's
why
we
have
this
different
name,
so
it
can
be
application
set
application
or
it
can
be
a
domain.
So
that's
our
product,
that's
the
only
like
the
what
you
can
say
the
whole
conclusion
that
we
can
have.
B
Yeah
and
one
of
the
ideas
chrome
came
up
with
we
were
talking
about
the
other
day
was
for
component
sets
using
domains
to
represent
a
logical
grouping
of
component
versions,
and
I
was
looking
at
that
and
I
think,
in
order
to
just
stay
consistent,
I
think
we'll
have
to
implement
it
more
as
a
different
object
that
can
have
its
its
own
domain
as
part
of
it
that
a
component
set
would
belong
to
a
domain.
B
B
C
So
could
we
that's
why
I
keep
thinking
of
the
release,
object
that
we
already
have.
You
think
that
we
should
be
able
to
a
a
component
set,
could
be
a
product,
but
I
guess
it's
really
not
yeah
a
components
that
might
get
pushed
out
to
its
own
namespace,
based
on
the
application
or
the
now
what
you're
calling
the
product
right
or
it
might
be,
pushed
out
to
its
a
separate
namespace.
B
Yeah,
it's
it's
one
of
those.
The
way
I'm
really
looking
at
is
a
component
set.
Really
is
a
convenience
way
of
grouping
components
together
on
that
right.
So,
basically,.
B
C
Because
right
and
then
you
could
always
take
a
if
you
wanted
a
group
of
tightly
of
reusable
components
that
itself
could
be
a
product
that
has
an
environment
okay,
so
we
can.
We
can
handle
both
cases
if
we
keep
the
component
set,
where
it
is
just
a
grouping
and
not
it
doesn't
have
sub
domains
in
our
environments.
B
A
B
When
you
start
looking
at
different
scenarios,
the
the
drawing
the
complexity
relationships
just
doesn't
fit
in
a
single
drawing.
You
know
every
single
use
case
that
I
came
up
with
ended
up
being
a
different
drawing
so.
C
What
we're
going
to
have
to
do
is
add
to
the
documentation
we
might
want
to
open
up
a
ticket,
for
this
is
to
explain
how
application
or
what,
if
we
call
it
a
product,
has
sub
domains
that
map
to
potential
namespaces,
because
if
that's
how
people
are
are
implementing
it,
so
that
they
also
can
understand
that
the
way
we
have
configured
it.
You
could
potentially
have
a
grouping
of
shared
components
that
can
be
separated
if
they're
having
namespace
communication.
B
C
E
C
So
we're
going
down
the
road
that
we
did
with
object,
oriented
programming
and
we're
going
down
that
road
really
fast
right,
everybody's
renaming
their
own
shared
objects
and
making
them
their
own.
B
Yeah
and
one
of
the
things
like
I
said
in
both
argo
and
spinnaker,
they
do
not
care
about
components
at
all.
They
are
looking
at
the
the
deployment
manifest.
They
don't.
B
They're
they're,
not
even
looking
at
the
product
they're
just
looking
at.
How
do
I
copy
something
from
point?
A
to
point
b.
B
Yes,
that's
what
they're,
both
of
those
tools
are
creating
monolithic
deployments
through
the
the
process
of
using
the
kubernetes,
manifest
files.
A
C
Well,
we're
just
not
we
haven't
adopted
as
a
community.
When
I
say
we,
this
idea
of
reuse,
we
couldn't
do
it
and
we've
never
had.
We've
never
been
able
to
really
embrace
fully
a
service
oriented
architecture,
we're
constantly
pulling
it
back
into
our
own
little
products
in
our
little
worlds.
A
A
It
I'm
over
another
time
I
would
say
part
of
the
issue
at
the
moment
is
the
tooling
around.
It
is
incredibly
poor
as
a
whole
and
that's
one
of
the
areas
where
I
think
of
italians
can
help
a
lot
with
that,
but
also,
but
just
for
tuning
around
managing
these
appointment
relationships.
Having
done
quite
a
big
evaluation
recently
is
incredibly
weak
and
incredibly
poor.
Maybe
look
to
write
something
up
on
that
and
on
the
architecture
front
steve,
I
dropped
your
message
on
discord
to
the
side
of
this
thing.
A
A
Four
nine
days
so
yeah.
A
B
So
that's
kind
of
what
I
found
there
has
been
other
discussions
we'll
get
into
next
time
around
it's
another
part
that
I
we've
kind
of
run
across
as
another
problem
set.
We
need
to
address,
which
is
associating
associating
additional,
I'm
trying
to
think
of
the
word.
B
For
example,
what's
the
slack
channel
for
this
microservice
that
the
development
team
uses
what's
the?
Where
are
the
log
files
stored?
What's
the
pager
duty.
C
A
So
one
of
the
there's
a
really
good
example
of
that
kind
of
thinking
in
the
get
lab
operational
handbook.
I
think
it
is.
They
use
alert
manager
with
teams,
essentially
self-registering
and
a
custom
service
discovery
thing,
but
there's
some
good
documentation,
they've
published
around
how
they've
approached
that
problem,
which
might
be
interesting
for
folk
to
read
at
least
and
kind
of
some
of
the
pain
they
had
along
the
way
as
well,
and
that
was
from
git
lab
yeah.
A
I'm
sure
I
got
it
somewhere
buried
in
my
millions
of
bookmarks
I'll,
try
and
find
it
and
share
it
in
discord,
but
that
bookmark
system
is
right
only
right
now.
So
it
might
take
me
a
bit
of
time.
C
Yeah,
I
think
that
once
we
we
find
out
what
those
elements
are,
that
those
are
kind
of
easier.
I
hate
to
call
them
easier,
but
those
are
issues
that
are
easier
to
to
take
on.
B
And
one
of
the
the
tricky
parts
for
us
is
along.
Those
lines
is
so:
let's,
let's
take
it,
the
the
log
url,
let's
say
we're
gonna
we
want
for
this
component.
This
is
where
you
can
find
the
log
files
that's
easy
to
do
for
production.
We
know
that
it's
running
in
gke
and
here's
the
stackdriver
url
with
the
filters
already
predefined
for
me
to
go.
Look
at
the
logs
for
this
service,
but
now
we
go
to
a
customer
that
has
17
qa
environments
and
they
want
to
look
at
log
files
for
all
17
qa
clusters.
B
We
get
this
a
problem
of
a
one-to-many
relationships
and
how
we
manage
that
and
that
kind
of
comes
across
not
only
with
the
like
a
log
url,
but
also
with
you
know,
the
pagerduty
for
qa
may
be
different
for
pagerduty
for
production.
You
know
the
slack
channel,
you
know
those
type
of
things
are
different.
C
C
B
Yeah,
so
it's
just
it's
just
those
are
the
concepts
that
we
need
to
think
about.
How
we
can
you
know,
making
the
associations
easy
but
being
able
to
display
and
make
it
useful
from
a
user
perspective.
Is
the
hard
part.
B
C
B
Yeah,
but
that's
down
the
pipeline,
we'll
we'll
talk
about
that
next
time,
so
that's
kind
of
where
we're
at
any
questions
on
the
application
sets
think
about
the
concept
of
renaming
application
to
product.
What
that
means
to
you
in
your
world.
B
If
that
would
make
sense,
if
you
were
to
implement
ortulius
if
a
product
would
make
sense
to
as
that
logical
grouping
of
components
and
component
sets
or
if
there's
another
terminology
that
would
fit
better
and
we'll
kind
of
touch
base
on
that
on
our
general
meeting
about
that
rename
as
part
of
that
process
and
take
a
look
at
the
the
in
this
doctor
relationships
just
to
get
a
feel
for
how
things
are
related
together,
especially
when
it
comes
to
the
to
the
component,
sets.
E
And
component
set
would
be
like
a
different
object
and
also
part
of
what
is
a
domain.
B
It
would
be
part
of
a
domain
as
well,
and
the
the
component
set
the
components
that
the
component
set
is
consuming
or
grouping
together
can
come
from
multiple
domains,
and
that
was
one
of
the
things
that
when
I
was
looking
at
the
implementation,
the
flexibility
that
we
get
to
span
multiple
domains
of
a
component.
So
let's
say
you
have
a
single
sign-on
could
be
in
the
security
domain.
You
may
have
you
know
the
login
box
and
a
different
in
a
front-end
domain,
and
then
you
may
have
something
else.
B
You
know
the
the
oauth
in
another
domain
that
at
the
components
that
level
that
would
that
would
span
all
those
sub
domains
that
the
components
are
coming
from.
But
you
get
the
component
set
level
you
can
call
it.
You
know,
authentication
would
be
the
components
that
that
were
we're
going
to
work
with
and
that
could
sit
at
a
a
certain
domain
hierarchy
as
well.
E
Yeah
so
basically
like
we
are
changing
the
word,
like
the
logic
that
we
had
recently,
that
our
corporate
can
belong
to
only
a
particular
single
domain,
so
we
are
now
expanding
that
it
can
be
shared
across
multiple
domains.
Our.
C
Yeah
so
domain
doesn't
restrict
you
can't
like
in
our
in
what
we
call
our
pro
version.
We
allow
you
to
restrict
domain
access,
so
you
can't
see
it,
but
in
the
in
ortilius
it's
opened
up,
so
anybody
can
see
any
other
domain
and
the
difference
between
a
what
now
steve
is
calling.
Potentially
a
product
domain
and
a
component
domain
is
a
product.
C
B
Yeah,
originally
back
in
the
day,
we
used
to
have
components
and
component
versions
live
with
a
an
environment
or
a
stage
of
the
pipeline,
and
it
was
too
restrictive.
We
weren't
getting
enough
reuse
out
of
it,
so
we
pulled
that
away,
so
components
live
in
a
domain
and
the
product
is
the
one
that
moves
through
the
pipeline
domains,
and
this
is
the
pointer
back
to
where
we're
consuming
it.
C
But
regardless
of
what
product
is
consuming
that
the
component
itself
is
deployed
in
incrementally
and
it
has
its
own
log,
so
we
so
ortillius
knows
that
if
product
a
already
deployed
a
particular
component,
it
doesn't
redeploy
it
because
the
component
still
has
a
history
of
where
it's
got
it.
Where
it's
been
deployed
to,
even
though
it
itself
doesn't
have
a
a
connected
environment.
B
And
that's
where
it
gets
tricky
with
when
we
look
at
our
data
model,
a
lot
of
it
is
a
traversal,
several
hops
to
get
to
the
information.
C
C
And
look
to
see
every
application
that
uses
it
and
every
other
com
every
other
component
that
it
might
touch.
B
E
Okay
sounds
good
tracy.
I
had
pinky
on
discord
regarding
the
cd
gone
like
I
had
some
queries
and.
C
C
C
B
And
if
anybody's
interested,
the
cdf
interoperability
working
group,
starting
in
a
couple
minutes.