Merge lp://qastaging/~justin-fathomdb/nova/java-binding into lp://qastaging/~hudson-openstack/nova/trunk

I may have came late to the game. It looks as though this is simply a client library to the OpenStack API. Should these bindings belong in nova or as a standalone project?

Would it make sense to simply work on solidifying OpenStack compatibility in jclouds?

My apologies if I am completely off topic.

This is indeed a simple Java client library to the OpenStack API. I'm
proposing that we keep the source in the same tree (under the contrib
directory, like our boto_v6 binding), so that we can develop the client as
we add features if we want to. We can also ship/stamp an approved version
of bindings with the release if we want to. We can't put a library we don't
control under our source tree (e.g. jclouds)

Also, by implementing a library ourselves we can see the consequences of our
API decisions from the point of view of the binding developers, and get an
idea of what developers using those bindings will think of OpenStack. So
we'll have a better product by virtue of implementing a library.

This also (starts to) solve an immediate problem, which is that we have no
tests of the XML API. This binding uses the XML API, and is finding bugs in
it. For example, at the moment, there are no namespace declarations at all,
so it fails immediately (there's a separate patch for that) Once things
don't fail immediately, I hope to add some simple tests.

However, I very much hope that you will work on solidifying support for
OpenStack in jclouds! Every library should support OpenStack, but equally
we should not be at the mercy of third parties.

I am also unconvinced of the value of shipping it in core code. If you do so, nova devs become collectively responsible for keeping it up to date with the rest of the source tree. I'm not sure we have so many Java nova-core developers.

We had the same question in the nova deployment tool in Bexar, and the decision was to keep it separate...

Well, I think that not having a binding in core is a mistake, but that's a
different discussion. Note that I have not proposed shipping this. This is
to support testing.

I was planning on using this binding for testing that our XML spec was to
spec (hence it was linked to the bug #740576). This is a binding to the
CloudServers API that my company created and uses against CloudServers, and
is willing contribute as open source. This binding is strict in requiring
that output be schema-compliant.

I'm willing to use this binding to test that our XML binding isn't
completely broken. Right now, it is completely broken - Bug #740576 means
that XML API clients won't even try to parse the data the API outputs. Once
that is fixed, I can start testing that we're outputting the correct XML.

However, if you have a better way to test our XML bindings for
spec-compliance, then this doesn't need to go in. I don't see a merge
proposal for an alternative though?

While I am all for keeping the source together I do find it scary to include a project written in a different language in our tree. I think we have an expectation of making and moving to openstack-common around the next summit and theoretically we will want a couple auxilliary tools for dealing with libraries in different repos, and this may be an opportunity for you to influence the design of those with whatever you build to support this use case.

Thoughts? This project will be separate eventually, so maybe jump the gun and write the first draft of the software that helps incorporate separate projects for testing.

I completely understand why this code is useful, I just don't see why it should be part of nova itself. We have been working to strip out all non-Python code from nova (including rewriting our CA stuff from bash to Python), so that looks like a step in the wrong direction.

As far as testing goes, the python client (python-novaclient) is used in testing (the zones stuff), and it's shipped separately... so there are precedents.

OK, sounds like this doesn't belong as part of openstack/nova.

Moving to WIP while I figure out next steps...