►
From YouTube: Kubernetes SIG CLI 20180815
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
There
are
two
important
dates
coming
up
shortly.
One
is
August
28,
which
is
code
slush,
which
means
everything
that
you
want
to
have
in
granny's.
1.12
has
to
be
labeled
and
mark
and
approved
for
112,
my
soul
by
that
Dave
and
a
week
later,
on,
September
4th.
There
is
a
code
freeze,
which
means
by
that
time
all
the
work
has
to
be
completed.
A
So
basically,
the
next
meeting,
we'll
be
having
will
be
already
a
post
code
slush.
That's
why
I'm
mentioning
both
of
these
dates?
Okay,
a
quick
update
from
the
test
scripts.
Looking
at
our
testing
playbook
the
person
that
was
looking
after
our
tests
was
Sean
Sean.
Can
you
give
us
a
quick
update?
Were
there
any
problems,
issues
with
March
Q
and
the
60
like
related.
B
Tests,
so
it
actually
was
surprisingly
uneventful
until
last
night
at
8
p.m.
the
skew
tests
started
flaking
dramatically,
I'm
still
in
the
process
of
trying
to
run
that
one
down.
But
if
you
look
at
all
the
other
tests,
they've
they're,
green
and
they've
all
been
green.
The
vast
majority
of
the
time
for
this
it
felt
like
a
like
weave,
unlike
previous
iterations,
this
felt
very
smooth
and
not
many
events.
I
haven't
updated
the
the
test
coverage
on
the
spreadsheet,
yet.
A
B
A
Feel
free
to
add
yourself
to
this
document.
I've
noticed
that
one
is
adding
it
I,
just
added
himself,
the
next
person,
if
there's
no
space,
feel
free
to
add
new
document
with
its
every
two
weeks.
In
short,
the
role
is
to
look
after
the
queue
and
the
test
script
and
ensure
that
all
the
sexy
like
tests
are
green.
If
there
are
some
problems,
you
either
try
to
solve
it
or
your
pain
person
that
are
responsible
for
at
the
area
and
ensure
that
these
are
handled
in
a
timely
manner.
A
So
I
encourage
everyone
who
has
not
volunteered
yet
to
do
just
that.
Okay,
with
that
I
think
we
can
jump
in
to
our
main
topics
and
the
first
first
one
is
new.
Plugin,
mechanist
and
Wan
will
tell
us
a
little
bit
about
the
cap
that
was
announced
two
weeks
ago
on
on
cube
dev
and
the
60
line
mailing
lists.
So
let's
give
us
go
on
go
ahead
and
give
us
a
a
quick
overview
of
GE
of
the
proposal,
and
then
we
can
discuss
this.
C
Later
on
sure,
so
the
proposal
basically
highlights
a
get
style,
plug-in
mechanism.
This
is
merely
an
update
to
the
existing
plug-in
mechanism
and
not
something
we
plan
on
making
beta
right
away.
So
the
main
gist
of
this
is
basically
addressing
all
of
the
limitations
that
the
previous
plug-in
mechanism
had.
C
You
know
more,
so
the
ability
for
a
plug-in
to
receive
an
untouched
environment
parameters,
flags
anything
passed
by
the
user,
so
that
was
a
person
foremost
priority
agreement
when
making
this
design.
The
other
is
to
basically
make
it
easy
to
for
users
to
install
plugins,
so
it
could
be
a
deterrent
for
users
if,
if
installing
a
plug-in
or
even
making
a
plug-in,
is
somewhat
difficult.
C
Aside
from
that,
we
have
a
few
non
goals
associated
with
us,
so
this
is
not
meant
to
manage
plugins
in
any
way.
There's
a
separate
cap
before
that.
This
is
also
not
meant
to
provide
updates,
plugins
or
anything
of
this
work.
This
is
simply,
you
know,
as
bare-bones
as
it
gets.
We
just
want
a
stable
foundation
to
stand
plugins
on
top
of,
and
you
know
basically
accommodate
any
further
features
that
need
to
be
music
along
with
this
proposal.
C
We're
basically,
including
you,
know
a
small
way
of
for
users
to
detect
any
valley
plugins
in
your
path,
so
the
old
plug-in,
come
sub-command
per
cube.
Control
has
been
repurposed
for
that
matter,
for
the
time
being
and
yeah.
Hopefully,
the
the
the
goals
in
the
use
case
here
are
pretty
self-explanatory
and
will
convince
you
as
to
why
we
need
something
like
this.
I
can
take
any
questions.
If
anybody
has
any
questions
at
this
time,.
B
C
Yes,
sir,
hopefully
the
implementation
PR
gives
or
sheds
a
bit
more
light
as
to
the
intended
purpose
behind
the
cab.
There
is
a
walk
through
a
small
walkthrough
in
the
description
of
this
SBR,
which
I'm
hoping
users
or
viewers
will
try
another
own
leisure
and
pretty
much
experience
for
themselves.
What
would
the
new
mechanism
gonna
be,
like
all
of
the
old
code
paths,
have
been
removed
for
the
old
plugin
mechanism
with
this
VR.
C
Also,
something
of
note
that
this
BR
brings
is
that
plugins
will
no
longer
be
mean
spaced
to
the
Q
control
plug-in
sub-command,
but
rather
any
plugins
you
make
will
basically
act
as
first-class
citizens
right.
B
C
A
I,
don't
remember
where
we
keep
the
sample
controller
example,
which
is
there
for
showing
people
how
to
write
a
sample
controller,
but
I
won't.
Imagine
us
having
something
similar
called
sample
plugin,
and
that
will
happen
right
after
we
have
the
plugin
mechanism
and
secondly,
in
the
CLI
runtime
library,
which
will
provide
the
foundation
for
building
cube
CD
like
commands
and
and
I
with
that,
I'm
hoping
that
the
sample
plugin
will
will
show
people
how
to
both
implement
plugin
and,
at
the
same
time,
reuse
the
functionality
that
we
also
use
within
the
cube
CTL
itself.
A
B
A
A
Okay,
hearing
none
Thanks,
so
we
can
focus
on
this
Uli
run
thing,
and
that
will
be
me
so,
like
we
said
some
time
ago,
writing
plugins
is
one
thing.
What
we
would
like
to
see
is
people
reusing
the
functionality
that
we
already
have
and
providing
plug-in
outers
with
library
that
will
enable
them
to
write
QCD
like
behaving
plug-ins
or
commands
and
for
that
and
within
the
111
release
with
spent
a
decent
amount
of
time
extracting
the
main
functionalities
into
a
package
that
is
currently
under
package
keeps
EDL
generics,
UI
options.
This
is
to
start
with.
A
There
will
be
more
things
being
extracted
from
the
core
cube
CDL
into
this
library,
but
it
will
definitely
be.
It
will
take
us
some
time,
so
hopefully
we'll
be
expanding
things
library,
but
we
will
what
we
would
like
to
start
with,
and
we're
hoping
to
start
with
this
within
112
still
is
to
extract
the
generic
CLI
options
to
start
with,
and
hopefully
that
will
be
published
similarly
to
how
clang
go.
A
Api
machinery
and
other
staging
repos
are
currently
done
so
hopefully,
within
the
next
two
weeks,
we'll
be
able
to
to
tackle
this
problem
and
and
have
that
library
extracted.
Once
that
happens,
the
sample
the
sample
plug-in
should
come
to
fruition
as
well.
Are
there
any
questions
concerns
for
this
one.
C
You
know
stick
to
go
so
the
plugin
mechanism
will
be
language
agnostic.
All
you
need
is
an
executable
I
guess.
The
best
way
to
put
it
is
we're,
swaying
the
decision
of
potential
pluggin
authors.
You
know
to
write
their
plugins
and
go
and
and
if
they
do,
then
you
know
they'll
get
the
same
helpers
from
the
same.
C
You
know,
utilities
and
libraries
of
reusing
computable
form
commands,
and
you
know
as
a
side
benefit
for
us
that
will
pretty
much
ensure
that
any
plugins
that
are
created
with
this
with
this
set
of
tools
adhere
to
common
CLI
practices
and
do
control,
and
but
the
plugins
that
come
out
of
it
are
or
feel
native
to
the
user.
I.
B
A
Api,
so
definitely
there
are.
There
is
a
dependency
against
the
cube.
Api
I,
don't
remember
whether
we
have
any
dependencies
against
client
go
but
I'm,
not
saying
that
we
want
in
the
long
term,
because
eventually
we
would
like
to
have
some
kind
of
a
functionality
for
accessing
clients.
I'm,
not
a
hundred
percent
sure
that
might
change
so
I'm.
Not
that
part
is,
is
it's
pretty
much
fluid?
A
What
type
of
function
allows
these
we
are
repeating
over
and
over
again
and
might
be
just
of
use
for
other
plugin
others
and
we'll
be
extracting
this
functionality
into
into
that
library,
so
that,
at
the
end
of
the
day,
users
should
not
ever
need
to
do
vendor
cheap
CTL
when
it
eventually
reaches
its
owner
Apple,
nor
any
part
of
kubernetes
for
the
basic
functionality
I'm.
Not
talking
about
some
advanced
use
cases
where
I
don't
know,
I
can't
imagine
people
doing
some
crazy
stuff,
but
that's
I'm
trying
to
let
the
thing
about
those.
At
this
moment.
A
A
Run
time
for
controllers,
which
is
called
controller,
run
time
and
controller
tools
we
decided
I
will
we'll
just
go
with
CLI
run
time
as
the
the
basic
building
blocks
for
any
type
of
CLI
commands
that
wants
to
follow,
keeps
ETL
patterns
and
I'm,
not
saying
that
this
will
be
only
for
keeps
util
plugins
itself,
but
I
can
imagine
other
tools,
reusing
this
functionality
for
creating
some
higher-level
CL
eyes
for
interacting
with
queries.
Api.
B
A
D
I
I
mean,
as
a
as
an
author,
really
kind
of
playing
playing
devil's
advocate
here,
but
like
as
an
author
of
a
CLI
that
mimics
they
keep
Goodell
in
a
way
he
can
scuttle
I'm,
not
entirely
sure
what
I
could
reuse
right
from
the
from
Cupid.
All.Experiment
I
just
have
very
similar
command
structure,
but
I'm
moving
tied
to
sure
what
would
be
so
reusable
from
from
Keith
puddles
maybe
brings
his
package
I'm,
not
entirely
sure
about
much
else.
Could.
A
Uh-Huh
the
question
was:
the
question
was
whether
what
type
of
functionality
are
we
hoping
to
provide
with
the
generates
a
lie
option,
so
our
CLI
runtime
that
other
tools
might
want
to
reuse
within
their
own
code.
So
we
initially
started
with
printing
since
printing
is
basically
reused
in
every
single
command.
A
With
that,
we
provided
a
printers
package
which
embed
all
this
functionality
and
and
provide
a
unified
way
of
printing
objects
across
all
the
QCD
commands
and
I'm,
hoping
that
all
the
other
tools
or
plugins
will
be
able
to
reuse
that
same
functionality
for
printing
the
objects.
I
think
that
printing
is
probably
the
most
the
most
common
functionality,
either
for
a
dry
run
or
for
notifying
use
durable
type
faction
has
been,
has
been
performed.
C
Here
it's
also
from
printing
the
side.
You
could
call
it
a
side
effect
off
this
repo
would
also
be
providing
common
config
flag
setup.
So,
within
this
generic
scaley
options
package
of
the
moment,
we
also
have
all
of
the
functionality
that
both
control
command
use
that
basically
every
single
cue
for
command
use.
This
is
library
to
obtain
rest
clients,
configuration
bind,
config
flags
and
anything
else
is
needed
to
basically
parse
and
retrieve
and
make
sense
of
a
user
is
queue
config
file.
So
should
you
use
this?
C
A
D
Yeah,
just
you
know
mostly
curious
at
this
point,
but,
like
other
things
like
let's
say,
I'm
working
on
some
CLI
and
I,
don't
want
to
inherit
certain
flags
from
one
cube,
cut',
alright,
so
I'll
actually
want
to
avoid
using
cube
config
the
way
that
kernel
uses
it
and
you
they
mean
for
me
cube,
put
a
cube.
Config
means
something
else.
So,
specifically
es
got
all
we
need
to
before
we
even
get
to
talk
to
the
API.
D
We
need
to
go
and
talk
to
Amazon
API
and
create
a
bunch
of
these
options
there
and
wait
faster
and
then
to
the
right.
Our
cube
country
can
actually
like
you
confer
gargling.
Is
the
one
specified
a
path
where
to
right?
Keep
on
thick
to
so
just
an
example
right
and
so
I
wouldn't
want
to
have
the
same
behavior.
That
little
has
around
keep
configuring.
You
know,
tries
to
load.
C
Yeah,
so
pretty
much
when,
when
you
choose
to
use
this
this
repository,
the
way
you
would
use
certain
bits
and
pieces
is
by
instantiating
flag
and
struts.
So,
basically
for
any
bits
and
pieces,
you
want
to
use,
say
printers,
for
example,
you'd
be
instantiating,
it's
called
print
flags
just
struct,
and
then
what
that
allows
you
to
do
is
it
allows
you
to
bind
all
or
certain
flags
and
then
retrieve
a
working
printer
and
then
the
configuration
stuff
works
the
exact
same
way.
So
everything
follows
the
same
pattern
for
config
Flags.
C
A
C
There's
a
few
items
here:
that's
part
of
this
topic,
I'll
go
ahead
and
talk
about
watch
first,
so
with
regards
to
the
changes
that
have
occurred
in
queue
control,
yet
we
have
basically
enabled
server-side
printing
by
default
as
of
acute
control.
111.
What
this
means
is
that
s
of
111,
whenever
users
have
performed
to
people,
get
command.
They
have
been
using
a
response,
a
tabular
response
meant
for
humans
that
has
been
essentially
formatted
by
the
server.
C
So
the
just
to
give
a
quick
recap,
the
main
just
behind
server-side
printing
is
we
don't
want
to
control
to
have
knowledge
baked
in
of
every
single
type
it
supports
where
that
the
server
supports,
because
you
know
this
basically
tends
to
break
down.
When
we
talk
to
new
servers,
it
tends
to
break
down
when
we
deal
with.
You
know:
customers,
definitions
and
custom
resources,
and
it
just
it.
It
tends
to
be
unmaintainable
in
the
long
term.
So
what
server
set
printing
Hasaan
is?
C
It
basically
allows
the
server
with
its
knowledge
of
all
the
types
it
supports
to
tell.
The
client
here
is,
what's
worth
printing
to
a
human,
about
this
particular
resource
that
you're
asking
about.
So
as
part
of
that
update,
we
have
certain
pieces
that
still
need
to
be
addressed.
A
few
of
those
are,
you
know,
watching
resources
we
get
as
well
as
describing
resources
sorting
is
also
in
there
and
what
specifically
needs
to
be
addressed
about
these
is
that
currently
we
don't
support
service
at
printing
with
the
good
thoughts.
C
As
far
as
this
crowd
goes,
we
have
a
few
options
here.
The
most
straightforward
way
to
handle
described
is
to
just
literally
switch
every
single
handler
we
have
for
describe
to
deal
with
external
types.
So
currently
describers
live
in
our
internal
printing
package
and
they
only
take
internal
versions
of
resources.
So
a
stripper
wait
for
now
simple
solution
could
just
be
to
copy
paste.
Those
and
just
you
know,
have
the
healthy
new
copies
deal
entirely
with
the
external
objects,
and
just
you
switch
to
using
bits.
C
A
more
long-term
solution
for
this
drive
ideally
would
be
to
have
the
server
do
the
same
thing
not
forget
and
basically
have
the
server
dictate.
What
the
description
of
an
object
looks
like
there's
a
few
issues
that
you
know
we
can
immediately
detect
with
this
idea.
They
need
to
be
addressed
and
those
are
mainly
when
you
describe
an
object
such
as
a
pod.
For
example.
Part
of
the
pause
description
today
includes
events.
C
You
know
for
an
in
space.
They
also
include
maybe
events,
but
they
also
include
you
know
basically
limits
and
protests.
So
how
should
those
be
addressed?
Should
the
server
present
a
description
of
all
this
to
the
client?
Should
the
server
say?
Oh
I,
don't
know
if
the
user
is
allowed
to
view
quotas,
for
example,
so
you'll
just
have
to
make
that
request
again
asking
for
that
particular
resource
and
I'll
tell
you
yes
or
no,
whether
it
be,
you
cannot
access
it.
C
Essentially,
there's
potential
for
leaking
information.
The
user
can't
see
if
the
server
presents
all
the
information
at
once
and
then,
if
we
try
to
essentially
address
the
problem
by
just
having
the
server
include
references
to
other
resources
that
the
claim
can
request
a
second
or
third
time.
We
risk
over
complicating
the
client-side
mechanism
for
putting
together
so
I
think
it's
good
to
at
least
begin
discussion
on
these
things.
B
C
A
Every
ever
get
request
that
is
requesting
a
server-side
printing
information
receives
a
table
and
the
table
contains
the
columns
that
are
to
be
printed
and
then
the
following
rows
contain
the
actual
data
to
be
printed,
as
is
without
any
further
formatting.
If
any
formatting
is
required,
which
should
be
done
on
the
server
and
as
an
aside
from
freeing
keeps
you
deal
from
the
knowledge
of
the
internal
types.
This
also
allows
us
to
have
a
unified
way
of
printing
resources
across
all
the
clients.
A
A
This
is
how
we
currently
do
print
CRT
resources
so
see.
Are
the
authors
within
the
CR,
the
definition
they
embed
information,
which
columns
should
be
printed
for
the
service
I
printing,
aside
from
the
name
which
is
which
is
there
by
default?
If
you
don't
provide
the
columns,
descriptions
and
the
data,
then
by
default
we
always
print
name
and
creation
timestamp,
if
you
provide
the
additional
columns.
I
can't
remember
the
exact
field
name
currently
on
top
of
my
head,
but
aside
from
name,
we
will
print
the
additional
columns.
A
So
if
you
have
some
my
Frankie
field
or
something
that
you
just
need
to
map
the
give
the
name
of
the
field
that
should
be
presented
as
the
server-side
printing
and
the
Jason
path
were,
which
part
of
your
CRT
object.
This
data
should
be
coming
from,
and
this
is
how
we
currently
saw
the
service,
the
printing
of
the
series-
and
it
works
very
well.
A
A
A
Okay,
let's,
let's
do
that
in
that
case,
I
think
yeah.
These
two
topics
are
the
most
important
and
we
can
always
talk
about
sorting
and
in
the
next
in
the
next
meeting.
Actually
I
want
I
want
to
also
wanted
to
touch
base
on
on
the
charger
as
well
to
give
a
quick
discussion,
but
we
can
do
that
by
the
afterwards
okay.
So,
let's,
let's
do
the
cube,
CTO
extraction.
First.
B
Yeah,
so
this
I
don't
have
much
to
add
actually
I'm
trying
to
come
up
with
a
list
of
what
I
imagine
all
of
the
dependencies
that
we
need
to
be
snipped
before
well,
just
for
anybody
who's
not
familiar
with
this
effort
for
them.
For
quite
a
long
time,
we've
been
trying
to
get
our
coop
cuddle
code
base
out
of
kubernetes
core
into
its
own
repo
there's.
B
You
know
various
reasons
for
that,
along
the
lines
of
velocity
and
and
and
etc,
and
and
so
we
right
now,
I'm
I've
just
recently
started
digging
into
trying
to
figure
out
just
what
it.
What
is
it?
That's,
keeping
us
from
from
moving
this
from
coop
cuddle
out
of
core
what
dependencies
are
there
and
once
we
pull
it
out
of
core,
we
can't
vendor
anything
in
from
kubernetes
kubernetes,
so
we'll
have
to
any
of
those
any
of
the
places
where
we
depend
upon
the
core.
B
B
A
So,
to
add
a
little
bit
more
color
to
what
what
Shawn
just
said,
all
the
work
that
we've
been
doing
for
the
past
couple
of
releases,
which
includes
you
probably
noticed
that
we
are
working
hard
on
externalizing,
the
all
of
the
cubes
easy
of
commands,
which
basically
means
that
every
single
cube
CTO
commands
if
it's
using
internal
clients
set
or
basically
the
clients
that
are
not
part
of
a
particular
assertion,
but
rather
the
internals.
This
type
of
a
changes
is
what
we
are
currently
doing.
A
So
all
of
the
commands
has
to,
as
Shawn
mentioned,
work
with
the
external
version
of
their
resources.
That's
one
of
under
and
out
of
the
two
biggest
offenders
that
are
using
the
internals
is
actually
the
GAT
command
and
the
scribe
command
the
gate
command.
One
of
the
reasons
that
we
went
with
the
server-side
printing
is
to
get
rid
of
the
problem
of
cube
CTL
having
to
know
how
the
resources
look
like,
etc,
etc,
and
as
a
side
effect,
we
got
rid
of
handlink
with
the
internal
resources,
of
course,
for
backwards
compatibility.
A
A
That's
why
we're
also
bringing
the
topic
of
describe,
because
this
crap
currently
relies
on
the
internal
version
of
the
resources,
and
there
are
currently
discussions
whether
we
might
be
duplicating
the
code
for
describe
so
that
it
works
with
external
versions
and
the
internals
will
leave
with
the
server
to
speed
up
on
all
the
extraction
that
not
shown
mentioned
a
minute
ago.
But
these
are
the
biggest
offenders
currently
there
yeah
their
internal
client
set
and
everywhere.
A
If
you
see
and
keep
CTL
in
your
and
you
have
some
time
and
you're
willing
to
fix
them,
we
are
more
than
happy
to
see
PRS
that
are
actually
transitioning
from
the
internal
clients.
That's
to
the
external.
It's
not
a
it's
not
super
hard,
and
if
you
look
through
several
paths,
PRS
against
our
cube,
CDO
commands,
it
should
be
pretty
easy
to
follow
the
trend.
B
Yes,
so
that
was
about
all
all
I
had
just
to
let
everybody
know
that
that
that's
ongoing
and
I'm
attempting
to
document
all
the
places
I
believe
need
to
be
changed.
I
put
a
few
PRS
out
to
actually
do
it
just
so
that
I
could
see
what
it
feels
like
in
in
real
life,
but
mostly
I
just
want
to
document
it
so
that
we
know
exactly
what
needs
to
be
done
before
we
can
finally
get
cuddle
into
a
staging
repo.
A
B
I'll
share
one
quick
update,
which
is
on
the
server
site,
apply
so
I've
I've
left
the
working
group
on
server
site
apply,
but
that
work
is
still
ongoing
and
I
had
claimed
I.
Think
in
two
previous
meetings
ago
that
we
were
very
close
to
an
alpha,
and
that
was
way
premature
to
be
honest,
there's
it's
still
not
alpha
and
it
still
won't
be
alpha,
probably
for
another
four
weeks
or
so
I
I,
it's
I
think
they're
gonna
try
to
get
alpha
for
112,
but
I.
B
Don't
think
anyone
is
very
confident
in
that
they've
been
working
a
lot
on
dry
run,
which
is
much
more
complicated
than
was
initially
thought,
because
everything
through
the
you
know
all
of
the
the
web
hooks
have
to
get
this
new
flag.
Everything
through
the
admission
chain
has
to
get
the
new
dry
run
flag,
but
they've
been
doing
a
lot
of
work
on
that
I'll
keep
everybody
up
to
date
when
I
think
something
more
substantial
it
happens
is
what
do
you
think
when
she
said?
Did
that
sound
right,
yeah,
okay,
okay,.
A
From
our
end,
the
plugins
were
discussed
at
the
beginning
of
the
meeting,
so
I
don't
think
we
need
to
update
on
this
topic.
On
the
other
note,
although
that
was
also
discussed,
we're
still
progressing
with
the
refactorings
to
the
external
client
set
with
all
of
the
cube
CTO
commands.
As
far
we
can
and
as
much
as
we
can
other
than
that,
the
current
work
is
on
improving
the
generic
July
options
functionality,
because
over
the
past
couple
weeks,
Quan
and
I
we've
been
struggling
with
the
current
implementation.
A
A
A
Yeah
yeah,
that
makes
sense.
Let's,
let's
look
at
this
question
on
the
Charter
as
as
well
on
the
next
one,
hopefully
by
then
we'll
we
should
be
able
to
have
the
PR
in
a
shape
for
for
merge
as
well.
I've
noticed
that
you
had
some
questions.
I
I
went
through
the
third
fer
earlier
today.
Sorry
for
for
the
delay,
I
thought
you'd
run
out
of
time
in
the
past
two
weeks,
and
so
hopefully
we
will
be
able
to
close
that
one
in
and
during
the
next.
B
You
know
the
standard
template
for
roles,
but
but
it
ends
up
being
that
you
know
this
is
much
smaller
and
much
more
tractable.
Although
you
know
the
like
I
said
they
want
us
to
focus
on
the.
What
is
the
scope
of
what
we're
we,
we
think
we're
in
charge
of
and
what
are
the
things
we
definitely
are
not
in
charge
of
like
API
machinery.