[Engine-devel] REST-API: Problem with additional DELETE action at collection level
by Shubhendu Tripathi
This is a multi-part message in MIME format.
--------------050509030900000404030401
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Hi All,
There is a DELETE action defined at collection level for Gluster Bricks
with signature -
/@DELETE
public////Response//remove//(//GlusterBricks//bricks//);/
Recently we had needed a commit action to remove migrated bricks.
After multiple rounds of discussion on introducing a commit action to
remove migrated bricks we introduced a DELETE action [1] which accepts a
boolean parameter isForce.
If the parameter is set to /true/, forced deletion of bricks happens
without any data migration.
And if the parameter is not set or set to /false,/ the deletion is meant
for a brick on which migration has already taken place.
To achieve the above functionality we introduced another DELETE action
with new signature as below and also marked the first action as deprecated -
/@DELETE
public////Response//remove//(//Action//action//);/
The problem arises now as the new api works fine for all possible
scenarios with below input structure -
/
//<action>//
// <force>true/false</force>//
// <bricks>//
// <brick>//
// <name>//brick1-name</name>//
// <name>brick2-name</name>//
// </brick>//
// </bricks>//
//</action>/
BUT after these change backward compatibility is broken and the old api
does not work.
If we try invoking old DELETE with bricks as input parameter as below,
it still invokes the new api and gives an error saying "Invalid parameter".
/
//<bricks>
<brick id="brick1-id"/>
// <brick id="brick2-id"/>
</bricks>/
Kindly suggest a solution around the same.
*PS:* Both the actions are defined at collection level
(//api/clusters/<cluster-id>/glustervolumes/<volume-id>/bricks/)
[1]: http://gerrit.ovirt.org/#/c/21043/
Thanks and Regards,
Shubhendu
--------------050509030900000404030401
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>
There is a DELETE action defined at collection level for Gluster
Bricks with signature -<br>
<br>
<font color="#3333ff"><i><span class="kwd">@DELETE<br>
public</span></i><i><span class="pln"> </span></i><i><span
class="typ">Response</span></i><i><span class="pln"> remove</span></i><i><span
class="pun">(</span></i><i><span class="typ">GlusterBricks</span></i><i><span
class="pln"> bricks</span></i></font><span class="pun"><font
color="#3333ff"><i>);</i></font><br>
<br>
Recently we had needed a commit action to remove migrated bricks.
<br>
After multiple rounds of discussion on introducing a commit action
to remove migrated bricks we introduced a DELETE action [1] which
accepts a boolean parameter isForce.<br>
If the parameter is set to <i>true</i>, forced deletion of bricks
happens without any data migration.<br>
And if the parameter is not set or set to <i>false,</i> the
deletion is meant for a brick on which migration has already taken
place.<br>
<br>
To achieve the above functionality we introduced another DELETE
action with new signature as below and </span><span class="pun"><span
class="pun"><span class="pun">also marked the first action as
deprecated</span></span> -<br>
<br>
</span><span class="pun"><font color="#3333ff"><i><span class="kwd">@DELETE<br>
public</span></i><i><span class="pln"> </span></i><i><span
class="typ">Response</span></i><i><span class="pln"> remove</span></i><i><span
class="pun">(</span></i><i><span class="typ">Action</span></i><i><span
class="pln"> action</span></i></font><span class="pun"><font
color="#3333ff"><i>);</i></font><br>
<br>
The problem arises now as the new api works fine for all
possible scenarios with below input structure -<br>
<font color="#3333ff"><i><br>
</i><i><action></i><i><br>
</i><i> <force>true/false</force></i><i><br>
</i><i> <bricks></i><i><br>
</i><i> <brick></i><i><br>
</i><i> <name></i><i>brick1-name</name></i><i><br>
</i></font></span></span><span class="pun"><span class="pun"><font
color="#3333ff"><i><span class="pun"><span class="pun">
<name>brick2-name</name></span></span></i><i><br>
</i><i> </brick></i><i><br>
</i><i> </bricks></i><i><br>
</i><i></action></i></font><br>
<br>
BUT after these change backward compatibility is broken and the
old api does not work.<br>
If we try invoking old DELETE with bricks as input parameter as
below, it still invokes the new api and gives an error saying "<font
color="#ff0000">Invalid parameter</font>".<br>
<font color="#3333ff"><i><br>
</i></font></span></span><font color="#3333ff"><i><span
class="pun"><span class="pun"><span class="pun"><span
class="pun"><bricks><br>
<brick id="brick1-id"/><br>
</span></span></span></span></i></font><span class="pun"><span
class="pun"><font color="#3333ff"><i><span class="pun"><span
class="pun"><span class="pun"><span class="pun"><span
class="pun"><span class="pun"> <brick
id="brick2-id"/></span></span></span></span><br>
</bricks></span></span></i></font><br>
<br>
Kindly suggest a solution around the same.<br>
<br>
<b>PS:</b> Both the actions are defined at collection level (<font
color="#3333ff"><i>/api/clusters/<cluster-id>/glustervolumes/<volume-id>/bricks</i></font>)<br>
<br>
[1]: <a href="http://gerrit.ovirt.org/#/c/21043/">http://gerrit.ovirt.org/#/c/21043/</a><br>
<br>
Thanks and Regards,<br>
Shubhendu<br>
<br>
<br>
</span></span>
</body>
</html>
--------------050509030900000404030401--
10 years, 5 months
[Engine-devel] Custom properties per device + vNIC profile = not working (< 3.3)
by Mike Kolesnik
------=_Part_29121434_1238593392.1384156173914
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Hi,
I came across a situation where I wanted to define custom properties on a vNIC profile sitting under a network in a 3.2 data center.
>From what I saw the configuration value for custom properties (CustomDeviceProperties) is split into 4, one per each version (3.0, 3.1, 3.2, 3.3).
Since vNIC profile is located under the DC tree, it takes the DC version - 3.2 in this specific case.
I tried to set the config value for 3.2 but got:
$ engine-config -s CustomDeviceProperties="{type=interface;prop={myProp=[a-zA-Z0-9-]+}}" --cver=3.2
Cannot set value {type=interface;prop={myProp=[a-zA-Z0-9-]+}} to key CustomDeviceProperties. Device custom properties are not supported in version 3.2
This is already not very good, since in a 3.2 DC there can be 3.3 clusters with 3.3 hosts that do support custom device properties.
I also tried to alter the config value in the DB directly, but the custom properties code ignored it since custom properties are not supported in 3.2.
So, de facto, I have no reasonable way as a user to define custom device properties to use for my vNIC profiles in DC < 3.3.
I opened the bug https://bugzilla.redhat.com/show_bug.cgi?id=1028757 for this, however I also want to discuss the situation:
1. As a user, I can't set custom properties for level < 3.3 which is not good.
Removing the blocking, and loading custom properties for all versions would fix the bug and allow using custom device properties for older versions, the reasonable place to block this would be running a VM (or plugging a device).
Basically this is the lesser issue..
2. I just don't see the added value of splitting the definition of the properties per level..
The custom properties are extensions which might or might not be available to a certain VM, I don't see how having different sets of custom properties per version (what version, DC version, cluster version?) would make any difference - either the VM can utilize the extension given some state of the system, or it can't, but the determining factor is not the version but rather the availability of the extension.
For example, I can have a hook for vNIC altering some property installed on host A and not host B, if the VM runs on host A it will get this capability and on host B it won't, regardless the DC version the VM is in.
This is not to say we shouldn't block custom properties on the engine-VDSM API level since it's only available since 3.3, but this is handled by another config value (SupportCustomDeviceProperties) which is not alterable by the user.
So basically, I think splitting the value per version is over complication and see no added value to the users, just more maintenance should they choose to use this feature.
Your thoughts please.
Regards,
Mike
------=_Part_29121434_1238593392.1384156173914
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><body><div style=3D"font-family: times new roman, new york, times, se=
rif; font-size: 12pt; color: #000000"><div>Hi,<br></div><div><br></div><div=
>I came across a situation where I wanted to define custom properties on a =
vNIC profile sitting under a network in a 3.2 data center.<br></div><div>Fr=
om what I saw the configuration value for custom properties (CustomDevicePr=
operties) is split into 4, one per each version (3.0, 3.1, 3.2, 3.3).<br></=
div><div>Since vNIC profile is located under the DC tree, it takes the DC v=
ersion - 3.2 in this specific case.<br></div><div><br></div><div>I tried to=
set the config value for 3.2 but got:<br></div><div>$ engine-config -s Cus=
tomDeviceProperties=3D"{type=3Dinterface;prop=3D{myProp=3D[a-zA-Z0-9-]+}}" =
--cver=3D3.2<br>Cannot set value {type=3Dinterface;prop=3D{myProp=3D[a-zA-Z=
0-9-]+}} to key CustomDeviceProperties. Device custom properties are not su=
pported in version 3.2<br><br></div><div>This is already not very good, sin=
ce in a 3.2 DC there can be 3.3 clusters with 3.3 hosts that do support cus=
tom device properties.<br></div><div><br></div><div>I also tried to alter t=
he config value in the DB directly, but the custom properties code ignored =
it since custom properties are not supported in 3.2.<br></div><div>So, de f=
acto, I have no reasonable way as a user to define custom device properties=
to use for my vNIC profiles in DC < 3.3.<br></div><div><br></div><div>I=
opened the bug <a href=3D"https://bugzilla.redhat.com/show_bug.cgi?id=3D10=
28757">https://bugzilla.redhat.com/show_bug.cgi?id=3D1028757</a> for this, =
however I also want to discuss the situation:</div><div><br></div><div>1. A=
s a user, I can't set custom properties for level < 3.3 which is not goo=
d.<br></div><div> Removing the blocking, and loading cust=
om properties for all versions would fix the bug and allow using custom dev=
ice properties for older versions, the reasonable place to block this would=
be running a VM (or plugging a device).<br></div><div> B=
asically this is the lesser issue..<br></div><div><br></div><div>2. I just =
don't see the added value of splitting the definition of the properties per=
level..<br></div><div> The custom properties are extensi=
ons which might or might not be available to a certain VM, I don't see how =
having different sets of custom properties per version (what version, DC ve=
rsion, cluster version?) would make any difference - either the VM can util=
ize the extension given some state of the system, or it can't, but the dete=
rmining factor is not the version but rather the availability of the extens=
ion.<br></div><div> For example, I can have a hook for vN=
IC altering some property installed on host A and not host B, if the VM run=
s on host A it will get this capability and on host B it won't, regardless =
the DC version the VM is in.<br></div><div><br></div><div>  =
; This is not to say we shouldn't block custom properties on the engine-VDS=
M API level since it's only available since 3.3, but this is handled by ano=
ther config value (SupportCustomDeviceProperties) which is not alterable by=
the user.<br></div><div> So basically, I think splitting=
the value per version is over complication and see no added value to the u=
sers, just more maintenance should they choose to use this feature.<br></di=
v><div><br></div><div>Your thoughts please.<br></div><div><br></div><div><s=
pan name=3D"x"></span>Regards,<br>Mike<span name=3D"x"></span><br></div><di=
v><br></div></div></body></html>
------=_Part_29121434_1238593392.1384156173914--
10 years, 5 months
[Engine-devel] oVirt UI plugins feature announcements
by Vojtech Szocs
Hello everyone,
I'd like to share some important updates on oVirt UI plugins feature.
First of all, UI plugins wiki [1] is finally complete. API reference (application events, API functions, API options, entity types) now includes all the details and snippets of example code. I've also added section "Why load plugins via iframe element?" explaining reasons behind this design decision.
[1] http://www.ovirt.org/Features/UIPlugins
You might have noticed the changes in oVirt Engine URI layout [2], these are already reflected in UI plugins wiki. For existing plugins, this means changing URLs like this:
/webadmin/webadmin/plugin/ExamplePlugin/start.html
to this:
/ovirt-engine/webadmin/plugin/ExamplePlugin/start.html
[2] http://gerrit.ovirt.org/#/c/20473/
We're planning to merge patch "Improve UI Plugin vs. REST API integration" [http://gerrit.ovirt.org/#/c/20404/] soon, please review the change outlined in commit message, let me know if you have any questions.
Last but not least, oVirt Space Shooter (a.k.a UI plugins crash course) wiki [3] has been updated to reflect changes mentioned above.
[3] http://www.ovirt.org/Tutorial/UIPlugins/CrashCourse
Regards,
Vojtech
10 years, 5 months
[Engine-devel] Browsing source repository
by Bob Doolittle
Hi folks,
Do we have gitweb installed for the ovirt-engine repo, or is there any
other way of browsing the source repository without cloning the entire
thing?
Is there a description of the various branches in the ovirt-engine
repository? If I wanted to build the 3.3 source is the ovirt-engine-3.3
branch sufficient?
I'm afraid I am new to git and also to general source/build conventions
in place for Linux community projects, so sorry if my questions are
naive (I come from a long Unix development background but no FOSS
projects so far). I'm familiar with sccs, cvs, svn, and a little hg, but
not git (yet).
Thanks,
Bob
P.S. I'll be studying the User Portal primarily
10 years, 5 months
Re: [Engine-devel] [UX] how to design a bar/line chart?
by Justin Hammond
Not directly related, but it would be good if the UI could also display disk activity per VM and overall for a host.
I've got a few disk intensive VM's or the occasional memory starved VM that kills disk throughput for other VM's. it's always a struggle to identify them , so something in the UI would help me as a admin
Sent from my iPhone
On 6 Nov, 2013, at 11:45 PM, "Alexander Wels" <awels(a)redhat.com> wrote:
> I suppose we need to answer a few questions before we can go into which
> library is better:
>
> 1. Do we mind sending data over to Google so Google can render images for us.
> 2. Are we fine with just an image being displayed in the grid? If we aren't
> okay with #1, we will have to create some sort of servlet to generate the
> images.
> 3. Do we want the client to render the spark lines using javascript?
> 4. Do we want interactivity with these visualizations? For instance if I move
> my mouse over the spark line, does the value displayed change?
> 5. Can we display whatever we choice in our current grid implementation? I
> know the amount of javascript we can apply to it is somewhat limited right
> now.
> 6. Any other consideration I am not thinking of?
>
> Alexander
>
> On Wednesday, November 06, 2013 11:03:06 AM Malini Rao wrote:
>> Is this a possibility? Looks nicer. http://style.org/chartapi/sparklines/
>>
>> ----- Original Message -----
>> From: "Alexander Wels" <awels(a)redhat.com>
>> To: engine-devel(a)ovirt.org
>> Cc: "Malini Rao" <mrao(a)redhat.com>, "Tomas Jelinek" <tjelinek(a)redhat.com>,
>> "Eldan Hildesheim" <ehildesh(a)redhat.com>, "info" <info(a)eldanet.com> Sent:
>> Wednesday, November 6, 2013 10:46:01 AM
>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
>>
>> Maybe gchart is an option? Examples available here [1] one of the available
>> charts is a spark line. I just don't know how well that will play with our
>> grid implementation.
>>
>> [1]
>> http://clientsidegchart.googlecode.com/svn/trunk/javadoc/com/googlecode/gcha
>> rt/client/package-summary.html#ChartGallery
>> On Wednesday, November 06, 2013 10:24:56 AM Malini Rao wrote:
>>> Hey all,
>>>
>>> Comments inline-
>>>
>>>
>>>
>>> ----- Original Message -----
>>>
>>>> From: "Tomas Jelinek" <tjelinek(a)redhat.com>
>>>> To: "Einav Cohen" <ecohen(a)redhat.com>
>>>> Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Eldan Hildesheim"
>>>> <ehildesh(a)redhat.com>, "info" <info(a)eldanet.com>, "Malini Rao"
>>>> <mrao(a)redhat.com>, "Martin Polednik" <mpoledni(a)redhat.com> Sent:
>>>> Wednesday, November 6, 2013 9:58:03 AM
>>>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
>>>>
>>>> Hi Einav,
>>>>
>>>> ----- Original Message -----
>>>>
>>>>> From: "Einav Cohen" <ecohen(a)redhat.com>
>>>>> To: "Tomas Jelinek" <tjelinek(a)redhat.com>
>>>>> Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Eldan Hildesheim"
>>>>> <ehildesh(a)redhat.com>, "info" <info(a)eldanet.com>,
>>>>> "Malini Rao" <mrao(a)redhat.com>
>>>>> Sent: Wednesday, November 6, 2013 3:26:15 PM
>>>>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
>>>>>
>>>>> Hi Tomas,
>>>>>
>>>>> Like Itamar, I think that a line chart is a better idea, and that a
>>>>> chart per monitored fact (rather than a combined chart) is better.
>>>>
>>>> OK
>>>
>>> Based on the original request in the bug, it seems like Itamar is looking
>>> for a trend rather than just one data point. I think we are thinking along
>>> the correct lines here with a line graph but I think more specifically, we
>>> should consider sparklines -
>>> http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=0001OR. Agree
>>> that we should have one sparkline per fact but we may have to see how this
>>> looks when multiple sparklines reside in columns next to each other. See
>>> example of a grid where there are 2 sparklines next to each other -
>>> http://www.panopticon.com/Tables-Grids
>>>
>>>>>>> the statistics readable enough. Maybe if you hover the chart it
>>>>>>> could
>>>>>>> pop
>>>>>>> up a bigger version of the chart? Or not needed?
>>>>>
>>>>> this is a nice-to-have, I think, definitely not needed.
>>>>
>>>> OK
>>>
>>> Agree. As shown in the glucose example in the Tufte link I posted above,
>>> maybe all we need is to indicate the acceptable range with a band and if
>>> the last point is in the range or outside, it will be clear to the user if
>>> they should pay attention to it.
>>>
>>>>>>> - Would it be enough to have it in one color? Or should it be
>>>>>>> something
>>>>>>> like "the bigger the utilization the more red"?
>>>>>
>>>>> question is what will happen when there are a lot of "jumps": let's
>>>>> say
>>>>> that the graph changes from 0% to 100% to 0% to 100% and so on... what
>>>>> will be painted red? the entire line, but only in the periods that it
>>>>> jumps to 100%? only the parts of line that are in 100%?
>>>>> maybe a single color is enough.
>>>>
>>>> OK
>>>
>>> One color with a dot to indicate the most recent or most relevant data and
>>> display its value next to the sparkline
>>>
>>>>> I have another concern about this feature: currently, the GUI's most
>>>>> frequent
>>>>> refresh rate available is 5 seconds, which means that the line will
>>>>> "change"
>>>>> only every 5 seconds, which would be more noticeably slow when
>>>>> displayed
>>>>> in
>>>>> a form of a line chart (not even talking about lower frequencies).
>>>>> Moreover, I am not sure at what rate the VM statistics are pulled from
>>>>> VDSM,
>>>>> but if it is 10 seconds or 15 seconds, it means that the line in the
>>>>> GUI
>>>>> will
>>>>> be "flat" for every 2 reads / 3 reads, which is not so good, I think.
>>>>>
>>>>> any thoughts around that?
>>>>
>>>> Good point! AFAIK the VDSM is polled each 3 seconds for basic info (e.g.
>>>> the resource
>>>> usage not included) and than every 5th poll (e.g. every 15 seconds) for
>>>> full data
>>>> (with resource usage not included). This would indeed make the graph
>>>> pretty
>>>> useless.
>>>>
>>>> Michal proposed to do some averages on the VDSM site from more frequent
>>>> sampling and
>>>> send this average back to engine when polled - so we would display an
>>>> average after each poll (15s).
>>>>
>>>> I wonder if something like this is not already used on other places:
>>>> @Martin, do you know about something like this?
>>>
>>> Why does the change in the line need to seem palpable every few seconds? I
>>> think the base requirement of how accurate the data is when a user looks
>>> at
>>> a grid has not changed.. just the data visualization. Right? So , if the
>>> refresh rate is not a problem today, why is it a problem now? Am I missing
>>> something?
>>>
>>>>> ----- Original Message -----
>>>>>
>>>>>> From: "Itamar Heim" <iheim(a)redhat.com>
>>>>>> To: "Tomas Jelinek" <tjelinek(a)redhat.com>, "engine-devel"
>>>>>> <engine-devel(a)ovirt.org>
>>>>>> Sent: Tuesday, November 5, 2013 10:10:34 AM
>>>>>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart?
>>>>>>
>>>>>> On 11/05/2013 11:50 AM, Tomas Jelinek wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> There is a feature request [1] which aims to replace the resource
>>>>>>> utilization graphs (for example the cpu utilization from vm tab)
>>>>>>> by
>>>>>>> some
>>>>>>> which shows not only
>>>>>>> the actual percentage which is not so useful by some monitor
>>>>>>> graph.
>>>>>>>
>>>>>>> I have the following concerns:
>>>>>>> - I can think of a bar chart or a line chart and not sure what
>>>>>>> would
>>>>>>> be
>>>>>>> better.
>>>>>>> - Not sure if replacing the current chart with a bar/line chart
>>>>>>> would
>>>>>>> make
>>>>>>> the statistics readable enough. Maybe if you hover the chart it
>>>>>>> could
>>>>>>> pop
>>>>>>> up a bigger version of the chart? Or not needed?
>>>>>>> - Would it be enough to have it in one color? Or should it be
>>>>>>> something
>>>>>>> like "the bigger the utilization the more red"?
>>>>>>>
>>>>>>> Please advise from the UX perspective. As soon as the final design
>>>>>>> will
>>>>>>> be
>>>>>>> a bit more clear I will provide a feature page.
>>>>>>>
>>>>>>> Thank you,
>>>>>>> Tomas
>>>>>>>
>>>>>>> [1]: https://bugzilla.redhat.com/show_bug.cgi?id=803251
>>>>>>> _______________________________________________
>>>>>>> Engine-devel mailing list
>>>>>>> Engine-devel(a)ovirt.org
>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>
>>>>>> a moving trend graph (just like fedora's system monitor for
>>>>>> cpu/ram/network) is what i have in mind. so a line chart.
>>>>>> you could have a single chart with different lines for
>>>>>> cpu/ram/network,
>>>>>> or what seems to be more common, a chart per monitored fact
>>>>>> _______________________________________________
>>>>>> Engine-devel mailing list
>>>>>> Engine-devel(a)ovirt.org
>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel(a)ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
10 years, 5 months
[Engine-devel] [QE] 3.3.2 Release tracker
by Sandro Bonazzola
Hi,
as you may know, we're planning to build oVirt 3.3.2 beta really soon and release 3.3.2 by early December.
I have created a tracker bug (https://bugzilla.redhat.com/show_bug.cgi?id=1027349) for this release.
Beta build will be composed in 2 weeks.
The following is a list of the bugs with target 3.3.2 or 3.3:
Whiteboard Bug ID Summary
infra 987982 When adding a host through the REST API, the error message says that "rootPassword" is required...
infra 1017267 Plaintext user passwords in async_tasks database
infra 992883 VdsManager.OnTimer loads VDS instead of VdsDynamic
infra 1020344 Power Managent with cisco_ucs problem
infra 1009899 exportDbSchema scripts generates output file with wrong name
integration 1022440 AIO - configure the AIO host to be a gluster cluster/host
integration 1026926 engine-cleanup (and possible engine-setup) does not affect runtime value of shmmax
integration 902979 ovirt-live - firefox doesn't trust the installed engine
integration 1021805 oVirt Live - use motd to show the admin password
network 1019818 Support OpenStack Havana layer 2 agent integration
network 988002 [oVirt] [network] Add button shouldn't appear on specific network
network 987916 [oVirt] [provider] Dialog doesn't update unless focus lost
network 987999 [oVirt] [provider] Add button shouldn't appear on specific provider
storage 915753 Deadlock detected during creation vms in pool
storage 987917 [oVirt] [glance] API version not specified in provider dialog
storage 1024449 Check the performance with lvm-2.02.100-7
virt 1007940 Cannot clone from snapshot while using GlusterFS as POSIX Storage Domain
? 991267 [RFE] Add TUI information to log file.
Please set the target to 3.3.2 and add the bug to the tracker if you think that 3.3.2 should not be released without it fixed.
Please also update the target to 3.3.3 or any next release for bugs that won't be in 3.3.2: it will ease gathering the blocking bugs for next releases.
For those who want to help testing the bugs, I suggest to add yourself as QA contact for the bug.
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
10 years, 5 months
[Engine-devel] RFE: SPICE and VNC graphics at the same time
by Frantisek Kobzik
Dear devels,
I started working on a feature that allows user to run a VM with both SPICE and VNC graphics [1]. In the engine we derive the graphics server type (SPICE/VNC) from the video device (QXL/CIRRUS), which I think is wrong. These are two different things and should be treated separately. What I suggest is to split that configuration in vm_static into two fields:
1, (already existing) Display type with values QXL or CIRRUS
2, (new) Graphics types - enum or comma-separated string that indicates that the VM should be run with 'spice'/'vnc'/'spice,vnc'/'auto' (the last means that the type will be derived from the video device which is current behavior.
The feature would consist of three patches:
- vdsm - add new field in vm.conf with information about graphics types of a vm.
- engine backend - add graphics types to VM and corresponding entities, adjust xml rpc communication.
- engine frontend - "only" adjust the ui.
The patches would be backwards compatible with older engine/vdsm versions.
There are some things that must be taken into account, mostly it's about differences in SPICE/VNC supported features (like multimonitors, single qxl, smartcard, migration...). e.g. if you run a vm with both graphic types together the engine should probably disallow some spice features. But this is more of an implementation detail.
Feel free to reply if you have anything to say about this feature.
Cheers,
Franta.
[1]: https://bugzilla.redhat.com/show_bug.cgi?id=976044
10 years, 5 months
[Engine-devel] Missing: Always up-to-date documentation of oVirt
by David Jaša
--=-ln9kcnV6W2ZIoMc8ulrR
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi,
The oVirt project made a great progress in last two releases, who
doesn't believe, check Itamar's talk from recent KVM Forum. :) There is
a downside to that positive trend though: oVirt has become too large for
one person to know all its feautures in detail (save for full-time
managers of course).
The only sources currently are feature pages that tend to get outdated
fairly quickly after their respective feature initial implementation,
and release notes. This means that user evaluating oVirt or user looking
for particular feature has to cycle through release notes of several
versions, go through prospective feature pages or try luck with
hopefully suitable full text query.
RHEV/RHS documentation is good but not perfect either because it may
lack some feature available upstream and it also has some for latest
features.
oVirt should present itself better than now in this respect. Full-blown
documentation such as the one for RHEV/RHS is out of question IMO as it
requires steady effort of handful of people to keep it up-to date and
covered.
What IMO is feasible though is something like what libvirt does - keep
page/pages such as [1] that enumerates features with a short description
and note of version since when the feature was available. It is feasible
because the required run-time effort on single person is quite low: when
the feature is added or heavily modified, a description of similar size
to DocText of RFE bug has to be added/updated in the documentation page.
There is just one problem in getting there: agree if the problem really
exists and devote resources to record current state of affairs. There is
also one technical catch: if the documentation is to be consumable by
downstreams, the "available since" notes have to be in common format
that can be machine-converted downstream to matching d/s versions.
I personally can't do much more than spin up a discussion and probably
write about area I know, so I hope that this email can trigger actual
actions by Someone Else leading to ultimate goal....
Cheers,
David
[1] http://libvirt.org/formatdomain.html
--=20
David Ja=C5=A1a, RHCE
SPICE QE based in Brno
GPG Key: 22C33E24=20
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24
--=-ln9kcnV6W2ZIoMc8ulrR
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISsjCCBjQw
ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX
DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK
75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC
+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD
z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr
/+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc
fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG
XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt
UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R
HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv
sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s
sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq
+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT
zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq
Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1
9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGOTCCBSGg
AwIBAgIDBl1jMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN
MTMwNDEwMTE0ODI4WhcNMTQwNDEwMTM1MDM0WjBXMRkwFwYDVQQNExAxUktWVnliSEdDZnRMWjY3
MRkwFwYDVQQDDBBkamFzYUByZWRoYXQuY29tMR8wHQYJKoZIhvcNAQkBFhBkamFzYUByZWRoYXQu
Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx8unM64NLnlRZujXHb0ilCaqc7KB
r1MwlyCtOWAyH4M/24zvfyRQyTz4ZkHd1sMeewJ5ap1/128hLSqMY/6So5yhL6UlK3nM1r9H9PTz
CiPEMZmDazIzMb/Mt/4N3kkJBLpWPFRB5aB+COcex7a4dlmnUJASVWkVwvHRmfa06anME7DTccV5
cV95FKqoRUXawopdu5W2NhailCtbQJAbMIGf9FpH+J98swAsVHdvjZkSDnZcoQIPHzoPrEBawb7C
vsmCe8p7pv5Dxtx3T47FdAXJiO9u+QJkaBFjfiA9ywN8fFo3Q/Jr4vl6WqEr1SyQjgL9/dWeQSYI
8LzByChnXQIDAQABo4IC1jCCAtIwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYI
KwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ5AqZ3fyU5HOme+iF4KA3f8RxHPjAfBgNVHSME
GDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAbBgNVHREEFDASgRBkamFzYUByZWRoYXQuY29tMIIB
TAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENl
cnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQg
YWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBT
dGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3Nl
IGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQv
MC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUF
BwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3Mx
L2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3Vi
LmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29t
LzANBgkqhkiG9w0BAQUFAAOCAQEArlvH1bAdnpLvyeMQzPtJYs65ur7cpYnrxrIZ3P/r0F7juzIU
fb1S+M9sYBhalmBoZQMySlVveDYHUHPDsNJQtqUzYAJMbVTdRtviCSq3wmYtG/VJOOif11gM25u4
HcgXVuhF3di5G0CHwAIx0mjUi7fPJ3WMeFKWp550ZqpbFK/i9A5fJGfHk3MfXOhAu7vkEEjJY+gA
BpFqvk134+30mP4KoXfNGZpekWvj6lS/tfaxuuSTusPcY0yIGGtJqqFtL1tRlTIoaDGiok5O0k6W
pMFPtm+dGnOyKT4HQMFCaAgBOVCQFDYthuGlnUlJOP/BheuvaMfwgIqM4ir+DIqOyjCCBjkwggUh
oAMCAQICAwZdYzANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2
BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4X
DTEzMDQxMDExNDgyOFoXDTE0MDQxMDEzNTAzNFowVzEZMBcGA1UEDRMQMVJLVlZ5YkhHQ2Z0TFo2
NzEZMBcGA1UEAwwQZGphc2FAcmVkaGF0LmNvbTEfMB0GCSqGSIb3DQEJARYQZGphc2FAcmVkaGF0
LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMfLpzOuDS55UWbo1x29IpQmqnOy
ga9TMJcgrTlgMh+DP9uM738kUMk8+GZB3dbDHnsCeWqdf9dvIS0qjGP+kqOcoS+lJSt5zNa/R/T0
8wojxDGZg2syMzG/zLf+Dd5JCQS6VjxUQeWgfgjnHse2uHZZp1CQElVpFcLx0Zn2tOmpzBOw03HF
eXFfeRSqqEVF2sKKXbuVtjYWopQrW0CQGzCBn/RaR/iffLMALFR3b42ZEg52XKECDx86D6xAWsG+
wr7JgnvKe6b+Q8bcd0+OxXQFyYjvbvkCZGgRY34gPcsDfHxaN0Pya+L5elqhK9UskI4C/f3VnkEm
CPC8wcgoZ10CAwEAAaOCAtYwggLSMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQG
CCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUOQKmd38lORzpnvoheCgN3/EcRz4wHwYDVR0j
BBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwGwYDVR0RBBQwEoEQZGphc2FAcmVkaGF0LmNvbTCC
AUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVk
IGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUg
U3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9z
ZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8E
LzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEF
BQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNz
MS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1
Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNv
bS8wDQYJKoZIhvcNAQEFBQADggEBAK5bx9WwHZ6S78njEMz7SWLOubq+3KWJ68ayGdz/69Be47sy
FH29UvjPbGAYWpZgaGUDMkpVb3g2B1Bzw7DSULalM2ACTG1U3Ubb4gkqt8JmLRv1STjon9dYDNub
uB3IF1boRd3YuRtAh8ACMdJo1Iu3zyd1jHhSlqeedGaqWxSv4vQOXyRnx5NzH1zoQLu75BBIyWPo
AAaRar5Nd+Pt9Jj+CqF3zRmaXpFr4+pUv7X2sbrkk7rD3GNMiBhrSaqhbS9bUZUyKGgxoqJOTtJO
lqTBT7ZvnRpzsik+B0DBQmgIATlQkBQ2LYbhpZ1JSTj/wYXrr2jH8ICKjOIq/gyKjsoxggNvMIID
awIBATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT
IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs
YXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMGXWMwCQYFKw4DAhoFAKCCAa8w
GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMxMTA1MDAwMTUyWjAj
BgkqhkiG9w0BCQQxFgQUrxISTbkhz0FRsFQ+luSezjBCAhYwgaUGCSsGAQQBgjcQBDGBlzCBlDCB
jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBE
aWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJp
bWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMGXWMwgacGCyqGSIb3DQEJEAILMYGXoIGUMIGM
MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp
Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmlt
YXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwZdYzANBgkqhkiG9w0BAQEFAASCAQBsV8LEtRQT
UEJQ7qWHhUTsaBOYvIbc3krAosri3Fym6p/0hl00DCS2rrR0ezpyCW54qSoXSsCikYmKNIKeewNf
/yZ7TacKGTmVvHKA+U9gkd3soj5Gvv6zDJfxW0n/XewVHKsfDQhqxgCUd+UPONr7BDcw05xEBuBC
GqleQ69AxWYi+5rZSfh5CycBpqg397IrAeApAQlDc/V7eXsbNYONk5+/WknQIbSITwEo4cqKCJt+
hUTDrHnr2BltjiEVlrwQ6SdpUgnnsTwtS+5l7FTJDXpALUvSb8VwoHbRXFiIeAIno+g3QmH3verk
byIhET466uYcKqz1Itn+nFlQS3HlAAAAAAAA
--=-ln9kcnV6W2ZIoMc8ulrR--
10 years, 5 months
[Engine-devel] gerrit 2.7
by Itamar Heim
the only change i see interesting in gerrit 2.7 is:
- New copyMaxScore setting for labels.
Labels can be configured to copy approvals forward to the next patch
set.
but it's not clear on its scope, considering the mentioned changes in
2.8 release notes on same topic.
I plan to upgrade gerrit to 2.7 in a couple of weeks, mainly to prepare
for the 2.8 upgrade later on.
gerrit 2.8 (not released yet) has these interesting changes:
- Configurable external robots.txt file.
(courtesy of juan hernandez)
as well as:
- Labels can be configured to copy scores forward to new patch sets if
there is no code change.
- Labels can be configured to copy scores forward to new patch sets for
trivial rebases.
- New button to cherry-pick the change to another branch.
- When issuing a rebase via the Web UI, the committer is now the logged
in user, rather than "Gerrit Code Review".
- Copy reviewed flag to new patch sets for identical files.
If a user has already seen and reviewed a file, the reviewed flag is
forwarded on to the next patch set when the content of the file in
the next patch set is identical to the reviewed file.
other interesting changes in 2.8:
- New change screen with completely redesigned UI and fully using the
REST API.
- Secondary indexing with Lucene and Solr.
- Lots of new REST API endpoints.
- New UI extension and JavaScript API for plugins.
10 years, 5 months
