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:

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?