Open Stack

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