[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