Hi Mark,
On Tue, 2011-10-25 at 15:20 +1100, Mark Nottingham wrote:
[snip]
What do people think of the linked approach to versioning and extensibility?
I like it. With the exception of the media types, it's very similar to
the approach we took with the RHEV API[1] and it works really well. We
andi abes wrote:
I'm a bit confused with the state of affairs for swift diablo.
I've seen notes and checkins for backports to nova from essex, and
found https://launchpad.net/~openstack-release/+archive/2011.3 which
seems to be the repo for the patched packages...
Is that right? Is this the
Along the same lines, how do you export the shell variables for
euca-tools with keystone since nova-manage to create the zipfile does
not work?
-David
On 10/24/2011 8:29 PM, Vishvananda Ishaya wrote:
Speaking of keystone diablo tag, it is currently missing the following
commit:
All,
This is the follow-up for our Deployment Fixture blueprint brainstorm at the
conference
(https://blueprints.launchpad.net/openstack-common/+spec/deployer-api ).
As an Essex release object, I'd like to be automatically deploy OpenStack from
a community standard configuration description
I'm at a loss how to assist this poster:
https://answers.launchpad.net/glance/+question/176064
If anyone has experience using Nova with the VMWare drivers, please
try to lend a hand.
Thanks!
-jay
___
Mailing list: https://launchpad.net/~openstack
On Oct 25, 2011 8:04 p.m., Dave Walker davewal...@ubuntu.com wrote:
Can you point me to this discussion? It sound awfully like there has
been some confusion.. Who was it that said this?
It was on one of the OpenStack or Ubuntu IRC channels a week or so ago, I'd
have to go digging through
I expect this is going to open a nasty can of worms... today we don't have a
consistent way of describing the APIs for the various services. I saw Nati's
bug (https://launchpad.net/bugs/881621), which implies that all the services
should have a WADL somewhere describing the API.
I'm not a huge
Hi all -
Would also love Swagger. Nati looked into it and he thought it would require
a Python client generator, based on reading that Client generators are
currently available for Scala, Java, Javascript, Ruby, PHP, and Actionscript
3. So in the meantime the QA list and Nati suggested WADL as a
Hi Joe, Anne
I'm working on WADL of Openstack Diablo in order to generate both of
Test List and API docs from WADL.
I wrote simple script which generate a simple api list from WADL. It
is very helpful.
Nova and Keystone has WADL, and Ravi@HP is working for glance.
Nova's WADL is inconsistent
On Oct 25, 2011, at 12:54 PM, Jesse Andrews wrote:
I'm not an expert ... adding some comments
On Tue, Oct 25, 2011 at 12:05 PM, Joseph Heck he...@me.com wrote:
I've just dropped in place a bunch of developer documentation (RST) for
Keystone - one in, one pending
Hi everyone,
This is just my opinion, but I've only found WADLs very useful when use tool
based automation. To me they're a huge headache to read. To me, the current dev
guide style of documentation has been far more helpful in developing automation.
Daryl
On Oct 25, 2011, at 3:24 PM, Anne
Some of that dev guide documentation is generated from a WADL :-) The purpose
of a WADL is that it is machine readable so it opens up a lot of possibilities,
for creating docs, testing, validation, etc.
-jOrGe W.
On Oct 25, 2011, at 4:14 PM, Daryl Walleck wrote:
Hi everyone,
This is just my
Hi Folks
Daryl
I know to read and write WADL is awful.. because I'm working on that.
My main point is for clear specs. Current docs are very helpful, but
it is not includes
clear specs (parameter structures and types).
Jorge
Sounds Great
My review request is
Which dev docs and how? I haven't spotted those scripts or systems...
-joe
On Oct 25, 2011, at 2:58 PM, Jorge Williams wrote:
Some of that dev guide documentation is generated from a WADL :-) The
purpose of a WADL is that it is machine readable so it opens up a lot of
possibilities, for
It sounds like even though most of us hate WADL, it's what we're expending
effort after to make a consolidated API set. So unless Nati and Ravi want to
switch to using Swagger (or something else), WADL is the direction we're
heading. I totally agree with Daryl that reading it is a PITA, and am
WADL sounds like a wonderful validation tool.
But shouldn't our primary goal be finding a consistent way to describe the APIs
for *application developers*.
Syntax tools, whether ancient notations like BNF or the latest XML concoction
only tell you the syntax of the operation.
There also has to
I don't think the debate is whether to do migrations or not. I think
the debate should be:
Is there more value in not doing it the same way another openstack
project does it?
If you can use nova's method, then we get closer to having standard
operating procedures for openstack projects...
On
Keystone is using it more than Nova, especially to document their extensions.
It's working with our existing docs tool chain.
You can reference a WADL directly from the DocBook source, you can go in and
reference particular resources and methods it will parse stuff out and put it
in the
Totally agree. The goal is to create narrative documents that devs can read
etc. The WADL is just there to fill in the nitty gritty details in a
consistent way.
-jOrGe W.
On Oct 25, 2011, at 5:34 PM, Caitlin Bestler wrote:
WADL sounds like a wonderful validation tool.
But shouldn’t our
That's exactly what I'm poking at (and what Nati has started doing as well). I
was trying to see if there was a consistent way to describe all the API
endpoints that could be used to document the combined set.
The raw description is clearly insufficient, so how best to create a final
product
we are working to use swagger, but i think the s/w is not working
can help?
F
On Wed, Oct 26, 2011 at 3:24 AM, Anne Gentle a...@openstack.org wrote:
Hi all -
Would also love Swagger. Nati looked into it and he thought it would require
a Python client generator, based on reading that Client
On Tue, 25 Oct 2011, Kiall Mac Innes wrote:
On Oct 25, 2011 8:04 p.m., Dave Walker davewal...@ubuntu.com wrote:
Can you point me to this discussion? It sound awfully like there has
been some confusion.. Who was it that said this?
It was on one of the OpenStack or Ubuntu IRC channels a
The hard thing about processing a WADL is that WADLs uses links and references.
For example: WADL A may refer to a method defined in WADL B, that's useful
when you're defining extensions. Or WADL A may define two resources that share
GET, PUT, POST operations: You see this with metadata in
Hi Nati - I might be opening a can of worms here, but I thought the API spec
and WADL were complete and we were working on implementing it. It sounds to me
like you are doing the reverse and matching the WADL to the current state of
the code. There's value in that, but i know it will cause
The WADL should be complete for Nova. There are a couple of error fixes that
I've completed but haven't pushed up yet. I'll try to get to those tomorrow
and I'll look over Nachi's contributions as well.
What's not done in Nova is documenting all of the extensions. I'm working on
that and
Hi-
I am looking for the way to get system usage data for a billing purpose
in Diablo release. Is there anyone know as to how to get event messages
such as compute.instance.create, compute.instance.delete, etc? I believe
this information cat be retrieved via log files or AMQP.
P.S: I guess
Hi Ziad,Joe, jOrGe W.
Ziad
I'm agree with you. Blueprint must contain clear specs!!
Current api document is not covering all accepted blueprints.
As Joe mentioned, current WADL is not perfect. It is the reason of i'm
reverse checking code for now.
Joe
Ah, it it is just a patch, I need a paper
Blueprint changed by Vish Ishaya:
Priority: Undefined = Medium
--
XenAPI SM Volume Driver
https://blueprints.launchpad.net/nova/+spec/xenapi-sm-support
--
Mailing list: https://launchpad.net/~openstack-volume
Post to : openstack-volume@lists.launchpad.net
Unsubscribe :
28 matches
Mail list logo
