Bug 1119030

Summary:	skip_if_unavailable to correctly treat repos that are down during package download
Product:	[Fedora] Fedora	Reporter:	Jaroslav Škarvada <jskarvad>
Component:	dnf	Assignee:	Packaging Maintenance Team <packaging-team-maint>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	low
Version:	21	CC:	jsilhan, jzeleny, packaging-team-maint, petersen, pnemade, rholy, tim.lauridsen
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	hawkey-0.5.3-2.fc21	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-02-20 08:32:05 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Jaroslav Škarvada 2014-07-13 10:16:03 UTC

Description of problem:
I have some optional repos that are accessible only from the office or through the VPN and they have "skip_if_unavailable=1" in their .repo files. The problem is if I try to update the system outside office and without VPN and if there are update candidates in the optional repos, the update process fails.

Version-Release number of selected component (if applicable):
dnf-0.5.3-1.fc20.noarch

How reproducible:
Always

Steps to Reproduce:
1. Have repo with skip_if_unavailable=1 and with update candidates
2. Let metadata to sync
3. Make the repo unavailable
4. dnf upgrade

Actual results:
Update fails

Expected results:
No failure, repo skip

Additional info:
I encountered this with the qa repo (http://liver.englab.brq.redhat.com/repo/) and I got the following error:
[FAILED] qa-tools-workstation-3.2-278.x86_64.rpm: No more mirrors to try - All mirrors were already tried without success

It seems to work if I use --disablerepo=qa or if I clean the cache/metadata by:
# dnf clean all

It is annoying if there are more optional repos to use --disablerepo for all of them. I think the skip_if_unavailable=1 should work here.

Comment 1 Ales Kozumplik 2014-07-14 05:06:19 UTC

Hello, thanks for the report, we'll take a look at what can be done: either provide this or update the documentation of `skip_if_unavailable`.

Comment 2 Jens Petersen 2015-02-13 09:29:49 UTC

+1 to fixing this.  I see this behaviour with F21 too.
I feel this this should be higher than low priority.

Naively this behaviour seems to contradict https://github.com/rpm-software-management/dnf/blob/master/doc/cli_vs_yum.rst#skip-if-unavailable-enabled-by-default

Comment 3 Jens Petersen 2015-02-13 09:38:31 UTC

Ah okay sorry I understand this is about if there is only an update in
the unavailable repo then: then I suggest just making an better error
message to that effect.

Comment 4 Jens Petersen 2015-02-13 09:39:23 UTC

(or maybe the behaviour has improved in 0.6?)

Comment 5 Jaroslav Škarvada 2015-02-13 09:45:55 UTC

(In reply to Jens Petersen from comment #3)
> Ah okay sorry I understand this is about if there is only an update in
> the unavailable repo then: then I suggest just making an better error
> message to that effect.

The problem is that it doesn't complete the transaction. It can write any error it likes, but it should complete the transaction without the unavailable packages (which aren't deps). It is pain discovering which package belongs to which repo and disabling such repo by hand.

Comment 6 Jaroslav Škarvada 2015-02-13 09:48:07 UTC

If skip_if_unavailable=1, unavailable repos should be skipped for download, even if cached.

Comment 7 Jens Petersen 2015-02-13 10:00:12 UTC

Sorry for too many comments (I am jetlagged too): I think what I saw
on F21 was just just a "repo unavailable warning": "dnf --refresh update"
actually worked for me without disabling the unavailable repo.
So it was just the lack of any updates that confused me.

Comment 8 Jens Petersen 2015-02-13 10:01:40 UTC

Jaroslav: is the behaviour better on F21, ie worse with F20?

Under F21 dnf seems to do the expected thing I think.

Comment 9 Jaroslav Škarvada 2015-02-13 13:21:15 UTC

(In reply to Jens Petersen from comment #8)
> Jaroslav: is the behaviour better on F21, ie worse with F20?
> 
> Under F21 dnf seems to do the expected thing I think.

I currently cannot say, I need to retest. But I haven't noticed this problem any more since the switch to f21, so it was probably fixed.

Comment 10 Fedora Update System 2015-02-16 00:02:56 UTC

dnf-plugins-core-0.1.5-1.fc21,hawkey-0.5.3-2.fc21,dnf-0.6.4-1.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/dnf-plugins-core-0.1.5-1.fc21,hawkey-0.5.3-2.fc21,dnf-0.6.4-1.fc21

Comment 11 Fedora Update System 2015-02-17 08:03:51 UTC

Package hawkey-0.5.3-2.fc21, dnf-plugins-core-0.1.5-1.fc21, dnf-0.6.4-1.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing hawkey-0.5.3-2.fc21 dnf-plugins-core-0.1.5-1.fc21 dnf-0.6.4-1.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-2139/dnf-plugins-core-0.1.5-1.fc21,hawkey-0.5.3-2.fc21,dnf-0.6.4-1.fc21
then log in and leave karma (feedback).

Comment 12 Jens Petersen 2015-02-17 09:35:52 UTC

This is an F20 bug, so not completely sure why it was included in
FEDORA-2015-2139.  Maybe it should be removed?  Or can you summarize
what changed?

AFAICT there is no serious problem with F21 but I prefer yum's
behaviour of only showing the warning for update not all commands
like dnf seems to do.  So I'd like to suggest doing the same
in dnf: only print the "repo unavailable" when doing dnf update
I think.  I can also file a separate RFE for that behaviour...

Comment 13 Fedora Update System 2015-02-20 08:32:05 UTC

hawkey-0.5.3-2.fc21, dnf-plugins-core-0.1.5-1.fc21, dnf-0.6.4-1.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 14 Honza Silhan 2015-03-05 14:27:58 UTC

(In reply to Jens Petersen from comment #12)
> This is an F20 bug, so not completely sure why it was included in
> FEDORA-2015-2139.  Maybe it should be removed?  Or can you summarize
> what changed?

This bug was still in the upstream.

> AFAICT there is no serious problem with F21 but I prefer yum's
> behaviour of only showing the warning for update not all commands
> like dnf seems to do.  So I'd like to suggest doing the same
> in dnf: only print the "repo unavailable" when doing dnf update
> I think.  I can also file a separate RFE for that behaviour...

For me it makes more sense to print it everytime you deal with available packages (when it downloads new metadata) - the way DNF does it now. No need to file RFE :)