[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