[katello-devel] Foreman integration model question

Lukas Zapletal lzap at redhat.com
Wed Aug 22 08:19:50 UTC 2012


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.

-- 
Later,

 Lukas "lzap" Zapletal
 #katello #systemengine




More information about the katello-devel mailing list