I have added a new blue print https://blueprints.launchpad.net/nova/+spec/open-stack-api and associated wiki page to capture and make some progress.I have a launchpad account from my Ubuntu days.As I am new to OpenStack, am not sure if this is the right way to proceed. Don'r want to be presumptuous
Totally agree with you Jorge, although I don't like the term "Dev APIs" (since
developers who consume the service will interact with the Public APIs). I
propose we call them Internal APIs.
Erik
From: Jorge Williams
mailto:jorge.willi...@rackspace.com>>
Date: Wed, 5 Jan 2011 05:00:56 +
To:
I think I agree with most of what you're saying, but bringing in the discussion
in "the scope and projects thread" I would summarize things a little
differently:
"OpenStack APIs"
1. Each core project will expose one or more HTTP/RESTful interfaces for the
purpose interacting with the outside
Looks like we are converging. Summarizing:OpenStack API is the Management & Control Plane for a Cloud Infrastructure built using OpenStack components. It will be used by cloud service consumers & operators to build higher level systems. It is REST-fulIt will have a programming model appropriate for
I also agree. Just to be clear thought, we should make a distinction between
internal API (devAPI) that's used by the developers of that particular service
and the management API that may be used by an operator of a service OR by an
orchestration service and is a proper "OpenStack API" with ve
Good discussion, and an overwhelming no vote on requiring OpenStack language
bindings to be first-class constructs and the preferred method for
publishing our programming model.
I do believe that we should have/need an aggregation layer for services that
expose multiple services/functions (such
Agreed,
This seems like a clear distinction.
On Jan 4, 2011, at 11:02 AM, John Purrier wrote:
> Good points, I just deleted my post as you made my points J.
>
> The “devAPI” is valuable for developers/contributors to the OpenStack
> services for all of the reasons Vishy stated in terms of imm
Good points, I just deleted my post as you made my points J.
The “devAPI” is valuable for developers/contributors to the OpenStack services
for all of the reasons Vishy stated in terms of immediacy, access, and easy
evolution. This should be internal to the project. Having a CLI to drive this
Responses Below
On Jan 4, 2011, at 10:37 AM, wrote:
> Good point - this was my concern on "REST API for developers" in the other
> thread. Relative stability, versioning, published API and programming models
> that need to be supported and deprecated systemically and so forth. Plus
> evolution
Good point - this was my concern on "REST API for developers" in the other thread. Relative stability, versioning, published API and programming models that need to be supported and deprecated systemically and so forth. Plus evolutionay concerns like extensibility, feature velocity, ... Before we e
Sure. DevAPI perhaps?
Another point that might help clarify: Each component of Nova exposes an "api"
to the other components in the system via python methods. You could refer to
these as the "internal api" for that component. Both the OS api and the EC2
api use this internal api, for example
On Jan 3, 2011, at 8:32 PM, Vishvananda Ishaya wrote:
> I feel very strongly that we need to keep the code easy to extend and
> prototype, without forcing developers to go through the process of api specs
> and versioning. I don't think this is going to happen through the
> OpenStack/Rackspace
John Dickinson wrote:
> On Jan 3, 2011, at 6:13 PM, John Purrier wrote:
>> The key concept being proposed is that the developers that will be
>> interacting with the OpenStack services will not interact directly with the
>> service API’s, but rather will have a set of published language bindings
On Mon, Jan 3, 2011 at 10:00 PM, John Dickinson
wrote:
> On Jan 3, 2011, at 6:13 PM, John Purrier wrote:
>>
>> API/Service Protocol: RESTful interfaces specific to each service. Each
>> service will present a Public API, a Management API, and optionally, a
>> Notification API. The set and format
Happy new year everyone,
As a reminder, our weekly team meeting will take place at 21:00 UTC
this Tuesday in #openstack-meeting on IRC.
This is the last meeting before BranchMergeProposalFreeze. If you have a
feature targeted to Bexar that might not be merge-proposed in time, but
can't make it to
Hi, guys.
Can we please try to keep the commit messages more descriptive than this?
A changelog is a much more useful read if you can actually learn what
changed in the individual revisions. Referencing a bug number forces
people to go and look stuff up on the web and all they will (usually)
find
16 matches
Mail list logo
