[katello-devel] Foreman integration model question

[Petr Chalupa]

Lukas is right, our motivation was to break the code into smaller pieces 
(I am big fan of SOLID and 'single responsibility principle' in 
particular). If you write code this way, you can then move things around 
very quickly so you can develop features and fix bugs faster. No to 
mention it can be testes more easily.

app/models/user.rb (User) is representation of katello user which mixes 
(if foreman is installed) foreman orchestration 
app/models/glue/forema/user.rb. Orchestration is working with foreman 
through children of ForemanModel which are representation of remote 
resources app/models/foreman/user.rb (Foreman::User). Foreman::User is 
using foreman-api bindings which are defined as singletons in 
lib/resources/foreman.rb.

So there are 4 layers:
- katello model
- foreman-katello orchestration
- foreman model (remote resource)
- foreman bindings (gem foreman-api)

I also for splitting up big parts.

Petr

On 22.08.12 10:19, Lukas Zapletal wrote:
> On Tue, Aug 21, 2012 at 02:48:56PM -0400, Justin Sherrill wrote:
>> Taking user for example we would have:
>>
>> user.rb
>> glue/pulp/user.rb
>
> But you are missing one piece of the puzzle:
>
> lib/resources/pulp.rb (class User)
>
> And that is the piece which you can find in foreman/user.rb.
>
>> What I see with foreman is:
>>
>> user.rb
>> glue/foreman/user.rb
>> foreman/user.rb
>
> So instead having all the resources in a single class
> (lib/resources/foreman.rb), we are going to have (or better - generate)
> all resource (read also as "dumb") classes. Each in separate file.
>
>> Where foreman/user is a second class that can be instantiated and
>> used on its own, while glue/foreman/user.rb is simply the
>> orchestration to create that object.  I see the use of
>> Resources::ForemanModel, but in this user instance the foreman user
>> could be manipulated completely apart from the katello user (which
>> is bad IMHO).  This also is completely different from our existing
>> orchestration methods.
>
> Yes, it is different. I like this approach more. Creating a one instance
> per request is nothing, while the code is definitely better than eight
> hundred lines long pulp.rb with all the resources there as "class"
> methods.
>
> I think this is the correct approach and we may discuss splitting those
> big resource files in future into smaller pieces for other backend
> engines too. If we write a similar generator, we wont longer need to
> write them manually (and we will be able to track API changes too).
>
> I was not writing the code, but I believe those instances are treated
> like singletons, so you do not need to create instances by yourself:
>
> https://github.com/Katello/katello/blob/foreman_architectures/src/lib/resources/foreman.rb
>
> Guys please elaborate what the intentions are.
>