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

Dmitri Dolguikh dmitri at redhat.com
Fri Sep 7 11:26:03 UTC 2012


On 07/09/12 12:24 PM, Dmitri Dolguikh wrote:
> 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. 

Correction:
Data types are currently *NOT* being 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/7073c13d/attachment.html>


More information about the aeolus-devel mailing list