[katello-devel] some thoughts on foreman-architectures branch

Dmitri Dolguikh dmitri at redhat.com
Fri Sep 7 11:24:04 UTC 2012


On 06/09/12 05:17 PM, Martyn Taylor wrote:
> On 09/06/2012 04:19 PM, Hugh Brock wrote:
>> On Thu, Sep 06, 2012 at 04:06:14PM +0200, Ivan Nečas wrote:
>>> On 09/06/2012 03:30 PM, Hugh Brock wrote:
>>>> On Wed, Sep 05, 2012 at 04:30:59PM +0100, Dmitri Dolguikh wrote:
>>>>> The logic used to access Foreman server is spread over several
>>>>> classes: a bunch of automatically-generated proxy-type classes that
>>>>> reside in foreman_api gem, ForemanModel (resides in
>>>>> lib/resources/foreman_model.rb), that is a base-class for Foreman
>>>>> resource classes that reside in app/models/foreman.
>>>>>
>>>>> Good things first:
>>>>>   - app/models/foreman classes are minimal, and clearly show what
>>>>> attributes are being used.
>>>>>   - app/models/foreman classes allow for local validation via
>>>>> standard ActiveModel validators.
>>>>>   - app/models/foreman classes allow for easy customization of json
>>>>> generation.
>>>>>
>>>>>
>>>>> Things I don't like:
>>>>>   - I can't shake the feeling that the approach represented in the
>>>>> branch is a huge duplication of effort. We are replicating
>>>>> ActiveResource on every step of the way, and:
>>>>>    - ActiveResource's error handling is better/consistent (ours is
>>>>> minimal and current approach would require us to recreate all of
>>>>> RestClient's exceptions)
>>>>>    - ActiveResource's error parsing is much better (we'll have to
>>>>> duplicate AR's code to be able to parse remote errors).
>>>>>    - Pretty much all of ForemanModel is what we'd get with
>>>>> ActiveResource for free. Keep in mind that custom methods are simple
>>>>> with ActiveResource.
>>>>>   - Foreman uses rabl [1] for json-generation, we implemented a
>>>>> custom approach. I think rabl is at least worth a look.
>>>>>   - Apipie in it's current shape promotes code duplication. See
>>>>> foreman_api classes, domain- and architectures-controllers in
>>>>> katello.
>>>>>
>>>>>
>>>>> I propose:
>>>>>   - It's been close to a couple of years since we looked at
>>>>> ActiveResource last. I'd like to see where it is now, how hard it is
>>>>> to use with oauth and non-rails types of resource urls these days.
>>>>>   - I'd like to evaluate rabl for use in Katello
>>>>>   - I'd like to fix code duplication issues in Apipie, possibly
>>>>> switch it to use ActiveResource instead of RestClient
>>>>>
>>>>>
>>>>> -d
>>>>>
>>>>>
>>>>> [1] https://github.com/nesquena/rabl 
>>>>> <https://github.com/nesquena/rabl>
>>>> Absent any knowledge of the actual code I strongly agree :).
>>>>
>>>> Seriously, we are using active resource pretty heavily in a lot of
>>>> places in Conductor, I would like to see us standardize on it to the
>>>> extent we can.
>
>>> Good to hear you have real experience with that. What king of
>>> services do you use that for? Rails app, or something totally out of
>>> your control (at least partly:) ? I would like to see the actual
>>> code and ask the people that were working on that about their
>>> experience with that.
>>>
>>> -- Ivan
>> cc-ing aeolus-devel.
>>
>> Martyn, can you give the folks a run-down on our Active Resource usage?
>>
>> --Hugh
>
> Sure, so we are using ActiveResource heavily in 3 of our projects; 
> talking to a few different RESTful APIs using both OAuth and Basic 
> HTTP Authentication.
>
> There is still no native support for OAuth authentication in the 
> latest release of ActiveResource though there are a couple of gems 
> that offer this functionality.  oauth-active-resource is one.  We 
> extended ActiveResource ourselves to add OAuth support.  The code is 
> here: 
> https://github.com/aeolusproject/aeolus-image-rubygem/blob/master/lib/aeolus_image/active_resource_oauth_client.rb. 
> There are one or two things in that patch that make it specific to our 
> usage but should be easy enough to generalise to use for any OAuth API.
>
> I've cc'd Matt Wagner who is the original author of the OAuth patch.  
> We could fix the specific bits and pull patch that into its own gem so 
> we can easily use it across projects.
>
> Custom urls are partially supported in that you can specify resource 
> paths and you can create custom methods see: 
> http://api.rubyonrails.org/classes/ActiveResource/Base.html.  If you 
> are doing something particularly different to generally accepted 
> patterns then you might have some issues.  Generally I've found that 
> ActiveResource works well out of the box with rails applications and 
> most REST APIs.  However sometimes it can be frustratingly difficult 
> to customize - though we've yet come across an issue yet that we've 
> been unable to get round.
>
> Standardizing our usage of ActiveResource really would consist of 
> standardizing our APIs, since all the custom code is tailoring 
> ActiveResource to the API it is consuming (Other than the OAuth 
> support of course).
>
> You should also get a few of the Foreman benefits in ActiveResource too:
>
> Good things first:
>
>  - app/models/foreman classes allow for local validation via standard 
> ActiveModel validators.
>
> ActiveResource includes the ActiveModel validators see: 
> http://api.rubyonrails.org/classes/ActiveResource/Validations.html
>
>  - app/models/foreman classes allow for easy customization of json 
> generation.
>
> I've not done this but it should be possible by overriding to_json 
> methods.
>
> Feel free to ping me on IRC if you'd like to talk more: my nick 
> #martyntaylor on freenode
> a
> Regards
>
> Martyn

I spent some time yesterday on looking at how to get ActiveResource to 
interact with a non-Rails based rest service that uses OAuth 
(candlepin). See some of the code at [3].

  - Adding OAuth support is pretty trivial, with or without 
oauth-active-resource. I did something similar to 
aeolus_image/active_resource_oauth_client.rb
  - Supporting nested resources is done via specifying resource prefix, 
and then supplying prefix parameters when doing stuff with the resource [3].
  - ActiveResource *still* insists on appending of encoding type to 
resource urls. Annoying, but the fix is simple (required for non-Rails 
services).
  - It is possible to specify resource schema [2]. Not sure if 
attributes not specified in the schema will be silently dropped, or an 
exception will be thrown. Data types are being currently used however.


Using ActiveResource for Rails-backed service will only require changes 
to support OAuth, which makes it extrememly attractive (if not a 
no-brainer).

-d


[2] 
http://api.rubyonrails.org/classes/ActiveResource/Base.html#method-c-schema
[3] https://gist.github.com/3665270

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/aeolus-devel/attachments/20120907/051bf061/attachment.html>


More information about the aeolus-devel mailing list