Bug 857018
Summary: | rhevm-sdk: make /filter header global rather than method driven | ||
---|---|---|---|
Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Ondra Machacek <omachace> |
Component: | ovirt-engine-restapi | Assignee: | Michael Pasternak <mpastern> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Ondra Machacek <omachace> |
Severity: | medium | Docs Contact: | |
Priority: | high | ||
Version: | 3.1.0 | CC: | acathrow, bazulay, bdagan, dyasny, ecohen, iheim, lpeer, mpastern, oourfali, oramraz, Rhev-m-bugs, yeylon, ykaul |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | infra | ||
Fixed In Version: | si20 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2012-12-04 19:59:35 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: |
Description
Ondra Machacek
2012-09-13 11:56:45 UTC
Ondrej , please explain which operations you are trying to perform and the list of permissions your users has . It looks like API related issue , please change bug component if needed . I think it is same issues as bz 854296, because everything works for me with via REST API. Some things I tryied: 1) Add user with "TemplateOwner" role on DC. 2) Try to run code below. code(version of ovirtsdk is 3.2.0.1): API = ovirtsdk.api.API( url='https://url:443/api', insecure=True, username='newUser', password='password', filter=True) vm = API.vms.get(name='vmName') API.templates.add(params.Template(name='templateName', vm=vm)) # Fails # same for template.nics.add(params.NIC()) # same for API.templates.get(templateName).delete() Getting an error: query execution failed due to insufficient permissions. This error is getting also via REST API if i use curl and don't use "Filter: true" header. After some playing around i think 'filter' header is missing in all permission which are the same for Admin roles and user roles. That are all permissions which has these roles: TemplateOwner, DiskCreator, TemplateCreator, VmCreator, DiskOperator, UserVmManager, PowerUserRole, UserRole. Michael - are there operations that we shouldn't pass the filter header to? If the answer is no, shouldn't we somehow use the filter header definition (Filter: {value: true|false, required: false}) only in one place, making all the actions inherit it? (In reply to comment #4) > Michael - are there operations that we shouldn't pass the filter header to? good question, asaf? > If the answer is no, shouldn't we somehow use the filter header definition > (Filter: {value: true|false, required: false}) only in one place, making all > the actions inherit it? it's doable, worth case, api will ignore it (In reply to comment #5) > (In reply to comment #4) > > Michael - are there operations that we shouldn't pass the filter header to? > > good question, asaf? > > > If the answer is no, shouldn't we somehow use the filter header definition > > (Filter: {value: true|false, required: false}) only in one place, making all > > the actions inherit it? > > it's doable, worth case, api will ignore it ok, before we decide on making global filter=x, is there a use-case that admin user would like to run method X as filtered=true and method Y as filtered=false? (In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > Michael - are there operations that we shouldn't pass the filter header to? > > > > good question, asaf? > > > > > If the answer is no, shouldn't we somehow use the filter header definition > > > (Filter: {value: true|false, required: false}) only in one place, making all > > > the actions inherit it? > > > > it's doable, worth case, api will ignore it > > ok, before we decide on making global filter=x, is there a use-case > that admin user would like to run method X as filtered=true and method > Y as filtered=false? mention functionality can be achieved via: api.set_filter(true|false) between method invocations rhevm-sdk: make /filter header global rather than method driven we can wait for that use case to happen. but, iirc, there is planned work on handling multiple connections to different ovirt engines. that would mean diffrenet credentials to different engines. it would also mean for each connection different filter mode. so i'd argue filter mode can be a connection level property. and sdk should allow working with two connections to same engine, one filtered, and one not. actually, in a connection broker (user portal) implementation, i'd expect the code to keep a connection per user to same engine (and use filtred mode for all). |