Re: [ovirt-devel] Changing the name of VDSM in oVirt 4.0.

2016-02-02 Thread Greg Sheremeta 
On Thu, Jan 28, 2016 at 9:57 AM, Michal Skrivanek
 wrote:
>
> On 26 Jan 2016, at 19:13, Oved Ourfali  wrote:
>
> I must agree with Martin here.
> In addition, I think the benefit here is low, and the efforts it will
> require and the risks are high. Upgrade issues? Compatibility ones? Effect
> on engine features such as host upgrade manager, different provisioning
> products that might rely on that such as puppet recipes, ansible modules, or
> others..
> (can't say all mentioned stuff are relevant, and I guess there might be more
> implications than I've described).
>
> IMHO, we should spend our time improving our project rather than spend a lot
> of developers, testers and integration people on these kind of tasks.
>
>
> +1
> I like vdsm.
> any variant with “agent” brings confusion with guest agent (let alone the
> fact we have three of them)

Oved has a point, but all native English speakers will agree that "vdsm" is
a bad (i.e. almost inappropriate) name.

I think it should be changed for that reason alone.

It's unfortunate that the name "ovirt-agent" is already taken.

Greg


>
> In addition, bootstrapping of hosts doesn't require manual installation of
> VDSM, and as of 3.6 neither does upgrade, so most users shouldn't know and
> care what VDSM is.
>
> Regards,
> Oved
>
> On Jan 26, 2016 7:00 PM, "Martin Sivak"  wrote:
>>
>> Hi,
>>
>> name change might be considered, but I do not think it will make a big
>> difference. People do not see vdsm too often (installed by host
>> deploy, managed by engine..).
>>
>>
>> But trying to make sure that (all?) component versions in a project
>> are the same is not a good idea if you ask me. You are not going to
>> rebuild everything when a hot fix is needed, but granted, you might
>> use minor numbers so the versions will at least start with the same
>> numbers. Or will we force a version bump and rebuild to unchanged
>> component, when others were updated for a given release? (we have
>> components like that - ovirt-scheduler-proxy for example)
>>
>> Engine does not depend on an exact vdsm version, we have gradual
>> feature degradation built in in form of capabilities, machine type and
>> cluster levels so it should be totally up to the user what version of
>> vdsm is used. The same we do not control libvirt or kernel. Some of
>> the components (at least on my side) are completely usable without
>> oVirt and when oVirt is released it just gets the latest stable bits
>> available.
>>
>> Why don't we treat oVirt as a package distribution it is? The long
>> term plan still is to break the monoliths (like vdsm or engine) and
>> the possibly new teams (or community) might have different needs.. we
>> might even want to promote reuse of some of the components (like [2])
>> in oVirt unrelated way and I would really love to see that kind of
>> adoption. We are trying to keep so much control that we are an open
>> project, but not a community one (where the community can influence
>> future plans, release schedules, workflows or processes).
>>
>> Neither Fedora, nor RHEL (Debian, ..) try to control the version of
>> components. They depend purely on package dependencies and separate
>> component development from distribution compose processes (something
>> we lack..). Even OpenStack abandoned the unified versioning last year
>> (at least partially) [1]. We decided to use similar age based
>> versioning like described in [1] when I was still part of the Anaconda
>> team and it worked perfectly fine.
>>
>> I really wish we would loosen the project coupling (and processes)
>> instead of tightening it. Sadly everything we have done lately is
>> going in the tightening direction...
>>
>>
>>
>> TL;DR: Please let us use whatever versions of packages we want,
>> release as often as we want and just take the latest bits to compose
>> the oVirt distribution. Most of the components we have handle that
>> just fine.
>>
>> [1] OpenStack versioning plans: http://ttx.re/new-versioning.html (and
>> please pay particular attention to the last section and especially the
>> last two paragraphs in it)
>> [2] There was a thread about vdsm RPMs being too granular:
>> http://lists.ovirt.org/pipermail/devel/2016-January/012185.html
>>
>> --
>> Martin Sivak
>> oVirt / SLA
>> ___
>> 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



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

Re: [ovirt-devel] outdated quickstart guide

2016-02-02 Thread Amit Aviram 
Anyway, if you are installing a dev env, you should follow this wiki page,
rather than the quickstart page:
http://www.ovirt.org/OVirt_Engine_Development_Environment

On Wed, Feb 3, 2016 at 5:27 AM, Greg Sheremeta  wrote:

> Trying to go through this with a new hire, and there doesn't seem to
> be a version matrix anywhere.
>
> We're just guessing at which OSes are supported for both engine and hosts.
>
> Is that information handy somewhere?
>
> Greg
>
>
> On Sat, Jan 30, 2016 at 5:48 PM, Yaniv Kaul  wrote:
> >
> >
> > On Fri, Jan 29, 2016 at 5:35 PM, Sven Kieske 
> wrote:
> >>
> >> On 29/01/16 16:17, Nir Soffer wrote:
> >> > This is a wiki, you can update it.
> >> yes I know, i even have an account, but just no time atm.
> >> so I figured maybe someone can do it quicker.
> >
> >
> > Note that we are moving away from the Wiki to the new website soon.
> > I suggest updating it there[1]
> >
> > Y.
> > [1] https://github.com/oVirt/ovirt-site
> >
> >
> >>
> >>
> >> I also noticed that el 7.2  does not get mentioned as a supported
> >> platform, just 7.1.
> >>
> >> I will edit all places when I find the time, maybe next week :)
> >>
> >> --
> >> 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
>
>
>
> --
> 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
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] outdated quickstart guide

2016-02-02 Thread Yedidyah Bar David 
On Wed, Feb 3, 2016 at 5:27 AM, Greg Sheremeta  wrote:
> Trying to go through this with a new hire, and there doesn't seem to
> be a version matrix anywhere.
>
> We're just guessing at which OSes are supported for both engine and hosts.
>
> Is that information handy somewhere?

AFAIK the "official" place is the release notes page for the version you
intend to install. [1] [2] [3] [4]

All 3.6.N versions support el7 for the engine and hosts, and all of them
support el6 for the engine and can work with el6 hosts installed by 3.5
(in 3.5 cluster compatibility level).

3.6(.0) supported also fedora 22. Since it's considered old and quickly
approaching EOL, it's not mentioned anymore in 3.6.1 and 3.6.2. We still
do builds for it in both official latest 3.6 (currently 3.6.2) and in
3.6-snapshot [5]. I am not aware of actual problems on it.

We recently merged some patches for the engine on fedora 23,
and are aware of at least one bug for hosts on it [6] (with a simple
workaround). So a later 3.6 (3.6.3?) might support it too.

[1] http://www.ovirt.org/OVirt_3.6_Release_Notes
[2] http://www.ovirt.org/OVirt_3.6.1_Release_Notes
[3] http://www.ovirt.org/OVirt_3.6.2_Release_Notes
[4] http://www.ovirt.org/OVirt_3.6.z_Release_Management
[5] http://www.ovirt.org/Install_nightly_snapshot
[6] https://bugzilla.redhat.com/show_bug.cgi?id=1297835

>
> Greg
>
>
> On Sat, Jan 30, 2016 at 5:48 PM, Yaniv Kaul  wrote:
>>
>>
>> On Fri, Jan 29, 2016 at 5:35 PM, Sven Kieske  wrote:
>>>
>>> On 29/01/16 16:17, Nir Soffer wrote:
>>> > This is a wiki, you can update it.
>>> yes I know, i even have an account, but just no time atm.
>>> so I figured maybe someone can do it quicker.
>>
>>
>> Note that we are moving away from the Wiki to the new website soon.
>> I suggest updating it there[1]
>>
>> Y.
>> [1] https://github.com/oVirt/ovirt-site
>>
>>
>>>
>>>
>>> I also noticed that el 7.2  does not get mentioned as a supported
>>> platform, just 7.1.
>>>
>>> I will edit all places when I find the time, maybe next week :)
>>>
>>> --
>>> 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
>
>
>
> --
> 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



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

Re: [ovirt-devel] Hello and A Question about oVirt

2016-02-02 Thread Michal Skrivanek 

> On 02 Feb 2016, at 10:40, Yaniv Dary  wrote:
> 
> I don't think we have a option like this. Michal?
> 
> 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 Mon, Feb 1, 2016 at 5:16 AM, zhukaijie  > wrote:
> Hello, now I have defined a custom property named 'A' in oVirt Engine. 
> Administrator is responsible for entering the value (and arbitrary string ) 
> of 'A' before starting the VM. After an users trys to start the VM in oVirt, 
> VDSM will add the value of 'A' in the qemu:arg of libvirt domain xml, so that 
> the value of 'A' will be added into the QEMU Cmd as a param. However, just 
> like the password of VNC or SPICE, I want to hide the value of 'A' in '*' 
> format in both Libvirt domain xml and QEMU Cmd, So could you please tell me 
> how to achieve it? Thank you very much and happy 2016.

No, I don’t think you would be able to make libvirt and qemu to hide it. 
Unfortunately it would be exposed…for log files you are protected by file 
access permissions, but if there is anything sensitive on the command line and 
you have a user who can get a shell on that machine one can always see that in 
process listing

do you perhaps need to pass some secret to a VM? Might be better via payload, 
it can be accessed in the guest as a file then.

Thanks,
michal

> ___
> 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] Hello and A Question about oVirt

2016-02-02 Thread Yaniv Dary 
I don't think we have a option like this. Michal?

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 Mon, Feb 1, 2016 at 5:16 AM, zhukaijie  wrote:

> Hello, now I have defined a custom property named 'A' in oVirt Engine.
> Administrator is responsible for entering the value (and arbitrary string )
> of 'A' before starting the VM. After an users trys to start the VM in
> oVirt, VDSM will add the value of 'A' in the qemu:arg of libvirt domain
> xml, so that the value of 'A' will be added into the QEMU Cmd as a param.
> However, just like the password of VNC or SPICE, I want to hide the value
> of 'A' in '*' format in both Libvirt domain xml and QEMU Cmd, So could you
> please tell me how to achieve it? Thank you very much and happy 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] Debian porting

2016-02-02 Thread lucas castro 
I take a time for analyzing all that was told,
I think I can't say anything before my first try running it on debian.
Maybe I do it on weekend but I'll pay attention about everything had been
said.

On Mon, Feb 1, 2016 at 10:09 AM, Milan Zamazal  wrote:

> Nir Soffer  writes:
>
> > If you must avoid /rhev/data-center, move it to /run/vdsm/data-center,
> > but note that future version of vdsm may move it to /run/vdsm/storage,
> > or another location, so old debain code will not be compatible with
> > new debian code :-)
> >
> > It would be easier to support vdsm if the runtime configuration is the
> > same on all platforms.
>
> Thank you for explanation of the issue.  I think we can go with
> /run/vdsm/data-center for now.  There's no hurry about final decision,
> it would be nice to have the upstream decision about the future location
> before the next Debian freeze, which is going to happen sometimes in
> fall.
>



-- 
contatos:
Celular: ( 99 ) 99143-5954 - Vivo
skype: lucasd3castro
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] sync meeting - Vdsm 2.2

2016-02-02 Thread Nir Soffer 
On Tue, Feb 2, 2016 at 6:19 PM, Dan Kenigsberg  wrote:
> (nir, piotr, danken)
>
> - splitting supervdsmServer:
>   I think that its a good idea, and that https://gerrit.ovirt.org/#/c/52875/ 
> is a good start.
>   It would give a nice separation of responsibility, and may serve as a
>   "teaser" for how Vdsm's public API can be broken apart.
>
>   Nir is worried that it would introduce instability for no immediate gain,
>   while distracting us from solving the supervdsmServer memory leak, or
>   possible security concens

Or other stuff like porting to python 3.

I'll leave the decision about this to Piotr.

> - schema conversion: Piotr presented his https://gerrit.ovirt.org/#/c/52864/
>   which would convert the json-based schema into a cleaner yaml-based one,
>   which would be easier to version, validate, and obsolete.
>
> - Nir was unhappy with recent changes to the contrib client:
>   
> https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:jsonrpc-client
>   would prefer using standard stomp client

I'm ok, with switching to our jsonrpc library. I'm not happy about the
additional
changes - the client was kind of rewritten from scratch.

> - name discussion is stalling. some people are worried that a rename may
>   turn out to be expensive (release engineering, outher packages,
>   interal module and function name). Still, it would be fun to foresake
>   the non-pronounceable name "vdsm". ovirt-hostd seems like a front
>   runner at the moment.

We also discussed the username - if we change the project name and the
executables
we probably want to change the vdsm user to something else (ovirt?).

This may be a problem with existing file storage, using vdsm:kvm. I would like
to avoid such changes.

> - Nir has advocated trying to use https://trello.com/b/U3lsbVRU/maintenance to
>   maintain the list of our pending tasks. Let's try.
>
> Ciao!
> ___
> 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 UI now supports GWT Super Dev Mode

2016-02-02 Thread Vojtech Szocs 


- Original Message -
> From: "Eli Mesika" 
> To: "Vojtech Szocs" 
> Cc: "devel" 
> Sent: Tuesday, February 2, 2016 2:53:34 PM
> Subject: Re: [ovirt-devel] oVirt UI now supports GWT Super Dev Mode
> 
> 
> 
> - Original Message -
> > From: "Vojtech Szocs" 
> > To: "devel" 
> > Sent: Monday, February 1, 2016 8:46:51 PM
> > Subject: [ovirt-devel] oVirt UI now supports GWT Super Dev Mode
> > 
> > Hi everyone,
> > 
> > in ovirt-engine master branch, it's now possible [1] to use GWT Super
> > Dev Mode [2] to debug oVirt web applications (WebAdmin, UserPortal):
> > 
> > [1] https://gerrit.ovirt.org/#/c/50742/
> > [2] http://www.gwtproject.org/articles/superdevmode.html
> > 
> > Please refer to commit msg [1] for details on GWT Super Dev Mode.
> 
> First of all Kudos

Thanks!

> I think that the steps explaining how to use that should appear also in
> README.developer file

These steps should be already there:

  https://gerrit.ovirt.org/#/c/50742/10/README.developer

it's basically like this:

  - use DEV_BUILD_GWT_SUPER_DEV_MODE=1 when running make install-dev
  - use DEV_BUILD_GWT_SUPER_DEV_MODE=1 when running make gwt-debug
  - visit http://127.0.0.1:9876/ and bookmark "Dev Mode On" script
  - open GWT app (without ?gwt.codesvr=..) and click "Dev Mode On"

I'll update the "Frontend Debug" docs accordingly, I promise :-)

> 
> > 
> > In general, SDM is good for "iterative" development when one changes
> > UI code and wants to see the change reflected in browser very quickly
> > (compared to existing GWT debug mechanism, aka Classic Dev Mode).
> > 
> > On the other hand, SDM does *not* allow using Java IDE to debug UI
> > code, so one has to rely on browser's JavaScript developer tools.
> > 
> > Existing (Java IDE based) debug mechanism still works as expected,
> > the Super Dev Mode is just an alternative.
> > 
> > Note on SDM usage by Scott: it's almost easier to run in Chrome's
> > incognito mode so cached JS and mapped sources aren't an issue.
> > 
> > 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] sync meeting - Vdsm 2.2

2016-02-02 Thread Dan Kenigsberg 
(nir, piotr, danken)

- splitting supervdsmServer:
  I think that its a good idea, and that https://gerrit.ovirt.org/#/c/52875/ is 
a good start.
  It would give a nice separation of responsibility, and may serve as a
  "teaser" for how Vdsm's public API can be broken apart.

  Nir is worried that it would introduce instability for no immediate gain,
  while distracting us from solving the supervdsmServer memory leak, or
  possible security concens

- schema conversion: Piotr presented his https://gerrit.ovirt.org/#/c/52864/
  which would convert the json-based schema into a cleaner yaml-based one,
  which would be easier to version, validate, and obsolete.

- Nir was unhappy with recent changes to the contrib client:
  
https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:jsonrpc-client
  would prefer using standard stomp client

- name discussion is stalling. some people are worried that a rename may
  turn out to be expensive (release engineering, outher packages,
  interal module and function name). Still, it would be fun to foresake
  the non-pronounceable name "vdsm". ovirt-hostd seems like a front
  runner at the moment.

- Nir has advocated trying to use https://trello.com/b/U3lsbVRU/maintenance to
  maintain the list of our pending tasks. Let's try.

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

Re: [ovirt-devel] cpu profile permission error while editing/creating vm

2016-02-02 Thread Greg Sheremeta 
Do you have an open BZ on this?

If not, there should be one :) Lmk and I will open it.

Greg


On Wed, Jan 13, 2016 at 8:55 AM, Tomer Saban  wrote:
> Hi,
>
> If you get an error message like the following while editing/creating VM:
> """
> User doesn't have permissions to assign the cpu profile ASFDS with id 
> 3c990c63-8078-4916-bf18-f38596232a5a to VMs.
> """
>
> Go to Clusters->choose your cluster-> cpu profiles in the subtab-> choose the 
> any cpu profile-> click add in the right frame and add permission for your 
> user with role "CpuProfileCreator".
>
> Thanks,
> Tomer
>
> ___
> 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
919-741-4016
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] outdated quickstart guide

2016-02-02 Thread Greg Sheremeta 
Trying to go through this with a new hire, and there doesn't seem to
be a version matrix anywhere.

We're just guessing at which OSes are supported for both engine and hosts.

Is that information handy somewhere?

Greg


On Sat, Jan 30, 2016 at 5:48 PM, Yaniv Kaul  wrote:
>
>
> On Fri, Jan 29, 2016 at 5:35 PM, Sven Kieske  wrote:
>>
>> On 29/01/16 16:17, Nir Soffer wrote:
>> > This is a wiki, you can update it.
>> yes I know, i even have an account, but just no time atm.
>> so I figured maybe someone can do it quicker.
>
>
> Note that we are moving away from the Wiki to the new website soon.
> I suggest updating it there[1]
>
> Y.
> [1] https://github.com/oVirt/ovirt-site
>
>
>>
>>
>> I also noticed that el 7.2  does not get mentioned as a supported
>> platform, just 7.1.
>>
>> I will edit all places when I find the time, maybe next week :)
>>
>> --
>> 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



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

Re: [ovirt-devel] oVirt UI now supports GWT Super Dev Mode

2016-02-02 Thread Eli Mesika 


- Original Message -
> From: "Vojtech Szocs" 
> To: "devel" 
> Sent: Monday, February 1, 2016 8:46:51 PM
> Subject: [ovirt-devel] oVirt UI now supports GWT Super Dev Mode
> 
> Hi everyone,
> 
> in ovirt-engine master branch, it's now possible [1] to use GWT Super
> Dev Mode [2] to debug oVirt web applications (WebAdmin, UserPortal):
> 
> [1] https://gerrit.ovirt.org/#/c/50742/
> [2] http://www.gwtproject.org/articles/superdevmode.html
> 
> Please refer to commit msg [1] for details on GWT Super Dev Mode.

First of all Kudos 
I think that the steps explaining how to use that should appear also in 
README.developer file 

> 
> In general, SDM is good for "iterative" development when one changes
> UI code and wants to see the change reflected in browser very quickly
> (compared to existing GWT debug mechanism, aka Classic Dev Mode).
> 
> On the other hand, SDM does *not* allow using Java IDE to debug UI
> code, so one has to rely on browser's JavaScript developer tools.
> 
> Existing (Java IDE based) debug mechanism still works as expected,
> the Super Dev Mode is just an alternative.
> 
> Note on SDM usage by Scott: it's almost easier to run in Chrome's
> incognito mode so cached JS and mapped sources aren't an issue.
> 
> 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