[katello-devel] available release versions

Tom McKay thomasmckay at redhat.com
Tue Jul 10 13:01:40 UTC 2012



----- Original Message -----
> From: "James Bowes" <jbowes at redhat.com>
> To: "Bryan Kearney" <bkearney at redhat.com>
> Cc: katello-devel at redhat.com
> Sent: Monday, July 9, 2012 10:56:38 AM
> Subject: Re: [katello-devel] available release versions
> 
> On Mon, Jul 09, 2012 at 06:40:08AM -0400, Bryan Kearney wrote:
> > On 07/06/2012 11:00 AM, Tom McKay wrote:
> > >https://bugzilla.redhat.com/show_bug.cgi?id=834012
> > >
> > >Both headpin and subscription-manager-gui reach out to the CDN to
> > >get a list of available release versions (5.8, 6.2, etc.).
> > >Katello, however, bases the available release versions on the
> > >subset that have repos enabled.
> > >
> > >With that in mind, I think the BZ above is working as intended,
> > >ie. release versions shown in subscription-manager-gui have
> > >nothing to do with what katello has available.
> > >
> > >I think there have been BZs/RFEs that systems should not be able
> > >to set a release version when registered to katello to a version
> > >where no repos (and hence no content) are available.
> > >
> > >Someone with more knowledge of the feature and intricacies please
> > >chime in.
> > >
> > >_______________________________________________
> > >katello-devel mailing list
> > >katello-devel at redhat.com
> > >https://www.redhat.com/mailman/listinfo/katello-devel
> > >
> > Where does subscription manager reach out to? It would be great if
> > it looked into the directories which are published by katello.
> >
> 
> Here is roughly what subman does:
> - for all installed products on a system, iterate over the products:
>   - if a product has the product tag 'rhel-N' consider it to be a
>   base OS
>     product.
>   - take the last found base os product
> - if no base os products found, set available releases to an empty
> list.
> - with the last found base os product, find all entitlements that
> grant
>   access to that product
> - create an empty list, listings
> - for each entitlement, do:
>   - for each _enabled_ content set on the entitlement, do:
>     - compare the product tag to the content set's required tag, ie
>       (rhel-6 matches rhel-6 but not rhel-5). If the tags do not
>       match,
>       continue to the next content set.
>     - take the content set's url, and split it on $releasever. Take
>     the
>       section before the split, and append '/listing' to it. This is
>       the
>       location on the CDN where we expect to find a listing file for
>       this OS. add this file location to the listings list.
> - for each entry in listings, download the file from the cdn.
> - create a set containing all entries from all listings files.
> - done!
> 
> 
> As far as I can tell, SAM does:
> - for each content set, grab its listing file, if available. return a
>   set of the results.
> 
> 
> Katello/CFSE does:
> - for each enabled content set in a system's environment, get the
>   content set's applicable releases. return a set of the results.
> 
> I assume the CFSE results come from pulp, but let's also assume that
> they'll be identical to whatever the CDN would have.
> 
> Therefore, the difference between CFSE and SAM is that katello only
> examines the content sets that are enabled in a given environment.
> This
> makes sense, as any content not enabled is totally inaccessible for
> all
> consumers in that environment. SAM doesn't have environments, so the
> difference is moot.
> 
> Between katello and subman, katello's results should be a superset of
> what subman sees.
> 
> Subman removes the following content sets:
> - content sets that don't map to an installed product on the system
>   (makes sense, imo)
> - content sets that don't map to an entitled product on the system
>   (makes sense for subman. could probably be a toggle for katello,
>   defaulting to only showing entitled ones, or showing all if the
>   system
>   doesn't have any entitlements)
> - content sets that are not enabled on the client (i dunno if katello
>   has access to this, but i think this could fall in with the above
>   logic)
> - content sets that don't map to a product tagged with rhel-N (this
> is
>   probably a bit broken. we should maybe be looking for a product
>   tagged
>   with baseOS or something? but its more of an optimization; other
>   content sets won't have listing files. safe to ignore for katello).
> - content sets that aren't tagged with the same rhel version as the
>   installed product (this makes sense to do in katello if possible,
>   and
>   again, probably as a toggle. you likely don't want to put your
>   system
>   on 6Server if it has 4AS installed).
> 
> Phew! That was a lot of stuff.
> 
> So, back to the original referenced bug. If the cli can use
> releaseVer
> against that SAM instance, but the gui can't, that totally sounds
> like a
> bug! The logic in both cli and gui should be the same, so we should
> rectify that, then if that makes the gui work, good. if not, there
> might
> be a bug in SAM.

So I think we are agreeing to put this BZ into the subscription-manager bucket at the moment?

Is this BZ a blocker in any way? It does need to be addressed, but in which release?

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




More information about the katello-devel mailing list