[katello-devel] ActiveResource as an alternative to custom RestClient-based Foreman api client

[Petr Chalupa]

ActiveResource looks great in this example, but I have some concerns 
about edge cases:

- API call where no resources are returned [3]
- nested attributes or nested resources [4]
- update action has nested attributes but create action has not [5]
- create action accepts an attribute but update action does not accept 
the attribute, see [6] :provider_type
- API returns something else than json
- API returns 200 instead of an error (this bug was in Katello recently)

(I know last four cases are taken from Katello API but if we have these 
types of mistakes it's a reasonable assumption other REST API have them 
also.)

We may have to fix these quirks temporarily on Katello side before this 
is fixed in Foreman/Candlepin/Pulp API.

I would like to see at least a draft or concept how these can be fixed 
with ActiveResource. Imho this will become messy because AR combines two 
things into one. AR does not separate raw calls to API and object 
representation of remote resources, in foreman_architectures these are 
separated (also mentioned by Eric).

I do not know if this is the case, but I feel like I should mention it 
(because I did this mistake before): We should evaluate ActiveResource 
as any other library, it should not be assumed that ActiveResource is 
the best choice just because it's part of Rails.

There are 3 possible approaches. I'll try to summarize them and put in 
order from the worst to the best. ('+' for pros, '-' for cons)

= Current implementation of Candlepin/Pulp orchestration
+ it works
- no distinct representation of remote resources
- ActiceRecord models are god-objects [1]; They are representation of: 
Katello model, remote resources (Candlepin and Pulp), orchestration 
between them.
- highly coupled together => bad maintainability

== ActiveResource
+ it works
+ it's dry
+ distinct representation of remote resources
+- lots of features we may or may not need
- combines raw calls and representation of remote resources
- no concept how to solve edge cases
- monolithic lib as other parts of Rails
- uncertain Future [2]

== ForemanModel
+ it works
+ it's dry
+ distinct representation of remote resources
+ distinct implementation of API adapter => easy dealing with edge cases
- differs from Candlepin/Pulp orchestration (but border is clearly 
defined by Foreman orchestration)

[1] http://en.wikipedia.org/wiki/God_object
[2] 
https://github.com/rails/rails/commit/f1637bf2bb00490203503fbd943b73406e043d1d
[3] https://fedorahosted.org/pulp/wiki/UGREST-Consumers#ConsumerRepositories
[4] https://fedorahosted.org/pulp/wiki/UGREST-Consumers#ConsumerErrata
[5] 
https://github.com/Katello/katello/blob/master/src/app/controllers/api/organizations_controller.rb#L59
[6] 
https://github.com/Katello/katello/blob/master/src/app/controllers/api/providers_controller.rb#L45

On 17.09.12 21:09, Eric Helms wrote:
> On 09/17/2012 02:04 PM, Dmitri Dolguikh wrote:
>> Hey everybody,
>>
>> I finished the spike on using ActiveResource as a replacement for
>> RestClient, only for communication with Foreman, and only to
>> orchestrate user creation/deletion in Foreman. See the results at [1].
>>
>> Some post-spike thoughts/observations:
>>  - I monkey-patched ActiveResource to support OAuth, but the same can
>> be achieved by subclassing ActiveResource::Base, which is the way to go.
>>  - The amount of custom-code is *very* minimal and it's mostly to
>> support OAuth.
>>  - Not a fan of custom to_json, we could either use resource's schema
>> (there are some drawbacks), or try using rabl [2] (like foreman folks do)
>>  - Should we decide to adopt this, we can eventually move both
>> candlepin and pulp to use ActiveResource. I think it will be possible
>> to drop our lazy_attributes in the process with some work, if we adopt
>> rails caching.
>>
>>
>> Comments, concerns?
>> -d
>>
>>
>> [1] https://github.com/witlessbird/katello/tree/foreman-ar-spike
>> [2] https://github.com/nesquena/rabl
>>
>>
>> _______________________________________________
>> katello-devel mailing list
>> katello-devel at redhat.com
>> https://www.redhat.com/mailman/listinfo/katello-devel
> Worth noting, as part of the PulpV2 migration work the API bindings for
> pulp are being pulled out into a separate gem -
> https://github.com/Katello/runcible
>
> Right now this is being built using RestClient and with the idea that it
> simply exposes the Pulp API calls in Ruby.  There was some discussion
> over sticking with RestClient or doing more ActiveResource style.  The
> thinking up to this point has been that adding an ActiveResource
> interface or style of returnable object on top of this layer could be
> nice but that having a direct 1:1 set of bindings that just return the
> raw data is also useful.
>
> -Eric
>
>
> _______________________________________________
> katello-devel mailing list
> katello-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/katello-devel
>