[ovirt-devel] Re: Fwd: Orphaning my packages

[Martin Sivak]

On Wed, Nov 20, 2019 at 1:20 PM Tal Nisan  wrote:

>
>
> On Tue, Nov 19, 2019 at 8:39 PM Martin Perina  wrote:
>
>>
>>
>> On Tue, 19 Nov 2019, 16:33 Tal Nisan,  wrote:
>>
>>>
>>>
>>> On Tue, Nov 19, 2019 at 5:22 PM Sandro Bonazzola 
>>> wrote:
>>>
 FYI, we consume those packages on Fedora.
 Any volunteer for taking them?

>>> Do we know which ones we actually use? (as opposed to consume)
>>>
>>
>> They are all dependencies of engine hystrix integration
>>
> Which we actually don't use, so probably the first thing to do will be to
> remove the dependencies and see if anything is broken
>

It is a debugging tool. It was used back then to identify couple of
performance bottlenecks. You might want to check it out again... even if
just to see that everything is fast and there are no unnecessary loops :)

Martin



>
>>
 -- Forwarded message -
 Da: Roman Mohr 
 Date: mar 19 nov 2019 alle ore 15:20
 Subject: Orphaning my packages
 To: 


 Hi,

 I take [1] as the opportunity  to orphan the following packages:

 rpms/aspectjweaver
 rpms/assertj-core
 rpms/hystrix
 rpms/memoryfilesystem
 rpms/rxjava
 rpms/archaius

 I don't use these projects anymore, and I don't have time to follow
 them.

 Best Regards,
 Roman

 [1] https://pagure.io/fesco/issue/2280

 ___
 devel mailing list -- de...@lists.fedoraproject.org
 To unsubscribe send an email to devel-le...@lists.fedoraproject.org
 Fedora Code of Conduct:
 https://docs.fedoraproject.org/en-US/project/code-of-conduct/
 List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
 List Archives:
 https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org


 --

 Sandro Bonazzola

 MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV

 Red Hat EMEA 

 sbona...@redhat.com
 *Red Hat respects your work life balance.
 Therefore there is no need to answer this email out of your office hours.
 *
 ___
 Devel mailing list -- devel@ovirt.org
 To unsubscribe send an email to devel-le...@ovirt.org
 Privacy Statement: https://www.ovirt.org/site/privacy-policy/
 oVirt Code of Conduct:
 https://www.ovirt.org/community/about/community-guidelines/
 List Archives:
 https://lists.ovirt.org/archives/list/devel@ovirt.org/message/XSETKPZLR4C7WZHLSBWVEKDIMEQ5PSFO/

>>> ___
>>> Devel mailing list -- devel@ovirt.org
>>> To unsubscribe send an email to devel-le...@ovirt.org
>>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>>> oVirt Code of Conduct:
>>> https://www.ovirt.org/community/about/community-guidelines/
>>> List Archives:
>>> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/35M5TAI3K6YPLDC3AF2V3B2LT2VH7SVR/
>>>
>> ___
> Devel mailing list -- devel@ovirt.org
> To unsubscribe send an email to devel-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/UXULNRPQKJH2ADAFGHRDCPLJUNZYV2V5/
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/7RYOUYHTGDJOUTPJSOEPXM7ZTIKMOKAV/

[ovirt-devel] Re: Checkstyle Java 11 false positives.

[Martin Sivak]

> I think more correct usage is:
>
> Set attachmentsToRemove = new HashSet<>();

Well, for something that survives long enough yes. But `var` is a new
Java 10 feature that is totally valid. See for example here:

https://www.baeldung.com/java-10-local-variable-type-inference

Martin

On Mon, Oct 14, 2019 at 4:11 PM Martin Perina  wrote:
>
>
>
> On Mon, Oct 14, 2019 at 9:49 AM Ales Musil  wrote:
>>
>> Hi,
>> just found out that checkstyle is not completely aware of Java 11 features.
>> Completely valid syntax e.g. "var attachmentsToRemove = new HashSet();"
>
>
> We are using custom DiamongOperator check style:
>
> https://github.com/oVirt/ovirt-engine/blob/master/build-tools-root/ovirt-checkstyle-extension/src/main/java/org/ovirt/checkstyle/checks/DiamondOperatorCheck.java
>
> I think more correct usage is:
>
> Set attachmentsToRemove = new HashSet<>();
>
> Does check style complain if you change to above?
>
>> is marked with error: "DiamondOperator: Diamond operator should be used"
>>
>> What can we do about this?
>>
>> Thanks.
>> Regards,
>> Ales
>>
>> --
>>
>> Ales Musil
>>
>> Associate Software Engineer - RHV Network
>>
>> Red Hat EMEA
>>
>> amu...@redhat.comIM: amusil
>>
>> ___
>> Devel mailing list -- devel@ovirt.org
>> To unsubscribe send an email to devel-le...@ovirt.org
>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>> oVirt Code of Conduct: 
>> https://www.ovirt.org/community/about/community-guidelines/
>> List Archives: 
>> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/GA3QZK7IHFMGLND5PRNCWEF3WCCXSDTH/
>
>
>
> --
> Martin Perina
> Manager, Software Engineering
> Red Hat Czech s.r.o.
> ___
> Devel mailing list -- devel@ovirt.org
> To unsubscribe send an email to devel-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct: 
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives: 
> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/WXKMNDI6QM6ADD6SYEMEX27INOJDPR5F/
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/TQE3XCZOWDX3HGFW7Q5U7KN7SYP3RG2G/

[ovirt-devel] Re: Proposing Andrej Krejcir as a maintainer of engine core

[Martin Sivak]

+1 from me.

Martin

On Wed, Jun 26, 2019 at 2:03 PM Arik Hadas  wrote:
>
> Dear engine-core maintainers,
>
> I'd like to propose Andrej Krejcir as a maintainer of oVirt engine backend.
>
> Since Jul 2015, Andrej has been contributing to ovirt-engine, mostly in SLA 
> areas (scheduling, quota, etc) and recently being more and more involved also 
> in the VIRT areas. This results in ~200 patches to engine master alone.
>
> Personally, I reviewed some of Andrej's contributions and noticed reviews 
> made by Andrej to others. I sincerely believe Andrej would be a good addition 
> to the maintainers' group.
>
> Thanks in advance for your response!
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/4XWESHZUZCK6MBG44ZDAW3YZOE2UHYRZ/

[ovirt-devel] Re: ovirt-vdsmfake

[Martin Sivak]

I only ever used it compiled from source for developer side validation. I
never used any packages..

Martin

On Wed, Mar 20, 2019 at 4:35 PM Sandro Bonazzola 
wrote:

>
>
> Il giorno mer 20 mar 2019 alle ore 16:30 Greg Sheremeta <
> gsher...@redhat.com> ha scritto:
>
>> Ok 
>>
>> Then I guess it stays. :)
>>
>
> Stays on master only? Do we need it in 4.3?
> Looking at google looks like only documentation available is
> https://www.ovirt.org/develop/developer-guide/vdsm/fake.html
> I don't see it used in OST, does it make sense to add a test using it for
> scale?
>
>
>
>>
>> On Wed, Mar 20, 2019 at 10:34 AM Martin Sivak  wrote:
>>
>>> Really? I was definitely using it last year for scheduling testing.
>>>
>>> Martin
>>>
>>> On Wed, Mar 20, 2019 at 3:30 PM Greg Sheremeta 
>>> wrote:
>>>
>>>> It is abandoned, and hasn't worked in quite some time. Last commit was
>>>> 2017, and even in 2017 it wasn't always reliable so we stopped using it.
>>>>
>>>> Greg
>>>>
>>>>
>>>> On Wed, Mar 20, 2019 at 10:02 AM Sandro Bonazzola 
>>>> wrote:
>>>>
>>>>> Hi,
>>>>> on master we have ovirt-vdsmfake package.
>>>>> Is there any reason for branching it and/or add it to 4.3 pipeline?
>>>>>
>>>>> --
>>>>>
>>>>> SANDRO BONAZZOLA
>>>>>
>>>>> MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
>>>>>
>>>>> Red Hat EMEA <https://www.redhat.com/>
>>>>>
>>>>> sbona...@redhat.com
>>>>> <https://red.ht/sig>
>>>>> ___
>>>>> Devel mailing list -- devel@ovirt.org
>>>>> To unsubscribe send an email to devel-le...@ovirt.org
>>>>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>>>>> oVirt Code of Conduct:
>>>>> https://www.ovirt.org/community/about/community-guidelines/
>>>>> List Archives:
>>>>> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/CSCEZN7SVXYDVZZSZ5NJDH3QK2R4NPKD/
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> GREG SHEREMETA
>>>>
>>>> SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX
>>>>
>>>> Red Hat NA
>>>>
>>>> <https://www.redhat.com/>
>>>>
>>>> gsher...@redhat.comIRC: gshereme
>>>> <https://red.ht/sig>
>>>> ___
>>>> Devel mailing list -- devel@ovirt.org
>>>> To unsubscribe send an email to devel-le...@ovirt.org
>>>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>>>> oVirt Code of Conduct:
>>>> https://www.ovirt.org/community/about/community-guidelines/
>>>> List Archives:
>>>> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/U7JMX4SUNYRMG4USZMR5GOXLOHJ4SIXK/
>>>>
>>>
>>
>> --
>>
>> GREG SHEREMETA
>>
>> SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX
>>
>> Red Hat NA
>>
>> <https://www.redhat.com/>
>>
>> gsher...@redhat.comIRC: gshereme
>> <https://red.ht/sig>
>>
>
>
> --
>
> SANDRO BONAZZOLA
>
> MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
>
> Red Hat EMEA <https://www.redhat.com/>
>
> sbona...@redhat.com
> <https://red.ht/sig>
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/FF3SDXZSABF7OMNOGGJVGSKJLBGHKYF7/

[ovirt-devel] Re: ovirt-vdsmfake

[Martin Sivak]

Really? I was definitely using it last year for scheduling testing.

Martin

On Wed, Mar 20, 2019 at 3:30 PM Greg Sheremeta  wrote:

> It is abandoned, and hasn't worked in quite some time. Last commit was
> 2017, and even in 2017 it wasn't always reliable so we stopped using it.
>
> Greg
>
>
> On Wed, Mar 20, 2019 at 10:02 AM Sandro Bonazzola 
> wrote:
>
>> Hi,
>> on master we have ovirt-vdsmfake package.
>> Is there any reason for branching it and/or add it to 4.3 pipeline?
>>
>> --
>>
>> SANDRO BONAZZOLA
>>
>> MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
>>
>> Red Hat EMEA 
>>
>> sbona...@redhat.com
>> 
>> ___
>> Devel mailing list -- devel@ovirt.org
>> To unsubscribe send an email to devel-le...@ovirt.org
>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>> oVirt Code of Conduct:
>> https://www.ovirt.org/community/about/community-guidelines/
>> List Archives:
>> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/CSCEZN7SVXYDVZZSZ5NJDH3QK2R4NPKD/
>>
>
>
> --
>
> GREG SHEREMETA
>
> SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX
>
> Red Hat NA
>
> 
>
> gsher...@redhat.comIRC: gshereme
> 
> ___
> Devel mailing list -- devel@ovirt.org
> To unsubscribe send an email to devel-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/U7JMX4SUNYRMG4USZMR5GOXLOHJ4SIXK/
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/HJUNJOOGYAYXSDWS5QB6O55YOPAS5YBA/

[ovirt-devel] Re: ovirt-scheduler-proxy: subproject health check

[Martin Sivak]

Hi,

The project was definitely supposed to be shipped with oVirt 4.3.
There was no deprecation and it still works. It is a simple proxy that
allows adding external rules to engine scheduler. There are no bugs
and so there are no fixes.. does not mean it is dead.

There used to be documentation based on examples.. but apparently it got lost.
https://web.archive.org/web/20170326001609/https://www.ovirt.org/documentation/sla/external-scheduler-samples/

This is not widely used feature however there were users and use cases
for it. I found a question about it from 2017 for example:
https://lists.ovirt.org/pipermail/users/2017-July/083232.html

Best regards

Martin Sivak

On Fri, Mar 8, 2019 at 10:41 AM Sandro Bonazzola  wrote:
>
> Hi,
> oVirt Scheduler Proxy has been introduced in oVirt 3.3.1 back in 2013.
> Last update on master branch is dated November 2017 with 0.1.8 released.
> The package has been shipped till oVirt 4.2.8 and it has not been shipped in 
> oVirt 4.3 despite no official deprecation has been announced.
>
> According to Gerrit, current maintainers are Doron Fediuck and Martin Sivak.
>
> According to Bugzilla there are no open bugs or RFEs for this project.
>
> The project has no documentation available on oVirt website.
>
> Can we declare this subproject retired from oVirt project and drop CI 
> automation for it?
>
> Thanks,
>
> --
>
> SANDRO BONAZZOLA
>
> MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
>
> Red Hat EMEA
>
> sbona...@redhat.com
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/T4BIFY3GA5LH3ATIL3BWVZODS6CUHCD3/

[ovirt-devel] Re: Taking down the engine without setting global maintenance

[Martin Sivak]

> When the engine goes down, it can't know if it's part of a
> graceful/clean reboot. It can be due to a problem, which is severe
> enough to take the machine down and not take it up again, but still
> not severe enough to prevent clean shutdown of the engine itself.

That and the fact that the engine does not have a direct access to
storage and has to go through vdsm. Meaning the flagging mechanism
might not be reliable enough. Also there has to be an automatic way to
reset it and make the VM start again or the user will wonder why the
next outage left the engine down.

Figuring out the rules for the two automatic actions (get GM and reset
GM) is not trivial.

> perhaps at least
> make HA wait longer (say, 30 minutes), and/or notify a few times by
> email, or something like that.

The delay is at least 5 minutes before shutdown is initiated and you
will get couple of emails (well at least one, I do not remember how
often we repeat it).

> I simply wonder how many times HA actually saved people from a
> long(er) unplanned engine downtime compared to how many times it was
> simply annoyingly restarting the vm in the middle of some routine
> maintenance...

You do not touch the engine that often and that is why people forget
the right procedure. Engine offline "migration" was visible in many
logs I reviewed during bug analyses. So this is probably working well
for most people most of the time (eg. when nothing is changing).

Martin

On Thu, Mar 7, 2019 at 11:04 AM Yedidyah Bar David  wrote:
>
> On Thu, Mar 7, 2019 at 11:41 AM Simone Tiraboschi  wrote:
> >
> >
> >
> > On Thu, Mar 7, 2019 at 10:34 AM Yedidyah Bar David  wrote:
> >>
> >> On Thu, Mar 7, 2019 at 11:30 AM Martin Sivak  wrote:
> >> >
> >> > Hi,
> >> >
> >> > there is no way to distinguish an engine that is not responsive
> >> > (software or network issue) from a VM that is being powered off. The
> >> > shutdown takes some time during which you just do not know.
> >>
> >> _I_ do not know, but the user might still know beforehand.
> >>
> >> > Global
> >> > maintenance informs the tooling in advance that something like this is
> >> > going to happen.
> >>
> >> Yes. But users keep forgetting setting it. So I am trying to come up
> >> with something that will fix that :-)
> >
> >
> > Now we have exactly the opposite:
> > engine-setup is already checking for global maintenance mode (the check 
> > acts on the engine DB over what the hosts report when polled so we have a 
> > bit of latency here) and engine-setup is exiting if we are on hosted-engine 
> > and not in global maintenance mode.
> > https://github.com/oVirt/ovirt-engine/blob/master/packaging/setup/plugins/ovirt-engine-common/ovirt-engine/system/he.py#L49
>
> You are right, if the engine restart was only via engine-setup. But
> there might be other reasons for restarting.
>
> Martin's claim, AFAIU, is more-or-less:
>
> When the engine goes down, it can't know if it's part of a
> graceful/clean reboot. It can be due to a problem, which is severe
> enough to take the machine down and not take it up again, but still
> not severe enough to prevent clean shutdown of the engine itself.
>
> Martin - is it so?
>
> Not sure I agree personally, that this flow is likely enough to make
> my suggestion problematic (meaning, will cause HA to leave the engine
> vm down, when it was actually better to try starting it on another
> host). But I can see the point.
>
> Let's say that I mainly think we should differentiate between a clean
> shutdown and a non-responsive engine (died via a power cut, or network
> problem, or whatever). If we do not want to consider this as a "global
> maintenance" (meaning, do nothing until the user clears it, or if we
> set it ourselves, until the engine starts again), perhaps at least
> make HA wait longer (say, 30 minutes), and/or notify a few times by
> email, or something like that.
>
> I simply wonder how many times HA actually saved people from a
> long(er) unplanned engine downtime compared to how many times it was
> simply annoyingly restarting the vm in the middle of some routine
> maintenance...
>
> >
> >
> >>
> >>
> >> Perhaps instead of my original text, use something like "Right before
> >> the engine goes down, it should set global maintenance".
> >>
> >> >
> >> > Who do you expect should be touching the shared storage? The engine VM
> >> > itself? That might be possible, but remember the jboss instance is
> >> > just the top

[ovirt-devel] Re: Taking down the engine without setting global maintenance

[Martin Sivak]

Hi,

there is no way to distinguish an engine that is not responsive
(software or network issue) from a VM that is being powered off. The
shutdown takes some time during which you just do not know. Global
maintenance informs the tooling in advance that something like this is
going to happen.

Who do you expect should be touching the shared storage? The engine VM
itself? That might be possible, but remember the jboss instance is
just the top of the process hierarchy. There are a lot of components
where something might break during shutdown (filesystem umount timeout
for example).

Martin

On Thu, Mar 7, 2019 at 9:27 AM Yedidyah Bar David  wrote:
>
> Hi all,
>
> How about making this change:
>
> Right before the engine goes down cleanly, it marks the shared storage
> saying it did not crash but exited cleanly, and then HE-HA will not
> try to restart it on another host. Perhaps make this optional, so that
> users can do clean shutdowns and still test HA cleanly (or some other
> use cases, where users might not want this).
>
> This should help a lot cases where people restarted their engine for
> some reason, e.g. upgrade, and forgot to set maintenance.
>
> Makes sense?
> --
> Didi
> ___
> Devel mailing list -- devel@ovirt.org
> To unsubscribe send an email to devel-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct: 
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives: 
> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/WCLSLEVXPHGRHL5BJHPLSYWPPOCMIJOQ/
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/FO34NFXR5U43GRC3LU4PUAPEXRNSSKLN/

[ovirt-devel] Re: oVirt documentation vs. feature pages

[Martin Sivak]

Hi,

> 2. Feature pages can and should be updated, and include inline the changes
> done per version.

This is very hard to enforce as feature pages are part of a different
repository on a different review platform (!). Ideally this kind of
(developer) documentation should be part of source code repository so
you can track history together with the actual source changes. That
way reviewers can also check the changes together.

Martin

On Thu, Feb 21, 2019 at 8:33 AM Yedidyah Bar David  wrote:
>
> On Thu, Feb 21, 2019 at 5:03 AM Laura Wright  wrote:
>>
>> I think from a design perspective we should try to make the features and 
>> documentation pages look more different from one another so users are less 
>> likely to mistake the different types of docs for one another. We can 
>> definitely address this more in the site redesign. I can come up with 
>> further iterations of those pages for the site redesign so we have a couple 
>> different options to talk more about.
>>
>> I also think from an information architecture perspective we should probably 
>> feature the official end user documentation at a higher level than the 
>> features pages so users would be more likely to find the end user 
>> documentation first and then find the features pages if they dig a little 
>> deeper.
>>
>> We could also feature different documentation user guides that are more 
>> tailored to the different types of users who might use oVirt.
>>
>> I'm curious to hear others thoughts on this.
>>
>> Best,
>> Laura
>>
>> On Wed, Feb 20, 2019 at 11:59 PM Greg Sheremeta  wrote:
>>>
>>> Hi,
>>>
>>> TL;DR: please don't direct users to feature pages -- direct them to 
>>> end-user documentation instead. And maintain content separation between 
>>> end-user documentation and technical docs like feature pages.
>>> ...
>>>
>>> Lately we've cleaned up documentation on ovirt.org, and I wanted to share 
>>> some of my thoughts about it. As a user experience focused person, I really 
>>> believe that clear and helpful documentation is crucial to the project's 
>>> success. I've also seen outdated documentation be a source of extreme 
>>> frustration for our users.
>>>
>>> In the distant past, most of oVirt's documentation was written by 
>>> developers on a wiki, typically in the form of "feature pages." Feature 
>>> pages are basically technical design documents with occasionally some user 
>>> help sprinkled in.
>>>
>>> With oVirt 4.0, we put a great set of clear documentation, written by 
>>> technical writers, on the oVirt website (which was also converted from a 
>>> wiki to a regular static site). This documentation is up to date with 4.2, 
>>> and we'll get the 4.3 content out there soon.
>>>
>>> This official documentation lives at https://ovirt.org/documentation
>>> and it should be considered the authoritative place for users to access our 
>>> documentation.
>>>
>>> Feature pages, on the other hand, are (now) for developers. When you hear 
>>> the term "feature page", think "technical design document." Most users 
>>> should not be interested in this content.
>>>
>>> It helps to think about the personas.
>>>
>>> 1. oVirt admins -- the person who sets up oVirt on Day 1 and 2. This is the 
>>> person who cares about and will read the Installation Guide and the 
>>> Administration Guide. These live under /documentation, e.g.
>>> https://ovirt.org/documentation/install-guide/Installation_Guide.html
>>>
>>> 2. oVirt users -- the people who use oVirt to create, manage, and use 
>>> virtual machines, etc. This person will care about and read the VM Portal 
>>> Guide, User Guides, and such. These also live under /documentation, e.g.
>>> https://ovirt.org/documentation/vmm-guide/Virtual_Machine_Management_Guide.html
>>>
>>> 3. Developers -- you and I, and occasionally highly curious and technical 
>>> admins. These people might care about how the project works under the hood 
>>> -- high level designs, code flows, etc. Persona 2, oVirt users, do not care 
>>> about these details when they are learning to use oVirt, so end-user 
>>> documentation should not be polluted with this type of content. This 
>>> content now lives exclusively under /develop, the developer's section of 
>>> the site.
>>> https://ovirt.org/develop/release-management/features/
>>>
>>> Let's help our users by directing them to the end-user documentation, not 
>>> to feature pages. If you would like to contribute end-user documentation, 
>>> it should go under /documentation and not in a feature page. If you build a 
>>> new feature, the technical stuff goes under 
>>> /develop/release-management/features/ and the end-user stuff goes under 
>>> /documentation.
>>>
>>> Feedback welcome :)
>
>
> I'd like to add another issue which might be worth discussing now, also
> in light of what you suggest re different design. This is: How do we handle
> the history of version changes?
>
> Suppose at some version X a new feature is added. We obviously want a
> feature page for it (

[ovirt-devel] Re: Proposing Fred Rolland as a Storage backend maintainer

[Martin Sivak]

+1 from me as well

Martin

On Thu, Nov 15, 2018 at 12:02 PM, Tal Nisan  wrote:
> Hi everyone,
> I'd like to propose Fred as a backend maintainer in Engine for the storage
> area.
> Fred has been contributing to ovirt-engine for the last 3.5 years and have
> done tremendous job in adding new features, bug fixes and code review.
>
> Thanks,
> Tal.
>
>
> ___
> Devel mailing list -- devel@ovirt.org
> To unsubscribe send an email to devel-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/6GRTZVSB3PK4GMRYEA7RYOOZMSJWN5C3/
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/YQAKPOW46VW4H6N2W22LXIJJW64WWVPY/

[ovirt-devel] Re: Proposing Shmuel Melamud as a Virt backend maintainer

[Martin Sivak]

+1 from me too

On Wed, Nov 14, 2018 at 8:21 AM, Michal Skrivanek
 wrote:
> Hi all,
> I’d like to propose Shmuel as a backend maintainer for the virt area. He’s a 
> good candidate with his 200+ patches and insight into complex parts of VM 
> pools, templates, q35 support, v2v, sparsify...
> Feel free to bother him more with review requests;)
>
> Thanks,
> michal
> ___
> Devel mailing list -- devel@ovirt.org
> To unsubscribe send an email to devel-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct: 
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives: 
> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/TBYGMRTCF3BUMZ4ZC46DI6BQONNUMWOV/
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/AXRXWC245QHS23FDGBQ5ZKMEJKSMRUKJ/

Re: [ovirt-devel] oVirt messages from engine to vdsm

[Martin Sivak]

Hi,

that sure looks like postgresql SCL packages. Software collections are
installed into /opt and need to be enabled using the `scl enable
` command to allow their usage.

Best regards

Martin Sivak

On Mon, May 7, 2018 at 2:21 PM, Anastasiya Ruzhanskaya
 wrote:
> rpm -qa |grep postgres
> rh-postgresql95-postgresql-libs-9.5.9-1.el7.x86_64
> postgresql-libs-9.2.23-3.el7_4.x86_64
> rh-postgresql95-runtime-2.2-2.el7.x86_64
> rh-postgresql95-postgresql-9.5.9-1.el7.x86_64
> postgresql-jdbc-9.2.1002-5.el7.noarch
> postgresql-contrib-9.2.23-3.el7_4.x86_64
> rh-postgresql95-postgresql-server-9.5.9-1.el7.x86_64
> postgresql-9.2.23-3.el7_4.x86_64
> rh-postgresql95-postgresql-contrib-9.5.9-1.el7.x86_64
> collectd-postgresql-5.8.0-2.el7.x86_64
> postgresql-server-9.2.23-3.el7_4.x86_64
> [skotti@localhost ~]$ psql -U postgres
> psql: FATAL:  Peer authentication failed for user "postgres"
>
> But I actually installed it manually, still no succeed. But ovirt engine is
> working.
>
> 2018-05-07 5:22 GMT-04:00 Eli Mesika :
>>
>>
>>
>> On Mon, May 7, 2018 at 11:40 AM, Anastasiya Ruzhanskaya
>>  wrote:
>>>
>>> If the engine user is not accessible directly, why then in this command
>>> you use it?:
>>>
>>>  psql -U engine engine -c "UPDATE vdc_options set option_value = 'false'
>>>  WHERE option_name =
>>> 'SSLEnabled';"
>>>
>>> I am not really good in managing databases, I also didn't have postgresql
>>> installed after finishing oVirt engine installation and even managing to
>>> deploy everything. Does it mean that no database was created at all? I have
>>> chosen automatic and local creation in all fields related to database while
>>> installing oVirt engine.
>>
>>
>> Can you paste the output of the following command
>>
>> rpm -qa |grep postgres
>>
>>
>>
>>>
>>>
>>>
>>> 2018-05-07 11:00 GMT+03:00 Martin Sivak :
>>>>
>>>> Hi,
>>>>
>>>> I think what you are looking for is mostly this:
>>>> https://github.com/oVirt/vdsm/blob/master/lib/vdsm/api/vdsm-api.yml
>>>>
>>>> The best way to see what the traffic is is to disable SSL. The
>>>> postgres database is installed and accessible using the postgres user
>>>> (the engine user is not allowed to access it directly).
>>>>
>>>> You might also be interested in the vdsm fake project we use as node
>>>> simulator. Its readme will tell you exactly how to do this:
>>>> https://github.com/oVirt/ovirt-vdsmfake
>>>>
>>>> I wrote an article some time ago that explained how to setup a
>>>> development environment without real hosts:
>>>>
>>>> https://www.ovirt.org/blog/2016/11/testing-ovirt-changes-without-cluster/
>>>>
>>>> Might I ask what you goal is?
>>>>
>>>> Best regards
>>>>
>>>> --
>>>> Martin Sivak
>>>> SLA / oVirt
>>>>
>>>> On Sun, May 6, 2018 at 6:26 AM, Anastasiya Ruzhanskaya
>>>>  wrote:
>>>> > Hello everyone!
>>>> > Currently I want to determine what information is included in messages
>>>> > passing from oVirt engine to VDSM on ovirt-node.
>>>> >
>>>> > I made up a really simple configuration with one VM representing
>>>> > engine,
>>>> > another - node, a managed to successfully  launch a single VM on this
>>>> > node.
>>>> > However, I have chosen to configure everything automatically.
>>>> > Currently
>>>> > traffic is encrypted with default certificates.
>>>> > So, there are three options for me and no one of them really works.
>>>> >
>>>> > 1) Find the format of messages ( what the fields are, session id for
>>>> > example) in docs, but I didn't  manage to find it;
>>>> > 2) Use wireshark to decrypt the traffic and the apply maybe a json
>>>> > -dissector to the decrypted data. I have tried many solutions ( thanks
>>>> > god I
>>>> > have rsa private and public keys but there is another session key
>>>> > which is
>>>> > generated every time engine starts to communicate with vdsm, which I
>>>> > cannot
>>>> > get with the help of sslkeylog file or ld_preload tech

Re: [ovirt-devel] oVirt messages from engine to vdsm

[Martin Sivak]

Hi,

you must have postgresql installed or the engine would not work. I see
I used the engine user there (the second engine is the database name),
but both vdsm fake and my personal notes say to use postgres user.

sudo -i -u postgres
export ENGINE_DB=dbname
psql $ENGINE_DB -c "UPDATE vdc_options set option_value = 'false'
WHERE option_name = 'SSLEnabled';"
psql $ENGINE_DB -c "UPDATE vdc_options set option_value = 'false'
WHERE option_name = 'EncryptHostCommunication';"

So I must have done something differently at that time (the article
was written in 2016).

Best regards

Martin Sivak

On Mon, May 7, 2018 at 10:40 AM, Anastasiya Ruzhanskaya
 wrote:
> If the engine user is not accessible directly, why then in this command you
> use it?:
>
>  psql -U engine engine -c "UPDATE vdc_options set option_value = 'false'
>  WHERE option_name =
> 'SSLEnabled';"
>
> I am not really good in managing databases, I also didn't have postgresql
> installed after finishing oVirt engine installation and even managing to
> deploy everything. Does it mean that no database was created at all? I have
> chosen automatic and local creation in all fields related to database while
> installing oVirt engine.
>
>
> 2018-05-07 11:00 GMT+03:00 Martin Sivak :
>>
>> Hi,
>>
>> I think what you are looking for is mostly this:
>> https://github.com/oVirt/vdsm/blob/master/lib/vdsm/api/vdsm-api.yml
>>
>> The best way to see what the traffic is is to disable SSL. The
>> postgres database is installed and accessible using the postgres user
>> (the engine user is not allowed to access it directly).
>>
>> You might also be interested in the vdsm fake project we use as node
>> simulator. Its readme will tell you exactly how to do this:
>> https://github.com/oVirt/ovirt-vdsmfake
>>
>> I wrote an article some time ago that explained how to setup a
>> development environment without real hosts:
>> https://www.ovirt.org/blog/2016/11/testing-ovirt-changes-without-cluster/
>>
>> Might I ask what you goal is?
>>
>> Best regards
>>
>> --
>> Martin Sivak
>> SLA / oVirt
>>
>> On Sun, May 6, 2018 at 6:26 AM, Anastasiya Ruzhanskaya
>>  wrote:
>> > Hello everyone!
>> > Currently I want to determine what information is included in messages
>> > passing from oVirt engine to VDSM on ovirt-node.
>> >
>> > I made up a really simple configuration with one VM representing engine,
>> > another - node, a managed to successfully  launch a single VM on this
>> > node.
>> > However, I have chosen to configure everything automatically. Currently
>> > traffic is encrypted with default certificates.
>> > So, there are three options for me and no one of them really works.
>> >
>> > 1) Find the format of messages ( what the fields are, session id for
>> > example) in docs, but I didn't  manage to find it;
>> > 2) Use wireshark to decrypt the traffic and the apply maybe a json
>> > -dissector to the decrypted data. I have tried many solutions ( thanks
>> > god I
>> > have rsa private and public keys but there is another session key which
>> > is
>> > generated every time engine starts to communicate with vdsm, which I
>> > cannot
>> > get with the help of sslkeylog file or ld_preload technology.
>> > Maybe someone knows the exact methodology how to do this correctly?
>> >
>> > 3) Turn off ssl in oVirt. It is simple to do that for vdsm, but for
>> > engine,
>> > according to answers on oVirt site, I should do 2 requests to the
>> > database.
>> > I was really surprised that psql was not installed by oVirt on my
>> > system.
>> > How did it then created a default database? ( I have chosen to create
>> > all
>> > locally and with default configurations).
>> > I mean these two commands :
>> >
>> > https://www.ovirt.org/develop/developer-guide/vdsm/connecting-development-vdsm-to-engine/
>> > . I have a following error there :
>> > psql: FATAL: Peer authentication failed for user "engine"
>> >
>> > Could you please guide my what method is the best and how should I
>> > correct
>> > my faults there?
>> >
>> >
>> > ___
>> > Devel mailing list
>> > Devel@ovirt.org
>> > http://lists.ovirt.org/mailman/listinfo/devel
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] oVirt RPC messages

[Martin Sivak]

Hi,

no, the traffic is not enough. All the information is present in the
both audit log and engine log. You can even forward your audit log
messages to email for example:
https://www.ovirt.org/documentation/admin-guide/chap-Event_Notifications/

Best regards

Martin Sivak

On Mon, May 7, 2018 at 9:59 AM, Anastasiya Ruzhanskaya
 wrote:
> So, then by analyzing traffic from ovirt-engine to ovirt-node ( vdsm) and
> then from vdsm to libvirt I am not able to find out which user is executing
> the actions ( for example shut down VM or make snapshot)?
>
> 2018-05-07 10:53 GMT+03:00 Martin Sivak :
>>
>> Hi,
>>
>> we send a correlation id with the commands to be able to pair the
>> engine.log commands with vdsm commands. I am pretty sure we do not
>> send any user identification to the node.
>>
>> Best regards
>>
>> Martin Sivak
>>
>> On Mon, May 7, 2018 at 6:19 AM, Anastasiya Ruzhanskaya
>>  wrote:
>> > Hello!
>> > Do messages sent from ovirt-engine to ovirt-node in RPC format contain
>> > the
>> > session number or any user information?
>> >
>> >
>> > ___
>> > Devel mailing list
>> > Devel@ovirt.org
>> > http://lists.ovirt.org/mailman/listinfo/devel
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] oVirt messages from engine to vdsm

[Martin Sivak]

Hi,

I think what you are looking for is mostly this:
https://github.com/oVirt/vdsm/blob/master/lib/vdsm/api/vdsm-api.yml

The best way to see what the traffic is is to disable SSL. The
postgres database is installed and accessible using the postgres user
(the engine user is not allowed to access it directly).

You might also be interested in the vdsm fake project we use as node
simulator. Its readme will tell you exactly how to do this:
https://github.com/oVirt/ovirt-vdsmfake

I wrote an article some time ago that explained how to setup a
development environment without real hosts:
https://www.ovirt.org/blog/2016/11/testing-ovirt-changes-without-cluster/

Might I ask what you goal is?

Best regards

--
Martin Sivak
SLA / oVirt

On Sun, May 6, 2018 at 6:26 AM, Anastasiya Ruzhanskaya
 wrote:
> Hello everyone!
> Currently I want to determine what information is included in messages
> passing from oVirt engine to VDSM on ovirt-node.
>
> I made up a really simple configuration with one VM representing engine,
> another - node, a managed to successfully  launch a single VM on this node.
> However, I have chosen to configure everything automatically. Currently
> traffic is encrypted with default certificates.
> So, there are three options for me and no one of them really works.
>
> 1) Find the format of messages ( what the fields are, session id for
> example) in docs, but I didn't  manage to find it;
> 2) Use wireshark to decrypt the traffic and the apply maybe a json
> -dissector to the decrypted data. I have tried many solutions ( thanks god I
> have rsa private and public keys but there is another session key which is
> generated every time engine starts to communicate with vdsm, which I cannot
> get with the help of sslkeylog file or ld_preload technology.
> Maybe someone knows the exact methodology how to do this correctly?
>
> 3) Turn off ssl in oVirt. It is simple to do that for vdsm, but for engine,
> according to answers on oVirt site, I should do 2 requests to the database.
> I was really surprised that psql was not installed by oVirt on my system.
> How did it then created a default database? ( I have chosen to create all
> locally and with default configurations).
> I mean these two commands :
> https://www.ovirt.org/develop/developer-guide/vdsm/connecting-development-vdsm-to-engine/
> . I have a following error there :
> psql: FATAL: Peer authentication failed for user "engine"
>
> Could you please guide my what method is the best and how should I correct
> my faults there?
>
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] oVirt RPC messages

[Martin Sivak]

Hi,

we send a correlation id with the commands to be able to pair the
engine.log commands with vdsm commands. I am pretty sure we do not
send any user identification to the node.

Best regards

Martin Sivak

On Mon, May 7, 2018 at 6:19 AM, Anastasiya Ruzhanskaya
 wrote:
> Hello!
> Do messages sent from ovirt-engine to ovirt-node in RPC format contain the
> session number or any user information?
>
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Name resolution not working after vdsm installation

[Martin Sivak]

IPv6 only DNS? Cool (if it works) :)

Martin

On Wed, Apr 25, 2018 at 11:43 AM, Piotr Kliczewski
 wrote:
> In addition here is my resolv.conf
>
> ; generated by /usr/sbin/dhclient-script
> nameserver 2001:730:3ed2::53
> nameserver 2001:730:3ed2:1000::53
> search localdomain
>
> On Wed, Apr 25, 2018 at 11:26 AM, Piotr Kliczewski
>  wrote:
>> All,
>>
>> I am using latest engine and vdsm 4.20.23-1. I installed vdsm on
>> centos7 vm and after the installation my vm stopped resolving names.
>>
>> Here is my nic configuration before installation:
>>
>> TYPE="Ethernet"
>> BOOTPROTO="dhcp"
>> DEFROUTE="yes"
>> PEERDNS="yes"
>> PEERROUTES="yes"
>> IPV4_FAILURE_FATAL="no"
>> IPV6INIT="yes"
>> IPV6_AUTOCONF="yes"
>> IPV6_DEFROUTE="yes"
>> IPV6_PEERDNS="yes"
>> IPV6_PEERROUTES="yes"
>> IPV6_FAILURE_FATAL="no"
>> NAME="eth0"
>> UUID="0079668a-8708-46ad-8dbf-da418ae6f77e"
>> DEVICE="eth0"
>> ONBOOT="yes"
>>
>> here is after:
>>
>> # Generated by VDSM version 4.20.23-1.el7.centos
>> DEVICE=eth0
>> BRIDGE=ovirtmgmt
>> ONBOOT=yes
>> MTU=1500
>> DEFROUTE=no
>> NM_CONTROLLED=no
>> IPV6INIT=no
>>
>> and the bridge:
>> # Generated by VDSM version 4.20.23-1.el7.centos
>> DEVICE=ovirtmgmt
>> TYPE=Bridge
>> DELAY=0
>> STP=off
>> ONBOOT=yes
>> BOOTPROTO=dhcp
>> MTU=1500
>> DEFROUTE=yes
>> NM_CONTROLLED=no
>> IPV6INIT=yes
>> DHCPV6C=yes
>> IPV6_AUTOCONF=no
>>
>> Thanks,
>> Piotr
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Invitation: oVirt STDCI v2 deep dive @ Thu Apr 26, 2018 11:00 - 12:00 (IDT) (devel@ovirt.org)

[Martin Sivak]

Hi,

I did see it already and added it to the team calendar. I wonder if it
forwards the confirmations back to you.

Martin

On Tue, Apr 24, 2018 at 9:27 AM, Sandro Bonazzola 
wrote:

>
>
> 2018-04-24 6:11 GMT+02:00 Barak Korren :
>
>>
>>
>> On 23 April 2018 at 14:36, Sandro Bonazzola  wrote:
>>
>>> From past experience, sending calendar invitation to ovirt mailing lists
>>> doesn't work well. see https://lists.ovirt.org/pi
>>> permail/users/2018-March/087616.html for reference.
>>>
>>
>> I agree the experience is less then optional - I do seem to get
>> confirmation emails, so some people manage to use it anyway.
>>
>>
>>> I would recommend to track this on https://ovirt.org/events/ by adding
>>> the event following https://github.com/OSAS/rh-events/wiki/Adding-and-
>>> modifying-events
>>>
>>>
>> Are you sure that is the right place for this? that repo seems to list
>> events at the scale of conferences...
>>
>
> Well, this is a kind of conference with just 1 talk :-)
>
>
>>
>>
>>> I would also recommend to send personal invitation to oVirt team leads
>>> to be sure they see it.
>>>
>>
>> Sure of you can give me a list...
>>
>
> Sandro Bonazzola  - Integration / Release Engineering
> Ryan Barry  - Node
> Michal Skrivanek  - Virtualization
> Shirly Radco  - Metrics / Data Warehouse
> Tal Nisan  - Storage
> Martin Sivak  - SLA
> Eyal Edri  - Project infrastructure
> Martin Perina  - Infra
> Dan Kenigsberg  - Network
> Sahina Bose  - Gluster
> Tomas Jelinek  - UX
>
> I'm missing a reference person for other teams listed in
> https://ovirt.org/develop/#ovirt-teams:
> Docs
> I18N
> Marketing
> Spice
>
>
>
>
>>
>>
>>>
>>> If you need to track who's going to join, I would recommend a ticketing
>>> system like eventbrite.
>>>
>>
>> Not sure I want to force people to use yet another 3rd party platform for
>> the benefit of me having some tracking information. Do people prefer this?
>>
>>
>>>
>>> 2018-04-23 10:36 GMT+02:00 :
>>>
>>>> more details »
>>>> <https://www.google.com/calendar/event?action=VIEW&eid=MHBvcmNoYWQ5YmtzNmlmdWw2M25jNzM5djMgZGV2ZWxAb3ZpcnQub3Jn&tok=MTgjYmtvcnJlbkByZWRoYXQuY29tODBiMjViYzFjZmZhYWYzMmJiNmNlNWU3NTA3OGRjOGQwYmJiNTBhOA&ctz=Asia%2FJerusalem&hl=en&es=0>
>>>> oVirt STDCI v2 deep dive
>>>>
>>>> *When*
>>>> Thu Apr 26, 2018 11:00 – 12:00 Jerusalem
>>>> *Where*
>>>> raanana-04-asia-8-p-vc; https://bluejeans.com/8705030462 (map
>>>> <https://maps.google.com/maps?q=raanana-04-asia-8-p-vc;+https://bluejeans.com/8705030462&hl=en>
>>>> )
>>>> *Calendar*
>>>> devel@ovirt.org
>>>> *Who*
>>>> •
>>>> bkor...@redhat.com - organizer
>>>> •
>>>> devel@ovirt.org
>>>>
>>>> Introduction to the 2nd version of oVirt's CI standard - What is it,
>>>> what can it do, how to use it and how does it work.
>>>>
>>>> BJ link:
>>>> https://bluejeans.com/8705030462
>>>> <https://www.google.com/url?q=https%3A%2F%2Fbluejeans.com%2F8705030462&sa=D&usd=2&usg=AFQjCNEElRX6SA9bn6kPQbako_CGx68GmA>
>>>>
>>>> Going?   *Yes
>>>> <https://www.google.com/calendar/event?action=RESPOND&eid=MHBvcmNoYWQ5YmtzNmlmdWw2M25jNzM5djMgZGV2ZWxAb3ZpcnQub3Jn&rst=1&tok=MTgjYmtvcnJlbkByZWRoYXQuY29tODBiMjViYzFjZmZhYWYzMmJiNmNlNWU3NTA3OGRjOGQwYmJiNTBhOA&ctz=Asia%2FJerusalem&hl=en&es=0>
>>>> - Maybe
>>>> <https://www.google.com/calendar/event?action=RESPOND&eid=MHBvcmNoYWQ5YmtzNmlmdWw2M25jNzM5djMgZGV2ZWxAb3ZpcnQub3Jn&rst=3&tok=MTgjYmtvcnJlbkByZWRoYXQuY29tODBiMjViYzFjZmZhYWYzMmJiNmNlNWU3NTA3OGRjOGQwYmJiNTBhOA&ctz=Asia%2FJerusalem&hl=en&es=0>
>>>> - No
>>>> <https://www.google.com/calendar/event?action=RESPOND&eid=MHBvcmNoYWQ5YmtzNmlmdWw2M25jNzM5djMgZGV2ZWxAb3ZpcnQub3Jn&rst=2&tok=MTgjYmtvcnJlbkByZWRoYXQuY29tODBiMjViYzFjZmZhYWYzMmJiNmNlNWU3NTA3OGRjOGQwYmJiNTBhOA&ctz=Asia%2FJerusalem&hl=en&es=0>*
>>>> more options »
>>>> <https://www.google.com/calendar/event?action=VIEW&eid=MHBvcmNoYWQ5YmtzNmlmdWw2M25jNzM5djMgZGV2ZWxAb3ZpcnQub3Jn&tok=MTgjYmtvcnJlbkByZWRoYXQuY29tODBiMjViYzFjZmZhYWYzMmJiNmNlNWU3NTA3OGRjOGQwYmJiNTBhOA&ctz=Asia%2FJerusalem&hl=en&es=0>
>>>>
>&g

Re: [ovirt-devel] he-basic-ansible-suite-master and he-basic-suite-master

[Martin Sivak]

Isn't it enforcing the legacy flow already? I think it was last time I
tried.

Martin

On Thu, Mar 8, 2018 at 1:46 PM, Sandro Bonazzola 
wrote:

> Hi,
> I'm looking at diffs between he-basic-ansible-suite-master and
> he-basic-suite-master in oVirt Sytem Test. Since we are now defaulting to
> the ansible deployment, aren't these 2 suites substantially testing the
> same flow?
>
> Can we drop one of them? Or should we change the non ansible suite to
> enforce using legacy otopi flow?
> Thanks,
> --
>
> SANDRO BONAZZOLA
>
> ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
>
> Red Hat EMEA 
> 
> TRIED. TESTED. TRUSTED. 
>
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt 4.2 (ovirt-hosted-engine-setup) ] [ 08-03-2018 ] [ 004_basic_sanity.run_vms ]

[Martin Sivak]

Does not seem to be hosted engine related.. there is no way we could
cause internal engine error by using the API alone.

Martin

On Thu, Mar 8, 2018 at 12:53 PM, Dafna Ron  wrote:
> Hi,
>
> We have a failed test on ovirt-hosted-engine-setup basic suite.
> We failed to run a vm with internal engine error.
>
> Link and headline of suspected patches:
>
> Add engine fqdn to inventory and allow dynamic inventory scripts -
> https://gerrit.ovirt.org/#/c/88622/
>
> Link to Job:
>
> http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/1064/
>
> Link to all logs:
>
> http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/1064/artifact/
>
> (Relevant) error snippet from the log:
>
> 
>
>
> 2018-03-07 17:03:38,374-05 INFO
> [org.ovirt.engine.core.bll.RunVmOnceCommand] (default task-21)
> [a514da44-d44f-46b9-8bdf-08ba2d513929] Running command: RunVmOnceCommand
> internal: false. Entities affected :  ID: 634c6a46-d057-4509-be3b-710
> 716cbd56d Type: VMAction group RUN_VM with role type USER,  ID:
> 634c6a46-d057-4509-be3b-710716cbd56d Type: VMAction group
> EDIT_ADMIN_VM_PROPERTIES with role type ADMIN
> 2018-03-07 17:03:38,379-05 DEBUG
> [org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor]
> (default task-21) [a514da44-d44f-46b9-8bdf-08ba2d513929] method:
> getVmManager, params: [634c6a46-d057-4509-be3b-710716cbd56d], timeElap
> sed: 5ms
> 2018-03-07 17:03:38,391-05 DEBUG
> [org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor]
> (default task-21) [a514da44-d44f-46b9-8bdf-08ba2d513929] method:
> getAllForClusterWithStatus, params: [14cad400-49a0-44e0-ab15-9da778f08
> 082, Up], timeElapsed: 7ms
> 2018-03-07 17:03:38,408-05 DEBUG
> [org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor]
> (default task-21) [a514da44-d44f-46b9-8bdf-08ba2d513929] method:
> getVdsManager, params: [8ef2f490-1b76-46e0-b9fe-f3412a36e03b], timeEla
> psed: 0ms
> 2018-03-07 17:03:38,419-05 DEBUG
> [org.ovirt.engine.core.dal.dbbroker.CustomSQLErrorCodeSQLExceptionTranslator]
> (default task-21) [a514da44-d44f-46b9-8bdf-08ba2d513929] Translating
> SQLException with SQL state '23505', error code '0', messa
> ge [ERROR: duplicate key value violates unique constraint "name_server_pkey"
>   Detail: Key (dns_resolver_configuration_id,
> address)=(8a941b6a-83aa-44de-9800-2a1ea6e8e029, 192.168.200.1) already
> exists.
>   Where: SQL statement "INSERT INTO
> name_server(
>   address,
>   position,
>   dns_resolver_configuration_id)
> VALUES (
>   v_address,
>   v_position,
>   v_dns_resolver_configuration_id)"
> PL/pgSQL function insertnameserver(uuid,character varying,smallint) line 3
> at SQL statement]; SQL was [{call insertnameserver(?, ?, ?)}] for task
> [CallableStatementCallback]
> 2018-03-07 17:03:38,420-05 ERROR
> [org.ovirt.engine.core.bll.RunVmOnceCommand] (default task-21)
> [a514da44-d44f-46b9-8bdf-08ba2d513929] Command
> 'org.ovirt.engine.core.bll.RunVmOnceCommand' failed:
> CallableStatementCallback; SQL [{call inse
> rtnameserver(?, ?, ?)}]; ERROR: duplicate key value violates unique
> constraint "name_server_pkey"
>   Detail: Key (dns_resolver_configuration_id,
> address)=(8a941b6a-83aa-44de-9800-2a1ea6e8e029, 192.168.200.1) already
> exists.
>   Where: SQL statement "INSERT INTO
> name_server(
>   address,
>   position,
>   dns_resolver_configuration_id)
> VALUES (
>   v_address,
>   v_position,
>   v_dns_resolver_configuration_id)"
> PL/pgSQL function insertnameserver(uuid,character varying,smallint) line 3
> at SQL statement; nested exception is org.postgresql.util.PSQLException:
> ERROR: duplicate key value violates unique constraint "name_server_pkey"
>   Detail: Key (dns_resolver_configuration_id,
> address)=(8a941b6a-83aa-44de-9800-2a1ea6e8e029, 192.168.200.1) already
> exists.
>   Where: SQL statement "INSERT INTO
> name_server(
>   address,
>   position,
>   dns_resolver_configuration_id)
> VALUES (
>   v_address,
>   v_position,
>   v_dns_resolver_configuration_id)"
> PL/pgSQL function insertnameserver(uuid,character varying,smallint) line 3
> at SQL statement
> 2018-03-07 17:03:38,420-05 ERROR
> [org.ovirt.engine.core.bll.RunVmOnceCommand] (default task-21)
> [a514da44-d44f-46b9-8bdf-08ba2d513929] Exception:
> org.springframework.dao.DuplicateKeyException: CallableStatementCallback;
> SQL [{call insertn
> ameserver(?, ?, ?)}]; ERROR: duplicate key value violates unique constraint
> "name_server_pkey"
>   Detail: Key (dns_resolver_configuration_id,
> address)=(8a941b6a-83aa-44de-9800-2a1ea6e8e029, 192.168.200.1) already
> exists.
>   Where: SQL statement "INSERT INTO
> name_server(
>   address,
>   position,
>   dns_resolver_configuration_id)
> VALUES (
> :
>v_address,
>   v_position,
>   v_dns_resolver_configuration_id)"
> PL/pgSQL function insertnameserver(uuid,character varying,smallint) line 3
> at SQL statement; nested exception is org.postgr

Re: [ovirt-devel] [OST][HC] Failed to deploy HE

[Martin Sivak]

Hi Sahina,

you need to synchronize couple of fixes to make everything work
properly, most importantly

- hosted engine setup https://gerrit.ovirt.org/#/c/88311/
- vdsm https://gerrit.ovirt.org/#/c/88370/

Those were all merged already (yesterday in fact), but it takes time
to propagate them to the OST repos I guess.

Best regards

Martin Sivak


On Thu, Mar 8, 2018 at 5:55 AM, Sahina Bose  wrote:
> Error is - The host has been set in non_operational status, please check
> engine logs, fix accordingly and re-deploy.
>
> However there are no engine logs available. Is this error seen in HE suite
> as well?
>
> On Thu, Mar 8, 2018 at 8:58 AM,  wrote:
>>
>> Project:
>> http://jenkins.ovirt.org/job/ovirt-system-tests_hc-basic-suite-master/
>> Build:
>> http://jenkins.ovirt.org/job/ovirt-system-tests_hc-basic-suite-master/213/
>> Build Number: 213
>> Build Status:  Failure
>> Triggered By: Started by timer
>>
>> -
>> Changes Since Last Success:
>> -
>> Changes for Build #213
>> [Sandro Bonazzola] image-ng-suite-4.2: sync 001_initialize_engine
>>
>> [Barak Korren] Enable mock to use bootstrap chroot for FC27/RAW
>>
>> [Sandro Bonazzola] gerrit-admin: move to el7
>>
>> [Daniel Belenky] Add symlinks resolving capabilities to usrc
>>
>> [Barak Korren] Fix auto-merge in downstream instances
>>
>> [Dafna Ron] sync_mirror: removing fc24
>>
>>
>>
>>
>> -
>> Failed Tests:
>> -
>> No tests ran.
>
>
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ACTION-REQUIRED] Making accurate CI for oVirt 4.2

[Martin Sivak]

Hi,

> You`re asking a bigger question here - Who decides which distros/archs
> each project targets. The CI system currently places the burden of
> this decision on the shoulders of individual maintainers. We could
> have done things differently and placed the decision solely in the
> hands of the integration team.

Actually, I believe it should be a global decision of the project
leadership. But I believe the word global to be important here. We
should decide together and then a common version to platform map
should be prepared by the integration team.

Single projects could still add additional overrides if needed though.

> The reason to placing the power (and responsibility) in the hands of
> maintainers we simple - we wanted to reduce the chances of having
> maintainers be surprised.

This actually means we get surprised and confused indeed. Please note
that nobody really told us that Fedora bits are not going to be
released anymore (see 4.2 release notes [1]) and whether we should
update the job specifications or not.

> Suppose we made it so that target distros
> change globally for everyone - you would have had patches failing CI
> at arbitrary times as new target distros or architectures were
> added...

Right. But we have something very similar now: spreadsheets with lists
of packages that are missing from a new version compose. I do not see
too much difference actually..

> Personally I prefer that decisions remain distributed

I agree with who decides things (all of us). But the decision needs to
be documented. Do we have any (easy to find) list of expected
platforms for given a release?

The decision then might be compiled into a file we could include and
stay current without manual edits.

[1] https://www.ovirt.org/release/4.2.0/#no-fedora-support

Martin
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ACTION-REQUIRED] Making accurate CI for oVirt 4.2

[Martin Sivak]

I do understand the semantics mostly, I am just not sure why we repeat
the distro excludes for almost every job and project.

Don't we have an oVirt global list for that somewhere (base-params)?
Because I am never sure which distros are supported for which
versions. Especially now after Sandro said Fedora bits are no longer
released.

Martin

On Wed, Jan 24, 2018 at 9:46 AM, Michal Skrivanek
 wrote:
>
>
> On 24 Jan 2018, at 09:23, Michal Skrivanek 
> wrote:
>
>
>
> On 24 Jan 2018, at 08:52, Dan Kenigsberg  wrote:
>
> On Wed, Jan 24, 2018 at 8:35 AM, Barak Korren  wrote:
>
> On 23 January 2018 at 18:44, Martin Sivak  wrote:
>
> Hi Barak,
>
> can you please please add links to the proper repositories and/or
> directories when you send something like this? I really helps us when
> we do not have to search through all the jenkins and other infra
> repositories for which is the correct one. Because I really do not
> remember all the places that need to change out of my head.
>
>
> See below.
>
> So what you are asking for here is basically that we edit the files
> here [1] and create a 4.2_build-artifacts job using copy and paste,
> right? Or is there some other place that needs to change as well?
>
>
> Yep. technically this should amount to a single change to a single
> file (See below). The important part is making the right decision for
> each project, understanding its consequences, and realizing the
> actions that would be needed for changing that decision in the future.
>
> [1]
> https://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;f=jobs/confs/projects;h=5a59dfea545da98e252eb6c8d95a92d08708a22d;hb=cd75bb9eb3353652384ed89777fc15d71d1f9e36
>
>
> There is only one file** you need to maintain that is (currently) not
> in your own project's repo***.
> Each project has such a file at [1].
>
> Documentation for the contents of that file can be found here: [2].
>
> There is no need to copy-paste much - the existing file should contain
> a mapping of project branches to oVirt versions. Typically what would
> be needed is just to add a single entry to the map. For example, for
> engine it would be:
>
>version:
>- master:
>branch: master
>- 4.2:
>branch: master
>   ...
>
>
> If project maintainers opt for this "Route 2", it is their personal
> responsibility to change the above "master" to "ovirt-4.2" branch
> *BEFORE* they create their stable branch ovirt-4.2. If they fail to do
> so, CI would get "dirty" with 4.3 packages.  Barak hinted to this a
> bit too mildly.
>
>
> well, I still do not get the hint at all
> Why exactly?
>
>
> apologies for stupid questions, but TBH I do not get most of these things….I
> tried to take a look at projects I’m familiar with and I still don’t quite
> understand what is getting to what repo.
> I guess the syntax is described, that’s fine, but I’m really not sure about
> semantics. Why do we need each of those things?
> I see stuff like f24 everywhere…is that just outdated?
> And what’s the relation to https://github.com/oVirt/releng-tools ?
>
> Thanks,
> michal
>
>
>
>
> ** Bigger projects can spread configuration across multiple files, but
> this is rarely needed.
> *** This applies only to Gerrit projects. GitHub projects have
> everything configured in their own repo. See [3].
>  Specifically for engine, the map appears twice in the file, this
> should probably be re-factored.
>
> [1]:
> https://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;f=jobs/confs/projects;hb=refs/heads/master
> [2]:
> http://ovirt-infra-docs.readthedocs.io/en/latest/CI/Using_STDCI_with_Gerrit/index.html
> [3]:
> http://ovirt-infra-docs.readthedocs.io/en/latest/CI/Using_STDCI_with_GitHub/index.html
>
>
>
> --
> Barak Korren
> RHV DevOps team , RHCE, RHCi
> Red Hat EMEA
> redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
>
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ACTION-REQUIRED] Making accurate CI for oVirt 4.2

[Martin Sivak]

Hi Barak,

can you please please add links to the proper repositories and/or
directories when you send something like this? I really helps us when
we do not have to search through all the jenkins and other infra
repositories for which is the correct one. Because I really do not
remember all the places that need to change out of my head.

So what you are asking for here is basically that we edit the files
here [1] and create a 4.2_build-artifacts job using copy and paste,
right? Or is there some other place that needs to change as well?

[1] 
https://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;f=jobs/confs/projects;h=5a59dfea545da98e252eb6c8d95a92d08708a22d;hb=cd75bb9eb3353652384ed89777fc15d71d1f9e36


Best regards

Martin Sivak

On Tue, Jan 23, 2018 at 1:52 PM, Barak Korren  wrote:
> Hi,
>
> This message is aimed for project maintainers. Other developers may
> also find it interesting to have a glimpse at the oVirt-wide test and
> composition processes.
>
> TL;DR: To get accurate CI for oVirt 4.2, most projects
>need to add 4.2 jobs in YAML.
>
> Before I can explain what the current issue is and which action is
> required, I'm need to provide a brief overview into how oVirt CI
> works.
>
> oVirt CI has two major components to it:
> 1. The STDCI component which is used to build and test individual
> projects. Most developers interact with this on a daily basis as it is
> responding on GitHub and Gerrit events.
> 2. The "change-queue" (CQ) component which is used to automatically
> compose the whole of oVirt from its sub projects  and run system tests
> (OST) on it. This component is used to gather the information that is
> used by the infra team to compose the "OST failure report" you can
> occasionally see being sent to this list. The change queue is also
> used to automatically maintain the 'tested' and '*-snapshot' (AKA
> nightly) repositories.
>
> The way the CQ composes oVirt is by looking at the post-merge STDCI
> 'build-artifacts' jobs, and collecting together artifacts built by
> jobs that target a specific oVirt version into that version's change
> queue. Essentially the '*_master_build-artifacts-*' jobs go into the
> 'ovirt-master' change queue, the '*_4.1_build-artifacts-*' jobs go
> into the 'ovirt-4.1' change queue etc.
>
> Over the course of the oVirt 4.2 development, most project used their
> 'master' branch, which is typically mapped to '*_master_*' jobs, for
> developing 4.2 code. So the 'ovirt-master' CQ provided good indication
> of the state of 4.2 code.
>
> As projects started addeing 4.2 branches, we have created an
> 'ovirt-4.2' CQ to gather them. We did so under the assumption that
> most projects will branch soon after. The assumption turned up to be
> wrong as most projects did not yet fork and may not do so in the near
> future.
>
> As some projects did fork, the end result is that currently:
>
>  ___there is no accurate representation of oVirt 4.2 in CI___
>
> 'ovirt-master' CQ no longer represents oVirt 4.2 as some projects
> already have some 4.3 code in their 'master' branches.
>
> 'ovirt-4.2' CQ does not represent oVirt 4.2 as most projects do not
> push artifacts into it.
>
> To get any benefit from CI, we need to have it represent what we are
> going to release. This means that at this point we need all projects
> to have '*_4.2_build-artifacts-*' jobs that map to the code that is
> intended to be included in oVirt 4.2. Projects can either:
>
> 1. Create 4.2 branches and map the new jobs to them.
> 2. Keep 4.2 development in 'master' and create '4.2' jobs that map to it.
>
> Taking route #2 means a commitment to not adding any 4.3 code to the
> 'master' branch. Please keep it, as rolling back "too new" builds from
> the various repos and caches we have is very difficult.
>
> --
> Barak Korren
> RHV DevOps team , RHCE, RHCi
> Red Hat EMEA
> redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] oVirt 4.2.0 GA Go / No go

[Martin Sivak]

I have my reservations, but perfect is the enemy of good.

+1

Martin

On Tue, Dec 19, 2017 at 8:11 PM, Sandro Bonazzola 
wrote:

>
>
> 2017-12-19 15:21 GMT+01:00 Sandro Bonazzola :
>
>> Hi,
>> we released 4.2.0 RC3 yesterday and currently we don't have approved or
>> proposed blockers.
>> So maintainers, please give your Go / No go for releasing GA tomorrow,
>> December 20th.
>>
>>
> + 1 for integration team
> + 1 for oVirt Node team (forwarding Ryan's vote)
>
>
>
>> Thanks,
>>
>> --
>>
>> SANDRO BONAZZOLA
>>
>> ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
>>
>> Red Hat EMEA 
>> 
>> TRIED. TESTED. TRUSTED. 
>>
>>
>
>
> --
>
> SANDRO BONAZZOLA
>
> ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
>
> Red Hat EMEA 
> 
> TRIED. TESTED. TRUSTED. 
>
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] oVirt 4.2.0 GA status

[Martin Sivak]

> The only control that we expose for reconnect is number of retires.

Right, but what is the default value? Because I see reconnect attempt
even with no nr_retries and no timeout provided and then it gets stuck
(or waiting for a really long timeout).

Martin

On Tue, Dec 19, 2017 at 2:28 PM, Piotr Kliczewski
 wrote:
> On Tue, Dec 19, 2017 at 2:05 PM, Martin Sivak  wrote:
>>>> So I think that we still have to fix it somehow.
>>>> Are we really sure that nr_retries=2 and _timeout=20 are really the magic 
>>>> numbers that works on every conditions?
>>>
>>>
>>> No, it should be tested on HE environment and it depends on your usage.
>>
>> What does happen when only timeout is specified and the connection
>> fails after the command is sent? What are the defaults in that case?
>
> Timeout defines how long we are going to wait for a response. It is
> there in the code
> for a bit of time already and it is not related to reconnect.
>
> The only control that we expose for reconnect is number of retires.
>
>>
>> Martin
>>
>> On Tue, Dec 19, 2017 at 1:55 PM, Irit Goihman  wrote:
>>>
>>>
>>>
>>> On Tue, Dec 19, 2017 at 2:51 PM, Simone Tiraboschi  
>>> wrote:
>>>>
>>>>
>>>>
>>>> On Tue, Dec 19, 2017 at 12:56 PM, Martin Perina  wrote:
>>>>>
>>>>> As Irit mentioned the provided reproduction steps are wrong (misuse of 
>>>>> the code) and she posted correct example showing that jsonrpc code works 
>>>>> as expected. So Martin/Simone are you using somewhere in HE code the 
>>>>> original example that is misusing the client?
>>>>
>>>>
>>>> According to
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1527155#c9
>>>> It works in Irit example, at least on that host with that load and 
>>>> timings, setting nr_retries=2 and _timeout=20
>>>>
>>>> While we have _timeout=5 and no custom nr_retries
>>>> https://github.com/oVirt/ovirt-hosted-engine-ha/blob/master/ovirt_hosted_engine_ha/lib/util.py#L417
>>>>
>>>> So I think that we still have to fix it somehow.
>>>> Are we really sure that nr_retries=2 and _timeout=20 are really the magic 
>>>> numbers that works on every conditions?
>>>
>>>
>>> No, it should be tested on HE environment and it depends on your usage.
>>>>
>>>>
>>>>>
>>>>>
>>>>> Thanks
>>>>>
>>>>> Martin
>>>>>
>>>>>
>>>>> On Tue, Dec 19, 2017 at 12:53 PM, Oved Ourfali  
>>>>> wrote:
>>>>>>
>>>>>> From the latest comment it doesn't seem like a blocker to me.
>>>>>> Martin S. - your thoughts?
>>>>>>
>>>>>> On Tue, Dec 19, 2017 at 1:48 PM, Sandro Bonazzola  
>>>>>> wrote:
>>>>>>>
>>>>>>> We have a proposed blocker for the release:
>>>>>>> 1527155InfravdsmBindings-APIigoihman@redhat.comNEWjsonrpc reconnect 
>>>>>>> logic does not work and gets stuckurgentunspecifiedovirt-4.2.004:30:30
>>>>>>>
>>>>>>> Please review and either approve the blcoker or postpone to 4.2.1.
>>>>>>> Thanks,
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> SANDRO BONAZZOLA
>>>>>>>
>>>>>>> ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
>>>>>>>
>>>>>>> Red Hat EMEA
>>>>>>>
>>>>>>> TRIED. TESTED. TRUSTED.
>>>>>>>
>>>>>>>
>>>>>>> ___
>>>>>>> Devel mailing list
>>>>>>> Devel@ovirt.org
>>>>>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Martin Perina
>>>>> Associate Manager, Software Engineering
>>>>> Red Hat Czech s.r.o.
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> IRIT GOIHMAN
>>>
>>> SOFTWARE ENGINEER
>>>
>>> EMEA VIRTUALIZATION R&D
>>>
>>> Red Hat EMEA
>>>
>>> TRIED. TESTED. TRUSTED.
>>> @redhatnews   Red Hat   Red Hat
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] oVirt 4.2.0 GA status

[Martin Sivak]

There is no misuse when optional argument is not used. But hosted engine
uses the timeout parameter anyway so you can assume it is not a blocker for
us.

Martin

On Tue, Dec 19, 2017 at 12:56 PM, Martin Perina  wrote:

> As Irit mentioned the provided reproduction steps are wrong (misuse of the
> code) and she posted correct example showing that jsonrpc code works as
> expected. So Martin/Simone are you using somewhere in HE code the original
> example that is misusing the client?
>
> Thanks
>
> Martin
>
>
> On Tue, Dec 19, 2017 at 12:53 PM, Oved Ourfali 
> wrote:
>
>> From the latest comment it doesn't seem like a blocker to me.
>> Martin S. - your thoughts?
>>
>> On Tue, Dec 19, 2017 at 1:48 PM, Sandro Bonazzola 
>> wrote:
>>
>>> We have a proposed blocker for the release:
>>> 1527155  Infra vdsm
>>> Bindings-API igoih...@redhat.com NEW jsonrpc reconnect logic does not
>>> work and gets stuck
>>>  urgent unspecified
>>> ovirt-4.2.0 04:30:30
>>>
>>> Please review and either approve the blcoker or postpone to 4.2.1.
>>> Thanks,
>>>
>>>
>>> --
>>>
>>> SANDRO BONAZZOLA
>>>
>>> ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
>>>
>>> Red Hat EMEA 
>>> 
>>> TRIED. TESTED. TRUSTED. 
>>>
>>>
>>> ___
>>> Devel mailing list
>>> Devel@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>
>>
>
>
> --
> Martin Perina
> Associate Manager, Software Engineering
> Red Hat Czech s.r.o.
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] oVirt 4.2.0 GA status

[Martin Sivak]

>> So I think that we still have to fix it somehow.
>> Are we really sure that nr_retries=2 and _timeout=20 are really the magic 
>> numbers that works on every conditions?
>
>
> No, it should be tested on HE environment and it depends on your usage.

What does happen when only timeout is specified and the connection
fails after the command is sent? What are the defaults in that case?

Martin

On Tue, Dec 19, 2017 at 1:55 PM, Irit Goihman  wrote:
>
>
>
> On Tue, Dec 19, 2017 at 2:51 PM, Simone Tiraboschi  
> wrote:
>>
>>
>>
>> On Tue, Dec 19, 2017 at 12:56 PM, Martin Perina  wrote:
>>>
>>> As Irit mentioned the provided reproduction steps are wrong (misuse of the 
>>> code) and she posted correct example showing that jsonrpc code works as 
>>> expected. So Martin/Simone are you using somewhere in HE code the original 
>>> example that is misusing the client?
>>
>>
>> According to
>> https://bugzilla.redhat.com/show_bug.cgi?id=1527155#c9
>> It works in Irit example, at least on that host with that load and timings, 
>> setting nr_retries=2 and _timeout=20
>>
>> While we have _timeout=5 and no custom nr_retries
>> https://github.com/oVirt/ovirt-hosted-engine-ha/blob/master/ovirt_hosted_engine_ha/lib/util.py#L417
>>
>> So I think that we still have to fix it somehow.
>> Are we really sure that nr_retries=2 and _timeout=20 are really the magic 
>> numbers that works on every conditions?
>
>
> No, it should be tested on HE environment and it depends on your usage.
>>
>>
>>>
>>>
>>> Thanks
>>>
>>> Martin
>>>
>>>
>>> On Tue, Dec 19, 2017 at 12:53 PM, Oved Ourfali  wrote:

 From the latest comment it doesn't seem like a blocker to me.
 Martin S. - your thoughts?

 On Tue, Dec 19, 2017 at 1:48 PM, Sandro Bonazzola  
 wrote:
>
> We have a proposed blocker for the release:
> 1527155InfravdsmBindings-APIigoihman@redhat.comNEWjsonrpc reconnect logic 
> does not work and gets stuckurgentunspecifiedovirt-4.2.004:30:30
>
> Please review and either approve the blcoker or postpone to 4.2.1.
> Thanks,
>
>
> --
>
> SANDRO BONAZZOLA
>
> ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
>
> Red Hat EMEA
>
> TRIED. TESTED. TRUSTED.
>
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel


>>>
>>>
>>>
>>> --
>>> Martin Perina
>>> Associate Manager, Software Engineering
>>> Red Hat Czech s.r.o.
>>
>>
>
>
>
> --
>
> IRIT GOIHMAN
>
> SOFTWARE ENGINEER
>
> EMEA VIRTUALIZATION R&D
>
> Red Hat EMEA
>
> TRIED. TESTED. TRUSTED.
> @redhatnews   Red Hat   Red Hat
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] oVirt System Test configuration

[Martin Sivak]

The engine only updates a short list of packages during host deploy If I
remember correctly.

See: https://gerrit.ovirt.org/#/c/59897/

Martin

On Mon, Dec 18, 2017 at 2:01 PM, Sandro Bonazzola 
wrote:

>
>
> 2017-12-18 13:57 GMT+01:00 Eyal Edri :
>
>>
>>
>> On Mon, Dec 18, 2017 at 2:53 PM, Sandro Bonazzola 
>> wrote:
>>
>>>
>>>
>>> 2017-12-18 12:42 GMT+01:00 Yaniv Kaul :
>>>


 On Mon, Dec 18, 2017 at 12:43 PM, Sandro Bonazzola >>> > wrote:

> Hi, I'd like to discuss what's being tested by oVirt System Test.
>
> I'm investigating on a sanlock issue that affects hosted engine hc
> suite.
> I installed a CentOS minimal VM and set repositories as in
> http://jenkins.ovirt.org/job/ovirt-system-tests_hc-basic-
> suite-master/128/artifact/exported-artifacts/reposync-config.repo
>
> Upgrade from CentOS 1708 (7.4) minimal is:
>
> Aggiornamento:
>  bind-libs-lite   x86_64
> 32:9.9.4-51.el7_4.1
> centos-updates-el7  733 k
>  bind-license noarch
> 32:9.9.4-51.el7_4.1
> centos-updates-el7   84 k
>  nss  x86_64
> 3.28.4-15.el7_4
> centos-updates-el7  849 k
>  nss-softokn  x86_64
> 3.28.3-8.el7_4
>centos-updates-el7  310 k
>  nss-softokn-freebl   x86_64
> 3.28.3-8.el7_4
>centos-updates-el7  214 k
>  nss-sysinit  x86_64
> 3.28.4-15.el7_4
> centos-updates-el7   60 k
>  nss-toolsx86_64
> 3.28.4-15.el7_4
> centos-updates-el7  501 k
>  selinux-policy   noarch
> 3.13.1-166.el7_4.7
>centos-updates-el7  437 k
>  selinux-policy-targeted  noarch
> 3.13.1-166.el7_4.7
>centos-updates-el7  6.5 M
>  systemd  x86_64
> 219-42.el7_4.4
>centos-updates-el7  5.2 M
>  systemd-libs x86_64
> 219-42.el7_4.4
>centos-updates-el7  376 k
>  systemd-sysv x86_64
> 219-42.el7_4.4
>centos-updates-el7   70 k
>
> Enabling the CentOS repos:
>
>  grub2   x86_64
>  1:2.02-0.65.el7.centos.2
> updates 29 k
>  in sostituzione di grub2.x86_64 1:2.02-0.64.el7.centos
>  grub2-tools x86_64
>  1:2.02-0.65.el7.centos.2
> updates1.8 M
>  in sostituzione di grub2-tools.x86_64 1:2.02-0.64.el7.centos
>  grub2-tools-extra   x86_64
>  1:2.02-0.65.el7.centos.2
> updates993 k
>  in sostituzione di grub2-tools.x86_64 1:2.02-0.64.el7.centos
>  grub2-tools-minimal x86_64
>  1:2.02-0.65.el7.centos.2
> updates170 k
>  in sostituzione di grub2-tools.x86_64 1:2.02-0.64.el7.centos
>  kernel  x86_64
>  3.10.0-693.11.1.el7
>updates 43 M
> Aggiornamento:
>  NetworkManager  x86_64
>  1:1.8.0-11.el7_4
> updates1.6 M
>  NetworkManager-libnmx86_64
>  1:1.8.0-11.el7_4
> updates1.2 M
>  NetworkManager-team x86

Re: [ovirt-devel] 4.2.0 RC3 blockers status: no go

[Martin Sivak]

On Fri, Dec 15, 2017 at 7:21 AM, Sandro Bonazzola 
wrote:

> 1522641  Node
> cockpit-ovirt Hosted Engine phbai...@redhat.com ASSIGNED Hosted Engine
> deployment looks like stuck, but become up ...
>  urgent unspecified
> ovirt-4.2.0 23:01:07
>

I believe this is just a manifestation of couple of other bugs and not a
bug by itself. Well at least it wasn't.. the report contains too many
different bits of info now. I added the depends on bugs there, all are
fixed or are waiting for merge and then this needs to be retested.

Martin



> SANDRO BONAZZOLA
>
> ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
>
> Red Hat EMEA 
> 
> TRIED. TESTED. TRUSTED. 
>
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ANN] oVirt 4.2.0 Second Candidate Release is now available for testing

[Martin Sivak]

>
> On my opinion it's just a duplicate of
>   https://bugzilla.redhat.com/show_bug.cgi?id=1512534
> and today Nikolai got it again on RHEL with everything at latest version.
> It's not 100% reproducible being a time based issue.

I think so as well, I think it has actually nothing to do with the UI
itself. And so Phillip is probably not the proper assignee either.

Martin


On Wed, Dec 13, 2017 at 5:24 PM, Simone Tiraboschi  wrote:
>
>
>
> On Wed, Dec 13, 2017 at 11:40 AM, Sandro Bonazzola  
> wrote:
>>
>>
>>
>> 2017-12-13 11:37 GMT+01:00 Michal Skrivanek :
>>>
>>>
>>> > On 13 Dec 2017, at 09:58, Sandro Bonazzola  wrote:
>>> >
>>> >
>>> >
>>> > 2017-12-13 9:51 GMT+01:00 Michal Skrivanek :
>>> > Hi Sandro,
>>> > we’ve identified one more blocker for HE installations[1]. We plan 
>>> > getting it in today if everything goes well, would be great if we can 
>>> > update the RC with new vdsm soon after.
>>> >
>>> > Thanks,
>>> > michal
>>> >
>>> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1524119
>>> >
>>> > We have right now 3 blockers:
>>> > ID▲   oVirt Team  Product▲Component▲  Assignee
>>> > Status▼ Summary SeverityPriority▲
>>> > 1522641   Nodecockpit-ovirt   Hosted Engine   phbai...@redhat.com 
>>> > NEW Hosted Engine deployment failed, there display 'Timed out...  
>>> >   urgent  unspecified
>>>
>>> seems this still requires clarification. There is some misunderstanding 
>>> between the assignee and qe.
>
>
> On my opinion it's just a duplicate of
>   https://bugzilla.redhat.com/show_bug.cgi?id=1512534
> and today Nikolai got it again on RHEL with everything at latest version.
> It's not 100% reproducible being a time based issue.
>
>>>
>>>
>>> > 1525353   Network ovirt-engineBLL.Network era...@redhat.com   
>>> > NEW vNIC mapping is broken on import from data domain - vNICs...  
>>> >   urgent  urgent
>>>
>>> Dan, can you update why this is a urgent/urgent  blocker? It doesn’t seem 
>>> to qualify for that severity. Import VM from SD and end up with empty 
>>> mapping you can easily fix…that hardly critically affects running workloads.
>>
>>
>> VDSM build is ready and added to ovirt-4.2-pre repo.
>> Pending decision on cockpit-ovirt and ovirt-engine for going ahead with the 
>> release.
>>
>>
>>
>>
>>>
>>>
>>> > 1524119   VirtvdsmGeneral from...@redhat.com  POST
>>> > Failed to migrate HE VM urgent  urgent
>>> >
>>> >
>>> > Looks like we'll need a RC3.
>>> >
>>> >
>>> >
>>> >
>>> >> On 12 Dec 2017, at 16:45, Sandro Bonazzola  wrote:
>>> >>
>>> >> The oVirt Project is pleased to announce the availability of the Second 
>>> >> Candidate Release of oVirt 4.2.0, as of December 12th, 2017
>>> >>
>>> >> This is pre-release software. This pre-release should not to be used in 
>>> >> production.
>>> >> Please take a look at our community page[1] to learn how to ask 
>>> >> questions and interact with developers and users.
>>> >> All issues or bugs should be reported via oVirt Bugzilla[2].
>>> >>
>>> >> This update is the second candidate release of the 4.2.0 version. This 
>>> >> release brings more than 280 enhancements and more than one thousand bug 
>>> >> fixes, including more than 500 high or urgent severity fixes, on top of 
>>> >> oVirt 4.1 series.
>>> >>
>>> >> What's new in oVirt 4.2.0?
>>> >>
>>> >>  • The Administration Portal has been completely redesigned using 
>>> >> Patternfly, a widely adopted standard in web application design. It now 
>>> >> features a cleaner, more intuitive design, for an improved user 
>>> >> experience.
>>> >>  • There is an all-new VM Portal for non-admin users.
>>> >>  • A new High Performance virtual machine type has been added to the 
>>> >> New VM dialog box in the Administration Portal.
>>> >>  • Open Virtual Network (OVN) adds support for Open vSwitch software 
>>> >> defined networking (SDN).
>>> >>  • oVirt now supports Nvidia vGPU.
>>> >>  • The ovirt-ansible-roles package helps users with common 
>>> >> administration tasks.
>>> >>  • Virt-v2v now supports Debian/Ubuntu based VMs.
>>> >>
>>> >> For more information about these and other features, check out the oVirt 
>>> >> 4.2.0 blog post.
>>> >>
>>> >> This release is available now on x86_64 architecture for:
>>> >> * Red Hat Enterprise Linux 7.4 or later
>>> >> * CentOS Linux (or similar) 7.4 or later
>>> >>
>>> >> This release supports Hypervisor Hosts on x86_64 and ppc64le 
>>> >> architectures for:
>>> >> * Red Hat Enterprise Linux 7.4 or later
>>> >> * CentOS Linux (or similar) 7.4 or later
>>> >> * oVirt Node 4.2 (available for x86_64 only)
>>> >>
>>> >> See the release notes draft [3] for installation / upgrade instructions 
>>> >> and a list of new features and bugs fixed.
>>> >>
>>> >> Notes:
>>> >> - oVirt Appliance is already available.
>>> >> - oVirt Node is already available [4]
>>> >>
>>> >> Additional Resources:
>>> >> * Read more about the oVirt 4.2.0 release highlights: 

Re: [ovirt-devel] 4.2.1 bugs

[Martin Sivak]

We are in very similar situation. We have bugs for 4.2.x that are more
urgent than what we currently have for 4.3. Including bugs where we
already know we will be doing the 4.2.z backport.

Martin

On Fri, Dec 1, 2017 at 9:08 PM, Dan Kenigsberg  wrote:
> On Fri, Dec 1, 2017 at 2:06 PM, Greg Sheremeta  wrote:
>>
>> On Fri, Dec 1, 2017 at 3:25 AM, Dan Kenigsberg  wrote:
>>>
>>> On Fri, Dec 1, 2017 at 3:18 AM, Greg Sheremeta 
>>> wrote:

 Hi,

 I have some 4.2.1 bugs I want to start working on, but I don't want them
 getting into 4.2.0 GA. What should I do?

 Best wishes,
 Greg
>>>
>>>
>>> You can work on them all right, but until we have an rc branch, you should
>>> not have them merged.
>>> I believe that an rc branch would be created after rc1 is built (which is
>>> now delayed for the 4th day).
>>>
>>
>> Ok, makes sense. But even after the rc is built and safe, there's always a
>> chance of us needing another rc before 4.2 GA. So isn't it the case that
>> nothing for 4.2.1 should be merged until the GA branch is created (if
>> there's such a thing, or is that the rc branch you refer to)?
>>
>> I know this was discussed in a meeting, but I guess I'm a proponent of
>> branching 4.2 off master completely at this point. We (UX team) have some
>> 4.3 items I think we could start on, too.
>>
>> Leaving a bunch of patches sitting in gerrit introduces risks of them not
>> working when they all get rebased, and we're also missing out on OST.
>>
>
> People in my team have plenty of 4.2 bugs to work on (17 bugs, few
> RFEs) and no urgent 4.3 tasks, so for us, branching out 4.2 means
> double the backports.
>
> However, we have 0 bugs for 4.2.0, so I am a proponent of branching
> out 4.2.0-rc now (but that may mean a lot of headache for CI team).
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [VDSM] mom missing on fc27?

[Martin Sivak]

> Do you know why we cannot find the package? maybe we are missing some
> repo?

I am not sure our CI supports the transition from rawhide to F27. The
rules that control what is taken from where for CI are sufficiently
complicated that I do not even know where to start looking.

It is definitely possible the rules expect a specific F27 repo
somewhere which we do not have..

Martin

On Fri, Dec 1, 2017 at 2:57 PM, Nir Soffer  wrote:
> On Fri, Dec 1, 2017 at 3:09 PM Martin Sivak  wrote:
>>
>> I am the maintainer. MOM was properly released
>>
>> (https://copr.fedorainfracloud.org/coprs/msivak/mom-for-ovirt/build/607620/)
>> to F26 and F27 when it was still rawhide and there was no change since
>> then.
>
>
> But we still fail to find the package when the test is running "yum
> install".
>
> Do you know why we cannot find the package? maybe we are missing some
> repo?
>
>>
>> We should really setup the buildroot inheritance properly so we
>> do not have to manually rebuild everything just because Fedora
>> released another version. Fedora itself behaves like that...
>>
>> The same applies to our build configurations. You should not require
>> people to update the jenkins files every time we add a distro or
>> version, it should be done automatically. Again, the Fedora equivalent
>> is distgit branch creation and it happens with no maintainer
>> intervention.
>>
>> All those issues are the price we pay for developing our own solution.
>>
>> Martin
>>
>> On Sat, Nov 25, 2017 at 1:51 AM, Nir Soffer  wrote:
>> > Looks like all the tests are passing now on fc27, but the install
>> > test, running when modifying the spec or makefiles fails with
>> > the error bellow.
>> >
>> > Looks like mom 0.5.8 is missing (as usual). Who is the maintainer?
>> >
>> > There is also this (bogus?) error:
>> >
>> > nothing provides python-argparse needed by
>> > vdsm-4.18.999-444.git0bb7717.fc27.x86_64
>> >
>> > Vdsm does not require python-argparse since:
>> >
>> > commit 3405cbc566de012556d07d86eb1a2c13a5346253
>> > Author: Yaniv Bronhaim 
>> > Date:   Mon Sep 19 18:28:47 2016 +0300
>> >
>> > Remove python-argparse requirement
>> >
>> > This package has been obsoleted in Fedora because it got in to
>> > stdlib.
>> >
>> > Change-Id: I4b9e46427eece4987082344b0936f51ce300f39e
>> > Signed-off-by: Yaniv Bronhaim 
>> > Reviewed-on: https://gerrit.ovirt.org/64162
>> > Continuous-Integration: Jenkins CI
>> > Reviewed-by: Nir Soffer 
>> > Reviewed-by: Piotr Kliczewski 
>> > Reviewed-by: Dan Kenigsberg 
>> >
>> > And of course git grep python-argparse show nothing in vdsm tree.
>> >
>> > Maybe mom or a package required by mom require python-argparse?
>> >
>> > 19:30:55 Error:
>> > 19:30:55  Problem 1: conflicting requests
>> > 19:30:55   - nothing provides mom >= 0.5.8 needed by
>> > vdsm-4.20.8-24.gita3fa2c46e.fc27.x86_64
>> > 19:30:55  Problem 2: package
>> > vdsm-tests-4.20.8-24.gita3fa2c46e.fc27.noarch
>> > requires vdsm = 4.20.8-24.gita3fa2c46e.fc27, but none of the providers
>> > can
>> > be installed
>> > 19:30:55   - conflicting requests
>> > 19:30:55   - nothing provides mom >= 0.5.8 needed by
>> > vdsm-4.20.8-24.gita3fa2c46e.fc27.x86_64
>> > 19:30:55  Problem 3: package
>> > vdsm-hook-vmfex-dev-4.20.8-24.gita3fa2c46e.fc27.noarch requires vdsm =
>> > 4.20.8-24.gita3fa2c46e.fc27, but none of the providers can be installed
>> > 19:30:55   - conflicting requests
>> > 19:30:55   - nothing provides mom >= 0.5.8 needed by
>> > vdsm-4.20.8-24.gita3fa2c46e.fc27.x86_64
>> > 19:30:55  Problem 4: package
>> > vdsm-hook-fcoe-4.20.8-24.gita3fa2c46e.fc27.noarch requires vdsm =
>> > 4.20.8-24.gita3fa2c46e.fc27, but none of the providers can be installed
>> > 19:30:55   - conflicting requests
>> > 19:30:55   - nothing provides mom >= 0.5.8 needed by
>> > vdsm-4.20.8-24.gita3fa2c46e.fc27.x86_64
>> > 19:30:55  Problem 5: package
>> > vdsm-hook-extnet-4.20.8-24.gita3fa2c46e.fc27.noarch requires vdsm =
>> > 4.20.8-24.gita3fa2c46e.fc27, but none of the providers can be installed
>> > 19:30:55   - conflicting requests
>> > 19:30:55   - nothing provides mom >= 0.5.8 needed by
>> > vdsm-4.20.8-24.gita3fa2c46e.fc27.x86_64
>> > 19:30:55  Problem 6: package

Re: [ovirt-devel] [VDSM] mom missing on fc27?

[Martin Sivak]

I am the maintainer. MOM was properly released
(https://copr.fedorainfracloud.org/coprs/msivak/mom-for-ovirt/build/607620/)
to F26 and F27 when it was still rawhide and there was no change since
then. We should really setup the buildroot inheritance properly so we
do not have to manually rebuild everything just because Fedora
released another version. Fedora itself behaves like that...

The same applies to our build configurations. You should not require
people to update the jenkins files every time we add a distro or
version, it should be done automatically. Again, the Fedora equivalent
is distgit branch creation and it happens with no maintainer
intervention.

All those issues are the price we pay for developing our own solution.

Martin

On Sat, Nov 25, 2017 at 1:51 AM, Nir Soffer  wrote:
> Looks like all the tests are passing now on fc27, but the install
> test, running when modifying the spec or makefiles fails with
> the error bellow.
>
> Looks like mom 0.5.8 is missing (as usual). Who is the maintainer?
>
> There is also this (bogus?) error:
>
> nothing provides python-argparse needed by
> vdsm-4.18.999-444.git0bb7717.fc27.x86_64
>
> Vdsm does not require python-argparse since:
>
> commit 3405cbc566de012556d07d86eb1a2c13a5346253
> Author: Yaniv Bronhaim 
> Date:   Mon Sep 19 18:28:47 2016 +0300
>
> Remove python-argparse requirement
>
> This package has been obsoleted in Fedora because it got in to stdlib.
>
> Change-Id: I4b9e46427eece4987082344b0936f51ce300f39e
> Signed-off-by: Yaniv Bronhaim 
> Reviewed-on: https://gerrit.ovirt.org/64162
> Continuous-Integration: Jenkins CI
> Reviewed-by: Nir Soffer 
> Reviewed-by: Piotr Kliczewski 
> Reviewed-by: Dan Kenigsberg 
>
> And of course git grep python-argparse show nothing in vdsm tree.
>
> Maybe mom or a package required by mom require python-argparse?
>
> 19:30:55 Error:
> 19:30:55  Problem 1: conflicting requests
> 19:30:55   - nothing provides mom >= 0.5.8 needed by
> vdsm-4.20.8-24.gita3fa2c46e.fc27.x86_64
> 19:30:55  Problem 2: package vdsm-tests-4.20.8-24.gita3fa2c46e.fc27.noarch
> requires vdsm = 4.20.8-24.gita3fa2c46e.fc27, but none of the providers can
> be installed
> 19:30:55   - conflicting requests
> 19:30:55   - nothing provides mom >= 0.5.8 needed by
> vdsm-4.20.8-24.gita3fa2c46e.fc27.x86_64
> 19:30:55  Problem 3: package
> vdsm-hook-vmfex-dev-4.20.8-24.gita3fa2c46e.fc27.noarch requires vdsm =
> 4.20.8-24.gita3fa2c46e.fc27, but none of the providers can be installed
> 19:30:55   - conflicting requests
> 19:30:55   - nothing provides mom >= 0.5.8 needed by
> vdsm-4.20.8-24.gita3fa2c46e.fc27.x86_64
> 19:30:55  Problem 4: package
> vdsm-hook-fcoe-4.20.8-24.gita3fa2c46e.fc27.noarch requires vdsm =
> 4.20.8-24.gita3fa2c46e.fc27, but none of the providers can be installed
> 19:30:55   - conflicting requests
> 19:30:55   - nothing provides mom >= 0.5.8 needed by
> vdsm-4.20.8-24.gita3fa2c46e.fc27.x86_64
> 19:30:55  Problem 5: package
> vdsm-hook-extnet-4.20.8-24.gita3fa2c46e.fc27.noarch requires vdsm =
> 4.20.8-24.gita3fa2c46e.fc27, but none of the providers can be installed
> 19:30:55   - conflicting requests
> 19:30:55   - nothing provides mom >= 0.5.8 needed by
> vdsm-4.20.8-24.gita3fa2c46e.fc27.x86_64
> 19:30:55  Problem 6: package
> vdsm-hook-ethtool-options-4.20.8-24.gita3fa2c46e.fc27.noarch requires vdsm =
> 4.20.8-24.gita3fa2c46e.fc27, but none of the providers can be installed
> 19:30:55   - conflicting requests
> 19:30:55   - nothing provides mom >= 0.5.8 needed by
> vdsm-4.20.8-24.gita3fa2c46e.fc27.x86_64
> 19:30:55  Problem 7: package
> vdsm-hook-checkips-4.20.8-24.gita3fa2c46e.fc27.x86_64 requires vdsm =
> 4.20.8-24.gita3fa2c46e.fc27, but none of the providers can be installed
> 19:30:55   - conflicting requests
> 19:30:55   - nothing provides mom >= 0.5.8 needed by
> vdsm-4.20.8-24.gita3fa2c46e.fc27.x86_64
> 19:30:55  Problem 8: package vdsm-gluster-4.20.8-24.gita3fa2c46e.fc27.noarch
> requires vdsm = 4.20.8-24.gita3fa2c46e.fc27, but none of the providers can
> be installed
> 19:30:55   - conflicting requests
> 19:30:55   - nothing provides mom >= 0.5.8 needed by
> vdsm-4.20.8-24.gita3fa2c46e.fc27.x86_64
> 19:30:55  Problem 9: package
> vdsm-hook-qemucmdline-4.20.8-24.gita3fa2c46e.fc27.noarch requires vdsm, but
> none of the providers can be installed
> 19:30:55   - conflicting requests
> 19:30:55   - nothing provides mom >= 0.5.8 needed by
> vdsm-4.20.8-1.git383bc1031.fc27.x86_64
> 19:30:55   - nothing provides mom >= 0.5.8 needed by
> vdsm-4.20.8-15.git50bd65cf2.fc27.x86_64
> 19:30:55   - nothing provides mom >= 0.5.8 needed by
> vdsm-4.20.8-18.git28b0fffcd.fc27.x86_64
> 19:30:55   - nothing provides mom >= 0.5.8 needed by
> vdsm-4.20.8-3.gita9ee9c65f.fc27.x86_64
> 19:30:55   - nothing provides mom >= 0.5.8 needed by
> vdsm-4.20.8-4.gite1d056920.fc27.x86_64
> 19:30:55   - nothing provides mom >= 0.5.8 needed by
> vdsm-4.20.8-5.git4b7766c65.fc27.x86_64
> 19:30:55   - nothing provides pytho

Re: [ovirt-devel] oVirt 4.2.0 blockers review - Day 4

[Martin Sivak]

The Quota bug was not really a blocker, but since it kept the flag, we
merged the fix.

I just tried to help Ondra with the other one, but we need to wait and see
if the fix we got from Fedora guidelines works.

Martin

On Fri, Dec 1, 2017 at 12:49 PM, Sandro Bonazzola 
wrote:

> we still have 2 open acknowledged blockers according to
> https://bugzilla.redhat.com/buglist.cgi?quicksearch=flag%
> 3Ablocker%2B%20target_milestone%3Aovirt-4.2.0%20status%
> 3Anew%2Cassigned%2Cpost
>
> Bug ID Product Assignee Status Summary
> 1518693  ovirt-engine
> akrej...@redhat.com POST Quota is needed to copy template disk
> 1519301  Red Hat
> Enterprise Virtualization Manager omach...@redhat.com POST Transaction
> failed when upgrading engine + ovirt-ansible-roles
>
> There are no additional proposed blockers: https://bugzilla.red
> hat.com/buglist.cgi?quicksearch=flag%3Ablocker%3F%20target_
> milestone%3Aovirt-4.2.0%20status%3Anew%2Cassigned%2Cpost
>
> Please give estimation for fixing the last 2 blockers.
>
> Please note we still have 79 non blocking bugs targeted to 4.2.0; please
> review them and re-target to 4.2.1 or later. https://bugzilla.
> redhat.com/buglist.cgi?quicksearch=-flag%3Ablocker%
> 3F%20target_milestone%3Aovirt-4.2.0%20status%3Anew%
> 2Cassigned%2Cpost%20-flag%3Ablocker
>
> Thanks
>
> --
>
> SANDRO BONAZZOLA
>
> ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
>
> Red Hat EMEA 
> 
> TRIED. TESTED. TRUSTED. 
>
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] oVirt 4.2 and UI plugin infrastructure

[Martin Sivak]

It stays on a single line with just slightly wider window than I normally
have. But all plugins will be adding buttons here so the line can
theoretically get really long.

Btw, is 1920px the required resolution now? Because I have no screen or
machine with that :D

Martin

On Thu, Nov 30, 2017 at 4:44 PM, Greg Sheremeta  wrote:

> How does it look at 1920px wide?
>
> On Thu, Nov 30, 2017 at 10:40 AM, Martin Sivak  wrote:
>
>> Hi,
>>
>> I see it working with a small UI glitch:
>>
>> Martin
>>
>> On Wed, Nov 29, 2017 at 6:25 PM, Martin Sivak  wrote:
>>
>>> I will try finding time tomorrow. Thanks.
>>>
>>> Martin
>>>
>>> On Wed, Nov 29, 2017 at 6:02 PM, Greg Sheremeta 
>>> wrote:
>>>
>>>> Martin, we've merged the fix. (Thanks to Alexander for the super fast
>>>> fix.)
>>>>
>>>> Care to test with master?
>>>>
>>>> On Wed, Nov 29, 2017 at 10:50 AM, Alexander Wels 
>>>> wrote:
>>>>
>>>>> On Wednesday, November 29, 2017 10:16:27 AM EST Martin Sivak wrote:
>>>>> > Thanks to you too for checking.
>>>>> >
>>>>> > Martin
>>>>> >
>>>>>
>>>>> Fix is pending review [1]. We moved the main views to a different class
>>>>> hierarchy and it wasn't inheriting the methods to add the buttons.
>>>>>
>>>>> Alexander
>>>>>
>>>>> [1] https://gerrit.ovirt.org/c/84901/
>>>>>
>>>>> > On Wed, Nov 29, 2017 at 3:07 PM, Greg Sheremeta 
>>>>> wrote:
>>>>> > > Discussed with Alexander, and yep this is an issue.
>>>>> > > I opened https://bugzilla.redhat.com/show_bug.cgi?id=1518724
>>>>> > >
>>>>> > > Thanks for checking and reporting!
>>>>> > >
>>>>> > > On Wed, Nov 29, 2017 at 8:35 AM, Greg Sheremeta <
>>>>> gsher...@redhat.com>
>>>>> > >
>>>>> > > wrote:
>>>>> > >> +Alexander, can you take a look?
>>>>> > >>
>>>>> > >> On Wed, Nov 29, 2017 at 8:33 AM, Martin Sivak 
>>>>> wrote:
>>>>> > >>> Hi,
>>>>> > >>>
>>>>> > >>> I think I found one issue.. I do not see the extra menu items
>>>>> that were
>>>>> > >>> supposed to be added to VMs (used to be available in context
>>>>> menu as
>>>>> > >>> well).
>>>>> > >>>
>>>>> > >>> You can check it with
>>>>> > >>>
>>>>> > >>> http://jenkins.ovirt.org/job/ovirt-optimizer_master_check-pa
>>>>> > >>> tch-el7-x86_64/65/
>>>>> > >>>
>>>>> > >>> Martin
>>>>> > >>>
>>>>> > >>> On Wed, Nov 29, 2017 at 1:22 AM, Greg Sheremeta <
>>>>> gsher...@redhat.com>
>>>>> > >>>
>>>>> > >>> wrote:
>>>>> > >>>> Hey,
>>>>> > >>>>
>>>>> > >>>> We haven't changed the API, so everything should still work. For
>>>>> > >>>> example, I just installed 4.1 versions of dashboard and
>>>>> support-plugin
>>>>> > >>>> in
>>>>> > >>>> master, and all's well [*]:
>>>>> > >>>>
>>>>> > >>>> API:
>>>>> > >>>>
>>>>> > >>>> api.addSubTab('Template', 'Red Hat Documentation',
>>>>> > >>>> 'my-host-subtab-template', '', {alignRight: true});
>>>>> > >>>> api.setTabAccessible('my-host-subtab-template', true);
>>>>> > >>>>
>>>>> > >>>> [image: Inline image 1]
>>>>> > >>>>
>>>>> > >>>> [*] however, note that "alignRight" is now ignored
>>>>> > >>>>
>>>>> > >>>> And dashboard 4.1.8 installed in master engine:
>>>>> > >>>>
>>>>> > >>>> [image: Inline image 2]

Re: [ovirt-devel] oVirt 4.2 and UI plugin infrastructure

[Martin Sivak]

Hi,

I see it working with a small UI glitch:

Martin

On Wed, Nov 29, 2017 at 6:25 PM, Martin Sivak  wrote:

> I will try finding time tomorrow. Thanks.
>
> Martin
>
> On Wed, Nov 29, 2017 at 6:02 PM, Greg Sheremeta 
> wrote:
>
>> Martin, we've merged the fix. (Thanks to Alexander for the super fast
>> fix.)
>>
>> Care to test with master?
>>
>> On Wed, Nov 29, 2017 at 10:50 AM, Alexander Wels 
>> wrote:
>>
>>> On Wednesday, November 29, 2017 10:16:27 AM EST Martin Sivak wrote:
>>> > Thanks to you too for checking.
>>> >
>>> > Martin
>>> >
>>>
>>> Fix is pending review [1]. We moved the main views to a different class
>>> hierarchy and it wasn't inheriting the methods to add the buttons.
>>>
>>> Alexander
>>>
>>> [1] https://gerrit.ovirt.org/c/84901/
>>>
>>> > On Wed, Nov 29, 2017 at 3:07 PM, Greg Sheremeta 
>>> wrote:
>>> > > Discussed with Alexander, and yep this is an issue.
>>> > > I opened https://bugzilla.redhat.com/show_bug.cgi?id=1518724
>>> > >
>>> > > Thanks for checking and reporting!
>>> > >
>>> > > On Wed, Nov 29, 2017 at 8:35 AM, Greg Sheremeta >> >
>>> > >
>>> > > wrote:
>>> > >> +Alexander, can you take a look?
>>> > >>
>>> > >> On Wed, Nov 29, 2017 at 8:33 AM, Martin Sivak 
>>> wrote:
>>> > >>> Hi,
>>> > >>>
>>> > >>> I think I found one issue.. I do not see the extra menu items that
>>> were
>>> > >>> supposed to be added to VMs (used to be available in context menu
>>> as
>>> > >>> well).
>>> > >>>
>>> > >>> You can check it with
>>> > >>>
>>> > >>> http://jenkins.ovirt.org/job/ovirt-optimizer_master_check-pa
>>> > >>> tch-el7-x86_64/65/
>>> > >>>
>>> > >>> Martin
>>> > >>>
>>> > >>> On Wed, Nov 29, 2017 at 1:22 AM, Greg Sheremeta <
>>> gsher...@redhat.com>
>>> > >>>
>>> > >>> wrote:
>>> > >>>> Hey,
>>> > >>>>
>>> > >>>> We haven't changed the API, so everything should still work. For
>>> > >>>> example, I just installed 4.1 versions of dashboard and
>>> support-plugin
>>> > >>>> in
>>> > >>>> master, and all's well [*]:
>>> > >>>>
>>> > >>>> API:
>>> > >>>>
>>> > >>>> api.addSubTab('Template', 'Red Hat Documentation',
>>> > >>>> 'my-host-subtab-template', '', {alignRight: true});
>>> > >>>> api.setTabAccessible('my-host-subtab-template', true);
>>> > >>>>
>>> > >>>> [image: Inline image 1]
>>> > >>>>
>>> > >>>> [*] however, note that "alignRight" is now ignored
>>> > >>>>
>>> > >>>> And dashboard 4.1.8 installed in master engine:
>>> > >>>>
>>> > >>>> [image: Inline image 2]
>>> > >>>>
>>> > >>>>
>>> > >>>> That said, we probably should have sent some announcement about
>>> making
>>> > >>>> sure the plugins actually look good with the new theme. If some
>>> plugins
>>> > >>>> are
>>> > >>>> greenish, that will look bad.
>>> > >>>>
>>> > >>>> To help with styling external things, we've started exposing more
>>> CSS
>>> > >>>> via a new SASS brand module:
>>> > >>>> https://github.com/oVirt/ovirt-engine/tree/master/frontend/b
>>> > >>>> rands/ovirt-brand/src/main/sass
>>> > >>>> Also, we're heavily relying on base PatternFly styles, and plugins
>>> > >>>> should do the same. For example, the new dialog styles are
>>> completely
>>> > >>>> PatternFly [http://www.patternfly.org/pat
>>> tern-library/forms-and-control
>>> > >>>> s/modal-overlay/] and we do

Re: [ovirt-devel] oVirt 4.2.0 blockers review - Day 3

[Martin Sivak]

>
>> 1517810 
>>> ovirt-engine stira...@redhat.com Adding additional ha-host fails.
>>>
>>
> This one has a verified engine fix now, we just need to merge it and
> update Node 0 setup (also verified).
>

Merged.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] oVirt 4.2.0 blockers review - Day 3

[Martin Sivak]

On Thu, Nov 30, 2017 at 11:28 AM, Martin Sivak  wrote:

> I think a reasonable alternative is to revert the change, adjust HE to use
>> both formats, and then introduce the new format. The first step (revert)
>> should be done for 4.2.0 (today?) and the rest for 4.2.1.
>> Y.
>>
>>
> The format is still the same, we just needed to autodetect the used NS and
> then query for attributes using the detected namespace. Patch posted, tests
> are passing, but since we want to be 100% sure we will test with OST and
> Node 0 before pushing it. Should not take long.
>


Verified and Merged.


> Martin
>
>
>
>>
>>>
>>>>
>>>>
>>>>>
>>>>> 1516113 <https://bugzilla.redhat.com/show_bug.cgi?id=1516113>
>>>>>> cockpit-ovirt phbai...@redhat.com POST Deploy the HostedEngine
>>>>>> failed with the default CPU type
>>>>>>
>>>>>
>>>>> Would be happy if the remaining patch could get reviewed quickly.
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>> 1518693 <https://bugzilla.redhat.com/show_bug.cgi?id=1518693>
>>>>>> ovirt-engine akrej...@redhat.com POST Quota is needed to copy
>>>>>> template disk
>>>>>>
>>>>>
>>>>> This is only via REST and the default quota can be used as a
>>>>> workaround - why is this a blocker?
>>>>>
>>>>
>>>> Automation added it because Raz marked it as Regression. But the change
>>>> was intentional.
>>>>
>>>>
>>>>
>>>>> 1517810 <https://bugzilla.redhat.com/show_bug.cgi?id=1517810>
>>>>>> ovirt-engine stira...@redhat.com Adding additional ha-host fails.
>>>>>>
>>>>>
>>>> This one has a verified engine fix now, we just need to merge it and
>>>> update Node 0 setup (also verified).
>>>>
>>>>
>>>> Martin
>>>>
>>>>
>>>> ___
>>>> Devel mailing list
>>>> Devel@ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>>
>>>
>>>
>>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] oVirt 4.2.0 blockers review - Day 3

[Martin Sivak]

>
> I think a reasonable alternative is to revert the change, adjust HE to use
> both formats, and then introduce the new format. The first step (revert)
> should be done for 4.2.0 (today?) and the rest for 4.2.1.
> Y.
>
>
The format is still the same, we just needed to autodetect the used NS and
then query for attributes using the detected namespace. Patch posted, tests
are passing, but since we want to be 100% sure we will test with OST and
Node 0 before pushing it. Should not take long.

Martin



>
>>
>>>
>>>

 1516113 
> cockpit-ovirt phbai...@redhat.com POST Deploy the HostedEngine failed
> with the default CPU type
>

 Would be happy if the remaining patch could get reviewed quickly.

>>>
>>>
>>>
>>>

 1518693 
> ovirt-engine akrej...@redhat.com POST Quota is needed to copy
> template disk
>

 This is only via REST and the default quota can be used as a workaround
 - why is this a blocker?

>>>
>>> Automation added it because Raz marked it as Regression. But the change
>>> was intentional.
>>>
>>>
>>>
 1517810 
> ovirt-engine stira...@redhat.com Adding additional ha-host fails.
>

>>> This one has a verified engine fix now, we just need to merge it and
>>> update Node 0 setup (also verified).
>>>
>>>
>>> Martin
>>>
>>>
>>> ___
>>> Devel mailing list
>>> Devel@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>
>>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] oVirt 4.2.0 blockers review - Day 3

[Martin Sivak]

>
>
>>
>> Bug ID Product Assignee Status Summary
>> 1518887 
>> ovirt-hosted-engine-ha b...@ovirt.org NEW ovirt-ha-agent fails parsing
>> the OVF_STORE due to a change in OVF namespace URI
>>
>
> I'm in favor of reverting the virt change personally.
>

Unless something else depends on it, the commit message said vdsm needs
this.


>
> 1516113 
>> cockpit-ovirt phbai...@redhat.com POST Deploy the HostedEngine failed
>> with the default CPU type
>>
>
> Would be happy if the remaining patch could get reviewed quickly.
>




>
> 1518693  ovirt-engine
>> akrej...@redhat.com POST Quota is needed to copy template disk
>>
>
> This is only via REST and the default quota can be used as a workaround -
> why is this a blocker?
>

Automation added it because Raz marked it as Regression. But the change was
intentional.



> 1517810  ovirt-engine
>> stira...@redhat.com Adding additional ha-host fails.
>>
>
This one has a verified engine fix now, we just need to merge it and update
Node 0 setup (also verified).


Martin
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] oVirt 4.2.0 blockers review

[Martin Sivak]

> Ouch, the code should now accept both URI, to support OVFs created prior to
> the change, as well as new ones.

Yeah, we will have to add some detection of the used URI. The library
does not support wildcards I am afraid.

Martin

On Wed, Nov 29, 2017 at 8:43 PM, Dan Kenigsberg  wrote:
>
> On Wed, Nov 29, 2017 at 7:33 PM, Simone Tiraboschi 
> wrote:
>>
>> I think that this one should be considered a blocker as well:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1518887 - ovirt-ha-agent fails
>> parsing the OVF_STORE
>
>
> Ouch, the code should now accept both URI, to support OVFs created prior to
> the change, as well as new ones.
>
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] oVirt 4.2 and UI plugin infrastructure

[Martin Sivak]

I will try finding time tomorrow. Thanks.

Martin

On Wed, Nov 29, 2017 at 6:02 PM, Greg Sheremeta  wrote:

> Martin, we've merged the fix. (Thanks to Alexander for the super fast fix.)
>
> Care to test with master?
>
> On Wed, Nov 29, 2017 at 10:50 AM, Alexander Wels  wrote:
>
>> On Wednesday, November 29, 2017 10:16:27 AM EST Martin Sivak wrote:
>> > Thanks to you too for checking.
>> >
>> > Martin
>> >
>>
>> Fix is pending review [1]. We moved the main views to a different class
>> hierarchy and it wasn't inheriting the methods to add the buttons.
>>
>> Alexander
>>
>> [1] https://gerrit.ovirt.org/c/84901/
>>
>> > On Wed, Nov 29, 2017 at 3:07 PM, Greg Sheremeta 
>> wrote:
>> > > Discussed with Alexander, and yep this is an issue.
>> > > I opened https://bugzilla.redhat.com/show_bug.cgi?id=1518724
>> > >
>> > > Thanks for checking and reporting!
>> > >
>> > > On Wed, Nov 29, 2017 at 8:35 AM, Greg Sheremeta 
>> > >
>> > > wrote:
>> > >> +Alexander, can you take a look?
>> > >>
>> > >> On Wed, Nov 29, 2017 at 8:33 AM, Martin Sivak 
>> wrote:
>> > >>> Hi,
>> > >>>
>> > >>> I think I found one issue.. I do not see the extra menu items that
>> were
>> > >>> supposed to be added to VMs (used to be available in context menu as
>> > >>> well).
>> > >>>
>> > >>> You can check it with
>> > >>>
>> > >>> http://jenkins.ovirt.org/job/ovirt-optimizer_master_check-pa
>> > >>> tch-el7-x86_64/65/
>> > >>>
>> > >>> Martin
>> > >>>
>> > >>> On Wed, Nov 29, 2017 at 1:22 AM, Greg Sheremeta <
>> gsher...@redhat.com>
>> > >>>
>> > >>> wrote:
>> > >>>> Hey,
>> > >>>>
>> > >>>> We haven't changed the API, so everything should still work. For
>> > >>>> example, I just installed 4.1 versions of dashboard and
>> support-plugin
>> > >>>> in
>> > >>>> master, and all's well [*]:
>> > >>>>
>> > >>>> API:
>> > >>>>
>> > >>>> api.addSubTab('Template', 'Red Hat Documentation',
>> > >>>> 'my-host-subtab-template', '', {alignRight: true});
>> > >>>> api.setTabAccessible('my-host-subtab-template', true);
>> > >>>>
>> > >>>> [image: Inline image 1]
>> > >>>>
>> > >>>> [*] however, note that "alignRight" is now ignored
>> > >>>>
>> > >>>> And dashboard 4.1.8 installed in master engine:
>> > >>>>
>> > >>>> [image: Inline image 2]
>> > >>>>
>> > >>>>
>> > >>>> That said, we probably should have sent some announcement about
>> making
>> > >>>> sure the plugins actually look good with the new theme. If some
>> plugins
>> > >>>> are
>> > >>>> greenish, that will look bad.
>> > >>>>
>> > >>>> To help with styling external things, we've started exposing more
>> CSS
>> > >>>> via a new SASS brand module:
>> > >>>> https://github.com/oVirt/ovirt-engine/tree/master/frontend/b
>> > >>>> rands/ovirt-brand/src/main/sass
>> > >>>> Also, we're heavily relying on base PatternFly styles, and plugins
>> > >>>> should do the same. For example, the new dialog styles are
>> completely
>> > >>>> PatternFly [http://www.patternfly.org/pat
>> tern-library/forms-and-control
>> > >>>> s/modal-overlay/] and we don't do anything extra on top of that.
>> > >>>>
>> > >>>> Let us know if something doesn't work, or you need help styling
>> > >>>> something.
>> > >>>>
>> > >>>> Greg
>> > >>>>
>> > >>>> On Tue, Nov 28, 2017 at 6:25 PM, Martin Sivak 
>> > >>>>
>> > >>>> wrote:
>> > >>>>> Hi,
>> > >>>>>
>> > >>>>> I just got a question from an ovirt-optimizer user about the
>> support
>> > >>>>> in 4.2. And I realized I haven't heard anything about how UI
>> plugins
>> > >>>>> should be updated to work with the new UI.
>> > >>>>>
>> > >>>>> Is there anything special that needs to be done to make the plugin
>> > >>>>> functional? Or will everything still work somehow?
>> > >>>>>
>> > >>>>> Best regards
>> > >>>>>
>> > >>>>> Martin Sivak
>> > >>>>> ___
>> > >>>>> Devel mailing list
>> > >>>>> Devel@ovirt.org
>> > >>>>> http://lists.ovirt.org/mailman/listinfo/devel
>> > >>
>> > >> --
>> > >>
>> > >> GREG SHEREMETA
>> > >>
>> > >> SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX
>> > >>
>> > >> Red Hat NA
>> > >>
>> > >> <https://www.redhat.com/>
>> > >>
>> > >> gsher...@redhat.comIRC: gshereme
>> > >> <https://red.ht/sig>
>> > >
>> > > --
>> > >
>> > > GREG SHEREMETA
>> > >
>> > > SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX
>> > >
>> > > Red Hat NA
>> > >
>> > > <https://www.redhat.com/>
>> > >
>> > > gsher...@redhat.comIRC: gshereme
>> > > <https://red.ht/sig>
>>
>>
>>
>
>
> --
>
> GREG SHEREMETA
>
> SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX
>
> Red Hat NA
>
> <https://www.redhat.com/>
>
> gsher...@redhat.comIRC: gshereme
> <https://red.ht/sig>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] oVirt 4.2 and UI plugin infrastructure

[Martin Sivak]

Thanks to you too for checking.

Martin

On Wed, Nov 29, 2017 at 3:07 PM, Greg Sheremeta  wrote:

> Discussed with Alexander, and yep this is an issue.
> I opened https://bugzilla.redhat.com/show_bug.cgi?id=1518724
>
> Thanks for checking and reporting!
>
> On Wed, Nov 29, 2017 at 8:35 AM, Greg Sheremeta 
> wrote:
>
>> +Alexander, can you take a look?
>>
>> On Wed, Nov 29, 2017 at 8:33 AM, Martin Sivak  wrote:
>>
>>> Hi,
>>>
>>> I think I found one issue.. I do not see the extra menu items that were
>>> supposed to be added to VMs (used to be available in context menu as well).
>>>
>>> You can check it with
>>>
>>> http://jenkins.ovirt.org/job/ovirt-optimizer_master_check-pa
>>> tch-el7-x86_64/65/
>>>
>>> Martin
>>>
>>> On Wed, Nov 29, 2017 at 1:22 AM, Greg Sheremeta 
>>> wrote:
>>>
>>>> Hey,
>>>>
>>>> We haven't changed the API, so everything should still work. For
>>>> example, I just installed 4.1 versions of dashboard and support-plugin in
>>>> master, and all's well [*]:
>>>>
>>>> API:
>>>>
>>>> api.addSubTab('Template', 'Red Hat Documentation',
>>>> 'my-host-subtab-template', '', {alignRight: true});
>>>> api.setTabAccessible('my-host-subtab-template', true);
>>>>
>>>> [image: Inline image 1]
>>>>
>>>> [*] however, note that "alignRight" is now ignored
>>>>
>>>> And dashboard 4.1.8 installed in master engine:
>>>>
>>>> [image: Inline image 2]
>>>>
>>>>
>>>> That said, we probably should have sent some announcement about making
>>>> sure the plugins actually look good with the new theme. If some plugins are
>>>> greenish, that will look bad.
>>>>
>>>> To help with styling external things, we've started exposing more CSS
>>>> via a new SASS brand module:
>>>> https://github.com/oVirt/ovirt-engine/tree/master/frontend/b
>>>> rands/ovirt-brand/src/main/sass
>>>> Also, we're heavily relying on base PatternFly styles, and plugins
>>>> should do the same. For example, the new dialog styles are completely
>>>> PatternFly [http://www.patternfly.org/pattern-library/forms-and-control
>>>> s/modal-overlay/] and we don't do anything extra on top of that.
>>>>
>>>> Let us know if something doesn't work, or you need help styling
>>>> something.
>>>>
>>>> Greg
>>>>
>>>> On Tue, Nov 28, 2017 at 6:25 PM, Martin Sivak 
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I just got a question from an ovirt-optimizer user about the support
>>>>> in 4.2. And I realized I haven't heard anything about how UI plugins
>>>>> should be updated to work with the new UI.
>>>>>
>>>>> Is there anything special that needs to be done to make the plugin
>>>>> functional? Or will everything still work somehow?
>>>>>
>>>>> Best regards
>>>>>
>>>>> Martin Sivak
>>>>> ___
>>>>> Devel mailing list
>>>>> Devel@ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>>
>> GREG SHEREMETA
>>
>> SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX
>>
>> Red Hat NA
>>
>> <https://www.redhat.com/>
>>
>> gsher...@redhat.comIRC: gshereme
>> <https://red.ht/sig>
>>
>
>
>
> --
>
> GREG SHEREMETA
>
> SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX
>
> Red Hat NA
>
> <https://www.redhat.com/>
>
> gsher...@redhat.comIRC: gshereme
> <https://red.ht/sig>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] oVirt 4.2 and UI plugin infrastructure

[Martin Sivak]

Hi,

I think I found one issue.. I do not see the extra menu items that were
supposed to be added to VMs (used to be available in context menu as well).

You can check it with

http://jenkins.ovirt.org/job/ovirt-optimizer_master_check-patch-el7-x86_64/65/

Martin

On Wed, Nov 29, 2017 at 1:22 AM, Greg Sheremeta  wrote:

> Hey,
>
> We haven't changed the API, so everything should still work. For example,
> I just installed 4.1 versions of dashboard and support-plugin in master,
> and all's well [*]:
>
> API:
>
> api.addSubTab('Template', 'Red Hat Documentation',
> 'my-host-subtab-template', '', {alignRight: true});
> api.setTabAccessible('my-host-subtab-template', true);
>
> [image: Inline image 1]
>
> [*] however, note that "alignRight" is now ignored
>
> And dashboard 4.1.8 installed in master engine:
>
> [image: Inline image 2]
>
>
> That said, we probably should have sent some announcement about making
> sure the plugins actually look good with the new theme. If some plugins are
> greenish, that will look bad.
>
> To help with styling external things, we've started exposing more CSS via
> a new SASS brand module:
> https://github.com/oVirt/ovirt-engine/tree/master/
> frontend/brands/ovirt-brand/src/main/sass
> Also, we're heavily relying on base PatternFly styles, and plugins should
> do the same. For example, the new dialog styles are completely PatternFly [
> http://www.patternfly.org/pattern-library/forms-and-
> controls/modal-overlay/] and we don't do anything extra on top of that.
>
> Let us know if something doesn't work, or you need help styling something.
>
> Greg
>
> On Tue, Nov 28, 2017 at 6:25 PM, Martin Sivak  wrote:
>
>> Hi,
>>
>> I just got a question from an ovirt-optimizer user about the support
>> in 4.2. And I realized I haven't heard anything about how UI plugins
>> should be updated to work with the new UI.
>>
>> Is there anything special that needs to be done to make the plugin
>> functional? Or will everything still work somehow?
>>
>> Best regards
>>
>> Martin Sivak
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] oVirt 4.2 and UI plugin infrastructure

[Martin Sivak]

Hi,

I just got a question from an ovirt-optimizer user about the support
in 4.2. And I realized I haven't heard anything about how UI plugins
should be updated to work with the new UI.

Is there anything special that needs to be done to make the plugin
functional? Or will everything still work somehow?

Best regards

Martin Sivak
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] oVirt 4.2.0 blockers review

[Martin Sivak]

> > 1516113 cockpit-ovirt phbai...@redhat.com POST Deploy the HostedEngine
> failed with the default CPU type
> The whole series was merged, but without the obvious patch (which was
> abandoned), let me check what the status is.
>

Fixed too.




>
> > 1506677 ovirt-engine dchap...@redhat.com POST Hotplug fail when
> attaching a disk with cow format on glusterfs
>
> Patch merged.
>
> Martin
>
> On Tue, Nov 28, 2017 at 11:58 AM, Sandro Bonazzola 
> wrote:
>
>> Hi,
>> I'm waiting for last blockers to be fixed for starting a 4.2.0 RC build.
>> Assignee are in the TO list of this email.
>> So far we are down to 7 bugs: https://bugzilla.redhat.
>> com/buglist.cgi?quicksearch=flag%3Ablocker%2B%20target_miles
>> tone%3Aovirt-4.2.0%20status%3Anew%2Cassigned%2Cpost
>>
>> Please review them and provide an ETA for the fix. If the bug is marked
>> as blocker by mistake, please remove the blocker flag and / or postpone the
>> bug to a later release.
>>
>> Bug ID Product Assignee Status Summary
>> 1516113 cockpit-ovirt phbai...@redhat.com POST Deploy the HostedEngine
>> failed with the default CPU type
>> 1509629 ovirt-engine ah...@redhat.com ASSIGNED Cold merge failed to
>> remove all volumes
>> 1507277 ovirt-engine era...@redhat.com POST [RFE][DR] - Vnic Profiles
>> mapping in VMs register from data storage domain should be supported also
>> for templates
>> 1506677 ovirt-engine dchap...@redhat.com POST Hotplug fail when
>> attaching a disk with cow format on glusterfs
>> 1488338 ovirt-engine mlipc...@redhat.com NEW SPM host is not moving to
>> Non-Operational status when blocking its access to storage domain.
>> 1512534 ovirt-hosted-engine-ha pklic...@redhat.com ASSIGNED SHE
>> deployment takes too much time and looks like stuck.
>> 1496719 vdsm edwa...@redhat.com POST Port mirroring is not set after VM
>> migration
>>
>> --
>>
>> SANDRO BONAZZOLA
>>
>> ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
>>
>> Red Hat EMEA 
>> 
>> TRIED. TESTED. TRUSTED. 
>> 
>>
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] oVirt 4.2.0 blockers review

[Martin Sivak]

> 1516113 cockpit-ovirt phbai...@redhat.com POST Deploy the HostedEngine
failed with the default CPU type
The whole series was merged, but without the obvious patch (which was
abandoned), let me check what the status is.

> 1506677 ovirt-engine dchap...@redhat.com POST Hotplug fail when attaching
a disk with cow format on glusterfs

Patch merged.

Martin

On Tue, Nov 28, 2017 at 11:58 AM, Sandro Bonazzola 
wrote:

> Hi,
> I'm waiting for last blockers to be fixed for starting a 4.2.0 RC build.
> Assignee are in the TO list of this email.
> So far we are down to 7 bugs: https://bugzilla.redhat.
> com/buglist.cgi?quicksearch=flag%3Ablocker%2B%20target_
> milestone%3Aovirt-4.2.0%20status%3Anew%2Cassigned%2Cpost
>
> Please review them and provide an ETA for the fix. If the bug is marked as
> blocker by mistake, please remove the blocker flag and / or postpone the
> bug to a later release.
>
> Bug ID Product Assignee Status Summary
> 1516113 cockpit-ovirt phbai...@redhat.com POST Deploy the HostedEngine
> failed with the default CPU type
> 1509629 ovirt-engine ah...@redhat.com ASSIGNED Cold merge failed to
> remove all volumes
> 1507277 ovirt-engine era...@redhat.com POST [RFE][DR] - Vnic Profiles
> mapping in VMs register from data storage domain should be supported also
> for templates
> 1506677 ovirt-engine dchap...@redhat.com POST Hotplug fail when attaching
> a disk with cow format on glusterfs
> 1488338 ovirt-engine mlipc...@redhat.com NEW SPM host is not moving to
> Non-Operational status when blocking its access to storage domain.
> 1512534 ovirt-hosted-engine-ha pklic...@redhat.com ASSIGNED SHE
> deployment takes too much time and looks like stuck.
> 1496719 vdsm edwa...@redhat.com POST Port mirroring is not set after VM
> migration
>
> --
>
> SANDRO BONAZZOLA
>
> ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
>
> Red Hat EMEA 
> 
> TRIED. TESTED. TRUSTED. 
> 
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Adding s390 support to oVirt

[Martin Sivak]

Dan Horak used to be part of this project. Lets see if he still remembers that.

Dan: Can you please tell us how the s390 builds in Fedora are/were
done when no hw was available?

Martin Sivak

On Sat, Nov 18, 2017 at 12:14 PM, Barak Korren  wrote:
> On 16 November 2017 at 19:38, Martin Sivak  wrote:
>>> Koji is very opinionated about how RPMs and specfiles should look,
>>> AFAIK
>>
>> Actually, koji does not care much. Fedora packaging rules are enforced
>> by package reviewers.
>>
>>> More specifically, Koji usually assumes the starting point for the
>>> build process would be a specfile
>>
>> This is correct though.
>>
>>> Does fedora have an s390x server associated to it?
>>
>> They used to have s390 emulators running for that purpose iirc.
>
> I wonder if someone could provide more information about this. Is this
> done via qemu? Or built-in to mock perhaps? It this exists, I can pave
> the way to enabling s390x build support on oVirt infra.
>
>
> --
> Barak Korren
> RHV DevOps team , RHCE, RHCi
> Red Hat EMEA
> redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Adding s390 support to oVirt

[Martin Sivak]

> Koji is very opinionated about how RPMs and specfiles should look,
> AFAIK

Actually, koji does not care much. Fedora packaging rules are enforced
by package reviewers.

> More specifically, Koji usually assumes the starting point for the
> build process would be a specfile

This is correct though.

> Does fedora have an s390x server associated to it?

They used to have s390 emulators running for that purpose iirc.


Best regards

Martin Sivak

On Thu, Nov 16, 2017 at 6:27 PM, Barak Korren  wrote:
> On 16 November 2017 at 18:52, Viktor Mihajlovski
>  wrote:
>>
>> Short update, with yesterday's API model 4.2.25 release, there's basic
>> support for s390 available in ovirt-engine. At this point in time, there
>> are no ovirt yum repositories for the s390x architecture - not sure what
>> the process would be to add s390x repositories and how to build the
>> binary RPMs at least for the host packages (i.e. vdsm-*). Maybe it would
>> possible to use the s390-koji infrastructure used to build Fedora for s390x?
>
> Koji is very opinionated about how RPMs and specfiles should look,
> AFAIK A pretty massive amount of work would be needed to make
> everything that is needed for a node to build on it, and then we would
> end up with a process that is quite different with how we currently do
> builds for other platforms.
>
> (I might be wrong about this, since some oVirt packages get also built
> as part of the CentOS virt SIG, and that is done using Koji as well)
>
> More specifically, Koji usually assumes the starting point for the
> build process would be a specfile, while in oVirt we typically
> generated the specfile and then the RPM as part of a bigger build
> process.
>
> Does fedora have an s390x server associated to it?
> We do use the same basic environment setup tool - mock - as the basis
> of our build infrastructure, so if Fedora is actually emulating s390x
> is some way while using mock, we might be able to do the same thing.
>
> Just for general knowledge, the process for building oVirt repos, is
> to have *-build-artifacts-* jobs for each project that build RPM's
> after patches get merged, and then have the change-queue to collect
> the built packages, rung them through ovirt-system-tests (a.k.a. OST)
> and finally deposit them into the 'tested' rpoe, from which they are
> copied nightly to the '*-snapshot' repos.
>
> OST only tests for CentOS 7/x86_64 ATM, but we bring along packages
> for other distros and architectures via the same process while
> assuming that if a package for a given commit works for CentOS
> 7/x86_64 it would probably work for other platforms as well...
>
> --
> Barak Korren
> RHV DevOps team , RHCE, RHCi
> Red Hat EMEA
> redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Adding new features to ovirt.org

[Martin Sivak]

> I wonder where did this category division come from, some of these,
> like "VDSM" or "Infra" or "SLA" may not be easy for users to
> understand.
> We need to be careful about using internal development terms in user
> facing documentation.

And yet we require the user to select a team using the same terms when
filing a new bug..

I agree with you, but I think the mandatory field in bugzilla is
another candidate for consideration.

Martin

On Thu, Nov 16, 2017 at 8:21 AM, Barak Korren  wrote:
> On 15 November 2017 at 17:47, John Marks  wrote:
>> Hi,
>> Thanks to everyone who helped with the feature categorization effort on the
>> ovirt feature page.
>>
>> We've made significant progress, and thanks also to Eldan's UX work, the
>> page is looking much better organized.
>>
>> There are a few simple things you can do to help keep the page organized,
>> and to improve it.
>>
>> 1.  Adding a new feature to ovirt.org:
>>
>> Please add your feature to a suitable category:
>> - Gluster (The location in the repository is:
>> /develop/release-management/features/gluster)
>> - Infra   (Same pattern as above)
>> - Integration
>> - Metrics
>> - Network
>> - Node
>> - SLA
>> - Storage
>> - UX
>> - VDSM
>> - Virt
>
> I wonder where did this category division come from, some of these,
> like "VDSM" or "Infra" or "SLA" may not be easy for users to
> understand.
> We need to be careful about using internal development terms in user
> facing documentation.
>
> --
> Barak Korren
> RHV DevOps team , RHCE, RHCi
> Red Hat EMEA
> redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] more aggressive static asset caching in ovirt-engine

[Martin Sivak]

> The downside is you'll have to clear your browser cache more often as you
are developing. (You can use a browser plugin, incognito mode, F12
> disable cache, etc. if you don't want to keep opening the dialog.)

Why don't we use the name-hash.ext format for static files? Recompile
creates a different filename (because hash changed) which is not cached.
That would take care of cache invalidation and it is a common pattern in
the CDN world.

Best regards

Martin Sivak

On Tue, Nov 14, 2017 at 5:49 PM, Greg Sheremeta  wrote:

> Hi,
>
> I made some changes [1][2] to ovirt-engine that make it now more
> aggressively (and correctly) cache all static assets. We were previously
> caching some things, but not all. (Thanks to ykaul for noticing.)
>
> The upside is reduced server hits and faster page loads.
>
> The downside is you'll have to clear your browser cache more often as you
> are developing. (You can use a browser plugin, incognito mode, F12 >
> disable cache, etc. if you don't want to keep opening the dialog.)
>
> [1] https://gerrit.ovirt.org/#/c/83879/
> [2] https://gerrit.ovirt.org/#/c/83871/
>
> Best wishes,
> Greg
>
>
> --
>
> GREG SHEREMETA
>
> SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX
>
> Red Hat NA
>
> <https://www.redhat.com/>
>
> gsher...@redhat.comIRC: gshereme
> <https://red.ht/sig>
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [oVirt 4.2 Localization Question #5] VM SLA Policy command does not change anything.

[Martin Sivak]

The error message can be printed in development or beta versions (if
we break something :). The user should not see it if we do our jobs
properly. So we were not thinking about removing it for now.

Martin

On Fri, Oct 27, 2017 at 12:41 AM, Yuko Katabami  wrote:
> Thank you very much Martin and Andrej for clarification.
> I can understand it clearly now.
> I will apply this interpretation but if user will not get the message,
> perhaps it will be removed at a later stage?
>
> On Thu, Oct 26, 2017 at 11:17 PM, Andrej Krejcir 
> wrote:
>>
>> Yes, the user should not be able to get this error message.
>>
>> The message means that the operation to update the SLA policies does not
>> actually update any policy and has no effect.
>>
>> Andrej
>>
>> On 26 October 2017 at 10:11, Martin Sivak  wrote:
>>>
>>> Hi,
>>>
>>> I think the only way to get this message is to update QoS settings for
>>> a VM and keep all the fields intact. I am not sure the user can
>>> actually achieve that as we have other checks in place too.
>>>
>>> I would treat this as a test suite only message for now.
>>>
>>> Andrej, am I correct?
>>>
>>> Martin Sivak
>>>
>>> On Thu, Oct 26, 2017 at 5:19 AM, Yuko Katabami 
>>> wrote:
>>> > Hello oVirt developers.
>>> > I have another question.
>>> >
>>> > File: AppErrors
>>> >
>>> > Resource ID: VM_SLA_POLICY_UNCHANGED
>>> >
>>> > String: VM SLA Policy command does not change anything.
>>> > Question: Could someone explain to me what this actually means? Does it
>>> > mean
>>> > "the operation (user performed) to update VM's SLA policy did not
>>> > change
>>> > anything"
>>> >
>>> > Thanks in advance.
>>> >
>>> > Yuko
>>> >
>>> > ___
>>> > Devel mailing list
>>> > Devel@ovirt.org
>>> > http://lists.ovirt.org/mailman/listinfo/devel
>>
>>
>
>
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [oVirt 4.2 Localization Question #6] Misplaced double quotes?

[Martin Sivak]

Hi,

I believe the output with quotes is going to be:

Please disable KSM by disabling it for the Cluster: "CLUSTER_NAME".
This can be done by editing the Cluster and disabling the "Enable KSM"
field.

The colon or the quotes can probably be removed. But I am not a
typography expert.

Martin

On Fri, Oct 27, 2017 at 1:24 AM, Yuko Katabami  wrote:
> Hello oVirt developers.
> My next question is as follows;
>
> File: UIConstants
>
> Resource IDs:
> highPerformancePopupRecommendationMsgForKsmPart1
>
> highPerformancePopupRecommendationMsgForKsmPart2
>
> Strings:
> KERNEL SAME PAGE MERGING (KSM):
> Please disable KSM by disabling it for the Cluster: "
>
> ". This can be done by editing the Cluster and disabling the "Enable KSM"
> field.
> Question: There is something wrong with the usage of double quotes in those
> two strings. Could I remove it from the end of the first string, and the
> beginning of the second string (as well as the period)?
>
> Thank you,
>
> Yuko
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [oVirt 4.2 Localization Question #5] VM SLA Policy command does not change anything.

[Martin Sivak]

Hi,

I think the only way to get this message is to update QoS settings for
a VM and keep all the fields intact. I am not sure the user can
actually achieve that as we have other checks in place too.

I would treat this as a test suite only message for now.

Andrej, am I correct?

Martin Sivak

On Thu, Oct 26, 2017 at 5:19 AM, Yuko Katabami  wrote:
> Hello oVirt developers.
> I have another question.
>
> File: AppErrors
>
> Resource ID: VM_SLA_POLICY_UNCHANGED
>
> String: VM SLA Policy command does not change anything.
> Question: Could someone explain to me what this actually means? Does it mean
> "the operation (user performed) to update VM's SLA policy did not change
> anything"
>
> Thanks in advance.
>
> Yuko
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [oVirt 4.2 Localization Question #1] ACTION_TYPE_FAILED_AFFINITY_HOSTS_RULES_COLLISION

[Martin Sivak]

Hi,

the affinity groups allow defining VM to host affinity rules. This
error is shown when the same pair of host and VM has both positive and
negative affinity rule defined. Both host and VM are specified by the
user, but not necessarily directly as there can be a conflict chain
like this: A + B, B + C, A - C (plus is positive affinity, minus is
negative).

Best regards

Martin Sivak

On Wed, Oct 25, 2017 at 5:34 PM, Greg Sheremeta  wrote:
> Phillip might know
>
> On Wed, Oct 25, 2017 at 11:25 AM, Yuko Katabami  wrote:
>>
>> Re-posting.
>> Could anyone help us with this?
>>
>> On Mon, Oct 23, 2017 at 9:31 AM, Yuko Katabami 
>> wrote:
>>>
>>> Hello oVirt developers.
>>> I have started translating Admin Portal strings for 4.2 from today and
>>> here is my first question.
>>>
>>>
>>> File: AppErrors
>>> Resource ID: ACTION_TYPE_FAILED_AFFINITY_HOSTS_RULES_COLLISION
>>>
>>> String: The following affinity groups, containing the indicated hosts and
>>> VMs, have VM to host conflicts between positive and negative enforcing
>>> affinity groups.
>>>
>>> Question: Does "the indicated hosts and VMs" mean the hosts and VMs
>>> specified by user? Could you please also explain what "VM to host conflicts"
>>> mean?
>>>
>>>
>>> Kind regards,
>>>
>>>
>>> Yuko
>>
>>
>>
>>
>>
>>
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>
>
>
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Unable to add host in oVirt 4.2 (clean install)

[Martin Sivak]

Hi,

I ran engine OST this afternoon and it passed. But I also saw Andrej's
tracebacks and Jenny reported the same thing yesterday. No idea what is
wrong, but both were related to hosted engine setup flow.

Martin

On Wed, Oct 4, 2017 at 11:56 AM, Marek Libra  wrote:

> Since Andrej ran in similar issue today, I'm posting for others:
>
> When installing oVirt 4.2 first alpha release from scratch on fresh Centos
> 7 minimal, adding host failed. Unfortunately, I don't have log messages
> anymore, but I remember last errors were misleadingly related to ovn (no
> matter the ovn was not configured on the engine).
>
> The issue was resolved by manual installation of python-netaddr package on
> the host. Subsequently, adding the host in webadmin passed.
>
> What package should require the python-netaddr? ovirt-provider-ovn-driver?
>
> I hope it helps,
> Marek
>
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Unable to run "make check" on master with an updated Centos7

[Martin Sivak]

Well.. isn't tox using virtualenv by any chance? The Python path in
the traceback does not look like the standard one

Martin

On Mon, Sep 25, 2017 at 12:48 PM, Dan Kenigsberg  wrote:
> nope.
>
> $ rpm -qa |grep -- -six
> python2-six-1.10.0-9.fc26.noarch
> python3-six-1.10.0-9.fc26.noarch
>
> On Mon, Sep 25, 2017 at 1:46 PM, Nir Soffer  wrote:
>> Missing six in your system?
>>
>>
>> On יום ב׳, 25 בספט׳ 2017, 13:28 Dan Kenigsberg  wrote:
>>>
>>> Nir,
>>>
>>> I have not run `make check` locally for a while. It fails here, too,
>>> but completely differently:
>>>
>>> https://paste.fedoraproject.org/paste/jF-TlI4Dpe7d~2ZboXZ89Q
>>>
>>> Any idea where the following is coming from?
>>>
>>> ImportError while importing test module
>>> '/home/danken/redhat/vdsm.git/tests/storage/asyncevent_test.py'.
>>> Hint: make sure your test modules/packages have valid Python names.
>>> Traceback:
>>> ../.tox/storage-py35/lib/python3.5/site-packages/_pytest/python.py:408:
>>> in _importtestmodule
>>> mod = self.fspath.pyimport(ensuresyspath=importmode)
>>> ../.tox/storage-py35/lib/python3.5/site-packages/py/_path/local.py:662:
>>> in pyimport
>>> __import__(modname)
>>>
>>> ../.tox/storage-py35/lib/python3.5/site-packages/_pytest/assertion/rewrite.py:215:
>>> in load_module
>>> py.builtin.exec_(co, mod.__dict__)
>>> storage/asyncevent_test.py:33: in 
>>> from testlib import VdsmTestCase
>>> testlib.py:35: in 
>>> from six.moves import configparser
>>> E   ImportError: No module named 'six'
>>>
>>> On Sun, Sep 24, 2017 at 11:00 PM, Nir Soffer  wrote:
>>> > On Sun, Sep 24, 2017 at 5:37 PM Edward Haas  wrote:
>>> >>
>>> >> Hello,
>>> >>
>>> >> After updating my Centos7 VM, the unit tests are failing on
>>> >> check_imports.
>>> >> Some kind of recursion.
>>> >>
>>> >> https://paste.fedoraproject.org/paste/lcjYudT50AJDLJnw9SH3vw
>>> >>
>>> >> I have not seen this on CI.
>>> >> Any ideas?
>>> >
>>> >
>>> > You have old __cache__ directory or something similar.
>>> >
>>> > git clean -dxf; ./autogen.sh --system && make
>>> >
>>> > will probably fix this.
>>> >
>>> > Also filing a pytest bug would be a good idea.
>>> >
>>> >>
>>> >>
>>> >> Thanks,
>>> >> Edy.
>>> >>
>>> >> ___
>>> >> Devel mailing list
>>> >> Devel@ovirt.org
>>> >> http://lists.ovirt.org/mailman/listinfo/devel
>>> >
>>> >
>>> > ___
>>> > Devel mailing list
>>> > Devel@ovirt.org
>>> > http://lists.ovirt.org/mailman/listinfo/devel
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Code owners configuration for GitHub projects

[Martin Sivak]

>> Is actually prefer if there was a way to keep this out of the code, or if
>> they'd adopted Kubernetses format for this instead of inventing thier own.
>
> It is the same format.

Ah, it is the same format some kubernetes projects use (like
https://github.com/kubernetes/test-infra/blob/master/CODEOWNERS). The
main repo uses their own OWNERS which is slightly different.

Martin

On Fri, Sep 8, 2017 at 2:15 PM, Martin Sivak  wrote:
>> Not sure what are they using to identify people, are these GitHub usernames?
>> This feels a bit like lock-in.
>
> @usernames or emails
>
>> It might be better to enforce using email addresse in the file.
>
> Should work according to the article.
>
>> Is actually prefer if there was a way to keep this out of the code, or if
>> they'd adopted Kubernetses format for this instead of inventing thier own.
>
> It is the same format.
>
>
> Martin
>
> On Fri, Sep 8, 2017 at 1:39 PM, Barak Korren  wrote:
>>
>>
>> בתאריך 8 בספט׳ 2017 14:18,‏ "Martin Sivak"  כתב:
>>
>> Hi,
>>
>> I recently noticed GitHub enabled a feature that allows specifying
>> code owners for different pieces of code:
>>
>> https://github.com/blog/2392-introducing-code-owners
>>
>> It should supposedly automatically
>>
>> add the proper reviewers to patches.
>>
>>
>> Not sure what are they using to identify people, are these GitHub usernames?
>> This feels a bit like lock-in.
>>
>> It might be better to enforce using email addresse in the file.
>>
>> Is actually prefer if there was a way to keep this out of the code, or if
>> they'd adopted Kubernetses format for this instead of inventing thier own.
>>
>>
>> We have similar feature enabled in Gerrit and it might make sense for
>> our GitHub specific projects to do the same.
>>
>>
>> Sure, why not. Its been very useful in Gerrit.
>>
>> (It might even make sense
>> to follow the same format in Gerrit)
>>
>>
>> If soneone would contribute a parser to the GitHub format (which is to say,
>> something that would scan a commit and yield a list of addresses). We could
>> make it work with a hook or a Jenkins job.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Code owners configuration for GitHub projects

[Martin Sivak]

> Not sure what are they using to identify people, are these GitHub usernames?
> This feels a bit like lock-in.

@usernames or emails

> It might be better to enforce using email addresse in the file.

Should work according to the article.

> Is actually prefer if there was a way to keep this out of the code, or if
> they'd adopted Kubernetses format for this instead of inventing thier own.

It is the same format.


Martin

On Fri, Sep 8, 2017 at 1:39 PM, Barak Korren  wrote:
>
>
> בתאריך 8 בספט׳ 2017 14:18,‏ "Martin Sivak"  כתב:
>
> Hi,
>
> I recently noticed GitHub enabled a feature that allows specifying
> code owners for different pieces of code:
>
> https://github.com/blog/2392-introducing-code-owners
>
> It should supposedly automatically
>
> add the proper reviewers to patches.
>
>
> Not sure what are they using to identify people, are these GitHub usernames?
> This feels a bit like lock-in.
>
> It might be better to enforce using email addresse in the file.
>
> Is actually prefer if there was a way to keep this out of the code, or if
> they'd adopted Kubernetses format for this instead of inventing thier own.
>
>
> We have similar feature enabled in Gerrit and it might make sense for
> our GitHub specific projects to do the same.
>
>
> Sure, why not. Its been very useful in Gerrit.
>
> (It might even make sense
> to follow the same format in Gerrit)
>
>
> If soneone would contribute a parser to the GitHub format (which is to say,
> something that would scan a commit and yield a list of addresses). We could
> make it work with a hook or a Jenkins job.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] Code owners configuration for GitHub projects

[Martin Sivak]

Hi,

I recently noticed GitHub enabled a feature that allows specifying
code owners for different pieces of code:

https://github.com/blog/2392-introducing-code-owners

It should supposedly automatically add the proper reviewers to patches.

We have similar feature enabled in Gerrit and it might make sense for
our GitHub specific projects to do the same. (It might even make sense
to follow the same format in Gerrit)

Martin Sivak
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Slack channel

[Martin Sivak]

> Gitter also seems to be good for that, much more than slack for just being
> available, but Ive been on IRC and have asked, seen others ask, and havent
> really seen much back and forth, theyre mostly all dead channels (slack
> included)

IRC is not too busy, but when it is, it is mostly during European
working hours.. not much activity from the devs during US working
hours as we mostly sit in EMEA. That might not be an obvious
limitation and it might give bad impression too.

Martin

On Tue, Sep 5, 2017 at 8:22 PM, Marc Young <3vilpeng...@gmail.com> wrote:
> FWIW I was mostly coming in from the community perspective.
> While I'm sure most can do proxies/vpn's/etc Im more curious about lowering
> the barrier from people like me writing 3rd party tools that will have quick
> project related questions such as:
>
>  * is this a bug
>  * where do i put in a ticket
>  * is this code wrong
>
> It would be nice to just be able to load up slack (the new unofficial
> standard) and be able to chat quickly with others without a ton of barriers.
> As far as for the full project there are a ton of other issues at play, but
> theres tons to gain from being able to meet/greet/etc with devs on the
> project.
>
> Gitter also seems to be good for that, much more than slack for just being
> available, but Ive been on IRC and have asked, seen others ask, and havent
> really seen much back and forth, theyre mostly all dead channels (slack
> included)
>
> On Tue, Sep 5, 2017 at 10:14 AM, Martin Sivak  wrote:
>>
>> > "Not everyone can/will do it." It's a pain.
>>
>> Why everyone? Someone at oVirt can prepare that for others and just
>> keep it running. The same we would have to do with Rocket for example.
>> The difference is that people can use their own client if they want,
>> that is not an option with Slack. Free tier Slack will become unusable
>> once more people join, the persistent history limit will be depleted
>> very quickly.
>>
>> > How does a web-based client with archiving work with a private IRC
>> > server
>> > behind openvpn?
>>
>> The same as Slack. It does not. But I am not talking about local web
>> based client. I am talking about public web based gateway that uses
>> irc/jabber internally.
>>
>> > What if the archiver fails and you miss important messages? How do you
>> > know
>> > the archiver hasn't failed?
>>
>> How do you know that with Slack? The guarantees are exactly the same..
>> none. Real time messaging is not meant for important messages. We have
>> email (well...) and bugzilla for that. You can get guarantees for
>> money I guess, but not in any free service.
>>
>> > Does it integrate with other services that people use, like trello and
>> > jira?
>> > (Can edit cards / bugs right in the chat)
>>
>> I was able to google couple of different projects, there definitely is
>> a JIRA irc notification plugin in use (#optaplanner-dev@freenode uses
>> it). But some setup is probably required..
>>
>> > Does it let you post images in the chat, where everyone (no matter their
>> > client) can see them?
>>
>> This is the biggest pain of all alternative solutions. You need
>> storage.. Jabber is better than IRC in this sense, firewall traversal
>> for direct data transfer is not one of irc's strongpoints.
>>
>> > I just want to work. I don't want to spend (waste, imo) time on rolling
>> > my
>> > own chat technology when I can connect to a website and get on with my
>> > day.
>>
>> And are you willing to have multiple different communication tools
>> open just because you are part of multiple communities? I already need
>> email (more than one), bugzilla, Trello, IRC and Slack (my Jabber
>> community kind of died..) and it is becoming too much sometimes..
>>
>> Slack at least offers limited gateway to both IRC and Jabber:
>>
>> https://get.slack.help/hc/en-us/articles/201727913-Connect-to-Slack-over-IRC-and-XMPP
>>
>> We can drop IRC, but we need adequate replacement for people who are
>> not purely web based and work on multiple different projects. I
>> currently have 15 open irc channels and I will prefer any
>> multi-protocol or federated solution over closed one any day.
>>
>> Martin
>>
>>
>> On Tue, Sep 5, 2017 at 4:38 PM, Greg Sheremeta 
>> wrote:
>> >
>> > On Mon, Sep 4, 2017 at 4:54 AM, Martin Sivak  wrote:
>> >>
>> >> > Right, still it is an IRC technology, and every user must set it up
&g

Re: [ovirt-devel] Slack channel

[Martin Sivak]

> "Not everyone can/will do it." It's a pain.

Why everyone? Someone at oVirt can prepare that for others and just
keep it running. The same we would have to do with Rocket for example.
The difference is that people can use their own client if they want,
that is not an option with Slack. Free tier Slack will become unusable
once more people join, the persistent history limit will be depleted
very quickly.

> How does a web-based client with archiving work with a private IRC server
> behind openvpn?

The same as Slack. It does not. But I am not talking about local web
based client. I am talking about public web based gateway that uses
irc/jabber internally.

> What if the archiver fails and you miss important messages? How do you know
> the archiver hasn't failed?

How do you know that with Slack? The guarantees are exactly the same..
none. Real time messaging is not meant for important messages. We have
email (well...) and bugzilla for that. You can get guarantees for
money I guess, but not in any free service.

> Does it integrate with other services that people use, like trello and jira?
> (Can edit cards / bugs right in the chat)

I was able to google couple of different projects, there definitely is
a JIRA irc notification plugin in use (#optaplanner-dev@freenode uses
it). But some setup is probably required..

> Does it let you post images in the chat, where everyone (no matter their
> client) can see them?

This is the biggest pain of all alternative solutions. You need
storage.. Jabber is better than IRC in this sense, firewall traversal
for direct data transfer is not one of irc's strongpoints.

> I just want to work. I don't want to spend (waste, imo) time on rolling my
> own chat technology when I can connect to a website and get on with my day.

And are you willing to have multiple different communication tools
open just because you are part of multiple communities? I already need
email (more than one), bugzilla, Trello, IRC and Slack (my Jabber
community kind of died..) and it is becoming too much sometimes..

Slack at least offers limited gateway to both IRC and Jabber:
https://get.slack.help/hc/en-us/articles/201727913-Connect-to-Slack-over-IRC-and-XMPP

We can drop IRC, but we need adequate replacement for people who are
not purely web based and work on multiple different projects. I
currently have 15 open irc channels and I will prefer any
multi-protocol or federated solution over closed one any day.

Martin


On Tue, Sep 5, 2017 at 4:38 PM, Greg Sheremeta  wrote:
>
> On Mon, Sep 4, 2017 at 4:54 AM, Martin Sivak  wrote:
>>
>> > Right, still it is an IRC technology, and every user must set it up in
>> > order
>> > to keep their presence (which you get out-of-the-box from
>> > above-mentioned).
>> > Not everyone can/will do it.
>>
>> Meaning it is federated, you can connect to any server you want and
>> the protocol is open and dead simple + there are hundreds of clients.
>> Including web based.. in case you did not look. The same applies to
>> archiver services for IRC.
>>
>> So just setup an archive, publish the irc information + a link to web
>> based client and you get the best of both worlds.
>
>
> "Not everyone can/will do it." It's a pain.
>
> How does a web-based client with archiving work with a private IRC server
> behind openvpn?
>
> What if the archiver fails and you miss important messages? How do you know
> the archiver hasn't failed?
>
> Does it let you post images in the chat, where everyone (no matter their
> client) can see them?
>
> Does it integrate with other services that people use, like trello and jira?
> (Can edit cards / bugs right in the chat)
>
> I just want to work. I don't want to spend (waste, imo) time on rolling my
> own chat technology when I can connect to a website and get on with my day.
>
> Just some random thoughts I had. I probably said the same stuff last time
> this came up.
>
> Best wishes,
> Greg
>
>>
>>
>> The only alternative that got close was Jabber (IM, groups and
>> supports file transfers), too bad the adoption there is stagnating.
>>
>> Martin
>>
>>
>>
>> On Mon, Sep 4, 2017 at 10:25 AM, Roy Golan  wrote:
>> >
>> >
>> > On Mon, 4 Sep 2017 at 11:14 Artyom Lukianov  wrote:
>> >>
>> >> Like an alternative to Slack or gitter, you can run ZNC server on some
>> >> VM,
>> >> that will save all messages for you.
>> >>
>> > Right, still it is an IRC technology, and every user must set it up in
>> > order
>> > to keep their presence (which you get out-of-the-box from
>> > above-mentioned).
>> >

Re: [ovirt-devel] Feature pages

[Martin Sivak]

> You can search by category (which we need to improve, remove the
> unclassified, etc.)

The side panel was not loaded when I looked at it. It looks a bit
better with it, but the category information is missing from the
version specific feature list..

But what I really want is to enable discussion about new or updated
features and it is not easy to see what changes are proposed or what
was changed recently.

Martin

On Tue, Sep 5, 2017 at 2:21 PM, Yaniv Kaul  wrote:
>
>
> On Tue, Sep 5, 2017 at 3:09 PM, Martin Sivak  wrote:
>>
>> > https://www.ovirt.org/develop/release-management/features/ contains list
>> > of
>> > features grouped by versions.
>>
>> Except there is no "All versions" page and I can't combine it with the
>> other criteria. Which means I need to know the version first when I am
>> searching for a feature.
>
>
> You can search by category (which we need to improve, remove the
> unclassified, etc.)
> Y.
>
>>
>>
>> Martin
>>
>> On Tue, Sep 5, 2017 at 1:58 PM, Jakub Niedermertl 
>> wrote:
>> > Hi,
>> >
>> > https://www.ovirt.org/develop/release-management/features/ contains list
>> > of
>> > features grouped by versions.
>> >
>> > Jakub
>> >
>> > On Tue, Sep 5, 2017 at 1:47 PM, Martin Sivak  wrote:
>> >>
>> >> Hi Eldan,
>> >>
>> >> Doron tells me you did play with the current website in the past, can
>> >> you share your opinion about my proposal please? I am really after a
>> >> single page list that would allow listing features according to given
>> >> criteria (including the pull requests links if at all possible).
>> >>
>> >> Martin
>> >>
>> >> On Tue, Sep 5, 2017 at 1:02 PM, Martin Sivak  wrote:
>> >> > Hi,
>> >> >
>> >> > Phillip had a nice idea, can we get a page that would list all
>> >> > Feature
>> >> > pages and allowed sorting / filtering by release they are in and by
>> >> > the time they where last updated? And of course alphabetically.
>> >> >
>> >> > We might have all the information necessary and I believe it might be
>> >> > nicer than the current deep links. We can then track when a feature
>> >> > appeared and disappeared and hide it from the list according to the
>> >> > selected filters.
>> >> >
>> >> > This would allow users to see what features were available in given
>> >> > release, when a feature appeared or which pages are active and need
>> >> > reviews.. (can we link this to the pull requests too?)
>> >> >
>> >> > -
>> >> > Sort by: alphabet | update date
>> >> > Filter by release: all | 3.3 | 3.4 | 3.5 | 3.6 | 
>> >> > Filter by team: SLA | infra | 
>> >> >
>> >> > 1. Alpha [3.5+]
>> >> > 2. Beta [3.3+] - PR1256 pending
>> >> > 3. Gamma [4.2+]
>> >> > 4. Delta [3.5 - 4.1]
>> >> >
>> >> > 
>> >> >
>> >> > What do you think?
>> >> >
>> >> > --
>> >> > Martin Sivak
>> >> > SLA / oVirt
>> >> ___
>> >> Devel mailing list
>> >> Devel@ovirt.org
>> >> http://lists.ovirt.org/mailman/listinfo/devel
>> >
>> >
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Feature pages

[Martin Sivak]

> https://www.ovirt.org/develop/release-management/features/ contains list of
> features grouped by versions.

Except there is no "All versions" page and I can't combine it with the
other criteria. Which means I need to know the version first when I am
searching for a feature.

Martin

On Tue, Sep 5, 2017 at 1:58 PM, Jakub Niedermertl  wrote:
> Hi,
>
> https://www.ovirt.org/develop/release-management/features/ contains list of
> features grouped by versions.
>
> Jakub
>
> On Tue, Sep 5, 2017 at 1:47 PM, Martin Sivak  wrote:
>>
>> Hi Eldan,
>>
>> Doron tells me you did play with the current website in the past, can
>> you share your opinion about my proposal please? I am really after a
>> single page list that would allow listing features according to given
>> criteria (including the pull requests links if at all possible).
>>
>> Martin
>>
>> On Tue, Sep 5, 2017 at 1:02 PM, Martin Sivak  wrote:
>> > Hi,
>> >
>> > Phillip had a nice idea, can we get a page that would list all Feature
>> > pages and allowed sorting / filtering by release they are in and by
>> > the time they where last updated? And of course alphabetically.
>> >
>> > We might have all the information necessary and I believe it might be
>> > nicer than the current deep links. We can then track when a feature
>> > appeared and disappeared and hide it from the list according to the
>> > selected filters.
>> >
>> > This would allow users to see what features were available in given
>> > release, when a feature appeared or which pages are active and need
>> > reviews.. (can we link this to the pull requests too?)
>> >
>> > -
>> > Sort by: alphabet | update date
>> > Filter by release: all | 3.3 | 3.4 | 3.5 | 3.6 | 
>> > Filter by team: SLA | infra | 
>> >
>> > 1. Alpha [3.5+]
>> > 2. Beta [3.3+] - PR1256 pending
>> > 3. Gamma [4.2+]
>> > 4. Delta [3.5 - 4.1]
>> >
>> > 
>> >
>> > What do you think?
>> >
>> > --
>> > Martin Sivak
>> > SLA / oVirt
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Feature pages

[Martin Sivak]

Hi Eldan,

Doron tells me you did play with the current website in the past, can
you share your opinion about my proposal please? I am really after a
single page list that would allow listing features according to given
criteria (including the pull requests links if at all possible).

Martin

On Tue, Sep 5, 2017 at 1:02 PM, Martin Sivak  wrote:
> Hi,
>
> Phillip had a nice idea, can we get a page that would list all Feature
> pages and allowed sorting / filtering by release they are in and by
> the time they where last updated? And of course alphabetically.
>
> We might have all the information necessary and I believe it might be
> nicer than the current deep links. We can then track when a feature
> appeared and disappeared and hide it from the list according to the
> selected filters.
>
> This would allow users to see what features were available in given
> release, when a feature appeared or which pages are active and need
> reviews.. (can we link this to the pull requests too?)
>
> -
> Sort by: alphabet | update date
> Filter by release: all | 3.3 | 3.4 | 3.5 | 3.6 | 
> Filter by team: SLA | infra | 
>
> 1. Alpha [3.5+]
> 2. Beta [3.3+] - PR1256 pending
> 3. Gamma [4.2+]
> 4. Delta [3.5 - 4.1]
>
> --------
>
> What do you think?
>
> --
> Martin Sivak
> SLA / oVirt
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] Feature pages

[Martin Sivak]

Hi,

Phillip had a nice idea, can we get a page that would list all Feature
pages and allowed sorting / filtering by release they are in and by
the time they where last updated? And of course alphabetically.

We might have all the information necessary and I believe it might be
nicer than the current deep links. We can then track when a feature
appeared and disappeared and hide it from the list according to the
selected filters.

This would allow users to see what features were available in given
release, when a feature appeared or which pages are active and need
reviews.. (can we link this to the pull requests too?)

-
Sort by: alphabet | update date
Filter by release: all | 3.3 | 3.4 | 3.5 | 3.6 | 
Filter by team: SLA | infra | 

1. Alpha [3.5+]
2. Beta [3.3+] - PR1256 pending
3. Gamma [4.2+]
4. Delta [3.5 - 4.1]



What do you think?

--
Martin Sivak
SLA / oVirt
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Slack channel

[Martin Sivak]

> Right, still it is an IRC technology, and every user must set it up in order
> to keep their presence (which you get out-of-the-box from above-mentioned).
> Not everyone can/will do it.

Meaning it is federated, you can connect to any server you want and
the protocol is open and dead simple + there are hundreds of clients.
Including web based.. in case you did not look. The same applies to
archiver services for IRC.

So just setup an archive, publish the irc information + a link to web
based client and you get the best of both worlds.

The only alternative that got close was Jabber (IM, groups and
supports file transfers), too bad the adoption there is stagnating.

Martin


On Mon, Sep 4, 2017 at 10:25 AM, Roy Golan  wrote:
>
>
> On Mon, 4 Sep 2017 at 11:14 Artyom Lukianov  wrote:
>>
>> Like an alternative to Slack or gitter, you can run ZNC server on some VM,
>> that will save all messages for you.
>>
> Right, still it is an IRC technology, and every user must set it up in order
> to keep their presence (which you get out-of-the-box from above-mentioned).
> Not everyone can/will do it.
>
>>
>> On Thu, Aug 24, 2017 at 5:31 AM, Marc Young <3vilpeng...@gmail.com> wrote:
>>>
>>> Is there hope for slack over IRC?
>>>
>>> The problem with IRC is all the connect/disconnect chatter (and offline
>>> being a black hole)
>>>
>>> ___
>>> Devel mailing list
>>> Devel@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>>
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] vdsm vds.dispatcher

[Martin Sivak]

One more thing:

MOM's getStatistics is actually called by VDSM stats reporting code,
so my guess here is that someone queries VDSM for stats pretty hard,
VDSM then asks MOM for details.

Martin

On Thu, Aug 31, 2017 at 4:14 PM, Martin Sivak  wrote:
> Hi,
>
>> 2017-08-27 23:15:41,199 - mom.RPCServer - INFO - ping()
>> 2017-08-27 23:15:41,200 - mom.RPCServer - INFO - getStatistics()
>> 2017-08-27 23:15:43,946 - mom.RPCServer - INFO - ping()
>> 2017-08-27 23:15:43,947 - mom.RPCServer - INFO - getStatistics()
>
> These are logs from mom's RPC server, someone is calling MOM way too
> often. Well about 25 times per minute if my math is right.
>
> The only client I know about is actually VDSM.
>
> Martin
>
>
> On Mon, Aug 28, 2017 at 9:17 AM, Gary Pedretty  wrote:
>> Be glad to provide logs to help diagnose this.  I see nothing unusual in the
>> vdsm.log
>>
>> mom.log shows the following almost as frequently as the messages log entries
>>
>> 2017-08-27 23:15:41,199 - mom.RPCServer - INFO - ping()
>> 2017-08-27 23:15:41,200 - mom.RPCServer - INFO - getStatistics()
>> 2017-08-27 23:15:43,946 - mom.RPCServer - INFO - ping()
>> 2017-08-27 23:15:43,947 - mom.RPCServer - INFO - getStatistics()
>>
>>
>> 
>> Gary Pedrettyg...@ravnalaska.net
>> Systems Manager  www.flyravn.com
>> Ravn Alaska   /\907-450-7251
>> 5245 Airport Industrial Road /  \/\ 907-450-7238 fax
>> Fairbanks, Alaska  99709/\  /\ \ Second greatest commandment
>> Serving All of Alaska  /  \/  /\  \ \/\   “Love your neighbor as
>> Green, green as far as the eyes can see yourself” Matt 22:39
>> 
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Aug 27, 2017, at 10:51 PM, Piotr Kliczewski 
>> wrote:
>>
>> This change was backported to 4.1 and you can find it in 4.19.7+.
>>
>> This log entry appears in the logs when a client disconnects. 3
>> seconds is much too often and the only client could do it is mom
>> (adding Martin to confirm).
>>
>> On Mon, Aug 28, 2017 at 12:11 AM, Gary Pedretty  wrote:
>>
>> vdsm-4.18.21-1.el7.centos.x86_64
>>
>> the entries are about every 3 seconds on all hosts
>>
>>
>> 
>> Gary Pedrettyg...@ravnalaska.net
>> Systems Manager  www.flyravn.com
>> Ravn Alaska   /\907-450-7251
>> 5245 Airport Industrial Road /  \/\ 907-450-7238 fax
>> Fairbanks, Alaska  99709/\  /\ \ Second greatest commandment
>> Serving All of Alaska  /  \/  /\  \ \/\   “Love your neighbor as
>> Green, green as far as the eyes can see yourself” Matt 22:39
>> 
>>
>>
>>
>>
>> On Aug 27, 2017, at 12:46 PM, Piotr Kliczewski 
>> wrote:
>>
>> Hello,
>>
>> This is not an error and it was modified to reduce logging level.
>> Which vdsm version are you using?
>>
>> Thanks,
>> Piotr
>>
>>
>>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] vdsm vds.dispatcher

[Martin Sivak]

Hi,

> 2017-08-27 23:15:41,199 - mom.RPCServer - INFO - ping()
> 2017-08-27 23:15:41,200 - mom.RPCServer - INFO - getStatistics()
> 2017-08-27 23:15:43,946 - mom.RPCServer - INFO - ping()
> 2017-08-27 23:15:43,947 - mom.RPCServer - INFO - getStatistics()

These are logs from mom's RPC server, someone is calling MOM way too
often. Well about 25 times per minute if my math is right.

The only client I know about is actually VDSM.

Martin


On Mon, Aug 28, 2017 at 9:17 AM, Gary Pedretty  wrote:
> Be glad to provide logs to help diagnose this.  I see nothing unusual in the
> vdsm.log
>
> mom.log shows the following almost as frequently as the messages log entries
>
> 2017-08-27 23:15:41,199 - mom.RPCServer - INFO - ping()
> 2017-08-27 23:15:41,200 - mom.RPCServer - INFO - getStatistics()
> 2017-08-27 23:15:43,946 - mom.RPCServer - INFO - ping()
> 2017-08-27 23:15:43,947 - mom.RPCServer - INFO - getStatistics()
>
>
> 
> Gary Pedrettyg...@ravnalaska.net
> Systems Manager  www.flyravn.com
> Ravn Alaska   /\907-450-7251
> 5245 Airport Industrial Road /  \/\ 907-450-7238 fax
> Fairbanks, Alaska  99709/\  /\ \ Second greatest commandment
> Serving All of Alaska  /  \/  /\  \ \/\   “Love your neighbor as
> Green, green as far as the eyes can see yourself” Matt 22:39
> 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Aug 27, 2017, at 10:51 PM, Piotr Kliczewski 
> wrote:
>
> This change was backported to 4.1 and you can find it in 4.19.7+.
>
> This log entry appears in the logs when a client disconnects. 3
> seconds is much too often and the only client could do it is mom
> (adding Martin to confirm).
>
> On Mon, Aug 28, 2017 at 12:11 AM, Gary Pedretty  wrote:
>
> vdsm-4.18.21-1.el7.centos.x86_64
>
> the entries are about every 3 seconds on all hosts
>
>
> 
> Gary Pedrettyg...@ravnalaska.net
> Systems Manager  www.flyravn.com
> Ravn Alaska   /\907-450-7251
> 5245 Airport Industrial Road /  \/\ 907-450-7238 fax
> Fairbanks, Alaska  99709/\  /\ \ Second greatest commandment
> Serving All of Alaska  /  \/  /\  \ \/\   “Love your neighbor as
> Green, green as far as the eyes can see yourself” Matt 22:39
> 
>
>
>
>
> On Aug 27, 2017, at 12:46 PM, Piotr Kliczewski 
> wrote:
>
> Hello,
>
> This is not an error and it was modified to reduce logging level.
> Which vdsm version are you using?
>
> Thanks,
> Piotr
>
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Please note: ovirt-hosted-engine-ha builds are failing

[Martin Sivak]

Hi Barak,

maybe you should stop setting CI+1 before that is fixed?

Martin

On Thu, Aug 31, 2017 at 8:36 AM, Barak Korren  wrote:
> Hi,
>
> Builds of ovirt-hosted-engine-ha had been failing for the last 3 merged 
> patches.
>
> This is currently not being reported on gerrit because of a known
> issue we are working to fix [1].
>
> The 1st patch where builds started failing is:
> https://gerrit.ovirt.org/#/c/81224/
>
> Failing build jobs for this patch are the following:
> - 
> http://jenkins.ovirt.org/job/ovirt-hosted-engine-ha_master_build-artifacts-el7-x86_64/75/
> - 
> http://jenkins.ovirt.org/job/ovirt-hosted-engine-ha_master_build-artifacts-fc25-x86_64/42/
>
> Build logs for failing jobs are respectively at these locations:
> - 
> http://jenkins.ovirt.org/job/ovirt-hosted-engine-ha_master_build-artifacts-el7-x86_64/75/artifact/exported-artifacts/mock_logs/mocker-epel-7-x86_64.el7.build-artifacts.sh/build-artifacts.sh.log
> - 
> http://jenkins.ovirt.org/job/ovirt-hosted-engine-ha_master_build-artifacts-fc25-x86_64/42/artifact/exported-artifacts/mock_logs/mocker-fedora-25-x86_64.fc25.build-artifacts.sh/build-artifacts.sh.log
>
>
> [1]: https://ovirt-jira.atlassian.net/browse/OVIRT-1502
>
>
> --
> Barak Korren
> RHV DevOps team , RHCE, RHCi
> Red Hat EMEA
> redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [proposal] deprecate VDSM ping in favor of ping2 and confirmConnectivity

[Martin Sivak]

>> A ping that has no side effects and a "watchdog" mechanism to confirm
>> connectivity.
>
> This sounds as exactly the right solution right now.

Just to clarify: Removing the undocumented side effects from ping. Not
introducing ping2.

Martin

On Tue, Aug 8, 2017 at 10:47 AM, Martin Sivak  wrote:
>> The proposed solution is focused on making sure a command does one thing and
>> not two:
>> A ping that has no side effects and a "watchdog" mechanism to confirm
>> connectivity.
>
> This sounds as exactly the right solution right now.
>
>>>> Still someone could call conirmConnectivity, no?
>
> We do not protect any other endpoints that can cause the host to go
> wild (storage or even setupNetworks). I agree with Edward it is the
> responsibility of the caller to do the right thing. You need to be
> root or have the certificate to talk to VDSM anyway.
>
> Martin
>
> On Tue, Aug 8, 2017 at 8:24 AM, Edward Haas  wrote:
>>
>>
>> On Mon, Aug 7, 2017 at 11:06 PM, Nir Soffer  wrote:
>>>
>>> On Mon, Aug 7, 2017 at 5:28 PM Roy Golan  wrote:
>>>>
>>>> Still someone could call conirmConnectivity, no? so the state isn't
>>>> guarded from localhost tinkering anyhow. If you really need a solution you
>>>> can acuire a token for this operation by setupNetworks, and confirm
>>>> connectivity with this token passed back.
>>>>
>>>> I'm not sure about the severity of the problem here, I'll let other
>>>> reply, but I'm against this kind of solution.
>>>>
>>>>
>>>>
>>>> On Mon, 7 Aug 2017 at 15:32 Petr Horacek  wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> current VDSM ping verb has a problem - it confirms network
>>>>> connectivity as a side-effect. After Engine calls setupNetwork it
>>>>> pings VDSM host to confirm that external network connectivity is not
>>>>> broken. This prohibits other users to call ping from localhost since
>>>>> it would confirm connectivity even though networking could be broken.
>>>
>>>
>>> Vdsm can save the client ip setting up the network. Getting a ping from
>>> this
>>> client can confirm that the connectivity was restored. pings from other
>>> hosts
>>> can be ignored.
>>>
>>> The client address is available in a thread local variable
>>> (context.client_host)
>>> during all api calls. see vdsm.common.api.context_string() for example
>>> usage.
>>>
>>> This infrastructure is available in 4.1.
>>
>>
>> The proposed solution is focused on making sure a command does one thing and
>> not two:
>> A ping that has no side effects and a "watchdog" mechanism to confirm
>> connectivity.
>>
>> Does it make sense to confirm connectivity from localhost? In many cases it
>> probably does not,
>> but there may be cases where it does make sense... it is not the
>> functionality to determine what
>> makes sense or not, it is the usage of it who has the responsibility to use
>> it correctly.
>>
>>>
>>> Nir
>>>
>>>>>
>>>>>
>>>>> In order to fix this problem ping should be split to ping2 (which just
>>>>> returns Success with no side-effect) and confirmConnectivity. Change
>>>>> on VDSM side was introduced in [1], we still need to expose new verbs
>>>>> in Engine.
>>>>>
>>>>> Regards,
>>>>> Petr
>>>>>
>>>>> [1] https://gerrit.ovirt.org/#/c/80119/
>>>>> ___
>>>>> Devel mailing list
>>>>> Devel@ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>>
>>>> ___
>>>> Devel mailing list
>>>> Devel@ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>>
>>> ___
>>> Devel mailing list
>>> Devel@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>>
>>
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [proposal] deprecate VDSM ping in favor of ping2 and confirmConnectivity

[Martin Sivak]

But it isn't as I said already. And so we are keeping the ping code
and that is why vdsm needs to solve the setupNetworks/ping bug.

Martin

On Tue, Aug 8, 2017 at 2:50 PM, Roy Golan  wrote:
> This is for 4.1 https://gerrit.ovirt.org/#/c/78916/ , track that, it should
> be in.
>
> On Tue, 8 Aug 2017 at 15:10 Martin Sivak  wrote:
>>
>> What stomp heartbeat? There is no such thing in the Python json rpc
>> client.
>>
>> Martin
>>
>> On Tue, Aug 8, 2017 at 1:04 PM, Roy Golan  wrote:
>> > Why isn't the stomp heartbeat enough?
>> >
>> > On Tue, 8 Aug 2017 at 13:45 Martin Sivak  wrote:
>> >>
>> >> MOM and hosted engine use the ping verb to verify the connection is
>> >> still OK. The RPC client did not have any reconnect logic in the past
>> >> (and I think it still does not..).
>> >>
>> >> Martin
>> >>
>> >> On Tue, Aug 8, 2017 at 12:01 PM, Roy Golan  wrote:
>> >> > Petr, why do you need the ping verb? what are you after?
>> >> >
>> >> > On Tue, 8 Aug 2017 at 11:54 Martin Sivak  wrote:
>> >> >>
>> >> >> > The proposed solution is focused on making sure a command does one
>> >> >> > thing
>> >> >> > and
>> >> >> > not two:
>> >> >> > A ping that has no side effects and a "watchdog" mechanism to
>> >> >> > confirm
>> >> >> > connectivity.
>> >> >>
>> >> >> This sounds as exactly the right solution right now.
>> >> >>
>> >> >> >>> Still someone could call conirmConnectivity, no?
>> >> >>
>> >> >> We do not protect any other endpoints that can cause the host to go
>> >> >> wild (storage or even setupNetworks). I agree with Edward it is the
>> >> >> responsibility of the caller to do the right thing. You need to be
>> >> >> root or have the certificate to talk to VDSM anyway.
>> >> >>
>> >> >> Martin
>> >> >>
>> >> >> On Tue, Aug 8, 2017 at 8:24 AM, Edward Haas 
>> >> >> wrote:
>> >> >> >
>> >> >> >
>> >> >> > On Mon, Aug 7, 2017 at 11:06 PM, Nir Soffer 
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> On Mon, Aug 7, 2017 at 5:28 PM Roy Golan 
>> >> >> >> wrote:
>> >> >> >>>
>> >> >> >>> Still someone could call conirmConnectivity, no? so the state
>> >> >> >>> isn't
>> >> >> >>> guarded from localhost tinkering anyhow. If you really need a
>> >> >> >>> solution
>> >> >> >>> you
>> >> >> >>> can acuire a token for this operation by setupNetworks, and
>> >> >> >>> confirm
>> >> >> >>> connectivity with this token passed back.
>> >> >> >>>
>> >> >> >>> I'm not sure about the severity of the problem here, I'll let
>> >> >> >>> other
>> >> >> >>> reply, but I'm against this kind of solution.
>> >> >> >>>
>> >> >> >>>
>> >> >> >>>
>> >> >> >>> On Mon, 7 Aug 2017 at 15:32 Petr Horacek 
>> >> >> >>> wrote:
>> >> >> >>>>
>> >> >> >>>> Hello,
>> >> >> >>>>
>> >> >> >>>> current VDSM ping verb has a problem - it confirms network
>> >> >> >>>> connectivity as a side-effect. After Engine calls setupNetwork
>> >> >> >>>> it
>> >> >> >>>> pings VDSM host to confirm that external network connectivity
>> >> >> >>>> is
>> >> >> >>>> not
>> >> >> >>>> broken. This prohibits other users to call ping from localhost
>> >> >> >>>> since
>> >> >> >>>> it would confirm connectivity even though networking could be
>> >> >> >>>> broken.
>> >> >> >>
>> >> >> >>
>> >

Re: [ovirt-devel] [proposal] deprecate VDSM ping in favor of ping2 and confirmConnectivity

[Martin Sivak]

What stomp heartbeat? There is no such thing in the Python json rpc client.

Martin

On Tue, Aug 8, 2017 at 1:04 PM, Roy Golan  wrote:
> Why isn't the stomp heartbeat enough?
>
> On Tue, 8 Aug 2017 at 13:45 Martin Sivak  wrote:
>>
>> MOM and hosted engine use the ping verb to verify the connection is
>> still OK. The RPC client did not have any reconnect logic in the past
>> (and I think it still does not..).
>>
>> Martin
>>
>> On Tue, Aug 8, 2017 at 12:01 PM, Roy Golan  wrote:
>> > Petr, why do you need the ping verb? what are you after?
>> >
>> > On Tue, 8 Aug 2017 at 11:54 Martin Sivak  wrote:
>> >>
>> >> > The proposed solution is focused on making sure a command does one
>> >> > thing
>> >> > and
>> >> > not two:
>> >> > A ping that has no side effects and a "watchdog" mechanism to confirm
>> >> > connectivity.
>> >>
>> >> This sounds as exactly the right solution right now.
>> >>
>> >> >>> Still someone could call conirmConnectivity, no?
>> >>
>> >> We do not protect any other endpoints that can cause the host to go
>> >> wild (storage or even setupNetworks). I agree with Edward it is the
>> >> responsibility of the caller to do the right thing. You need to be
>> >> root or have the certificate to talk to VDSM anyway.
>> >>
>> >> Martin
>> >>
>> >> On Tue, Aug 8, 2017 at 8:24 AM, Edward Haas  wrote:
>> >> >
>> >> >
>> >> > On Mon, Aug 7, 2017 at 11:06 PM, Nir Soffer 
>> >> > wrote:
>> >> >>
>> >> >> On Mon, Aug 7, 2017 at 5:28 PM Roy Golan  wrote:
>> >> >>>
>> >> >>> Still someone could call conirmConnectivity, no? so the state isn't
>> >> >>> guarded from localhost tinkering anyhow. If you really need a
>> >> >>> solution
>> >> >>> you
>> >> >>> can acuire a token for this operation by setupNetworks, and confirm
>> >> >>> connectivity with this token passed back.
>> >> >>>
>> >> >>> I'm not sure about the severity of the problem here, I'll let other
>> >> >>> reply, but I'm against this kind of solution.
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> On Mon, 7 Aug 2017 at 15:32 Petr Horacek 
>> >> >>> wrote:
>> >> >>>>
>> >> >>>> Hello,
>> >> >>>>
>> >> >>>> current VDSM ping verb has a problem - it confirms network
>> >> >>>> connectivity as a side-effect. After Engine calls setupNetwork it
>> >> >>>> pings VDSM host to confirm that external network connectivity is
>> >> >>>> not
>> >> >>>> broken. This prohibits other users to call ping from localhost
>> >> >>>> since
>> >> >>>> it would confirm connectivity even though networking could be
>> >> >>>> broken.
>> >> >>
>> >> >>
>> >> >> Vdsm can save the client ip setting up the network. Getting a ping
>> >> >> from
>> >> >> this
>> >> >> client can confirm that the connectivity was restored. pings from
>> >> >> other
>> >> >> hosts
>> >> >> can be ignored.
>> >> >>
>> >> >> The client address is available in a thread local variable
>> >> >> (context.client_host)
>> >> >> during all api calls. see vdsm.common.api.context_string() for
>> >> >> example
>> >> >> usage.
>> >> >>
>> >> >> This infrastructure is available in 4.1.
>> >> >
>> >> >
>> >> > The proposed solution is focused on making sure a command does one
>> >> > thing
>> >> > and
>> >> > not two:
>> >> > A ping that has no side effects and a "watchdog" mechanism to confirm
>> >> > connectivity.
>> >> >
>> >> > Does it make sense to confirm connectivity from localhost? In many
>> >> > cases
>> >> > it
>> >> > probably does not,
>

Re: [ovirt-devel] [proposal] deprecate VDSM ping in favor of ping2 and confirmConnectivity

[Martin Sivak]

MOM and hosted engine use the ping verb to verify the connection is
still OK. The RPC client did not have any reconnect logic in the past
(and I think it still does not..).

Martin

On Tue, Aug 8, 2017 at 12:01 PM, Roy Golan  wrote:
> Petr, why do you need the ping verb? what are you after?
>
> On Tue, 8 Aug 2017 at 11:54 Martin Sivak  wrote:
>>
>> > The proposed solution is focused on making sure a command does one thing
>> > and
>> > not two:
>> > A ping that has no side effects and a "watchdog" mechanism to confirm
>> > connectivity.
>>
>> This sounds as exactly the right solution right now.
>>
>> >>> Still someone could call conirmConnectivity, no?
>>
>> We do not protect any other endpoints that can cause the host to go
>> wild (storage or even setupNetworks). I agree with Edward it is the
>> responsibility of the caller to do the right thing. You need to be
>> root or have the certificate to talk to VDSM anyway.
>>
>> Martin
>>
>> On Tue, Aug 8, 2017 at 8:24 AM, Edward Haas  wrote:
>> >
>> >
>> > On Mon, Aug 7, 2017 at 11:06 PM, Nir Soffer  wrote:
>> >>
>> >> On Mon, Aug 7, 2017 at 5:28 PM Roy Golan  wrote:
>> >>>
>> >>> Still someone could call conirmConnectivity, no? so the state isn't
>> >>> guarded from localhost tinkering anyhow. If you really need a solution
>> >>> you
>> >>> can acuire a token for this operation by setupNetworks, and confirm
>> >>> connectivity with this token passed back.
>> >>>
>> >>> I'm not sure about the severity of the problem here, I'll let other
>> >>> reply, but I'm against this kind of solution.
>> >>>
>> >>>
>> >>>
>> >>> On Mon, 7 Aug 2017 at 15:32 Petr Horacek  wrote:
>> >>>>
>> >>>> Hello,
>> >>>>
>> >>>> current VDSM ping verb has a problem - it confirms network
>> >>>> connectivity as a side-effect. After Engine calls setupNetwork it
>> >>>> pings VDSM host to confirm that external network connectivity is not
>> >>>> broken. This prohibits other users to call ping from localhost since
>> >>>> it would confirm connectivity even though networking could be broken.
>> >>
>> >>
>> >> Vdsm can save the client ip setting up the network. Getting a ping from
>> >> this
>> >> client can confirm that the connectivity was restored. pings from other
>> >> hosts
>> >> can be ignored.
>> >>
>> >> The client address is available in a thread local variable
>> >> (context.client_host)
>> >> during all api calls. see vdsm.common.api.context_string() for example
>> >> usage.
>> >>
>> >> This infrastructure is available in 4.1.
>> >
>> >
>> > The proposed solution is focused on making sure a command does one thing
>> > and
>> > not two:
>> > A ping that has no side effects and a "watchdog" mechanism to confirm
>> > connectivity.
>> >
>> > Does it make sense to confirm connectivity from localhost? In many cases
>> > it
>> > probably does not,
>> > but there may be cases where it does make sense... it is not the
>> > functionality to determine what
>> > makes sense or not, it is the usage of it who has the responsibility to
>> > use
>> > it correctly.
>> >
>> >>
>> >> Nir
>> >>
>> >>>>
>> >>>>
>> >>>> In order to fix this problem ping should be split to ping2 (which
>> >>>> just
>> >>>> returns Success with no side-effect) and confirmConnectivity. Change
>> >>>> on VDSM side was introduced in [1], we still need to expose new verbs
>> >>>> in Engine.
>> >>>>
>> >>>> Regards,
>> >>>> Petr
>> >>>>
>> >>>> [1] https://gerrit.ovirt.org/#/c/80119/
>> >>>> ___
>> >>>> Devel mailing list
>> >>>> Devel@ovirt.org
>> >>>> http://lists.ovirt.org/mailman/listinfo/devel
>> >>>
>> >>> ___
>> >>> Devel mailing list
>> >>> Devel@ovirt.org
>> >>> http://lists.ovirt.org/mailman/listinfo/devel
>> >>
>> >>
>> >> ___
>> >> Devel mailing list
>> >> Devel@ovirt.org
>> >> http://lists.ovirt.org/mailman/listinfo/devel
>> >
>> >
>> >
>> > ___
>> > Devel mailing list
>> > Devel@ovirt.org
>> > http://lists.ovirt.org/mailman/listinfo/devel
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [proposal] deprecate VDSM ping in favor of ping2 and confirmConnectivity

[Martin Sivak]

> The proposed solution is focused on making sure a command does one thing and
> not two:
> A ping that has no side effects and a "watchdog" mechanism to confirm
> connectivity.

This sounds as exactly the right solution right now.

>>> Still someone could call conirmConnectivity, no?

We do not protect any other endpoints that can cause the host to go
wild (storage or even setupNetworks). I agree with Edward it is the
responsibility of the caller to do the right thing. You need to be
root or have the certificate to talk to VDSM anyway.

Martin

On Tue, Aug 8, 2017 at 8:24 AM, Edward Haas  wrote:
>
>
> On Mon, Aug 7, 2017 at 11:06 PM, Nir Soffer  wrote:
>>
>> On Mon, Aug 7, 2017 at 5:28 PM Roy Golan  wrote:
>>>
>>> Still someone could call conirmConnectivity, no? so the state isn't
>>> guarded from localhost tinkering anyhow. If you really need a solution you
>>> can acuire a token for this operation by setupNetworks, and confirm
>>> connectivity with this token passed back.
>>>
>>> I'm not sure about the severity of the problem here, I'll let other
>>> reply, but I'm against this kind of solution.
>>>
>>>
>>>
>>> On Mon, 7 Aug 2017 at 15:32 Petr Horacek  wrote:

 Hello,

 current VDSM ping verb has a problem - it confirms network
 connectivity as a side-effect. After Engine calls setupNetwork it
 pings VDSM host to confirm that external network connectivity is not
 broken. This prohibits other users to call ping from localhost since
 it would confirm connectivity even though networking could be broken.
>>
>>
>> Vdsm can save the client ip setting up the network. Getting a ping from
>> this
>> client can confirm that the connectivity was restored. pings from other
>> hosts
>> can be ignored.
>>
>> The client address is available in a thread local variable
>> (context.client_host)
>> during all api calls. see vdsm.common.api.context_string() for example
>> usage.
>>
>> This infrastructure is available in 4.1.
>
>
> The proposed solution is focused on making sure a command does one thing and
> not two:
> A ping that has no side effects and a "watchdog" mechanism to confirm
> connectivity.
>
> Does it make sense to confirm connectivity from localhost? In many cases it
> probably does not,
> but there may be cases where it does make sense... it is not the
> functionality to determine what
> makes sense or not, it is the usage of it who has the responsibility to use
> it correctly.
>
>>
>> Nir
>>


 In order to fix this problem ping should be split to ping2 (which just
 returns Success with no side-effect) and confirmConnectivity. Change
 on VDSM side was introduced in [1], we still need to expose new verbs
 in Engine.

 Regards,
 Petr

 [1] https://gerrit.ovirt.org/#/c/80119/
 ___
 Devel mailing list
 Devel@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>> ___
>>> Devel mailing list
>>> Devel@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>>
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>
>
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ovirt-users] Lowering the bar for wiki contribution?

[Martin Sivak]

> I think we need a wiki for this, instead of reinventing one :-)

Really? And ending in the same mess we had before? No thanks.

Other big ans successful [1] (single component) projects have docs/
directory and documentation and design reviews are integral part of
code review. That way you can atomically reject/accept changes to code
and docs together. We can't easily do it this way as we have multiple
cooperating components, but we should try to get close.

> We have a builtin markdown based wiki in the ovirt site github project.

Yes we do, but we do not have commit rights. And internal technical
documentation and _design_ pages need to be a bit closer to the source
otherwise nobody will want to touch them.

> For discussion, we have the mailing list and other channels like bluejeans
> and irc.

For informal yes. But formal proposals and final design documentation
are something different.

And don't let me started on the theoretical open aspect of our
project.. do we want more contributors or not? Can we afford
artificial barriers? Is somebody from general public allowed to
contribute ideas?

Gerrit / Github give everybody the power to easily see all currently
considered (open) projects and review them using the same interface we
use for our daily work! This way any team can catch conceptual issues
with other teams' projects. Searching through email threads is nowhere
near the same experience.

[1] kubernetes and Linux kernel just to name two

--
Martin Sivak
SLA / oVirt


On Tue, Jun 20, 2017 at 9:22 PM, Nir Soffer  wrote:
>
> בתאריך יום ג׳, 20 ביוני 2017, 13:10, מאת Martin Sivak ‏:
>>
>> Hi,
>>
>> I think what Edy did here makes sense. We do not need anything fancy
>> for technical documentation and design. This would also be easy to
>> maintain or integrate to the main website (git submodules will help).
>>
>> I have two basic requirements for design space:
>>
>> - commenting so devs can discuss the design
>> - ease of update so we can respond to comments
>>
>> A plain markdown repo would work well for this and both points are
>> possible using github or gerrit workflows.
>>
>> I would actually prefer if we had something that is directly part of
>> the source repositories so we could review code updates and docs
>> updates together. Unfortunately that it is hard to do when we have
>> multiple different components to update. So this proposal is probably
>> the next best thing.
>
>
> I think we need a wiki for this, instead of reinventing one :-)
>
> We have a builtin markdown based wiki in the ovirt site github project.
>
> For discussion, we have the mailing list and other channels like bluejeans
> and irc.
>
> Nir
>
>>
>> --
>> Martin Sivak
>> SLA
>>
>>
>> On Thu, Jun 15, 2017 at 8:11 PM, Edward Haas  wrote:
>> > Hi all,
>> >
>> > Came back to this thread due to a need to post some design
>> > documentation.
>> > After fetching the ovirt-site and looking up where to start the
>> > document, I
>> > remembered why I stopped using it.
>> >
>> > After exploring several options, including the GitHub wiki, I think that
>> > for
>> > the development documentation we can just go with the minimum:
>> > Use a repo to just post markdown and image files, letting GitHub
>> > rendering/view of such files to do the job for us.
>> > We can still review the documents and have discussions on the content,
>> > and
>> > provide access to all who wants to use it (to perform the merges).
>> > The fact it uses markdown and images, can allow its content to be
>> > relocated
>> > to any other solutions that will come later on, including adding the
>> > content
>> > back on ovirt-site.
>> >
>> > Here is a simple example:
>> > https://github.com/EdDev/ovirt-devwiki/blob/initial-structure/index.md
>> >
>> > it uses simple markdown md files with relative links to other pages.
>> > Adding
>> > images is also simple.
>> >
>> > What do you think?
>> >
>> > Thanks,
>> > Edy.
>> >
>> >
>> >
>> > On Tue, Feb 7, 2017 at 12:42 PM, Michal Skrivanek
>> >  wrote:
>> >>
>> >>
>> >> On 16 Jan 2017, at 11:13, Roy Golan  wrote:
>> >>
>> >>
>> >>
>> >> On 11 January 2017 at 17:06, Marc Dequènes (Duck) 
>> >> wrote:
>> >>>
>> >>> Quack,
>> >>>
>> >>> On 01/08/2017 06:39 PM, Barak Korren wrote:
>> >>> > On 8 Janua

Re: [ovirt-devel] [ovirt-users] Lowering the bar for wiki contribution?

[Martin Sivak]

Hi,

I think what Edy did here makes sense. We do not need anything fancy
for technical documentation and design. This would also be easy to
maintain or integrate to the main website (git submodules will help).

I have two basic requirements for design space:

- commenting so devs can discuss the design
- ease of update so we can respond to comments

A plain markdown repo would work well for this and both points are
possible using github or gerrit workflows.

I would actually prefer if we had something that is directly part of
the source repositories so we could review code updates and docs
updates together. Unfortunately that it is hard to do when we have
multiple different components to update. So this proposal is probably
the next best thing.

--
Martin Sivak
SLA


On Thu, Jun 15, 2017 at 8:11 PM, Edward Haas  wrote:
> Hi all,
>
> Came back to this thread due to a need to post some design documentation.
> After fetching the ovirt-site and looking up where to start the document, I
> remembered why I stopped using it.
>
> After exploring several options, including the GitHub wiki, I think that for
> the development documentation we can just go with the minimum:
> Use a repo to just post markdown and image files, letting GitHub
> rendering/view of such files to do the job for us.
> We can still review the documents and have discussions on the content, and
> provide access to all who wants to use it (to perform the merges).
> The fact it uses markdown and images, can allow its content to be relocated
> to any other solutions that will come later on, including adding the content
> back on ovirt-site.
>
> Here is a simple example:
> https://github.com/EdDev/ovirt-devwiki/blob/initial-structure/index.md
>
> it uses simple markdown md files with relative links to other pages. Adding
> images is also simple.
>
> What do you think?
>
> Thanks,
> Edy.
>
>
>
> On Tue, Feb 7, 2017 at 12:42 PM, Michal Skrivanek
>  wrote:
>>
>>
>> On 16 Jan 2017, at 11:13, Roy Golan  wrote:
>>
>>
>>
>> On 11 January 2017 at 17:06, Marc Dequènes (Duck)  wrote:
>>>
>>> Quack,
>>>
>>> On 01/08/2017 06:39 PM, Barak Korren wrote:
>>> > On 8 January 2017 at 10:17, Roy Golan  wrote:
>>> >> Adding infra which I forgot to add from the beginning
>>>
>>> Thanks.
>>>
>>> > I don't think this is an infra issue, more of a community/working
>>> > procedures one.
>>>
>>> I do thin it is. We are involved in the tooling, for their maintenance,
>>> for documenting where things are, for suggesting better solutions,
>>> ensuring security…
>>>
>>> > On the one hand, the developers need a place where they create and
>>> > discuss design documents and road maps. That please needs to be as
>>> > friction-free as possible to allow developers to work on the code
>>> > instead of on the documentation tools.
>>>
>>> As for code, I think there is need for review, even more for design
>>> documents, so I don't see why people are bothered by PRs, which is a
>>> tool they already know fairly well.
>>
>>
>> because it takes ages to get attention and get it in, even in cases when
>> the text/update is more of an FYI and doesn’t require feedback.
>> That leads to frustration, and that leads to loss of any motivation to
>> contribute anything at all.
>> You can see people posting on their own platforms, blogs, just to run away
>> from this one
>>
>>>
>>> For people with few git knowledge, the GitHub web interface allows to
>>> edit files.
>>>
>>> > On the other hand, the user community needs a good, up to date source
>>> > of information about oVirt and how to use it.
>>>
>>> Yes, this official entry point and it needs to be clean.
>>
>>
>> yep, you’re right about the entry point -like pages
>>
>>>
>>> > Having said the above, I don't think the site project's wiki is the
>>> > best place for this. The individual project mirrors on GitHub may be
>>> > better for this
>>>
>>> We could indeed split the technical documentation. If people want to
>>> experiment with the GH wiki pages, I won't interfere.
>>>
>>> I read several people in this thread really miss the old wiki, so I
>>> think it is time to remember why we did not stay in paradise. I was not
>>> there at the time, but I know the wiki was not well maintained. People
>>> are comparing our situation to the MediaWiki site, but the workforce is
>&

Re: [ovirt-devel] Who cares about 'memGuaranteedSize'?

[Martin Sivak]

Hi Francesco,

MOM is using it via the balloon_min key in balloonInfo. The policy
that does that is part of the vdsm package though:

https://gerrit.ovirt.org/gitweb?p=vdsm.git;a=blob;f=static/etc/vdsm/mom.d/02-balloon.policy;h=b1af0d5833619042d8d9f023905efb59a99f2041;hb=209d37b60f55461a80bf0115cdf411c5c1b6e475#l129

Best regards

Martin

On Thu, Jun 8, 2017 at 9:28 AM, Francesco Romani  wrote:
> Hi all,
>
>
> We have this field in the Vdsm API:
>
>
> -   description: The amount of memory guaranteed to the VM in MB
> name: memGuaranteedSize
> type: uint
>
>
> Available in VmDefinition, VMFullInfo, VmParameters
>
>
> Vdsm dutifully records and reports this value - but doesn't use it. It
> is used exactly once for balloon stata:
>
>
> stats['balloonInfo'].update({
> 'balloon_max': str(max_mem),
> 'balloon_min': str(
> int(vm.conf.get('memGuaranteedSize', '0')) * 1024),
> 'balloon_cur': str(balloon_cur),
> 'balloon_target': str(balloon_target)
> })
>
>
> Now, a quick git grep in both MOM and Engine reveals no obvious usages.
> Am I missing something?
>
> Can we drop this for 4.2, and deprecate it in next(4.1) ?
>
>
> Thanks,
>
> --
> Francesco Romani
> Senior SW Eng., Virtualization R&D
> Red Hat
> IRC: fromani github: @fromanirh
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Using more specific types in code visible to GWT frontend

[Martin Sivak]

Hi,

the part I would be worried about is that entities are also used on
the Java side of the engine. And the generic type recommendations and
guidelines say exactly the opposite for Java (declare generic, use
whatever impl you need).

It seems to me that some form of UI specific DTOs might improve the
separation and performance here. Changing all entities to use specific
types would be a HUGE patch as it would probably affect almost every
single file we have in the engine.

Or maybe: Can we use some kind of compiler extension to rewrite the
source code for the GWT side only? I would really prefer if the Java
side of out logic and DAOs was not mangled just to make GWT happier.

--
Martin Sivak
SLA / oVirt
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] high performance VM preset

[Martin Sivak]

Or maybe on NUMA nodes.

On Wed, May 24, 2017 at 3:03 PM, Martin Sivak  wrote:
>> In order to maximize performance we may also want to limit the number of
>> other VMs (either regular or high performance) running on the same
>> host. This to minimize the interference and the resource stealing.
>>
>>
>> In the extreme case, just the selected high performance VM would be
>> allowed to run on one suitable host.
>
> I would base this on cores. You can have two HPF VMs when each is
> pinned to distinct set of CPUs.
>
> Martin
>
> On Wed, May 24, 2017 at 2:11 PM, Francesco Romani  wrote:
>> On 05/24/2017 12:57 PM, Michal Skrivanek wrote:
>>> Hi all,
>>> we plan to work on an improvement in VM definition for high performance 
>>> workloads which do not require desktop-class devices and generally favor 
>>> highest possible performance in expense of less flexibility.
>>> We’re thinking of adding a new VM preset in addition to current Desktop and 
>>> Server in New VM dialog, which would automatically pre-select existing 
>>> options in the right way, and suggest/warn on suboptimal configuration
>>> All the presets and warning can be changed and ignored. There are few 
>>> things we already identified as boosting performance and/or minimize the 
>>> complexity of the VM, so we plan the preset to:
>>> - remove all graphical consoles and set the VM as headless, making it 
>>> accessible by serial console.
>>> - disable all USB.
>>> - disable soundcard.
>>> - enable I/O Threads, just one for all disks by default.
>>> - set host cpu passthrough (effectively disabling VM live migration), add 
>>> I/O Thread pinning in a similar way as the existing CPU pinning.
>>> We plan the following checks and suggest to perform CPU pinning, host 
>>> topology == guest topology (number of cores per socket and threads per core 
>>> should match), NUMA topology host and guest match, check and suggest the 
>>> I/O threads pinning.
>>> A popup on a VM dialog save seems suitable.
>>>
>>> currently identified task and status can be followed on trello card[1]
>>>
>>> Please share your thoughts, questions, any kind of feedback…
>>
>> In order to maximize performance we may also want to limit the number of
>> other VMs (either regular or high performance) running on the same
>> host. This to minimize the interference and the resource stealing.
>>
>>
>> In the extreme case, just the selected high performance VM would be
>> allowed to run on one suitable host.
>>
>> Bests,
>>
>> --
>> Francesco Romani
>> Senior SW Eng., Virtualization R&D
>> Red Hat
>> IRC: fromani github: @fromanirh
>>
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] high performance VM preset

[Martin Sivak]

> In order to maximize performance we may also want to limit the number of
> other VMs (either regular or high performance) running on the same
> host. This to minimize the interference and the resource stealing.
>
>
> In the extreme case, just the selected high performance VM would be
> allowed to run on one suitable host.

I would base this on cores. You can have two HPF VMs when each is
pinned to distinct set of CPUs.

Martin

On Wed, May 24, 2017 at 2:11 PM, Francesco Romani  wrote:
> On 05/24/2017 12:57 PM, Michal Skrivanek wrote:
>> Hi all,
>> we plan to work on an improvement in VM definition for high performance 
>> workloads which do not require desktop-class devices and generally favor 
>> highest possible performance in expense of less flexibility.
>> We’re thinking of adding a new VM preset in addition to current Desktop and 
>> Server in New VM dialog, which would automatically pre-select existing 
>> options in the right way, and suggest/warn on suboptimal configuration
>> All the presets and warning can be changed and ignored. There are few things 
>> we already identified as boosting performance and/or minimize the complexity 
>> of the VM, so we plan the preset to:
>> - remove all graphical consoles and set the VM as headless, making it 
>> accessible by serial console.
>> - disable all USB.
>> - disable soundcard.
>> - enable I/O Threads, just one for all disks by default.
>> - set host cpu passthrough (effectively disabling VM live migration), add 
>> I/O Thread pinning in a similar way as the existing CPU pinning.
>> We plan the following checks and suggest to perform CPU pinning, host 
>> topology == guest topology (number of cores per socket and threads per core 
>> should match), NUMA topology host and guest match, check and suggest the I/O 
>> threads pinning.
>> A popup on a VM dialog save seems suitable.
>>
>> currently identified task and status can be followed on trello card[1]
>>
>> Please share your thoughts, questions, any kind of feedback…
>
> In order to maximize performance we may also want to limit the number of
> other VMs (either regular or high performance) running on the same
> host. This to minimize the interference and the resource stealing.
>
>
> In the extreme case, just the selected high performance VM would be
> allowed to run on one suitable host.
>
> Bests,
>
> --
> Francesco Romani
> Senior SW Eng., Virtualization R&D
> Red Hat
> IRC: fromani github: @fromanirh
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] New design for the Gerrit UI

[Martin Sivak]

> It will help if someone can suggest an alternate CSS which we can use or
specific color codes,

Well.. keep it as it is or make it really dark (like the patternfly menu).
I do not care about logos but big area filled with non-neutral color is
always going to be an issue.

Martin

On Thu, May 4, 2017 at 2:15 PM, Eyal Edri  wrote:

>
>
> On Thu, May 4, 2017 at 3:05 PM, Martin Perina  wrote:
>
>> I agree with Milan and Martin, even after few minutes looking at it, the
>> green
>> with combination of white background just made my eyes burning :-(
>>
>> Would it be possible to use more darker colors (at least for top
>> banner/menu)?
>> For example darker colors we use in oVirt engine welcome page ...
>>
>
> Thanks for the feedback,
> It will help if someone can suggest an alternate CSS which we can use or
> specific color codes,
> otherwise it will be long trial and error process until we'll find
> something that will suite everyone.
>
>
>
>>
>>
>> Martin
>>
>> On Thu, May 4, 2017 at 5:53 AM, Martin Sivak  wrote:
>>
>>> I agree with Milan here. The light green background makes the menu
>>> items to be almost unreadable, the search button (slightly different
>>> green color) blends with the background and generally the color pulls
>>> my eyes away from the content. I wouldn't feel comfortable looking at
>>> the screen for a whole day.
>>>
>>> Martin
>>>
>>> On Thu, May 4, 2017 at 9:57 AM, Milan Zamazal 
>>> wrote:
>>> > Evgheni Dereveanchin  writes:
>>> >
>>> >> 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/
>>> >
>>> > Thank you for the preview.  While it fits better with oVirt services,
>>> > there is one thing that makes me uncomfortable with it: low contrast.
>>> > The top green bar is probably directly violating Web Accessibility
>>> > Guidelines (AA level; see
>>> > https://www.w3.org/TR/WCAG20/#visual-audio-contrast-contrast), but I
>>> > find all the green parts harder to read than in the current version.
>>> > So it would be nice if the contrast could be improved.
>>> >
>>> > Thanks,
>>> > Milan
>>> > ___
>>> > Devel mailing list
>>> > Devel@ovirt.org
>>> > http://lists.ovirt.org/mailman/listinfo/devel
>>> ___
>>> Devel mailing list
>>> Devel@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>
>>
>> ___
>> Infra mailing list
>> in...@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/infra
>>
>>
>
>
> --
>
> Eyal edri
>
>
> ASSOCIATE MANAGER
>
> RHV DevOps
>
> EMEA VIRTUALIZATION R&D
>
>
> Red Hat EMEA <https://www.redhat.com/>
> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
> phone: +972-9-7692018 <+972%209-769-2018>
> irc: eedri (on #tlv #rhev-dev #rhev-integ)
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] New design for the Gerrit UI

[Martin Sivak]

I agree with Milan here. The light green background makes the menu
items to be almost unreadable, the search button (slightly different
green color) blends with the background and generally the color pulls
my eyes away from the content. I wouldn't feel comfortable looking at
the screen for a whole day.

Martin

On Thu, May 4, 2017 at 9:57 AM, Milan Zamazal  wrote:
> Evgheni Dereveanchin  writes:
>
>> 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/
>
> Thank you for the preview.  While it fits better with oVirt services,
> there is one thing that makes me uncomfortable with it: low contrast.
> The top green bar is probably directly violating Web Accessibility
> Guidelines (AA level; see
> https://www.w3.org/TR/WCAG20/#visual-audio-contrast-contrast), but I
> find all the green parts harder to read than in the current version.
> So it would be nice if the contrast could be improved.
>
> Thanks,
> Milan
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Firewalld migration.

[Martin Sivak]

> Engine - no, running from RHVM - yes - if you are using Ansible , I think it
> makes sense to use a single common script or possibly per cluster.

Exactly my point. The engine should not manage those, but it should
still know how to execute them to perform a proper host deploy.

Martin

On Thu, Apr 6, 2017 at 2:13 PM, Yaniv Kaul  wrote:
>
>
> On Thu, Apr 6, 2017 at 2:56 PM, Leon Goldberg  wrote:
>>
>> Hey,
>>
>> There seems to be a growing consensus towards moving custom rules out of
>> Engine. It is believed that Engine shouldn't have assumed the role of a
>> centralized firewall management system in he first place, and that using a
>> proper 3rd party solution will be both favorable to the users (allowing
>> better functionality and usability) and will allow us to simplify our
>> firewall deployment process.
>>
>> Considering we don't have to manage custom rules, a host will be able to
>> derive all the information regarding its firewalld services from its own
>> configuration. Consequently, option #2 becomes a forerunner with Engine's
>> involvement being even further diminished.
>
>
> Engine - no, running from RHVM - yes - if you are using Ansible , I think it
> makes sense to use a single common script or possibly per cluster.
> Y.
>
>>
>>
>>
>> On Sun, Mar 26, 2017 at 1:33 PM, Leon Goldberg 
>> wrote:
>>>
>>>
>>> Hey,
>>>
>>> We're looking to migrate from iptables to firewalld. We came up with a
>>> couple of possible approaches we'd like opinions on. I'll list the options
>>> first, and will
>>>
>>> 1) Replicate existing flow:
>>>
>>> As of date, iptable rules are inserted in the database via SQL config
>>> files. During host deployment, VdsDeployIptablesUnit adds the required rules
>>> (based on cluster/firewall configuration) to the deployment configuration,
>>> en route to being deployed on the host via otopi and its iptables plugin.
>>>
>>> Pros:
>>>
>>> - Reuse of existing infrastructure.
>>>
>>> Cons:
>>>
>>> - Current infrastructure is overly complex...
>>> - Many of the required services are provided by firewalld. Rewriting them
>>> is wasteful; specifying them (instead of providing actual service .xml
>>> content) will require adaptations on both (engine/host) sides. More on that
>>> later.
>>>
>>>
>>> 2) Host side based configuration:
>>>
>>> Essentially, all the required logic (aforementioned cluster/firewall
>>> configuration) to determine if/how firewalld should be deployed could be
>>> passed on to the host via ohd. Vdsm could take on the responsibility of
>>> examining the relevant configuration, and then creating and/or adding the
>>> required services (using vdsm.conf and vdsm-tool).
>>>
>>> Pros:
>>>
>>>  - Engine side involvement is greatly diminished.
>>>  - Simple(r).
>>>
>>> Cons:
>>>
>>>  - Custom services/rules capabilities will have to be rethought and
>>> re-implemented (current infrastructure supports custom iptables rules by
>>> being specified in the SQL config file).
>>>
>>>
>>> 3) Some other hybrid approach:
>>>
>>> If we're able to guarantee all the required firewalld services are
>>> statically provided one way or the other, the current procedure could be
>>> replicated and be made more simpler. Instead of providing xml content in the
>>> form of strings, service names could be supplied. The responsibility of
>>> actual service deployment becomes easier, and could be left to otopi (with
>>> the appropriate modifications) or switched over to vdsm.
>>>
>>> --
>>>
>>> Regardless, usage of statically provided vs. dynamically created services
>>> remains an open question. I think we'd like to avoid implementing logic that
>>> ask whether some service is provided (and then write it if it isn't...), and
>>> so choosing between the dynamic and static approaches is also needed. Using
>>> the static approach, guaranteeing all services are provided will be
>>> required.
>>>
>>> I do believe guaranteeing the presence of all required services is worth
>>> it, however custom services aren't going to be naively compatible, and we'll
>>> still have to use similar mechanism as described in #1 (service string ->
>>> .xml -> addition of service name to active zone).
>>>
>>>
>>> Your thoughts are welcome.
>>>
>>> Thanks,
>>> Leon
>>>
>>
>>
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>
>
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Writing SQL queries in DAO code

[Martin Sivak]

> In that case , if we will not use SP , we still will have to secure the data
> (for example , hidden columns for some users like in the VDS view)

But isn't this the current problem?

- The whole permission model is so complicated that nobody wants to
write new queries with it. (custom solution)
- Permissions are checked both in db and in the engine differently
(our custom solution)
- We do not have clear distinction between internal queries and
queries with user facing data.
- The SQL code style we expect is not properly documented and has NO
support in IDEs we use so it is all manual hit or miss when trying to
get a patch merged. (custom sql style)
- We hand "optimize" every query without measuring first (again all is
custom with no caching)

And the most important issues I think are:

- We have no developer documentation for tables or queries that would
explain what the structure is and what should be visible or hidden
when certain user is looking at it. (We do not have any entity
documentation either, so I often have to dig into dao, vdsbroker and
vdsm just to find out the used units)

- You insist on seeing every single patch and any db update means you
have to constantly update the filename of the script, that makes
merging hard and really slow (again custom solution, although I accept
neither flyway nor liquidbase are too much better)

We do not have to use ORM for everything (that would be a mistake too
I think), but think about this: Hibernate/JPA or jOOQ or Spring Data
probably have had more people working at them and using them, than
what we will ever be able to provide for the whole engine. So why not
reuse at least part of what the community can give us. New developers
will get productive sooner too...

When you sum all those up, no wonder people are trying to avoid
touching the db layer. We have so many custom steps in the process
that maybe we should start looking in what the industry is using.
Having everything custom will take us nowhere (that is not just about
DAO).

Martin


On Thu, Mar 30, 2017 at 9:31 AM, Eli Mesika  wrote:
>
>
> On Wed, Mar 29, 2017 at 4:23 PM, Martin Mucha  wrote:
>>
>> Hi,
>>
>> I didn't want to step into this, but I was asked by dan to express my
>> opinion about this. I'm not pushing for change (since I believe it will be
>> blocked), I'm just trying to help us focus. We should have some questions
>> answered prior to saying what we want to do...
>>
>> Current state of accessing db is that there's fired lots of unnecessary db
>> calls, just because there isn't easy way to do them correctly, someone is
>> lazy, whatever, that isn't important. The blame was laid on invalid code
>> review. Now let me remember maintainer Kolesnik, who during CR insisted on
>> creating N+1 problem[1] when accessing db, to save ±10 lines of code in dal
>> layer. So Eli is right, our code suck because of improper code revision
>> process, but sometimes it is maintainers who wants invalid code to be pushed
>> to simplify db access code. Therefore we cannot rely on review process, this
>> is real issue we have. I'm fine with it, this is how we do things. But we
>> also have (sometimes (a lot)) degraded performance because of it.
>>
>> We should have answered following questions:
>>
>> 1) is performance even important at all? Should we optimize db access? I'm
>> assuming "yes" should be the answer. If it's not the answer, we can skip
>> next questions.
>>
>> 2) can someone responsible for whole project provide timings and count of
>> queries? This should easily bring crosshair on commands requiring attention.
>>   2.1) customer is issuing synchronous command. What is maximum number of
>> queries this command (plus all transitive internal commands) should fire?
>> What's the number for asynchronous command?
>>   2.2) same for time; what is the maximum time for synchronous and
>> asynchronous command?
>>
>> 3) lets say that we found command which requires optimization (and that
>> should not be hard). If we go back to mentioned N+1 problem, it's rather
>> easy to avoid it for one association(yet we did not do it even there), but
>> it's not that easy for multiple joins [1]. But it's superbly easy to achieve
>> it using ORM tool, even with still using only named queries, even native
>> ones defined outside of java. Supposing we want to optimize found command,
>> what would dal maintainers consider as a acceptable optimization? Is there
>> even possibility to not use stored procedures? I believe saying simple "no",
>> if that's the case, is valid response, which can save time. If there is
>> theoretical possibility, what criteria must be met so that we can consider
>> replacing most trivial stored procedures with some tool in our project?
>> There are lots of tools/frameworks, based on your criteria we might find
>> some, which would work best...
>>
>> —
>>
>> My generic opinion would be to stick with sp and allowing to use something
>> less heavy for simplest queries/stuff. It could beJP

Re: [ovirt-devel] Firewalld migration.

[Martin Sivak]

> 2. There are better tools to do it than via engine-config -> database ->
> host-deploy, which are also easier for both us to support as well as our
> users to work with.

I am all in favor of skipping engine-config and database.

> 1. We can't configure (and/or possibly customize) everything (NTP?
> multipath.conf configuration? even vdsm.conf!). We strive to improve and do
> it well, but there are limits and challenges.

Sure, but we still run the host deploy from the engine side and then
activate the host immediately. Which means we need give the user a
chance to execute customizations in the middle of the process.
Currently it was firewall only and the way it was done was pretty
awkward, but we can do better instead of removing the option
completely.

I actually like the radical option Didi mentioned -> using Ansible for
the whole deploy flow. A simple host-deploy dir with playbooks (and
builtin roles) is something most people would understand easily.

And it would even remove all the infrastructure burden from us, oVirt
would not be the host management solution, Ansible would take the role
and we would just invoke it when deploying a new host much like we do
with host deploy now (except Ansible manages its own ssh connection
too).

Martin

On Tue, Mar 28, 2017 at 5:29 PM, Yaniv Kaul  wrote:
>
>
> On Tue, Mar 28, 2017 at 4:00 PM, Martin Sivak  wrote:
>>
>> > But we do not want to support custom firewall rules, we are not a
>> > firewall
>> > manager.
>> > IMO, oVirt should support the hardening of its services and co-exist
>> > with
>> > other rules.
>> > Custom firewall settings imply one of these:
>> > - We need to extend current firewall options.
>> > - It needs to be implemented outside oVirt.
>> >
>> > But if the need to support back doors is proven to be a must, then
>> > implement
>> > them
>> > outside the main core solution, these edge cases should not block the
>> > main
>> > business
>> > logic.
>>
>> I seem to remember that the one feature that sets us apart from
>> everybody else is that we know how to manage the bare metal. And the
>> current standing decision I know about is that we want to keep that
>> capability.
>>
>> Yaniv? Is that still so?
>
>
> It is, but we also need to acknowledge that:
> 1. We can't configure (and/or possibly customize) everything (NTP?
> multipath.conf configuration? even vdsm.conf!). We strive to improve and do
> it well, but there are limits and challenges.
> 2. There are better tools to do it than via engine-config -> database ->
> host-deploy, which are also easier for both us to support as well as our
> users to work with.
> Y.
>
>
>>
>> All other solutions (OpenStack, OpenShift, ..) require you to
>> configure the bare metal first and then deploy virtualization. We
>> simplify this for the sysadmin and that makes us special (for good and
>> bad as Sven pointed out).
>>
>> So, if we do not want to support custom rules in the engine, then the
>> whole host deploy script (not just firewall) needs to work very
>> differently, because the end goal is to have properly deployed node
>> for virtualization. And the "properly" word is defined both by us and
>> the owner sysadmin.
>>
>> But deploy has to all or nothing operation, otherwise the engine will
>> start using half configured host and you risk someone forgetting to
>> run an extra script.
>>
>> Martin
>>
>> On Mon, Mar 27, 2017 at 7:47 PM, Edward Haas  wrote:
>> >
>> >
>> > On Mon, Mar 27, 2017 at 7:07 PM, Martin Sivak  wrote:
>> >>
>> >> > Clients should be made aware their custom rules are going to be
>> >> > obsolete
>> >> > and
>> >> > that they should reapply them once they reinstall.
>> >>
>> >> Would you want to manually fix every reinstalled host? I would
>> >> consider that very annoying. This has to be somewhat automatic if we
>> >> want to support custom firewall rules. And although I agree the engine
>> >> is not the right place for that, it is the only central place we have
>> >> and from which we are starting the reinstall task.
>> >
>> >
>> > But we do not want to support custom firewall rules, we are not a
>> > firewall
>> > manager.
>> > IMO, oVirt should support the hardening of its services and co-exist
>> > with
>> > other rules.
>> > Custom firewall settings imply one of these:
>> > - We need to extend current firewal

Re: [ovirt-devel] Firewalld migration.

[Martin Sivak]

> But we do not want to support custom firewall rules, we are not a firewall
> manager.
> IMO, oVirt should support the hardening of its services and co-exist with
> other rules.
> Custom firewall settings imply one of these:
> - We need to extend current firewall options.
> - It needs to be implemented outside oVirt.
>
> But if the need to support back doors is proven to be a must, then implement
> them
> outside the main core solution, these edge cases should not block the main
> business
> logic.

I seem to remember that the one feature that sets us apart from
everybody else is that we know how to manage the bare metal. And the
current standing decision I know about is that we want to keep that
capability.

Yaniv? Is that still so?

All other solutions (OpenStack, OpenShift, ..) require you to
configure the bare metal first and then deploy virtualization. We
simplify this for the sysadmin and that makes us special (for good and
bad as Sven pointed out).

So, if we do not want to support custom rules in the engine, then the
whole host deploy script (not just firewall) needs to work very
differently, because the end goal is to have properly deployed node
for virtualization. And the "properly" word is defined both by us and
the owner sysadmin.

But deploy has to all or nothing operation, otherwise the engine will
start using half configured host and you risk someone forgetting to
run an extra script.

Martin

On Mon, Mar 27, 2017 at 7:47 PM, Edward Haas  wrote:
>
>
> On Mon, Mar 27, 2017 at 7:07 PM, Martin Sivak  wrote:
>>
>> > Clients should be made aware their custom rules are going to be obsolete
>> > and
>> > that they should reapply them once they reinstall.
>>
>> Would you want to manually fix every reinstalled host? I would
>> consider that very annoying. This has to be somewhat automatic if we
>> want to support custom firewall rules. And although I agree the engine
>> is not the right place for that, it is the only central place we have
>> and from which we are starting the reinstall task.
>
>
> But we do not want to support custom firewall rules, we are not a firewall
> manager.
> IMO, oVirt should support the hardening of its services and co-exist with
> other rules.
> Custom firewall settings imply one of these:
> - We need to extend current firewall options.
> - It needs to be implemented outside oVirt.
>
> But if the need to support back doors is proven to be a must, then implement
> them
> outside the main core solution, these edge cases should not block the main
> business
> logic.
>
>
>>
>>
>> Martin
>>
>> On Mon, Mar 27, 2017 at 4:16 PM, Leon Goldberg 
>> wrote:
>> > You're right, but I don't think it matters; hosts will remain unaffected
>> > until they're reinstalled via an upgraded Engine.
>> >
>> > Clients should be made aware their custom rules are going to be obsolete
>> > and
>> > that they should reapply them once they reinstall.
>> >
>> > On Mon, Mar 27, 2017 at 9:01 AM, Yedidyah Bar David 
>> > wrote:
>> >>
>> >> On Sun, Mar 26, 2017 at 6:01 PM, Leon Goldberg 
>> >> wrote:
>> >> > Effectively, upgrading will leave lingering (but nonetheless
>> >> > operational)
>> >> > iptables rules on the hosts. I'm not even sure there needs to be
>> >> > special
>> >> > upgrade treatment?
>> >>
>> >> Please describe the expected flow.
>> >>
>> >> Please note that at least when I tried, 'systemctl start firewalld'
>> >> stops
>> >> iptables.
>> >>
>> >> Thanks,
>> >>
>> >> >
>> >> > On Sun, Mar 26, 2017 at 4:59 PM, Yedidyah Bar David 
>> >> > wrote:
>> >> >>
>> >> >> On Sun, Mar 26, 2017 at 4:49 PM, Leon Goldberg 
>> >> >> wrote:
>> >> >> > 1) Do we actually need iptables for any reason that isn't a legacy
>> >> >> > consideration?
>> >> >>
>> >> >> No idea personally.
>> >> >>
>> >> >> Perhaps some users prefer that, and/or need that for integration
>> >> >> with
>> >> >> other
>> >> >> systems/solutions/whatever.
>> >> >>
>> >> >> If we drop iptables, how do you suggest to treat upgrades?
>> >> >>
>> >> >> >
>> >> >> > 2 & 3) I am in favor of treating custom services as a requirement
>>

Re: [ovirt-devel] Firewalld migration.

[Martin Sivak]

> Clients should be made aware their custom rules are going to be obsolete and
> that they should reapply them once they reinstall.

Would you want to manually fix every reinstalled host? I would
consider that very annoying. This has to be somewhat automatic if we
want to support custom firewall rules. And although I agree the engine
is not the right place for that, it is the only central place we have
and from which we are starting the reinstall task.

Martin

On Mon, Mar 27, 2017 at 4:16 PM, Leon Goldberg  wrote:
> You're right, but I don't think it matters; hosts will remain unaffected
> until they're reinstalled via an upgraded Engine.
>
> Clients should be made aware their custom rules are going to be obsolete and
> that they should reapply them once they reinstall.
>
> On Mon, Mar 27, 2017 at 9:01 AM, Yedidyah Bar David  wrote:
>>
>> On Sun, Mar 26, 2017 at 6:01 PM, Leon Goldberg 
>> wrote:
>> > Effectively, upgrading will leave lingering (but nonetheless
>> > operational)
>> > iptables rules on the hosts. I'm not even sure there needs to be special
>> > upgrade treatment?
>>
>> Please describe the expected flow.
>>
>> Please note that at least when I tried, 'systemctl start firewalld' stops
>> iptables.
>>
>> Thanks,
>>
>> >
>> > On Sun, Mar 26, 2017 at 4:59 PM, Yedidyah Bar David 
>> > wrote:
>> >>
>> >> On Sun, Mar 26, 2017 at 4:49 PM, Leon Goldberg 
>> >> wrote:
>> >> > 1) Do we actually need iptables for any reason that isn't a legacy
>> >> > consideration?
>> >>
>> >> No idea personally.
>> >>
>> >> Perhaps some users prefer that, and/or need that for integration with
>> >> other
>> >> systems/solutions/whatever.
>> >>
>> >> If we drop iptables, how do you suggest to treat upgrades?
>> >>
>> >> >
>> >> > 2 & 3) I am in favor of treating custom services as a requirement and
>> >> > plan
>> >> > accordingly. Many (most, even) of the services are already provided
>> >> > by
>> >> > either firewalld itself (e.g. vdsm, libvirt) or the 3rd party
>> >> > packages
>> >> > (e.g.
>> >> > gluster). Some are missing (I've recently created a pull request for
>> >> > ovirt-imageio to firewalld, for example) and I hope we'll be able to
>> >> > get
>> >> > all
>> >> > the services to be statically provided (by either firewalld or the
>> >> > relevant
>> >> > 3rd party packages).
>> >> >
>> >> > Ideally I think we'd like use statically provided services, and
>> >> > provide
>> >> > the
>> >> > capability to provide additional services (I'm not a fan of the
>> >> > current
>> >> > methodology of converting strings into xmls). I don't think we'd want
>> >> > to
>> >> > limit usage to just statically provided services. (2)
>> >> >
>> >> > As previously stated, I don't see a technical reason to keep iptables
>> >> > under
>> >> > consideration. (3)
>> >> >
>> >> >
>> >> > On Sun, Mar 26, 2017 at 2:57 PM, Yedidyah Bar David 
>> >> > wrote:
>> >> >>
>> >> >>
>> >> >> 1. Do we want to support in some version X both iptables and
>> >> >> firewalld,
>> >> >> or
>> >> >> is it ok to stop support for iptables and support only firewalld
>> >> >> without
>> >> >> overlap? If so, do we handle upgrades, and how?
>> >> >>
>> >> >> 2. Do we want to support custom firewalld xml to be configured on
>> >> >> the
>> >> >> host by us? Or is it ok to only support choosing among existing
>> >> >> services,
>> >> >> which will need to be added to the host using other means (packaged
>> >> >> by
>> >> >> firewalld, packaged by 3rd parties, added manually by users)?
>> >> >>
>> >> >> 3. Opposite of (2.): Do we want to support firewalld services that
>> >> >> are
>> >> >> added to the host using other means (see there)? Obviously we do,
>> >> >> but:
>> >> >> If we do, do we still want to support also iptables (see (1.))? And
>> >> >> if
>> >> >> so, what do we want to then happen?
>> >> >>
>> >> >> (2.) and (3.) are not conflicting, each needs its own answer.
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Didi
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Didi
>> >
>> >
>>
>>
>>
>> --
>> Didi
>
>
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Firewalld migration.

[Martin Sivak]

> Right, so why not create an Ansible playbook which the users can change
> (extend?), based on http://docs.ansible.com/ansible/firewalld_module.html ?

I think I like the playbook proposal the best.

Lets assume the engine provides a firewall.yaml playbook somewhere in /etc:

 - The default playbook would contain our default firewalld
configuration (we should also provide it in /usr/share/doc to give the
user a reference)
 - The engine or host deploy script can provide ansible variables so
the playbook can even be a parametrized one (port numbers)
 - The user can add rules he needs
 - The user can REPLACE the content with iptables rules if he wishes
so (we can even say it is unsupported, but possible)

As an extension:

 - We can provide ovirt-engine-firewalld ansible role with the default
config so we can properly update files using RPM. The user defined (or
default) playbook would just call this role and would stay intact
during package upgrades.

This is outside of database, allows customization and adapts to
whatever firewall backend we might need.

--
Martin Sivak
SLA / oVirt

On Mon, Mar 27, 2017 at 12:46 PM, Yaniv Kaul  wrote:
>
>
> On Mon, Mar 27, 2017 at 1:20 PM, Martin Perina  wrote:
>>
>>
>>
>> On Mon, Mar 27, 2017 at 12:00 PM, Yaniv Kaul  wrote:
>>>
>>>
>>>
>>> On Mon, Mar 27, 2017 at 11:55 AM, Martin Perina 
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> so personally I don't like the current way how we store firewall
>>>> configuration within engine (saving complete iptables commands as string). 
>>>> I
>>>> think should change the way how we store firewall configuration:
>>>>
>>>> 1. On engine side I'd just store which services/ports (or port ranges)
>>>> need to be enabled on host. By default only those services/ports that 
>>>> engine
>>>> needs, but we can maintain also custom services defined by users
>>>
>>>
>>> Agreed. I hope that's enough on one hand, on the other hand, users can
>>> probably easily extend it via Ansible to the hosts and execution of a more
>>> customized firewalld configuration there - we probably should not own it.
>>
>>
>> Right, we should take care only about services/ports which we need. So we
>> probably could drop the ability for users to define their own custom
>> services/ports within engine for firewalld and force them to use Ansible or
>> other tools to handle their own configuration.
>
>
> Right, so why not create an Ansible playbook which the users can change
> (extend?), based on http://docs.ansible.com/ansible/firewalld_module.html ?
> ...
>>
>>
>>>
>>>>
>>>>
>>>> 2. Write plugin to ovirt-host-deploy which will translate those
>>>> services/ports into actual firewall configuration on the host (it should
>>>> detected what firewall is currently enabled and adapt)
>
>
> ...  and then ovirt-host-deploy will be in charge of executing that
> playbook? Seems fairly straightforward.
> Y.
>
>>>
>>> Agreed.
>>>
>>>>
>>>>
>>>> 3. For newly installed host I'd just use firewalld
>>>
>>>
>>> Agreed.
>>>
>>>>
>>>>
>>>> 4. Also for 4.2 clusters I'd switch from iptables to firewalld when you
>>>> execute Reinstall (we should document this and make firewalld preferred
>>>> solution)
>>>
>>>
>>> That's a good question. If a user had the default, non-changed policy we
>>> have had in iptables - sure.
>>> If not, I think it may be a bit of a challenge to switch otherwise.
>>
>>
>> Right. We could detect if there's some custom firewall rules in
>> IPTablesConfigSiteCustom engine-config option and if not we could probably
>> assume that switching to firewalld could be performed.
>>
>> We could also mark iptables configuration as deprecated in 4.2 and declare
>> that it will be removed in 4.3. That would add some time for users to
>> prepare for the switch ...
>>
>>> Y.
>>>
>>>>
>>>>
>>>>
>>>>
>>>> Martin
>>>>
>>>>
>>>>
>>>> On Mon, Mar 27, 2017 at 8:01 AM, Yedidyah Bar David 
>>>> wrote:
>>>>>
>>>>> On Sun, Mar 26, 2017 at 6:01 PM, Leon Goldberg 
>>>>> wrote:
>>>>> > Effectively, upgrading will leave lingering (but nonetheless
>>>>> > operational)
&

Re: [ovirt-devel] Writing SQL queries in DAO code

[Martin Sivak]

I agree with Moti, but I think we might have an alternative.

Does our DAO layer support named queries (aka PreparedStatements
loaded from a properties file)? Those are generally plain SQL queries
with arguments that are compiled in advance and still allow direct
access to the JDBC internals without the heavy translation layer.

Martin

On Sun, Mar 26, 2017 at 4:12 PM, Yevgeny Zaspitsky  wrote:
> Hi All,
>
> Recently I had a task of performance improvement in one of our network
> related flows and had some hard time following our DAL code and one of the
> outcomes of the task was defining a couple of new quite simple, but neat
> queries.
> When I came to coding those new queries I remembered how hard was following
> the existing DAL code, I decided to make my own new methods clearer. So I
> created [1] and [2] patches.
>
> Everything is quite standard there beside the fact that they do not use any
> stored procedure, but use SQL directly, IMHO by that they save time that I
> spent in trying to follow what a DAO method does. Looking into the method
> code you get the understanding of what this method is all about:
>
> no looking for a stored procedure name that is buried in the DAO class
> hierarchy
> no looking for the SP definition
>
> So I'd like to propose moving towards this approach in general in all cases
> when nothing beyond a simple SQL is needed (no stored procedure programming
> language is needed).
> From my experience with the performance improvement task it looks like
> people avoid adding new queries for a specific need of a flow, instead they
> use the existing general ones (e.g. dao.getAllForX()) and do the actual join
> in the bll code.
> IMHO the proposed approach would simplify adding new specific queries and by
> that would prevent a decent part of performance issues in the future.
>
> I do not propose changing all existing SP's to inline queries in a once, but
> to allow adding new queries this way. Also we might consider converting
> relatively simple SP's to inline SQL statements later in a graduate way.
>
> [1] - https://gerrit.ovirt.org/#/c/74456
> [2] - https://gerrit.ovirt.org/#/c/74458
>
> Regards,
> Yevgeny
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] REST API data aggregation

[Martin Sivak]

> Current Apache used has only experimental module for it.
> Undertow is supposed to have a better support. I wonder when/if we can drop
> Apache...

The last info I have about that from mperina is that we need Apache
for kerberos support atm.

Martin

On Fri, Mar 24, 2017 at 5:30 PM, Yaniv Kaul  wrote:
>
>
> On Fri, Mar 24, 2017 at 6:43 PM, Martin Sivak  wrote:
>>
>> > 2: you can have more api gateways (e.g. more apis) tailored for every
>> > frontend. I don't think we need this - the current API serves us pretty
>> > well
>> > in every FE Im involved in. The only thing which I miss is the data
>> > aggregation.
>>
>> So it does not serve us well. Aggregation of data is one the usual
>> points of using the gateway.
>> Yes microservices are affected by this indeed, but so are we because
>> implementing the aggregation directly in the current engine API layer
>> is hard.
>>
>> > So I would go back to the original topic of this thread - do some small
>> > change which has a chance to be merged to the project and helps us where
>> > it
>> > hurts.
>
>
> I'm wondering if very specific additional REST API calls can suffice.
> For example, a 'Get VM + disks + NIC' API call seems reasonable to add for
> the various clients who commonly need it.
>
>>
>> Can a simple HTTP/2 to HTTP/AJP gateway be the simplest solution? Our
>> Apache might even have a module for it already.
>
>
> Current Apache used has only experimental module for it.
> Undertow is supposed to have a better support. I wonder when/if we can drop
> Apache...
> Y.
>
>>
>> That way you can multiplex all the REST calls using a single tcp
>> connection (and a single SSL negotiation).
>>
>> A custom SSO enabled service like that might be even better as it
>> would be able to skip the authentication
>> layers too and that would lower the engine load. But I am not sure it
>> is possible with the current codebase.
>>
>> Martin
>>
>> On Fri, Mar 24, 2017 at 4:22 PM, Tomas Jelinek 
>> wrote:
>> >
>> >
>> > On Fri, Mar 24, 2017 at 3:58 PM, Martin Sivak  wrote:
>> >>
>> >> > I feel like every REST API I've ever worked with has had the
>> >> > aggregation
>> >> > +
>> >> > projection problem. It's like we're trying to use REST as a
>> >> > replacement
>> >> > for
>> >> > SQL -- but the logic that executes the "SQL" lives in a browser now,
>> >> > and
>> >> > it
>> >> > used to live on a server close to the DB. And REST isn't expressive
>> >> > for
>> >> > selecting data like SQL is.
>> >>
>> >> The current industry solution I know about is called API gateway..
>> >> most of the big players have internal API with lots of low level stuff
>> >> and then couple of external API gateways tailored to what the client
>> >> needs.
>> >>
>> >> http://microservices.io/patterns/apigateway.html (check the backend
>> >> for frontend section)
>> >>
>> >> This trend is also visible when you think about services that offer
>> >> API gateway management and billing like
>> >> https://aws.amazon.com/api-gateway/ or our very own
>> >> https://www.3scale.net/
>> >
>> >
>> > right, but the api gateway solves 2 problems:
>> >
>> > 1: if you have a microservice architecture it is hard for frontend to
>> > talk
>> > to 20 different moving services. So the gateway hides this complexity
>> > behind
>> > it. This is not the problem we have.
>> >
>> > 2: you can have more api gateways (e.g. more apis) tailored for every
>> > frontend. I don't think we need this - the current API serves us pretty
>> > well
>> > in every FE Im involved in. The only thing which I miss is the data
>> > aggregation.
>> >
>> > So I would go back to the original topic of this thread - do some small
>> > change which has a chance to be merged to the project and helps us where
>> > it
>> > hurts.
>> >
>> >>
>> >>
>> >>
>> >> Martin
>> >>
>> >> On Fri, Mar 24, 2017 at 3:47 PM, Greg Sheremeta 
>> >> wrote:
>> >> > I feel like every REST API I've ever worked with has had the
>> >> > aggregation
>> >> >

Re: [ovirt-devel] REST API data aggregation

[Martin Sivak]

> 2: you can have more api gateways (e.g. more apis) tailored for every
> frontend. I don't think we need this - the current API serves us pretty well
> in every FE Im involved in. The only thing which I miss is the data
> aggregation.

So it does not serve us well. Aggregation of data is one the usual
points of using the gateway.
Yes microservices are affected by this indeed, but so are we because
implementing the aggregation directly in the current engine API layer
is hard.

> So I would go back to the original topic of this thread - do some small
> change which has a chance to be merged to the project and helps us where it
> hurts.

Can a simple HTTP/2 to HTTP/AJP gateway be the simplest solution? Our
Apache might even have a module for it already.
That way you can multiplex all the REST calls using a single tcp
connection (and a single SSL negotiation).

A custom SSO enabled service like that might be even better as it
would be able to skip the authentication
layers too and that would lower the engine load. But I am not sure it
is possible with the current codebase.

Martin

On Fri, Mar 24, 2017 at 4:22 PM, Tomas Jelinek  wrote:
>
>
> On Fri, Mar 24, 2017 at 3:58 PM, Martin Sivak  wrote:
>>
>> > I feel like every REST API I've ever worked with has had the aggregation
>> > +
>> > projection problem. It's like we're trying to use REST as a replacement
>> > for
>> > SQL -- but the logic that executes the "SQL" lives in a browser now, and
>> > it
>> > used to live on a server close to the DB. And REST isn't expressive for
>> > selecting data like SQL is.
>>
>> The current industry solution I know about is called API gateway..
>> most of the big players have internal API with lots of low level stuff
>> and then couple of external API gateways tailored to what the client
>> needs.
>>
>> http://microservices.io/patterns/apigateway.html (check the backend
>> for frontend section)
>>
>> This trend is also visible when you think about services that offer
>> API gateway management and billing like
>> https://aws.amazon.com/api-gateway/ or our very own
>> https://www.3scale.net/
>
>
> right, but the api gateway solves 2 problems:
>
> 1: if you have a microservice architecture it is hard for frontend to talk
> to 20 different moving services. So the gateway hides this complexity behind
> it. This is not the problem we have.
>
> 2: you can have more api gateways (e.g. more apis) tailored for every
> frontend. I don't think we need this - the current API serves us pretty well
> in every FE Im involved in. The only thing which I miss is the data
> aggregation.
>
> So I would go back to the original topic of this thread - do some small
> change which has a chance to be merged to the project and helps us where it
> hurts.
>
>>
>>
>>
>> Martin
>>
>> On Fri, Mar 24, 2017 at 3:47 PM, Greg Sheremeta 
>> wrote:
>> > I feel like every REST API I've ever worked with has had the aggregation
>> > +
>> > projection problem. It's like we're trying to use REST as a replacement
>> > for
>> > SQL -- but the logic that executes the "SQL" lives in a browser now, and
>> > it
>> > used to live on a server close to the DB. And REST isn't expressive for
>> > selecting data like SQL is.
>> >
>> > There must be some industry solution to this "I want to do SQL over
>> > REST"
>> > problem.
>> >
>> > On Fri, Mar 24, 2017 at 5:54 AM, Martin Sivak  wrote:
>> >>
>> >> > for quite some time I have been more or less involved in development
>> >> > of
>> >> > various UIs for oVirt based entirely on the oVirt's REST API ranging
>> >> > from
>> >> > the quite mature moVirt [1] through some cockpit extensions to a
>> >> > young
>> >> > and
>> >> > experimental user portal replacement [2].
>> >>
>> >> oVirt optimizer has the same issue..
>> >>
>> >> > 2: add some tiny service which would just accept a list of queries,
>> >> > execute
>> >> > them locally (but using real HTTP requests) and return in one bulk. A
>> >> > naive
>> >> > implementation just to give a sense of what I mean of this would be a
>> >> > shell
>> >> > script getting list of strings like
>> >> > "https://localhost/ovirt-engine/api/vms/123/sessions"; iterate over
>> >> > them
>> >> &g

Re: [ovirt-devel] REST API data aggregation

[Martin Sivak]

> I feel like every REST API I've ever worked with has had the aggregation +
> projection problem. It's like we're trying to use REST as a replacement for
> SQL -- but the logic that executes the "SQL" lives in a browser now, and it
> used to live on a server close to the DB. And REST isn't expressive for
> selecting data like SQL is.

The current industry solution I know about is called API gateway..
most of the big players have internal API with lots of low level stuff
and then couple of external API gateways tailored to what the client
needs.

http://microservices.io/patterns/apigateway.html (check the backend
for frontend section)

This trend is also visible when you think about services that offer
API gateway management and billing like
https://aws.amazon.com/api-gateway/ or our very own
https://www.3scale.net/

Martin

On Fri, Mar 24, 2017 at 3:47 PM, Greg Sheremeta  wrote:
> I feel like every REST API I've ever worked with has had the aggregation +
> projection problem. It's like we're trying to use REST as a replacement for
> SQL -- but the logic that executes the "SQL" lives in a browser now, and it
> used to live on a server close to the DB. And REST isn't expressive for
> selecting data like SQL is.
>
> There must be some industry solution to this "I want to do SQL over REST"
> problem.
>
> On Fri, Mar 24, 2017 at 5:54 AM, Martin Sivak  wrote:
>>
>> > for quite some time I have been more or less involved in development of
>> > various UIs for oVirt based entirely on the oVirt's REST API ranging
>> > from
>> > the quite mature moVirt [1] through some cockpit extensions to a young
>> > and
>> > experimental user portal replacement [2].
>>
>> oVirt optimizer has the same issue..
>>
>> > 2: add some tiny service which would just accept a list of queries,
>> > execute
>> > them locally (but using real HTTP requests) and return in one bulk. A
>> > naive
>> > implementation just to give a sense of what I mean of this would be a
>> > shell
>> > script getting list of strings like
>> > "https://localhost/ovirt-engine/api/vms/123/sessions"; iterate over them
>> > and
>> > do a curl request for each, mangle the results into one string and
>> > return
>> > (credits for this idea to msivak). Easy to implement, possibility to add
>> > also projections later to save some bandwidth. But the API would anyway
>> > be
>> > hammered by bunch of queries, only the network roundtrip would be saved.
>>
>> The biggest cost for (especially mobile) clients is the cost of
>> establishing new SSL connection. SSL is also pretty expensive on the
>> server side.
>>
>> So running the aggregation service on the ovirt-engine machine (behind
>> Apache) means the client will do a single SSL request with list of N
>> urls and the local "reverse-proxy" will perform single authentication
>> and N plain HTTP requests (or even better - AJP). It won't remove any
>> time from the actual command run time, but it will reduce protocol
>> overhead.
>>
>> I think this is the simplest first step that requires almost no change
>> to existing infrastructure.
>>
>> --
>> Martin Sivak
>> SLA / oVirt
>>
>> On Fri, Mar 24, 2017 at 10:20 AM, Tomas Jelinek 
>> wrote:
>> > Hi All,
>> >
>> > for quite some time I have been more or less involved in development of
>> > various UIs for oVirt based entirely on the oVirt's REST API ranging
>> > from
>> > the quite mature moVirt [1] through some cockpit extensions to a young
>> > and
>> > experimental user portal replacement [2].
>> >
>> > One issue we hit over and over again is the missing data aggregation. In
>> > the
>> > 3.x era we used to use in moVirt the detail=something
>> > api to get the disks and nics of the VM, something like:
>> >
>> > GET /ovirt-engine/api/vms
>> > Accept: application/json; detail=disks
>> >
>> > This allowed us to store this data in local database leading to great
>> > user
>> > experience. Since this feature has been removed in 4.x API [3]
>> > we needed to retire to a different solution. When the VM detail is
>> > selected
>> > by the user, start loading the disks and nics and hope the user
>> > will not be fast enough to see the delay. The UX is slightly worse bug
>> > kinda
>> > acceptable.
>> >
>> > We hit this issue harder in the new user porta

Re: [ovirt-devel] REST API data aggregation

[Martin Sivak]

> for quite some time I have been more or less involved in development of
> various UIs for oVirt based entirely on the oVirt's REST API ranging from
> the quite mature moVirt [1] through some cockpit extensions to a young and
> experimental user portal replacement [2].

oVirt optimizer has the same issue..

> 2: add some tiny service which would just accept a list of queries, execute
> them locally (but using real HTTP requests) and return in one bulk. A naive
> implementation just to give a sense of what I mean of this would be a shell
> script getting list of strings like
> "https://localhost/ovirt-engine/api/vms/123/sessions"; iterate over them and
> do a curl request for each, mangle the results into one string and return
> (credits for this idea to msivak). Easy to implement, possibility to add
> also projections later to save some bandwidth. But the API would anyway be
> hammered by bunch of queries, only the network roundtrip would be saved.

The biggest cost for (especially mobile) clients is the cost of
establishing new SSL connection. SSL is also pretty expensive on the
server side.

So running the aggregation service on the ovirt-engine machine (behind
Apache) means the client will do a single SSL request with list of N
urls and the local "reverse-proxy" will perform single authentication
and N plain HTTP requests (or even better - AJP). It won't remove any
time from the actual command run time, but it will reduce protocol
overhead.

I think this is the simplest first step that requires almost no change
to existing infrastructure.

--
Martin Sivak
SLA / oVirt

On Fri, Mar 24, 2017 at 10:20 AM, Tomas Jelinek  wrote:
> Hi All,
>
> for quite some time I have been more or less involved in development of
> various UIs for oVirt based entirely on the oVirt's REST API ranging from
> the quite mature moVirt [1] through some cockpit extensions to a young and
> experimental user portal replacement [2].
>
> One issue we hit over and over again is the missing data aggregation. In the
> 3.x era we used to use in moVirt the detail=something
> api to get the disks and nics of the VM, something like:
>
> GET /ovirt-engine/api/vms
> Accept: application/json; detail=disks
>
> This allowed us to store this data in local database leading to great user
> experience. Since this feature has been removed in 4.x API [3]
> we needed to retire to a different solution. When the VM detail is selected
> by the user, start loading the disks and nics and hope the user
> will not be fast enough to see the delay. The UX is slightly worse bug kinda
> acceptable.
>
> We hit this issue harder in the new user portal [2], because we already have
> the VM cached and show the whole VM in one screen. So, if you pick it, you
> will get it's details immediately.
> But, since you don't have all the details, we need to do an additional call
> (two actually) to load this data and they start to appear later.
> So, something which would be very fast and smooth starts to feel sluggish.
>
> Recently, we hit this issue again which forced us to sacrifice the UX even
> more - it is the "console in use" feature of user portal.
> The use case is this:
> - if the console is already taken by some user, there are complications if
> other current user tryes to take it as well (will avoid details about
> settings and permissins involved, but long story short, the user will
> probably not be allowed to connect to it. The "probably" is the key here
> since we can not do any intelligent decision in advance, we can only warn
> the user that the console is taken).
> - in the current GWT user portal, if the VM's console is taken, it is shown
> on the VM's "box" that "console is taken". This was a highly requested
> feature
> - to get this information using the current REST API, we need to go to the
> /vms//sessions subcollection. To get this for all VMs, it would be
> doing N queries per poll which we can not afford
> - so the current PR [4] will probably end up to only check it on the attempt
> to connect to the console warning the user. Maybe it will be also shown in
> Vm details. But the UX in case the user will look for a VM which has free
> console will suffer significantly (e.g. try one by one until some opens or
> look at details one by one to see if the warning appears (with a delay))
>
> I understand that embedding the details of the VM to the response comes with
> a cost, namely:
> - performance hit
> - complexity of the API code
> - the "cleanness" of REST suffers
>
> But I think we should seriously consider to provide some option to data
> aggregation.
>
> I know this has been discussed many times with no result, but I thi

Re: [ovirt-devel] Introducing engine micro-benchmarks

[Martin Sivak]

Hi,

I am just wondering whether you tried Roman's Hystrix integration to
see what command was so slow?

Martin

On Thu, Mar 23, 2017 at 11:05 AM, Roy Golan  wrote:
> Lately we came across an interesting case where multi-host+mult-networks
> resulted editing a host to conclude in minutes. One assumption that was
> raised which we wanted to eliminate was that the decryption we perform on a
> fence agent password might be taking too long.
>
> So these days it's an easy task thanks to JMH[1], supplied by the jdk
> itself. I kickstarted [2] and added a 'DecryptionBenchmark', see the output
> as an example[3]
>
> Although The JMH project recommends to create a separate project I find it
> would be less trivial to people to contribute benchmarks let alone just
> playing around with current code they want to test.
>
> - So, (when it will be merged) you add your benchmark under
>  backend/manager/modules/benchmarks/MyBenchmark.java
>
> - run it from intellij using the jmh plugin exactly like a unit-test
> OR
> - mvn test -P benchmarks -pl org.ovirt.engine:benchmarks
> OR
> - java -jar benchmarks.jar
>
> I hope this would serve all of us well, please review and add your
> benchmarks.
>
> PS - this will not run in the CI atm.
>
> [1] http://openjdk.java.net/projects/code-tools/jmh/
> [2] https://gerrit.ovirt.org/74537 microbenchmarks: Introduce
> microbenchmarks using JMH
> [3] DecryptionBenchmark output (short version):
>
> # Run complete. Total time: 00:09:06
>
> Benchmark Mode  SamplesScore  Score error
> Units
> b.DecryptionBenchmark.decryption thrpt   50  101.2581.270
> ops/s
> b.DecryptionBenchmark.encryption thrpt   50  238.5874.667
> ops/s
> b.DecryptionBenchmark.decryption  avgt   500.0100.000
> s/op
> b.DecryptionBenchmark.encryption  avgt   500.0040.000
> s/op
> b.DecryptionBenchmark.decryptionsample 55440.0100.000
> s/op
> b.DecryptionBenchmark.encryptionsample130670.0040.000
> s/op
> b.DecryptionBenchmark.decryptionss   500.0140.001
> s
> b.DecryptionBenchmark.encryptionss   500.0090.001
> s
>
> Process finished with exit code 0
>
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] HE setup failure

[Martin Sivak]

I see https://bugzilla.redhat.com/show_bug.cgi?id=1101554 as VERIFIED
so I guess it is.

Martin

On Thu, Mar 9, 2017 at 2:11 PM, Nir Soffer  wrote:
> Sahina, Martin, can you confirm that this issue is resolved now?
>
> On Mon, Feb 13, 2017 at 2:22 PM, Martin Sivak  wrote:
>> Hi,
>>
>> we saw this last week, I think there was a place in setup that was not
>> moved to jsonrpc, I think Simone is handling that:
>>
>> https://gerrit.ovirt.org/#/c/72068/
>>
>> Martin
>>
>> On Mon, Feb 13, 2017 at 1:20 PM, Nir Soffer  wrote:
>>> On Mon, Feb 13, 2017 at 1:45 PM, Sahina Bose  wrote:
>>>>
>>>> Hi all,
>>>>
>>>> The HE setup fails in ovirt-system-tests while deploying HE on
>>>> hyperconverged gluster setup using master
>>>>
>>>> Error :
>>>> Failed to execute stage 'Misc configuration': >>> localhost:54321/RPC2: 400 Bad Request>"
>>>>
>>>> Traceback from hosted-engine log:
>>>> ProtocolError: 
>>>>   File
>>>> "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/storage_backends.py",
>>>> line 279, in create_volume
>>>> volUUID=volume_uuid
>>>>   File
>>>> "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/storage_backends.py",
>>>> line 245, in _get_volume_path
>>>> volUUID
>>>>   File "/usr/lib64/python2.7/xmlrpclib.py", line **FILTERED**3, in
>>>> __call__
>>>> return self.__send(self.__name, args)
>>>>   File "/usr/lib64/python2.7/xmlrpclib.py", line 1587, in __request
>>>> verbose=self.__verbose
>>>>   File "/usr/lib64/python2.7/xmlrpclib.py", line 1273, in request
>>>> return self.single_request(host, handler, request_body, verbose)
>>>>   File "/usr/lib64/python2.7/xmlrpclib.py", line 1321, in single_request
>>>> response.msg,
>>>> ProtocolError: 
>>>>
>>>> Is this a regression?
>>>
>>>
>>> xmlrpc was deprecated in 3.6, and we disabled it in master:
>>> https://github.com/oVirt/vdsm/commit/1350c887f75b2ac9a095e1662c87b1212f702248
>>>
>>> You must use jsonrpc to talk with vdsm.
>>>
>>> I know that hosted engine moved to jsonrpc in 4.1 - maybe you are using
>>> an older version of hosted engine?
>>>
>>> Nir
>>>
>>>>
>>>>
>>>>
>>>> ___
>>>> Devel mailing list
>>>> Devel@ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>>
>>>
>>> ___
>>> Devel mailing list
>>> Devel@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [REQUEST FOR COMMENTS] oVirt features tracking and documentation

[Martin Sivak]

How are we going to track possible contributions from the community?
Those won't have any bugzilla associated in general. And we want them
and we want to lower the hurdle for other people to contribute.
Especially for the side projects we have (the engine is quite a beast,
but we have smaller or new projects where it is not that hard to
contribute).

Projects using GitHub track everything using pull requests. Those
generally serve as the umbrella for all the associated changes and
issues. We do not have anything like that. Bugzilla maps to issues and
Gerrit changes map to the code part of pull requests. We do not have
the documentation and design in the sources either so we can't check
for those to be provided together with the patch.

--
Martin Sivakl
oVirt / SLA

On Wed, Feb 22, 2017 at 3:43 PM, Yaniv Dary  wrote:
> As long as a RFE is created at some point for tracking the testing and docs
> I don't mind letting them in.
> If no RFE is created it will get lost and no one will probably use the
> feature, which will be a waste of time for the developer working on that.
> Feature page can probably be a good option to automate a required url, since
> this is also a good option to provide details on the work being done.
>
> Yaniv Dary
> Technical Product Manager
> Red Hat Israel Ltd.
> 34 Jerusalem Road
> Building A, 4th floor
> Ra'anana, Israel 4350109
>
> Tel : +972 (9) 7692306
> 8272306
> Email: yd...@redhat.com
> IRC : ydary
>
>
> On Tue, Feb 21, 2017 at 1:01 PM, Sandro Bonazzola 
> wrote:
>>
>>
>>
>> On Tue, Feb 21, 2017 at 11:56 AM, Michal Skrivanek
>>  wrote:
>>>
>>>
>>> On 21 Feb 2017, at 09:36, Eyal Edri  wrote:
>>>
>>>
>>>
>>> On Tue, Feb 21, 2017 at 10:34 AM, Sandro Bonazzola 
>>> wrote:



 On Tue, Feb 21, 2017 at 9:31 AM, Eyal Edri  wrote:
>
>
>
> On Tue, Feb 21, 2017 at 10:20 AM, Sandro Bonazzola
>  wrote:
>>
>> Hi,
>> I'm facing a new challenge today, I see new features getting pushed to
>> oVirt gerrit intentionally out of bugzilla.
>> The specific case is not really relevant, but just for reference:
>> https://gerrit.ovirt.org/#/c/65761/ .
>> Looks like we'll see features getting merged without any RFE opened in
>> bugzilla for them.
>>>
>>>
>>> this is a common case for master, many patches do not have Bug-Url
>>> including features initially
>>>
>> With current workflow, auto-generating release notes from bugzilla
>> doc-texts. this means they won't ever be documented.
>>>
>>>
>>> true. Typically they don’t have to be as for user consumable features
>>> there is typically many patches, and eventually the final part of feature do
>>> have proper tracking, RFE and so on.
>>>
>>
>> I'd like to open this public discussion getting comments about how
>> things will be handled.
>
>
> We can start enforcing bug-url in master branch as well, maybe under
> certain conditions.
>>>
>>>
>>> I do not see the current practice as problematic
>>>

 The issue here is that the decision is to not use bugzilla and use
 something different like trello.
 So enforcing bug-url will collide with the decision from the feature
 owner team.
>>>
>>>
>>> If there is an official decision ( I havn't heard on such ) to move to
>>> another issue tracker for some of the projects then it needs to be planned,
>>>
>>>
>>> Some of the projects decided not to use bugzilla. It’s a project
>>> decision, not an “official” decision affecting other projects.
>>> In this case the reason is that a supposed feature triggered a code
>>> change in a side project using bugzilla.
>>
>>
>> Fair enough for me.
>>
>>
>>>
>>> I would say in that case it either deserves a bugzilla on that side
>>> project, or we decide it’s not important, not a substantial part of the
>>> whole feature, and therefore doesn’t need to be documented/tracked in that
>>> side project and use Bug-Url-less commit to master.
>>>
>>> and maybe consider adding tools/verification for the new tools.
>>>
>>>
>>> But it doesn't make sense to start supporting more than one issue
>>> tracker, we have too many systems already, so if we move, then all projects
>>> needs to move.
>>>
>>>
>>> github issue is fairly common so if we want to support something else in
>>> addition to bugzilla Bug-Url this would be a good candidate
>>>
>>> Thanks,
>>> michal
>>>
>>>



>
>
>>
>> Thanks,
>>
>> --
>> Sandro Bonazzola
>> Better technology. Faster innovation. Powered by community
>> collaboration.
>> See how it works at redhat.com
>>
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>
>
>
>
> --
> Eyal Edri
> Associate Manager
> RHV DevOps
> EMEA ENG Virtualization R&D
> Red Hat Israel
>
> phone: +972-9-7692018
> irc: eedri (on #tlv #rhev-dev #rhev-in

Re: [ovirt-devel] OST: HE vm does not restart on HC setup

[Martin Sivak]

Btw, this whole thing is probably the oldest untouched piece of hosted
engine we have. It worked till now :)

Martin

On Wed, Feb 22, 2017 at 3:38 PM, Martin Sivak  wrote:
>> broke HA. Could you perhaps fixing it checking that the message *begins*
>> with that string, and/or checking the error code. bests,
>
> Already done:
>
> https://gerrit.ovirt.org/#/c/72791/
>
> Martin
>
> On Wed, Feb 22, 2017 at 3:32 PM, Francesco Romani  wrote:
>> On 02/22/2017 01:53 PM, Simone Tiraboschi wrote:
>>
>>
>>
>> On Wed, Feb 22, 2017 at 1:33 PM, Simone Tiraboschi 
>> wrote:
>>>
>>> When ovirt-ha-agent checks the status of the engine VM we get:
>>>
>>> 2017-02-21 22:21:14,738-0500 ERROR (jsonrpc/2) [api] FINISH getStats
>>> error=Virtual machine does not exist: {'vmId':
>>> u'2ccc0ef0-cc31-45b8-8e91-a78fa4cad671'} (api:69)
>>> Traceback (most recent call last):
>>>   File "/usr/lib/python2.7/site-packages/vdsm/common/api.py", line 67, in
>>> method
>>> ret = func(*args, **kwargs)
>>>   File "/usr/share/vdsm/API.py", line 335, in getStats
>>> vm = self.vm
>>>   File "/usr/share/vdsm/API.py", line 130, in vm
>>> raise exception.NoSuchVM(vmId=self._UUID)
>>> NoSuchVM: Virtual machine does not exist: {'vmId':
>>> u'2ccc0ef0-cc31-45b8-8e91-a78fa4cad671'}
>>>
>>> While in ovirt-ha-agent logs we have:
>>>
>>> MainThread::INFO::2017-02-21
>>> 22:21:18,583::hosted_engine::453::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(start_monitoring)
>>> Current state UnknownLocalVmState (score: 3400)
>>>
>>> ...
>>>
>>> MainThread::INFO::2017-02-21
>>> 22:21:31,199::state_decorators::25::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(check)
>>> Unknown local engine vm status no actions taken
>>>
>>> Probably it's a bug or a regression somewhere on master.
>>
>> On ovirt-ha-broker side the detection is based on a strict string match on
>> the error message that is expected to be exactly 'Virtual machine does not
>> exist' to set down status otherwise we set unknown status as in this case:
>> https://gerrit.ovirt.org/gitweb?p=ovirt-hosted-engine-ha.git;a=blob;f=ovirt_hosted_engine_ha/broker/submonitors/engine_health.py;h=d633cb860b811e84021221771bf706a9a4ac1d63;hb=refs/heads/master#l54
>>
>> Adding Francesco here to understand if something has recently changed there
>> on vdsm side.
>>
>> It has changed indeed; we had a series of changes which added context to
>> some exceptions. I believe the straw who broke the camel's back was
>> I32ec3f86f8d53f8412f4c0526fc85e2a42e30ea5 It is unfortunate that this change
>> broke HA. Could you perhaps fixing it checking that the message *begins*
>> with that string, and/or checking the error code. bests,
>>
>> --
>> Francesco Romani
>> Red Hat Engineering Virtualization R & D
>> IRC: fromani
>>
>>
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] OST: HE vm does not restart on HC setup

[Martin Sivak]

> broke HA. Could you perhaps fixing it checking that the message *begins*
> with that string, and/or checking the error code. bests,

Already done:

https://gerrit.ovirt.org/#/c/72791/

Martin

On Wed, Feb 22, 2017 at 3:32 PM, Francesco Romani  wrote:
> On 02/22/2017 01:53 PM, Simone Tiraboschi wrote:
>
>
>
> On Wed, Feb 22, 2017 at 1:33 PM, Simone Tiraboschi 
> wrote:
>>
>> When ovirt-ha-agent checks the status of the engine VM we get:
>>
>> 2017-02-21 22:21:14,738-0500 ERROR (jsonrpc/2) [api] FINISH getStats
>> error=Virtual machine does not exist: {'vmId':
>> u'2ccc0ef0-cc31-45b8-8e91-a78fa4cad671'} (api:69)
>> Traceback (most recent call last):
>>   File "/usr/lib/python2.7/site-packages/vdsm/common/api.py", line 67, in
>> method
>> ret = func(*args, **kwargs)
>>   File "/usr/share/vdsm/API.py", line 335, in getStats
>> vm = self.vm
>>   File "/usr/share/vdsm/API.py", line 130, in vm
>> raise exception.NoSuchVM(vmId=self._UUID)
>> NoSuchVM: Virtual machine does not exist: {'vmId':
>> u'2ccc0ef0-cc31-45b8-8e91-a78fa4cad671'}
>>
>> While in ovirt-ha-agent logs we have:
>>
>> MainThread::INFO::2017-02-21
>> 22:21:18,583::hosted_engine::453::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(start_monitoring)
>> Current state UnknownLocalVmState (score: 3400)
>>
>> ...
>>
>> MainThread::INFO::2017-02-21
>> 22:21:31,199::state_decorators::25::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(check)
>> Unknown local engine vm status no actions taken
>>
>> Probably it's a bug or a regression somewhere on master.
>
> On ovirt-ha-broker side the detection is based on a strict string match on
> the error message that is expected to be exactly 'Virtual machine does not
> exist' to set down status otherwise we set unknown status as in this case:
> https://gerrit.ovirt.org/gitweb?p=ovirt-hosted-engine-ha.git;a=blob;f=ovirt_hosted_engine_ha/broker/submonitors/engine_health.py;h=d633cb860b811e84021221771bf706a9a4ac1d63;hb=refs/heads/master#l54
>
> Adding Francesco here to understand if something has recently changed there
> on vdsm side.
>
> It has changed indeed; we had a series of changes which added context to
> some exceptions. I believe the straw who broke the camel's back was
> I32ec3f86f8d53f8412f4c0526fc85e2a42e30ea5 It is unfortunate that this change
> broke HA. Could you perhaps fixing it checking that the message *begins*
> with that string, and/or checking the error code. bests,
>
> --
> Francesco Romani
> Red Hat Engineering Virtualization R & D
> IRC: fromani
>
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel