New design for the Gerrit UI
by Evgheni Dereveanchin
Hi everyone,
The Infra team is working on customizing the look of Gerrit to make it fit
better with other oVirt services. I want to share the result of this
effort. Hopefully we can gather some feedback before applying the design to
oVirt's instance of Gerrit.
Please visit the Staging instance to check it out:
https://gerrit-staging.phx.ovirt.org/
The new design is inspired by oVirt's main website. There is a known glitch
that the "Loading Gerrit Code Review" message is overlapped by the logo
when the UI is loading. If you spot any other issues or have ideas for
improvement feel free to respond to this thread or share your feedback in
the following JIRA ticket:
https://ovirt-jira.atlassian.net/browse/OVIRT-912
--
Regards,
Evgheni Dereveanchin
7 years, 3 months
Lowering the bar for wiki contribution?
by Roy Golan
I'm getting the feeling I'm not alone in this, authoring and publishing a
wiki page isn't as used to be for long time.
I want to suggest a bit lighter workflow:
1. Everyone can merge their page - (it's a wiki)
Same as with (public and open) code, no one has the motivation to publish
a badly written
wiki page under their name. True, it can have an impact, but not as with
broken code
2. Use Page-Status marker
The author first merges the draft. Its now out there and should be updated
as time goes and its
status is DRAFT. Maintainers will come later and after review would change
the status to
PUBLISH. That could be a header in on the page:
---
page status: DRAFT/PUBLISH
---
Simple I think, and should work.
7 years, 6 months
[ENGINE][ACTION_NEEDED] - default maintainers, per path
by Roy Golan
Hi all,
Some time ago the infra team enabled *gerrit default reviewer plugin* which
you probably noticed if you logged in to gerrit.
What we can do is for example set the stable branch maintainers per branch
automatically:
[filter "branch:ovirt-engine-4.1"]
reviewer = stableBranchMaintainersGroup
Put people based on path:
[filter "branch:master file:^frontend/.*"]
reviewer = j.r.r.t(a)shire.me
*Action Needed:*
Nominate yourself, or others, by amending this patch online [1]. Once this
patch is fully acked and agreed we will merge it. If something can't get
consensus we will defer it from the patch till maintainers agree.
[1] https://gerrit.ovirt.org/#/c/77488/
7 years, 6 months
Re: [ovirt-devel] Making event types backwards compatible?
by Michal Skrivanek
> On 29 May 2017, at 11:44, Juan Hernández <jhernand(a)redhat.com> wrote:
>
>> On 05/29/2017 11:27 AM, Michal Skrivanek wrote:
>>
>>> On 29 May 2017, at 10:39, Juan Hernández <jhernand(a)redhat.com> wrote:
>>>
>>> Hello,
>>>
>>> It has been recently requested that the API provides event types:
>>>
>>> [RFE] Expose event types to API
>>> https://bugzilla.redhat.com/1453170
>>>
>>> Currently the API provides the event code and description, for example:
>>>
>>> <event href="/ovirt-engine/api/events/8021" id="8021">
>>> <code>19</code>
>>> <description>Host myhost failed to recover.</description
>>> ...
>>> </event>
>>>
>>> There is no documentation of what is the meaning of codes, except the
>>> source code of the engine itself. This forces some applications to add
>>> their own code to name mapping. For example, the 'ovirt' Ruby gem used
>>> by older versions of ManageIQ to interact with oVirt contains the following:
>>>
>>> https://github.com/ManageIQ/ovirt/blob/v0.17.0/lib/ovirt/event.rb#L25-L485
>>>
>>> We could avoid this by adding to the API a new event attribute that
>>> indicates the type:
>>>
>>> <event href="/ovirt-engine/api/events/8021" id="8021">
>>> <code>19</code>
>>> <type>host_recover_failure</type>
>>> <description>Host myhost failed to recover.</description>
>>> ...
>>> </event>
>>>
>>> Ideally this should be defined as an enum, so that it will be
>>> represented as an enum in the SDKs. Alternatively it could just be an
>>> string, and we could reuse the 'name' attribute:
>>>
>>> <event href="/ovirt-engine/api/events/8021" id="8021">
>>> <code>19</code>
>>> <name>host_recover_failure</name>
>>> <description>Host myhost failed to recover.</description>
>>> ...
>>> </event>
>>>
>>> However, the key point to making this useful would be to keep the types
>>> (or names) backwards compatible, so that users of the API can rely on
>>> their values and meanings.
>>>
>>> So this is my question to you: can we commit to keep the names and
>>> meanings of the backend event types backwards compatible?
>>
>> Do we even have to make it bw compatible?
>> I guess it depends on the actual usage of those names…
>> The ovirt ruby gem itself doesn’t do much with it
>
> We need to make keep it backwards compatible or else tell users "don't
> rely on these values, as they may change without notice".
>
> The 'ovirt' gem doesn't do anything special, it just creates its own
> code to name mapping. But the users of the 'ovirt' gem (the ManageIQ
> oVirt provider) do rely on the name. For example:
>
>
> https://github.com/ManageIQ/manageiq-providers-ovirt/blob/master/app/mode...
>
> That means that if we ever change the meaning of a code the ManageIQ
> provider, for example, will break.
Right,then it indeed needs to stay stable.
But how is maintaining the enum string different from the code? It is
the same information, so if MIQ doesn't use the name directly then it
doesn't really matter if it's a code or string.
Perhaps deprecate the code and keep the name fixed?
Thanks,
michal
>
>>>
>>> Regards,
>>> Juan Hernandez
>>>
>>>
>>> _______________________________________________
>>> Devel mailing list
>>> Devel(a)ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>
7 years, 6 months
[ovirt-system-tests] ssh to an oVirt VM in Lago
by Valentina Makarova
Hello!
Please, help me to find way to execute some command in oVirt VM.
Is it possible to get ssh connection to non-host VM in LAGO?
And how can I get ssh connection through the console in my computer?
I installed ovirt-system-tests and run tests from basic-suite-master.
So there is 2 hosts and 3 vms in my configuration.
And I want to execute command inside the vm0 using LAGO (as part of my own
test).
It is easy for host vm and engine, there is method ''ssh"
in ovirt-engine-api-model.
And this task for host vm can be performed as there
prefix.virt_env.get_vm(VM_NAME).ssh(['bash_command_what_i_want'])
Please give me advice, can Iget connection to vm0 in a similar way?
And a second question is about ssh to this vm connection from my laptop's
console.
According run_vm test from 004_basic_sanity.py (
https://github.com/oVirt/ovirt-system-tests/blob/master/basic-suite-maste...
) vm0 should contain interface with ip 192.168.200.200, but ping this from
engine (192.168.200.4) Destination Host Unreachable. And 'ping vm0' defined
vm0 as 192.168.201.213 and also couldn't reach vm0.
And in webadmin (https://engine/ovirt-engine/webadmin/#vms) IP Address
field is empty.
What is a right way to get connection to vm0 console and execute some
command there?
Sincerely,
Valentina Makarova
7 years, 6 months
Engine query & action result classes are now final
by Vojtech Szocs
Hi everyone,
yesterday, we merged https://gerrit.ovirt.org/#/c/75705/ which seals Engine
query & action result classes.
We will follow this up with renaming "VdcReturnValueBase" to
"ActionReturnValue" and doing similar renames to existing "VdcSomething"
classes.
The reason for finalizing those result classes is to avoid us implementing
a GWT custom field serializer for each such subclass, therefore limiting
our exposure to GWT RPC specifics when transferring objects between client
and server.
On a side note, we also upgraded GWT 2.8.0 to 2.8.1 which fixes a GWT
compiler bug we had to work around: https://gerrit.ovirt.org/#/c/77264/
Regards,
Vojtech
7 years, 6 months
Regarding site bug fix
by shubham dubey
Hi,
I want to fix some issues in ovirt site. Since I never did a pull request
before,
hence want to know few things.
1)can I fix multiple bug and send a single pr for them.
2) when I fix a issue did I need to write something in the comment of the
bug (like 'fixed' or 'patch send').
thanks in advance and I will appreciate for extra related info:)
Shubham
7 years, 6 months
