[ovirt-devel] [vdsm] new internal stable modules + proposal

[Nir Soffer]

On Tue, Mar 29, 2016 at 6:12 PM, Francesco Romani <fromani at redhat.com> wrote:
> Hi,
>
> in the last Vdsm developer call we agreed to promote a few modules in the common repository.
> The common repository provides the additional guarantees over regular modules in lib/vdsm/
>
> - stable API
> - (thus) safe to use across verticals
>
> the planned moves are:
>
> lib/vdsm/schedule.py -> lib/vdsm/common/schedule.py

+1

I think we want to move also the executor, used by virt and jsonrpc.
We plan to move all storage jobs
to the executor.

> lib/vdsm/periodic.py -> lib/vdsm/common/periodic.py

Is it used outside of virt?

> lib/vdsm/virt/api.py -> lib/vdsm/common/api.py

+1

>
> Question is if those modules should go under common/ or under another subdirectory, maybe infra?

I would not add infra package, common *is* infra.

>
> Lastly, i have a proposal about better handling of those modules.
>
> First, the mere fact a module is placed under lib/vdsm/common provides the extra guarantees I mentioned.
> But should we added more annotations?
>
> for example something like
>
> __API__ = {}
>
> near the top of the module
>
> if this attribute exist, then the module is safe to use across verticals, has stable API and so forth
> (this is _in addition_ to the common/ package, not as replacement).
>
> Like:
>
> __API__ = {
>   "introduced-in": "4.14.0",
>   "deprecated-from": "4.18.0",
>   "removed-at": "4.20.0",
>   "contact": "fromani at redhat.com"
> }

Since this is internal api, I don't think we need this info. The
guarantee you have when you
use such module is that it will never break your code. If someone one
is changing such module,
it must change and test the code using it.

Maybe the "standard" __author__ ?

Not sure it will help much, using git shortlog path/to/module is
probably more useful when you
look for someone to review a patch for some module.

>
> We could refine further this concept if we like it. The idea is to be lightweight as possible while
> carrying all the information we need.

Adding nothing is the most lightweight way :-)

Nir