►
From YouTube: Service APIs Office Hours 20200708
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
This
is
the
office
hours
meeting
for
service
apis
for
july,
8th
welcome
to
everyone.
We
have
a
relatively
light
crowd
today.
I
know
bowie's
going
to
be
joining
a
bit
later
on.
He's
got
a
conflict
for
the
first
half
of
this
meeting,
but
there's
plenty
that
I
think
we
can
discuss
despite
me
not
getting
this
agenda
up
to
date.
A
There
are
a
few
new
issues
that
have
come
in
that
I
think,
are
worth
some
broader
discussion
and
also
a
couple
pull
requests
that
could
potentially
use
some
attention,
but
before
I
get
going,
is
there
anything
that's
not
on
the
agenda
that
someone
would
like
to
cover
here.
A
Cool
all
right.
Well,
the
first
one
is
courtesy
andrew
cuts.
He
had
a
an
interesting
idea
about
v1
alpha
zero
freeze.
A
Basically,
if
I
I
had
some
discussion
on
slack
with
him
around
this
and
it
it
sounds
like
for
their
specific
use
case.
They
would
like
to
freeze
the
api
in
its
current
state
or
close
to
its
current
state
in
the
next
week
or
two,
and
they
actually
want
to
use
it
for
one
of
their
implementations.
A
It
raises
a
very
good
point
that
right
now
anyone
wanting
to
use
the
api
in
its
current
state-
it
which
I
know
is
not
really
supported,
but
if
anyone
is
playing
around
with
this
they're
going
to
have
a
really
difficult
time,
transitioning
from
or
distinguishing
between
the
crds
that
are
constantly
changing.
In
our
current
repository
and
the
eventual
release
of
v1
alpha
1.,
because
we're
already
using
v1
alpha
1
versioning,
I
think
it
could
confuse
our
eventual
v1
alpha
1.
A
A
B
A
You
know
I
I
think
I
think
we
need
to
make
it
clear
or
clearer
that
anything
we're
doing
right
now
is
not
actually
supported
and
is
actively
changing
that
that
could
probably
use
some
help,
but
I
I
think
there,
I
think,
there's
probably
some
value
just
the
way
that
crds
work
just
having
some
kind
of
different
version,
maybe
v1
alpha
0,
isn't
that
maybe
it
is
pre-release,
I
I
don't
know
pre-alpha,
I'm
not
sure
what
the
what
the
correct
term
is,
but
maybe
that
would
help
identify
that
the
version
we
are
currently
using
and
for
service
apis.
A
B
C
B
Reached
alpha
stability,
yet
so
don't
use
it,
and
if
you
use
it
create
a
four
something
like
that.
D
Then
that
team
became
the
contour
team
and
james
nick
can
manage
any
issues,
but
that
team
is
since
no
longer
on
the
project
either
I'm
in
a
different
part
of
vmware,
but
I
keep
falling
back
into
this.
So
what
we?
The
issue
we
have
right
now,
is
we're
going
to
be
using
some
of
these
crds
and
we're
going
to
be
shipping,
something
ahead
of
when
you
plan
to
lock
v1,
alpha
1.
D
and
if
somebody,
and
so
since
those
crds
be
part
of
a
cluster.
If
someone
were
to
target
those
crds
later,
the
v1
alpha
1
their
targeting
would
be
pretty
different
than
what
it's
already
pretty
different
than
the
ones
we
were
targeting.
And
so
we
had
a
couple.
We
have.
We
outlined
six
options
and
one
and
a
couple
of
the
options,
surrounded
forking
this
project
and
just
creating
a
branch
from
the
commit
we
were
using
and
calling
that
v1
office
zero
and
rob.
D
When
you
and
I
talked
the
other
day,
we
discussed
doing
the
same
thing
upstream,
but
creating
it
from
head-
and
you
said:
well,
that's
probably
fairly
arbitrary,
but
you
would
suggested.
Maybe
we
just
reset
master
to
v1
alpha
zero
and
then,
when
v1
alpha
one
comes
out.
That's
when
we
rev
it
to
the
v
one
alpha
one.
This
is
not
a
y'all
problem,
it's
an
us
problem
and
we
can
manage
it
with
a
fork,
but
it
would
be
nice
to
have
a
little
bit
more.
D
It
would
be
nice
that
v1
alpha
one
represented
like
there
would
be
some
transition
between
a
project
that
has
been
around
for
about
a
year
a
little
longer
and
it's
it's
moving
model
to
its
finished
state
and
as
it
is,
there
will
be
no
transition
right,
it'll
just
be
when
alpha
one
will
suddenly
be
bv
when
alpha
one
and
if
we
set
it
to
v
one
off
of
zero
and
then
moved
it
to
v1
alpha
1.
D
If
somebody
were
to
target
that,
then
we
can
use
the
more
conventional
update
methods
to
upgrade
the
resources
that
would
be
at
v1
office,
zero
to
v1
alpha
one
such
as
conversion
web
hooks
and
whatever.
But
what
we
can't
do
right
is:
we
can't
have
resources
that
be
on
alpha
one
from
an
earlier
build
of
service
apis
and
then
have
people
expect.
You
know
those
crds
to
be
v1
off
of
one
from
a
later
version
of
the
service
apis.
That's
something
we're
going
to
have
to
manage
internally
and
yeah.
A
Yeah
and
and
thanks
thanks
for
the
background
and
filing
this
and
I'll
say
selfishly.
A
That
actually
happen
to
be
older,
copies
of
v1
alpha
1
crds
I
for
for
whatever
reason
and-
and
I
think
just
getting
away
from
that
terminology
before
we're
ready
to
use
that
could
help
us
out
as
well,
just
as
as
a
broader
term
of
easier
supportability.
What
version
of
crds
are
you
using?
Oh
v1,
alpha
one
well,
which
view
one
alpha.
One
yeah.
D
Yeah
for
what
it's
worth,
I
added
a
link
in
chat
to
a
commit
zoom
chat,
yeah
to
to
a
commit
that
I
pushed
a
support
branch
of
one
of
our
fork
and
again
this
is
the
support.
Branch
is
from
an
earlier
version
of
service
api.
So
it's
not
going
to
reflect
pr221,
but
it
did
all
the
work
to
reset
the
schema
version
and
it
would
need
to
be
you
know,
rebased
or
it
would
need
to
be
updated
to
you
know
on
master.
D
D
If
there's
there's
resistance
to
it,
you,
like
you,
said
you
indicated
that
you
thought
it
could
be
valuable
for
upstream,
and
I
agree
that
it
does
give
a
nice
cut
over,
and
I
think
I
put
it
in
the
issue
that
something
you
and
I
discussed
that
we
would
need
explicit
messaging
saying
that
there
is
no
guarantee
of
support
at
v1
alpha
0
and
we
are
not
planning
on
offering
any
conversion
web
hooks
from
v1
alpha
0
to
v1
alpha
1.,
but
at
least,
if
you
have
that
cut
over,
then
you
could
then
say.
A
Yeah
and
it's
this
clear
differentiation
between
pre
pre-release
v1,
alpha
zero,
whatever
you
want
to
call
it
and
an
actual
v1
alpha
one
api,
and
I-
and
I
think
something
like
that
harry
had
mentioned-
is
you
know
I
don't
know
what
you
know
like?
I
don't
know
if
there's
any
prior
art
here,
I
I
feel
like
what
we're
doing
is
relatively
relatively
unique.
A
lot
of
api
design
either
moves
faster
or
is
closely
tied
to
the
release
of
a
single
product.
D
This
is
a
this
is
a
problem
we
created
for
ourselves
and
again
it
was
that
I
was
willing
to
accept,
because
there
were
at
times
two
entire
teams
dedicated
to
this,
but
yeah.
It's
it's
a
unique
situation
because,
again
that
these
apis
have
been
out
there
for
a
while
and
the
other
option
was
to-
and
I
think
what
contour
had
planned
to
do
was
to
fork
both
the
api
version
and
group
name.
D
This
would
at
least
allow
people
to
use
these
models
and
provide
an
upgrade
path
to
whatever
comes
out
eventually
but
you're
right.
I
think
I
think
things
tend
to
be
iterated
faster
this,
and
this
was
a
case.
I
think
I've
said
this
on
this
call
before
right
that
if
you
know
once
I
looked
at
these,
if
I
had
to
build
something
from
scratch,
it
would
have
looked
amazingly
like
this.
D
So
I
was,
you
know,
maybe
wrongfully
so,
but
determined
to
figure
out
how
to
use
these
and
add
value
here
rather
than
just
building
something
from
scratch.
So
I
won't
lie
and
say
it's
not
a
unique
issue.
It
is,
but
I
think
the
kubernetes
api
documentation
right
that
alpha
is
alpha
for
a
reason.
I
think
that
applies
here.
D
You
know
we
decided
to
do
this
and
that's
that's
our
problem,
but
if
there's
a
reason
to
set
main
to
v1
alpha
0,
it
solves
that
problem,
and
maybe
it
adds
value
here
as
well,
but
yeah
cluster
api
is
an
interesting
one.
I've
been
involved
with
that
since
alpha
one
more
far
more
in
alpha
two.
D
I
know
for
a
fact
that
there
were
companies
building
on
their
alpha
one
and
they
were
people
were
really
shocked
to
find
that
out,
but
what
they
did
was
a
little
different.
They
they
focused
on
the
design
first
and
then
added
the
code
later
so
by
the
time
you
know
they
had
the
design
they
were
adding
the
code.
People
already
knew
what
the
spec
was.
D
I
don't
think
they
were
iterating
on
the
spec
and
the
code
at
the
same
time
necessarily
so
I
think
this
is
a
little
different
than
that.
A
Yeah
this
this
feels
like
a
public
experiment
in
api
design
where
we
are
iterating
and-
and
it
could
be
very
easy
to
confuse
what
we
have
here
with
the
v1
alpha
1
api.
B
So
I
think
this
makes
a
lot
of
sense
now.
What
I
would
suggest
we
do
is
we
don't
name
it
alpha
0,
because
then
it
closes
the
door
of
introducing
another
version
between
weave
and
alpha
between
now
and
even
alpha
one
just
in
case.
You
know,
if
andrew's
team
needs
to
do
that,
like
you
know,
they
want
to
put
in
some
more
features
in
case,
or
maybe
somebody
else,
who's
trying
to
experiment
with
it
and
want
to
do
that.
They
can't
do
that
or
some
somebody
between
v
and
alpha
one
and
v.
B
Even
alpha
two
wants
another
release
like
this,
then
that
is
not
a
possibility.
So
if
I
think
kubernetes.
D
C
B
C
So
this
is
not
a
unique
problem
to
this
version.
Right,
yes,
we're
in
this
situation
where
okay,
we
we
said
we're
going
to
work
on
v1,
alpha
1
and
then
we
make
a
bunch
of
changes
and
then
at
some
point
you
release
that
and
it's
frozen
now,
that's
going
to
happen
again
for
v1
alpha,
2,
presumably
and.
B
C
D
But
the
difference
is
the
the
difference
is
and
I'll
use
cluster
api
as
an
example,
they
will
put
together
a
ket
to
say
this
is
what
v1
alpha
2
or
v1
alpha
1
is
going
to
be
right
and
the
community
agrees
on
the
cap
or
kite,
because
I
think
it's
a
ca
ep
there
and
they
agree
on
that
and
then
people
you
know
they
create
issues
off
of
it
and
then
people
iterate
on
those
issues
to
drive
towards
that,
but
the
entire
time.
D
It's
already
understood
what
that
spec
is
going
to
be
and
in
between,
let's
say:
v1,
alpha
1
and
b1.
Alpha
2
they've
been
really
good
about
not
introducing
any
contract
breaking
features
like
anything
that
would
violate
v1
alpha.
Whatever
the
api
contract
is
that
just
gets
pushed
to
the
next
api
version,
I
mean
there,
there
can
be
improvements
and
enhancements,
but
nothing
that
breaks
the
contract.
C
So
they're
doing
it
in
kind
of
a
more
like
you
have
a
group
which
goes
off
and
kind
of
experiments
with
with
code
and
comes
back
and
makes
an
api
proposal,
and
then
you
you
so
you
kind
of
move,
have
discrete
steps
which
move
between
api
versions,
whereas
this
service
api
is
sort
of
doing
it
more
or
yeah
everyone's
everyone's
sort
of
working
on
the
same
spec
as
we
as
we
go.
So
we're
not
moving
the
api
in
step
like
they
do
there.
That's.
D
Interesting,
yeah
and
and
I've
I've
wanted
changes
in
between
there
and
what
you
end
up
doing
is
you
know
filing
an
issue
and
you
know,
gets
marked
for
the
next
api
iteration
and
then
you,
you
know
you
show
up,
and
you
make
your
case
for
that-
that
cap
and
it
either
gets
added-
or
you
know,
doesn't
here,
but
I
mean
you
know
at
some
point.
You
have
to
do
the
first
thing
right
and
you
have
to
get
a
group
of
people
together.
That
has
some
momentum
and
that's
what
happened
here.
D
I
think,
though,
that
there
was
something
between
what
we
have
today
in
service
apis,
and
you
know
t0
that
would
have
been
good
enough
for
v1
alpha
zero,
or
even
I
mean
I
would
argue,
probably
at
doing
off
too.
There
would
have
been
something
right.
This
has
just
been
baking
for
so
long
that
yeah,
I
think
that
was.
D
D
I
realized
this.
The
rest
of
the
sentence
didn't
qualify.
What
I
said
there
would
be
so
much
shift
left
between
when
we
pick
this
up
and
what
would
eventually
be
v1
alpha
one
and
that's
mine.
I
ever
tell
you
because
cluster
api
was
really
the
first
time
I
was
so
heavily
involved
in
the
kubernetes
process.
I
just
kind
of
thought:
that's
how
other
processes
work,
so
that
was
my
bad.
C
A
There
are
I'm
trying
to
think
I've
seen.
I
think
john
howard,
with
istio
may
have
had
a
real.
It's
not
a
complete
implementation,
but
there
is
something
somewhere
that
implement
implements
a
part
of
this
spec.
D
A
Good
to
know
right,
yeah
and
we're
we're
also
working
on
an
internal
implementation
of
this
that
that
works
for
some
parts
of
the
api
as
well
so
yeah
yeah
there.
There
is
work
against
the
api
that
has
not
gone
v1
alpha
one,
yet
I
know
there's,
obviously
you
know
everything
we're
working
towards.
I
think
a
great
deal
of
the
meeting,
if
not
today,
tomorrow,
will
be
about
the
the
last
few
things
we
need
before
v1
alpha
1
release,
but
that
v1
alpha
1
release
is
not
coming
in
a
time
frame.
A
D
And
to
be
clear,
our
fork
locks
it
currently
at
the
version
we
were
using,
so
it's
not
even
off
of
master,
but
if,
even
if,
even
if
the
decision
will
upstream
we're
going
to
set
it
to
v1
office,
0.,
it's
not
going
to
be
locked,
but
it's
going
to
main
would
be.
V
went
off
to
zero,
that's
still
a
better
situation
than
we
have
today,
because
we
would
tell
other
people
who
want
to
target
our
clusters.
Even
though
they'll
be
one
up
to
zero,
they
should
be
targeting
what
will
be
viewing
alpha
one.
D
D
No
one
else
would
be
using
that
and
it
gives
us
a
upgrade
path
with
convergent
web
hooks
and
whatever
else
we
need
to
do
so,
even
if
it
wasn't
locked,
it
would
be
better
than
what
there
is
today,
because
it
wouldn't
just
be
v1a1
to
v1a1,
and
at
that
point
I'm
not
even
sure
what
we
would
do
we'd
have
to.
D
D
A
Yeah
yeah,
and
for
me
you
know
just
going
back
to
my
primary
motivation
behind
this
is
just
making
it
clear
that
what
we
have
now
is
not
v1
alpha,
1,
that
what
what
we
are
currently
working
towards
is
working
towards
v1,
alpha
1,
but
the
crds
do
not
represent
v1
alpha
1,
crds
or
any
part
of
that
api.
Yet,
and
and
to
one
of
james
points,
is
a
good
one
that
we
will
deal
with
this
again.
A
A
D
Can
tell
you
I
can
tell
you
what?
How
would
you
do
that
yeah?
I
can
tell
you
what
cluster
api
does
they?
They
do
the
cap
thing
right
and
then
they
slowly
iterate
on
main
to
a
point
where
they
have
to
update
their
apis.
At
that
point
they
update
their
apis.
They
change
their
schema
version
on
main,
but
before
that
they
create
a
long-lived
release
branch
where
they
do
any
back
ports
they
need.
So
if
they've
got
you
know,
let's
say
it's
cluster
api
version,
you
know,
v1
alpha
3
would
be
view.
D
You
know
v031
v032,
that's
where
their
patch
releases
are
for
those
previous
versions,
but
they
basically
do
the
cut
over
on
main
to
the
new
version,
once
the
are
ready
and
the
code
compiles
and
they're,
actually
something
that
I've
never
been
quite
comfortable
with,
but
you
know
it
works
is
though
maine
can
be
broken.
They'll
leave
maine
in
a
broken
state,
because
they've
they're
not
iterating
towards
deciding
what
the
spec
is.
That's
already
been
decided,
they're,
iterating
maine,
to
make
to
be
up
to
date
with
the
spec
that
has
been
decided
in
the
meantime.
D
They've
got
those
long-lived
release
branches
where
they
do
any
back
ports
or
any
bug
fixes
to
previous
releases.
C
So
maybe
another
as
a
kind
of
a
simpler
approach
for
this
project
could
be
to
have
like
a
pre
tag
in
the
version.
So
when,
when
we
iterate
when
we're
actually
working
on
main
on
v1
alpha
2,
maybe
you
could
call
it
v1,
alpha
pre
pre-two
and
then,
when
you're,
ready
to
when
you're
ready.
When
when
we're
actually
shipping
it,
then
you
you
branch
and
you
version
that
v1
alpha
pre,
two.
D
And
it
would
have
to
be
one
r2
would
have
to
be
v1
alpha,
2
pre.
I
think,
because
of
the
the
sorting
convention
for
the
kubernetes
resource
versions,
but
yeah.
D
I
mean
so,
do
you
know
what's
really
odd
about
all
this
we've
had
these
discussions
in
cluster
api
as
well.
They
events,
especially
you
know,
wants
to
go
back
to
this
is
all
alpha.
It's
right
there
in
the
schema,
except
it's
also
not
right.
People
are
building
products
on
it
and
it's
being
managed
like
a
real
product.
It
we
got
into
an
issue
with
github's
version
numbers,
because
you
can't
actually
do
it
when
we
were
doing
the
releases
and
the
github
repo.
Did
you
mark
these
things
as
pre-release
or
release
right?
D
D
If
you're
going
to
continue
to
do
what
you're
doing
now
and
you're
just
iterating
on
main
towards
a
spec
as
opposed
to
sitting
down
and
figuring
out,
the
spec
is
first,
then
I
think
that
makes
sense,
but
I
would
check
with
other
repository
other
projects
as
well.
I
can
only
speak
from
experience
with
cluster
api.
C
Yeah
because,
like
for
service
apis,
it's
kind
of
it
sounds
like
in
cluster.
Api
teams
go
away,
they
they
iterate
kind
of
off
in
other
forums,
and
then
they
bring
it
back
to
the
working
group.
D
C
D
Well,
I
mean
that's,
that's
definitely
one
way
to
do
it,
but
it
may
also
be
worth
trying
like
getting
together
and
sitting
down
and
deciding
what's
needed,
and
I
think
it's
just
more
planned
right
and,
as
you
have
more
contributors
and
you
have
more
stakeholders
knowing
where
it's
going
versus
figuring
it
out
along
the
way,
I
think
can
be
valuable.
A
That
you
know,
while
we're
talking
about
this,
are
there
other
projects
in
the
community
that
are
using
a
similar
model?
You
know,
like
this
whole
concept
of
a
a
set
of
apis
for
kubernetes
that
are
basically
just
crds
they're.
Not
this
may
eventually
become
core
like,
but
it's
not
at
least
initially.
That
way
are
there.
Are
there
other
good
examples
of
api
design?
This
way,
like,
I
obviously
think,
of
cluster
api,
but
I'm
not
aware
of
many
others
doing
this
that
aren't
tied
to
a
very
specific
product.
D
A
Yeah
all
right
well,
this
is
this
is
very
helpful.
I
I
think
I'm
interested
in
additional
feedback
on
this
pr,
but
I
if,
if
I'm
understanding
the
discussion
so
far,
it
seems
like
there's
sufficient
support
for
moving
away
from
v1
alpha
1
to
some
other
versioning.
D
It
it
does
and
the
one
thing
you
could
do
once
you
release
v1
alpha
1,
to
avoid
this
without
doing
anything
else,
create
a
long-lived
release
branch
called
release,
v1
that
would
be
like
v1
0
or
just
like
release
v1
and
then
everyone
would
understand
main
is,
is
not
stable.
Your
stable
branches,
release,
v1
and
main
is
where
you're
doing
active
development,
so
at
least
you
will
always
have
at
that
point
a
locked
or
a
release
that
will
never
deviate
from
that
contract.
D
A
D
Ironically,
the
same
reason
that
I
could
argue
it
doesn't
matter
if
the
reason-
I'm
is
the
reason
I'm
asking
to
do
it,
it's
alpha.
So
what
does
it
matter?
What
we
do,
but
then,
at
the
same
time,
then
we
should
be
using
the
crds
right,
but
I
think
the
bottom
line
is
people
are
using
this,
regardless
of
what
the
technical
rules
are.
I
think
it
goes
back
to
what
I
said.
This
is
really
well
designed
and
people
want
to
use
yeah
yeah.
A
Well
appreciate
that,
and
hopefully
we
can
make
it
even
better
yeah
all
right.
Well,
I
think
I
think
this
is
good
enough
for
an
initial
discussion.
I
know
I
need
to
to
reach
out
to
john
for
istio
team
just
to
make
sure
I
don't
think
this
will
be
an
issue
for
them
and
I'll
I'll
look
for
some
broader
feedback
as
a
whole.
A
Discussion
or
yeah
open
a
pr,
even
but
even
just
capturing
part
of
this
discussion
either
in
the
agenda
or
in
this
issue,
would
be
would
be
awesome.
D
But
I
yes,
okay,
once
the
recording
is
up,
I
can
go
back
and
okay
kind
of
take
some
broad
notes.
I'll,
probably
just
do
it
in
the
issue,
if
that's
okay
with
everybody
or.
B
D
A
Okay
sounds
great
thanks
all
right.
Well,
there
were
a
couple
other
issues
that
I
thought
were
worth
mentioning
and
one
I
I
thought
was
especially
interesting
was
raised
by
mark,
and
this
is,
I
actually
chatted
with
him
a
bit
offline,
because
I
wanted
to
understand
this
a
little
bit
better,
so
I
could
at
least
explain
how
I
understood
it,
but
he
he
is
proposing
some
additional
versioning
that,
as
as
I
understand
it
and
mark,
I
don't
think,
is
on
this
call.
A
So
he
can't
correct
me,
but
hopefully
my
understanding
is
reasonably
good.
Here
there
there
was
some
level
of
desire
to
add
some
kind
of
versioning
to
the
way
an
input
implementation
interprets
an
api,
so
there
may
be
a
different
versioning
of
a
release,
but
there
may
also
be
within
that
release
different
ways
to
it
slightly
different
ways
to
interpret
the
same
field.
A
I
I'm
hoping
these
are
relatively
rare,
but
I
I
could
see
a
variety
of
potential
cases
where
our
spec
cannot
be
quite
specific
enough
and
an
implementation
may
want
to
have
this
additional
level
of
versioning
so
to
anyone
who's
currently
working
on
an
implementation
or
thinking
about
implementations.
A
D
To
me,
it
seems
like
an
implementation,
specific
issue
like
a
vendor
specific
issue.
Like
the
easy
answer
is,
you
would
have
multiple
controllers
that
would
key
on
some
field.
You'd
have
one
controller
that
would
decide
what
to
do
based
on
some
fields,
but
I
mean
this
is
either
a
issue
broader
than
this
project
and
applies
to
many
other
projects
or
it's
a
vendor-specific
detail.
That's
what
annotations
are
for.
A
Yeah
yeah
and
we
we
do
have
gateway
class
parameters,
which
you
know
I
I
think
is
likely
the
place
for
this,
but
it
was.
I
think
this
this
issue
was
brought
up,
because
there
was
some
some
idea
that
this
might
apply
to
more
vendors,
that
more
more
potential
implementations
would
have
this
same
kind
of
version
and
consideration,
and
it
might
be
something
like
that,
instead
of
being
implementation,
specific
was
useful
to
other
use
cases,
but
it
sounds
like
there
is
not
a
whole
lot
of
interest.
D
What
is
this
sorry
sorry
rob
is
this
specific
to
get
did
mark
indicate
whether
this
was
specific
to
gateway
class
or
not,
because
that
changes
that
can
change
things,
because,
if
I
think
about
from
a
a
vendor
perspective,
let's
say
it's
aj
proxy
or
hobby
they're
going
to
have
all
these
other
resources
they're
going
to
have
gateway
resources
and
route
resources.
That
may
also
be
subject
to
this,
how
they
interpret
these
fields.
That's
why
I
mentioned
annotation.
D
You
mentioned
parameters
which
leads
me
to
believe
that
it's
specific
the
gateway
class.
Well,
if
it's
parameters,
then
they
should
just
point
that
to
different
versions
of
a
resource
like
they
could
have
config
version,
one
config
version
two
can
be
so
I'm
saying
else
it
seems
like
it
would
apply
to
all
of
the
resources
associated
with
their
implementation,
not
just
gateway
class
yeah,
but
I
I
don't
know
because
mark
isn't
here.
A
Yeah,
no,
I
I
think
you're
right,
I
mean
a
lot
of
the
different
examples
we
talked
through
were
were
related
to
new
features,
being
added
or
new
functionality
being
added
or
slightly
different
interpretations
of
specific
fields
and
in
all
cases
it
felt
like
something
that
maybe
could
be
handled
by,
like
you
say,
an
annotation
or
if
it's
a
higher
level
thing
a
parameter
in
gateway
class
or
a
new
version
of
the
controller
implementation.
D
A
Over
time,
no
no,
this
is
this.
Is
the
implementation
now
supports
feature
x
or
implementation?
Now
has
a
different
way
of
handling
this
type
of
route-
optionally,
maybe
oh,
and
and
as
an
example,
we
don't.
We
don't
actually
have
this,
but
this
is
a
a
rough
example.
A
Maybe
the
first
version
of
the
implement
implementation
used,
regex,
pcf,
a
specific
form
of
regex
and
the
next
version
of
the
implementation
added
support
for
a
different
form
of
regex,
and
there
was
some
way
to
say,
oh
by
the
way,
I'd
rather
use
this
kind
of
regex
for
everything,
and
but
I
that
feels
like
an
implementation,
specific
parameter
at
that
point.
So.
D
Yeah
yeah,
okay,
multiple
versions
of
word
that
operate
on
the
spec
for
a
document
version,
but
they're
backwards
compatible
or
forwards
compatible
based
on
the
features
of
the
newer
versions
of
the
word
processor.
It
feels
like
that's
what
this
is
yeah
agreed,
so
at
best
I
would
say
like
there
could
be
something
specific
to
like
extensions
or
something,
but
this,
like
I
said,
feels
broader
than
just
this
seems
like
something
that
would
impact
anything
that
use
crds,
yeah.
A
Yeah
I'll
have
to
I'll
have
to
check
back
in
with
him
and
make
sure
I'm
understanding
this
properly,
but
I
think
I
agree
with
that
that
conclusion
as
well
yeah
and
those
are
those
are
the
two
issues
that
came
in
in
the
past
week.
The
other
ones
we've
already
discussed
in
some
form
they're
about
new
protocols
and
a
variety
of
other
things.
There
is
one
issue:
oh
did
I
maybe
it
already.
It
already
got
merged,
never
mind
okay.
A
So
there
was
one
issue
created
that
all
our
examples
were
out
of
date.
This
ended
up
being
a
bigger
pr
than
I
thought,
and
I
will
give
credit
where
credit
is
due.
This
would
not
have
come
up
if,
if
james
pr
had
been
in
so
I
am
excited
for
james
verifier
to
make
it
in,
and
I
I
think,
bowie's
gonna
gonna
give
a
look
at
this
today.
I
I
hope.
C
Yeah,
it
helped
me
when
I
tried
to
do
some
examples,
but
yeah
there's
still
validation,
it's
still,
but
there's
still
validation,
which
can
bite
you,
oh
right.
This
will
check
the.
B
A
B
A
Yeah,
the
the
required
fields
and
a
variety
of
other
things
that
that's
a
great
point
and
and
one
of
the
things
I
ran
into
with
our
examples
as
they
exist,
and
is
that
we
we
have
one
example
right
now
that
specifies
a
namespace,
a
non-standard
namespace,
and
it
makes
sense
like
that
that
namespace
makes
sense
in
the
context
of
the
example.
I
think
it's
ssh
server
or
something
like
that,
but
that
doesn't
just
exist
so
just
running
a
coupe
cuddle
apply.
Examples
is
going
to
fail.
If
you
don't
have
that
that
namespace
around.
C
A
Yeah
yeah,
so
overall
I
I
think
I
think
we're
making
progress
here.
I
this
kind
to
route
finding
selector,
I
think,
was
also
generally
positive
and
all
the
feedback
has
been
responded
to
last.
I
checked
and
approved
and
just
needs,
maybe
one
more
lgtm
or
approval
at
this
point,
but
this
this
should
help
in
in
a
in
a
vast
number
of
things,
and
I
think
those
are
the
big
changes
that
have
happened
in
the
past
week.
A
I
should
also
mention
for
anyone
that
didn't
notice
the
oh.
This
is
way
down
here,
because
it's
an
old
pr
but
john
created
a
pr
to
autogen,
client,
lister
and
informers
for
everything
I
it
was
a
relatively
large
change,
but
fortunately
did
not
add
any
new
dependencies.
It
just
added
more
cogen,
unfortunately,
but
this
should
help
implementations
either
be
easier
to
use,
or
certainly
more
scalable
if
we're
dealing
with
thousands.
D
I
did
add
a
note
later
that
the
change
to
the
name
of
the
directory
is
sort
of
orthogonal
to
the
direction
of
other
projects.
I
know
this
isn't
necessarily
based
on
cube
builder.
I
had
one
note
that
was
wrong
because
I
thought
he
had
added
some
dependencies
because
that
client
set
generator
often
does,
but
in
this
case
it
didn't,
but
the
api
directory
rename
is
gonna
seem
odd
to
other
people
working
on
things
that
are
based
on
q
builder,.
D
D
B
D
Seeing
these
projects
put
everything
in
the
root
directory
now
same
same
deal,
and
the
issue
is
around
a
lot
of
the
the
generator
code
which
still
expects
the
older
layout,
which
is
what
he
hits
yeah
and
I'm
part
of
that
is
because
I
think
they're
trying
to
deprecate
some
of
that,
because
people
are
tending
to
move
away
from
the.
I
even
asked
this
question
as
well.
A
I
know
I
know
the
concern
had
been
around
the
be
larger
larger
potential
scale
like
if,
if
someone
has
say
thousands
of
routes
in
their
cluster
or
something
like
that,
you
might
start
to
notice
the
the
difference
in
performance
between
dynamic,
client
and
and
everything
that
it
has
to
do
versus
be
generated
clients,
but
but
that's
a
good
point
about
the
the
rename
and
not
and
now
non-standard
project
structure
where
we're
we're
not
quite
a
cube
builder
project
structure
anymore,
but
we're
also
not
the
the
standard.
A
D
D
And,
quite
frankly,
if
you
ever
do
go
to
the
design,
the
spec
up
front,
then
you
could
potentially,
you
know,
make
this
change
to
generate
the
clients,
then
change
the
folder
back,
and
you
would
have
to
do
that
whenever
you
want
to
generate
the
clients.
But
ideally
you
know
you
only
ever
do
that
when
the
api
changes
yeah.
A
Yeah
yeah,
that
you
know
the
whole
idea
of
generating
a
spec
up
front
is
is
interesting,
and
it's
certainly
something
that
I
think
this
project
kind
of
started
with
and
tried
for
a
bit
in
the
sense
that
we
we
had
this
doc
and
there
were
just
tons
of
comments
on
it
back
and
forth
about
every
little
component
and
at
some
point
I
think
it
got
too
complicated
for
us
and
it
was
deemed
that
this
was
maybe
easier
or
more
straightforward.
A
I
don't
know
if
that
was
a
good
or
bad
decision,
but
it
it
is
nice
to
have
the
get
history
associated
with
this.
Where
it,
you
know,
a
google
doc,
as
we
were
using
before.
If,
if
something
changes,
it's
harder
to
see
the
history
or
rationale
behind,
not
not
that
it's
particularly
easy
with
git
commits,
but
it's
at
least
somewhat
more
straightforward
to
go
back
to
to
different
versions
and
and
see
who
changed
and
why
but
yeah
that
yeah.
A
Maybe
we
can
revisit
that
approach
as
I
imagine
future
alphas
will
be
more
iterative
instead
of
just
we
have
to
think
everything
from
the
ground
up
with
this
viewing
awful
one
yeah
on
the
on
the
inversion
value
that
like,
if
we're
moving
away
from
v1
alpha
1
for
the
time
being
until
we
actually
get
to
a
v1
alpha,
1
respon
release
was
the
preference
to
call
it
v1
alpha,
0
or
v1
alpha
1
pre.
D
D
D
It
looks
like
one
way
to
do:
it
would
to
be
to
not
have
the
v
prefix,
because
it's
always
going
to
get
sorted
at
the
bottom.
So
if
that
makes
sense,
you
could
follow
the
same
convention.
Otherwise,
and
you
know
you
could
be
like
v
one
alpha
one,
but
instead
of
v
it
could
be
like
p
one
alpha
one.
I
don't
know,
but
I
would
assume
to
see
an
r
there
for
release
at
some
point
because
the
you
know
the
way
people
used
to
do
that.
D
A
Okay,
well,
I
think
that's
everything
we
had
to
discuss
today
before
we
before
we
call
it
a
day.
Is
there
anything
that
I've
missed
or
anything
that
someone
wants
to
discuss.
A
Cool
well,
thank
you
so
much
everyone
for
the
great
feedback
here
and
I
will
follow
up,
but
I
guess
I'll
follow
up
on
that
issue,
specifically
I'll
reach
out
to
john
and
also
check
in
with
bowie
as
far
as
his
thoughts
here
and
if
anyone
else
wants
to
comment
that
would
be
great
for
a
bit
more
context.