Subscription Manager vs deployment configs

[petervo]

I spent way too long trying to figure out why the remote portion of my deployment refspecs would get reverted back to rhel-atomic-host-ostree after a booting into a rebased deployment. Breaking any further updates or changes. Eventually I figured out that it wasn't a ostree bug but subscription-manager was rewriting the deployment origin files.

While I understand the motivation here, this behavior is very unexpected and pretty much makes any sort of multiple remote workflows completely unworkable on a system running subscription-manager. At the very least this should be documented with a warning somewhere, or maybe it already is but I wasn't able to find it.

IMO subscription manager should not change configurations that users have explicitly configured and deployed on their own. One possible solution is to only automatically change deployments that are explicitly configured to be changed like that. This could be done by adding something to the remote config file in /etc/ostree/remote.d for example

managed-by-subscription = true

then subscription manager would only touch deployments for configurations where managed-by-subscription is a truthy value.

Or if @cgwalters prefers subscription manager doesn't pollute the ostree remote config files subscription manager can maintain it's own list.

[stefwalter]

This breaks the Cockpit integration tests. @petervo Does this break functionality for real users? If so, do you have a moment to outline a reproducer?

[petervo]

As I said above it means you can't rebase a system running the subscription manager daemon to a different origin. The reproducer is rebase / reboot and then wait a few seconds for subscriptions manager to rewrite the origin.

[cgwalters]

Indeed we didn't consider this when doing the initial subman 🔧 ostree designs. managed-by-subscription=true would be utterly trivial to add to the remote configs if subman would use it.

[stefwalter]

@cnsnyder Where does the code need to be changed to make this happen?

@petervo What would reliably set managed-by-subscription=true? Does subscription-manager setup the remote.d config, and would include that setting?

[petervo]

On 04/26/2016 12:27 AM, Stef Walter wrote:

@cnsnyder https://github.com/cnsnyder Where does the code need to be
changed to make this happen?

The relevent code is here:
https://github.com/candlepin/subscription-manager/blob/master/src/subscription_manager/plugin/ostree/model.py

I can make changes once @cnsnyder or someone from subscription-manager
indicates that they like this plan.

@petervo https://github.com/petervo What would reliably set
|managed-by-subscription=true|? Does subscription-manager setup the
|remote.d| config, and would include that setting?

I assume that it would be up to the distro to include that setting with
the config that they ship. Or are there other use cases to consider?

[stefwalter]

I assume that it would be up to the distro to include that setting with the config that they ship. Or are there other use cases to consider?

Makes sense. I just figured there needs to be good heuristic to detect whether an ostree config came from the distribution or was inserted manually. I'm fine with it happening either way.

[cgwalters]

TL;DR, before one uses rpm-ostree rebase do this:

# systemctl stop rhsmcertd
# systemctl mask rhsmcertd

[miabbott]

I believe this is a relevant BZ 1226007

[cgwalters]

ostreedev/ostree#627 will be the inverse of this - so we can change things so subman only edits remotes with this flag.

[jirihnidek]

Hi, I am closing old issues. I believe that this issue is not valid anymore, because ostree is not supported by subscription-manager in main branch.