►
From YouTube: 20190206 kubeadm office hours
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
A
A
First
item
is
a
PSA
more
than
anything
else
is
that
there
is
a
critical
bug
that
exists
in
our
current
stand
up
for
H
a
control
planes
so
for
folks
we're
gonna
cap
up
its
FYI,
but
there
is
a
condition
that
exists
currently
where
you
can
basically
crash
an
STD
and
it
doesn't
recover
right
and
nothing
recovers.
The
API
servers
won't
reconnect.
A
Currently,
the
the
current
information
that
we
have
in
the
investigation
is
that
it's
somewhere
inside
the
SD
client
and
not
necessarily
inside
of
anything
Canadian
specific
and
our
deployment
configuration
but
I'm
not
done
too
deep
into
this
issue.
But
it's
it's
catastrophic
in
nature.
So
if
anyone
wants
to
dig
in
there,
I
think
that's
probably
a
worthwhile
cause
because
for
folks
doing
H
a
clustering,
that's
gonna
matter,
I.
B
C
B
A
D
Experience
that
lately
and
I
did
and
everything
like
I
think
it's
not
cute
cubase
him
issue.
Well,
I
haven't
had
time
to
dig
deeper
yeah,
there
was
connection
I've
used.
Api
is
the
communication
and
a
documentation
I
mean
over
which
it
was
locally
NICU,
but
still
issues
appeared
to
delete
everything.
Yeah.
D
A
E
E
Just
generating
it
config
I
run
into
a
few
problems,
but
I
wasn't
able
to
solve
last
night.
I
didn't
get
as
much
time
on
it
as
I
meant
to
and
how
there
are
some
limitations
of
NS
p.m.
that
I'd
like
to
discuss
with
some
people's
that
one
I
found
that
it
hasn't
actually
actively
been
developed
for,
like
a
couple
of
months
like
the
last
I
think
it
was
November
28th
and
so
like
I,
don't
know
that
might
be
a
deal
breaker
and
maybe
push
us
more
to
s
p.m.
E
A
E
Spm
was
started
like
it
had
a
ton
of
development
in
like
2013
2014,
but
it
actually
has
more
development
in
the
last
six
months
than
NFB
M
has
as
well,
so
it
still
seems
more
active,
even
though
it's
not
I
would
say
it's
more
of
a
manage
it
for
a
an
active
development.
But
it's
in
a
maintaining
cycle.
A
E
Right
and
so
I
think
that
SPM
is
probably
the
better
tool
to
run
in
a
container
it's
on.
It
uses
Ruby
and
isn't
because
nice,
if
we
wanted
to
like
embedded
in
our
code
like
we
couldn't,
but
it's
fully
featured
it's
a
little
bit
more
complicated
and
I
didn't
get
a
chance
to
actually
make
our
package
with
it.
That's
next
on
my
list,
but.
B
E
F
I
think
the
signing
stuff
we
shouldn't
care.
We
can
do
this
in
a
separate
step
afterwards,
even
for
rpms,
as
far
as
I
saw
for
DV
on
packages
anyway
and
kind
of
kinda
similar
as
Luba
me,
I
would
be
interested
if,
for
the
forty
and
fpm
stuff
like,
are
there
any
open
issues
or
any
open
PRS
like
just
probing
the
community?
If
there
is
something
missing
in
an
F
p.m.
E
G
G
A
Which
means
that
we
have
to
maintain
a
little
tool
exactly
or
we
can
just
use
what
we
have
like
the
current
probably
have.
Is
we
have
this
bifurcation
of
how
we
build
things
right
where
we
have
mirror
if
the
problem
is
fragmented
in
a
couple
different
parts,
one
is
that
want
to
make
changes
to
one
thing,
but
doesn't
actually
percolate
to
both
the
W
interview
packages.
That's
one
problem.
The
second
problem
is
that
it
doesn't
percolate
into
the
release.
Repo
right.
A
That's
we'll
talk
about
that
one
separately,
but
the
the
first
problem
that
we
wanted
to
address
is
we
wanted
to
use
a
unifying
tool.
Ideally
that
solved
our
problems
and
enabled
us
to
use
one
build,
build
file
that
we
can
manage
and
just
built
the
packages
we
need
it
and
an
investigation
of
NF
or
fpm
was
was
the
the
goal
here.
A
B
We
just
got
to
remember
to
install
Ruby
in
the
containers
yeah.
G
A
The
docker
file
would
be
underneath
the
build
directory
in
main
KK,
and
we
would
have
to
work
with
XT
or
Jeff
to
get
that
docker
file
pushed
and
updated
when
we
needed
it,
but
I
would
hope
that
we're
not
doing
anything
special
in
any
of
our
packages.
From
what
I've
seen
I
would
hope
that
a
simple,
yeah
mol
description
file
should
be
sufficient.
G
A
Basil
doesn't
really
do
packaging,
it
generates
a
spec
file
and
then
it
kicks
the
RPM
builder,
and
the
idea
was
that
we
would
slowly
build
this
up
on
the
side
and
then
tear
down
the
other
one
right.
So
that
way,
we'd
have
a
single
I
drew
a
long
picture
for
Marek.
When
we
started
this
conversation,
it's.
A
G
A
A
B
E
H
E
A
A
We
have
problems,
we
have
many
problems.
The
question
is
who's
going
to
do
it
and
where
who
owns
pieces
of
the
puzzle,
I
think
this
group
cares
a
lot
about
making
sure
that
KK
can
build
artifacts,
that
we
can
use
for
testing
and
for
automation
how
it
gets
released.
That's
kind
of
out
of
our
view,
like
we've,
we've
interjected
there,
but
we
don't
we've
done
it
on
an
ad-hoc
basis
and
we
don't
really
have
ownership
rights.
F
On
the
other
side,
how
generally
packages
are
gonna
be
published
and
and
eye
candy
in
the
place
where
those
both
worlds
come
together?
What
I
would
like
to
see,
if
maybe
I
don't
know
if
you
have
something
like
that,
but
I
would
like
to
see
how
your
thing
is
evolving
and
then
I
can
figure
out,
maybe
with
aligning
with
Marek
how
we
can
use
that
and
integrate
that
into
the
publishing
side
of
things.
So,
basically,
what
question
do
you
have
a
tracking
issue
or
something.
A
The
main
issue
that
we
have
that
you
referenced
in
your
original
spec
is
the
original
tracking
issue.
Yeah
I
think
what
we're
gonna
do
next
week
is,
after
after
American
and
II
have
had
a
little
bit
of
time
to
dig
a
little
bit
deeper
break
down
the
work
items
which
are
very
coarse-grained
into
a
more
fine-grained
set
in
that
tracking
issue.
I
wish
I
have
the
doc.
If
someone
else
wants
to
look
at
the
time
to
us
right
now
for
a
release
perspective
I
have
requirements
that
I
would
like
to
give
right
like
I.
A
Would
I
would
ideally
love
to
be
able
to
have
a
stable
of
testing,
and
they
will
call
it
nightly
to
set
up
channels
the
for
those
that
that
work
could
be
done
totally
independently.
Yes
and
I
think
that
type
of
work
would
help
to
facilitate
where
we
want
to
go
because
currently
like
no
one
can
actually
test
a
an
alpha
cut
of
any
release
right
from
the
external
world.
They
look
at.
We
don't
even
cut
it
yeah
exactly.
A
A
A
F
A
Yeah,
the
the
second
thing
outside
of
the
structure
having
stable,
devel
and
nightly,
or
testing
that
lee
would
be
the
refactoring
of
an
ago
to
consume
the
artifacts
from
kk
versus
trying
to
publish
them
out
of
the
release,
repository
right.
That
could
happen
also
in
parallel
and
a
separate
pace
and
not
merge
until
the
other
pieces.
Already,
you
could
even
test
that
with
the
current
packaging
that
exists
inside
of
KK
repo
right.
F
A
A
The
Ndebele
release
contains
the
debian
in
RPM
files
today
right
the
spec
files
and
whatever
every
what
the
debian
packaging
name
is
called,
but
it
contains
all
the
informations
there
right.
What
we
could
do
today
is
create
a
pull
request
or
get
a
progress
ready
to
make
the
transition
to
modify
antigo.
Instead
of
publishing,
out
of
this
repository
to
publish
the
release,
our
facts
from
the
cake-
hey,
Rico
right,
just
like
me
with
all
the
other
all
the
other
packages
early
other
containers,
sure.
G
G
That,
well
it's
been
a
long.
They
the
actual
changes
to
the
Debian
and
rpm
package,
packaging
files
that
are
in
this
repository,
don't
always
get
checked
back
in
to
this
repository.
In
fact,
they
frequently
don't
so
the
the
patch
or
the
the
branch
managers.
For
you
know,
111
112
113
have
some
private
repository
that
they
work
with
for
for
updating
the
spec
files
and
they
don't
generally
check
them
back
in
here.
Yeah.
A
We
need
to
find
a
what
you
to
find
you
can
solve
this
from,
but
I
don't
know
if
it's
going
to
happen
from
114
I
love
it
too
hip
to
be
fixed
by
114.
Are
there
if
we
can
point
people
in
cig
releases
general
direction
to
help
solve
this
problem?
Who
would
we
point
this
at
probably
me,
but
do
you
have
you
don't
have
Eccles
to
the
the
details
of
how
they
do
that
publishing
in
the
backend.
F
No
but
I
talked
to
the
Googlers,
who
do
it
and
I
want
to
I'm
in
contact
with
them
to
understand
what
they
actually
do
and
then
move
it
to
some
CN
CF
for
whatever
or
to
some
infrastructure,
where
we
all
have
access
or
a
subset
of
Defense's.
So.
A
G
What
we've
covered
is
like,
if
we
can
see
it
all
to
fruition,
it
would
be
excellent.
So
getting
the
separate
repository
set
up
getting
the
artifacts
published
from
the
kubernetes
proper
repository
once
those
artifacts
are
published,
having
Anago
consume
them
to
produce
a
release
doesn't
seem
like
all
that
much
work,
I
can't
I
can't
think
of
too
much
else
off
the
top
of
my
head
specifically
about
packaging
Tim.
You
and
I've
talked
separately
about
like
if
we
wanted
to
bring
our
own
source
code
for
kubernetes,
like
you
know
what
we
did.
G
It
kept
you
or
what
other
companies
may
want
to
do,
that
it's
very
difficult
to
use
the
current
scripts
and
tooling
to
you
know,
build
your
own
because
it
all
expects
that
it's
going
up
to
the
standard
GCS
buckets
for
kubernetes,
proper
kubernetes,
official
I,
don't
know
if
that's
something
that
I
mean
it's
certainly
not
a
sick
cluster
lifecycle
problem.
Specifically,
it's
definitely
a
release
problem
for
sure.
G
A
F
I
I
F
A
A
G
Well,
and
so
yes-
I
mean
I,
don't
know
what
our
intent
is,
but
the
current
build
process
is
the
the
binary
like
cube,
API,
a
cube,
API
server,
acute
controller
manager
and
so
on
are
published
to
the
GCS
buckets
in
their
official
release.
You
know
tag
versions,
the
code
that
currently
generates
the
RPMs
and
the
devs
downloads,
those
previously
built
artifacts
from
the
GCS
bucket
and
puts
them
in
our
PM's
and
Deb's.
G
J
I
was
raising
this
concern,
because
what
was
it
because
before
about
resigning
and
building
your
own
rpms,
it
would
only
solve
basically
all
of
the
problem.
If
you
want
to
build
your
own
rpms
using
different
source
code
or
different
compilation,
options
or
whatever
you
would
still
require
to
publish
those
binary
somewhere
else
and
then
track
them
and
then
have
them
through
n
FP
m
or
FP
m
integrated
in
the
final
rpm,
which
is
kind
of
the
easy
stage.
G
However,
that
happens
like
if,
if
I
build
the
binary
separately
and
then
the
RPM
building
is
just
take
the
artifacts
and
wrap
them
in
an
RPM
okay,
you
know
it's
not
exactly
the
nature
of
how
RPM
is
meant
to
build
things
where
it's
supposed
to
go
from
source,
but
if,
if
the
best
we
can
get
upstream
to
allow
us
to
bring
our
own
is
we
have
to
bring
our
own
binaries
and
then
we
get
to
share
NFP,
M
or
F
p.m.
yeah,
Mille
and
whatnot,
like
that's,
that's
better
than
nothing.
Okay,.
A
A
But
this
comes
up
every
single
release
cycle
we
become
enter
to
a
hellscape
of
training,
to
be
able
to
verify,
build
and
build
artifacts
and
make
sure
that
what
we've
been
testing
is
actually
what
we
are
releasing
right
and
we
need
to
get
this
problem
so
I
think
the
horse
is
officially
beaten
there.
So
can
probably
move
on
the
agenda.
K
Have
you
been
considering
using
like
native
tools
like
get
built
package,
get
bill
package
RPM
so
that
those
tools
work
like
the
keeping
packaging
method
data
in
this
special
branch
like
in
a
separate
branch
in
git,
and
they
just
be
used
out
of
sources,
so
they
they
are
well
well-known
and
widely
used
tools.
I
believe
was
the
name
of
that
tool
for
Debian
packaging.
It's
get
built
package,
I,
think,
and
there
is
a
fork
or
I,
don't
know
extension,
which
also
uses
the
same
approach
to
build
rpms
I.
G
A
A
Next
up
is
a
quick
pulse.
I
would
pass
gloomier
to
kind
of
give
a
brief
status
update
in
the
state
of
Windows.
For
those
who
aren't
aware
when
data
support
is
going
GA,
this
cycle,
but
we
as
in
the
Covidien
sub-project,
have
not
actually
had
test
apparatus
or
the
state
of
Windows
has
not
been
updated,
so
I
kind
of
wanted
to
get
a
brief
debrief
from
the
mirror.
What's
going
on
so.
B
I
joined
the
sig
windows
meeting
yesterday
and
we
mostly
because
the
testing
mechanic
they
want
to
use
for
going
g8,
because
testing
is
a
requirement
and
first
of
all
to
the
to
the
question
like
is
Windows
Server,
2008
19
going
to
be
use.
This
is
the
minimum
version
they
want
and
for
the
containers.
A
lot
of
stuff
is
going
on.
I
see
a
lot
of
changes
in
testing
front
and
KK
related
to
what
they.
I
B
Do
the
like,
for
example,
recently
they
added
the
Linux
only
label,
that's
for
skipping
tests
that
should
not
run
on
Windows
modes,
so
I
was
Tim.
I
was
confused
that
they
was,
they
were
using
cubed.
There
are
not
cubic,
except
that
Google
are
using
two
tests,
Windows
nodes
already
and
it
feels
like
with
Google,
were
kinda
hit
in
the
effort
of
testing
windows.
B
So
the
SIP
windows
folks
are
using
Asia
the
usual
Asia
of
deploying
cube
test.
That's
in
the
testing
for
people
and,
basically
the
report.
What
it
does
is
it
spawns
a
bunch
of
nodes
in
our
Asia
coaster
and
it
obtains
the
the
resulted
locks.
Basically,
you
cannot
monitor.
What's
going
on,
you
just
fetch
the
work
who
walks
out
of
there.
So
it's
like
Dasia
cosas
acts
like
a
dispatcher
for
the
logs.
It
says
I
think
this
is
the
first
instance
of
such
a
setup
in
testing
front,
but
they.
B
A
C
B
Only
by
Google
because
they
already
like
they
also
do
it,
but
instead
they
do
it
with
Cuba
on
GC
clusters,
and
so
the
signal
III.
The
signal
for
Asia
I
didn't
look
at
it,
but
the
the
signal
from
the
Google
people
is
mostly
green.
There
is
only
one
one
test
is
failing
in
the
job:
I
looked
at
its
DNS
related,
but
I'm
going
to
check
again
this
next
week
to
see
the
progress.
A
Yeah
I
guess
the
question
I
have
for
this
group
is
that
as
soon
as
Windows
gets
released,
I
guarantee
you
people
marked
as
GA
we
sit.
Cluster
lifecycle
in
comedian
in
particular,
will
be
asked.
How
do
I
stand
up
at
Windows
cluster
right?
Like
that's,
going
to
happen
on
order
0?
We
have
no
answer
for
that
and
we
have
no
test
signal.
B
For
that
yeah,
but
it's
our
fault
to
not
support
Windows,
because
we
integrated
a
bunch
of
assertions
related
to
the
couplet
configure
couplet
command
line,
folks
that
we,
like,
we
assume
secret
drivers.
This
is
not
something
that
exists
on
Windows
and
basically,
we
kind
of
deviated
from
the
multi-platform
support
that
cubm
is
supposed
to
have
so
next
I
go
I
and
I
spoke
with
Michael
and
Patrick.
On
about
this,
we
are
going
to
investigate
and
basically
invest
effort
into
get
comedian
back
on
track
to
support
Windows
right.
B
A
Can
also
have
tracking
issues
currently
if
we
can
open
tracking
issues
with
some
of
the
like
a
general
umbrella
issue
for
Windows
support,
and
then
you
know
a
federated
list
of
cross-referenced
issues
that
would
be
probably
sufficient.
So
when
people
are
inbound,
we
can
point
them
in
in
that
general
direction
and
then
start
targeting
that
for
planning
in
the
115
cycle.
B
Michael
Michael
basically
said
that
keep
IDM
used
to
work
on
Windows,
but
something
broke
it
and
the
reason
for
that
is
that
probably
after
I
joined
the
project,
or
maybe
before
that
somebody
implemented
something
that
simply
does
not
port
well
to
the
other
platform.
And
we
don't.
We
don't
have
windows
developers
for
kit
idea.
That's
the
other
yeah.
A
B
A
problem
with
the
whole
testing
situation
I
want
to
touch
also
on
the
heterogeneous
questions,
so
the
prowl-
the
browser
currently
does,
cannot
spawn
windows
thoughts.
That's
a
limitation!
So
that's
why
they
are
doing
it
in
Asia
and
I.
Don't
know
how
the
Google
people
are
doing
it,
but
pro-pro
itself,
maybe
maybe
it's
possible
actually,
but
we
cannot
use
the
ATM
such
windows
modes.
We
cannot
use
cube
ATM
on
them
because
we
don't
have
a
deploy.
We
basically
have
to
write
the
separate
the
boy
for
cutest,
especially
for
testing
windows
loads
with
cube
ATM.
A
A
B
Also
wanted
to
say
something
about
like
this
current
cycle
and
the
GA,
so
they
might
have
a
problem
with
testing
Linux
loads
and
windows
loads
at
the
same
time,
and
the
reason
for
that
is
I
think
it's
the
test
time
to
intestine
framework
in
KK.
It
has
a
flag
that
only
tests
one
OS
at
a
time
they
might
be
able
to
set
it
up.
But
do
you
think
this
is
going
to
be
a
broker
for
GA
heterogeneous.
A
I'd
have
to
look
it's
probably
not
germane
to
this
specific
group.
It's
more
of
a
test!
Automation,
thing!
Okay,
I
can
take
a
look
at
that.
If
you,
if
you
point
me
at
the
issue,
I
can
do
that
after
the
meeting.
Well.
B
A
B
B
So
Patrick,
who
is
the
German
developer?
Who
is
working
on
the
end-to-end
testing
framework?
He
basically
the
patch
that
he
sent
about
disabling
uncle
providers?
The
patch
is
fine,
but
this
thing
fur
is
so
tightly
coupled
with
everything
that
I
need
to
rewrite
parts
of
our
copper
87,
deploy
again
and
I'm
talking
with
Ben
and
Sandra
about
this
but
yeah
our
tests
are
it
and
some.
C
B
Yeah,
we
don't
with
kind,
we
don't
miss
any
packages,
that's
the
problem
and
it's
a
very
entangled
problem,
because,
first
of
all,
we
have
the
regular
branch
tests.
Then,
at
the
master,
the
112
113.
That,
though
those
tests
we
can
replace
with
kind
this
cycle
yeah
to
be
a
complete
replacement.
We
have
to
also
enable
some
jobs
for
the
packages.
Yes,
we
do.
On
the
other
hand,
we
also
have
the
skew
tests,
the
X&Y
and
also
we
have
the
upgrade
tests.
B
So
I
mean
Cosette.
Api
is
going
to
be
great
to
have
signal
from
it.
We
like
for
the
next
cycle.
We
plan
to
extend
kind
in
some
way.
Maybe
when
I
had
to
sit
for
it
too
I
don't
know
depends
on
how
politics
end
up
being
there,
but
we
we
do
need
a
separate,
maybe
for
upgrade
askew
tests
that
are
based
on
kind
and
overall
it's
slower.
It's
not
going
to
be
a
very
complicated
setup.
We
basically
SSH
it's
like
a.
F
B
B
A
H
Yeah
so
they're
these
two
commands
Covidien
in
it
Flags
in
it
coop
config
I,
don't
know
anyway,
they
generate
coop
configs
for
specific
users.
The
one
found
under
the
phases
on
the
end
of
the
interfaces
generates
an
admin
generates
a
couplet
or
whatever
has
a
bunch
of
specific
ones.
You
can
generate
the
other.
One
is
kuba
diem,
alpha
coop
config
user,
and
you
can
generate
arbitrary
user,
the
coop
config
for
an
arbitrary
user.
H
They
do
very
similar
things,
but
they
have
slightly
different
use
cases.
I'm
expected
there
are
a
few
other
commands
that
may
be
overlapping
as
well
in
their
responsibilities,
wondering
if
we
could
consider
condensing
these
until
one
there's
some
suggestions
on
this
issue
for
how
to
do
that,
which
kind
of
led
me
into
my
into
a
question
about
like
non
config
flag
deprecation
are
we
do
we
have
any
thoughts
on
deprecating
flags
that
were
not
config
flags,
so
like
this,
like
the
API
address
server
or
things
like
that,
that
might
be
better
super
config
file.
A
K
H
Yeah
I
just
didn't.
We
did
the
big
switch
to
config
everywhere.
Some
some
commands
didn't
yet
that
config
change
didn't
get
the
new
config
argument.
So
I
don't
know.
Yeah
I
was
wondering
if,
if
we
had
a
policy
around
what
we
were
planning
on
doing
with
existing
flags
in
commands
that
were
not
particularly
the
door
that
get
overridden
by
the
config
look
for
Razia.
L
You
know,
I
have
a
very
opinionated
idea
that
we
have
to
throw
away
the
command
that
generate
the
configure
for
the
for
the
users.
In
my
opinion,
it
overlaps
with
good
cattle,
coffee
and
I.
Think
that
increment
mean
we
should
stay
focused
on
the
on
the
unit
join
and
a
bad
workflow.
This
is
my
opinion
that
about
the
alpha
common.
A
L
I
H
L
D
A
A
Have
like
a
general,
you
know,
I
think
the
ship.
We
should
address
this
one
in
the
1:15
timeframe
for
some
of
this,
but
there
are.
There
are
broader
questions
about
like
how
we
do
command
line
overrides
through
configs
and
how
we
want
to
produce
those
artifacts,
given
that
there
are
other
tools
nowadays
like
customize,
which
could
potentially
provide
an
exit
strategy
for
us
to
do
that
sort
of
override
customization
and
the
community
are
kind
of
rallying
around.
A
B
B
A
L
Sounds
good.
My
opinion
is
that
this
is
not
only
a
coup.
Battening,
Tobin
and
Lucas
is
about
peace.
We
should
be
the
first
adopter
of
this
law
of
the
target
solution
and
don't
arrangement
the
wheel
about
bits,
legs
and
count
again,
I'm
I'm,
hoping
that
they
will
help
us
and-
and
we
forgot
to
customize
it
will
be
if
it's
something
that
she
adds
on
top.
So
it
is
not
replacing.
Config
is
not
a
personal
drag
in
my
opinion,
but
this
is
something
that
we've
another
extension
point
to.
Take
you
to
a
mean
and.
L
L
L
It
is
quickly
feasible,
but
if
we
want
to
do
these
to
make
the
music
follow
the
user
custom
to
customize
everything,
our
back
rules,
Cooper
proxy
and
whatever,
and
at
the
one
say
whatever
this
will
be.
A
big
error
factor
of
cubed
means
because
we
have
to
introduce
a
clean
spark
separation
between
when
we
create
Yama
and
when
we
apply
Yama
yep.
A
Agree
I
mean
I
purposely
when
I
open.
That
issue
put
it
on
next
I
did
not.
I
did
not
try
to
tackle
it
for
for
this
cycle,
because
I
knew
that
the
implications
would
be
far-reaching,
but
I
do
think
from
a
consumer
perspective.
We
we
always
get
asked
and
we
always
have
been
asked.
How
do
I
modify?
How
do
I
plug
through
a
some
baroque
knob
that
I
care
about
a
lot,
and
the
answer
is
usually
been
like
you
know?
A
L
A
B
M
A
So
that
that's
kind
of
the
future
work
I
don't
want
to
write
home
too
much
on
that
one
one
thing
I
did
want
to
discuss
is
current
state
of
114
backlog.
There
is
a
bunch
of
Help
Wanted
issues.
Currently
I
did
modify
existing
ones
that
were
there
and
I'm
probably
go
through
a
separate
grooming
session
that,
before
the
end
of
this
week,
to
try
and
clean
up
some
of
the
items
we
know
we
won't
get
to
or
I
could
just
punt
on
them
and
wait.