►
From YouTube: OKD Working Group 2021 01 05 Full Meeting Recording
Description
OKD Working Group 2021 01 05 Full Meeting Recording
https://okd.io
https://github.com/openshift/community/projects/1
A
Hi
joseph
all
right,
let's
get
rocking
and
rolling
here
and
I'm
just
going
to
share
my
screen.
A
See
you
later
and
thanks
everybody
for
signing
in
and
welcome
to,
and
I
even
wrote
2020
because
I
just
didn't
get
enough
last
year.
A
At
least
change
that
to
2021
we
will
properly
start
off
the
new
year
and
I'm
going
to
share
the
we
have
a
little
bit
of
an
agenda
today.
El
maiko
are
you
here
with
us
too,
today
joined
in.
A
Okay
cool,
so
I
was
hoping
that
christian
would
be
joining
us
too,
because
I
think
he
updated
the
community
operator
wish
list,
which
is
one
of
the
things
that
I
kind
of
need
to
start
reaching
out
to
the
operator
communities
and
see
if
we
can
find
some
sort
of
a
a
date
time
to
do
a
hackathon
on
those
operators,
which
is
where
we
left
off.
A
I
think
I'm
missing
one
in
november,
then
I'll
just
go
dig
up
and
put
up
soon,
but
they
should
be
all
there.
So
one
of
the
things
that
we
came
out
of
the
22nd
meeting
was
talking
about
reviewing
and
the
community
operator
wish
list
and
seeing
if
we
couldn't
set
up
a
time,
maybe
to
do
something
like
a
hackathon
or
pair
programming
with
people
from
our
community,
with
that,
with
a
an
advisor
from
the
operator
community
about
building
a
community
operator
for
okd.
A
For
the
ones
that
are
missing
that
normally
come
from
there
and
I'm
looking
to
see
now
as
vadim
joined
the
call,
not
you
if
not
vedin
christian
and
I'm
gonna
unmute
people
because
nobody
needs
to
be
muted.
A
I
thought
we
would
kick
off
with
that
topic
and
unless
vedim,
you
have
an
update
on
the
release
that
you'd
like
to
start
with.
Is
there.
C
C
Instead
of
previously
registry.svc,
all
the
releases
are
still
uploaded
to
kuwait,
so
there
hasn't
been
any
change
there
and
we
didn't
get
a
chance
to
merge
a
lot
of
code
recently
because
of
well
everybody's
on
video,
we'll
catch
up
on
that
in
the
coming
up
weeks.
Okay,
I
think
that's
all
good.
A
Do
you
have
anything
christian
from
the
engineering
side
to
update
people
on,
or
is
that
that
was
that
sound
like
a
a
warning
signal.
A
E
Maybe
maybe
have
you
read
that,
but
I
I
found
out
that
also
for
some
operators
like
way
issue.
I
think,
with
this
mirroring
bug
with
the
wrong
manifests
in
cray,
is
also
affecting,
so
just
just
to
be
safe,
that
everybody
knows
that
if
you
try
to
mirror
some
operators
on
your
local
register
in
a
private
registry,
maybe
it
won't
work
because
say
wrong.
Manifest
is
used
on
newer,
query
images.
E
Yeah,
it's
a
as
a
funny
funny
thing
in
question
in
question
marks
is
that
this
issue,
this
pull
request
you
mentioned
in
slack
that
is
taking
care
about
the
problem
was
running
in
the
image
polaroid
thing
from
docker
hub.
They
have
limited
the
pool
rate
recently
and
I
think
it's
a
bigger
issue
for
us
projects.
C
A
All
right
so
well,
joseph,
while
you're
talking
one
of
the
things
that
you
were
doing
is
you
had
created
your
own
community
operator
and
you
were
gonna.
You
were
thinking
about
and
I
know
we
had
a
holiday
writing
up
a
recipe
or
you
know
how
you
created
that
tecton.
One.
E
It
was
one
yeah
I
I
created
a
repository.
I
put
a
link,
also
in
slack
with
the
idea,
is
that
we
create
for
all
operators
we
are
working
on
and
where
we
cannot
rely
on
the
on
the
teams
that
they
do
it
for
us
that
in
the
meantime,
we
write
descriptions
of
how
we
can
build
it
on
our
own.
E
E
We
had
the
idea
that
I
posted
to
some
repository
in
gray,
some
some
joseph
meyer
repository,
and
I
had
a
few
questions,
because
I
also
wrote
that,
on
slack
I
had
a
good
day
where
I
wrote
all
that
a
few
questions
where
I
was
not
sure
if
I'm
allowed
to
yeah
write
that
red
hat
maintains
that
the
ownership
is
not
clear
and
so
on.
I
was
not
sure
if
I'm
allowed
to
do
that
and
that's
why
I
have
not
opened
the
pull
request
before
we
answer
this
question.
A
Can
you
throw
the
link
to
that
in
the
chat
here
so
that
I
can
keep
a
reference
to
it,
because
that
would
be
what
I
was
hoping
to
do
was
use
joseph's
exercise
and
write
up
as
a
template
for
how
to
do
all
the
other
community
operators
too,
so
maybe
and
run
through
that
and
any
issues
that
you
came
up
with,
so
that
we
can
rinse
and
repeat
that
as
sort
of
the
process
for
building
on
healing
community.
F
And
I
think,
for
the
time
being,
we
could
just
put
okd
working
group
in
in
the
kind
of
maintainers
field.
There
do
not
mention
red
hat
since
we're
kind
of
building
these
on
our
own.
For
the
time
being.
Okay,.
A
I'm
gonna
stop
sharing
for
a
minute
and
see
if
I
can
find
that
note.
So
if
you
can
throw
that
into
the
in
the
chat
the
link
to
what
you
did
so
what
I
think
you're
back
here
now
christian,
you
were
having
some
technical
difficulties
there
for
a
minute.
You
went
all
purple
on
us
and
gave
us
a
storm
warning
signal
for
some
reason.
A
Can
I
get
you
christian,
maybe
to
share
your
screen
and
and
walk
through
the
operator
wish
list
and
we'll
drive
that
and
then
we'll
do
a
bit
with
mike
mcewen's
must
gather
conversation
and
walk
through
the
rest
of
the
few
things
here
that
we
have.
F
F
Okay,
so
I've
updated
the
the
operator
wishlist
a
little
bit
and
yeah
really
I
just
found
some
of
the
operators
are
already
available
either
in
the
community
catalog,
which
we
install
by
default
on
okd
or
also
in
the
upstream
catalog.
F
F
So,
for
example,
the
maestra
istio
service
mesh
operator
was
updated
recently
and
all
of
these
other
operators
are
available
there
for
the
upstream
catalog,
I'm
not
actually
sure
whether
that's
installed,
I
don't
think
it's
installed
and
enabled
by
default
on
okay,
but
you
can
do
that
and
then
you'll
also
have
access
to
these
operators
here
down
here.
Among
more.
E
The
problem
with
maestro
was
that
the
versions
did
not
properly
work
together
between
maestra
kiali
and
jaeger.
We
had
to
patch
lots
of
things
to
get
it
working
and
yeah
and.
F
I
I
think
that
yeah
with
the
yeah
with
the
maestro
operator,
it
actually
has
a
dependency
on
the
elastic
search
operator.
I
think
yes.
F
Yeah
and
yeah,
and
obviously
we'll
we'll
need
to
make
sure
these
versions
match
up
then
yeah.
That
would
be
so.
The
plan
is
so
we
have
some
kind
of
strategic
work
going
on,
but
then
also
I
will
just
open
issues
on
all
these
repositories
here
who
can
request
the
team,
the
teams
to
to
add
those
builds
to
operator
hub.
A
Yeah,
and
so
so,
maybe
one
of
the-
if
we
can
add
a
note
to
the
maestro
kiali
and
jager
in
the
list
that
they're
dependent
on
elasticsearch
so
have
has
everything.
That's
in
the
section
that's
available
in
community
catalog
been
tested
untested.
The
oadp
is:
has
anyone
used
any
of
these
things
on
okd
or
know
of
anyone
who
has
which.
D
A
C
A
F
And
diego
will
work
independently
of
each
other
than
with
this
maestro
operator.
I
don't
yeah
they've
built
it
and
released
it,
but
they
have
a
dependency
on
the
elastic
search
operator,
which
I
think,
obviously
they
they'll
take
the
downstream
one
from
red
hat,
which
we
don't
from
openshift,
which
we
don't
currently
build
and
release
to
operate
up
so
yeah.
The
maestro
one
probably
needs
such
some
work
there,
but
then
all
the
others
should
work,
especially
those
that
are
in
the
community
catalog.
F
They
can
be
installed
independently
of
each
other,
except
for
the
maestro
one
and
yeah.
You
should
be
able
to
test
them
for
those
in
the
upstream
catalog
they
some
of
them
might
work
on.
Okay,
and
especially
those
I've
listed
here.
I
think
there's
nothing
that
goes
like
against
installing
them
on
okd.
F
I
I
would
expect
them
to
work
and
if
we
could
get
some
people
to
actually
just
test
those
that'd
be
great,
and
then
we
could
easily
kind
of
copy
those
over
from
the
upstream
catalog
into
the
community
catalog
as
well,
without
having
to
actually
rely
on
on
the
maintainers
work.
Here
too
much.
E
I
I
tried
out
the
cef
operator,
but
not
from
a
catalog,
and
I
don't
know
if
there
is
a
cluster
service
version.
What
was
the
name
of
the
crd
cloud?
I
think,
but.
E
Yeah-
and
I
think
I
I
did
not
found
any
csv
for
the
rook
cev
operator-
maybe
we
have
to
write
our
own,
but
this
should
be
no
big
big
problem.
In
my
opinion,.
F
That
should
be
there,
it's
just
not
in
the
community
catalog,
so
it
doesn't
show
up
in
okay,
okay,
okay,
but
if
you
enable
the
upstream
catalog
manually
by
adding
that
subscription,
then
that
would
show
up
as
well,
and
you
can
see
the
cluster
service
version
in
the
community.
E
Yeah,
sorry,
I
have
a
delay
three
sorry
and
the
idea
is
that
we
try
it
out
from
the
upstream
catalog
and
if
it
works
properly,
then
we
can
create
a
pull
request
for
the
community
catalog.
F
Then
we
can
just
create
a
pull
request
to
copy
that
over
to
we
should
be
able
to
use
the
same
contents
there.
I
think
it
shouldn't
be
a
problem
for
those
in
the
same
catalog
but
yeah.
We
can
create
an
apr
and
then
have
that
reviewed.
A
Okay,
so
I'm
going
to
ask
a
a
question
about
process
2.
once
once,
we've
done
that
ourselves
say
we
take
the
the
rook
ceph
operator
from
the
upstream
catalog
and
make
a
pull
request,
like
maybe
joseph
does
it
to
put
it
in
the
community
operator.
Isn't
the
end
goal
to
get
the
commute
the
rook
ceph
community
in
their
ci
cd
release
process
to
make
that
pull
request
to
us.
So
we
still
need
to
absolutely.
B
A
With
them
and
tell
them
what
we're
doing
so,
if,
if
it
does
work
rather
than
us
testing
it,
how
do
we
communicate?
I
mean?
How
do
we
want
to
communicate
to?
I
know
the
rook
ceph
people
and
because
I've
made
them
talk
a
billion
times,
so
you
know
I
can
reach
out
to
them.
If
someone,
if
someone
writes
that
pull
request
in
their
repo,
we
put
it
put
it
in
our
community
repo
to
start
with,
but.
F
Yeah,
so
definitely
we
should
we
should
get
the
the
operator
maintainers
to
do
that
eventually
for
all
operators
right
now,
I
think
the
the
biggest
hurdle
here
is
that
that
isn't
really
an
automated
process
to
release
to
the
operator
hub.
So
there
are
a
few
scripts
around
to
generate
that
data.
F
But
since
that
comes
from
a
different
repository
from
the
repository
where
the
individual
operator
codes,
it's
updating
the
operator
each
time
is
some
yeah
involves
some
manual
steps
mostly,
and
I
think
once
we
get
that
to
yeah,
get
more
automation
for
that
and
kind
of.
I
can
integrate
that
better
with
with
ci's
with
these
various
ci
systems,
we
have
kind
of
just
promote
some
builds
whenever
the
maintainers
decide
to
promote
that
to
operate
out.
F
H
Often
christians,
john
forten,
is
there
a?
Is
there
any
instructions
on
enabling
the
upstream
catalog?
I
just
looked
real,
quick
and
I
see
the
red
hat
catalogs
in
the
community.
I
don't
see
a
way
of
enabling
the
upstream
catalog,
because
I'd
love
to
test
the
rook
stuff
operator,
I'm
right
now,
I'm
doing
it
by
hand.
H
F
I
mean
he
said
in
the
update.
There
should
be
some
some
documentation
on
the
operator
sdk
documentation
on
how
to
enable
right
secondary
catalog
sources.
H
F
There
I'm
not
actually
sure
I'll
I'll
find
it.
F
A
Yeah,
I
think,
there's
some
before
we
could
do
a
hackathon
or
anything,
that's
kind
of
why
I
was
trying
to
tickle
ortiz
out
of
the
tech
time
work
that
joseph
was
doing
sort
of
a
template
for
how
to
do
this.
F
Yeah,
so
these
are
the
sources
in
the
community
operators
repository
in
the
upstream
community
operators
directory
and
yeah.
I'm
not
sure
what
the
catalog
sources
would
exactly
look
like.
We
currently
add
them
to
our
machine
os
content,
but
maybe
you
can
you
find
a
link
where
we
do
that.
A
C
Basically,
I
don't
know
it's
a
great
documentation
bug
in
short
operator
full
operator
framework
folks
are
pushing
three
different
container
images
with
an
index
of
the
operators,
and
we
know
too,
we
just
need
to
find
out
which
image
is
being
pushed
for
upstream
catalog.
A
So
joseph
is
is
in
the
chat
is
suggesting
that
we
should
create
some
notes
in
the
okd
cookbook
how
to
build
an
opera
openshift
operators
for
okd,
and
I
think
that's
that's
really.
What
I'm
getting
at
is
that
if,
once
we
have
once
you
guys
create
that
documentation,
then
then
rolling
out
to
the
the
list.
The
wish
list,
that
christian
is
curating
there
is
that
wish
list
for
other
people
on
it.
Are
there
things
missing
from
that?
Has
anyone.
F
I
will
actually
open
an
issue
on
the
on
our
okay
d
repository-
oh
actually,
the
community
repository
for
this.
So
we
can
kind
of
have
people
throw
in
their
own
suggestions.
B
Yeah
yeah
diane
you
were
asking
before
about
if
anybody
had
run
those
operators
on
okd,
I've
run
previous
versions
of
the
open
data
hub
operator
on
okd,
and
I
think
that's
that's
gonna.
I
have
a
feeling
that
would
be
a
very
popular
day,
two
operator,
because
you
know
everyone's
gonna
want
the
ml
stuff.
It's
also
like
a
meta
operator.
It
installs
other
operators
of
its
own.
I
have
a
feeling
it's
gonna,
be
really
difficult
to
test,
like
the
experiences
that
I've
seen
from
people
who
are
running
the
current
versions.
B
Is
that,
like
some
parts
of
it
work
really
well,
other
parts
of
it
are
extremely
difficult
to
operate
so
that
that
may
be
one
that
it
will
probably
require
a
lot
of
testing.
Fortunately,
the
team
that's
working
on
it
is
really
good
about.
You
know
responding
to
requests.
A
B
Kubeflow,
open
data
hub
so
open
data
hub
is
a
project
that
is,
it
now
includes
kubeflow,
and
it
also
has
like
support
for
apache
spark
patch.
You
know
it
uses
strimzy
for
kafka
and
it
has
a
bunch
of
machine
learning
and
you
know
data
specific
data
analysis
specific
packages
inside
of
it,
but
it
does
a
lot
of
this
through
importing
other
community
operators.
You
know
to
do
that
work
so
things
like
installing
jupiter
hub.
I
think
they
have
a
jupiter
hub
operator
for
and
you
know,
etc.
There's
a
spark
operator,
that's
involved.
B
Yeah
yeah
so
like
there's
a
lot
of
really
popular
machine
learning
and,
like
you
know,
dare
use
the
word
artificial
intelligence
type
stuff
in
that
operator.
So
you
know
we
just
we
get.
I
see
a
lot
of
people
wanting
to
do
that
as
like
a
day
two
operation
to
open
up.
You
know
let
their
users
start
working
on
ai
type
stuff,
but
it's
it's
extremely
complicated.
Depending
on
what
you're
working
on
just
a
warning,
I
guess.
A
Yeah,
it
would
be
lovely-
and
I
I
have
all
kinds
of
ulterior
thing
is
if
we
could
get
a
demo
of
that
by
the
28th
of
january,
which
is
when
I'm
hosting
the
openshift
commons
gathering
on
data
science.
B
B
No,
it
probably
won't
be
subin.
Subin
is
working
on
the
top
stuff,
but
you
know
it
would
be
like
you
know,
someone
like
avashek
or
someone
like
that
who's
on
the
the
odh
stuff
now,
but
I
would
reach
out
to
sherrod
griffin,
I
think
he's
still
leading
that
group
so,
like
I'm
sure,
they'd
love
to
get
involved.
A
Yeah,
no,
I
think
I
think
you're.
I
think
you're
right
about
that.
So
what
I
had
asked
quickly
is,
if
there's
anything,
glaring,
that's
missing
from
here
john
fortin,
joseph
those
of
you
who
are
out
there
and
end
user
land
really
using
this.
Is
there
anything
we're
missing,
yeah.
E
E
Suppose
maybe
I
mix
it
up,
but
there
was
a
was
installation
was
a
bare
metal
installation.
Something
was
missing,
but
it's
not
an
operator.
I
think
it's
awesome.
Yeah.
F
The
bare
metal
operator
is
part
of
the
payload,
but
we're
currently
not
building
it,
because
we
don't
have
all
the
parts
to
do
that
with
fedora
slash
centos
in
this
case,
because
we're
yeah
we're
doing
that
for
ocp
for
the
product,
obviously
with
with
rel,
and
we
need,
I
think,
the
shim
binary
there,
or
at
least
some
some
parts,
some
image
parts
or
dixie
booting.
I
think
I
think
it
was
no.
F
That's
work
in
progress.
We
have
open
prs
for
this,
so
bare
metal
is
currently
not
supported
as
a
platform
in
okd,
but
once
it
is
it'll
just
be
in
the
payload
there's
no
extra
operator,
we
need.
E
Okay,
another
question:
is
it
possible
how
how
do
we
take
care
about
the
image
location?
Currently,
the
images
are
stored
under
open
quay,
io,
openshift
or
quero
yeah,
some
open
shift,
specific
namespaces
should
be
open.
If,
if
you
build
these
operators
on
our
own
and
manage
them,
should
we
create
an
okd
working
group
namespace
in
quay,
or
how
do
we
handle
that?
I
have
no
good
feeling
in
using
my
own
namespace,
because
if
I
overwrite
something
during
my
test,
then
lots
of
people
will
shout
at
me
for
a
good
reason.
C
I
would
prefer
to
use
openshift
namespace
that
would
make
things
a
lot
easier.
First
of
all,
if
this
whole
thing
goes
live,
we
will
be
using
ci,
meaning
we
would
push
images
automatically
to
open
shift
namespace,
so
there
shouldn't
be
any
difference
between,
but
the
the
manual
how
to
do
this
yourself
and
use
your
own
custom
namespaces
is
certainly
very
useful,
but
in
the
future
I
would
prefer
to
use
openshift
for
everything
going
on.
E
Yeah,
that's,
I
think
we
all
would
prefer
that,
but
the
idea
was
to
yeah
release
the
stress
from
the
teams,
because
we
we
would
have
to
wait
for
the
teams
until
we
get
it
in
okd
in
the
community
catalogue.
You
know
and
if
we
find
a
good
way
to
have
some
intermediate
process
to
get
it
in
the
catalogs
very
soon,
because
it's
yeah
in
the
case
of
the
pipeline
operator,
it's
just
you
call
three
or
four
commands
and
you
have
it
in
the
in
your
catalog.
If
you
want.
C
Yeah,
something
like
staging
would
probably
be
useful.
I
guess
sojiri
would
be
a
good
start,
but
we
would
need
some
architects
and
probably
folks
from
operator
hub
opinion.
So
your
proposal.
F
I
I'd
say
just
publish
them
to
your
own
namespace
for
now
open
the
pr,
and
once
we
have
that
reviewed
and
everything
we
can
still
copy
the
images
over
to
some
other
namespace
that
would
be
okd
working
group
or
whatever
concrete
before
we
actually
merge,
merge
and
aprs.
So
I
wouldn't
block
on
that.
Now
we
can
still
create
a
kind
of
a
working
group
namespace
later
on.
E
Okay,
yeah,
I
will
do
that
and
I
will
change
a
maintainer
to
a
okd
working
group
and
that
should
be
all
or
is
there
something
I
should
take
care
about
to
not
get
stressed
with
legal,
the
icon?
It
was
the
operator
name,
it
is
called
openshift
pipeline
operator.
I
No
it'll
get
changed
to
tactile
pipelines,
operator,
it'll,
it'll
it'll
turn
into
something
generic
or
upstream,
like
hubert
operator,
is
not
called
cube.
Vert
operator
for
red
hat,
open
shift
container
platform,
it's
called
something
like
red
hat,
open
shift,
virtualization
or
something
dumb
like
that.
So
so
that'll
happen
with
the
tactile
pipelines
operator
will
probably
just
be
called
kubernetes
pipelines
or
tecton
cd
or
just
something
something.
That's
that's
useful.
I
think
the
tactile.
E
F
A
So
if
we,
what
I
would
like
to
use
is,
is
joseph's
efforts
and
get
that
all
everything
figured
out
in
terms
of
naming
and
what
the
process
is
for.
A
Building
that
and
I'm
wondering
if
I
know
we
only
meet
by
bi-weekly
if
we
could
use
this
time
slot
next
week
and
I'm
not
sure
what
joseph,
what
your
schedule
is
like
to
coach
and
review
what
joseph's
done
and
clean
it
up
and
get
it
into
the
okd
cookbook
how
to
build
an
operators
and,
and
maybe
next
tuesday,
joseph
and
I'm
not
sure
who
who's
the
best
person
to
help,
whether
it's
christian
or
vadim,
or
someone
else
here
and
get
one
done.
A
The
way
that
we
as
a
working
group
want
to
do
this
would
be
great,
is
christian
or
vadim.
Are
you
available
next
tuesday?
I
am
not
because
I'm
in
a
all-day
meeting
next
week,
but
I
I
actually
prefer
to
do
that.
F
Asynchronously,
if
there's
a
full
request,
it's
easy
for
me
to
review
it.
Whenever
I
comment.
E
Do
it
we
could
remove
all
openshift
references,
replace
it
by
okd
community
well
or
simply
only
okd
instead
of
openshift.
Would
that
be
okay
well
place
an
okd
before
the
name
of
an
operator
for
all
okd
operators.
B
A
All
right,
so
we
don't
need
to
meet
next
week,
which
is
fine.
I
just
wanted
to
make
that
space
for
us
if
we,
if
we
needed
it,
so
I'm
just
adding
updating
this
here
so
because
what
my
goal
is,
as
everybody
knows,
I
always
have
an
up.
A
Teriya
motive
is
to
get
one
done
all
the
way
through
and
then
hack
our
way
through
the
rest
of
the
list
and
with
the
techton
one
it
doesn't
sound
like
we
need
someone
from
the
tecton
community
to
coach
you
guys
on
on
anything
anything
technical
just
to
get
it
incorporated
in
as
a
pull
request
for
them
to
do
it
in
the
future.
E
I
I
don't
think
so,
because
I
am
using
it
for
building
stuff
already.
I
did
not
found
any
any
issues
I
can
remember
off.
I
I
would
I
would
prefer.
I
would
suggest
that
we,
if
we
have
to
change
something
on
the
operators
like
I
have
to
change
openshift
to
something
else.
Yeah
I
will.
I
will
fork
the
repo
also
to
the
okay
cook,
cookbook
organization,
and
we
should
write
the
changes.
E
This
is
says.
That's
such
a
suggestion
to
this
repo
I
have
mentioned
before
just
to
have
it
written
down
in
a
structured
way
in
one
repository
how
to
build
openshift
operators,
and
it's
only
an
immediate
intermediate
step.
If
we
have
the
ci's
running,
we
can
delete
it,
but
in
the
meantime
I
think
it's
valuable
to
save
this
findings
somewhere
in
one
repository.
E
I
would,
I
would
yeah,
do
it
like
this
and
we
should
mention
this
repository
this
organization
somewhere.
I
did
not
find
in
okdio
that
we
have
mentioned
it.
Okd
cookbook.
A
It's
yeah,
it's
it's!
It's
just
a
landing
page
at
the
moment
that
has
links
out
to
some
of
the
rupos
that
charo
has
done
so
we'll
need
to
clean
that
up
a
little
bit
too.
Okay,
let's
let's,
let's
get
through
next,
hopefully
by
next
tuesday.
That
will
be
my
goal
and
then,
when
I
come
out
of
the
three-day
all-day
meetings,
I'll
take
a
look
at
what
you
guys
have
done
and
see
what
we
need
to
do
in
terms
of
okd
and
the
cookbook.
A
The
question:
that's
in
the
back
of
my
mind,
is
once
we
have
it
all
done
once
and
we
have
the
techton
one
in
our
repo
working.
Well,
I
think
I
heard
someone
say
I
think
it
was
christian
that
we
need
to
make
a
pull
request
on
that
operator,
the
tecton
operators
repo
for
them
to
be
informed
that
this
is
something
we
would
like
them
to
do
on
a
regular
cadence
or
inform
us
when
they
have
a
new
release.
Yeah.
F
J
F
E
A
Well,
everyone
will
get
get
a
little
better
at
building
operators,
then
out
of
this
all
right,
so
so
that
that's
really
for
2021
in
january.
A
What
I'd
really
like
to
do
is
just
in
january
and
february,
is
push
through
that
list
and
then,
if
we
need
to
set
up
a
you
know,
maybe
asynchronous
pair
of
programming
with
people
from
the
community
from
who
are
members
of
the
working
group
with
with
anyone
from
maybe
elasticsearch
or
whatever,
to
just
inform
them
on
what
the
new
process
is
or
the
request
is
and
if
there
are
things
like
variables
that
need
to
get
changed,
start
working
with
them
and
identify
them.
A
A
I
do
have
audrey
and
sophie
speaking
at
the
january
28th
thing,
but
I
don't
think
I
have
anyone
doing
I'd
love
to
have
like
a
short
video
on
using
the
open
data
hub
operator
on
okd
sort
of
like
we
did
with
the
the
marathon
day
we
did
of
okd
deployments
is
showing
them
in
action
on
okd
and
any
tweaks
that
we
had
to
do
so
just
to
give
them
a
little
more
publicity
in
return
for
their
health.
A
So
the
next
thing
I
have
on
my
list
here
is
mike.
You
had
brought
up
on
the
mailing
list,
the
must-gather
and
okd
topic.
You
want
to
walk
through
that
and.
B
Yeah
so
before
before
holiday
and
everything
bruce-
and
I-
and
I
think
a
couple
others
were
talking
in
slack
about
you-
know-
must
gather
and
kind
of
like
the
safety
of
sharing
those
things
and
how
useful
they
are
and
stuff-
and
I
guess
just
for
a
little
background
for
anyone
who
doesn't
know,
although
I'm
guessing
most
of
people
here
do
know,
must
gather
is
like
an
administrator
tool
that
we
have
in
openshift.
B
B
This
is
an
extremely
useful
and
I
think
some
would
probably
say
essential
tool
for
us
in
solving
some
problems,
especially
with
running
clusters,
and
so
you
know
the
question
that
bruce
was
raising
was
like.
Is
it
safe
to
create
these
and
kind
of
share
them
publicly?
Where
should
we
do
it
because
they
can,
they
can
grow
in
size
up
to
four
or
500
megs
and
they're?
B
You
know-
and
this
is
the
safety
issue-
was
kind
of
the
the
heart
of
it,
and
I
think
you
know
vadim
and
christian
probably
know
way
more
about
this
than
me,
but
you
know
my
my
gut
feeling
is
like
it's
not
safe,
but
it
should
be
safe.
The
problem
is,
there
are
like
container
logs
from
your.
You
know
from
your
control
plane
that
are
included.
B
There
are
dumps
of
all
sorts
of
like
configuration
and
objects
that
exist
in
the
control
plane
that
are
dumped
so
like
in
a
in
a
in
the
best
world
situation.
It
should
be
safe
to
do
that,
but,
like
you
know,
there
are
corner
cases
and
I've
seen
bugs
that
have
come
up
where
you
know
some
container
logs,
especially
like
sensitive
container
logs
in
the
control
plane,
are
maybe
exfiltrating
secrets
through
their
logs
and
whatnot.
If
they
have
the
wrong
verbosity
level
set.
You
know
those
kind
of
things,
so
you
know
to
kind
of
bundle.
B
This
all
up.
The
reason
I
sent
the
email
and
the
reason
that
I
kind
of
looked
into
this
a
little
more
after
bruce
and
I
had
talked
about
it-
was,
I
think,
I
think,
for
the
okd
community.
It's
going
to
be
like
really
important
for
us
to
figure
out
a
way
that
we
could
consume
must
gathers
from
the
community,
because
it
will
really
help
us
to
solve
problems
that
people
are
seeing.
B
You
know
it
may
not
be
the
best
tool
for
every
problem
that
we
have,
but
if
we
could
establish
some
way
to
make
this,
you
know
safe
and
kind
of
make
it
like
a
trusted
way
for
people
to
do
this
with
the
okd
community.
I
think
it
would
be,
I
think,
would
be
tremendous
just
to
help
us
out
so
anyways
yeah.
I
wanted
to
open
it
up.
D
I
think
that's
a
great
idea.
I
think
one
thing
we're
going
to
want
to
do.
First
is
look
at
examples
and
make
a
list
of
things
that
are
possible
issues
with
what
is
gathered,
because
right
now,
there's
vadim
seems
to
know
a
fair
amount
about
it,
but
it
seems
like
there
are
some
edge
circumstances,
but
we
need
some
examples
to
actually
know
what
those
are
and
under
once
what
circumstances
that
those
come
about.
So
I
think
research
would
be
phase.
D
One
of
this
right
is
find
out
under
what
circumstances,
something
you
know
determine
something
that
is
sensitive
and
figure
out
under
what
circumstances
that
it
appeared.
D
E
C
That's
correct:
that's
what
it
does
we
don't.
The
information
from
other
namespace
is
just
irrelevant
if
I
remember
correctly
we're
stripping
passwords
from
idp
configuration
and
things
like
that,
but
it
needs
to
be
verified.
I
don't
have
a
nice
setup
where
we
would,
it
would
be
visible.
C
J
C
Oh,
so
it's
safe
to
rip
it
out
from
the
actual
mass
getter
you're
sending
us.
I
was
under
impression
that
we're
only
getting
the
open
shift,
but
I.
J
Well,
I
guess
because
it
pulls
in
all
the
operators
that
are
installed
cluster-wide
in
every
namespace.
B
Yeah,
it
pulls
in
the
cluster-wide
resources.
So
if
there's,
if
there's
a
cluster-wide
resource,
that's
exposing
that
information
and
this
you
know
what
I
think,
what
you're
bringing
up
bruce
is
something
that
probably
I
I
don't
even
know
if
it
was
thought
about.
You
know
the
idea
that
you
might
have
personal
information
encoded
in
your
name,
space,
I.e
like
your
your
name
or
something
that
that
might
be
an
opportunity
for
us
to
do
some
work
around
on
the
must-gather
side.
You
know
maybe
things
like
name
spaces
and
other
types
of
user
input.
B
B
If
I'm
looking
at
one
of
these
must-gathers,
I
might
try
to
match
up,
you
know
like
what
container
was
running
and
what
you
know
area
or
whatever.
So
I
might
see
one
of
those
values-
and
this
is
exactly
you
know
to
the
thing
that
jamie
was
talking
about
before
these
are
exactly
the
type
of
bugs
we
see
where
you
know.
B
Someone
has
inadvertently
exposed
information
in
what
you
would
think
would
be
a
benign
resource
object,
but
now
it's
in
the
must
gather
and
it's
been
uploaded
forever
right
and
and
likewise
with
the
logs
coming
out
of,
even
even
if
they're,
just
the
logs
for
containers
on
the
control
plane.
You
know
we
just
had
a
bug
recently
where
one
of
the
verbosities
was
set
wrong,
so
it
was
dumping
everything
from
that
container.
I
think
I
think
vadim
identified
it.
So
I
see
him
shaking
here
nodding
his
head.
B
You
know,
and
that
was
the
kind
of
thing
where
it
was
like
it
was
exposing
secrets
in
the
logs
inside
the
must
gather.
So
I
I
kind
of
got
away
from
what
you
were
talking
about,
but
I
think
the
things
that
you're
talking
about
maybe
give
us
some
ideas
on
how
we
could
make
must
gather
a
little
better
in
terms
of
scrubbing
out
some
of
this
information
as
it
does
that.
D
J
Yeah
nazi's
got
to
say
that
one
way
to
keep
the
information
from
going
across
the
internet
would
be
to
encrypt
it
with
you
know
like
like.
If
you
have
a
a
key
pair,
then
you
could
encrypt
it
with
a
public
version
and
then
it's
only
visible
inside
of
your
organization
as
opposed
to
the
entire
internet,
which
is
not
perfect,
but
it's
a
lot
better.
B
Yeah,
especially
for
the
for
the
okd
community,
that
I
mean
obviously
any
encryption
that
we
put
on
it
even
if
we
had
keys
that
were
shared
with
people
who
were
like
on
the
debugger
list
or
whatever
that
I
I
don't
know
that
that
necessarily
creates
the
trust
that
we,
you
know,
because
those
those
keys
would
be
pretty
weak.
You
know
someone
could
share
them
or
whatever,
but
but
I
like,
I,
like
the
notion
that
you
know
there's
a
way
we
could
at
least
store
them
at
rest
in
a
way
that's
encrypted.
D
B
I
try
I
looked
around
inside
and
tried
to
find
something
I
did
find
a
document.
Unfortunately,
I
can't
share
it
because
it's
like
you
know
it's
red
hat.
It
has
personally,
it
has
red
hat.
You
know
corporate
information
in
it.
The
must,
I
think
you
know
what
I
was
thinking
as
I
was
reading
through
this
stuff
and
looking
at
the
must-gather
repo.
I
think
the
next
really
big
step
would
be
to
propose
like
an
faq
or
something
to
that
repo.
If
it's
not
there
already,
you
know
just
a
document
in
that
must-gather
repo.
B
That
says
this
is
exactly
what
is
collected
because
that's
where
it
should
live.
You
know
for
everybody
right.
B
I'm
looking
at
that
repo
again
just
to
double
check.
I
didn't
miss
something,
but
yeah
I
mean
it's
pretty
barren.
I
guess
there
is
an
enhancement
they
link
to.
I
didn't
read
that
that
that
might
actually
give
all
the
information.
B
So
anyways
the
I
guess,
the
second
kind
of
the
other.
The
second
question
I
had
for
this
group-
and
maybe
you
know
I
obviously
it's
not
something
we're
going
to
solve
now,
but
something
we
should
think
about
is
kind
of
like
how
would
we
you
know?
How
would
we
have
a
workflow
where
an
okd
user
could
create
a
must
gather
and
then
have
a
place
to
upload
it
so
that
they
could
link
it
against?
I
A
B
B
Is
there
some
way
that
we
could
we
could
change
the
must
gather
to
more
aggressively
scrub
out
information?
You
know
and
replace
it
with.
Just
you
know
hashes
that
can
be
linked
like
is
there
a
way
to
take
that
must-gather
tool
into
the
next
generation
of
what
data
governance
really
means
because,
like
for
those
of
us
fixing
the
problems
like
we
don't
care
about
the
names
and
all
the
stuff?
You
know
the
sensitive
information
there
does
not
affect
me
one
way
or
the
other.
B
It
could
all
be
changed
to
just
hash
values
that
I
match
up
and
I
can
still
achieve
the
same
thing.
So
you
know,
like
I
think,
there's
probably
some
middle
ground
we
could
achieve
where
those
must-gathers
could
become
totally
just
neutral.
You
know
where
it's
like
it.
Does
it's
not
going
to
mean
anything
to
anyone
else
than
the
person
who
created
it
and
the
people
who
are
trying
to
debug
from
it.
D
Yeah,
just
to
give
you
a
good
example
of
this,
so
using
it
in
a
university
environment,
people
are
going
to
name
their
projects,
often
with
their
unique
name,
their
username
at
the
university.
You
know,
and
there
may
be
something
else
in
the
title
of
the
name
space.
There
may
be
other
things
that
really
that
relate
to
individuals
and
in
united
states
and
university
settings.
That's
problematic,
because
people
you're
not
supposed
to
even
identify
what
classes
that
people
are
taking
outside
of
the
university
and
whatnot.
So.
A
There's
a
lot
of
issues
about-
maybe
one
thing
we
could
do
mike
is:
who
is
the
point
person
in
that
repo
for
must
gather
like
they
must
have
thought
about
this
pretty
a
lot
when
they
they
were
writing
it
up.
So
maybe
what
we
could
do
is
have
you
reach
out
to
them
and
and
see
what
they
what
what
their,
what
their
game
game
plan
was.
I
probably
bring
it
all
behind
the
red
hat
firewall.
You
know
well.
B
Right
right
because
we're
doing
it
through
bugzilla
and
we're
bringing
these
things
internal,
you
know.
That's
it's
a
great
idea,
though
diane
I'll
figure
out
who
that
is
and
do
some
reaching
out
and
just
see
if
I
can
do
a
little
more,
a
little
more
digging
just
to
see
what
they
were.
Thinking
and
maybe
they've
got
some
ideas
around
this-
that
they're
already
kind
of
working
on
yeah.
A
B
A
I
A
Rainbow
all
right,
so
I
I
just
wanted.
I
know,
there's
been
a
lot
of
chat
while
you
were
talking
about
mustgather,
because
as
soon
as
anyone
says
the
word
arm
or
raspberry
pi
and
any
tech
meeting
everything
blows
up
in
chat.
A
So
I
wanted
to
ask
jeremy
linton
to
introduce
himself
because
he's
new
to
the
meeting
and
he's
from
the
arm
world
and
maybe
talk
a
little
bit
about
what's
been
going
on
in
the
chat
there
around
needing
needing
some
place
to
test
arm
and
that
so
jeremy,
can
I
get
you
to
turn
your
microphone
on?
If
it's
not?
A
K
Just
did
I
guess,
quick
intro,
I
guess
I'm
jeremy
linton,
I'm
actually
one
of
the
red
hat
partner
engineers,
I've
been
all
eternal
years.
We
don't
see
you
yeah.
I
guess
you
can
have
camera
too,
but
I've.
K
Yeah
so
yeah
I've.
I
guess
I
went
to
a
flock
a
couple
years
ago.
I'm
sort
of
somewhat
active
on
the
side
as
well
upstream
kernel,
piano
core
that
kind
of
stuff,
and
I
guess
the
chat.
I
was
talking
about
the
pi
firmware
task
force,
which
I
can
get
hub
page,
which
is
there's
a
uefi
firmware
for
the
raspberry
pi
that
allows
it
to
boot
a
wide
range
of
operating
systems
windows.
K
There
aren't
drivers
for
some
of
the
hardware
yet
centos,
because
it's
not
a
supported
rail
target
but
yeah.
It
works
fairly.
Well
when
in
fedora
it's
getting
better
every
day
like
right
now
I
have
some
pci
patches
posted
that
are
hopefully
going
to
merge.
That'll
give
us
native
pci
support
instead
of
having
to
use
the
usb
xhci
as
a
platform
device,
there's
a
long
list
of
things
anyway.
K
So
I
guess
personally,
with
the
up
and
coming
open
shift
release
for
red
hat,
I'm
sort
of
getting
in
front
of
a
bit
of
that
and
seeing
if
I
can
do
a
little
bit
of
contribution
or
testing
with
okd
on
maybe
that
platform
graviton
whatever
seems
to
be
desirable.
At
the
moment.
I
have
a
pretty
wide
range
of
spsa
platforms.
I
can
test
it
on
and
a
couple
years
ago
I
actually
spun
up
openshift-
or
I
guess,
okd
from
source
and
sort
of
got
it
working.
But
I
haven't
really
touched
it
since.
A
Well,
I
think
if-
and
this
is
I
was
just
talking
yesterday
with
the
folks
who
do
developer.com
redhat,
developer.com
and
they've-
been
asking
me
for
very
specific
things:
developer
focused
topics,
so
you're
you're
you're.
My
lead-in
to
this
conversation
about-
and
I
and
I
know,
arm
and
raspberry
pi-
are
really
hot
topics
for
folks.
So,
if,
even
if
you
just
wrote
up
a
blog,
they
would-
and
I
would
funnel
it
into
them-
about
your
adventures
in
deploying
okd
on
arm.
That
would
be
a
great
spot
to
start
the
other
thing
and
charo's.
A
Not
here,
I'm
going
to
try
and
get
charo
to
do
one
on
using
the
code
ready
container.
I
think
we
have
videos
of
it,
but
we
don't
have
any
write
up
how
to's
or
anything
that
for
developer.com,
specifically
with
okd.
There
was
a
question
joseph
you
put
in
about
the
tool
chain
for
code,
ready
containers
so
I'll
see.
A
If
I'm,
I
can
track
down
char
to
do
that
and
then
craig
robinson,
who
I
don't
think
is
on
the
call
today
did
a
nice
using
his
deploying
okd
for
I
think,
was
4.4
on
his
home
lab.
So
the
more
content
we
can
get
that
is
specifically
like
things
that
developers
are
just
going
to
eat
up
like
candy,
which
is
what
I
think
of
raspberry
pies
as
candy.
I
love
them
so
and
there's
too
many
of
them
in
my
house
right
now,
and
but
I
think
that
would
be.
A
That
would
be
great.
If
you
have
the
platforms
to
test
on
you
know,
we
definitely
would
help
you
out
doing
that
and
and
a
recipe.
A
What
we're
trying
to
do
is
create
sort
of
a
cookbook
of
recipes
on
how
to
do
that,
and
I'm
trying
to
drive
adoption
of
okd,
because
for
me-
and
this
is
just
my
philosophy
of
okd-
allows
us
to
do
a
great
lot
of
collaboration
with
the
fedora
core
west
community
and
and
like
we
saw
with
4.6
when
things
happen
in
fedora
core
os.
A
That
impact
us
we're
basically
the
early
warning
system
for
for
a
lot
of
things,
fedora
core
west,
which
will
eventually
end
up
in
real
core
os,
which
will
you
know
so
it's
really
great
for
us
to
be
able
to
do
that,
testing
on
arm
and
any
other
places
as
well
so
thumbs
up
thanks
for
joining
us.
That
would
be
that's
great,
and
if
anybody
wants
to
help
him
with
that,
I
can
see
chatter
going
on.
C
So
yeah
a
short
short
recap
of
what
we
talked
about
in
the
chat
so
from
okay.
These
perspective,
we
don't
run
on
arm
yet
because
we
don't
build
arm
64
images
that
can
be
fixed,
relatively
simple,
but
the
problem
is
cadence.
We
probably
would
be
able
to
rebuild
just
released
images,
because
that
would
take
time
and
precious
resources
and
okay.
They
can
afford
that.
C
Another
problem
is,
we
are
targeting
16
gigabyte
semesters
and
I
don't
think
raspberry
pi
can
allow
that.
But
that
is
my.
J
C
On
openshift
scale,
because
they
are
targeting
three
masters
on
eight
gigabytes,
so
we
will
gather
for
free
once
we
rebase
once
we,
this
lands
on
four.
For
this.
L
F
There
there
are
already
arm
builds
from
the
community
from
the
typhoon.
I
think
it
is
this
kubernetes
distribution
that
also
runs
on
our
os
and
we're
actively
working
on
on
actually
building
official
arm
images.
I
As
well,
right
and
fedora,
core
os
already
does
produce
arm.
64
images
arc,
64
images,
whatever
you
want
to
call
them
now,
and
the
main
issue
right
now
is
that
the
raspberry
pi
4
series,
like
between
the
eight
gigabyte
model,
which
is
the
only
reasonable
model
to
actually
use
for
for
okd,
has
a
sufficiently
different
square
base
and
dt
and
device
tree
and
components
and
drivers
and
stuff
that
none
of
it
has
been
upstreamed
into
the
latex
kernel.
So
fedora
has
basically
no
functional
support
for
the
eight
gigabyte
model.
I
The
four
gigabyte
model
mostly
works,
the
eight
gigabyte
model
does
not
work,
and
the
raspberry
pi
foundation
doesn't
care
about
up
streaming
stuff,
so
that
turns
into
a
whole
other
set
of
messes
about
getting
the
raspberry
pi
4
to
work
correctly
in
the
four
series
in
general.
K
I
I
It
has
different
memory,
partitioning
all
those
sorts
of
things,
and
while
some
of
it
is
it
seems
to
be
kind
of
okay
with
the
raspberry
pi
4
ua5
firmware
like,
for
example,
we
there's
no
way
for
anything
but
raspberry
pi
os
to
use
the
full
eight
gigs
of
ram
with
the
uefi
firmware,
it's
relatively
straightforward,
to
get
everything
to
use
full
eight
gigs
of
ram
on
64-bit.
I
Yes,
it
only
works
on
32-bit.
Don't
ask
me:
I
have
no
idea
why
that
that
that
restriction
exists.
That
way,
it
makes
no
sense.
A
So
folks
I
just
want,
I
just
want
to
recognize
that
it
is
the
top
of
the
hour,
and
this
is
we
do
end
normally
and
I'm
sure
everybody's
got
a
stacked,
email
or
whatever
to
do
that.
So
I'm
I'm
happy
to
let
it
jeremy.
If
you
want
to
drive
a
conversation
about
this,
we
can
also
do
like
we
did
with
the
vsphere
triage
last
month.
A
So
that
would
be
make
me
happy,
and
I
know
amy
merrick
is
on
the
call
and
she's
being
quiet,
so
happy
2021
and
I
was
going
to
ask
her
to
give
me
a
hand,
reviewing
the
documentation
and
the
contribution
you
know,
contributor
ladder
stuff,
that's
on
our
in
the
okd
site,
so
that
we're
a
little
bit
better
adhering
to
best
practices
and
stuff
like
that.
I
think
we
can
use
that
and
I
know
amy.
A
That's
something
you've
done
very
nicely
for
a
number
of
other
communities,
so
I'll,
try
and
hit
you
up
in
slack
or
somewhere.
Just
hit
me
up
and
we'll
get
that
just
just
to
take.
Maybe
do
an
audit,
because,
from
my
perspective,
we've
got
stuff
on
okd.io
we've
got
a
website,
that's
separate
from
the
github.
We've
got
the
github
documentation.
A
We've
got
that
so
just
really
kind
of
one
of
my
goals
for
2021
is
to
get
our
our
documentation
up
to
snuff
our
cookbook
working
effectively,
and
it
may
mean
quite
a
big
thing
and
I
was
hoping
I
could
get
amy
and
josh
berkus
who's
also
from
the
ospo
group,
to
take
a
look
at
that
as
an
initiative
for
2021.
A
A
And
people
will
start
dropping
off
and
I
will
we'll
we'll
keep
this
on
the
menu
for
the
two
weeks
from
now
jeremy.
If
you
want
to
come
back
with
whatever
thoughts
you
have
and
then,
if
we
need
to
set
up
the
alternate
week
to
do
stuff
on
the
raspberry
pi
arm
stuff,
I'm
sure
there
will
be
people
who
will
join
you
in
this
endeavor,
including
myself.
A
So
that
would
be
great
and
if
there's
anyone
else
on
the
call
whose
agenda-
and
we
had
folks
say
from
the
the
github
actions
team
that
they
were
going
to
come
and
from
one
other
group
from
the
power
folks
we're
going
to
talk
about
something
and
that
I
don't
see
any
of
them.
I
didn't
see
any
of
them.
A
So
next
I
know
you
keep
coming
and
I
didn't
and
didn't
see
you
on
in
the
chat.
A
So
we'll
next
time,
we'll
also
give
you
some
air
time.
If
you
want
to
talk
about
the
ppc
64
le
stuff,
because
that
might
help
spur
that
as
well.
So.
L
Yeah-
and
I
mean
we
can
frame
it
also
as
a
alt-arch
in
general
kind
of
thing,
so
maybe
some
of
this
arm
stuff
can
also
be
helpful
there
as
well
yeah.
A
So
I
think
that
that
would
be
great
and
maybe
that
maybe
that's
just
an
alt
arc
working
sub
working
group
set
of
conversations
too
because
for
me,
2021
is
okd
everywhere.
A
So,
let's
see
if
we
can
make
that
happen
and
get
the
the
okd
operators
going
and
just
drive
adoption,
I
wanted
to
give
a
shout
out
quickly
to
jamie
thank
you
for
the
faq
updates
and
a
reminder
for
folks
that
we
do
and
I'll
send
the
date
a
timeline
and
session.
We
have
a
slot
at
dev
comp
in
february
to
do
birds
of
the
feather,
so
I
will
send
that
timeout
and
then
we'll
figure
out
how
to
run
that
that
group
meeting
too
once
I
have
that
time.
A
But
that's
what
I
have
for
today
and
I
just
wanted
to
wish
everybody
a
happy
and
healthy
2021,
and
thank
you
for
your
participation.
It
really
makes
this
whole
thing.
Wonderful
and
I'm
just
really
thrilled
to
have
all
of
you
here.
So
thanks
and
have
a
great
week
and
we'll
see
you
in
two
weeks
time.