On Friday, 15 July 2016 17:05:41 CEST Hayes, Graham wrote: > On 15/07/2016 17:52, Luigi Toscano wrote: > > On Friday, 15 July 2016 16:42:22 CEST Hayes, Graham wrote: > >> On 15/07/2016 17:10, Andrew Laski wrote: > >>>> Tempest plugins are another example. Approximately 30 of the 36 > >>>> current plugins are using resources that are not supposed to be > >>>> used, and are an unstable interface. Projects in tree in tempest > >>>> are at a much better position, as any change to the internal > >>>> API will have to be fixed before the gate merges, but other > >>>> out of tree plugins are in a place where they can be broken at any > >>>> point. > >>> > >>> Has there been an attempt to elevate these internal interfaces into > >>> stable and publicly consumable interfaces? Was there resistance to such > >>> an effort? > >> > >> When we have asked previously, we have been told that certain parts > >> of tempest "are not really meant for plugins". > >> > >> The main part that is used that is not part of the tempest stable > >> interface is the base test class. > >> > >> This is the bit that sets up credentials, clients, and other useful > >> things. > >> > >> There is a base test class in the tempest lib - but it is very sparse - > >> meaning any project using it would have to re-invent creating users, > >> resources, and clients. > >> > >> https://github.com/openstack/tempest/blob/master/tempest/test.py#L203 > >> vs > >> https://github.com/openstack/tempest/blob/master/tempest/lib/base.py#L22 > > > > This is a known situation, but it is being addressed right now. It's not > > like no one wants to have a stable Tempest interface, but it had to be > > cleanly built. > > There is a spec and work in progress to make the client manager interface > > stable: > > > > http://specs.openstack.org/openstack/qa-specs/specs/tempest/client-manager > > -refactor.html > > > > So yes, almost existing plugins are using unstable interfaces right now, > > but again this is not meant to be the long term scenario. > > > > Ciao > > Yeap - I have seen the spec. > > My point is that if all projects had to use the same plugin interface, > this would not be a problem.
Could you please clarify: do you advocate for a generic plugin interface for every project, or that each project should expose a plugin interface that allows plugin to behave as in-tree components? Because the latter is what happens with Tempest, and I see the former a bit complicated. > > If we have this as our default position as the community continues to > build more and more things like tempest, OSC, devstack, grenade we > should build it so there is not a discrepancy between projects. > > The root cause is not being addressed, as features can still land in > tempest, but not tempest.lib, and then can only be used by the projects > that tempest keeps as built in. I think I disagree here. The root cause is being addressed: external tests can use the Tempest plugin interface, and use the API, which is being stabilized. The fact that the Tempest API is partially unstable is a temporary things, due to the origin of the project and the way the scope was redefined, but again it's temporary. -- Luigi __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
