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 1284653 - [RFE] Better semantics around ostree origin
Summary: [RFE] Better semantics around ostree origin
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: subscription-manager
Version: 7.3
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: candlepin-bugs
QA Contact: John Sefler
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-11-23 19:23 UTC by Colin Walters
Modified: 2016-12-01 17:03 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-12-01 17:03:59 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

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).
Note You need to log in before you can comment on or make changes to this bug.