Bug 1376116
| Summary: | Vdsm install "api" package in the python global namespace | ||
|---|---|---|---|
| Product: | [oVirt] vdsm | Reporter: | Nir Soffer <nsoffer> |
| Component: | Core | Assignee: | Piotr Kliczewski <pkliczew> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Petr Kubica <pkubica> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 4.18.0 | CC: | bugs, danken, lsvaty, mperina, nsoffer, oourfali, pkliczew, ybronhei |
| Target Milestone: | ovirt-4.1.1 | Keywords: | CodeChange |
| Target Release: | 4.19.7 | Flags: | rule-engine:
ovirt-4.1+
rule-engine: planning_ack+ oourfali: devel_ack+ pstehlik: testing_ack+ |
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-04-21 09:48:51 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | Infra | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
OUCH! it was unintentionally introduced by https://gerrit.ovirt.org/45750 and should be cleaned out quickly. This should be handled in 4.0.z? There's no immediate customer-related effect; it's just horribly ugly. It does not HAVE to be backported, but I surely won't object a backport. I do not understand what is the issue here. We only install vdsmapi module there which is vdsm specific. Schemas are in different place. Nir, any updates? The description of the bug is very clear, it does not matter what is shipped in the api package, but it cannot be installed as "api". It must be part of the vdsm package (vdsm.api). Another uglier way is to rename it to vdsm_api. Moving to Piotr - please decide between you guys how you want the package to be installed and change the spec accordingly We can move vdsmapi module which is the only vdsm specific thing. Other ideas need to stay there because they need to be used without vdsm. (In reply to Piotr Kliczewski from comment #8) > We can move vdsmapi module which is the only vdsm specific thing. Other > ideas need to stay there because they need to be used without vdsm. moving api to vdsm.api does not mean it is part of the vdsm package. We can have: vdsm.rpm - install vdsm/* vdsm-api.rpm - install vdsm/api/* If you install vdsm-api, you will get this directory layout: vdsm/ api/ ... This is the nicest way to handle this. It will work best if all modules under vdsm are moved to vdsm.common. (In reply to Nir Soffer from comment #9) > (In reply to Piotr Kliczewski from comment #8) > > We can move vdsmapi module which is the only vdsm specific thing. Other > > ideas need to stay there because they need to be used without vdsm. > > moving api to vdsm.api does not mean it is part of the vdsm package. We can > have: > > vdsm.rpm - install vdsm/* > vdsm-api.rpm - install vdsm/api/* > > If you install vdsm-api, you will get this directory layout: > > vdsm/ > api/ > ... > This was exactly something which we did not want (In reply to Piotr Kliczewski from comment #10) > > If you install vdsm-api, you will get this directory layout: > > > > vdsm/ > > api/ > > ... > > This was exactly something which we did not want Why? Le's talk about it and stop this ping pong here. The reason is to separate schemas from vdsm which should be used by the engine. Missed RC build, moving to 4.1.1 proposing CodeChange checked that its now under /usr/lib/python2.7/site-packages/vdsm/api/vdsmapi.py thus moving to VERIFIED |
Description of problem: vdsm-api package is installed in: /usr/lib/python2.7/site-packages/api This is not acceptable, vdsm cannot claim the api package for itself, and it does not make sense for user of this library, having to import it like this: import api The proper place for the vdsm-api package is under the vdsm package, so users will import it like this: from vdsm import api Version-Release number of selected component (if applicable): Since the package was released (3.6?) Since the package does not include useful code for users at this point, it should be very easy to move it.