[sorry sent previous email too early] Traditional OpenStack testing tool have had a pretty hard time to support multiple openstack releases because the openstack API community has been very opinionated in managing API evolution and backward compatibility. I’d like to provide some feedback from my perspective, if you forget for a moment how functest is designed today and testing tools that must run in functest in order to run at all…
It is still possible for openstack apps in general to support multiple openstack releases but that requires constant adjustment and potentially supporting multiple branches in the worst cases. Whether a project can manage to evade multiple branches depends on its footprint to openstack APIs and some luck. A simple example is the openstack api to manage floating IPs was removed starting from python neutron client 10.0.0, following a few releases of deprecation status, of course that broke a lot of apps but luckily there was an easy temporary fix to it: restrict the dependencies to use a version of that API < 10.0.0 and it was luckily working again. The better solution would be to change the code to use the new API for managing floating IPs but that is not an easy path because such API may not even exist or be properly documented (the case of floating IP being pulled without proper replacement API with proper documentation is just one example of miscommunication between the various teams involved in OpenStack). Python also allows tools to be able to support multiple APIs at runtime, so you could for example try something (old API) and if it fails try the second way – and still manage to avoid multiple branches. So it is not necessarily that bad for all apps to have one branch (master) supporting multiple openstack releases (e.g. releases in CD and traditional track), For example nfvbench has managed so far to support releases spanning from Liberty to Queens using just master. However that may not be that easy for every project … Functest in particular is at the opposite end as it is designed to control the exact set of library dependencies for every release and in a way that is strictly aligned to the openstack release under test. Meaning that some of the solutions I described above are not available to test projects that run under Functest: for example, you can’t downgrade your own project dependency because it is imposed by Functest (more precisely Functest will build you the container image that only has the strict set of libraries). But you could still program your way around it (e.g. at runtime try old way and if it fails try new way) but that requires proper adjustment in the code. Having said that, it will be up to the Barometer team to find out if they can handle more than 1 openstack release and I do agree it can potentially be a lot of work doing so. (Fatih) Perhaps a useful precision to provide to the community is an estimate of the spread in openstack release between the traditional tracks and the CD tracks. From what I can see it should not be more than 3 openstack releases? Alec From: <[email protected]> on behalf of "[email protected]" <[email protected]> Date: Saturday, April 21, 2018 at 9:22 AM To: David McBride <[email protected]>, Aaron Smith <[email protected]> Cc: "[email protected]" <[email protected]> Subject: Re: [opnfv-tech-discuss] [barometer] Both? Technically very difficult and it duplicates branches and all patchsets if barometer follows both master and stable. In case of Features integrated in Functest, it's even much more complex as it raises side effects on Functest, Snaps, requirement synchronization over the OPNFV projects, etc. Again the topic is interesting but we may take all technical details into consideration (see threads about first tests again XCI). From the time being, the model mostly fits a virtual installer and Apex. From the time being, the full model is built from a falsy upward compatibility (already discussed during release meeting). And all dependencies and needs regarding Functest are unmet. I will open a full thread about the falsy upward compatibility. Cédric On ven., 2018-04-20 at 15:32 -0700, David McBride wrote: Do both! :) On Fri, Apr 20, 2018 at 1:32 PM, Aaron Smith <[email protected]<mailto:[email protected]>> wrote: I am assuming participation in the Gambia release? The question is whether to switch to XCI or continue with the traditional release. Feedback? Aaron -- Mobile _______________________________________________ opnfv-tech-discuss mailing list [email protected]<mailto:[email protected]> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss -- David McBride Release Manager, OPNFV Mobile: +1.805.276.8018<tel:%2B1.805.276.8018> Email/Google Talk: [email protected]<mailto:[email protected]> Skype: davidjmcbride1 IRC: dmcbride _______________________________________________ opnfv-tech-discuss mailing list [email protected]<mailto:[email protected]> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
_______________________________________________ opnfv-tech-discuss mailing list [email protected] https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
