►
From YouTube: Kubernetes SIG CLI 20180425
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
Okay,
so
today
is
April
25th,
and
this
is
another
six
CLI
meeting.
My
name
is
machi
and
I'll
be
your
host
date,
a
quick
announcement
for
for,
what's
going
on,
we
started
officially
yesterday
111
feature
freeze,
which
means
all
the
features
that
are
planned
for
111
should
be
already
filled
in,
and
the
futures
repo
from
the
email
that
josh
set
out
two
days
ago.
He
will
be
publishing
the
the
list
of
the
future
items
by
shortly
as
a
Google
spreadsheet.
A
B
B
A
Those
of
us
that
are
heading
to
to
Copenhagen
does
anyone
else
have
any
other
announcements
that
I
would
like
to
bring
up.
A
B
B
I
would
try
it
this
particular
meeting
to
see
if
we
can
get
into
the
habit
of
looking
at
the
health
of
the
project
at
the
beginning
of
the
meeting,
and
so
how
to
look
at
the
test
grid.
Put
a
couple
links
in
currently
there's
a
lot
of
flakes
that
started
yesterday
around
4:00
p.m.
Pacific
time,
and
so
I'll
nominate
myself
to
dig
into
that
and
to
resolve
it.
A
Sure,
and
actually
that
that
the
nicely
goes
with
another
topic
that
I
want
to
bring
up.
So
during
the
last
session
we
had
two
weeks
ago.
First,
during
the
retrospective,
we
talked
about
focusing
on
flakes
and
then
men.
She
also
proposed
having
a
on-call
rotation
for
monitoring
flakes
and
especially
addressing
those
so
I
propose
that
we
talk
with
sick
apps,
because
apparently
they
were
also
discussing
this
topic.
So
I
reach
out
to
Matt
Farina
is
one
of
the
colleagues
for
cig
apps.
A
He
mentioned
that
they
were
discussing
this
topic,
but
nothing
actually
came
to
fruition
out
of
it.
So
then
she
can
you
tell
me
if
your
proposal
about
setting
up
the
on
call
that
you
sent
it
out
to
me
last
time.
Are
you
still
interested
in
setting
it
up
and
we
can
slowly
start
actually
implementing
the
the.
A
A
A
Maybe
some
some
basic
rules
to
start
with
to
get
it
working,
we'll
see
how
this
thing
is
working
during
the
111
closing
that
will
be
happening
in
the
in
the
next
month,
so
we'll
see
more
or
less
how
this
is
working
and
then
we
will
be
able
to
eventually
document
it
better
and
propose
the
the
same
tool
for
four
other
six
I.
Think.
A
Can
you
can
you
can
let's
start
with
the
one
that
you
that
you
mentioned
I,
think
I,
remember
and
I
was
asking
Mary
and
I
remember.
He
also
mentioned
me
the
same
tool
so
I'm
fine
with
that.
Please
leave
a
link.
I
don't
have
it
currently
handy.
Please
leave
a
link
to
that
to
the
project
and
the
agenda
so
that
it's
it's
visible
for
everyone
else.
A
What
we
went
with
ok
now,
we'll
have
to
talk
cool
awesome,
so
Sean,
going
back
to
the
test
grid
topic,
you're,
basically
proposing
that
we
set
up
some
kind
of
a
set
of
links
that
people
can
or
we
will
go
through
on
every
single
six-year
line
at
the
beginning
of
sixty
line
meetings
and
verify
the
current
state
of
the
queue
and
the
project.
That's
that's!
Basically
what
you
were
hoping
to
get
to
achieve
with
this
test.
Great
topic.
I
was.
B
Yeah
I
was
just
hoping
to
kind
of
get
the
ball
rolling
with
with
this
on
call,
as
you
know,
just
an
informal
here's.
What
the
test
grid
looks
like
I,
I'm,
not
sure
what
the
community
thinks
about.
You
know
how
to
organize
that,
but
I
thought
that
we'd
just
get
it
rolling.
If
that's,
ok
and
then
I
hate
myself
too,
if
you
guys
agree
just
to
dig
into
these
issues
and
in
the
future,
whoever
is
you
know
on
call.
A
A
A
Okay
hearing
none
so
so
I
went
through
over
the
past
couple
weeks,
Burcu
and
and
I.
We
had
a
lot
of.
We
spent
a
lot
of
time
going
through
all
the
cube
CTL
commands,
while
implementing
the
printer
flags
and
trying
to
unify
the
current
usage
of
flags,
and
what
struck
me
several
times
is
that
we
are
testing
different
parts
of
code
and
very
non
unified
way
up
to
a
point
that
we
are
one
example
that
struck
me.
The
most
was
that
we
were
using
fake
printer
and
the
output
of
the
command
was
just
printed.
A
That
object,
X
was
created
was
what
the
test
was
checking.
It
did
not
check
whether
the
correctness
of
the
object
created
that
was
in
the
create
meds.
It
only
checked
whether
the
command
Ron
and
the
output
was
that
I
don't
know
a
job
was
creative,
which
I
think
is
very
wrong,
because
we
are
not
passing
the
actual
functionality
of
the
command.
A
This
will
goes
into.
This
will
go
into
several
pieces
because,
as
you
probably
all
know,
we
have
different
levels
of
tests.
We
have
unit
tests
and
these
should
be
written
inside.
First.
We
need
to
modify
the
code
that
we
have
in
such
a
way
that
it
is
unit
testable,
so
I'm,
hoping
for
the
create
as
an
example
that
we
will
be
able
to
verify
that
the
generator
that
we
are
using
is
actually
producing
the
object
that
we
expect
from
the
input
parameters.
A
I
would
be
very
cautious
with
testing
the
printing
output
because
I
think
the
the
output
we.
We
never
said
that
the
output
of
the
cube
CDL
commands
is
stable.
It
will
be
changing
the
majority
of
time.
It
will
be
slight
changes,
but
I
don't
wanna
hard
code
tests.
That
will
be
exactly
counting
this
now.
This
number
of
spaces
between
object,
X
and
object
Y
in
the
output.
A
Additionally,
so
I
would
like
to
describe
in
a
dog
what
should
be
unit
tested
and
how
code
should
be
wrote
written
in
such
a
way
that
it
is
unit
testable.
What
kind
of
test
should
land
in
a
test
command,
because,
obviously
we
have
a
test
command
that
will
be
verifying
overall
correctness
of
a
commands.
I
doubt
we
have
any
cube,
CTL
related
integration
tests,
and
but
we
do
have
several
of
e
two
E's,
but
they
are
more
as
a
future,
plus
an
actual
CLI
behind
it
type
of
a
tests.
A
So
if
anyone
has
any
ideas,
how
we
should
approach
this
topic,
please
reach
out
to
me
I'll,
be
very
happy
to
answer
your
questions
or
to
to
gather
some
additional
feedback
around
the
topic
and
I'm
hoping
to
to
come
up
with
some
document
that
we
will
be
reliably
showing
to
every
single
cube,
CDL
developer,
so
that
we
will
be
able
to
limit
the
number
of
legs
and
have
the
test
actually
verify
the
functionality
they
should
be.
Does
that
make
sense.
A
D
Ahead
I
just
mean
so
everything
you're
saying,
sounds
great
I,
totally
agree
more
unit
tests
and
and
consistency
and
making
sure
we're
testing
the
right
things.
We
do
have
version
skew
tests
which
right
now
are
été
tests
and
make
sure
that
right,
skewed
versions
of
the
client
and
server
work
together
as
we
increase
coverage
with
unit
tests
and
make
those
better
do
we
need
to
make
sure
that
everything
that
we're
testing
for
correctness
of
the
tool
is
also
represented
in
edie
tests
that
can
be
done
with
version
skew
as
well.
A
I'm
not
sure,
if
we'll
be
able
to
to
have
everything
test
it
and
in
the
version
SKU,
but
I
would
like
to
see
some
of
the
major
areas
on
the
major
pinpoints
be
tested
and
in
the
version
skew.
If
that
means
introducing
additional
e
two
E's.
Yes,
then
then
we
will
do
so,
but
explicitly
testing
everything
for
the
for
the
version
school
I'm,
not
sure
we
should
go
with
this
one,
maybe
not
not
at
least
now.
A
D
A
D
A
Well,
obviously,
there
will
be
commands
that
are
introduced
over
time
that
won't
work
in
the
older
versions
and
that's
perfectly
fine,
because
some
resources
are
not
available
or
are
in
the
different
versions
and
I'm
perfectly
fine
Oh
as
a
good
example
of
stuff
that
should
be
tested
with
multiple
for
the
version.
Sku
is
those
resources
that
are
interacting
with
resources
that
be
that
were
promoted
from
one
APA
version
to
another,
one
move
to
from
one
group,
vert
API
grouped
and
different
API
group,
or
promoted
from
alpha
to
beta
and
beta
to
to
G
a
so.
A
If
we
test
at
least
those
I
think
we
should
be.
We
should
be
reasonably
good
about
the
versions
qu
and
if
there
is
no
such
move,
I
don't
know,
create
paw,
obviously,
I,
don't
think
we
would
have
to
test
part,
because
pod
will
be
working
all
the
way
back
couple
versions.
Phil,
can
you
tell
me
I'm,
I
I,
think
I
tab
I've
searched
several
times
this
topic
and
I
never
was
able
to
find
a
proper
dog.
Do
we
document
what
is
the
current
version
school.
A
A
Maybe
we
should
introduce
is
a
separate
doc
for
where
we
describe
the
testing
guidelines
and
the
testing
objectives
in
the
same
way
within
those
tests,
we
will
provide
the
information
that
this
is
the
version
school
guarantee
that
we
provide
within
the
cube
CDL,
and
this
is
the
the
testing
guidelines
that
we
are
trying
to
follow
to
to
fulfill.
That
requirement.
Does
that
make
sense,
yeah.
A
C
So,
as
I
have
a
comment
related
to
the
testing
so
before
we
have
everything
we
only
have
unit
has
on
the
e3
test,
and
now
we
have
a
integration
test
library
and
we
can
leverage
that
to
make
our
tests
can
be
run
faster,
so
I
mean
that
we
should
suggest
all
the
new
newt
annuity.
It
has
should
be
like
right
in
the
in
that,
using
that
library
right
into
a
as
a
integration
test,
and
if
we
have
time
we
can
average
out
tests
to
the
integration
test
actually.
A
We
have
unit
tests,
we
have
tests
command
and
we
have
e
two
E's
currently
I'm,
not
sure
if
we
have
any
integration
test
and
I'm
not
sure
if
integration
is
a
good
place
for
the
CLI
stuff.
The
unit
tests
are
very
are
perfectly
fine
because
they
are
focused
on
white
box
testing
particular
bit
of
functionality.
The
test
command
take
a
broad
approach
on
a
specific
command,
similarly
to
how
to
ease,
and
additionally
ETS
are
helping
us
for
the
version
of
school
testing.
That's
right.
C
So
I'm
I
think
I
may
have
a
slightly
different
opinion,
so
we
I
guess
we
don't
really
need
a
full
cluster
with
a
lot
of
nose
to
two
renders,
you
know,
say
I
test
with
what
we
really
carried
the
masternode,
the
cube,
API
server
and
the
schedule
we
have
I
believe
the
10
streamwork
already
can
mark
that
behavior.
So
we
only
need
one
master
node
to
do
all
these
tasks.
We
don't
really
need
to
flip
some
checkers
three
node
cluster.
To
do
this
test.
That's
all.
A
C
A
But
that
but
then
again
we
have
the
test
command.
That
can
perfectly
fine
that
are
perfectly
fine,
not
sure
how
much
of
the
the
server
but
I
think
the
testament
are
setting
up
a
limited
server
as
well
and
they're
perfectly
fine
for
the
majority
of
tests
to
verify
the
test
is
working
as
the
command
is
working
as
you
as
you
imagine
it
to
be
working.
So,
instead
of
going
to
all
the
way
to
integration,
the
testament
is
actually
sufficient.
A
I'm,
not
saying
that
the
test
command
that
we
currently
have
is
perfect
on
it.
Just
that
I'm
saying
it's,
it's
sufficient
it
and
sometimes
for
keep
CDL
commands
it's
easier
to
write
tons
of
bash
for
testing
the
functionality
rather
than
going
to
the
integration,
which
will
be
mimicking
a
lot
of
the
cube
City
invocations.
A
We
we
can
discuss
so
an
open
ships.
We
solve
this
problem
with
the
task
man
and
the
way
that
we
split
the
entire
because
we
used
to
have
it
in
a
single
in
a
single
file.
Currently,
this
the
test,
command,
butyl
I,
believe
it's
three
three
thousand
lines,
or
even
more
or
close
to
three
thousand
lines.
So
it's
pretty
big
and
it's
definitely
hard
to
navigate
through
this
file
figure
out
what
belongs
were
so
maybe
the
solution
for
us
is
to
actually
split
this.
D
A
Does
any
one
of
you
have
I,
don't
know
a
length
to
the
discussion
to
to
project
the
library.
D
A
Greatly
appreciated
I'll
try
to
Alden
sync
with
the
mystic
testing
folks
before
proceeding
with
this
one
in
that
case,
because
I
think
that
that's
reasonable
to
to
look
them
in
in
this,
because
that
that
somehow
overlaps
the
functionality
yeah.
That
will
make
sense
if,
if
the
sick,
the
test
command
would
be
entirely
rewritten
with
this
new
framework
and
that's
fine
as
well
yeah,
it's
actually
quite
nice,
not
cool,
that's
good!
That
would
simplify
because
I
know
that
did
yeah
the
test
command
is
age
is
is
a
big
problem.
A
A
A
We
will
probably
start
with
with
gathering
some
requirements
and
coming
up
with
a
proposal,
and
then
we
will
let
the
entire
six
year.
I
know
about
the
fact,
and
then
we
will
just
wait
for
the
input
and
basically
yes,
we
are
open
for
any
input
from
anyone
or
especially
help
well,
either
with
writing
or
the
document
or
with
actual
work
that
we
will
be
doing
afterwards,
while
cleaning
the
tests.
A
Okay,
I
think
we
can
the
case
we
can
move
to
the
next
topic,
which
is
the
cube
CTL
edit.
If
one
can
you
because
you
you've
added
that
one
to
the
agenda,
can
you
shortly
describe
this
and
then
I'll,
probably
I,
think
fill
left
some
comment
and
in
the
end
the
topic
is
also
I'll.
Let
the
two
of
you
speak
up
sure.
E
So
the
a
sort
of
a
major
proposed
feature
but
I've
come
across
it
multiple
times
in
the
past,
so
the
the
PR
that's
linked
on
here
is
a
basically
a
PR
that
Brendan
opened
a
while
back
trying
to
solve
the
issue
of
you
know,
basically,
given
a
config
map
with
a
file
embedded
as
the
value
in
one
of
the
keys.
How
do
you
edit
that
file?
You
know
human
in
the
humanly
possible
way
so
well,
a
PR
that
Brendan
opened
had
a
valid
idea.
E
The
implementation
was
ultimately
reverted
because
he
basically
proposed
adding
a
sub
command
to
the
edit
command
to
specifically
target
config
nuts.
So
in
the
case
of
config
nut,
you
could
specify
a
flag,
and
you
know
with
the
flag,
you'd
specify
a
key
and
then
the
key
pointed
to
a
value
of
containing
a
file.
Then
only
that
I
think
the
contents
of
that
key
would
be
opened
in
your
editor
and
there
before
mattad.
You
know
like
you'd
expect
in
a
human
and
it
merely
meant
family
way.
E
So
the
reason
why
I've
added
this
here
now
is
because
currently
we
still
doing
so
since
this
gear
was
reverted,
we
still
do
not
have
a
way
to
use
the
edit
command
or
anything
similar
to
either
view
or
edit.
The
contents
large
contents
of
a
key
segments,
so
I
was
hoping
to
get
some
input
from
from
the
community,
see
if
anybody
had
ideas
or
was
aware
of
an
ongoing
effort
that
exists.
Perhaps
in
addressing
this
issue,
I
would
count
this
as
a
feature.
E
F
Gonna
add
one
like
this
is
really
it
a
place
to
seek
secrets.
Equally
I
think
people
hit
this
for
secrets
just
as
much
as
they
hit
African
segments,
and
it
probably
also
really
applies
to
anything
in
a
CR
D
at
some
point
that
has
a
slightly
non-standard
and
adding
flow.
So
I
mean
this
feels
like
a
gap
in
how
edit
works
from
the
perspective
of
edit
is
for
humans,
and
if
humans
can't
edit
fields
on
our
objects,
then
our
we
need
a
way
to
do
that.
F
E
Perhaps
a
new
command
could
be
the
potential
solution.
We
could
have
something
that
is
able
to
edit
embedded
values
for
any
object
that
resembles
the
edit
command,
but
it's
separate
from
it.
What
I
can
do
is
I
can
open
up
a
Google
Doc
begin
drafting
a
set
of
solutions,
and
perhaps
this
will
generate
the
feedback
from
if
anybody
questions
a.
F
D
F
D
F
One
I
would
say
that
the
dual
of
this
is:
it's
still
incredibly
do
love
it.
It
is
it's
incredibly
hard
to
actually
view
secret
content
right
in
a
reasonable
way,
so
both
describe
like
the
scribe
doesn't
decode
things
vaguely,
so
there's
really
no
way
other
than
exporting
the
Emmel
and
then
doing
a
base64
decode.
So
I
would
put
this
into
general
usability
around
viewing
and
editing
both
secrets,
which
used
by
you,
know
base64
encoded
fields
and
config
maps,
which
are
also
large
frequently
at
an
instructional
data.
D
Could
I
still
think
we
could
do
this
with
I
mean
it
might
be,
not
the
right
reason
for
a
right
decision
for
other
reasons,
but
I
still
don't
understand
why
we
can't
do
this
as
written
just
implemented
differently
like,
instead
of
doing
it
explicitly
as
a
sub
command.
We
could
just
look
at
the
arguments
right
and
then
dispatch
different
code
based
on
if
it's
a
config
map
I
was
actually.
A
Thinking
about
maybe
maybe
being
able
to
provide
I,
don't
know
as
a
parameter
to
edit
command
the
path
that
you
intern.
You
want
to
edit
from
within
the
object,
I
I,
know
and
I
heard
from
some
people
complaining
that
they
would
like
to
be
able
to
edit
only
part
of
the
specific
object
and
not
the
whole
and
not
the
whole
object.
A
So
if
we
could
come
up
with
a
generic
way
to
modify
only
I,
don't
know,
I
want
to
modify
just
pack,
because,
if
I'm
looking
on
my
deployment,
the
majority
of
this
thing
that
I
see,
is
a
status
and
don't
care
about
the
status,
because
I
want
to
see
just
a
speck
or
part
of
its
back.
If
we
could
come
up
with
a
generic
way
to
be
able
to
edit
stuff
like
that,
that
would
apply
equally
to
two
secrets:
contact
maps
or
even
see
our
DS
that
has
embedded
fields.
A
F
Me,
the
primary
user
that
we're
focusing
on
here
is
someone
who's.
Just
coming
to
kubernetes
like
they're
gonna
do
describe
and
then
they're
gonna
do
edit
and
if
you
have
to
explain
to
someone
that
they
have
to
pass
key
equals
whatever
it
feels
like
we're,
basically
kind
of
saying,
and
it
doesn't
really
work
for
the
most
commonly
edited
contents.
F
So
I
mean
I,
mean
I,
agree,
much,
that's
a
useful
feature,
but
I
might
even
just
go
back
a
step
and
say
you
know:
does
any
user
using
the
CLI
who
sees
the
edit
command
not
expect
to
be
able
to
edit
config,
Maps
or
secrets
and,
like
you
know,
if
it
requires
us
to
transform
the
object
or
whatever,
like
those
are?
Also
things
like
there's
no
reason
that
edit
couldn't,
for
instance,
convert
you
to
string
Maps
or
just
decode
it
for
you
and
handle
the
details
on
the
way
out.
F
F
A
F
That,
like,
if
you
say
hey,
we
have
this
edit
command,
that's
supposed
to
work,
but
it
doesn't
actually
work
for
the
two
things
that
most
commonly
edit.
You
should
go
use
this
other
coming.
Should
we
just
make
edit
work
for
the
things
that
people
expect
at
it,
for
like
it'd,
be
kind
of
like
it's
described
for
a
pod?
Didn't
show
you
details
about
the
pod
like?
Would
anybody
really
expect
that,
like
you
have
to
cook
all
describe
pod,
show
me
you
know,
containers
or
something
I
feel
like
you
know.
What
are
people
like?
F
Maps
take
the
brunt
second
and
then
there's
a
long
tail
others
and
we
validate
that
and
then,
if
that's
the
case,
I
would
kind
of
argue,
let's
fix
what
users
care
about.
Not
what,
like
you
know.
Well,
we
had
adding
features
to
fix
problems
with
fundamental
things.
Just
means
we
have
two
things
they
understand.
Instead
of
the
thing
working
like
they
expected
how.
F
As
a
as
a
user,
that's
a
problem
that
edit
needs
to
deal
with
like
I
kind
of
this
gets
to
like
the
extensibility
versus
whatever
like.
If
we
go
make
a
perfectly
extensible
system,
that's
not
useful
for
anyone,
so
that,
like
it,
works
generically
with
everything
I'm
very
helpful.
But
if
we
said
like
okay,
well
secrets
and
config
match
should
be
editable.
There's
a
generic
problem
there,
which
could
apply
to
CRTs
once
the
best
way
to
fix
it
for
the
end
user
for
config
maps
and
secrets.
F
Just
automatically
convert
it
to
to
text
in
the
back,
or
we
warn
users
and
say
hey.
We
tried
to
decode
that,
like
there's
a
bunch
of
things,
we
could
do.
I
kind
of
I
would
worry
about
making
users
have
to
know
the
distinction
when
it's
a
pointless
technical
decision,
that
most
users
don't
care
about.
Yeah.
F
Question
and
that's
and
that's
actually
a
good
example
of
where
the
more
specific
one
I
think
would
make
sense.
Like
we
tried
to
edit
this,
we
couldn't
decode
the
non.
You
know,
Unicode
characters
in
your
secret,
you
can
use
dash
dash
key
or
I
mean
that's,
that's
almost
a
different
case.
That's
like
patch
right.
If.
B
F
Trying
to
send
binary
contents
in
there,
you
need
to
do
something
else:
you're,
not
really
editing
and
your
text
editors
not
going
to
work
with
binary
content.
Most
of
the
case.
We're
not
like
open
a
hex
editor
or
something
and
tell
you
to
change
the
vise
one
by
one.
So
I
I
feel
like
just
breaking
this
down
to
use
cases.
Does
it
make
sense
to
everybody
else
that
people
just
expect
to
be
able
to
edit
secrets
and
config
maps
and
should
focus
on
satisfying
the
expectation
rather
than
coming
out.
A
A
And
we
will
change
the
behavior
of
the
current
edit
command
if
we
introduce
the
fact
that
the
config
map
is
is
modifying
the
M
that
interior,
oh
I,
know
what
I
want
to
say.
Basically,
the
other
fields
that
we
have
on
a
config
map
resource,
there's
nothing
that
you
cannot
do
with
other
commands,
because
you
can
always
annotate
or
label
with
the
appropriate
commands,
and
the
actual
contents
is
just
the
data
fueled
inside
of
both
secret
or
a
config
map.
A
F
I
think
one's
idea
of
a
doc
where
we
can
kind
of
write
out
some
of
what
we
might
think
of
as
like,
like
I,
have
some
pretty
strong
opinions
on
this,
because,
as
a
user,
it
makes
me
angry
right.
I
can't
get
the
thing,
that's
very
natural
for
me
to
want
to
do
done
and
so
I
think
like.
We
should
use
the
doc
as
a
way
to
like
flesh
those
out
have
all
the
options
there.
So
people
can
talk
about
it.
I
think
some
of
the
concern
about
the
original
PR
was.
F
A
Remember
correctly,
the
original
entirely
broke
the
Edit
comment,
so
but
yeah
I
think
that's
that's
something
reasonable
and
definitely
desirable
by
the
majority
of
the
community
to
have
and
I
totally
feel
your
pain,
because
I'm
struggling
with
this
one
as
myself,
although
I'm,
mostly
with
contact
mat,
so
that's
easier
than
with
secrets.
Usually
if.
D
We
do
have
them
edit,
the
config
map.
We
probably
want
to
give
some
messaging
that
says:
hey
this,
isn't
gonna
like
your
pause,
won't
get
this
until
you
take
them
or
something
since,
if
we're
targeting
like
the
beginning
users
that
it's
not
always
obvious
to
everyone
that
when
they
make
a
change
to
config
map,
it
doesn't
get
propagated.
A
But
that's
a
that.
That's
not
a
cube,
CTL
thing
that
we
should
be
worrying
about
that's
a
thing.
That
is
that
a
user
should
understand
when
using
when
working
with
a
specific
object.
It's
it's
like
with
saying
that.
Oh
you
just
modified
a
cron
job,
but
you
should
be
aware
that
only
the
next
cron
job,
then
the
next
job
that
creates
that
will
be
created,
will
be
the
one
that
will
pick
up
the
spec
that
you
just
modified,
but
not
the
one
that
is
currently
running.
So
we
can't
embed
stuff
like
that
within
the
CLI.
A
F
F
A
That
makes
sense
it
that
would
be
like
that
would
be
resembling
the
current
flow
that
we
have
quit.
Validation
when
you
failure,
validation,
the
information
about
what
you've
more
failed
is
at
the
top
of
the
file
that
you
that
you
have
open.
Also,
they
can
clearly
see
what
failed
and
what
is
that
you
need
to
fix
so,
but
that's
still,
then
it
would
require
that
information
being
presented
by
the
yeah
by
the
server
yeah.
It's.
F
All
in
the
open,
API
spec
today
I
mean
okay
and,
and
maybe
another
point
even
is
to
go
a
little
bit
further.
Is
people
who
come
in
and
do
edit
may
not
know
what
fields
mean
it
might
be
useful
for
us
in
the
comment
at
the
top
of
edit
to
even
go
so
far
as
to
to
bring
up
the
existence
of
keep
control.
Explain
because
queue
control
explained
is
actually
a
pretty
good.
Do
all
do
it,
which
is
even
if
we
can't
like
we
can't
inline
it
and
can't
offer
a
rich
editing
experience.
A
A
You
want
to
add
it
so
suggesting
to
keep
CDR
explained
with
a
short
description
of
the
resource
and
eventually
length
where
you
can
get
more
data
would
be
beneficial,
because
that
will
give
both
the
novice
users
and
the
experience
and
for
me
they
would
be
looking
for,
but
only
enough
to
learn
something
more,
but
not
too
much.
So
they
are
flooded
with
sort
of
useful
information,
but
not
in
not
after
you
do
it
you're
doing
it
like
for
the
tenth
or
a
hundredth
time.
Yeah.
F
I
feel
like
a
lot
of
our
resource
problems,
basically
come
down
to
do.
We
do
a
good
job
of
helping
you
find
out
what
resources
there
are
and
explaining
what
those
resources
do
and
that's
we
have
most
of
the
tools
for
that,
but
we
don't
put
them
front
and
center
and
a
lot
of
flows,
and
so
you
know
I've
certainly
met
people
who
have
asked
me
endless
questions
about
what
objects
do
and
like
did
you
ever.
Try
explain.
They're,
like
oh
I,
didn't
even
know
that
existed
and
yeah,
and
someone.
A
Goodness
somebody
just
recently
added
the
API
resources
command
that
will
return
what
the
current
server
provides,
because
for
a
long
time
we
had,
there
was
no
reasonable
way
how
to
get
the
resources
and
I
think
one
has
a
pure
open
so
that
we
changed
a
hard-coded
list
of
resources
with
a
suggestion.
Oh,
and
if
you
don't
want
to
know
what
the
resources
we
have
used
this
command-
and
this
will
free
us
from
actually
hard
coding
the
list
of
resources,
because
there
was
another
proposal
of
getting
the
bad
list
from
the
server.
A
A
A
E
So
currently
there
are
Spears
have
been
so
in
flight
or
or
you
know,
close
emerging
the
finish,
wiring
print
flags
through
all
commands.
So
hopefully,
by
the
end
of
this
week,
the
latest
we
will
have
the
new
print
flags
pattern
set
across
all
commands.
As
an
aside,
there
has
been
also
ongoing
work
to
apply
this
same
pattern
to
other
Flags,
not
related
to
printing
such
as
record.
A
E
B
Share
yeah
I
was
hoping
to
just
give
a
quick
comment
on
the
server
side,
apply
working
group
since
there's
obvious
overlap
with
six
Eli,
so
the
we're
on
the
fourth
week
of
the
fourth
sprint
of
the
server
side
apply
working
group
there's
been
several
PRS
that
have
been
merged
into
the
open,
coop
open,
API
repo
in
order
to
enhance
our
IDL
and
the
swagger,
and
there
has
been
a
significant
refactor
of
the
the
patch
code
on
the
server
in
order
to
make
it
more
testable
and
so
that
we
can
have
some
confidence
in
our
changes
once
we
do
add
this
to
the
patch
I
think,
that's
about
all
that.