Jay Pipes wrote:
> On Tue, 2014-01-14 at 11:45 +0800, Christopher Yeoh wrote:
>> On Tue, Jan 14, 2014 at 10:59 AM, Jay Pipes
>> wrote:
>>
>> We don't need API extensions and they make our Compute API
>> laughably complex and cumbersome. We should ditch entirely the
>> concept
On Tue, Jan 14, 2014 at 3:36 AM, Christopher Yeoh wrote:
> On Tue, Jan 14, 2014 at 1:12 PM, Jay Pipes wrote:
>
>> On Tue, 2014-01-14 at 11:45 +0800, Christopher Yeoh wrote:
>> > On Tue, Jan 14, 2014 at 10:59 AM, Jay Pipes
>> > wrote:
>> >
>> > We don't need API extensions and they make
On 01/14/2014 12:12 AM, Jay Pipes wrote:
> On Tue, 2014-01-14 at 11:45 +0800, Christopher Yeoh wrote:
>> On Tue, Jan 14, 2014 at 10:59 AM, Jay Pipes
>> wrote:
>>
>> We don't need API extensions and they make our Compute API
>> laughably complex and cumbersome. We should di
On Tue, Jan 14, 2014 at 1:12 PM, Jay Pipes wrote:
> On Tue, 2014-01-14 at 11:45 +0800, Christopher Yeoh wrote:
> > On Tue, Jan 14, 2014 at 10:59 AM, Jay Pipes
> > wrote:
> >
> > We don't need API extensions and they make our Compute API
> > laughably complex and cumbersome. We sh
On Tue, 2014-01-14 at 11:45 +0800, Christopher Yeoh wrote:
> On Tue, Jan 14, 2014 at 10:59 AM, Jay Pipes
> wrote:
>
> We don't need API extensions and they make our Compute API
> laughably complex and cumbersome. We should ditch entirely the
> concept of API extens
On Tue, Jan 14, 2014 at 10:59 AM, Jay Pipes wrote:
>
> We don't need API extensions and they make our Compute API laughably
> complex and cumbersome. We should ditch entirely the concept of API
> extensions in our next Compute API major release.
>
>
I think it way too late in the cycle to make th
Caution! Long and opinionated response.
tl;dr:
A versioned API with no API extensions is *not* a static API. If you
want to look at a heavily versioned API without extensions for a Compute
control API that has successfully evolved over the years to meet its
customers' needs, you need look no furt
On Mon, Jan 13, 2014 at 11:15 PM, Jay Pipes wrote:
> On Mon, 2014-01-13 at 09:40 -0500, Ryan Petrello wrote:
> > Jay, I’ll +1 to that. As I’ve been tinkering with potential Pecan
> support for the Nova API, I’ve run into the same issue w/ the API
> composition being seriously complicated (to the
On Mon, 2014-01-13 at 09:40 -0500, Ryan Petrello wrote:
> Jay, I’ll +1 to that. As I’ve been tinkering with potential Pecan support
> for the Nova API, I’ve run into the same issue w/ the API composition being
> seriously complicated (to the point where I’ve realized Pecan isn’t the hard
> part
Jay, I’ll +1 to that. As I’ve been tinkering with potential Pecan support for
the Nova API, I’ve run into the same issue w/ the API composition being
seriously complicated (to the point where I’ve realized Pecan isn’t the hard
part, it’s the bunch of cruft you need to tie in Pecan/Routes/Falcon
On Sun, 2014-01-12 at 19:52 -0800, Christopher Yeoh wrote:
> On my phone so will be very brief but perhaps the extensions extension
> could publish the jsonschema(s) for the extension. I think the only
> complicating factor would be where extensions extend extensions but I
> think it's all doable.
On my phone so will be very brief but perhaps the extensions extension could
publish the jsonschema(s) for the extension. I think the only complicating
factor would be where extensions extend extensions but I think it's all doable.
Chris
—
Sent from Mailbox for iPhone
On Mon, Jan 13, 2014
> > Last, is a question, is it possible to currently run the full API an build a
> > json schema for it all? Or to query these validating schemas? We *really*
> > want that over in tempest, so we can completely drop the manual creation of
> > negative testing, and just fuzz known bad against the s
Hi Sean,
Thank you for reviewing patches,
2014/1/12 Sean Dague :
> Ken'ichi,
>
> I've been going through a bunch of the API validation reviews, and while the
> specifics are fine, there are some overarching style patterns that I think
> we might want to change.
>
> First, the decorator -
>
> @val
14 matches
Mail list logo
