I'm a huge fan of Peter Coad in the area of software architecture.
One of the largest hurdles to overcome is the separation between code
& design. The larger the gap, the more they diverge and the greater
the inconsistencies become. Many tools (like xdoclet, Together, etc.)
have focused on keepin
I don't necessarily agree with that approach. I'm not sure if that's the way
AWS does things or not, but you will note that the AWS APIs are very fragmented
across projects.
I think there are several principles that may at times be in conflict that need
to be in place:
* Any GA feature should
This is on the agenda for Tuesday's policy board meeting (in #openstack-meeting
1 hour before the weekly OpenStack team meeting for those interested). Sounds
like a potentially acceptable solution is to set some cross-project API
standards and then push the remainder of the API definition and im
On 8/26/11 1:19 PM, "Devin Carlen" wrote:
>There have been a lot of efforts lately to bring the feature set of the
>OpenStack API in line with the EC2 API, and this is admirable. But this
>has NOT been happening at the architect level. This has been happening
>at the developer level, and it i
I have an api, diablo nova v1.1.
What we are talking about is if it covers 100% functionality.
I can start my deployment testing with v1.1. The limiting factor is not v1.1
vs v1.x for most sites. It is packaging, user exits and integration, not
whether feature X is in the latest API.
Tim.
--
A cloud platform simply isn't functional without an API. It is a core
requirement.
No API, no cloud.
-George
On Aug 27, 2011, at 7:04 PM, Tim Bell wrote:
> I'm also a non-API expert but getting a stable open cloud engine with a
> reasonable API would seem to be a good target before we look to
I'm also a non-API expert but getting a stable open cloud engine with a
reasonable API would seem to be a good target before we look to enhance it.
There are lots of potential users of Nova (including Rackspace) who would like
to get Nova into production. An API will fully exploits all of the u
The Rackspace compute API is actually one of the better cloud APIs out there.
It's a pretty damn good basis for an OpenStack Nova API.
EC2, on the other hand, is a pretty obnoxious API and I've already outlined my
thoughts on its role as a defacto API on my blog.
Having said that, there is bas
Preface: I am not very familiar with Nova.
On 08/26/2011 01:19 PM, Devin Carlen wrote:
> I believe we should have had a Rackspace API module just like we have
> an EC2 API module. Then the OpenStack API wouldn't have been
> burdened by the historical decisions around the Rackspace API.
>
> But t
Devin,
Thank you for putting this so eloquently. I cannot agree more
+1000
On Aug 26, 2011 11:38 AM, "Devin Carlen" wrote:
> Hey all,
>
> I've been following the code vs architect debate that's been unfolding
over the past week or so. Here are some of the problems I've seen from my
point of view
You couldn't be more correct.
The words I would use to describe this scenario are: "unacceptable" and
"inexcusable".
On Aug 26, 2011, at 7:19 PM, Devin Carlen wrote:
> Hey all,
>
> I've been following the code vs architect debate that's been unfolding over
> the past week or so. Here are som
++
-Dolph
On 08/26/2011 02:46 PM, Mark Collier wrote:
> +1
>
>
>
>
> On 8/26/11 1:19 PM, "Devin Carlen" wrote:
>
>> Hey all,
>>
>> I've been following the code vs architect debate that's been unfolding
>> over the past week or so. Here are some of the problems I've seen from
>> my point of vie
2011/8/25 Jorge Williams :
>> On Aug 24, 2011, at 12:02 PM, Soren Hansen wrote:
> 2011/8/24 Jorge Williams :
> Okay, I do remember these, but the talks focus on documenting what the
> implementation does. I'm all for it, docstrings are good, but that's not
> what I usually think of a specification
+1
On 8/26/11 1:19 PM, "Devin Carlen" wrote:
>Hey all,
>
>I've been following the code vs architect debate that's been unfolding
>over the past week or so. Here are some of the problems I've seen from
>my point of view. Fundamentally, the process we have now for defining
>API specs is broke
Hey all,
I've been following the code vs architect debate that's been unfolding over the
past week or so. Here are some of the problems I've seen from my point of
view. Fundamentally, the process we have now for defining API specs is broken.
I don't believe that this can be argued. The firs
>
> That analysis omits a very important third party: users of the API.
>
>
+1
Users of the API are one of the audiences for docs.openstack.org. Another
audience is system admins standing up clouds.
I'd like to revise the docs landing page to better serve users of all of the
OpenStack APIs - Comp
Thierry wrote:
> And now, the architects vs. developers discussion :)
> I hear both sides of the argument, and I think both have very valid
points.
> However, so far we have been following the "architect" way (design
upfront and separately from code),
> and it's failing miserably.
That analy
On Aug 24, 2011, at 12:02 PM, Soren Hansen wrote:
2011/8/24 Jorge Williams
mailto:jorge.willi...@rackspace.com>>:
Let me start by saying that I have no idea why we're having this
discussion again. We talked about it at the design summit and we
agreed we'd move forward in pretty much exactly the
2011/8/25 Mellquist, Peter :
> but ... in regard to API design this approach leaves something to be
> desired. There is much value in designing the APIs up front to ensure
> consistency, a cohesive presentation model and to ensure that API best
> practices are followed. APIs need to be designed
And now, the architects vs. developers discussion :)
I hear both sides of the argument, and I think both have very valid points.
However, so far we have been following the "architect" way (design
upfront and separately from code), and it's failing miserably.
I'm a bit tired to see developers spe
AM
To: Jorge Williams
Cc:
Subject: Re: [Openstack] API Spec
2011/8/24 Jorge Williams :
>> Let me start by saying that I have no idea why we're having this
>> discussion again. We talked about it at the design summit and we
>> agreed we'd move forward in pretty much ex
2011/8/24 Jorge Williams :
>> Let me start by saying that I have no idea why we're having this
>> discussion again. We talked about it at the design summit and we
>> agreed we'd move forward in pretty much exactly the way Vish describes
>> it.
> I believe I attended all discussions on the compute A
Inline:
On Aug 23, 2011, at 4:40 PM, Soren Hansen wrote:
> Let me start by saying that I have no idea why we're having this
> discussion again. We talked about it at the design summit and we
> agreed we'd move forward in pretty much exactly the way Vish describes
> it.
>
I believe I attended al
On Mon, 2011-08-22 at 21:12 -0500, Anne Gentle wrote:
> I think it makes sense to have an openstack-api project with all the
> API docs (specs and learning materials) gathered in one place. I think
> it's preferable to have the API separated out from the code for
> several reasons - ease of review,
Let me start by saying that I have no idea why we're having this
discussion again. We talked about it at the design summit and we
agreed we'd move forward in pretty much exactly the way Vish describes
it.
2011/8/23 Jorge Williams :
> I don't have a problem moving the spec out of docs manuals and
What behavior we encourage has little to do with whether the extension
mechanism is there or not. I certainly think we need to encourage companies to
work together with the community to define capabilities that will make it into
core. We need to make sure that process works well and is open an
2011/8/23 Jorge Williams :
> Imagine
> that Rackspace comes up with a feature to perform backups and places it in
> /backups. HP comes up with it's own backup feature and also puts it in
> /backups. The features are different so a client expecting Rackspace backup
> will break when it encounters a
I'd love to keep you on as a reviewer Anne, having you in the loop is really
helpful -- I don't want to lose that aspect of it. I agree that we need a
better governance model.
+1 on separate repos for books though that doesn't necessarily have to be 1:1.
-jOrGe W.
On Aug 23, 2011, at 10:19 AM
Couple of reasons from my perspective:
We've got to get me out of the loop for reviews of the API spec - I'm happy
to review and would like to be a reviewer of all the API docs for OpenStack,
but we need better governance of API updates.
Also, my goal was to move doc source to github prior to Oct
No problems with anything you say below...
-jay
On Mon, Aug 22, 2011 at 9:59 PM, Vishvananda Ishaya
wrote:
> Inline
>
> On Aug 22, 2011, at 4:15 PM, Jay Pipes wrote:
>
>> It may be just me, but having DocBookXML in the source tree is hideous
>> to me. Not only does it clutter the source tree wit
I'm not proposing that the API be frozen solid. I'm all for making changes to
the API in a backward compatible manner. In fact, I think most changes should
come in this way, which is why versions of the *core* API shouldn't have to
change frequently, but the API itself may be under constant ra
Vishvananda Ishaya wrote:
> Ultimately I would like the spec to be generated from the code, but as a
> first pass, we should at least be able to edit the future version of the
> spec as we make changes. I've proposed the current version of the spec
> here:
>
> https://code.launchpad.net/~vishvana
That sounds fair. I listened to Linus talk about a similar thing when
in the early days they tried to pack in features, and only later
started to try and constrain what got into the "core". There was some
interesting debate about the new features as they often didn't know
how they would be best u
I say we up the version number when we can't ensure backward compatibility. As
to how long older versions should be supported. Hard to say. It depends on a
lot of factors, and at the end of the day it may come up to how popular a
version is and how willing and able operators and client devs
Inline
On Aug 22, 2011, at 9:12 PM, Anne Gentle wrote:
I think it makes sense to have an openstack-api project with all the API docs
(specs and learning materials) gathered in one place. I think it's preferable
to have the API separated out from the code for several reasons - ease of
review, e
On Aug 22, 2011, at 8:59 PM, Vishvananda Ishaya wrote:
> Inline
>
> On Aug 22, 2011, at 4:15 PM, Jay Pipes wrote:
>
>> It may be just me, but having DocBookXML in the source tree is hideous
>> to me. Not only does it clutter the source tree with non-RST
>> documentation, but as you know, review
Comments inline
On Aug 22, 2011, at 9:05 PM, Vishvananda Ishaya wrote:
> Inline
> On Aug 22, 2011, at 4:59 PM, Jorge Williams wrote:
>
>> Hi Vish,
>>
>> I don't have a problem moving the spec out of docs manuals and into another
>> project even the nova repo. But, I do have a number of issue
Christopher,
I agree that a feature that is generically applicable to all implementations
should be in the core API. I also agree that we should be having debates at
proposal time rather than merge time -- which is one of the benefits of having
a separate spec -- we can debate the spec before
Inline
On Aug 22, 2011, at 4:59 PM, Jorge Williams wrote:
> Hi Vish,
>
> I don't have a problem moving the spec out of docs manuals and into another
> project even the nova repo. But, I do have a number of issues with the
> approach that you're proposing. First, I think that fundamentally the
I think it makes sense to have an openstack-api project with all the API
docs (specs and learning materials) gathered in one place. I think it's
preferable to have the API separated out from the code for several reasons -
ease of review, ease of check out, also for learning materials for the API
it
I agree the Specs shouldn't change often ... but just to use your
examples, they where all simplifications of larger specs that took
years to create.
If an API changes and is deprecated, how long does backwards
compatibility stay in place?
Thanks,
Thor W
On Mon, Aug 22, 2011 at 5:49 PM, Jan Drak
Inline
On Aug 22, 2011, at 4:15 PM, Jay Pipes wrote:
> It may be just me, but having DocBookXML in the source tree is hideous
> to me. Not only does it clutter the source tree with non-RST
> documentation, but as you know, reviewing diffs of XML is just about
> makes people want to slit their thr
+1
On Aug 22, 2011, at 5:06 PM, Jay Pipes wrote:
> ++
>
> On Mon, Aug 22, 2011 at 7:59 PM, Jorge Williams
> wrote:
>> Hi Vish,
>> I don't have a problem moving the spec out of docs manuals and into another
>> project even the nova repo. But, I do have a number of issues with the
>> approa
++
On Mon, Aug 22, 2011 at 7:59 PM, Jorge Williams
wrote:
> Hi Vish,
> I don't have a problem moving the spec out of docs manuals and into another
> project even the nova repo. But, I do have a number of issues with the
> approach that you're proposing. First, I think that fundamentally there
>
Hi Vish,
I don't have a problem moving the spec out of docs manuals and into another
project even the nova repo. But, I do have a number of issues with the
approach that you're proposing. First, I think that fundamentally there should
be a decoupling of the spec and the implementation. If y
Hi Vish! Comments inline...
On Mon, Aug 22, 2011 at 6:43 PM, Vishvananda Ishaya
wrote:
> Hey Everyone,
> We discussed at the Diablo design summit having API spec changes be proposed
> along with code changes and reviewed according to the merge process that we
> use for code. This has been imposs
46 matches
Mail list logo
