►
From YouTube: Kubernetes SIG CLI 20161026
Description
First-ever meeting of the Kubernetes SIG-CLI Group. CLI Vision Statement from Brian Grant and proposed topics for upcoming work and meetings.
Minutes: https://docs.google.com/document/d/1r0YElcXt6G5mOWxwZiXgGu_X6he3F--wKwg-9UBc29I/edit
A
Sure
my
name
is
Fabiano
France
I
work
on
openshift
for
the
last
a
little
more
than
five
years
and
mostly
doing
CLI
stuff
in
since
the
first
version
of
open
shifts.
We
are
now
in
version
3,
which
is
based
on
Cuban
Eddie's,
so
I
do
boat,
web
UI
and
also
CLI
development
and
I'm
I'm
based
in
south
of
Brazil
I.
D
B
C
C
E
C
I'll
go
I'm
Brian
grant.
Maybe
some
of
you
know
me
I've,
been
on
the
project
since
more
or
less
the
beginning.
I
worked
on
Borg
and
Google
before
that.
I
created
concepts
in
communities
like
Todd's
and
labels
and
a
bunch
of
the
basic
ways
in
which
keep
control
works
were
inspired
by
some
of
Google's
internal
tools,
as
well
as
some
lessons
learned
from
those
internal
tools
so
happy
to
see
a
lot
of
people
interested
in
helping
out
with
the
CLI.
B
C
A
Sure
that's
going
to
be
a
real,
quick.
Well,
as
I
mentioned
to
you
Philip
for
me,
it's
the
first
cig
I'm,
actively
involved
with
so
I
noticed
that
some
of
the
other
things
they
they
formally
have
a
process
for
adding
demos
for
for
the
weekly
meetings.
So
things
like
demos,
some
things
I
noticed
they
do
for
most
status
updates
liking.
Scram,
you
know
status
some,
some
other
teams
doesn't
do
that,
and
some
some
teams
take
some
time
to
discuss
the
new
open
issues
in
their
weekly
meeting
so
anyway.
A
So
I
added
that
as
a
real,
quick
discussion
about
how
we
want
or
the
dynamic
of
our
Sigma
T's
to
work
so
do
do
we
really
want
to
have
things
like
demos
and
status
updates
are
much
more
like
you
know,
people
add
topics
of
the
calendar
and
we
go
over
them.
So
the
idea
is
to
have
this
meeting
for
the
sick
CLI
every
two
weeks.
So
it's
be
weekly,
not
weekly.
A
C
But
I
would
like
to
do
things
like
status
update.
You
know,
I
I
would
like
the
team
to
operate
as
an
extended
team
across
organizations
effectively.
I
think
signode
is
a
good
example
of
a
team
that
functions
that
way,
so
I
am
in
favor
of
some
time
for
status
updates
in
newly
opened
issues
to
help
us
prioritize.
A
Definitely
works
for
me,
so
what
I
have
in
mind
was
much
more
like
on
demand
stuff.
So
if
we
ever
have
any
topics
that
we
would
like
to
discuss,
people
can
edit
them
during
the
wake
you
know
before
the
meeting
and
we
can
go
over
them
and
first
status
update
yeah,
that's
something
we
do
here
in
openshift.
Also,
it
works
pretty
well
I!
Think
for
us
specifically,
we
probably
don't
need
to
be
a
really
formal
like
scram,
like
everyone
goes
over
the
status
update
yesterday
today.
A
C
Think,
especially
for
I
agree
about
this
from
thing.
I
think
you
know
if
there
are
features
and
keep
control
that
warrant
issues
in
the
features
repo,
for
example,
but
someone's
trying
to
get
to
the
release.
It's
helpful
to
keep
tabs
on
whether
those
are
on
track
or
not,
and
speaking
of
which
you
know
mini
almost
any
feature.
You
add,
the
system
impacts
cute
control
in
some
way,
so
we
I
think
CCL.
I
could
be
a
good
forum
for
people
from
other
six
to
come
to
discuss
changes
they
want
to
make
like
the
cluster
lifecycle.
C
A
Absolutely
you
know
hearing
openshift
we.
We
also
have
something
like
that.
You
know
we
have
a
CLI
team
here
too,
and
however
CLI
something
that
every
other
team
can
actually
work
on
right.
So
definitely
people
from
other
six
also
work
on
CL
I
stuff.
Eventually,
so
we
have
something
similar.
You
know
people
from
other
groups
join
our
meeting
to
discuss
about
design,
especially
when
they're
like
new
commands,
something
like
that
being
added
so
yeah.
That
sounds
good
to
me
and
other
than
that.
A
B
A
C
A
C
C
C
C
Yeah,
it's
like
that.
Rosa
talking
about
new
place
with
key
patrol
yeah,
the
you
know,
but
I
think,
since
a
lot
of
other
teams
do
work
on
keep
control
and
a
lot
of
community
members
find
keep
control
in
an
approachable
area
of
the
system
to
work
on
and
one
that
they
interact
was
quite
frequently,
you
know
having
some
statements
round.
What
we
can
keep
control
is
what
we
can
do,
what
his
conventions
are.
What
do
we
see
is
the
road
map
will
help
people
understand
how
they
should
contribute.
C
The
there
are,
there
is
a
conventions
document
or
cute
control.
It
is
mostly
targeted,
acute
control
developers.
We
probably
need
a
version
of
it
targeted
at
users
as
well
to
help
users
understand
how
to
use
cute
control
in
general,
but
the
developer
focus
one
I
think
they're
a
bunch
of
things
we
could
add
to
it.
So
when
people
admin
commands
or
change
plans,
they
understand
the
conventions
they
need
to
follow.
Things
like
which
commands
should
take
the
dash
dash
filename
arguments
and
how
should
they
behave?
You
know.
C
Cute
control
in
general
is
designed
to
foremost
operations
that
make
sense
on
multiple
resources,
for
those
operations
to
be
able
to
apply
to
multiple
resources
in
a
single
command
by
specifying
a
file
containing
multiple
resources
or
even
multiple
files
or
a
directory
or
even
recursively.
Traverse
directories
I'd
actually
like
to
extend
those
capabilities.
C
A
Yeah
I
just
wanted
to
add
something
related
to
conventions,
I'm
not
sure
if
everyone
is
aware,
but
recently
I
got
up,
you
are
merged.
That's
added
a
new
script
called
in
hack
called
very,
very
feisty
like
conventions,
so
it's
kind
of
a
a
framework
that
runs
on
make,
so
that-
and
it's
very
you
know
the
idea
behind
it-
is
to
have
small
scripts
that
verify.
A
If
your
CLI
commands
are
following
the
conventions
we
have
and
if
it
doesn't,
the
scripts
fails
and
actually
our
tests
failed,
meaning
that
people
writing
CLI
commands
are
now
must
actually
follow
the
conventions.
We
are
testing
in
those
scripts.
So
right
now
there
are
only
two
really
simple
checks
being
done
it
just
it's
just
checking
if
your
examples
and
command
the
command
examples
and
the
long
description
is
normalized,
but
anyway
the
framework
is
there
and
we
could
add
other.
You
know
checks
to
that.
B
A
C
C
Yeah
I
guess
some
it.
Some
of
the
cigs
have
a
you
know
if
they're
a
bunch
of
source
standing
issue
since
we're
just
starting,
we
want,
might
want
to
make
a
list
and
spread
them
over
several
meetings.
I
do
know
that
there
are
things
we
need
to
discuss
like
the
fishy
that
was
opened
about
you
know.
Do
we
have
one
command
line
tool
to
rule
them
all
or
to
command
line
tools
or
50
command
line
tools?
Look
long
as
in
each
command
line
tool.
Things
like
that,
there's
also
the
extensions
proposal.
C
C
C
Nor
do
I
want
to
I
mean
I
actually
want
these
things
in
separate,
repos
and
separate
github
works.
I
want
kind
of
an
ecosystem
of
tools
to
develop.
I
saw
you
know
that
happened
inside
of
Google
and
a
very
powerful
thing
is,
you
know,
I
think
certain
classes
of
users
understand
their
problems
better
than
we
do,
and
certainly
you
know
there
will
be
people
who
use
puppet
or
ansible
or
whatever
it
is,
who
also
build
terraform,
who
also
build
adapters
right,
so
people
are
going
to
be
using
multiple
tools.
C
So
if
you
design
the
tools
in
such
a
way
that
they
can
be
used
together,
I
think
users
would
benefit
from
that.
So
there
are
some
in
terms
of
the
sort
of
the
roadmap
and
the
vision
and
the
conventions.
There
are
some
things
that
we
discussed
for
a
long
time
that
we
should
make
sure
that
we're
all
on
the
same
page
about
a
long
term
directions
like
you
know,
multiple
and
our
operating
tools
is
one
put-putting
making
most
of
cute
controls.
Generic
functionality
available
in
a
reusable
library
is
another
right.
Now
people
do
do
it.
C
It's
a
pain
to
vendor
in
I.
Don't
think
the
code
can
be,
you
can
just
do
go
get
because
of
the
sprawling
dependencies,
and
there
are
some
annoyances
like
cute
control.
Business
logic.
Just
uses
takes
input
from
standard
input
and
output
to
standard
outputs.
So
you
sort
of
have
to
you
can't
just
like
pass
in
a
string
and
get
back
a
string
and
things
like
that.
It's
not
designed
to
be
used
as
a
library,
so
I
think
they're
a
bunch
of
things
in
that
and
also
really
complex,
commonly
used
functionality.
C
We
want
to
actually
push
all
the
way
to
the
server
so
moving
cute
control.
Rolling
update
to
pull
it
into
deployment
is
one
example
about
that.
Enables
deployment
to
be
rolling
updates
to
be
triggered
by
cice
by
you
eyes
by
all
kinds
of
scenarios
where
they
may
not
want
to
invoke
exactly
command
line
tool.
C
But
you
know
once
it's
clear
how
it
should
work
and
how
useful
it
is.
Then
some
of
this
stuff
will
probably
move
to
the
server
I
guess.
Another
long-standing
issue
is
the
well
long-ish
standing
issue
is
support
for
dynamically
registered
api's
and
for
third-party
resources.
You
know
how
to
deal
with
extensions.
C
You
know.
Open
shift
has
its
own
solution,
I,
guess
to
how
it
adds
support
for
its
own
resources,
but
as
we
make
communities
more
composable,
so
we
can
actually
continue
to
grow.
We
will
need
I,
think
a
more
principled
solution
to
this
and
I
think
there's
is
a
proposal
open
for
returning
get
and
describe
output
from
the
server
I
think
so
that
would
be
useful
to
talk
about
at
some
point
anyway.
C
C
One
thing
that
we're
working
on
right
now
for
1.5
is
making
cute
control,
apply,
work
and
for
people
I,
don't
know
if
everybody
understands
how
cute
control
applies
close
to
work,
but
basic
you
control
apply
is
a
declarative,
a
method
for
managing
Cooper
Nettie's
resources.
You
can
just
specify
the
resources
and
files
you
can
do,
Q
control
apply
and
the
idea
is
it
should
make
it
so
in
this
order
without
clobbering
other
state
that
wasn't
set
wasn't
configured
by
Q
control
apply.
C
C
C
C
So
I
think
there's
going
to
be
a
lot
of
work
to
actually
make
it
work
correctly,
but
once
it
does,
it's
going
to
be
worth
it
the
if
we
move
it
into
the
server
some
of
those
how
we
handle
some
of
those
might
change,
because
relying
on
the
struct
egg
isn't
nearly
as
bad.
If
there's
not
a
big
issue,
is
that
correct?
C
C
C
Yeah
so
as
part
of
the
vision
document,
I
think
Welling
out,
the
use
cases
would
be
useful.
You
know,
we've
been
talking
about
apply,
which,
as
I
said,
is
a
declarative
way
of
managing
resources
would
also
want
to
support
imperative
commands
slice.
Keep
control
set,
for
example,
which
is
really
convenient
for
developers
who
aren't
just
committing
all
their
configs
into
the
source,
control,
so
I
think
as
part
of
the
vision
capturing
the
the
main
usage
paradigms
that
we
plan
a
sport
thing.
C
C
C
C
C
Logical
groupings
of
commands
in
the
help
text-
all
right,
oh
yeah,
so
I
think
there
was
a
thread
we
had
on
this,
and
the
threat
was
terminated
with.
Let's
discuss
this
at
the
at
the
CLI
meeting,
which
we're
here
today,
so
I
thought
I'd
bring
it
up.
I
think
that
this
kind
of
goes
as
some
overlap
with
Brian
support
for
imperative
commands
and
what's
the
identity
of
coop
control
and
just
responsibilities
and
all
that
stuff,
and
it
probably
makes
sense
for
our
groupings
to
reflect
the
responsibilities
of
the
tool.
C
It
also
relates
to
you
one
of
your
next
bullet
items.
The
sub
commands
versus
top
little
commands.
Yes,
it
does
I
guess
so
those
two
items
I
can
I'll
put
them
next
to
each
other,
but
they
should.
I
guess
the
higher
point
is:
how
do
we
want
to
structure
the
coup
control
tool
both
for
part
of
its
discoverability?
C
I'll
copy,
let
me
copy
the
the
list
I
had
in
here.
I
think
maybe
it's
controversial,
but
I'd
ask.
Does
their
only
need
to
be
one
way
we
group
them
right
like
if
you
are
reading
a
book,
there's
a
table
of
contents
and
an
index
or
if
you
are
learning
about
some
system,
there's
neither
guide
and
a
reference
guide
right
side.
I
think
there
should
be
a
default
organization.
C
You
know
similar
to
the
top
down
NAB
of
the
doc
site,
maybe
which
is
sort
of
a
logical
organization,
but
we
may
also
need
some
other
end
of
organization
like
task-based
or
something
like
that.
You
know
if
the
division
is
imperative
and
declarative,
that's
not
going
to
be
like
almost
all
the
commands
are
going
to
be
imperative.
So
that's
not
a
useful
division.
In
this
sense,
there
is
like
pathological
in
the
squared
quicksort
fee
or
like
taking
one
thing
out.
C
Yeah
I
mean
I,
think
it
yes
I
think
it's
fine
to
have
multiple
groupings
for
different
contexts.
I
guess
I'd
say
the
the
trade-off.
There
is
to
the
extent
we
can
if
we
provide
the
users
with
a
consistent
view
of
the
system
when
they
switch
context,
things
will
be
more,
hopefully
more
familiar.
So
if
our
docs
group
commands
the
same
way
as
we
group
them
in
other
other
ways,
they
encounter
them
well,
yeah
ducks
are
generated
from
keep
control
help.
C
Also,
yes,
so
so
by
the
way,
I
think
you
control
help
is
a
big
area
that
needs
improvement.
So
that's
another
useful
topic
for
future
meetings
as
well
as
I
want
to
do
with
cute
control
help.
We
don't
have
to
derail
on
that
here,
but
they're,
a
bunch
of
issues
like
just
updating
it.
How
we
manage
the
examples,
do
me
generate
markdown
or
to
multiple
different
formats,
or
how
do
we?
How
do
we
do
that?
So
you
know
help
needs
a
lot
of
help.
Yeah
I'd
say
I
have
my
last
assignment
is
on
that
I.
C
But
I
guess
what
I
was
thinking
is
from
users
perspective
I,
maybe
they're
coming
to
the
command
and
I
want
to
set
stuff
through
flags,
so
I'm
doing
good
control
run,
I'm
doing
crates
your
it
doing,
delete
deployment
x
and
all
these
things
I
never
see
config
right
and
I'm
not
managing
anything
through
it.
They
can
fake
arm
and
then
there's
another
set
of
commands
that
does
include
like
create,
replace
delete
with
files
and
those
are
while
you
write,
those
are
imperative
commands.
They
are
managed
through
a
user
having
a
configuration
file.
C
B
C
Having
to
figure
out
config
stuff,
though
it's
like,
can
be
convenient
man's
and
crud
operations.
All
right,
however,
want
to
name
them
that
will
split.
I.
Also
think
you
know
you
have
other
lists
your
cluster
management,
yeah,
I,
cluster,
cluster
administration
or
cluster
manageable
operations,
I
think
separating
those
from
app
management.
C
Yeah
me
and
inspecting
also
makes
make
sense.
There
may
be
seen
as
it
makes
sense
to
put
into
multiple
categories.
So
I
get
is
a
crowd
clans
and
it
can
be
used
for
scripting
and
stuff,
but
it's
also
the
main
inspection
command
yeah
get
even
create
because
create.
We
have
sub
commands
that
are
not
config
based
and
then
we
have
create
that
takes
a
file
yeah.
C
Actually,
so
that's
enough
brings
up
another
future
topic,
which
is
we've
had
some
people
request,
declared
it
forms
of
the
convenience
communities
like
the
declarative,
form
of
cute
control,
run
or
keep
control.
Trade
secret
is
probably
what
the
biggest
single
is
blessed
for
a
convenient
for
a
declarative
form.
I.
Have
that
now
do
do
me
not
adding
additional
stuff
to
it.
I
mean
people
want
to
do
cute
control,
ply
and
have
that
also
do
great
secret
life.
If
their
underlying
credentials
file
it
gets
updated,
then
we'll
update
it
in
the
server.
C
Benefits,
maybe
it
is
the
error
handling
like
if
you
write
a
script
than
every
line
of
that
script,
you
have
to
be
pretty
careful
about
the
error
handling,
so
you
have
to
decide
you
want
to
keep
going
and
in
execute
the
subsequent
commands.
Or
do
you
want
to
stop
at
the
first
error
and
all
that
stuff?
That's
kind
of
annoying
one
advantage
of
cute
control
apply,
especially
with
the
just
pointing
it
at
a
directory
and
and
even
recursively
traversing
is
you
can
just
drop
another
file
in
that
directory?
C
C
Yeah,
okay,
I
think
that
the
the
change
I
was
suggesting
is
that
grouping
now
is
based
on
I
guess
the
complexity,
or
at
least
partially,
based
in
the
complexity
of
the
command
and
I'll.
Add
that
that
the
the
groupings
really
helped
actually
help
that
help
text,
and
this
is
pretty
close
to
what
the
existing
groupings
are
but
I
want.
It
collapsed.
It
just
reorganizes
a
couple
of
them.
So
there's
like
advanced
commands,
began
during
an
intermediate
commands.
C
You
have
listed
here
seem
like
a
reasonable
starting
point.
If
we
get
user
feedback
that
is
confusing
or
whatever
we
can
always
change,
it
again
sounds
kids
all
right.
Moving
on
to
the
next
thing,
sub
commands
vers
top
level
commands
I
had
a
us
forget
who
was
someone
came
to
the
other
day,
asking
how
to
add
commands
for
cluster
Federation?
Thank
you.
C
Baby
I
is
probably
McNichol,
yeah
and
I
think
the
question
I
had
for
him
was:
you
can
make
them
you
could
make
like
a
top-level
federation
command
and
ran
her
tongue
answer
that
you
could
or,
alternatively,
you
could
embed.
So
if,
like
I,
think
there
were
some
commands,
that
already
did
what
he
wanted.
I
forget
what
they
were,
but
it
was
something
like
join
I
think
join
was
one
of
them.
C
There
was
this
idea
that
there
might
already
be
a
joint
armed
command,
so,
alternatively,
you
can
make
subcommand
of
join
or
control
it
with
flags
against
join
right.
Ok,
so
my
general
opinion
about
subcommands
is:
if
there
are
a
bunch
of
the
cute
control
commands,
are
designed
to
apply
to
arbitrary
resources
like
create
fleet
label,
etc.
Those
definitely
should
not
be
under
subcommand.
C
And
especially,
if
they're
not
going
to
be
used
by
the
majority
of
keep
control
users
and
it
does
make
sense
for
those
to
be
grouped
under
self-command
I-
think
it's
a
discoverability
and
invincibility,
you
know
so
cute
control
rollout
was
kind
of
the
first
one
of
those
that
we
added.
You
know
they
all
just
relate
to
roll
outs.
Maybe
of
a
couple
of
resources
like
maybe
they'll
apply
to
deployment
and
demons
and
pen
set
sorry
I
staple
set,
but.
C
But
it's
sort
of
a
focused
activity
with
a
small
number
of
sources
is
something
this
generic
across
many
resources,
contrast
that
with
Q
control
set,
which
doesn't
apply
to
all
resources
but
could
eventually
apply
in
some
way
to
all
resources.
Maybe
not
the
same
fields
would
be
set
upon
by
all
within
all
resources,
but
certainly
at
least
the
ones
we
started
with
for
Pollock
set
image.
It
applies
to
anything
with
a
pot
or
pots
back
right
sort
of
to
pod.
C
It
applies
to
all
the
controllers
and
its
intended
to
be
generic
and
common,
and
we
plan
to
add
support
for
more
fields
to
my
cover,
other
other
things.
So
you
know
so
this
sort
of
generic
thing
should
be
top
level
non.
Generic
things
should
not
be
top
level
I
like
the
idea
of
either
having
some
kind
of
cluster
admin
subgroup
or
moving
those
even
to
another
command.
I
only
have
a
disagreement
with
jovita
about
what
cube
admin
is
supposed
to
do
like
Joe
is
a
big
fan
of
everything
in
one
binary
and
I.
Just
think.
C
So
we'll
have
to
hash
that
out
with
him,
I
don't
know
if
anybody
else
cares,
but
the
on
the
Federation
stuff
I,
don't
know
that
they
have
a
I
mean
honestly,
I
told
them.
What
they
should
do
is
just
go
to
separate
command
and
put
the
fans
there
and
once
Federation
is
more
fully
baked
in
whatever
we
can
kick
about
merging
the
tools,
but
they
didn't
want
to
do
that.
This
is
a
separate
command
line,
yeah
a
separate
likes,
cube,
fed
or
whatever
a
separate
command
line
tool.
C
You
know,
like
only
the
people
using
Federation
will
care
about.
It
is
noise
for
everybody
else,
it'll
be
it
would
be
easier
for
them
to
actually
develop
if
it
weren't
another
repo.
They
can
just
develop
it
independently.
Until
such
time
is
it
it's
all
fully
baked
and
more
people
are
using
it
in
whatever
yep
I'm.
That
good
I
think
if
we
solve
some
of
the
tool,
distribution
problems,
that'll
be
a
an
easier
sell.
C
Yeah
I
know
Clayton
is
of
the
opinion
that
distribution
is
solved
by
the
OS
distros,
but
that
is
no
longer
the
case,
especially
now
that
oh,
there
are
less
distros
with
no
package
managers
right.
So
I
think
if
you
for
anybody
who
hasn't
looked
at
the
D
cos
command
line
tool,
it's
kind
of
is
sting
is
where
to
look
for
comparison
and
they
have
their
own
plug-in
distribution
mechanism.
C
A
Here
I
know
that
I
think
it's
count.
Cloud
Foundry
also
CF
also
has
something
specific
for
plugins,
so
you
can
do
something
like
CF
install
plugin,
I,
don't
know
Jenkins,
something
like
that
and
it
actually
downloads
and
installs
the
HTTP
I
did
somewhere
in
the
invest
about
both
something
like
that
and
also
a
self
updater
command.
If
we
want
to
take
a
look
at
that,
I
probably
still
have
that
on
github.
Anyway,
there
are
some
subtle
solutions
for
things
like
that.
If,
at
some
point
we.
C
Dis
rose
up
to
date,
so,
even
if
we
were
able
to
get
up-to-date
builds
of
cute
control
and
the
other
tools
into
an
updated
package
packages
for
Debian
infer
rpms,
we
couldn't
count
on
people
getting
to
those
and
we
also
have
people
a
lot
of
people
use
cute
control
on
Mac,
I
know,
I
do
and
some
the
number
people
use
it
on
windows
and
more
will
use
it
on
windows.
Presumably
once
Pernetti
supports
windows
containers,
so
you
know
it's
that's
at
least
44
os's,
plus
raspberry,
PI's
and
other
things.
C
A
Definitely
if
we,
if
we
don't,
you
know,
do
something
like
a
self
of
dr.
something
like
that,
but
at
least
we
should
warn
users
that
they
are
using
a
rated
version
of
the
the
CLI
tool.
I
could,
of
course,
switch
that
something
off,
not
sure
if
that's
a
in
a
compiling
stage,
something
like
that,
so
that
users,
that,
for
example,
use
rpms
would
not
be
notified
and
would
just
get
the
new
versions
from
their
OS
updating
system.
A
C
So
that
reminds
me
of
two
long-standing
issues
that
we
should
try
to
fix.
What
is
we
should
actually
make
cute
control
work
with
virgin
skew
like
we
should
make
an
older
version
of
cute
control
able
to
work
with
newer
clusters
and
vice
versa,
if
you're,
just
using
the
subset
of
functionality
that
you
know
from
this
pin
existed
for
a
while.
There
shouldn't
be
a
reason
why
you
have
to
use
a
Newark,
you
control,
but
today
you
do
it.
C
Basically,
it
basically
doesn't
work
because
you
control
round-trips
objects
and
that
causes
it
to
drop
shields,
and
things
like
that,
so
you
can't
reliably
write
scripts,
that
you
read,
modify
write
without
an
up-to-date
keep
control
and
there
are
a
bunch
of
other
problems.
So
we
should
do
things
like
eliminate
all
the
round
trip
being
make
sure
it
doesn't
drop
any
fields
unintentionally,
make
all
the
version.