[katello-devel] ActiveResource-based Foreman client in Katello

[Ivan Nečas]

On 09/21/2012 11:15 AM, Dmitri Dolguikh wrote:
> On 21/09/12 08:32 AM, Petr Chalupa wrote:
>> +1 for foreman_architectures
>>
>> I am choosing this because:
>> - no problems with edge cases
>
> I'm not sure why Petr and Ivan continue repeating this, what are the 
> problems, exactly, that we [are|will be] running into?
See my previous email about trying using ActiveResource to Candlepin and 
perhaps find a solution to it. Thank you!
>
>>
>> - can be also used for orchestrating Cadlepin and Pulp
>
> Why are implying that this can't be done with ActiveResource? FYI - 
> the original orchestration used ActiveResource, but it was passed over 
> in favour of RestClient, because we explicitly didn't want to have 
> model classes.
Is there a discussion about this archived somewhere, mailing list is ok?
>
>>
>> - generated api layer from foreman documentation
>> - foreman_api gem for community
>
> This is an artefact of using apipie. My personal opinion is that api 
> bindings for REST services are of limited value. Even Katello doesn't 
> use all of candlepin and pulp api's and we are constraining what 
> attributes we are using.
>
>
>> - it separates api-resources and remote-resource-model
>
> This is an implementation detail, why are you bringing this up?
>
>>
>> - to avoid monkey-patching of ActiveResource
>
> Why do you keep bringing this one up? Did you see any monkey-pathing 
> in the code I showed??? Can we please stop with FUD already?
Ok, it's just internal methods overriding, though not being private. Ok 
then.
>
>
>
> To Petr and Ivan: you never acknowledged code duplication, and never 
> answered the questions about lack of tests and insufficient error 
> handling, inability to parse errors, etc. These will result in even 
> more duplicated of functionality. You never acknowldeged code 
> duplication and enforced validation in the foreman_api itself.
>
> I'm not opposed to using the gem, but those things need to be resolved.
Yop, the code is not perfect. On the other side, we need to do this with 
Pulp and Candlepin as well, where ActiveResource won't help us a lot, 
but this is not a discussion about Pulp or Candlepin.
>
>
>
> ActiveResource can be used in place of our custom solution (RestClient 
> + custom code) and with lesser amount of effort. We don't need to 
> write tests for that code either. Maintenance comes for free too. All 
> of this is available now. There's minimal amount of risk in using this 
> approach too, the switch I did in foreman_architectures branch 
> required minimal changes in the main Katello code base.
That's true indeed. I'm really curious to see all the advantages of 
ActiveResource in real world. If we will keep this independence in mind 
(letting us switch to custom solution later if some complications show 
up) I am ok with it. +1 for giving ActiveResource a chance.

-- Ivan
>
>
> -d
>>
>> On 20.09.12 22:11, Bryan Kearney wrote:
>>> On 09/20/2012 09:54 AM, Dmitri Dolguikh wrote:
>>>> On 20/09/12 11:41 AM, Dmitri Dolguikh wrote:
>>>>> As promised, I added a short page to Katello wiki on
>>>>> ActiveResource-based Foreman API that can be found at [1].
>>>>> -d
>>>>>
>>>>> [1] https://fedorahosted.org/katello/wiki/ArForemanModel
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> katello-devel mailing list
>>>>> katello-devel at redhat.com
>>>>> https://www.redhat.com/mailman/listinfo/katello-devel
>>>>
>>>> It seems that we are at an impasse yet again.
>>>>
>>>> Personally, I'm not interested in yet another prolonged conversation.
>>>> The spike shows that AR as Foreman client results in simpler
>>>> integration: less code, in less time. Foreman-architectures branch in
>>>> its current state can't go into master: short term changes required to
>>>> use it include addition of tests, dropping of client-side 
>>>> validation in
>>>> API bindings. Longer term-changes include updates to error handling,
>>>> removing of code duplication in api bindings.
>>>>
>>>> -d
>>>>
>>>
>>> IMHO.. give 1 day for a vote after the last points have been made. Have
>>> the team +1 their preference.
>>>
>>> -- bk
>>>
>>>
>>> _______________________________________________
>>> katello-devel mailing list
>>> katello-devel at redhat.com
>>> https://www.redhat.com/mailman/listinfo/katello-devel
>>
>> _______________________________________________
>> katello-devel mailing list
>> katello-devel at redhat.com
>> https://www.redhat.com/mailman/listinfo/katello-devel
>
> _______________________________________________
> katello-devel mailing list
> katello-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/katello-devel


-- 
Ivan