[Fuel Plugins] Change deprecation warning on 6.0 Fuel Plugins into a more user-friendly and clear

If i correctly understand, we do such thing in case of upgrade. In 6.1 env we can support 6.0 and 6.1 environments.

You suggest to prevent installation if no supported releases was found in env, for example it is clean 6.1 installation?

I had a discussion with Irina and Olena this morning and our suggestion is to update the deprecation warning to be explicit - i.e. if you are installing a plugin from scratch on MOS 6.1, it should say something to the effect of DEPRECATION WARNING: this plugin is incompatible with MOS 6.1 - please go to Fuel Plugin Catalog {link} to see if an updated version is available.

I think there is still work to be done on testing the upgrade use case with plugins (Oleg is documenting this/working on this now), but agree that making a previously compatible plugin unusable because the MOS version has been changed doesn't make much sense.

Fabrizio - would a more explicit deprecation warning be sufficient, from your perspective?

Sheena, from a customer/user standpoint, I'd expect if I download & install a plugin, it works.
And, if I download a plugin made specifically for 6.0 (not working on 6.1), and I attempt to install it on 6.1, it refuses to install warning the user: You should install this package {link} instead.

I tried to install LBaaS made for 6.0 on 6.1, it installed pretty smoothly, but it doesn't work. So is it a LBaaS plugin bug? I mean, will we make some plugins certified for 6.0+, so they can work on 6.0, 6.1, 6.2 and they should be installed on any version?

@Vladimir Sharshov, yes say you have a fresh 6.1, I'm trying to understand if the LBaaS I tried to install is not compatible with 6.1 or if it is just a bug in the plugin itself...

Guys, we should:
- improve deprecation warning we have right now
- make it appear for 6.1 and future 7.0 Fuel.

What do we need to get in that very message:
- link to fuel-infra Plugins Catalog (as we have community iso as well, no Mirantis is okay here)
- no weird 'plugin package' and stuff like that - only clear end user instructions

I'm still not sure why we can install 6.0 plugins at 6.1 Fuel.

I edited the bug and reassigned to Fuel Project as well.

Fabrizio -

I understand your concern, but until we understand the upgrade path for a MOS + plugin deployment, I do not want to create any sort of inability to install the plugin in any environment. We can revisit this once we have confirmed the behavior of a MOS + plugin environment upgrade.

Specifically: if a customer has a 6.0 environment with a plugin and then we upgrade to MOS 6.1 and there is an incompatibility specified, what would happen to the plugin running on the 6.0 environment? If the user wants to keep both their 6.0 environment and create new environments, how do we account for application plugins which the user might want to install that would be compatible with their original environment? Long-term we want to support the ability for a user to add non-core plugins to an environment after the deployment is complete. There maybe metadata living in the fuel-master node that knows which environments it is capable of supporting and we could map plugin installation to that, but it still wouldn't cover your exact use case (i.e. a user could still install a plugin that is not compatible with their new environment - 6.1 - and get confused/not be able to use it even though it is usable in their old environment - 6.0). This use case needs to be explored thoroughly before we make any decisions on preventing a plugin from installing.

If we are specifying compatibility both in the plugin catalog AND in a deprecation warning, I think that is sufficient for now.

I renamed the bug a bit, just to be more specific.

Not affect deployment/plugin installation. Small problem with UX. Moved to 8.0

Won't Fix for 7.0-updates and 6.1-updates because of Medium importance

This bug also affects 7.0 GA when user installs plugin designed for MOS6.1.
Here is no clear warning about incompatibility.

# fuel plugins --install zabbix_monitoring-1.0.0.noarch.rpm
DEPRECATION WARNING: /etc/fuel/client/config.yaml exists and will be used as the source for settings. This behavior is deprecated. Please specify the path to your custom settings file in the FUELCLIENT_CUSTOM_SETTINGS environment variable.
Loaded plugins: fastestmirror, priorities
Setting up Install Process
Examining zabbix_monitoring-1.0.0.noarch.rpm: zabbix_monitoring-1.0-1.0.0-1.noarch
Marking zabbix_monitoring-1.0.0.noarch.rpm to be installed
Loading mirror speeds from cached hostfile
mos7.0-security | 2.9 kB 00:00
mos7.0-security/primary_db | 1.1 kB 00:00
mos7.0-updates | 2.9 kB 00:00
mos7.0-updates/primary_db | 1.1 kB 00:00
Resolving Dependencies
--> Running transaction check
---> Package zabbix_monitoring-1.0.noarch 0:1.0.0-1 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

======================================================================================================================================================
 Package Arch Version Repository Size
======================================================================================================================================================
Installing:
 zabbix_monitoring-1.0 noarch 1.0.0-1 /zabbix_monitoring-1.0.0.noarch 12 M

Transaction Summary
======================================================================================================================================================
Install 1 Package(s)

Total size: 12 M
Installed size: 12 M
Downloading Packages:
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
  Installing : zabbix_monitoring-1.0-1.0.0-1.noarch 1/1
  Verifying : zabbix_monitoring-1.0-1.0.0-1.noarch 1/1

Installed:
  zabbix_monitoring-1.0.noarch 0:1.0.0-1

Complete!
Plugin zabbix_monitoring-1.0.0.noarch.rpm was successfully installed.

We passed SCF in 8.0. Moving the bug to 9.0.