Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1319913

Summary:	Ostree gets remote origin wrong when there are different remotes in deployments
Product:	Red Hat Enterprise Linux 7	Reporter:	Peter <pvolpe>
Component:	ostree	Assignee:	Colin Walters <walters>
Status:	CLOSED NOTABUG	QA Contact:	atomic-bugs <atomic-bugs>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	7.2	CC:	alikins
Target Milestone:	rc	Keywords:	Extras
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-03-21 21:51:45 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 Peter 2016-03-21 19:36:29 UTC

Description of problem:
ostree changes the remote after an upgrade attempt when the local deployments contain multiple ostree remotes.

Version-Release number of selected component (if applicable):
ostree-2016.1-2.atomic.el7.x86_64
rpm-ostree-client-2015.11-1.atomic.el7.1.x86_64


How reproducible:
Everytime

Steps to Reproduce:
cp /etc/ostree/remotes.d/redhat.conf /etc/ostree/remotes.d/local.conf

change first line to [remote "local"]
vi /etc/ostree/remotes.d/local.conf

#rebase
rpm-ostree rebase local:

#reboot
shutdown -r now

# shows everything normal
ostree admin status

# Nothing should change here if you started up to date.
ostree admin upgrade

# shows wrong remote on booted deployment
ostree admin status


Actual results:
ostree changes the remote from local to rhel-atomic-host-ostree after an upgrade attempt.


Expected results:
Remote should stay local after upgrade attempt.

Additional info:

Comment 1 Peter 2016-03-21 19:41:39 UTC

This doesn't seem to happen with 2015.11

Comment 3 Colin Walters 2016-03-21 20:30:26 UTC

Oh, I see.  Yes...the semantics here are confusing.  The current way ostree is designed is that when you do the `rebase` operation, you're setting the origin for the new deployment.  Your current origin is not changed.

`ostree admin upgrade` (and generally all operations) will only look at the currently booted system.  It happens to not redownload anything because we already got that commit, but the not-booted new deployment is just trashed.

Another way to look at this is, do `rpm-ostree rebase local:` again before the reboot and see it flip back.

So...is this a bug?  Changing things here would have large design implications...my inclination is not to try to do anything here (other than docs).

Do you have a use case for this?

Comment 4 Peter 2016-03-21 20:35:01 UTC

The rebase part was just to get the deployment list in the right state. I did reboot after the rebase. So the 'local' deployment was the booted deployment after the reboot completed. 

After the rebase reboot ostree admin status says:

* rhel-atomic-host 8b2cf24b420d659179dc866eab1bb341748839204ba56ed46a86218010789e91.1
    Version: 7.2.2-2
    origin refspec: local:rhel-atomic-host/7/x86_64/standard
  rhel-atomic-host 8b2cf24b420d659179dc866eab1bb341748839204ba56ed46a86218010789e91.0
    Version: 7.2.2-2
    origin refspec: rhel-atomic-host-ostree:rhel-atomic-host/7/x86_64/standard

Then you run ostree admin upgrade, this outputs:

No update available.

Nothing is changed but the origin for the booted deployment was changed and ostree admin status now says: 

* rhel-atomic-host 8b2cf24b420d659179dc866eab1bb341748839204ba56ed46a86218010789e91.1
    Version: 7.2.2-2
    origin refspec: rhel-atomic-host-ostree:rhel-atomic-host/7/x86_64/standard
  rhel-atomic-host 8b2cf24b420d659179dc866eab1bb341748839204ba56ed46a86218010789e91.0
    Version: 7.2.2-2
    origin refspec: rhel-atomic-host-ostree:rhel-atomic-host/7/x86_64/standard

Comment 5 Peter 2016-03-21 21:49:55 UTC

Turns out this was caused by rhsmcertd messing with the configurations. This is IMO not a great place to be, but not also not a ostree bug. I'll close this until I figure out where to refile.

Comment 6 Colin Walters 2016-03-21 22:13:00 UTC

Oh yes, right =(  

See https://bugzilla.redhat.com/show_bug.cgi?id=1117420 which is related to this.

I think we're going to have to coordinate better with subman somehow.   Adding Adrian to CC.

Let's open a different bug though, possibly on github?