►
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).
A
B
A
A
So
hello,
everyone
and
welcome
to
this
week's
distribution
demo.
This
week's
demo
is
a
bit
different
in
this
demo.
I
want
to
discuss
a
proposal
for
developing
a
gitlab
operator
to
start
with.
I
just
want
to
go
through
some
of
the
challenges
and
difficulties
that
we
have
for
developing
operator
at
the
moment
and
then
I'm
gonna
pitch
the
proposal,
and
then
we
will
get
a
chance
to
discuss,
and
hopefully
we
can
continue
discussing
it
offline
or
async.
A
So
without
further
ado.
Let's
let
me
start
so
get
that
operator
is
becoming
a
mean
of
distribution
along
with
omnibus
and
get
that
charge
and
soon
operator
hub
will
be
our
one
of
our
distribution
channels
comparing
to
omnibus
and
health
chart.
We
have
a
like
a
bigger
vision
for
for
operator,
because
people
are
aiming
for
higher
capability
levels,
which
does
not
limit
it
to
to
installing
and
upgrading
gitlab,
but
rather
operating
and
driving
gitlab
in
runtime
environments.
A
A
So
let's
have
take
a
look.
So
when
we
come
to
the
difficulty
of
deploying
gitlab
omnibus
manages
it
very
well
because
we
have
omnibus
and
chef
dear
cells,
we
have
many
still
established
patterns
and
behavior
edfs
and
utilities,
and
very
well
a
structure
to
absorb
that
complexity
and
break
it
down
into
omnibus
and
mostly
because
first
of
all,
omnibus
had
a
very
good
foundation.
And
secondly,
it
has
been
around
for
a
long
long
time.
A
Gitlab
operator
is
like
wild
west
right
now,
because
operator,
framework
and
controller
runtime
just
starts
just
lay
the
bare
foundation,
and
after
that,
you
just
need
to
go
and
write
a
shell
script
with
go,
which
is
most
of
the
people
in
this
demo,
know
that
it's
not
fun.
So
it
is
difficult
to
maintain
that
and
it
is
getting
more
and
more
complicated.
So
we
expect
to
bring
more
of
the
operational
knowledge
into
operator
with
this
complex,
with
these
difficulties
and
lack
of
a
clear
platform,
a
good
foundation.
A
So
the
challenge
here
is
that
we
want
to
develop
something
in
gitlab,
a
gitlab
operator
in
gitlab.
It
is
iterative,
it
is
going
to
be
in
collaboration
with
the
community,
so
we
want
to
keep
adding
features
to
it
to
keep
and
make
sure
that
it
doesn't
break
while
we
are
adding
more
features
or
improving
them
and
at
the
same
time
we
want
to
get
feedback
and
improve
it
all
the
time.
A
At
the
same
time,
we
want
it
to
be
clear
enough
for
our
own
sanity
and
our
community's
understanding,
because,
basically
we
want
to
have
that
reliability
by
being
readable
and
testable,
so
these
are
actually
show
themselves
in
the
design
forces
that
we
I've.
Actually,
I
translated
those
requirements
into
some
of
the
design
courses
and,
in
turn,
turn
into
a
framework
that
I'm
going
to
present
and
if
I
want
to
break
them
down,
it's
basically
accessibility,
clarity
and
disability,
and
I'm
trying
to.
I
will
try
to
show
them
when
we
get
into
it.
A
So
my
proposal
is
github
operator
framework.
It
starts
when
exactly
where
the
operator
framework,
sdk
and
the
queue
builder
stop.
They
just
build
this
scaffolding
of
the
framework.
They
give
you
some
of
the
basic
tools
that
you
need
to
build
your
framework,
you,
your
operator
and
just
leave
you
there.
So
exactly
there.
We,
this
framework
comes
in
and
it
provides
an
abstraction
of
what
operator
does
so.
A
And
finally,
we
have
a
better
structure
around
the
operator,
so
I'm
just
gonna
go
through
some
of
the
basic
concepts.
These
are
the
constructs
that
we
will
see
in
the
demo
for
managed
resources.
We
have
inventories,
which
is
basically
collection
of
resources
that
we
collect.
We
gather
from
different
sources.
We
have
queries
to
sort
to
go
through
these
inventories
based
on
different
search
criterias.
A
We
have
the
editors
which
led
us
to
manipulate
the
output
of
those
queries,
change
something
in
the
resources
we
did
with
the
certainty
of
immutability
of
the
inventory
itself.
We
are
not
going
to
touch
the
inventory,
but
the
copy
of
the
query,
and
we
have
the
adapters
which
led
us
to
deal
with
different
versions
and
different
types
of.
A
A
A
So
what
we
do
we?
First
of
all,
we
start
start
the
execution
context.
The
execution
context
carries
out
everything
that
we
need
to
run
to
execute
a
workflow
for
that
specific
request.
So
the
runtime
context,
the
execution
context
is
request
dependent.
It
runs
for
a
specific
request
and
different
requests
will
have
different
runtime
contexts.
A
A
A
We
do
here
is
we
just
keep
write
an
adapter
function.
This
is
the
the
the
the
signature
of
the
function.
It
receives
the
execution
context
and
returns
the
value
provider
and
the
value
provider
is
basically
an
interface
that
returns
values
and
hash.
This
is
pretty
similar
to
what
we
already
have
as
the
adapter
the
custom
resource
adapter
in
the
current
operator,
but
it
just
does
a
binding
of
an
unstructured
payload
of
the
custom
resource
and
a
hash
which
we
will
use
later
for
for
caching,.
A
A
A
A
A
dynamic
inventory,
on
the
other
hand,
is
a
list
of
objects
defining
the
code,
but
can
be
touched
by
some
editors
when
they
are
asked
for
so,
and
they
will
stay
immutable.
So
here's
an
editor.
This
is,
for
example,
set
release.
Label
editor,
which
receives
the
values
and
receives
an
object,
can
cast
typecast
the
object.
Sorry,
what
was
the
word
in
in
go?
A
Sorry,
yeah
cast
the
object
into
a
type
change,
something,
for
example.
I
have
something
here
for
skip
activity
challenge
which
touches
ingresses.
I
haven't
brought
it
though,
and
we
have
the
chart
inventory,
which
basically
looks
at
the
path
of
the
chart.
So
this
is
how
we
define
the
inventory,
the
rest
of
how
this
will
be
loaded.
This
will
be
managed.
This
will
be
worked
out
is
done
within
the
framework
from
the
operator
point
of
view.
This
is
what
you
need
to
define
and
if
you
look
at
it,
it
kind
of
looks
like
a
dsl.
A
Okay,
so
going
back
to
the
controller,
we
set
up
the
inventory
and
now
we
are
going
to
and
the
context
is
ready.
So
these
are
all
contextual
information
and
if
you
look
at
it,
this
doesn't
really.
The
main
inventory
is
actually
constant
between
different
contexts.
It
doesn't
change,
it
was
def,
it
is
defined
when
the
operator
is
starting
up.
A
A
File
here-
and
this
is
basically
a
workflow-
a
workflow
is
a
list
of
tasks,
and
let
me
show
you
the
actual
workflow
here
and
we
can
add
infer.
So
this
is
the
workflow.
It
can
include
other
workflows.
So,
for
example,
it
includes
run
shared
secrets
which
we
use
by
the
way.
This
is
a
bit
old.
So
the
example
is
a
bit
old.
It
doesn't
reflect
the
latest
changes
that
we
have
inside
the
github
operator.
A
A
This
is
the
job
that
you
need
to
look
up
and
then
timeout
same
thing
is
for
run
shared
secrets.
I
defined
something
here:
deployment
io
these
are
the
smaller
workflows
that
can
be
included
and
can
be
reused,
workflows.
Also,
every
task
also
has
a
guard
which
helps
us
the
set
conditions,
so
these
tasks,
this
runs-
self-signed
certificates,
runs
only
if
we
check
the
value
and
these
values
like
this.
A
And
I
don't
want
to
really
go
into
the
details
of
the.
What
we
are
doing
here
is
basically
an
example,
and
it's
not
an
accurate
example,
but
what
it
basically
does.
If
take
a
look
at
the
overall
structure,
we
have
a
workflow.
This
is
kind
of
the
workflow
of
github
operator
before
the
zero
downtime
upgrade
near
zero
downtime
upgrade,
but
this
is
how
it
will
look
like
a
set
of
tasks
can
be
conditional
each
task.
A
A
A
A
A
A
So
the
task
receives
that
and
does
what
it
does
and
returns
an
outcome
which
can
be
okay,
error
or
retry.
Just
these
are
the
three
different
options
that
it
can
have.
Some
of
the
tasks
are
resource
bound.
So
this
is
the
type
of
thing
that
we
have
here,
which
kind
of
connects
the
task
to
the
allows
us
to
define
tasks
that
are
tied
to
inventory,
for
example,
for
querying
inventory
and
returning
a
set
of
resources
from
inventory
and.
A
If
we
do
it
like
this,
the
the
framework
itself
is
going
to
be
it's
going
to
contain
most
of
the
most
of
the
building
blocks
that
we
need
for
building
operator.
Of
course,
we
can
add
more
more
blocks
to
it,
but
it
will
simplify
the
way
that
we
and
tests
to
it
and
it
will
simplify
the
way
that
we
can
describe,
because
our
actual
job
would
be
defining
these
workflows
and
going
through
this
operator
that
these
workflows
most
of
the
time
and
fixing
them
or
going
back
to
fix
them.
A
A
We
can
basically
mock
a
runtime
and
a
runtime
scenario
into
into
we
can
we
can
for
for
a
particular
scenario.
We
can
mock
the
runtime
context
and
just
feed
it
to
the
the
workflow
and
get
the
results
and
see
how
the
operator
or
that
particular
workflow
will
react
to
the
runtime
scenario,
so
it
makes
it
more
testable.
We
don't
need
a
control
plane,
we
need
to
do.
We
won't
need
etcd
or
anything
else,
because
we
can
run
the
tests
quickly
and
make
sure
that
the
workflows
are
covered
in
different
runtime
scenarios
yeah.
C
C
It
became
clear
that
there's
so
many
conditions
to
check
and
scenarios
where
you
want
to
wait
for
things
which
is
not
wait
for
things,
etcetera
that
it
just
starts
to
look
like
a
blob
of
if
else's
and
and
it's
kind
of
hard
to
track
and
then
even
with
adam
are.
It
was
so
hard
to
add
tests,
because
I
would
have
to
mock
everything
up
until
that
point,
where
an
upgrade
was
happening.
B
C
C
C
A
I
really
like
the
idea,
thanks
about
the
the
learning
curve,
first
of
all
and
the
development
first
of
all,
I
when
I
was
just
thinking
about
it,
I
thought
that
it's
going
to
be
bigger
than
this,
but
weirdly.
The
number
of
basic
constructs
that
I
needed
was
much
more
smaller
than
my
that
about
that
I
anticipated.
But
yes,
that's
true.
There
is
a
bit
of
because
this
is
a
different
framework
and
it
provides
a
different
set
of
constructs
to
build
yeah.
E
A
D
F
D
You
know
I'll
probably
get
to
the
point
where
it'll
be
easier
to
just
say
this
version
of
the
operator
is
only
for
this
version
of
git
lab.
You
know
today
we're
trying
to
do
multiple
versions
by
having
access
to
multiple
charts
and
stuff,
and
I
think
that's
probably
going
to
go
away,
especially
when
we
go
toward
this.
D
The
other
piece
that
I
see,
which
is
probably
the
bigger
issue
that
just
scares
me
mostly
because
it
can
be
a
huge
maintenance
problem
and
I'm
not
sure
exactly
how
to
describe
this
other
than
if
you
look
at
what
the
helm
charts
doing
with
specifically
the
managing
the
configuration
files
and
so
forth.
There's
a
lot
of
work,
a
lot
of
things
in
play
inside
there
that
how
we
construct
those
config
files
into
the
config
maps
and
stuff
like
that
specifically.
D
Of
everything
to
reproduce
that
into
go
just,
I
don't
see
a
good
way
to
deal
with
that
other
than
write
everything
and
go,
and
then
it
becomes
a
huge
administrative
maintenance
burden
of
maintaining
all
that
in
goal.
Now
and
again,
I'm
not
I'm
not
in
the
girl
world.
Knowing
everything
that's
going
on
inside
go,
maybe
there's
some
go
component
out
there,
that's
going
to
make
working
with
config
files
and
stuff
more
manageable
somewhere.
D
D
D
Just
I
just
bring
it
up,
make
a
figure
think
about
it
versus
saying:
oh,
we
should
go
this
way
because
I
I
think
I
think,
there's
value
here.
I
like
a
lot
of
what
I'm
seeing
here.
I
just
want
to
make
sure
that
we
step
into
it
and
go
hey.
We've
got
a
solid
plan.
How
to
move
forward
versus.
Oh
we're.
Gonna
go
do
this
and
then
we
start
going
oh
crap.
Now
we
got
all
this
other
stuff.
We
have
to
figure
out
how
to
bring
forward
to
so
anyways.
A
To
be
fair,
I
I
have
a
few
effects
myself.
I
think
the
biggest
challenge
that
we
have
here
is
that
if
we
decide
to
go
to
this
direction,
then
we
have
an
operator
that
is
going
to
pga
very
soon,
and
then
we
have
a
framework
that
we
are
advocating
for
and
then
at
some
point,
these
two
need
to
meet
each
other
and
when
and
where
that
time
is
so,
if
we
keep
developing
operator
framework
the
operator
the
way
that
we
do,
we
still
have
the
pain.
D
D
D
A
So
basically,
we
the
only
thing
that
we
will
left
after
a
while
is
just
the
know
how
of
how
to
write
the
operator
and
how
the
operator
works,
because
we
have
encoded
that
when
we
acquired
that
understanding
and
now
we
need,
we
are
going
to
restate
it
in
a
different
language.
Let's
say
not
a
programming
language,
but
you
know
just
basically
communication
method.
A
D
E
E
If
you
were
going
to
boil
this
to
like
one
or
two
sentences
of
what
does
this
solve
and
then
mitch
as
the
consumer,
what
pain
points
is
limiting
because
I'm
hearing
talk
of
configuration,
but
I
thought
operator
was
controlling
like
sequence
of
events
and
the
configuration
was
in
the
helm
chart
still
and
the
operator
just
deployed
the
helm
chart.
So
I
kind
of
want
to
understand
both
from
hussein
what
you're
trying
to
solve
and
mitch
what
you
see
so
strongly
is
going
to
save
you
pain,
because
I
don't
think
I'm
connecting
those
two
pieces
yet.
A
Okay
and
go
first,
the
the
broadest
in
the
broadest
term,
I'm
trying
to
solve
the
increasing
complexity
of
operator
as
we
proceed
with
this
development.
So
far
we
have
been
only
deploying
chart.
Now
we
are
upgrading
it
which,
by
the
way,
deploying
chart
is
just
was
rendering
and
just
tweaking
it,
but
now
for
deploying
for
upgrading
it.
A
C
C
The
added
benefit
here
is
that
if
we
can
mock
these
because
their
interface
isn't
so
high
level,
we
can
mock
in
our
tests
all
the
way
up
to
these
certain
conditions
without
having
to
worry
about
interacting
with
the
api
server.
Because
today,
if
I
want
to
mock
the
migrations,
job
is
finished,
I
have
to
go
like
push
and
change
the
api
server
saying
override
this
and
mark
it
as
successful.
C
I
don't
really
need
to
test
kubernetes
ability
to
to
modify
api
objects.
I
just
want
to
validate
that
when
a
certain
state
exists,
this
workflow
results
in
something
that
I
want
the
end
state,
and
so
it
kind
of
abstracts
us
away
from
re-testing
things
that
are
probably
already
tested
upstream
and
gives
us
the
ability
to
just
say
in
this
workflow.
If
I
have
this
current
state,
does
this
workflow
get
me
to
the
desired
state
without
having
to
worry
about
testing
against
the
api
server
and
stuff
again,
I
think
we
could
do
that
without
these
abstractions.
E
I
think
I
understand
what
you're
putting
down
so
I'm
gonna
step
up
one
more
level
of
abstraction
higher
than
this,
and
this
goes
back
to
a
conversation.
I've
been
having
with
dj
and
jason
and
steven
over
the
past,
probably
year
year
and
a
half
you
know
we're
talking
about
states
and
knowing
like
when
you're
upgrading
something
one
of
the
things
that
I
desperately
would
like
to
see
us
develop.
E
So
I
feel
like
one
of
the
things
that
we're
gonna
want
to
do
here
is
step
back
and
say:
well,
wait.
Why
are
we
configuring
each
of
these
in
separate?
It's
the
same
configurations
like
the
gerard's
point
right,
if
we're
pulling
it
out
of
the
config
maps
and
generating
it
go?
What
does
that
mean?
I
would
go
further
if
we're
talking
about
this.
E
Can
we
just
manage
configuration
because
a
gitlab
yaml
is
going
to
be
a
gitlab
yammo,
whether
it's
anywhere
so
can
we
step
back
and
if
we're
going
to
try
and
architect
this,
can
we
make
something
that
will
unify
our
configuration
so
that
each
of
our
individual
things
consume
this
configuration
engine?
It's
aware
is
a
stateful
engine
aware
of
what
it
takes
to
upgrade
and
then
into
that
we
just
have
like
a
factory
like
in
fact
using
the
factory
pattern
right.
E
Oh
well,
I'm
going
to
use
this
same
logic,
but
I'm
going
to
plug
in
all
of
my
machines
are
omnibus
machines
or
kubernetes
machines
or
openshift
machines,
or
something
else
can
we
extract
that
back
so
that
we
get
something
even
more
impactful?
That
will
eliminate
a
lot
of
these
problems
across
all
of
our
stuff
right,
because
we
have
a
large
scalability
problem
going
back
to
jose's.
E
First
thing
about
omnibus:
I
would
argue
that
omnibus
solves
well
one,
but
it
does
a
very
does
not
do
as
good
of
a
job
when
you
scale
it
out,
but
most
customers
aren't
going
to
want
kubernetes
for
scaling
out,
because
it's
just
kubernetes
is
an
answer
if
you're
really
big
right.
So
we
have
to
have
some
answer
for
that
and
for
that
stateful
engine
and
have
it
in
one
place.
We
don't
want
to
have
omnibus
in
one
place
and
charts
in
the
other
will
always
have
double
work.
E
A
So
I
am
not
really
not
concerned
about
the
configuration
of
the
of
of
gitlab
to
be
to
as
a
matter
of
fact,
we
are
just
in
operator,
and
here,
even
in
this
framework,
I
I'm
trying
to
piggyback
on
chart
to
handle
that.
So
this
is
like
a
this
is
completely
contingent
on
whatever
the
other,
what
other
decision
that
is
made
on
charts
and
how
it
will
end
up
a
chart.
A
Basically,
if
you
give
me
a
chart
or
more
charts
or
many
charts,
you're,
just
I'm
just
gonna
use
it
and
I
don't
care
and
that's
it
okay
and
how
you
want
to
if
you
want
to
upgrade
that
chart.
Okay,
that's
that's
my
problem.
I
need
to
know
what
the
version
you
are
on,
which
version
you
want
to
go
to
I'm
going
to
validate
that
I
am
going
to
run
certain
steps.
Stop
things
start
things.
A
E
A
D
I
I
think,
there's
I
think,
there's
two
views
here,
robert
and
I
I
think
we're
both
all
of
us
are
sort
of
dancing
around
both
of
them
in
a
sense.
What
what
hussein
has
here
is
really
the
pieces
to
manage,
mostly
the
kubernetes
or
openshift
world.
Some
of
what
you're
talking
about
robert
is
the
next
level
down
as
managing
that
installation
image.
D
The
operator
doesn't
really
manage
the
installation
image
it
just
takes
that
image
and
gets
it
deployed
and
running
elsewhere.
The
the
there's
a
I
like,
the
idea
of
we
have
one
final
configuration,
whether
it's
omnibus
or
charts,
or
this
now
operator
or
whatever
the
future
things
are
going
to
be.
We
configure
it
once
and
get
it
out
there.
D
E
See
I'm
still
hearing
that
duality
there
where
we
say
like
it's,
not
about
the
installation
of
the
upgrade
deployment
process,
but
here's
the
thing
if
we're
managing
like.
What's
this
current
state-
and
I
want
to
go
from
this
version
to
that
version-
that
is
a
deployment
state
engine
to
know
what
state
does
git
lab
the
application
have
to
be
in
to
move
it
from
this
version
to
that
version
and
that's
a
common
problem
among
all
the
ways
in
which
gitlab
is
out
there.
D
A
Basically,
it
looks
at
the
status
of
the
gitlab
cr,
which
it
sets
it
defines
and
manipulates
itself,
and
secondly,
it
looks
at
the
metrics
that
we
haven't
added
yet,
but
it
will
later
will
be
added.
It's
look
at
the
metrics
that
the
the
the
exporters
gitlab
exporter
and
other
spoke
exporters
basically
export
about
this
status
object.
This
is
this
is
how
it
this
is.
This
is
the
extent
of
the
status
that
it
understands
at
the
moment.
Sorry
dj.
F
C
Operator
yeah,
I
think
this
specifically,
it
just
helps
making
the
get
an
operator
easier.
Whether
or
not
an
operator
needs
to
exist
in
the
merits
of
that
is
probably
totally
separate
discussion,
but
I
would
even
go
further
and
say
this
doesn't
even
have
to
be
an
operator
based
on
helm
chart.
We
can
probably
swap
out
where
you
get
these
resources,
whether
it's
from
a
helm,
chart
or
an
api
spec
and
go
that
it
pulls
these.
C
You
know,
because
that
might
be
a
future
state
as
well,
so
I
would
just
say
in
general,
the
operator
the
concept
of
writing
an
operator
in
any
language
is
only
several
years
old,
which
compared
to
like
chef
and
omnibus
right,
that's
pretty
new,
and
so
there's
not
a
lot
of
concepts
out
there.
Yet
that
make
writing
the
logic
of
an
operator
easier.
C
The
operator
sdk
helps
us,
set
the
scaffolding
to
interact
with
the
api
server
much
easier,
but
all
the
logic
of
how
to
implement,
like
your
business
logic,
is
up
to
you,
and
so
this
just
kind
of
helps
solidify
that
and
make
that
easier
and,
like
I
said
earlier,
we
could
probably
do
it
without
this,
but
for
the
concept
of
this
call,
this
framework
that
hussein
is
proposing
could
probably
live
in
its
own
repository
and
we
import
it
as
a
package
and
it's
not
get
lab
specific.
It's
not
chart
specific.
C
A
Thanks
mitch,
that's
that's
basically
the
gist
of
it.
That's
very
true.
I
just
want
to
point
out
that
there
is
also
a
white
paper
that
I
wrote
few
months
ago.
This
is
still
a
draft,
so
I'm
just
sorry
going
to
share
it.
It's
in
the
meeting
notes,
so
we
can
just
go
ahead
and
basically
go
through
the
whole
rationale
and
the
description-
and
there
are
some
codex
sketches
there
again.
These
are
not
real
functional
codes.
A
E
Can
I
just
have
a
clarification
or
mitch
when
you
say
that
this
operator
thing
is
like
only
last
couple
years,
you're
talking
about
specifically
within
kubernetes
right,
yeah?
Okay,
because
the
general
idea
of
what
an
operator
is
is
like
from
the
1960s.
So
that's
why
I'm
just
clarifying
that
like
no,
it's.
C
E
E
We
could
gain
a
lot
by
looking
at
what
some
of
those
patterns
are.
Unfortunately,
my
copy
is
a
physical
copy
and
but
it's
out
there,
but
I
recommend
that
as
well,
because
that'll
help
us
because
staple
set
is
it
can
get
complicated,
really
quick
and
trying
to
get
these
reconciled.
As
we
found
right,
you've
run
right
into
the
exact
problem,
that's
out
there,
but
there's
a
lot
of
literature
and
writing
about
how
to
make
it
more
efficient.
That,
I
think,
would
benefit
from
like.
A
Okay,
thank
you.
I
think
we
are
past
our
mark,
but
if
you
really,
I
would
love
to
hear
your
feedback
discuss
it.
If
you
rather
do
it
one-on-one
face-to-face
just
drop
me
a
link
or,
alternatively,
you
can
just
comment
on
the
the
white
paper
itself
or
just
I
don't
know
ping
me
over
slack.
I
am
available,
would
love
to
hear
your
feedback
and
I
want
to
know
how
we
can
go
ahead
with
this.
D
A
D
I
was
gonna
say
I
mean
the
alternative:
is
each
one
becomes
a
co-routine
that
then
runs
and
could
drive
you
crazy,
trying
to
figure
out
what
happened,
but
I
could
also
see
there
might
be
an
advantage
at
certain
times
where
we
build
another
construct
here
which
allows
us
to
run
some
of
this
stuff
in
parallel
for
performance
reasons,
but
it
would
have
to
be
very
selectively
applied.
I
suggest.