On 07/15/2009 08:51 AM, James Bowes wrote:
On Tue, Jul 14, 2009 at 12:14:49PM -0400, Pradeep Kilambi wrote:
Hey Guys:

So I'm mostly done with adding the sha256 checksum support for yum repo
generation in taskomatic and its fully functional. Now, currently the
way I have it working is, if the Channel or in child channel case (its
parent) is el5'ish or if its a custom channel then we use sha1, else we
default to sha256.  This works fine in all cases and specifically for
el5.

Now for custom channels, was thinking of another approach, this may be
for spacewalk-0.6 if we have time or do it in 0.7..

So basically, give the user an option to choose which checksum to use at
the channel creation time,

* In the createChannel page, we add a little field for user to chose
which checksum to use for repo cache. With a tip at the bottom that
suggests which option to choose when. for example,
<channel creation page>

Checksum Type for Repo: ______________________ (default to sha1 as its
less breakage prone. Or we can change this to sha256)
tip: Use sha1 if you're using older rpm content such as RHEL-5/Centos-5
       Use sha256 if you're using newer rpm content such as Fedora-11.

* If its a null org channel we go by what I have so far and decide by
channel release.

This adds little more extension to what I have but its probably better
in long run.

My take is leave it the way I have for space0.6 and do this improvement
for 0.7'ish.

What do you guys think ?

How about asking for the 'generation' or some such for the channel? You
could have:
                      _____________
Channel Generation: |f 11 or newer| (including hyperlink to help doc)
                     |f 6 / el 5   |
                     |f<  6        |
                     |el<  4       |
                     |other        |
                     ---------------

Yea something like that. I wanted to put out the thought of giving the user an option. I like the generation based approach as thats more abstract so user doesn't have to know the checksum details per se and we make the decision. I think this shouldn't be too hard to get it running.


Advanced>                            (expander, closed by default)
      Uses Yum for clients [ ]
      Checksum type for repo [              ]
      (Some kickstart suff maybe?)

I'm not sure if we need to get into this level of detail. If a channel is subscribed by a RHEL-5 it will anyway trigger the repo. If its using up2date we dont even ask for repo data, it directly goes through the db. But one issue I see is we subscribe an up2date based client to the custom channel and still trigger the generation.

~ Prad


--
--
Pradeep Kilambi
RHN Satellite Engineering
[email protected]
Phone: +1 919 754 4285
RHCE # 805008680430554


_______________________________________________
Spacewalk-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/spacewalk-devel

-James
------------------------------------------------------------------------

_______________________________________________
Spacewalk-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/spacewalk-devel


--
--
Pradeep Kilambi
RHN Satellite Engineering
[email protected]
Phone: +1 919 754 4285
RHCE # 805008680430554


_______________________________________________
Spacewalk-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/spacewalk-devel

Reply via email to