Bug 1284653

Summary:	[RFE] Better semantics around ostree origin
Product:	Red Hat Enterprise Linux 7	Reporter:	Colin Walters <walters>
Component:	subscription-manager	Assignee:	candlepin-bugs
Status:	CLOSED WONTFIX	QA Contact:	John Sefler <jsefler>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.3	CC:	alikins, bcourt, csnyder, vrjain
Target Milestone:	rc	Keywords:	FutureFeature, Triaged
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-12-01 17:03:59 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 Colin Walters 2015-11-23 19:23:26 UTC

If I have a CentOS Atomic Host and want to live-rebase to RHELAH, currently subman will change the *current* deployment origin, but not change the branch name, i.e.:

rhel-atomic-host-ostree:centos-atomic-host/7/x86_64/standard

I think subman should unconditionally change the branch name as well; I believe we have this in the metadata?

Optional extras:

The above said, what would be a notable improvement in the CentOSAH -> RHELAH story here would be to combine attach+upgrade, and only change the *new* origin.
The rationale here is that it's confusing to have the *current* origin changed as it's really still CentOS.

I'm not totally sure if `subscription-manager attach` should be triggering an upgrade/deployment itself...maybe a new verb like `atomic host subscribe-update` or something?

Comment 2 Adrian Likins 2016-01-21 15:50:47 UTC

(In reply to Colin Walters from comment #0)
> If I have a CentOS Atomic Host and want to live-rebase to RHELAH, currently
> subman will change the *current* deployment origin, but not change the
> branch name, i.e.:
> 
> rhel-atomic-host-ostree:centos-atomic-host/7/x86_64/standard
> 
> I think subman should unconditionally change the branch name as well; I
> believe we have this in the metadata?

Sounds like a good feature, but with current code I think the DTO's used between candlepin/rhsm and subscription-manager[1] includes that branches info.
I don't think we have the branch name in the metadata, iow.

(Or at least not as an isolated field. We could possibly lump it into the url field and have the client split it, but that is still candlepin and subscription-manager changes, and possibly CDN/RCM changes)

So that may require some candlepin changes to get that info to the client.
Once the client has the branches data, the code change to replace it as well should be straightforward.


[1] via the content data in the ent cert itself and it's attached content data blob

Comment 3 Colin Walters 2016-01-26 16:27:39 UTC

(In reply to Adrian Likins from comment #2)
> (In reply to Colin Walters from comment #0)
> > If I have a CentOS Atomic Host and want to live-rebase to RHELAH, currently
> > subman will change the *current* deployment origin, but not change the
> > branch name, i.e.:
> > 
> > rhel-atomic-host-ostree:centos-atomic-host/7/x86_64/standard
> > 
> > I think subman should unconditionally change the branch name as well; I
> > believe we have this in the metadata?
> 
> Sounds like a good feature, but with current code I think the DTO's used
> between candlepin/rhsm and subscription-manager[1] includes that branches
> info.
> I don't think we have the branch name in the metadata, iow.

FWIW OSTree now has support for a `summary` file which contains all remote branches.  Fetchable from the commandline via `ostree remote summary`.  At the moment there's only one for RHEL...

But if we did have more than one, it gets into prioritization/entitlement things get murkier to me.

> So that may require some candlepin changes to get that info to the client.
> Once the client has the branches data, the code change to replace it as well
> should be straightforward.

Possibly though the simplest is for subman to just hardcode deleting the original installed branch (maybe only if the ref matches but the remote name differs).

I could also investigate changing the way we generate media so that we deploy by commit ID with no ref, but that would impact the UI and be...weirder.

Probably `atomic host status` is going to need to learn how to display things like entitlement status.

Comment 4 Chris Snyder 2016-12-01 17:03:59 UTC

We do not want subscription-manager to duplicate work that is better suited for the ostree native tools.

For the specific case of CentOSAH to RHELAH story, there should be a script that is provided via the customer portal that will run a system through the steps (including any cleanup of config, origin, branches, or other centos artifacts).