You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@deltacloud.apache.org by mf...@redhat.com on 2010/10/25 16:35:16 UTC
Add version checking from client to API
Hi,
This simple patch will add support for checking API core server
version from client.
This approach should avoid conflicts between versions, especially
when API adds new feature and you want to use it from the client.
In this case you will get some exception now. After this patch
you will get warning about version mismatch.
-- Michal
Re: Add version checking from client to API
Posted by Max Rydahl Andersen <ma...@redhat.com>.
> On Tue, 2010-10-26 at 15:50 +0200, Max Rydahl Andersen wrote:
>> May I ask why all these patches and improvements dont just go to jira
>> so one can actually find them again ?
>
> Mostly because people like me are used to a mailing-list centric
> workflow, and we worked that way before entering the incubator. The
> workflow is actually widely used (actually, all the OSS projects I've
> even mildly participated in in the last few years work like this)
>
> The main downside to the workflow, that patches might get dropped on the
> floor, is mitigated by the fact that the patch author should have an
> interest in seeing their work committed (and therefore poke ppl when
> acking/committing a patch takes too long)
>
> I am also open to experiment with the newly set-up ASF reviewboard[1],
> though I don't feel we really need it, given the fairly low volume of
> traffic on this list.
well, there is enough volume of patches going to this list making it almost
impossible to follow what is being done/planned/talked about - especially
when subject lines aren't edited.
>
>> And the list is used for out-of-bound discussions ?
>
> What do you mean by that ?
bad wording, what I mean is for me a dev mailing list is to discuss things
that aren't specific to a single jira/patch but about some design or issues.
/max
Re: Add version checking from client to API
Posted by David Lutterkort <lu...@redhat.com>.
On Tue, 2010-10-26 at 15:50 +0200, Max Rydahl Andersen wrote:
> May I ask why all these patches and improvements dont just go to jira
> so one can actually find them again ?
Mostly because people like me are used to a mailing-list centric
workflow, and we worked that way before entering the incubator. The
workflow is actually widely used (actually, all the OSS projects I've
even mildly participated in in the last few years work like this)
The main downside to the workflow, that patches might get dropped on the
floor, is mitigated by the fact that the patch author should have an
interest in seeing their work committed (and therefore poke ppl when
acking/committing a patch takes too long)
I am also open to experiment with the newly set-up ASF reviewboard[1],
though I don't feel we really need it, given the fairly low volume of
traffic on this list.
> And the list is used for out-of-bound discussions ?
What do you mean by that ?
David
[1] https://blogs.apache.org/infra/entry/reviewboard_instance_running_at_the
Re: Add version checking from client to API
Posted by Max Rydahl Andersen <ma...@redhat.com>.
> Hi Max,
>
> * developers get the latest version of code from the git-svn repo
> * patches made against that code and posted to this list
> * other developers can apply the patch to their code and ack or nack accordingly
> * if you get at least one ack and no nack then the code is pushed into the core repo (so next time someone pulls from git repo they get the latest code)
okey - problem is just that this is nowhere to be seen by contributors that aren't
directly contributors to the core code.
i.e. i'm interested on a higher level to see what is moving being planned for and what has been done - normally
I can see that in a jira, blog or mailing list discussions for an opensource project.
Where is that for deltacloud ? i.e. the jira's we opened and which I think is already fixed are still open...
On deltacloud its just all a "read the patches and you'll know what were planned some weeks ago"...
Anyway, if you guys are all fine about it then that is just that - but you guys aren't making it easy for others ;)
/max
>
> this is the model followed since I joined the project (I don't know *why* this is how we do it, but it seems to work just fine)
>
> marios
>
>
>
> On 26/10/10 16:50, Max Rydahl Andersen wrote:
>> May I ask why all these patches and improvements dont just go to jira so one can actually find them again ?
>>
>> And the list is used for out-of-bound discussions ?
>>
>> /max
>>
>> On Oct 25, 2010, at 16:35, mfojtik@redhat.com wrote:
>>
>>> Hi,
>>>
>>> This simple patch will add support for checking API core server
>>> version from client.
>>>
>>> This approach should avoid conflicts between versions, especially
>>> when API adds new feature and you want to use it from the client.
>>> In this case you will get some exception now. After this patch
>>> you will get warning about version mismatch.
>>>
>>> -- Michal
>>>
>>
>
Re: Add version checking from client to API
Posted by "marios@redhat.com" <ma...@redhat.com>.
Hi Max,
* developers get the latest version of code from the git-svn repo
* patches made against that code and posted to this list
* other developers can apply the patch to their code and ack or nack
accordingly
* if you get at least one ack and no nack then the code is pushed into
the core repo (so next time someone pulls from git repo they get the
latest code)
this is the model followed since I joined the project (I don't know
*why* this is how we do it, but it seems to work just fine)
marios
On 26/10/10 16:50, Max Rydahl Andersen wrote:
> May I ask why all these patches and improvements dont just go to jira so one can actually find them again ?
>
> And the list is used for out-of-bound discussions ?
>
> /max
>
> On Oct 25, 2010, at 16:35, mfojtik@redhat.com wrote:
>
>> Hi,
>>
>> This simple patch will add support for checking API core server
>> version from client.
>>
>> This approach should avoid conflicts between versions, especially
>> when API adds new feature and you want to use it from the client.
>> In this case you will get some exception now. After this patch
>> you will get warning about version mismatch.
>>
>> -- Michal
>>
>
Re: Add version checking from client to API
Posted by Max Rydahl Andersen <ma...@redhat.com>.
May I ask why all these patches and improvements dont just go to jira so one can actually find them again ?
And the list is used for out-of-bound discussions ?
/max
On Oct 25, 2010, at 16:35, mfojtik@redhat.com wrote:
> Hi,
>
> This simple patch will add support for checking API core server
> version from client.
>
> This approach should avoid conflicts between versions, especially
> when API adds new feature and you want to use it from the client.
> In this case you will get some exception now. After this patch
> you will get warning about version mismatch.
>
> -- Michal
>
[PATCH core] Added version check from client to core version
Posted by mf...@redhat.com.
From: Michal Fojtik <mf...@redhat.com>
---
client/lib/deltacloud.rb | 16 +++++++++++++---
server/deltacloud-core.gemspec | 4 ++--
server/server.rb | 1 +
server/views/api/show.xml.haml | 2 +-
4 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/client/lib/deltacloud.rb b/client/lib/deltacloud.rb
index 117a04b..71112cf 100644
--- a/client/lib/deltacloud.rb
+++ b/client/lib/deltacloud.rb
@@ -23,6 +23,8 @@ require 'logger'
module DeltaCloud
+ REQUIRED_API_VERSION="0.1.0"
+
# Get a new API client instance
#
# @param [String, user_name] API user name
@@ -70,9 +72,11 @@ module DeltaCloud
@defined_classes || []
end
+ class WrongAPIVersionException < Exception; end
+
class API
attr_accessor :logger
- attr_reader :api_uri, :driver_name, :api_version, :features, :entry_points
+ attr_reader :api_uri, :driver_name, :api_version, :features, :entry_points, :server_version
def initialize(user_name, password, api_url, opts={}, &block)
opts[:version] = true
@@ -82,6 +86,13 @@ module DeltaCloud
@features, @entry_points = {}, {}
@verbose = opts[:verbose] || false
discover_entry_points
+ if discovered?
+ valid_version = Gem::Version.new(REQUIRED_API_VERSION) <=> Gem::Version.new(@server_version)
+ if valid_version > 0
+ warn "[WARNING] API version should be >= #{REQUIRED_API_VERSION} (now using API version #{@server_version})"
+ raise WrongAPIVersionException.new
+ end
+ end
yield self if block_given?
end
@@ -149,8 +160,6 @@ module DeltaCloud
c.instance_eval do
attr_accessor :id
attr_accessor :uri
-
-
end
obj = xml_to_class(c, item)
end
@@ -252,6 +261,7 @@ module DeltaCloud
api_xml = Nokogiri::XML(response)
@driver_name = api_xml.xpath('/api').first['driver']
@api_version = api_xml.xpath('/api').first['version']
+ @server_version = api_xml.xpath('/api').first['server_version']
logger << "[API] Version #{@api_version}\n"
logger << "[API] Driver #{@driver_name}\n"
api_xml.css("api > link").each do |entry_point|
diff --git a/server/deltacloud-core.gemspec b/server/deltacloud-core.gemspec
index e6de1bf..4164d19 100644
--- a/server/deltacloud-core.gemspec
+++ b/server/deltacloud-core.gemspec
@@ -18,7 +18,7 @@
require 'rake'
-Gem::Specification.new do |s|
+$gem=Gem::Specification.new do |s|
s.author = 'Red Hat, Inc.'
s.homepage = "http://www.deltacloud.org"
s.email = 'deltacloud-users@lists.fedorahosted.org'
@@ -31,7 +31,7 @@ Gem::Specification.new do |s|
which implements the REST interface.
EOF
- s.version = '0.0.9'
+ s.version = '0.1.0'
s.date = Time.now
s.summary = %q{Deltacloud REST API}
s.files = FileList[
diff --git a/server/server.rb b/server/server.rb
index af8bc09..7d8048f 100644
--- a/server/server.rb
+++ b/server/server.rb
@@ -10,6 +10,7 @@ require 'erb'
require 'haml'
require 'open3'
require 'lib/deltacloud/helpers/blob_stream'
+load 'deltacloud-core.gemspec'
configure do
set :raise_errors => false
diff --git a/server/views/api/show.xml.haml b/server/views/api/show.xml.haml
index 70c26c9..edb748a 100644
--- a/server/views/api/show.xml.haml
+++ b/server/views/api/show.xml.haml
@@ -1,4 +1,4 @@
-%api{ :version=>@version, :driver=>DRIVER }
+%api{ :version=>@version, :server_version => $gem::version, :driver=>DRIVER }
- for entry_point in entry_points
%link{ :rel=>entry_point[0], :href=>entry_point[1] }
- for feature in driver.features(entry_point[0])
--
1.7.2.3