- Devel - oVirt List Archives

[Engine-devel] restapi: Permissions in Capabilities (#859225)
by Ori Liel 09 Dec '13

09 Dec '13

When listing the application's capabilities we currently show 'permissions' both for each version, and outside versions altogether: GET .../api/capabilities <capabilities> <permits></permits> <version major="3" minor="1" href="/api/capabilities/332e3133-2e31-332e-3133-2e31332e3133" id="332e3133-2e31-332e-3133-2e31332e3133"> <permits>...</permits> </version> <version major="3" minor="0" href="/api/capabilities/332e3033-2e30-332e-3033-2e30332e3033" id="332e3033-2e30-332e-3033-2e30332e3033"> <permits>...</permits> </version> </capabilities> 1) Permissions should only exist within a version; their current existence outside 'version' is for backwards compatibility only. We assume that no one (except perhaps Automation) uses these non-version-specific permissions these days, and we'd like to remove them. 2) Regarding permissions within a version - Oded brought up that some permissions which are only relevant for 3.1 are listed also under 3.0 (for example, quota related permissions). In order for the API layer to be able to group permissions by version, permission<-->version metadata must exist somewhere. The permissions enum in the engine seems a natural place to put it, as Michael commented. Setting out to do this, I realized that which-permission-belongs-to-which-version is knowledge that I don't have, and don't really know how to get efficiently, and I sort of got stuck because of this. Ideas regarding this issue? Thanks, Ori.

1 0

Re: [Engine-devel] Jenkins JAVA_HOME
by Itamar Heim 06 Dec '13

06 Dec '13

On 12/05/2013 09:55 PM, Gustavo Frederico Temple Pedrosa wrote: > Hello all, > > I have two changes that the build failed with "Error: JAVA_HOME is not > defined correctly." > > Anyone knows how I fix this? more details/link?

3 2

[Engine-devel] Using config values
by Kanagaraj 04 Dec '13

04 Dec '13

This is a multi-part message in MIME format. --------------050008020702070900040001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi All, The are some issues arising in configurations whenever we move up on the versions(3.3 => 3.4), because of the way we store and interpret them. Whenever there is a new cluster level, you will need to add a new entry for all(most) of the configuration. Mostly a copy paste if you see from 3.2 to 3.3, except some CPU/PM type related configurations. Better option would be to have the defaul config value in ConfigValues.java and the overrides will go to config.sql. In this approach you don't need a new entries to config.sql when there is a new cluster level. Lets take an exmaple, "SupportForceCreateVG" - This is supported from 3.1 onwards, If you look at config.sql, you will see following entries select fn_db_add_config_value('SupportForceCreateVG','false','3.0'); select fn_db_add_config_value('SupportForceCreateVG','true','3.1'); select fn_db_add_config_value('SupportForceCreateVG','true','3.2'); select fn_db_add_config_value('SupportForceCreateVG','true','3.3'); And in ConfigValues.java @TypeConverterAttribute(Boolean.class) @DefaultValueAttribute("false") SupportForceCreateVG, Now if there is 3.4 and 3.5, the user needs to add 2 more entries, which i feel is redundant. Instead we can make @TypeConverterAttribute(Boolean.class) @DefaultValueAttribute("true") SupportForceCreateVG, and have only the following in config.sql select fn_db_add_config_value('SupportForceCreateVG','false','3.0'); if a particular value(for a specific cluster level) is not found in Config.sql, the fallback is to use the value available in ConfigValues.java. Please share your thoughts on this. Thanks, Kanagaraj --------------050008020702070900040001 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </head> <body bgcolor="#FFFFFF" text="#000000"> Hi All,<br> <br> The are some issues arising in configurations whenever we move up on the versions(3.3 => 3.4), because of the way we store and interpret them.<br> <br> Whenever there is a new cluster level, you will need to add a new entry for all(most) of the configuration. Mostly a copy paste if you see from 3.2 to 3.3, except some CPU/PM type related configurations.<br> Better option would be to have the defaul config value in ConfigValues.java and the overrides will go to config.sql. In this approach you don't need a new entries to config.sql when there is a new cluster level.<br> <br> Lets take an exmaple, "SupportForceCreateVG" - This is supported from 3.1 onwards,<br> <br> If you look at config.sql, you will see following entries <br> select fn_db_add_config_value('SupportForceCreateVG','false','3.0'); <br> select fn_db_add_config_value('SupportForceCreateVG','true','3.1'); <br> select fn_db_add_config_value('SupportForceCreateVG','true','3.2'); <br> select fn_db_add_config_value('SupportForceCreateVG','true','3.3');<br> <br> And in ConfigValues.java<br> <br>     @TypeConverterAttribute(Boolean.class)<br>     @DefaultValueAttribute("false")<br>     SupportForceCreateVG,<br> <br> Now if there is 3.4 and 3.5, the user needs to add 2 more entries, which i feel is redundant.<br> <br> Instead we can make <br> <br>     @TypeConverterAttribute(Boolean.class)<br>     @DefaultValueAttribute("true")<br>     SupportForceCreateVG,<br> <br> and have only the following in config.sql<br> select fn_db_add_config_value('SupportForceCreateVG','false','3.0');<br> <br> if a particular value(for a specific cluster level) is not found in Config.sql, the fallback is to use the value available in ConfigValues.java.<br> <br> Please share your thoughts on this.<br> <br> Thanks,<br> Kanagaraj<br> <br> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </body> </html> --------------050008020702070900040001--

8 13

[Engine-devel] Adding users and assigning roles in Ovirt
by Ramesh 03 Dec '13

03 Dec '13

Hi All, We have 'Add' action under 'Users' main tab to add users in Ovirt . It looks slightly different from the "Add user" option of the Configure option. Actually, this one is missing the "Role to Assign" option. I think without assigning any role, adding a user is not meaningful and it didn't complete the flow. Currently to assign any role to the user, either we have to use 'Configure' option ( to add system permission) or we have to go to the specific entity and add permission for that entity. It will be nice if we can assign roles( system level permissions) while adding users in 'Users' tab itself. It will be a clear user flow where one can add user and assign role in the same place. I have attached both the screen shots. please share your thoughts. Regards, Ramesh

6 7

[Engine-devel] oVirt 3.3.2 Beta now available
by Sandro Bonazzola 03 Dec '13

03 Dec '13

The oVirt team is pleased to announce that the 3.3.2 Release is now available in beta. Release notes and information on the changes for this update are still being worked on and will be available soon on the wiki[1]. A new oVirt Node build will be available soon as well. You're welcome to join us testing [2] this beta release. [1] http://www.ovirt.org/OVirt_3.3.2_release_notes [2] http://www.ovirt.org/Testing/Ovirt_3.3.2_testing -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

[Engine-devel] Remove Comment column in main tabs
by Mike Kolesnik 02 Dec '13

02 Dec '13

------=_Part_40758794_854245147.1385448274314 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, When the comment RFE was added (in 3.3), there was also a column added to many main tabs. I would like to propose to get rid of the column (which can only house one icon or no icon), and instead if there's a comment on an entity just display the icon with the tooltip adjacent to the name. In this case the icon should probably be scaled down a bit since its huge. I think this would be a good alternative and save us some valued screen real estate. Thoughts, opinions? Regards, Mike ------=_Part_40758794_854245147.1385448274314 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html><body><div style="font-family: times new roman, new york, times, serif; font-size: 12pt; color: #000000"><div>Hi,<br></div><div><br></div><div>When the comment RFE was added (in 3.3), there was also a column added to many main tabs.<br></div><div><br></div><div>I would like to propose to get rid of the column (which can only house one icon or no icon),</div><div>and instead if there's a comment on an entity just display the icon with the tooltip adjacent to the name.<br></div><div><br></div><div>In this case the icon should probably be scaled down a bit since its huge.<br></div><div><br></div><div>I think this would be a good alternative and save us some valued screen real estate.<br></div><div><br></div><div>Thoughts, opinions?<br></div><div><br></div><div><span name="x"></span>Regards,<br>Mike<span name="x"></span><br></div><div><br></div></div></body></html> ------=_Part_40758794_854245147.1385448274314--

5 16

[Engine-devel] [oVirt jenkins] Weekly report on open tasks for ovirt-engine
by Jenkins ci oVirt Server 01 Dec '13

01 Dec '13

------=_Part_5305_987499901.1385856217394 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit <html><head></head><body><b>Files scanned: '**/*.java, **/*.py'. </b><br /> <b>Strings searched: FIXME | TODO | @deprecated </b> <br /><br /> Report: http://jenkins.ovirt.org/job/ovirt_engine_scan_open_tasks/14/tasksResult/?</body></html> ------=_Part_5305_987499901.1385856217394--

1 0

[Engine-devel] [ANN] new fedora20 nightlies rpms for oVirt are available for download
by Eyal Edri 30 Nov '13

30 Nov '13

fyi, oVirt infra has added support for nighlies rpms for various oVirt projects for fedora 20. the following has be done: - All ovirt projects were added f20 nightlies on jenkins.ovirt.org. (replaced f18, which is NOT built nightly anymore). - One jenkins f19 slave (vm02) was upgraded to f20, and we also have a bare metal host running f20 as well. - Nightlies rpms can be downloaded on the repos [1] - Nightlies publish & cleanup scripts were updated on the resources.ovirt.org to support f20. I didn't update any ovirt-node* job, since i'm not familiar with them. if you would like to build f20 builds, just add the 'fedora20' label to the relevant jobs. Eyal. [1] http://resources.ovirt.org/releases/nightly/rpm/Fedora/20/

1 0

Re: [Engine-devel] Fedora 20 support, Was: [Users] oVirt Weekly Meeting Minutes -- 2013-11-27
by Eyal Edri 30 Nov '13

30 Nov '13

I updated the environment to support f20, including new slave and nighlites. i will send a separate email on it soon to infra/users/devel. Eyal. ----- Original Message ----- > From: "Doron Fediuck" <dfediuck(a)redhat.com> > To: "Dan Kenigsberg" <danken(a)redhat.com>, "David Caro Estevez" <dcaroest(a)redhat.com> > Cc: board(a)ovirt.org, "users" <users(a)ovirt.org>, eedri(a)redhat.com, "Sandro Bonazzola" <sbonazzo(a)redhat.com> > Sent: Thursday, November 28, 2013 1:55:13 PM > Subject: Re: Fedora 20 support, Was: [Users] oVirt Weekly Meeting Minutes -- 2013-11-27 > > > > ----- Original Message ----- > > From: "Dan Kenigsberg" <danken(a)redhat.com> > > To: board(a)ovirt.org, "users" <users(a)ovirt.org> > > Cc: "Doron Fediuck" <dfediuck(a)redhat.com>, eedri(a)redhat.com > > Sent: Thursday, November 28, 2013 12:19:05 PM > > Subject: Fedora 20 support, Was: [Users] oVirt Weekly Meeting Minutes -- > > 2013-11-27 > > > > We've forgotten to discuss an important issue: Fedora 20, which is > > expected to be out in two weeks: > > http://fedoraproject.org/wiki/Releases/20/Schedule. > > I believe that ovirt-3.4 must support it, and that ovirt-3.3.2 would > > better do so. > > > > Toni has fixed two issues regarding Vdsm-networking, and they are going > > into ovirt-3.3.2 beta. However, we must perform much more comprehensive > > testing. > > > > We'd need to have f20 Jenkins slave(s), and someone in each team > > responsible to testing functionality. Who can cover for storage, virt, > > infra and integration? > > > > Dan. > > > > Indeed so, thanks Dan. > David, is this something we have resources for? >

1 0

Re: [Engine-devel] [Users] oVirt Weekly Meeting Minutes -- 2013-11-27
by Sandro Bonazzola 29 Nov '13

29 Nov '13

Il 29/11/2013 13:13, Dan Kenigsberg ha scritto: > On Fri, Nov 29, 2013 at 11:49:59AM +0100, Sandro Bonazzola wrote: >> Il 29/11/2013 09:43, Gianluca Cecchi ha scritto: >>> On Fri, Nov 29, 2013 at 8:57 AM, Sandro Bonazzola wrote: >>> >>>>> >>>>> Meeting summary >>>>> --------------- >>>>> * Agenda and roll Call (doron, 15:02:42) >>>>> * 3.3 update releases (doron, 15:04:23) >>>>> * 3.4 planning (doron, 15:04:24) >>>>> * conferences and workshops (doron, 15:04:26) >>>>> * infra update (doron, 15:04:27) >>>>> * other topics (doron, 15:04:29) >>>>> * LINK: http://gerrit.ovirt.org/#/admin/projects/ovirt-release ~ >>>>> (danken, 15:12:58) >>>>> * LINK: http://gerrit.ovirt.org/21794 (mburns, 15:15:04) >>>>> * LINK: http://jenkins.ovirt.org/job/ovirt-release/16800/ (mburns, >>>>> 15:15:48) >>>>> * mburns to add sbonazzo as a maintainer to support ovirt-release >>>>> project (doron, 15:18:17) >>>> >>>> ovirt-release-9 released yesterday >>> >>> BTW: I see that this package contains >>> /etc/yum.repos.d/fedora-virt-preview.repo >>> (and ovirt-release-fedora-8-1.noarch already did so) >>> By default all lines are disabled in it. >>> When and how this repo should be enabled? Only when using nightly or >>> only under developers/maintainers indications? >> >> I think that fedora-virt-preview should be used with nightly, stable shouldn't need it. >> However, since fedora-virt-preview contains vdsm - related packages not needed if you run only ovirt-engine (without using the same host as >> hypervisor) I think it's better to wait for VDSM guys answer. > > Vdsm is not in > http://fedorapeople.org/groups/virt/virt-preview/fedora-20/x86_64/ > > virt-preview is not needed for ovirt-3.3, and frankly, I think it should > be dropped from ovirt-release. > > It used to be needed on the nodes when vdsm required a version of > libvirt that was not yet in Fedora. Now that we have el6 as a > fully-supported platform, and given that el6 is missing from > virt-preview, virt-preview is much less helpful to us. > > Dan. > So, any objection in removing virt-preview from ovirt-release? What about nightly? Will it be needed there? -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

2 1