►
From YouTube: Kubernetes SIG Architecture Community Meeting 20180215
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
All
right,
good
morning
afternoon
evening,
night,
wherever
you
may
be
in
the
world,
where
I
am
it's
Thursday
February,
15th
2018,
and
this
is
the
Sikh
architecture.
Community
meeting
I
am
Jason
singer,
DeMars
Khalid,
along
with
Brian
cranes,
and
we
are
going
to
kick
off
the
meeting
if
you
want
to
follow
along
after
the
fact,
the
agenda
is
available
at
bit:
dot
Lee,
slash,
sig
architecture,
and
we
will
have
notes
from
this
meeting
there
as
well
as
links
to
relevant
proposals
in
what
not.
A
So
without
further
ado,
today
we
have
any
interesting
cross
seg
meeting
with
sig
p.m.
and
the
intent
is
really
to
sort
out
what
is
currently
I
believe
a
relatively
messy
feature
process,
with
some
confusion
about
how
caps
relate
to
that
and
how
sick
pm's
mission
has.
Essentially,
since
it
was
founded
radically
changed,
versioning,
sick
p.m.
was
intended
to
be
program,
product
and
project
and
all
those
different
peas
are
now
sort
of
at
different
odds
with
one
another.
A
So
essentially,
what
we
want
to
do
is
find
out
what
are
the
places
that
we
overlap
with
sig
architecture?
What
are
the
ways
in
which
would
say
p.m.
conserve
architecture
and
basically
try
and
make
sure
that
we're
all
in
alignment
around
all
the
things
we're
trying
to
accomplish,
because
right
now,
I
feel
like
the
sig
PM
is
flagging
and
we
need
to
do
a
much
better
job
of
serving
the
community
and
I.
Don't
believe
we're
doing
that
so
I'm
going
to
turn
that
a
micro,
video
or
but
ostensibly
I'm,
not
a
leader
in
sig
p.m.
A
B
A
B
Sure
so
yeah
I'm
your
own
I'm,
a
co-leader
of
6:00
p.m.
today
as
we
scale
it,
who
is
also
here
at
Maidan
I
hope
that
her
partner
will
join
us
soon,
so
yeah
we
should
have
enough
quorum
on,
discuss
and
decide
him.
So
our
first
of
all,
I'd
like
to
mention
that
the
major
the
media
pot
we're
sick
p.m.
was
involved
during
the
last
around
the
year.
So
this
disease
days,
we're
celebrating
our
first
anniversary
6:00
p.m.
B
and
the
major
Arab
of
where
we've
been
involved
in
the
last
year
was
the
features
process
and
the
roadmap
process.
At
the
same
time,
I
should
mention
that
when
we
have
established
SiC
p.m.
and
when
the
original
features
process
was
established,
NASA
secret
detection,
all
secretly
is
not
kept.
Process
has
an
existent
at
all.
So
today
we
have
a
bit
different
story
of
how
to
manage
cabinets
at
all
as
a
project
and
I'd
like
to
receive
the
complex
feedback
and
suggestions.
B
How
should
we
move
on
with
with
the
current
state
of
cabinet
is
especially
in
the
features
area
and
enhancements
era?
How
can
we
work
on
the
under
new
features
for
cabinet?
Is
together
in
a
scope
of
caps,
and
so
on
so
Jesus
pasted
the
link
in
the
in
the
meeting
notes
about
about
the
proposal
of
enhancement,
delivery
management
in
community
service
system.
B
We
have
prepared
this
document
a
few
months
ago
in
a
scope
of
CPM.
As
far
as
I
remember,
even
caps-
heaven
even
existed
so
in
in
so
mature
state
at
as
they
exist
today.
So
I'd
like
us
to
briefly
review
this
document
and
provide
some
suggestions
and
provide
some
feedback
on
what
can
we
do
to
date
to
make
this
process
more
efficient?
B
The
second
part
is
the
episodes
just
mentioned.
How
can
we
safely?
How
can
we
collaborate
with
secret
addiction?
What
did
the
errors
were
to
be
overlap,
and
one
of
us
should
step
back
and
simply
simply
work
in
the
same
area
where
one
sake
currently
works
today
and
what
did
they?
What
did
the
errors
where
we
don't
have
an
overlap,
and
we
should
focus
more
on
a
specific
area
and
also
like
to
discuss
the
future
of
the
feature
itself
as
as
the
primary
repo,
as
that
is
owned
by
6:00
p.m.
the
primary
place?
B
Where
do
we
track?
We've
been
tracking
our
feature
related
activities
for
human
ages
for
around
one
and
a
half
years,
but
again
when
feature
strip
was
established
around
one
and
a
half
years
ago.
So
much
things
have
changed
during
during
this
time,
and
I
hope
that
we
may
find
the
Beretta
process
of
managing
the
features
managing
the
feature
related
process,
because
for
my
from
a
personal
standpoint
and
my
personal
feedback
on
how
these
things
that
happen
in
the
future
through
petunia
last
one
to
us
releases.
B
This
case,
Ripper
is
not
so
actively
used
by
communities,
contributors
and
by
kubernetes
developers.
So
at
the
same
time,
most
of
them
have
moved
to
kept
process
and
related
processes.
At
the
same
time,
we
can't
kill
and
destroy
features
Ripper
at
all,
because
it
brings
their
significant
value
for
for
the
errors
that
are
not
related
to
the
technical
development
of
communities
itself.
B
It
still
has
two
extremely
big
failure
for
marketing
people
for
for
people
outside
of
communities
community
who
are
looking
at
what
was
going
on
risk
of
the
next
and
what's
happening
music
to
the
netizen.
What
we
are
delivering
with
wasting
your
lives
of
cabinet
is
for
for
our
customers
and
features.
Repo
is
the
final
source
of
choice
for
them.
We
have
the
more
user-friendly
version
of
the
features
rapport
with
the
feature
straightly
spreadsheet
I
maintain
for
a
couple
of
releases.
B
Okay.
Yes,
so
that's
that's
yet
another
reason:
why
do
we
have
these
discussions?
I
would
I
would
notice
that
around
90%
of
features
in
the
future
who
are
really
up-to-date
and
maintained
by
by
their
actual
owners.
At
the
same
time,
we
have
around
like
10%
of
features
that
are
not
really
actively
maintained
and
we
have
to
push
feature
owners
to
to
update
them
correctly.
I
see.
A
Yeah
I
mean
this:
is
this
gets
into
the
heart
of
the
issue?
Is
that
what's
what
actually
are
the
features
are
the
the
code?
Is
the
only
thing
that
really
knows,
and
even
though
the
labels
and
flags
are
not
not
accurate,
we're
seeing
that
that's
release
more
than
I've
seen
in
other
works,
where
there's
a
fuzzy
line
between.
What's
an
enhancement,
cleanup,
a
bug,
fix
and
a
feature,
so
we're
starting
to
lose
fidelity
on
this,
and
that's
that's
a
real
serious
problem.
B
F
So
I
actually
think
that's
in
order
to
ensure
that
it's
used,
it
has
to
actually
tie
more
tightly
into
the
development
workflow
of
users
so
I
much
like
we
have
the
feature
complete
date
that
people
need
to
hit
and
they
need
to
ask
for
exceptions
to
get
changes
merged
after
that
date,
and
we
have
automation
to
you,
know,
stop
automatically
merging
PRS
and
things
like
that.
If
it
were
tied
to
the
actual
development
process
and
automation
more
tightly,
then
there
would
be
a
better
chance
of
using
it.
F
So
I
really
still
believe
we're
going
to
need
to
stop
most
development
and
the
master
branch
of
communities
communities.
In
order
to
make
that
happen,
like
once,
people
start
merging
stuff
into
the
master
branch,
then
it's
really
hard
to
impose
any
kind
of
requirements
or
timelines
or
whatever,
because
you
can't-
and
it's
not
practical,
to
revert
that
stuff
anymore
I.
Don't.
G
D
I,
take
a
step
back
and
I
feel
like
we're
diving
right
down
into
solution
here.
I
think
the
fundamental
problem
with
the
futures
process
as
it
exists,
is
that
there
are
essentially
no
carrots
and
no
sticks.
There's
no
benefits
to
actually
working
through
that
process
and
there's
no
downsides
to
ignoring
it.
I.
A
Don't
agree
with
those
big
carrot,
so
I
think
there's
a
huge
carrot
in
the
sense
that
if
people
are
proud
of
what
they're
delivering
in
terms
of
features
that
that
is
the
avenue
to
get
that
exposure
in
terms
of
blogs,
the
release,
notes
and
all
that
stuff.
But
you
can
get
stuff
into
them
and
I,
don't
think
we
want
features.
You.
D
G
Honestly,
I
don't
think
the
people
are
developing.
Those
patients
are
actually
motivated
by
any
of
those.
Just
a
blog
and
I
put
on
my
own
blog,
okay,
I
guess,
I
think
we
should
maybe
separate
this
out
like
I.
Think
there's
a.
How
do
we
propose
improvements
and
track
improve
question
which
is
I,
think
the
feature
isn't
capped
and
all
that
stuff
and
then
there's
a
brian
is
saying
which
is
basically
like.
We
don't
have
a
mechanism.
G
Even
if
we
had
these
things,
I
don't
think
we
have
a
mechanism
for
enforcing
it
if
everybody's
merging
code
and
master-
and
I
totally
agree
with
what
you
said,
which
is
like
there's
just
so
many
wiggle,
there's
just
so
much
room
for
wiggling-
that's
like
if
you're
determined
you
can
merge
your
future
whenever
the
hell.
You
want
to
merge
your
future
and
very
little
that
we
can
do
about
it.
G
So
I
think
we
should
separate
out
the
discussions
and
I,
don't
know
which
one
we
want
to
have.
One
is
around
the
logistics
of
how
do
we,
you
know,
discuss
and
come
to
agreement
on
a
feature,
and
then
the
other
is
how
do
we
tie
the
actual
development
of
teacher
to
a
specific
release
and
the
specific
timeline
they're,
both
very
relevant
discussions,
but
we
should
decide
which
one
we're
going
to
have
it
that
way.
So.
F
Yeah
I,
don't
you
know
popping
up
a
level
in
terms
of
how
this
discussion
started
with
overlap
between
said
architecture
and
CPM
and
kept
in
teachers
and
kept
at
least
my
original
intent,
for
that
was
to
replace
the
unspecified
cargo
cult
based
proposal
process
and
the
reason
it
was
in
Sagarika.
Texture
is
because
that's
one
of
the
means
by
which
we
have
to
review
significant
changes
to
cover
denny's
to
ensure
that
they
conform
to
our
conventions
and
guidelines
and
requirements,
and
so
on.
F
You
know
it
does
have
some
amount
of
overlap
with
the
features
process
in
terms
of
tracking
the
stage
of
development
and
identifying
major
changes,
but
I
don't
think
it's
my
view.
Is
it
shouldn't?
Be
a
hundred
percent
overlap?
Necessarily-
and
that's
you
know
the
implementation
details
were
never
in
the
features,
issues
or
weren't
intended
to
be
they're.
You
know
they're
supposed
to
link
out
to
the
proposal
or
design
or
whatever,
so
they
seems
complementary
to
me.
F
Even
in
the
absence
it's
related
to
the
feature
branches,
but
one
thing
that
that
a
feature
branch
would
do
is
create
an
identifiable
place
where
changes
could
get
merged
in
a
controlled
process
by
which
those
get
folded
into
a
release.
Another
approach
would
be
that
changes
would
require.
Instead
of
a
blanket
milestone
label,
we
could
develop
like
some
more
specific
mechanism
for
identifying
individual
features
that
have
been
vetted
to
go
in
to
release
or
something
like
that.
F
D
Minutes
left
here,
I
get
the
feeling
that
the
Sapien
folks
were
looking
for
some
sort
of
resolution.
Is
there?
Is
there
a
specific
sort
of
proposal
or
you've
got
or
with
the
cat,
stuff
and
I'd
love
to
you
know,
and
obviously
there's
there's
bumps
in
the
road
there?
That
I
think
are
worth
talking
about.
There's
clarification
there
that's
worth
talking
about,
but
is
there
a
larger
sort
of
you
know
reset
that
folks
are
looking
for?
Is
there
a
larger
set
up
yeah.
A
I
think
what
we
need
to
do
is
just
write
a
proposal.
What
I
want
to
say
here-
and
hopefully
this
is
recorded
until
the
end
of
time.
The
kept
process
is
not
ever
and
nor
will
it
ever
be
a
replacement
for
the
features
process
it
is.
It
is
the
proposal
process.
The
features
process
is
a
separate
process,
which
is
how
at
a
very
low
level
from
the
commit
level
that
you
track
the
work,
so
I
think
that
if
we
can
at
least
accomplish
that
that
helps
us
delineate
where
SIG
architecture
and
where
6:00
p.m.
A
D
I
got
to
be
honest,
I
think,
there's
a
ton
of
confusion
in
terms
of
what
exactly
the
future
process
is
and
what
the
granularity
there
is
and
I
mean.
Maybe
some
clarity
there,
because
I
think
in
your
mind,
Jace.
You
have
a
very
clear
view
of
it.
I
pulled
up
the
the
original
message
that
kicked
off
the
features,
repo
and
I'm
gonna
post
that
in
here,
just
as
a
point
of
history
and
I,
think
it's
mutated
over
time
and
I
think
it's
it's
it's
it's
worth
for
us.
D
A
Document
that
I
linked
it
has
that
I
believe
it's
very,
very
clear
and
on
anyway,
and
there's
no
ambiguity
about
I
hope.
If
there
is
please,
please
mark
them.
This
is
the
document
that
was
linked
out
of
the
notes.
Yes,
okay,
too
many
documents
flying
around
sorry,
no
kidding
and
I'm.
Sorry
I
hate
to
add
to
the
pile.
But
this
is
that's
what
we
do
important
thing,
so
I
think
the
other
thing
is
just
I
mean
since
we're
running
out
of
time.
I.
A
F
B
Yeah
yeah,
that
was
a
problem.
We've
changed
our
cadence
of
meetings
a
bit,
so
we're
not
we're
happening
on
every
hour.
Medium
is
happening
on
every
second
and
force
accused
of
amounts
well,
C&C.
After
say,
meetings
have
been
in
under
first
ministerÃs.
At
the
same
time,
we
are
currently
facing
some
issues
we
used
to
show
up
with
the
with.
B
A
With
a
lot
of
people's
commutes,
there's
also
I
sent
an
email
to
sick
p.m.
mailing
list
and
I
I
think
you
can
look
at
it
without
having
to
join,
but
it's
a
really
important
email
about
sick
PM's
raised
on
debt,
which
is
really
what
is
the
P
stand
for
nowadays
is
a
program
project
or
product,
because
each
of
those
things
is
different.
They
have
different
missions
and
in
some
cases
product
and
project
are
at
odds
with
one
another.
A
D
That's
on
the
same
list:
yes,
okay,
I'll
have
to
find
it.
I
I
have
concerns,
because
I
think
sig
p.m.
my
impression
is
that
it
tries
to
apply
a
management
model
that
works
inside
of
a
top-down
company
to
an
open-source
project
and
I.
Think.
A
lot
of
the
friction
here
is
that
there
is
no
one
set
of
people
that
can
direct
things.
D
We
can
provide
incentives
and
those
incentives
have
to
be
enforced
and
those
incentives
have
to
be
embedded
in
terms
of
the
processes
and
the
people
that
hold
power
to
make
things
happen,
and
so
again
it
comes
down
to
carrots
and
sticks
in
a
big
company.
The
the
carrot
and
stick
is,
you
know,
promotions
and
you
get
paid
and
you
can
get
fired
right
that
doesn't
exist
really
inside
of
the
project
and
so
I'm
not
sure
the
traditional
way
of
thinking
about
this
is
actually
going
to
be
effective.
Well,.
F
F
A
A
Okay,
all
right:
let's
move
on
to
crunch
of
instantiate.
H
Neither
yeah
I'm
here
watch
it
here
drum.
So
here's
the
thing.
There
was
a
request
to
be
able
to
schedule
cron
jobs,
manually,
ad
hoc
and
initially
we
thought
that
we
are
going
to
introduce
a
another
end
point
on
a
cron
job,
so
that
every
single
client
could
use
that
end.
Point
instead
of
manually
creating
manually
creating
the
cron
the
job
itself,
but
it
appeared
that
there's
more
problems
with
this
approach
then
actually.
H
H
So
David
David
concern
is
that
instantiate,
where
a
cron
job
is
very
simplistic,
because
all
it
does
is
just
copies
over
the
job
template
and
apply
its
labels
and
annotation.
So
there's
no
problem
of
like
an
open
shift.
What
we
have
that
the
user
can
do
it
by
himself
instead
of
the
need
for
the
system
to
be
able
to
do
it
and
an
open
shop.
For
example,
we
have
this
concept
of
instantiate
for
a
buildconfig,
because
user
cannot
create
the
pot
by
himself.
H
So
there's
a
problem
of
permissions
that
the
user
doesn't
have
to
be
able
to
create
the
bills
by
himself.
So
we're
delegating
the
the
the
work
to
the
system
to
be
able
to
to
create
the
build
itself
with
a
cron
job.
The
problem
doesn't
exist
because
the
user
can
create
manually
a
job
out
of
out
of
a
cron
job.
You.
H
F
H
D
F
D
Okay,
so,
but
the
world
that
we're
in
now
is
it's
not
practical
to
really
have
sort
of
sub
permissions
inside
of
a
namespace,
you
know
it's
I
know
you
can
I
mean
you
can,
but
okay,
that's
a
different
discussion.
Sig
off
we've
been
talking
about
that
stuff,
but
so
what
the
whole
pod
template
do?
We
want
to
support
that
that
the
authentication
issue
where
it's
like
one
actor,
creates
the
cron
job?
Is
that
part
of
this
part
of
this
the
goals?
Out
of
this?
That's
not
a
goal.
That's
not
a
goal.
Okay,
go.
H
F
H
H
Scale,
sub
resources,
I
think
headed
differently
because
it
and
installs
itself
in
in
different
versions.
I
was
looking
at
into
the
scale
as
an
example
where
we
do
support
it,
but
in
in
case
of
a
scale
we
just
install
scale
in
different
and
different
good
versions,
but
during
the
the
processing
you're,
always
processing
a
scale
resource
so
whatever
is
in,
is
actually
going
out.
So
so
so
we
don't
want
to
mirror
the
job.
It's
the
same,
API
version.
H
F
H
Be
one
big
one:
yeah
it's
in
beta
and
I:
don't
want
to
promote
it
further
until
it
will
be
more
stable.
I
have
a
little
bit
of
a
few
concerns
with
regards
to
the
controller.
I
would
sure
them
it
needs
to
be
ruined
and
to
to
use
the
shirt
and
formats,
because
it
is
not
currently
and
there's
there
a
few
other
issues
that
I
would
like
to
see
addressed
before,
actually
promoting
it
further.
H
F
H
That
will
be
actually
so.
There
are
two
possibilities
that
we
could
handle
with
this
if
we
would
use
a
qcdr
command
that
could
set
up
a
annotation
that
would
say
that
this
cron
job
this
is
part
of
a
cron
job,
because
we
would
be
saving
the
owner
of
the
references
and
based
on
that,
the
crunch
of
controller
would
be
able
to
properly
I
miss
the
word.
H
So
and
I
brought
this
discussion
yesterday
during
SiC
CLI
meeting
and
there's
an
old
there's,
an
agreement
from
the
six
Eli
that
we
definitely
need
to
have
more
cube.
Cbl
created
commands
because
we
are
lacking.
Currently,
the
only
way
of
CLI
creating
creating
a
job
from
a
CLI
is
with
cube
cd-rom,
which
is
kind
of
a
complicated
thing,
because
you
need
to
know
the
the
flag
values
that
are
probably
that
you
need
to
probably
pass
to
have
the
job
that
you
care
about.
H
H
H
Fine
thing
binding
and
eviction
are
the
other,
but
not
not
was
that
was
creating
this.
So
there
was
also
the
discussion
because
fixing
this
end
point
or
our
API
server
so
that
it
can
actually
return.
A
different
object
was
one
approach,
but
with
the
current
state
of
things
we
would
we
could.
There
are
two
possible
approaches
either
we
would
be
just
returning
a
made
of
you
want
status
about
that.
F
H
H
F
H
F
H
F
H
Discussing
and
figuring
out
the
approach,
because
I'm
I'm
guessing
that
this
might
create
a
path
forward
for
other,
similar
self
resource
paths
or
stuff,
like
that.
So
yeah.
F
Yes,
I
agree
either
returning
a
job
is
something
that
we
may
want
to
do
in
other
cases
where
we
want
to
render
some
derived
object
that
hasn't
come
up
before,
as
well
as
actually
launch
just
launching
the
job
and
returning
information
about
that
job.
That
is
also
something
we
have
wanted
previously
in
other
cases,
but
hadn't
implemented,
yet
so
finding
a
way
to
do
either.
One
of
those
is
reasonable
in
the
use
cases
very
reasonable,
though
I'll
try
to
think
about
that.
F
D
H
D
Pick
Euler,
the
solution
were
happy
with
and
I'd
also
say
that
something
like
run.
This
now
ends
up
being
an
edge
triggered
type
of
thing.
It's
similar
to
like
reboot,
which
is
different
from
scale
which
is
essentially
sort
of
a
a
collab.
We'll
modify
this.
You
know
parent
resource,
you
know
the
the
idea
of
like
a
reboot
type
of
thing
can
be
modeled
in
terms
of
like
reboot
account,
or
you
can
say,
like
test
run
counted.
D
H
D
F
B
F
F
F
Talk
I've
been
working
on,
I
started
out
building
something
called
API
server
builder
about
a
year
ago.
We
got
some
feedback
on
it.
A
number
of
folks
have
been
working
on
it.
Our
demo
folks
have
been
using
it
for
different
projects
and
when
the
feedback
I
got
was
series
are
kind
of
the
recommended
way
of
building
things
so
asking
for
a
toolkit
for
building
series.
F
It
is
a
little
bit
of
a
cross-cutting
piece
because
it
kind
of
touches,
see
debbye
developer
experience
apps,
because
here
are
these
and
building
controllers
and
that
sort
of
Easterns
the
gaps
API
API
machinery,
because
it
works
with
the
informers
and
API
server,
aggregation
and
packaging
up
the
API
machinery,
libraries
and
code
generator,
libraries
and
potentially,
my
hope-
is
that
it
will
be
like
a
fully
featured
SDK
that
really
provides
into
and
guidance
for,
developing
extensions.
F
F
Else
was
gonna
speak
up,
I
personally
think
it
should
be
API
machinery
I
do
want
to
see
us
actually
have
full-fledged
as
SDKs
for
both
building
and
consuming
api's
I.
Imagine
even
like
the
really
generic
parts
of
keep
control
as
we
thin
it
down
and
embed
less
logic
and
keep
control
would
probably
also
migrate
in
that
direction,
especially
once
we
broaden
it
out
to
support
a
lot
of
non-native
api's.
F
So
then
cute
controller
can
kind
of
move
up
and
focus
on
more
more
opinionated
things,
but
you
know
if
we
need
to
eventually
split
out
API
machinery
into
multiple
efforts.
We
could
do
that,
but
I
think
for
now.
Api
machinery
is
right
home
for
this.
Much
like
the
client,
libraries
and
things
like
that.
Ok
awesome,
like.
G
G
D
Mean
that's
a
good
question,
so
I
mean
do
you
feel
like
this
has
to
be
sponsored
by
a
sig?
Is
there
a
lot
of
folks
who
want
to
sort
of
meet
and
sort
of
join
in
with
this
I
mean,
there's
no
reason
why
I
can't
sort
of
exist
outside
of
the
structure,
all
together
as
like
an
Associated
project
with
the
CLA,
and
then
you
know
if
it
catches,
fire
and
and
there's
a
bunch
of
people
that
want
to
coordinate
it
might
make
sense
to
then
migrate.
It
in
I'm.
F
G
G
D
D
F
D
F
D
It's
gonna
go
in
a
sync:
it
should
be
API.
Machinery
I
think,
is
the
takeaway
there's
a
question
whether
it
needs
to
be
sig
associated
and
I.
Think
that
that's
something
that
you
know
as
the
the
author?
That's
that's
something
that
you
can
decide
so
I.
Think
there's
some
larger
concerns
around
sort
of
like
is
this
I
think
we
agree
from
the
outside
that
this
should
be
part
of
the
mission
for
API
machinery,
whether
it's
actually
the
the
mission
that
API
machinery
is
taking
on.
I
think
is
another
open
question.
Maybe
a
sub-project
right,
yeah!
D
F
F
D
F
F
A
A
F
F
So
the
first
thing
you
saw
the
error
message
there
and
it
says:
hey
you
got
a
B
in
it
has
to
be
run
from
your
go
path.
So
I
set
my
go
path
and
then
I
run.
The
tool
now
puts
this
messaging
talking
about
different
ways
running
it.
But
the
first
thing
it
does
is
say:
okay,
like
here's,
the
typical
life
cycle
so
run
this
command.
F
C
F
F
So
so
what
I?
What
I
do
actually
is?
I
I
run
DEP
in
my
tool
and
get
the
whole
vendor.
They
are
somewhere
else
and
then
I
tore
it
up
with
the
DEP
files
and
everything
else
and
then
give
it
to
you
and
then
that
way,
if
one
of
the
URLs
happens
to
be
down
where
you
pull
it
down,
it
doesn't
like
prevent
the
tool
from
working,
which
is
it's.
C
F
F
F
It's
frustrating
okay,
so
it
prints
out
this
command
like
hey.
Why
don't
you
run
this
next?
So
you
go
ahead
and
run
that,
and
so
it
says:
okay,
I'm,
creating
these
files
for
you
and
then
I'm
going
to
generate
run
all
the
code,
generators
against
your
code
and
this
point
I'm
going
to
switch
to
what
I'm
sharing
to
my
IDE.
F
F
So
this
really
quickly
what
this
does
is.
It
creates
the
file
here
the
resource
file
with
the
like
edit
this
and
insert
your
code
here.
This
is
what
was
listed.
It
creates
a
test
for
this,
so
this
spins
up
a
test
framework
that
brings
up
an
API
server
locally,
even
on
Mac
or
control
plane.
It
installs
the
CR
DS,
does
a
storage
test
for
you,
so
you
can
add
your
test
for
validation
here.
F
H
F
Your
at
your
feedback,
thank
you
for
that
feedback
Ryan.
So
again
it
prints
out
these
files
when
it
creates
them
in
the
terminal.
You
may
have
saw
it
briefly
so
at
points
you
go
look
at
these
and
then
it
says
edit
this
file.
This
is
what
graded
it
and
here's
where
you
edit
your
code,
and
so
it
hasn't
a
reconciled
loop
for
the
controller.
This
automatically
gets
installed.
F
And
then
you
add
your
business
logic
to
the
test
like
I,
think
it's
really
gonna
help
developers
write
tests
first,
instead
of
like
say:
okay,
that's
the
last
thing:
I'm
gonna
do
after
I've
like
done
everything
else
real
quickly.
It
provides
like
it
really
tries
to
reduce
friction
across
the
whole
thing,
so
it
provides
you
a
sample
so
right
off
the
bat.
F
You
can
actually
create
an
instance
of
whatever
it
is
that
you
built
it
make
sure
that
basil
works
with
ghazal,
so
you
can
have
faster
two
builds
and
make
sure
that
Doc's
can
be
built
free
reference,
Docs,
there's
a
build
box
demand
it'll,
build
all
this
stuff
into
containers
and
it
even
builds
an
installer
container
for
you
over
here
that
you
can
override
and
do
different
pieces
with
to
change
how
things
are
installed,
but
you
can
flag
whether
you
want
API
server,
aggregation
or
CRTs
and
how
to
install
them.
That's
it.
That's
the
whole
thing.
A
B
F
The
draft
versus
accepted
versus
provisional
versus
some
other
thing,
I
think
the
biggest
challenge
with
the
cap
so
far,
and
we've
actually
proposed
several
different
ways
of
dealing
with
the
initial
formulation
of
the
cap.
All
of
them
are
kind
of
going
all
the
things
we
wanted
to.
Try
are
kind
of
going
against
the
grain
for
natural
tendencies
of
people
on
this
project
to
bike
shed
for-
and
you
know,
have
productive,
constructive
debate
as
well
for
a
really
long
time,
but
one
of
the
goals
was
to
find
a
way
to
facilitate
for
progress.
F
F
F
My
argument
against
draft
was
that
we
have
used
it
a
lot
in
the
past
and
it
became
meaningless
because
people
would
go
ahead
and
things
would
stay
in
draft
forever
and
they
would
be
abandoned
and
they
would
stay
a
draft
or
they
would
be
implemented
and
stay
in
draft
or
they'd
be
improved
and
stayed
in
draft,
so
like
draft
has
to
me
no
longer
has
any
meaning
and
it
doesn't
really
suggest
where
it
is
in
the
process
or
that
it
has
later
like.
If
something
is
approved
but
not
implemented
it,
it
might
still
change.
F
D
F
Wanted
people
to
just
have
people
check
in
the
parts
that
are
agreed
upon,
but
I
find
I
mean.
That
is
also
a
pretty
big
change
in
behavior
because,
like
I,
don't
you
know,
people
would
put
in
a
lot
of
texts
and
then
they'd
be
asked
to
remove
most
of
it
to
get
down
on
to
something
that
could
be
agreed
upon,
and
then
they
would
have
to
create
an
EGR
that
added
it
back.
F
E
My
only
comment
for
something
other
than
provisional
was
my
reading
of
the
draft
to
me
or
Provisionals
me
and
sounds
like
I'm.
Just
writing
a
document.
There
seems
to
need
to
be
a
step
where
a
sake
bones
this,
and
it
has
accepted
that
they're
going
to
own
it
so
was
implying.
There
could
be
other
words
like
bones
or
accept
accepted.
D
The
fact
that
the
sig
has
taken
up
that
work
is
kind
of
implied
by
just
having
a
sing
thing.
There
I
think
we're
focused
on
sort
of
which
sig
does
this
belong
to,
but
any
especially
for
the
ones
that
aren't
sitting
at
the
root
that
are
in
a
sig
directory.
There's
sort
of
an
implied
like
hey,
I,
think
it's
merged
at
all.
That
sig
is
taking
up
that
work
right,
so
I
think
that's
sort
of
accepted
by
the
sig
is
kind
of
implied
yeah.