Re: [Spacewalk-devel] Removal of entitlement counting code
This is a quick email. I'm getting ready for next weeks Red Hat Summit, but we agreed today that this makes sense for Spacewalk. I don't have all the answers - in fact, I hope others can give input/guidance. Below is stuff from the top of my tired head. We would like you to reach out to the main spacewalk users list, ensure that they are aware of what will change/break and get input, try to ensure we know the alternatives, if required. We'd like to try to ensure success and give guidance, but not lead ... consult, inform, give consent :) I suspect that work should be done either in a public branch or via a long running pull request. Ideally we'd try to have builds testable before it hits nightly. When it does hit nightly, we have users on nightly, react in a timely manner to issues raised and ensure users are aware before it hits nightly. Same for when next Spacewalk is released with this code changes. Being responsive to posts on the changes to the users list. The Spacewalk/Satellite team at Red Hat have concerns. We hope for minimal requirements on us before and after landing :) I think that is it for now. Hope folks have a great weekend. I'll be back in July :) Cliff On 26/05/15 14:07, Silvio Moioli wrote: Dear Spacewalkers, as briefly mentioned via chat we are planning coding efforts to drop entitlement counting code here at SUSE for the next major version. As subscription rules are very different in our own products, we plan to remove all Spacewalk counting code and add a new downstream-only module. We acknowledge that this code is probably still used in Satellite but as far as we know it makes very little sense in plain Spacewalk, and as no new Satellite versions are planned it shouldn't hurt to remove some cruft. Moreover, being implemented mostly in the database layer with heavy stored procedure use, this feature is sometimes causing hard-to-debug problems (examples: [1][2]). Is development team willing to accept our patches to drop it and clean up the result? If that is the case we will take care that development is done in an upstream-friendly way and all patches are sent to you via PR as soon as possible. We might also have other contributions on top of this one, but we are still early in the planning phases so we are not sure yet. I will of course keep you updated as development starts. [1] https://github.com/spacewalkproject/spacewalk/pull/233 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1063821 Regards, ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Getting rid of Repository Checksum Type None
Hi
While fixing our testsuite to run with PhantomJS, we hit a clunky
part:
- One is that when adding a channel, default checksum is sha1, parent
channel None. But:
- Changing the parent channel, triggers changing the checksum /
arch
to the parent channel one
- Except if you select Parent: None again, Checksum will be None
(and
not sha1) - BUG (and we can fix it and make a PR)
So to fix that bug, we found out that a None checksum makes
taskomatic
silently skip that channel for metadata generation which could be
very
confusing for users:
Duncan,
what you describe this is a feature that works as designed. :-)
RHEL4 clients and older used up2date instead of yum. And all the dependency
resolution wasn't done on the client, but on the server.
That's why no repodata was needed to generate for these channels.
'bad repo' was implemented to let the user know, there is no intention to
generate proper repodata and to say - we did not forget to generate
repodata for this channel as someone could have assumed.
And the 'none' checksum was used to mark these channels.
If this code bothers you and taking into consideration RHEL4 is EOL, we do not
need that code any more.
Feel free to create a PR, we're open to remove the code.
Regards,
--
Tomas Lestach
Red Hat Satellite Engineering, Red Hat
if (checksumtype == null) {
generateBadRepo(channel, prefix);
return;
}
So I was thinking to add a better log entry and may be a warning in
the
channel details page, but...
If we don't generate metadata for None, and this option is not part
of
checksumtype table, but manually added in the form:
ListMapString, String checksums = new ArrayListMapString,
String();
addOption(checksums, ls.getMessage(generic.jsp.none), );
for (ChecksumType chType :
ChannelFactory.listYumSupportedChecksums()) {
addOption(checksums, chType.getLabel(),
chType.getLabel());
}
Why not removing the None option alltogether? Does anyone see a
reason
to keep it?
Regards,
--
Duncan Mac-Vicar P. - http://www.suse.com/
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu,
Graham Norton, HRB 21284 (AG Nürnberg)
Maxfeldstraße 5, 90409 Nürnberg, Germany
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Getting rid of Repository Checksum Type None
Hello,
- Original Message -
From: Duncan Mac-Vicar P. dmacvi...@suse.de
To: spacewalk-devel@redhat.com
Sent: Wednesday, June 10, 2015 2:00:06 PM
Subject: [Spacewalk-devel] Getting rid of Repository Checksum Type None
Hi
While fixing our testsuite to run with PhantomJS, we hit a clunky part:
- One is that when adding a channel, default checksum is sha1, parent
channel None. But:
- Changing the parent channel, triggers changing the checksum / arch
to the parent channel one
- Except if you select Parent: None again, Checksum will be None (and
not sha1) - BUG (and we can fix it and make a PR)
So to fix that bug, we found out that a None checksum makes taskomatic
silently skip that channel for metadata generation which could be very
confusing for users:
if (checksumtype == null) {
generateBadRepo(channel, prefix);
return;
}
So I was thinking to add a better log entry and may be a warning in the
channel details page, but...
If we don't generate metadata for None, and this option is not part of
checksumtype table, but manually added in the form:
ListMapString, String checksums = new ArrayListMapString, String();
addOption(checksums, ls.getMessage(generic.jsp.none), );
for (ChecksumType chType :
ChannelFactory.listYumSupportedChecksums()) {
addOption(checksums, chType.getLabel(), chType.getLabel());
}
Why not removing the None option alltogether? Does anyone see a reason
to keep it?
According to tooltip in Spacewalk - 'Yum repository checksum type 'None' is
supported only for RHEL 3 and RHEL 4.'. I suppose we can remove this support
since we don't support these old RHELs anyway. I see you already created PR for
this bug, probably would be better to drop None checksum support first.
Regards,
--
Duncan Mac-Vicar P. - http://www.suse.com/
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu,
Graham Norton, HRB 21284 (AG Nürnberg)
Maxfeldstraße 5, 90409 Nürnberg, Germany
Regards,
--
Jan Dobes
Satellite Engineering, Red Hat
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
