►
From YouTube: SIG Cluster Lifecycle - Cluster Addons 20200218
A
B
Oh
yeah,
so
if
I
miss
that
my
name
is
alpha,
alpha
sailing
and
I
am
a
PhD
student,
mostly
working
on
usable
security.
I
am
in
my
second
year.
I
have
participated
in
this
work
in
last
year:
280
2018
no
year
before
last
so
jisub
2018
with
the
Eclipse
Foundation
for
the
Eclipse
formal
project
and
the
idea
there
was
to
add
an
amqp
1.0
protocol
adapter
for
no
sort
of
devices
that
speaks
the
amqp
1.0
protocol
can
publish
telemetry
and
events
to
to
downstream
applications.
B
So
this
year
I
want
to
participate
in
this
work
again.
So
I
was
and
this
time
I
want
to
do
it
within
the
kubernetes
space.
So
I
was
taking
a
look
at
some
of
the
projects
that
were
at
least
so
far.
Posted
I
mean
the
organizations
are
not
announced
yet
so
I
have
been
following
this
up
a
bit
and
saw
that
there
is
a
proposal
to
add
so
operators
for
the
cluster
Adams
project,
so
I
also
saw
that
on
the
slide
7
there
is
so
meetings
in
the
first
and
third
Tuesday
of
every
month.
B
B
A
A
A
C
D
C
Also
at
the
meeting,
so
we
can
go
ahead,
Nick
yeah,
so
we
talked
with
soly
and
good
to
be
both
from
the
Builder
in
San
Francisco
two
weeks
ago.
There
wasn't
anything:
I
need
a
feedback
given
there
that
was
structural.
They
were
just
like
yeah.
This
is
a
you
know,
solid
idea
and
the
other
feedback
that
they
gave
was
just
like
small
things
like
you
want
to
have
a.
D
C
C
C
B
C
C
But
given
the
current
state
of
the
ecosystem,
well,
instead
use
docker
images
with
labels
until
such
time
as
the
mascara.
In
fact,
ecosystem
is
mature.
Enough
could
use
that
instead,
and
so
it's
basically
literally
like
the
stuff
that
we
previously
talked
about
about
packaging
add-ons
as
OC,
is
that
just
instantiated
as
a
docker
image,
instead
of
as
an
aside
and
then
is
there
any
either
shared
or
a
separate
idea
in
these
bundles,
like
I,
don't
see
anything
about
like
runtime
or.
D
C
F
C
C
Anyway,
sorry
I
said:
yeah
inflation
like
had
meaning
tools
actually
inflate
the
manifest
soon
like
its
net
or
tongs
ooh
or
what
is
it?
I'm
already
I'm
already
conflating
kubernetes
project
names
not
tons,
ooh
who's
that
Griffin
I
just
took
over
a
new
new
maintainer
ship
of
case.
In
that
what
was
it
called.
C
C
It's
easy,
because
these
are
images
that
you
can
expect,
but
on
cluster
is
more
interesting
because
we
want
to
one
of
the
constraints
we
were
looking
at
is
having
them
all
images
to
be
pulled
via
the
cubelet,
and
so
when
you
start
talking
about
that
and
pulling
playing
manifests
gets
a
little
more
interesting
and
so
there's
a
discussion.
A
brief
discussion.
There
I
was
going
to
the
tool
that
we've
done
for
operating
framework.
C
So
as
part
of
this,
we
went
ahead
and
like
prototypes
all
this
out
in
an
operator
at
work,
basically
instantiated
a
manifest
bundle.
Here's
one
variant
of
it.
That's
an
operator
bundle.
Here's
a
tool
that
Buster
just
to
test
out
the
ideas,
basically
so
here,
you've
written
that
relying
on
the
couplet
to
pull
manifest
bundles
ensures
that
the
configuration
comes
through
the
same
channel
as
runnable
images.
C
C
I,
don't
currently
see
how
that
could
be
done
without
either
conflating
the
pole
with
actually
trying
to
run
a
pod
or
modifying
the
couplet
yeah.
That's
that's,
essentially
what
the
tool
does
it
runs
a
pod
that
has
multiple
containers
in
it.
One
of
them
is,
is
the
manifest
bundle
that
you're
trying
to
extract
the
other?
One
is
one
that
contains
tooling.
C
That
knows
how
to
take
the
contents
of
that
and
put
it
somewhere
else
in
the
cluster
that
can
be
write,
a
foster,
the
one
that
we
prototyped
takes
the
files
and
puts
them
into
config
map
so
that
other
tools
can
read
it,
but
you
can
imagine
any
other
type
of
inflation
and
I
imagined
that
would
need
host
access
to
do
that.
Right,
I,
don't
know
I,
just
yeah
just
needs
one
shared
volume
between
the
HUDs.
C
C
C
Right,
okay
and
then
you
could
just
mount
something
into
it:
that's
runnable
yeah!
So
we
have
one
image
that
has
the
tool
that
is
runnable
has
the
manifest
that's
just
scratch
and
then
it
in
then
it
hydrates
it
into
a
conflict
map
and
you
can
use
like
a
jog
or
something
to
make
sure
that
it
terminates
very.
C
C
C
A
C
A
A
A
A
A
A
Yes,
so
about
some
of
code,
so
Lee
has
already
cut
nerd
a
couple
of
people
who
talked
to
him
about
some
of
code
and
I
just
thought
that
it
would
make
sense
to
put
together
a
little
bit
of
a
reading
list,
or
you
see
like
okay
like
this
is
the
story
of
the
project
is
what
we
did
have
a
look
at
this
first,
so
they,
basically,
you
read
up
on
what
what
has
happened
and
they
can
start
preparing
themselves
if
they
really
want
to
get
involved
in
the
project.
I
guess
it's!
C
So
I'm
working
through
the
feedback,
I
was
hoping
to
be
done
by
now
already,
but
there
is
a
pretty
significant
list
of
non-trivial
feedback
that
the
primarily
cubanÃa
maintainer
x',
as
well
as
Jeff
Johnson
left
regarding
the
Anton's
cap.
Some
of
it
very
pointed
about
things
that
we
need
to
eventually
discuss
regarding
add-on
life
cycle,
who's,
owning
and
maintaining
those
things
own.
C
We
will
be
going
over
this
as
well.
In
tommorows,
cubed
am
meaning
and
likely
doing
a
separate
meeting
to
actually
talk
about
the
feature
intent
because
it's
been
difficult
to
have
a
full
conversation
about
it
at
any
one
point
in
time,
so
we'll
be
asking
for
probably
from
the
cluster
or
yeah
the
cluster
life
cycle,
slack
channel
be
posting,
meaning
there
just
an
ad-hoc
one
to
talk
about
this
feature
for
add-on
installer.
C
A
A
So,
basically,
this
makes
the
scope
of
the
project
it
be
bigger
because
we
will
need
to
figure
out.
Are
we
going
to
have
operators
for
these
add-ons
who's
going
to
maintain
them?
What
is
going
to
be
the
release
cycle?
So
they
want
basically
everything
specked
out
and
yeah.
We
need
to
figure
out
like
which
of
these
fits.
A
C
If
anyone
has
opinions
on
like
whether
or
not
every
cluster
by
default
should
have
like
a
core
DNS
operator
in
it
or
whether
or
not
that's
something
that
should
be
opted
into
or
if
we
should
provide
a
little
resource
alternative
or
something
like
that
or
you
know
from
the
viewpoint
of
node
local
DNS
as
an
add-on
like
how
you
know
how
much
of
an
opt-in
is,
that
kind
of
thing.
So
this
the
cap
is
a
great
place
to
comment
on
that
stuff.
E
I'm,
just
looking
for
some
feedback
on
this
I
think
this
relates
to
what
Jeff
Johnson
yours
are
you
put
in
around
component
config
integration
into
every
controller,
runtime
and
hopefully
into
Q
builder,
eventually
so
I
started
looking
into
this
and
talking
with
Lee
about
how
this
potentially
could
be
implemented,
see
I'm
just
looking
for
some
base
feedback.
If
this
is
if
this
fits,
what
everybody's
looking
for
I'm
open
to
go
put
in
the
pull
request
and
try
and
push
this
through.
C
Yeah
and
then
we
do
have
time
so
I'm
just
gonna,
take
the
quick
liberty
of
sharing
what
Chris
is
actually
talking
about,
since
not
everyone
may
be
looking
at
the
notes,
but
basically
you
left
this
comment
here.
Talking
about
how
to
provide
component
configuration
to
bootstrap
a
controller
runtimes
manager
right.
E
C
If
you're
creating
an
add-on
an
operator,
you
need
some
ideally
somewhat
standard
and
useful
way
to
configure
that
operator
to
start
and
run,
and
if
we're
gonna
have
a
lot
of
these
things,
then
we
want
a
configuration
interface
that
is
roughly
consistent
across
all
of
them,
so
that
people
have
the
flexibility
to
deploy
these
things
in
different
ways.
Some
of
these
add-on
operators
may
not
be
running
inside
of
a
cluster
with
access
to
service
accounts
cube
can
taking
that
kind
of
thing.
So
you
know
just
like
providing
a
formal
API
for
doing.
C
This
makes
a
lot
of
sense
and
if
we
could
get
some
feedback
here,
I
don't
actually
see
a
problem
with
this
but
I'm
biased,
because
we
came
up
with
the
idea
together
so
yeah,
but
bring
your
strong
opinions
please
and
comment
on
the
issue.
In
order
to
find
this,
you
can
go
to
our
cluster
add-ons
meeting
notes
and
right
here
at
the
bottom.
Chris
has
added
to
the
agenda
with
the
direct
link
to
the
comment
so
and.
E
C
C
B
C
C
C
C
C
Yes,
there's
the
baton
operators,
one
I
actually
haven't
looked
at
in
a
while.
Did
we
not
merge
that
one
already
I,
don't
think
it's
marriage?
Last
time,
I
checked
I
think
like
there
is
an
undertone
with
enhancements
being
a
repo
where
ideas
go
to
die.
Isn't
it
no
just
gets
stuck
in
in
the
word
face?
D
C
C
B
C
Okay,
so
I
mean
the
high
level
is
the
summary
that
I
gave
earlier,
which
is
really
interested
in
storing
manifests
of
various
purposes
in
cater
images,
and
it's
really
the
same
used
case
that
okay
artifacts
is
attempting
to
address.
Unfortunately,
we
want,
we
just
want
to
start
doing
it
now,
and
we
don't
want
to
wait
for
all
these
other
environments
to
support,
oh
say
artifacts.
The
good
news
is
that
I
think
the
transition
transition
path
chose.
Jared
effects
is
incredibly
straightforward
if
we
go
ahead
and
agree
on
these
things
now.
C
So
some
of
the
things
that
we
are
interested
in
is
having
a
way
to
basically
consolidate
all
these
other
things.
This
doesn't
necessarily
deprecated
other
ways
that
people
send
manifests
around.
So
you
know
there
I'm
sure
there
will
always
be
reasons
to
keep
manna-fest
and
get
because
at
registries
you're
not
familiar
with
this.
This
is
almost
this
was
a
waste
clay,
specific
storage
mechanism
for
hump
tricks,
so
it
is
kind
of
a
precursor
to
the
CIA
is
only
supported
by
acquiesce.
C
C
C
Some
of
the
things
that
we
defined
is
to
in
and
out
of
scope
are
want
to
make
sure
that
we
can
build
using
standard,
container,
tooling
and
standard
image
registries.
So
this
is
kind
of
the
big
one
where
OC
is
not
fully
supported
by
all
these
things,
yet
or
I
should
say,
let's
say
artifacts
in
particular.
C
Another
one
is
a
goal
of
this
particular
kept.
But
potentially
you
know
we
could
relax
the
scope
as
well,
which
is
just
that
all
of
these
bundles
that
we're
talking
about
don't
actually
require
a
real
runtime.
They
don't
require
a
union
chastised
and
they'll
acquire
any
of
the
container
mechanisms
that
docker
images
or
continuum
tubes
normally
do
and-
and
so
the
goal
is
to
make
sure
that
whatever
we
do
here,
it
retains
that
ability-
and
maybe
if
you
want
to
talk
about
runnable
things
kind
of
like
we're
talking
about
the
the
tooling
earlier,
you
can.
C
So
we're
dividing
the
manifests
that
we're
storing
to
two
broad
categories
run
into
the
manifests
themselves,
so
things
that
can
be
applied
to
a
cluster
and
then
metadata
is
things
that
we
need
to
know
about
this
bundle,
but
will
not
be
directly
applied
to
a
cluster.
So,
for
example,
if
if
we
were
trying
to
instantiate
a
helmet
chart
as
one
of
these
bundles,
that
template
would
probably
be
the
manifests,
those
are
things
applied
to
the
poster
and
then
the
metadata
would
be
like
the
values
that
you
can
put
into.
C
C
C
Each
application
would
define
a
particular
namespace
like
a
media
type
and
their
version
for
it
and
then
essentially,
a
location
within
the
image
where
manifests
can
be
found
where
the
metadata
can
be
found
and
then
essentially
any
other
metadata
that
you
want
to
lift
up
onto
this
layer.
So
this
is
analogous
to
the
annotations
sorry
yeah
annotations
in
an
OCI
image
or
labels
on
a
docker
image.
This
is
top-level
information.
C
The
thing
that
the
one
thing
that's
interesting
about
this
is
that,
in
addition
to
putting
those
on
the
on
the
manifest
itself,
so
the
CI
manifest
has
like
annotations
and
the
dr
manifest
has
the
label
section.
We
also
want
that
inside
the
container
for
the
on
cluster
use
cases.
So
one
of
the
premises
here
is
that
we'll
keep
these
two
things
in
sync.
C
If
there's
a
discrepancy,
the
one
that's
in
the
container
has
precedence,
because
there's
currently
no
way
to
get
labels
from
cubelet
from
an
image
that
does
make
sense,
and
so
is
basically
a
mechanism
that
works
around
the
couplet
use
case
right
right.
Exactly
the
ideal
scenario
would
be
that
you
don't
have
to
replicate
it.
It's
just
there
on
the
manifest
and
then
it's
available
abuse.
C
You're
pulling
the
pod
when
you're
pulling
the
container,
but
that
could
easily
be
layered
on
as
an
improvement
in
the
future.
Yeah
I'm,
not
convinced
that
the
pod
mechanism
is
sufficient
and
and
also
necessary,
because,
if
you're
in,
if
you're,
creating
compute
inside
of
a
namespace
that
you're
running
a
tool
with
some
privileges,
you
could
just
have
a
service
account
to
the
registry
credentials.
But
that's
a
that's
really
just
mechanisms.
It
doesn't.
Yes,
so
that's
definitely
technically
possible
and
it
something
that
we
discussed.
C
C
But
if
you're
willing
to
allow
that
yeah
absolutely
having
a
separate
tool
that
can
be
the
opposite
is
also
true,
which
is
like
using
like
exposing
the
inflation
of
manifests
through
something
that's
designed
to
run
things
yeah,
that's
fair,
which
is,
which
is
just
the
other
trade-offs
that
you're
making
yeah
yeah,
yeah
I.
Think
one
interesting
part
of
this
is
that
which
constraints
you
have
for
your
cluster
is
almost
entirely
defined
by
who's
administering
the
cluster.
C
So
ideally,
we
can
do
both
and
just
say
that
you
pick
which
one
you
want
I'm.
So
this
is
an
example.
That's
taken
directly
from
operator
framework,
so
we
have
some
examples
over
here.
Our
namespace
is
operators
toad
operator
from
Rio
and
then
our
these
are
the
defaults,
but
these
are
also
declaring
that
if
you
look,
if
you
unpack
this
image
and
you
look
in
the
manifest
directory,
that's
what
the
manifest.
Sorry,
if
you
look
here,
that's
where
the
data
is,
and
then
this
is
an
example
of
pulling
some
of
the
metadata.
C
Inside
metadata,
here's
an
example
of
what
we
were
thinking.
We
would
do
so.
Here's
our
registry
v1
format.
This
means
this
has
certain
constraints
over
what's
in
manifest
like
we
expect
certain
objects
to
be
here,
we're
also
looking
at
you
know
how
we
can
treat
sets
of
manifest
as
operators.
Well,
if
they're
not
following
those
conventions-
and
in
that
case
we've
defined
more
minimal
set
here
where
this
is,
we
expect
this
to
be
a
set
of
coop
cuttable
manifests.
We
don't
expect
anything
other
than
that
or
not
of
course.
C
These
were,
these
are
a
little
fuzzier,
because
I
know
we
haven't
actually
protect
any
of
this
out,
but
this
is
ok.
This
is.
It
should
still
be
cops
that
case
I,
oh,
but
if
we,
if
we
do
find
a
format
for
this,
is
what
a
cops
bundle
tornado
looks
like.
So
this
was
based
on
that
demo.
C
So-
and
this
is
getting
back
here
so
I
didn't
realize
that
the
previous
one
had
merged.
So
it
would
be
interesting.
C
What
this
looks
like
for
community
and
a
12
yeah,
the
the
previous
kept
being
merged,
is
just
the
general
approach
and
the
foundation
of
this
effort
and
talking
about
like
what
an
add-on
is
and
why
we
would
want
to
potentially
use
operators
and
that
kind
of
thing.
So
it's
yeah
we're
pretty
far
beyond
that
previous
kept.
But
then
yeah
this.
C
One
is
the
one
that
we've
already
implemented,
but
for
the
most
part,
just
doing
the
media
type
and
knowing
where
to
find
things
and
how
to
apply
them
to
a
cluster
and
then
being
able
to
adjust
how
you
apply
them.
Based
on
that,
media
type
is
essentially
the
only
value
this
this
proposal.
This
is
saying
like.
If
we
standardize
on
this,
then
we
have
a
common
way
to
build
those
variants
and-
and
then
you're-
probably
more
knowledgeable
about
this
question.
C
So
the
current
OCIE
spec
is
basically
the
doctor
needs
you
to
format
with
the
media
types
swapped
for
the
seei
media
types.
So
it's
it
kind
of
depends
on
which
direction
they're.
Looking
whether
or
not
you
say
that
it's
closely
I
can
find
that
I
think
there's
a
couple
of
small
differences,
but
I
don't
remember
them
on
top
of
my
head.
So
from
a
technical
standpoint,
some
people
may
call
it
roughly
accurate
to
say
that
it's
like
a
Venn
diagram
like
lots
of
overlap
and
then
maybe
some
divergence
yeah.
C
But
then
there
there
is
still
a
formal
process
like
using
yamaki
or
one
of
these
OCI
targeting
tools
that
takes
a
docker
image
and
turns
it
into
something.
That's
fully
OC
IDEs
OCI
be
to
complain,
yeah,
so
I'm
trainer
now
so
the
the
document
fest
has
like
a
it
bundles
in
a
second
manifest
that
can
pick
manifest.
That
tells
you
like
who's
how
it
was
built.
We
do
so
like
run
commands
for
that
work.
I.
C
Don't
think
that,
for
example,
it
was
ci
cares
that,
like
the
particular
property
of
the
config
layer
is
the
same
as
in
doctor
like
I,
think
that's
the
parts
where
it
can
vary,
but
the
overall
structure
and
overall
API
is-
and
things
like
that
are
the
same
yeah
I
guess
like
I,
just
I,
don't
know
who
I
could
ask
the
question
to
like?
Is
our
darker
images,
like
subsets
of
the
OCI
standard,
or
not
already
and
like,
where
those
things
get
weird
I
can
see
how
implementation
details
that
are
in
the
OCI
spec.
C
The
image
could
be
compliant,
but
then
registries
may
not
be
general
right.
Like
they
may
be
specific,
and
that's
actually
something
that
I
called
out
down
here,
which
is
that
there's
this
concept
of
CI
as
the
same
as
the
runnable
docker
images,
but
just
different
media
types.
So
a
lot
of
registries
support
that
now,
where
I
can
build
a
new
sky
image
and
push
and
pull
it
and
run
it,
but
that's
still
a
specific
set
of
media
types.
C
What
the
OTA
artifact
thing
is
saying
is
making
that
way
more
general
and
you
can
have
any
subset
of
media
types
and
then
you
can
have
essentially
like
the
manifest
list
concept
with
whatever
media
types
for
layers
that
link
outside
a
manifest.
You
can
have
like
arbitrarily
messages
depth.
So
that's
kind
of
the
the
idea
of
OCI
artifacts
and
that's
the
thing
that
has
much
more
limited
support
across
registries.
C
Some
of
them
only
support
media
types
that
they
know
about
ahead
of
time,
which
kind
of
has
like
a
chicken-egg
problem
with
defining
new
ones
or
it's
like
I
defined
a
new
one.
But
you
can't
actually
push
it
anywhere,
because
no
one
agrees
on
lopes.
Media
type
should
be,
and
they
have
an
added
support
for
it.
Others
I
can
configure
it
like
her
namespace
or
are
they
just
allow
anything
and
then
store
whatever
as
a
blob,
and
you
can
retrieve
it
later.
C
On
projects,
and
then
the
this
is
the
one
that's
the
harder
constraint
to
work
around,
which
is
that
there's
no
way
to
get
a
Kubla
diplomacy
artifact,
which
limits
you
to
the
use
case
for
is
separated
tool
talking
to
your
industry
and
pulling
artifacts,
which
may
be
okay
for
some
clusters.
It's
not
okay
for
posters,
I.
C
C
We
kind
of
looked
at
ways
of
like
what,
if
we
take
all
the
configure
that
the
cubelet
is
using
and
mount
that
somewhere
else
and
use
all
the
configuration
to
go
reach
out
to
any
artifact
or
industry
instead,
but
yeah,
it
gets
back
to
a
lot
of
the
policy
questions.
So
do
you
actually
want
two
things
in
your
cluster
that
can
talk
to
her
industries
when
you've
authorized
this
one
thing
to
do
it
for
you?
C
C
C
Unless
you
stick
all
the
layers
down
into
one
layer
in
the
docker
image,
in
which
case
you
lose
kind
of
a
benefit
of
yeah
yeah,
it
definitely
needs
to
be
solved
at
a
at
a
different
at
the
runtime
or
the
the
thing
that
inflates.
The
image
needs
to
expose
it
a
little
bit
more
smarts
about
what
it's
doing.
Yeah.
C
C
C
Cool
great
well,
it's
very
well
structured,
kept
that's
for
sure.
As
far
as
the
initiative
goes
in,
it's
really
more
of
a
governance
question,
but
I
think
that
there
is
a
little
bit
of
a
of
a
dissonance
in
like
what
the
release
team
wants,
caps
for
and
then
how
they
are
being
used,
because
it's
difficult
to
call
this
like
a
feature
and
it's
current
step.
But
all
of
this
design
work
is
very
sorry
yeah.
C
It's
definitely
tricky
and
I
think
the
utility
of
it
doesn't
really
bear
fruit
for
a
little
while
you
know
it's
more
useful
when
it's
later,
oh
and
when
you
build
a
thing
with
crew
builder,
you
specify
your
like
output,
media
type,
and
now
now
you
can
use
Kugler
and
just
say
this
is
an
add-on.
And
now
it's
with
cops.
You
know-
or
this
is
an
operator
now-
this
works
with
operator
yeah
like
that's,
where
the
value
starts
to
really
come
into
play.
C
C
B
C
C
B
C
Yeah
I,
basically
I
was
going
more
customized
as
like
the
primary
thing,
because
I
had
all
of
these
ideas
of
like
patching
an
extension.
It
already
had
to
get
repo
thing,
it's
already
built
into
coops
ETL
in
some
way,
no
immediate
foreseeable
future,
and
so
it's
just
easy
to
adopt.
But
then
I
added
I
made
it
an
explicit
field.
C
So
when
you
list
your
add-ons
install
configuration,
you
have
to
say
customize
breath,
and
then
you
point
it
to
somewhere
where
you
can
get
a
customized
folder,
oh,
but
you
can
also
just
point
it
to
like
an
HTTP
link
for
a
manifest
mm-hmm.
That's
called
manifest.
Ref
right,
you
know
right,
like
a
Don,
ended,
ref,
right
or
OCI
image,
ref
that
kind
of
thing.
So
what.
C
Could
be
either
playing
or
customized?
Yes,
whatever
machinery
you
have
based
on
yeah
quite
interesting
but
yeah,
the
that's,
a
difficult
part
of
the
design
is
like
how
can
you
decouple
to
the
necessary
extent
like
the
inflation
mechanism,
but
still
provide
something
useful
for
most
of
the
use
cases?
C
C
You
can
get
this
whole
idea
of
like
distributed.
Scripting
on
kubernetes
is
a
really
interesting
space
because,
like
what
we're
effectively
trying
to
achieve
is
like
the
standard,
bash
or
C
code
that
is
run
inside
of
like
apt-get,
but
for
kubernetes
right,
because
it's
it's
not
just
one
computer
and
like
it,
doesn't
have
a
POSIX
filesystem
right.
So
these
ideas
are
weird
to
map
in
a
new
paradigm.
C
Okay,
cool
thanks
for
the
review
appreciate
you
going
through.
It
feel
free
to
post
any
follow-up
questions
or
bright
ideas
in
the
slack
Channel
we
made
it
all.
The
way
through
our
agenda
feel
free
to
queue
anything
that
you
have
for
next
week's
agenda
thanks
to
all
ooh
and
anybody
else
who
joined
welcome
thanks
for
joining.
We're
really
happy
that
you
want
to
or
that
you're
interested
in
working
in
this
area
and.