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

Martyn Taylor mtaylor at redhat.com
Thu Sep 6 16:17:21 UTC 2012


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

Regards

Martyn



More information about the aeolus-devel mailing list