[ovirt-devel] Nominate Sharon and Michal as ovirt-engine-nodejs-modules maintainers

[Vojtech Szocs]

Hi everyone,

I'd like to nominate Sharon and Michal as ovirt-engine-nodejs-modules
 project
maintainers.

This project is a build-time dependency of oVirt web-related projects,
providing the required npm (JavaScript) dependencies via single RPM package.

Projects that depend on ovirt-engine-nodejs-modules include (see here

for
details):

   - ovirt-web-ui  (next-gen User
   Portal)
   - ovirt-engine-ui-extensions
    (UI
   plugin for Admin Portal)
   - cockpit-ovirt
 (plugins
   for Cockpit)

Both Sharon and Michal are familiar with these projects and having them as
maintainers would help with resolving any issues related to oVirt JS
dependencies.

Thanks,
Vojtech
___
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/S3ULX7EQZ7YHRM6TWUUY26VOHNQZE43I/

[ovirt-devel] Re: oVirt Dashboard issues

[Vojtech Szocs]

Hi Hetz,

the Dashboard page is used to visualize data collected from two sources:

   - Engine DB
   - inventory data, rendered as "status cards" (or "cubes" as you call
  them) located at the top
   - Data Warehouse (DWH) DB
  - global utilization data, rendered as "utilization cards" (the
  "cubes" in the middle) and "heat maps" at the bottom

with Engine server caching both types of data. By default, inventory data
is refreshed every 60sec and the utilization data is refreshed every 5min.

> * the errors/warning cube doesn't update so much even after cleaning and
waiting an hour or 2

The Dashboard page doesn't refresh its data automatically (yet) but there's
a refresh button & "Last Updated" label in the top left corner. As
mentioned above, the top-most status cards should have their (cached) data
updated every 60sec.

> * Cluster cube shows "1 cluster" but also "N/A" even when my cluster is
up with 2 machines (with DNS names).

The "N/A" text shown in Cluster status card simply means that we aren't
tracking status (up/down/etc.) for the Cluster object within the Dashboard.

> * The memory calculation is wrong - it still shows 503.5 GB even if 1
node is down for maintenance (which means I need to see something like
220GB)

This is part of the utilization card, which means it takes its data from
DWH. As Greg wrote, please check your DWH setup
.
Are you running DWH on Engine machine or on a different machine?

Regards,
Vojtech


On Fri, Jul 27, 2018 at 1:09 PM, Hetz Ben Hamo  wrote:

> Care to share how to check?
>
> תודה,
> *חץ בן חמו*
> אתם מוזמנים לבקר בבלוג היעוץ  או בבלוג הפרטי שלי
> 
>
> On Fri, Jul 27, 2018 at 2:08 PM, Greg Sheremeta 
> wrote:
>
>> It sounds like your dwh database is not updating. Can you check that?
>>
>> Greg
>>
>> On Fri, Jul 27, 2018 at 5:41 AM Hetz Ben Hamo  wrote:
>>
>>> Hi,
>>>
>>> Whats up with the oVirt Dashboard? it has few problems:. You can see my
>>> Dashboard here: https://imgur.com/a/n4IWppe
>>>
>>> * the errors/warning cube doesn't update so much even after cleaning and
>>> waiting an hour or 2
>>> * Cluster cube shows "1 cluster" but also "N/A" even when my cluster is
>>> up with 2 machines (with DNS names).
>>> * The memory calculation is wrong - it still shows 503.5 GB even if 1
>>> node is down for maintenance (which means I need to see something like
>>> 220GB)
>>>
>>> Should I open bugs on all of them in 1 bugzilla? if so, on which product?
>>>
>>> Thanks,
>>> Hetz
>>> ___
>>> 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/communit
>>> y/about/community-guidelines/
>>> List Archives: https://lists.ovirt.org/archiv
>>> es/list/devel@ovirt.org/message/BZUKLSBOWZPMHYU7XDDUX6LOZULMFNCG/
>>>
>>
>>
>> --
>>
>> 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/TI5CCSL4NXTKHWNGRFNGPKEJWHO27OQ5/
>
>
___
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/WNVQ2PPTNWGC5R3QTG3RMJDV3OCUWRWX/

[ovirt-devel] Re: [ACTION REQUIRED] CSS changes in webadmin

[Vojtech Szocs]

On Sun, Jul 8, 2018 at 4:51 PM, Greg Sheremeta  wrote:

> Hi all,
>
> We are actively moving away from GWT and towards react [
> https://reactjs.org/] in webadmin, so the CSS needs to be in a place
> where both can access it.
>

Right, whenever you need to add new UI bits (i.e. as part of implementing
some feature) into WebAdmin - please do so via the ​
ovirt-engine-ui-extensions

project if possible. It's an oVirt UI plugin
 meant
to contain various types of UI extensions, including the Dashboard (and
effectively replacing the ovirt-engine-dashboard

dependency in 4.3/master Engine).

​If you need to modify some existing WebAdmin dialog and the change is not
trivial, please consider the possibility to re-implement bits of (or even
the entire) dialog in React. We have already implemented a new version of
"Migrate VM(s)" dialog within the ui-extensions project [1] - it will soon
replace the corresponding GWT dialog code. What seems too complex in
GWT/Java doesn't have to be that complex in React/JavaScript!

[1]
https://github.com/oVirt/ovirt-engine-ui-extensions/tree/master/src/components/modals/vm

And if the given UI component is important/useful enough, we can
​contribute it to patternfly-react
 and use it in other
projects as necessary. (For example, sharing common UI components with VM
Portal .)


> Moving forward, please avoid using any and all of GWT's CSS features when
> working in webadmin. This new(ish) place is sass: [
> https://github.com/oVirt/ovirt-engine/tree/master/
> frontend/brands/ovirt-brand/src/main/sass]
>
> Sass is easy to use, and hopefully the structure makes sense.
>
> So --
> don't use
> ​​
> 
> nor addStyleNames="{style.whatever}">
>
> instead,
> 
> more examples here [1]
> (prefix == the sass file name)
>

​Currently, most WebAdmin CSS is baked into the GWT application - using
​ scopes it to the given widget. As Greg wrote above, moving
forward, we'd like to share the common styling between core UI and other
projects - and we can do it via Engine branding infra. For example:


http://localhost:8080/ovirt-engine/webadmin/theme/00-ovirt.brand/common.css

contains all styles as declared in:


​/path/to/ovirt-engine/frontend/brands/ovirt-brand/src/main/sass/common.scss

​Note: ​"ovirt-brand" is the name of the default branding package. This is
generally how we can facilitate CSS sharing, produced by core UI and
consumed by others. As for the opposite direction (common CSS produced by
others and consumed by core UI and/or others), we could add new branding
package to contain the extra CSS.


> For programmatic manipulation, simply hardcode style names in Java code
> and don't use GWT's Style:
> widget.addClassName("notif_someClassName")
> etc.
>
> Best wishes,
> Greg
>
>
> [1] https://github.com/oVirt/ovirt-engine/blob/
> f14587eb9deab300c31247b6941a2d67da1edcea/frontend/webadmin/
> modules/webadmin/src/main/java/org/ovirt/engine/ui/
> webadmin/section/main/view/NotificationView.ui.xml
>
> Sass package:
> https://github.com/oVirt/ovirt-engine/tree/master/
> frontend/brands/ovirt-brand/src/main/sass
>
>
> --
>
> 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/G4XP5R7RPVNRCDDAX56EM3DK4BVXWJF2/
>
>
___
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/63KFQTCPTJC7AFA6KADQL2JGBCRKYEKB/

[ovirt-devel] Re: blog on asking questions

[Vojtech Szocs]

Thanks for sharing!

As with everything in life, there should be some degree of balance.
Extremes are not good, and every single person is different - one might
give great results when working uninterrupted, while other might excel at
doing various things in & out of the usual-work bubble.

The key to a productive team, in my opinion, is getting to know the people
and guiding/leading them to utilize their individual strengths. You'll
likely end up with a diverse skill set & way of working for every person in
your team. Getting from zero to a very productive team takes time and
everyone getting to know each other. It's important not to try to make
every single member of your team work in the same way - instead, identify
the strengths/weaknesses and adapt accordingly.

When it comes to asking for help when stuck on some problem, the key is to
create an encouraging environment where people assist each other. If one
team member gets stuck, it hurts the team as a whole. People with lots of
knowledge and experience should share it with others and help them become
better. It's not a competition on "who's the best developer" or "who can do
tasks in the shortest timeframe", it's about evolving your team into a
productive unit where people help each other out.

And there is no shame in saying "I'm stuck on this problem, please help
me". People eventually get better at what they do. Eventually, there's only
one difference between a beginner and a master - the master has failed more
times than the beginner has even tried.

​Regards,​
​Vojtech​


On Thu, Jul 12, 2018 at 2:19 AM, Greg Sheremeta  wrote:

> wanted to share :)
>
> "Software folk are very good at putting their headphones on and living in
> their own little bubbles. This reinforces the idea that software
> development is some sort of mythical or sacred practice that should never
> be interrupted, and it makes people second guess whether they should ask
> for help. This isn’t what you want in a team. You want people to be
> comfortable asking for help – that can be the difference between a
> successful & productive team who ask for help as soon as they’re stuck, and
> an unproductive team who struggle with their work in silence."
>
> from https://wildlyinaccurate.com/becoming-a-team-lead-a-survival-guide/
>
> I love helping everyone, and I know most people love to help, but my usual
> first reaction to needing help is to resist asking. After 5 years on the
> team I'm starting to get more comfortable lol :)
>
> --
>
> 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/WN7ZN34BT6LZW5KHQGDWXY5NNELMWATS/
>
>
___
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/H5RMXTCEMI6GMZVFTDUJ5AMKWHKFTAXC/

[ovirt-devel] UI plugin API updates

[Vojtech Szocs]

Hi everyone, just a heads-up on recent UI plugin API changes.


*oVirt 4.2*

4.2.5+ will support "icon" option when adding new menu item & content via
addMainTab API function [1]. Both Font Awesome and PatternFly icons are
supported [2].

  api.addMainTab('Test', 'fooBar', 'plugin/plugin-name/test.html', {
icon: 'fa-lock'
// icon: 'pficon-security'
  });

[1] https://bugzilla.redhat.com/1591730
[2] https://www.patternfly.org/styles/icons/


*oVirt** master*

You can now use showToast API function [3] to render "toast" notifications
in top right corner of the page.

  api.showToast('success', 'Operation completed successfully.');

The first parameter can be "info" (white), "success" (green), "warning"
(yellow) or "danger" (red).

[3] https://gerrit.ovirt.org/#/c/92354/


Regards,
Vojtech
___
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/7EYAQRF46GXGUL6DYWP7EPZNJ6HPIYHE/

Re: [ovirt-devel] How To Construct An Local Developing Enviroment?

[Vojtech Szocs]

On Thu, Apr 5, 2018 at 1:53 PM, Petr Kotas  wrote:

> Hi,
>
> you can take a look at my env here https://github.com/petrkotas/
> ovirt-dev-env
>

​Thanks Petr for sharing this!


>
>
> it is not complete and there is still some work left.
>
> Feel free to contact me if you have any questions.
>
> Best,
> Petr
>
> On Tue, Apr 3, 2018 at 12:56 PM, sundw 
> wrote:
>
>> Hi Guys!
>> I plan to construct an local developing environment for oVirt.
>> But I can not find any relative pages from the web site(www.ovirt.org).
>> Maybe I am not patient :).
>>
>> Could you please give me some advice or some links about
>> How To Construct An Local Developing Enviroment?
>>
>> Thanks!
>>
>> --
>> *孙大巍*
>> 北京科银京成技术有限公司/新产品研发部
>> 13378105625
>>
>> ___
>> 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

[ovirt-devel] UI plugin API updates

[Vojtech Szocs]

Dear community,

the UI plugin API will be updated to reflect recent oVirt web
administration UI design changes.

The relevant patch is already merged in master branch [1] and the
associated BZ [2] is targeted for 4.3 release.

*What's new*

Two new API functions, addPrimaryMenuContainer and addSecondaryMenuPlace,
allow you to add custom secondary menu items to the vertical navigation
menu. You can target both existing (core) and custom primary menu items
when adding secondary ones.

*What's changed*

Some API functions were renamed to stay consistent with current UI design,
i.e. reflecting the absence of "main" and "sub" tabs.

   - addMainTab => addPrimaryMenuPlace
   - addSubTab => addDetailPlace
   - setTabContentUrl => setPlaceContentUrl
   - setTabAccessible => setPlaceAccessible
   - addMainTabActionButton => addMenuPlaceActionButton
   - addSubTabActionButton => addDetailPlaceActionButton

You can still use the original functions mentioned above, but doing so will
yield a warning in the browser console, for example:

*addMainTab is deprecated, please use addPrimaryMenuPlace instead.*


In addition, for functions that used to deal with "main" or "sub" tabs, the
options object no longer supports alignRight (boolean) parameter. That's
because PatternFly tabs widget [3] expects all tabs to be aligned next to
each other, flowing from left to right.

We'll be updating the UI plugins feature page shortly to reflect all the
changes.

[1] https://gerrit.ovirt.org/#/c/88690/
[2] https://bugzilla.redhat.com/1553902
[3] http://www.patternfly.org/pattern-library/widgets/#tabs

Regards,
Vojtech
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Browser Bookmarkable places

[Vojtech Szocs]

On Thu, Jan 18, 2018 at 5:34 PM, Alexander Wels  wrote:

> Hi,
>
> I just merged [1] into master, this patch will allow you to use browser
> bookmarks to save your current location in the application and return to it
> later. Basically the current entity and place are synchronized into the URL
> bar of your browser, which together with some previous infra structure
> allows
> you to use your browsers bookmark to go directly to an entity from being
> logged out. The same is true for search queries on main views.
>

​Nice work!

If the user isn't already logged in, they will be redirected to SSO login
page and then back to desired application URL​.


>
> Alexander
>
> [1] https://gerrit.ovirt.org/c/86496/
> ___
> 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

[Vojtech Szocs]

Hello Martin,

UI plugin API in 4.2 should be generally backwards compatible with 4.1.

Comparing PluginManager.java between master and 4.1.8 - the
exposePluginApi() function is exactly the same for now.

However, we might do some API changes in the future, mainly due to 4.2 UI
redesign. For example:

   - taking out the word "Tab" out of function names, since the UI concept
   of "main tab" is no more
   - as mentioned by Alex, support adding buttons inside kebab drop-down,
   as opposed to adding them directly to the toolbar (UX wise, important
   things should be outside kebab, less important things should go inside it)
   - support adding secondary level menu items when adding new "main tab"
   (this should become "add menu item" function)
   - support customizing the icon for primary menu items

As for the visuals, as Greg wrote, UI plugins should generally follow the
PatternFly styling to ensure consistent looks.

WebAdmin has its own branding infra and UI plugins can use that. Just
inspect the HTML source and see how WebAdmin requests PatternFly & branding
related assets.

Vojtech


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

Re: [ovirt-devel] alerts in webadmin UI

[Vojtech Szocs]

On Tue, Nov 28, 2017 at 3:24 AM, Greg Sheremeta  wrote:

>
>
> On Mon, Nov 27, 2017 at 9:22 PM, Greg Sheremeta 
> wrote:
>
>> Hi,
>>
>> If you create new "alert" messages in the webadmin UI, or you are working
>> near some code that has an alert, please use the PatternFly alert widget
>> instead of rendering a plain (or red) label.
>>
>> Example:
>> http://www.patternfly.org/pattern-library/communication/inli
>> ne-notifications/
>>
>> Widget:
>>
>
> Oops, wrong link. Should be:
> https://github.com/oVirt/ovirt-engine/blob/master/
> frontend/webadmin/modules/gwt-common/src/main/java/org/
> ovirt/engine/ui/common/widget/panel/AlertPanel.java
>

You can still use ​AlertManager in case you'd like to display
application-wide alert messages, rendered in top center part of the page,
with optional auto-hide behavior. UI runtime errors, for example, are
rendered this way.

Or use AlertPanel directly if the message is local to the given UI
component, ideally from within ui.xml file, for example:
https://github.com/oVirt/ovirt-engine/blob/master/frontend/webadmin/modules/webadmin/src/main/java/org/ovirt/engine/ui/webadmin/section/main/view/MainEngineErrataView.ui.xml


>
>
>>
>>
>> So instead of this:
>>
>> [image: Inline image 2]
>>
>>
>>
>> Do this:
>> [image: Inline image 1]
>>
>>
>> Thanks!
>>
>> Best wishes,
>> Greg
>>
>> --
>>
>> GREG SHEREMETA
>>
>> SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX
>>
>> Red Hat NA
>>
>> 
>>
>> gsher...@redhat.comIRC: gshereme
>> 
>>
>
>
>
> ___
> 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] [webadmin] Fixed a bug when pressing Enter while focused on dialog field

[Vojtech Szocs]

Hi,

when there's a dialog open and you're focused on some input (e.g. text)
field and then press Enter, dialog's model is now properly updated with
input's value before the dialog View's flush() method runs. See
https://gerrit.ovirt.org/#/c/82944/ for details.

Regards,
Vojtech
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] blog post: quick(er) development / testing of GWT code using SDM

[Vojtech Szocs]

Nice blog post, disabling source maps is a great idea to improve Super Dev
Mode experience.

For a quick change/recompile/refresh workflow, SDM is better than the usual
GWT Java-based debugger.

Vojtech


On Sun, Aug 27, 2017 at 11:45 PM, Greg Sheremeta 
wrote:

> Hi,
>
> I wrote a blog post detailing how to use GWT SDM to let you change GWT
> code and see the results in a few seconds.
>
> http://www.ovirt.org/blog/2017/08/ovirt-webadmin-gwt-debug-quick-refresh/
>
> Best wishes,
> Greg
>
>
> --
>
> GREG SHEREMETA
>
> SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX
>
> Red Hat
>
> 
>
> gsher...@redhat.comIRC: gshereme
> 
>
> ___
> 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] (WebAdmin) multi-dialog-per-model infra was simplified

[Vojtech Szocs]

Hi devs,

just a heads-up that [1] was merged, making the use case "trigger multiple
dialogs by the same model" easier to implement.

The infra is now model-centric, just override get(Confirm)WindowProperties
+ set(Confirm)WindowProperty methods in your model (the one which triggers
dialogs), along with popup resolution logic, which usually sits in *Module
classes.

[1] https://gerrit.ovirt.org/#/c/67532/

Regards,
Vojtech
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Fwd: Removing @DefaultValueAttribute

[Vojtech Szocs]

On Wed, Aug 9, 2017 at 8:55 AM, Miroslava Voglova 
wrote:

> Hi,
>
> I am currently moving all option values from ConfigValues to database. It
> should make this values more readable and less error prone, since all will
> be in one place. Also it will allow engine-config to work with all
> available options and provide a way to find out if option is versioned, or
> has one general value.
>
> But I encountered problem with unit tests. Some tests (tests that use
> MockConfigRule e.g. NetworkInSyncWithVdsNetworkInterfaceTest) rely on
> getting default value from ConfigUtilBase#getValue, which will no longer be
> possible, because there will be no @DefaultValueAttribute. As I understand,
> this tests cannot get values from database either.
>

​Looking at code, it seems that ConfigUtilsBase makes the assumption that
default value for given VdcOption [1] is available through annotations,
driven by the presence of @TypeConverterAttribute + @DefaultValueAttribute.
If we want to remove those annotations throughout ConfigValues, we could
consider adapting ConfigUtilsBase accordingly.

[1] ConfigUtilsBase#getValue(VdcOption)​

​Or, simply allow the test to specify the given VdcOption's default value
explicitly (avoid relying on annotation-driven default value resolution)
which can reduce the amount of "magic" in the test :-)


> Does someone have an idea how to solve this problem? I was thinking about
> changing MockConfigRule to get values from 000_config.sql, but I am not
> sure if this change won't cause some other issues.
>
> Thanks,
> Mirka
>
>
> ___
> 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] UI Redesign patch has been merged.

[Vojtech Szocs]

Excellent work, Alex!

Most of the patches are already in, just a couple remaining:
https://gerrit.ovirt.org/#/q/status:open+topic:ui-redesign

Greg also fixed a memory leak caused by GWT-Platform framework bug:
https://gerrit.ovirt.org/#/c/78025/

As Jakub pointed out, replacing the "main & sub tab" concept with "main
(grid) view leading to details (tabbed) view" impacts existing UI
workflows, and the "entity actions available only from the main view" is
one of them. I remember this being discussed with UXD and it makes perfect
sense to have those actions available in details view as well, we'll
improve that.

Regards,
Vojtech


On Wed, Jun 14, 2017 at 8:54 PM, Alexander Wels  wrote:

> On Wednesday, June 14, 2017 2:49:55 PM EDT Jakub Niedermertl wrote:
> > Thanks Alex. It looks great!
> >
> > After a while of using the new design I feel it would be nice to have
> > context actions available not only on the list view but also on entity
> > detail. It feels natural for me to click on the entity I want to works
> > with, and after examining some details to perform an action. For example
> > start a VM, put Host to maintenance, or edit a Cluster.
> >
> > Is there any plan to make actions of context menu of entity listings
> > available also in entity detail page?
> >
> > Regards.
> > Jakub
> >
>
> Jakub,
>
> thanks, yes, in fact I am working with the UXD team on exactly that right
> now.
> The details not having the actions available will be one of the first
> things I
> will work on after I get my patch train all merged.
>
> Alexander
>
> >
> > On Wed, Jun 14, 2017 at 6:13 PM, Jorge Luis Andrade Escobar <
> >
> > jandr...@i-t-m.com> wrote:
> > > Looks great!!!
> > >
> > > Great work.
> > >
> > >
> > > On Wed, Jun 14, 2017 at 9:00 AM, Yaniv Bronheim 
> > >
> > > wrote:
> > >> Erray !! :P Great work
> > >>
> > >> On Wed, Jun 14, 2017 at 4:29 PM Alexander Wels 
> wrote:
> > >>> Hi,
> > >>>
> > >>> I have just merged [1] which is a huge patch to update the look and
> feel
> > >>> of
> > >>> the webadmin UI to be more modern and based on Patternfly. I believe
> > >>> this is a
> > >>> huge step forward for the UI and should hopefully improve the
> usability
> > >>> and
> > >>> functionality of the UI (it certainly looks better).
> > >>>
> > >>> There are a bunch of follow up patches that once merged will make
> the UI
> > >>> look
> > >>> like [2]. It might take a few days for all of these patches to get
> into
> > >>> master. There are more enhancements planned to the usability of the
> UI
> > >>> as part
> > >>> of the overhaul process.
> > >>>
> > >>> As always, if there are any issues or comments let me know and I
> will be
> > >>> sure
> > >>> to address them ASAP.
> > >>>
> > >>> Alexander
> > >>>
> > >>>
> > >>> ps. You will have to clear your browser cache to get some of the
> > >>> formatting to
> > >>> look right.
> > >>>
> > >>> [1] https://gerrit.ovirt.org/#/c/75669/
> > >>> [2] http://imgur.com/a/JX0iG
> > >>> ___
> > >>> Devel mailing list
> > >>> Devel@ovirt.org
> > >>> http://lists.ovirt.org/mailman/listinfo/devel
> > >>
> > >> --
> > >> Yaniv Bronhaim.
> > >>
> > >> ___
> > >> Devel mailing list
> > >> Devel@ovirt.org
> > >> http://lists.ovirt.org/mailman/listinfo/devel
> > >
> > > --
> > > Jorge Luis Andrade Escobar
> > > jandr...@i-t-m.com
> > > jandr...@itm.gt
> > > Red Hat Certified Architect (RHCA)
> > > Red Hat Certified Instructor/Examiner (RHCX)
> > > # 100-000-967
> > > gpg: 685C 68E8 9F55 771B ED7C 3CC7 5E65 8385 88D3 09A5
> > > Phone: +502 2305-0800 ext. 4005 <+502%202305%200800>
> > >
> > > http://www.i-t-m.com
> > >
> > > ___
> > > 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] AppErrors.properties merged together

[Vojtech Szocs]

Hi Jakub, thanks for taking the effort to simplify AppErrors handling!

The AppErrors.properties file and its localized variants should live in a
single location, e.g. frontend/webadmin/modules/frontend. We should avoid
having multiple AppErrors.properties copies spread across the codebase.

The backend dal (data access layer) module has its own copy of
AppErrors.properties file. One option is to copy it from the source
location during Engine build, another option is to simply use symlinks.

In any case, there should be a unit test that ensures all EngineMessage
enum members are reflected as methods in AppErrors interface. This will
give us the confidence that backend EngineMessage's have proper strings
associated with them.

Regards,
Vojtech


On Mon, Jun 12, 2017 at 8:51 PM, Jakub Niedermertl 
wrote:

> Hi all,
>
> there is a patch [1] removing `AppErrors.properties` from webadmin project
> to simplify edits of AppErrors/EngineMessage. AppErrors.properties from
> webadmin project will be merged to AppErrors.properties in frontend
> project. This requires some manual resolutions of conflicts of translation
> values.
>
> I'd like to kindly ask you to review altered translation values. They are
> mostly just typos.
>
> Thanks.
> Jakub
>
> [1]: https://gerrit.ovirt.org/#/c/76215/
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] GWT symbol maps are now installed with Engine, the "debuginfo" packages are out

[Vojtech Szocs]

On Thu, Jun 8, 2017 at 11:16 PM, Greg Sheremeta  wrote:

>
> On Thu, Jun 8, 2017 at 3:50 PM, Martin Perina  wrote:
>
>>
>>
>> On Thu, Jun 8, 2017 at 7:37 PM, Greg Sheremeta 
>> wrote:
>>
>>> Yes, they'll now be in ui.log on the server.
>>>
>>> Greg
>>>
>>>
>>> On Thu, Jun 8, 2017 at 1:32 PM, Shmuel Melamud 
>>> wrote:
>>>
>>>> Hi!
>>>>
>>>> When building the Engine manually, is it possible to get de-obfuscated
>>>> stack traces without rebuilding with DEV_BUILD_GWT_DRAFT=1 ?
>>>>
>>>> Shmuel
>>>>
>>>> On Thu, Jun 8, 2017 at 8:17 PM, Vojtech Szocs 
>>>> wrote:
>>>> > Hello everyone,
>>>> >
>>>> > in master [1] and 4.1 [2] branches, meaningful (de-obfuscated)
>>>> GWT/Java
>>>> > stack traces are now available right after Engine installation or
>>>> upgrade.
>>>> >
>>>> > There's no need to install the complementary "debuginfo" packages
>>>> anymore.
>>>> > In fact, those packages are removed now. (If installed, please remove
>>>> them
>>>> > manually before upgrading Engine.)
>>>>
>>>
>> ​This is bad, we should not require manual uninstallation during
>> upgrades. Could you please
>> add​
>>
>> ​correct Provides/Conflicts into webadmin/userportal packages, so
>> existing debuginfo
>> packages will be uninstalled automatically?
>>
>
> Normally it is probably bad. We discussed this in the patch comments.
> Quoting Sandro [3]:
>
> """
> about yum update error messages related to version locking:
> debug packages are not meant to be installed on any production
> environment other than for debugging purpose.
> Once the debug is finished they need to be removed.
> """
>

Right, ​those "debuginfo" packages are complementary and expected to be
removed once no longer needed (e.g. after collecting GWT/Java stack trace
information when reporting a UI related bug).

As Greg wrote, this was discussed in patch [1], please see the review
comments from Simone, Sandro and Didi.


> See the patch [1] for more of the conversation.
>
> [3] https://bugzilla.redhat.com/show_bug.cgi?id=1401963#c23
>
> Greg
>
>
>> ​
>>
>>> >
>>>> > Please refer to commit msg for details.
>>>> >
>>>> > [1] https://gerrit.ovirt.org/#/c/75420
>>>> > [2] https://gerrit.ovirt.org/#/c/77892/
>>>> >
>>>> > Regards,
>>>> > Vojtech
>>>> >
>>>> >
>>>> > ___
>>>> > 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
>>>>
>>>
>>>
>>>
>>> --
>>> Greg Sheremeta, MBA
>>> Sr. Software Engineer
>>> Red Hat, Inc.
>>> gsher...@redhat.com
>>>
>>> ___
>>> Devel mailing list
>>> Devel@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>
>>
>
>
> --
> Greg Sheremeta, MBA
> Sr. Software Engineer
> Red Hat, Inc.
> gsher...@redhat.com
>
> ___
> 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] GWT symbol maps are now installed with Engine, the "debuginfo" packages are out

[Vojtech Szocs]

Hello everyone,

in master [1] and 4.1 [2] branches, meaningful (de-obfuscated) GWT/Java
stack traces are now available right after Engine installation or upgrade.

There's no need to install the complementary "debuginfo" packages anymore.
In fact, those packages are removed now. (If installed, please remove them
manually before upgrading Engine.)

Please refer to commit msg for details.

[1] https://gerrit.ovirt.org/#/c/75420
[2] https://gerrit.ovirt.org/#/c/77892/

Regards,
Vojtech
___
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

[Vojtech Szocs]

On Fri, Jun 2, 2017 at 5:44 PM, Martin Sivak  wrote:

> 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).
>

​First of all, many thanks for your feedback, Martin!​

I agree with you completely. The Engine/Java side should follow standard
Java best practices.

The Engine/Java world is very different from GWT/Java world, but
unfortunately, they are coupled via GWT RPC run{query,action} mechanism.


>
> 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.
>

Well, there are (at least) two possible solutions​:

1, the one you've suggested - make the separation explicit by transforming
objects from Engine/Java world (such as business entities) into DTOs which
are optimized for GWT/Java world

2, tweak GWT compiler's handling of Java types without touching existing
code - blacklist generic types, whitelist only some specific impl's of
those types (note: this is a built-in GWT feature)

​Given the existing complexity​, I'd like to try out the second approach
first and see how far we can get.

For example, add a GWT-specific rule that replaces List to
ArrayList during GWT compilation (affects generated JS code), plus
blacklist List and whitelist ArrayList in GWT RPC serialization
policy (affects GWT RPC request validation). This approach can be applied
to any other types, all the way up to the `Serializable` interface.

The separation by DTO approach is, however, more correct from design
perspective. I'll give it more thought. Thanks for bringing it up.


> 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.
>

​That compiler extension is already possible, it's a built-in GWT feature
:-)

However, we still need to know if it's OK to treat all Lists as ArrayLists
on frontend, for example. That's the motivation behind my question:

> What about limiting us to ArrayList, HashSet and HashMap for GWT RPC
transfer?

More generally, if we can think of any non-standard, non-obvious
`Serializable` type that is needed on the frontend, in order to safely
construct the whitelist/blacklist for GWT code.​ That's because I'm
suspecting that our GWT code does reference `Serializable` type and we *do*
need to blacklist it and whitelist only specific types we need. (The
List to ArrayList approach will have no impact if GWT still sees
us using `Serializable` interface.)


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

Re: [ovirt-devel] Engine query & action result classes are now final

[Vojtech Szocs]

On Wed, May 31, 2017 at 6:19 PM, Vojtech Szocs  wrote:

> Hi everyone,
>
> yesterday, we merged https://gerrit.ovirt.org/#/c/75705/ which seals
> Engine query & action result classes.
>
> We will follow this up with renaming "VdcReturnValueBase" to
> "ActionReturnValue" and doing similar renames to existing "VdcSomething"
> classes.
>
> The reason for finalizing those result classes is to avoid us implementing
> a GWT custom field serializer for each such subclass, therefore limiting
> our exposure to GWT RPC specifics when transferring objects between client
> and server.
>
> On a side note, we also upgraded GWT 2.8.0 to 2.8.1 which fixes a GWT
> compiler bug we had to work around: https://gerrit.ovirt.org/#/c/77264/
>

​Unfortunately, we've found a bug [1] in GWT 2.8.1 that causes the GWT
debugger (classic dev mode - using Java IDE) to crash right upon startup.

[1] https://github.com/gwtproject/gwt/issues/9522​

The ^^ bug is currently marked as "wontfix" because classic dev mode was
deprecated in GWT 2.8.0 release. For us, classic dev mode remains the only
reliable way to debug our GWT code (even though you have to use a very old
Firefox or Chrome, but it works).

​For​ now, we're going to revert to GWT 2.8.0 so that frontend development
experience isn't affected.


>
>
> Regards,
> Vojtech
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

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

[Vojtech Szocs]

Hello,

in GWT world, being more specific (e.g. using ArrayList instead of just
List) is preferred since the GWT compiler doesn't need to introspect all
possible subtypes and include them in the generated JavaScript. Using too
"generic" types is one of the main reasons of significant GWT-generated
JavaScript size.

I'd like to improve this and I'm wondering what others think.

For example, in BusinessEntity interface, is there any reason why  and not e.g.  ? If the GWT compiler
sees a reference to Serializable type and it isn't obvious what's the
instance type behind it, it includes *all* Serializable subtypes into the
generated JavaScript. You can probably imagine how many of those are
visible to GWT compiler via Java classpath.

Another example is query & action result allowing arbitrary List/Map/Set
impl. to be passed through GWT RPC. What about limiting us to ArrayList,
HashSet and HashMap for GWT RPC transfer? Please be aware that usual Java
performance tips do not apply to GWT world due to Java-to-JS compilation.
(And therefore, using LinkedList instead of ArrayList has no practical
effect aside from bigger JS footprint.)

I'd like both frontend and backend maintainers to share their thoughts.
Alexander's UI redesign efforts [1] are well on their way into the master
branch and it's a good opportunity to improve existing GWT frontend, making
it smaller & faster for our users.

[1] https://gerrit.ovirt.org/#/c/75669/

Thanks!
Vojtech
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] Engine query & action result classes are now final

[Vojtech Szocs]

Hi everyone,

yesterday, we merged https://gerrit.ovirt.org/#/c/75705/ which seals Engine
query & action result classes.

We will follow this up with renaming "VdcReturnValueBase" to
"ActionReturnValue" and doing similar renames to existing "VdcSomething"
classes.

The reason for finalizing those result classes is to avoid us implementing
a GWT custom field serializer for each such subclass, therefore limiting
our exposure to GWT RPC specifics when transferring objects between client
and server.

On a side note, we also upgraded GWT 2.8.0 to 2.8.1 which fixes a GWT
compiler bug we had to work around: https://gerrit.ovirt.org/#/c/77264/

Regards,
Vojtech
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] ovirt-engine-nodejs failing build on fc26

[Vojtech Szocs]

+1 on bumping to NodeJS v8.

According to [1] the build should pass with gcc v6, but seems that fc26
ships gcc v7 only.

[1] https://github.com/nodejs/node/issues/10388#issuecomment-283056552

The root cause is indeed an ill-formed NodeJS source code. Using older gcc
to build it isn't a proper solution.

According to [2] the NodeJS v6 "active LTS" period ends at April 2018,
however this is a build-related bug, and the GitHub issue is closed with
resolution "fixed in next v7 release" (note that v7 is not LTS).

[2] https://github.com/nodejs/LTS

Even though NodeJS v8 "active LTS" period starts at October 2017 (in ~4
months), I'm OK with us bumping to v8 now.

(If we face any problems with v8, we can "downgrade" to v7 if necessary.)

Regards,
Vojtech


On Wed, May 31, 2017 at 8:54 AM, Sandro Bonazzola 
wrote:

>
>
> On Wed, May 31, 2017 at 2:45 AM, Greg Sheremeta 
> wrote:
>
>> Root cause is a node bug: https://github.com/nodejs/node/issues/8
>>
>> patch is https://gerrit.ovirt.org/#/c/77568
>>
>
> +1
>
>
>> which simply bumps us to node 8, which coincidentally was released today.
>> Looks like the fix isn't going into the node 6 line.
>>
>> Greg
>>
>> On Tue, May 30, 2017 at 8:12 AM, Greg Sheremeta 
>> wrote:
>>
>>> I'll take care of it. Thanks for letting us know :)
>>>
>>> On Mon, May 29, 2017 at 9:33 AM, Sandro Bonazzola 
>>> wrote:
>>>
 Hi,
 just an heads up that ovirt-engine-nodejs fails to build on fc26:
 http://jenkins.ovirt.org/job/ovirt-engine-nodejs_master_buil
 d-artifacts-fc26-x86_64/1/consoleFull


 --

 SANDRO BONAZZOLA

 ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D

 Red Hat EMEA 
 
 TRIED. TESTED. TRUSTED. 

>>>
>>>
>>>
>>> --
>>> Greg Sheremeta, MBA
>>> Sr. Software Engineer
>>> Red Hat, Inc.
>>> gsher...@redhat.com
>>>
>>
>>
>>
>> --
>> Greg Sheremeta, MBA
>> Sr. Software Engineer
>> Red Hat, Inc.
>> gsher...@redhat.com
>>
>
>
>
> --
>
> 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

Re: [ovirt-devel] ovirt-engine version problem

[Vojtech Szocs]

You can also try ovirt-vdsmfake [1] if you just need to add some fake hosts
to your dev. env.

[1] https://gerrit.ovirt.org/#/admin/projects/ovirt-vdsmfake

Vojtech


On Wed, Apr 12, 2017 at 7:24 PM, shubham dubey  wrote:

> Thanks for explanation, I completely understand it now.
>
> On Wed, Apr 12, 2017 at 10:17 PM, Greg Sheremeta 
> wrote:
>
>> For pretty much any open source project, you can install previous
>> versions by checking out "tags". That's one very important reason why we
>> tag things.
>>
>> greg@greg-x1:~/projects/ovirt-engine(master|✔) $ git checkout
>> ovirt-engine-4.0.7
>> Note: checking out 'ovirt-engine-4.0.7'.
>>
>> You are in 'detached HEAD' state. You can look around, make experimental
>> changes and commit them, and you can discard any commits you make in this
>> state without impacting any branches by performing another checkout.
>>
>> If you want to create a new branch to retain commits you create, you may
>> do so (now or later) by using -b with the checkout command again. Example:
>>
>>   git checkout -b 
>>
>> HEAD is now at e00e36d... build: ovirt-engine-4.0.7
>>
>> greg@greg-x1:~/projects/ovirt-engine(:e00e36d|✔) $ make clean
>> install-dev PREFIX=$HOME/ovirt-engine
>>
>>
>> On Wed, Apr 12, 2017 at 12:40 PM, shubham dubey 
>> wrote:
>>
>>> I just delete the ovirt-engine folder and .m2/repository folder and
>>> recompile it and it just work.:)
>>> But one thing I want to clarify is that can I only install ovirt 4.2
>>> through source or I can install previous versions also?
>>>
>>> Thanks,
>>> Shubham
>>>
>>> On Wed, Apr 12, 2017 at 5:22 PM, Tomas Jelinek 
>>> wrote:
>>>


 On Wed, Apr 12, 2017 at 1:51 PM, shubham dubey 
 wrote:

> that doesn't work.
>

 what does it do? Please paste the output


>
> On Wed, Apr 12, 2017 at 4:13 PM, Tomas Jelinek 
> wrote:
>
>>
>>
>> On Wed, Apr 12, 2017 at 11:34 AM, shubham dubey 
>> wrote:
>>
>>> Hello,
>>> Recently I have installed ovirt-engine development environment. The
>>> snapshot repository I have used
>>> is ovirt-release-master.
>>> Now I have installed vdsm in ovirt host with ovirt-release41, so
>>> when I am trying to add the host it is
>>> showing that ovirt node support cluster version 3.9,4.0 and 4.1 but
>>> 4.2 is available.
>>> So I have decided to installed ovirt engine with ovirt-engine41
>>> repository. The steps I follow are :-
>>> 1) yum remove ovirt-release-master.noarch
>>> 2) yum install ovirt-release41.noarch
>>> 3) delete $HOME/ovirt-engine and $HOME/git/ovirt-engine
>>> 4) git clone ovirt-engine again
>>> 5) make install-dev PREFIX=$HOME/ovirt-engine
>>>
>>> The compiling ends successfully but the $HOME/ovirt-engine directory
>>> is coming out empty.
>>>
>>
>> Maybe some permission or similar issues on the $HOME/ovirt-engine
>> dir. You can try to redeploy again using:
>> make install-dev PREFIX=$HOME/ovirt-engine DEV_REBUILD=0
>> to see if it passes or if it complains
>>
>>
>>> So $HOME/ovirt-engine/bin/engine-setup is giving error that NO file
>>> or directory found.
>>> So can anyone tell me what I am doing wrong?
>>>
>>> Note:One more thing I have noticed is that even after changing repo
>>> to ovirt 4.1 the make is still compiling ovirt 4.2 snapshot.
>>>
>>> Thanks,
>>> Shubham
>>>
>>> ___
>>> 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
>>>
>>
>>
>>
>> --
>> Greg Sheremeta, MBA
>> Sr. Software Engineer
>> Red Hat, Inc.
>> gsher...@redhat.com
>>
>
>
> ___
> 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] Live demo session on how to debug oVirt GWT applications

[Vojtech Szocs]

Hello everyone,

for those who missed my session, please find the recording at
https://bluejeans.com/s/zij35/ (there are two chapters, because I've
accidentally clicked "stop recording" during the session)

slides are available at
http://redhat.slides.com/vszocs/debugging-ovirt-gwt-applications?token=brh5Tzaz

As for the questions - let me post some answers here:

> ​(asked by Roy) Intellij supports super dev mode. Does anyone have
experience with it?

Yes, IntelliJ has built-in GWT support, see
https://blog.jetbrains.com/idea/2014/09/intellij-idea-14-brings-better-gwts-super-dev-mode-support/

But I wasn't able to make it work on my local dev. env. as it attempts to
start SDM code server on its own, whereas in oVirt we have a dedicated
command to start the code server, `make gwt-debug`. And that's partially
because we use ${foo} placeholders in our *.gwt.xml files (to be
substituted during Maven build) which causes IntelliJ to fail with messages
like

  Invalid property value '${gwt.runtimeLogLevel}'

which comes from WebAdmin.gwt.xml file.

TL;DR it works for HelloWorld-style GWT webapps, but unless we can tell
IntelliJ to reuse existing SDM code server, it won't work for us.

> (asked by Shmuel) What about utilizing WebAssembly to improve performance?

There are two things to consider, asm.js [1] and WebAssembly spec [2].

[1] http://asmjs.org/
[2] http://webassembly.org/

asm.js is about having a subset of JavaScript which is easily optimizable
by the runtime platform (e.g. browser's JavaScript engine) but this
platform obviously needs to be aware of the asm.js spec to do the
optimizations. Latest working draft of asm.js is from Aug 2014.

WebAssembly seems to be the next step, defining a binary format that is
size- and load-time-efficient but working with low level structures like
some basic types, table of types, linear memory, functions and local/global
variables - everything wrapped as a "module". The runtime platform also
needs to support WebAssembly spec, which is currently being standardized,
see http://webassembly.org/docs/mvp/

I found some GWT discussions about WebAssembly and it eventually comes down
to GC (garbage collection) support, since WebAssembly code runs in its own
context, possibly outside (next to) JavaScript VM. Plus, given the fact
that lots of performance depends on how much DOM (or other
browser-specific) operations a webapp performs, the gain of using
WebAssembly in webapps might not be that big, compared to e.g. games or
scientific applications that leverage the power of native code on given OS
platform.

Good news is that WebAssembly has plans for GC -
https://github.com/WebAssembly/design/blob/master/GC.md

So once/if WebAssembly adds GC support and tightens integration with web
APIs, it might be a feasible compilation target for GWT.

​Regards,
Vojtech​


On Sun, Apr 2, 2017 at 11:24 AM, Roy Golan  wrote:

>
>
> On Fri, Mar 31, 2017 at 4:49 PM Vojtech Szocs  wrote:
>
>> Hello,
>>
>> the slides are here: http://redhat.slides.com/vszocs/debugging-ovirt-gwt-
>> applications?token=brh5Tzaz
>>
>> I've made some new discoveries while working on this, the biggest one is
>> that SDBG (link below) actually works for oVirt WebAdmin!
>>
>>
> ​​
> Intellij supports super dev mode. Does anyone have experience with it?
>
>
>> This means there's a viable alternative to existing GWT debug method,
>> which doesn't restrict you to using an ancient (NPAPI-compliant) browser,
>> while still being able to use Java IDE (Eclipse) as well as reaping the
>> benefits of SDM code server (fast incremental recompiles).
>>
>> If you're an oVirt UI maintainer, I highly suggest you to join this
>> session, spend ~1 hour of your time and in return, get the knowledge to be
>> more productive when dealing with our GWT code.
>>
>> Regards,
>> Vojtech
>>
>>
>> On Tue, Mar 28, 2017 at 3:56 PM, Vojtech Szocs  wrote:
>>
>> Update: moving the session to Tue, Apr 4 @ the same time as originally
>> planned.
>>
>> Regards,
>> ​V​
>> ojtech
>>
>> PS: Greg sent me a link to SDBG project [1] which allows you to debug GWT
>> application via Super Dev Mode from within Java Eclipse IDE. I'm going to
>> cover this in the presentation as well.
>>
>> [1] http://sdbg.github.io/
>>
>>
>> On Mon, Mar 27, 2017 at 8:09 PM, Vojtech Szocs  wrote:
>>
>> Hello UI devs,
>>
>> with oVirt master UI using the latest GWT SDK [1], I'd like to host a
>> live demo session with two goals in mind:
>>
>> a, explain how the (Java IDE based) Classic Dev Mode works and mention
>> its limitations
>> b, explain how the (browser based) Super Dev Mode wo

Re: [ovirt-devel] Live demo session on how to debug oVirt GWT applications

[Vojtech Szocs]

Hi, I've shifted the meeting to 4pm CET to make it easier for TLV folks to
join.

We can still change the time if needed.

Vojtech


On Fri, Mar 31, 2017 at 3:48 PM, Vojtech Szocs  wrote:

> Hello,
>
> the slides are here: http://redhat.slides.com/vszocs/debugging-ovirt-gwt-
> applications?token=brh5Tzaz
>
> I've made some new discoveries while working on this, the biggest one is
> that SDBG (link below) actually works for oVirt WebAdmin!
>
> This means there's a viable alternative to existing GWT debug method,
> which doesn't restrict you to using an ancient (NPAPI-compliant) browser,
> while still being able to use Java IDE (Eclipse) as well as reaping the
> benefits of SDM code server (fast incremental recompiles).
>
> If you're an oVirt UI maintainer, I highly suggest you to join this
> session, spend ~1 hour of your time and in return, get the knowledge to be
> more productive when dealing with our GWT code.
>
> Regards,
> Vojtech
>
>
> On Tue, Mar 28, 2017 at 3:56 PM, Vojtech Szocs  wrote:
>
>> Update: moving the session to Tue, Apr 4 @ the same time as originally
>> planned.
>>
>> Regards,
>> ​V​
>> ojtech
>>
>> PS: Greg sent me a link to SDBG project [1] which allows you to debug GWT
>> application via Super Dev Mode from within Java Eclipse IDE. I'm going to
>> cover this in the presentation as well.
>>
>> [1] http://sdbg.github.io/
>>
>>
>> On Mon, Mar 27, 2017 at 8:09 PM, Vojtech Szocs  wrote:
>>
>>> Hello UI devs,
>>>
>>> with oVirt master UI using the latest GWT SDK [1], I'd like to host a
>>> live demo session with two goals in mind:
>>>
>>> a, explain how the (Java IDE based) Classic Dev Mode works and mention
>>> its limitations
>>> b, explain how the (browser based) Super Dev Mode works and encourage
>>> people to start using it to boost their productivity
>>>
>>> [1] http://www.mail-archive.com/devel@ovirt.org/msg08558.html
>>>
>>> The Classic vs. Super Dev Mode are two possible ways to debug GWT
>>> applications. This session will give you the knowledge to decide which one
>>> to use in a specific situation.
>>>
>>> Proposed time: Mon, Apr 3 @ 5pm CET / 6pm TLV / 11am US EST. (This can
>>> be changed as needed.)
>>>
>>> Let me know if this kind of session interests you or if the above time
>>> doesn't fit you but you'd still like to join.
>>>
>>> Thanks,
>>> Vojtech
>>>
>>>
>>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Live demo session on how to debug oVirt GWT applications

[Vojtech Szocs]

Hello,

the slides are here:
http://redhat.slides.com/vszocs/debugging-ovirt-gwt-applications?token=brh5Tzaz

I've made some new discoveries while working on this, the biggest one is
that SDBG (link below) actually works for oVirt WebAdmin!

This means there's a viable alternative to existing GWT debug method, which
doesn't restrict you to using an ancient (NPAPI-compliant) browser, while
still being able to use Java IDE (Eclipse) as well as reaping the benefits
of SDM code server (fast incremental recompiles).

If you're an oVirt UI maintainer, I highly suggest you to join this
session, spend ~1 hour of your time and in return, get the knowledge to be
more productive when dealing with our GWT code.

Regards,
Vojtech


On Tue, Mar 28, 2017 at 3:56 PM, Vojtech Szocs  wrote:

> Update: moving the session to Tue, Apr 4 @ the same time as originally
> planned.
>
> Regards,
> ​V​
> ojtech
>
> PS: Greg sent me a link to SDBG project [1] which allows you to debug GWT
> application via Super Dev Mode from within Java Eclipse IDE. I'm going to
> cover this in the presentation as well.
>
> [1] http://sdbg.github.io/
>
>
> On Mon, Mar 27, 2017 at 8:09 PM, Vojtech Szocs  wrote:
>
>> Hello UI devs,
>>
>> with oVirt master UI using the latest GWT SDK [1], I'd like to host a
>> live demo session with two goals in mind:
>>
>> a, explain how the (Java IDE based) Classic Dev Mode works and mention
>> its limitations
>> b, explain how the (browser based) Super Dev Mode works and encourage
>> people to start using it to boost their productivity
>>
>> [1] http://www.mail-archive.com/devel@ovirt.org/msg08558.html
>>
>> The Classic vs. Super Dev Mode are two possible ways to debug GWT
>> applications. This session will give you the knowledge to decide which one
>> to use in a specific situation.
>>
>> Proposed time: Mon, Apr 3 @ 5pm CET / 6pm TLV / 11am US EST. (This can be
>> changed as needed.)
>>
>> Let me know if this kind of session interests you or if the above time
>> doesn't fit you but you'd still like to join.
>>
>> Thanks,
>> Vojtech
>>
>>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] oVirt Engine checkstyle upgrade

[Vojtech Szocs]

On Tue, Mar 28, 2017 at 3:56 PM, Shmuel Melamud  wrote:

> Hi!
>
> > Well, whenever I see:
> >
> >   class Foo {
> > int a;
> > void bar() {
> > }
> >
> >   }
> >
> > it hurts my eyes because there's no symmetry - whitespace before class
> > declaration end, but no whitespace after class declaration start.
>
> Yes. And the same in this case:
>
> class Foo {
>
> int a;
> void bar() {
> }
> }
>
> Personally I'd like to force this symmetry with checkstyle rules, but
> I know many don't agree with me ;)
>

​Well, I agree with you.

Some people don't care about stylistic issues, however with things like
above enforced, it reduces the variance (e.g. related to whitespace usage)
and consequently makes the code look more consistent.


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

Re: [ovirt-devel] Live demo session on how to debug oVirt GWT applications

[Vojtech Szocs]

Update: moving the session to Tue, Apr 4 @ the same time as originally
planned.

Regards,
​V​
ojtech

PS: Greg sent me a link to SDBG project [1] which allows you to debug GWT
application via Super Dev Mode from within Java Eclipse IDE. I'm going to
cover this in the presentation as well.

[1] http://sdbg.github.io/


On Mon, Mar 27, 2017 at 8:09 PM, Vojtech Szocs  wrote:

> Hello UI devs,
>
> with oVirt master UI using the latest GWT SDK [1], I'd like to host a live
> demo session with two goals in mind:
>
> a, explain how the (Java IDE based) Classic Dev Mode works and mention its
> limitations
> b, explain how the (browser based) Super Dev Mode works and encourage
> people to start using it to boost their productivity
>
> [1] http://www.mail-archive.com/devel@ovirt.org/msg08558.html
>
> The Classic vs. Super Dev Mode are two possible ways to debug GWT
> applications. This session will give you the knowledge to decide which one
> to use in a specific situation.
>
> Proposed time: Mon, Apr 3 @ 5pm CET / 6pm TLV / 11am US EST. (This can be
> changed as needed.)
>
> Let me know if this kind of session interests you or if the above time
> doesn't fit you but you'd still like to join.
>
> Thanks,
> Vojtech
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] oVirt Engine checkstyle upgrade

[Vojtech Szocs]

On Mon, Mar 27, 2017 at 11:46 PM, Allon Mureinik 
wrote:

>
>
> On Mon, Mar 27, 2017 at 8:48 PM, Vojtech Szocs  wrote:
>
>>
>>
>> On Mon, Mar 27, 2017 at 2:10 PM, Allon Mureinik 
>> wrote:
>>
>>>
>>>
>>> On Mon, Mar 27, 2017 at 3:09 PM, Allon Mureinik 
>>> wrote:
>>>
>>>> Indeed, Greg.thanks
>>>>
>>>> As a temporary solution, you could cherry-pick https://gerrit.ovi
>>>> rt.org/#/c/74611 and work above it.
>>>> It should solve the issue (even though IMHO it isn't ready for merging
>>>> to master).
>>>>
>>>> Vojta - are you updating https://gerrit.ovirt.org/#/c/74611 as per my
>>>> comments there, or should I take it over?
>>>>
>>> I literally have no idea who I did made this typo.
>>> I meant "Vojtech", of course.​
>>>
>>
>> ​In Czech language, Vojta actually means Vojtech, in a less formal way =)
>>
> ​In that case, I totally meant to type that :-)
> ​
>
>>
>> I've just updated https://gerrit.ovirt.org/#/c/74611/ according to your
>> comments.
>>
> ​I cleaned up some white-spacing noise there that seemed unrelated to the
> patch and merged.
>

Well, whenever I see:

  class Foo {
int a;
void bar() {
}

  }
​
it hurts my eyes because there's no symmetry - whitespace before class
declaration end, but no whitespace after class declaration start.

Additionally, I prefer instance.method() to be on the same line (unless you
intend to chain calls), e.g. following:

  matcher
.start();

is IMHO less readable than:

  matcher.start();

​but following is OK:

  foo
.bar()
.baz();​



> From my local testing, using -Pgwtdev now works just find.
>
> Votech (or Vojta, if you prefer ^_^) - many thanks for your efforts here.
>
> Marek, and everyone else - please let me know if this still causes you any
> grief.​
>
>
>
>
>>
>> The reason why GWT debugger fails to start is because one of the
>> non-localized strings (which comes from `gwt-extension` and therefore
>> shouldn't be checked in the first place..) contains a {} placeholder,
>> NlsCheck logs it, and eventually crashes because it thinks it's a log
>> message placeholder, but it's just something we want printed out.
>>
>>
>>>
>>>
>>>
>>>>
>>>> On Mon, Mar 27, 2017 at 3:03 PM, Greg Sheremeta 
>>>> wrote:
>>>>
>>>>> From the comments in 74619
>>>>>
>>>>> "" "
>>>>> So, tl;dr - it /won't/ work with this patch but without 74611. This
>>>>> patch should be applied before 74611
>>>>> "" "
>>>>>
>>>>> On Mon, Mar 27, 2017 at 7:42 AM, Marek Libra 
>>>>> wrote:
>>>>>
>>>>>> With
>>>>>>   https://gerrit.ovirt.org/#/c/74619/
>>>>>>
>>>>>> applied, following is still failing:
>>>>>>   make gwt-debug DEBUG_MODULE=webadmin DEV_EXTRA_BUILD_FLAGS_GWT_DEFA
>>>>>> ULTS="-Dgwt.cssResourceStyle=pretty -Dgwt.userAgent=gecko1_8"
>>>>>>
>>>>>> with message:
>>>>>> [WARNING] The requested profile "gwt-user" could not be activated
>>>>>> because it does not exist.
>>>>>> [ERROR] Failed to execute goal 
>>>>>> org.apache.maven.plugins:maven-checkstyle-plugin:2.17:check
>>>>>> (checkstyle) on project webadmin: Failed during checkstyle configuration:
>>>>>> Exception was thrown while processing /home/mlibra/IdeaProjects/ovir
>>>>>> t-engine/frontend/webadmin/modules/gwt-extension/src/main/ja
>>>>>> va/org/ovirt/engine/ui/uioverrides/org/slf4j/Logger.java: can't
>>>>>> parse argument number: For input string: "" -> [Help 1]
>>>>>>
>>>>>>
>>>>>> Any hint, please?
>>>>>> Marek
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Mar 24, 2017 at 4:14 PM, Vojtech Szocs 
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Mar 24, 2017 at 3:51 PM, Vojtech Szocs 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Found the problem after debugging NlsCheck.
>>>>>>>>

[ovirt-devel] Live demo session on how to debug oVirt GWT applications

[Vojtech Szocs]

Hello UI devs,

with oVirt master UI using the latest GWT SDK [1], I'd like to host a live
demo session with two goals in mind:

a, explain how the (Java IDE based) Classic Dev Mode works and mention its
limitations
b, explain how the (browser based) Super Dev Mode works and encourage
people to start using it to boost their productivity

[1] http://www.mail-archive.com/devel@ovirt.org/msg08558.html

The Classic vs. Super Dev Mode are two possible ways to debug GWT
applications. This session will give you the knowledge to decide which one
to use in a specific situation.

Proposed time: Mon, Apr 3 @ 5pm CET / 6pm TLV / 11am US EST. (This can be
changed as needed.)

Let me know if this kind of session interests you or if the above time
doesn't fit you but you'd still like to join.

Thanks,
Vojtech
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] oVirt Engine checkstyle upgrade

[Vojtech Szocs]

On Mon, Mar 27, 2017 at 2:10 PM, Allon Mureinik  wrote:

>
>
> On Mon, Mar 27, 2017 at 3:09 PM, Allon Mureinik 
> wrote:
>
>> Indeed, Greg.thanks
>>
>> As a temporary solution, you could cherry-pick https://gerrit.ovi
>> rt.org/#/c/74611 and work above it.
>> It should solve the issue (even though IMHO it isn't ready for merging to
>> master).
>>
>> Vojta - are you updating https://gerrit.ovirt.org/#/c/74611 as per my
>> comments there, or should I take it over?
>>
> I literally have no idea who I did made this typo.
> I meant "Vojtech", of course.​
>

​In Czech language, Vojta actually means Vojtech, in a less formal way =)

I've just updated https://gerrit.ovirt.org/#/c/74611/ according to your
comments.

The reason why GWT debugger fails to start is because one of the
non-localized strings (which comes from `gwt-extension` and therefore
shouldn't be checked in the first place..) contains a {} placeholder,
NlsCheck logs it, and eventually crashes because it thinks it's a log
message placeholder, but it's just something we want printed out.


>
>
>
>>
>> On Mon, Mar 27, 2017 at 3:03 PM, Greg Sheremeta 
>> wrote:
>>
>>> From the comments in 74619
>>>
>>> "" "
>>> So, tl;dr - it /won't/ work with this patch but without 74611. This
>>> patch should be applied before 74611
>>> "" "
>>>
>>> On Mon, Mar 27, 2017 at 7:42 AM, Marek Libra  wrote:
>>>
>>>> With
>>>>   https://gerrit.ovirt.org/#/c/74619/
>>>>
>>>> applied, following is still failing:
>>>>   make gwt-debug DEBUG_MODULE=webadmin DEV_EXTRA_BUILD_FLAGS_GWT_DEFA
>>>> ULTS="-Dgwt.cssResourceStyle=pretty -Dgwt.userAgent=gecko1_8"
>>>>
>>>> with message:
>>>> [WARNING] The requested profile "gwt-user" could not be activated
>>>> because it does not exist.
>>>> [ERROR] Failed to execute goal 
>>>> org.apache.maven.plugins:maven-checkstyle-plugin:2.17:check
>>>> (checkstyle) on project webadmin: Failed during checkstyle configuration:
>>>> Exception was thrown while processing /home/mlibra/IdeaProjects/ovir
>>>> t-engine/frontend/webadmin/modules/gwt-extension/src/main/ja
>>>> va/org/ovirt/engine/ui/uioverrides/org/slf4j/Logger.java: can't parse
>>>> argument number: For input string: "" -> [Help 1]
>>>>
>>>>
>>>> Any hint, please?
>>>> Marek
>>>>
>>>>
>>>>
>>>> On Fri, Mar 24, 2017 at 4:14 PM, Vojtech Szocs 
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Fri, Mar 24, 2017 at 3:51 PM, Vojtech Szocs 
>>>>> wrote:
>>>>>
>>>>>> Found the problem after debugging NlsCheck.
>>>>>>
>>>>>> First of all, it checks all kinds of Java sources, including the
>>>>>> generated ones. That's silly and one of the reasons why Checkstyle
>>>>>> execution takes a rather long time. I'll fix that.
>>>>>>
>>>>>> Next, when checking a Java source that contains string "{}" (without
>>>>>> quotes) it will log the problem, but Checkstyle message logging infra
>>>>>> things that "{}" is a placeholder to resolve, but it's not, and it fails 
>>>>>> on
>>>>>> NumberFormatException. I'll fix that too.
>>>>>>
>>>>>
>>>>> ​https://gerrit.ovirt.org/#/c/74611/​
>>>>>
>>>>>
>>>>>> Vojtech
>>>>>>
>>>>>>
>>>>>> On Fri, Mar 24, 2017 at 3:19 PM, Vojtech Szocs 
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Allon,
>>>>>>>
>>>>>>> I think I found some strange Checkstyle related problems on master.
>>>>>>>
>>>>>>> Engine build with (GWT compilation enabled) works OK.
>>>>>>>
>>>>>>> Next, trying to start GWT debugger:
>>>>>>>
>>>>>>> $ make gwt-debug DEBUG_MODULE=webadmin \
>>>>>>>   DEV_EXTRA_BUILD_FLAGS_GWT_DEFAULTS="-Dgwt.userAgent=gecko1_8,safari"
>>>>>>> \
>>>>>>>   DEV_EXTRA_BUILD_FLAGS="-Dgwt.logLevel=INFO -Dgwt.locale=en_US
>>>>>

Re: [ovirt-devel] oVirt Engine checkstyle upgrade

[Vojtech Szocs]

On Fri, Mar 24, 2017 at 3:51 PM, Vojtech Szocs  wrote:

> Found the problem after debugging NlsCheck.
>
> First of all, it checks all kinds of Java sources, including the generated
> ones. That's silly and one of the reasons why Checkstyle execution takes a
> rather long time. I'll fix that.
>
> Next, when checking a Java source that contains string "{}" (without
> quotes) it will log the problem, but Checkstyle message logging infra
> things that "{}" is a placeholder to resolve, but it's not, and it fails on
> NumberFormatException. I'll fix that too.
>

​https://gerrit.ovirt.org/#/c/74611/​


> Vojtech
>
>
> On Fri, Mar 24, 2017 at 3:19 PM, Vojtech Szocs  wrote:
>
>> Hi Allon,
>>
>> I think I found some strange Checkstyle related problems on master.
>>
>> Engine build with (GWT compilation enabled) works OK.
>>
>> Next, trying to start GWT debugger:
>>
>> $ make gwt-debug DEBUG_MODULE=webadmin \
>>   DEV_EXTRA_BUILD_FLAGS_GWT_DEFAULTS="-Dgwt.userAgent=gecko1_8,safari" \
>>   DEV_EXTRA_BUILD_FLAGS="-Dgwt.logLevel=INFO -Dgwt.locale=en_US
>> -Dgwt.compiler.localWorkers=1" \
>>   DEV_BUILD_GWT_SUPER_DEV_MODE=1
>>
>> maven-checkstyle-plugin:check execution fails on
>>
>>   frontend/webadmin/modules/gwt-extension/src/main/java/org/ov
>> irt/engine/ui/uioverrides/org/ovirt/engine/core/compat/Forma
>> tterDotnet.java
>>   can't parse argument number: (\\d)\\: For input string: "(\\d)\\"
>>
>> the class isn't used, removed it, retry. Now it fails on:
>>
>>   frontend/webadmin/modules/gwt-extension/src/main/java/org/ov
>> irt/engine/ui/uioverrides/org/slf4j/Logger.java
>>   can't parse argument number: For input string: ""
>>
>> I guess it's a bug in our NON-NLS check? But why doesn't the problem
>> occur during Engine build?
>>
>> I'm thinking about disabling Checkstyle for gwt-extension module, as it
>> contains custom GWT RPC serializers and GWT class overrides, and maybe the
>> file path src/main/java/org/ovirt/engine/ui/uioverrides/here/goes/actual/pkg
>> is confusing the Checkstyle now.
>>
>> Thanks,
>> Vojtech
>>
>>
>> On Wed, Mar 22, 2017 at 10:33 PM, Allon Mureinik 
>> wrote:
>>
>>> Hi all,
>>>
>>> As per [1], I've just merged a series of patches that upgrades the oVirt
>>> engine to use the latest maven-checkstyle-plugin and checkstyle packages.
>>>
>>> Please note that the newer checkstyle is a tad stricter than the old one
>>> we used to have (read: it contains several fixes for bugs where the old
>>> checkstyle was supposed to find issues but missed them).
>>> I also took the opportunity and added a couple of new checks that
>>> enforce rules we were de-facto adhering to anyway.
>>>
>>> If any problems come up, please let me know.
>>>
>>>
>>> -Your friendly neighborhood cleanup dude
>>>
>>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1433408
>>>
>>> ___
>>> 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 Engine checkstyle upgrade

[Vojtech Szocs]

Found the problem after debugging NlsCheck.

First of all, it checks all kinds of Java sources, including the generated
ones. That's silly and one of the reasons why Checkstyle execution takes a
rather long time. I'll fix that.

Next, when checking a Java source that contains string "{}" (without
quotes) it will log the problem, but Checkstyle message logging infra
things that "{}" is a placeholder to resolve, but it's not, and it fails on
NumberFormatException. I'll fix that too.

Vojtech


On Fri, Mar 24, 2017 at 3:19 PM, Vojtech Szocs  wrote:

> Hi Allon,
>
> I think I found some strange Checkstyle related problems on master.
>
> Engine build with (GWT compilation enabled) works OK.
>
> Next, trying to start GWT debugger:
>
> $ make gwt-debug DEBUG_MODULE=webadmin \
>   DEV_EXTRA_BUILD_FLAGS_GWT_DEFAULTS="-Dgwt.userAgent=gecko1_8,safari" \
>   DEV_EXTRA_BUILD_FLAGS="-Dgwt.logLevel=INFO -Dgwt.locale=en_US
> -Dgwt.compiler.localWorkers=1" \
>   DEV_BUILD_GWT_SUPER_DEV_MODE=1
>
> maven-checkstyle-plugin:check execution fails on
>
>   frontend/webadmin/modules/gwt-extension/src/main/java/org/
> ovirt/engine/ui/uioverrides/org/ovirt/engine/core/compat/
> FormatterDotnet.java
>   can't parse argument number: (\\d)\\: For input string: "(\\d)\\"
>
> the class isn't used, removed it, retry. Now it fails on:
>
>   frontend/webadmin/modules/gwt-extension/src/main/java/org/
> ovirt/engine/ui/uioverrides/org/slf4j/Logger.java
>   can't parse argument number: For input string: ""
>
> I guess it's a bug in our NON-NLS check? But why doesn't the problem occur
> during Engine build?
>
> I'm thinking about disabling Checkstyle for gwt-extension module, as it
> contains custom GWT RPC serializers and GWT class overrides, and maybe the
> file path src/main/java/org/ovirt/engine/ui/uioverrides/here/goes/actual/pkg
> is confusing the Checkstyle now.
>
> Thanks,
> Vojtech
>
>
> On Wed, Mar 22, 2017 at 10:33 PM, Allon Mureinik 
> wrote:
>
>> Hi all,
>>
>> As per [1], I've just merged a series of patches that upgrades the oVirt
>> engine to use the latest maven-checkstyle-plugin and checkstyle packages.
>>
>> Please note that the newer checkstyle is a tad stricter than the old one
>> we used to have (read: it contains several fixes for bugs where the old
>> checkstyle was supposed to find issues but missed them).
>> I also took the opportunity and added a couple of new checks that enforce
>> rules we were de-facto adhering to anyway.
>>
>> If any problems come up, please let me know.
>>
>>
>> -Your friendly neighborhood cleanup dude
>>
>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1433408
>>
>> ___
>> 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 Engine checkstyle upgrade

[Vojtech Szocs]

Hi Allon,

I think I found some strange Checkstyle related problems on master.

Engine build with (GWT compilation enabled) works OK.

Next, trying to start GWT debugger:

$ make gwt-debug DEBUG_MODULE=webadmin \
  DEV_EXTRA_BUILD_FLAGS_GWT_DEFAULTS="-Dgwt.userAgent=gecko1_8,safari" \
  DEV_EXTRA_BUILD_FLAGS="-Dgwt.logLevel=INFO -Dgwt.locale=en_US
-Dgwt.compiler.localWorkers=1" \
  DEV_BUILD_GWT_SUPER_DEV_MODE=1

maven-checkstyle-plugin:check execution fails on


frontend/webadmin/modules/gwt-extension/src/main/java/org/ovirt/engine/ui/uioverrides/org/ovirt/engine/core/compat/FormatterDotnet.java
  can't parse argument number: (\\d)\\: For input string: "(\\d)\\"

the class isn't used, removed it, retry. Now it fails on:


frontend/webadmin/modules/gwt-extension/src/main/java/org/ovirt/engine/ui/uioverrides/org/slf4j/Logger.java
  can't parse argument number: For input string: ""

I guess it's a bug in our NON-NLS check? But why doesn't the problem occur
during Engine build?

I'm thinking about disabling Checkstyle for gwt-extension module, as it
contains custom GWT RPC serializers and GWT class overrides, and maybe the
file path
src/main/java/org/ovirt/engine/ui/uioverrides/here/goes/actual/pkg is
confusing the Checkstyle now.

Thanks,
Vojtech


On Wed, Mar 22, 2017 at 10:33 PM, Allon Mureinik 
wrote:

> Hi all,
>
> As per [1], I've just merged a series of patches that upgrades the oVirt
> engine to use the latest maven-checkstyle-plugin and checkstyle packages.
>
> Please note that the newer checkstyle is a tad stricter than the old one
> we used to have (read: it contains several fixes for bugs where the old
> checkstyle was supposed to find issues but missed them).
> I also took the opportunity and added a couple of new checks that enforce
> rules we were de-facto adhering to anyway.
>
> If any problems come up, please let me know.
>
>
> -Your friendly neighborhood cleanup dude
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1433408
>
> ___
> 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 master UI now uses GWT 2.8

[Vojtech Szocs]

Hello folks,

we're using the latest GWT version in master UI now [1].

We can start using Java 8 syntax in our frontend code. GWT 2.8 also brings
partial support for Java 8 standard library APIs, see "JDK emulation" at
[2] for details.

[1] https://gerrit.ovirt.org/#/q/topic:gwtupgrade
[2] http://www.gwtproject.org/release-notes.html#Release_Notes_2_8_0_RC1

Effectively, all Engine (Java Maven) modules [3] are now Java 8 source &
target compilant.

[3] except backend/manager/modules/extensions-api-root

With this upgrade, the GWT UI should be a bit faster - generated JavaScript
should take advantage of new web APIs (e.g. using ES6 Maps to implement
Java HashMap) as well as general performance improvements (e.g. using a
faster "long" emulation).

GWT 2.8 removes deRPC (direct-eval RPC) mechanism but that's OK because
we're already using the standard GWT RPC [4].

[4] https://gerrit.ovirt.org/#/c/65735/

There are no changes to existing build & development process:
- debugging via Java IDE (aka Classic Dev Mode) remains the default debug
method
- debugging via browser (aka Super Dev Mode) can be enabled via
DEV_BUILD_GWT_SUPER_DEV_MODE flag [5]

[5] example: $ make gwt-debug DEBUG_MODULE=webadmin
DEV_BUILD_GWT_SUPER_DEV_MODE=1

Note that in GWT 2.8 the Super Dev Mode is the new default debug method
(with Classic Dev Mode being deprecated).

There are still some post-upgrade tasks to do, we're tracking them on
Trello: https://trello.com/b/o26RrVLz/post-gwt-2-8-upgrade-tasks

If you encounter any issues related to GWT compilation or debugging, let me
know.

Regards,
Vojtech
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] oVirt packages for JavaScript development have been updated

[Vojtech Szocs]

Ryan, try running webpack with --display-error-details parameter.

Also, maybe this comment is related:
https://github.com/webpack/webpack/issues/3242#issuecomment-260411104

AFAIK, Node.js v6 path APIs had some changes, which possibly broke some
webpack plugins. Since current Node.js active LTS == v6, I'd expect webpack
plugin authors to fix their issues, you'll need to bump some versions in
package.json probably.

Vojtech


On Fri, Feb 10, 2017 at 6:05 PM, Greg Sheremeta  wrote:

> I'm clueless. Lol, actually I was just debugging the exact same thing when
> I saw your email that you were working on it.
>
> I was next going to look into https://github.com/babel/
> grunt-babel/issues/56#issuecomment-154377457 and the comment after it.
>
>
> On Fri, Feb 10, 2017 at 12:02 PM, Ryan Barry  wrote:
>
>> Thanks Greg!
>>
>> I actually merged patches for it to work, but it's always nice to see
>> another approach, and in looking at your diff, I see that I also didn't
>> change "--with-npm-install", which I should.
>>
>> As long as we have you on the phone (so to speak), I'm actually curious
>> about ovirt-engine-nodejs. We've been having failures in CI since December,
>> give or take, but they're not tied to any particular patch. That is to say
>> that checking out an earlier commit still suddenly fails. This has been a
>> low-grade annoyance while we prep for 4.1, since everything still builds
>> and runs in build-artifacts without any problems, but getitng "-1
>> Continuous Integration" on every patch isn't very helpful.
>>
>> Webpack complains "PATH should be a string, is undefined", but never
>> tells me where it's looking for this. We don't use path.resolve anywhere
>> and I've probably tried every suggestion on github/stackoverflow for making
>> this go away, without any success. There are a lot of reports that changing
>> the downgrading the NodeJS major version (from 6 -> 5, generally) resolves
>> this,b ut that's obviously not an option for us.
>>
>> Any ideas?
>>
>> On Fri, Feb 10, 2017 at 9:52 AM, Greg Sheremeta 
>> wrote:
>>
>>> I didn't realize Ryan was already doing this, so here was my take
>>> (attached). Maybe it helps.
>>>
>>>
>>>
>>> On Fri, Feb 10, 2017 at 11:33 AM, Vojtech Szocs 
>>> wrote:
>>>
>>>>
>>>>
>>>> On Fri, Feb 10, 2017 at 5:30 PM, Ryan Barry  wrote:
>>>>
>>>>> Nothing, but thanks.
>>>>>
>>>>> It is/was a question of time. I didn't expect the changes to
>>>>> ovirt-engine-modules to make it into master as quickly as they did (to be
>>>>> fair, it's been nearly a month since the initial meeting, but that month
>>>>> passed very quickly prepping for the beta release).
>>>>>
>>>>> I'm pushing patches to cockpit-ovirt and ovirt-engine-nodejs-modules
>>>>> to get cockpit-ovirt working on master again now.
>>>>>
>>>>
>>>> Please add Greg & me as reviewers :-)​ also, if there are any open
>>>> issues or questions, let us know.
>>>>
>>>>
>>>>>
>>>>> On Fri, Feb 10, 2017 at 6:56 AM, Greg Sheremeta 
>>>>> wrote:
>>>>>
>>>>>> I can assist too. What do you need? If it's easier, I'm available on
>>>>>> IRC.
>>>>>>
>>>>>> On Fri, Feb 10, 2017 at 8:00 AM, Sandro Bonazzola <
>>>>>> sbona...@redhat.com> wrote:
>>>>>>
>>>>>>> Vojtech, can you please help Ryan and Marek with cockpit-ovirt?
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Feb 8, 2017 at 3:29 PM, Vojtech Szocs 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hello devs,
>>>>>>>>
>>>>>>>> following packages, intended as build-time dependencies of oVirt
>>>>>>>> JavaScript projects, have been updated:
>>>>>>>>
>>>>>>>> * ovirt-engine-nodejs
>>>>>>>> * ovirt-engine-nodejs-modules
>>>>>>>> * ovirt-engine-yarn
>>>>>>>>
>>>>>>>> If you use those packages, please read on to learn how to adapt your
>>>>>>>> project. oVirt Dashboard (master) is already adapted and you can use
>>>

Re: [ovirt-devel] oVirt packages for JavaScript development have been updated

[Vojtech Szocs]

On Fri, Feb 10, 2017 at 5:30 PM, Ryan Barry  wrote:

> Nothing, but thanks.
>
> It is/was a question of time. I didn't expect the changes to
> ovirt-engine-modules to make it into master as quickly as they did (to be
> fair, it's been nearly a month since the initial meeting, but that month
> passed very quickly prepping for the beta release).
>
> I'm pushing patches to cockpit-ovirt and ovirt-engine-nodejs-modules to
> get cockpit-ovirt working on master again now.
>

Please add Greg & me as reviewers :-)​ also, if there are any open issues
or questions, let us know.


>
> On Fri, Feb 10, 2017 at 6:56 AM, Greg Sheremeta 
> wrote:
>
>> I can assist too. What do you need? If it's easier, I'm available on IRC.
>>
>> On Fri, Feb 10, 2017 at 8:00 AM, Sandro Bonazzola 
>> wrote:
>>
>>> Vojtech, can you please help Ryan and Marek with cockpit-ovirt?
>>>
>>>
>>> On Wed, Feb 8, 2017 at 3:29 PM, Vojtech Szocs  wrote:
>>>
>>>> Hello devs,
>>>>
>>>> following packages, intended as build-time dependencies of oVirt
>>>> JavaScript projects, have been updated:
>>>>
>>>> * ovirt-engine-nodejs
>>>> * ovirt-engine-nodejs-modules
>>>> * ovirt-engine-yarn
>>>>
>>>> If you use those packages, please read on to learn how to adapt your
>>>> project. oVirt Dashboard (master) is already adapted and you can use
>>>> it as your reference.
>>>>
>>>> ==
>>>>
>>>> 1, move your project from npm to Yarn:
>>>>
>>>> - using nodejs-modules implies that your project moves from npm to
>>>> Yarn, please do this as your first step
>>>> - make sure to add yarn.lock file to source control: rm -rf
>>>> node_modules && yarn install # generates yarn.lock
>>>> - your automation/*.packages should contain something like this:
>>>>
>>>>   ovirt-engine-nodejs-6.9.4
>>>>   ovirt-engine-nodejs-modules-1.0.3
>>>>   ovirt-engine-yarn-0.19.1
>>>>
>>>> - since oVirt CI uses yum cache, always specify exact version of
>>>> nodejs-modules in your automation/*.packages
>>>> - in your RPM build script, make sure to set up Node.js env.: source
>>>> /usr/share/ovirt-engine-nodejs-modules/setup-env.sh
>>>>
>>>> ==
>>>>
>>>> 2a, dependency handling - 1st time:
>>>>
>>>> - clone nodejs-modules repo & update the projects.list file - add
>>>> URL(s) to your project's files (package.json + yarn.lock)
>>>> - bump .z in RPM Version and reset the RPM Release number, submit
>>>> patch to Gerrit
>>>> - in your project, update automation/*.packages to use the right
>>>> nodejs-modules version
>>>>
>>>> 2b, dependency handling - whenever your dependencies change:
>>>>
>>>> - clone nodejs-modules repo & bump RPM Release number, submit patch to
>>>> Gerrit
>>>> - in your project, update automation/*.packages to use the right
>>>> nodejs-modules version
>>>>
>>>> ==
>>>>
>>>> Q: how does the new nodejs-modules work?
>>>>
>>>> A: instead of maintaining one big package.json file to specify all
>>>> dependencies of all projects (effectively forcing all projects to use
>>>> single dependency tree), it contains the projects.list file with
>>>> URL(s) to specific project files.
>>>>
>>>> When building nodejs-modules RPM, it goes through the list of URL(s),
>>>> downloading project's files (package.json + yarn.lock), then
>>>> downloading required dependencies (using Yarn) and collecting their
>>>> .tar.gz sources. The nodejs-modules RPM therefore contains a flat list
>>>> of all .tar.gz sources of all dependencies of all projects.
>>>>
>>>> When you source the setup-env.sh script, it does, among other things,
>>>> tell Yarn to use
>>>> /usr/share/ovirt-engine-nodejs-modules/yarn-offline-cache containing
>>>> all .tar.gz sources. Then, it runs Yarn in offline mode to populate
>>>> your project's node_modules directory.
>>>>
>>>> ==
>>>>
>>>> Hope this helps.
>>>>
>>>> Regards,
>>>> Vojtech
>>>> ___
>>>> Devel mailing list
>>>> Devel@ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>>
>>>
>>>
>>>
>>> --
>>> 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
>>>
>>
>>
>>
>> --
>> Greg Sheremeta, MBA
>> Red Hat, Inc.
>> Sr. Software Engineer
>> gsher...@redhat.com
>>
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] oVirt packages for JavaScript development have been updated

[Vojtech Szocs]

On Fri, Feb 10, 2017 at 2:56 PM, Greg Sheremeta  wrote:

> I can assist too. What do you need? If it's easier, I'm available on IRC.
>
> On Fri, Feb 10, 2017 at 8:00 AM, Sandro Bonazzola 
> wrote:
>
>> Vojtech, can you please help Ryan and Marek with cockpit-ovirt?
>>
>
​Hi guys, we can organize a short session ​to explain the changes and help
people to use the new packages. Does that make sense?

Generally, any project using nodejs-modules should move from npm to Yarn
(using ovirt-engine-yarn) and then modify the `projects.list` file in
nodejs-modules repo, see [1] for reference.

[1] https://gerrit.ovirt.org/#/c/71134/

This triggers new nodejs-modules RPM build, which will contain all
dependencies required by all projects defined via the the `projects.list`
file.

If you face issues with CI yum caching like we did in Dashboard (e.g.
nodejs-modules defined in .packages file wasn't actually installed), you
might try installing it manually in your build script, see [2] for
reference.

[2] https://gerrit.ovirt.org/#/c/71923/


>
>>
>> On Wed, Feb 8, 2017 at 3:29 PM, Vojtech Szocs  wrote:
>>
>>> Hello devs,
>>>
>>> following packages, intended as build-time dependencies of oVirt
>>> JavaScript projects, have been updated:
>>>
>>> * ovirt-engine-nodejs
>>> * ovirt-engine-nodejs-modules
>>> * ovirt-engine-yarn
>>>
>>> If you use those packages, please read on to learn how to adapt your
>>> project. oVirt Dashboard (master) is already adapted and you can use
>>> it as your reference.
>>>
>>> ==
>>>
>>> 1, move your project from npm to Yarn:
>>>
>>> - using nodejs-modules implies that your project moves from npm to
>>> Yarn, please do this as your first step
>>> - make sure to add yarn.lock file to source control: rm -rf
>>> node_modules && yarn install # generates yarn.lock
>>> - your automation/*.packages should contain something like this:
>>>
>>>   ovirt-engine-nodejs-6.9.4
>>>   ovirt-engine-nodejs-modules-1.0.3
>>>   ovirt-engine-yarn-0.19.1
>>>
>>> - since oVirt CI uses yum cache, always specify exact version of
>>> nodejs-modules in your automation/*.packages
>>> - in your RPM build script, make sure to set up Node.js env.: source
>>> /usr/share/ovirt-engine-nodejs-modules/setup-env.sh
>>>
>>> ==
>>>
>>> 2a, dependency handling - 1st time:
>>>
>>> - clone nodejs-modules repo & update the projects.list file - add
>>> URL(s) to your project's files (package.json + yarn.lock)
>>> - bump .z in RPM Version and reset the RPM Release number, submit
>>> patch to Gerrit
>>> - in your project, update automation/*.packages to use the right
>>> nodejs-modules version
>>>
>>> 2b, dependency handling - whenever your dependencies change:
>>>
>>> - clone nodejs-modules repo & bump RPM Release number, submit patch to
>>> Gerrit
>>> - in your project, update automation/*.packages to use the right
>>> nodejs-modules version
>>>
>>> ==
>>>
>>> Q: how does the new nodejs-modules work?
>>>
>>> A: instead of maintaining one big package.json file to specify all
>>> dependencies of all projects (effectively forcing all projects to use
>>> single dependency tree), it contains the projects.list file with
>>> URL(s) to specific project files.
>>>
>>> When building nodejs-modules RPM, it goes through the list of URL(s),
>>> downloading project's files (package.json + yarn.lock), then
>>> downloading required dependencies (using Yarn) and collecting their
>>> .tar.gz sources. The nodejs-modules RPM therefore contains a flat list
>>> of all .tar.gz sources of all dependencies of all projects.
>>>
>>> When you source the setup-env.sh script, it does, among other things,
>>> tell Yarn to use
>>> /usr/share/ovirt-engine-nodejs-modules/yarn-offline-cache containing
>>> all .tar.gz sources. Then, it runs Yarn in offline mode to populate
>>> your project's node_modules directory.
>>>
>>> ==
>>>
>>> Hope this helps.
>>>
>>> Regards,
>>> Vojtech
>>> ___
>>> Devel mailing list
>>> Devel@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>
>>
>>
>> --
>> 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
>>
>
>
>
> --
> Greg Sheremeta, MBA
> Red Hat, Inc.
> Sr. Software Engineer
> gsher...@redhat.com
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] oVirt packages for JavaScript development have been updated

[Vojtech Szocs]

Hello devs,

following packages, intended as build-time dependencies of oVirt
JavaScript projects, have been updated:

* ovirt-engine-nodejs
* ovirt-engine-nodejs-modules
* ovirt-engine-yarn

If you use those packages, please read on to learn how to adapt your
project. oVirt Dashboard (master) is already adapted and you can use
it as your reference.

==

1, move your project from npm to Yarn:

- using nodejs-modules implies that your project moves from npm to
Yarn, please do this as your first step
- make sure to add yarn.lock file to source control: rm -rf
node_modules && yarn install # generates yarn.lock
- your automation/*.packages should contain something like this:

  ovirt-engine-nodejs-6.9.4
  ovirt-engine-nodejs-modules-1.0.3
  ovirt-engine-yarn-0.19.1

- since oVirt CI uses yum cache, always specify exact version of
nodejs-modules in your automation/*.packages
- in your RPM build script, make sure to set up Node.js env.: source
/usr/share/ovirt-engine-nodejs-modules/setup-env.sh

==

2a, dependency handling - 1st time:

- clone nodejs-modules repo & update the projects.list file - add
URL(s) to your project's files (package.json + yarn.lock)
- bump .z in RPM Version and reset the RPM Release number, submit
patch to Gerrit
- in your project, update automation/*.packages to use the right
nodejs-modules version

2b, dependency handling - whenever your dependencies change:

- clone nodejs-modules repo & bump RPM Release number, submit patch to Gerrit
- in your project, update automation/*.packages to use the right
nodejs-modules version

==

Q: how does the new nodejs-modules work?

A: instead of maintaining one big package.json file to specify all
dependencies of all projects (effectively forcing all projects to use
single dependency tree), it contains the projects.list file with
URL(s) to specific project files.

When building nodejs-modules RPM, it goes through the list of URL(s),
downloading project's files (package.json + yarn.lock), then
downloading required dependencies (using Yarn) and collecting their
.tar.gz sources. The nodejs-modules RPM therefore contains a flat list
of all .tar.gz sources of all dependencies of all projects.

When you source the setup-env.sh script, it does, among other things,
tell Yarn to use
/usr/share/ovirt-engine-nodejs-modules/yarn-offline-cache containing
all .tar.gz sources. Then, it runs Yarn in offline mode to populate
your project's node_modules directory.

==

Hope this helps.

Regards,
Vojtech
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [Node.js] moving from npm to Yarn & how it impacts oVirt JS applications

[Vojtech Szocs]

- Original Message -
> From: "Vojtech Szocs" 
> To: "devel" 
> Sent: Thursday, January 12, 2017 6:04:03 PM
> Subject: [ovirt-devel] [Node.js] moving from npm to Yarn & how it impacts 
> oVirt JS applications
> 
> Hello guys,
> 
> as you probably know, we're using Node.js (ovirt-engine-nodejs) to build
> some of our applications, including ovirt-engine-dashboard, ovirt-web-ui,
> cockpit-ovirt, and some others.
> 
> This is just to inform you that in ovirt-engine-nodejs-modules (RPM that
> bundles all of our JS dependencies), we're moving from npm to Yarn.
> 
> The related patch is here: https://gerrit.ovirt.org/#/c/69934/
> 
> nodejs-modules 1.0.0 will bump all dependencies to their latest version,
> plus add version locking.
> 
> To prepare for consuming nodejs-modules 1.0.0, please:
> 
> - make sure to test your applications with bumped dependencies
> - once the patch is merged, you can update your BuildRequires to 1.0.0
> - once we have an RPM for Yarn, you can start using it in your project

I wrote a patch that adds Yarn (as ovirt-engine-yarn RPM), along with
bumping Node.js version & updating nodejs-modules/setup-env.sh script:

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

> 
> Regards,
> Vojtech
> 
> ___
> 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] [Node.js] moving from npm to Yarn & how it impacts oVirt JS applications

[Vojtech Szocs]

Hello guys,

as you probably know, we're using Node.js (ovirt-engine-nodejs) to build
some of our applications, including ovirt-engine-dashboard, ovirt-web-ui,
cockpit-ovirt, and some others.

This is just to inform you that in ovirt-engine-nodejs-modules (RPM that
bundles all of our JS dependencies), we're moving from npm to Yarn.

The related patch is here: https://gerrit.ovirt.org/#/c/69934/

nodejs-modules 1.0.0 will bump all dependencies to their latest version,
plus add version locking.

To prepare for consuming nodejs-modules 1.0.0, please:

- make sure to test your applications with bumped dependencies
- once the patch is merged, you can update your BuildRequires to 1.0.0
- once we have an RPM for Yarn, you can start using it in your project

Regards,
Vojtech

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

Re: [ovirt-devel] PatternFly upgrade - how to handle JS dependencies

[Vojtech Szocs]

- Original Message -
> From: "Greg Sheremeta" 
> To: "Vojtech Szocs" 
> Cc: "devel" , "Oved Ourfali" , "Juan 
> Hernández" 
> Sent: Tuesday, January 10, 2017 10:28:06 PM
> Subject: Re: PatternFly upgrade - how to handle JS dependencies
> 
> On Tue, Jan 10, 2017 at 1:00 PM, Vojtech Szocs  wrote:
> 
> >
> >
> > - Original Message -
> > > From: "Greg Sheremeta" 
> > > To: "Vojtech Szocs" 
> > > Cc: "devel" , "Oved Ourfali" ,
> > "Juan Hernández" 
> > > Sent: Monday, January 9, 2017 9:46:18 PM
> > > Subject: Re: PatternFly upgrade - how to handle JS dependencies
> > >
> > > On Fri, Jan 6, 2017 at 12:45 PM, Vojtech Szocs 
> > wrote:
> > >
> > > > Hello,
> > > >
> > > > we'd like to upgrade the version of PatternFly (plus associated
> > libraries,
> > > > namely Bootstrap and jQuery) used in oVirt UI.
> > > >
> > > > Today, PatternFly stuff (PF + associated libraries) comes from
> > > > `patternfly1`
> > > > package hosted at Copr repo:
> > > >
> > > >   https://copr.fedorainfracloud.org/coprs/patternfly/patternfly1/
> > > >
> > > > Today, we require `patternfly1` as both Engine RPM build dependency
> > and the
> > > > Engine devel. env. dependency.
> > > >
> > > > To keep things simple, I'd like to propose the following approach:
> > > >
> > > > - create oVirt specific package, e.g. `ovirt-patternfly`, hosted at
> > Copr,
> > > >   containing PatternFly + associated libraries (Bootstrap, jQuery)
> > which
> > > >   are intended *specifically* for use by oVirt UI (hence the ovirt
> > prefix)
> > > >
> > >
> > > I've already done this, although it's currently named 'patternfly3'
> > > https://copr.fedorainfracloud.org/coprs/patternfly/patternfly3/
> >
> > I really think we should put some `ovirt` prefix there, to avoid
> > people thinking that it's some kind of general-purpose PatternFly
> > package.
> >
> > For example, `ovirt-engine-ui-dependencies` (for Engine GWT UI).
> >
> 
> That's fine. I had created the repo long before your suggestion, that's all.

I know, I just wanted to suggest the future change.

Having `patternfly3` right now allows us to experiment with upgrading
the PatternFly version in GWT UI so for the moment, I'm OK with that.

> 
> I think it should have 'js' in the name somewhere.

OK, this is Martin's suggestion actually =) ovirt-js-dependencies.

> 
> 
> >
> > >
> > > However, we want to move it to our ovirt infra because copr sometimes
> > goes
> > > down, and that breaks CI jobs.
> >
> > If we really want to do that, maybe we should add a new project
> > into releng-tools repo. The project would be at
> >
> >   releng-tools/specs/ovirt-engine-ui-dependencies
> >
> > containing package.json and build script that downloads JS dep's
> > and then packages all JS stuff as RPM.
> >
> > (Basically a very similar build process as with nodejs-modules.)
> >
> 
> Sure, that sounds good. Let me verify with infra where it should go.

Thanks.

Note that I'm totally OK with Copr too. But having an RPM built by
oVirt infra (with JS dependencies fetched in a way consistent with
e.g. nodejs-modules) indeed seems as the more correct approach.

> 
> 
> >
> > >
> > > So, +1 from me, but let's move to ovirt infra.
> > >
> > >
> > > >
> > > > - discontinue maintenance of `patternfly1` package at Copr
> > > >
> > > > - keep the existing approach: require `ovirt-patternfly` as both the
> > Engine
> > > >   build dependency and the Engine devel. env. dependency
> > > >
> > > > An alternative approach would be to introduce Node.js as Engine devel.
> > env.
> > > > dependency (use `npm install` to pull PF stuff), while using the
> > existing
> > > > ovirt-engine-{nodejs,nodejs-modules} packages for Engine RPM build.
> > > >
> > > > However, this alternative has some downsides, namely complication of
> > devel.
> > > > env. just to fetch the PF stuff. I don't like the idea of complicating
> > the
> > > > existing devel. env. just for the sake of fetching some 3rd party libs.
> > > >
> > > > I'm wondering what others think about this.
> > > >
> > > > Regards,
> > > > Vojtech
> > > >
> > >
> > >
> > >
> > > --
> > > Greg Sheremeta, MBA
> > > Red Hat, Inc.
> > > Sr. Software Engineer
> > > gsher...@redhat.com
> > >
> >
> 
> 
> 
> --
> Greg Sheremeta, MBA
> Red Hat, Inc.
> Sr. Software Engineer
> gsher...@redhat.com
> 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] PatternFly upgrade - how to handle JS dependencies

[Vojtech Szocs]

- Original Message -
> From: "Greg Sheremeta" 
> To: "Vojtech Szocs" 
> Cc: "devel" , "Oved Ourfali" , "Juan 
> Hernández" 
> Sent: Monday, January 9, 2017 9:46:18 PM
> Subject: Re: PatternFly upgrade - how to handle JS dependencies
> 
> On Fri, Jan 6, 2017 at 12:45 PM, Vojtech Szocs  wrote:
> 
> > Hello,
> >
> > we'd like to upgrade the version of PatternFly (plus associated libraries,
> > namely Bootstrap and jQuery) used in oVirt UI.
> >
> > Today, PatternFly stuff (PF + associated libraries) comes from
> > `patternfly1`
> > package hosted at Copr repo:
> >
> >   https://copr.fedorainfracloud.org/coprs/patternfly/patternfly1/
> >
> > Today, we require `patternfly1` as both Engine RPM build dependency and the
> > Engine devel. env. dependency.
> >
> > To keep things simple, I'd like to propose the following approach:
> >
> > - create oVirt specific package, e.g. `ovirt-patternfly`, hosted at Copr,
> >   containing PatternFly + associated libraries (Bootstrap, jQuery) which
> >   are intended *specifically* for use by oVirt UI (hence the ovirt prefix)
> >
> 
> I've already done this, although it's currently named 'patternfly3'
> https://copr.fedorainfracloud.org/coprs/patternfly/patternfly3/

I really think we should put some `ovirt` prefix there, to avoid
people thinking that it's some kind of general-purpose PatternFly
package.

For example, `ovirt-engine-ui-dependencies` (for Engine GWT UI).

> 
> However, we want to move it to our ovirt infra because copr sometimes goes
> down, and that breaks CI jobs.

If we really want to do that, maybe we should add a new project
into releng-tools repo. The project would be at

  releng-tools/specs/ovirt-engine-ui-dependencies

containing package.json and build script that downloads JS dep's
and then packages all JS stuff as RPM.

(Basically a very similar build process as with nodejs-modules.)

> 
> So, +1 from me, but let's move to ovirt infra.
> 
> 
> >
> > - discontinue maintenance of `patternfly1` package at Copr
> >
> > - keep the existing approach: require `ovirt-patternfly` as both the Engine
> >   build dependency and the Engine devel. env. dependency
> >
> > An alternative approach would be to introduce Node.js as Engine devel. env.
> > dependency (use `npm install` to pull PF stuff), while using the existing
> > ovirt-engine-{nodejs,nodejs-modules} packages for Engine RPM build.
> >
> > However, this alternative has some downsides, namely complication of devel.
> > env. just to fetch the PF stuff. I don't like the idea of complicating the
> > existing devel. env. just for the sake of fetching some 3rd party libs.
> >
> > I'm wondering what others think about this.
> >
> > Regards,
> > Vojtech
> >
> 
> 
> 
> --
> Greg Sheremeta, MBA
> Red Hat, Inc.
> Sr. Software Engineer
> gsher...@redhat.com
> 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] PatternFly upgrade - how to handle JS dependencies

[Vojtech Szocs]

- Original Message -
> From: "Sven Kieske" 
> To: devel@ovirt.org
> Sent: Saturday, January 7, 2017 5:01:37 PM
> Subject: Re: [ovirt-devel] PatternFly upgrade - how to handle JS dependencies
> 
> On 06/01/17 18:45, Vojtech Szocs wrote:
> > Today, we require `patternfly1` as both Engine RPM build dependency and the
> > Engine devel. env. dependency.
> > 
> > To keep things simple, I'd like to propose the following approach:
> > 
> > - create oVirt specific package, e.g. `ovirt-patternfly`, hosted at Copr,
> >   containing PatternFly + associated libraries (Bootstrap, jQuery) which
> >   are intended *specifically* for use by oVirt UI (hence the ovirt prefix)
> > 
> > - discontinue maintenance of `patternfly1` package at Copr
> 
> afaik you're also requiring patternfly1 for ovirt-engine installation,
> not just dev or build env?

Sven, you are correct.

Today, `patternfly1` is needed at Engine RPM install-time (via Requires)
and as Engine devel. env. pre-requisite.

It's not needed at Engine RPM build-time (no BuildRequires). Apologies
for confusion. I realized it after I sent my mail..

> 
> if that is correct and your new "ovirt-patternfly" would superseed that
> I'm afraid you would violate fedora and rhel/centos package guidelines
> by throwing this all together in one package?

The newly proposed package should be oVirt-specific, for oVirt by oVirt.
It's not meant to be a general-purpose RPM containing PatternFly stuff.

Is it a violation of Fedora pkg guidelines if a project creates its own
package, bundling 3rd party dependencies?

> 
> I hope I understood the scope of this correct, if not, just disregard my
> comment.
> 
> --
> Mit freundlichen Grüßen / Regards
> 
> Sven Kieske
> 
> Systemadministrator
> Mittwald CM Service GmbH & Co. KG
> Königsberger Straße 6
> 32339 Espelkamp
> T: +495772 293100
> F: +495772 29
> https://www.mittwald.de
> Geschäftsführer: Robert Meyer
> St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
> Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
> 
> 
> ___
> 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] PatternFly upgrade - how to handle JS dependencies

[Vojtech Szocs]

- Original Message -
> From: "Martin Perina" 
> To: "Vojtech Szocs" 
> Cc: "devel" , "Juan Hernández" 
> Sent: Friday, January 6, 2017 10:14:22 PM
> Subject: Re: [ovirt-devel] PatternFly upgrade - how to handle JS dependencies
> 
> On Fri, Jan 6, 2017 at 6:45 PM, Vojtech Szocs  wrote:
> 
> > Hello,
> >
> > we'd like to upgrade the version of PatternFly (plus associated libraries,
> > namely Bootstrap and jQuery) used in oVirt UI.
> >
> > Today, PatternFly stuff (PF + associated libraries) comes from
> > `patternfly1`
> > package hosted at Copr repo:
> >
> >   https://copr.fedorainfracloud.org/coprs/patternfly/patternfly1/
> >
> > Today, we require `patternfly1` as both Engine RPM build dependency and the
> > Engine devel. env. dependency.
> >
> > To keep things simple, I'd like to propose the following approach:
> >
> > - create oVirt specific package, e.g. `ovirt-patternfly`, hosted at Copr,
> >   containing PatternFly + associated libraries (Bootstrap, jQuery) which
> >   are intended *specifically* for use by oVirt UI (hence the ovirt prefix)
> >
> > - discontinue maintenance of `patternfly1` package at Copr
> >
> > - keep the existing approach: require `ovirt-patternfly` as both the Engine
> >   build dependency and the Engine devel. env. dependency
> >
> 
> ​+1 from me.
> 
> The only issue is that we combine several javascript libraries in a package
> named ovirt-patternfly.

Well, this is the same approach like with ovirt-engine-nodejs-modules,
with a difference that nodejs-modules is intended for build-time only.

The proposed `ovirt-patternfly` (or whatever it's called) is intended
for Engine run-time + as Engine devel. env. pre-requisite.

The idea is to bundle all JS/CSS/etc. files required by $PROJECT into
a single package. In case of `ovirt-patternfly`, $PROJECT == Engine.

> Is there a high probabily that we will need some
> other javascript libraries in near future?

Not too likely, but there's always the chance.

> If so, then I'd rather call the
> package ovirt-javascript-dependencies (or ovirt-js-dependencies).

OK, maybe even putting `engine` in the name, since we actually need it
for the Engine (GWT UI), e.g. `ovirt-engine-ui-dependencies`.

> ​
> 
> 
> >
> > An alternative approach would be to introduce Node.js as Engine devel. env.
> > dependency (use `npm install` to pull PF stuff), while using the existing
> > ovirt-engine-{nodejs,nodejs-modules} packages for Engine RPM build.
> >
> > However, this alternative has some downsides, namely complication of devel.
> > env. just to fetch the PF stuff. I don't like the idea of complicating the
> > existing devel. env. just for the sake of fetching some 3rd party libs.
> >
> > I'm wondering what others think about this.
> >
> > Regards,
> > Vojtech
> > ___
> > 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] PatternFly upgrade - how to handle JS dependencies

[Vojtech Szocs]

Hello,

we'd like to upgrade the version of PatternFly (plus associated libraries,
namely Bootstrap and jQuery) used in oVirt UI.

Today, PatternFly stuff (PF + associated libraries) comes from `patternfly1`
package hosted at Copr repo:

  https://copr.fedorainfracloud.org/coprs/patternfly/patternfly1/

Today, we require `patternfly1` as both Engine RPM build dependency and the
Engine devel. env. dependency.

To keep things simple, I'd like to propose the following approach:

- create oVirt specific package, e.g. `ovirt-patternfly`, hosted at Copr,
  containing PatternFly + associated libraries (Bootstrap, jQuery) which
  are intended *specifically* for use by oVirt UI (hence the ovirt prefix)

- discontinue maintenance of `patternfly1` package at Copr

- keep the existing approach: require `ovirt-patternfly` as both the Engine
  build dependency and the Engine devel. env. dependency

An alternative approach would be to introduce Node.js as Engine devel. env.
dependency (use `npm install` to pull PF stuff), while using the existing
ovirt-engine-{nodejs,nodejs-modules} packages for Engine RPM build.

However, this alternative has some downsides, namely complication of devel.
env. just to fetch the PF stuff. I don't like the idea of complicating the
existing devel. env. just for the sake of fetching some 3rd party libs.

I'm wondering what others think about this.

Regards,
Vojtech
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Publicly available REST documentation

[Vojtech Szocs]

- Original Message -
> From: "Rafael Martins" 
> To: "Vojtech Szocs" 
> Cc: "Juan Hernández" , "Michal Skrivanek" 
> , "devel" 
> Sent: Tuesday, January 3, 2017 2:28:30 PM
> Subject: Re: [ovirt-devel] Publicly available REST documentation
> 
> 
> 
> - Original Message -
> > From: "Vojtech Szocs" 
> > To: "Rafael Martins" 
> > Cc: "Juan Hernández" , "Michal Skrivanek"
> > , "devel" 
> > Sent: Tuesday, January 3, 2017 2:24:22 PM
> > Subject: Re: [ovirt-devel] Publicly available REST documentation
> > 
> > 
> > 
> > - Original Message -
> > > From: "Rafael Martins" 
> > > To: "Vojtech Szocs" 
> > > Cc: "Juan Hernández" , "Michal Skrivanek"
> > > , "devel" 
> > > Sent: Tuesday, January 3, 2017 2:17:49 PM
> > > Subject: Re: [ovirt-devel] Publicly available REST documentation
> > > 
> > > - Original Message -
> > > > From: "Vojtech Szocs" 
> > > > To: "Juan Hernández" 
> > > > Cc: "Michal Skrivanek" , "devel" 
> > > > Sent: Tuesday, January 3, 2017 2:11:06 PM
> > > > Subject: Re: [ovirt-devel] Publicly available REST documentation
> > > > 
> > > > 
> > > > 
> > > > - Original Message -
> > > > > From: "Juan Hernández" 
> > > > > To: "Jakub Niedermertl" 
> > > > > Cc: "devel" , "Michal Skrivanek"
> > > > > 
> > > > > Sent: Monday, January 2, 2017 10:48:53 PM
> > > > > Subject: Re: [ovirt-devel] Publicly available REST documentation
> > > > > 
> > > > > On 01/02/2017 10:13 PM, Jakub Niedermertl wrote:
> > > > > > Hi Juan,
> > > > > > 
> > > > > > from time to time I'd like the REST doc to be available on some
> > > > > > public
> > > > > > site. It would allow us to
> > > > > > * check the documentation without searching for running engine
> > > > > > * be able to easily link documentations in irc/mails
> > > > > > * link rest doc from ovirt.org site doc
> > > > > > Recently I've also heard similar request from other guys (cc-ed).
> > > > > > Would it be possible to for example publish generated doc of merged
> > > > > > patches of ovirt-engine-api-model project? Maybe github project
> > > > > > pages
> > > > > > [1] of project mirror [2] could be used for hosting.
> > > > > > 
> > > > > > Regards
> > > > > > Jakub
> > > > > > 
> > > > > > [1]
> > > > > > https://help.github.com/articles/user-organization-and-project-pages/#project-pages
> > > > > > [2] https://github.com/oVirt/ovirt-engine-api-model
> > > > > > 
> > > > > 
> > > > > Yes, we can publish the documentation using gh-pages. I just created
> > > > > and
> > > > > populated the 'gh-branch' with some initial content, and requested
> > > > > the
> > > > > activation of the feature in Github. I will inform you when it is
> > > > > ready.
> > > > 
> > > > Alternatively, you could use readthedocs.org which supports webhooks:
> > > > a push to GitHub (mirror) project [syncing Gerrit with GitHub] would
> > > > regenerate the project's documentation available at
> > > > 
> > > >   .readthedocs.io
> > > > 
> > > > which would allow to separate the GitHub project from its docs, given
> > > > the source comes from Gerrit.
> > > 
> > > ReadTheDocs relies on sphinx and/or mkdocs to rebuild the docs when
> > > called
> > > by
> > > the webhook, and we use something else. We just need some hosting for
> > > static
> > > files, then github-pages is a better solution.
> > 
> > Hm, and what about pushing to https://github.com/oVirt/ovirt-site directly,
> > instead of pushing to GitHub (mirror) project pages?
> 
> there's no real need to mess with the ovirt-site repo. we can have a
> separated repo, that can be freely updated by a jenkins job, for example,
> and include it on ovirt-site using a sub-repository, like it is done for
> data/events today. The good thing of this approach is that we can have
> "unstable" docs in the separated repo, updated by jenkins, and just checkout
> stable versions on the ovirt-site subrepo.

I like the idea of  as sub-repo of  :)

Thanks for your response, it makes sense.

> 
> Rafael
> 
> > > 
> > > Thanks.
> > > Rafael
> > > 
> > > > > ___
> > > > > 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] Publicly available REST documentation

[Vojtech Szocs]

- Original Message -
> From: "Rafael Martins" 
> To: "Vojtech Szocs" 
> Cc: "Juan Hernández" , "Michal Skrivanek" 
> , "devel" 
> Sent: Tuesday, January 3, 2017 2:17:49 PM
> Subject: Re: [ovirt-devel] Publicly available REST documentation
> 
> - Original Message -
> > From: "Vojtech Szocs" 
> > To: "Juan Hernández" 
> > Cc: "Michal Skrivanek" , "devel" 
> > Sent: Tuesday, January 3, 2017 2:11:06 PM
> > Subject: Re: [ovirt-devel] Publicly available REST documentation
> > 
> > 
> > 
> > - Original Message -
> > > From: "Juan Hernández" 
> > > To: "Jakub Niedermertl" 
> > > Cc: "devel" , "Michal Skrivanek" 
> > > Sent: Monday, January 2, 2017 10:48:53 PM
> > > Subject: Re: [ovirt-devel] Publicly available REST documentation
> > > 
> > > On 01/02/2017 10:13 PM, Jakub Niedermertl wrote:
> > > > Hi Juan,
> > > > 
> > > > from time to time I'd like the REST doc to be available on some public
> > > > site. It would allow us to
> > > > * check the documentation without searching for running engine
> > > > * be able to easily link documentations in irc/mails
> > > > * link rest doc from ovirt.org site doc
> > > > Recently I've also heard similar request from other guys (cc-ed).
> > > > Would it be possible to for example publish generated doc of merged
> > > > patches of ovirt-engine-api-model project? Maybe github project pages
> > > > [1] of project mirror [2] could be used for hosting.
> > > > 
> > > > Regards
> > > > Jakub
> > > > 
> > > > [1]
> > > > https://help.github.com/articles/user-organization-and-project-pages/#project-pages
> > > > [2] https://github.com/oVirt/ovirt-engine-api-model
> > > > 
> > > 
> > > Yes, we can publish the documentation using gh-pages. I just created and
> > > populated the 'gh-branch' with some initial content, and requested the
> > > activation of the feature in Github. I will inform you when it is ready.
> > 
> > Alternatively, you could use readthedocs.org which supports webhooks:
> > a push to GitHub (mirror) project [syncing Gerrit with GitHub] would
> > regenerate the project's documentation available at
> > 
> >   .readthedocs.io
> > 
> > which would allow to separate the GitHub project from its docs, given
> > the source comes from Gerrit.
> 
> ReadTheDocs relies on sphinx and/or mkdocs to rebuild the docs when called by
> the webhook, and we use something else. We just need some hosting for static
> files, then github-pages is a better solution.

Hm, and what about pushing to https://github.com/oVirt/ovirt-site directly,
instead of pushing to GitHub (mirror) project pages?

> 
> Thanks.
> Rafael
> 
> > > ___
> > > 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] Publicly available REST documentation

[Vojtech Szocs]

- Original Message -
> From: "Juan Hernández" 
> To: "Jakub Niedermertl" 
> Cc: "devel" , "Michal Skrivanek" 
> Sent: Monday, January 2, 2017 10:48:53 PM
> Subject: Re: [ovirt-devel] Publicly available REST documentation
> 
> On 01/02/2017 10:13 PM, Jakub Niedermertl wrote:
> > Hi Juan,
> > 
> > from time to time I'd like the REST doc to be available on some public
> > site. It would allow us to
> > * check the documentation without searching for running engine
> > * be able to easily link documentations in irc/mails
> > * link rest doc from ovirt.org site doc
> > Recently I've also heard similar request from other guys (cc-ed).
> > Would it be possible to for example publish generated doc of merged
> > patches of ovirt-engine-api-model project? Maybe github project pages
> > [1] of project mirror [2] could be used for hosting.
> > 
> > Regards
> > Jakub
> > 
> > [1]
> > https://help.github.com/articles/user-organization-and-project-pages/#project-pages
> > [2] https://github.com/oVirt/ovirt-engine-api-model
> > 
> 
> Yes, we can publish the documentation using gh-pages. I just created and
> populated the 'gh-branch' with some initial content, and requested the
> activation of the feature in Github. I will inform you when it is ready.

Alternatively, you could use readthedocs.org which supports webhooks:
a push to GitHub (mirror) project [syncing Gerrit with GitHub] would
regenerate the project's documentation available at

  .readthedocs.io

which would allow to separate the GitHub project from its docs, given
the source comes from Gerrit.

> ___
> 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 SLF4J in frontend code

[Vojtech Szocs]

- Original Message -
> From: "Tomas Jelinek" 
> To: "Vojtech Szocs" 
> Cc: "devel" 
> Sent: Monday, December 19, 2016 7:50:55 PM
> Subject: Re: [ovirt-devel] Using SLF4J in frontend code
> 
> On Mon, Dec 19, 2016 at 6:26 PM, Vojtech Szocs  wrote:
> 
> >
> >
> > - Original Message -
> > > From: "Tomas Jelinek" 
> > > To: "Vojtech Szocs" 
> > > Cc: "devel" 
> > > Sent: Thursday, December 15, 2016 8:27:10 AM
> > > Subject: Re: [ovirt-devel] Using SLF4J in frontend code
> > >
> > > On Wed, Dec 14, 2016 at 5:27 PM, Vojtech Szocs 
> > wrote:
> > >
> > > > Hi,
> > > >
> > > > I was looking into "why" we need to emulate SLF4J classes for usage
> > > > in GWT frontend (given that one should use java.util.logging instead):
> > > >
> > > >   frontend/webadmin/modules/gwt-extension/src/main/java/org/
> > > > ovirt/engine/ui/uioverrides/org/slf4j/Logger.java
> > > >   frontend/webadmin/modules/gwt-extension/src/main/java/org/
> > > > ovirt/engine/ui/uioverrides/org/slf4j/LoggerFactory.java
> > > >
> > > > I found two frontend-specific classes, which I fixed. However, I could
> > > > not remove ^^ SLF4J class overrides, because some shared (backend) code
> > > > still uses SLF4J, in particular:
> > > >
> > > >   VmRngDevice.java => backend, common module
> > > >   EnumValueAutoCompleter.java => backend, searchbackend module
> > > >   SyntaxChecker.java => backend, searchbackend module
> > > >
> > > > 1, should a backend business entity (VmRngDevice) perform logging?
> > > >
> > >
> > > Well, VmRngDevice has some data and has some logic. And since it has
> > logic,
> > > I think it should also be allowed to
> > > do some logging.
> > >
> > > I honestly don't have issues with entities to have some degree of logic,
> > > the problem is that they are sent to FE.
> >
> > If we adhere to existing backend design, all business logic should
> > be isolated into dedicated commands. This implies leaving entities
> > void of actual business logic.
> >
> > But VmRngDevice#csvToSourcesSet isn't really business logic, it's
> > just a utility to parse String into Set.
> 
> 
> Lets not start a discussion if this is a logic or business logic or utility
> function or whatever kind of logic :)
> 
> So, what are you proposing? Extract it to a utility class?

Yes, ideally, we'd extract it to a class which doesn't belong into
any "visible by GWT" package [1]:

  org.ovirt.engine.core.(common|compat)

[1] see `gwt.dontPrune` in frontend/webadmin/modules/pom.xml

VmRngDevice#csvToSourcesSet is clearly a utility to parse a string
fetched from DB via DAOs [additional_rng_sources] or from host via
JSON RPC [VDSInfoReturn]; makes no sense for GWT compiler to see it.

> 
> 
> >
> 
> Just wondering why
> > are we suppressing IllegalArgumentException (parse errors) there.
> >
> 
> Because of this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1374216
> Long story short, the host can return us a rng device we don't know about
> and we don't want to die on it.
> Could be implemented also in a nicer way, but it is correct...
> 
> > But this is an old decision and we need to live with it (for now). That
> > > particular log statement looks quite useful to me and I
> > > would not remove it.
> >
> > The thing is, VmRngDevice#csvToSourcesSet is only called on backend,
> > but since we tell GWT compiler that all business entity code is live
> > (via DontPrune aspect), we still need to emulate SLF4J logging API..
> >
> > >
> > >
> > > > 2, assuming "searchbackend" functionality is exposed only via the GWT
> > > >frontend, why it's represented as a backend module?

Is it OK to move searchbackend under frontend/webadmin/modules?

If not, is it OK to remove org.slf4j.* imports in searchbackend
and replace them with java.util.logging.* imports?

Also, as searchbackend is currently in backend/manager/modules,
the searchbackend.jar is deployed to WildFly [2] even though it
isn't used by any backend code.. (only needed for GWT compile,
since the functionality is exposed only through GWT UI..)

[2] 
/usr/share/ovirt-engine/modules/common/org/ovirt/engine/core/searchbackend/main/searchbackend.jar

> > > >
> > > > Thanks,
> > > > Vojtech
> > > > ___
> > > > Devel mailing list
> > > > Devel@ovirt.org
> > > > http://lists.phx.ovirt.org/mailman/listinfo/devel
> > > >
> > >
> >
> 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ACTION REQUIRED] ovirt-cokpit broken, please fix

[Vojtech Szocs]

- Original Message -
> From: "Marek Libra" 
> To: "Sandro Bonazzola" 
> Cc: "devel" 
> Sent: Friday, December 16, 2016 2:36:05 PM
> Subject: Re: [ovirt-devel] [ACTION REQUIRED] ovirt-cokpit broken, please fix
> 
> Not sure yet, but most probably with updating nodejs in ovirt-engine-nodejs
> we need to update babel to 6.10.4 or higher in ovirt-engine-nodejs-modules
> as well.

Hi Marek, this looks similar to https://github.com/webpack/webpack/issues/3242

In particular, see 
https://github.com/webpack/webpack/issues/3242#issuecomment-260411104

Since our Node.js dependencies (ovirt-engine-nodejs-modules) aren't locked
down (yet), doing `npm install` locally pulls the latest (fixed ^^) versions
of dependencies (e.g. webpack loaders/plugins) -> local build succeeds.

In CI, the build fails because it uses the ovirt-engine-nodejs-modules RPM
built previously. (containing older dependencies)

I'm still working on that Yarn & dep. lock-down stuff (among other things).

> 
> On Fri, Dec 16, 2016 at 11:45 AM, Sandro Bonazzola < sbona...@redhat.com >
> wrote:
> 
> 
> 
> http://jenkins.ovirt.org/job/cockpit-ovirt_master_check-merged-el7-x86_64/128/artifact/exported-artifacts/logs/mocker-epel-7-x86_64.el7.check-merged.sh/check-merged.sh.log
> 
> WARNING in bundle.js from UglifyJs
> Side effects in initialization of unused variable CONFIG
> [./src/constants.js:2,13]
> Side effects in initialization of unused variable VM_STATUS_ICONS_PATH_PREFIX
> [./src/constants.js:42,13]
> Side effects in initialization of unused variable VM_STATUS_ICONS
> [./src/constants.js:43,13]
> Side effects in initialization of unused variable GLOBAL
> [./src/globaldata.js:1,11]
> Condition always true [./~/d3/d3.js:9553,0]
> Dropping unreachable code [./~/d3/d3.js:9553,75]
> Condition always true [./~/c3/c3.js:52,0]
> Condition always true [./~/c3/c3.js:8194,0]
> Dropping unreachable code [./~/c3/c3.js:8196,5]
> Condition always false [./~/style-loader/addStyles.js:24,0]
> Dropping unreachable code [./~/style-loader/addStyles.js:25,0]
> Condition always false
> [./~/style-loader!./~/css-loader!./~/patternfly/dist/css/patternfly-additions.css:10,0]
> Dropping unreachable code
> [./~/style-loader!./~/css-loader!./~/patternfly/dist/css/patternfly-additions.css:12,0]
> Side effects in initialization of unused variable update
> [./~/style-loader!./~/css-loader!./~/patternfly/dist/css/patternfly-additions.css:7,0]
> Condition always false
> [./~/style-loader!./~/css-loader!./~/patternfly/dist/css/patternfly.css:10,0]
> Dropping unreachable code
> [./~/style-loader!./~/css-loader!./~/patternfly/dist/css/patternfly.css:12,0]
> Side effects in initialization of unused variable update
> [./~/style-loader!./~/css-loader!./~/patternfly/dist/css/patternfly.css:7,0]
> 
> ERROR in Path must be a string. Received undefined
> chmod a+x dist/vdsm/vdsm
> chmod: cannot access ‘dist/vdsm/vdsm’: No such file or directory
> make[1]: *** [vdsm] Error 1
> make[1]: Leaving directory
> `/home/jenkins/workspace/cockpit-ovirt_master_check-merged-el7-x86_64/cockpit-ovirt/vdsm'
> make: *** [check-recursive] Error 1
> Took 229 seconds
> 
> --
> 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
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Using SLF4J in frontend code

[Vojtech Szocs]

- Original Message -
> From: "Tomas Jelinek" 
> To: "Vojtech Szocs" 
> Cc: "devel" 
> Sent: Thursday, December 15, 2016 8:27:10 AM
> Subject: Re: [ovirt-devel] Using SLF4J in frontend code
> 
> On Wed, Dec 14, 2016 at 5:27 PM, Vojtech Szocs  wrote:
> 
> > Hi,
> >
> > I was looking into "why" we need to emulate SLF4J classes for usage
> > in GWT frontend (given that one should use java.util.logging instead):
> >
> >   frontend/webadmin/modules/gwt-extension/src/main/java/org/
> > ovirt/engine/ui/uioverrides/org/slf4j/Logger.java
> >   frontend/webadmin/modules/gwt-extension/src/main/java/org/
> > ovirt/engine/ui/uioverrides/org/slf4j/LoggerFactory.java
> >
> > I found two frontend-specific classes, which I fixed. However, I could
> > not remove ^^ SLF4J class overrides, because some shared (backend) code
> > still uses SLF4J, in particular:
> >
> >   VmRngDevice.java => backend, common module
> >   EnumValueAutoCompleter.java => backend, searchbackend module
> >   SyntaxChecker.java => backend, searchbackend module
> >
> > 1, should a backend business entity (VmRngDevice) perform logging?
> >
> 
> Well, VmRngDevice has some data and has some logic. And since it has logic,
> I think it should also be allowed to
> do some logging.
> 
> I honestly don't have issues with entities to have some degree of logic,
> the problem is that they are sent to FE.

If we adhere to existing backend design, all business logic should
be isolated into dedicated commands. This implies leaving entities
void of actual business logic.

But VmRngDevice#csvToSourcesSet isn't really business logic, it's
just a utility to parse String into Set. Just wondering why
are we suppressing IllegalArgumentException (parse errors) there.

> But this is an old decision and we need to live with it (for now). That
> particular log statement looks quite useful to me and I
> would not remove it.

The thing is, VmRngDevice#csvToSourcesSet is only called on backend,
but since we tell GWT compiler that all business entity code is live
(via DontPrune aspect), we still need to emulate SLF4J logging API..

> 
> 
> > 2, assuming "searchbackend" functionality is exposed only via the GWT
> >frontend, why it's represented as a backend module?
> >
> > Thanks,
> > Vojtech
> > ___
> > Devel mailing list
> > Devel@ovirt.org
> > http://lists.phx.ovirt.org/mailman/listinfo/devel
> >
> 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] Using SLF4J in frontend code

[Vojtech Szocs]

Hi,

I was looking into "why" we need to emulate SLF4J classes for usage
in GWT frontend (given that one should use java.util.logging instead):

  
frontend/webadmin/modules/gwt-extension/src/main/java/org/ovirt/engine/ui/uioverrides/org/slf4j/Logger.java
  
frontend/webadmin/modules/gwt-extension/src/main/java/org/ovirt/engine/ui/uioverrides/org/slf4j/LoggerFactory.java

I found two frontend-specific classes, which I fixed. However, I could
not remove ^^ SLF4J class overrides, because some shared (backend) code
still uses SLF4J, in particular:

  VmRngDevice.java => backend, common module
  EnumValueAutoCompleter.java => backend, searchbackend module
  SyntaxChecker.java => backend, searchbackend module

1, should a backend business entity (VmRngDevice) perform logging?
2, assuming "searchbackend" functionality is exposed only via the GWT
   frontend, why it's represented as a backend module?

Thanks,
Vojtech
___
Devel mailing list
Devel@ovirt.org
http://lists.phx.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] SSO/CORS for remote non-Java apps

[Vojtech Szocs]

Hi,

I agree with Juan that handling the list of "allowed origins" for CORS
filter should be done carefully, since that filter applies to each and
every REST API request.

> For completeness, there's already another patch providing SSO for non-GWT 
> applications, but deployed along with the ovirt-engine and packaged in .war, 
> no matter if the application itself is non-Java one.
> See https://gerrit.ovirt.org/#/c/67206/ .

That ^^ new filter is for enginesso.war or a different .war?

The general problem is, from an external web application perspective,
how to:

a, obtain SSO token

   - reusing some "externally given" token is generally a bad idea,
 unless the external application is "under control" of enclosing
 application that issued the token, for example => UI plugins

   - therefore, requesting new token per each external application
 should be the way to go, in general

b, call REST API with SSO token

   - using HTTP basic auth is generally a bad idea (many reasons)

c, (optional, just an idea) tighter UI integration

   - add infra to manage "trusted" web applications, these will show
 up on the oVirt welcome page

   - when accessing "trusted" web application (via the welcome page),
 get current user's SSO token and pass it to that application

As for CORS "allowed origins" list: this is currently managed through
`CORSAllowedOrigins` Engine config value. This list is read only once
(on 1st CORSSupportFilter access). So any change in following options:

  CORSSupport # true or false
  CORSAllowedOrigins # comma separated list of protocol://domain:port

requires Engine restart, which isn't too flexible.

After we acknowledge that CORS is a necessary feature of oVirt Engine
(in relation to SSO/REST usage from external application context), we
should introduce a better interface to manage CORS settings, *without*
having to restart Engine on each change.

Regards,
Vojtech


- Original Message -
> From: "Juan Hernández" 
> To: "Marek Libra" , "devel" 
> Sent: Monday, December 12, 2016 9:22:03 AM
> Subject: Re: [ovirt-devel] SSO/CORS for remote non-Java apps
> 
> On 12/12/2016 08:03 AM, Marek Libra wrote:
> > The proposed way is:
> > - use CORS filter for enginesso.war (https://gerrit.ovirt.org/68062)
> > - at host installation, add the host to CORSAllowedOrigins
> >- on engine host: # engine-config -s 'CORSAllowedOrigins=[host IPs]'
> > 
> > So if Cockpit's plugin accesses the oVirt REST API, CORS will work.'
> > 
> 
> Note that adding the host with 'engine-config' isn't ideal, as it would
> require to restart the engine whenever a host is installed. In addition
> you would also need to find a way to update the configuration when a
> host is removed.
> 
> I think that it would be better to change the CORS filter so that it
> gets the list of allowed origins running a query that returns the list
> of hosts. That needs to be done with care, probably caching it somehow,
> as otherwise that query would run once for each API request, killing
> performance. I suggest something like this:
> 
> 1. Store in the backend, in memory, the list of allowed origins.
> 
> 2. During startup populate that with the list of hosts.
> 
> 3. Whenever a host is added or removed (with the corresponding backend
> command) update that list.
> 
> 4. Add a new backend query that returns that list stored in memory
> (without database access).
> 
> 5. Modify the CORS filter so that it executes that query to get the list
> of allowed hosts. Runing this query should be avoided for non-CORS requests.
> 
> > On Fri, Dec 9, 2016 at 3:42 PM, Marek Libra  > > wrote:
> > 
> > Hi,
> > 
> > How can external, purely JavaScript application, running in a
> > browser and served from non-engine host access the oVirt REST API?
> > 
> > Recent SSO implementation does not provide CORS support. It can be
> > fixed by https://gerrit.ovirt.org/68062 .
> > 
> > How shall this support for external application look like?
> > 
> > More details are in our so far discussion with Juan bellow.
> > 
> > For completeness, there's already another patch providing SSO for
> > non-GWT applications, but deployed along with the ovirt-engine and
> > packaged in .war, no matter if the application itself is non-Java one.
> > See https://gerrit.ovirt.org/#/c/67206/
> >  .
> > 
> > -- Forwarded message --
> > From: *Juan Hernández*  > >
> > Date: Fri, Dec 9, 2016 at 2:40 PM
> > Subject: Re: CORSSuport
> > To: Marek Libra mailto:mli...@redhat.com>>
> > 
> > 
> > On 12/09/2016 02:26 PM, Marek Libra wrote:
> > > Thanks for your quick response and fast action :-)
> > >
> > > I'm working on integration of oVirt to Cockpit, ideally purely JS
> > > application (Cockpit's plugin) will access oVirt REST API without
> > > using
> > > any proxy.
> >

Re: [ovirt-devel] Gerrit parallel patch handling and CI (Or, why did my code fail post-merge)

[Vojtech Szocs]

- Original Message -
> From: "Barak Korren" 
> To: "Vojtech Szocs" 
> Cc: "devel" 
> Sent: Thursday, December 1, 2016 9:10:19 AM
> Subject: Re: [ovirt-devel] Gerrit parallel patch handling and CI (Or, why did 
> my code fail post-merge)
> 
> On 30 November 2016 at 19:12, Vojtech Szocs  wrote:
> >
> > So before we adopt auto-submit-after-ci-pass (e.g. using Zuul, as Eyal
> > mentioned in that thread), we should be able to manually trigger heavy
> > CI (check-merged) job from Gerrit web interface, is that correct?
> 
> We could make it a two-step operation where you indicate you want to
> submit, wait for the CI output and then click submit - but why not
> just let the system submit for you?
> 
> One road I don't think we should go down is to have 3 CI stages:
> "light" check_patch, "heavy" check_patch and "pre-merge", this looks
> like a design smell to me.
> 
> WRT Zuul:
> 
> Unless you are using a strict policy like ff-only (which so far seems
> no to scale, because it is essentially a GIL on merging), Zuul is
> essential in order to test the right code in CI (even just for basic
> check_patch testing). So we are working to bring it in (See OVIRT-734
> [1] and OVIRT-882 [2]).

Thanks for sharing those links.

I didn't know you're already working on adopting Zuul, my bad =)

So the maintainer can simply express his/her intent to merge the given
patch, and CI infra takes care of the rest (run heavy tests and submit
changes if successful).

> 
> WRT merge gating - Zuul tries to make the process "fire and forget" as
> far as maintainers are concerned - if failures are found, it actually
> tries out different combinations of patches to see if, from a set of
> patches that were asked to be merged, some could be merged even when
> others could not.

I'd be cautious with this feature, since our heavy CI tests involve
GWT compilation, so Zuul trying to run more tests (on different patch
combinations) = more time spent.

> 
> > If so, it would be the patch owner's responsibility to submit (merge)
> > only after heavy CI (check-merged) pass?
> 
> The question hiding here is wither a maintainer could submit _without_
> passing the "heavy" CI. I'm guessing some maintainers will demand
> that, but I'm hoping in the long run this will not be needed and you
> will know that once submitted, a patch will be eventually merged
> unless it has real issues in it.

We cannot rule out issues that might happen in future. There will be
flaky/broken tests or CI infra issues, we need to decide how to deal
with those, I think.

> 
> > So we could actually write Gerrit plugin using MergeValidationListener
> > that would operate in the following way:
> > ...snip...
> 
> Just because something could be written doesn't mean it should - we
> are already stretched too thinly over too much code in the CI system,
> we do not want to maintain any more of it, certainly not in a core
> component like Gerrit.

It was just an idea =) Zuul sounds more like a proper solution.

> 
> Then again, this is a prioritization question - it not up to me to decide.
> 
> [1]: https://ovirt-jira.atlassian.net/browse/OVIRT-734
> [2]: https://ovirt-jira.atlassian.net/browse/OVIRT-882
> 
> --
> Barak Korren
> bkor...@redhat.com
> RHCE, RHCi, RHV-DevOps Team
> https://ifireball.wordpress.com/
> 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] performance improvements and gwt-rpc switch

[Vojtech Szocs]

Thanks Greg for the excellent write-up!

oVirt WebAdmin UI is quite complex, with lots of abstractions (the GWT
technology being a Java-on-top-of-Web-APIs abstraction itself) as well
as many features (and lots of dialogs..) so this task wasn't easy, but
I guess we managed to get UI into a stabilized state now.

Dialogs (non-singleton by design) were a major source of memory leaks,
so we added UI infra to ensure automatic dialog cleanup.

In 4.2, we'd like to upgrade GWT SDK version to latest stable (2.8.x)
which will hopefully improve GWT compiler performance and, importantly,
allow us to use Java 8 language features in our GWT UI code.

There's still potential for improvement, we're tracking that through:

  [tracker] oVirt UI performance improvements
  https://bugzilla.redhat.com/1378935

(some IE-specific improvements are already submitted as part of ^^)

Regards,
Vojtech


- Original Message -
> From: "Greg Sheremeta" 
> To: "devel" 
> Sent: Monday, November 28, 2016 7:43:27 PM
> Subject: [ovirt-devel] performance improvements and gwt-rpc switch
> 
> Hi everyone,
> 
> For the upcoming oVirt 4.1, the UX team has been focused hard on webadmin
> performance improvements. There have been some reports [1] [2] of UI
> sluggishness in both 3.6 and 4.0, usually after the browser had been open
> some time, and usually in scale environments.
> 
> After some research, we determined that the primary cause of this
> sluggishness was memory leaks.
> 
> We embarked on several weeks of hunting down memory leak bugs and squashing
> them. Alexander Wels and Vojtech Szocs led this work, and I helped test the
> performance of each patch as they created them. As they created patches to
> squash leaks, performance kept getting better and better. Today we've merged
> the last of our patches [*], and I'm happy to announce that we are now
> seeing much better UI performance on 4.1-master and 4.0.6.
> 
> Over the course of several hours with the browser window open, users should
> see no sluggishness at all.
> 
> [*] This last patch switches oVirt from using de-rpc to gwt-rpc in the
> frontend. This improves performance, but it also allows us to upgrade to GWT
> 2.8. We'd been previously blocked on that.
> 
> If you're interested in UI performance testing, continue reading. If not, you
> can stop here :)
> 
> .
> 
> To verify our performance improvements, we took some simple measurements
> using selenium webdriver. The tests were unscientific, but very helpful. We
> ran a webdriver flow through oVirt that clicked some buttons and tabs and
> refreshed some grids. We did it a few hundred or thousand times. The tests
> were run using stubbed hosts (ovirt-vdsmfake) so that only the engine and UI
> were under test.
> 
> Below are the important takeaways. The x axis is time, and each point on a
> graph is a loop through the same webdriver flow. The (ms) y axes are
> response times, and memory is in MB.
> 
> In this graph, we compare oVirt 4.1 with and without our most impactful patch
> applied. As you can see, with the patch applied, response time stays flat
> for 200 loops of my test script over the course of 18 and 43 minutes.
> Without the patch applied, response time quickly degraded such that 200
> loops of my test script took 1 hr 2 minutes vs. 18 minutes with the patch
> applied -- a 66% improvement!
> 
> In this graph [ignore the spike], we tested oVirt hard for 6 hours 25 minutes
> (2000 loops). As you can see, the response times stay relatively flat over 6
> hours! This is a great improvement. Do note that the memory is still
> growing, albeit much more slowly now. You can see towards the end of this
> run, maybe around hour 5, that the deviation starts to go up (the line
> thickens). Takeaway: maybe refresh your browser after many hours of having
> webadmin open. But, this is a stress test -- I'm betting users won't notice
> this slowdown after even 6 hours of regular webadmin use or idling.
> 
> ​
> Last, here is a graph that shows gwt-rpc performing slightly better than
> de-rpc. Memory consumption is about the same -- gwt-rpc is just a faster rpc
> implementation.
> 
> ​
> Reply with any questions or concerns. Thanks!
> 
> Best wishes,
> Greg
> 
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1368101
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1388462
> 
> --
> Greg Sheremeta, MBA
> Red Hat, Inc.
> Sr. Software Engineer
> gsher...@redhat.com
> 
> ___
> 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] Gerrit parallel patch handling and CI (Or, why did my code fail post-merge)

[Vojtech Szocs]

- Original Message -
> From: "Barak Korren" 
> To: "Vojtech Szocs" 
> Cc: "devel" 
> Sent: Wednesday, November 30, 2016 9:20:27 AM
> Subject: Re: [ovirt-devel] Gerrit parallel patch handling and CI (Or, why did 
> my code fail post-merge)
> 
> On 29 November 2016 at 19:34, Vojtech Szocs  wrote:
> >
> > Question: after the patch is submitted in Gerrit (it's fully acked
> > and maintainer hits the "Submit" button), does Gerrit allow us to
> > run CI (e.g. `check-merged` script) *before* doing the actual merge?
> >
> > [In other words, does Gerrit support gating merge based on CI script?]
> 
> No.
> See separate thread about merge-gateing:
> http://lists.ovirt.org/pipermail/devel/2016-November/014192.html

Thanks, I've missed that thread.

So before we adopt auto-submit-after-ci-pass (e.g. using Zuul, as Eyal
mentioned in that thread), we should be able to manually trigger heavy
CI (check-merged) job from Gerrit web interface, is that correct?

If so, it would be the patch owner's responsibility to submit (merge)
only after heavy CI (check-merged) pass?

As for Gerrit's "Submit" button hook, there's "pre-merge validation":

  
https://gerrit-review.googlesource.com/Documentation/config-validation.html#pre-merge-validation
  
https://github.com/gerrit-review/gerrit/blob/master/gerrit-server/src/main/java/com/google/gerrit/server/git/validators/MergeValidationListener.java

This validation API (MergeValidationListener) doesn't seem async as it
relies on exception (MergeValidationException) to block the operation.

So we could actually write Gerrit plugin using MergeValidationListener
that would operate in the following way:

1, on first "Submit" button click, tell Jenkins CI to run check-merged
   and block merge (e.g. providing reason like "wait till CI finishes")
2, Jenkins CI is expected to set some flag on patch once it finishes
3, on next "Submit" button click, block unless flag has "ok" value

> 
> > That said, +1 on "Fast Forward Only" submit type.
> 
> So far only VDSM stepped forward to try it out - and it proved to be
> too cumbersome for VDSM maintainers - so switched back to "Merge if
> Necessary".
> 
> --
> Barak Korren
> bkor...@redhat.com
> RHCE, RHCi, RHV-DevOps Team
> https://ifireball.wordpress.com/
> 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [JIRA] (OVIRT-416) [standard-ci] build-artifacts should reuse the artifacts built on check-merged if any

[Vojtech Szocs]

- Original Message -
> From: "Eyal Edri" 
> To: "Vojtech Szocs" 
> Cc: "Oved Ourfali" , "devel" 
> Sent: Sunday, November 27, 2016 11:28:08 AM
> Subject: Re: [JIRA] (OVIRT-416) [standard-ci] build-artifacts should reuse 
> the artifacts built on check-merged if any
> 
> Hi Vojtech,
> 
> I posted a patch [1] for this, so the change isn't merged yet.
> We thought of using the 'minimal' macro for it.
> 
> Can you send your suggestion to the patch?

Hi, sorry for late reply.

The patch looks good, my original idea was [all browsers x en_US],
but with "ovirt_build_minimal 1" it's actually [Firefox x en_US].

So +1 on that, but I see it's already merged =)

In automation/build-artifacts.sh, we can also remove the `BUILD_UT`
variable as it's not needed (taken care of by "ovirt_build_minimal").

> 
> 
> [1] https://gerrit.ovirt.org/#/c/67269/
> 
> On Fri, Nov 25, 2016 at 8:43 PM, Vojtech Szocs  wrote:
> 
> > Hi,
> >
> > > Any patches sent on this?
> >
> > I'd like to help.
> >
> > Looking at the recent Engine (master) build:
> >
> >   http://jenkins.ovirt.org/job/ovirt-engine_master_build-
> > artifacts-el7-x86_64/1691/
> >
> >   $ rpm -qlp ovirt-engine-webadmin-portal-4.1.0-0.0.master.
> > 20161125171318.gitae69c34.el7.centos.noarch.rpm
> >
> > it shows we still build all [browser x language] GWT permutations,
> > basically there are tons of .cache.js files in `webadmin.war`
> > directory (each one represents a single permutation).
> >
> > In automation/build-artifacts.sh, we could add some variable that
> > controls what kind of GWT build to do (e.g. GWT_BUILD_MODE):
> >
> > 1, snapshot GWT build: all supported browsers x en_US (only)
> >=> 3 x 1 = 3 GWT permutations
> >
> > 2, full GWT build: all supported browsers x all supported locales
> >=> 3 x 9 = 27 (!) GWT permutations
> >
> > With "snapshot GWT build", we should do:
> >
> >   rpmbuild \
> > .. existing stuff
> > -D "ovirt_build_locales 0" \
> > .. existing stuff
> >
> > GWT_BUILD_MODE can default to "full GWT build".
> >
> > But how do we override GWT_BUILD_MODE when doing non-release builds?
> >
> > Regards,
> > Vojtech
> >
> >
> > - Original Message -
> > > From: "eyal edri [Administrator] (oVirt JIRA)" <
> > j...@ovirt-jira.atlassian.net>
> > > To: in...@ovirt.org
> > > Sent: Sunday, November 6, 2016 4:29:02 PM
> > > Subject: [JIRA] (OVIRT-416) [standard-ci] build-artifacts should reuse
> > theartifacts built on check-merged if any
> > >
> > >
> > > [
> > > https://ovirt-jira.atlassian.net/browse/OVIRT-416?page=com.
> > atlassian.jira.plugin.system.issuetabpanels:comment-
> > tabpanel&focusedCommentId=22321#comment-22321
> > > ]
> > >
> > > eyal edri [Administrator] commented on OVIRT-416:
> > > -
> > >
> > > Any patches sent on this?
> > > Also, wanted to mention #OVIRT-751 is handling similar purpose with
> > enabling
> > > better maven caching, so it might suffice as a starting point in
> > optimizing
> > > ovirt-engine runtime for builds.
> > >
> > > > [standard-ci] build-artifacts should reuse the artifacts built on
> > > > check-merged if any
> > > > 
> > -
> > > >
> > > > Key: OVIRT-416
> > > > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-416
> > > > Project: oVirt - virtualization made easy
> > > >  Issue Type: Improvement
> > > >Reporter: David Caro Estevez
> > > >Assignee: infra
> > > >
> > > > Right now most projects just rebuild twice the artifacts, what for some
> > > > means a big waste of resources, if we could just reuse what was built
> > > > previously there would be no rebuilding.
> > > > Something to take into account is that the distributions that
> > check-merged
> > > > and build-artifacts run for might not match, so you can be running
> > > > check-merged only on fc23 but building artifacts for fc23, fc22 an el7
> > (as
> > > > an example), maybe we should not allow different distros on each
> > stage?|
> > >
> > >
> > >
> > > --
> > > This message was sent by Atlassian JIRA
> > > (v1000.499.4#100018)
> > > ___
> > > Infra mailing list
> > > in...@ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/infra
> > >
> >
> 
> 
> 
> --
> 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-integ)
> 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Gerrit parallel patch handling and CI (Or, why did my code fail post-merge)

[Vojtech Szocs]

- Original Message -
> From: "Barak Korren" 
> To: "devel" 
> Sent: Sunday, November 20, 2016 3:07:56 PM
> Subject: [ovirt-devel] Gerrit parallel patch handling and CI (Or, why did 
> my code fail post-merge)
> 
> Hi there,
> 
> I would like to address a concernt that had been raised to us by
> multiple developers, and reach an agreement on how (and if)  to remedy
> it.
> 
> Lets assume the following situation:
> We have a Git repo in Gerrit with top commit C0 in master.
> On time t0 developers Alice and Bob push patches P1 and P2 respectively
> to master so that we end up with the following situation in git:
> C0 <= P1 (this is Alice`s patch)
> C0 <= P2 (this is Bob`s patch)
> 
> On time t1 CI runs for both patches checking the code as it looks for
> each patch. Lets assume CI is successful for both.
> 
> On time t2 Alice submits her patch and Gerrit merges it, resulting in
> the following situation in master:
> C0 <= P1
> 
> On time t2 Bob submits his patch. Gerrit, seeing master has changed,
> re-bases the patch and merges it, the resulting situation (If the
> rebase is successful) is:
> C0 <= P1 <= P2
> 
> This means that the resulting code was never tested in CI. This, in
> turn, causes various failures to show up post-merge despite having
> pre-merge CI run successfully.
> 
> This situation is a result of the way our repos are currently
> configured. Most repos ATM are configured with the "Rebase If
> Necessary" submit type. This means that Gerrit tries to automatically
> rebase patches as mentioned in t2 above.
> 
> We could, instead, configure the repos to use the "Fast Forward Only"
> submit type. In that case, when Bob submits on t2, Gerrit refuses to
> merge and asks Bob to rebase (While offering a convenient button to do
> it). When he does, a new patch set gets pushed, and subsequently
> checked by CI.
> 
> I recommend we switch all projects to use the "Fast Forward Only" submit
> type.
> 
> Thoughts? Concerns?

Question: after the patch is submitted in Gerrit (it's fully acked
and maintainer hits the "Submit" button), does Gerrit allow us to
run CI (e.g. `check-merged` script) *before* doing the actual merge?

[In other words, does Gerrit support gating merge based on CI script?]

That said, +1 on "Fast Forward Only" submit type.

> 
> --
> Barak Korren
> bkor...@redhat.com
> RHEV-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] [JIRA] (OVIRT-416) [standard-ci] build-artifacts should reuse the artifacts built on check-merged if any

[Vojtech Szocs]

Hi,

> Any patches sent on this?

I'd like to help.

Looking at the recent Engine (master) build:

  
http://jenkins.ovirt.org/job/ovirt-engine_master_build-artifacts-el7-x86_64/1691/

  $ rpm -qlp 
ovirt-engine-webadmin-portal-4.1.0-0.0.master.20161125171318.gitae69c34.el7.centos.noarch.rpm

it shows we still build all [browser x language] GWT permutations,
basically there are tons of .cache.js files in `webadmin.war`
directory (each one represents a single permutation).

In automation/build-artifacts.sh, we could add some variable that
controls what kind of GWT build to do (e.g. GWT_BUILD_MODE):

1, snapshot GWT build: all supported browsers x en_US (only)
   => 3 x 1 = 3 GWT permutations

2, full GWT build: all supported browsers x all supported locales
   => 3 x 9 = 27 (!) GWT permutations

With "snapshot GWT build", we should do:

  rpmbuild \
.. existing stuff
-D "ovirt_build_locales 0" \
.. existing stuff

GWT_BUILD_MODE can default to "full GWT build".

But how do we override GWT_BUILD_MODE when doing non-release builds?

Regards,
Vojtech


- Original Message -
> From: "eyal edri [Administrator] (oVirt JIRA)" 
> To: in...@ovirt.org
> Sent: Sunday, November 6, 2016 4:29:02 PM
> Subject: [JIRA] (OVIRT-416) [standard-ci] build-artifacts should reuse the
> artifacts built on check-merged if any
> 
> 
> [
> 
> https://ovirt-jira.atlassian.net/browse/OVIRT-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22321#comment-22321
> ]
> 
> eyal edri [Administrator] commented on OVIRT-416:
> -
> 
> Any patches sent on this?
> Also, wanted to mention #OVIRT-751 is handling similar purpose with enabling
> better maven caching, so it might suffice as a starting point in optimizing
> ovirt-engine runtime for builds.
> 
> > [standard-ci] build-artifacts should reuse the artifacts built on
> > check-merged if any
> > -
> >
> > Key: OVIRT-416
> > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-416
> > Project: oVirt - virtualization made easy
> >  Issue Type: Improvement
> >Reporter: David Caro Estevez
> >Assignee: infra
> >
> > Right now most projects just rebuild twice the artifacts, what for some
> > means a big waste of resources, if we could just reuse what was built
> > previously there would be no rebuilding.
> > Something to take into account is that the distributions that check-merged
> > and build-artifacts run for might not match, so you can be running
> > check-merged only on fc23 but building artifacts for fc23, fc22 an el7 (as
> > an example), maybe we should not allow different distros on each stage?|
> 
> 
> 
> --
> This message was sent by Atlassian JIRA
> (v1000.499.4#100018)
> ___
> Infra mailing list
> in...@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
> 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [Call for Vote] moVirt as a Full oVirt Project

[Vojtech Szocs]

- Original Message -
> From: "Eyal Edri" 
> To: "Vojtech Szocs" 
> Cc: "Barak Korren" , "devel" , "board" 
> , "Michal Skrivanek"
> 
> Sent: Monday, November 21, 2016 7:23:44 PM
> Subject: Re: [ovirt-devel] [Call for Vote] moVirt as a Full oVirt Project
> 
> On Mon, Nov 21, 2016 at 8:17 PM, Vojtech Szocs  wrote:
> 
> >
> >
> > - Original Message -
> > > From: "Barak Korren" 
> > > To: "Brian Proffitt" 
> > > Cc: "Michal Skrivanek" , bo...@ovirt.org, "devel" <
> > devel@ovirt.org>
> > > Sent: Monday, November 21, 2016 7:01:08 PM
> > > Subject: Re: [ovirt-devel] [Call for Vote] moVirt as a Full oVirt Project
> > >
> > > -1
> > > Not because of anything with the project itself - I think it is
> > > genuinely awesome, but because I expect a project that emerges out of
> > > the incubation process to "look" like an oVirt project, by which I
> > > mean:
> > > 1. Have the code in the oVirt Gerrit
> > > 2. Have tests and builds running on oVirt's CI system.
> > > 3. Have artefacts served from oVirt's mirrors.
> > > 4. Have bugs tracked in oVirt's bugzilla.
> >
> > For 1 and 4, I feel that the benefit of allowing some projects to be hosted
> > on GitHub (attract & involve community through GitHub's public service)
> > does
> > out-weigh the rule of strict consistency (have everything in oVirt Gerrit).
> >
> >
> Any project in oVirt gerrit can be mirrored to GitHub, and most of them are
> ( see github.com/oVirt )
> 
> 
> > Although, not sure how hard would it be to modify oVirt CI system to allow
> > building GitHub hosted projects.
> >
> 
> We are supporting it, Lago is an example of such project.
> 
> 
> >
> > The guidelines should be clear about whether a project must be hosted via
> > oVirt Gerrit, whether it must have its bugs tracked via oVirt Bugzilla,
> > etc.
> >
> 
> I don't think its a must, but its highly recommended IMO, and will help the
> project grow.
> Imagine this scenario:
> 
> the project grows and uses its own CI/testing frameworks and reaches a
> point it wants to join the oVirt eco-system,
> At that point it will be much harder to integrate it if at all, assuming
> the tools he's been using were not aligned with
> the tooling other projects are using.
> 
> Also - in terms of release process, its will be very hard to include it in
> an official oVirt release if he wishes to do so,
> as all oVirt projects are built in the current infra and shipped as a
> single repository.

Eyal, I agree with your points.

I just wanted to point out the possibility of hosting project's
sources on GitHub (point 1 from Barak's list). And as you wrote,
Lago is a good example of such project.

Using standard oVirt CI infra & tools (points 2 & 3 from Barak's
list) should be mandatory for all oVirt projects, to keep things
manageable from build/release perspective. Full agreement here.

As for bug tracking (point 4 from Barak's list), I see Lago using
GitHub's issue tracking interface, so this should be OK too..

In general, I'd say that moVirt maintainers should clearly voice
their vision on converging (or not) towards points 1,2,3,4 that
Barak has mentioned in his email.

For me, having source code & issues on GitHub, but using standard
oVirt CI infra & tools, is still acceptable for an oVirt project,
but it's just my own opinion.

> 
> 
> >
> > >
> > > On 21 November 2016 at 19:07, Brian Proffitt 
> > wrote:
> > > > All:
> > > >
> > > > The moVirt Project was initially accepted as an oVirt incubator
> > project in
> > > > February 2015. It has been a successful subproject for quite some time
> > and
> > > > it is well due for being accepted as a full oVirt project. I believe
> > it is
> > > > appropriate to post a Call for Vote on the Devel and Board lists.
> > > >
> > > > http://www.ovirt.org/develop/projects/project-movirt/
> > > >
> > > > A “healthy” project, as determined by the oVirt Board, can be found at
> > > > http://www.ovirt.org/develop/projects/adding-a-new-project/
> > > >
> > > > Voting will be open until 1200 UTC Nov. 30, 2016. A net total of +7
> > votes
> > > > should be received to formalize this project as an full oVirt project.
> > > >

Re: [ovirt-devel] [Call for Vote] moVirt as a Full oVirt Project

[Vojtech Szocs]

- Original Message -
> From: "Barak Korren" 
> To: "Brian Proffitt" 
> Cc: "Michal Skrivanek" , bo...@ovirt.org, "devel" 
> 
> Sent: Monday, November 21, 2016 7:01:08 PM
> Subject: Re: [ovirt-devel] [Call for Vote] moVirt as a Full oVirt Project
> 
> -1
> Not because of anything with the project itself - I think it is
> genuinely awesome, but because I expect a project that emerges out of
> the incubation process to "look" like an oVirt project, by which I
> mean:
> 1. Have the code in the oVirt Gerrit
> 2. Have tests and builds running on oVirt's CI system.
> 3. Have artefacts served from oVirt's mirrors.
> 4. Have bugs tracked in oVirt's bugzilla.

For 1 and 4, I feel that the benefit of allowing some projects to be hosted
on GitHub (attract & involve community through GitHub's public service) does
out-weigh the rule of strict consistency (have everything in oVirt Gerrit).

Although, not sure how hard would it be to modify oVirt CI system to allow
building GitHub hosted projects.

The guidelines should be clear about whether a project must be hosted via
oVirt Gerrit, whether it must have its bugs tracked via oVirt Bugzilla, etc.

> 
> On 21 November 2016 at 19:07, Brian Proffitt  wrote:
> > All:
> >
> > The moVirt Project was initially accepted as an oVirt incubator project in
> > February 2015. It has been a successful subproject for quite some time and
> > it is well due for being accepted as a full oVirt project. I believe it is
> > appropriate to post a Call for Vote on the Devel and Board lists.
> >
> > http://www.ovirt.org/develop/projects/project-movirt/
> >
> > A “healthy” project, as determined by the oVirt Board, can be found at
> > http://www.ovirt.org/develop/projects/adding-a-new-project/
> >
> > Voting will be open until 1200 UTC Nov. 30, 2016. A net total of +7 votes
> > should be received to formalize this project as an full oVirt project.
> > Please use the following vote process:
> >
> > +1
> > Yes, agree, or the action should be performed. On some issues, this vote
> > must only be given after the voter has tested the action on their own
> > system(s).
> >
> > ±0
> > Abstain, no opinion, or I am happy to let the other group members decide
> > this issue. An abstention may have detrimental affects if too many people
> > abstain.
> >
> > -1
> > No, I veto this action. All vetos must include an explanation of why the
> > veto is appropriate. A veto with no explanation is void.
> >
> > Thank you!
> >
> > Brian Proffitt
> > Principal Community Analyst
> > Open Source and Standards
> > @TheTechScribe
> > 574.383.9BKP
> >
> > ___
> > Devel mailing list
> > Devel@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
> 
> 
> 
> --
> Barak Korren
> bkor...@redhat.com
> RHEV-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] [Call for Vote] Proposal for new Incubator Project

[Vojtech Szocs]

+1

I agree with Barak's point. Plus it would make people (who use Vagrant) aware 
of oVirt.

Vojtech


- Original Message -
> From: "Barak Korren" 
> To: "Sandro Bonazzola" 
> Cc: bo...@ovirt.org, "devel" 
> Sent: Monday, November 21, 2016 6:12:45 PM
> Subject: Re: [ovirt-devel] [Call for Vote] Proposal for new Incubator Project
> 
> +1
> I think oVirt had been missing from the list of Vagrant providers for too
> long.
> 
> On 21 November 2016 at 19:09, Sandro Bonazzola < sbona...@redhat.com > wrote:
> 
> 
> 
> 
> 
> 
> Il 21/Nov/2016 17:55, "Brian Proffitt" < bprof...@redhat.com > ha scritto:
> > 
> > All:
> > 
> > This project was initially proposed for review on Oct. 9. It has been
> > reviewed for major issues and having heard no objections, it's now time to
> > formally vote on accepting this as an official oVirt incubator subproject.
> > 
> > The last time we voted on one of these was during an IRC weekly meeting, so
> > I believe it is appropriate to post a Call for Vote on the Devel and Board
> > lists.
> > 
> > Voting will be open until 1200 UTC Nov. 28, 2016. A net total of +5 votes
> > should be received to formalize this project as an incubator subproject.
> > Please use the following vote process:
> > 
> > +1
> > Yes, agree, or the action should be performed. On some issues, this vote
> > must only be given after the voter has tested the action on their own
> > system(s).
> > 
> > ±0
> > Abstain, no opinion, or I am happy to let the other group members decide
> > this issue. An abstention may have detrimental affects if too many people
> > abstain.
> > 
> > -1
> > No, I veto this action. All vetos must include an explanation of why the
> > veto is appropriate. A veto with no explanation is void.
> > 
> > Thank you!
> > Brian Proffitt
> > 
> > 
> > ---
> > 
> > Project Proposal - Vagrant Provider
> > 
> > A vagrant provider for oVirt v4
> > 
> 
> 
> My vote is +0. I have no strong opinion on this and I'm not using vagrant so
> I would be happy to leave other to decide.
> Using the + because I am happy to see the contribution ☺
> 
> 
> 
> 
> 
> > Abstract
> > 
> > This will be a provider plugin for the Vagrant suite that allows
> > command-line ease of virtual machine provisioning and lifecycle
> > management.
> > 
> > Proposal
> > 
> > This Vagrant provider plugin will interface with the oVirt REST API
> > (version 4 and higher) using the oVirt provided ruby SDK
> > 'ovirt-engine-sdk-ruby'. This allows users to abstract the user
> > interface and experience into a set of command line abilities to
> > create, provision, destroy and manage the complete lifecycle of
> > virtual machines. It also allows the use of external configuration
> > management and configuration files themselves to be committed into
> > code.
> > 
> > Background
> > 
> > I have previously forked and maintained the 'vagrant-ovirt' gem as
> > 'vagrant-ovirt3' due to Gems requiring unique names. The original
> > author has officially abandoned the project. For the last few years
> > all code to maintain this project has been maintained by myself and a
> > few ad-hoc github contributors. This provider interfaced directly with
> > oVirt v3 using fog and rbovirt. The new project would be a fresh start
> > using the oVirt provided ruby SDK to work directly with version 4.
> > 
> > Rationale
> > 
> > The trend in configuration management, operations, and devops has been
> > to maintain as much of the development process as possible in terms of
> > the virtual machines and hosts that they run on. With software like
> > Terraform the tasks of creating the underlying infrastructure such as
> > network rules, etc have had great success moving into 'Infrastructure
> > as code'. The same company behind Terraform got their reputation from
> > Vagrant which aims to utilize the same process for virtual machines
> > themselves. The core software allows for standard commands such as
> > 'up', 'provision', 'destroy' to be used across a provider framework. A
> > provider for oVirt makes the process for managing VMs easier and able
> > to be controlled through code and source control.
> > 
> > Initial Goals
> > 
> > The initial goal is to get the base steps of 'up', 'down' (halt), and
> > 'destroy' to succeed using the oVirt provided ruby SDK for v4.
> > Stretch/followup goals would be to ensure testability and alternate
> > commands such as 'provision' and allow configuration management suites
> > like puppet to work via 'userdata' (cloud-init).
> > 
> > Current Status
> > 
> > The version 3 of this software has been heavily utilized. The original
> > fork known as 'vagrant-ovirt' has been abandoned with no plans to
> > communicate or move forward. My upstream fork has had great success
> > with nearly 4x the downloads from rubygems.org . Until my github fork
> > has more 'stars' I cannot take over it completely so the gem was
> > renamed 'vagrant-ovirt3'. This is also true for rubygems.org since
> > gems are not namespaced, therefore c

Re: [ovirt-devel] Moving oVirt JavaScript application stack forward (short and long term)

[Vojtech Szocs]

- Original Message -
> From: "Vojtech Szocs" 
> To: "devel" 
> Sent: Wednesday, November 9, 2016 8:49:39 PM
> Subject: [ovirt-devel] Moving oVirt JavaScript application stack forward 
> (short and long term)
> 
> Hello,
> 
> regarding oVirt JavaScript applications (like Dashboard), we'd like
> to reach a point where we'll be using latest Node.js LTS runtime and
> lock down all dependency versions, resulting in reproducible builds.
> 
> Please note that both Node.js and all JS dependencies are needed only
> when building oVirt JavaScript applications & corresponding packages.
> 
> The near future items are following:
> 
> 1, patch ovirt-engine-{nodejs,nodejs-modules} to use Node.js v6 (LTS),
>refer to https://github.com/nodejs/LTS for more details

Posted patch https://gerrit.ovirt.org/#/c/66471/

> 
> 2, patch ovirt-engine-nodejs-modules to use Node.js runtime provided
>by ovirt-engine-nodejs - revive https://gerrit.ovirt.org/#/c/59898/
> 
> 3, lock down dependency versions in ovirt-engine-nodejs-modules
>via npm-shrinkwrap - finalize https://gerrit.ovirt.org/#/c/61957/
> 
> From this point, we can proceed with long term items:
> 
> 4, consolidate dependencies across projects:
> 
>4a, update react-patternfly:
>- https://github.com/jtomasek/react-patternfly/
>- add common PatternFly components (e.g. out of Dashboard)
> 
>4b, update ovirt-ui-components:
>- https://github.com/matobet/ovirt-ui-components/
>- depend on react-patternfly
>- add oVirt specific components (e.g. out of Dashboard)
> 
>4c, update ovirt-engine-nodejs-modules:
>- depend on ovirt-ui-components
> 
>4d, update all oVirt JS projects, like Dashboard
>- depend on ovirt-ui-components
> 
>*all* oVirt JS projects should depend on ovirt-ui-components.
> 
>react-patternfly exists separately to support non-oVirt cases.
> 
> 5, develop "showcase" webapp as part of react-patternfly repo to
>ensure it's well-aligned with PatternFly look'n'feel
> 
>- it would be nice to host the "showcase" webapp somewhere
> 
> 6, address common problems that arise from using npm-shrinkwrap
> 
>- deterministic (predictable) dependency resolution
>- checksum verification to ensure integrity of dependencies
>- dependency de-duplication (avoid multiple versions)
> 
>Yarn [1][2] addresses all problems mentioned above. It's still
>in early development, so I'd wait a bit and see how it matures.
> 
>Note: ManageIQ UI is already using Yarn [3].
> 
>[1] https://code.facebook.com/posts/1840075619545360
>[2] https://github.com/yarnpkg/yarn
>[3] https://github.com/ManageIQ/manageiq-ui-service/pull/296/files
> 
> Feel free to share your thoughts or concerns.
> 
> Regards,
> Vojtech
> ___
> 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] Moving oVirt JavaScript application stack forward (short and long term)

[Vojtech Szocs]

Hello,

regarding oVirt JavaScript applications (like Dashboard), we'd like
to reach a point where we'll be using latest Node.js LTS runtime and
lock down all dependency versions, resulting in reproducible builds.

Please note that both Node.js and all JS dependencies are needed only
when building oVirt JavaScript applications & corresponding packages.

The near future items are following:

1, patch ovirt-engine-{nodejs,nodejs-modules} to use Node.js v6 (LTS),
   refer to https://github.com/nodejs/LTS for more details

2, patch ovirt-engine-nodejs-modules to use Node.js runtime provided
   by ovirt-engine-nodejs - revive https://gerrit.ovirt.org/#/c/59898/

3, lock down dependency versions in ovirt-engine-nodejs-modules
   via npm-shrinkwrap - finalize https://gerrit.ovirt.org/#/c/61957/

>From this point, we can proceed with long term items:

4, consolidate dependencies across projects:

   4a, update react-patternfly:
   - https://github.com/jtomasek/react-patternfly/
   - add common PatternFly components (e.g. out of Dashboard)

   4b, update ovirt-ui-components:
   - https://github.com/matobet/ovirt-ui-components/
   - depend on react-patternfly
   - add oVirt specific components (e.g. out of Dashboard)

   4c, update ovirt-engine-nodejs-modules:
   - depend on ovirt-ui-components

   4d, update all oVirt JS projects, like Dashboard
   - depend on ovirt-ui-components

   *all* oVirt JS projects should depend on ovirt-ui-components.

   react-patternfly exists separately to support non-oVirt cases.

5, develop "showcase" webapp as part of react-patternfly repo to
   ensure it's well-aligned with PatternFly look'n'feel

   - it would be nice to host the "showcase" webapp somewhere

6, address common problems that arise from using npm-shrinkwrap

   - deterministic (predictable) dependency resolution
   - checksum verification to ensure integrity of dependencies
   - dependency de-duplication (avoid multiple versions)

   Yarn [1][2] addresses all problems mentioned above. It's still
   in early development, so I'd wait a bit and see how it matures.

   Note: ManageIQ UI is already using Yarn [3].

   [1] https://code.facebook.com/posts/1840075619545360
   [2] https://github.com/yarnpkg/yarn
   [3] https://github.com/ManageIQ/manageiq-ui-service/pull/296/files

Feel free to share your thoughts or concerns.

Regards,
Vojtech
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Missing 11-setup-sso.conf after Engine build

[Vojtech Szocs]

- Original Message -
> From: "Martin Perina" 
> To: "Sandro Bonazzola" 
> Cc: "Vojtech Szocs" , "devel" 
> Sent: Tuesday, October 18, 2016 9:12:02 AM
> Subject: Re: [ovirt-devel] Missing 11-setup-sso.conf after Engine build
> 
> On Tue, Oct 18, 2016 at 8:52 AM, Sandro Bonazzola 
> wrote:
> 
> >
> >
> > On Mon, Oct 17, 2016 at 5:16 PM, Vojtech Szocs  wrote:
> >
> >> Hello,
> >>
> >> I'm using latest master with some UI patches on top of it.
> >>
> >> Engine builds OK, however engine-setup does not ask for admin@internal
> >> password.
> >>
> >
> > Please note that engine-setup is not asking questions you already answered
> > in a previous run (answers stored in the post install file).
> > Looks like you've been able to set password to None:
> > 2016-10-17 17:02:26 DEBUG otopi.context context.dumpEnvironment:770 ENV
> > OVESETUP_CONFIG/adminPassword=NoneType:'None'
> >
> >
> >
> >
> >
> >> In $PREFIX/etc/ovirt-engine/engine.conf.d, there is no 11-setup-sso.conf
> >> file.
> >>
> >
> ​11-setup-sso.conf file is created only during installation (first
> execution of engine-setup with empty db). If it was not created, it means
> that you cleared your prefix (by removing existing configuration files),
> but you db is not empty and contains old data. Be aware that configuration
> files in your prefix and bound to db content, if you clear config files,
> you should also clear db content, easiest was is to execute engine-cleanup.

Thank you Sandro & Martin for your responses!

Martin was right, I've cleared my $PREFIX, then rebuilt Engine
and executed engine-setup, but DB wasn't empty. My bad, sorry.

> 
> ​
> 
> 
> >
> >> AFAIK, this should be done by aaa-jdbc extension, is that correct?
> >>
> >
> ​No, 11-setup-sso.conf is part of new SSO feature of 4.0, it's not related
> to aaa-jdbc.
> ​
> 
> 
> >
> >> (Am I missing something?)
> >>
> >> Here is how I build Engine:
> >>
> >>   engine_userAgent='gecko1_8,safari'
> >>   engine_draftCompile=1
> >>   engine_buildUserPortal=0
> >>   engine_buildWebAdmin=1
> >>   engine_runTests=1
> >>   engine_gwtLogLevel='INFO'
> >>   engine_gwtLocale='en_US'
> >>   engine_gwtSuperDev=0
> >>   engine_jbossHome=/usr/share/ovirt-engine-wildfly
> >>
> >>   make clean install-dev PREFIX="$PREFIX" \
> >> JBOSS_HOME="$engine_jbossHome" \
> >> DEV_EXTRA_BUILD_FLAGS_GWT_DEFAULTS="-Dgwt.userAgent=$engine_userAgent"
> >> \
> >> DEV_EXTRA_BUILD_FLAGS="-Dgwt.logLevel=$engine_gwtLogLevel
> >> -Dgwt.locale=$engine_gwtLocale -Dgwt.compiler.localWorkers=1" \
> >> DEV_BUILD_GWT_DRAFT=$engine_draftCompile \
> >> DEV_BUILD_GWT_SUPER_DEV_MODE=$engine_gwtSuperDev \
> >> BUILD_GWT_USERPORTAL=$engine_buildUserPortal \
> >> BUILD_GWT_WEBADMIN=$engine_buildWebAdmin \
> >> BUILD_UT=$engine_runTests
> >>
> >> Attaching engine-setup log file.
> >>
> >> Thanks,
> >> Vojtech
> >>
> >> ___
> >> Devel mailing list
> >> Devel@ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/devel
> >>
> >
> >
> >
> > --
> > Sandro Bonazzola
> > Better technology. Faster innovation. Powered by community collaboration.
> > See how it works at redhat.com
> > <https://www.redhat.com/it/about/events/red-hat-open-source-day-2016>
> >
> > ___
> > 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] engine-setup: ***L:ERROR Internal error: No module named dwh

[Vojtech Szocs]

Hi, thanks for fixing this.

(Should we really add DWH as requirement for dev-env? Shouldn't it be opt-in 
instead?)

Thanks,
Vojtech


- Original Message -
> From: "Simone Tiraboschi" 
> To: "Vojtech Szocs" 
> Cc: "devel" 
> Sent: Thursday, October 13, 2016 12:23:39 AM
> Subject: Re: [ovirt-devel] engine-setup: ***L:ERROR Internal error: No module 
> named dwh
> 
> Hi,
> Jakub was right: the issue has been introduced with commit 221c7ed.
> 
> It affects just the dev env since there we are currently not installing (we
> need to dig this!) DWH which instead is a dependency on the packaged builds
> since 4.0.
> 
> Patch https://gerrit.ovirt.org/#/c/65409/ fixes it.
> 
> ciao
> 
> On Wed, Oct 12, 2016 at 6:08 PM, Vojtech Szocs  wrote:
> 
> > Same problem here.
> >
> > Vojtech
> >
> >
> > - Original Message -
> > > From: "Dominik Holler" 
> > > To: devel@ovirt.org
> > > Sent: Wednesday, October 12, 2016 2:39:27 PM
> > > Subject: Re: [ovirt-devel] engine-setup: ***L:ERROR Internal error: No
> > module named dwh
> > >
> > > Hi,
> > > I got the same error. Is there any experience about this, by now?
> > > Dominik
> > >
> > > On Mon, 10 Oct 2016 15:48:08 -0400 (EDT)
> > > Jakub Niedermertl  wrote:
> > >
> > > > Hi all,
> > > >
> > > > does anyone else experience following error of `engine-setup`?
> > > >
> > > > $ ~/target/bin/engine-setup
> > > > ***L:ERROR Internal error: No module named dwh
> > > >
> > > > I have a suspicion it might be related to commit '221c7ed packaging:
> > > > setup: Remove constants duplication'.
> > > >
> > > > Jakub
> > > > ___
> > > > 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] engine-setup: ***L:ERROR Internal error: No module named dwh

[Vojtech Szocs]

Same problem here.

Vojtech


- Original Message -
> From: "Dominik Holler" 
> To: devel@ovirt.org
> Sent: Wednesday, October 12, 2016 2:39:27 PM
> Subject: Re: [ovirt-devel] engine-setup: ***L:ERROR Internal error: No module 
> named dwh
> 
> Hi,
> I got the same error. Is there any experience about this, by now?
> Dominik
> 
> On Mon, 10 Oct 2016 15:48:08 -0400 (EDT)
> Jakub Niedermertl  wrote:
> 
> > Hi all,
> > 
> > does anyone else experience following error of `engine-setup`?
> > 
> > $ ~/target/bin/engine-setup
> > ***L:ERROR Internal error: No module named dwh
> > 
> > I have a suspicion it might be related to commit '221c7ed packaging:
> > setup: Remove constants duplication'.
> > 
> > Jakub
> > ___
> > 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] Dropping rpm build from ovirt-engine check-merged.sh

[Vojtech Szocs]

Hi,

to me, it seems that with current CI flow, we can do following:

- in build-artifacts.sh, build UI for English (only) & all supported
  browsers (IE10+, Firefox, Chrome), by using `ovirt_build_locales 0`
  as the default fallback

  Note: this will cut down the # of permutations from 3x9 to just 3
  (currently we have 3 supported browser types, 9 supported locales).

- ensure that release builds still target all supported UI locales,
  by using `ovirt_build_locales 1` (override the default fallback)

- it would be nice if the Jenkins job for build-artifacts.sh would
  set some `RELEASE=1` flag (or similar) when doing a release build
  (is this possible with current standard CI?)

Eyal/others, does above make sense?

Also, as Nir mentioned, if `ovirt-engine` repo was configured with
Submit Type == Fast Forward Only, we could drop RPM / GWT build in
check-merged.sh (which was Eyal's original suggestion).

Regards,
Vojtech


- Original Message -
> From: "Nir Soffer" 
> To: "Eyal Edri" 
> Cc: "Juan Hernandez" , "devel" , 
> "Martin Perina" , "Tal
> Nisan" , "infra" 
> Sent: Tuesday, September 20, 2016 5:38:08 PM
> Subject: Re: Dropping rpm build from ovirt-engine check-merged.sh
> 
> On Tue, Sep 20, 2016 at 11:27 AM, Eyal Edri < ee...@redhat.com > wrote:
> 
> 
> 
> 
> 
> On Tue, Sep 20, 2016 at 9:34 AM, Sandro Bonazzola < sbona...@redhat.com >
> wrote:
> 
> 
> 
> 
> 
> On Mon, Sep 19, 2016 at 7:56 PM, Eyal Edri < ee...@redhat.com > wrote:
> 
> 
> 
> 
> 
> On Mon, Sep 19, 2016 at 9:41 AM, Sandro Bonazzola < sbona...@redhat.com >
> wrote:
> 
> 
> 
> 
> 
> On Sun, Sep 18, 2016 at 4:18 PM, Eyal Edri < ee...@redhat.com > wrote:
> 
> 
> 
> Hi,
> 
> Following [1] I'd like to propose to remove rpm building from the
> 'check-merged.sh' script from ovirt-engine (master for now).
> 
> The job [2] takes on avg 15 min while actually the rpms are built already in
> check-patch
> (with gwt draft mode if needed) and runs exactly the same build rpm command
> as check-patch [3].
> 
> So there isn't real value in running exactly the same rpm build post merge,
> and we already build full permutation mode in 'build-artifacts.sh'.
> 
> Any reason to keep it?
> We can cut down valuable time in CI if we drop it and vacant more time for
> more meaningful tests.
> 
> 
> This depends on the flow: if we make check_merge gating to the merge and to
> the build we should keep the rpm build becuase at merge a rebase is done
> automatically.
> 
> What do you mean by 'gating to the merge'? I'm not sure I understand what it
> means.
> Isn't check-patch.sh does the gating? check-merge runs post merge so its
> already too late to gate the code ...
> And I think check-merge and check-patch currently runs the same rpmbuild
> command, so I don't see how check-merged has any value over check-patch.
> 
> when merge command is issued a rebase is done as well. We still need a
> check-merged job because the code checked by check-patch is not the same
> anymore when check-merged runs.
> 
> OK, now I understand, so indeed check-merge can potentially run on different
> code than check-patch and possibly fail due to it.
> 
> If we require only fast-forward merges, there is no way to merge patch
> before a rebase. Once you rebase a patch, check-patch runs...
> 
> So check-merge may be unneeded in this case.
> 
> 
> 
> 
> 
> 
> In original desing of stdci, check-merged was supposed to become a gating
> test for build-artifacts.
> 
> We have it in our backlog, i.e installing Zuul and adding gating for the
> check-merged jobs, its mostly relevant for system jobs, but we can defiently
> do it first for simple 'check-merged.sh' jobs
> as part of standard CI.
> 
> Opened a ticket for it [1]
> 
> [1] https://ovirt-jira.atlassian.net/browse/OVIRT-734
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> If there's not gating process performed by check-merge then I agree in
> dropping rpm build.
> 
> 
> 
> 
> 
> 
> [1] https://ovirt-jira.atlassian.net/browse/OVIRT-416
> [2]
> http://jenkins.ovirt.org/job/ovirt-engine_master_check-merged-el7-x86_64/buildTimeTrend
> [3]
> rpmbuild \
> -D "_rpmdir $PWD/output" \
> -D "_topmdir $PWD/rpmbuild" \
> -D "release_suffix ${SUFFIX}" \
> -D "ovirt_build_ut $BUILD_UT" \
> -D "ovirt_build_extra_flags $EXTRA_BUILD_FLAGS" \
> -D "ovirt_build_draft 1" \
> --rebuild output/*.src.rpm
> 
> 
> --
> 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-integ)
> 
> 
> 
> --
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com
> 
> 
> 
> 
> --
> 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-integ)
> 
> 
> 
> --
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com
> 
> 
> 
> 
> --
> Eyal Edri
> 

Re: [ovirt-devel] Dropping rpm build from ovirt-engine check-merged.sh

[Vojtech Szocs]

- Original Message -
> From: "Sandro Bonazzola" 
> To: "Eyal Edri" 
> Cc: "Juan Hernandez" , "infra" , 
> "devel" 
> Sent: Monday, September 19, 2016 8:41:12 AM
> Subject: Re: [ovirt-devel] Dropping rpm build from ovirt-engine   
> check-merged.sh
> 
> 
> 
> On Sun, Sep 18, 2016 at 4:18 PM, Eyal Edri < ee...@redhat.com > wrote:
> 
> 
> 
> Hi,
> 
> Following [1] I'd like to propose to remove rpm building from the
> 'check-merged.sh' script from ovirt-engine (master for now).
> 
> The job [2] takes on avg 15 min while actually the rpms are built already in
> check-patch
> (with gwt draft mode if needed) and runs exactly the same build rpm command
> as check-patch [3].
> 
> So there isn't real value in running exactly the same rpm build post merge,
> and we already build full permutation mode in 'build-artifacts.sh'.
> 
> Any reason to keep it?
> We can cut down valuable time in CI if we drop it and vacant more time for
> more meaningful tests.
> 
> 
> This depends on the flow: if we make check_merge gating to the merge and to
> the build we should keep the rpm build becuase at merge a rebase is done
> automatically.
> If there's not gating process performed by check-merge then I agree in
> dropping rpm build.

First of all, for oVirt Engine snapshot (non-release) builds, we should
avoid doing a full GWT compilation [all browsers x all locales]. That's
simply because the full GWT compilation is too costly for CI to run on
a regular basis.

Doing [Firefox + Chrome x English = 2 permutations] && [draft GWT build
option enabled] for snapshot builds should be enough.

The *only* downside of not doing a full GWT build is that problems with
localization resources [e.g. non-English .properties files] will not be
reported by the GWT compiler. But we have Java unit tests to cover this,
so it should be OK. (And if not, we must improve those tests.)

In general, we should do a full GWT compilation only for release builds.
Eyal mentioned at [1] that his team is working on

  'build official manual' option to standard CI

so that would be a great place to document & perform the full GWT build.

As for build jobs: if `check-merged` is indeed acting as gate for merge
[fail of `check-merged` => patch not merged, `build-artifacts` does not
execute], then it actually makes sense to:

- keep `check-merged` doing a (draft) GWT build + Engine RPM build
- maybe skip GWT build in `check-patch` [right now, there's detection
  logic => if frontend files were changed, do GWT build]

Otherwise, if `check-merged` doesn't act as gate for merge, we can just
skip GWT build / Engine RPM build for that script.

> 
> 
> 
> 
> 
> 
> [1] https://ovirt-jira.atlassian.net/browse/OVIRT-416
> [2]
> http://jenkins.ovirt.org/job/ovirt-engine_master_check-merged-el7-x86_64/buildTimeTrend
> [3]
> rpmbuild \
> -D "_rpmdir $PWD/output" \
> -D "_topmdir $PWD/rpmbuild" \
> -D "release_suffix ${SUFFIX}" \
> -D "ovirt_build_ut $BUILD_UT" \
> -D "ovirt_build_extra_flags $EXTRA_BUILD_FLAGS" \
> -D "ovirt_build_draft 1" \
> --rebuild output/*.src.rpm
> 
> 
> --
> 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-integ)
> 
> 
> 
> --
> 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
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [RFE] Add ovirt-engine-filesystem sub-package

[Vojtech Szocs]

Hi,

for now, ovirt-engine-dashboard spec file [1] contains

  Requires: ovirt-engine-webadmin-portal >= 4.0.2

[1] 
https://gerrit.ovirt.org/gitweb?p=ovirt-engine-dashboard.git;a=blob;f=packaging/spec.in;hb=HEAD

Dashboard RPM needs to create files (symlinks) in

  /usr/share/ovirt-engine/ui-plugins

directory, which is owned by `backend` sub-pkg, however
the Requires declaration is for `webadmin-portal` sub-pkg
to indicate relationship with WebAdmin UI (since Dashboard
is technically a UI plugin).

The downside of current approach is having dependency on
specific sub-pkg just for the sake of putting some files
into above directory within Dashboard's %install section.

But I'm not an expert on RPM packaging / guidelines etc.
so I just wanted to clarify the motivation behind this.

Vojtech


- Original Message -
> From: "Sandro Bonazzola" 
> To: "devel" 
> Sent: Thursday, August 4, 2016 4:58:18 PM
> Subject: [ovirt-devel] [RFE] Add ovirt-engine-filesystem sub-package
> 
> Hi,
> while developing ovirt-engine-dashboard it has been raised the issue that
> just for having ovirt-engine directories in place on the filesystem, the
> whole engine has to be required.
> 
> Some of the directories currently owned by ovirt-engine package and its
> subpackages are used also by other projects. In order to provide them
> whitout installing the whole engine a new sub package is needed, let's call
> it ovirt-engine-filesystem.
> 
> There are several example of this approach in Fedora, to see them:
> $ dnf list "*filesystem*"
> 
> A bug has been opened to track this RFE[1] and a patch has been submitted
> some time ago[2]
> 
> We didn't reach an agreement on creating the sub package or not, major
> objection was:
> " is ok for the whole distribution but for us this is an overkill"
> 
> Following Open Decision Framework, I'd like to get some more feedback from
> others since generally seems to be a good idea but I'd like to understand if
> this may cause issues to other developers / projects and why it's considered
> an overkill.
> 
> In Fedora packaging guidelines[3], the topic is covered by "File and
> Directory Ownership" section.
> 
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1333880
> [2] https://gerrit.ovirt.org/57271
> [3]
> https://fedoraproject.org/wiki/Packaging:Guidelines#File_and_Directory_Ownership
> 
> --
> 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
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] 4.1.0-0.0.master.20160802181918.gitd8decfe Uncaught exception occurred

[Vojtech Szocs]

Hi,

Caused by: com.google.gwt.core.client.JavaScriptException: (TypeError) 
 __gwt$exception: : Cannot read property 'k' of null
at 
org.ovirt.engine.ui.uicommonweb.models.vms.InstanceImageLineModel.$attachDisk(InstanceImageLineModel.java:169)

looks like NPE in InstanceImageLineModel#attachDisk method, the '$' in 
'$attachDisk'
might indicate that NPE occurs within `new InstanceImagesAttachDiskModel() { .. 
}`
declaration.

Can you please open BZ with steps on how to reproduce?

Vojtech


- Original Message -
> From: "Sandro Bonazzola" 
> To: "devel" , "Vojtech Szocs" , 
> "Alexander Wels" 
> Sent: Thursday, August 4, 2016 1:22:33 PM
> Subject: 4.1.0-0.0.master.20160802181918.gitd8decfe Uncaught exception 
> occurred
> 
> # rpm -qa |grep userportal
> ovirt-engine-userportal-debuginfo-4.1.0-0.0.master.20160802181918.gitd8decfe.fc24.noarch
> ovirt-engine-userportal-4.1.0-0.0.master.20160802181918.gitd8decfe.fc24.noarch
> 
> client side:
> 
> Thu Aug 04 13:18:47 GMT+200 2016 org.ovirt.engine.ui.frontend.Frontend
> WARNING: Failure while invoking runQuery [Query execution failed due to
> insufficient permissions., Query execution failed due to insufficient
> permissions_]
> userportal-0.js:5832 Thu Aug 04 13:18:52 GMT+200 2016
> SEVERE: Uncaught exceptioncom.google.gwt.event.shared.UmbrellaException:
> Exception caught: (TypeError)
>  __gwt$exception: : Cannot read property 'k' of null
> at Unknown.Ur(userportal-0.js@17729)
> at Unknown.as(userportal-0.js@41)
> at Unknown.wX(userportal-0.js@19)
> at Unknown.zX(userportal-0.js@19)
> at Unknown.KW(userportal-0.js@116)
> at Unknown.Q$c(userportal-0.js@27)
> at Unknown.$$c(userportal-0.js@13141)
> at Unknown._S(userportal-0.js@147)
> at Unknown.S$c(userportal-0.js@113)
> at Unknown.Yhd(userportal-0.js@21707)
> at Unknown.G6c(userportal-0.js@85)
> at Unknown.D8c(userportal-0.js@46)
> at Unknown._t(userportal-0.js@29)
> at Unknown.du(userportal-0.js@57)
> at Unknown.eval(userportal-0.js@54)
> at Unknown.Sy(userportal-0.js@20)
> at Unknown.Chd(userportal-0.js@98)
> at Unknown.dMi(userportal-28.js@147517)
> at Unknown.Yhd(userportal-0.js@21325)
> at Unknown.G6c(userportal-0.js@85)
> at Unknown.F6c(userportal-0.js@60)
> at Unknown.B8c(userportal-0.js@52)
> at Unknown._t(userportal-0.js@29)
> at Unknown.du(userportal-0.js@57)
> at Unknown.eval(userportal-0.js@54)
> Caused by: com.google.gwt.core.client.JavaScriptException: (TypeError)
>  __gwt$exception: : Cannot read property 'k' of null
> at Unknown.BSm(userportal-28.js@58)
> at Unknown.PSm(userportal-28.js@506365)
> at Unknown.GLi(userportal-0.js@101)
> at Unknown.Cyj(userportal-28.js@218011)
> at Unknown.uT(userportal-0.js@27451)
> at Unknown.UW(userportal-0.js@209)
> at Unknown.KW(userportal-0.js@59)
> at Unknown.Q$c(userportal-0.js@27)
> at Unknown.$$c(userportal-0.js@13141)
> at Unknown._S(userportal-0.js@147)
> at Unknown.S$c(userportal-0.js@113)
> at Unknown.Yhd(userportal-0.js@21707)
> at Unknown.G6c(userportal-0.js@85)
> at Unknown.D8c(userportal-0.js@46)
> at Unknown._t(userportal-0.js@29)
> at Unknown.du(userportal-0.js@57)
> at Unknown.eval(userportal-0.js@54)
> at Unknown.Sy(userportal-0.js@20)
> at Unknown.Chd(userportal-0.js@98)
> at Unknown.dMi(userportal-28.js@147517)
> at Unknown.Yhd(userportal-0.js@21325)
> at Unknown.G6c(userportal-0.js@85)
> at Unknown.F6c(userportal-0.js@60)
> at Unknown.B8c(userportal-0.js@52)
> at Unknown._t(userportal-0.js@29)
> at Unknown.du(userportal-0.js@57)
> at Unknown.eval(userportal-0.js@54)
> dRc @ userportal-0.js:5832
> userportal-0.js:5832 Thu Aug 04 13:18:52 GMT+200 2016 remote
> SEVERE: Uncaught exceptioncom.google.gwt.event.shared.UmbrellaException:
> Exception caught: (TypeError)
>  __gwt$exception: : Cannot read property 'k' of null
> at Unknown.Ur(userportal-0.js@17729)
> at Unknown.as(userportal-0.js@41)
> at Unknown.wX(userportal-0.js@19)
> at Unknown.zX(userportal-0.js@19)
> at Unknown.KW(userportal-0.js@116)
> at Unknown.Q$c(userportal-0.js@27)
> at Unknown.$$c(userportal-0.js@13141)
> at Unknown._S(userportal-0.js@147)
> at Unknown.S$c(userportal-0.js@113)
> at Unknown.Yhd(userportal-0.js@21707)
> at Unknown.G6c(userportal-0.js@85)
> at Unknown.D8c(userportal-0.js@46)
> at Unknown._t(userportal-0.js@29)
> at Unknown.du(userportal-0.js@57)
> at Unknown.eval(userportal-0.js@54)
> at Unknown.Sy(userportal-0.js@20)
> at Unknown.Chd(userportal-0.js@98)
> at Unknown.dMi(userportal-28.js@147517)
> at Unknown.Yhd(userportal-0.js@21325)
> at Unknown.G6c(userportal-0.js@85)
> at Unknown.F6c(userportal-0.js@60)
> at Unknown.B8c(userportal-0.js@

Re: [ovirt-devel] Strange issues with com.google.gwt.i18n.client.Messages.AlternateMessage [bz#1358837]

[Vojtech Szocs]

- Original Message -
> From: "Scott Dickerson" 
> To: "Vojtech Szocs" 
> Cc: "Alexander Wels" , "Ramesh Nachimuthu" 
> , "devel" 
> Sent: Thursday, July 28, 2016 6:27:44 PM
> Subject: Re: Strange issues with 
> com.google.gwt.i18n.client.Messages.AlternateMessage [bz#1358837]
> 
> On Thu, Jul 28, 2016 at 11:19 AM, Vojtech Szocs  wrote:
> 
> > Hi Ramesh,
> >
> > this issue seems to be related with removal of @DefaultMessage annotations,
> > moving the default (English) strings into corresponding .properties files.
> >
> 
> Apparently if both properties file definitions and annotations are
> connected to the same message method, the properties version takes
> precidence.  I wasn't sure if this applied to alternate messages, but your
> problem clearly shows that it does.
> 
> 
> > As we generally want default strings to reside in .properties files, I see
> > following options to explore, based on our earlier conversation:
> >
> > 1, try annotating UIMessages interface with:
> >@Generate(format = "com.google.gwt.i18n.server.PropertyCatalogFactory")
> >
> >- ref:
> > https://github.com/gwtproject/gwt/issues/7032#issuecomment-110858030
> >- this is likely non-feasible, however, since @Generate requests
> > generation
> >  of translation sources (.properties) from Java code
> >
> > 2, try removing @AlternateMessage annotation and modify .properties file:
> >recurrenceType=Incorrect enum
> >recurrenceType[UNKNOWN]=None
> >recurrenceType[INTERVAL]=Minute
> >recurrenceType[HOURLY]=Hourly
> >recurrenceType[DAILY]=Daily
> >recurrenceType[WEEKLY]=Weekly
> >recurrenceType[MONTHLY]=Monthly
> >
> >- ref:
> > http://www.gwtproject.org/doc/latest/DevGuideI18nPluralForms.html
> >- this might not work as it might be @PluralCount-only (not for @Select)
> >
> >
> I just tried this alternate messages in properties file technique and it
> will work.

I'm actually surprised that it works for @Select annotation.

I didn't see that mentioned anywhere in GWT docs, note that ^^ ref link
covers the @PluralCount annotation only. No mention of @Select anywhere.

I agree with others - if it works, let's use that for now.

> 
> UIMessages.java:
> String recurrenceType(@Messages.Select
> GlusterVolumeSnapshotScheduleRecurrence recurrence);
> 
> UIMessage.properties:
> recurrenceType=Incorrect enum
> recurrenceType[UNKNOWN]=None
> recurrenceType[INTERVAL]=Minute
> recurrenceType[HOURLY]=Hourly
> recurrenceType[DAILY]=Daily
> recurrenceType[WEEKLY]=Weekly
> recurrenceType[MONTHLY]=Monthly
> 
> The generated code looks like this:
>   public java.lang.String
> recurrenceType(org.ovirt.engine.core.common.businessentities.gluster.GlusterVolumeSnapshotScheduleRecurrence
> arg0) {
> java.lang.String returnVal = null;
> int arg0_ordinal = -1;
> if (arg0 != null) {
>   arg0_ordinal = arg0.ordinal();
> }
> switch (arg0_ordinal) {
>   case 2:  // DAILY
> returnVal = "Daily";
> break;
>   case 1:  // HOURLY
> returnVal = "Hourly";
> break;
>   case 0:  // INTERVAL
> returnVal = "Minute";
> break;
>   case 4:  // MONTHLY
> returnVal = "Monthly";
> break;
>   case 5:  // UNKNOWN
> returnVal = "None";
> break;
>   case 3:  // WEEKLY
> returnVal = "Weekly";
> break;
> }
> if (returnVal != null) {
>   return returnVal;
> }
> return "Incorrect enum";
>   }
> 
> 
> 
> > 3, remove @AlternateMessage & handle enum-to-string formatting on our own
> >
> >String sizeUnitString(String size, @Messages.Select
> > SizeConverter.SizeUnit sizeUnit);
> >becomes
> >String sizeUnitString(String size, String sizeUnitValue);
> >
> >String recurrenceType(@Select GlusterVolumeSnapshotScheduleRecurrence
> > recurrence);
> >gets removed, because there is no point in having "{0}" message
> >
> >getMessages().sizeUnitString(size, sizeUnit);
> >becomes
> >getMessages().sizeUnitString(size, (sizeUnit));
> >
> >getMessages().recurrenceType(recurrence);
> >becomes
> >(recurrence);
> >
> > Personally, I think 3, is the most correct solution. As Alex wrote below,
> > we're planning to switch away from GWT i18n mechanism in the long-term

Re: [ovirt-devel] Strange issues with com.google.gwt.i18n.client.Messages.AlternateMessage [bz#1358837]

[Vojtech Szocs]

Hi Ramesh,

this issue seems to be related with removal of @DefaultMessage annotations,
moving the default (English) strings into corresponding .properties files.

As we generally want default strings to reside in .properties files, I see
following options to explore, based on our earlier conversation:

1, try annotating UIMessages interface with:
   @Generate(format = "com.google.gwt.i18n.server.PropertyCatalogFactory")

   - ref: https://github.com/gwtproject/gwt/issues/7032#issuecomment-110858030
   - this is likely non-feasible, however, since @Generate requests generation
 of translation sources (.properties) from Java code

2, try removing @AlternateMessage annotation and modify .properties file:
   recurrenceType=Incorrect enum
   recurrenceType[UNKNOWN]=None
   recurrenceType[INTERVAL]=Minute
   recurrenceType[HOURLY]=Hourly
   recurrenceType[DAILY]=Daily
   recurrenceType[WEEKLY]=Weekly
   recurrenceType[MONTHLY]=Monthly

   - ref: http://www.gwtproject.org/doc/latest/DevGuideI18nPluralForms.html
   - this might not work as it might be @PluralCount-only (not for @Select)

3, remove @AlternateMessage & handle enum-to-string formatting on our own

   String sizeUnitString(String size, @Messages.Select SizeConverter.SizeUnit 
sizeUnit);
   becomes
   String sizeUnitString(String size, String sizeUnitValue);

   String recurrenceType(@Select GlusterVolumeSnapshotScheduleRecurrence 
recurrence);
   gets removed, because there is no point in having "{0}" message

   getMessages().sizeUnitString(size, sizeUnit);
   becomes
   getMessages().sizeUnitString(size, (sizeUnit));

   getMessages().recurrenceType(recurrence);
   becomes
   (recurrence);

Personally, I think 3, is the most correct solution. As Alex wrote below,
we're planning to switch away from GWT i18n mechanism in the long-term;
relying on @AlternateMessage etc. is therefore an obstacle to that effort.

Also, we already have infra for localizing enum members: LocalizedEnums

So as part of solution 3, we should add into LocalizedEnums:

  String GlusterVolumeSnapshotScheduleRecurrence___INTERVAL();
  String GlusterVolumeSnapshotScheduleRecurrence___HOURLY();
  String GlusterVolumeSnapshotScheduleRecurrence___DAILY();
  String GlusterVolumeSnapshotScheduleRecurrence___WEEKLY();
  String GlusterVolumeSnapshotScheduleRecurrence___MONTHLY();
  String GlusterVolumeSnapshotScheduleRecurrence___UNKNOWN();

plus add corresponding strings in LocalizedEnums.properties file.

This way, we can leverage existing EnumTranslator#translate method.

By doing so,  mentioned above === EnumTranslator#translate

Regards,
Vojtech


- Original Message -
> From: "Alexander Wels" 
> To: "Ramesh Nachimuthu" 
> Cc: "devel" , "Vojtech Szocs" , "Scott 
> Dickerson" 
> Sent: Thursday, July 28, 2016 2:21:23 PM
> Subject: Re: Strange issues with 
> com.google.gwt.i18n.client.Messages.AlternateMessage [bz#1358837]
> 
> On Thursday, July 28, 2016 05:49:57 AM Ramesh Nachimuthu wrote:
> > Hi,
> > 
> >  We have a strange issue with the
> > com.google.gwt.i18n.client.Messages.AlternateMessage in UIMessages.java. We
> > have defined some alternate messages using @Messages.Select with Enums. But
> > its doesn't work any more.
> > 
> > We have following messages in the UIMessages.java.
> > 
> > @Messages.AlternateMessage(value = { "UNKNOWN" , "None" , "INTERVAL" ,
> > "Minute" , "HOURLY" , "Hourly" , "DAILY" , "Daily" , "WEEKLY" , "Weekly" ,
> > "MONTHLY" , "Monthly" }) String recurrenceType(@Messages.Select
> > GlusterVolumeSnapshotScheduleRecurrence recurrence);
> > 
> > @Messages.AlternateMessage(value = { "BYTES" , "{0} B" , "KiB" , "{0}
> > KiB" , "MiB" , "{0} MiB" , "GiB" , "{0} GiB" , "TiB" , "{0} TiB" }) String
> > sizeUnitString(String size, @Messages.Select
> > SizeConverter.SizeUnit sizeUnit);
> > 
> > But the generated UIMessages_.java doesn't use any of the enum conditions.
> > 
> >   public java.lang.String
> > recurrenceType(org.ovirt.engine.core.common.businessentities.gluster.Gluste
> > rVolumeSnapshotScheduleRecurrence arg0) { java.lang.String returnVal =
> > null;
> > int arg0_ordinal = -1;
> > if (arg0 != null) {
> >   arg0_ordinal = arg0.ordinal();
> > }
> > if (returnVal != null) {
> >   return returnVal;
> > }
> > return "Incorrect enum";
> >   }
> > 
> >   public java.lang.String sizeUnitString(java.lang.String
> > arg0,org.ovirt.engine

Re: [ovirt-devel] Type Safety on the Frontend (refactoring of all async queries)

[Vojtech Szocs]

Great work, Martin!

Always happy to see improvements in UI code :)

Vojtech


- Original Message -
> From: "Martin Betak" 
> To: "devel" 
> Cc: "Vojtech Szocs" , "Tomas Jelinek" 
> , "Alexander Wels" 
> Sent: Monday, July 25, 2016 8:54:39 PM
> Subject: Type Safety on the Frontend (refactoring of all async queries)
> 
> Hi All,
> 
> today a *major* frontend refactoring was merged [1].
> Its purpose was to remove some of the most significant artifacts of legacy C#
> code.
> 
> Huge thanks to Vojtech and Alex for heavenly patience during code review!
> 
> For a complete description please see the commit message, but here are
> some highlights for programmers that need to touch FE code:
> 
> 1) AsyncQuery, AsyncCallback and Converter are now generic and typesafe
>(formerly INewAsyncCallback and IAsyncConverter).
> 
> 2) It is no longer possible (or desirable) to PASS MODEL to queries.
>From within Model sublasses `new AsyncQuery<>(...)` will have the correct
>value set
>(see patch for impl details) and if you want to run a query on a different
>model
>(so the infrastructure would set the progress spinner on that model
>instead),
>usually for the purpose of a ListModel showing a popup window - where we
>want to
>display the spinner on the dialog window instead, you can use the
>`myWindowModel.asyncQuery(...)` helper factory to create query with model
>set
>to myWindowModel.
> 
>// note: this also has the nice side-effect of eliminating the harmful
>pattern of using
>// the model value from within callbacks by casting it to surrounding
>model type (while that
>// value is already available by feature of java inner classes)
> 
> 3) AsyncDataProvider's API methods now deal with strongly typed queries. This
> is facilitated
>through usage of strongly typed Converters (please see some defined
>converters -> usually
>you just need a CastingConverter<> or a ListConverter<>).
>Please use this architectural layer of strongly typed AsyncDataProvider to
>your advantage.
>(as plain  Fronted.runQuery does not provide any guarantees and leaves you
>at risk of
>mis-casting the return value).
> 
> If you have any more questions please feel free to ask me or look at the
> patch for details
> (warning: it's quite big!).
> 
> This kind of major change necessarily touched all areas of the code (those
> issuing queries...)
> and there is of course some probability that something may break. But I
> believe this risk is
> well outweight by the benefits. Nevertheless if you find any issue please let
> me know and
> we can fix it together.
> 
> Thanks again to anyone who contributed to this noble effort.
> 
> Best regards :-)
> 
> Martin
> 
> [1] https://gerrit.ovirt.org/#/c/60822/
> 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Logs showing in the oVirt Engine localization/translation

[Vojtech Szocs]

Hi,

such logs come from Engine backend. These messages can be found here:

  
backend/manager/modules/dal/src/main/resources/bundles/AuditLogMessages.properties

It seems that AuditLogMessages are not supposed to be translated (?)

Vojtech


- Original Message -
> From: "Juliette Tux" 
> To: Devel@ovirt.org
> Sent: Friday, June 24, 2016 6:21:56 PM
> Subject: [ovirt-devel] Logs showing in the oVirt Engine   
> localization/translation
> 
> Hello, gentlemen,
> 
> Is there a way to translate the logs which appear in the Engine interface at
> the bottom part of the window, see the secreenshot here:
> http://rgho.st/75Y5P2jXM.view ?
> 
> Were the logs meant to be translated at all, i.e. are they i18'd in the
> source code? Kindly direct me towards the relevant files in the v 3.6.x.
> 
> Sorry for another small stupid question, and lots of thanks in advance!
> 
> --
> Best regards,
> Julia Dronova
> 
> С уважением, Дронова Юлия
> 
> ___
> 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.0 Nightly repo

[Vojtech Szocs]

Hi everyone,

I think Sven was referring specifically to oVirt Dashboard component
of oVirt Engine product. Dashboard (UI plugin) has its own repo [1]

[1] https://gerrit.ovirt.org/#/admin/projects/ovirt-engine-dashboard

with dedicated Jenkins job to build its RPM. When Engine is installed,
Dashboard RPM is *automatically* installed & updated as well.

You don't have to worry about tracking Dashboard RPM version installed
on machine running your Engine. Dashboard is technically part of Engine
because it relies on Engine UI plugin infra, it's not "standalone" like
VDSM.

TL;DR the fact that Dashboard has its own RPM shouldn't impact users,
it's a logical part of Engine.

Regards,
Vojtech


- Original Message -
> From: "Eyal Edri" 
> To: "Vinzenz Feenstra" 
> Cc: "Unname" 
> Sent: Thursday, June 16, 2016 3:11:51 PM
> Subject: Re: [ovirt-devel] oVirt 4.0 Nightly repo
> 
> I'm not sure what you mean or which versions you're referring to.
> Like every project there is the 'master' branch and nightlies which is latest
> and greatest (and probably the least stable, but still go over heavy CI
> tests).
> The oVirt project reached a point when the next stable major version (4.0) is
> nearing GA, and part of the process is to branch it to create rpms for it,
> in order to continue developing 4.1 (now master) and not to merge new
> features that may risk 4.0 stability the new branch has to be created.
> 
> You as user/developer has the choice to choose which version to use,
> according to you needs:
> for e.g, at this time point, you choices are:
> 
> 1. Use current stable: 3.6 rpms - most stable, only gets specific fixes and
> not major features - recommended for a production usage and if you don't
> need any of the new features [1]
> 2. Use current RC candidate for next major 4.0, which should be the next
> stable version soon and replace 3.6 as the latest stable version [2]
> 3. Use nightlies for every version - either 4.0, master, 3.6 - use at your
> own risk since these are not official releases and not going via extensive
> QA, although the automated tests for each version
> are improving over time and make the nightlies more and more stable. [3]
> 
> 
> Just to help better undertand, if you'll make the same decision in one more
> months for e.g, after 4.0 is GA, you choices will be:
> 
> 1. use current stable 4.0 (unless you really want to use older 3.6)
> 2. use nightlies
> 
> So the extra versions are temp version that are part of the development
> process and actually gives you an oppertunity to check out new features that
> are not available yet in a formal stable version.
> I hope it gives some info on the diff between all the versions.
> 
> [1]. http://resources.ovirt.org/pub/ovirt-3.6/
> [2] http://resources.ovirt.org/pub/ovirt-4.0-pre/
> [3] http://resources.ovirt.org/pub/ovirt-4.0-snapshot(+-static) ,
> http://resources.ovirt.org/pub/ovirt-master-snapshot(+static)
> 
> 
> 
> 
> 
> 
> 
> On Thu, Jun 16, 2016 at 12:16 PM, Vinzenz Feenstra < vfeen...@redhat.com >
> wrote:
> 
> 
> 
> > On Jun 16, 2016, at 11:06 AM, Sven Kieske < s.kie...@mittwald.de > wrote:
> > 
> > On 14/06/16 17:34, Vojtech Szocs wrote:
> >> Hi,
> >> 
> >> ovirt-engine-dashboard is currently built from master as well.
> >> 
> >> We should probably create a stable branch, e.g.
> >> ovirt-engine-dashboard-1.0.
> > 
> > Hi,
> > 
> > speaking as an end user (mostly):
> > 
> > please not yet-another-versioning in the great ovirt project.
> > 
> > I'm already having severe issues tracking which engine versions works
> > with which vdsm version, let alone track which datacenter and cluster
> > version within each engine version works with which vdsm version and
> > which features are (un)supported.
> > 
> > Please don't add another different version to the already far to complex
> > equation.
> +1 :-)
> > 
> > I'd suggest you take the same version number as the supported
> > ovirt-engine, you also should adjust release cycles of all the
> > subprojects where possible (I know that doesn't work always).
> > 
> > this would make every users life make so much less painful.
> > 
> > keep up the great work!
> > 
> > --
> > Mit freundlichen Grüßen / Regards
> > 
> > Sven Kieske
> > 
> > Systemadministrator
> > Mittwald CM Service GmbH & Co. KG
> > Königsberger Straße 6
> > 32339 Espelkamp
> > T: +495772 293100
> > F: +495772 29
> > https://www.mittwald.de
&g

Re: [ovirt-devel] GWT developer mode not working on fc23?

[Vojtech Szocs]

Hi Roman,

the latest Firefox version that supports NPAPI (Netscape plugin API),
which is needed when debugging GWT webapps via GWT browser plugin
(a.k.a the "classic" dev mode) is Firefox 26. In later FF releases,
they removed NPAPI which broke GWT debug browser plugin. Same story
for Chrome as well.

The "new" (and recommended) way to debug GWT webapps is "super" dev
mode: http://lists.ovirt.org/pipermail/devel/2016-February/012268.html

The "super" dev mode debugs GWT application in browser, using source
maps to map Java source code to generated JavaScript. The downside is
that you can't use Java IDE here.

I know that GWT debugging via Java IDE can be very slow, so I suggest
trying Chrome + "super" dev mode.

Vojtech


- Original Message -
> From: "Roman Mohr" 
> To: "Alexander Wels" 
> Cc: "devel" , "Tomas Jelinek" , 
> "Vojtech Szocs" 
> Sent: Tuesday, June 7, 2016 2:38:22 PM
> Subject: Re: GWT developer mode not working on fc23?
> 
> On Tue, Jun 7, 2016 at 2:28 PM, Alexander Wels  wrote:
> > On Tuesday, June 07, 2016 02:15:07 PM Roman Mohr wrote:
> >> On Tue, Jun 7, 2016 at 2:00 PM, Roman Mohr  wrote:
> >> > Hi,
> >> >
> >> > I wanted to debug some GWT code the first time on fc23. No matter if I
> >> > try to debug 4.0 or 3.6 I always see in my browser and in the gwt
> >> >
> >> > developer console:
> >> > 00:01:36.758 [ERROR] Unable to load module entry point class
> >> >
> >> > com.gwtplatform.mvp.client.ApplicationControllerImpl (see associated
> >> > exception for details)
> >> >
> >> > com.google.gwt.core.client.JavaScriptException: (NS_ERROR_FAILURE)
> >> > @com.google.gwt.storage.client.StorageImpl::getItem(Ljava/lang/String;Ljav
> >> > a/lang/String;)([string: 'localStorage', string:
> >> > 'ENGINE_WebAdmin_LogHead']): Component
> >> > returned failure code: 0x80004005 (NS_ERROR_FAILURE)
> >> > [nsIDOMStorage.getItem]
> >> > at
> >> > com.google.gwt.dev.shell.BrowserChannelServer.invokeJavascript(BrowserCha
> >> > nnelServer.java:249) at
> >> > com.google.gwt.dev.shell.ModuleSpaceOOPHM.doInvoke(ModuleSpaceOOPHM.java:
> >> > 136) at
> >> > com.google.gwt.dev.shell.ModuleSpace.invokeNative(ModuleSpace.java:576)
> >> > at
> >> > com.google.gwt.dev.shell.ModuleSpace.invokeNativeObject(ModuleSpace.java:
> >> > 284) at
> >> > com.google.gwt.dev.shell.JavaScriptHost.invokeNativeObject(JavaScriptHost
> >> > .java:91) at
> >> > com.google.gwt.storage.client.StorageImpl.getItem(StorageImpl.java) at
> >> > com.google.gwt.storage.client.Storage.getItem(Storage.java:257) at
> >> > org.ovirt.engine.ui.common.system.ClientStorageImpl.getLocalItemImpl(Clie
> >> > ntStorageImpl.java:53) at
> >> > org.ovirt.engine.ui.common.system.ClientStorageImpl.getLocalItem(ClientSt
> >> > orageImpl.java:46) at
> >> > org.ovirt.engine.ui.common.logging.LocalStorageLogHandler.readInt(LocalSt
> >> > orageLogHandler.java:56) at
> >> > org.ovirt.engine.ui.common.logging.LocalStorageLogHandler.setActive(Local
> >> > StorageLogHandler.java:48) at
> >> > org.ovirt.engine.ui.common.logging.LocalStorageLogHandler.init(LocalStora
> >> > geLogHandler.java:40) at
> >> > org.ovirt.engine.ui.common.system.BaseApplicationInit.initLocalStorageLog
> >> > Handler(BaseApplicationInit.java:120) at
> >> > org.ovirt.engine.ui.common.system.BaseApplicationInit.onBootstrap(BaseApp
> >> > licationInit.java:102) at
> >> > com.gwtplatform.mvp.client.ApplicationControllerImpl.init(ApplicationCont
> >> > rollerImpl.java:11) at
> >> > com.gwtplatform.mvp.client.ApplicationControllerImpl.onModuleLoad(Applica
> >> > tionControllerImpl.java:15) at
> >> > sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >> > at
> >> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java
> >> > :62) at
> >> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI
> >> > mpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498)
> >> > at com.google.gwt.dev.shell.ModuleSpace.onLoad(ModuleSpace.java:411)
> >> > at
> >> > com.google.gwt.dev.shell.OophmSessionHandler.loadModule(OophmSessionHandl
> >> > er.java:200) at
> >> > com.google.gwt.dev.s

Re: [ovirt-devel] oVirt 4.0 Nightly repo

[Vojtech Szocs]

Hi,

ovirt-engine-dashboard is currently built from master as well.

We should probably create a stable branch, e.g. ovirt-engine-dashboard-1.0.

For now, the nightly publisher configs:

  jobs/confs/projects/ovirt/publish-rpms-nightly-{master,4.0}.yaml

both use ovirt-engine-dashboard "master" build-artifacts job.

Vojtech


- Original Message -
> From: "Francesco Romani" 
> To: "Eyal Edri" 
> Cc: "devel" , "Fabian Deutsch" , "Piotr 
> Kliczewski" ,
> "David Caro Estevez" , "Lev Veyde" 
> Sent: Tuesday, June 14, 2016 4:39:47 PM
> Subject: Re: [ovirt-devel] oVirt 4.0 Nightly repo
> 
> - Original Message -
> > From: "Eyal Edri" 
> > To: "Francesco Romani" 
> > Cc: "Simone Tiraboschi" , "Tal Nisan"
> > , "Piotr Kliczewski"
> > , "Dan Kenigsberg" , "Yaniv
> > Bronheim" , "Nir Soffer"
> > , "Juan Antonio Hernandez Fernandez"
> > , "Shirly Radco"
> > , "Yedidyah Bar David" , "Martin Sivak"
> > , "Fabian Deutsch"
> > , "Sandro Bonazzola" , "Lev
> > Veyde" , "Rafael Martins"
> > , "David Caro Estevez" , "devel"
> > 
> > Sent: Tuesday, June 14, 2016 4:37:55 PM
> > Subject: Re: [ovirt-devel] oVirt 4.0 Nightly repo
> > 
> > You don't need to do it francesco if vmconsole doesn't have a 4.0 branch (i
> > saw you're still using master ?)
> 
> Yes, ovirt-vmconsole is tagged abd build from master.
> 
> > In any case, see my previous patch which updates the publisher to publish
> > the 4.0 rpms that the 4.0 build artifacts for vdsm is creating rather than
> > master rpms.
> 
> Sure, will review, thanks for your patch.
> 
> Bests,
> 
> --
> Francesco Romani
> RedHat Engineering Virtualization R & D
> Phone: 8261328
> 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] [ACTION REQUESTED] i18n default English text is now stored in properties files

[Vojtech Szocs]

- Original Message -
> From: "Yaniv Dary" 
> To: "Scott Dickerson" 
> Cc: "engine-de...@ovirt.org" 
> Sent: Tuesday, May 31, 2016 5:24:17 PM
> Subject: Re: [ovirt-devel] [ACTION REQUESTED] i18n default English text is 
> now stored in properties files
> 
> Is this change being done for 4.0? I would think this is a risky change that
> better fits 4.1.

The follow-up changes mentioned by Scott (custom GWT i18n infra,
reduce redundancy within multiple AppErrors etc. properties files)
are planned to be done in 4.1.

> 
> 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, May 24, 2016 at 6:20 PM, Scott Dickerson < sdick...@redhat.com >
> wrote:
> 
> 
> 
> 
> 
> On Tue, May 24, 2016 at 9:28 AM, Martin Sivak < msi...@redhat.com > wrote:
> 
> 
> > Are you talking about some files in specific, and if so which ones?
> 
> # find . -name AppErrors.properties | grep -v generated | grep -v target
> 
> ./backend/manager/modules/dal/src/main/resources/bundles/AppErrors.properties
> ./frontend/webadmin/modules/frontend/src/main/resources/org/ovirt/engine/ui/frontend/AppErrors.properties
> ./frontend/webadmin/modules/userportal-gwtp/src/main/resources/org/ovirt/engine/ui/frontend/AppErrors.properties
> ./frontend/webadmin/modules/webadmin/src/main/resources/org/ovirt/engine/ui/frontend/AppErrors.properties
> 
> That properties file does appear 3 times on the frontend side. It is quite
> annoying, and there is a reason for it. I ran a process to move English text
> to properties files out of annotations, creating the properties files as
> necessary. In this case, AppErrors.properties existed in both
> "userportal-gwtp" and "webadmin", but didn't originally exist in the
> frontend module. Due to the way GWT i18n and GWT compiling work, default
> values from annotations on the interface would augment the properties values
> that GWT finds first on the classpath. Since AppErrors.properties in
> "webadmin" is closer to the compiler then AppError.properties in "frontend",
> webadmin will be used. This allows us to have a full set of AppErrors
> messages per GWT project, unique to get GWT project. It still confuses me a
> bit. There are better ways to do this.
> 
> ConsoleErrors and VdsmErrors do the same thing. Those 3 message bundles are
> on the list to do something about in the next round of work. We'll probably
> create a common (App|Console|Vdsm)Errors interface, move messages that are
> the same between the user portal and the admin portal to the common ancestor
> and only define app specific keys in their respective projects.
> 
> 
> 
> Now, I know the files are not 100% equivalent, but we were adding the
> same messages to all of them in all the features I was working on.
> This leads me to believe that most of the people treat them as the
> same and we should only have one source for them.
> 
> 
> Yes, our goal is to only have 1 source for them. It is unfortunate that you
> have to add the text in multiple places currently. We'll get better (soon).
> 
> 
> 
> Martin
> 
> On Tue, May 24, 2016 at 3:17 PM, Scott Dickerson < sdick...@redhat.com >
> wrote:
> > response inline
> > 
> > On Tue, May 24, 2016 at 5:29 AM, Martin Sivak < msi...@redhat.com > wrote:
> >> 
> >> Hi,
> >> 
> >> We still have three almost identical files. Can we somehow keep just
> >> one and generate the other two? I was actually playing a bit with a
> >> change in the opposite direction - keeping just the EngineMessages
> >> enum with added default english translations and generating all other
> >> files from it.
> > 
> > 
> > Are you talking about some files in specific, and if so which ones?
> > 
> >> 
> >> Do you think it would make sense? It would not require a test then as
> >> the consistency would be checked during compilation phase directly.
> > 
> > 
> > Sure, generating some code from a key/message file could be useful. The
> > difficulty comes in when we have Messages or Constants interface that
> > inherit from a common ancestor. That construct is used a few times to share
> > messages between both the user portal and the admin portal.
> > 
> > The primary reasons this change was done was to simplify translation and to
> > better manage workflow between language files in gerrit and documents in
> > Zanata. With this change, there is now a 1 to 1 mapping of properties files
> > to zanata documents. Well, for the front end i18n code at least. The
> > current translations for 4.0 can be seen here:
> > 
> > https://translate.zanata.org/iteration/view/ovirt/master/documents
> > 
> > We will be making additional i18n changes for 4.1, so any input is very
> > welcome.
> > 
> >> 
> >> Martin
> >> 
> >> On Mon, May 23, 2016 at 7:38 PM, Scott Dickerson < sdick...@redhat.com >
> >> wrote:
> >> > Hi,
> >> > 
> >> > In order to resolve bug [1] and prep [2], the default

Re: [ovirt-devel] Empty Dropdown Menus in Webadmin

[Vojtech Szocs]

Hi Phillip,

can you please share some screenshots?

Thanks,
Vojtech


- Original Message -
> From: "Phillip Bailey" 
> To: devel@ovirt.org
> Sent: Tuesday, May 31, 2016 2:47:31 PM
> Subject: [ovirt-devel] Empty Dropdown Menus in Webadmin
> 
> Hi,
> 
> Is anyone else experiencing empty dropdown menus in webadmin? I started
> having the problem after rebasing Friday afternoon. I rebased again this
> morning, but am still experiencing the same problem. I'm trying to determine
> whether this is something isolated to my environment, or a more widespread
> issue.
> 
> I appreciate any advice any of you may be able to offer.
> 
> Thanks!
> 
> -Phillip Bailey
> 
> ___
> 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 Reports Portal localization

[Vojtech Szocs]

Hi,

I'm not the maintainer but you can clone `ovirt-reports` git repo,
the localized messages seem to be at:

  packaging/ovirt-reports/resources/reports_resources/localization

In Zanata, I found a project called `Ovirt Engine Reports`:

  https://translate.zanata.org/project/view/ovirt-reports-history

Hope it helps.

Regards,
Vojtech


- Original Message -
> From: "Juliette Tux" 
> To: Devel@ovirt.org
> Sent: Tuesday, May 31, 2016 1:50:08 PM
> Subject: [ovirt-devel] oVirt Reports Portal localization
> 
> Hello gentlemen,
> Russian localizators here :)
> 
> Which files should we look into to be able to translate the Reports Portal
> interface/messages for oVirt ver 3.x ?
> Did not find anything relevant on Zanata in case you would like to redirect
> me over 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 4.0 Localization Question #4] "Disk Containers Icon"

[Vojtech Szocs]

Hi Yuko,

this string is used on Disks main tab and Storage/Disks sub tab:
there's an icon column, right before "Attached To" column, which
shows the "VM type" (either opaque or translucent monitor icon).

The string "Disk Containers Icon" isn't the best, I think, but
I believe it's meant in plural context (a disk can have multiple
VMs assigned, e.g. when "VM type" is template).

[This string is used in column context menu (when you right-click
the table's header area). This is the only usage of this string.]

Vojtech


- Original Message -----
> From: "Yuko Katabami" 
> To: devel@ovirt.org, "Vojtech Szocs" 
> Sent: Wednesday, May 18, 2016 1:10:07 PM
> Subject: Re: [oVirt 4.0 Localization Question #4] "Disk Containers Icon"
> 
> Hi Vojtech,
> 
> Could you please help us?
> 
> Kind regards,
> 
> Yuko
> 
> On Wed, May 18, 2016 at 11:41 AM, Yuko Katabami  wrote:
> 
> > Hi all,
> >
> > Could anyone help us with the following question?
> >
> > ​​*File: *UI Common ApplicationConstants
> >
> > *Resource ID: *containersIconDisk
> >
> > *String: *Disk Containers Icon
> >
> > *Question:* Is Container plural or should be singular with apostrophe s?
> > (i.e. Container's Icon)
> >
> >
> > Kind regards,
> >
> >
> > Yuko
> >
> 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] gerrit.ovirt.org projects

[Vojtech Szocs]

- Original Message -
> From: "Shlomo Ben David" 
> To: devel@ovirt.org
> Sent: Tuesday, May 17, 2016 1:49:30 PM
> Subject: [ovirt-devel] gerrit.ovirt.org projects
> 
> Hi,
> 
> I have a question about projects on gerrit.ovirt.org .
> I'm working on cleaning up the gerrit.ovirt.org and updating the replication
> process to github, I've noticed that the projects below weren't updated > ~6
> months.
> 
> Do you know which of the below projects is still relevant for replication
> (sync to github)?
> 
> ovirt-register
> test
> chrooter
> gluster-nagios-monitoring
> ovirt-container-node
> ovirt-container-engine
> ovirt-engine-sdk-js

The `ovirt-engine-sdk-js` was meant to contain JavaScript SDK
for working with Engine REST API. It's currently empty, we plan
to merge some (older) stuff there for future reference.

For now, there's no need to replicate this project to GitHub.

> vdsm-arch-dependencies
> ovirt-node-dbus-backend
> samples-portals
> jasperreports-server-rpm
> ovirt-node-tests
> ovirt-engine-sdk-tests
> Node
> ovirt-tools-common-python
> mediawiki-example
> 
> 
> Thanks in advanced,
> 
> Shlomi Ben-David | Software Engineer | Red Hat ISRAEL
> Phone: +972-54-8008858
> IRC: sbendavi
> 
> OPEN SOURCE - 1 4 011 && 011 4 1
> 
> ___
> 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] [UI plugins] RestApiSessionAcquired is out, api.ssoToken() is in

[Vojtech Szocs]

Hi everyone,

we've merged a patch that aligns UI code with Engine SSO infra:

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

In particular, UI code that creates & maintains REST webapp's
HTTP session was removed in favor of using SSO token.

**UI plugin authors take note!** The "RestApiSessionAcquired"
callback was removed -- please update your UI plugins to use
the new "api.ssoToken" function when making REST API requests:

  var xhr = new XMLHttpRequest();
  xhr.open('GET', 'http://example.com/ovirt-engine/api');
  xhr.setRequestHeader('Authorization', 'Bearer ' + api.ssoToken());
  xhr.setRequestHeader('Accept', 'application/json');
  xhr.addEventListener('load', function () {
// response loaded OK, parse JSON data
var data = JSON.parse(this.responseText);
  });
  xhr.send();

While being a breaking change, this should simplify UI plugin
code because:

- the new "api.ssoToken" function can be called anytime,
  removing the need for an asynchronous callback

- no need to use session-specific request headers anymore
  (like "Prefer: persistent-auth" and "JSESSIONID: xxx"),
  just use "Authorization: Bearer xxx" and you're good

Please see commit msg of above mentioned patch for further
details on the changes and their implications.

Let me know if you have any questions or comments.

Regards,
Vojtech
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Master ovirt-engine build broken

[Vojtech Szocs]

- Original Message -
> From: "Eyal Edri" 
> To: "Vojtech Szocs" 
> Cc: "Oved Ourfali" , "devel" 
> Sent: Wednesday, May 4, 2016 2:38:40 PM
> Subject: Re: [ovirt-devel] Master ovirt-engine build broken
> 
> Vojtech,
> Any ideas on a test we can add to check-patch.sh (other than building all
> permutations) that can help catch these ?

We already have Java unit tests for these issues:

  org.ovirt.engine.ui.uicompat.UIMessagesTest
  org.ovirt.engine.ui.common.CommonApplicationMessagesTest
  org.ovirt.engine.ui.userportal.ApplicationMessagesTest
  org.ovirt.engine.ui.webadmin.ApplicationMessagesTest

they were added like 1 year ago by Alexander [1].

[1] https://gerrit.ovirt.org/#/c/32995/

I'm not sure why `check-patch` didn't report errors,
because above mentioned unit tests should be executed
just like any other Engine unit tests.

> 
> The original patch didn't fail on unit tests (though I can't see info since
> the build got deleted, we now increased the history for builds so we will
> be able to see it).

I don't know why above mentioned unit tests didn't
fail when `check-patch` was executed. If this happens
again, we can investigate test logs for that build.

> Please let me know once the translations patch is re-submitted,I'd like to
> monitor it and see if CI catch any issues there.

OK, we'll let you know.

> 
> e.
> 
> On Wed, May 4, 2016 at 3:30 PM, Vojtech Szocs  wrote:
> 
> >
> >
> > - Original Message -
> > > From: "Vojtech Szocs" 
> > > To: "Oved Ourfali" 
> > > Cc: "devel" 
> > > Sent: Wednesday, May 4, 2016 2:24:21 PM
> > > Subject: Re: [ovirt-devel] Master ovirt-engine build broken
> > >
> > >
> > >
> > > - Original Message -
> > > > From: "Vojtech Szocs" 
> > > > To: "Oved Ourfali" , "David Caro"
> > > > 
> > > > Cc: "devel" 
> > > > Sent: Wednesday, May 4, 2016 2:19:09 PM
> > > > Subject: Re: [ovirt-devel] Master ovirt-engine build broken
> > > >
> > > >
> > > >
> > > > - Original Message -
> > > > > From: "Oved Ourfali" 
> > > > > To: "Vojtech Szocs" 
> > > > > Cc: "Marek Libra" , "devel" 
> > > > > Sent: Wednesday, May 4, 2016 2:07:19 PM
> > > > > Subject: Re: [ovirt-devel] Master ovirt-engine build broken
> > > > >
> > > > > Okay.
> > > > > Makes sense.
> > > > > Thanks Vojtech - please also revert this one.
> > > >
> > > > Trying to revert master patch https://gerrit.ovirt.org/#/c/56720/
> > > > gives me "500 Internal server error" -- am I missing something?
> > > >
> > > > Perhaps oVirt gerrit maintainers can advise here? (adding David)
> > >
> > > Sorry for the noise, I did it manually with git revert:
> > >
> > >   https://gerrit.ovirt.org/#/c/57031/
> > >
> > > Can someone please ack?
> >
> > Merged, this should fix the master build.
> >
> > >
> > > >
> > > > >
> > > > > Oved
> > > > >
> > > > > On Wed, May 4, 2016 at 3:04 PM, Vojtech Szocs 
> > wrote:
> > > > >
> > > > > > (top-posting)
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > root cause is wrong number of message parameters (placeholders)
> > > > > > in translated properties files, compared to message definitions
> > > > > > in Java code.
> > > > > >
> > > > > > For example, UIMessages#cpuInfoLabel method has 4 parameters,
> > > > > > but the corresponding message in `UIMessages_de_DE.properties`
> > > > > > only contains 3 placeholders.
> > > > > >
> > > > > > 4.0 String Freeze is May 25 so it's still OK to modify message
> > > > > > definitions in Java code.
> > > > > >
> > > > > > I suggest to simply revert the offending patch:
> > > > > >
> > > > > >   translations update from zanata ovirt-3.6
> > > > > >   https://gerrit.ovirt.org/#/c/56720/
> > > > > >
> > > > > > and create new one which doesn't introduce conflicts.
> > > > > >
> >

Re: [ovirt-devel] Master ovirt-engine build broken

[Vojtech Szocs]

- Original Message -
> From: "Vojtech Szocs" 
> To: "Oved Ourfali" 
> Cc: "devel" 
> Sent: Wednesday, May 4, 2016 2:24:21 PM
> Subject: Re: [ovirt-devel] Master ovirt-engine build broken
> 
> 
> 
> - Original Message -
> > From: "Vojtech Szocs" 
> > To: "Oved Ourfali" , "David Caro"
> > 
> > Cc: "devel" 
> > Sent: Wednesday, May 4, 2016 2:19:09 PM
> > Subject: Re: [ovirt-devel] Master ovirt-engine build broken
> > 
> > 
> > 
> > - Original Message -
> > > From: "Oved Ourfali" 
> > > To: "Vojtech Szocs" 
> > > Cc: "Marek Libra" , "devel" 
> > > Sent: Wednesday, May 4, 2016 2:07:19 PM
> > > Subject: Re: [ovirt-devel] Master ovirt-engine build broken
> > > 
> > > Okay.
> > > Makes sense.
> > > Thanks Vojtech - please also revert this one.
> > 
> > Trying to revert master patch https://gerrit.ovirt.org/#/c/56720/
> > gives me "500 Internal server error" -- am I missing something?
> > 
> > Perhaps oVirt gerrit maintainers can advise here? (adding David)
> 
> Sorry for the noise, I did it manually with git revert:
> 
>   https://gerrit.ovirt.org/#/c/57031/
> 
> Can someone please ack?

Merged, this should fix the master build.

> 
> > 
> > > 
> > > Oved
> > > 
> > > On Wed, May 4, 2016 at 3:04 PM, Vojtech Szocs  wrote:
> > > 
> > > > (top-posting)
> > > >
> > > > Hi,
> > > >
> > > > root cause is wrong number of message parameters (placeholders)
> > > > in translated properties files, compared to message definitions
> > > > in Java code.
> > > >
> > > > For example, UIMessages#cpuInfoLabel method has 4 parameters,
> > > > but the corresponding message in `UIMessages_de_DE.properties`
> > > > only contains 3 placeholders.
> > > >
> > > > 4.0 String Freeze is May 25 so it's still OK to modify message
> > > > definitions in Java code.
> > > >
> > > > I suggest to simply revert the offending patch:
> > > >
> > > >   translations update from zanata ovirt-3.6
> > > >   https://gerrit.ovirt.org/#/c/56720/
> > > >
> > > > and create new one which doesn't introduce conflicts.
> > > >
> > > > We have unit tests to detect these kinds of errors, this is
> > > > to ensure the build fails early on (before GWT compilation).
> > > >
> > > > I'm not sure why `check-patch` job for above mentioned patch
> > > > didn't report the problem, since UIMessagesTest should fail,
> > > > as Roman wrote below.
> > > >
> > > > Regards,
> > > > Vojtech
> > > >
> > > >
> > > > - Original Message -
> > > > > From: "Marek Libra" 
> > > > > To: "devel" 
> > > > > Sent: Wednesday, May 4, 2016 12:31:18 PM
> > > > > Subject: Re: [ovirt-devel] Master ovirt-engine build broken
> > > > >
> > > > > There are issues on other keys as well.
> > > > > I'm rebuilding for all locales locally now.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > From: "Marek Libra" 
> > > > > To: "devel" 
> > > > > Sent: Wednesday, May 4, 2016 11:29:55 AM
> > > > > Subject: Re: [ovirt-devel] Master ovirt-engine build broken
> > > > >
> > > > > The fix is here: https://gerrit.ovirt.org/#/c/57007/
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > From: "Roman Mohr" 
> > > > > To: "Oved Ourfali" 
> > > > > Cc: "devel" 
> > > > > Sent: Wednesday, May 4, 2016 10:27:51 AM
> > > > > Subject: Re: [ovirt-devel] Master ovirt-engine build broken
> > > > >
> > > > >
> > > > >
> > > > > On Wed, May 4, 2016 at 10:24 AM, Oved Ourfali < oourf...@redhat.com >
> > > > wrote:
> > > > >
> > > > >
> > > > >
> > > > > Roman - did you build the langs in order to find the issue?
> > > > >
> > > > > I ju

Re: [ovirt-devel] Master ovirt-engine build broken

[Vojtech Szocs]

- Original Message -
> From: "Vojtech Szocs" 
> To: "Oved Ourfali" , "David Caro" 
> Cc: "devel" 
> Sent: Wednesday, May 4, 2016 2:19:09 PM
> Subject: Re: [ovirt-devel] Master ovirt-engine build broken
> 
> 
> 
> - Original Message -
> > From: "Oved Ourfali" 
> > To: "Vojtech Szocs" 
> > Cc: "Marek Libra" , "devel" 
> > Sent: Wednesday, May 4, 2016 2:07:19 PM
> > Subject: Re: [ovirt-devel] Master ovirt-engine build broken
> > 
> > Okay.
> > Makes sense.
> > Thanks Vojtech - please also revert this one.
> 
> Trying to revert master patch https://gerrit.ovirt.org/#/c/56720/
> gives me "500 Internal server error" -- am I missing something?
> 
> Perhaps oVirt gerrit maintainers can advise here? (adding David)

Sorry for the noise, I did it manually with git revert:

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

Can someone please ack?

> 
> > 
> > Oved
> > 
> > On Wed, May 4, 2016 at 3:04 PM, Vojtech Szocs  wrote:
> > 
> > > (top-posting)
> > >
> > > Hi,
> > >
> > > root cause is wrong number of message parameters (placeholders)
> > > in translated properties files, compared to message definitions
> > > in Java code.
> > >
> > > For example, UIMessages#cpuInfoLabel method has 4 parameters,
> > > but the corresponding message in `UIMessages_de_DE.properties`
> > > only contains 3 placeholders.
> > >
> > > 4.0 String Freeze is May 25 so it's still OK to modify message
> > > definitions in Java code.
> > >
> > > I suggest to simply revert the offending patch:
> > >
> > >   translations update from zanata ovirt-3.6
> > >   https://gerrit.ovirt.org/#/c/56720/
> > >
> > > and create new one which doesn't introduce conflicts.
> > >
> > > We have unit tests to detect these kinds of errors, this is
> > > to ensure the build fails early on (before GWT compilation).
> > >
> > > I'm not sure why `check-patch` job for above mentioned patch
> > > didn't report the problem, since UIMessagesTest should fail,
> > > as Roman wrote below.
> > >
> > > Regards,
> > > Vojtech
> > >
> > >
> > > - Original Message -
> > > > From: "Marek Libra" 
> > > > To: "devel" 
> > > > Sent: Wednesday, May 4, 2016 12:31:18 PM
> > > > Subject: Re: [ovirt-devel] Master ovirt-engine build broken
> > > >
> > > > There are issues on other keys as well.
> > > > I'm rebuilding for all locales locally now.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > From: "Marek Libra" 
> > > > To: "devel" 
> > > > Sent: Wednesday, May 4, 2016 11:29:55 AM
> > > > Subject: Re: [ovirt-devel] Master ovirt-engine build broken
> > > >
> > > > The fix is here: https://gerrit.ovirt.org/#/c/57007/
> > > >
> > > >
> > > >
> > > >
> > > > From: "Roman Mohr" 
> > > > To: "Oved Ourfali" 
> > > > Cc: "devel" 
> > > > Sent: Wednesday, May 4, 2016 10:27:51 AM
> > > > Subject: Re: [ovirt-devel] Master ovirt-engine build broken
> > > >
> > > >
> > > >
> > > > On Wed, May 4, 2016 at 10:24 AM, Oved Ourfali < oourf...@redhat.com >
> > > wrote:
> > > >
> > > >
> > > >
> > > > Roman - did you build the langs in order to find the issue?
> > > >
> > > > I just ran 'mvn clean verify', so I saw it on my machine. On gerrit not
> > > all
> > > > of my builds showed that error.
> > > >
> > > > Looking at
> > > >
> > > >
> > > https://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:integration
> > > >
> > > > two patches passed and two failed after a topic rebase.
> > > >
> > > >
> > > >
> > > > Eyal - can we monitor a list of files that i changed will result in
> > > > also
> > > > building all the languages?
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Wed, May 4, 2016 at 11:22 AM, Eyal Edri < ee...@redhat.com 

Re: [ovirt-devel] Master ovirt-engine build broken

[Vojtech Szocs]

- Original Message -
> From: "Oved Ourfali" 
> To: "Vojtech Szocs" 
> Cc: "Marek Libra" , "devel" 
> Sent: Wednesday, May 4, 2016 2:07:19 PM
> Subject: Re: [ovirt-devel] Master ovirt-engine build broken
> 
> Okay.
> Makes sense.
> Thanks Vojtech - please also revert this one.

Trying to revert master patch https://gerrit.ovirt.org/#/c/56720/
gives me "500 Internal server error" -- am I missing something?

Perhaps oVirt gerrit maintainers can advise here? (adding David)

> 
> Oved
> 
> On Wed, May 4, 2016 at 3:04 PM, Vojtech Szocs  wrote:
> 
> > (top-posting)
> >
> > Hi,
> >
> > root cause is wrong number of message parameters (placeholders)
> > in translated properties files, compared to message definitions
> > in Java code.
> >
> > For example, UIMessages#cpuInfoLabel method has 4 parameters,
> > but the corresponding message in `UIMessages_de_DE.properties`
> > only contains 3 placeholders.
> >
> > 4.0 String Freeze is May 25 so it's still OK to modify message
> > definitions in Java code.
> >
> > I suggest to simply revert the offending patch:
> >
> >   translations update from zanata ovirt-3.6
> >   https://gerrit.ovirt.org/#/c/56720/
> >
> > and create new one which doesn't introduce conflicts.
> >
> > We have unit tests to detect these kinds of errors, this is
> > to ensure the build fails early on (before GWT compilation).
> >
> > I'm not sure why `check-patch` job for above mentioned patch
> > didn't report the problem, since UIMessagesTest should fail,
> > as Roman wrote below.
> >
> > Regards,
> > Vojtech
> >
> >
> > - Original Message -
> > > From: "Marek Libra" 
> > > To: "devel" 
> > > Sent: Wednesday, May 4, 2016 12:31:18 PM
> > > Subject: Re: [ovirt-devel] Master ovirt-engine build broken
> > >
> > > There are issues on other keys as well.
> > > I'm rebuilding for all locales locally now.
> > >
> > >
> > >
> > >
> > >
> > > From: "Marek Libra" 
> > > To: "devel" 
> > > Sent: Wednesday, May 4, 2016 11:29:55 AM
> > > Subject: Re: [ovirt-devel] Master ovirt-engine build broken
> > >
> > > The fix is here: https://gerrit.ovirt.org/#/c/57007/
> > >
> > >
> > >
> > >
> > > From: "Roman Mohr" 
> > > To: "Oved Ourfali" 
> > > Cc: "devel" 
> > > Sent: Wednesday, May 4, 2016 10:27:51 AM
> > > Subject: Re: [ovirt-devel] Master ovirt-engine build broken
> > >
> > >
> > >
> > > On Wed, May 4, 2016 at 10:24 AM, Oved Ourfali < oourf...@redhat.com >
> > wrote:
> > >
> > >
> > >
> > > Roman - did you build the langs in order to find the issue?
> > >
> > > I just ran 'mvn clean verify', so I saw it on my machine. On gerrit not
> > all
> > > of my builds showed that error.
> > >
> > > Looking at
> > >
> > >
> > https://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:integration
> > >
> > > two patches passed and two failed after a topic rebase.
> > >
> > >
> > >
> > > Eyal - can we monitor a list of files that i changed will result in also
> > > building all the languages?
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Wed, May 4, 2016 at 11:22 AM, Eyal Edri < ee...@redhat.com > wrote:
> > >
> > >
> > >
> > > right, and we can't enable lang permutation since it takes a very long
> > time
> > > to run.
> > >
> > > On Wed, May 4, 2016 at 11:07 AM, Tomas Jelinek < tjeli...@redhat.com >
> > wrote:
> > >
> > >
> > >
> > >
> > > - Original Message -
> > > > From: "Oved Ourfali" < oourf...@redhat.com >
> > > > To: "Tomas Jelinek" < tjeli...@redhat.com >
> > > > Cc: "Roman Mohr" < rm...@redhat.com >, "devel" < devel@ovirt.org >,
> > "Scott
> > > > Dickerson" < sdick...@redhat.com >
> > > > Sent: Wednesday, May 4, 2016 9:55:40 AM
> > > > Subject: Re: [ovirt-devel] Master ovirt-engine build broken
> > >

Re: [ovirt-devel] Master ovirt-engine build broken

[Vojtech Szocs]

(top-posting)

Hi,

root cause is wrong number of message parameters (placeholders)
in translated properties files, compared to message definitions
in Java code.

For example, UIMessages#cpuInfoLabel method has 4 parameters,
but the corresponding message in `UIMessages_de_DE.properties`
only contains 3 placeholders.

4.0 String Freeze is May 25 so it's still OK to modify message
definitions in Java code.

I suggest to simply revert the offending patch:

  translations update from zanata ovirt-3.6
  https://gerrit.ovirt.org/#/c/56720/

and create new one which doesn't introduce conflicts.

We have unit tests to detect these kinds of errors, this is
to ensure the build fails early on (before GWT compilation).

I'm not sure why `check-patch` job for above mentioned patch
didn't report the problem, since UIMessagesTest should fail,
as Roman wrote below.

Regards,
Vojtech


- Original Message -
> From: "Marek Libra" 
> To: "devel" 
> Sent: Wednesday, May 4, 2016 12:31:18 PM
> Subject: Re: [ovirt-devel] Master ovirt-engine build broken
> 
> There are issues on other keys as well.
> I'm rebuilding for all locales locally now.
> 
> 
> 
> 
> 
> From: "Marek Libra" 
> To: "devel" 
> Sent: Wednesday, May 4, 2016 11:29:55 AM
> Subject: Re: [ovirt-devel] Master ovirt-engine build broken
> 
> The fix is here: https://gerrit.ovirt.org/#/c/57007/
> 
> 
> 
> 
> From: "Roman Mohr" 
> To: "Oved Ourfali" 
> Cc: "devel" 
> Sent: Wednesday, May 4, 2016 10:27:51 AM
> Subject: Re: [ovirt-devel] Master ovirt-engine build broken
> 
> 
> 
> On Wed, May 4, 2016 at 10:24 AM, Oved Ourfali < oourf...@redhat.com > wrote:
> 
> 
> 
> Roman - did you build the langs in order to find the issue?
> 
> I just ran 'mvn clean verify', so I saw it on my machine. On gerrit not all
> of my builds showed that error.
> 
> Looking at
> 
> https://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:integration
> 
> two patches passed and two failed after a topic rebase.
> 
> 
> 
> Eyal - can we monitor a list of files that i changed will result in also
> building all the languages?
> 
> 
> 
> 
> 
> 
> On Wed, May 4, 2016 at 11:22 AM, Eyal Edri < ee...@redhat.com > wrote:
> 
> 
> 
> right, and we can't enable lang permutation since it takes a very long time
> to run.
> 
> On Wed, May 4, 2016 at 11:07 AM, Tomas Jelinek < tjeli...@redhat.com > wrote:
> 
> 
> 
> 
> - Original Message -
> > From: "Oved Ourfali" < oourf...@redhat.com >
> > To: "Tomas Jelinek" < tjeli...@redhat.com >
> > Cc: "Roman Mohr" < rm...@redhat.com >, "devel" < devel@ovirt.org >, "Scott
> > Dickerson" < sdick...@redhat.com >
> > Sent: Wednesday, May 4, 2016 9:55:40 AM
> > Subject: Re: [ovirt-devel] Master ovirt-engine build broken
> > 
> > I wonder, how come the CI didn't catch that?
> 
> because this happens only when you compile with language permutations
> 
> > 
> > On Wed, May 4, 2016 at 10:44 AM, Tomas Jelinek < tjeli...@redhat.com >
> > wrote:
> > 
> > > hmmm,
> > > regression introduced yesterday by https://gerrit.ovirt.org/#/c/56720/
> > > fix on the way
> > > 
> > > - Original Message -
> > > > From: "Roman Mohr" < rm...@redhat.com >
> > > > To: "devel" < devel@ovirt.org >
> > > > Sent: Wednesday, May 4, 2016 9:34:53 AM
> > > > Subject: [ovirt-devel] Master ovirt-engine build broken
> > > > 
> > > > Hi,
> > > > 
> > > > I see failing tests regarding to missing translations (e.g. [1]).
> > > > 
> > > > [...]
> > > > 
> > > > Failed tests: doTest(org.ovirt.engine.ui.uicompat.UIMessagesTest):
> > > > cpuInfoLabel does not match the number of parameters in
> > > > UIMessages_zh_CN.properties(..)
> > > > 
> > > > [...]
> > > > 
> > > > Best Regards,
> > > > 
> > > > Roman
> > > > 
> > > > [1]
> > > > 
> > > http://jenkins.ovirt.org/job/ovirt-engine_master_check-patch-fc23-x86_64/407/console
> > > > 
> > > > ___
> > > > 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
> 
> 
> 
> 
> 
> --
> Eyal Edri
> Associate Manager
> RHEV DevOps
> EMEA ENG Virtualization R&D
> Red Hat Israel
> 
> phone: +972-9-7692018
> irc: eedri (on #tlv #rhev-dev #rhev-integ)
> 
> 
> ___
> 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 mail

Re: [ovirt-devel] UI plugins - access to engine styles and libraries

[Vojtech Szocs]

- Original Message -
> From: "Greg Sheremeta" 
> To: "Vojtech Szocs" 
> Cc: "Martin Sivak" , "Alexander Wels" , 
> "engine-de...@ovirt.org"
> 
> Sent: Wednesday, April 20, 2016 8:20:11 PM
> Subject: Re: [ovirt-devel] UI plugins - access to engine styles and libraries
> 
> On Wed, Apr 20, 2016 at 1:52 PM, Vojtech Szocs  wrote:
> 
> >
> >
> > - Original Message -
> > > From: "Greg Sheremeta" 
> > > To: "Vojtech Szocs" 
> > > Cc: "Martin Sivak" , "Alexander Wels" <
> > aw...@redhat.com>, "engine-de...@ovirt.org"
> > > 
> > > Sent: Wednesday, April 20, 2016 7:06:13 PM
> > > Subject: Re: [ovirt-devel] UI plugins - access to engine styles and
> > libraries
> > >
> > > On Wed, Apr 20, 2016 at 12:51 PM, Vojtech Szocs 
> > wrote:
> > >
> > > >
> > > >
> > > > - Original Message -
> > > > > From: "Martin Sivak" 
> > > > > To: "Vojtech Szocs" 
> > > > > Cc: "Greg Sheremeta" , "Alexander Wels" <
> > > > aw...@redhat.com>, "engine-de...@ovirt.org"
> > > > > 
> > > > > Sent: Tuesday, April 19, 2016 5:07:52 PM
> > > > > Subject: Re: [ovirt-devel] UI plugins - access to engine styles and
> > > > libraries
> > > > >
> > > > > > With this (static linking) approach, you don't need those CSS
> > > > > > or JS resources at runtime; your webapp is self-contained and
> > > > > > optimized (containing only stuff it really uses).
> > > > >
> > > > > Right, but I won't get the same look and feel as the styles might be
> > > > > different.
> > > >
> > > > If `ovirt.brand` is RPM-packaged, you could depend on it
> > > > when building your webapp (UI plugin), but I don't think
> > > > we have such RPM.
> > > >
> > > > > I was looking for a way to use the same colors and styles
> > > > > to make the UI plugin look right in both RHEV and oVirt.
> > > >
> > > > Understood, just use the URL that exposes branding files,
> > > > it's perfectly fine to load CSS and other stuff at runtime.
> > > >
> > >
> > > But much of the CSS is obfuscated by GWT. There's no way to hook into it.
> >
> > That's correct.
> >
> > All I wanted to say is that we have some base CSS files
> > (see "webadmin_css" in ovirt.brand/branding.properties)
> > and some of them could be of use to Martin. For example,
> > vanilla PatternFly CSS:
> >
> > - patternfly/css/styles.min.css
> > - patternfly-ovirt.css
> >
> > >
> > > My idea is completely different. I wanted to stop using GWT for all CSS,
> > > and instead use LESS or SASS. Then any plugins could simply use the
> > > LESS/SASS files as needed.
> >
> > I like that idea.
> >
> > In general, we should extract *all* styling (including
> >  in ui.xml templates) into separate CSS files
> >
> 
> Yes.
> 
> 
> > and access that through appropriate Java interfaces in
> > our GWT applications.
> >
> 
> What do you see as the benefit of continuing to wrap CSS classes in Java
> interfaces? We could just stop doing that, too. I don't think it buys us
> much. I see it as just more code to maintain for no good reason. When we
> access PatternFly classes, we just hardcode the strings. I think that's
> pretty typical with CSS, and ok.

GWT is centered around the Java language, providing (Java)
abstraction for everything that relates to web technologies.

There's an abstraction for DOM elements, widgets (on top of
DOM elements), web APIs (such as local storage), etc. etc.

GWT's CssResource interface is the standard way of working
with CSS. GWT's ClientBundle interface is the standard way
of grouping all webapp's resources (CSS, images etc.) into
resource "bundle" that gets optimized during compilation.

That said, I understand your point and I agree that having
a Java interface for every CSS file is extra maintenance.

If we agree we don't need GWT compiler's CSS optimization
(because we'll use Less/Sass anyway), we can completely
remove all CssResource interfaces and simply have some
Java class to contain string constants referring to CSS
class names.

  // in Java code
  myWidget.addStyleName(CssClassNames.FO

Re: [ovirt-devel] UI plugins - access to engine styles and libraries

[Vojtech Szocs]

- Original Message -
> From: "Greg Sheremeta" 
> To: "Vojtech Szocs" 
> Cc: "Martin Sivak" , "Alexander Wels" , 
> "engine-de...@ovirt.org"
> 
> Sent: Wednesday, April 20, 2016 7:06:13 PM
> Subject: Re: [ovirt-devel] UI plugins - access to engine styles and libraries
> 
> On Wed, Apr 20, 2016 at 12:51 PM, Vojtech Szocs  wrote:
> 
> >
> >
> > - Original Message -
> > > From: "Martin Sivak" 
> > > To: "Vojtech Szocs" 
> > > Cc: "Greg Sheremeta" , "Alexander Wels" <
> > aw...@redhat.com>, "engine-de...@ovirt.org"
> > > 
> > > Sent: Tuesday, April 19, 2016 5:07:52 PM
> > > Subject: Re: [ovirt-devel] UI plugins - access to engine styles and
> > libraries
> > >
> > > > With this (static linking) approach, you don't need those CSS
> > > > or JS resources at runtime; your webapp is self-contained and
> > > > optimized (containing only stuff it really uses).
> > >
> > > Right, but I won't get the same look and feel as the styles might be
> > > different.
> >
> > If `ovirt.brand` is RPM-packaged, you could depend on it
> > when building your webapp (UI plugin), but I don't think
> > we have such RPM.
> >
> > > I was looking for a way to use the same colors and styles
> > > to make the UI plugin look right in both RHEV and oVirt.
> >
> > Understood, just use the URL that exposes branding files,
> > it's perfectly fine to load CSS and other stuff at runtime.
> >
> 
> But much of the CSS is obfuscated by GWT. There's no way to hook into it.

That's correct.

All I wanted to say is that we have some base CSS files
(see "webadmin_css" in ovirt.brand/branding.properties)
and some of them could be of use to Martin. For example,
vanilla PatternFly CSS:

- patternfly/css/styles.min.css
- patternfly-ovirt.css

> 
> My idea is completely different. I wanted to stop using GWT for all CSS,
> and instead use LESS or SASS. Then any plugins could simply use the
> LESS/SASS files as needed.

I like that idea.

In general, we should extract *all* styling (including
 in ui.xml templates) into separate CSS files
and access that through appropriate Java interfaces in
our GWT applications.

There should be no CSS styling outside of 'css' files.

The GWT build would involve an extra step, if needed:
take Less/Sass files and compile them into CSS files.

GWT Java interfaces would link to these CSS files and
GWT compiler could still do its obfuscate/minification
thing. We *could* disable CSS selector obfuscation if
we wanted to, using "@external" as we do for branding.

However, the main point is because we'd already have
CSS styling isolated into dedicated files, we could
simply expose those CSS files via HTTP/servlet.

So assuming we have everything in CSS files:

  interface MyCss extends CssResource {
String className();
  }

  interface MyResources extends ClientBundle {
@Source("my.css")
MyCss css();
  }

  // inside ui.xml template
  
  

(Note that  above is empty on purpose.)

> 
> There's no way that could make 4.0 now, though.
> 
> 
> >
> > >
> > > Martin
> > >
> > > On Fri, Apr 15, 2016 at 5:37 PM, Vojtech Szocs 
> > wrote:
> > > >
> > > >
> > > > - Original Message -
> > > >> From: "Vojtech Szocs" 
> > > >> To: "Martin Sivak" , "Greg Sheremeta"
> > > >> , "Alexander Wels" 
> > > >> Cc: "engine-de...@ovirt.org" 
> > > >> Sent: Friday, April 15, 2016 5:23:08 PM
> > > >> Subject: Re: [ovirt-devel] UI plugins - access to engine styles and
> > > >> libraries
> > > >>
> > > >> Hi Martin,
> > > >>
> > > >> (adding Greg and Alex in case they have any thoughts)
> > > >>
> > > >> if you build your UI plugin in a way that requires CSS styles,
> > > >> JS libraries etc. at runtime (dynamic linking), you can utilize
> > > >> oVirt branding servlet [a] to serve branding-related resources.
> > > >
> > > > Just a note - another way of building your UI plugin is to use
> > > > tools that take your CSS styles and JS sources (including 3rd
> > > > party ones) and produce a self-contained bundle for deployment.
> > > >
> > > > oVirt Dashboard, for example, follows this approach:
> > > >
> > > >   h

Re: [ovirt-devel] UI plugins - access to engine styles and libraries

[Vojtech Szocs]

- Original Message -
> From: "Martin Sivak" 
> To: "Vojtech Szocs" 
> Cc: "Greg Sheremeta" , "Alexander Wels" 
> , "engine-de...@ovirt.org"
> 
> Sent: Tuesday, April 19, 2016 5:07:52 PM
> Subject: Re: [ovirt-devel] UI plugins - access to engine styles and libraries
> 
> > With this (static linking) approach, you don't need those CSS
> > or JS resources at runtime; your webapp is self-contained and
> > optimized (containing only stuff it really uses).
> 
> Right, but I won't get the same look and feel as the styles might be
> different.

If `ovirt.brand` is RPM-packaged, you could depend on it
when building your webapp (UI plugin), but I don't think
we have such RPM.

> I was looking for a way to use the same colors and styles
> to make the UI plugin look right in both RHEV and oVirt.

Understood, just use the URL that exposes branding files,
it's perfectly fine to load CSS and other stuff at runtime.

> 
> Martin
> 
> On Fri, Apr 15, 2016 at 5:37 PM, Vojtech Szocs  wrote:
> >
> >
> > - Original Message -
> >> From: "Vojtech Szocs" 
> >> To: "Martin Sivak" , "Greg Sheremeta"
> >> , "Alexander Wels" 
> >> Cc: "engine-de...@ovirt.org" 
> >> Sent: Friday, April 15, 2016 5:23:08 PM
> >> Subject: Re: [ovirt-devel] UI plugins - access to engine styles and
> >> libraries
> >>
> >> Hi Martin,
> >>
> >> (adding Greg and Alex in case they have any thoughts)
> >>
> >> if you build your UI plugin in a way that requires CSS styles,
> >> JS libraries etc. at runtime (dynamic linking), you can utilize
> >> oVirt branding servlet [a] to serve branding-related resources.
> >
> > Just a note - another way of building your UI plugin is to use
> > tools that take your CSS styles and JS sources (including 3rd
> > party ones) and produce a self-contained bundle for deployment.
> >
> > oVirt Dashboard, for example, follows this approach:
> >
> >   https://github.com/vojtechszocs/ovirt-dashboard-ui-plugin
> >
> > (soon, we'll sync it with ovirt-engine-dashboard on our gerrit
> > and continue developing the project there)
> >
> > With this (static linking) approach, you don't need those CSS
> > or JS resources at runtime; your webapp is self-contained and
> > optimized (containing only stuff it really uses).
> >
> > We also have two RPM packages (initiated by Juan) for building
> > (oVirt) webapps that require a JS build step, utilizing tools
> > around the Node.js platform:
> >
> >   ovirt-engine-nodejs [Node.js runtime]
> >   ovirt-engine-nodejs-modules [all frontend dependencies]
> >
> > Regards,
> > Vojtech
> >
> >>
> >>   [a] org.ovirt.engine.core.branding.BrandingServlet
> >>
> >> By default, oVirt Engine ships with single branding package:
> >>
> >>   $ ls /etc/ovirt-engine/branding/
> >>   00-ovirt.brand
> >>
> >> That `00-ovirt.brand` directory symlinks to:
> >>
> >>   /usr/share/ovirt-engine/branding/ovirt.brand
> >>
> >> containing all branding-related resources.
> >>
> >> To fetch them, use the following URL:
> >>
> >>   http://example.com/ovirt-engine/webadmin/theme/
> >>
> >> where  is relative to `ovirt.brand` directory.
> >>
> >> In your UI plugin, you can use the newly introduced API to
> >> construct this URL more easily [b]:
> >>
> >>   var url = api.engineBaseUrl() + 'webadmin/theme/' + pathToFile
> >>
> >>   [b] https://gerrit.ovirt.org/#/c/55694/
> >>
> >> WebAdmin UI itself loads following CSS styles (in this order):
> >>
> >> - web_admin.css
> >> - common.css
> >> - gwt_common.css
> >> - patternfly/css/styles.min.css
> >> - patternfly-ovirt.css
> >> - ovirt-patternfly-compat.css
> >> - ovirt.css
> >>
> >> For starters, you can load PatternFly-specific CSS only.
> >>
> >> As for JS libraries, these are typically provided through
> >> PatternFly RPM, to which `patternfly` directory symlinks.
> >>
> >> For starters, you can use stuff under `patternfly/js` and
> >> `patternfly/components` (these are PF's own dependencies).
> >>
> >> oVirt ships its own version of jQuery (v1.11) + Bootstrap
> >> (v3.3.6) -- please don't use them!! If you're wondering
>

Re: [ovirt-devel] UI plugins - access to engine styles and libraries

[Vojtech Szocs]

- Original Message -
> From: "Greg Sheremeta" 
> To: "Vojtech Szocs" 
> Cc: "Martin Sivak" , "Alexander Wels" , 
> "engine-de...@ovirt.org"
> , "Moran Goldboim" , "Oved Ourfali" 
> 
> Sent: Saturday, April 16, 2016 4:05:56 PM
> Subject: Re: UI plugins - access to engine styles and libraries
> 
> On Fri, Apr 15, 2016 at 11:23 AM, Vojtech Szocs  wrote:
> 
> > Hi Martin,
> >
> > (adding Greg and Alex in case they have any thoughts)
> >
> > if you build your UI plugin in a way that requires CSS styles,
> > JS libraries etc. at runtime (dynamic linking), you can utilize
> > oVirt branding servlet [a] to serve branding-related resources.
> >
> >   [a] org.ovirt.engine.core.branding.BrandingServlet
> >
> > By default, oVirt Engine ships with single branding package:
> >
> >   $ ls /etc/ovirt-engine/branding/
> >   00-ovirt.brand
> >
> > That `00-ovirt.brand` directory symlinks to:
> >
> >   /usr/share/ovirt-engine/branding/ovirt.brand
> >
> > containing all branding-related resources.
> >
> > To fetch them, use the following URL:
> >
> >   http://example.com/ovirt-engine/webadmin/theme/
> >
> > where  is relative to `ovirt.brand` directory.
> >
> > In your UI plugin, you can use the newly introduced API to
> > construct this URL more easily [b]:
> >
> >   var url = api.engineBaseUrl() + 'webadmin/theme/' + pathToFile
> >
> >   [b] https://gerrit.ovirt.org/#/c/55694/
> >
> > WebAdmin UI itself loads following CSS styles (in this order):
> >
> > - web_admin.css
> > - common.css
> > - gwt_common.css
> > - patternfly/css/styles.min.css
> > - patternfly-ovirt.css
> > - ovirt-patternfly-compat.css
> > - ovirt.css
> >
> > For starters, you can load PatternFly-specific CSS only.
> >
> > As for JS libraries, these are typically provided through
> > PatternFly RPM, to which `patternfly` directory symlinks.
> >
> > For starters, you can use stuff under `patternfly/js` and
> > `patternfly/components` (these are PF's own dependencies).
> >
> > oVirt ships its own version of jQuery (v1.11) + Bootstrap
> > (v3.3.6) -- please don't use them!! If you're wondering
> > why we use custom jQuery and Bootstrap, see here:
> >
> >   https://gerrit.ovirt.org/#/c/41228/
> >   https://gerrit.ovirt.org/#/c/55546/
> >
> > (@Greg, any plans for upgrading to PF-provided jQuery?)
> >
> 
> No plans to switch to the libraries that PatternFly provides -- and I'm not
> all that sure we should. We got burned by it, so we moved away from it
> intentionally in [https://gerrit.ovirt.org/#/c/41228/]. Probably best to
> chat about that in another thread.

OK, thanks for the update.

I thought that we're using jQuery 1.x solely for IE8 support.

According to [ms]:

"
Beginning January 12, 2016, only the most current version of
Internet Explorer available for a supported operating system
will receive technical supports and security updates.

Internet Explorer 11 is the last version of Internet Explorer...
"

[ms] https://www.microsoft.com/en-us/WindowsForBusiness/End-of-IE-support

Agreed - let's discuss this separately.

> 
> Greg
> 
> 
> 
> >
> > Regards,
> > Vojtech
> >
> >
> > - Original Message -
> > > From: "Martin Sivak" 
> > > To: "engine-de...@ovirt.org" 
> > > Cc: "Moran Goldboim" , "Vojtech Szocs" <
> > vsz...@redhat.com>, "Oved Ourfali" 
> > > Sent: Wednesday, April 13, 2016 5:30:49 PM
> > > Subject: UI plugins - access to engine styles and libraries
> > >
> > > Hi everybody,
> > >
> > > there is one piece I always missed when developing my optimizer plugin
> > > and that is the access to the engine css styles.
> > >
> > > I feel it might be pretty easy and good for both bandwidth and
> > > branding to expose them using some "well known" url from the engine.
> > > All plugins would be then able to (re-)use the same styling
> > > information and basic javascript libraries (jQuery, angular, whatever
> > > you decide the core engine will use).
> > >
> > > So far, each UI plugin has to link to its own version of libraries and
> > > define (and maintain) custom color theme.
> > >
> > > Do you think this would be doable for 4.0?
> > >
> > > Best regards
> > >
> > > --
> > > Martin Sivak
> > > SLA / oVirt
> > >
> >
> 
> 
> 
> --
> Greg Sheremeta, MBA
> Red Hat, Inc.
> Sr. Software Engineer
> gsher...@redhat.com
> 919-741-4016
> 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] Introducing oVirt Dashboard

[Vojtech Szocs]

Hi everyone,

Alexander and me are working on oVirt Dashboard UI plugin that
gives overview of the virtualized environment and its specific
objects. (See the attached screenshot.)

Development started on GitHub:

  https://github.com/vojtechszocs/ovirt-dashboard-ui-plugin

but now we're moving the project to Gerrit:

  https://gerrit.ovirt.org/#/q/project:ovirt-engine-dashboard

See project's README on how to set it up if you're interested:

  
https://gerrit.ovirt.org/gitweb?p=ovirt-engine-dashboard.git;a=blob;f=README.md;hb=HEAD

Technology-wise, we're planning to utilize newly introduced
RPMs for developing oVirt JavaScript applications:

- ovirt-engine-nodejs # Node.js binaries
- ovirt-engine-nodejs-modules # frontend (npm) dependencies

(these are used only during the build time.)

oVirt Dashboard uses React JS library to implement reusable
components on top of PatternFly (+ jQuery/D3/C3):

  http://facebook.github.io/react/

We're planning to share our React components with others via
"react-patternfly" community project hosted on GitHub:

  https://github.com/jtomasek/react-patternfly/

If you have some spare time, we'd really, really appreciate
current JS code review :-) any feedback is highly welcome.

Regards,
Vojtech
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] New UI plugin API additions

[Vojtech Szocs]

Hi,

in oVirt master / 4.0, following new UI plugin API
functions are now available.

--

engineBaseUrl [1]: can be used to construct Engine
URLs.

Signature:

  engineBaseUrl()

Examples:

  // returns something like:
  //   https://example.com:8443/ovirt-engine/
  api.engineBaseUrl()

[1] https://gerrit.ovirt.org/#/c/55694/

--

showAlert [2]: can be used to show 'global' alert
messages (colored boxes in top-center part of UI).

Signature:

  showAlert(alertTypeName, message, options)

Examples:

  api.showAlert('success', 'Everything is good');

  api.showAlert('danger', 'Something is bad', {
autoHideMs: 3000
  });

[2] https://gerrit.ovirt.org/#/c/55504/

--

Regards,
Vojtech
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] UI plugins - access to engine styles and libraries

[Vojtech Szocs]

- Original Message -
> From: "Vojtech Szocs" 
> To: "Martin Sivak" , "Greg Sheremeta" 
> , "Alexander Wels" 
> Cc: "engine-de...@ovirt.org" 
> Sent: Friday, April 15, 2016 5:23:08 PM
> Subject: Re: [ovirt-devel] UI plugins - access to engine styles and libraries
> 
> Hi Martin,
> 
> (adding Greg and Alex in case they have any thoughts)
> 
> if you build your UI plugin in a way that requires CSS styles,
> JS libraries etc. at runtime (dynamic linking), you can utilize
> oVirt branding servlet [a] to serve branding-related resources.

Just a note - another way of building your UI plugin is to use
tools that take your CSS styles and JS sources (including 3rd
party ones) and produce a self-contained bundle for deployment.

oVirt Dashboard, for example, follows this approach:

  https://github.com/vojtechszocs/ovirt-dashboard-ui-plugin

(soon, we'll sync it with ovirt-engine-dashboard on our gerrit
and continue developing the project there)

With this (static linking) approach, you don't need those CSS
or JS resources at runtime; your webapp is self-contained and
optimized (containing only stuff it really uses).

We also have two RPM packages (initiated by Juan) for building
(oVirt) webapps that require a JS build step, utilizing tools
around the Node.js platform:

  ovirt-engine-nodejs [Node.js runtime]
  ovirt-engine-nodejs-modules [all frontend dependencies]

Regards,
Vojtech

> 
>   [a] org.ovirt.engine.core.branding.BrandingServlet
> 
> By default, oVirt Engine ships with single branding package:
> 
>   $ ls /etc/ovirt-engine/branding/
>   00-ovirt.brand
> 
> That `00-ovirt.brand` directory symlinks to:
> 
>   /usr/share/ovirt-engine/branding/ovirt.brand
> 
> containing all branding-related resources.
> 
> To fetch them, use the following URL:
> 
>   http://example.com/ovirt-engine/webadmin/theme/
> 
> where  is relative to `ovirt.brand` directory.
> 
> In your UI plugin, you can use the newly introduced API to
> construct this URL more easily [b]:
> 
>   var url = api.engineBaseUrl() + 'webadmin/theme/' + pathToFile
> 
>   [b] https://gerrit.ovirt.org/#/c/55694/
> 
> WebAdmin UI itself loads following CSS styles (in this order):
> 
> - web_admin.css
> - common.css
> - gwt_common.css
> - patternfly/css/styles.min.css
> - patternfly-ovirt.css
> - ovirt-patternfly-compat.css
> - ovirt.css
> 
> For starters, you can load PatternFly-specific CSS only.
> 
> As for JS libraries, these are typically provided through
> PatternFly RPM, to which `patternfly` directory symlinks.
> 
> For starters, you can use stuff under `patternfly/js` and
> `patternfly/components` (these are PF's own dependencies).
> 
> oVirt ships its own version of jQuery (v1.11) + Bootstrap
> (v3.3.6) -- please don't use them!! If you're wondering
> why we use custom jQuery and Bootstrap, see here:
> 
>   https://gerrit.ovirt.org/#/c/41228/
>   https://gerrit.ovirt.org/#/c/55546/
> 
> (@Greg, any plans for upgrading to PF-provided jQuery?)
> 
> Regards,
> Vojtech
> 
> 
> - Original Message -
> > From: "Martin Sivak" 
> > To: "engine-de...@ovirt.org" 
> > Cc: "Moran Goldboim" , "Vojtech Szocs"
> > , "Oved Ourfali" 
> > Sent: Wednesday, April 13, 2016 5:30:49 PM
> > Subject: UI plugins - access to engine styles and libraries
> > 
> > Hi everybody,
> > 
> > there is one piece I always missed when developing my optimizer plugin
> > and that is the access to the engine css styles.
> > 
> > I feel it might be pretty easy and good for both bandwidth and
> > branding to expose them using some "well known" url from the engine.
> > All plugins would be then able to (re-)use the same styling
> > information and basic javascript libraries (jQuery, angular, whatever
> > you decide the core engine will use).
> > 
> > So far, each UI plugin has to link to its own version of libraries and
> > define (and maintain) custom color theme.
> > 
> > Do you think this would be doable for 4.0?
> > 
> > Best regards
> > 
> > --
> > 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] UI plugins - access to engine styles and libraries

[Vojtech Szocs]

Hi Martin,

(adding Greg and Alex in case they have any thoughts)

if you build your UI plugin in a way that requires CSS styles,
JS libraries etc. at runtime (dynamic linking), you can utilize
oVirt branding servlet [a] to serve branding-related resources.

  [a] org.ovirt.engine.core.branding.BrandingServlet

By default, oVirt Engine ships with single branding package:

  $ ls /etc/ovirt-engine/branding/
  00-ovirt.brand

That `00-ovirt.brand` directory symlinks to:

  /usr/share/ovirt-engine/branding/ovirt.brand

containing all branding-related resources.

To fetch them, use the following URL:

  http://example.com/ovirt-engine/webadmin/theme/

where  is relative to `ovirt.brand` directory.

In your UI plugin, you can use the newly introduced API to
construct this URL more easily [b]:

  var url = api.engineBaseUrl() + 'webadmin/theme/' + pathToFile

  [b] https://gerrit.ovirt.org/#/c/55694/

WebAdmin UI itself loads following CSS styles (in this order):

- web_admin.css
- common.css
- gwt_common.css
- patternfly/css/styles.min.css
- patternfly-ovirt.css
- ovirt-patternfly-compat.css
- ovirt.css

For starters, you can load PatternFly-specific CSS only.

As for JS libraries, these are typically provided through
PatternFly RPM, to which `patternfly` directory symlinks.

For starters, you can use stuff under `patternfly/js` and
`patternfly/components` (these are PF's own dependencies).

oVirt ships its own version of jQuery (v1.11) + Bootstrap
(v3.3.6) -- please don't use them!! If you're wondering
why we use custom jQuery and Bootstrap, see here:

  https://gerrit.ovirt.org/#/c/41228/
  https://gerrit.ovirt.org/#/c/55546/

(@Greg, any plans for upgrading to PF-provided jQuery?)

Regards,
Vojtech


- Original Message -
> From: "Martin Sivak" 
> To: "engine-de...@ovirt.org" 
> Cc: "Moran Goldboim" , "Vojtech Szocs" 
> , "Oved Ourfali" 
> Sent: Wednesday, April 13, 2016 5:30:49 PM
> Subject: UI plugins - access to engine styles and libraries
> 
> Hi everybody,
> 
> there is one piece I always missed when developing my optimizer plugin
> and that is the access to the engine css styles.
> 
> I feel it might be pretty easy and good for both bandwidth and
> branding to expose them using some "well known" url from the engine.
> All plugins would be then able to (re-)use the same styling
> information and basic javascript libraries (jQuery, angular, whatever
> you decide the core engine will use).
> 
> So far, each UI plugin has to link to its own version of libraries and
> define (and maintain) custom color theme.
> 
> Do you think this would be doable for 4.0?
> 
> Best regards
> 
> --
> Martin Sivak
> SLA / oVirt
> 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] oVirt-specific aspect languages

[Vojtech Szocs]

- Original Message -
> From: "Arik Hadas" 
> To: "Martin Sivak" , "Vojtech Szocs" 
> Cc: "devel" 
> Sent: Wednesday, April 13, 2016 10:58:46 PM
> Subject: Re: [ovirt-devel] oVirt-specific aspect languages
> 
> Hi,
> 
> Thanks for the feedback!
> I commented below.
> 
> - Original Message -
> > Hi all,
> > 
> > I agree that it was an interesting article.
> > 
> > > However, since AspectJ is an extension to Java, most of oVirt
> > > developers would need to know additional programming language
> > > which puts the cost-effectiveness of this approach into question.
> > 
> > Actually you only need to learn some very basic stuff about pointcut
> > definition. The rest was pure Java for anything I ever needed (before,
> > after and around cases).
> > 
> 
> Well, it depends on both the base code and the crosscutting-concerns you
> develop the aspects for I guess.
> From my experience with AspectJ, the very basic stuff there typically fits
> only for very simple crosscutting concerns.
> For example, in the generated aspects for the languages I developed for the
> crosscutting concerns in oVirt I had to use more than the basic stuff (e.g.
> inter-type declarations).
> I'm curios, where did you use AspectJ? For how many and what kind of
> crosscutting concerns did you use it?
> 
> > DSLs are a nice thing to have, and we can start by utilizing object
> > builders more :) Those are a kind of DSL too if nicely written. See
> > the latest email on this list from Roman Mohr that talks about Domain
> > Object Builders (or Spring Security Java configuration [2] to see a
> > more complicated example of how it is used elsewhere).
> > 
> > Martin
> > 
> > [1] http://lists.ovirt.org/pipermail/devel/2016-April/012790.html
> > [2]
> > http://docs.spring.io/spring-security/site/docs/current/reference/html/jc.html
> > 
> > On Mon, Apr 11, 2016 at 4:13 PM, Vojtech Szocs  wrote:
> > > Hi Arik,
> > >
> > > thanks for sharing this, the article is very interesting!
> > >
> > > "
> > > However, since AspectJ is an extension to Java, most of oVirt
> > > developers would need to know additional programming language
> > > which puts the cost-effectiveness of this approach into question.
> > > "
> > >
> > > I always thought that good Java developers should be familiar
> > > with AOP concepts anyway.
> 
> I think that many are familiar with the general AOP concepts but nevertheless
> decide not to adopt them.

I think it comes down to two factors - experience and willingness
to learn given technology. The fact that many people don't use AOP
doesn't imply that AOP isn't appropriate to solve their problems.

In previous company, I've used AOP with GWT to implement "command"
invocation bus between client and server. The client would create
an instance of a command like this:

  @ImplementedBy(DoSomethingWithLogic.class)
  class DoSomething implements Command {

// fields to carry data go here
// getters/setters go here

public MyResult execute() { return null; }

  }

and send it to server for execution. During GWT deserialization
of "DoSomething" instance, an aspect would catch instantiation
of "DoSomething" and replace instantiated instance with this:

  class DoSomethingWithLogic extends DoSomething {

public MyResult execute() {
  // logic that executes on the server
}

  }

Many people thought of this as "hacky", I actually liked it :)

> Many think that AOP is useful only for simple logging and tracing or as a
> simplified API for byte-code manipulation (I guess that's why AspectJ is
> used by GWT in our build process, right?)

GWT compiler is written in Java. It parses your code into AST,
does "live" code analysis, and translates "live" code into JS.

When building oVirt GWT UI, we use AOP to trick GWT compiler
into thinking that all common code (shared between frontend
and backend) is "live", because otherwise it would prune
(cut-away) unused code and it would cause de-serialization
issues back on server.

That aspect can be found here:

  frontend/webadmin/modules/gwt-extension/
src/main/java/org/ovirt/engine/ui/gwtextension/DontPrune.java

(The underlying problem is sharing code between frontend
and backend which couples both sides very tightly, a much
better approach is to have some API like REST in between
the two.)

> or in its simplified form as
> spring-aop, because of the known drawbacks of AspectJ.
> Hopefully the proposed approach would change that :)
> 
> > >
>