search

SUSE / suse-migration-services

GNU General Public License v3.0
7 stars 11 forks source link

Allow for vendor change during migration #137

Closed schaefi closed 5 years ago

schaefi commented 5 years ago

The migration concept allows for the zypper dup as well as for the zypper migrate approach. In the first case the user is responsible for setting up the repos and we expect that to be done in a way that vendor changes are acceptable. In the second case a repository server is used to serve the repos and we expect that registration instance to be trustworthy such that potential vendor changes are also allowed

rjschwei commented 5 years ago

I think this may have unintended consequences and should be configurable with package_vendor=strict|permissive we can make permissive the default.

schaefi commented 5 years ago

If we allow this to be handled strict the migration will abort, meaning no migration possible for this system. I'm just thinking under which condition it would be useful to reach this condition ? I think users that starts the migration the way we offered it have the most interest to get their system migrated.

I think the switch would never be used especially when permissive is the default. If the default is strict it would probably just annoy people.

I also thought it would be good to have this configurable but then I went through the situations people use it and thought the scope is on getting migrated and if a vendor change is needed people will accept it otherwise a migration is not possible without changing the system content or repo setup. I think users running the migration are more concerned in changing those than accepting a vendor change in the upgrade process.

Thoughts ?

rjschwei commented 5 years ago

A vendor change can only be triggered based on the configured repositories that is correct. And there is probably a reasonable argument to be made that a user before using migration should ensure they understand their repository setup and know where packages are being pulled from. However do that is rather complicated. Being strict with vendor changes highlights these issues.

One use case that i can think of that would want a strict configuration is the case where a vendor ships a dependent package for their application, let's say libpng for argument sake. We also ship libpng. Now when migration runs zypper will pull a newer version of libpng onto the system from the new distribution. This may or may not break the application. However, because we allowed the vendor change from $ISV_VENDOR to $SUSE the issue gets hidden and becomes difficult to debug. If vendor change is not allowed then the issue gets surfaced.

We can of course argue that the user tests $APP on $NEW_DISTRO before running migration but that would not necessarily surface this issue.

I am fine leaving it as is and we can add a config switch when the issue comes up.

schaefi commented 5 years ago

I am fine leaving it as is and we can add a config switch when the issue comes up.

ok sounds good to me. I'm not sure how long this project will survive and also don't think we should put too much energy into it. The concept is nice but I think there are people at suse who work with more effort on this topic, yast, suse-manager.. For the purpose of a dedicated upgrade solution like we use it in the public cloud it's fine and in that scenario we don't want to be blocked by the vendor change since all the repos are the result of the request to a trusted repository server.

So I'm going to merge it as it is right now and am happy with your agreement that we do it when there is an issue

Thanks