[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