[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