[katello-devel] Modelling of environments, products, etc in Katello (take ||)

[Justin Sherrill]

On 08/13/2012 12:18 PM, Justin Sherrill wrote:
> On 08/13/2012 11:05 AM, Dmitri Dolguikh wrote:
>> Could a couple of folks on Katello team spend an hour or so and take 
>> a look at the architectural changes I propose in 
>> https://www.redhat.com/archives/katello-devel/2012-August/msg00102.html?
>>
>>
>> Much appreciated,
>> -d
>>
>>
>> _______________________________________________
>> katello-devel mailing list
>> katello-devel at redhat.com
>> https://www.redhat.com/mailman/listinfo/katello-devel
>
> A couple of thoughts.  As we discussed previously  productContent does 
> not have a 1-1 mapping to a pulp repo, so with that in mind:
>
> 1.  Pulp::Repos is a module made up of product and content related 
> items in relation to pulp.  I understand that product may not be the 
> best fit for this, however sticking it within repo really isn't either 
> (I would be 100% against this).  Potentially breaking it up into 
> product related items and product content related items would make the 
> most sense.
>
> 2.  I don't see how repositories are tied to environments in this 
> diagram.  How would i go about getting all the repositories for a 
> product within an environment?
>
> 3.  Data level organization is great and all, but if the code isn't 
> more readable (or at least isn't less readable) its all for nothing.  
> Its been my experience that rarely within the code do we need all the 
> repos for a product content within an environment (I don''t know that 
> i've ever needed that information).   This is how you've proposed to 
> organize the data however.   So if i have to do something like   
> my_product.product_content.collect{|pc| pc.repositories}.flatten  in 
> order to get the list of repos in a product, it would not be worth 
> it.  I believe the current structure came out of the lack of a need 
> for product content within katello itself (as a user facing object).  
> Try to keep the scopes within product as they are today as much as 
> possible.  (i.e. I should still be able to do  
> my_product.repos(my_environment) as that is much nicer :} ).    I 
> understand that candlepin relies on product content for lots of 
> things, but katello itself really doesn't care about product content.  
> I'm hesitant to make it a first class model citizen in katello as it 
> could make a lot of code more complicated, but as long as that's kept 
> to a minimum, I'm ok with it.
>
> I would say as part of this if you find yourself replacing lots of db 
> queries/AR lookups with longer statements, step back and ask yourself 
> how to simplify it.
>
> 4.  I would like to see a new proposed diagram with some of these 
> concerns (#1 & #2 & the fact that productContent and repos are not 1-1 
> mapped) addressed.
>
> Thanks,
>
> -Justin

Couple of other things I noticed which kinda might address some of the 
confusion around my previous questions:

5.   You're current katello diagram is incorrect in that Repository does 
not "use" (aka include i assume)  Pulp::Repos, it includes Pulp::Repo.

6.  In your proposed model, a product is only related to an environment 
by its Product content and I believe a repo is only related to an 
environment through its product content.

    This changes how we today consider if a product is promoted within 
katello and what it means for a repository to be in an environment.  
Currently if I promote repo "RHEL Server 6.2 x86_64"  That doesn't mean 
all repos within that content (RHEL Server $relver $arch) exist in that 
environment, which i feel is kinda what it implies.  We also I believe 
allow the promotion of empty products, which i don't think this model 
allows.

I do believe there is a disconnect between repos in katello and product 
content in candlepin and as long we allow you to selectively enable and 
promote only certain instances of content (aka repos), then I think 
there always will be.   I know we are not handling this perfectly today 
within katello (i.e. a client might assume that RHEL Server 6.1 x86_64 
exist in an environment when it does not), but i'm not entirely sure 
this is improves the situation?

-Justin

>
>
>
>
> _______________________________________________
> katello-devel mailing list
> katello-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/katello-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/katello-devel/attachments/20120813/f6f3f056/attachment.htm>