From jenkins at ovirt.org  Sun Dec  1 00:03:34 2013
From: jenkins at ovirt.org (Jenkins ci oVirt Server)
Date: Sun, 1 Dec 2013 00:03:34 +0000 (GMT)
Subject: [Engine-devel] [oVirt jenkins] Weekly report on open tasks for
	ovirt-engine
Message-ID: <925402032.5306.1385856226434.JavaMail.jenkins@jenkins.ovirt.org>

An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20131201/ee67ff38/attachment.html>

From mkolesni at redhat.com  Sun Dec  1 06:08:42 2013
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Sun, 1 Dec 2013 01:08:42 -0500 (EST)
Subject: [Engine-devel] Using config values
In-Reply-To: <52984D48.1070009@redhat.com>
References: <52984D48.1070009@redhat.com>
Message-ID: <1643824061.43195741.1385878122949.JavaMail.root@redhat.com>

----- Original Message -----

> Hi All,
Hi Kanagaraj, 

> The are some issues arising in configurations whenever we move up on the
> versions(3.3 => 3.4), because of the way we store and interpret them.

> Whenever there is a new cluster level, you will need to add a new entry for
> all(most) of the configuration. Mostly a copy paste if you see from 3.2 to
> 3.3, except some CPU/PM type related configurations.
> Better option would be to have the defaul config value in ConfigValues.java
> and the overrides will go to config.sql. In this approach you don't need a
> new entries to config.sql when there is a new cluster level.

> Lets take an exmaple, "SupportForceCreateVG" - This is supported from 3.1
> onwards,

> If you look at config.sql, you will see following entries
> select fn_db_add_config_value('SupportForceCreateVG','false','3.0');
> select fn_db_add_config_value('SupportForceCreateVG','true','3.1');
> select fn_db_add_config_value('SupportForceCreateVG','true','3.2');
> select fn_db_add_config_value('SupportForceCreateVG','true','3.3');

> And in ConfigValues.java

> @TypeConverterAttribute(Boolean.class)
> @DefaultValueAttribute("false")
> SupportForceCreateVG,

> Now if there is 3.4 and 3.5, the user needs to add 2 more entries, which i
> feel is redundant.

> Instead we can make

> @TypeConverterAttribute(Boolean.class)
> @DefaultValueAttribute("true")
> SupportForceCreateVG,

> and have only the following in config.sql
> select fn_db_add_config_value('SupportForceCreateVG','false','3.0');

> if a particular value(for a specific cluster level) is not found in
> Config.sql, the fallback is to use the value available in ConfigValues.java.
This has already been implemented, there are many "feature supported" configurations working like this (for example GlusterSupport). 

I think a more interesting approach would be to move these out of the DB since these values don't really hav e a reson to be there. 
Since the entire thing is abstracted by "Gluster/FeatureSupported" classes then we can easily change mechanism (of course whatever code is not using it can be easily converted to use the mechanism) 

For example a simple enum could do the trick: 
------------------------------------- EXAMPLE ------------------------------------- 
/** 
* Convenience class to check if a gluster feature is supported or not in any given version.<br> 
* Methods should be named by feature and accept version to check against. 
*/ 
public class GlusterFeatureSupported { 
/** 
* @param version 
* Compatibility version to check for. 
* @return <code>true</code> if gluster support is enabled, <code>false</code> if it's not. 
*/ 
public static boolean gluster(Version version) { 
return SupportedFeatures.GLUSTER.isSupportedOn(version); 
} 

/** 
* @param version 
* Compatibility version to check for. 
* @return <code>true</code> if gluster heavyweight refresh is enabled, <code>false</code> if it's not. 
*/ 
public static boolean refreshHeavyWeight(Version version) { 
return SupportedFeatures.REFRESH_HEAVYWEIGHT.isSupportedOn(version); 
} 

/* More methods... */ 

enum SupportedFeatures { 
GLUSTER(Version.v3_0), 
REFRESH_HEAVYWEIGHT(Version.v3_0, Version.v3_1), 
/* More members */; 

private Set<Version> unsupportedVersions = new HashSet<Version>(); 

private SupportedFeatures(Version... versions) { 
unsupportedVersions.addAll(Arrays.asList(versions)); 
} 

public boolean isSupportedOn(Version version) { 
return !unsupportedVersions.contains(version); 
} 
} 
------------------------------------- END EXAMPLE ------------------------------------- 

Thoughts? 

Regards, 
Mike 

> Please share your thoughts on this.

> Thanks,
> Kanagaraj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20131201/6b539e38/attachment.html>

From mpastern at redhat.com  Sun Dec  1 07:02:12 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Sun, 01 Dec 2013 09:02:12 +0200
Subject: [Engine-devel] Using REST API in web UI - review call summary
In-Reply-To: <52986581.6090309@redhat.com>
References: <1515483885.28819526.1385068697947.JavaMail.root@redhat.com>	<5291B3A5.5060305@redhat.com>	<1131535003.32427980.1385666553819.JavaMail.root@redhat.com>
	<5298623F.6080605@redhat.com> <52986581.6090309@redhat.com>
Message-ID: <529ADEF4.9080500@redhat.com>

On 11/29/2013 11:59 AM, Michael Pasternak wrote:
> On 11/29/2013 11:45 AM, Michael Pasternak wrote:
>> On 11/28/2013 09:22 PM, Vojtech Szocs wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Michael Pasternak" <mpastern at redhat.com>
>>>> To: "Vojtech Szocs" <vszocs at redhat.com>
>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>>>> Sent: Sunday, November 24, 2013 9:07:01 AM
>>>> Subject: Re: [Engine-devel] Using REST API in web UI - review call summary
>>>>
>>>>
>>>>
>>>> Hi Vojtech,
>>>>
>>>> First of all it was a good "presentation" of requirements + suggested
>>>> solutions - well done!,
>>>
>>> Thank you :)
>>>
>>>> few comments/questions inline.
>>>>
>>>> On 11/21/2013 11:18 PM, Vojtech Szocs wrote:
>>>>> Hi guys,
>>>>>
>>>>> this is a summary of yesterday's review call, I'll try to highlight
>>>>> important Q/A and things we agreed on.
>>>>> Feel free to add anything in case I've missed something.
>>>>>
>>>>> --
>>>>>
>>>>> Q: Why don't we simply try to use existing Java SDK and adapt it for GWT
>>>>> apps? (asked by Michael & Gilad)
>>>>>
>>>>> A: This might be a viable option to consider if we wanted to skip
>>>>> JavaScript-based SDK altogether and target Java/GWT code
>>>>> directly; we could simply take Java SDK and customize its abstractions
>>>>> where necessary, i.e. using HTTP transport layer
>>>>> implementation that works with GWT. In any case, this would mean coupling
>>>>> ourselves to Java SDK (which has its own release cycle)
>>>>> and I think this would complicate things for us.
>>>>
>>>> not sure i buy this one :), this is the purpose of any sdk, including the
>>>> one you about to write, people that will use it, will be "coupling" to it ...
>>>
>>> Of course, but by saying "coupling ourselves to Java SDK" I meant SDK perspective, not client perspective:
>>
>> of course, but you told something different, that you want js-sdk to be aware
>> of the client, and this is actually why you taking this path.
>>
>>>
>>> - someone else (you) maintains Java SDK and therefore controls generated sources (JAR or RPM isn't relevant here)
>>> - another guy (me) maintains (fictional) Java/GWT SDK that relies on Java SDK + some (supported) customizations
>>> - the only way I can impose changes in my SDK is through supported customizations as you control original (Java SDK) sources,
>>>   i.e. the whole code generation process is driven by your SDK, so my SDK is coupled to your SDK's build/release cycle
>>
>> that's how things working in software, you always depending on the certain version
>> of the component you're working against, as it expose set of features you need, i don't
>> think that having control over framework features, justifying rewriting the
>> framework ...
>>
>> (please note that i'm not against the js-sdk, go ahead, this is a nice initiative indeed, i
>> just can't see the business case for not reusing existent infrastructure cause it works
>> for all your needs and eventually both worlds would benefiting from it UI and java-sdk users
>> cause you where extending it with additional capabilities they may also need)
>>
>>>
>>> For the sake of simplicity, I guess it's best to start with SDK that has no dependencies whatsoever. 
>>
>> so why won't you rewrite the engine in Java-script? your js-sdk eventually will be depending on it,
>> this way you'll have control over it (and it's features) as well ;-)
>>
>>> After all, there's no common dependency (aside from running Engine to provide XSD & RSDL) between Java & Python SDK too, if I understand correctly.
>>>
>>> In other words, building on top of something existing (just because we can do that) isn't always appropriate/flexible/efficient, it always depends on given context and requirements.
>>
>> it would be true, if your requirements would make existing infrastructure inappropriate.
>>
>>>
>>>>
>>>>>
>>>>> As proposed on the meeting, I think it's best to aim for JavaScript SDK as
>>>>> the lowest
>>>>> common denominator for *any* web application that wants to work with REST
>>>>> API. oVirt GWT-based
>>>>> UI can simply bind to JavaScript SDK, i.e. Java/GWT code that just overlays
>>>>> objects and functions
>>>>> provided by JavaScript SDK. Another reason is ease of maintenance - I'd
>>>>> rather see JavaScript SDK's code
>>>>> generation process to be independent of any other SDK (people responsible
>>>>> for maintaining JavaScript SDK
>>>>> should have full control over generated code).
>>>>
>>>> what do you mean by "people should have full control over generated code"?
>>>
>>> It's related to "coupling from SDK perspective" I mentioned above:
>>> "the only way I can impose changes in my SDK is through supported customizations as you control original (Java SDK) sources"
>>
>> if you need additional functionality in java-sdk, you could do the following:
>>
>> 1. submit a patch to java-sdk
>> 2. build new java-sdk locally and use it along with new feature you've added
>> 3. make UI depending on next version of java-sdk (which includes your new feature)
>>
>> we (and all other SW projects) doing that day by day in engine,api,etc.
>>
>> (as i mentioned this would also benefit java-sdk users with additional features
>> they might find useful as well)
>>
>>>
>>> (by "people" I meant "JavaScript SDK developers")
>>>
>>> Full control means ability to change generated sources in whatever way desired, but assuming the idea of reusing/customizing existing SDK code, aspect of full control is lost in favor of reusing existing code.
>>
>> i disagree on this one, you have all control you need over java-sdk at any time
>> as it one of indoor projects.
>>
>>> And of course, this assumes that existing code (Java SDK) provides everything we need, which might or might not be the case.
>>>
>>> So I just vote for simplicity, generate JavaScript SDK the way like other SDKs (Java/Python) - not trying to reuse anything, just grab XSD & RSDL and generate sources.
>>>
>>>> the purpose of
>>>> code generation is to ease maintenance, i.e you/maintainer should not write
>>>> the feature
>>>> once it available in api, just run CodeGen and you'll get it for free, but
>>>> this is zero control
>>>> over code.
>>>
>>> +1
>>>
>>> I agree with you on this.
>>>
>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Q: What about functionality currently used by oVirt UI but not supported by
>>>>> REST API? (asked by Einav)
>>>>>    [For example, fetching VM entity over GWT RPC also returns related data
>>>>>    such as Cluster name.]
>>>>>
>>>>> A: Based on discussion I've had with other colleagues after yesterday's
>>>>> review call, I don't think that
>>>>> separate support-like backend layer is a good idea. Instead, this is the
>>>>> kind of functionality that could be
>>>>> placed in oVirt.js library. Logical operations like "get VMs and related
>>>>> data" would be exposed through oVirt.js
>>>>> (callback-based) API and ultimately realized as multiple physical requests
>>>>> to REST API via JavaScript Binding.
>>>>>
>>>>> oVirt.js client would be completely oblivious to the fact that multiple
>>>>> physical requests are dispatched. In fact,
>>>>> since HTTP communication is asynchronous in nature, oVirt.js client
>>>>> wouldn't even notice any difference in terms of API
>>>>> consumption. This assumes JavaScript SDK would use callback-based
>>>>> (non-blocking) API instead of blocking one - after all,
>>>>> blocking API on top of non-blocking implementation sounds pretty much like
>>>>> leaky abstraction [1].
>>>>>
>>>>> For example:
>>>>>
>>>>>     sdk.getVmsWithExtraData(
>>>>>         callbackToGetExtraDataForGivenVm, // might cause extra physical
>>>>>         requests to REST API
>>>>>         callbackFiredWhenAllDataIsReady   // update client only when all
>>>>>         data is ready
>>>>>     )
>>>>
>>>> actually this the main bottleneck in moving UI to work on top of REST, and
>>>> most interesting/complex part of this project,
>>>
>>> Agreed, it's because UI "got used to" using internal backend interface concepts (actions, queries etc.) in the first place.. So we'll have to emulate what we used to use to prevent regressions, maybe improve/refactor in future.
>>>
>>>>
>>>> you should think of very wise polling mechanism cause callbacks is a nice
>>>> thing on paper, but behind the scene it all about polling:
>>>>
>>>> - the entity/s till action got accomplished
>>>> - add to this updating different grids
>>>> - running multiple actions
>>>> - showing events
>>>> - and obviously much more
>>>
>>> IMHO polling is just a workaround and indicates lack of proper notification solution.
>>>
>>> Apparently, oVirt web UI isn't some CLI program for which HTTP request/response style is sufficient. oVirt web UI is dynamic, interactive web application that displays/updates data in real time. This is, in my opinion, quite a big difference.
>>>
>>> I don't think callbacks are just a nice thing on paper. Callbacks are needed because the underlying communcation is async in nature:
>>
>> Vojtech, you've got all wrong, i told that you *do need* callbacks,
>> but implementing them only sounds easy, while actually it will be
>> a quite complicated task.
>>
>>>
>>> - caller invokes API function and provides callback to execute when operation completes -> API is non-blocking
>>> - polling attempts to detect change (i.e. operation completed) and notify the caller, so it's also some sort of callback -> this is more complicated compared to simple callback
>>>
>>>>
>>>> and don't forget that every polled entity should be marshalled from xml to
>>>> the javascript
>>>> entity so at the end, "callbacks" mechanism will be extremely CPU consuming.
>>>
>>> First of all, I don't understand how callback mechanism can be CPU consuming, can you please provide some explanation or use case?
>>
>> of course, you'll have to do per call-back call:
> 
> s/"call-back call"/"polling request", e.g:
> 
> 1 polling task == N * (#1+#2+#3)
> 
> [where N is amount of requests you need to perform till desired state is achieved]

i have a solution for this!, will get back to you/publish it when i have a mature design.

> 
>>
>> 1. request/response to the server
>> 2. decompression of data from gzip
>> 3. object mapping (in 99% of cases)
>>
>>
>> note you'll have a lot of callback consumers that monitoring resource state, waiting for new events.
>>
>>
>>>
>>> Does Java SDK provide ability to poll Engine in order to get recent updates, and if yes, why?
>>
>> i was kinda hoping that you'll add it, but you've chosen to write your own sdk ;-)
>>
>>>
>>> Finally, polling makes things stateful, whereas SDK code should be stateless instead. If client wants to get recent updates, it should just use (stateless) SDK code to achieve this goal.
>>
>> sdk cannot be stateful by definition simply because server is stateless,
>> (also pooling != keeping state, being stateful means that you save data
>> for request on server side)
>>
>>>
>>>>
>>>>>
>>>>> [1] http://en.wikipedia.org/wiki/Leaky_abstraction
>>>>>
>>>>> --
>>>>>
>>>>> Last but not least, where to maintain JavaScript SDK projects: low-level
>>>>> JavaScript Binding + high-level oVirt.js library.
>>>>>
>>>>> I agree that conceptually both above mentioned projects should go into
>>>>> dedicated "ovirt-engine-sdk-js" git repository and
>>>>> have their own build/release process. However, for now, we're just making
>>>>> baby steps so let's keep things simple and prototype
>>>>> these projects as part of "ovirt-engine" git repository.
>>>>>
>>>>> ... we can complicate things anytime, but we should know that any complex
>>>>> system that works has inevitably evolved from simple
>>>>> system that works ... (quote from
>>>>> http://en.wikipedia.org/wiki/Gall%27s_law)
>>>>>
>>>>> Regards,
>>>>> Vojtech
>>>>> _______________________________________________
>>>>> Engine-devel mailing list
>>>>> Engine-devel at ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Michael Pasternak
>>>> RedHat, ENG-Virtualization R&D
>>>>
>>
>>
> 
> 


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From ofrenkel at redhat.com  Sun Dec  1 08:55:19 2013
From: ofrenkel at redhat.com (Omer Frenkel)
Date: Sun, 1 Dec 2013 03:55:19 -0500 (EST)
Subject: [Engine-devel] Using config values
In-Reply-To: <1643824061.43195741.1385878122949.JavaMail.root@redhat.com>
References: <52984D48.1070009@redhat.com>
	<1643824061.43195741.1385878122949.JavaMail.root@redhat.com>
Message-ID: <1268805500.21090048.1385888119665.JavaMail.root@redhat.com>

----- Original Message -----

> From: "Mike Kolesnik" <mkolesni at redhat.com>
> To: "Kanagaraj" <kmayilsa at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Sunday, December 1, 2013 8:08:42 AM
> Subject: Re: [Engine-devel] Using config values

> ----- Original Message -----

> > Hi All,
> 
> Hi Kanagaraj,

> > The are some issues arising in configurations whenever we move up on the
> > versions(3.3 => 3.4), because of the way we store and interpret them.
> 

> > Whenever there is a new cluster level, you will need to add a new entry for
> > all(most) of the configuration. Mostly a copy paste if you see from 3.2 to
> > 3.3, except some CPU/PM type related configurations.
> 
> > Better option would be to have the defaul config value in ConfigValues.java
> > and the overrides will go to config.sql. In this approach you don't need a
> > new entries to config.sql when there is a new cluster level.
> 

> > Lets take an exmaple, "SupportForceCreateVG" - This is supported from 3.1
> > onwards,
> 

> > If you look at config.sql, you will see following entries
> 
> > select fn_db_add_config_value('SupportForceCreateVG','false','3.0');
> 
> > select fn_db_add_config_value('SupportForceCreateVG','true','3.1');
> 
> > select fn_db_add_config_value('SupportForceCreateVG','true','3.2');
> 
> > select fn_db_add_config_value('SupportForceCreateVG','true','3.3');
> 

> > And in ConfigValues.java
> 

> > @TypeConverterAttribute(Boolean.class)
> 
> > @DefaultValueAttribute("false")
> 
> > SupportForceCreateVG,
> 

> > Now if there is 3.4 and 3.5, the user needs to add 2 more entries, which i
> > feel is redundant.
> 

> > Instead we can make
> 

> > @TypeConverterAttribute(Boolean.class)
> 
> > @DefaultValueAttribute("true")
> 
> > SupportForceCreateVG,
> 

> > and have only the following in config.sql
> 
> > select fn_db_add_config_value('SupportForceCreateVG','false','3.0');
> 

> > if a particular value(for a specific cluster level) is not found in
> > Config.sql, the fallback is to use the value available in
> > ConfigValues.java.
> 
> This has already been implemented, there are many "feature supported"
> configurations working like this (for example GlusterSupport).

> I think a more interesting approach would be to move these out of the DB
> since these values don't really hav e a reson to be there.
> Since the entire thing is abstracted by "Gluster/FeatureSupported" classes
> then we can easily change mechanism (of course whatever code is not using it
> can be easily converted to use the mechanism)

> For example a simple enum could do the trick:
> ------------------------------------- EXAMPLE
> -------------------------------------
> /**
> * Convenience class to check if a gluster feature is supported or not in any
> given version.<br>
> * Methods should be named by feature and accept version to check against.
> */
> public class GlusterFeatureSupported {
> /**
> * @param version
> * Compatibility version to check for.
> * @return <code>true</code> if gluster support is enabled, <code>false</code>
> if it's not.
> */
> public static boolean gluster(Version version) {
> return SupportedFeatures.GLUSTER.isSupportedOn(version);
> }

> /**
> * @param version
> * Compatibility version to check for.
> * @return <code>true</code> if gluster heavyweight refresh is enabled,
> <code>false</code> if it's not.
> */
> public static boolean refreshHeavyWeight(Version version) {
> return SupportedFeatures.REFRESH_HEAVYWEIGHT.isSupportedOn(version);
> }

> /* More methods... */

> enum SupportedFeatures {
> GLUSTER(Version.v3_0),
> REFRESH_HEAVYWEIGHT(Version.v3_0, Version.v3_1),
> /* More members */;

> private Set<Version> unsupportedVersions = new HashSet<Version>();

> private SupportedFeatures(Version... versions) {
> unsupportedVersions.addAll(Arrays.asList(versions));
> }

> public boolean isSupportedOn(Version version) {
> return !unsupportedVersions.contains(version);
> }
> }
> ------------------------------------- END EXAMPLE
> -------------------------------------

> Thoughts?

unless i didn't understand something, this is not good, 
this should stay configurable by the users, 
for example if some user experience some issues with a feature and want to turn it off/change the values.. 
(not all version configuration are boolean, some are different values to different versions, like cpu-list) 

> Regards,
> Mike

> > Please share your thoughts on this.
> 

> > Thanks,
> 
> > Kanagaraj
> 

> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20131201/0b36ec9b/attachment.html>

From mkolesni at redhat.com  Sun Dec  1 09:01:50 2013
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Sun, 1 Dec 2013 04:01:50 -0500 (EST)
Subject: [Engine-devel] Using config values
In-Reply-To: <1268805500.21090048.1385888119665.JavaMail.root@redhat.com>
References: <52984D48.1070009@redhat.com>
	<1643824061.43195741.1385878122949.JavaMail.root@redhat.com>
	<1268805500.21090048.1385888119665.JavaMail.root@redhat.com>
Message-ID: <1138287431.43206802.1385888510815.JavaMail.root@redhat.com>

----- Original Message -----

> ----- Original Message -----

> > From: "Mike Kolesnik" <mkolesni at redhat.com>
> 
> > To: "Kanagaraj" <kmayilsa at redhat.com>
> 
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> 
> > Sent: Sunday, December 1, 2013 8:08:42 AM
> 
> > Subject: Re: [Engine-devel] Using config values
> 

> > ----- Original Message -----
> 

> > > Hi All,
> > 
> 
> > Hi Kanagaraj,
> 

> > > The are some issues arising in configurations whenever we move up on the
> > > versions(3.3 => 3.4), because of the way we store and interpret them.
> > 
> 

> > > Whenever there is a new cluster level, you will need to add a new entry
> > > for
> > > all(most) of the configuration. Mostly a copy paste if you see from 3.2
> > > to
> > > 3.3, except some CPU/PM type related configurations.
> > 
> 
> > > Better option would be to have the defaul config value in
> > > ConfigValues.java
> > > and the overrides will go to config.sql. In this approach you don't need
> > > a
> > > new entries to config.sql when there is a new cluster level.
> > 
> 

> > > Lets take an exmaple, "SupportForceCreateVG" - This is supported from 3.1
> > > onwards,
> > 
> 

> > > If you look at config.sql, you will see following entries
> > 
> 
> > > select fn_db_add_config_value('SupportForceCreateVG','false','3.0');
> > 
> 
> > > select fn_db_add_config_value('SupportForceCreateVG','true','3.1');
> > 
> 
> > > select fn_db_add_config_value('SupportForceCreateVG','true','3.2');
> > 
> 
> > > select fn_db_add_config_value('SupportForceCreateVG','true','3.3');
> > 
> 

> > > And in ConfigValues.java
> > 
> 

> > > @TypeConverterAttribute(Boolean.class)
> > 
> 
> > > @DefaultValueAttribute("false")
> > 
> 
> > > SupportForceCreateVG,
> > 
> 

> > > Now if there is 3.4 and 3.5, the user needs to add 2 more entries, which
> > > i
> > > feel is redundant.
> > 
> 

> > > Instead we can make
> > 
> 

> > > @TypeConverterAttribute(Boolean.class)
> > 
> 
> > > @DefaultValueAttribute("true")
> > 
> 
> > > SupportForceCreateVG,
> > 
> 

> > > and have only the following in config.sql
> > 
> 
> > > select fn_db_add_config_value('SupportForceCreateVG','false','3.0');
> > 
> 

> > > if a particular value(for a specific cluster level) is not found in
> > > Config.sql, the fallback is to use the value available in
> > > ConfigValues.java.
> > 
> 
> > This has already been implemented, there are many "feature supported"
> > configurations working like this (for example GlusterSupport).
> 

> > I think a more interesting approach would be to move these out of the DB
> > since these values don't really hav e a reson to be there.
> 
> > Since the entire thing is abstracted by "Gluster/FeatureSupported" classes
> > then we can easily change mechanism (of course whatever code is not using
> > it
> > can be easily converted to use the mechanism)
> 

> > For example a simple enum could do the trick:
> 
> > ------------------------------------- EXAMPLE
> > -------------------------------------
> 
> > /**
> 
> > * Convenience class to check if a gluster feature is supported or not in
> > any
> > given version.<br>
> 
> > * Methods should be named by feature and accept version to check against.
> 
> > */
> 
> > public class GlusterFeatureSupported {
> 
> > /**
> 
> > * @param version
> 
> > * Compatibility version to check for.
> 
> > * @return <code>true</code> if gluster support is enabled,
> > <code>false</code>
> > if it's not.
> 
> > */
> 
> > public static boolean gluster(Version version) {
> 
> > return SupportedFeatures.GLUSTER.isSupportedOn(version);
> 
> > }
> 

> > /**
> 
> > * @param version
> 
> > * Compatibility version to check for.
> 
> > * @return <code>true</code> if gluster heavyweight refresh is enabled,
> > <code>false</code> if it's not.
> 
> > */
> 
> > public static boolean refreshHeavyWeight(Version version) {
> 
> > return SupportedFeatures.REFRESH_HEAVYWEIGHT.isSupportedOn(version);
> 
> > }
> 

> > /* More methods... */
> 

> > enum SupportedFeatures {
> 
> > GLUSTER(Version.v3_0),
> 
> > REFRESH_HEAVYWEIGHT(Version.v3_0, Version.v3_1),
> 
> > /* More members */;
> 

> > private Set<Version> unsupportedVersions = new HashSet<Version>();
> 

> > private SupportedFeatures(Version... versions) {
> 
> > unsupportedVersions.addAll(Arrays.asList(versions));
> 
> > }
> 

> > public boolean isSupportedOn(Version version) {
> 
> > return !unsupportedVersions.contains(version);
> 
> > }
> 
> > }
> 
> > ------------------------------------- END EXAMPLE
> > -------------------------------------
> 

> > Thoughts?
> 

> unless i didn't understand something, this is not good,
> this should stay configurable by the users,
> for example if some user experience some issues with a feature and want to
> turn it off/change the values..
> (not all version configuration are boolean, some are different values to
> different versions, like cpu-list)

This is for API level compatibility. 
If VDSM doesn't support for example hot plug in 3.1 then the user can't just decide that it does and change it. 
Also, this is not changeable by user since it's not exposed by engine-config (nor should it be). 

This is strictly for the engine-VDSM API compatibility, not for other configs which are version specific. 

> > Regards,
> 
> > Mike
> 

> > > Please share your thoughts on this.
> > 
> 

> > > Thanks,
> > 
> 
> > > Kanagaraj
> > 
> 

> > _______________________________________________
> 
> > Engine-devel mailing list
> 
> > Engine-devel at ovirt.org
> 
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20131201/9ecc6310/attachment.html>

From ofrenkel at redhat.com  Sun Dec  1 09:02:46 2013
From: ofrenkel at redhat.com (Omer Frenkel)
Date: Sun, 1 Dec 2013 04:02:46 -0500 (EST)
Subject: [Engine-devel] Using config values
In-Reply-To: <1299085692.33736696.1385845115835.JavaMail.root@redhat.com>
References: <52984D48.1070009@redhat.com> <52987D19.9000203@redhat.com>
	<1299085692.33736696.1385845115835.JavaMail.root@redhat.com>
Message-ID: <496533960.21093647.1385888566815.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Eli Mesika" <emesika at redhat.com>
> To: "Dusmant Kumar Pati" <dpati at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Saturday, November 30, 2013 10:58:35 PM
> Subject: Re: [Engine-devel] Using config values
> 
> 
> 
> ----- Original Message -----
> > From: "Dusmant Kumar Pati" <dpati at redhat.com>
> > To: "Kanagaraj" <kmayilsa at redhat.com>, "engine-devel"
> > <engine-devel at ovirt.org>
> > Sent: Friday, November 29, 2013 1:40:09 PM
> > Subject: Re: [Engine-devel] Using config values
> > 
> > On 11/29/2013 01:46 PM, Kanagaraj wrote:
> > 
> > 
> > Hi All,
> > 
> > The are some issues arising in configurations whenever we move up on the
> > versions(3.3 => 3.4), because of the way we store and interpret them.
> > 
> > Whenever there is a new cluster level, you will need to add a new entry for
> > all(most) of the configuration. Mostly a copy paste if you see from 3.2 to
> > 3.3, except some CPU/PM type related configurations.
> > Better option would be to have the defaul config value in ConfigValues.java
> > and the overrides will go to config.sql. In this approach you don't need a
> > new entries to config.sql when there is a new cluster level.
> > 
> > Lets take an exmaple, "SupportForceCreateVG" - This is supported from 3.1
> > onwards,
> > 
> > If you look at config.sql, you will see following entries
> > select fn_db_add_config_value('SupportForceCreateVG','false','3.0');
> > select fn_db_add_config_value('SupportForceCreateVG','true','3.1');
> > select fn_db_add_config_value('SupportForceCreateVG','true','3.2');
> > select fn_db_add_config_value('SupportForceCreateVG','true','3.3');
> > 
> > And in ConfigValues.java
> > 
> > @TypeConverterAttribute(Boolean.class)
> > @DefaultValueAttribute("false")
> > SupportForceCreateVG,
> > 
> > Now if there is 3.4 and 3.5, the user needs to add 2 more entries, which i
> > feel is redundant.
> > 
> > Instead we can make
> > 
> > @TypeConverterAttribute(Boolean.class)
> > @DefaultValueAttribute("true")
> > SupportForceCreateVG,
> > 
> > and have only the following in config.sql
> > select fn_db_add_config_value('SupportForceCreateVG','false','3.0');
> > 
> > if a particular value(for a specific cluster level) is not found in
> > Config.sql, the fallback is to use the value available in
> > ConfigValues.java.
> > 
> > Please share your thoughts on this.
> 
> Hi
> 
> First of all I think its a good idea
> I have 2 questions
> 
> 1) Which value will be stored as default in the java class for configuration
> values that are not a boolean, that represents if a feature is active or
> not.
>    Is that the latest version value ? sounds not obvious to me
> 

i guess this will have to have a configuration values for each version in the db.

> 2) There are some configuration values that are exposed to the user via the
> engine-config tool, how this will work, we can not remove the entries their
> since the user may change and override those values.
> 

in your suggestion below, there is the same issue,
if user want to change the 3.3 value, engine config will fail with "No such entry"
because 3.3 will not be in the db..
so if we are not fixing this, i think using the current implementation is good enough,
no need to add logic, just to convert current options that are not in this format, to use this logic.

> I have a different suggestion:
> Default value will stay as is , meaning , it will reflect the value that
> should be used to keep the application running correctly if a value is not
> found in DB (which should not occur)
> 
> Code of getting configuration value (getConfigValue(<key>,<version>) will be
> changed to get the closest version value to the given one.
> For example , if a 3.4 version is given for a given <key> and we have in DB
> just values for 3.0 and 3.1 , the 3.1 value is returned.
> I prefer this solution since it makes the config.sql file self documented ,
> showing only value changes and in which version each change occurred.
> 
> To implement that, we should add this mechanism to the current code that
> caches the DB content and as I see that it should be a simple change.
> engine-config should be modified such that if the user change a value, this
> value will be inserted to the database with the current release if not
> exists and then the mechanism described above will get this value
> 
> Example:
> 
> VdsFenceType lists all the supported fencing agents for power management , it
> currently has the following settings
> 
>                                        option_value
>                                        |
>                                        version
> ---------------------------------------------------------------------------------------------+---------
>  alom,apc,bladecenter,drac5,eps,ilo,ilo3,ipmilan,rsa,rsb,wti,cisco_ucs
>  | 3.0
>  alom,apc,bladecenter,drac5,eps,ilo,ilo3,ipmilan,rsa,rsb,wti,cisco_ucs
>  | 3.1
>  apc,apc_snmp,bladecenter,cisco_ucs,drac5,eps,ilo,ilo2,ilo3,ilo4,ipmilan,rsa,rsb,wti
>  | 3.2
>  apc,apc_snmp,bladecenter,cisco_ucs,drac5,eps,ilo,ilo2,ilo3,ilo4,ipmilan,rsa,rsb,wti
>  | 3.3
> 
> In the proposed solution, we will have
> 
>                                        option_value
>                                        |
>                                        version
> ---------------------------------------------------------------------------------------------+---------
>  alom,apc,bladecenter,drac5,eps,ilo,ilo3,ipmilan,rsa,rsb,wti,cisco_ucs
>  | 3.0
>  apc,apc_snmp,bladecenter,cisco_ucs,drac5,eps,ilo,ilo2,ilo3,ilo4,ipmilan,rsa,rsb,wti
>  | 3.2
> 
> This is clear and documents only the changes done between versions and serve
> all values: boolean , string and complex type (those which requires any kind
> of parsing)
> 
> What do you think?
> 
> Eli
> 
> 
> 
> 
> 
> 
> 
>  
> 
> 
> 
>   
> 
> 
> > 
> > Thanks,
> > Kanagaraj
> > 
> > 
> > 
> > _______________________________________________
> > Engine-devel mailing list Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > I think, this is a good suggestion...
> > 
> > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From ofrenkel at redhat.com  Sun Dec  1 09:09:32 2013
From: ofrenkel at redhat.com (Omer Frenkel)
Date: Sun, 1 Dec 2013 04:09:32 -0500 (EST)
Subject: [Engine-devel] Using config values
In-Reply-To: <1138287431.43206802.1385888510815.JavaMail.root@redhat.com>
References: <52984D48.1070009@redhat.com>
	<1643824061.43195741.1385878122949.JavaMail.root@redhat.com>
	<1268805500.21090048.1385888119665.JavaMail.root@redhat.com>
	<1138287431.43206802.1385888510815.JavaMail.root@redhat.com>
Message-ID: <823270883.21094118.1385888972530.JavaMail.root@redhat.com>

----- Original Message -----

> From: "Mike Kolesnik" <mkolesni at redhat.com>
> To: "Omer Frenkel" <ofrenkel at redhat.com>
> Cc: "Kanagaraj" <kmayilsa at redhat.com>, "engine-devel"
> <engine-devel at ovirt.org>
> Sent: Sunday, December 1, 2013 11:01:50 AM
> Subject: Re: [Engine-devel] Using config values

> ----- Original Message -----

> > ----- Original Message -----
> 

> > > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > 
> 
> > > To: "Kanagaraj" <kmayilsa at redhat.com>
> > 
> 
> > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > 
> 
> > > Sent: Sunday, December 1, 2013 8:08:42 AM
> > 
> 
> > > Subject: Re: [Engine-devel] Using config values
> > 
> 

> > > ----- Original Message -----
> > 
> 

> > > > Hi All,
> > > 
> > 
> 
> > > Hi Kanagaraj,
> > 
> 

> > > > The are some issues arising in configurations whenever we move up on
> > > > the
> > > > versions(3.3 => 3.4), because of the way we store and interpret them.
> > > 
> > 
> 

> > > > Whenever there is a new cluster level, you will need to add a new entry
> > > > for
> > > > all(most) of the configuration. Mostly a copy paste if you see from 3.2
> > > > to
> > > > 3.3, except some CPU/PM type related configurations.
> > > 
> > 
> 
> > > > Better option would be to have the defaul config value in
> > > > ConfigValues.java
> > > > and the overrides will go to config.sql. In this approach you don't
> > > > need
> > > > a
> > > > new entries to config.sql when there is a new cluster level.
> > > 
> > 
> 

> > > > Lets take an exmaple, "SupportForceCreateVG" - This is supported from
> > > > 3.1
> > > > onwards,
> > > 
> > 
> 

> > > > If you look at config.sql, you will see following entries
> > > 
> > 
> 
> > > > select fn_db_add_config_value('SupportForceCreateVG','false','3.0');
> > > 
> > 
> 
> > > > select fn_db_add_config_value('SupportForceCreateVG','true','3.1');
> > > 
> > 
> 
> > > > select fn_db_add_config_value('SupportForceCreateVG','true','3.2');
> > > 
> > 
> 
> > > > select fn_db_add_config_value('SupportForceCreateVG','true','3.3');
> > > 
> > 
> 

> > > > And in ConfigValues.java
> > > 
> > 
> 

> > > > @TypeConverterAttribute(Boolean.class)
> > > 
> > 
> 
> > > > @DefaultValueAttribute("false")
> > > 
> > 
> 
> > > > SupportForceCreateVG,
> > > 
> > 
> 

> > > > Now if there is 3.4 and 3.5, the user needs to add 2 more entries,
> > > > which
> > > > i
> > > > feel is redundant.
> > > 
> > 
> 

> > > > Instead we can make
> > > 
> > 
> 

> > > > @TypeConverterAttribute(Boolean.class)
> > > 
> > 
> 
> > > > @DefaultValueAttribute("true")
> > > 
> > 
> 
> > > > SupportForceCreateVG,
> > > 
> > 
> 

> > > > and have only the following in config.sql
> > > 
> > 
> 
> > > > select fn_db_add_config_value('SupportForceCreateVG','false','3.0');
> > > 
> > 
> 

> > > > if a particular value(for a specific cluster level) is not found in
> > > > Config.sql, the fallback is to use the value available in
> > > > ConfigValues.java.
> > > 
> > 
> 
> > > This has already been implemented, there are many "feature supported"
> > > configurations working like this (for example GlusterSupport).
> > 
> 

> > > I think a more interesting approach would be to move these out of the DB
> > > since these values don't really hav e a reson to be there.
> > 
> 
> > > Since the entire thing is abstracted by "Gluster/FeatureSupported"
> > > classes
> > > then we can easily change mechanism (of course whatever code is not using
> > > it
> > > can be easily converted to use the mechanism)
> > 
> 

> > > For example a simple enum could do the trick:
> > 
> 
> > > ------------------------------------- EXAMPLE
> > > -------------------------------------
> > 
> 
> > > /**
> > 
> 
> > > * Convenience class to check if a gluster feature is supported or not in
> > > any
> > > given version.<br>
> > 
> 
> > > * Methods should be named by feature and accept version to check against.
> > 
> 
> > > */
> > 
> 
> > > public class GlusterFeatureSupported {
> > 
> 
> > > /**
> > 
> 
> > > * @param version
> > 
> 
> > > * Compatibility version to check for.
> > 
> 
> > > * @return <code>true</code> if gluster support is enabled,
> > > <code>false</code>
> > > if it's not.
> > 
> 
> > > */
> > 
> 
> > > public static boolean gluster(Version version) {
> > 
> 
> > > return SupportedFeatures.GLUSTER.isSupportedOn(version);
> > 
> 
> > > }
> > 
> 

> > > /**
> > 
> 
> > > * @param version
> > 
> 
> > > * Compatibility version to check for.
> > 
> 
> > > * @return <code>true</code> if gluster heavyweight refresh is enabled,
> > > <code>false</code> if it's not.
> > 
> 
> > > */
> > 
> 
> > > public static boolean refreshHeavyWeight(Version version) {
> > 
> 
> > > return SupportedFeatures.REFRESH_HEAVYWEIGHT.isSupportedOn(version);
> > 
> 
> > > }
> > 
> 

> > > /* More methods... */
> > 
> 

> > > enum SupportedFeatures {
> > 
> 
> > > GLUSTER(Version.v3_0),
> > 
> 
> > > REFRESH_HEAVYWEIGHT(Version.v3_0, Version.v3_1),
> > 
> 
> > > /* More members */;
> > 
> 

> > > private Set<Version> unsupportedVersions = new HashSet<Version>();
> > 
> 

> > > private SupportedFeatures(Version... versions) {
> > 
> 
> > > unsupportedVersions.addAll(Arrays.asList(versions));
> > 
> 
> > > }
> > 
> 

> > > public boolean isSupportedOn(Version version) {
> > 
> 
> > > return !unsupportedVersions.contains(version);
> > 
> 
> > > }
> > 
> 
> > > }
> > 
> 
> > > ------------------------------------- END EXAMPLE
> > > -------------------------------------
> > 
> 

> > > Thoughts?
> > 
> 

> > unless i didn't understand something, this is not good,
> 
> > this should stay configurable by the users,
> 
> > for example if some user experience some issues with a feature and want to
> > turn it off/change the values..
> 
> > (not all version configuration are boolean, some are different values to
> > different versions, like cpu-list)
> 

> This is for API level compatibility.
> If VDSM doesn't support for example hot plug in 3.1 then the user can't just
> decide that it does and change it.
> Also, this is not changeable by user since it's not exposed by engine-config
> (nor should it be).

some are exposed 

> This is strictly for the engine-VDSM API compatibility, not for other configs
> which are version specific.

right, but still user should be able to turn features off in case of problems, 
or change in some cases (for example it is possible to add support for more power management devices, i know it was done by users) 
no reason to block this 

> > > Regards,
> > 
> 
> > > Mike
> > 
> 

> > > > Please share your thoughts on this.
> > > 
> > 
> 

> > > > Thanks,
> > > 
> > 
> 
> > > > Kanagaraj
> > > 
> > 
> 

> > > _______________________________________________
> > 
> 
> > > Engine-devel mailing list
> > 
> 
> > > Engine-devel at ovirt.org
> > 
> 
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20131201/dc8de80b/attachment.html>

From masayag at redhat.com  Sun Dec  1 09:23:24 2013
From: masayag at redhat.com (Moti Asayag)
Date: Sun, 1 Dec 2013 04:23:24 -0500 (EST)
Subject: [Engine-devel] Using config values
In-Reply-To: <823270883.21094118.1385888972530.JavaMail.root@redhat.com>
References: <52984D48.1070009@redhat.com>
	<1643824061.43195741.1385878122949.JavaMail.root@redhat.com>
	<1268805500.21090048.1385888119665.JavaMail.root@redhat.com>
	<1138287431.43206802.1385888510815.JavaMail.root@redhat.com>
	<823270883.21094118.1385888972530.JavaMail.root@redhat.com>
Message-ID: <1728493072.3569411.1385889804043.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Omer Frenkel" <ofrenkel at redhat.com>
> To: "Mike Kolesnik" <mkolesni at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Sunday, December 1, 2013 11:09:32 AM
> Subject: Re: [Engine-devel] Using config values
> 
> 
> 
> 
> 
> 
> From: "Mike Kolesnik" <mkolesni at redhat.com>
> To: "Omer Frenkel" <ofrenkel at redhat.com>
> Cc: "Kanagaraj" <kmayilsa at redhat.com>, "engine-devel"
> <engine-devel at ovirt.org>
> Sent: Sunday, December 1, 2013 11:01:50 AM
> Subject: Re: [Engine-devel] Using config values
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> From: "Mike Kolesnik" <mkolesni at redhat.com>
> To: "Kanagaraj" <kmayilsa at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Sunday, December 1, 2013 8:08:42 AM
> Subject: Re: [Engine-devel] Using config values
> 
> 
> 
> 
> Hi All,
> 
> Hi Kanagaraj,
> 
> 
> 
> 
> The are some issues arising in configurations whenever we move up on the
> versions(3.3 => 3.4), because of the way we store and interpret them.
> 
> Whenever there is a new cluster level, you will need to add a new entry for
> all(most) of the configuration. Mostly a copy paste if you see from 3.2 to
> 3.3, except some CPU/PM type related configurations.
> Better option would be to have the defaul config value in ConfigValues.java
> and the overrides will go to config.sql. In this approach you don't need a
> new entries to config.sql when there is a new cluster level.
> 
> Lets take an exmaple, "SupportForceCreateVG" - This is supported from 3.1
> onwards,
> 
> If you look at config.sql, you will see following entries
> select fn_db_add_config_value('SupportForceCreateVG','false','3.0');
> select fn_db_add_config_value('SupportForceCreateVG','true','3.1');
> select fn_db_add_config_value('SupportForceCreateVG','true','3.2');
> select fn_db_add_config_value('SupportForceCreateVG','true','3.3');
> 
> And in ConfigValues.java
> 
> @TypeConverterAttribute(Boolean.class)
> @DefaultValueAttribute("false")
> SupportForceCreateVG,
> 
> Now if there is 3.4 and 3.5, the user needs to add 2 more entries, which i
> feel is redundant.
> 
> Instead we can make
> 
> @TypeConverterAttribute(Boolean.class)
> @DefaultValueAttribute("true")
> SupportForceCreateVG,
> 
> and have only the following in config.sql
> select fn_db_add_config_value('SupportForceCreateVG','false','3.0');
> 
> if a particular value(for a specific cluster level) is not found in
> Config.sql, the fallback is to use the value available in ConfigValues.java.
> 
> This has already been implemented, there are many "feature supported"
> configurations working like this (for example GlusterSupport).
> 
> I think a more interesting approach would be to move these out of the DB
> since these values don't really hav e a reson to be there.
> Since the entire thing is abstracted by "Gluster/FeatureSupported" classes
> then we can easily change mechanism (of course whatever code is not using it
> can be easily converted to use the mechanism)
> 
> For example a simple enum could do the trick:
> ------------------------------------- EXAMPLE
> -------------------------------------
> /**
> * Convenience class to check if a gluster feature is supported or not in any
> given version.<br>
> * Methods should be named by feature and accept version to check against.
> */
> public class GlusterFeatureSupported {
> /**
> * @param version
> * Compatibility version to check for.
> * @return <code>true</code> if gluster support is enabled, <code>false</code>
> if it's not.
> */
> public static boolean gluster(Version version) {
> return SupportedFeatures.GLUSTER.isSupportedOn(version);
> }
> 
> /**
> * @param version
> * Compatibility version to check for.
> * @return <code>true</code> if gluster heavyweight refresh is enabled,
> <code>false</code> if it's not.
> */
> public static boolean refreshHeavyWeight(Version version) {
> return SupportedFeatures.REFRESH_HEAVYWEIGHT.isSupportedOn(version);
> }
> 
> /* More methods... */
> 
> enum SupportedFeatures {
> GLUSTER(Version.v3_0),
> REFRESH_HEAVYWEIGHT(Version.v3_0, Version.v3_1),
> /* More members */;
> 
> private Set<Version> unsupportedVersions = new HashSet<Version>();
> 
> private SupportedFeatures(Version... versions) {
> unsupportedVersions.addAll(Arrays.asList(versions));
> }
> 
> public boolean isSupportedOn(Version version) {
> return !unsupportedVersions.contains(version);
> }
> }
> ------------------------------------- END EXAMPLE
> -------------------------------------
> 
> Thoughts?
> 
> unless i didn't understand something, this is not good,
> this should stay configurable by the users,
> for example if some user experience some issues with a feature and want to
> turn it off/change the values..
> (not all version configuration are boolean, some are different values to
> different versions, like cpu-list)
> 
> This is for API level compatibility.
> If VDSM doesn't support for example hot plug in 3.1 then the user can't just
> decide that it does and change it.
> Also, this is not changeable by user since it's not exposed by engine-config
> (nor should it be).
> some are exposed
> 
> 
> 
> This is strictly for the engine-VDSM API compatibility, not for other configs
> which are version specific.
> right, but still user should be able to turn features off in case of
> problems,
> or change in some cases (for example it is possible to add support for more
> power management devices, i know it was done by users)
> no reason to block this
> 

In this case you add additional protection level to block user from enabling features
for unsupported cluster levels.

However it sounds more reasonable than requiring the user to use a lower cluster level
which enforces him to give up on other features.

> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Regards,
> Mike
> 
> 
> 
> Please share your thoughts on this.
> 
> Thanks,
> Kanagaraj
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> 
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From mkolesni at redhat.com  Sun Dec  1 09:26:32 2013
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Sun, 1 Dec 2013 04:26:32 -0500 (EST)
Subject: [Engine-devel] Using config values
In-Reply-To: <823270883.21094118.1385888972530.JavaMail.root@redhat.com>
References: <52984D48.1070009@redhat.com>
	<1643824061.43195741.1385878122949.JavaMail.root@redhat.com>
	<1268805500.21090048.1385888119665.JavaMail.root@redhat.com>
	<1138287431.43206802.1385888510815.JavaMail.root@redhat.com>
	<823270883.21094118.1385888972530.JavaMail.root@redhat.com>
Message-ID: <2111239521.43208505.1385889991988.JavaMail.root@redhat.com>

Regards, 
Mike 

----- Original Message -----

> ----- Original Message -----

> > From: "Mike Kolesnik" <mkolesni at redhat.com>
> 
> > To: "Omer Frenkel" <ofrenkel at redhat.com>
> 
> > Cc: "Kanagaraj" <kmayilsa at redhat.com>, "engine-devel"
> > <engine-devel at ovirt.org>
> 
> > Sent: Sunday, December 1, 2013 11:01:50 AM
> 
> > Subject: Re: [Engine-devel] Using config values
> 

> > ----- Original Message -----
> 

> > > ----- Original Message -----
> > 
> 

> > > > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > > 
> > 
> 
> > > > To: "Kanagaraj" <kmayilsa at redhat.com>
> > > 
> > 
> 
> > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > 
> > 
> 
> > > > Sent: Sunday, December 1, 2013 8:08:42 AM
> > > 
> > 
> 
> > > > Subject: Re: [Engine-devel] Using config values
> > > 
> > 
> 

> > > > ----- Original Message -----
> > > 
> > 
> 

> > > > > Hi All,
> > > > 
> > > 
> > 
> 
> > > > Hi Kanagaraj,
> > > 
> > 
> 

> > > > > The are some issues arising in configurations whenever we move up on
> > > > > the
> > > > > versions(3.3 => 3.4), because of the way we store and interpret them.
> > > > 
> > > 
> > 
> 

> > > > > Whenever there is a new cluster level, you will need to add a new
> > > > > entry
> > > > > for
> > > > > all(most) of the configuration. Mostly a copy paste if you see from
> > > > > 3.2
> > > > > to
> > > > > 3.3, except some CPU/PM type related configurations.
> > > > 
> > > 
> > 
> 
> > > > > Better option would be to have the defaul config value in
> > > > > ConfigValues.java
> > > > > and the overrides will go to config.sql. In this approach you don't
> > > > > need
> > > > > a
> > > > > new entries to config.sql when there is a new cluster level.
> > > > 
> > > 
> > 
> 

> > > > > Lets take an exmaple, "SupportForceCreateVG" - This is supported from
> > > > > 3.1
> > > > > onwards,
> > > > 
> > > 
> > 
> 

> > > > > If you look at config.sql, you will see following entries
> > > > 
> > > 
> > 
> 
> > > > > select fn_db_add_config_value('SupportForceCreateVG','false','3.0');
> > > > 
> > > 
> > 
> 
> > > > > select fn_db_add_config_value('SupportForceCreateVG','true','3.1');
> > > > 
> > > 
> > 
> 
> > > > > select fn_db_add_config_value('SupportForceCreateVG','true','3.2');
> > > > 
> > > 
> > 
> 
> > > > > select fn_db_add_config_value('SupportForceCreateVG','true','3.3');
> > > > 
> > > 
> > 
> 

> > > > > And in ConfigValues.java
> > > > 
> > > 
> > 
> 

> > > > > @TypeConverterAttribute(Boolean.class)
> > > > 
> > > 
> > 
> 
> > > > > @DefaultValueAttribute("false")
> > > > 
> > > 
> > 
> 
> > > > > SupportForceCreateVG,
> > > > 
> > > 
> > 
> 

> > > > > Now if there is 3.4 and 3.5, the user needs to add 2 more entries,
> > > > > which
> > > > > i
> > > > > feel is redundant.
> > > > 
> > > 
> > 
> 

> > > > > Instead we can make
> > > > 
> > > 
> > 
> 

> > > > > @TypeConverterAttribute(Boolean.class)
> > > > 
> > > 
> > 
> 
> > > > > @DefaultValueAttribute("true")
> > > > 
> > > 
> > 
> 
> > > > > SupportForceCreateVG,
> > > > 
> > > 
> > 
> 

> > > > > and have only the following in config.sql
> > > > 
> > > 
> > 
> 
> > > > > select fn_db_add_config_value('SupportForceCreateVG','false','3.0');
> > > > 
> > > 
> > 
> 

> > > > > if a particular value(for a specific cluster level) is not found in
> > > > > Config.sql, the fallback is to use the value available in
> > > > > ConfigValues.java.
> > > > 
> > > 
> > 
> 
> > > > This has already been implemented, there are many "feature supported"
> > > > configurations working like this (for example GlusterSupport).
> > > 
> > 
> 

> > > > I think a more interesting approach would be to move these out of the
> > > > DB
> > > > since these values don't really hav e a reson to be there.
> > > 
> > 
> 
> > > > Since the entire thing is abstracted by "Gluster/FeatureSupported"
> > > > classes
> > > > then we can easily change mechanism (of course whatever code is not
> > > > using
> > > > it
> > > > can be easily converted to use the mechanism)
> > > 
> > 
> 

> > > > For example a simple enum could do the trick:
> > > 
> > 
> 
> > > > ------------------------------------- EXAMPLE
> > > > -------------------------------------
> > > 
> > 
> 
> > > > /**
> > > 
> > 
> 
> > > > * Convenience class to check if a gluster feature is supported or not
> > > > in
> > > > any
> > > > given version.<br>
> > > 
> > 
> 
> > > > * Methods should be named by feature and accept version to check
> > > > against.
> > > 
> > 
> 
> > > > */
> > > 
> > 
> 
> > > > public class GlusterFeatureSupported {
> > > 
> > 
> 
> > > > /**
> > > 
> > 
> 
> > > > * @param version
> > > 
> > 
> 
> > > > * Compatibility version to check for.
> > > 
> > 
> 
> > > > * @return <code>true</code> if gluster support is enabled,
> > > > <code>false</code>
> > > > if it's not.
> > > 
> > 
> 
> > > > */
> > > 
> > 
> 
> > > > public static boolean gluster(Version version) {
> > > 
> > 
> 
> > > > return SupportedFeatures.GLUSTER.isSupportedOn(version);
> > > 
> > 
> 
> > > > }
> > > 
> > 
> 

> > > > /**
> > > 
> > 
> 
> > > > * @param version
> > > 
> > 
> 
> > > > * Compatibility version to check for.
> > > 
> > 
> 
> > > > * @return <code>true</code> if gluster heavyweight refresh is enabled,
> > > > <code>false</code> if it's not.
> > > 
> > 
> 
> > > > */
> > > 
> > 
> 
> > > > public static boolean refreshHeavyWeight(Version version) {
> > > 
> > 
> 
> > > > return SupportedFeatures.REFRESH_HEAVYWEIGHT.isSupportedOn(version);
> > > 
> > 
> 
> > > > }
> > > 
> > 
> 

> > > > /* More methods... */
> > > 
> > 
> 

> > > > enum SupportedFeatures {
> > > 
> > 
> 
> > > > GLUSTER(Version.v3_0),
> > > 
> > 
> 
> > > > REFRESH_HEAVYWEIGHT(Version.v3_0, Version.v3_1),
> > > 
> > 
> 
> > > > /* More members */;
> > > 
> > 
> 

> > > > private Set<Version> unsupportedVersions = new HashSet<Version>();
> > > 
> > 
> 

> > > > private SupportedFeatures(Version... versions) {
> > > 
> > 
> 
> > > > unsupportedVersions.addAll(Arrays.asList(versions));
> > > 
> > 
> 
> > > > }
> > > 
> > 
> 

> > > > public boolean isSupportedOn(Version version) {
> > > 
> > 
> 
> > > > return !unsupportedVersions.contains(version);
> > > 
> > 
> 
> > > > }
> > > 
> > 
> 
> > > > }
> > > 
> > 
> 
> > > > ------------------------------------- END EXAMPLE
> > > > -------------------------------------
> > > 
> > 
> 

> > > > Thoughts?
> > > 
> > 
> 

> > > unless i didn't understand something, this is not good,
> > 
> 
> > > this should stay configurable by the users,
> > 
> 
> > > for example if some user experience some issues with a feature and want
> > > to
> > > turn it off/change the values..
> > 
> 
> > > (not all version configuration are boolean, some are different values to
> > > different versions, like cpu-list)
> > 
> 

> > This is for API level compatibility.
> 
> > If VDSM doesn't support for example hot plug in 3.1 then the user can't
> > just
> > decide that it does and change it.
> 
> > Also, this is not changeable by user since it's not exposed by
> > engine-config
> > (nor should it be).
> 

> some are exposed

If there is such a thing then its a design flaw. 

The only one I see in FeatureSupported class is EnableMACAntiSpoofingFilterRules 
This should be split into 2: 
MACAntiSpoofingFilterRulesSupported - which is used to determine API compatibility 
EnableMACAntiSpoofingFilterRules - which the user can set to determine system behaviour 

I see no reason why to allow user to set EnableMACAntiSpoofingFilterRules=true for 3.0 since it will not work so it's just confusing to him 

> > This is strictly for the engine-VDSM API compatibility, not for other
> > configs
> > which are version specific.
> 

> right, but still user should be able to turn features off in case of
> problems,
> or change in some cases (for example it is possible to add support for more
> power management devices, i know it was done by users)
> no reason to block this

Again not talking about all the config values, strictly the ones that are (or should be) in FeatureSupported class. 

In case we want to allow user to tweak behavior there, we can always do as I suggested for EnableMACAntiSpoofingFilterRules 

> > > > Regards,
> > > 
> > 
> 
> > > > Mike
> > > 
> > 
> 

> > > > > Please share your thoughts on this.
> > > > 
> > > 
> > 
> 

> > > > > Thanks,
> > > > 
> > > 
> > 
> 
> > > > > Kanagaraj
> > > > 
> > > 
> > 
> 

> > > > _______________________________________________
> > > 
> > 
> 
> > > > Engine-devel mailing list
> > > 
> > 
> 
> > > > Engine-devel at ovirt.org
> > > 
> > 
> 
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20131201/a35edfb0/attachment.html>

From emesika at redhat.com  Sun Dec  1 09:58:54 2013
From: emesika at redhat.com (Eli Mesika)
Date: Sun, 1 Dec 2013 04:58:54 -0500 (EST)
Subject: [Engine-devel] Using config values
In-Reply-To: <496533960.21093647.1385888566815.JavaMail.root@redhat.com>
References: <52984D48.1070009@redhat.com> <52987D19.9000203@redhat.com>
	<1299085692.33736696.1385845115835.JavaMail.root@redhat.com>
	<496533960.21093647.1385888566815.JavaMail.root@redhat.com>
Message-ID: <1044736237.33757114.1385891934497.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Omer Frenkel" <ofrenkel at redhat.com>
> To: "Eli Mesika" <emesika at redhat.com>
> Cc: "Dusmant Kumar Pati" <dpati at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
> Sent: Sunday, December 1, 2013 11:02:46 AM
> Subject: Re: [Engine-devel] Using config values
> 
> 
> 
> ----- Original Message -----
> > From: "Eli Mesika" <emesika at redhat.com>
> > To: "Dusmant Kumar Pati" <dpati at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Saturday, November 30, 2013 10:58:35 PM
> > Subject: Re: [Engine-devel] Using config values
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Dusmant Kumar Pati" <dpati at redhat.com>
> > > To: "Kanagaraj" <kmayilsa at redhat.com>, "engine-devel"
> > > <engine-devel at ovirt.org>
> > > Sent: Friday, November 29, 2013 1:40:09 PM
> > > Subject: Re: [Engine-devel] Using config values
> > > 
> > > On 11/29/2013 01:46 PM, Kanagaraj wrote:
> > > 
> > > 
> > > Hi All,
> > > 
> > > The are some issues arising in configurations whenever we move up on the
> > > versions(3.3 => 3.4), because of the way we store and interpret them.
> > > 
> > > Whenever there is a new cluster level, you will need to add a new entry
> > > for
> > > all(most) of the configuration. Mostly a copy paste if you see from 3.2
> > > to
> > > 3.3, except some CPU/PM type related configurations.
> > > Better option would be to have the defaul config value in
> > > ConfigValues.java
> > > and the overrides will go to config.sql. In this approach you don't need
> > > a
> > > new entries to config.sql when there is a new cluster level.
> > > 
> > > Lets take an exmaple, "SupportForceCreateVG" - This is supported from 3.1
> > > onwards,
> > > 
> > > If you look at config.sql, you will see following entries
> > > select fn_db_add_config_value('SupportForceCreateVG','false','3.0');
> > > select fn_db_add_config_value('SupportForceCreateVG','true','3.1');
> > > select fn_db_add_config_value('SupportForceCreateVG','true','3.2');
> > > select fn_db_add_config_value('SupportForceCreateVG','true','3.3');
> > > 
> > > And in ConfigValues.java
> > > 
> > > @TypeConverterAttribute(Boolean.class)
> > > @DefaultValueAttribute("false")
> > > SupportForceCreateVG,
> > > 
> > > Now if there is 3.4 and 3.5, the user needs to add 2 more entries, which
> > > i
> > > feel is redundant.
> > > 
> > > Instead we can make
> > > 
> > > @TypeConverterAttribute(Boolean.class)
> > > @DefaultValueAttribute("true")
> > > SupportForceCreateVG,
> > > 
> > > and have only the following in config.sql
> > > select fn_db_add_config_value('SupportForceCreateVG','false','3.0');
> > > 
> > > if a particular value(for a specific cluster level) is not found in
> > > Config.sql, the fallback is to use the value available in
> > > ConfigValues.java.
> > > 
> > > Please share your thoughts on this.
> > 
> > Hi
> > 
> > First of all I think its a good idea
> > I have 2 questions
> > 
> > 1) Which value will be stored as default in the java class for
> > configuration
> > values that are not a boolean, that represents if a feature is active or
> > not.
> >    Is that the latest version value ? sounds not obvious to me
> > 
> 
> i guess this will have to have a configuration values for each version in the
> db.
> 
> > 2) There are some configuration values that are exposed to the user via the
> > engine-config tool, how this will work, we can not remove the entries their
> > since the user may change and override those values.
> > 
> 
> in your suggestion below, there is the same issue,
> if user want to change the 3.3 value, engine config will fail with "No such
> entry"
> because 3.3 will not be in the db..
> so if we are not fixing this, i think using the current implementation is
> good enough,

In this case engine-config will add this key with the given value for that version, so , I see no problem in that...
In addition the getConfigValue will lookup for version matching only the first time, so , if it was given a 3.4 version for key K and found a matching only for 3.2 , it will add to the cache K with the same value for version 3.4



> no need to add logic, just to convert current options that are not in this
> format, to use this logic.
> 
> > I have a different suggestion:
> > Default value will stay as is , meaning , it will reflect the value that
> > should be used to keep the application running correctly if a value is not
> > found in DB (which should not occur)
> > 
> > Code of getting configuration value (getConfigValue(<key>,<version>) will
> > be
> > changed to get the closest version value to the given one.
> > For example , if a 3.4 version is given for a given <key> and we have in DB
> > just values for 3.0 and 3.1 , the 3.1 value is returned.
> > I prefer this solution since it makes the config.sql file self documented ,
> > showing only value changes and in which version each change occurred.
> > 
> > To implement that, we should add this mechanism to the current code that
> > caches the DB content and as I see that it should be a simple change.
> > engine-config should be modified such that if the user change a value, this
> > value will be inserted to the database with the current release if not
> > exists and then the mechanism described above will get this value
> > 
> > Example:
> > 
> > VdsFenceType lists all the supported fencing agents for power management ,
> > it
> > currently has the following settings
> > 
> >                                        option_value
> >                                        |
> >                                        version
> > ---------------------------------------------------------------------------------------------+---------
> >  alom,apc,bladecenter,drac5,eps,ilo,ilo3,ipmilan,rsa,rsb,wti,cisco_ucs
> >  | 3.0
> >  alom,apc,bladecenter,drac5,eps,ilo,ilo3,ipmilan,rsa,rsb,wti,cisco_ucs
> >  | 3.1
> >  apc,apc_snmp,bladecenter,cisco_ucs,drac5,eps,ilo,ilo2,ilo3,ilo4,ipmilan,rsa,rsb,wti
> >  | 3.2
> >  apc,apc_snmp,bladecenter,cisco_ucs,drac5,eps,ilo,ilo2,ilo3,ilo4,ipmilan,rsa,rsb,wti
> >  | 3.3
> > 
> > In the proposed solution, we will have
> > 
> >                                        option_value
> >                                        |
> >                                        version
> > ---------------------------------------------------------------------------------------------+---------
> >  alom,apc,bladecenter,drac5,eps,ilo,ilo3,ipmilan,rsa,rsb,wti,cisco_ucs
> >  | 3.0
> >  apc,apc_snmp,bladecenter,cisco_ucs,drac5,eps,ilo,ilo2,ilo3,ilo4,ipmilan,rsa,rsb,wti
> >  | 3.2
> > 
> > This is clear and documents only the changes done between versions and
> > serve
> > all values: boolean , string and complex type (those which requires any
> > kind
> > of parsing)
> > 
> > What do you think?
> > 
> > Eli
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >  
> > 
> > 
> > 
> >   
> > 
> > 
> > > 
> > > Thanks,
> > > Kanagaraj
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > Engine-devel mailing list Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > I think, this is a good suggestion...
> > > 
> > > 
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 


From rnachimu at redhat.com  Mon Dec  2 05:22:53 2013
From: rnachimu at redhat.com (Ramesh)
Date: Mon, 02 Dec 2013 10:52:53 +0530
Subject: [Engine-devel] Adding users and assigning roles in Ovirt
Message-ID: <529C192D.106@redhat.com>

Hi All,

   We have 'Add' action under 'Users' main tab to add users in Ovirt . 
It looks slightly different from the "Add user" option of the Configure 
option. Actually, this one is missing the "Role to Assign" option. I 
think without assigning any role, adding a user is not meaningful and it 
didn't complete the flow.

   Currently to assign any role to the user, either we have to use 
'Configure' option ( to add system permission) or we have to go to the 
specific entity and add permission for that entity. It will be nice if 
we can assign roles( system level permissions) while adding users in 
'Users' tab itself. It will be a clear user flow where one can add user 
and assign role in the same place.

I have attached both the screen shots.

please share your thoughts.

Regards,
Ramesh

-------------- next part --------------
A non-text attachment was scrubbed...
Name: AddUserFromConfigureOption.jpg
Type: image/jpeg
Size: 65424 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20131202/8f214f92/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AddUserFromUsersTab.jpg
Type: image/jpeg
Size: 185433 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20131202/8f214f92/attachment-0001.jpg>

From ovedo at redhat.com  Mon Dec  2 07:01:52 2013
From: ovedo at redhat.com (Oved Ourfalli)
Date: Mon, 2 Dec 2013 02:01:52 -0500 (EST)
Subject: [Engine-devel] Adding users and assigning roles in Ovirt
In-Reply-To: <529C192D.106@redhat.com>
References: <529C192D.106@redhat.com>
Message-ID: <1286130035.32994182.1385967712137.JavaMail.root@redhat.com>

Your E-mail made me look a bit and check the different flows.

I think the only use-case for adding users without giving any permissions is when you add a user for notification reasons.
You can add a user, and then in the Event Notifier sub-tab define what events he will get via E-mail.
afaik (and I'm not an event notifier expert), this user doesn't have to be able to login, or to have permissions of any kind. He just gets events.

Other than that you're right. A user which is added to the system can't do much without assigning him roles.
I think adding roles assignment to this dialog may be a bit cumbersome. Perhaps some wizard is required in that case. Or at least some checkbox saying "allow user to login". That way the new user will be able to login, and he will have some default permissions as well (permissions granted to Everyone).

Let's see what others think.

Regards,
Oved


----- Original Message -----
> From: "Ramesh" <rnachimu at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Monday, December 2, 2013 7:22:53 AM
> Subject: [Engine-devel] Adding users and assigning roles in Ovirt
> 
> Hi All,
> 
>    We have 'Add' action under 'Users' main tab to add users in Ovirt .
> It looks slightly different from the "Add user" option of the Configure
> option. Actually, this one is missing the "Role to Assign" option. I
> think without assigning any role, adding a user is not meaningful and it
> didn't complete the flow.
> 
>    Currently to assign any role to the user, either we have to use
> 'Configure' option ( to add system permission) or we have to go to the
> specific entity and add permission for that entity. It will be nice if
> we can assign roles( system level permissions) while adding users in
> 'Users' tab itself. It will be a clear user flow where one can add user
> and assign role in the same place.
> 
> I have attached both the screen shots.
> 
> please share your thoughts.
> 
> Regards,
> Ramesh
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From gchaplik at redhat.com  Mon Dec  2 08:47:56 2013
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Mon, 2 Dec 2013 03:47:56 -0500 (EST)
Subject: [Engine-devel] Adding users and assigning roles in Ovirt
In-Reply-To: <1286130035.32994182.1385967712137.JavaMail.root@redhat.com>
References: <529C192D.106@redhat.com>
	<1286130035.32994182.1385967712137.JavaMail.root@redhat.com>
Message-ID: <1561192373.43408976.1385974076894.JavaMail.root@redhat.com>

Hi Ramesh,

You're right, I also think that the 'add users' is a bit pointless, but adding a system permission in that dialog can be dangerous (if admin doesn't fully understand what he's doing, and MLA is complicated enough ;-) ).

Currently when adding a permission we can specify a AD-user (regardless to the fact he's added or not), So eventually power users can add users to the system.
I can think of a case, that admins will want to manage the users by themselves, i.e- power users can add permissions for the added users only.
this way this dialog can be useful.

Thanks, 
Gilad.

----- Original Message -----
> From: "Oved Ourfalli" <ovedo at redhat.com>
> To: "Ramesh" <rnachimu at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Monday, December 2, 2013 9:01:52 AM
> Subject: Re: [Engine-devel] Adding users and assigning roles in Ovirt
> 
> Your E-mail made me look a bit and check the different flows.
> 
> I think the only use-case for adding users without giving any permissions is
> when you add a user for notification reasons.
> You can add a user, and then in the Event Notifier sub-tab define what events
> he will get via E-mail.
> afaik (and I'm not an event notifier expert), this user doesn't have to be
> able to login, or to have permissions of any kind. He just gets events.
> 
> Other than that you're right. A user which is added to the system can't do
> much without assigning him roles.
> I think adding roles assignment to this dialog may be a bit cumbersome.
> Perhaps some wizard is required in that case. Or at least some checkbox
> saying "allow user to login". That way the new user will be able to login,
> and he will have some default permissions as well (permissions granted to
> Everyone).
> 
> Let's see what others think.
> 
> Regards,
> Oved
> 
> 
> ----- Original Message -----
> > From: "Ramesh" <rnachimu at redhat.com>
> > To: engine-devel at ovirt.org
> > Sent: Monday, December 2, 2013 7:22:53 AM
> > Subject: [Engine-devel] Adding users and assigning roles in Ovirt
> > 
> > Hi All,
> > 
> >    We have 'Add' action under 'Users' main tab to add users in Ovirt .
> > It looks slightly different from the "Add user" option of the Configure
> > option. Actually, this one is missing the "Role to Assign" option. I
> > think without assigning any role, adding a user is not meaningful and it
> > didn't complete the flow.
> > 
> >    Currently to assign any role to the user, either we have to use
> > 'Configure' option ( to add system permission) or we have to go to the
> > specific entity and add permission for that entity. It will be nice if
> > we can assign roles( system level permissions) while adding users in
> > 'Users' tab itself. It will be a clear user flow where one can add user
> > and assign role in the same place.
> > 
> > I have attached both the screen shots.
> > 
> > please share your thoughts.
> > 
> > Regards,
> > Ramesh
> > 
> > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From jhernand at redhat.com  Mon Dec  2 08:57:17 2013
From: jhernand at redhat.com (Juan Hernandez)
Date: Mon, 02 Dec 2013 09:57:17 +0100
Subject: [Engine-devel] Increasing the HTTP keep alive to 30 seconds
Message-ID: <529C4B6D.4080006@redhat.com>

Hello,

We have an RFE that has been open for quite a long time requesting an
increase of the keep alive time in the HTTP communications between the
GUI applications and the web server:

https://bugzilla.redhat.com/833799

Implementing it should be as simple as modifying the setup application
so that it includes the modified KeepAlive directives in the web server
configuration, something like this:

KeepAlive on
KeepAliveTimeout 30

Is someone with knowledge of the setup application interested on taking
this?

Regards,
Juan Hernandez
-- 
Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3?D, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat S.L.


From ecohen at redhat.com  Mon Dec  2 17:30:45 2013
From: ecohen at redhat.com (Einav Cohen)
Date: Mon, 2 Dec 2013 12:30:45 -0500 (EST)
Subject: [Engine-devel] Remove Comment column in main tabs
In-Reply-To: <1993200129.42184923.1385618604601.JavaMail.root@redhat.com>
References: <1370005434.40758795.1385448274315.JavaMail.root@redhat.com>
	<246185107.31436601.1385495640948.JavaMail.root@redhat.com>
	<128970096.16796135.1385500794982.JavaMail.root@redhat.com>
	<319931619.31531966.1385503424736.JavaMail.root@redhat.com>
	<1474811117.17678021.1385558318419.JavaMail.root@redhat.com>
	<178932064.31886562.1385562261282.JavaMail.root@redhat.com>
	<1290384231.17884950.1385565383762.JavaMail.root@redhat.com>
	<1993200129.42184923.1385618604601.JavaMail.root@redhat.com>
Message-ID: <1740158774.21709080.1386005445607.JavaMail.root@redhat.com>

> I opened a bug for this: https://bugzilla.redhat.com/show_bug.cgi?id=1035566
> While at it, I also opened a BZ to fixate the icon column size:
> https://bugzilla.redhat.com/show_bug.cgi?id=1035567

Thanks, Mike.

> Not sure but I think these bugs should be fixed (if and when) for user portal
> as well..

I think that the comment field is not displayed in the user portal at all (maybe 
need a separate RFE?);
regarding icon columns - there is a chance that there are some icon columns in 
the sub-tabs within the power-user portal, which should indeed be taken care of. 

----
Regards,
Einav

----- Original Message -----
> From: "Mike Kolesnik" <mkolesni at redhat.com>
> To: "Einav Cohen" <ecohen at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Thursday, November 28, 2013 1:03:24 AM
> Subject: Re: [Engine-devel] Remove Comment column in main tabs
> 
> ----- Original Message -----
> > > For the reasons stated in my earlier comment, let's place this column to
> > > the
> > > right of the name.
> > 
> > I am OK with that.
> > @Mike/others - any objections for placing the Comment column with an
> > icon-ed
> > tooltip-ed title to the right of the Name column?
> 
> No objections, I'm actually +1 for it :)
> 
> > [are we tracking it in a BZ? is someone volunteering to take care of this?]
> 
> I opened a bug for this: https://bugzilla.redhat.com/show_bug.cgi?id=1035566
> While at it, I also opened a BZ to fixate the icon column size:
> https://bugzilla.redhat.com/show_bug.cgi?id=1035567
> 
> Not sure but I think these bugs should be fixed (if and when) for user portal
> as well..
> 
> > 
> > > OK.. so we are on the same page and potentially, it can then be
> > > incorporated
> > > into a sort sequence of the name column.
> > 
> > Malini, I missed your earlier reference to sort sequence, I apologize.
> > I am not familiar with sort sequence other than Ascending/Descending;
> > do you happen to have an example for something that uses sort sequence
> > for something other than/in addition to Ascending/Descending? It sounds
> > interesting.
> > 
> > ----
> > Thanks,
> > Einav
> > 
> > ----- Original Message -----
> > > From: "Malini Rao" <mrao at redhat.com>
> > > To: "Einav Cohen" <ecohen at redhat.com>
> > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Wednesday, November 27, 2013 9:24:21 AM
> > > Subject: Re: [Engine-devel] Remove Comment column in main tabs
> > > 
> > > --- Original Message -----
> > > > From: "Einav Cohen" <ecohen at redhat.com>
> > > > To: "Malini Rao" <mrao at redhat.com>
> > > > Cc: "engine-devel" <engine-devel at ovirt.org>, "Mike Kolesnik"
> > > > <mkolesni at redhat.com>
> > > > Sent: Wednesday, November 27, 2013 8:18:38 AM
> > > > Subject: Re: [Engine-devel] Remove Comment column in main tabs
> > > > 
> > > > > That is a good point. I guess the question is if sorting will be
> > > > > necessary
> > > > > on
> > > > > comments since it is available on hover only anyway and I am not sure
> > > > > an
> > > > > alphabetical sort would be very useful in finding a particular
> > > > > comment
> > > > 
> > > > what I had in mind is Boolean sorting (i.e. similar to sorting
> > > > according
> > > > to
> > > > the 'attachment' field in e-mail - sort by existence, and not by
> > > > content).
> > > 
> > > OK.. so we are on the same page and potentially, it can then be
> > > incorporated
> > > into a sort sequence of the name column.
> > > 
> > > > 
> > > > > If the comment is relatively unimportant, then I think it would be
> > > > > reasonable
> > > > > to leave it where it is today.
> > > > 
> > > > In my view (and I think that Mike implied that on his last reply as
> > > > well),
> > > > the comment can be pretty important; the comment is meant for dynamic
> > > > notifications on the object. So I would imagine a comment to be
> > > > something
> > > > like "!! do not shutdown this VM! it is being installed with xyz!!"
> > > > which
> > > > is probably important enough to not be "hidden" in a distant column.
> > > > 
> > > > [my suggestion earlier to keep it in its current location was merely
> > > > for
> > > > doing minimal changes, without changing anything in the primary-columns
> > > > area or "making things worse" comment-wise, while saving real-estate;
> > > > but
> > > > if we can easily do a change that will also make the 'comment' column
> > > > more
> > > > noticeable, it is better]
> > > 
> > > I am sure many examples abound for good and not so god paradigms. Even
> > > though
> > > I recommend other means of displaying info that apply only to some cases
> > > instead of dedicating a column for it, to come to a consensus for the
> > > short
> > > term, I think we can all agree to place this column to the right of the
> > > name
> > > column. This way, it is separated from the other two icons but still
> > > close
> > > to the name to gather attention.
> > > 
> > > > 
> > > > > Maybe if we decide not to implement the recommendation I sent
> > > > > earlier,
> > > > > we
> > > > > could move the comment column to display after the name column. This
> > > > > way
> > > > > it
> > > > > is not lost at the very end esp because its presence is known only
> > > > > via
> > > > > a
> > > > > small icon.
> > > > 
> > > > I don't feel strongly one way or another; I think it is acceptable to
> > > > make
> > > > this column adjacent to the 'Name' column either on its left or right
> > > > side
> > > > (see also Mike's Gmail example from his last reply on this thread - it
> > > > is
> > > > really not that bad, in my view, to have another column to the left).
> > > 
> > > For the reasons stated in my earlier comment, let's place this column to
> > > the
> > > right of the name.
> > > 
> > > Thanks
> > > Malini
> > > > 
> > > > -----
> > > > Thanks,
> > > > Einav
> > > > 
> > > > 
> > > > > ----- Original Message -----
> > > > > From: "Malini Rao" <mrao at redhat.com>
> > > > > Sent: Tuesday, November 26, 2013 5:03:44 PM
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Einav Cohen" <ecohen at redhat.com>
> > > > > > To: "Malini Rao" <mrao at redhat.com>
> > > > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > > Sent: Tuesday, November 26, 2013 4:19:55 PM
> > > > > > Subject: Re: [Engine-devel] Remove Comment column in main tabs
> > > > > > 
> > > > > > Hi Malini,
> > > > > > 
> > > > > > > This could work but I am not a big fan of simply adding iconic
> > > > > > > columns
> > > > > > > preceding the name. This is actually a good example where 2 icon
> > > > > > > columns
> > > > > > > are
> > > > > > > already there and adding another column is making the primary
> > > > > > > column
> > > > > > > (
> > > > > > > i.e
> > > > > > > the name column) not seem like the first column the eye focuses
> > > > > > > on.
> > > > > > 
> > > > > > not sure that I completely agree with that: if I am taking my
> > > > > > e-mail
> > > > > > client,
> > > > > > for example - it has a lot of icon columns that precede the primary
> > > > > > columns
> > > > > > ('From', 'Subject'), however I don't think that it makes the
> > > > > > primary
> > > > > > columns
> > > > > > any less 'catchy' (see attached
> > > > > > 'e-mail-client--a-lot-of-preceding-icons.png').
> > > > > > Having said that - it may depend on the actual content of the icon
> > > > > > columns
> > > > > > (i.e. in my e-mail example, the icon-columns are mostly empty,
> > > > > > whereas
> > > > > > in
> > > > > > the
> > > > > > VMs main tab example, at least the 'status' and 'vm-type' icon
> > > > > > columns
> > > > > > are
> > > > > > expected to always contain some icon), so not sure.
> > > > > 
> > > > > Einav, I do take your point. That said, I don't think the screenshot
> > > > > you
> > > > > sent
> > > > > me would be considered a good example of something well designed - at
> > > > > least
> > > > > not in terms of the number of columns with icons. Also, it kind of
> > > > > works
> > > > > because the subject column which is possibly what the user will focus
> > > > > on
> > > > > is
> > > > > the widest.
> > > > > 
> > > > > > 
> > > > > > > I understand that it is not as easy implementation-wise but in
> > > > > > > the
> > > > > > > effort
> > > > > > > to
> > > > > > > start moving towards a more elegant solution, I am wondering if
> > > > > > > we
> > > > > > > can
> > > > > > > cash
> > > > > > > in on what users may have learned in spreadsheet software and use
> > > > > > > a
> > > > > > > dog
> > > > > > > ear
> > > > > > > image at the corner of the name cell ( See attached). This way,
> > > > > > > we
> > > > > > > are
> > > > > > > not
> > > > > > > dedicating any more space and it does not take away space
> > > > > > > allotted
> > > > > > > to
> > > > > > > the
> > > > > > > text string either. The visual details of the icon are not final
> > > > > > > and
> > > > > > > this
> > > > > > > is
> > > > > > > sent to communicate an idea only. If we agree on this, I will
> > > > > > > send
> > > > > > > the
> > > > > > > final
> > > > > > > icon to use.
> > > > > > 
> > > > > > this solution is nice and elegant - I like it;
> > > > > > my main concern is that I am not sure how will we be able to sort
> > > > > > the
> > > > > > items
> > > > > > by that field if we won't have a dedicated column for it (once
> > > > > > column
> > > > > > sorting
> > > > > > will be available in general, of course).
> > > > > 
> > > > > That is a good point. I guess the question is if sorting will be
> > > > > necessary
> > > > > on
> > > > > comments since it is available on hover only anyway and I am not sure
> > > > > an
> > > > > alphabetical sort would be very useful in finding a particular
> > > > > comment.
> > > > > In
> > > > > general, once we have that feature, it may be worthwhile to consider
> > > > > what
> > > > > columns need sorting and not necessarily have every available column
> > > > > in
> > > > > the
> > > > > list have that ability. What could be useful in this case is to sort
> > > > > by
> > > > > all
> > > > > the rows that do have a comment on them and that could potentially be
> > > > > incorporated into the sort sequence - for e.g, unsorted, alphanumeric
> > > > > Asc,alphanumeric desc, presence of comment on top, unsorted.
> > > > > 
> > > > > 
> > > > > > my other concern is indeed the implementation effort that would
> > > > > > need
> > > > > > to
> > > > > > be
> > > > > > involved in it.
> > > > > > 
> > > > > > Question is if it is something that is worth considering if we
> > > > > > decide
> > > > > > that
> > > > > > the
> > > > > > extra-icon-column solution is acceptable.
> > > > > 
> > > > > The extra-icon-column solution is not whacky or unacceptable but it
> > > > > creates
> > > > > these empty spaces or tiled patterns depending on whether it is
> > > > > filled
> > > > > or
> > > > > not and it also takes up space all the time.
> > > > > 
> > > > > > 
> > > > > > Another option (at least for the short term) for solving the
> > > > > > real-estate
> > > > > > problem
> > > > > > without changing anything in the primary column area is to keep the
> > > > > > 'Comment'
> > > > > > column in its current location, only replace its textual title with
> > > > > > an
> > > > > > icon
> > > > > > title
> > > > > > (see attached 'move-comment-column--option-1-variation.png').
> > > > > 
> > > > > I was thinking along these lines as well. Maybe if we decide not to
> > > > > implement
> > > > > the recommendation I sent earlier, we could move the comment column
> > > > > to
> > > > > display after the name column. This way it is not lost at the very
> > > > > end
> > > > > esp
> > > > > because its presence is known only via a small icon. If the comment
> > > > > is
> > > > > relatively unimportant, then I think it would be reasonable to leave
> > > > > it
> > > > > where it is today.
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > Thoughts?
> > > > > > > 
> > > > > > > -Malini
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > From: "Einav Cohen" <ecohen at redhat.com>
> > > > > > > To: "Daniel Erez" <derez at redhat.com>
> > > > > > > Cc: "Malini Rao" <mrao at redhat.com>, "Mike Kolesnik"
> > > > > > > <mkolesni at redhat.com>,
> > > > > > > "engine-devel" <engine-devel at ovirt.org>
> > > > > > > Sent: Tuesday, November 26, 2013 11:44:49 AM
> > > > > > > Subject: Re: [Engine-devel] Remove Comment column in main tabs
> > > > > > > 
> > > > > > > > ----- Original Message -----
> > > > > > > > From: "Daniel Erez" <derez at redhat.com>
> > > > > > > > Sent: Tuesday, November 26, 2013 11:24:30 AM
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > ----- Original Message -----
> > > > > > > > > From: "Einav Cohen" <ecohen at redhat.com>
> > > > > > > > > To: "Malini Rao" <mrao at redhat.com>, "Mike Kolesnik"
> > > > > > > > > <mkolesni at redhat.com>
> > > > > > > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > > > > > Sent: Tuesday, November 26, 2013 6:17:18 PM
> > > > > > > > > Subject: Re: [Engine-devel] Remove Comment column in main
> > > > > > > > > tabs
> > > > > > > > > 
> > > > > > > > > > ----- Original Message -----
> > > > > > > > > > From: "Malini Rao" <mrao at redhat.com>
> > > > > > > > > > Sent: Tuesday, November 26, 2013 11:06:17 AM
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > From: "Eli Mesika" <emesika at redhat.com>
> > > > > > > > > > > To: "Mike Kolesnik" <mkolesni at redhat.com>
> > > > > > > > > > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > > > > > > > Sent: Tuesday, November 26, 2013 4:05:37 AM
> > > > > > > > > > > Subject: Re: [Engine-devel] Remove Comment column in main
> > > > > > > > > > > tabs
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > ----- Original Message -----
> > > > > > > > > > > > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > > > > > > > > > > > To: "engine-devel" <engine-devel at ovirt.org>
> > > > > > > > > > > > Sent: Tuesday, November 26, 2013 8:44:34 AM
> > > > > > > > > > > > Subject: [Engine-devel] Remove Comment column in main
> > > > > > > > > > > > tabs
> > > > > > > > > > > > 
> > > > > > > > > > > > Hi,
> > > > > > > > > > > > 
> > > > > > > > > > > > When the comment RFE was added (in 3.3), there was also
> > > > > > > > > > > > a
> > > > > > > > > > > > column
> > > > > > > > > > > > added
> > > > > > > > > > > > to
> > > > > > > > > > > > many main tabs.
> > > > > > > > > > > > 
> > > > > > > > > > > > I would like to propose to get rid of the column (which
> > > > > > > > > > > > can
> > > > > > > > > > > > only
> > > > > > > > > > > > house
> > > > > > > > > > > > one
> > > > > > > > > > > > icon or no icon),
> > > > > > > > > > > > and instead if there's a comment on an entity just
> > > > > > > > > > > > display
> > > > > > > > > > > > the
> > > > > > > > > > > > icon
> > > > > > > > > > > > with
> > > > > > > > > > > > the
> > > > > > > > > > > > tooltip adjacent to the name.
> > > > > > > > > > > > 
> > > > > > > > > > > > In this case the icon should probably be scaled down a
> > > > > > > > > > > > bit
> > > > > > > > > > > > since
> > > > > > > > > > > > its
> > > > > > > > > > > > huge.
> > > > > > > > > > > > 
> > > > > > > > > > > > I think this would be a good alternative and save us
> > > > > > > > > > > > some
> > > > > > > > > > > > valued
> > > > > > > > > > > > screen
> > > > > > > > > > > > real
> > > > > > > > > > > > estate.
> > > > > > > > > > > > 
> > > > > > > > > > > > Thoughts, opinions?
> > > > > > > > > > > 
> > > > > > > > > > > +1
> > > > > > > > > > 
> > > > > > > > > > +1. But isn't there a limitation on appending an icon to a
> > > > > > > > > > column
> > > > > > > > > > that
> > > > > > > > > > already has content? Also to fully consider pros and cons -
> > > > > > > > > > if
> > > > > > > > > > it
> > > > > > > > > > is
> > > > > > > > > > possible, we have to think of where to append this icon -
> > > > > > > > > > prefix
> > > > > > > > > > or
> > > > > > > > > > suffix.
> > > > > > > > > > If we prefix, then it is likely that some names will be
> > > > > > > > > > preceded
> > > > > > > > > > by
> > > > > > > > > > 2
> > > > > > > > > > icons
> > > > > > > > > > because many of our lists have an icon already in the first
> > > > > > > > > > column.
> > > > > > > > > > If
> > > > > > > > > > it
> > > > > > > > > > is
> > > > > > > > > > suffixed, the relative position on the icon will change
> > > > > > > > > > based
> > > > > > > > > > on
> > > > > > > > > > how
> > > > > > > > > > long
> > > > > > > > > > the name is and if the object names tend to be long, then
> > > > > > > > > > potentially,
> > > > > > > > > > the
> > > > > > > > > > icon is taking some room away.
> > > > > > > > > 
> > > > > > > > > see attached two options (both comparing the current state
> > > > > > > > > and
> > > > > > > > > a
> > > > > > > > > suggested
> > > > > > > > > state in the VMs main tab) - not sure which one Mike had in
> > > > > > > > > mind.
> > > > > > > > > option #1 is easy to implement while option #2, as Malini
> > > > > > > > > mentioned,
> > > > > > > > > may
> > > > > > > > > be more difficult to implement.
> > > > > > > > > also need to keep in mind that the today, the comment column
> > > > > > > > > real-estate
> > > > > > > > > is
> > > > > > > > > taken mostly by the column title; therefore if we lose the
> > > > > > > > > title,
> > > > > > > > > we
> > > > > > > > > should
> > > > > > > > > indicate in some other manner that this is the comment field
> > > > > > > > > of
> > > > > > > > > the
> > > > > > > > > object
> > > > > > > > > (e.g. within the tooltip - also demonstrated in the
> > > > > > > > > attached).
> > > > > > > > 
> > > > > > > > +1
> > > > > > > > I think that an image header might be a good solution.
> > > > > > > > E.g. an image of a post-it note instead of the title.
> > > > > > > 
> > > > > > > good idea - we can display a "comment" tool-tip when hovering on
> > > > > > > the
> > > > > > > title-icon
> > > > > > > and, like today, display only the comment value within the
> > > > > > > tool-tip
> > > > > > > when
> > > > > > > hovering
> > > > > > > on the regular-row-icon (see attached).
> > > > > > > [we already have icon-column-titles in the application, e.g.
> > > > > > > "shareable",
> > > > > > > "bootable"
> > > > > > > in the Disks grid, so it shouldn't be hard to implement]
> > > > > > > 
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > Also worth considering is the fact that if we prefix the
> > > > > > > > > > icon
> > > > > > > > > > only
> > > > > > > > > > on
> > > > > > > > > > the
> > > > > > > > > > rows where it is needed, it will be in a position that will
> > > > > > > > > > definitely
> > > > > > > > > > grab
> > > > > > > > > > attention. So, it may be worthwhile to see if this is the
> > > > > > > > > > icon
> > > > > > > > > > that
> > > > > > > > > > we
> > > > > > > > > > should place here or if there is any other icon that
> > > > > > > > > > deserves
> > > > > > > > > > this
> > > > > > > > > > attention
> > > > > > > > > > in a consistent manner across entities.
> > > > > > > > > > 
> > > > > > > > > > While on the topic, it will also be a great idea IMHO to
> > > > > > > > > > take
> > > > > > > > > > a
> > > > > > > > > > look
> > > > > > > > > > at
> > > > > > > > > > our
> > > > > > > > > > various lists and see what columns are actually valuable
> > > > > > > > > > for
> > > > > > > > > > a
> > > > > > > > > > default
> > > > > > > > > > display. I think we are working on adding the ability to
> > > > > > > > > > select
> > > > > > > > > > columns
> > > > > > > > > > for
> > > > > > > > > > display and so the columns that we remove can be added back
> > > > > > > > > > in
> > > > > > > > > > by
> > > > > > > > > > users
> > > > > > > > > > when
> > > > > > > > > > they want but do not sit there taking up room permanently.
> > > > > > > > > > If
> > > > > > > > > > anyone
> > > > > > > > > > has
> > > > > > > > > > ideas on what the default columns should be for one or many
> > > > > > > > > > of
> > > > > > > > > > the
> > > > > > > > > > lists
> > > > > > > > > > in
> > > > > > > > > > our product, do send it to me. I will be willing to compile
> > > > > > > > > > and
> > > > > > > > > > consolidate
> > > > > > > > > > the list and then post it back to the group for
> > > > > > > > > > consideration.
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > Regards,
> > > > > > > > > > > > Mike
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > _______________________________________________
> > > > > > > > > > > > Engine-devel mailing list
> > > > > > > > > > > > Engine-devel at ovirt.org
> > > > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > > > > > > 
> > > > > > > > > > > _______________________________________________
> > > > > > > > > > > Engine-devel mailing list
> > > > > > > > > > > Engine-devel at ovirt.org
> > > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > > > > > 
> > > > > > > > > > _______________________________________________
> > > > > > > > > > Engine-devel mailing list
> > > > > > > > > > Engine-devel at ovirt.org
> > > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > _______________________________________________
> > > > > > > > > Engine-devel mailing list
> > > > > > > > > Engine-devel at ovirt.org
> > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > > > 
> > > > > > > > 
> > > > > > > 
> > > > > > > _______________________________________________
> > > > > > > Engine-devel mailing list
> > > > > > > Engine-devel at ovirt.org
> > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > >
> > > > > _______________________________________________
> > > > > Engine-devel mailing list
> > > > > Engine-devel at ovirt.org
> > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > 
> > > > > 
> > > > > 
> > > > 
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > > 
> > > 
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> 
> 


From ecohen at redhat.com  Mon Dec  2 18:37:57 2013
From: ecohen at redhat.com (Einav Cohen)
Date: Mon, 2 Dec 2013 13:37:57 -0500 (EST)
Subject: [Engine-devel] Adding users and assigning roles in Ovirt
In-Reply-To: <1561192373.43408976.1385974076894.JavaMail.root@redhat.com>
References: <529C192D.106@redhat.com>
	<1286130035.32994182.1385967712137.JavaMail.root@redhat.com>
	<1561192373.43408976.1385974076894.JavaMail.root@redhat.com>
Message-ID: <1960288549.21771993.1386009477305.JavaMail.root@redhat.com>

we should definitely not completely remove the possibility to add permission-less users to the system, 
due to possible use-cases as Gilad mentioned and/or simply to allow the flexibility of adding the user 
first, and only then adding the relevant (business entity and) permissions, should the admin choose to 
do so. 

the more correct location to add system permissions to a user would probably be a 'Add System Permission' 
dialog that will be available from the Permissions sub-tab of the Users main tab, however it won't allow 
to assign system permissions to several users at once, so I understand the need for this ability within 
the 'Add User(s)' dialog. 

I think that adding an "allow user to login" check-box would not be good enough, since once a user 
would be able to login, he won't be able to do (or even see) anything (well, other than the 'Blank' 
Template, maybe), so the admin would need to assign additional permissions to this user anyway. 
The minimal solution in my view is to add a "assign these users the following system permissions" 
check-box, with a Roles drop down; as Gilad mentioned - need to be very careful with that, as 
system-wide permissions are powerful. 
A more comprehensive solution (more complex for implementation) would probably be, as Oved mentioned, 
some sort of a user-adding-wizard, that will allow easy permissions-assignment (maybe even not only 
system-wide permissions) to the newly-added users. 

----
Thanks,
Einav

----- Original Message -----
> From: "Gilad Chaplik" <gchaplik at redhat.com>
> To: "Oved Ourfalli" <ovedo at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Monday, December 2, 2013 3:47:56 AM
> Subject: Re: [Engine-devel] Adding users and assigning roles in Ovirt
> 
> Hi Ramesh,
> 
> You're right, I also think that the 'add users' is a bit pointless, but
> adding a system permission in that dialog can be dangerous (if admin doesn't
> fully understand what he's doing, and MLA is complicated enough ;-) ).
> 
> Currently when adding a permission we can specify a AD-user (regardless to
> the fact he's added or not), So eventually power users can add users to the
> system.
> I can think of a case, that admins will want to manage the users by
> themselves, i.e- power users can add permissions for the added users only.
> this way this dialog can be useful.
> 
> Thanks,
> Gilad.
> 
> ----- Original Message -----
> > From: "Oved Ourfalli" <ovedo at redhat.com>
> > To: "Ramesh" <rnachimu at redhat.com>
> > Cc: engine-devel at ovirt.org
> > Sent: Monday, December 2, 2013 9:01:52 AM
> > Subject: Re: [Engine-devel] Adding users and assigning roles in Ovirt
> > 
> > Your E-mail made me look a bit and check the different flows.
> > 
> > I think the only use-case for adding users without giving any permissions
> > is
> > when you add a user for notification reasons.
> > You can add a user, and then in the Event Notifier sub-tab define what
> > events
> > he will get via E-mail.
> > afaik (and I'm not an event notifier expert), this user doesn't have to be
> > able to login, or to have permissions of any kind. He just gets events.
> > 
> > Other than that you're right. A user which is added to the system can't do
> > much without assigning him roles.
> > I think adding roles assignment to this dialog may be a bit cumbersome.
> > Perhaps some wizard is required in that case. Or at least some checkbox
> > saying "allow user to login". That way the new user will be able to login,
> > and he will have some default permissions as well (permissions granted to
> > Everyone).
> > 
> > Let's see what others think.
> > 
> > Regards,
> > Oved
> > 
> > 
> > ----- Original Message -----
> > > From: "Ramesh" <rnachimu at redhat.com>
> > > To: engine-devel at ovirt.org
> > > Sent: Monday, December 2, 2013 7:22:53 AM
> > > Subject: [Engine-devel] Adding users and assigning roles in Ovirt
> > > 
> > > Hi All,
> > > 
> > >    We have 'Add' action under 'Users' main tab to add users in Ovirt .
> > > It looks slightly different from the "Add user" option of the Configure
> > > option. Actually, this one is missing the "Role to Assign" option. I
> > > think without assigning any role, adding a user is not meaningful and it
> > > didn't complete the flow.
> > > 
> > >    Currently to assign any role to the user, either we have to use
> > > 'Configure' option ( to add system permission) or we have to go to the
> > > specific entity and add permission for that entity. It will be nice if
> > > we can assign roles( system level permissions) while adding users in
> > > 'Users' tab itself. It will be a clear user flow where one can add user
> > > and assign role in the same place.
> > > 
> > > I have attached both the screen shots.
> > > 
> > > please share your thoughts.
> > > 
> > > Regards,
> > > Ramesh
> > > 
> > > 
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From mrao at redhat.com  Mon Dec  2 19:20:06 2013
From: mrao at redhat.com (Malini Rao)
Date: Mon, 2 Dec 2013 14:20:06 -0500 (EST)
Subject: [Engine-devel] Adding users and assigning roles in Ovirt
In-Reply-To: <1960288549.21771993.1386009477305.JavaMail.root@redhat.com>
References: <529C192D.106@redhat.com>
	<1286130035.32994182.1385967712137.JavaMail.root@redhat.com>
	<1561192373.43408976.1385974076894.JavaMail.root@redhat.com>
	<1960288549.21771993.1386009477305.JavaMail.root@redhat.com>
Message-ID: <423545477.33455738.1386012006240.JavaMail.root@redhat.com>

Joining in the thread a bit green but wouldn't it be ok to add the new user with the most basic permissions by default ( may be just read only permissions)until the admin goes and deliberately tweaks permissions or assigns a role? 

Also, if we add that roles drop down as Einav mentioned, isn't there a way to only show that drop down if the logged in user is an admin role?

+1 on the user adding wizard. I think in general connecting related task flows together will improve the overall UX too.

Thanks
Malini

----- Original Message -----
From: "Einav Cohen" <ecohen at redhat.com>
To: "Gilad Chaplik" <gchaplik at redhat.com>, "Ramesh" <rnachimu at redhat.com>, "Oved Ourfalli" <ovedo at redhat.com>
Cc: engine-devel at ovirt.org
Sent: Monday, December 2, 2013 1:37:57 PM
Subject: Re: [Engine-devel] Adding users and assigning roles in Ovirt

we should definitely not completely remove the possibility to add permission-less users to the system, 
due to possible use-cases as Gilad mentioned and/or simply to allow the flexibility of adding the user 
first, and only then adding the relevant (business entity and) permissions, should the admin choose to 
do so. 

the more correct location to add system permissions to a user would probably be a 'Add System Permission' 
dialog that will be available from the Permissions sub-tab of the Users main tab, however it won't allow 
to assign system permissions to several users at once, so I understand the need for this ability within 
the 'Add User(s)' dialog. 

I think that adding an "allow user to login" check-box would not be good enough, since once a user 
would be able to login, he won't be able to do (or even see) anything (well, other than the 'Blank' 
Template, maybe), so the admin would need to assign additional permissions to this user anyway. 
The minimal solution in my view is to add a "assign these users the following system permissions" 
check-box, with a Roles drop down; as Gilad mentioned - need to be very careful with that, as 
system-wide permissions are powerful. 
A more comprehensive solution (more complex for implementation) would probably be, as Oved mentioned, 
some sort of a user-adding-wizard, that will allow easy permissions-assignment (maybe even not only 
system-wide permissions) to the newly-added users. 

----
Thanks,
Einav

----- Original Message -----
> From: "Gilad Chaplik" <gchaplik at redhat.com>
> To: "Oved Ourfalli" <ovedo at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Monday, December 2, 2013 3:47:56 AM
> Subject: Re: [Engine-devel] Adding users and assigning roles in Ovirt
> 
> Hi Ramesh,
> 
> You're right, I also think that the 'add users' is a bit pointless, but
> adding a system permission in that dialog can be dangerous (if admin doesn't
> fully understand what he's doing, and MLA is complicated enough ;-) ).
> 
> Currently when adding a permission we can specify a AD-user (regardless to
> the fact he's added or not), So eventually power users can add users to the
> system.
> I can think of a case, that admins will want to manage the users by
> themselves, i.e- power users can add permissions for the added users only.
> this way this dialog can be useful.
> 
> Thanks,
> Gilad.
> 
> ----- Original Message -----
> > From: "Oved Ourfalli" <ovedo at redhat.com>
> > To: "Ramesh" <rnachimu at redhat.com>
> > Cc: engine-devel at ovirt.org
> > Sent: Monday, December 2, 2013 9:01:52 AM
> > Subject: Re: [Engine-devel] Adding users and assigning roles in Ovirt
> > 
> > Your E-mail made me look a bit and check the different flows.
> > 
> > I think the only use-case for adding users without giving any permissions
> > is
> > when you add a user for notification reasons.
> > You can add a user, and then in the Event Notifier sub-tab define what
> > events
> > he will get via E-mail.
> > afaik (and I'm not an event notifier expert), this user doesn't have to be
> > able to login, or to have permissions of any kind. He just gets events.
> > 
> > Other than that you're right. A user which is added to the system can't do
> > much without assigning him roles.
> > I think adding roles assignment to this dialog may be a bit cumbersome.
> > Perhaps some wizard is required in that case. Or at least some checkbox
> > saying "allow user to login". That way the new user will be able to login,
> > and he will have some default permissions as well (permissions granted to
> > Everyone).
> > 
> > Let's see what others think.
> > 
> > Regards,
> > Oved
> > 
> > 
> > ----- Original Message -----
> > > From: "Ramesh" <rnachimu at redhat.com>
> > > To: engine-devel at ovirt.org
> > > Sent: Monday, December 2, 2013 7:22:53 AM
> > > Subject: [Engine-devel] Adding users and assigning roles in Ovirt
> > > 
> > > Hi All,
> > > 
> > >    We have 'Add' action under 'Users' main tab to add users in Ovirt .
> > > It looks slightly different from the "Add user" option of the Configure
> > > option. Actually, this one is missing the "Role to Assign" option. I
> > > think without assigning any role, adding a user is not meaningful and it
> > > didn't complete the flow.
> > > 
> > >    Currently to assign any role to the user, either we have to use
> > > 'Configure' option ( to add system permission) or we have to go to the
> > > specific entity and add permission for that entity. It will be nice if
> > > we can assign roles( system level permissions) while adding users in
> > > 'Users' tab itself. It will be a clear user flow where one can add user
> > > and assign role in the same place.
> > > 
> > > I have attached both the screen shots.
> > > 
> > > please share your thoughts.
> > > 
> > > Regards,
> > > Ramesh
> > > 
> > > 
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
_______________________________________________
Engine-devel mailing list
Engine-devel at ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel


From ecohen at redhat.com  Mon Dec  2 19:55:45 2013
From: ecohen at redhat.com (Einav Cohen)
Date: Mon, 2 Dec 2013 14:55:45 -0500 (EST)
Subject: [Engine-devel] Adding users and assigning roles in Ovirt
In-Reply-To: <423545477.33455738.1386012006240.JavaMail.root@redhat.com>
References: <529C192D.106@redhat.com>
	<1286130035.32994182.1385967712137.JavaMail.root@redhat.com>
	<1561192373.43408976.1385974076894.JavaMail.root@redhat.com>
	<1960288549.21771993.1386009477305.JavaMail.root@redhat.com>
	<423545477.33455738.1386012006240.JavaMail.root@redhat.com>
Message-ID: <652830843.21821507.1386014145780.JavaMail.root@redhat.com>

> ----- Original Message -----
> From: "Malini Rao" <mrao at redhat.com>
> Sent: Monday, December 2, 2013 2:20:06 PM
> 
> Joining in the thread a bit green but wouldn't it be ok to add the new user
> with the most basic permissions by default ( may be just read only
> permissions)until the admin goes and deliberately tweaks permissions or
> assigns a role?

this is similar to what Oved has suggested, but I think that it won't really 
make any difference, since there is very little chance, in my view, that these 
permissions would be sufficient for anything - the admin would need to assign 
additional/different permissions at some point anyway, so not much point in 
allowing that default minimal assignment in the first place - we might as well 
keep the 'Add User(s)' dialog as is. 

> 
> Also, if we add that roles drop down as Einav mentioned, isn't there a way to
> only show that drop down if the logged in user is an admin role?

the logged in user must be an admin, as the 'Add User(s)' dialog (which is 
available from the Users main tab) exists only in the web-admin, which is 
accessible only to admins by definition. 

> 
> +1 on the user adding wizard. I think in general connecting related task
> flows together will improve the overall UX too. 

agreed. 

> 
> Thanks
> Malini
> 
> ----- Original Message -----
> From: "Einav Cohen" <ecohen at redhat.com>
> To: "Gilad Chaplik" <gchaplik at redhat.com>, "Ramesh" <rnachimu at redhat.com>,
> "Oved Ourfalli" <ovedo at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Monday, December 2, 2013 1:37:57 PM
> Subject: Re: [Engine-devel] Adding users and assigning roles in Ovirt
> 
> we should definitely not completely remove the possibility to add
> permission-less users to the system,
> due to possible use-cases as Gilad mentioned and/or simply to allow the
> flexibility of adding the user
> first, and only then adding the relevant (business entity and) permissions,
> should the admin choose to
> do so.
> 
> the more correct location to add system permissions to a user would probably
> be a 'Add System Permission'
> dialog that will be available from the Permissions sub-tab of the Users main
> tab, however it won't allow
> to assign system permissions to several users at once, so I understand the
> need for this ability within
> the 'Add User(s)' dialog.
> 
> I think that adding an "allow user to login" check-box would not be good
> enough, since once a user
> would be able to login, he won't be able to do (or even see) anything (well,
> other than the 'Blank'
> Template, maybe), so the admin would need to assign additional permissions to
> this user anyway.
> The minimal solution in my view is to add a "assign these users the following
> system permissions"
> check-box, with a Roles drop down; as Gilad mentioned - need to be very
> careful with that, as
> system-wide permissions are powerful.
> A more comprehensive solution (more complex for implementation) would
> probably be, as Oved mentioned,
> some sort of a user-adding-wizard, that will allow easy
> permissions-assignment (maybe even not only
> system-wide permissions) to the newly-added users.
> 
> ----
> Thanks,
> Einav
> 
> ----- Original Message -----
> > From: "Gilad Chaplik" <gchaplik at redhat.com>
> > To: "Oved Ourfalli" <ovedo at redhat.com>
> > Cc: engine-devel at ovirt.org
> > Sent: Monday, December 2, 2013 3:47:56 AM
> > Subject: Re: [Engine-devel] Adding users and assigning roles in Ovirt
> > 
> > Hi Ramesh,
> > 
> > You're right, I also think that the 'add users' is a bit pointless, but
> > adding a system permission in that dialog can be dangerous (if admin
> > doesn't
> > fully understand what he's doing, and MLA is complicated enough ;-) ).
> > 
> > Currently when adding a permission we can specify a AD-user (regardless to
> > the fact he's added or not), So eventually power users can add users to the
> > system.
> > I can think of a case, that admins will want to manage the users by
> > themselves, i.e- power users can add permissions for the added users only.
> > this way this dialog can be useful.
> > 
> > Thanks,
> > Gilad.
> > 
> > ----- Original Message -----
> > > From: "Oved Ourfalli" <ovedo at redhat.com>
> > > To: "Ramesh" <rnachimu at redhat.com>
> > > Cc: engine-devel at ovirt.org
> > > Sent: Monday, December 2, 2013 9:01:52 AM
> > > Subject: Re: [Engine-devel] Adding users and assigning roles in Ovirt
> > > 
> > > Your E-mail made me look a bit and check the different flows.
> > > 
> > > I think the only use-case for adding users without giving any permissions
> > > is
> > > when you add a user for notification reasons.
> > > You can add a user, and then in the Event Notifier sub-tab define what
> > > events
> > > he will get via E-mail.
> > > afaik (and I'm not an event notifier expert), this user doesn't have to
> > > be
> > > able to login, or to have permissions of any kind. He just gets events.
> > > 
> > > Other than that you're right. A user which is added to the system can't
> > > do
> > > much without assigning him roles.
> > > I think adding roles assignment to this dialog may be a bit cumbersome.
> > > Perhaps some wizard is required in that case. Or at least some checkbox
> > > saying "allow user to login". That way the new user will be able to
> > > login,
> > > and he will have some default permissions as well (permissions granted to
> > > Everyone).
> > > 
> > > Let's see what others think.
> > > 
> > > Regards,
> > > Oved
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Ramesh" <rnachimu at redhat.com>
> > > > To: engine-devel at ovirt.org
> > > > Sent: Monday, December 2, 2013 7:22:53 AM
> > > > Subject: [Engine-devel] Adding users and assigning roles in Ovirt
> > > > 
> > > > Hi All,
> > > > 
> > > >    We have 'Add' action under 'Users' main tab to add users in Ovirt .
> > > > It looks slightly different from the "Add user" option of the Configure
> > > > option. Actually, this one is missing the "Role to Assign" option. I
> > > > think without assigning any role, adding a user is not meaningful and
> > > > it
> > > > didn't complete the flow.
> > > > 
> > > >    Currently to assign any role to the user, either we have to use
> > > > 'Configure' option ( to add system permission) or we have to go to the
> > > > specific entity and add permission for that entity. It will be nice if
> > > > we can assign roles( system level permissions) while adding users in
> > > > 'Users' tab itself. It will be a clear user flow where one can add user
> > > > and assign role in the same place.
> > > > 
> > > > I have attached both the screen shots.
> > > > 
> > > > please share your thoughts.
> > > > 
> > > > Regards,
> > > > Ramesh
> > > > 
> > > > 
> > > > _______________________________________________
> > > > Engine-devel mailing list
> > > > Engine-devel at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > 
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> 
> 


From yzaslavs at redhat.com  Mon Dec  2 21:09:10 2013
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Mon, 2 Dec 2013 16:09:10 -0500 (EST)
Subject: [Engine-devel] Adding users and assigning roles in Ovirt
In-Reply-To: <652830843.21821507.1386014145780.JavaMail.root@redhat.com>
References: <529C192D.106@redhat.com>
	<1286130035.32994182.1385967712137.JavaMail.root@redhat.com>
	<1561192373.43408976.1385974076894.JavaMail.root@redhat.com>
	<1960288549.21771993.1386009477305.JavaMail.root@redhat.com>
	<423545477.33455738.1386012006240.JavaMail.root@redhat.com>
	<652830843.21821507.1386014145780.JavaMail.root@redhat.com>
Message-ID: <83819078.10898841.1386018550425.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Einav Cohen" <ecohen at redhat.com>
> To: "Malini Rao" <mrao at redhat.com>
> Cc: "Oved Ourfalli" <ovedo at redhat.com>, engine-devel at ovirt.org
> Sent: Monday, December 2, 2013 9:55:45 PM
> Subject: Re: [Engine-devel] Adding users and assigning roles in Ovirt
> 
> > ----- Original Message -----
> > From: "Malini Rao" <mrao at redhat.com>
> > Sent: Monday, December 2, 2013 2:20:06 PM
> > 
> > Joining in the thread a bit green but wouldn't it be ok to add the new user
> > with the most basic permissions by default ( may be just read only
> > permissions)until the admin goes and deliberately tweaks permissions or
> > assigns a role?
> 
> this is similar to what Oved has suggested, but I think that it won't really
> make any difference, since there is very little chance, in my view, that
> these
> permissions would be sufficient for anything - the admin would need to assign
> additional/different permissions at some point anyway, so not much point in
> allowing that default minimal assignment in the first place - we might as
> well
> keep the 'Add User(s)' dialog as is.
> 
> > 
> > Also, if we add that roles drop down as Einav mentioned, isn't there a way
> > to
> > only show that drop down if the logged in user is an admin role?
> 
> the logged in user must be an admin, as the 'Add User(s)' dialog (which is
> available from the Users main tab) exists only in the web-admin, which is
> accessible only to admins by definition.
> 
> > 
> > +1 on the user adding wizard. I think in general connecting related task
> > flows together will improve the overall UX too.

+1 here
> 
> agreed.
> 
> > 
> > Thanks
> > Malini
> > 
> > ----- Original Message -----
> > From: "Einav Cohen" <ecohen at redhat.com>
> > To: "Gilad Chaplik" <gchaplik at redhat.com>, "Ramesh" <rnachimu at redhat.com>,
> > "Oved Ourfalli" <ovedo at redhat.com>
> > Cc: engine-devel at ovirt.org
> > Sent: Monday, December 2, 2013 1:37:57 PM
> > Subject: Re: [Engine-devel] Adding users and assigning roles in Ovirt
> > 
> > we should definitely not completely remove the possibility to add
> > permission-less users to the system,
> > due to possible use-cases as Gilad mentioned and/or simply to allow the
> > flexibility of adding the user
> > first, and only then adding the relevant (business entity and) permissions,
> > should the admin choose to
> > do so.
> > 
> > the more correct location to add system permissions to a user would
> > probably
> > be a 'Add System Permission'
> > dialog that will be available from the Permissions sub-tab of the Users
> > main
> > tab, however it won't allow
> > to assign system permissions to several users at once, so I understand the
> > need for this ability within
> > the 'Add User(s)' dialog.
> > 
> > I think that adding an "allow user to login" check-box would not be good
> > enough, since once a user
> > would be able to login, he won't be able to do (or even see) anything
> > (well,
> > other than the 'Blank'
> > Template, maybe), so the admin would need to assign additional permissions
> > to
> > this user anyway.
> > The minimal solution in my view is to add a "assign these users the
> > following
> > system permissions"
> > check-box, with a Roles drop down; as Gilad mentioned - need to be very
> > careful with that, as
> > system-wide permissions are powerful.
> > A more comprehensive solution (more complex for implementation) would
> > probably be, as Oved mentioned,
> > some sort of a user-adding-wizard, that will allow easy
> > permissions-assignment (maybe even not only
> > system-wide permissions) to the newly-added users.
> > 
> > ----
> > Thanks,
> > Einav
> > 
> > ----- Original Message -----
> > > From: "Gilad Chaplik" <gchaplik at redhat.com>
> > > To: "Oved Ourfalli" <ovedo at redhat.com>
> > > Cc: engine-devel at ovirt.org
> > > Sent: Monday, December 2, 2013 3:47:56 AM
> > > Subject: Re: [Engine-devel] Adding users and assigning roles in Ovirt
> > > 
> > > Hi Ramesh,
> > > 
> > > You're right, I also think that the 'add users' is a bit pointless, but
> > > adding a system permission in that dialog can be dangerous (if admin
> > > doesn't
> > > fully understand what he's doing, and MLA is complicated enough ;-) ).
> > > 
> > > Currently when adding a permission we can specify a AD-user (regardless
> > > to
> > > the fact he's added or not), So eventually power users can add users to
> > > the
> > > system.
> > > I can think of a case, that admins will want to manage the users by
> > > themselves, i.e- power users can add permissions for the added users
> > > only.
> > > this way this dialog can be useful.
> > > 
> > > Thanks,
> > > Gilad.
> > > 
> > > ----- Original Message -----
> > > > From: "Oved Ourfalli" <ovedo at redhat.com>
> > > > To: "Ramesh" <rnachimu at redhat.com>
> > > > Cc: engine-devel at ovirt.org
> > > > Sent: Monday, December 2, 2013 9:01:52 AM
> > > > Subject: Re: [Engine-devel] Adding users and assigning roles in Ovirt
> > > > 
> > > > Your E-mail made me look a bit and check the different flows.
> > > > 
> > > > I think the only use-case for adding users without giving any
> > > > permissions
> > > > is
> > > > when you add a user for notification reasons.
> > > > You can add a user, and then in the Event Notifier sub-tab define what
> > > > events
> > > > he will get via E-mail.
> > > > afaik (and I'm not an event notifier expert), this user doesn't have to
> > > > be
> > > > able to login, or to have permissions of any kind. He just gets events.

+1 - this is due to the fact a user has an email account - no need to login to ovirt-engine
in order to read your emails :)

> > > > 
> > > > Other than that you're right. A user which is added to the system can't
> > > > do
> > > > much without assigning him roles.
> > > > I think adding roles assignment to this dialog may be a bit cumbersome.
> > > > Perhaps some wizard is required in that case. Or at least some checkbox
> > > > saying "allow user to login". That way the new user will be able to
> > > > login,
> > > > and he will have some default permissions as well (permissions granted
> > > > to
> > > > Everyone).
> > > > 
> > > > Let's see what others think.
> > > > 
> > > > Regards,
> > > > Oved
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Ramesh" <rnachimu at redhat.com>
> > > > > To: engine-devel at ovirt.org
> > > > > Sent: Monday, December 2, 2013 7:22:53 AM
> > > > > Subject: [Engine-devel] Adding users and assigning roles in Ovirt
> > > > > 
> > > > > Hi All,
> > > > > 
> > > > >    We have 'Add' action under 'Users' main tab to add users in Ovirt
> > > > >    .
> > > > > It looks slightly different from the "Add user" option of the
> > > > > Configure
> > > > > option. Actually, this one is missing the "Role to Assign" option. I
> > > > > think without assigning any role, adding a user is not meaningful and
> > > > > it
> > > > > didn't complete the flow.
> > > > > 
> > > > >    Currently to assign any role to the user, either we have to use
> > > > > 'Configure' option ( to add system permission) or we have to go to
> > > > > the
> > > > > specific entity and add permission for that entity. It will be nice
> > > > > if
> > > > > we can assign roles( system level permissions) while adding users in
> > > > > 'Users' tab itself. It will be a clear user flow where one can add
> > > > > user
> > > > > and assign role in the same place.
> > > > > 
> > > > > I have attached both the screen shots.
> > > > > 
> > > > > please share your thoughts.
> > > > > 
> > > > > Regards,
> > > > > Ramesh
> > > > > 
> > > > > 
> > > > > _______________________________________________
> > > > > Engine-devel mailing list
> > > > > Engine-devel at ovirt.org
> > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > 
> > > > _______________________________________________
> > > > Engine-devel mailing list
> > > > Engine-devel at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > 
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> > 
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From sbonazzo at redhat.com  Tue Dec  3 07:09:04 2013
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Tue, 03 Dec 2013 08:09:04 +0100
Subject: [Engine-devel] oVirt 3.3.2 Beta now available
Message-ID: <529D8390.30200@redhat.com>

The oVirt team is pleased to announce that the 3.3.2 Release is now available in beta.

Release notes and information on the changes for this update are still being worked on and will be available soon on the wiki[1].

A new oVirt Node build will be available soon as well.

You're welcome to join us testing [2] this beta release.


[1] http://www.ovirt.org/OVirt_3.3.2_release_notes
[2] http://www.ovirt.org/Testing/Ovirt_3.3.2_testing


-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com


From mpastern at redhat.com  Tue Dec  3 11:45:35 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Tue, 03 Dec 2013 13:45:35 +0200
Subject: [Engine-devel] Using REST API in web UI - review call summary
In-Reply-To: <305092398.32429154.1385667456789.JavaMail.root@redhat.com>
References: <1515483885.28819526.1385068697947.JavaMail.root@redhat.com>
	<528E7A30.7040503@redhat.com>
	<1590829306.28868001.1385071018139.JavaMail.root@redhat.com>
	<528E8279.40701@redhat.com> <5291BAC2.9010902@redhat.com>
	<305092398.32429154.1385667456789.JavaMail.root@redhat.com>
Message-ID: <529DC45F.5090007@redhat.com>

On 11/28/2013 09:37 PM, Vojtech Szocs wrote:
> 
> 
> ----- Original Message -----
>> From: "Michael Pasternak" <mpastern at redhat.com>
>> To: "Itamar Heim" <iheim at redhat.com>
>> Cc: "Vojtech Szocs" <vszocs at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, "Einav Cohen" <ecohen at redhat.com>
>> Sent: Sunday, November 24, 2013 9:37:22 AM
>> Subject: Re: Using REST API in web UI - review call summary
>>
>> On 11/22/2013 12:00 AM, Itamar Heim wrote:
>>> On 11/21/2013 11:56 PM, Vojtech Szocs wrote:
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Itamar Heim" <iheim at redhat.com>
>>>>> To: "Vojtech Szocs" <vszocs at redhat.com>, "engine-devel"
>>>>> <engine-devel at ovirt.org>
>>>>> Cc: "Einav Cohen" <ecohen at redhat.com>
>>>>> Sent: Thursday, November 21, 2013 10:25:04 PM
>>>>> Subject: Re: Using REST API in web UI - review call summary
>>>>>
>>>>> On 11/21/2013 11:18 PM, Vojtech Szocs wrote:
>>>>>> Hi guys,
>>>>>>
>>>>>> this is a summary of yesterday's review call, I'll try to highlight
>>>>>> important Q/A and things we agreed on. Feel free to add anything in case
>>>>>> I've missed something.
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Q: Why don't we simply try to use existing Java SDK and adapt it for GWT
>>>>>> apps? (asked by Michael & Gilad)
>>>>>>
>>>>>> A: This might be a viable option to consider if we wanted to skip
>>>>>> JavaScript-based SDK altogether and target Java/GWT code directly; we
>>>>>> could simply take Java SDK and customize its abstractions where
>>>>>> necessary,
>>>>>> i.e. using HTTP transport layer implementation that works with GWT. In
>>>>>> any
>>>>>> case, this would mean coupling ourselves to Java SDK (which has its own
>>>>>> release cycle) and I think this would complicate things for us.
>>>>>>
>>>>>> As proposed on the meeting, I think it's best to aim for JavaScript SDK
>>>>>> as
>>>>>> the lowest common denominator for *any* web application that wants to
>>>>>> work
>>>>>> with REST API. oVirt GWT-based UI can simply bind to JavaScript SDK,
>>>>>> i.e.
>>>>>> Java/GWT code that just overlays objects and functions provided by
>>>>>> JavaScript SDK. Another reason is ease of maintenance - I'd rather see
>>>>>> JavaScript SDK's code generation process to be independent of any other
>>>>>> SDK (people responsible for maintaining JavaScript SDK should have full
>>>>>> control over generated code).
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Q: What about functionality currently used by oVirt UI but not supported
>>>>>> by
>>>>>> REST API? (asked by Einav)
>>>>>>      [For example, fetching VM entity over GWT RPC also returns related
>>>>>>      data
>>>>>>      such as Cluster name.]
>>>>>>
>>>>>> A: Based on discussion I've had with other colleagues after yesterday's
>>>>>> review call, I don't think that separate support-like backend layer is a
>>>>>> good idea. Instead, this is the kind of functionality that could be
>>>>>> placed
>>>>>> in oVirt.js library. Logical operations like "get VMs and related data"
>>>>>> would be exposed through oVirt.js (callback-based) API and ultimately
>>>>>> realized as multiple physical requests to REST API via JavaScript
>>>>>> Binding.
>>>>>>
>>>>>> oVirt.js client would be completely oblivious to the fact that multiple
>>>>>> physical requests are dispatched. In fact, since HTTP communication is
>>>>>> asynchronous in nature, oVirt.js client wouldn't even notice any
>>>>>> difference in terms of API consumption. This assumes JavaScript SDK
>>>>>> would
>>>>>> use callback-based (non-blocking) API instead of blocking one - after
>>>>>> all,
>>>>>> blocking API on top of non-blocking implementation sounds pretty much
>>>>>> like
>>>>>> leaky abstraction [1].
>>>>>>
>>>>>> For example:
>>>>>>
>>>>>>       sdk.getVmsWithExtraData(
>>>>>>           callbackToGetExtraDataForGivenVm, // might cause extra
>>>>>>           physical
>>>>>>           requests to REST API
>>>>>>           callbackFiredWhenAllDataIsReady   // update client only when
>>>>>>           all
>>>>>>           data is ready
>>>>>>       )
>>>>>
>>>>> would this also resolve RunMultipleActions?
>>>>
>>>> Yes, I think so. There could be API to pass multiple "actions" and get
>>>> notified when they complete.
>>>>
>>>>> sounds like no reason to have RunMultipleQueries, although i'm still
>>>>> sure a single call to engine for multiple keys would be much more
>>>>> efficient than multiple async calls?
>>>>> (I understand we may not be able to model this).
>>>>
>>>> Efficiency-wise, yes, single call to get all data seems optimal. API-wise,
>>>> I don't think it really matters from oVirt.js client perspective.
>>>>
>>>> We can proceed with simple (possibly inefficient) solution and improve as
>>>> needed. We're making baby steps now..
>>>>
>>>>>
>>>>>>
>>>>>> [1] http://en.wikipedia.org/wiki/Leaky_abstraction
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Last but not least, where to maintain JavaScript SDK projects: low-level
>>>>>> JavaScript Binding + high-level oVirt.js library.
>>>>>>
>>>>>> I agree that conceptually both above mentioned projects should go into
>>>>>> dedicated "ovirt-engine-sdk-js" git repository and have their own
>>>>>> build/release process. However, for now, we're just making baby steps so
>>>>>> let's keep things simple and prototype these projects as part of
>>>>>> "ovirt-engine" git repository.
>>>>>>
>>>>>> ... we can complicate things anytime, but we should know that any
>>>>>> complex
>>>>>> system that works has inevitably evolved from simple system that works
>>>>>> ...
>>>>>> (quote from http://en.wikipedia.org/wiki/Gall%27s_law)
>>>>>
>>>>> I think the entities should just be generated from the xsd.
>>>>
>>>> +1
>>>>
>>>> The JavaScript Binding (aka low-level SDK) module should follow same
>>>> concepts as existing Java SDK - generated entities decorated with
>>>> operations to form fluent API.
>>>>
>>>> Everything Java SDK currently offers should be available in JavaScript
>>>> Binding. oVirt.js is our opportunity to build on top of that.
>>>>
>>>>> for the rsdl, makes sense to start with clean code to see what works
>>>>> best, then see about generating it (but you should adhere the rsdl as
>>>>> guidlines i guess).
>>>>
>>>> +1
>>>>
>>>> The initial prototype should be written by hand, things will get generated
>>>> as soon as we have better idea how the end result should look like.
>>>
>>> i can understand that for the methods and maybe for populating the entities
>>> for the first few.
>>> the entities themselves, no point in hand coding - just generated them from
>>> the api.xsd.
>>> and once you decide how you want to fill them, not worth hand coding this -
>>> either json gives this out of the box, or should be generated as well.
>>>
>>>>
>>>>>
>>>>> lets try to plan for lightweight entities while at it - the API has a
>>>>> mechanism for different level of details - maybe we need a custom level
>>>>> where the client specifies which fields they want back or something like
>>>>> that.
>>>>
>>>> Good idea! We should definitely think about the granularity of entities.
>>>>
>>>> I didn't know REST API supports different level of detail per entity, is
>>>> there some documentation for this feature?
>>
>> currently it's about adding adding extra information (by supplying header
>> [1]),
>> this is driven by the properties that require extra query against the engine
>> to
>> fill them,
>>
>> obviously the default is [2]
>>
>> [1] All-Content: True
>> [2] All-Content: False
> 
> OK so if I understand correctly, "All-Content: False" (default) just returns data of given entity plus IDs of related entities, whereas "All-Content: True" returns data of given entity plus (embedded) data of related entities, is that correct?

not exactly, "All-Content: True" will return other fields of this entity
(not the entity's your resource has relation with, as it was non-RESTful),
the differences is in cost of feeling these properties, if it's expensive
like running extra query to the engine (like Payload/Certificate/Ballooning in vm)
it's not shown by default.

> 
>>
>>>>
>>>> Since JavaScript is dynamic, one possible solution would be to let client
>>>> define the entity structure (i.e. what data client needs) on the fly,
>>>> during runtime :)
>>
>> we talked about this solution couple of years ago, but it was obvious
>> that there is no real "demand" for it till UI moves to REST,
> 
> I assume you mean to let client selectively specify properties of given entity when making REST call, correct? If yes, are you planning to support such feature?

obviously this is one of the steps to take down the road to enhance the restapi.

> 
>>
>> btw it won't solve the problem where to fill UI entity you need combination
>> of N REST entities, you still will have to perform N + 1 queries to API
> 
> Of course. But we can make improvements with regard to:
> 
> - optimizing queries so that client receives/parses only data it needs (see my question above)
> - if necessary, combine such optimized queries into bigger "logical" queries (utilizing callback mechanism)

not sure about "bigger" (you can't change api interface), but combining few requests for the same entity
(in sake of less verbose communication) in to single GET call, is a well known pattern in distributed
systems.

> 
>> (maybe asking for entity with fewer details), - all it address is a capacity
>> of the data being send.
> 
> Not only that, capacity of data sent goes proportionally with time needed to parse & process such data on client. (Imagine big XML marshalling on client. This is why everyone prefers JSON nowadays, JSON naturally maps to native JavaScript structures with minimal computational overhead.)
> 
>>
>>>
>>> michael?
>>>
>>>>
>>>>>
>>>>> Good luck,
>>>>>      Itamar
>>>>>
>>>
>>
>>
>> --
>>
>> Michael Pasternak
>> RedHat, ENG-Virtualization R&D
>>


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From ecohen at redhat.com  Tue Dec  3 20:42:44 2013
From: ecohen at redhat.com (Einav Cohen)
Date: Tue, 3 Dec 2013 15:42:44 -0500 (EST)
Subject: [Engine-devel] Fwd:  Adding users and assigning roles in Ovirt
In-Reply-To: <83819078.10898841.1386018550425.JavaMail.root@redhat.com>
References: <529C192D.106@redhat.com>
	<1286130035.32994182.1385967712137.JavaMail.root@redhat.com>
	<1561192373.43408976.1385974076894.JavaMail.root@redhat.com>
	<1960288549.21771993.1386009477305.JavaMail.root@redhat.com>
	<423545477.33455738.1386012006240.JavaMail.root@redhat.com>
	<652830843.21821507.1386014145780.JavaMail.root@redhat.com>
	<83819078.10898841.1386018550425.JavaMail.root@redhat.com>
Message-ID: <121876212.22757913.1386103364703.JavaMail.root@redhat.com>

[moving discussion to the users mailing list]

while it seems that we all agree that adding some sort of a wizard 
that will allow easy permission assignment to newly-added users, it 
doesn't seem like something that can be accomplished soon (e.g. for 
ovirt 3.4). 

maybe we can utilize Ramesh's initial suggestion [1] for the short term - 
allow assignment of *System* permissions in the context of the 'Add 
User(s)' dialog [with an explicit clarification within the dialog that 
we are talking about *System* permissions, so that the admin will be 
aware that the privileges that he can assign in this context would be 
very permissive]

any thoughts?
how extensively are system permissions used in oVirt in general? 
[if adding a system permission is not a common/popular action, there 
is no reason to expose it in the 'Add User(s)' dialog, since it will 
probably be hardly used anyway]

maybe different ideas for short-term solutions?

----
Thanks,
Einav


[1] http://lists.ovirt.org/pipermail/engine-devel/2013-December/006059.html


----- Forwarded Message -----
From: "Yair Zaslavsky" <yzaslavs at redhat.com>
To: "Einav Cohen" <ecohen at redhat.com>
Cc: "Oved Ourfalli" <ovedo at redhat.com>, engine-devel at ovirt.org
Sent: Monday, December 2, 2013 4:09:10 PM
Subject: Re: [Engine-devel] Adding users and assigning roles in Ovirt



----- Original Message -----
> From: "Einav Cohen" <ecohen at redhat.com>
> To: "Malini Rao" <mrao at redhat.com>
> Cc: "Oved Ourfalli" <ovedo at redhat.com>, engine-devel at ovirt.org
> Sent: Monday, December 2, 2013 9:55:45 PM
> Subject: Re: [Engine-devel] Adding users and assigning roles in Ovirt
> 
> > ----- Original Message -----
> > From: "Malini Rao" <mrao at redhat.com>
> > Sent: Monday, December 2, 2013 2:20:06 PM
> > 
> > Joining in the thread a bit green but wouldn't it be ok to add the new user
> > with the most basic permissions by default ( may be just read only
> > permissions)until the admin goes and deliberately tweaks permissions or
> > assigns a role?
> 
> this is similar to what Oved has suggested, but I think that it won't really
> make any difference, since there is very little chance, in my view, that
> these
> permissions would be sufficient for anything - the admin would need to assign
> additional/different permissions at some point anyway, so not much point in
> allowing that default minimal assignment in the first place - we might as
> well
> keep the 'Add User(s)' dialog as is.
> 
> > 
> > Also, if we add that roles drop down as Einav mentioned, isn't there a way
> > to
> > only show that drop down if the logged in user is an admin role?
> 
> the logged in user must be an admin, as the 'Add User(s)' dialog (which is
> available from the Users main tab) exists only in the web-admin, which is
> accessible only to admins by definition.
> 
> > 
> > +1 on the user adding wizard. I think in general connecting related task
> > flows together will improve the overall UX too.

+1 here
> 
> agreed.
> 
> > 
> > Thanks
> > Malini
> > 
> > ----- Original Message -----
> > From: "Einav Cohen" <ecohen at redhat.com>
> > To: "Gilad Chaplik" <gchaplik at redhat.com>, "Ramesh" <rnachimu at redhat.com>,
> > "Oved Ourfalli" <ovedo at redhat.com>
> > Cc: engine-devel at ovirt.org
> > Sent: Monday, December 2, 2013 1:37:57 PM
> > Subject: Re: [Engine-devel] Adding users and assigning roles in Ovirt
> > 
> > we should definitely not completely remove the possibility to add
> > permission-less users to the system,
> > due to possible use-cases as Gilad mentioned and/or simply to allow the
> > flexibility of adding the user
> > first, and only then adding the relevant (business entity and) permissions,
> > should the admin choose to
> > do so.
> > 
> > the more correct location to add system permissions to a user would
> > probably
> > be a 'Add System Permission'
> > dialog that will be available from the Permissions sub-tab of the Users
> > main
> > tab, however it won't allow
> > to assign system permissions to several users at once, so I understand the
> > need for this ability within
> > the 'Add User(s)' dialog.
> > 
> > I think that adding an "allow user to login" check-box would not be good
> > enough, since once a user
> > would be able to login, he won't be able to do (or even see) anything
> > (well,
> > other than the 'Blank'
> > Template, maybe), so the admin would need to assign additional permissions
> > to
> > this user anyway.
> > The minimal solution in my view is to add a "assign these users the
> > following
> > system permissions"
> > check-box, with a Roles drop down; as Gilad mentioned - need to be very
> > careful with that, as
> > system-wide permissions are powerful.
> > A more comprehensive solution (more complex for implementation) would
> > probably be, as Oved mentioned,
> > some sort of a user-adding-wizard, that will allow easy
> > permissions-assignment (maybe even not only
> > system-wide permissions) to the newly-added users.
> > 
> > ----
> > Thanks,
> > Einav
> > 
> > ----- Original Message -----
> > > From: "Gilad Chaplik" <gchaplik at redhat.com>
> > > To: "Oved Ourfalli" <ovedo at redhat.com>
> > > Cc: engine-devel at ovirt.org
> > > Sent: Monday, December 2, 2013 3:47:56 AM
> > > Subject: Re: [Engine-devel] Adding users and assigning roles in Ovirt
> > > 
> > > Hi Ramesh,
> > > 
> > > You're right, I also think that the 'add users' is a bit pointless, but
> > > adding a system permission in that dialog can be dangerous (if admin
> > > doesn't
> > > fully understand what he's doing, and MLA is complicated enough ;-) ).
> > > 
> > > Currently when adding a permission we can specify a AD-user (regardless
> > > to
> > > the fact he's added or not), So eventually power users can add users to
> > > the
> > > system.
> > > I can think of a case, that admins will want to manage the users by
> > > themselves, i.e- power users can add permissions for the added users
> > > only.
> > > this way this dialog can be useful.
> > > 
> > > Thanks,
> > > Gilad.
> > > 
> > > ----- Original Message -----
> > > > From: "Oved Ourfalli" <ovedo at redhat.com>
> > > > To: "Ramesh" <rnachimu at redhat.com>
> > > > Cc: engine-devel at ovirt.org
> > > > Sent: Monday, December 2, 2013 9:01:52 AM
> > > > Subject: Re: [Engine-devel] Adding users and assigning roles in Ovirt
> > > > 
> > > > Your E-mail made me look a bit and check the different flows.
> > > > 
> > > > I think the only use-case for adding users without giving any
> > > > permissions
> > > > is
> > > > when you add a user for notification reasons.
> > > > You can add a user, and then in the Event Notifier sub-tab define what
> > > > events
> > > > he will get via E-mail.
> > > > afaik (and I'm not an event notifier expert), this user doesn't have to
> > > > be
> > > > able to login, or to have permissions of any kind. He just gets events.

+1 - this is due to the fact a user has an email account - no need to login to ovirt-engine
in order to read your emails :)

> > > > 
> > > > Other than that you're right. A user which is added to the system can't
> > > > do
> > > > much without assigning him roles.
> > > > I think adding roles assignment to this dialog may be a bit cumbersome.
> > > > Perhaps some wizard is required in that case. Or at least some checkbox
> > > > saying "allow user to login". That way the new user will be able to
> > > > login,
> > > > and he will have some default permissions as well (permissions granted
> > > > to
> > > > Everyone).
> > > > 
> > > > Let's see what others think.
> > > > 
> > > > Regards,
> > > > Oved
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Ramesh" <rnachimu at redhat.com>
> > > > > To: engine-devel at ovirt.org
> > > > > Sent: Monday, December 2, 2013 7:22:53 AM
> > > > > Subject: [Engine-devel] Adding users and assigning roles in Ovirt
> > > > > 
> > > > > Hi All,
> > > > > 
> > > > >    We have 'Add' action under 'Users' main tab to add users in Ovirt
> > > > >    .
> > > > > It looks slightly different from the "Add user" option of the
> > > > > Configure
> > > > > option. Actually, this one is missing the "Role to Assign" option. I
> > > > > think without assigning any role, adding a user is not meaningful and
> > > > > it
> > > > > didn't complete the flow.
> > > > > 
> > > > >    Currently to assign any role to the user, either we have to use
> > > > > 'Configure' option ( to add system permission) or we have to go to
> > > > > the
> > > > > specific entity and add permission for that entity. It will be nice
> > > > > if
> > > > > we can assign roles( system level permissions) while adding users in
> > > > > 'Users' tab itself. It will be a clear user flow where one can add
> > > > > user
> > > > > and assign role in the same place.
> > > > > 
> > > > > I have attached both the screen shots.
> > > > > 
> > > > > please share your thoughts.
> > > > > 
> > > > > Regards,
> > > > > Ramesh
> > > > > 
> > > > > 
> > > > > _______________________________________________
> > > > > Engine-devel mailing list
> > > > > Engine-devel at ovirt.org
> > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > 
> > > > _______________________________________________
> > > > Engine-devel mailing list
> > > > Engine-devel at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > 
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> > 
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
_______________________________________________
Engine-devel mailing list
Engine-devel at ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel



From tjelinek at redhat.com  Wed Dec  4 12:14:06 2013
From: tjelinek at redhat.com (Tomas Jelinek)
Date: Wed, 4 Dec 2013 07:14:06 -0500 (EST)
Subject: [Engine-devel] [engine-devel] instance type as top-level entity
In-Reply-To: <942100091.1721704.1386151932263.JavaMail.root@redhat.com>
Message-ID: <220898566.1749726.1386159246739.JavaMail.root@redhat.com>

Hey all,

I have started to work on the instance types[1] again and hit an issue. Since the instance types are supposed to be top-level entities
(e.g. without the connection to DC/Cluster) but they are modeled as templates it is not possible to store them to DB since the DB constraints violation on vm_static table 
(e.g. the vds_group_id has to be unique and point to an existing vds_group).

So, I see 4 options:

1: drop the constraints on the vm_static.vds_group_id (the vds_groups_vm_static constraint)
   (most simple approach but would open the door to some issues which are now guard on the DB level)

2: do the same magic [well, hacks :) ] as with the "blank" template which is in the same situation
   (not exactly a nice solution to have the instance types wired to one specific cluster just to satisfy the constraint but return them all the time)

3: do not store this data in vm_static but create some new table called e.g. instance_type which would contain all of the fields from vm_static which are needed by it
   (actually the best approach AFAIK but to do it correctly it would require some more refactoring to do some hierarchy of tables and not copy the fields from table to table)

4: make the instance types not top-level (e.g. bound to specific DC/Cluster)
   (would bring some issues for example with the default instance types which should be present for all the DC/Clusters)

Thoughts?

Thank you,
Tomas

[1]: http://www.ovirt.org/Features/Instance_Types


From ofrenkel at redhat.com  Wed Dec  4 12:17:52 2013
From: ofrenkel at redhat.com (Omer Frenkel)
Date: Wed, 4 Dec 2013 07:17:52 -0500 (EST)
Subject: [Engine-devel] [engine-devel] instance type as top-level entity
In-Reply-To: <220898566.1749726.1386159246739.JavaMail.root@redhat.com>
References: <220898566.1749726.1386159246739.JavaMail.root@redhat.com>
Message-ID: <711610057.23141349.1386159472456.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Tomas Jelinek" <tjelinek at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Cc: "Omer Frenkel" <ofrenkel at redhat.com>
> Sent: Wednesday, December 4, 2013 2:14:06 PM
> Subject: [engine-devel] instance type as top-level entity
> 
> Hey all,
> 
> I have started to work on the instance types[1] again and hit an issue. Since
> the instance types are supposed to be top-level entities
> (e.g. without the connection to DC/Cluster) but they are modeled as templates
> it is not possible to store them to DB since the DB constraints violation on
> vm_static table
> (e.g. the vds_group_id has to be unique and point to an existing vds_group).
> 
> So, I see 4 options:
> 
> 1: drop the constraints on the vm_static.vds_group_id (the
> vds_groups_vm_static constraint)
>    (most simple approach but would open the door to some issues which are now
>    guard on the DB level)
> 
> 2: do the same magic [well, hacks :) ] as with the "blank" template which is
> in the same situation
>    (not exactly a nice solution to have the instance types wired to one
>    specific cluster just to satisfy the constraint but return them all the
>    time)
> 
> 3: do not store this data in vm_static but create some new table called e.g.
> instance_type which would contain all of the fields from vm_static which are
> needed by it
>    (actually the best approach AFAIK but to do it correctly it would require
>    some more refactoring to do some hierarchy of tables and not copy the
>    fields from table to table)
> 
> 4: make the instance types not top-level (e.g. bound to specific DC/Cluster)
>    (would bring some issues for example with the default instance types which
>    should be present for all the DC/Clusters)
> 
> Thoughts?
> 
> Thank you,
> Tomas
> 
> [1]: http://www.ovirt.org/Features/Instance_Types
> 

according to the wiki (and discussions we had) instance type is bounded to a cluster (even if only as a changeable default)
so i dont think there is an issue..


From iheim at redhat.com  Wed Dec  4 16:29:57 2013
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 04 Dec 2013 18:29:57 +0200
Subject: [Engine-devel] [engine-devel] instance type as top-level entity
In-Reply-To: <711610057.23141349.1386159472456.JavaMail.root@redhat.com>
References: <220898566.1749726.1386159246739.JavaMail.root@redhat.com>
	<711610057.23141349.1386159472456.JavaMail.root@redhat.com>
Message-ID: <529F5885.9020103@redhat.com>

On 12/04/2013 02:17 PM, Omer Frenkel wrote:
>
>
> ----- Original Message -----
>> From: "Tomas Jelinek" <tjelinek at redhat.com>
>> To: "engine-devel" <engine-devel at ovirt.org>
>> Cc: "Omer Frenkel" <ofrenkel at redhat.com>
>> Sent: Wednesday, December 4, 2013 2:14:06 PM
>> Subject: [engine-devel] instance type as top-level entity
>>
>> Hey all,
>>
>> I have started to work on the instance types[1] again and hit an issue. Since
>> the instance types are supposed to be top-level entities
>> (e.g. without the connection to DC/Cluster) but they are modeled as templates
>> it is not possible to store them to DB since the DB constraints violation on
>> vm_static table
>> (e.g. the vds_group_id has to be unique and point to an existing vds_group).
>>
>> So, I see 4 options:
>>
>> 1: drop the constraints on the vm_static.vds_group_id (the
>> vds_groups_vm_static constraint)
>>     (most simple approach but would open the door to some issues which are now
>>     guard on the DB level)
>>
>> 2: do the same magic [well, hacks :) ] as with the "blank" template which is
>> in the same situation
>>     (not exactly a nice solution to have the instance types wired to one
>>     specific cluster just to satisfy the constraint but return them all the
>>     time)
>>
>> 3: do not store this data in vm_static but create some new table called e.g.
>> instance_type which would contain all of the fields from vm_static which are
>> needed by it
>>     (actually the best approach AFAIK but to do it correctly it would require
>>     some more refactoring to do some hierarchy of tables and not copy the
>>     fields from table to table)
>>
>> 4: make the instance types not top-level (e.g. bound to specific DC/Cluster)
>>     (would bring some issues for example with the default instance types which
>>     should be present for all the DC/Clusters)
>>
>> Thoughts?
>>
>> Thank you,
>> Tomas
>>
>> [1]: http://www.ovirt.org/Features/Instance_Types
>>
>
> according to the wiki (and discussions we had) instance type is bounded to a cluster (even if only as a changeable default)
> so i dont think there is an issue..

where in the wiki please?
the way i read the wiki its DC level, just like templates?



From iheim at redhat.com  Wed Dec  4 16:33:54 2013
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 04 Dec 2013 18:33:54 +0200
Subject: [Engine-devel] Using config values
In-Reply-To: <1728493072.3569411.1385889804043.JavaMail.root@redhat.com>
References: <52984D48.1070009@redhat.com>	<1643824061.43195741.1385878122949.JavaMail.root@redhat.com>	<1268805500.21090048.1385888119665.JavaMail.root@redhat.com>	<1138287431.43206802.1385888510815.JavaMail.root@redhat.com>	<823270883.21094118.1385888972530.JavaMail.root@redhat.com>
	<1728493072.3569411.1385889804043.JavaMail.root@redhat.com>
Message-ID: <529F5972.6040802@redhat.com>

On 12/01/2013 11:23 AM, Moti Asayag wrote:
>
>
> ----- Original Message -----
>> From: "Omer Frenkel" <ofrenkel at redhat.com>
>> To: "Mike Kolesnik" <mkolesni at redhat.com>
>> Cc: "engine-devel" <engine-devel at ovirt.org>
>> Sent: Sunday, December 1, 2013 11:09:32 AM
>> Subject: Re: [Engine-devel] Using config values
>>
>>
>>
>>
>>
>>
>> From: "Mike Kolesnik" <mkolesni at redhat.com>
>> To: "Omer Frenkel" <ofrenkel at redhat.com>
>> Cc: "Kanagaraj" <kmayilsa at redhat.com>, "engine-devel"
>> <engine-devel at ovirt.org>
>> Sent: Sunday, December 1, 2013 11:01:50 AM
>> Subject: Re: [Engine-devel] Using config values
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> From: "Mike Kolesnik" <mkolesni at redhat.com>
>> To: "Kanagaraj" <kmayilsa at redhat.com>
>> Cc: "engine-devel" <engine-devel at ovirt.org>
>> Sent: Sunday, December 1, 2013 8:08:42 AM
>> Subject: Re: [Engine-devel] Using config values
>>
>>
>>
>>
>> Hi All,
>>
>> Hi Kanagaraj,
>>
>>
>>
>>
>> The are some issues arising in configurations whenever we move up on the
>> versions(3.3 => 3.4), because of the way we store and interpret them.
>>
>> Whenever there is a new cluster level, you will need to add a new entry for
>> all(most) of the configuration. Mostly a copy paste if you see from 3.2 to
>> 3.3, except some CPU/PM type related configurations.
>> Better option would be to have the defaul config value in ConfigValues.java
>> and the overrides will go to config.sql. In this approach you don't need a
>> new entries to config.sql when there is a new cluster level.
>>
>> Lets take an exmaple, "SupportForceCreateVG" - This is supported from 3.1
>> onwards,
>>
>> If you look at config.sql, you will see following entries
>> select fn_db_add_config_value('SupportForceCreateVG','false','3.0');
>> select fn_db_add_config_value('SupportForceCreateVG','true','3.1');
>> select fn_db_add_config_value('SupportForceCreateVG','true','3.2');
>> select fn_db_add_config_value('SupportForceCreateVG','true','3.3');
>>
>> And in ConfigValues.java
>>
>> @TypeConverterAttribute(Boolean.class)
>> @DefaultValueAttribute("false")
>> SupportForceCreateVG,
>>
>> Now if there is 3.4 and 3.5, the user needs to add 2 more entries, which i
>> feel is redundant.
>>
>> Instead we can make
>>
>> @TypeConverterAttribute(Boolean.class)
>> @DefaultValueAttribute("true")
>> SupportForceCreateVG,
>>
>> and have only the following in config.sql
>> select fn_db_add_config_value('SupportForceCreateVG','false','3.0');
>>
>> if a particular value(for a specific cluster level) is not found in
>> Config.sql, the fallback is to use the value available in ConfigValues.java.
>>
>> This has already been implemented, there are many "feature supported"
>> configurations working like this (for example GlusterSupport).
>>
>> I think a more interesting approach would be to move these out of the DB
>> since these values don't really hav e a reson to be there.
>> Since the entire thing is abstracted by "Gluster/FeatureSupported" classes
>> then we can easily change mechanism (of course whatever code is not using it
>> can be easily converted to use the mechanism)
>>
>> For example a simple enum could do the trick:
>> ------------------------------------- EXAMPLE
>> -------------------------------------
>> /**
>> * Convenience class to check if a gluster feature is supported or not in any
>> given version.<br>
>> * Methods should be named by feature and accept version to check against.
>> */
>> public class GlusterFeatureSupported {
>> /**
>> * @param version
>> * Compatibility version to check for.
>> * @return <code>true</code> if gluster support is enabled, <code>false</code>
>> if it's not.
>> */
>> public static boolean gluster(Version version) {
>> return SupportedFeatures.GLUSTER.isSupportedOn(version);
>> }
>>
>> /**
>> * @param version
>> * Compatibility version to check for.
>> * @return <code>true</code> if gluster heavyweight refresh is enabled,
>> <code>false</code> if it's not.
>> */
>> public static boolean refreshHeavyWeight(Version version) {
>> return SupportedFeatures.REFRESH_HEAVYWEIGHT.isSupportedOn(version);
>> }
>>
>> /* More methods... */
>>
>> enum SupportedFeatures {
>> GLUSTER(Version.v3_0),
>> REFRESH_HEAVYWEIGHT(Version.v3_0, Version.v3_1),
>> /* More members */;
>>
>> private Set<Version> unsupportedVersions = new HashSet<Version>();
>>
>> private SupportedFeatures(Version... versions) {
>> unsupportedVersions.addAll(Arrays.asList(versions));
>> }
>>
>> public boolean isSupportedOn(Version version) {
>> return !unsupportedVersions.contains(version);
>> }
>> }
>> ------------------------------------- END EXAMPLE
>> -------------------------------------
>>
>> Thoughts?
>>
>> unless i didn't understand something, this is not good,
>> this should stay configurable by the users,
>> for example if some user experience some issues with a feature and want to
>> turn it off/change the values..
>> (not all version configuration are boolean, some are different values to
>> different versions, like cpu-list)
>>
>> This is for API level compatibility.
>> If VDSM doesn't support for example hot plug in 3.1 then the user can't just
>> decide that it does and change it.
>> Also, this is not changeable by user since it's not exposed by engine-config
>> (nor should it be).
>> some are exposed
>>
>>
>>
>> This is strictly for the engine-VDSM API compatibility, not for other configs
>> which are version specific.
>> right, but still user should be able to turn features off in case of
>> problems,
>> or change in some cases (for example it is possible to add support for more
>> power management devices, i know it was done by users)
>> no reason to block this
>>
>
> In this case you add additional protection level to block user from enabling features
> for unsupported cluster levels.
>
> However it sounds more reasonable than requiring the user to use a lower cluster level
> which enforces him to give up on other features.

lowering the cluster level is not supported.
there is a difference between the configs we expose to users, and the 
configs we prefer to not be changed, but are used to workaround issues 
in some cases.



From iheim at redhat.com  Wed Dec  4 16:35:12 2013
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 04 Dec 2013 18:35:12 +0200
Subject: [Engine-devel] Using config values
In-Reply-To: <1044736237.33757114.1385891934497.JavaMail.root@redhat.com>
References: <52984D48.1070009@redhat.com>
	<52987D19.9000203@redhat.com>	<1299085692.33736696.1385845115835.JavaMail.root@redhat.com>	<496533960.21093647.1385888566815.JavaMail.root@redhat.com>
	<1044736237.33757114.1385891934497.JavaMail.root@redhat.com>
Message-ID: <529F59C0.1030603@redhat.com>

On 12/01/2013 11:58 AM, Eli Mesika wrote:
>
>
> ----- Original Message -----
>> From: "Omer Frenkel" <ofrenkel at redhat.com>
>> To: "Eli Mesika" <emesika at redhat.com>
>> Cc: "Dusmant Kumar Pati" <dpati at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
>> Sent: Sunday, December 1, 2013 11:02:46 AM
>> Subject: Re: [Engine-devel] Using config values
>>
>>
>>
>> ----- Original Message -----
>>> From: "Eli Mesika" <emesika at redhat.com>
>>> To: "Dusmant Kumar Pati" <dpati at redhat.com>
>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>>> Sent: Saturday, November 30, 2013 10:58:35 PM
>>> Subject: Re: [Engine-devel] Using config values
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Dusmant Kumar Pati" <dpati at redhat.com>
>>>> To: "Kanagaraj" <kmayilsa at redhat.com>, "engine-devel"
>>>> <engine-devel at ovirt.org>
>>>> Sent: Friday, November 29, 2013 1:40:09 PM
>>>> Subject: Re: [Engine-devel] Using config values
>>>>
>>>> On 11/29/2013 01:46 PM, Kanagaraj wrote:
>>>>
>>>>
>>>> Hi All,
>>>>
>>>> The are some issues arising in configurations whenever we move up on the
>>>> versions(3.3 => 3.4), because of the way we store and interpret them.
>>>>
>>>> Whenever there is a new cluster level, you will need to add a new entry
>>>> for
>>>> all(most) of the configuration. Mostly a copy paste if you see from 3.2
>>>> to
>>>> 3.3, except some CPU/PM type related configurations.
>>>> Better option would be to have the defaul config value in
>>>> ConfigValues.java
>>>> and the overrides will go to config.sql. In this approach you don't need
>>>> a
>>>> new entries to config.sql when there is a new cluster level.
>>>>
>>>> Lets take an exmaple, "SupportForceCreateVG" - This is supported from 3.1
>>>> onwards,
>>>>
>>>> If you look at config.sql, you will see following entries
>>>> select fn_db_add_config_value('SupportForceCreateVG','false','3.0');
>>>> select fn_db_add_config_value('SupportForceCreateVG','true','3.1');
>>>> select fn_db_add_config_value('SupportForceCreateVG','true','3.2');
>>>> select fn_db_add_config_value('SupportForceCreateVG','true','3.3');
>>>>
>>>> And in ConfigValues.java
>>>>
>>>> @TypeConverterAttribute(Boolean.class)
>>>> @DefaultValueAttribute("false")
>>>> SupportForceCreateVG,
>>>>
>>>> Now if there is 3.4 and 3.5, the user needs to add 2 more entries, which
>>>> i
>>>> feel is redundant.
>>>>
>>>> Instead we can make
>>>>
>>>> @TypeConverterAttribute(Boolean.class)
>>>> @DefaultValueAttribute("true")
>>>> SupportForceCreateVG,
>>>>
>>>> and have only the following in config.sql
>>>> select fn_db_add_config_value('SupportForceCreateVG','false','3.0');
>>>>
>>>> if a particular value(for a specific cluster level) is not found in
>>>> Config.sql, the fallback is to use the value available in
>>>> ConfigValues.java.
>>>>
>>>> Please share your thoughts on this.
>>>
>>> Hi
>>>
>>> First of all I think its a good idea
>>> I have 2 questions
>>>
>>> 1) Which value will be stored as default in the java class for
>>> configuration
>>> values that are not a boolean, that represents if a feature is active or
>>> not.
>>>     Is that the latest version value ? sounds not obvious to me
>>>
>>
>> i guess this will have to have a configuration values for each version in the
>> db.
>>
>>> 2) There are some configuration values that are exposed to the user via the
>>> engine-config tool, how this will work, we can not remove the entries their
>>> since the user may change and override those values.
>>>
>>
>> in your suggestion below, there is the same issue,
>> if user want to change the 3.3 value, engine config will fail with "No such
>> entry"
>> because 3.3 will not be in the db..
>> so if we are not fixing this, i think using the current implementation is
>> good enough,
>
> In this case engine-config will add this key with the given value for that version, so , I see no problem in that...
> In addition the getConfigValue will lookup for version matching only the first time, so , if it was given a 3.4 version for key K and found a matching only for 3.2 , it will add to the cache K with the same value for version 3.4


I don't think 3.4 should inherit from 3.2, only from the default value.
i do think the code knowing if it should ask by cluster or dc level, or 
at 'general' level is wrong, and asking by cluster level should fetch 
the 'general' level before going to code level default.



From tjelinek at redhat.com  Thu Dec  5 07:40:01 2013
From: tjelinek at redhat.com (Tomas Jelinek)
Date: Thu, 5 Dec 2013 02:40:01 -0500 (EST)
Subject: [Engine-devel] [engine-devel] instance type as top-level entity
In-Reply-To: <529F5885.9020103@redhat.com>
References: <220898566.1749726.1386159246739.JavaMail.root@redhat.com>
	<711610057.23141349.1386159472456.JavaMail.root@redhat.com>
	<529F5885.9020103@redhat.com>
Message-ID: <308092418.2259849.1386229201991.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Omer Frenkel" <ofrenkel at redhat.com>, "Tomas Jelinek" <tjelinek at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Wednesday, December 4, 2013 5:29:57 PM
> Subject: Re: [Engine-devel] [engine-devel] instance type as top-level entity
> 
> On 12/04/2013 02:17 PM, Omer Frenkel wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Tomas Jelinek" <tjelinek at redhat.com>
> >> To: "engine-devel" <engine-devel at ovirt.org>
> >> Cc: "Omer Frenkel" <ofrenkel at redhat.com>
> >> Sent: Wednesday, December 4, 2013 2:14:06 PM
> >> Subject: [engine-devel] instance type as top-level entity
> >>
> >> Hey all,
> >>
> >> I have started to work on the instance types[1] again and hit an issue.
> >> Since
> >> the instance types are supposed to be top-level entities
> >> (e.g. without the connection to DC/Cluster) but they are modeled as
> >> templates
> >> it is not possible to store them to DB since the DB constraints violation
> >> on
> >> vm_static table
> >> (e.g. the vds_group_id has to be unique and point to an existing
> >> vds_group).
> >>
> >> So, I see 4 options:
> >>
> >> 1: drop the constraints on the vm_static.vds_group_id (the
> >> vds_groups_vm_static constraint)
> >>     (most simple approach but would open the door to some issues which are
> >>     now
> >>     guard on the DB level)
> >>
> >> 2: do the same magic [well, hacks :) ] as with the "blank" template which
> >> is
> >> in the same situation
> >>     (not exactly a nice solution to have the instance types wired to one
> >>     specific cluster just to satisfy the constraint but return them all
> >>     the
> >>     time)
> >>
> >> 3: do not store this data in vm_static but create some new table called
> >> e.g.
> >> instance_type which would contain all of the fields from vm_static which
> >> are
> >> needed by it
> >>     (actually the best approach AFAIK but to do it correctly it would
> >>     require
> >>     some more refactoring to do some hierarchy of tables and not copy the
> >>     fields from table to table)
> >>
> >> 4: make the instance types not top-level (e.g. bound to specific
> >> DC/Cluster)
> >>     (would bring some issues for example with the default instance types
> >>     which
> >>     should be present for all the DC/Clusters)
> >>
> >> Thoughts?
> >>
> >> Thank you,
> >> Tomas
> >>
> >> [1]: http://www.ovirt.org/Features/Instance_Types
> >>
> >
> > according to the wiki (and discussions we had) instance type is bounded to
> > a cluster (even if only as a changeable default)
> > so i dont think there is an issue..
> 
> where in the wiki please?
> the way i read the wiki its DC level, just like templates?

OK, it seems I have not asked the question correctly. Let me rephrase it:
Since we are going to provide default (predefined) instance types which the user is not allowed to delete I assume this instance types should 
be available for the whole system (not only for the default cluster) just like blank template.

This brings up a question if all the other instance types are going to be also system level and if yes, how are we going to solve it technically.
We still have the option to implement the instance types as templates and the default instance types as blank template, but the question is if this is
what makes most sense. 

The wiki currently says that the instance type is connected to cluster using vds_group_id field but as I have started some implementation this
question popped up in my mind (not yet documented on wiki - will be according to the result of this discussion).

BTW the question if the instance types are top level or not leads us to a different question - where to put them in GUI?
- If the instance type is a top level entity the best place to have it is the configure dialog (top right corner)
- If the instance type is not a top level entity the best place to have it is possibly a main tab (or part of the template main tab)


> 
> 


From sbonazzo at redhat.com  Fri Dec  6 10:27:03 2013
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Fri, 06 Dec 2013 11:27:03 +0100
Subject: [Engine-devel] [QE] oVirt 3.3.2 RC status
Message-ID: <52A1A677.4040508@redhat.com>

Hi,

we've scheduled oVirt 3.3.2 RC build on 2013-12-11 [1]

A bug tracker is available at [2] and it shows only 4 bugs still blocking the release:

Whiteboard	Bug ID	Summary
integration	1036209	[AIO] ssh issues
storage		1022961	Running a VM from a gluster domain uses mount instead of gluster URI
virt		1029885	cloud-init testcase does not work in engine 3.3.1
virt		1025829	sysprep floppy is not attached to Windows 2008 R2 machine - even when specifically checked in Run Once


Please provide an ETA for the above bugs.

1036209	[AIO] ssh issues: patch merged on master branch, ready to be merged (hopefully today) on 3.3 and 3.3.2 branches.

For those who want to help testing the bugs, I suggest to add yourself as QA contact for the bug and add yourself to the testing page [3].
Thanks to all which have already started testing beta release!

Maintainers should fill release notes before RC build, the page has been created here [4]

[1] http://www.ovirt.org/OVirt_3.3.z_release-management
[2] https://bugzilla.redhat.com/1027349
[3] http://www.ovirt.org/Testing/Ovirt_3.3.2_testing
[4] http://www.ovirt.org/OVirt_3.3.2_release_notes

Thanks,


-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com


From S.Kieske at mittwald.de  Fri Dec  6 10:42:41 2013
From: S.Kieske at mittwald.de (Sven Kieske)
Date: Fri, 6 Dec 2013 10:42:41 +0000
Subject: [Engine-devel] Fwd: [Users] oVirt Cloud-Init integration REST-API
In-Reply-To: <52A1A6DD.4020100@mittwald.de>
References: <52A1A6DD.4020100@mittwald.de>
Message-ID: <52A1AAD8.101@mittwald.de>

Hi,

I think this may be the more appropriate list to discuss this issue?

I fear this isn't integrated yet and can't be integrated in 3.3.1 or 3.3.2?


-------- Original-Nachricht --------
Betreff: [Users] oVirt Cloud-Init integration REST-API
Datum: Fri, 6 Dec 2013 10:25:42 +0000
Von: Sven Kieske <S.Kieske at mittwald.de>
An: gpadgett at redhat.com <gpadgett at redhat.com>, users at ovirt.org
<users at ovirt.org>

Hi,

we want to utilize Cloud-Init via REST-API, like mentioned on
the feature page in the wiki:
http://www.ovirt.org/Features/Cloud-Init_Integration

but looking at api?rsdl I do not find any clue
if this is implemented already in 3.3.1?

if yes, how to call this function?

if no, can we hack something in the db to activate it
or at least use the function to automatic build the
cd-roms which get passed to the vms?

I really need this feature.

Thanks for your help.

-- 
Mit freundlichen Gr??en / Regards

Sven Kieske

Systemadministrator
Mittwald CM Service GmbH & Co. KG
K?nigsberger Stra?e 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
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
_______________________________________________
Users mailing list
Users at ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


From S.Kieske at mittwald.de  Fri Dec  6 10:51:53 2013
From: S.Kieske at mittwald.de (Sven Kieske)
Date: Fri, 6 Dec 2013 10:51:53 +0000
Subject: [Engine-devel] Fwd: [Users] oVirt Cloud-Init integration
 REST-API
In-Reply-To: <52A1AAD8.101@mittwald.de>
References: <52A1A6DD.4020100@mittwald.de> <52A1AAD8.101@mittwald.de>
Message-ID: <52A1AD01.4080301@mittwald.de>

I created a BZ for this one as I can't find this function in the API:

https://bugzilla.redhat.com/show_bug.cgi?id=1039009

Am 06.12.2013 11:42, schrieb Sven Kieske:
> Hi,
> 
> I think this may be the more appropriate list to discuss this issue?
> 
> I fear this isn't integrated yet and can't be integrated in 3.3.1 or 3.3.2?
> 
> 
> -------- Original-Nachricht --------
> Betreff: [Users] oVirt Cloud-Init integration REST-API
> Datum: Fri, 6 Dec 2013 10:25:42 +0000
> Von: Sven Kieske <S.Kieske at mittwald.de>
> An: gpadgett at redhat.com <gpadgett at redhat.com>, users at ovirt.org
> <users at ovirt.org>
> 
> Hi,
> 
> we want to utilize Cloud-Init via REST-API, like mentioned on
> the feature page in the wiki:
> http://www.ovirt.org/Features/Cloud-Init_Integration
> 
> but looking at api?rsdl I do not find any clue
> if this is implemented already in 3.3.1?
> 
> if yes, how to call this function?
> 
> if no, can we hack something in the db to activate it
> or at least use the function to automatic build the
> cd-roms which get passed to the vms?
> 
> I really need this feature.
> 
> Thanks for your help.
> 

-- 
Mit freundlichen Gr??en / Regards

Sven Kieske

Systemadministrator
Mittwald CM Service GmbH & Co. KG
K?nigsberger Stra?e 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
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

From iheim at redhat.com  Fri Dec  6 12:24:10 2013
From: iheim at redhat.com (Itamar Heim)
Date: Fri, 06 Dec 2013 14:24:10 +0200
Subject: [Engine-devel] Jenkins JAVA_HOME
In-Reply-To: <EF26FC1776F7FF46BFC072393EFD13A2557F0977@SERV070.corp.eldorado.org.br>
References: <EF26FC1776F7FF46BFC072393EFD13A2557F0977@SERV070.corp.eldorado.org.br>
Message-ID: <52A1C1EA.4000903@redhat.com>

On 12/05/2013 09:55 PM, Gustavo Frederico Temple Pedrosa wrote:
> Hello all,
>
> I have two changes that the build failed with "Error: JAVA_HOME is not
> defined correctly."
>
> Anyone knows how I fix this?

more details/link?



From iheim at redhat.com  Fri Dec  6 12:31:17 2013
From: iheim at redhat.com (Itamar Heim)
Date: Fri, 06 Dec 2013 14:31:17 +0200
Subject: [Engine-devel] Fwd: [Users] oVirt Cloud-Init integration
	REST-API
In-Reply-To: <52A1AAD8.101@mittwald.de>
References: <52A1A6DD.4020100@mittwald.de> <52A1AAD8.101@mittwald.de>
Message-ID: <52A1C395.7080803@redhat.com>

On 12/06/2013 12:42 PM, Sven Kieske wrote:
> Hi,
>
> I think this may be the more appropriate list to discuss this issue?
>
> I fear this isn't integrated yet and can't be integrated in 3.3.1 or 3.3.2?

its already fixed for stable 3.3, but just after 3.3.2 was created...

http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=commit;h=45cfd1951d87293d3aad661372cdd4391b7116f8
http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=commit;h=4eb464cec2b4f529a6b6a76bbcb5bd76a5302188



>
>
> -------- Original-Nachricht --------
> Betreff: [Users] oVirt Cloud-Init integration REST-API
> Datum: Fri, 6 Dec 2013 10:25:42 +0000
> Von: Sven Kieske <S.Kieske at mittwald.de>
> An: gpadgett at redhat.com <gpadgett at redhat.com>, users at ovirt.org
> <users at ovirt.org>
>
> Hi,
>
> we want to utilize Cloud-Init via REST-API, like mentioned on
> the feature page in the wiki:
> http://www.ovirt.org/Features/Cloud-Init_Integration
>
> but looking at api?rsdl I do not find any clue
> if this is implemented already in 3.3.1?
>
> if yes, how to call this function?
>
> if no, can we hack something in the db to activate it
> or at least use the function to automatic build the
> cd-roms which get passed to the vms?
>
> I really need this feature.
>
> Thanks for your help.
>



From gustavo.pedrosa at eldorado.org.br  Fri Dec  6 12:48:23 2013
From: gustavo.pedrosa at eldorado.org.br (Gustavo Frederico Temple Pedrosa)
Date: Fri, 6 Dec 2013 12:48:23 +0000
Subject: [Engine-devel] RES: Jenkins JAVA_HOME
In-Reply-To: <52A1C1EA.4000903@redhat.com>
References: <EF26FC1776F7FF46BFC072393EFD13A2557F0977@SERV070.corp.eldorado.org.br>,
	<52A1C1EA.4000903@redhat.com>
Message-ID: <EF26FC1776F7FF46BFC072393EFD13A2557F0A53@SERV070.corp.eldorado.org.br>

(#22107)
http://jenkins.ovirt.org/job/ovirt_engine_master_find_bugs_gerrit/1098/console

(#18226)
http://jenkins.ovirt.org/job/ovirt_engine_master_find_bugs_gerrit/1095/console

(#17972)
http://jenkins.ovirt.org/job/ovirt_engine_master_find_bugs_gerrit/1039/console



________________________________________
De: Itamar Heim [iheim at redhat.com]
Enviado: sexta-feira, 6 de dezembro de 2013 10:24
Para: Gustavo Frederico Temple Pedrosa; infra at ovirt.org; engine-devel
Assunto: Re: Jenkins JAVA_HOME

On 12/05/2013 09:55 PM, Gustavo Frederico Temple Pedrosa wrote:
> Hello all,
>
> I have two changes that the build failed with "Error: JAVA_HOME is not
> defined correctly."
>
> Anyone knows how I fix this?

more details/link?

From S.Kieske at mittwald.de  Fri Dec  6 13:43:56 2013
From: S.Kieske at mittwald.de (Sven Kieske)
Date: Fri, 6 Dec 2013 13:43:56 +0000
Subject: [Engine-devel] Fwd: [Users] oVirt Cloud-Init integration
 REST-API
In-Reply-To: <52A1C395.7080803@redhat.com>
References: <52A1A6DD.4020100@mittwald.de> <52A1AAD8.101@mittwald.de>
	<52A1C395.7080803@redhat.com>
Message-ID: <52A1D552.1000901@mittwald.de>

Hi,

cool that there are patches, but is there any chance to get this into
3.3.1 or at least 3.3.2? we need this feature asap.

This is really urgent.

Am 06.12.2013 13:31, schrieb Itamar Heim:
> On 12/06/2013 12:42 PM, Sven Kieske wrote:
>> Hi,
>>
>> I think this may be the more appropriate list to discuss this issue?
>>
>> I fear this isn't integrated yet and can't be integrated in 3.3.1 or
>> 3.3.2?
> 
> its already fixed for stable 3.3, but just after 3.3.2 was created...
> 
> http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=commit;h=45cfd1951d87293d3aad661372cdd4391b7116f8
> 
> http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=commit;h=4eb464cec2b4f529a6b6a76bbcb5bd76a5302188

-- 
Mit freundlichen Gr??en / Regards

Sven Kieske

Systemadministrator
Mittwald CM Service GmbH & Co. KG
K?nigsberger Stra?e 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
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

From eedri at redhat.com  Fri Dec  6 20:17:06 2013
From: eedri at redhat.com (Eyal Edri)
Date: Fri, 6 Dec 2013 15:17:06 -0500 (EST)
Subject: [Engine-devel] RES: Jenkins JAVA_HOME
In-Reply-To: <EF26FC1776F7FF46BFC072393EFD13A2557F0A53@SERV070.corp.eldorado.org.br>
References: <EF26FC1776F7FF46BFC072393EFD13A2557F0977@SERV070.corp.eldorado.org.br>
	<52A1C1EA.4000903@redhat.com>
	<EF26FC1776F7FF46BFC072393EFD13A2557F0A53@SERV070.corp.eldorado.org.br>
Message-ID: <658125983.1472129.1386361026064.JavaMail.root@redhat.com>

Hi Gustavo,

The problem was misconfigured jnlp jenkins slave, please see other reply i sent to infra.

should be ok now, you can try and retrigger any jobs that failed on gerrit here: http://jenkins.ovirt.org/gerrit_manual_trigger/?

eyal.

----- Original Message -----
> From: "Gustavo Frederico Temple Pedrosa" <gustavo.pedrosa at eldorado.org.br>
> To: "Itamar Heim" <iheim at redhat.com>, infra at ovirt.org, "engine-devel" <engine-devel at ovirt.org>
> Sent: Friday, December 6, 2013 2:48:23 PM
> Subject: RES: Jenkins JAVA_HOME
> 
> (#22107)
> http://jenkins.ovirt.org/job/ovirt_engine_master_find_bugs_gerrit/1098/console
> 
> (#18226)
> http://jenkins.ovirt.org/job/ovirt_engine_master_find_bugs_gerrit/1095/console
> 
> (#17972)
> http://jenkins.ovirt.org/job/ovirt_engine_master_find_bugs_gerrit/1039/console
> 
> 
> 
> ________________________________________
> De: Itamar Heim [iheim at redhat.com]
> Enviado: sexta-feira, 6 de dezembro de 2013 10:24
> Para: Gustavo Frederico Temple Pedrosa; infra at ovirt.org; engine-devel
> Assunto: Re: Jenkins JAVA_HOME
> 
> On 12/05/2013 09:55 PM, Gustavo Frederico Temple Pedrosa wrote:
> > Hello all,
> >
> > I have two changes that the build failed with "Error: JAVA_HOME is not
> > defined correctly."
> >
> > Anyone knows how I fix this?
> 
> more details/link?
> _______________________________________________
> Infra mailing list
> Infra at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
> 


From iheim at redhat.com  Sat Dec  7 08:09:05 2013
From: iheim at redhat.com (Itamar Heim)
Date: Sat, 07 Dec 2013 10:09:05 +0200
Subject: [Engine-devel] Fwd: [Users] oVirt Cloud-Init integration
	REST-API
In-Reply-To: <52A1D552.1000901@mittwald.de>
References: <52A1A6DD.4020100@mittwald.de> <52A1AAD8.101@mittwald.de>
	<52A1C395.7080803@redhat.com> <52A1D552.1000901@mittwald.de>
Message-ID: <52A2D7A1.90405@redhat.com>

On 12/06/2013 03:43 PM, Sven Kieske wrote:
> Hi,
>
> cool that there are patches, but is there any chance to get this into
> 3.3.1 or at least 3.3.2? we need this feature asap.
>
> This is really urgent.
>

3.3.1 was released, i don't see it being re-spin for anything but a 
critical regression.
3.3.2 is in beta, so still planned to re-spin. omer/michal - thoughts 
about backporting this to 3.3.2?

> Am 06.12.2013 13:31, schrieb Itamar Heim:
>> On 12/06/2013 12:42 PM, Sven Kieske wrote:
>>> Hi,
>>>
>>> I think this may be the more appropriate list to discuss this issue?
>>>
>>> I fear this isn't integrated yet and can't be integrated in 3.3.1 or
>>> 3.3.2?
>>
>> its already fixed for stable 3.3, but just after 3.3.2 was created...
>>
>> http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=commit;h=45cfd1951d87293d3aad661372cdd4391b7116f8
>>
>> http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=commit;h=4eb464cec2b4f529a6b6a76bbcb5bd76a5302188
>



From ofrenkel at redhat.com  Sun Dec  8 08:41:43 2013
From: ofrenkel at redhat.com (Omer Frenkel)
Date: Sun, 8 Dec 2013 03:41:43 -0500 (EST)
Subject: [Engine-devel] Fwd: [Users] oVirt Cloud-Init integration
 REST-API
In-Reply-To: <52A2D7A1.90405@redhat.com>
References: <52A1A6DD.4020100@mittwald.de> <52A1AAD8.101@mittwald.de>
	<52A1C395.7080803@redhat.com> <52A1D552.1000901@mittwald.de>
	<52A2D7A1.90405@redhat.com>
Message-ID: <338654880.26210590.1386492103177.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Sven Kieske" <S.Kieske at mittwald.de>, engine-devel at ovirt.org, "Omer Frenkel" <ofrenkel at redhat.com>, "Michal
> Skrivanek" <mskrivan at redhat.com>
> Sent: Saturday, December 7, 2013 10:09:05 AM
> Subject: Re: [Engine-devel] Fwd: [Users] oVirt Cloud-Init integration REST-API
> 
> On 12/06/2013 03:43 PM, Sven Kieske wrote:
> > Hi,
> >
> > cool that there are patches, but is there any chance to get this into
> > 3.3.1 or at least 3.3.2? we need this feature asap.
> >
> > This is really urgent.
> >
> 
> 3.3.1 was released, i don't see it being re-spin for anything but a
> critical regression.
> 3.3.2 is in beta, so still planned to re-spin. omer/michal - thoughts
> about backporting this to 3.3.2?

sent http://gerrit.ovirt.org/#/c/22139/

> 
> > Am 06.12.2013 13:31, schrieb Itamar Heim:
> >> On 12/06/2013 12:42 PM, Sven Kieske wrote:
> >>> Hi,
> >>>
> >>> I think this may be the more appropriate list to discuss this issue?
> >>>
> >>> I fear this isn't integrated yet and can't be integrated in 3.3.1 or
> >>> 3.3.2?
> >>
> >> its already fixed for stable 3.3, but just after 3.3.2 was created...
> >>
> >> http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=commit;h=45cfd1951d87293d3aad661372cdd4391b7116f8
> >>
> >> http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=commit;h=4eb464cec2b4f529a6b6a76bbcb5bd76a5302188
> >
> 
> 


From S.Kieske at mittwald.de  Mon Dec  9 08:08:25 2013
From: S.Kieske at mittwald.de (Sven Kieske)
Date: Mon, 9 Dec 2013 08:08:25 +0000
Subject: [Engine-devel] Fwd: [Users] oVirt Cloud-Init integration
 REST-API
In-Reply-To: <338654880.26210590.1386492103177.JavaMail.root@redhat.com>
References: <52A1A6DD.4020100@mittwald.de> <52A1AAD8.101@mittwald.de>
	<52A1C395.7080803@redhat.com> <52A1D552.1000901@mittwald.de>
	<52A2D7A1.90405@redhat.com>
	<338654880.26210590.1386492103177.JavaMail.root@redhat.com>
Message-ID: <52A57B35.4040001@mittwald.de>

Hi,

I appreciate your backport!
Are the RPMs in the beta repo also updated?
I would test this feature intensive, so
you might get valuable feedback.

-- 
Mit freundlichen Gr??en / Regards

Sven Kieske

Systemadministrator
Mittwald CM Service GmbH & Co. KG
K?nigsberger Stra?e 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
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

From sbonazzo at redhat.com  Mon Dec  9 09:30:58 2013
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Mon, 09 Dec 2013 10:30:58 +0100
Subject: [Engine-devel] [QE] oVirt 3.3.2 RC status
In-Reply-To: <52A1A677.4040508@redhat.com>
References: <52A1A677.4040508@redhat.com>
Message-ID: <52A58DD2.4070504@redhat.com>

Hi,

we've scheduled oVirt 3.3.2 RC build on 2013-12-11 [1]

A bug tracker is available at [2] and it shows only 3 bugs still blocking the release:
Whiteboard	Bug ID	Summary
storage		1022961	Running a VM from a gluster domain uses mount instead of gluster URI
virt		1029885	cloud-init testcase does not work in engine 3.3.1
virt		1025829	sysprep floppy is not attached to Windows 2008 R2 machine - even when specifically checked in Run Once

Please provide an ETA for the above bugs.

oVirt 3.3.2 beta testing is in progress, thanks to all who already started testing it!
For those willing to help testing the bugs, I suggest to add yourself as QA contact for the bug and add yourself to the testing page [3].

Maintainers should fill release notes before RC build, the page has been created here [4]

[1] http://www.ovirt.org/OVirt_3.3.z_release-management
[2] https://bugzilla.redhat.com/1027349
[3] http://www.ovirt.org/Testing/Ovirt_3.3.2_testing
[4] http://www.ovirt.org/OVirt_3.3.2_release_notes

Thanks,


-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com


From ofrenkel at redhat.com  Mon Dec  9 09:47:05 2013
From: ofrenkel at redhat.com (Omer Frenkel)
Date: Mon, 9 Dec 2013 04:47:05 -0500 (EST)
Subject: [Engine-devel] [QE] oVirt 3.3.2 RC status
In-Reply-To: <52A58DD2.4070504@redhat.com>
References: <52A1A677.4040508@redhat.com> <52A58DD2.4070504@redhat.com>
Message-ID: <317716930.26551595.1386582425882.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>, Users at ovirt.org, "VDSM Project Development"
> <vdsm-devel at lists.fedorahosted.org>, "Eduardo Warszawski" <ewarszaw at redhat.com>, "Roy Golan" <rgolan at redhat.com>,
> "Omer Frenkel" <ofrenkel at redhat.com>, "vdsm-devel" <vdsm-devel at fedorahosted.org>
> Cc: "Itamar Heim" <iheim at redhat.com>
> Sent: Monday, December 9, 2013 11:30:58 AM
> Subject: Re: [Engine-devel] [QE] oVirt 3.3.2 RC status
> 
> Hi,
> 
> we've scheduled oVirt 3.3.2 RC build on 2013-12-11 [1]
> 
> A bug tracker is available at [2] and it shows only 3 bugs still blocking the
> release:
> Whiteboard	Bug ID	Summary
> storage		1022961	Running a VM from a gluster domain uses mount instead of
> gluster URI
> virt		1029885	cloud-init testcase does not work in engine 3.3.1

3.3.2 backported and wait for review from REST

> virt		1025829	sysprep floppy is not attached to Windows 2008 R2 machine -
> even when specifically checked in Run Once
> 
> Please provide an ETA for the above bugs.
> 
> oVirt 3.3.2 beta testing is in progress, thanks to all who already started
> testing it!
> For those willing to help testing the bugs, I suggest to add yourself as QA
> contact for the bug and add yourself to the testing page [3].
> 
> Maintainers should fill release notes before RC build, the page has been
> created here [4]
> 
> [1] http://www.ovirt.org/OVirt_3.3.z_release-management
> [2] https://bugzilla.redhat.com/1027349
> [3] http://www.ovirt.org/Testing/Ovirt_3.3.2_testing
> [4] http://www.ovirt.org/OVirt_3.3.2_release_notes
> 
> Thanks,
> 
> 
> --
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com
> 


From mpastern at redhat.com  Mon Dec  9 10:47:12 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Mon, 09 Dec 2013 12:47:12 +0200
Subject: [Engine-devel] master is broken by Common#VdcActionUtilsTest ??
Message-ID: <52A59FB0.3070007@redhat.com>




[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:testCompile (default-testCompile) on project common: Compilation failure: Compilation
failure:
[ERROR] /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[13,42] error: package
org.ovirt.engine.core.common.action does not exist
[ERROR] /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[14,52] error: cannot
find symbol
[ERROR] package org.ovirt.engine.core.common.businessentities
[ERROR] /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[15,52] error: cannot
find symbol
[ERROR] package org.ovirt.engine.core.common.businessentities
[ERROR] /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[16,52] error: cannot
find symbol
[ERROR] package org.ovirt.engine.core.common.businessentities
[ERROR] /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[17,52] error: cannot
find symbol
[ERROR] package org.ovirt.engine.core.common.businessentities
[ERROR] /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[18,52] error: cannot
find symbol
[ERROR] package org.ovirt.engine.core.common.businessentities
[ERROR] /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[19,52] error: cannot
find symbol
[ERROR] package org.ovirt.engine.core.common.businessentities
[ERROR] /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[20,52] error: cannot
find symbol
[ERROR] package org.ovirt.engine.core.common.businessentities
[ERROR] /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[21,52] error: cannot
find symbol

...

org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:testCompile (default-testCompile) on
project common: Compilation failure
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
        at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
        at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
        at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
        at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
        at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
        at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
        at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:606)
        at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
        at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
        at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:414)
        at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:357)
Caused by: org.apache.maven.plugin.CompilationFailureException: Compilation failure
        at org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:656)
        at org.apache.maven.plugin.TestCompilerMojo.execute(TestCompilerMojo.java:161)
        at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
        ... 19 more


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From oliel at redhat.com  Mon Dec  9 10:59:03 2013
From: oliel at redhat.com (Ori Liel)
Date: Mon, 9 Dec 2013 05:59:03 -0500 (EST)
Subject: [Engine-devel] restapi: Permissions in Capabilities (#859225)
In-Reply-To: <757316122.1866024.1386585197262.JavaMail.root@redhat.com>
Message-ID: <86150267.1879702.1386586743183.JavaMail.root@redhat.com>

When listing the application's capabilities we currently show 'permissions' both for each version, and outside versions altogether: 

GET .../api/capabilities

<capabilities>
  <permits></permits>
  <version major="3" minor="1" href="/api/capabilities/332e3133-2e31-332e-3133-2e31332e3133" id="332e3133-2e31-332e-3133-2e31332e3133">
     <permits>...</permits>
  </version>
  <version major="3" minor="0" href="/api/capabilities/332e3033-2e30-332e-3033-2e30332e3033" id="332e3033-2e30-332e-3033-2e30332e3033">
     <permits>...</permits>
  </version>
</capabilities>


1) Permissions should only exist within a version; their current existence outside 'version' is for backwards compatibility only. We assume that no one (except perhaps Automation) uses these non-version-specific permissions these days, and we'd like to remove them. 

2) Regarding permissions within a version - Oded brought up that some permissions which are only relevant for 3.1 are listed also under 3.0 (for example, quota related permissions). In order for the API layer to be able to group permissions by version, permission<-->version metadata must exist somewhere. The permissions enum in the engine seems a natural place to put it, as Michael commented. Setting out to do this, I realized that which-permission-belongs-to-which-version is knowledge that I don't have, and don't really know how to get efficiently, and I sort of got stuck because of this. Ideas regarding this issue? 

Thanks, 

Ori. 



From yzaslavs at redhat.com  Mon Dec  9 11:11:46 2013
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Mon, 9 Dec 2013 06:11:46 -0500 (EST)
Subject: [Engine-devel] master is broken by Common#VdcActionUtilsTest ??
In-Reply-To: <52A59FB0.3070007@redhat.com>
References: <52A59FB0.3070007@redhat.com>
Message-ID: <184197218.13543831.1386587506493.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Michael Pasternak" <mpastern at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, December 9, 2013 12:47:12 PM
> Subject: [Engine-devel] master is broken by Common#VdcActionUtilsTest ??

Please provide the commit hash you tried to compile with ?

> 
> 
> 
> 
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:2.3.2:testCompile
> (default-testCompile) on project common: Compilation failure: Compilation
> failure:
> [ERROR]
> /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[13,42]
> error: package
> org.ovirt.engine.core.common.action does not exist
> [ERROR]
> /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[14,52]
> error: cannot
> find symbol
> [ERROR] package org.ovirt.engine.core.common.businessentities
> [ERROR]
> /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[15,52]
> error: cannot
> find symbol
> [ERROR] package org.ovirt.engine.core.common.businessentities
> [ERROR]
> /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[16,52]
> error: cannot
> find symbol
> [ERROR] package org.ovirt.engine.core.common.businessentities
> [ERROR]
> /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[17,52]
> error: cannot
> find symbol
> [ERROR] package org.ovirt.engine.core.common.businessentities
> [ERROR]
> /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[18,52]
> error: cannot
> find symbol
> [ERROR] package org.ovirt.engine.core.common.businessentities
> [ERROR]
> /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[19,52]
> error: cannot
> find symbol
> [ERROR] package org.ovirt.engine.core.common.businessentities
> [ERROR]
> /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[20,52]
> error: cannot
> find symbol
> [ERROR] package org.ovirt.engine.core.common.businessentities
> [ERROR]
> /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[21,52]
> error: cannot
> find symbol
> 
> ...
> 
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:testCompile
> (default-testCompile) on
> project common: Compilation failure
>         at
>         org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
>         at
>         org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
>         at
>         org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
>         at
>         org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
>         at
>         org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
>         at
>         org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
>         at
>         org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
>         at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
>         at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
>         at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
>         at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
>         at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at
>         sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>         at
>         sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>         at java.lang.reflect.Method.invoke(Method.java:606)
>         at
>         org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
>         at
>         org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
>         at
>         org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:414)
>         at
>         org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:357)
> Caused by: org.apache.maven.plugin.CompilationFailureException: Compilation
> failure
>         at
>         org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:656)
>         at
>         org.apache.maven.plugin.TestCompilerMojo.execute(TestCompilerMojo.java:161)
>         at
>         org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
>         at
>         org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
>         ... 19 more
> 
> 
> --
> 
> Michael Pasternak
> RedHat, ENG-Virtualization R&D
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From iheim at redhat.com  Mon Dec  9 11:22:21 2013
From: iheim at redhat.com (Itamar Heim)
Date: Mon, 09 Dec 2013 13:22:21 +0200
Subject: [Engine-devel] Fwd: [Users] oVirt Cloud-Init integration
	REST-API
In-Reply-To: <52A57B35.4040001@mittwald.de>
References: <52A1A6DD.4020100@mittwald.de> <52A1AAD8.101@mittwald.de>
	<52A1C395.7080803@redhat.com> <52A1D552.1000901@mittwald.de>
	<52A2D7A1.90405@redhat.com>
	<338654880.26210590.1386492103177.JavaMail.root@redhat.com>
	<52A57B35.4040001@mittwald.de>
Message-ID: <52A5A7ED.5070104@redhat.com>

On 12/09/2013 10:08 AM, Sven Kieske wrote:
> Hi,
>
> I appreciate your backport!
> Are the RPMs in the beta repo also updated?
> I would test this feature intensive, so
> you might get valuable feedback.
>

iirc, 3.3.2 is slated to be refreshed wednesday, assuming all blockers 
are fixed.


From sbonazzo at redhat.com  Mon Dec  9 11:27:11 2013
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Mon, 09 Dec 2013 12:27:11 +0100
Subject: [Engine-devel] Fwd: [Users] oVirt Cloud-Init integration
	REST-API
In-Reply-To: <52A5A7ED.5070104@redhat.com>
References: <52A1A6DD.4020100@mittwald.de> <52A1AAD8.101@mittwald.de>
	<52A1C395.7080803@redhat.com> <52A1D552.1000901@mittwald.de>
	<52A2D7A1.90405@redhat.com>
	<338654880.26210590.1386492103177.JavaMail.root@redhat.com>
	<52A57B35.4040001@mittwald.de> <52A5A7ED.5070104@redhat.com>
Message-ID: <52A5A90F.2020906@redhat.com>

Il 09/12/2013 12:22, Itamar Heim ha scritto:
> On 12/09/2013 10:08 AM, Sven Kieske wrote:
>> Hi,
>>
>> I appreciate your backport!
>> Are the RPMs in the beta repo also updated?
>> I would test this feature intensive, so
>> you might get valuable feedback.
>>
> 
> iirc, 3.3.2 is slated to be refreshed wednesday, assuming all blockers are fixed.

Well, we can refresh anyway on Wednesday also if not all blockers are fixed,
allowing to test the fixed bugs.
We'll discuss this on Wednesday sync meeting.


-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com


From mpastern at redhat.com  Mon Dec  9 11:36:22 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Mon, 09 Dec 2013 13:36:22 +0200
Subject: [Engine-devel] master is broken by Common#VdcActionUtilsTest ??
In-Reply-To: <184197218.13543831.1386587506493.JavaMail.root@redhat.com>
References: <52A59FB0.3070007@redhat.com>
	<184197218.13543831.1386587506493.JavaMail.root@redhat.com>
Message-ID: <52A5AB36.10600@redhat.com>

On 12/09/2013 01:11 PM, Yair Zaslavsky wrote:
> 
> 
> ----- Original Message -----
>> From: "Michael Pasternak" <mpastern at redhat.com>
>> To: "engine-devel" <engine-devel at ovirt.org>
>> Sent: Monday, December 9, 2013 12:47:12 PM
>> Subject: [Engine-devel] master is broken by Common#VdcActionUtilsTest ??
> 
> Please provide the commit hash you tried to compile with ?

30ff53078b18063e1ee94f68db11e91d49515e27

thanks.

> 
>>
>>
>>
>>
>> [ERROR] Failed to execute goal
>> org.apache.maven.plugins:maven-compiler-plugin:2.3.2:testCompile
>> (default-testCompile) on project common: Compilation failure: Compilation
>> failure:
>> [ERROR]
>> /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[13,42]
>> error: package
>> org.ovirt.engine.core.common.action does not exist
>> [ERROR]
>> /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[14,52]
>> error: cannot
>> find symbol
>> [ERROR] package org.ovirt.engine.core.common.businessentities
>> [ERROR]
>> /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[15,52]
>> error: cannot
>> find symbol
>> [ERROR] package org.ovirt.engine.core.common.businessentities
>> [ERROR]
>> /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[16,52]
>> error: cannot
>> find symbol
>> [ERROR] package org.ovirt.engine.core.common.businessentities
>> [ERROR]
>> /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[17,52]
>> error: cannot
>> find symbol
>> [ERROR] package org.ovirt.engine.core.common.businessentities
>> [ERROR]
>> /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[18,52]
>> error: cannot
>> find symbol
>> [ERROR] package org.ovirt.engine.core.common.businessentities
>> [ERROR]
>> /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[19,52]
>> error: cannot
>> find symbol
>> [ERROR] package org.ovirt.engine.core.common.businessentities
>> [ERROR]
>> /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[20,52]
>> error: cannot
>> find symbol
>> [ERROR] package org.ovirt.engine.core.common.businessentities
>> [ERROR]
>> /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[21,52]
>> error: cannot
>> find symbol
>>
>> ...
>>
>> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
>> goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:testCompile
>> (default-testCompile) on
>> project common: Compilation failure
>>         at
>>         org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
>>         at
>>         org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
>>         at
>>         org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
>>         at
>>         org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
>>         at
>>         org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
>>         at
>>         org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
>>         at
>>         org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
>>         at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
>>         at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
>>         at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
>>         at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
>>         at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
>>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>         at
>>         sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>>         at
>>         sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>         at java.lang.reflect.Method.invoke(Method.java:606)
>>         at
>>         org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
>>         at
>>         org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
>>         at
>>         org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:414)
>>         at
>>         org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:357)
>> Caused by: org.apache.maven.plugin.CompilationFailureException: Compilation
>> failure
>>         at
>>         org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:656)
>>         at
>>         org.apache.maven.plugin.TestCompilerMojo.execute(TestCompilerMojo.java:161)
>>         at
>>         org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
>>         at
>>         org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
>>         ... 19 more
>>
>>
>> --
>>
>> Michael Pasternak
>> RedHat, ENG-Virtualization R&D
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From kmayilsa at redhat.com  Mon Dec  9 11:52:50 2013
From: kmayilsa at redhat.com (Kanagaraj)
Date: Mon, 09 Dec 2013 17:22:50 +0530
Subject: [Engine-devel] make is failing in ovirt-engine master
Message-ID: <52A5AF12.5080501@redhat.com>

Hi,

  make clean install-dev PREFIX="$HOME/ovirt-engine"  is failing with 
following error on master branch.

  if [ "1" != 0 ]; then \
         build/python-check.sh; \
fi
packaging/setup/ovirt_engine_setup/database.py:365:80: E501 line too 
long (82 > 79 characters)
make[1]: *** [python-validation] Error 1
make[1]: Leaving directory `/home/kanagaraj/workspace/ovirt-engine'
make: *** [all-dev] Error 2

Can someone please fix this?

Thanks,
Kanagaraj


From alonbl at redhat.com  Mon Dec  9 11:57:38 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Mon, 9 Dec 2013 06:57:38 -0500 (EST)
Subject: [Engine-devel] make is failing in ovirt-engine master
In-Reply-To: <52A5AF12.5080501@redhat.com>
References: <52A5AF12.5080501@redhat.com>
Message-ID: <992051532.23934018.1386590258861.JavaMail.root@redhat.com>

http://gerrit.ovirt.org/#/c/22188/

----- Original Message -----
> From: "Kanagaraj" <kmayilsa at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, December 9, 2013 1:52:50 PM
> Subject: [Engine-devel] make is failing in ovirt-engine master
> 
> Hi,
> 
>   make clean install-dev PREFIX="$HOME/ovirt-engine"  is failing with
> following error on master branch.
> 
>   if [ "1" != 0 ]; then \
>          build/python-check.sh; \
> fi
> packaging/setup/ovirt_engine_setup/database.py:365:80: E501 line too
> long (82 > 79 characters)
> make[1]: *** [python-validation] Error 1
> make[1]: Leaving directory `/home/kanagaraj/workspace/ovirt-engine'
> make: *** [all-dev] Error 2
> 
> Can someone please fix this?
> 
> Thanks,
> Kanagaraj
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From sbonazzo at redhat.com  Mon Dec  9 14:01:47 2013
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Mon, 09 Dec 2013 15:01:47 +0100
Subject: [Engine-devel] Setting cluster CPU
Message-ID: <52A5CD4B.1000806@redhat.com>

Hi,
I'm trying to set the cluster CPU type while adding the first host to the Default cluster.

I know how to set the CPU type on a new cluster, since I'll do that in AIO plugin.
But I'm not sure to understand how to set the CPU on an existing cluster.

Should it be enough to specify cpu arg while adding the host to the cluster?
(before adding an host, cpu is None on the cluster)
Because I'm trying to do that without success (obtaining a sandybridge cluster while specifying westmere cpu).

Michael, can you take a look at http://gerrit.ovirt.org/22129 and advise?


-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com


From emesika at redhat.com  Mon Dec  9 15:21:00 2013
From: emesika at redhat.com (Eli Mesika)
Date: Mon, 9 Dec 2013 10:21:00 -0500 (EST)
Subject: [Engine-devel] make is failing in ovirt-engine master
In-Reply-To: <52A5AF12.5080501@redhat.com>
References: <52A5AF12.5080501@redhat.com>
Message-ID: <429386882.37165287.1386602460634.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Kanagaraj" <kmayilsa at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, December 9, 2013 1:52:50 PM
> Subject: [Engine-devel] make is failing in ovirt-engine master
> 
> Hi,
> 
>   make clean install-dev PREFIX="$HOME/ovirt-engine"  is failing with
> following error on master branch.
> 
>   if [ "1" != 0 ]; then \
>          build/python-check.sh; \
> fi
> packaging/setup/ovirt_engine_setup/database.py:365:80: E501 line too
> long (82 > 79 characters)
> make[1]: *** [python-validation] Error 1
> make[1]: Leaving directory `/home/kanagaraj/workspace/ovirt-engine'
> make: *** [all-dev] Error 2
> 
> Can someone please fix this?

merged , please take latest 

> 
> Thanks,
> Kanagaraj
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From michal.skrivanek at redhat.com  Mon Dec  9 15:50:49 2013
From: michal.skrivanek at redhat.com (Michal Skrivanek)
Date: Mon, 9 Dec 2013 17:50:49 +0200
Subject: [Engine-devel] Setting cluster CPU
In-Reply-To: <52A5CD4B.1000806@redhat.com>
References: <52A5CD4B.1000806@redhat.com>
Message-ID: <44A1E27A-9973-4D4F-B9D7-03C1DAF7161B@redhat.com>


On Dec 9, 2013, at 16:01 , Sandro Bonazzola <sbonazzo at redhat.com> wrote:

> Hi,
> I'm trying to set the cluster CPU type while adding the first host to the Default cluster.
> 
> I know how to set the CPU type on a new cluster, since I'll do that in AIO plugin.
> But I'm not sure to understand how to set the CPU on an existing cluster.
> 
> Should it be enough to specify cpu arg while adding the host to the cluster?
> (before adding an host, cpu is None on the cluster)
> Because I'm trying to do that without success (obtaining a sandybridge cluster while specifying westmere cpu).

The CPU should be set from the first host if None. That is needed for the PPC support. Roy, we talked about it recently, where are we with this patch.

Thanks,
michal

> 
> Michael, can you take a look at http://gerrit.ovirt.org/22129 and advise?
> 
> 
> -- 
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From ovedo at redhat.com  Mon Dec  9 16:58:29 2013
From: ovedo at redhat.com (Oved Ourfalli)
Date: Mon, 9 Dec 2013 11:58:29 -0500 (EST)
Subject: [Engine-devel] Setting cluster CPU
In-Reply-To: <44A1E27A-9973-4D4F-B9D7-03C1DAF7161B@redhat.com>
References: <52A5CD4B.1000806@redhat.com>
	<44A1E27A-9973-4D4F-B9D7-03C1DAF7161B@redhat.com>
Message-ID: <1421132832.38152228.1386608309092.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Michal Skrivanek" <michal.skrivanek at redhat.com>
> To: "Sandro Bonazzola" <sbonazzo at redhat.com>, "Roy Golan" <rgolan at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, December 9, 2013 5:50:49 PM
> Subject: Re: [Engine-devel] Setting cluster CPU
> 
> 
> On Dec 9, 2013, at 16:01 , Sandro Bonazzola <sbonazzo at redhat.com> wrote:
> 
> > Hi,
> > I'm trying to set the cluster CPU type while adding the first host to the
> > Default cluster.
> > 
> > I know how to set the CPU type on a new cluster, since I'll do that in AIO
> > plugin.
> > But I'm not sure to understand how to set the CPU on an existing cluster.
> > 
> > Should it be enough to specify cpu arg while adding the host to the
> > cluster?
> > (before adding an host, cpu is None on the cluster)
> > Because I'm trying to do that without success (obtaining a sandybridge
> > cluster while specifying westmere cpu).
> 
> The CPU should be set from the first host if None. That is needed for the PPC
> support. Roy, we talked about it recently, where are we with this patch.
> 

We already support modifying the CPU level of an existing cluster. If changing it to a higher level then we just change it.
If changing it to a lower level, and there are running VMs on the cluster, then we warn the user that some VMs might not be migrate-able, as we added a scheduling filter to filter out hosts with improper CPU level.

Unless I'm missing something, that covers the use-case, isn't it?

> Thanks,
> michal
> 
> > 
> > Michael, can you take a look at http://gerrit.ovirt.org/22129 and advise?
> > 
> > 
> > --
> > Sandro Bonazzola
> > Better technology. Faster innovation. Powered by community collaboration.
> > See how it works at redhat.com
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From michal.skrivanek at redhat.com  Mon Dec  9 18:37:00 2013
From: michal.skrivanek at redhat.com (Michal Skrivanek)
Date: Mon, 9 Dec 2013 13:37:00 -0500 (EST)
Subject: [Engine-devel] Setting cluster CPU
In-Reply-To: <1421132832.38152228.1386608309092.JavaMail.root@redhat.com>
References: <52A5CD4B.1000806@redhat.com>
	<44A1E27A-9973-4D4F-B9D7-03C1DAF7161B@redhat.com>
	<1421132832.38152228.1386608309092.JavaMail.root@redhat.com>
Message-ID: <211CC433-A88D-4C6B-A851-E3A8443DC49B@redhat.com>



> On 09 Dec 2013, at 18:58, Oved Ourfalli <ovedo at redhat.com> wrote:
> 
> 
> 
> ----- Original Message -----
>> From: "Michal Skrivanek" <michal.skrivanek at redhat.com>
>> To: "Sandro Bonazzola" <sbonazzo at redhat.com>, "Roy Golan" <rgolan at redhat.com>
>> Cc: "engine-devel" <engine-devel at ovirt.org>
>> Sent: Monday, December 9, 2013 5:50:49 PM
>> Subject: Re: [Engine-devel] Setting cluster CPU
>> 
>> 
>>> On Dec 9, 2013, at 16:01 , Sandro Bonazzola <sbonazzo at redhat.com> wrote:
>>> 
>>> Hi,
>>> I'm trying to set the cluster CPU type while adding the first host to the
>>> Default cluster.
>>> 
>>> I know how to set the CPU type on a new cluster, since I'll do that in AIO
>>> plugin.
>>> But I'm not sure to understand how to set the CPU on an existing cluster.
>>> 
>>> Should it be enough to specify cpu arg while adding the host to the
>>> cluster?
>>> (before adding an host, cpu is None on the cluster)
>>> Because I'm trying to do that without success (obtaining a sandybridge
>>> cluster while specifying westmere cpu).
>> 
>> The CPU should be set from the first host if None. That is needed for the PPC
>> support. Roy, we talked about it recently, where are we with this patch.
> 
> We already support modifying the CPU level of an existing cluster. If changing it to a higher level then we just change it.
> If changing it to a lower level, and there are running VMs on the cluster, then we warn the user that some VMs might not be migrate-able, as we added a scheduling filter to filter out hosts with improper CPU level.
> 
> Unless I'm missing something, that covers the use-case, isn't it?

Not sure. I thought this is None to something, where it should work automatically without specifying anything. Just add an operational host

> 
>> Thanks,
>> michal
>> 
>>> 
>>> Michael, can you take a look at http://gerrit.ovirt.org/22129 and advise?
>>> 
>>> 
>>> --
>>> Sandro Bonazzola
>>> Better technology. Faster innovation. Powered by community collaboration.
>>> See how it works at redhat.com
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>> 
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>> 


From sbonazzo at redhat.com  Tue Dec 10 07:12:14 2013
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Tue, 10 Dec 2013 08:12:14 +0100
Subject: [Engine-devel] Setting cluster CPU
In-Reply-To: <211CC433-A88D-4C6B-A851-E3A8443DC49B@redhat.com>
References: <52A5CD4B.1000806@redhat.com>
	<44A1E27A-9973-4D4F-B9D7-03C1DAF7161B@redhat.com>
	<1421132832.38152228.1386608309092.JavaMail.root@redhat.com>
	<211CC433-A88D-4C6B-A851-E3A8443DC49B@redhat.com>
Message-ID: <52A6BECE.7030608@redhat.com>

Il 09/12/2013 19:37, Michal Skrivanek ha scritto:
> 
> 
>> On 09 Dec 2013, at 18:58, Oved Ourfalli <ovedo at redhat.com> wrote:
>>
>>
>>
>> ----- Original Message -----
>>> From: "Michal Skrivanek" <michal.skrivanek at redhat.com>
>>> To: "Sandro Bonazzola" <sbonazzo at redhat.com>, "Roy Golan" <rgolan at redhat.com>
>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>>> Sent: Monday, December 9, 2013 5:50:49 PM
>>> Subject: Re: [Engine-devel] Setting cluster CPU
>>>
>>>
>>>> On Dec 9, 2013, at 16:01 , Sandro Bonazzola <sbonazzo at redhat.com> wrote:
>>>>
>>>> Hi,
>>>> I'm trying to set the cluster CPU type while adding the first host to the
>>>> Default cluster.
>>>>
>>>> I know how to set the CPU type on a new cluster, since I'll do that in AIO
>>>> plugin.
>>>> But I'm not sure to understand how to set the CPU on an existing cluster.
>>>>
>>>> Should it be enough to specify cpu arg while adding the host to the
>>>> cluster?
>>>> (before adding an host, cpu is None on the cluster)
>>>> Because I'm trying to do that without success (obtaining a sandybridge
>>>> cluster while specifying westmere cpu).
>>>
>>> The CPU should be set from the first host if None. That is needed for the PPC
>>> support. Roy, we talked about it recently, where are we with this patch.
>>
>> We already support modifying the CPU level of an existing cluster. If changing it to a higher level then we just change it.
>> If changing it to a lower level, and there are running VMs on the cluster, then we warn the user that some VMs might not be migrate-able, as we added a scheduling filter to filter out hosts with improper CPU level.
>>
>> Unless I'm missing something, that covers the use-case, isn't it?
> 
> Not sure. I thought this is None to something, where it should work automatically without specifying anything. Just add an operational host

Well, here the issue is that while deploying hosted-engine VM, I'm on a SandyBridge host, with 1 VM running on it (the hosted engine VM).
That VM has been created with CPU model Westmere to be able to migrate it to other hosts Westmere compatible.
But the Default cluster is automatically set to SandyBridge when I add the host also if I specify Westmere as CPU family in Host parameter.
We may be able to set manually the CPU level later somehow, but since we've already asked the user about the CPU level I think we should avoid to ask
the user to change it again later. See Bug 1034821 - Hosted-setup asks for CPU type but it doesn't set cluster to that CPU Level


> 
>>
>>> Thanks,
>>> michal
>>>
>>>>
>>>> Michael, can you take a look at http://gerrit.ovirt.org/22129 and advise?
>>>>
>>>>
>>>> --
>>>> Sandro Bonazzola
>>>> Better technology. Faster innovation. Powered by community collaboration.
>>>> See how it works at redhat.com
>>>> _______________________________________________
>>>> Engine-devel mailing list
>>>> Engine-devel at ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>


-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com


From ovedo at redhat.com  Tue Dec 10 07:14:44 2013
From: ovedo at redhat.com (Oved Ourfalli)
Date: Tue, 10 Dec 2013 02:14:44 -0500 (EST)
Subject: [Engine-devel] Setting cluster CPU
In-Reply-To: <52A6BECE.7030608@redhat.com>
References: <52A5CD4B.1000806@redhat.com>
	<44A1E27A-9973-4D4F-B9D7-03C1DAF7161B@redhat.com>
	<1421132832.38152228.1386608309092.JavaMail.root@redhat.com>
	<211CC433-A88D-4C6B-A851-E3A8443DC49B@redhat.com>
	<52A6BECE.7030608@redhat.com>
Message-ID: <1947325153.38937830.1386659684527.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
> To: "Michal Skrivanek" <michal.skrivanek at redhat.com>, "Oved Ourfalli" <ovedo at redhat.com>, "Roy Golan"
> <rgolan at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Tuesday, December 10, 2013 9:12:14 AM
> Subject: Re: [Engine-devel] Setting cluster CPU
> 
> Il 09/12/2013 19:37, Michal Skrivanek ha scritto:
> > 
> > 
> >> On 09 Dec 2013, at 18:58, Oved Ourfalli <ovedo at redhat.com> wrote:
> >>
> >>
> >>
> >> ----- Original Message -----
> >>> From: "Michal Skrivanek" <michal.skrivanek at redhat.com>
> >>> To: "Sandro Bonazzola" <sbonazzo at redhat.com>, "Roy Golan"
> >>> <rgolan at redhat.com>
> >>> Cc: "engine-devel" <engine-devel at ovirt.org>
> >>> Sent: Monday, December 9, 2013 5:50:49 PM
> >>> Subject: Re: [Engine-devel] Setting cluster CPU
> >>>
> >>>
> >>>> On Dec 9, 2013, at 16:01 , Sandro Bonazzola <sbonazzo at redhat.com> wrote:
> >>>>
> >>>> Hi,
> >>>> I'm trying to set the cluster CPU type while adding the first host to
> >>>> the
> >>>> Default cluster.
> >>>>
> >>>> I know how to set the CPU type on a new cluster, since I'll do that in
> >>>> AIO
> >>>> plugin.
> >>>> But I'm not sure to understand how to set the CPU on an existing
> >>>> cluster.
> >>>>
> >>>> Should it be enough to specify cpu arg while adding the host to the
> >>>> cluster?
> >>>> (before adding an host, cpu is None on the cluster)
> >>>> Because I'm trying to do that without success (obtaining a sandybridge
> >>>> cluster while specifying westmere cpu).
> >>>
> >>> The CPU should be set from the first host if None. That is needed for the
> >>> PPC
> >>> support. Roy, we talked about it recently, where are we with this patch.
> >>
> >> We already support modifying the CPU level of an existing cluster. If
> >> changing it to a higher level then we just change it.
> >> If changing it to a lower level, and there are running VMs on the cluster,
> >> then we warn the user that some VMs might not be migrate-able, as we
> >> added a scheduling filter to filter out hosts with improper CPU level.
> >>
> >> Unless I'm missing something, that covers the use-case, isn't it?
> > 
> > Not sure. I thought this is None to something, where it should work
> > automatically without specifying anything. Just add an operational host
> 
> Well, here the issue is that while deploying hosted-engine VM, I'm on a
> SandyBridge host, with 1 VM running on it (the hosted engine VM).
> That VM has been created with CPU model Westmere to be able to migrate it to
> other hosts Westmere compatible.
> But the Default cluster is automatically set to SandyBridge when I add the
> host also if I specify Westmere as CPU family in Host parameter.
> We may be able to set manually the CPU level later somehow, but since we've
> already asked the user about the CPU level I think we should avoid to ask
> the user to change it again later. See Bug 1034821 - Hosted-setup asks for
> CPU type but it doesn't set cluster to that CPU Level
> 

You can set the CPU level through the SDK, after you add the host (didn't check that, but see no reason it won't work).

> 
> > 
> >>
> >>> Thanks,
> >>> michal
> >>>
> >>>>
> >>>> Michael, can you take a look at http://gerrit.ovirt.org/22129 and
> >>>> advise?
> >>>>
> >>>>
> >>>> --
> >>>> Sandro Bonazzola
> >>>> Better technology. Faster innovation. Powered by community
> >>>> collaboration.
> >>>> See how it works at redhat.com
> >>>> _______________________________________________
> >>>> Engine-devel mailing list
> >>>> Engine-devel at ovirt.org
> >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>
> >>> _______________________________________________
> >>> Engine-devel mailing list
> >>> Engine-devel at ovirt.org
> >>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>
> 
> 
> --
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From S.Kieske at mittwald.de  Tue Dec 10 09:09:46 2013
From: S.Kieske at mittwald.de (Sven Kieske)
Date: Tue, 10 Dec 2013 09:09:46 +0000
Subject: [Engine-devel] [Bug] Small Typo in api.xsd
Message-ID: <52A6DB14.5030803@mittwald.de>

Hi,

I just was reading through the new cloud-init api integration and found
a small typo in:
backend/manager/modules/restapi/interface/definition/src/main/resources/api.xsd

Line 606:
It is: "  <!--  Extrenal tasks -->" but should be
"  <!--  External tasks -->", I guess.

-- 
Mit freundlichen Gr??en / Regards

Sven Kieske

Systemadministrator
Mittwald CM Service GmbH & Co. KG
K?nigsberger Stra?e 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
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

From S.Kieske at mittwald.de  Tue Dec 10 09:24:53 2013
From: S.Kieske at mittwald.de (Sven Kieske)
Date: Tue, 10 Dec 2013 09:24:53 +0000
Subject: [Engine-devel] [Bug] Small Typo in api.xsd
In-Reply-To: <52A6DB14.5030803@mittwald.de>
References: <52A6DB14.5030803@mittwald.de>
Message-ID: <52A6DEA0.3090402@mittwald.de>

I forgot:

this was in engine-3.3.2 branch may be as well in master
(didn't check that).

Am 10.12.2013 10:09, schrieb Sven Kieske:
> Hi,
> 
> I just was reading through the new cloud-init api integration and found
> a small typo in:
> backend/manager/modules/restapi/interface/definition/src/main/resources/api.xsd
> 
> Line 606:
> It is: "  <!--  Extrenal tasks -->" but should be
> "  <!--  External tasks -->", I guess.
> 

-- 
Mit freundlichen Gr??en / Regards

Sven Kieske

Systemadministrator
Mittwald CM Service GmbH & Co. KG
K?nigsberger Stra?e 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
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

From emesika at redhat.com  Tue Dec 10 09:35:28 2013
From: emesika at redhat.com (Eli Mesika)
Date: Tue, 10 Dec 2013 04:35:28 -0500 (EST)
Subject: [Engine-devel] [Bug] Small Typo in api.xsd
In-Reply-To: <52A6DB14.5030803@mittwald.de>
References: <52A6DB14.5030803@mittwald.de>
Message-ID: <1136847585.37538866.1386668128281.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Sven Kieske" <S.Kieske at mittwald.de>
> To: engine-devel at ovirt.org
> Sent: Tuesday, December 10, 2013 11:09:46 AM
> Subject: [Engine-devel] [Bug] Small Typo in api.xsd
> 
> Hi,
> 
> I just was reading through the new cloud-init api integration and found
> a small typo in:
> backend/manager/modules/restapi/interface/definition/src/main/resources/api.xsd
> 
> Line 606:
> It is: "  <!--  Extrenal tasks -->" but should be
> "  <!--  External tasks -->", I guess.

Yes, thanks for reporting that
I had sent a patch fixing that :
http://gerrit.ovirt.org/#/c/22226/

> 
> --
> Mit freundlichen Gr??en / Regards
> 
> Sven Kieske
> 
> Systemadministrator
> Mittwald CM Service GmbH & Co. KG
> K?nigsberger Stra?e 6
> 32339 Espelkamp
> T: +49-5772-293-100
> F: +49-5772-293-333
> 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
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From emesika at redhat.com  Tue Dec 10 14:30:16 2013
From: emesika at redhat.com (Eli Mesika)
Date: Tue, 10 Dec 2013 09:30:16 -0500 (EST)
Subject: [Engine-devel] Problems debugging client code
In-Reply-To: <1330910277.37663054.1386685701002.JavaMail.root@redhat.com>
Message-ID: <511605606.37663551.1386685816918.JavaMail.root@redhat.com>

Hi


Debugging client code I got this when trying to connect from Google Chrom :

********************************************************
Oops! Google Chrome could not connect to 127.0.0.1:8080
Try reloading the page
********************************************************

any ideas ???

I am following instructions from README.developer and using f19 with google-chrome-stable-31.0.1650.63-1.x86_64

Thanks 

Eli


From awels at redhat.com  Tue Dec 10 14:37:16 2013
From: awels at redhat.com (Alexander Wels)
Date: Tue, 10 Dec 2013 09:37:16 -0500
Subject: [Engine-devel] Problems debugging client code
In-Reply-To: <511605606.37663551.1386685816918.JavaMail.root@redhat.com>
References: <511605606.37663551.1386685816918.JavaMail.root@redhat.com>
Message-ID: <2783210.cTXeGUkJVu@awels>

Hi,

1. Is your engine runnning? [1]
2. Did you also start separately the debug mode [2] (This is debugging the 
webadmin)
3. Did you go to the right URL [3]
4. Make when you compile you compile for the correct browser. I usually 
compile for FF and chrome [4]

[1] $HOME/ovirt-engine/share/ovirt-engine/services/ovirt-engine/ovirt-
engine.py start

[2] make gwt-debug DEBUG_MODULE=webadmin DEV_EXTRA_BUILD_FLAGS_GWT_DEFAULTS="-
D gwt.userAgent=gecko1_8,safari"

[3] http://127.0.0.1:8080/ovirt-engine/webadmin/?gwt.codesvr=127.0.0.1:9997

[4] make clean install-dev PREFIX=$HOME/ovirt-engine BUILD_UT=0 BUILD_GWT=1 
DEV_EXTRA_BUILD_FLAGS_GWT_DEFAULTS="-D gwt.userAgent=gecko1_8,safari"

On Tuesday, December 10, 2013 09:30:16 AM Eli Mesika wrote:
> Hi
> 
> 
> Debugging client code I got this when trying to connect from Google Chrom :
> 
> ********************************************************
> Oops! Google Chrome could not connect to 127.0.0.1:8080
> Try reloading the page
> ********************************************************
> 
> any ideas ???
> 
> I am following instructions from README.developer and using f19 with
> google-chrome-stable-31.0.1650.63-1.x86_64
> 
> Thanks
> 
> Eli
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From emesika at redhat.com  Tue Dec 10 15:18:51 2013
From: emesika at redhat.com (Eli Mesika)
Date: Tue, 10 Dec 2013 10:18:51 -0500 (EST)
Subject: [Engine-devel] Problems debugging client code
In-Reply-To: <2783210.cTXeGUkJVu@awels>
References: <511605606.37663551.1386685816918.JavaMail.root@redhat.com>
	<2783210.cTXeGUkJVu@awels>
Message-ID: <2100567012.37698348.1386688731052.JavaMail.root@redhat.com>

That worked !!!
Thanks :-)

----- Original Message -----
> From: "Alexander Wels" <awels at redhat.com>
> To: engine-devel at ovirt.org
> Cc: "Eli Mesika" <emesika at redhat.com>, "Gilad Chaplik" <gchaplik at redhat.com>, "Daniel Erez" <derez at redhat.com>
> Sent: Tuesday, December 10, 2013 4:37:16 PM
> Subject: Re: [Engine-devel] Problems debugging client code
> 
> Hi,
> 
> 1. Is your engine runnning? [1]
> 2. Did you also start separately the debug mode [2] (This is debugging the
> webadmin)
> 3. Did you go to the right URL [3]
> 4. Make when you compile you compile for the correct browser. I usually
> compile for FF and chrome [4]
> 
> [1] $HOME/ovirt-engine/share/ovirt-engine/services/ovirt-engine/ovirt-
> engine.py start
> 
> [2] make gwt-debug DEBUG_MODULE=webadmin
> DEV_EXTRA_BUILD_FLAGS_GWT_DEFAULTS="-
> D gwt.userAgent=gecko1_8,safari"
> 
> [3] http://127.0.0.1:8080/ovirt-engine/webadmin/?gwt.codesvr=127.0.0.1:9997
> 
> [4] make clean install-dev PREFIX=$HOME/ovirt-engine BUILD_UT=0 BUILD_GWT=1
> DEV_EXTRA_BUILD_FLAGS_GWT_DEFAULTS="-D gwt.userAgent=gecko1_8,safari"
> 
> On Tuesday, December 10, 2013 09:30:16 AM Eli Mesika wrote:
> > Hi
> > 
> > 
> > Debugging client code I got this when trying to connect from Google Chrom :
> > 
> > ********************************************************
> > Oops! Google Chrome could not connect to 127.0.0.1:8080
> > Try reloading the page
> > ********************************************************
> > 
> > any ideas ???
> > 
> > I am following instructions from README.developer and using f19 with
> > google-chrome-stable-31.0.1650.63-1.x86_64
> > 
> > Thanks
> > 
> > Eli
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> 


From obasan at redhat.com  Tue Dec 10 16:28:52 2013
From: obasan at redhat.com (Ohad Basan)
Date: Tue, 10 Dec 2013 11:28:52 -0500 (EST)
Subject: [Engine-devel] daotest failure
Message-ID: <1581093273.27805204.1386692931995.JavaMail.root@redhat.com>

Hello

I've performed some changed to the daotest jobs on jenkins
1. we were created and populating the db with user "postgres". now we're doing it with engine as we should
2. structure of the job was changed according to readme.DEVELOPER 

since these changes I experience some test failure which I suspect that are true failures.
could you please look?
http://jenkins.ovirt.org/job/ovirt_engine_dao_unit_tests/5400/console

thanks,

Ohad


From michal.skrivanek at redhat.com  Tue Dec 10 18:01:08 2013
From: michal.skrivanek at redhat.com (Michal Skrivanek)
Date: Tue, 10 Dec 2013 20:01:08 +0200
Subject: [Engine-devel] Setting cluster CPU
In-Reply-To: <1947325153.38937830.1386659684527.JavaMail.root@redhat.com>
References: <52A5CD4B.1000806@redhat.com>
	<44A1E27A-9973-4D4F-B9D7-03C1DAF7161B@redhat.com>
	<1421132832.38152228.1386608309092.JavaMail.root@redhat.com>
	<211CC433-A88D-4C6B-A851-E3A8443DC49B@redhat.com>
	<52A6BECE.7030608@redhat.com>
	<1947325153.38937830.1386659684527.JavaMail.root@redhat.com>
Message-ID: <8FE86632-29E8-4458-BE05-2138B1D8354E@redhat.com>


On Dec 10, 2013, at 09:14 , Oved Ourfalli <ovedo at redhat.com> wrote:

> 
> 
> ----- Original Message -----
>> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
>> To: "Michal Skrivanek" <michal.skrivanek at redhat.com>, "Oved Ourfalli" <ovedo at redhat.com>, "Roy Golan"
>> <rgolan at redhat.com>
>> Cc: "engine-devel" <engine-devel at ovirt.org>
>> Sent: Tuesday, December 10, 2013 9:12:14 AM
>> Subject: Re: [Engine-devel] Setting cluster CPU
>> 
>> Il 09/12/2013 19:37, Michal Skrivanek ha scritto:
>>> 
>>> 
>>>> On 09 Dec 2013, at 18:58, Oved Ourfalli <ovedo at redhat.com> wrote:
>>>> 
>>>> 
>>>> 
>>>> ----- Original Message -----
>>>>> From: "Michal Skrivanek" <michal.skrivanek at redhat.com>
>>>>> To: "Sandro Bonazzola" <sbonazzo at redhat.com>, "Roy Golan"
>>>>> <rgolan at redhat.com>
>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>>>>> Sent: Monday, December 9, 2013 5:50:49 PM
>>>>> Subject: Re: [Engine-devel] Setting cluster CPU
>>>>> 
>>>>> 
>>>>>> On Dec 9, 2013, at 16:01 , Sandro Bonazzola <sbonazzo at redhat.com> wrote:
>>>>>> 
>>>>>> Hi,
>>>>>> I'm trying to set the cluster CPU type while adding the first host to
>>>>>> the
>>>>>> Default cluster.
>>>>>> 
>>>>>> I know how to set the CPU type on a new cluster, since I'll do that in
>>>>>> AIO
>>>>>> plugin.
>>>>>> But I'm not sure to understand how to set the CPU on an existing
>>>>>> cluster.
>>>>>> 
>>>>>> Should it be enough to specify cpu arg while adding the host to the
>>>>>> cluster?
>>>>>> (before adding an host, cpu is None on the cluster)
>>>>>> Because I'm trying to do that without success (obtaining a sandybridge
>>>>>> cluster while specifying westmere cpu).
>>>>> 
>>>>> The CPU should be set from the first host if None. That is needed for the
>>>>> PPC
>>>>> support. Roy, we talked about it recently, where are we with this patch.
>>>> 
>>>> We already support modifying the CPU level of an existing cluster. If
>>>> changing it to a higher level then we just change it.
>>>> If changing it to a lower level, and there are running VMs on the cluster,
>>>> then we warn the user that some VMs might not be migrate-able, as we
>>>> added a scheduling filter to filter out hosts with improper CPU level.
>>>> 
>>>> Unless I'm missing something, that covers the use-case, isn't it?
>>> 
>>> Not sure. I thought this is None to something, where it should work
>>> automatically without specifying anything. Just add an operational host
>> 
>> Well, here the issue is that while deploying hosted-engine VM, I'm on a
>> SandyBridge host, with 1 VM running on it (the hosted engine VM).
>> That VM has been created with CPU model Westmere to be able to migrate it to
>> other hosts Westmere compatible.
>> But the Default cluster is automatically set to SandyBridge when I add the

because it's created with None in the first place, and then set by the first host. If you'd create it with Westmere initially the joining host would not change it
IMHO the setting should be done during the installation not via calling SDK on already created empty cluster but directly in the db when the db is deployed. Unless I'm missing the sequence of deployment.
 
>> host also if I specify Westmere as CPU family in Host parameter.
>> We may be able to set manually the CPU level later somehow, but since we've
>> already asked the user about the CPU level I think we should avoid to ask
>> the user to change it again later. See Bug 1034821 - Hosted-setup asks for
>> CPU type but it doesn't set cluster to that CPU Level
>> 
> 
> You can set the CPU level through the SDK, after you add the host (didn't check that, but see no reason it won't work).

why so late in the process?

> 
>> 
>>> 
>>>> 
>>>>> Thanks,
>>>>> michal
>>>>> 
>>>>>> 
>>>>>> Michael, can you take a look at http://gerrit.ovirt.org/22129 and
>>>>>> advise?
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Sandro Bonazzola
>>>>>> Better technology. Faster innovation. Powered by community
>>>>>> collaboration.
>>>>>> See how it works at redhat.com
>>>>>> _______________________________________________
>>>>>> Engine-devel mailing list
>>>>>> Engine-devel at ovirt.org
>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>> 
>>>>> _______________________________________________
>>>>> Engine-devel mailing list
>>>>> Engine-devel at ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>> 
>> 
>> 
>> --
>> Sandro Bonazzola
>> Better technology. Faster innovation. Powered by community collaboration.
>> See how it works at redhat.com
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>> 



From yzaslavs at redhat.com  Wed Dec 11 01:42:04 2013
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Tue, 10 Dec 2013 20:42:04 -0500 (EST)
Subject: [Engine-devel] daotest failure
In-Reply-To: <1581093273.27805204.1386692931995.JavaMail.root@redhat.com>
References: <1581093273.27805204.1386692931995.JavaMail.root@redhat.com>
Message-ID: <1177802687.14789464.1386726124119.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Ohad Basan" <obasan at redhat.com>
> To: engine-devel at ovirt.org
> Cc: "Yair Zaslavsky" <yzaslavs at redhat.com>
> Sent: Tuesday, December 10, 2013 6:28:52 PM
> Subject: daotest failure
> 
> Hello
> 
> I've performed some changed to the daotest jobs on jenkins
> 1. we were created and populating the db with user "postgres". now we're
> doing it with engine as we should
> 2. structure of the job was changed according to readme.DEVELOPER
> 
> since these changes I experience some test failure which I suspect that are
> true failures.
> could you please look?
> http://jenkins.ovirt.org/job/ovirt_engine_dao_unit_tests/5400/console
> 
> thanks,
> 
> Ohad
> 

1. 
Hi, I am using the commit hash of a992aed8e7435b804b52b02e7192265f73de9c40 as stated at the job, and managed to run tests, according to the way it is ran in the job.

I tried sshing to the machine that ran the build but with no luck.

Can you please provide the content of the surefire reports directory - see the following line from the console for the correct path -


/home/jenkins/workspace/ovirt_engine_dao_unit_tests/backend/manager/modules/common/target/surefire-reports

In addition, as you can see , the failures are not at DAL tests, but at common unit tests, I tried running again the unit tests of common in a separate way - and it worked for me.




Yair




From ovedo at redhat.com  Wed Dec 11 06:18:23 2013
From: ovedo at redhat.com (Oved Ourfalli)
Date: Wed, 11 Dec 2013 01:18:23 -0500 (EST)
Subject: [Engine-devel] Setting cluster CPU
In-Reply-To: <8FE86632-29E8-4458-BE05-2138B1D8354E@redhat.com>
References: <52A5CD4B.1000806@redhat.com>
	<44A1E27A-9973-4D4F-B9D7-03C1DAF7161B@redhat.com>
	<1421132832.38152228.1386608309092.JavaMail.root@redhat.com>
	<211CC433-A88D-4C6B-A851-E3A8443DC49B@redhat.com>
	<52A6BECE.7030608@redhat.com>
	<1947325153.38937830.1386659684527.JavaMail.root@redhat.com>
	<8FE86632-29E8-4458-BE05-2138B1D8354E@redhat.com>
Message-ID: <1161617116.39883433.1386742703725.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Michal Skrivanek" <michal.skrivanek at redhat.com>
> To: "Oved Ourfalli" <ovedo at redhat.com>, "Sandro Bonazzola" <sbonazzo at redhat.com>
> Cc: "Roy Golan" <rgolan at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
> Sent: Tuesday, December 10, 2013 8:01:08 PM
> Subject: Re: [Engine-devel] Setting cluster CPU
> 
> 
> On Dec 10, 2013, at 09:14 , Oved Ourfalli <ovedo at redhat.com> wrote:
> 
> > 
> > 
> > ----- Original Message -----
> >> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
> >> To: "Michal Skrivanek" <michal.skrivanek at redhat.com>, "Oved Ourfalli"
> >> <ovedo at redhat.com>, "Roy Golan"
> >> <rgolan at redhat.com>
> >> Cc: "engine-devel" <engine-devel at ovirt.org>
> >> Sent: Tuesday, December 10, 2013 9:12:14 AM
> >> Subject: Re: [Engine-devel] Setting cluster CPU
> >> 
> >> Il 09/12/2013 19:37, Michal Skrivanek ha scritto:
> >>> 
> >>> 
> >>>> On 09 Dec 2013, at 18:58, Oved Ourfalli <ovedo at redhat.com> wrote:
> >>>> 
> >>>> 
> >>>> 
> >>>> ----- Original Message -----
> >>>>> From: "Michal Skrivanek" <michal.skrivanek at redhat.com>
> >>>>> To: "Sandro Bonazzola" <sbonazzo at redhat.com>, "Roy Golan"
> >>>>> <rgolan at redhat.com>
> >>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> >>>>> Sent: Monday, December 9, 2013 5:50:49 PM
> >>>>> Subject: Re: [Engine-devel] Setting cluster CPU
> >>>>> 
> >>>>> 
> >>>>>> On Dec 9, 2013, at 16:01 , Sandro Bonazzola <sbonazzo at redhat.com>
> >>>>>> wrote:
> >>>>>> 
> >>>>>> Hi,
> >>>>>> I'm trying to set the cluster CPU type while adding the first host to
> >>>>>> the
> >>>>>> Default cluster.
> >>>>>> 
> >>>>>> I know how to set the CPU type on a new cluster, since I'll do that in
> >>>>>> AIO
> >>>>>> plugin.
> >>>>>> But I'm not sure to understand how to set the CPU on an existing
> >>>>>> cluster.
> >>>>>> 
> >>>>>> Should it be enough to specify cpu arg while adding the host to the
> >>>>>> cluster?
> >>>>>> (before adding an host, cpu is None on the cluster)
> >>>>>> Because I'm trying to do that without success (obtaining a sandybridge
> >>>>>> cluster while specifying westmere cpu).
> >>>>> 
> >>>>> The CPU should be set from the first host if None. That is needed for
> >>>>> the
> >>>>> PPC
> >>>>> support. Roy, we talked about it recently, where are we with this
> >>>>> patch.
> >>>> 
> >>>> We already support modifying the CPU level of an existing cluster. If
> >>>> changing it to a higher level then we just change it.
> >>>> If changing it to a lower level, and there are running VMs on the
> >>>> cluster,
> >>>> then we warn the user that some VMs might not be migrate-able, as we
> >>>> added a scheduling filter to filter out hosts with improper CPU level.
> >>>> 
> >>>> Unless I'm missing something, that covers the use-case, isn't it?
> >>> 
> >>> Not sure. I thought this is None to something, where it should work
> >>> automatically without specifying anything. Just add an operational host
> >> 
> >> Well, here the issue is that while deploying hosted-engine VM, I'm on a
> >> SandyBridge host, with 1 VM running on it (the hosted engine VM).
> >> That VM has been created with CPU model Westmere to be able to migrate it
> >> to
> >> other hosts Westmere compatible.
> >> But the Default cluster is automatically set to SandyBridge when I add the
> 
> because it's created with None in the first place, and then set by the first
> host. If you'd create it with Westmere initially the joining host would not
> change it
> IMHO the setting should be done during the installation not via calling SDK
> on already created empty cluster but directly in the db when the db is
> deployed. Unless I'm missing the sequence of deployment.
> 

The hosted engine setup doesn't access the DB, so no reason to access it if it is possible to do that via the SDK.
Didn't test that, but see no reason for it not to work.
 
> >> host also if I specify Westmere as CPU family in Host parameter.
> >> We may be able to set manually the CPU level later somehow, but since
> >> we've
> >> already asked the user about the CPU level I think we should avoid to ask
> >> the user to change it again later. See Bug 1034821 - Hosted-setup asks for
> >> CPU type but it doesn't set cluster to that CPU Level
> >> 
> > 
> > You can set the CPU level through the SDK, after you add the host (didn't
> > check that, but see no reason it won't work).
> 
> why so late in the process?
> 

why does it matter? The setup is still running, so, imo, the order is less relevant, as long as the result is okay.

> > 
> >> 
> >>> 
> >>>> 
> >>>>> Thanks,
> >>>>> michal
> >>>>> 
> >>>>>> 
> >>>>>> Michael, can you take a look at http://gerrit.ovirt.org/22129 and
> >>>>>> advise?
> >>>>>> 
> >>>>>> 
> >>>>>> --
> >>>>>> Sandro Bonazzola
> >>>>>> Better technology. Faster innovation. Powered by community
> >>>>>> collaboration.
> >>>>>> See how it works at redhat.com
> >>>>>> _______________________________________________
> >>>>>> Engine-devel mailing list
> >>>>>> Engine-devel at ovirt.org
> >>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>>> 
> >>>>> _______________________________________________
> >>>>> Engine-devel mailing list
> >>>>> Engine-devel at ovirt.org
> >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>>> 
> >> 
> >> 
> >> --
> >> Sandro Bonazzola
> >> Better technology. Faster innovation. Powered by community collaboration.
> >> See how it works at redhat.com
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >> 
> 
> 


From michal.skrivanek at redhat.com  Wed Dec 11 06:45:41 2013
From: michal.skrivanek at redhat.com (Michal Skrivanek)
Date: Wed, 11 Dec 2013 08:45:41 +0200
Subject: [Engine-devel] Setting cluster CPU
In-Reply-To: <1161617116.39883433.1386742703725.JavaMail.root@redhat.com>
References: <52A5CD4B.1000806@redhat.com>
	<44A1E27A-9973-4D4F-B9D7-03C1DAF7161B@redhat.com>
	<1421132832.38152228.1386608309092.JavaMail.root@redhat.com>
	<211CC433-A88D-4C6B-A851-E3A8443DC49B@redhat.com>
	<52A6BECE.7030608@redhat.com>
	<1947325153.38937830.1386659684527.JavaMail.root@redhat.com>
	<8FE86632-29E8-4458-BE05-2138B1D8354E@redhat.com>
	<1161617116.39883433.1386742703725.JavaMail.root@redhat.com>
Message-ID: <6066CF2A-7E14-4E41-B3D0-ED853582F622@redhat.com>


On Dec 11, 2013, at 08:18 , Oved Ourfalli <ovedo at redhat.com> wrote:

> 
> 
> ----- Original Message -----
>> From: "Michal Skrivanek" <michal.skrivanek at redhat.com>
>> To: "Oved Ourfalli" <ovedo at redhat.com>, "Sandro Bonazzola" <sbonazzo at redhat.com>
>> Cc: "Roy Golan" <rgolan at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
>> Sent: Tuesday, December 10, 2013 8:01:08 PM
>> Subject: Re: [Engine-devel] Setting cluster CPU
>> 
>> 
>> On Dec 10, 2013, at 09:14 , Oved Ourfalli <ovedo at redhat.com> wrote:
>> 
>>> 
>>> 
>>> ----- Original Message -----
>>>> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
>>>> To: "Michal Skrivanek" <michal.skrivanek at redhat.com>, "Oved Ourfalli"
>>>> <ovedo at redhat.com>, "Roy Golan"
>>>> <rgolan at redhat.com>
>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>>>> Sent: Tuesday, December 10, 2013 9:12:14 AM
>>>> Subject: Re: [Engine-devel] Setting cluster CPU
>>>> 
>>>> Il 09/12/2013 19:37, Michal Skrivanek ha scritto:
>>>>> 
>>>>> 
>>>>>> On 09 Dec 2013, at 18:58, Oved Ourfalli <ovedo at redhat.com> wrote:
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> ----- Original Message -----
>>>>>>> From: "Michal Skrivanek" <michal.skrivanek at redhat.com>
>>>>>>> To: "Sandro Bonazzola" <sbonazzo at redhat.com>, "Roy Golan"
>>>>>>> <rgolan at redhat.com>
>>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>>>>>>> Sent: Monday, December 9, 2013 5:50:49 PM
>>>>>>> Subject: Re: [Engine-devel] Setting cluster CPU
>>>>>>> 
>>>>>>> 
>>>>>>>> On Dec 9, 2013, at 16:01 , Sandro Bonazzola <sbonazzo at redhat.com>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>> Hi,
>>>>>>>> I'm trying to set the cluster CPU type while adding the first host to
>>>>>>>> the
>>>>>>>> Default cluster.
>>>>>>>> 
>>>>>>>> I know how to set the CPU type on a new cluster, since I'll do that in
>>>>>>>> AIO
>>>>>>>> plugin.
>>>>>>>> But I'm not sure to understand how to set the CPU on an existing
>>>>>>>> cluster.
>>>>>>>> 
>>>>>>>> Should it be enough to specify cpu arg while adding the host to the
>>>>>>>> cluster?
>>>>>>>> (before adding an host, cpu is None on the cluster)
>>>>>>>> Because I'm trying to do that without success (obtaining a sandybridge
>>>>>>>> cluster while specifying westmere cpu).
>>>>>>> 
>>>>>>> The CPU should be set from the first host if None. That is needed for
>>>>>>> the
>>>>>>> PPC
>>>>>>> support. Roy, we talked about it recently, where are we with this
>>>>>>> patch.
>>>>>> 
>>>>>> We already support modifying the CPU level of an existing cluster. If
>>>>>> changing it to a higher level then we just change it.
>>>>>> If changing it to a lower level, and there are running VMs on the
>>>>>> cluster,
>>>>>> then we warn the user that some VMs might not be migrate-able, as we
>>>>>> added a scheduling filter to filter out hosts with improper CPU level.
>>>>>> 
>>>>>> Unless I'm missing something, that covers the use-case, isn't it?
>>>>> 
>>>>> Not sure. I thought this is None to something, where it should work
>>>>> automatically without specifying anything. Just add an operational host
>>>> 
>>>> Well, here the issue is that while deploying hosted-engine VM, I'm on a
>>>> SandyBridge host, with 1 VM running on it (the hosted engine VM).
>>>> That VM has been created with CPU model Westmere to be able to migrate it
>>>> to
>>>> other hosts Westmere compatible.
>>>> But the Default cluster is automatically set to SandyBridge when I add the
>> 
>> because it's created with None in the first place, and then set by the first
>> host. If you'd create it with Westmere initially the joining host would not
>> change it
>> IMHO the setting should be done during the installation not via calling SDK
>> on already created empty cluster but directly in the db when the db is
>> deployed. Unless I'm missing the sequence of deployment.
>> 
> 
> The hosted engine setup doesn't access the DB, so no reason to access it if it is possible to do that via the SDK.
> Didn't test that, but see no reason for it not to work.
> 
>>>> host also if I specify Westmere as CPU family in Host parameter.
>>>> We may be able to set manually the CPU level later somehow, but since
>>>> we've
>>>> already asked the user about the CPU level I think we should avoid to ask
>>>> the user to change it again later. See Bug 1034821 - Hosted-setup asks for
>>>> CPU type but it doesn't set cluster to that CPU Level
>>>> 
>>> 
>>> You can set the CPU level through the SDK, after you add the host (didn't
>>> check that, but see no reason it won't work).
>> 
>> why so late in the process?
>> 
> 
> why does it matter? The setup is still running, so, imo, the order is less relevant, as long as the result is okay.


depends. if hosted engine is part of the installation, it should do the modifications during installation the same way as anything else, forcefully, and not depend on working sdk or any other precondition
if it is something you are/should be able to deploy over an existing setup it's better via sdk...

>>> 
>>>> 
>>>>> 
>>>>>> 
>>>>>>> Thanks,
>>>>>>> michal
>>>>>>> 
>>>>>>>> 
>>>>>>>> Michael, can you take a look at http://gerrit.ovirt.org/22129 and
>>>>>>>> advise?
>>>>>>>> 
>>>>>>>> 
>>>>>>>> --
>>>>>>>> Sandro Bonazzola
>>>>>>>> Better technology. Faster innovation. Powered by community
>>>>>>>> collaboration.
>>>>>>>> See how it works at redhat.com
>>>>>>>> _______________________________________________
>>>>>>>> Engine-devel mailing list
>>>>>>>> Engine-devel at ovirt.org
>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> Engine-devel mailing list
>>>>>>> Engine-devel at ovirt.org
>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>> 
>>>> 
>>>> 
>>>> --
>>>> Sandro Bonazzola
>>>> Better technology. Faster innovation. Powered by community collaboration.
>>>> See how it works at redhat.com
>>>> _______________________________________________
>>>> Engine-devel mailing list
>>>> Engine-devel at ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>> 
>> 
>> 



From ovedo at redhat.com  Wed Dec 11 06:53:32 2013
From: ovedo at redhat.com (Oved Ourfalli)
Date: Wed, 11 Dec 2013 01:53:32 -0500 (EST)
Subject: [Engine-devel] Setting cluster CPU
In-Reply-To: <6066CF2A-7E14-4E41-B3D0-ED853582F622@redhat.com>
References: <52A5CD4B.1000806@redhat.com>
	<1421132832.38152228.1386608309092.JavaMail.root@redhat.com>
	<211CC433-A88D-4C6B-A851-E3A8443DC49B@redhat.com>
	<52A6BECE.7030608@redhat.com>
	<1947325153.38937830.1386659684527.JavaMail.root@redhat.com>
	<8FE86632-29E8-4458-BE05-2138B1D8354E@redhat.com>
	<1161617116.39883433.1386742703725.JavaMail.root@redhat.com>
	<6066CF2A-7E14-4E41-B3D0-ED853582F622@redhat.com>
Message-ID: <1844887159.39886512.1386744812543.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Michal Skrivanek" <michal.skrivanek at redhat.com>
> To: "Oved Ourfalli" <ovedo at redhat.com>
> Cc: "Sandro Bonazzola" <sbonazzo at redhat.com>, "Roy Golan" <rgolan at redhat.com>, "engine-devel"
> <engine-devel at ovirt.org>
> Sent: Wednesday, December 11, 2013 8:45:41 AM
> Subject: Re: [Engine-devel] Setting cluster CPU
> 
> 
> On Dec 11, 2013, at 08:18 , Oved Ourfalli <ovedo at redhat.com> wrote:
> 
> > 
> > 
> > ----- Original Message -----
> >> From: "Michal Skrivanek" <michal.skrivanek at redhat.com>
> >> To: "Oved Ourfalli" <ovedo at redhat.com>, "Sandro Bonazzola"
> >> <sbonazzo at redhat.com>
> >> Cc: "Roy Golan" <rgolan at redhat.com>, "engine-devel"
> >> <engine-devel at ovirt.org>
> >> Sent: Tuesday, December 10, 2013 8:01:08 PM
> >> Subject: Re: [Engine-devel] Setting cluster CPU
> >> 
> >> 
> >> On Dec 10, 2013, at 09:14 , Oved Ourfalli <ovedo at redhat.com> wrote:
> >> 
> >>> 
> >>> 
> >>> ----- Original Message -----
> >>>> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
> >>>> To: "Michal Skrivanek" <michal.skrivanek at redhat.com>, "Oved Ourfalli"
> >>>> <ovedo at redhat.com>, "Roy Golan"
> >>>> <rgolan at redhat.com>
> >>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> >>>> Sent: Tuesday, December 10, 2013 9:12:14 AM
> >>>> Subject: Re: [Engine-devel] Setting cluster CPU
> >>>> 
> >>>> Il 09/12/2013 19:37, Michal Skrivanek ha scritto:
> >>>>> 
> >>>>> 
> >>>>>> On 09 Dec 2013, at 18:58, Oved Ourfalli <ovedo at redhat.com> wrote:
> >>>>>> 
> >>>>>> 
> >>>>>> 
> >>>>>> ----- Original Message -----
> >>>>>>> From: "Michal Skrivanek" <michal.skrivanek at redhat.com>
> >>>>>>> To: "Sandro Bonazzola" <sbonazzo at redhat.com>, "Roy Golan"
> >>>>>>> <rgolan at redhat.com>
> >>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> >>>>>>> Sent: Monday, December 9, 2013 5:50:49 PM
> >>>>>>> Subject: Re: [Engine-devel] Setting cluster CPU
> >>>>>>> 
> >>>>>>> 
> >>>>>>>> On Dec 9, 2013, at 16:01 , Sandro Bonazzola <sbonazzo at redhat.com>
> >>>>>>>> wrote:
> >>>>>>>> 
> >>>>>>>> Hi,
> >>>>>>>> I'm trying to set the cluster CPU type while adding the first host
> >>>>>>>> to
> >>>>>>>> the
> >>>>>>>> Default cluster.
> >>>>>>>> 
> >>>>>>>> I know how to set the CPU type on a new cluster, since I'll do that
> >>>>>>>> in
> >>>>>>>> AIO
> >>>>>>>> plugin.
> >>>>>>>> But I'm not sure to understand how to set the CPU on an existing
> >>>>>>>> cluster.
> >>>>>>>> 
> >>>>>>>> Should it be enough to specify cpu arg while adding the host to the
> >>>>>>>> cluster?
> >>>>>>>> (before adding an host, cpu is None on the cluster)
> >>>>>>>> Because I'm trying to do that without success (obtaining a
> >>>>>>>> sandybridge
> >>>>>>>> cluster while specifying westmere cpu).
> >>>>>>> 
> >>>>>>> The CPU should be set from the first host if None. That is needed for
> >>>>>>> the
> >>>>>>> PPC
> >>>>>>> support. Roy, we talked about it recently, where are we with this
> >>>>>>> patch.
> >>>>>> 
> >>>>>> We already support modifying the CPU level of an existing cluster. If
> >>>>>> changing it to a higher level then we just change it.
> >>>>>> If changing it to a lower level, and there are running VMs on the
> >>>>>> cluster,
> >>>>>> then we warn the user that some VMs might not be migrate-able, as we
> >>>>>> added a scheduling filter to filter out hosts with improper CPU level.
> >>>>>> 
> >>>>>> Unless I'm missing something, that covers the use-case, isn't it?
> >>>>> 
> >>>>> Not sure. I thought this is None to something, where it should work
> >>>>> automatically without specifying anything. Just add an operational host
> >>>> 
> >>>> Well, here the issue is that while deploying hosted-engine VM, I'm on a
> >>>> SandyBridge host, with 1 VM running on it (the hosted engine VM).
> >>>> That VM has been created with CPU model Westmere to be able to migrate
> >>>> it
> >>>> to
> >>>> other hosts Westmere compatible.
> >>>> But the Default cluster is automatically set to SandyBridge when I add
> >>>> the
> >> 
> >> because it's created with None in the first place, and then set by the
> >> first
> >> host. If you'd create it with Westmere initially the joining host would
> >> not
> >> change it
> >> IMHO the setting should be done during the installation not via calling
> >> SDK
> >> on already created empty cluster but directly in the db when the db is
> >> deployed. Unless I'm missing the sequence of deployment.
> >> 
> > 
> > The hosted engine setup doesn't access the DB, so no reason to access it if
> > it is possible to do that via the SDK.
> > Didn't test that, but see no reason for it not to work.
> > 
> >>>> host also if I specify Westmere as CPU family in Host parameter.
> >>>> We may be able to set manually the CPU level later somehow, but since
> >>>> we've
> >>>> already asked the user about the CPU level I think we should avoid to
> >>>> ask
> >>>> the user to change it again later. See Bug 1034821 - Hosted-setup asks
> >>>> for
> >>>> CPU type but it doesn't set cluster to that CPU Level
> >>>> 
> >>> 
> >>> You can set the CPU level through the SDK, after you add the host (didn't
> >>> check that, but see no reason it won't work).
> >> 
> >> why so late in the process?
> >> 
> > 
> > why does it matter? The setup is still running, so, imo, the order is less
> > relevant, as long as the result is okay.
> 
> 
> depends. if hosted engine is part of the installation, it should do the
> modifications during installation the same way as anything else, forcefully,
> and not depend on working sdk or any other precondition
> if it is something you are/should be able to deploy over an existing setup
> it's better via sdk...
> 

Well... it is somewhere in between.
One of the steps in the hosted engine setup is to start a VM in which the user needs to install the engine.
So, adding the host is done via the SDK after the engine installation is completed.
That's why I thought it would be best to change the CPU level also after the engine installation is complete, and not during it.
In addition, it will probably also help covering the use-case of migrating an existing engine to a hosted engine environment (although I'm not familiar enough with the current proposed solution for this use-case).

> >>> 
> >>>> 
> >>>>> 
> >>>>>> 
> >>>>>>> Thanks,
> >>>>>>> michal
> >>>>>>> 
> >>>>>>>> 
> >>>>>>>> Michael, can you take a look at http://gerrit.ovirt.org/22129 and
> >>>>>>>> advise?
> >>>>>>>> 
> >>>>>>>> 
> >>>>>>>> --
> >>>>>>>> Sandro Bonazzola
> >>>>>>>> Better technology. Faster innovation. Powered by community
> >>>>>>>> collaboration.
> >>>>>>>> See how it works at redhat.com
> >>>>>>>> _______________________________________________
> >>>>>>>> Engine-devel mailing list
> >>>>>>>> Engine-devel at ovirt.org
> >>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>>>>> 
> >>>>>>> _______________________________________________
> >>>>>>> Engine-devel mailing list
> >>>>>>> Engine-devel at ovirt.org
> >>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>>>>> 
> >>>> 
> >>>> 
> >>>> --
> >>>> Sandro Bonazzola
> >>>> Better technology. Faster innovation. Powered by community
> >>>> collaboration.
> >>>> See how it works at redhat.com
> >>>> _______________________________________________
> >>>> Engine-devel mailing list
> >>>> Engine-devel at ovirt.org
> >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>> 
> >> 
> >> 
> 
> 


From michal.skrivanek at redhat.com  Wed Dec 11 06:57:56 2013
From: michal.skrivanek at redhat.com (Michal Skrivanek)
Date: Wed, 11 Dec 2013 08:57:56 +0200
Subject: [Engine-devel] Setting cluster CPU
In-Reply-To: <1844887159.39886512.1386744812543.JavaMail.root@redhat.com>
References: <52A5CD4B.1000806@redhat.com>
	<1421132832.38152228.1386608309092.JavaMail.root@redhat.com>
	<211CC433-A88D-4C6B-A851-E3A8443DC49B@redhat.com>
	<52A6BECE.7030608@redhat.com>
	<1947325153.38937830.1386659684527.JavaMail.root@redhat.com>
	<8FE86632-29E8-4458-BE05-2138B1D8354E@redhat.com>
	<1161617116.39883433.1386742703725.JavaMail.root@redhat.com>
	<6066CF2A-7E14-4E41-B3D0-ED853582F622@redhat.com>
	<1844887159.39886512.1386744812543.JavaMail.root@redhat.com>
Message-ID: <B04B342A-83C5-4094-A542-C070777522F6@redhat.com>


On Dec 11, 2013, at 08:53 , Oved Ourfalli <ovedo at redhat.com> wrote:

> 
> 
> ----- Original Message -----
>> From: "Michal Skrivanek" <michal.skrivanek at redhat.com>
>> To: "Oved Ourfalli" <ovedo at redhat.com>
>> Cc: "Sandro Bonazzola" <sbonazzo at redhat.com>, "Roy Golan" <rgolan at redhat.com>, "engine-devel"
>> <engine-devel at ovirt.org>
>> Sent: Wednesday, December 11, 2013 8:45:41 AM
>> Subject: Re: [Engine-devel] Setting cluster CPU
>> 
>> 
>> On Dec 11, 2013, at 08:18 , Oved Ourfalli <ovedo at redhat.com> wrote:
>> 
>>> 
>>> 
>>> ----- Original Message -----
>>>> From: "Michal Skrivanek" <michal.skrivanek at redhat.com>
>>>> To: "Oved Ourfalli" <ovedo at redhat.com>, "Sandro Bonazzola"
>>>> <sbonazzo at redhat.com>
>>>> Cc: "Roy Golan" <rgolan at redhat.com>, "engine-devel"
>>>> <engine-devel at ovirt.org>
>>>> Sent: Tuesday, December 10, 2013 8:01:08 PM
>>>> Subject: Re: [Engine-devel] Setting cluster CPU
>>>> 
>>>> 
>>>> On Dec 10, 2013, at 09:14 , Oved Ourfalli <ovedo at redhat.com> wrote:
>>>> 
>>>>> 
>>>>> 
>>>>> ----- Original Message -----
>>>>>> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
>>>>>> To: "Michal Skrivanek" <michal.skrivanek at redhat.com>, "Oved Ourfalli"
>>>>>> <ovedo at redhat.com>, "Roy Golan"
>>>>>> <rgolan at redhat.com>
>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>>>>>> Sent: Tuesday, December 10, 2013 9:12:14 AM
>>>>>> Subject: Re: [Engine-devel] Setting cluster CPU
>>>>>> 
>>>>>> Il 09/12/2013 19:37, Michal Skrivanek ha scritto:
>>>>>>> 
>>>>>>> 
>>>>>>>> On 09 Dec 2013, at 18:58, Oved Ourfalli <ovedo at redhat.com> wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Michal Skrivanek" <michal.skrivanek at redhat.com>
>>>>>>>>> To: "Sandro Bonazzola" <sbonazzo at redhat.com>, "Roy Golan"
>>>>>>>>> <rgolan at redhat.com>
>>>>>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>>>>>>>>> Sent: Monday, December 9, 2013 5:50:49 PM
>>>>>>>>> Subject: Re: [Engine-devel] Setting cluster CPU
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> On Dec 9, 2013, at 16:01 , Sandro Bonazzola <sbonazzo at redhat.com>
>>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>> Hi,
>>>>>>>>>> I'm trying to set the cluster CPU type while adding the first host
>>>>>>>>>> to
>>>>>>>>>> the
>>>>>>>>>> Default cluster.
>>>>>>>>>> 
>>>>>>>>>> I know how to set the CPU type on a new cluster, since I'll do that
>>>>>>>>>> in
>>>>>>>>>> AIO
>>>>>>>>>> plugin.
>>>>>>>>>> But I'm not sure to understand how to set the CPU on an existing
>>>>>>>>>> cluster.
>>>>>>>>>> 
>>>>>>>>>> Should it be enough to specify cpu arg while adding the host to the
>>>>>>>>>> cluster?
>>>>>>>>>> (before adding an host, cpu is None on the cluster)
>>>>>>>>>> Because I'm trying to do that without success (obtaining a
>>>>>>>>>> sandybridge
>>>>>>>>>> cluster while specifying westmere cpu).
>>>>>>>>> 
>>>>>>>>> The CPU should be set from the first host if None. That is needed for
>>>>>>>>> the
>>>>>>>>> PPC
>>>>>>>>> support. Roy, we talked about it recently, where are we with this
>>>>>>>>> patch.
>>>>>>>> 
>>>>>>>> We already support modifying the CPU level of an existing cluster. If
>>>>>>>> changing it to a higher level then we just change it.
>>>>>>>> If changing it to a lower level, and there are running VMs on the
>>>>>>>> cluster,
>>>>>>>> then we warn the user that some VMs might not be migrate-able, as we
>>>>>>>> added a scheduling filter to filter out hosts with improper CPU level.
>>>>>>>> 
>>>>>>>> Unless I'm missing something, that covers the use-case, isn't it?
>>>>>>> 
>>>>>>> Not sure. I thought this is None to something, where it should work
>>>>>>> automatically without specifying anything. Just add an operational host
>>>>>> 
>>>>>> Well, here the issue is that while deploying hosted-engine VM, I'm on a
>>>>>> SandyBridge host, with 1 VM running on it (the hosted engine VM).
>>>>>> That VM has been created with CPU model Westmere to be able to migrate
>>>>>> it
>>>>>> to
>>>>>> other hosts Westmere compatible.
>>>>>> But the Default cluster is automatically set to SandyBridge when I add
>>>>>> the
>>>> 
>>>> because it's created with None in the first place, and then set by the
>>>> first
>>>> host. If you'd create it with Westmere initially the joining host would
>>>> not
>>>> change it
>>>> IMHO the setting should be done during the installation not via calling
>>>> SDK
>>>> on already created empty cluster but directly in the db when the db is
>>>> deployed. Unless I'm missing the sequence of deployment.
>>>> 
>>> 
>>> The hosted engine setup doesn't access the DB, so no reason to access it if
>>> it is possible to do that via the SDK.
>>> Didn't test that, but see no reason for it not to work.
>>> 
>>>>>> host also if I specify Westmere as CPU family in Host parameter.
>>>>>> We may be able to set manually the CPU level later somehow, but since
>>>>>> we've
>>>>>> already asked the user about the CPU level I think we should avoid to
>>>>>> ask
>>>>>> the user to change it again later. See Bug 1034821 - Hosted-setup asks
>>>>>> for
>>>>>> CPU type but it doesn't set cluster to that CPU Level
>>>>>> 
>>>>> 
>>>>> You can set the CPU level through the SDK, after you add the host (didn't
>>>>> check that, but see no reason it won't work).
>>>> 
>>>> why so late in the process?
>>>> 
>>> 
>>> why does it matter? The setup is still running, so, imo, the order is less
>>> relevant, as long as the result is okay.
>> 
>> 
>> depends. if hosted engine is part of the installation, it should do the
>> modifications during installation the same way as anything else, forcefully,
>> and not depend on working sdk or any other precondition
>> if it is something you are/should be able to deploy over an existing setup
>> it's better via sdk...
>> 
> 
> Well... it is somewhere in between.
> One of the steps in the hosted engine setup is to start a VM in which the user needs to install the engine.
> So, adding the host is done via the SDK after the engine installation is completed.

ah, ok, I thought it's before that, as the host is the one your engine is at, so I thought it can be created right at the beginning
then it all makes sense:)
 
> That's why I thought it would be best to change the CPU level also after the engine installation is complete, and not during it.
> In addition, it will probably also help covering the use-case of migrating an existing engine to a hosted engine environment (although I'm not familiar enough with the current proposed solution for this use-case).

> 
>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>>> 
>>>>>>>>> Thanks,
>>>>>>>>> michal
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Michael, can you take a look at http://gerrit.ovirt.org/22129 and
>>>>>>>>>> advise?
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> --
>>>>>>>>>> Sandro Bonazzola
>>>>>>>>>> Better technology. Faster innovation. Powered by community
>>>>>>>>>> collaboration.
>>>>>>>>>> See how it works at redhat.com
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Engine-devel mailing list
>>>>>>>>>> Engine-devel at ovirt.org
>>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>>>> 
>>>>>>>>> _______________________________________________
>>>>>>>>> Engine-devel mailing list
>>>>>>>>> Engine-devel at ovirt.org
>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Sandro Bonazzola
>>>>>> Better technology. Faster innovation. Powered by community
>>>>>> collaboration.
>>>>>> See how it works at redhat.com
>>>>>> _______________________________________________
>>>>>> Engine-devel mailing list
>>>>>> Engine-devel at ovirt.org
>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>> 
>>>> 
>>>> 
>> 
>> 



From sbonazzo at redhat.com  Wed Dec 11 08:29:41 2013
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Wed, 11 Dec 2013 09:29:41 +0100
Subject: [Engine-devel] [QE] oVirt 3.3.2 RC status
In-Reply-To: <52A58DD2.4070504@redhat.com>
References: <52A1A677.4040508@redhat.com> <52A58DD2.4070504@redhat.com>
Message-ID: <52A82275.8090709@redhat.com>

Hi,
we should decide today at oVirt sync meeting about oVirt 3.3.2 RC build scheduled for today [1]
A bug tracker is available at [2] and it shows only 2 bugs still blocking the release:
Whiteboard	Bug ID	Summary
virt		1029885	cloud-init testcase does not work in engine 3.3.1
virt		1025829	sysprep floppy is not attached to Windows 2008 R2 machine - even when specifically checked in Run Once

Omer: "3.3.2 backported and wait for review from REST"
- Is 1029885 solved by fix introduced for bug 1039009 ? I can't see any pending patches about this pushed to 3.3.2 branch.

Roy:
- ETA for 1025829?

oVirt 3.3.2 beta testing is in progress, thanks to all who already started testing it!
For those willing to help testing the bugs, I suggest to add yourself as QA contact for the bug and add yourself to the testing page [3].

Maintainers should fill release notes before RC build if not already done, the page has been created here [4]

[1] http://www.ovirt.org/OVirt_3.3.z_release-management
[2] https://bugzilla.redhat.com/1027349
[3] http://www.ovirt.org/Testing/Ovirt_3.3.2_testing
[4] http://www.ovirt.org/OVirt_3.3.2_release_notes

-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com


From ofrenkel at redhat.com  Wed Dec 11 10:22:13 2013
From: ofrenkel at redhat.com (Omer Frenkel)
Date: Wed, 11 Dec 2013 05:22:13 -0500 (EST)
Subject: [Engine-devel] [QE] oVirt 3.3.2 RC status
In-Reply-To: <52A82275.8090709@redhat.com>
References: <52A1A677.4040508@redhat.com> <52A58DD2.4070504@redhat.com>
	<52A82275.8090709@redhat.com>
Message-ID: <1095144316.28422389.1386757333944.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>, Users at ovirt.org, "VDSM Project Development"
> <vdsm-devel at lists.fedorahosted.org>, "Roy Golan" <rgolan at redhat.com>, "Omer Frenkel" <ofrenkel at redhat.com>
> Cc: "Itamar Heim" <iheim at redhat.com>
> Sent: Wednesday, December 11, 2013 10:29:41 AM
> Subject: Re: [QE] oVirt 3.3.2 RC status
> 
> Hi,
> we should decide today at oVirt sync meeting about oVirt 3.3.2 RC build
> scheduled for today [1]
> A bug tracker is available at [2] and it shows only 2 bugs still blocking the
> release:
> Whiteboard	Bug ID	Summary
> virt		1029885	cloud-init testcase does not work in engine 3.3.1
> virt		1025829	sysprep floppy is not attached to Windows 2008 R2 machine -
> even when specifically checked in Run Once
> 
> Omer: "3.3.2 backported and wait for review from REST"
> - Is 1029885 solved by fix introduced for bug 1039009 ? I can't see any
> pending patches about this pushed to 3.3.2 branch.
> 

you are right, i mixed up those 2 bugs, 'Bug 1039009 - can't use cloud-init /run once via api' - fixed, 
'1029885 - cloud-init testcase does not work in engine 3.3.1' - no fix except upgrading guest right now

> Roy:
> - ETA for 1025829?
> 
> oVirt 3.3.2 beta testing is in progress, thanks to all who already started
> testing it!
> For those willing to help testing the bugs, I suggest to add yourself as QA
> contact for the bug and add yourself to the testing page [3].
> 
> Maintainers should fill release notes before RC build if not already done,
> the page has been created here [4]
> 
> [1] http://www.ovirt.org/OVirt_3.3.z_release-management
> [2] https://bugzilla.redhat.com/1027349
> [3] http://www.ovirt.org/Testing/Ovirt_3.3.2_testing
> [4] http://www.ovirt.org/OVirt_3.3.2_release_notes
> 
> --
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com
> 


From S.Kieske at mittwald.de  Wed Dec 11 12:12:47 2013
From: S.Kieske at mittwald.de (Sven Kieske)
Date: Wed, 11 Dec 2013 12:12:47 +0000
Subject: [Engine-devel] [QE] oVirt 3.3.2 RC status
In-Reply-To: <1095144316.28422389.1386757333944.JavaMail.root@redhat.com>
References: <52A1A677.4040508@redhat.com> <52A58DD2.4070504@redhat.com>
	<1095144316.28422389.1386757333944.JavaMail.root@redhat.com>
Message-ID: <52A8575A.5010607@mittwald.de>

Hi,

just wanted to add, that I will test if
'Bug 1039009 - can't use cloud-init /run once via api'
is fixed, but I have to wait for the new RPMs in the beta repo.
It would be cool if someone could ping me via mail when they are
available.

I will add myself to the wiki test page, once I installed 3.3.2 beta.

Thanks!

-- 
Mit freundlichen Gr??en / Regards

Sven Kieske

Systemadministrator
Mittwald CM Service GmbH & Co. KG
K?nigsberger Stra?e 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
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

From S.Kieske at mittwald.de  Thu Dec 12 08:14:16 2013
From: S.Kieske at mittwald.de (Sven Kieske)
Date: Thu, 12 Dec 2013 08:14:16 +0000
Subject: [Engine-devel] CodeQuality/Automated Checking
Message-ID: <52A970F3.3070608@mittwald.de>

Hi,

I just stumbled upon this:

http://gerrit.ovirt.org/#/c/22310/1/vdsm.spec.in

such errors could be prevented easily.
either by using bash -n $scriptname.sh before commit
or by automated syntaxchecking via jenkins ?

what do you think?
-- 
Mit freundlichen Gr??en / Regards

Sven Kieske

Systemadministrator
Mittwald CM Service GmbH & Co. KG
K?nigsberger Stra?e 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
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

From emesika at redhat.com  Thu Dec 12 11:10:20 2013
From: emesika at redhat.com (Eli Mesika)
Date: Thu, 12 Dec 2013 06:10:20 -0500 (EST)
Subject: [Engine-devel] CodeQuality/Automated Checking
In-Reply-To: <52A970F3.3070608@mittwald.de>
References: <52A970F3.3070608@mittwald.de>
Message-ID: <1318413862.38922007.1386846620941.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Sven Kieske" <S.Kieske at mittwald.de>
> To: engine-devel at ovirt.org
> Sent: Thursday, December 12, 2013 10:14:16 AM
> Subject: [Engine-devel] CodeQuality/Automated Checking
> 
> Hi,
> 
> I just stumbled upon this:
> 
> http://gerrit.ovirt.org/#/c/22310/1/vdsm.spec.in
> 
> such errors could be prevented easily.
> either by using bash -n $scriptname.sh before commit
> or by automated syntaxchecking via jenkins ?

+1

> 
> what do you think?
> --
> Mit freundlichen Gr??en / Regards
> 
> Sven Kieske
> 
> Systemadministrator
> Mittwald CM Service GmbH & Co. KG
> K?nigsberger Stra?e 6
> 32339 Espelkamp
> T: +49-5772-293-100
> F: +49-5772-293-333
> 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
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From emesika at redhat.com  Thu Dec 12 11:12:36 2013
From: emesika at redhat.com (Eli Mesika)
Date: Thu, 12 Dec 2013 06:12:36 -0500 (EST)
Subject: [Engine-devel] [QE] oVirt 3.3.2 RC status
In-Reply-To: <52A8575A.5010607@mittwald.de>
References: <52A1A677.4040508@redhat.com> <52A58DD2.4070504@redhat.com>
	<1095144316.28422389.1386757333944.JavaMail.root@redhat.com>
	<52A8575A.5010607@mittwald.de>
Message-ID: <1585381233.38922603.1386846756346.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Sven Kieske" <S.Kieske at mittwald.de>
> To: engine-devel at ovirt.org
> Sent: Wednesday, December 11, 2013 2:12:47 PM
> Subject: Re: [Engine-devel] [QE] oVirt 3.3.2 RC status
> 
> Hi,
> 
> just wanted to add, that I will test if
> 'Bug 1039009 - can't use cloud-init /run once via api'
> is fixed, but I have to wait for the new RPMs in the beta repo.
> It would be cool if someone could ping me via mail when they are
> available.
> 
> I will add myself to the wiki test page, once I installed 3.3.2 beta.
> 
> Thanks!


Please note that I had flagged https://bugzilla.redhat.com/show_bug.cgi?id=1040875 to 3.3.2 as well since it can corrupt other PM agents and not the reported one.
A patch fixing that is available : http://gerrit.ovirt.org/#/c/22326/


> 
> --
> Mit freundlichen Gr??en / Regards
> 
> Sven Kieske
> 
> Systemadministrator
> Mittwald CM Service GmbH & Co. KG
> K?nigsberger Stra?e 6
> 32339 Espelkamp
> T: +49-5772-293-100
> F: +49-5772-293-333
> 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
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From alonbl at redhat.com  Thu Dec 12 11:15:17 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Thu, 12 Dec 2013 06:15:17 -0500 (EST)
Subject: [Engine-devel] CodeQuality/Automated Checking
In-Reply-To: <1318413862.38922007.1386846620941.JavaMail.root@redhat.com>
References: <52A970F3.3070608@mittwald.de>
	<1318413862.38922007.1386846620941.JavaMail.root@redhat.com>
Message-ID: <476502120.25330244.1386846917674.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Eli Mesika" <emesika at redhat.com>
> To: "Sven Kieske" <S.Kieske at mittwald.de>
> Cc: engine-devel at ovirt.org
> Sent: Thursday, December 12, 2013 1:10:20 PM
> Subject: Re: [Engine-devel] CodeQuality/Automated Checking
> 
> 
> 
> ----- Original Message -----
> > From: "Sven Kieske" <S.Kieske at mittwald.de>
> > To: engine-devel at ovirt.org
> > Sent: Thursday, December 12, 2013 10:14:16 AM
> > Subject: [Engine-devel] CodeQuality/Automated Checking
> > 
> > Hi,
> > 
> > I just stumbled upon this:
> > 
> > http://gerrit.ovirt.org/#/c/22310/1/vdsm.spec.in
> > 
> > such errors could be prevented easily.
> > either by using bash -n $scriptname.sh before commit
> > or by automated syntaxchecking via jenkins ?
> 
> +1

first, using bash is not a good idea... better to use POSIX compliant shell.

second, these changes should be part of Makefile just like we validate python scripts.

I can workout some patch to do this.

> 
> > 
> > what do you think?
> > --
> > Mit freundlichen Gr??en / Regards
> > 
> > Sven Kieske
> > 
> > Systemadministrator
> > Mittwald CM Service GmbH & Co. KG
> > K?nigsberger Stra?e 6
> > 32339 Espelkamp
> > T: +49-5772-293-100
> > F: +49-5772-293-333
> > 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
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From alonbl at redhat.com  Thu Dec 12 12:11:31 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Thu, 12 Dec 2013 07:11:31 -0500 (EST)
Subject: [Engine-devel] CodeQuality/Automated Checking
In-Reply-To: <476502120.25330244.1386846917674.JavaMail.root@redhat.com>
References: <52A970F3.3070608@mittwald.de>
	<1318413862.38922007.1386846620941.JavaMail.root@redhat.com>
	<476502120.25330244.1386846917674.JavaMail.root@redhat.com>
Message-ID: <1455746512.25339980.1386850291130.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "Eli Mesika" <emesika at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Thursday, December 12, 2013 1:15:17 PM
> Subject: Re: [Engine-devel] CodeQuality/Automated Checking
> 
> 
> 
> ----- Original Message -----
> > From: "Eli Mesika" <emesika at redhat.com>
> > To: "Sven Kieske" <S.Kieske at mittwald.de>
> > Cc: engine-devel at ovirt.org
> > Sent: Thursday, December 12, 2013 1:10:20 PM
> > Subject: Re: [Engine-devel] CodeQuality/Automated Checking
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Sven Kieske" <S.Kieske at mittwald.de>
> > > To: engine-devel at ovirt.org
> > > Sent: Thursday, December 12, 2013 10:14:16 AM
> > > Subject: [Engine-devel] CodeQuality/Automated Checking
> > > 
> > > Hi,
> > > 
> > > I just stumbled upon this:
> > > 
> > > http://gerrit.ovirt.org/#/c/22310/1/vdsm.spec.in
> > > 
> > > such errors could be prevented easily.
> > > either by using bash -n $scriptname.sh before commit
> > > or by automated syntaxchecking via jenkins ?
> > 
> > +1
> 
> first, using bash is not a good idea... better to use POSIX compliant shell.
> 
> second, these changes should be part of Makefile just like we validate python
> scripts.
> 
> I can workout some patch to do this.

well, I did not notice two important facts...
1. the assumption that bash -n can be executed on spec, which is incorrect... I thought we are discussing proper scripts.
2. that the project is vdsm and not engine.

anyway, this is indeed nice to have, available for engine[1]

[1] http://gerrit.ovirt.org/22332

> 
> > 
> > > 
> > > what do you think?
> > > --
> > > Mit freundlichen Gr??en / Regards
> > > 
> > > Sven Kieske
> > > 
> > > Systemadministrator
> > > Mittwald CM Service GmbH & Co. KG
> > > K?nigsberger Stra?e 6
> > > 32339 Espelkamp
> > > T: +49-5772-293-100
> > > F: +49-5772-293-333
> > > 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
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From S.Kieske at mittwald.de  Thu Dec 12 12:16:53 2013
From: S.Kieske at mittwald.de (Sven Kieske)
Date: Thu, 12 Dec 2013 12:16:53 +0000
Subject: [Engine-devel] CodeQuality/Automated Checking
In-Reply-To: <476502120.25330244.1386846917674.JavaMail.root@redhat.com>
References: <52A970F3.3070608@mittwald.de>
	<1318413862.38922007.1386846620941.JavaMail.root@redhat.com>
	<476502120.25330244.1386846917674.JavaMail.root@redhat.com>
Message-ID: <52A9A9D0.7020904@mittwald.de>

Yeah of course it's always better you stay POSIX compliant, if it's
needed :)
The bash example was just the first one I thought of.

Glad to see this idea got picked up so fast!

Am 12.12.2013 12:15, schrieb Alon Bar-Lev:
> first, using bash is not a good idea... better to use POSIX compliant shell.

-- 
Mit freundlichen Gr??en / Regards

Sven Kieske

Systemadministrator
Mittwald CM Service GmbH & Co. KG
K?nigsberger Stra?e 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
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

From ybronhei at redhat.com  Thu Dec 12 15:18:35 2013
From: ybronhei at redhat.com (Yaniv Bronheim)
Date: Thu, 12 Dec 2013 10:18:35 -0500 (EST)
Subject: [Engine-devel] CodeQuality/Automated Checking
In-Reply-To: <52A9A9D0.7020904@mittwald.de>
References: <52A970F3.3070608@mittwald.de>
	<1318413862.38922007.1386846620941.JavaMail.root@redhat.com>
	<476502120.25330244.1386846917674.JavaMail.root@redhat.com>
	<52A9A9D0.7020904@mittwald.de>
Message-ID: <1178855771.25399224.1386861515049.JavaMail.root@redhat.com>

----- Original Message -----
> From: "Sven Kieske" <S.Kieske at mittwald.de>
> To: "Alon Bar-Lev" <alonbl at redhat.com>, "Eli Mesika" <emesika at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Thursday, December 12, 2013 2:16:53 PM
> Subject: Re: [Engine-devel] CodeQuality/Automated Checking
> 
> Yeah of course it's always better you stay POSIX compliant, if it's
> needed :)
> The bash example was just the first one I thought of.
> 
> Glad to see this idea got picked up so fast!

glad to cause this thread :) as it was my glitch leaving a "fi" out there
I'll be glad to review such patch as http://gerrit.ovirt.org/22332 for Vdsm 
doesn't look complicate to integrate it to vdsm code and run it as part of the make

+1

> 
> Am 12.12.2013 12:15, schrieb Alon Bar-Lev:
> > first, using bash is not a good idea... better to use POSIX compliant
> > shell.
> 
> --
> Mit freundlichen Gr??en / Regards
> 
> Sven Kieske
> 
> Systemadministrator
> Mittwald CM Service GmbH & Co. KG
> K?nigsberger Stra?e 6
> 32339 Espelkamp
> T: +49-5772-293-100
> F: +49-5772-293-333
> 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
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>


From eedri at redhat.com  Thu Dec 12 16:56:56 2013
From: eedri at redhat.com (Eyal Edri)
Date: Thu, 12 Dec 2013 11:56:56 -0500 (EST)
Subject: [Engine-devel] Please add an account for me in oVirt Jenkins.
In-Reply-To: <448108020.51310345.1386867033939.JavaMail.root@redhat.com>
References: <448108020.51310345.1386867033939.JavaMail.root@redhat.com>
Message-ID: <2069917934.4226140.1386867416162.JavaMail.root@redhat.com>

+1. (adding engine-devel also)

yaniv should have access to build ovirt dwh & reports projects on jenkins.

Eyal.

----- Original Message -----
> From: "Yaniv Dary" <ydary at redhat.com>
> To: infra at ovirt.org
> Sent: Thursday, December 12, 2013 6:50:33 PM
> Subject: Please add an account for me in oVirt Jenkins.
> 
> Hi,
> I need access to Jenkins to build projects and add/manage jobs. Can you
> please create an account for me?
> My fedora openID is ydary.
> 
> 
> Thanks!
> 
> ---
> Yaniv Dary
> BI Software Engineer
> Red Hat Israel Ltd.
> 34 Jerusalem Road
> Building A, 4th floor
> Ra'anana, Israel 43501
> 
> Tel : +972 (9) 7692306
> 72306
> Email: ydary at redhat.com
> IRC : ydary
> 
> _______________________________________________
> Infra mailing list
> Infra at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
> 


From sbonazzo at redhat.com  Fri Dec 13 06:38:43 2013
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Fri, 13 Dec 2013 07:38:43 +0100
Subject: [Engine-devel] Please add an account for me in oVirt Jenkins.
In-Reply-To: <2069917934.4226140.1386867416162.JavaMail.root@redhat.com>
References: <448108020.51310345.1386867033939.JavaMail.root@redhat.com>
	<2069917934.4226140.1386867416162.JavaMail.root@redhat.com>
Message-ID: <52AAAB73.2080001@redhat.com>

Il 12/12/2013 17:56, Eyal Edri ha scritto:
> +1. (adding engine-devel also)
> 
> yaniv should have access to build ovirt dwh & reports projects on jenkins.

+1 from me too

> 
> Eyal.
> 
> ----- Original Message -----
>> From: "Yaniv Dary" <ydary at redhat.com>
>> To: infra at ovirt.org
>> Sent: Thursday, December 12, 2013 6:50:33 PM
>> Subject: Please add an account for me in oVirt Jenkins.
>>
>> Hi,
>> I need access to Jenkins to build projects and add/manage jobs. Can you
>> please create an account for me?
>> My fedora openID is ydary.
>>
>>
>> Thanks!
>>
>> ---
>> Yaniv Dary
>> BI Software Engineer
>> Red Hat Israel Ltd.
>> 34 Jerusalem Road
>> Building A, 4th floor
>> Ra'anana, Israel 43501
>>
>> Tel : +972 (9) 7692306
>> 72306
>> Email: ydary at redhat.com
>> IRC : ydary
>>
>> _______________________________________________
>> Infra mailing list
>> Infra at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/infra
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com


From chuan.liao at hp.com  Fri Dec 13 07:37:59 2013
From: chuan.liao at hp.com (Liao, Chuan (Jason, MCXS-CQ))
Date: Fri, 13 Dec 2013 07:37:59 +0000
Subject: [Engine-devel] Help to review the design of Feature/NUMA and
	Virtual NUMA
Message-ID: <B63C858E777679458338A30A991BB5240155E248@G1W3780.americas.hpqcorp.net>

Hi Everyone,

I am Jason Liao from HP, now focus on the NUMA feature integration into oVirt.

Now we finish the first step of High-level design document.

Please help to review the design of Features/NUMA_and_Virtual_NUMA<http://www.ovirt.org/Features/NUMA_and_Virtual_NUMA> on oVirt community wiki page.

If anyone have some question and suggestion, please let me know.

Thanks all.

Best Regards,
Jason Liao

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20131213/b37721e5/attachment.html>

From sbonazzo at redhat.com  Fri Dec 13 08:11:36 2013
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Fri, 13 Dec 2013 09:11:36 +0100
Subject: [Engine-devel] [QE] ovirt-docs?
Message-ID: <52AAC138.2060009@redhat.com>

Hi,

both wiki page http://www.ovirt.org/User_Guides and git://gerrit.ovirt.org/ovirt-docs are a bit outdated.
We also have a few bugs for components:
- doc-Installation-Guide
- doc-REST_API_Guide

Anybody willing to update docs for 3.3.2 release?

-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com


From S.Kieske at mittwald.de  Fri Dec 13 08:17:28 2013
From: S.Kieske at mittwald.de (Sven Kieske)
Date: Fri, 13 Dec 2013 08:17:28 +0000
Subject: [Engine-devel] Fwd: Re: [Users] Ubuntu & Debian guest agent
In-Reply-To: <52A98DAB.7060407@mittwald.de>
References: <52A98DAB.7060407@mittwald.de>
Message-ID: <52AAC332.5010701@mittwald.de>

Forwarding to devel:

In short: does the guest agent really need to use
"usermode" for shutdown?

Simple sudoer rights should suffice and greatly reduce
the dependency tree.


-------- Original-Nachricht --------
Betreff: Re: [Users] Ubuntu & Debian guest agent
Datum: Thu, 12 Dec 2013 10:16:48 +0000
Von: Sven Kieske <S.Kieske at mittwald.de>
An: users at ovirt.org <users at ovirt.org>

Okay,

i was able to resolve some of my questions already
with the help of Vinzenz Feenstra in ovirt IRC
(Thanks again).

I'm somewhat impressed, the agent reports
IPv4 addresses and even multiple ipv6 addresses
from the vm.

But I have some additional question:

There is a huge dependency tree,
resulting in the download of the following
packages on Ubuntu 12.04.3:

fontconfig fontconfig-config hicolor-icon-theme libatk1.0-0
libatk1.0-data libavahi-client3
  libavahi-common-data libavahi-common3 libcairo2 libcups2 libdatrie1
libfontconfig1 libgdk-pixbuf2.0-0
  libgdk-pixbuf2.0-common libgtk2.0-0 libgtk2.0-bin libgtk2.0-common
libjasper1 libjpeg-turbo8 libjpeg8
  libnl1 libpango1.0-0 libpixman-1-0 libthai-data libthai0 libtiff4
libuser1 libxcb-render0 libxcb-shm0
  libxcomposite1 libxcursor1 libxdamage1 libxfixes3 libxft2 libxi6
libxinerama1 libxrandr2 libxrender1
  python-ethtool shared-mime-info ttf-dejavu-core usermode

I investigated a little and it seems that most of this stuff
(graphic libs) gets pulled in by the package "usermode"
which is a graphical tool for end users for manipulating
passwords etc.

I can understand that this tool might be needed for SSO
and okay for desktop users.

But I want to ask if it can't be substituted through sudo
or similar commandline tools for the purpose of installing
the agent on a server.

from a security perspective you don't want files like libjpeg
on your server if you don't need them.

I don't know how/why exactly usermode is used/needed so
maybe this can be changed?


-- 
Mit freundlichen Gr??en / Regards

Sven Kieske

Systemadministrator
Mittwald CM Service GmbH & Co. KG
K?nigsberger Stra?e 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
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
_______________________________________________
Users mailing list
Users at ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


From ecohen at redhat.com  Fri Dec 13 17:56:26 2013
From: ecohen at redhat.com (Einav Cohen)
Date: Fri, 13 Dec 2013 12:56:26 -0500 (EST)
Subject: [Engine-devel] developmen environment: logs
In-Reply-To: <1339982467.31090644.1386956442894.JavaMail.root@redhat.com>
Message-ID: <1075093769.31102444.1386957386516.JavaMail.root@redhat.com>

[working on development environment]

(1) I tried following instructions in [1] in order to have my engine.log 
log messages from the bll module in DEBUG level. 

After adding section [2] to the relevant file, I got an error message [3] 
(probably since a logger for category "org.ovirt.engine.core.bll" already 
exists in the file). 

I removed that new section, and changed the relevant string within the 
already-existing <logger category="org.ovirt.engine.core.bll"> from "INFO" 
to "DEBUG"; however, log for bll messages kept being logged only in the 
"INFO" level. 

[I restarted ovirt-engine.py after every change]

Any ideas?

(2) Does anyone know why queries invocation isn't being logged into the 
engine.log [maybe they are being logged in DEBUG level and due to (1) I 
cannot see them]? it seems that only action invocations are being logged. 

Many thanks in advance. 

----
Regards, 
Einav

[1] http://www.ovirt.org/OVirt_Engine_Development_Environment#Enable_DEBUG_log

[2] 
---
<logger category="org.ovirt.engine.core.bll">
   <level name="DEBUG"/>
</logger>
---

[3] [ovirt-engine-devel-env]$ ./ovirt-engine.py start
Listening for transport dt_socket at address: 8787
ovirt-engine[13794] ERROR run:485 Error: process terminated with status code 1
[ovirt-engine-devel-env]$


From awels at redhat.com  Fri Dec 13 18:01:09 2013
From: awels at redhat.com (Alexander Wels)
Date: Fri, 13 Dec 2013 13:01:09 -0500
Subject: [Engine-devel] developmen environment: logs
In-Reply-To: <1075093769.31102444.1386957386516.JavaMail.root@redhat.com>
References: <1075093769.31102444.1386957386516.JavaMail.root@redhat.com>
Message-ID: <2812174.GLULMYJF7Q@awels>

The attached ovirt-engine.xml.in.debug should be what you are looking for.

Save it as ~/ovirt-engine/share/ovirt-engine/services/ovirt-engine/ovirt-
engine.xml.in (maybe backup the original first).

Restart the engine and you should be running in debug mode.

On Friday, December 13, 2013 12:56:26 PM Einav Cohen wrote:
> [working on development environment]
> 
> (1) I tried following instructions in [1] in order to have my engine.log
> log messages from the bll module in DEBUG level.
> 
> After adding section [2] to the relevant file, I got an error message [3]
> (probably since a logger for category "org.ovirt.engine.core.bll" already
> exists in the file).
> 
> I removed that new section, and changed the relevant string within the
> already-existing <logger category="org.ovirt.engine.core.bll"> from "INFO"
> to "DEBUG"; however, log for bll messages kept being logged only in the
> "INFO" level.
> 
> [I restarted ovirt-engine.py after every change]
> 
> Any ideas?
> 
> (2) Does anyone know why queries invocation isn't being logged into the
> engine.log [maybe they are being logged in DEBUG level and due to (1) I
> cannot see them]? it seems that only action invocations are being logged.
> 
> Many thanks in advance.
> 
> ----
> Regards,
> Einav
> 
> [1]
> http://www.ovirt.org/OVirt_Engine_Development_Environment#Enable_DEBUG_log
> 
> [2]
> ---
> <logger category="org.ovirt.engine.core.bll">
>    <level name="DEBUG"/>
> </logger>
> ---
> 
> [3] [ovirt-engine-devel-env]$ ./ovirt-engine.py start
> Listening for transport dt_socket at address: 8787
> ovirt-engine[13794] ERROR run:485 Error: process terminated with status code
> 1 [ovirt-engine-devel-env]$
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ovirt-engine.xml.in.debug
Type: application/xml
Size: 13022 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20131213/fd6e11a4/attachment.wsdl>

From ecohen at redhat.com  Fri Dec 13 19:59:53 2013
From: ecohen at redhat.com (Einav Cohen)
Date: Fri, 13 Dec 2013 14:59:53 -0500 (EST)
Subject: [Engine-devel] developmen environment: logs
In-Reply-To: <2812174.GLULMYJF7Q@awels>
References: <1075093769.31102444.1386957386516.JavaMail.root@redhat.com>
	<2812174.GLULMYJF7Q@awels>
Message-ID: <1675330976.31206642.1386964793391.JavaMail.root@redhat.com>

thanks, Alexander - it worked.

----
Regards,
Einav

----- Original Message -----
> From: "Alexander Wels" <awels at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Friday, December 13, 2013 1:01:09 PM
> Subject: Re: [Engine-devel] developmen environment: logs
> 
> The attached ovirt-engine.xml.in.debug should be what you are looking for.
> 
> Save it as ~/ovirt-engine/share/ovirt-engine/services/ovirt-engine/ovirt-
> engine.xml.in (maybe backup the original first).
> 
> Restart the engine and you should be running in debug mode.
> 
> On Friday, December 13, 2013 12:56:26 PM Einav Cohen wrote:
> > [working on development environment]
> > 
> > (1) I tried following instructions in [1] in order to have my engine.log
> > log messages from the bll module in DEBUG level.
> > 
> > After adding section [2] to the relevant file, I got an error message [3]
> > (probably since a logger for category "org.ovirt.engine.core.bll" already
> > exists in the file).
> > 
> > I removed that new section, and changed the relevant string within the
> > already-existing <logger category="org.ovirt.engine.core.bll"> from "INFO"
> > to "DEBUG"; however, log for bll messages kept being logged only in the
> > "INFO" level.
> > 
> > [I restarted ovirt-engine.py after every change]
> > 
> > Any ideas?
> > 
> > (2) Does anyone know why queries invocation isn't being logged into the
> > engine.log [maybe they are being logged in DEBUG level and due to (1) I
> > cannot see them]? it seems that only action invocations are being logged.
> > 
> > Many thanks in advance.
> > 
> > ----
> > Regards,
> > Einav
> > 
> > [1]
> > http://www.ovirt.org/OVirt_Engine_Development_Environment#Enable_DEBUG_log
> > 
> > [2]
> > ---
> > <logger category="org.ovirt.engine.core.bll">
> >    <level name="DEBUG"/>
> > </logger>
> > ---
> > 
> > [3] [ovirt-engine-devel-env]$ ./ovirt-engine.py start
> > Listening for transport dt_socket at address: 8787
> > ovirt-engine[13794] ERROR run:485 Error: process terminated with status
> > code
> > 1 [ovirt-engine-devel-env]$
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From eedri at redhat.com  Sun Dec 15 10:10:11 2013
From: eedri at redhat.com (Eyal Edri)
Date: Sun, 15 Dec 2013 05:10:11 -0500 (EST)
Subject: [Engine-devel] [jenkins] dao tests broken
In-Reply-To: <901914100.4981981.1387102060376.JavaMail.root@redhat.com>
Message-ID: <2045137911.4982023.1387102211598.JavaMail.root@redhat.com>

fyi,

dao tests are broken for some time now, who can look into it?
current failing tests are:

Tests in error: 
  testAdUserConstrcutor(org.ovirt.engine.core.common.users.VdcUserTest): org.ovirt.engine.core.common.businessentities.LdapUser.setPassword(Ljava/lang/String;)V
  testAdUserAndFalseBooleanConstrcutor(org.ovirt.engine.core.common.users.VdcUserTest): org.ovirt.engine.core.common.businessentities.LdapUser.setPassword(Ljava/lang/String;)V
  testAdUserAndTrueBooleanConstrcutor(org.ovirt.engine.core.common.users.VdcUserTest): org.ovirt.engine.core.common.businessentities.LdapUser.setPassword(Ljava/lang/String;)V
  getUserFQN(org.ovirt.engine.core.common.users.VdcUserTest): org.ovirt.engine.core.common.businessentities.LdapUser.setPassword(Ljava/lang/String;)V

http://jenkins.ovirt.org/job/ovirt_engine_dao_unit_tests/5446/console

looks like it started after commit : http://jenkins.ovirt.org/job/ovirt_engine_dao_unit_tests/5438/
core: scheduling: handle cpu load duration (detail / gitweb)

Eyal.


From gchaplik at redhat.com  Sun Dec 15 11:06:04 2013
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Sun, 15 Dec 2013 06:06:04 -0500 (EST)
Subject: [Engine-devel] [jenkins] dao tests broken
In-Reply-To: <2045137911.4982023.1387102211598.JavaMail.root@redhat.com>
References: <2045137911.4982023.1387102211598.JavaMail.root@redhat.com>
Message-ID: <964579659.52022882.1387105564105.JavaMail.root@redhat.com>


----- Original Message -----
> From: "Eyal Edri" <eedri at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Cc: "infra" <infra at ovirt.org>, "Gilad Chaplik" <gchaplik at redhat.com>
> Sent: Sunday, December 15, 2013 12:10:11 PM
> Subject: [jenkins] dao tests broken
> 
> fyi,
> 
> dao tests are broken for some time now, who can look into it?
> current failing tests are:

Hi Eyal, 

what fails is unit tests and not dao tests (fails on dao job), 
it looks like you're trying to rebase ovirt-engine-3.3 on top of master (you can see it even it the log, comparing the last success and first fail jobs).

can you check it out?

Thanks, 
Gilad.

> 
> Tests in error:
>   testAdUserConstrcutor(org.ovirt.engine.core.common.users.VdcUserTest):
>   org.ovirt.engine.core.common.businessentities.LdapUser.setPassword(Ljava/lang/String;)V
>   testAdUserAndFalseBooleanConstrcutor(org.ovirt.engine.core.common.users.VdcUserTest):
>   org.ovirt.engine.core.common.businessentities.LdapUser.setPassword(Ljava/lang/String;)V
>   testAdUserAndTrueBooleanConstrcutor(org.ovirt.engine.core.common.users.VdcUserTest):
>   org.ovirt.engine.core.common.businessentities.LdapUser.setPassword(Ljava/lang/String;)V
>   getUserFQN(org.ovirt.engine.core.common.users.VdcUserTest):
>   org.ovirt.engine.core.common.businessentities.LdapUser.setPassword(Ljava/lang/String;)V
> 
> http://jenkins.ovirt.org/job/ovirt_engine_dao_unit_tests/5446/console
> 
> looks like it started after commit :
> http://jenkins.ovirt.org/job/ovirt_engine_dao_unit_tests/5438/
> core: scheduling: handle cpu load duration (detail / gitweb)
> 
> Eyal.
> 


From obasan at redhat.com  Sun Dec 15 11:44:08 2013
From: obasan at redhat.com (Ohad Basan)
Date: Sun, 15 Dec 2013 06:44:08 -0500 (EST)
Subject: [Engine-devel] [jenkins] dao tests broken
In-Reply-To: <964579659.52022882.1387105564105.JavaMail.root@redhat.com>
References: <2045137911.4982023.1387102211598.JavaMail.root@redhat.com>
	<964579659.52022882.1387105564105.JavaMail.root@redhat.com>
Message-ID: <20739648.31439826.1387107848201.JavaMail.root@redhat.com>

this job doesn't do any rebase
where do you see it ?
http://jenkins.ovirt.org/job/ovirt_engine_dao_unit_tests/5446/console
I didn't find "rebase" in the console log


----- Original Message -----
> From: "Gilad Chaplik" <gchaplik at redhat.com>
> To: "Eyal Edri" <eedri at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "infra" <infra at ovirt.org>
> Sent: Sunday, December 15, 2013 1:06:04 PM
> Subject: Re: [Engine-devel] [jenkins] dao tests broken
> 
> 
> ----- Original Message -----
> > From: "Eyal Edri" <eedri at redhat.com>
> > To: "engine-devel" <engine-devel at ovirt.org>
> > Cc: "infra" <infra at ovirt.org>, "Gilad Chaplik" <gchaplik at redhat.com>
> > Sent: Sunday, December 15, 2013 12:10:11 PM
> > Subject: [jenkins] dao tests broken
> > 
> > fyi,
> > 
> > dao tests are broken for some time now, who can look into it?
> > current failing tests are:
> 
> Hi Eyal,
> 
> what fails is unit tests and not dao tests (fails on dao job),
> it looks like you're trying to rebase ovirt-engine-3.3 on top of master (you
> can see it even it the log, comparing the last success and first fail jobs).
> 
> can you check it out?
> 
> Thanks,
> Gilad.
> 
> > 
> > Tests in error:
> >   testAdUserConstrcutor(org.ovirt.engine.core.common.users.VdcUserTest):
> >   org.ovirt.engine.core.common.businessentities.LdapUser.setPassword(Ljava/lang/String;)V
> >   testAdUserAndFalseBooleanConstrcutor(org.ovirt.engine.core.common.users.VdcUserTest):
> >   org.ovirt.engine.core.common.businessentities.LdapUser.setPassword(Ljava/lang/String;)V
> >   testAdUserAndTrueBooleanConstrcutor(org.ovirt.engine.core.common.users.VdcUserTest):
> >   org.ovirt.engine.core.common.businessentities.LdapUser.setPassword(Ljava/lang/String;)V
> >   getUserFQN(org.ovirt.engine.core.common.users.VdcUserTest):
> >   org.ovirt.engine.core.common.businessentities.LdapUser.setPassword(Ljava/lang/String;)V
> > 
> > http://jenkins.ovirt.org/job/ovirt_engine_dao_unit_tests/5446/console
> > 
> > looks like it started after commit :
> > http://jenkins.ovirt.org/job/ovirt_engine_dao_unit_tests/5438/
> > core: scheduling: handle cpu load duration (detail / gitweb)
> > 
> > Eyal.
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From dfediuck at redhat.com  Sun Dec 15 13:12:20 2013
From: dfediuck at redhat.com (Doron Fediuck)
Date: Sun, 15 Dec 2013 08:12:20 -0500 (EST)
Subject: [Engine-devel] Help to review the design of Feature/NUMA
	and	Virtual NUMA
In-Reply-To: <B63C858E777679458338A30A991BB5240155E248@G1W3780.americas.hpqcorp.net>
References: <B63C858E777679458338A30A991BB5240155E248@G1W3780.americas.hpqcorp.net>
Message-ID: <206088558.31446311.1387113140987.JavaMail.root@redhat.com>

Adding arch list as this may effect other sub-projects
as well.

----- Original Message -----
> From: "Chuan Liao (Jason, MCXS-CQ)" <chuan.liao at hp.com>
> To: engine-devel at ovirt.org
> Sent: Friday, December 13, 2013 9:37:59 AM
> Subject: [Engine-devel] Help to review the design of Feature/NUMA and	Virtual NUMA
> 
> 
> 
> Hi Everyone,
> 
> 
> 
> I am Jason Liao from HP, now focus on the NUMA feature integration into
> oVirt.
> 
> 
> 
> Now we finish the first step of High-level design document.
> 
> 
> 
> Please help to review the design of Features/NUMA_and_Virtual_NUMA on oVirt
> community wiki page.
> 
> 
> 
> If anyone have some question and suggestion, please let me know.
> 
> 
> 
> Thanks all.
> 
> 
> 
> Best Regards,
> Jason Liao
> 
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From yzaslavs at redhat.com  Sun Dec 15 13:29:12 2013
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Sun, 15 Dec 2013 08:29:12 -0500 (EST)
Subject: [Engine-devel] [jenkins] dao tests broken
In-Reply-To: <20739648.31439826.1387107848201.JavaMail.root@redhat.com>
References: <2045137911.4982023.1387102211598.JavaMail.root@redhat.com>
	<964579659.52022882.1387105564105.JavaMail.root@redhat.com>
	<20739648.31439826.1387107848201.JavaMail.root@redhat.com>
Message-ID: <620542342.17022681.1387114152087.JavaMail.root@redhat.com>

Worked for me perfectly on master.


----- Original Message -----
> From: "Ohad Basan" <obasan at redhat.com>
> To: "Gilad Chaplik" <gchaplik at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "infra" <infra at ovirt.org>
> Sent: Sunday, December 15, 2013 1:44:08 PM
> Subject: Re: [Engine-devel] [jenkins] dao tests broken
> 
> this job doesn't do any rebase
> where do you see it ?
> http://jenkins.ovirt.org/job/ovirt_engine_dao_unit_tests/5446/console
> I didn't find "rebase" in the console log
> 
> 
> ----- Original Message -----
> > From: "Gilad Chaplik" <gchaplik at redhat.com>
> > To: "Eyal Edri" <eedri at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>, "infra" <infra at ovirt.org>
> > Sent: Sunday, December 15, 2013 1:06:04 PM
> > Subject: Re: [Engine-devel] [jenkins] dao tests broken
> > 
> > 
> > ----- Original Message -----
> > > From: "Eyal Edri" <eedri at redhat.com>
> > > To: "engine-devel" <engine-devel at ovirt.org>
> > > Cc: "infra" <infra at ovirt.org>, "Gilad Chaplik" <gchaplik at redhat.com>
> > > Sent: Sunday, December 15, 2013 12:10:11 PM
> > > Subject: [jenkins] dao tests broken
> > > 
> > > fyi,
> > > 
> > > dao tests are broken for some time now, who can look into it?
> > > current failing tests are:
> > 
> > Hi Eyal,
> > 
> > what fails is unit tests and not dao tests (fails on dao job),
> > it looks like you're trying to rebase ovirt-engine-3.3 on top of master
> > (you
> > can see it even it the log, comparing the last success and first fail
> > jobs).
> > 
> > can you check it out?
> > 
> > Thanks,
> > Gilad.
> > 
> > > 
> > > Tests in error:
> > >   testAdUserConstrcutor(org.ovirt.engine.core.common.users.VdcUserTest):
> > >   org.ovirt.engine.core.common.businessentities.LdapUser.setPassword(Ljava/lang/String;)V
> > >   testAdUserAndFalseBooleanConstrcutor(org.ovirt.engine.core.common.users.VdcUserTest):
> > >   org.ovirt.engine.core.common.businessentities.LdapUser.setPassword(Ljava/lang/String;)V
> > >   testAdUserAndTrueBooleanConstrcutor(org.ovirt.engine.core.common.users.VdcUserTest):
> > >   org.ovirt.engine.core.common.businessentities.LdapUser.setPassword(Ljava/lang/String;)V
> > >   getUserFQN(org.ovirt.engine.core.common.users.VdcUserTest):
> > >   org.ovirt.engine.core.common.businessentities.LdapUser.setPassword(Ljava/lang/String;)V
> > > 
> > > http://jenkins.ovirt.org/job/ovirt_engine_dao_unit_tests/5446/console
> > > 
> > > looks like it started after commit :
> > > http://jenkins.ovirt.org/job/ovirt_engine_dao_unit_tests/5438/
> > > core: scheduling: handle cpu load duration (detail / gitweb)
> > > 
> > > Eyal.
> > > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From shtripat at redhat.com  Mon Dec 16 02:24:05 2013
From: shtripat at redhat.com (Shubhendu Tripathi)
Date: Sun, 15 Dec 2013 21:24:05 -0500 (EST)
Subject: [Engine-devel] [jenkins] dao tests broken
In-Reply-To: <620542342.17022681.1387114152087.JavaMail.root@redhat.com>
References: <2045137911.4982023.1387102211598.JavaMail.root@redhat.com>
	<964579659.52022882.1387105564105.JavaMail.root@redhat.com>
	<20739648.31439826.1387107848201.JavaMail.root@redhat.com>
	<620542342.17022681.1387114152087.JavaMail.root@redhat.com>
Message-ID: <572539134.95276.1387160645013.JavaMail.root@redhat.com>

The class VdcUserTest does not exist in master.
Whereas it is present in all other branches like ovirt-engine-3.3, ovirt-engine-3.3.0, ovirt-engine-3.3.1 and ovirt-engine-3.3.2.

----- Original Message -----
From: "Yair Zaslavsky" <yzaslavs at redhat.com>
To: "Ohad Basan" <obasan at redhat.com>
Cc: "engine-devel" <engine-devel at ovirt.org>, "infra" <infra at ovirt.org>
Sent: Sunday, December 15, 2013 6:59:12 PM
Subject: Re: [Engine-devel] [jenkins] dao tests broken

Worked for me perfectly on master.


----- Original Message -----
> From: "Ohad Basan" <obasan at redhat.com>
> To: "Gilad Chaplik" <gchaplik at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "infra" <infra at ovirt.org>
> Sent: Sunday, December 15, 2013 1:44:08 PM
> Subject: Re: [Engine-devel] [jenkins] dao tests broken
> 
> this job doesn't do any rebase
> where do you see it ?
> http://jenkins.ovirt.org/job/ovirt_engine_dao_unit_tests/5446/console
> I didn't find "rebase" in the console log
> 
> 
> ----- Original Message -----
> > From: "Gilad Chaplik" <gchaplik at redhat.com>
> > To: "Eyal Edri" <eedri at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>, "infra" <infra at ovirt.org>
> > Sent: Sunday, December 15, 2013 1:06:04 PM
> > Subject: Re: [Engine-devel] [jenkins] dao tests broken
> > 
> > 
> > ----- Original Message -----
> > > From: "Eyal Edri" <eedri at redhat.com>
> > > To: "engine-devel" <engine-devel at ovirt.org>
> > > Cc: "infra" <infra at ovirt.org>, "Gilad Chaplik" <gchaplik at redhat.com>
> > > Sent: Sunday, December 15, 2013 12:10:11 PM
> > > Subject: [jenkins] dao tests broken
> > > 
> > > fyi,
> > > 
> > > dao tests are broken for some time now, who can look into it?
> > > current failing tests are:
> > 
> > Hi Eyal,
> > 
> > what fails is unit tests and not dao tests (fails on dao job),
> > it looks like you're trying to rebase ovirt-engine-3.3 on top of master
> > (you
> > can see it even it the log, comparing the last success and first fail
> > jobs).
> > 
> > can you check it out?
> > 
> > Thanks,
> > Gilad.
> > 
> > > 
> > > Tests in error:
> > >   testAdUserConstrcutor(org.ovirt.engine.core.common.users.VdcUserTest):
> > >   org.ovirt.engine.core.common.businessentities.LdapUser.setPassword(Ljava/lang/String;)V
> > >   testAdUserAndFalseBooleanConstrcutor(org.ovirt.engine.core.common.users.VdcUserTest):
> > >   org.ovirt.engine.core.common.businessentities.LdapUser.setPassword(Ljava/lang/String;)V
> > >   testAdUserAndTrueBooleanConstrcutor(org.ovirt.engine.core.common.users.VdcUserTest):
> > >   org.ovirt.engine.core.common.businessentities.LdapUser.setPassword(Ljava/lang/String;)V
> > >   getUserFQN(org.ovirt.engine.core.common.users.VdcUserTest):
> > >   org.ovirt.engine.core.common.businessentities.LdapUser.setPassword(Ljava/lang/String;)V
> > > 
> > > http://jenkins.ovirt.org/job/ovirt_engine_dao_unit_tests/5446/console
> > > 
> > > looks like it started after commit :
> > > http://jenkins.ovirt.org/job/ovirt_engine_dao_unit_tests/5438/
> > > core: scheduling: handle cpu load duration (detail / gitweb)
> > > 
> > > Eyal.
> > > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
_______________________________________________
Engine-devel mailing list
Engine-devel at ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel


From obasan at redhat.com  Mon Dec 16 08:32:03 2013
From: obasan at redhat.com (Ohad Basan)
Date: Mon, 16 Dec 2013 03:32:03 -0500 (EST)
Subject: [Engine-devel] [jenkins] dao tests broken
In-Reply-To: <572539134.95276.1387160645013.JavaMail.root@redhat.com>
References: <2045137911.4982023.1387102211598.JavaMail.root@redhat.com>
	<964579659.52022882.1387105564105.JavaMail.root@redhat.com>
	<20739648.31439826.1387107848201.JavaMail.root@redhat.com>
	<620542342.17022681.1387114152087.JavaMail.root@redhat.com>
	<572539134.95276.1387160645013.JavaMail.root@redhat.com>
Message-ID: <159919251.31649412.1387182723604.JavaMail.root@redhat.com>

I splitted the job to two separate jobs
one for 3.3 and one for master.
so far it seems to be working


----- Original Message -----
> From: "Shubhendu Tripathi" <shtripat at redhat.com>
> To: "Yair Zaslavsky" <yzaslavs at redhat.com>
> Cc: "Ohad Basan" <obasan at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, "infra" <infra at ovirt.org>
> Sent: Monday, December 16, 2013 4:24:05 AM
> Subject: Re: [Engine-devel] [jenkins] dao tests broken
> 
> The class VdcUserTest does not exist in master.
> Whereas it is present in all other branches like ovirt-engine-3.3,
> ovirt-engine-3.3.0, ovirt-engine-3.3.1 and ovirt-engine-3.3.2.
> 
> ----- Original Message -----
> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> To: "Ohad Basan" <obasan at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "infra" <infra at ovirt.org>
> Sent: Sunday, December 15, 2013 6:59:12 PM
> Subject: Re: [Engine-devel] [jenkins] dao tests broken
> 
> Worked for me perfectly on master.
> 
> 
> ----- Original Message -----
> > From: "Ohad Basan" <obasan at redhat.com>
> > To: "Gilad Chaplik" <gchaplik at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>, "infra" <infra at ovirt.org>
> > Sent: Sunday, December 15, 2013 1:44:08 PM
> > Subject: Re: [Engine-devel] [jenkins] dao tests broken
> > 
> > this job doesn't do any rebase
> > where do you see it ?
> > http://jenkins.ovirt.org/job/ovirt_engine_dao_unit_tests/5446/console
> > I didn't find "rebase" in the console log
> > 
> > 
> > ----- Original Message -----
> > > From: "Gilad Chaplik" <gchaplik at redhat.com>
> > > To: "Eyal Edri" <eedri at redhat.com>
> > > Cc: "engine-devel" <engine-devel at ovirt.org>, "infra" <infra at ovirt.org>
> > > Sent: Sunday, December 15, 2013 1:06:04 PM
> > > Subject: Re: [Engine-devel] [jenkins] dao tests broken
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Eyal Edri" <eedri at redhat.com>
> > > > To: "engine-devel" <engine-devel at ovirt.org>
> > > > Cc: "infra" <infra at ovirt.org>, "Gilad Chaplik" <gchaplik at redhat.com>
> > > > Sent: Sunday, December 15, 2013 12:10:11 PM
> > > > Subject: [jenkins] dao tests broken
> > > > 
> > > > fyi,
> > > > 
> > > > dao tests are broken for some time now, who can look into it?
> > > > current failing tests are:
> > > 
> > > Hi Eyal,
> > > 
> > > what fails is unit tests and not dao tests (fails on dao job),
> > > it looks like you're trying to rebase ovirt-engine-3.3 on top of master
> > > (you
> > > can see it even it the log, comparing the last success and first fail
> > > jobs).
> > > 
> > > can you check it out?
> > > 
> > > Thanks,
> > > Gilad.
> > > 
> > > > 
> > > > Tests in error:
> > > >   testAdUserConstrcutor(org.ovirt.engine.core.common.users.VdcUserTest):
> > > >   org.ovirt.engine.core.common.businessentities.LdapUser.setPassword(Ljava/lang/String;)V
> > > >   testAdUserAndFalseBooleanConstrcutor(org.ovirt.engine.core.common.users.VdcUserTest):
> > > >   org.ovirt.engine.core.common.businessentities.LdapUser.setPassword(Ljava/lang/String;)V
> > > >   testAdUserAndTrueBooleanConstrcutor(org.ovirt.engine.core.common.users.VdcUserTest):
> > > >   org.ovirt.engine.core.common.businessentities.LdapUser.setPassword(Ljava/lang/String;)V
> > > >   getUserFQN(org.ovirt.engine.core.common.users.VdcUserTest):
> > > >   org.ovirt.engine.core.common.businessentities.LdapUser.setPassword(Ljava/lang/String;)V
> > > > 
> > > > http://jenkins.ovirt.org/job/ovirt_engine_dao_unit_tests/5446/console
> > > > 
> > > > looks like it started after commit :
> > > > http://jenkins.ovirt.org/job/ovirt_engine_dao_unit_tests/5438/
> > > > core: scheduling: handle cpu load duration (detail / gitweb)
> > > > 
> > > > Eyal.
> > > > 
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From iheim at redhat.com  Mon Dec 16 07:38:58 2013
From: iheim at redhat.com (Itamar Heim)
Date: Mon, 16 Dec 2013 09:38:58 +0200
Subject: [Engine-devel] [engine-devel] instance type as top-level entity
In-Reply-To: <308092418.2259849.1386229201991.JavaMail.root@redhat.com>
References: <220898566.1749726.1386159246739.JavaMail.root@redhat.com>
	<711610057.23141349.1386159472456.JavaMail.root@redhat.com>
	<529F5885.9020103@redhat.com>
	<308092418.2259849.1386229201991.JavaMail.root@redhat.com>
Message-ID: <52AEAE12.5050406@redhat.com>

On 12/05/2013 09:40 AM, Tomas Jelinek wrote:
>
>
> ----- Original Message -----
>> From: "Itamar Heim" <iheim at redhat.com>
>> To: "Omer Frenkel" <ofrenkel at redhat.com>, "Tomas Jelinek" <tjelinek at redhat.com>
>> Cc: "engine-devel" <engine-devel at ovirt.org>
>> Sent: Wednesday, December 4, 2013 5:29:57 PM
>> Subject: Re: [Engine-devel] [engine-devel] instance type as top-level entity
>>
>> On 12/04/2013 02:17 PM, Omer Frenkel wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Tomas Jelinek" <tjelinek at redhat.com>
>>>> To: "engine-devel" <engine-devel at ovirt.org>
>>>> Cc: "Omer Frenkel" <ofrenkel at redhat.com>
>>>> Sent: Wednesday, December 4, 2013 2:14:06 PM
>>>> Subject: [engine-devel] instance type as top-level entity
>>>>
>>>> Hey all,
>>>>
>>>> I have started to work on the instance types[1] again and hit an issue.
>>>> Since
>>>> the instance types are supposed to be top-level entities
>>>> (e.g. without the connection to DC/Cluster) but they are modeled as
>>>> templates
>>>> it is not possible to store them to DB since the DB constraints violation
>>>> on
>>>> vm_static table
>>>> (e.g. the vds_group_id has to be unique and point to an existing
>>>> vds_group).
>>>>
>>>> So, I see 4 options:
>>>>
>>>> 1: drop the constraints on the vm_static.vds_group_id (the
>>>> vds_groups_vm_static constraint)
>>>>      (most simple approach but would open the door to some issues which are
>>>>      now
>>>>      guard on the DB level)
>>>>
>>>> 2: do the same magic [well, hacks :) ] as with the "blank" template which
>>>> is
>>>> in the same situation
>>>>      (not exactly a nice solution to have the instance types wired to one
>>>>      specific cluster just to satisfy the constraint but return them all
>>>>      the
>>>>      time)
>>>>
>>>> 3: do not store this data in vm_static but create some new table called
>>>> e.g.
>>>> instance_type which would contain all of the fields from vm_static which
>>>> are
>>>> needed by it
>>>>      (actually the best approach AFAIK but to do it correctly it would
>>>>      require
>>>>      some more refactoring to do some hierarchy of tables and not copy the
>>>>      fields from table to table)
>>>>
>>>> 4: make the instance types not top-level (e.g. bound to specific
>>>> DC/Cluster)
>>>>      (would bring some issues for example with the default instance types
>>>>      which
>>>>      should be present for all the DC/Clusters)
>>>>
>>>> Thoughts?
>>>>
>>>> Thank you,
>>>> Tomas
>>>>
>>>> [1]: http://www.ovirt.org/Features/Instance_Types
>>>>
>>>
>>> according to the wiki (and discussions we had) instance type is bounded to
>>> a cluster (even if only as a changeable default)
>>> so i dont think there is an issue..
>>
>> where in the wiki please?
>> the way i read the wiki its DC level, just like templates?
>
> OK, it seems I have not asked the question correctly. Let me rephrase it:
> Since we are going to provide default (predefined) instance types which the user is not allowed to delete I assume this instance types should
> be available for the whole system (not only for the default cluster) just like blank template.

I think it makes sense to allow instance type (both default and custom 
ones) at system level. would be nice to allow them at cluster level as 
well of course.

>
> This brings up a question if all the other instance types are going to be also system level and if yes, how are we going to solve it technically.
> We still have the option to implement the instance types as templates and the default instance types as blank template, but the question is if this is
> what makes most sense.

if anything, i think everyone would appreciate if we remove the relation 
of Blank template to the default cluster so they can delete the default 
cluster...

>
> The wiki currently says that the instance type is connected to cluster using vds_group_id field but as I have started some implementation this
> question popped up in my mind (not yet documented on wiki - will be according to the result of this discussion).

it does say so, but i think you are right and we should allow system 
level as well. cc-ing andrew who authored this page for his thoughts?

>
> BTW the question if the instance types are top level or not leads us to a different question - where to put them in GUI?
> - If the instance type is a top level entity the best place to have it is the configure dialog (top right corner)
> - If the instance type is not a top level entity the best place to have it is possibly a main tab (or part of the template main tab)

well, the question is should we allow only system level (then configure 
is appropriate), or both system and cluster level, in which case a sub 
tab is more appropriate.

i could live with:
- only allow to configure instance types via configure (since its a
   rare operation, like configuring a role is).
- allow to set default enable/disable for an instance type.
- allow to set enable/disable override at cluster level, in which case,
    a subtab or a dialog at cluster level would do.

as a side note, i think 'configure' dialogs should be moved from the 
configure button to a new tree node, and appear as tab panes when 
standing on this new configure node in the tree.
>
>
>>
>>



From mpastern at redhat.com  Mon Dec 16 15:34:36 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Mon, 16 Dec 2013 17:34:36 +0200
Subject: [Engine-devel] Proposal to add Juan Hernandez as maintainer to
	api/sdk/cli
Message-ID: <52AF1D8C.5010208@redhat.com>


Juan has worked on oVirt for a long period of time, developing
several features in the different areas (including api and cli),
and obviously gained a lot of experience and knowledge,

I'd like to propose Juan as a maintainer of the  api/sdk/cli projects.

-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From sbonazzo at redhat.com  Mon Dec 16 15:39:55 2013
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Mon, 16 Dec 2013 16:39:55 +0100
Subject: [Engine-devel] oVirt 3.3.2 RC
Message-ID: <52AF1ECB.5000405@redhat.com>

The oVirt team is pleased to announce that the 3.3.2 Release Candidate is now
available in ovirt-updates-testing [1].

We planned to release it on Wed Dec 18th 2013 but it will probably be postponed
to next week for allowing more testing on the RC.
The release date will be decided in next oVrit sync meeting on Wed Dec 18th.
Feel free to join us testing it[2] and verifying the bugzilla entries actually
under verification [3].

Release notes for this update are available on the wiki [4].

A new oVirt Node build will be available soon as well.

[1] http://resources.ovirt.org/releases/updates-testing
[2] http://www.ovirt.org/Testing/Ovirt_3.3.2_testing
[3] http://red.ht/19NoJKf
[4] http://www.ovirt.org/OVirt_3.3.2_release_notes

-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com


From sbonazzo at redhat.com  Mon Dec 16 15:40:29 2013
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Mon, 16 Dec 2013 16:40:29 +0100
Subject: [Engine-devel] Proposal to add Juan Hernandez as maintainer to
 api/sdk/cli
In-Reply-To: <52AF1D8C.5010208@redhat.com>
References: <52AF1D8C.5010208@redhat.com>
Message-ID: <52AF1EED.9090106@redhat.com>

Il 16/12/2013 16:34, Michael Pasternak ha scritto:
> 
> Juan has worked on oVirt for a long period of time, developing
> several features in the different areas (including api and cli),
> and obviously gained a lot of experience and knowledge,
> 
> I'd like to propose Juan as a maintainer of the  api/sdk/cli projects.
> 

+1


-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com


From ovedo at redhat.com  Mon Dec 16 15:50:44 2013
From: ovedo at redhat.com (Oved Ourfalli)
Date: Mon, 16 Dec 2013 10:50:44 -0500 (EST)
Subject: [Engine-devel] Proposal to add Juan Hernandez as maintainer
	to	api/sdk/cli
In-Reply-To: <52AF1EED.9090106@redhat.com>
References: <52AF1D8C.5010208@redhat.com> <52AF1EED.9090106@redhat.com>
Message-ID: <1960323021.42603743.1387209044346.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
> To: "Michael Pasternak" <mpastern at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, "infra" <infra at ovirt.org>
> Sent: Monday, December 16, 2013 5:40:29 PM
> Subject: Re: [Engine-devel] Proposal to add Juan Hernandez as maintainer to	api/sdk/cli
> 
> Il 16/12/2013 16:34, Michael Pasternak ha scritto:
> > 
> > Juan has worked on oVirt for a long period of time, developing
> > several features in the different areas (including api and cli),
> > and obviously gained a lot of experience and knowledge,
> > 
> > I'd like to propose Juan as a maintainer of the  api/sdk/cli projects.
> > 
> 
> +1
> 
+1!
Well deserved!

> 
> --
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com
> _______________________________________________
> Infra mailing list
> Infra at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
> 


From masayag at redhat.com  Mon Dec 16 17:29:13 2013
From: masayag at redhat.com (Moti Asayag)
Date: Mon, 16 Dec 2013 12:29:13 -0500 (EST)
Subject: [Engine-devel] Proposal to add Juan Hernandez as maintainer to
	api/sdk/cli
In-Reply-To: <52AF1D8C.5010208@redhat.com>
References: <52AF1D8C.5010208@redhat.com>
Message-ID: <844647805.5717198.1387214953976.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Michael Pasternak" <mpastern at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>, "infra" <infra at ovirt.org>
> Sent: Monday, December 16, 2013 5:34:36 PM
> Subject: Proposal to add Juan Hernandez as maintainer to api/sdk/cli
> 
> 
> Juan has worked on oVirt for a long period of time, developing
> several features in the different areas (including api and cli),
> and obviously gained a lot of experience and knowledge,
> 
> I'd like to propose Juan as a maintainer of the  api/sdk/cli projects.
> 

+1

> --
> 
> Michael Pasternak
> RedHat, ENG-Virtualization R&D
> _______________________________________________
> Infra mailing list
> Infra at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
> 


From S.Kieske at mittwald.de  Tue Dec 17 08:08:11 2013
From: S.Kieske at mittwald.de (Sven Kieske)
Date: Tue, 17 Dec 2013 08:08:11 +0000
Subject: [Engine-devel] Polling vs Pushing engine events
Message-ID: <52B00708.5000405@mittwald.de>

Hi,

we got the following problem:

we create / start / stop
hole vms /data centers / storage etc
(basically: everything ovirt can handle
via REST-API)

But if you want to know e.g. the status
of a vm (or anything) you need to constantly
poll the API.

This is not what we desire to do, as it
does not scale very well (e.g. polling
100 vms).

Is there a standardized way of pushing information
from the engine?


-- 
Mit freundlichen Gr??en / Regards

Sven Kieske

Systemadministrator
Mittwald CM Service GmbH & Co. KG
K?nigsberger Stra?e 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
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

From iheim at redhat.com  Tue Dec 17 08:18:12 2013
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 17 Dec 2013 03:18:12 -0500
Subject: [Engine-devel] Polling vs Pushing engine events
In-Reply-To: <52B00708.5000405@mittwald.de>
References: <52B00708.5000405@mittwald.de>
Message-ID: <52B008C4.2060807@redhat.com>

On 12/17/2013 03:08 AM, Sven Kieske wrote:
> Hi,
>
> we got the following problem:
>
> we create / start / stop
> hole vms /data centers / storage etc
> (basically: everything ovirt can handle
> via REST-API)
>
> But if you want to know e.g. the status
> of a vm (or anything) you need to constantly
> poll the API.
>
> This is not what we desire to do, as it
> does not scale very well (e.g. polling
> 100 vms).

well, you can search events since last event you searched for, only for 
the specific type of event you are interested in, then check which vm 
its for.

>
> Is there a standardized way of pushing information
> from the engine?
>
>

well, the notification service which sends emails on these actually 
polls for them every minute in order to send the emails.

we are discussing snmptraps here[1]
one of the options this could be implemented with is via log4j getting 
all the audit log events, then you could use any log4j appender (db 
table, jms queue, etc.)

[1] Bug 1032661 - Add SNMP trap as notification method to to 
ovirt-engine-notification


From liran.zelkha at gmail.com  Tue Dec 17 08:24:45 2013
From: liran.zelkha at gmail.com (Liran Zelkha)
Date: Tue, 17 Dec 2013 10:24:45 +0200
Subject: [Engine-devel] Polling vs Pushing engine events
In-Reply-To: <52B008C4.2060807@redhat.com>
References: <52B00708.5000405@mittwald.de>
	<52B008C4.2060807@redhat.com>
Message-ID: <CAJ3aYLfOpu2eEhhaTfFL-b7rGdmb9qbSj6Y2056AttMShsKpOA@mail.gmail.com>

Note that you can usually get all the information you want using 1 API
call, which should still scale.
For instance, /ovirt-engine/api/vms will give you a list of all VMs and
their statuses, so you can just run an XPath and get the status of all of
them.


On Tue, Dec 17, 2013 at 10:18 AM, Itamar Heim <iheim at redhat.com> wrote:

> On 12/17/2013 03:08 AM, Sven Kieske wrote:
>
>> Hi,
>>
>> we got the following problem:
>>
>> we create / start / stop
>> hole vms /data centers / storage etc
>> (basically: everything ovirt can handle
>> via REST-API)
>>
>> But if you want to know e.g. the status
>> of a vm (or anything) you need to constantly
>> poll the API.
>>
>> This is not what we desire to do, as it
>> does not scale very well (e.g. polling
>> 100 vms).
>>
>
> well, you can search events since last event you searched for, only for
> the specific type of event you are interested in, then check which vm its
> for.
>
>
>> Is there a standardized way of pushing information
>> from the engine?
>>
>>
>>
> well, the notification service which sends emails on these actually polls
> for them every minute in order to send the emails.
>
> we are discussing snmptraps here[1]
> one of the options this could be implemented with is via log4j getting all
> the audit log events, then you could use any log4j appender (db table, jms
> queue, etc.)
>
> [1] Bug 1032661 - Add SNMP trap as notification method to to
> ovirt-engine-notification
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20131217/7d640233/attachment.html>

From emesika at redhat.com  Tue Dec 17 08:39:18 2013
From: emesika at redhat.com (Eli Mesika)
Date: Tue, 17 Dec 2013 03:39:18 -0500 (EST)
Subject: [Engine-devel] Proposal to add Juan Hernandez as maintainer
	to	api/sdk/cli
In-Reply-To: <52AF1D8C.5010208@redhat.com>
References: <52AF1D8C.5010208@redhat.com>
Message-ID: <1750519339.40721907.1387269558580.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Michael Pasternak" <mpastern at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>, "infra" <infra at ovirt.org>
> Sent: Monday, December 16, 2013 5:34:36 PM
> Subject: [Engine-devel] Proposal to add Juan Hernandez as maintainer to	api/sdk/cli
> 
> 
> Juan has worked on oVirt for a long period of time, developing
> several features in the different areas (including api and cli),
> and obviously gained a lot of experience and knowledge,
> 
> I'd like to propose Juan as a maintainer of the  api/sdk/cli projects.

+1
well deserved 

> 
> --
> 
> Michael Pasternak
> RedHat, ENG-Virtualization R&D
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From ofrenkel at redhat.com  Tue Dec 17 09:04:00 2013
From: ofrenkel at redhat.com (Omer Frenkel)
Date: Tue, 17 Dec 2013 04:04:00 -0500 (EST)
Subject: [Engine-devel] Proposal to add Juan Hernandez as maintainer to
	api/sdk/cli
In-Reply-To: <52AF1D8C.5010208@redhat.com>
References: <52AF1D8C.5010208@redhat.com>
Message-ID: <17654411.32639600.1387271040303.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Michael Pasternak" <mpastern at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>, "infra" <infra at ovirt.org>
> Sent: Monday, December 16, 2013 5:34:36 PM
> Subject: Proposal to add Juan Hernandez as maintainer to api/sdk/cli
> 
> 
> Juan has worked on oVirt for a long period of time, developing
> several features in the different areas (including api and cli),
> and obviously gained a lot of experience and knowledge,
> 
> I'd like to propose Juan as a maintainer of the  api/sdk/cli projects.
> 

+1 

> --
> 
> Michael Pasternak
> RedHat, ENG-Virtualization R&D
> _______________________________________________
> Infra mailing list
> Infra at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
> 


From S.Kieske at mittwald.de  Tue Dec 17 10:47:32 2013
From: S.Kieske at mittwald.de (Sven Kieske)
Date: Tue, 17 Dec 2013 10:47:32 +0000
Subject: [Engine-devel] Polling vs Pushing engine events
In-Reply-To: <CAJ3aYLfOpu2eEhhaTfFL-b7rGdmb9qbSj6Y2056AttMShsKpOA@mail.gmail.com>
References: <52B00708.5000405@mittwald.de>
	<CAJ3aYLfOpu2eEhhaTfFL-b7rGdmb9qbSj6Y2056AttMShsKpOA@mail.gmail.com>
Message-ID: <52B02C61.9000004@mittwald.de>

Hi,

thanks for your fast replies.

We are aware that we can poll this via API, but we don't want to poll
it, as it's not a good solution, from a design point of view.

We will maybe write a little python script, which runs on engine-node
via SDK which polls the API and let this script push the information
forward to external systems over network when a certain event occurs.

Something similar to this in oVirt would be useful.
You don't want to poll every second, or more often, for simple
events like "is the vm already up?".

This just creates unnecessary network traffic and load on the polling
system.

With this solution we can at least avoid the network traffic.

This is, why I asked for a pushing logic.

Maybe it's now more clear?

But thanks again for your help :-)

Am 17.12.2013 09:24, schrieb Liran Zelkha:
> Note that you can usually get all the information you want using 1 API
> call, which should still scale.
> For instance, /ovirt-engine/api/vms will give you a list of all VMs and
> their statuses, so you can just run an XPath and get the status of all of
> them.

-- 
Mit freundlichen Gr??en / Regards

Sven Kieske

Systemadministrator
Mittwald CM Service GmbH & Co. KG
K?nigsberger Stra?e 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
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

From yzaslavs at redhat.com  Tue Dec 17 11:18:40 2013
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Tue, 17 Dec 2013 06:18:40 -0500 (EST)
Subject: [Engine-devel] Proposal to add Juan Hernandez as maintainer to
	api/sdk/cli
In-Reply-To: <17654411.32639600.1387271040303.JavaMail.root@redhat.com>
References: <52AF1D8C.5010208@redhat.com>
	<17654411.32639600.1387271040303.JavaMail.root@redhat.com>
Message-ID: <966808741.18578863.1387279120089.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Omer Frenkel" <ofrenkel at redhat.com>
> To: "Michael Pasternak" <mpastern at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "infra" <infra at ovirt.org>
> Sent: Tuesday, December 17, 2013 11:04:00 AM
> Subject: Re: Proposal to add Juan Hernandez as maintainer to api/sdk/cli
> 
> 
> 
> ----- Original Message -----
> > From: "Michael Pasternak" <mpastern at redhat.com>
> > To: "engine-devel" <engine-devel at ovirt.org>, "infra" <infra at ovirt.org>
> > Sent: Monday, December 16, 2013 5:34:36 PM
> > Subject: Proposal to add Juan Hernandez as maintainer to api/sdk/cli
> > 
> > 
> > Juan has worked on oVirt for a long period of time, developing
> > several features in the different areas (including api and cli),
> > and obviously gained a lot of experience and knowledge,
> > 
> > I'd like to propose Juan as a maintainer of the  api/sdk/cli projects.
> > 
> 

+1

> 
> > --
> > 
> > Michael Pasternak
> > RedHat, ENG-Virtualization R&D
> > _______________________________________________
> > Infra mailing list
> > Infra at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/infra
> > 
> _______________________________________________
> Infra mailing list
> Infra at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
> 


From ydary at redhat.com  Tue Dec 17 11:33:28 2013
From: ydary at redhat.com (Yaniv Dary)
Date: Tue, 17 Dec 2013 06:33:28 -0500 (EST)
Subject: [Engine-devel] Polling vs Pushing engine events
In-Reply-To: <52B00708.5000405@mittwald.de>
References: <52B00708.5000405@mittwald.de>
Message-ID: <42452724.52940035.1387280008885.JavaMail.root@redhat.com>

You can use the DWH API to check these things.
The status is sampled and stored for most entities every 1 minute by default (and can be set to less than that). 



Yaniv

----- Original Message -----
> From: "Sven Kieske" <S.Kieske at mittwald.de>
> To: users at ovirt.org, engine-devel at ovirt.org
> Sent: Tuesday, December 17, 2013 10:08:11 AM
> Subject: [Engine-devel] Polling vs Pushing engine events
> 
> Hi,
> 
> we got the following problem:
> 
> we create / start / stop
> hole vms /data centers / storage etc
> (basically: everything ovirt can handle
> via REST-API)
> 
> But if you want to know e.g. the status
> of a vm (or anything) you need to constantly
> poll the API.
> 
> This is not what we desire to do, as it
> does not scale very well (e.g. polling
> 100 vms).
> 
> Is there a standardized way of pushing information
> from the engine?
> 
> 
> --
> Mit freundlichen Gr??en / Regards
> 
> Sven Kieske
> 
> Systemadministrator
> Mittwald CM Service GmbH & Co. KG
> K?nigsberger Stra?e 6
> 32339 Espelkamp
> T: +49-5772-293-100
> F: +49-5772-293-333
> 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
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>


From lvernia at redhat.com  Tue Dec 17 12:20:18 2013
From: lvernia at redhat.com (Lior Vernia)
Date: Tue, 17 Dec 2013 14:20:18 +0200
Subject: [Engine-devel] GUI widget for adding/removing entries
In-Reply-To: <1080405201.5269235.1381413666292.JavaMail.root@redhat.com>
References: <52551515.2090503@redhat.com>
	<1787139028.4279384.1381317863699.JavaMail.root@redhat.com>
	<52554CC9.5020806@redhat.com> <5255CBD2.7090606@redhat.com>
	<52565E6F.2060509@redhat.com> <52565113.9010103@redhat.com>
	<525668FF.3020102@redhat.com>
	<1080405201.5269235.1381413666292.JavaMail.root@redhat.com>
Message-ID: <52B04182.1080504@redhat.com>

Last patches were recently merged to the master branch; many thanks to
Tomas, Vojtech and Gilad for taking the time to review them (weren't
easy to review).

The following widgets now all use the same underlying widget:
* VM interfaces in add/edit VM dialog.
* Profiles in add/edit network dialog.
* Device custom properties in add/edit vNIC profile dialog.
* Custom properties in add/edit VM dialog.
* Custom properties in add/edit cluster dialog.
* Custom properties in add/edit cluster policy dialog.
* Custom properties in VM run once dialog.

I did my best to avoid regressions, but please let me know if any of
these seem to malfunction all of a sudden.

Yours, Lior.

On 10/10/13 16:01, Einav Cohen wrote:
> see attached: AFAIK, there are three types of adding-and-removing widget in the application:
> 
> (1) the one that exists in the customs properties section as well as the cluster policy.
> in this widget:
> - the "+" and "-" buttons appear on every row.
> - row is "identified" by a selected item from a drop down.
> - input controls in row: drop-down and text box (that appears upon selection of a non-empty value in the drop-down)
> 
> (2) the one that exists in the vNICs assignment part of the General section in the New VM dialog.
> in this widget:
> - the "+" appears only in the last row, "-" appears in all lines but the last row.
> - row is "identified" by (what seems to be a) read-only label (I assume that this widget is 
> built to be initially loaded to already contain a number of rows, as opposed to (1), which 
> typically starts with no rows / initial "empty" row.
> - input controls in row: drop-down
> 
> (3) the one that exists in the vNIC profiles section in the Add/Edit Network dialog
> in this widget:
> - the "+" and "-" buttons appear on every row.
> - row is "identified" by a free-text string.
> - input controls in row: text-box, check-box and drop-down.
> 
> so there are differences between the widgets other than the "+" and "-" buttons.
> however, from ux perspective, it is important to keep the look-and-feel of all of them consistent.
> 
> technically (code-wise), I am not sure how easy it is to merge the three, due to the differences.
> we can maybe think of creating a general adding-and-removing-entries widget, which can support 
> "ordered" and "non-ordered" flavors (which will affect the "+"/"-" buttons appearance / exact 
> behavior), and it will contain a collection of "abstract" row-widgets (and we will have several 
> implementations of row-widgets for each needed functionality [(1), (2), (3)] with exact appearance / 
> input controls / behavior/etc.), which may need to support a certain api (e.g. isRowEmpty(), get/set
> Identifier(), etc.) in order to communicate appropriately with its "parent" adding-and-removing-entries 
> widget.
> 
> thoughts?
> 
> ----- Original Message -----
>> From: "Lior Vernia" <lvernia at redhat.com>
>> To: "Itamar Heim" <iheim at redhat.com>
>> Cc: "engine-devel" <engine-devel at ovirt.org>
>> Sent: Thursday, October 10, 2013 4:44:47 AM
>> Subject: Re: [Engine-devel] GUI widget for adding/removing entries
>>
>> To my knowledge, such a widget existed only in two other places: custom
>> properties and vNIC profiles in add/edit network dialog. In both of them
>> the order wasn't important, in which case the new widget is probably
>> preferable. If it is indeed preferable (Einav? Malini?), I could do some
>> refactoring to have both of them use it.
>>
>> On 10/10/13 09:02, Itamar Heim wrote:
>>> On 10/10/2013 10:59 AM, Lior Vernia wrote:
>>>>
>>>>
>>>> On 09/10/13 23:34, Itamar Heim wrote:
>>>>> On 10/09/2013 03:32 PM, Lior Vernia wrote:
>>>>>> Of course, my bad. Attached is a screenshot of the add/edit VM dialog,
>>>>>> note the vNIC part on the bottom half of the dialog.
>>>>>
>>>>> how is it different from the custom properties one?
>>>>>
>>>>
>>>> Design-wise, there are a couple of small differences. There's only one
>>>> button next to each row, plus if it's the last row or minus otherwise
>>>> (so items can only be added at the end, as I replied to Malini order
>>>> hasn't been important so far). A row appears as disabled until it is
>>>> edited, and a disabled row is ignored when the view is flushed back to
>>>> the model (e.g. when the user presses OK in the dialog).
>>>>
>>>> Code-wise, it's constructed to be reusable, which the custom properties
>>>> widget wasn't :)
>>>
>>> could we converge on one of them though?
>>>
>>>>
>>>>>>
>>>>>> On 09/10/13 13:24, Einav Cohen wrote:
>>>>>>> Hi Lior - can you please provide a screen-shot, so we will know which
>>>>>>> widget
>>>>>>> you are referring to?
>>>>>>> will make it easier for people to decide if and where to use this
>>>>>>> widget.
>>>>>>>
>>>>>>> Many thanks!
>>>>>>>
>>>>>>> ----
>>>>>>> Regards,
>>>>>>> Einav
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Lior Vernia" <lvernia at redhat.com>
>>>>>>>> To: "engine-devel" <engine-devel at ovirt.org>
>>>>>>>> Sent: Wednesday, October 9, 2013 4:34:29 AM
>>>>>>>> Subject: [Engine-devel] GUI widget for adding/removing entries
>>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Lately a patch has been merged that introduces a widget for
>>>>>>>> adding/removing entries (e.g. network interfaces when
>>>>>>>> creating/editing a
>>>>>>>> VM):
>>>>>>>>
>>>>>>>> http://gerrit.ovirt.org/#/c/19530/
>>>>>>>>
>>>>>>>> This kind of widgets is becoming common in oVirt, so the idea is to
>>>>>>>> make
>>>>>>>> adding one easy rather than copying & pasting code.
>>>>>>>> AddRemoveRowWidget
>>>>>>>> takes care of the plus/minus button logic, disabling an entry that
>>>>>>>> hasn't been edited, and the arranging in rows.
>>>>>>>>
>>>>>>>> In order to use it, one is required to override a couple of abstract
>>>>>>>> methods that are dependent upon the specific entry implementation. An
>>>>>>>> example may be found in ProfilesInstanceTypeEditor, which handles
>>>>>>>> adding/removing network interfaces in the new/edit VM dialog.
>>>>>>>>
>>>>>>>> Yours, Lior.
>>>>>>>> _______________________________________________
>>>>>>>> Engine-devel mailing list
>>>>>>>> Engine-devel at ovirt.org
>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Engine-devel mailing list
>>>>>>>> Engine-devel at ovirt.org
>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>
>>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
>>


From ecohen at redhat.com  Tue Dec 17 12:46:43 2013
From: ecohen at redhat.com (Einav Cohen)
Date: Tue, 17 Dec 2013 07:46:43 -0500 (EST)
Subject: [Engine-devel] GUI widget for adding/removing entries
In-Reply-To: <52B04182.1080504@redhat.com>
References: <52551515.2090503@redhat.com> <52554CC9.5020806@redhat.com>
	<5255CBD2.7090606@redhat.com> <52565E6F.2060509@redhat.com>
	<52565113.9010103@redhat.com> <525668FF.3020102@redhat.com>
	<1080405201.5269235.1381413666292.JavaMail.root@redhat.com>
	<52B04182.1080504@redhat.com>
Message-ID: <1510056535.32739916.1387284403425.JavaMail.root@redhat.com>

Thank you Lior (and reviewers) for your efforts - they are highly appreciated!

----
Regards,
Einav

----- Original Message -----
> From: "Lior Vernia" <lvernia at redhat.com>
> To: "Einav Cohen" <ecohen at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Tuesday, December 17, 2013 7:20:18 AM
> Subject: Re: [Engine-devel] GUI widget for adding/removing entries
> 
> Last patches were recently merged to the master branch; many thanks to
> Tomas, Vojtech and Gilad for taking the time to review them (weren't
> easy to review).
> 
> The following widgets now all use the same underlying widget:
> * VM interfaces in add/edit VM dialog.
> * Profiles in add/edit network dialog.
> * Device custom properties in add/edit vNIC profile dialog.
> * Custom properties in add/edit VM dialog.
> * Custom properties in add/edit cluster dialog.
> * Custom properties in add/edit cluster policy dialog.
> * Custom properties in VM run once dialog.
> 
> I did my best to avoid regressions, but please let me know if any of
> these seem to malfunction all of a sudden.
> 
> Yours, Lior.
> 
> On 10/10/13 16:01, Einav Cohen wrote:
> > see attached: AFAIK, there are three types of adding-and-removing widget in
> > the application:
> > 
> > (1) the one that exists in the customs properties section as well as the
> > cluster policy.
> > in this widget:
> > - the "+" and "-" buttons appear on every row.
> > - row is "identified" by a selected item from a drop down.
> > - input controls in row: drop-down and text box (that appears upon
> > selection of a non-empty value in the drop-down)
> > 
> > (2) the one that exists in the vNICs assignment part of the General section
> > in the New VM dialog.
> > in this widget:
> > - the "+" appears only in the last row, "-" appears in all lines but the
> > last row.
> > - row is "identified" by (what seems to be a) read-only label (I assume
> > that this widget is
> > built to be initially loaded to already contain a number of rows, as
> > opposed to (1), which
> > typically starts with no rows / initial "empty" row.
> > - input controls in row: drop-down
> > 
> > (3) the one that exists in the vNIC profiles section in the Add/Edit
> > Network dialog
> > in this widget:
> > - the "+" and "-" buttons appear on every row.
> > - row is "identified" by a free-text string.
> > - input controls in row: text-box, check-box and drop-down.
> > 
> > so there are differences between the widgets other than the "+" and "-"
> > buttons.
> > however, from ux perspective, it is important to keep the look-and-feel of
> > all of them consistent.
> > 
> > technically (code-wise), I am not sure how easy it is to merge the three,
> > due to the differences.
> > we can maybe think of creating a general adding-and-removing-entries
> > widget, which can support
> > "ordered" and "non-ordered" flavors (which will affect the "+"/"-" buttons
> > appearance / exact
> > behavior), and it will contain a collection of "abstract" row-widgets (and
> > we will have several
> > implementations of row-widgets for each needed functionality [(1), (2),
> > (3)] with exact appearance /
> > input controls / behavior/etc.), which may need to support a certain api
> > (e.g. isRowEmpty(), get/set
> > Identifier(), etc.) in order to communicate appropriately with its "parent"
> > adding-and-removing-entries
> > widget.
> > 
> > thoughts?
> > 
> > ----- Original Message -----
> >> From: "Lior Vernia" <lvernia at redhat.com>
> >> To: "Itamar Heim" <iheim at redhat.com>
> >> Cc: "engine-devel" <engine-devel at ovirt.org>
> >> Sent: Thursday, October 10, 2013 4:44:47 AM
> >> Subject: Re: [Engine-devel] GUI widget for adding/removing entries
> >>
> >> To my knowledge, such a widget existed only in two other places: custom
> >> properties and vNIC profiles in add/edit network dialog. In both of them
> >> the order wasn't important, in which case the new widget is probably
> >> preferable. If it is indeed preferable (Einav? Malini?), I could do some
> >> refactoring to have both of them use it.
> >>
> >> On 10/10/13 09:02, Itamar Heim wrote:
> >>> On 10/10/2013 10:59 AM, Lior Vernia wrote:
> >>>>
> >>>>
> >>>> On 09/10/13 23:34, Itamar Heim wrote:
> >>>>> On 10/09/2013 03:32 PM, Lior Vernia wrote:
> >>>>>> Of course, my bad. Attached is a screenshot of the add/edit VM dialog,
> >>>>>> note the vNIC part on the bottom half of the dialog.
> >>>>>
> >>>>> how is it different from the custom properties one?
> >>>>>
> >>>>
> >>>> Design-wise, there are a couple of small differences. There's only one
> >>>> button next to each row, plus if it's the last row or minus otherwise
> >>>> (so items can only be added at the end, as I replied to Malini order
> >>>> hasn't been important so far). A row appears as disabled until it is
> >>>> edited, and a disabled row is ignored when the view is flushed back to
> >>>> the model (e.g. when the user presses OK in the dialog).
> >>>>
> >>>> Code-wise, it's constructed to be reusable, which the custom properties
> >>>> widget wasn't :)
> >>>
> >>> could we converge on one of them though?
> >>>
> >>>>
> >>>>>>
> >>>>>> On 09/10/13 13:24, Einav Cohen wrote:
> >>>>>>> Hi Lior - can you please provide a screen-shot, so we will know which
> >>>>>>> widget
> >>>>>>> you are referring to?
> >>>>>>> will make it easier for people to decide if and where to use this
> >>>>>>> widget.
> >>>>>>>
> >>>>>>> Many thanks!
> >>>>>>>
> >>>>>>> ----
> >>>>>>> Regards,
> >>>>>>> Einav
> >>>>>>>
> >>>>>>> ----- Original Message -----
> >>>>>>>> From: "Lior Vernia" <lvernia at redhat.com>
> >>>>>>>> To: "engine-devel" <engine-devel at ovirt.org>
> >>>>>>>> Sent: Wednesday, October 9, 2013 4:34:29 AM
> >>>>>>>> Subject: [Engine-devel] GUI widget for adding/removing entries
> >>>>>>>>
> >>>>>>>> Hello,
> >>>>>>>>
> >>>>>>>> Lately a patch has been merged that introduces a widget for
> >>>>>>>> adding/removing entries (e.g. network interfaces when
> >>>>>>>> creating/editing a
> >>>>>>>> VM):
> >>>>>>>>
> >>>>>>>> http://gerrit.ovirt.org/#/c/19530/
> >>>>>>>>
> >>>>>>>> This kind of widgets is becoming common in oVirt, so the idea is to
> >>>>>>>> make
> >>>>>>>> adding one easy rather than copying & pasting code.
> >>>>>>>> AddRemoveRowWidget
> >>>>>>>> takes care of the plus/minus button logic, disabling an entry that
> >>>>>>>> hasn't been edited, and the arranging in rows.
> >>>>>>>>
> >>>>>>>> In order to use it, one is required to override a couple of abstract
> >>>>>>>> methods that are dependent upon the specific entry implementation.
> >>>>>>>> An
> >>>>>>>> example may be found in ProfilesInstanceTypeEditor, which handles
> >>>>>>>> adding/removing network interfaces in the new/edit VM dialog.
> >>>>>>>>
> >>>>>>>> Yours, Lior.
> >>>>>>>> _______________________________________________
> >>>>>>>> Engine-devel mailing list
> >>>>>>>> Engine-devel at ovirt.org
> >>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> Engine-devel mailing list
> >>>>>>>> Engine-devel at ovirt.org
> >>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>>>
> >>>
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> >>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> 
> 


From piotr.kliczewski at gmail.com  Wed Dec 18 07:21:21 2013
From: piotr.kliczewski at gmail.com (Piotr Kliczewski)
Date: Wed, 18 Dec 2013 08:21:21 +0100
Subject: [Engine-devel] [jenkins] Request to be able to create jobs for
	jsonrpc project
Message-ID: <CAKU0_r=sK-wm_0Bh397KEupcEUCNWk8Zw-bE3uJwtj9TfYZvFQ@mail.gmail.com>

I am working on new project vdsm-jsonrpc-java which is async client
library using json which
will be used for communication between engine and vdsm. I would like
to create jenkins jobs for
this project but have no account nor authority to do so.

Can you please +1 my request?

Thanks,
Piotr


From sabose at redhat.com  Wed Dec 18 07:22:16 2013
From: sabose at redhat.com (Sahina Bose)
Date: Wed, 18 Dec 2013 12:52:16 +0530
Subject: [Engine-devel] Proposal to add Juan Hernandez as maintainer to
 api/sdk/cli
In-Reply-To: <52AF1D8C.5010208@redhat.com>
References: <52AF1D8C.5010208@redhat.com>
Message-ID: <52B14D28.1060701@redhat.com>


On 12/16/2013 09:04 PM, Michael Pasternak wrote:
> Juan has worked on oVirt for a long period of time, developing
> several features in the different areas (including api and cli),
> and obviously gained a lot of experience and knowledge,
>
> I'd like to propose Juan as a maintainer of the  api/sdk/cli projects.
>

+1


From S.Kieske at mittwald.de  Wed Dec 18 08:07:40 2013
From: S.Kieske at mittwald.de (Sven Kieske)
Date: Wed, 18 Dec 2013 08:07:40 +0000
Subject: [Engine-devel] Polling vs Pushing engine events
In-Reply-To: <52B00708.5000405@mittwald.de>
References: <52B00708.5000405@mittwald.de>
Message-ID: <52B15869.3000507@mittwald.de>

Hi,

the following seems to be killing our
plans to use a pythonscript to fetch the list of vms:

This comes from the users list:

Am 17.12.2013 15:04, schrieb Sander Grendelman:> Fetching the list of
vms through the API with the python SDK
> takes several seconds[1] with 100% cpu usage in the python script.
>
> When I look at the engine log there is only one (fast) fetch from
> the API. The rest of the time is spent in the SDK processing a
> relatively small bit of XML data (only 26 VMs in my environment).
>
> This seems an excessive amount of CPU for processing ~6KB of XML.
>
> I've included some sample code [2] and output [3].
> Attached is the cProfile output for this call and a visualization.
>
> [1] ~6,5 seconds on an oVirt VM with 1 vcpu on older hardware,
>     ~3,5 seconds on a fast physical machine with an i5 cpu.


Am 17.12.2013 15:31, schrieb Michael Pasternak:>
> Hi Sander,
>
> This is a known issue caused by generateDS python bindings we use,
> it's extremely slow in python<->xml marshalling, and unable to recognize
> cyclic referencing in the objects,
>
> i'm planning to upgrade in 3.4 from 2.9a to 2.12, if it won't help, we may
> consider other options.


This is no option for us at all:

We can't wait for a possible fix in 3.4
(which maybe even does not fix it).

Additionally we will have much higher amounts of vms to query.


-- 
Mit freundlichen Gr??en / Regards

Sven Kieske

Systemadministrator
Mittwald CM Service GmbH & Co. KG
K?nigsberger Stra?e 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
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

From sbonazzo at redhat.com  Wed Dec 18 12:28:47 2013
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Wed, 18 Dec 2013 13:28:47 +0100
Subject: [Engine-devel] [ATN] [devenv] packaging: setup: refactoring
Message-ID: <52B194FF.6090509@redhat.com>

Hello All,
a patch refactoring the packaging of ovirt-engine-setup[1] will be merged soon.
The change requires latest version of the otopi package to be installed.

Please update it in your development environment.

[1] http://gerrit.ovirt.org/20293

Thanks,

-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com


From rnori at redhat.com  Wed Dec 18 13:57:20 2013
From: rnori at redhat.com (Ravi Nori)
Date: Wed, 18 Dec 2013 08:57:20 -0500
Subject: [Engine-devel] Proposal to add Juan Hernandez as maintainer to
 api/sdk/cli
In-Reply-To: <52B14D28.1060701@redhat.com>
References: <52AF1D8C.5010208@redhat.com> <52B14D28.1060701@redhat.com>
Message-ID: <52B1A9C0.8070306@redhat.com>

>
> On 12/16/2013 09:04 PM, Michael Pasternak wrote:
>> Juan has worked on oVirt for a long period of time, developing
>> several features in the different areas (including api and cli),
>> and obviously gained a lot of experience and knowledge,
>>
>> I'd like to propose Juan as a maintainer of the  api/sdk/cli projects.
>>
>
> +1

+1


From ecohen at redhat.com  Wed Dec 18 13:58:13 2013
From: ecohen at redhat.com (Einav Cohen)
Date: Wed, 18 Dec 2013 08:58:13 -0500 (EST)
Subject: [Engine-devel] Proposal to add Juan Hernandez as maintainer
	to	api/sdk/cli
In-Reply-To: <52AF1D8C.5010208@redhat.com>
References: <52AF1D8C.5010208@redhat.com>
Message-ID: <667791144.34420751.1387375093421.JavaMail.root@redhat.com>

+1, well deserved.

----- Original Message -----
> From: "Michael Pasternak" <mpastern at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>, "infra" <infra at ovirt.org>
> Sent: Monday, December 16, 2013 10:34:36 AM
> Subject: [Engine-devel] Proposal to add Juan Hernandez as maintainer to	api/sdk/cli
> 
> 
> Juan has worked on oVirt for a long period of time, developing
> several features in the different areas (including api and cli),
> and obviously gained a lot of experience and knowledge,
> 
> I'd like to propose Juan as a maintainer of the  api/sdk/cli projects.
> 
> --
> 
> Michael Pasternak
> RedHat, ENG-Virtualization R&D
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From emesika at redhat.com  Wed Dec 18 14:07:45 2013
From: emesika at redhat.com (Eli Mesika)
Date: Wed, 18 Dec 2013 09:07:45 -0500 (EST)
Subject: [Engine-devel] [jenkins] Request to be able to create jobs for
	jsonrpc project
In-Reply-To: <CAKU0_r=sK-wm_0Bh397KEupcEUCNWk8Zw-bE3uJwtj9TfYZvFQ@mail.gmail.com>
References: <CAKU0_r=sK-wm_0Bh397KEupcEUCNWk8Zw-bE3uJwtj9TfYZvFQ@mail.gmail.com>
Message-ID: <593054759.41461431.1387375665691.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Piotr Kliczewski" <piotr.kliczewski at gmail.com>
> To: infra at ovirt.org, "engine-devel" <engine-devel at ovirt.org>
> Sent: Wednesday, December 18, 2013 9:21:21 AM
> Subject: [jenkins] Request to be able to create jobs for jsonrpc project
> 
> I am working on new project vdsm-jsonrpc-java which is async client
> library using json which
> will be used for communication between engine and vdsm. I would like
> to create jenkins jobs for
> this project but have no account nor authority to do so.
> 
> Can you please +1 my request?

+1

> 
> Thanks,
> Piotr
> _______________________________________________
> Infra mailing list
> Infra at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
> 


From alitke at redhat.com  Wed Dec 18 14:42:59 2013
From: alitke at redhat.com (Adam Litke)
Date: Wed, 18 Dec 2013 09:42:59 -0500
Subject: [Engine-devel] UX: Display VM Downtime in the UI
Message-ID: <20131218144259.GC3821@redhat.com>

Hi UX developers,

My recent change: http://gerrit.ovirt.org/#/c/22429/ adds support for
tracking the time a VM was last stopped and presenting it in the REST
API.  I would also like to expose this information in the admin
portal.  This feature has been requested by end users and is useful
for managing lots of VMs which may not be used frequently.

My idea is to change the 'Uptime' column in the VMs tab to 'Uptime /
Downtime' or some equivalent and more compact phrasing.  If the VM is
Up, then last_start_time would be used to calculate uptime.  If the VM
is Down, then last_stop_time would be used to calculate downtime.
This helps to make efficient use of the column space.

I am not sure how column sorting is being implemented, but if we
combine uptime and downtime into a single column we have an
opportunity to provide a really intuitive sort where the longest
uptime machines are at the top and the longest downtime machines are
at the bottom.  This could be accomplished by treating uptime as a
positive interval and downtime as a negative interval.

Questions for you all:

- Do you support the idea of changing the Uptime column to include
  Downtime as well or would you prefer a new column instead?

- Is there a better heading for the new column or is 'Uptime /
  Downtime' good enough?

- How should we handle sorting?

Thanks for your input!


From vszocs at redhat.com  Wed Dec 18 15:10:36 2013
From: vszocs at redhat.com (Vojtech Szocs)
Date: Wed, 18 Dec 2013 10:10:36 -0500 (EST)
Subject: [Engine-devel] No-arg constructor required by default in backend
 "common" module's classes
In-Reply-To: <1386043019.8554614.1387378620761.JavaMail.root@redhat.com>
Message-ID: <1180738433.8562374.1387379436879.JavaMail.root@redhat.com>

Hi guys,

in order to avoid potential errors related to GWT RPC serialization,
a recent patch [1] introduced the requirement for no-arg constructor
in backend "common" module's classes.

[1] http://gerrit.ovirt.org/#/c/21733/

(Even though we're planning to move away from GWT RPC to using REST API,
for the time being, this should prevent RPC related errors caused by
missing no-arg constructor, which are sometimes hard to trace.)

For a select few classes *not* involved in RPC communication, you
can add these in checkstyle-suppressions.xml file.

Vojtech


From mrao at redhat.com  Wed Dec 18 21:04:49 2013
From: mrao at redhat.com (Malini Rao)
Date: Wed, 18 Dec 2013 16:04:49 -0500 (EST)
Subject: [Engine-devel] UX: Display VM Downtime in the UI
In-Reply-To: <20131218144259.GC3821@redhat.com>
References: <20131218144259.GC3821@redhat.com>
Message-ID: <1438883773.44459634.1387400689527.JavaMail.root@redhat.com>


----- Original Message -----
> From: "Adam Litke" <alitke at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Wednesday, December 18, 2013 9:42:59 AM
> Subject: [Engine-devel] UX: Display VM Downtime in the UI
> 
> Hi UX developers,
> 
> My recent change: http://gerrit.ovirt.org/#/c/22429/ adds support for
> tracking the time a VM was last stopped and presenting it in the REST
> API.  I would also like to expose this information in the admin
> portal.  This feature has been requested by end users and is useful
> for managing lots of VMs which may not be used frequently.
> 
> My idea is to change the 'Uptime' column in the VMs tab to 'Uptime /
> Downtime' or some equivalent and more compact phrasing.  If the VM is
> Up, then last_start_time would be used to calculate uptime.  If the VM
> is Down, then last_stop_time would be used to calculate downtime.
> This helps to make efficient use of the column space.


MR: I like the idea in general but can we extend to other states as well? Then we could have the col be called something like 'Time in current state'. Also, I think since this col is so far from the first column that has the status icon, we should have a tooltip on the value that says ' Uptime' , 'down time' or '<Status> time'.

> 
> I am not sure how column sorting is being implemented, but if we
> combine uptime and downtime into a single column we have an
> opportunity to provide a really intuitive sort where the longest
> uptime machines are at the top and the longest downtime machines are
> at the bottom.  This could be accomplished by treating uptime as a
> positive interval and downtime as a negative interval.

MR: That's an interesting idea. Not sure how that would translate if we did all states and times. Then I would think you would do descending order within each state but then we would have to fix a sequence for the display of the various statuses based on the statuses that matter most.


> 
> Questions for you all:
> 
> - Do you support the idea of changing the Uptime column to include
>   Downtime as well or would you prefer a new column instead?


MR: I do not like the idea of introducing new columns for this purpose since at any given time, only one of the columns will be populated. Another idea is to remove this column all together and include the time for the current status as a tooltip on the status icon preceding the name.

> 
> - Is there a better heading for the new column or is 'Uptime /
>   Downtime' good enough?

MR: See earlier suggestions

> 
> - How should we handle sorting?


MR: See earlier suggestions

> 
> Thanks for your input!
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From alitke at redhat.com  Wed Dec 18 21:19:17 2013
From: alitke at redhat.com (Adam Litke)
Date: Wed, 18 Dec 2013 16:19:17 -0500
Subject: [Engine-devel] UX: Display VM Downtime in the UI
In-Reply-To: <1438883773.44459634.1387400689527.JavaMail.root@redhat.com>
References: <20131218144259.GC3821@redhat.com>
	<1438883773.44459634.1387400689527.JavaMail.root@redhat.com>
Message-ID: <20131218211917.GA10422@redhat.com>

On 18/12/13 16:04 -0500, Malini Rao wrote:
>
>----- Original Message -----
>> From: "Adam Litke" <alitke at redhat.com>
>> To: engine-devel at ovirt.org
>> Sent: Wednesday, December 18, 2013 9:42:59 AM
>> Subject: [Engine-devel] UX: Display VM Downtime in the UI
>>
>> Hi UX developers,
>>
>> My recent change: http://gerrit.ovirt.org/#/c/22429/ adds support for
>> tracking the time a VM was last stopped and presenting it in the REST
>> API.  I would also like to expose this information in the admin
>> portal.  This feature has been requested by end users and is useful
>> for managing lots of VMs which may not be used frequently.
>>
>> My idea is to change the 'Uptime' column in the VMs tab to 'Uptime /
>> Downtime' or some equivalent and more compact phrasing.  If the VM is
>> Up, then last_start_time would be used to calculate uptime.  If the VM
>> is Down, then last_stop_time would be used to calculate downtime.
>> This helps to make efficient use of the column space.
>

Thanks for your comments!

>MR: I like the idea in general but can we extend to other states as
>well? Then we could have the col be called something like 'Time in

I would argue that 'Up' and 'Down' are the only persistent states
where a VM can linger for a user-controlled amount of time.  The
others (WaitForLaunch, PoweringDown, etc) are just transitions with
their own system defined timeouts.  Because of this, it really only
makes sense to denote uptime and downtime.  When the VM is in another
state, this column would be empty.

>current state'. Also, I think since this col is so far from the first
>column that has the status icon, we should have a tooltip on the
>value that says ' Uptime' , 'down time' or '<Status> time'.

Agree on the tooltip.

>>
>> I am not sure how column sorting is being implemented, but if we
>> combine uptime and downtime into a single column we have an
>> opportunity to provide a really intuitive sort where the longest
>> uptime machines are at the top and the longest downtime machines
>> are at the bottom.  This could be accomplished by treating uptime
>> as a positive interval and downtime as a negative interval.
>
>MR: That's an interesting idea. Not sure how that would translate if
>we did all states and times. Then I would think you would do
>descending order within each state but then we would have to fix a
>sequence for the display of the various statuses based on the
>statuses that matter most.

This is much simpler if you just work with Up and Down.

>>
>> Questions for you all:
>>
>> - Do you support the idea of changing the Uptime column to include
>> Downtime as well or would you prefer a new column instead?
>
>
>MR: I do not like the idea of introducing new columns for this
>purpose since at any given time, only one of the columns will be
>populated. Another idea is to remove this column all together and
>include the time for the current status as a tooltip on the status
>icon preceding the name.

What about adding the uptime/downtime to the status column itself?  I
don't necessarily think this will muddy the status much since there is
still an icon on the left.



From mrao at redhat.com  Wed Dec 18 21:31:32 2013
From: mrao at redhat.com (Malini Rao)
Date: Wed, 18 Dec 2013 16:31:32 -0500 (EST)
Subject: [Engine-devel] UX: Display VM Downtime in the UI
In-Reply-To: <20131218211917.GA10422@redhat.com>
References: <20131218144259.GC3821@redhat.com>
	<1438883773.44459634.1387400689527.JavaMail.root@redhat.com>
	<20131218211917.GA10422@redhat.com>
Message-ID: <1256939327.44472238.1387402292685.JavaMail.root@redhat.com>


----- Original Message -----
> From: "Adam Litke" <alitke at redhat.com>
> To: "Malini Rao" <mrao at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Wednesday, December 18, 2013 4:19:17 PM
> Subject: Re: [Engine-devel] UX: Display VM Downtime in the UI
> 
> On 18/12/13 16:04 -0500, Malini Rao wrote:
> >
> >----- Original Message -----
> >> From: "Adam Litke" <alitke at redhat.com>
> >> To: engine-devel at ovirt.org
> >> Sent: Wednesday, December 18, 2013 9:42:59 AM
> >> Subject: [Engine-devel] UX: Display VM Downtime in the UI
> >>
> >> Hi UX developers,
> >>
> >> My recent change: http://gerrit.ovirt.org/#/c/22429/ adds support for
> >> tracking the time a VM was last stopped and presenting it in the REST
> >> API.  I would also like to expose this information in the admin
> >> portal.  This feature has been requested by end users and is useful
> >> for managing lots of VMs which may not be used frequently.
> >>
> >> My idea is to change the 'Uptime' column in the VMs tab to 'Uptime /
> >> Downtime' or some equivalent and more compact phrasing.  If the VM is
> >> Up, then last_start_time would be used to calculate uptime.  If the VM
> >> is Down, then last_stop_time would be used to calculate downtime.
> >> This helps to make efficient use of the column space.
> >
> 
> Thanks for your comments!
> 
> >MR: I like the idea in general but can we extend to other states as
> >well? Then we could have the col be called something like 'Time in
> 
> I would argue that 'Up' and 'Down' are the only persistent states
> where a VM can linger for a user-controlled amount of time.  The
> others (WaitForLaunch, PoweringDown, etc) are just transitions with
> their own system defined timeouts.  Because of this, it really only
> makes sense to denote uptime and downtime.  When the VM is in another
> state, this column would be empty.

ok

> 
> >current state'. Also, I think since this col is so far from the first
> >column that has the status icon, we should have a tooltip on the
> >value that says ' Uptime' , 'down time' or '<Status> time'.
> 
> Agree on the tooltip.

I think we should do this in addition to whatever way we decide to display this info elsewhere in the table.

> 
> >>
> >> I am not sure how column sorting is being implemented, but if we
> >> combine uptime and downtime into a single column we have an
> >> opportunity to provide a really intuitive sort where the longest
> >> uptime machines are at the top and the longest downtime machines
> >> are at the bottom.  This could be accomplished by treating uptime
> >> as a positive interval and downtime as a negative interval.
> >
> >MR: That's an interesting idea. Not sure how that would translate if
> >we did all states and times. Then I would think you would do
> >descending order within each state but then we would have to fix a
> >sequence for the display of the various statuses based on the
> >statuses that matter most.
> 
> This is much simpler if you just work with Up and Down.
> 
> >>
> >> Questions for you all:
> >>
> >> - Do you support the idea of changing the Uptime column to include
> >> Downtime as well or would you prefer a new column instead?
> >
> >
> >MR: I do not like the idea of introducing new columns for this
> >purpose since at any given time, only one of the columns will be
> >populated. Another idea is to remove this column all together and
> >include the time for the current status as a tooltip on the status
> >icon preceding the name.
> 
> What about adding the uptime/downtime to the status column itself?  I
> don't necessarily think this will muddy the status much since there is
> still an icon on the left.

I like that idea. This way, a column is not dedicated to a piece of info that is relevant only sometimes. Depending on how critical/ important this info is, this could just be a tooltip on the icon and the up and Down status values. 


> 
> 


From ofrenkel at redhat.com  Thu Dec 19 08:08:01 2013
From: ofrenkel at redhat.com (Omer Frenkel)
Date: Thu, 19 Dec 2013 03:08:01 -0500 (EST)
Subject: [Engine-devel] UX: Display VM Downtime in the UI
In-Reply-To: <20131218211917.GA10422@redhat.com>
References: <20131218144259.GC3821@redhat.com>
	<1438883773.44459634.1387400689527.JavaMail.root@redhat.com>
	<20131218211917.GA10422@redhat.com>
Message-ID: <1675709420.35220298.1387440481295.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Adam Litke" <alitke at redhat.com>
> To: "Malini Rao" <mrao at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Wednesday, December 18, 2013 11:19:17 PM
> Subject: Re: [Engine-devel] UX: Display VM Downtime in the UI
> 
> On 18/12/13 16:04 -0500, Malini Rao wrote:
> >
> >----- Original Message -----
> >> From: "Adam Litke" <alitke at redhat.com>
> >> To: engine-devel at ovirt.org
> >> Sent: Wednesday, December 18, 2013 9:42:59 AM
> >> Subject: [Engine-devel] UX: Display VM Downtime in the UI
> >>
> >> Hi UX developers,
> >>
> >> My recent change: http://gerrit.ovirt.org/#/c/22429/ adds support for
> >> tracking the time a VM was last stopped and presenting it in the REST
> >> API.  I would also like to expose this information in the admin
> >> portal.  This feature has been requested by end users and is useful
> >> for managing lots of VMs which may not be used frequently.
> >>
> >> My idea is to change the 'Uptime' column in the VMs tab to 'Uptime /
> >> Downtime' or some equivalent and more compact phrasing.  If the VM is
> >> Up, then last_start_time would be used to calculate uptime.  If the VM
> >> is Down, then last_stop_time would be used to calculate downtime.
> >> This helps to make efficient use of the column space.
> >
> 
> Thanks for your comments!
> 
> >MR: I like the idea in general but can we extend to other states as
> >well? Then we could have the col be called something like 'Time in
> 
> I would argue that 'Up' and 'Down' are the only persistent states
> where a VM can linger for a user-controlled amount of time.  The
> others (WaitForLaunch, PoweringDown, etc) are just transitions with
> their own system defined timeouts.  Because of this, it really only
> makes sense to denote uptime and downtime.  When the VM is in another
> state, this column would be empty.
> 

when do you think this would be empty?
the way i see it, if there is a qemu process running, we count 'up time' (as it is today)
otherwise, its down time (when vm is suspended/image locked its down as well)
maybe only in 'unknown' state, when we dont have connection to the host,
and we dont know the state of the vm it can be empty.

> >current state'. Also, I think since this col is so far from the first
> >column that has the status icon, we should have a tooltip on the
> >value that says ' Uptime' , 'down time' or '<Status> time'.
> 
> Agree on the tooltip.
> 
> >>
> >> I am not sure how column sorting is being implemented, but if we
> >> combine uptime and downtime into a single column we have an
> >> opportunity to provide a really intuitive sort where the longest
> >> uptime machines are at the top and the longest downtime machines
> >> are at the bottom.  This could be accomplished by treating uptime
> >> as a positive interval and downtime as a negative interval.
> >
> >MR: That's an interesting idea. Not sure how that would translate if
> >we did all states and times. Then I would think you would do
> >descending order within each state but then we would have to fix a
> >sequence for the display of the various statuses based on the
> >statuses that matter most.
> 
> This is much simpler if you just work with Up and Down.
> 
> >>
> >> Questions for you all:
> >>
> >> - Do you support the idea of changing the Uptime column to include
> >> Downtime as well or would you prefer a new column instead?
> >
> >
> >MR: I do not like the idea of introducing new columns for this
> >purpose since at any given time, only one of the columns will be
> >populated. Another idea is to remove this column all together and
> >include the time for the current status as a tooltip on the status
> >icon preceding the name.
> 
> What about adding the uptime/downtime to the status column itself?  I
> don't necessarily think this will muddy the status much since there is
> still an icon on the left.
> 

i like better the first option of one column with up/down time,
i think its more clear to the user

> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From iheim at redhat.com  Thu Dec 19 10:00:26 2013
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 19 Dec 2013 05:00:26 -0500
Subject: [Engine-devel] Proposal to add Juan Hernandez as maintainer to
 api/sdk/cli
In-Reply-To: <667791144.34420751.1387375093421.JavaMail.root@redhat.com>
References: <52AF1D8C.5010208@redhat.com>
	<667791144.34420751.1387375093421.JavaMail.root@redhat.com>
Message-ID: <52B2C3BA.7000505@redhat.com>

On 12/18/2013 08:58 AM, Einav Cohen wrote:
> +1, well deserved.

added.

>
> ----- Original Message -----
>> From: "Michael Pasternak" <mpastern at redhat.com>
>> To: "engine-devel" <engine-devel at ovirt.org>, "infra" <infra at ovirt.org>
>> Sent: Monday, December 16, 2013 10:34:36 AM
>> Subject: [Engine-devel] Proposal to add Juan Hernandez as maintainer to	api/sdk/cli
>>
>>
>> Juan has worked on oVirt for a long period of time, developing
>> several features in the different areas (including api and cli),
>> and obviously gained a lot of experience and knowledge,
>>
>> I'd like to propose Juan as a maintainer of the  api/sdk/cli projects.
>>
>> --
>>
>> Michael Pasternak
>> RedHat, ENG-Virtualization R&D
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> _______________________________________________
> Infra mailing list
> Infra at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
>



From dneary at redhat.com  Thu Dec 19 10:46:05 2013
From: dneary at redhat.com (Dave Neary)
Date: Thu, 19 Dec 2013 12:46:05 +0200
Subject: [Engine-devel] Increasing the HTTP keep alive to 30 seconds
In-Reply-To: <529C4B6D.4080006@redhat.com>
References: <529C4B6D.4080006@redhat.com>
Message-ID: <52B2CE6D.4040608@redhat.com>

Hi Juan,

Did you ever get an answer to this? I don't know who is looking after
the setup scripts these days, but I'd like to.

Thanks,
Dave.

On 12/02/2013 10:57 AM, Juan Hernandez wrote:
> Hello,
> 
> We have an RFE that has been open for quite a long time requesting an
> increase of the keep alive time in the HTTP communications between the
> GUI applications and the web server:
> 
> https://bugzilla.redhat.com/833799
> 
> Implementing it should be as simple as modifying the setup application
> so that it includes the modified KeepAlive directives in the web server
> configuration, something like this:
> 
> KeepAlive on
> KeepAliveTimeout 30
> 
> Is someone with knowledge of the setup application interested on taking
> this?
> 
> Regards,
> Juan Hernandez
> 

-- 
Dave Neary - Community Action and Impact
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13


From emesika at redhat.com  Thu Dec 19 11:13:43 2013
From: emesika at redhat.com (Eli Mesika)
Date: Thu, 19 Dec 2013 06:13:43 -0500 (EST)
Subject: [Engine-devel] Can not login to gerrit with Yahho Id
In-Reply-To: <351746940.42021351.1387451535985.JavaMail.root@redhat.com>
Message-ID: <1117899424.42021570.1387451623860.JavaMail.root@redhat.com>

Hi

I have a Yahoo ID I am using to register to gerrit.
It stops working today, I am getting in to Yahoo account but not getting to gerrit 

Is that a new issue in gerrit ?

Please help

Thanks

Eli


From alitke at redhat.com  Thu Dec 19 13:23:07 2013
From: alitke at redhat.com (Adam Litke)
Date: Thu, 19 Dec 2013 08:23:07 -0500
Subject: [Engine-devel] UX: Display VM Downtime in the UI
In-Reply-To: <1675709420.35220298.1387440481295.JavaMail.root@redhat.com>
References: <20131218144259.GC3821@redhat.com>
	<1438883773.44459634.1387400689527.JavaMail.root@redhat.com>
	<20131218211917.GA10422@redhat.com>
	<1675709420.35220298.1387440481295.JavaMail.root@redhat.com>
Message-ID: <20131219132307.GB10422@redhat.com>

On 19/12/13 03:08 -0500, Omer Frenkel wrote:
>
>
>----- Original Message -----
>> From: "Adam Litke" <alitke at redhat.com>
>> To: "Malini Rao" <mrao at redhat.com>
>> Cc: engine-devel at ovirt.org
>> Sent: Wednesday, December 18, 2013 11:19:17 PM
>> Subject: Re: [Engine-devel] UX: Display VM Downtime in the UI
>>
>> On 18/12/13 16:04 -0500, Malini Rao wrote:
>> >
>> >----- Original Message -----
>> >> From: "Adam Litke" <alitke at redhat.com>
>> >> To: engine-devel at ovirt.org
>> >> Sent: Wednesday, December 18, 2013 9:42:59 AM
>> >> Subject: [Engine-devel] UX: Display VM Downtime in the UI
>> >>
>> >> Hi UX developers,
>> >>
>> >> My recent change: http://gerrit.ovirt.org/#/c/22429/ adds support for
>> >> tracking the time a VM was last stopped and presenting it in the REST
>> >> API.  I would also like to expose this information in the admin
>> >> portal.  This feature has been requested by end users and is useful
>> >> for managing lots of VMs which may not be used frequently.
>> >>
>> >> My idea is to change the 'Uptime' column in the VMs tab to 'Uptime /
>> >> Downtime' or some equivalent and more compact phrasing.  If the VM is
>> >> Up, then last_start_time would be used to calculate uptime.  If the VM
>> >> is Down, then last_stop_time would be used to calculate downtime.
>> >> This helps to make efficient use of the column space.
>> >
>>
>> Thanks for your comments!
>>
>> >MR: I like the idea in general but can we extend to other states as
>> >well? Then we could have the col be called something like 'Time in
>>
>> I would argue that 'Up' and 'Down' are the only persistent states
>> where a VM can linger for a user-controlled amount of time.  The
>> others (WaitForLaunch, PoweringDown, etc) are just transitions with
>> their own system defined timeouts.  Because of this, it really only
>> makes sense to denote uptime and downtime.  When the VM is in another
>> state, this column would be empty.
>>
>
>when do you think this would be empty?
>the way i see it, if there is a qemu process running, we count 'up time' (as it is today)
>otherwise, its down time (when vm is suspended/image locked its down as well)
>maybe only in 'unknown' state, when we dont have connection to the host,
>and we dont know the state of the vm it can be empty.

Sure, makes sense and I agree.

>> >current state'. Also, I think since this col is so far from the first
>> >column that has the status icon, we should have a tooltip on the
>> >value that says ' Uptime' , 'down time' or '<Status> time'.
>>
>> Agree on the tooltip.
>>
>> >>
>> >> I am not sure how column sorting is being implemented, but if we
>> >> combine uptime and downtime into a single column we have an
>> >> opportunity to provide a really intuitive sort where the longest
>> >> uptime machines are at the top and the longest downtime machines
>> >> are at the bottom.  This could be accomplished by treating uptime
>> >> as a positive interval and downtime as a negative interval.
>> >
>> >MR: That's an interesting idea. Not sure how that would translate if
>> >we did all states and times. Then I would think you would do
>> >descending order within each state but then we would have to fix a
>> >sequence for the display of the various statuses based on the
>> >statuses that matter most.
>>
>> This is much simpler if you just work with Up and Down.
>>
>> >>
>> >> Questions for you all:
>> >>
>> >> - Do you support the idea of changing the Uptime column to include
>> >> Downtime as well or would you prefer a new column instead?
>> >
>> >
>> >MR: I do not like the idea of introducing new columns for this
>> >purpose since at any given time, only one of the columns will be
>> >populated. Another idea is to remove this column all together and
>> >include the time for the current status as a tooltip on the status
>> >icon preceding the name.
>>
>> What about adding the uptime/downtime to the status column itself?  I
>> don't necessarily think this will muddy the status much since there is
>> still an icon on the left.
>>
>
>i like better the first option of one column with up/down time,
>i think its more clear to the user

Can you suggest a good concise column heading for it?



From sbonazzo at redhat.com  Thu Dec 19 14:03:45 2013
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Thu, 19 Dec 2013 15:03:45 +0100
Subject: [Engine-devel] oVirt 3.3.2 release
Message-ID: <52B2FCC1.7030206@redhat.com>

The oVirt development team is very happy to announce the general
availability of oVirt 3.3.2 as of December 19th 2013. This release
solidifies oVirt as a leading KVM management application and open
source alternative to VMware vSphere.

oVirt is available now for Fedora 19 and Red Hat Enterprise Linux 6.5
(or similar).

This release of oVirt includes 175 bug fixes and the first release of the
Backup and Restore API, which enables backup programs to integrate with oVirt.
This release also simplifies the Guide Me VM-creation wizard. See the release
notes [1] for a list of the new features and bugs fixed.

IMPORTANT NOTE: If you're upgrading from a previous version, please update
ovirt-release to the latest version (10) and verify you have the correct
repositories enabled by running the following commands

# yum update ovirt-release
# yum repolist enabled

before upgrading with the usual procedure. You should see the ovirt-3.3.2 and
ovirt-stable repositories listed in the output of the repolist command.



[1] http://www.ovirt.org/OVirt_3.3.2_release_notes

-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com


From mrao at redhat.com  Thu Dec 19 17:02:17 2013
From: mrao at redhat.com (Malini Rao)
Date: Thu, 19 Dec 2013 12:02:17 -0500 (EST)
Subject: [Engine-devel] UX: Display VM Downtime in the UI
In-Reply-To: <20131219132307.GB10422@redhat.com>
References: <20131218144259.GC3821@redhat.com>
	<1438883773.44459634.1387400689527.JavaMail.root@redhat.com>
	<20131218211917.GA10422@redhat.com>
	<1675709420.35220298.1387440481295.JavaMail.root@redhat.com>
	<20131219132307.GB10422@redhat.com>
Message-ID: <1414113440.45120754.1387472537593.JavaMail.root@redhat.com>


----- Original Message -----
> From: "Adam Litke" <alitke at redhat.com>
> To: "Omer Frenkel" <ofrenkel at redhat.com>
> Cc: "Malini Rao" <mrao at redhat.com>, engine-devel at ovirt.org
> Sent: Thursday, December 19, 2013 8:23:07 AM
> Subject: Re: [Engine-devel] UX: Display VM Downtime in the UI
> 
> On 19/12/13 03:08 -0500, Omer Frenkel wrote:
> >
> >
> >----- Original Message -----
> >> From: "Adam Litke" <alitke at redhat.com>
> >> To: "Malini Rao" <mrao at redhat.com>
> >> Cc: engine-devel at ovirt.org
> >> Sent: Wednesday, December 18, 2013 11:19:17 PM
> >> Subject: Re: [Engine-devel] UX: Display VM Downtime in the UI
> >>
> >> On 18/12/13 16:04 -0500, Malini Rao wrote:
> >> >
> >> >----- Original Message -----
> >> >> From: "Adam Litke" <alitke at redhat.com>
> >> >> To: engine-devel at ovirt.org
> >> >> Sent: Wednesday, December 18, 2013 9:42:59 AM
> >> >> Subject: [Engine-devel] UX: Display VM Downtime in the UI
> >> >>
> >> >> Hi UX developers,
> >> >>
> >> >> My recent change: http://gerrit.ovirt.org/#/c/22429/ adds support for
> >> >> tracking the time a VM was last stopped and presenting it in the REST
> >> >> API.  I would also like to expose this information in the admin
> >> >> portal.  This feature has been requested by end users and is useful
> >> >> for managing lots of VMs which may not be used frequently.
> >> >>
> >> >> My idea is to change the 'Uptime' column in the VMs tab to 'Uptime /
> >> >> Downtime' or some equivalent and more compact phrasing.  If the VM is
> >> >> Up, then last_start_time would be used to calculate uptime.  If the VM
> >> >> is Down, then last_stop_time would be used to calculate downtime.
> >> >> This helps to make efficient use of the column space.
> >> >
> >>
> >> Thanks for your comments!
> >>
> >> >MR: I like the idea in general but can we extend to other states as
> >> >well? Then we could have the col be called something like 'Time in
> >>
> >> I would argue that 'Up' and 'Down' are the only persistent states
> >> where a VM can linger for a user-controlled amount of time.  The
> >> others (WaitForLaunch, PoweringDown, etc) are just transitions with
> >> their own system defined timeouts.  Because of this, it really only
> >> makes sense to denote uptime and downtime.  When the VM is in another
> >> state, this column would be empty.
> >>
> >
> >when do you think this would be empty?
> >the way i see it, if there is a qemu process running, we count 'up time' (as
> >it is today)
> >otherwise, its down time (when vm is suspended/image locked its down as
> >well)
> >maybe only in 'unknown' state, when we dont have connection to the host,
> >and we dont know the state of the vm it can be empty.
> 
> Sure, makes sense and I agree.
> 
> >> >current state'. Also, I think since this col is so far from the first
> >> >column that has the status icon, we should have a tooltip on the
> >> >value that says ' Uptime' , 'down time' or '<Status> time'.
> >>
> >> Agree on the tooltip.
> >>
> >> >>
> >> >> I am not sure how column sorting is being implemented, but if we
> >> >> combine uptime and downtime into a single column we have an
> >> >> opportunity to provide a really intuitive sort where the longest
> >> >> uptime machines are at the top and the longest downtime machines
> >> >> are at the bottom.  This could be accomplished by treating uptime
> >> >> as a positive interval and downtime as a negative interval.
> >> >
> >> >MR: That's an interesting idea. Not sure how that would translate if
> >> >we did all states and times. Then I would think you would do
> >> >descending order within each state but then we would have to fix a
> >> >sequence for the display of the various statuses based on the
> >> >statuses that matter most.
> >>
> >> This is much simpler if you just work with Up and Down.
> >>
> >> >>
> >> >> Questions for you all:
> >> >>
> >> >> - Do you support the idea of changing the Uptime column to include
> >> >> Downtime as well or would you prefer a new column instead?
> >> >
> >> >
> >> >MR: I do not like the idea of introducing new columns for this
> >> >purpose since at any given time, only one of the columns will be
> >> >populated. Another idea is to remove this column all together and
> >> >include the time for the current status as a tooltip on the status
> >> >icon preceding the name.
> >>
> >> What about adding the uptime/downtime to the status column itself?  I
> >> don't necessarily think this will muddy the status much since there is
> >> still an icon on the left.
> >>
> >
> >i like better the first option of one column with up/down time,
> >i think its more clear to the user
> 
> Can you suggest a good concise column heading for it?

Since this is really just up/ down time, I think that is the best name for it. It's good that this column is right next to the status column so that users can associate the time with the status. But I would still love to see the up or down time included in the tooltip over the main status icon.




From alitke at redhat.com  Thu Dec 19 20:05:12 2013
From: alitke at redhat.com (Adam Litke)
Date: Thu, 19 Dec 2013 15:05:12 -0500
Subject: [Engine-devel] Engine on Fedora 20
Message-ID: <20131219200512.GA3468@redhat.com>

Has anyone had success running ovirt-engine on Fedora 20?  I upgraded
my system on Wednesday and thought everything was fine but then I
started getting the following error:

2013-12-19 14:53:31,447 ERROR [org.ovirt.engine.core.bll.Backend] (MSC
service thread 1-5) Error in getting DB connection. The database is
inaccessible. Original exception is:
DataAccessResourceFailureException: Error retreiving database
metadata; nested exception is
org.springframework.jdbc.support.MetaDataAccessException: Could not
get Connection for extracting meta data; nested exception is
org.springframework.jdbc.CannotGetJdbcConnectionException: Could not
get JDBC Connection; nested exception is java.sql.SQLException:
javax.resource.ResourceException: IJ000453: Unable to get managed
connection for java:/ENGINEDataSource

Has anyone encountered this recently?


From alitke at redhat.com  Thu Dec 19 20:22:55 2013
From: alitke at redhat.com (Adam Litke)
Date: Thu, 19 Dec 2013 15:22:55 -0500
Subject: [Engine-devel] Engine on Fedora 20
In-Reply-To: <20131219200512.GA3468@redhat.com>
References: <20131219200512.GA3468@redhat.com>
Message-ID: <20131219202255.GB3468@redhat.com>

On 19/12/13 15:05 -0500, Adam Litke wrote:
>Has anyone had success running ovirt-engine on Fedora 20?  I upgraded
>my system on Wednesday and thought everything was fine but then I
>started getting the following error:
>
>2013-12-19 14:53:31,447 ERROR [org.ovirt.engine.core.bll.Backend] (MSC
>service thread 1-5) Error in getting DB connection. The database is
>inaccessible. Original exception is:
>DataAccessResourceFailureException: Error retreiving database
>metadata; nested exception is
>org.springframework.jdbc.support.MetaDataAccessException: Could not
>get Connection for extracting meta data; nested exception is
>org.springframework.jdbc.CannotGetJdbcConnectionException: Could not
>get JDBC Connection; nested exception is java.sql.SQLException:
>javax.resource.ResourceException: IJ000453: Unable to get managed
>connection for java:/ENGINEDataSource
>
>Has anyone encountered this recently?

Thanks to alonb for his help on IRC.  As it turns out, I had a poorly
configured pg_hba.conf file that only started causing problems on F20.
To fix I replaced my contents with the following two lines:

host    engine          engine          0.0.0.0/0               md5
host    engine          engine          ::0/0                   md5

Otherwise, it seems to be working fine.


From iheim at redhat.com  Thu Dec 19 20:43:11 2013
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 19 Dec 2013 15:43:11 -0500
Subject: [Engine-devel] Engine on Fedora 20
In-Reply-To: <20131219202255.GB3468@redhat.com>
References: <20131219200512.GA3468@redhat.com>
	<20131219202255.GB3468@redhat.com>
Message-ID: <52B35A5F.6070805@redhat.com>

On 12/19/2013 03:22 PM, Adam Litke wrote:
> On 19/12/13 15:05 -0500, Adam Litke wrote:
>> Has anyone had success running ovirt-engine on Fedora 20?  I upgraded
>> my system on Wednesday and thought everything was fine but then I
>> started getting the following error:
>>
>> 2013-12-19 14:53:31,447 ERROR [org.ovirt.engine.core.bll.Backend] (MSC
>> service thread 1-5) Error in getting DB connection. The database is
>> inaccessible. Original exception is:
>> DataAccessResourceFailureException: Error retreiving database
>> metadata; nested exception is
>> org.springframework.jdbc.support.MetaDataAccessException: Could not
>> get Connection for extracting meta data; nested exception is
>> org.springframework.jdbc.CannotGetJdbcConnectionException: Could not
>> get JDBC Connection; nested exception is java.sql.SQLException:
>> javax.resource.ResourceException: IJ000453: Unable to get managed
>> connection for java:/ENGINEDataSource
>>
>> Has anyone encountered this recently?
>
> Thanks to alonb for his help on IRC.  As it turns out, I had a poorly
> configured pg_hba.conf file that only started causing problems on F20.
> To fix I replaced my contents with the following two lines:
>
> host    engine          engine          0.0.0.0/0               md5
> host    engine          engine          ::0/0                   md5
>
> Otherwise, it seems to be working fine.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel

is this with the wildfly jboss version?


From alitke at redhat.com  Thu Dec 19 21:10:05 2013
From: alitke at redhat.com (Adam Litke)
Date: Thu, 19 Dec 2013 16:10:05 -0500
Subject: [Engine-devel] Engine on Fedora 20
In-Reply-To: <52B35A5F.6070805@redhat.com>
References: <20131219200512.GA3468@redhat.com>
	<20131219202255.GB3468@redhat.com> <52B35A5F.6070805@redhat.com>
Message-ID: <20131219211005.GD3468@redhat.com>

On 19/12/13 15:43 -0500, Itamar Heim wrote:
>On 12/19/2013 03:22 PM, Adam Litke wrote:
>>On 19/12/13 15:05 -0500, Adam Litke wrote:
>>>Has anyone had success running ovirt-engine on Fedora 20?  I upgraded
>>>my system on Wednesday and thought everything was fine but then I
>>>started getting the following error:
>>>
>>>2013-12-19 14:53:31,447 ERROR [org.ovirt.engine.core.bll.Backend] (MSC
>>>service thread 1-5) Error in getting DB connection. The database is
>>>inaccessible. Original exception is:
>>>DataAccessResourceFailureException: Error retreiving database
>>>metadata; nested exception is
>>>org.springframework.jdbc.support.MetaDataAccessException: Could not
>>>get Connection for extracting meta data; nested exception is
>>>org.springframework.jdbc.CannotGetJdbcConnectionException: Could not
>>>get JDBC Connection; nested exception is java.sql.SQLException:
>>>javax.resource.ResourceException: IJ000453: Unable to get managed
>>>connection for java:/ENGINEDataSource
>>>
>>>Has anyone encountered this recently?
>>
>>Thanks to alonb for his help on IRC.  As it turns out, I had a poorly
>>configured pg_hba.conf file that only started causing problems on F20.
>>To fix I replaced my contents with the following two lines:
>>
>>host    engine          engine          0.0.0.0/0               md5
>>host    engine          engine          ::0/0                   md5
>>
>>Otherwise, it seems to be working fine.
>>_______________________________________________
>>Engine-devel mailing list
>>Engine-devel at ovirt.org
>>http://lists.ovirt.org/mailman/listinfo/engine-devel
>
>is this with the wildfly jboss version?

Actually it's with the manually installed jboss-as-7.1.1.Final.tar.gz
that I put in place using the older development environment setup
instructions.



From S.Kieske at mittwald.de  Fri Dec 20 08:09:59 2013
From: S.Kieske at mittwald.de (Sven Kieske)
Date: Fri, 20 Dec 2013 08:09:59 +0000
Subject: [Engine-devel] REST Error during VM creation
Message-ID: <52B3FBF2.60305@mittwald.de>

Hi,

when we try to create a vm via REST-API, we get the following error
via REST:

<h1>HTTP Status 500 - org.codehaus.jackson.map.JsonMappingException:
(was java.lang.NullPointerException) (through reference chain:
org.ovirt.engine.api.model.VM[&quot;console&quot;])</h1><HR size="1"
noshade="noshade"><p><b>type</b> Status report</p><p><b>message</b>
<u>org.codehaus.jackson.map.JsonMappingException: (was
java.lang.NullPointerException) (through reference chain:
org.ovirt.engine.api.model.VM[&quot;console&quot;])</u></p><p><b>description</b>
<u>The server encountered an internal error
(org.codehaus.jackson.map.JsonMappingException: (was
java.lang.NullPointerException) (through reference chain:
org.ovirt.engine.api.model.VM[&quot;console&quot;])) that prevented it
from fulfilling this request.</u></p><HR size="1"
noshade="noshade"><h3>JBoss Web/7.0.13.Final</h3>

However, the vm is correctly created (see attached engine.log).

This is ovirt-engine 3.3.2-1.el6

Any suggestions?

We need to be able to get the correct response via API.

Should I open a BZ for this?


-- 
Mit freundlichen Gr??en / Regards

Sven Kieske

Systemadministrator
Mittwald CM Service GmbH & Co. KG
K?nigsberger Stra?e 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vm_setup_through_rest_engine.log
Type: text/x-log
Size: 12570 bytes
Desc: vm_setup_through_rest_engine.log
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20131220/c0d85d17/attachment.bin>

From S.Kieske at mittwald.de  Fri Dec 20 08:44:59 2013
From: S.Kieske at mittwald.de (Sven Kieske)
Date: Fri, 20 Dec 2013 08:44:59 +0000
Subject: [Engine-devel] REST Error during VM creation
In-Reply-To: <52B3FBF2.60305@mittwald.de>
References: <52B3FBF2.60305@mittwald.de>
Message-ID: <52B40426.4020900@mittwald.de>

I created a BZ for this:

https://bugzilla.redhat.com/show_bug.cgi?id=1045350

Am 20.12.2013 09:09, schrieb Sven Kieske:
> Hi,
> 
> when we try to create a vm via REST-API, we get the following error
> via REST:
> 
> <h1>HTTP Status 500 - org.codehaus.jackson.map.JsonMappingException:
> (was java.lang.NullPointerException) (through reference chain:
> org.ovirt.engine.api.model.VM[&quot;console&quot;])</h1><HR size="1"
> noshade="noshade"><p><b>type</b> Status report</p><p><b>message</b>
> <u>org.codehaus.jackson.map.JsonMappingException: (was
> java.lang.NullPointerException) (through reference chain:
> org.ovirt.engine.api.model.VM[&quot;console&quot;])</u></p><p><b>description</b>
> <u>The server encountered an internal error
> (org.codehaus.jackson.map.JsonMappingException: (was
> java.lang.NullPointerException) (through reference chain:
> org.ovirt.engine.api.model.VM[&quot;console&quot;])) that prevented it
> from fulfilling this request.</u></p><HR size="1"
> noshade="noshade"><h3>JBoss Web/7.0.13.Final</h3>
> 
> However, the vm is correctly created (see attached engine.log).
> 
> This is ovirt-engine 3.3.2-1.el6
> 
> Any suggestions?
> 
> We need to be able to get the correct response via API.
> 
> Should I open a BZ for this?
> 
> 
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 

-- 
Mit freundlichen Gr??en / Regards

Sven Kieske

Systemadministrator
Mittwald CM Service GmbH & Co. KG
K?nigsberger Stra?e 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
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

From tjelinek at redhat.com  Fri Dec 20 09:57:15 2013
From: tjelinek at redhat.com (Tomas Jelinek)
Date: Fri, 20 Dec 2013 04:57:15 -0500 (EST)
Subject: [Engine-devel] REST Error during VM creation
In-Reply-To: <52B40426.4020900@mittwald.de>
References: <52B3FBF2.60305@mittwald.de> <52B40426.4020900@mittwald.de>
Message-ID: <1591883432.9643281.1387533435890.JavaMail.root@redhat.com>

hey,

could you please share the exact XML you have sent to the REST?

Thanx,
Tomas

----- Original Message -----
> From: "Sven Kieske" <S.Kieske at mittwald.de>
> To: engine-devel at ovirt.org
> Sent: Friday, December 20, 2013 9:44:59 AM
> Subject: Re: [Engine-devel] REST Error during VM creation
> 
> I created a BZ for this:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1045350
> 
> Am 20.12.2013 09:09, schrieb Sven Kieske:
> > Hi,
> > 
> > when we try to create a vm via REST-API, we get the following error
> > via REST:
> > 
> > <h1>HTTP Status 500 - org.codehaus.jackson.map.JsonMappingException:
> > (was java.lang.NullPointerException) (through reference chain:
> > org.ovirt.engine.api.model.VM[&quot;console&quot;])</h1><HR size="1"
> > noshade="noshade"><p><b>type</b> Status report</p><p><b>message</b>
> > <u>org.codehaus.jackson.map.JsonMappingException: (was
> > java.lang.NullPointerException) (through reference chain:
> > org.ovirt.engine.api.model.VM[&quot;console&quot;])</u></p><p><b>description</b>
> > <u>The server encountered an internal error
> > (org.codehaus.jackson.map.JsonMappingException: (was
> > java.lang.NullPointerException) (through reference chain:
> > org.ovirt.engine.api.model.VM[&quot;console&quot;])) that prevented it
> > from fulfilling this request.</u></p><HR size="1"
> > noshade="noshade"><h3>JBoss Web/7.0.13.Final</h3>
> > 
> > However, the vm is correctly created (see attached engine.log).
> > 
> > This is ovirt-engine 3.3.2-1.el6
> > 
> > Any suggestions?
> > 
> > We need to be able to get the correct response via API.
> > 
> > Should I open a BZ for this?
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 
> --
> Mit freundlichen Gr??en / Regards
> 
> Sven Kieske
> 
> Systemadministrator
> Mittwald CM Service GmbH & Co. KG
> K?nigsberger Stra?e 6
> 32339 Espelkamp
> T: +49-5772-293-100
> F: +49-5772-293-333
> 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
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From S.Kieske at mittwald.de  Fri Dec 20 10:25:49 2013
From: S.Kieske at mittwald.de (Sven Kieske)
Date: Fri, 20 Dec 2013 10:25:49 +0000
Subject: [Engine-devel] REST Error during VM creation
In-Reply-To: <1591883432.9643281.1387533435890.JavaMail.root@redhat.com>
References: <52B3FBF2.60305@mittwald.de> <52B40426.4020900@mittwald.de>
	<1591883432.9643281.1387533435890.JavaMail.root@redhat.com>
Message-ID: <52B41BC8.8080909@mittwald.de>

Hi,

the data gets submitted through json, as stated in the BZ, here it is:

POST request on https://virt-mgmt-01.internal/api/vms/:
{"name":"vr00001","cluster":{"id":"2ad11b5e-9e74-499a-b317-5a9a3027cfca","name":"localcluster1"},"template":{"id":"10080414-d017-490b-b212-e02cee6a7b6e","name":"ubuntu-server-12.04"},"console":{"enabled":true}}

Am 20.12.2013 10:57, schrieb Tomas Jelinek:
> hey,
> 
> could you please share the exact XML you have sent to the REST?
> 
> Thanx,
> Tomas
> 
> ----- Original Message -----
>> From: "Sven Kieske" <S.Kieske at mittwald.de>
>> To: engine-devel at ovirt.org
>> Sent: Friday, December 20, 2013 9:44:59 AM
>> Subject: Re: [Engine-devel] REST Error during VM creation
>>
>> I created a BZ for this:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1045350
>>
>> Am 20.12.2013 09:09, schrieb Sven Kieske:
>>> Hi,
>>>
>>> when we try to create a vm via REST-API, we get the following error
>>> via REST:
>>>
>>> <h1>HTTP Status 500 - org.codehaus.jackson.map.JsonMappingException:
>>> (was java.lang.NullPointerException) (through reference chain:
>>> org.ovirt.engine.api.model.VM[&quot;console&quot;])</h1><HR size="1"
>>> noshade="noshade"><p><b>type</b> Status report</p><p><b>message</b>
>>> <u>org.codehaus.jackson.map.JsonMappingException: (was
>>> java.lang.NullPointerException) (through reference chain:
>>> org.ovirt.engine.api.model.VM[&quot;console&quot;])</u></p><p><b>description</b>
>>> <u>The server encountered an internal error
>>> (org.codehaus.jackson.map.JsonMappingException: (was
>>> java.lang.NullPointerException) (through reference chain:
>>> org.ovirt.engine.api.model.VM[&quot;console&quot;])) that prevented it
>>> from fulfilling this request.</u></p><HR size="1"
>>> noshade="noshade"><h3>JBoss Web/7.0.13.Final</h3>
>>>
>>> However, the vm is correctly created (see attached engine.log).
>>>
>>> This is ovirt-engine 3.3.2-1.el6
>>>
>>> Any suggestions?
>>>
>>> We need to be able to get the correct response via API.
>>>
>>> Should I open a BZ for this?
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>>
>> --
>> Mit freundlichen Gr??en / Regards
>>
>> Sven Kieske
>>
>> Systemadministrator
>> Mittwald CM Service GmbH & Co. KG
>> K?nigsberger Stra?e 6
>> 32339 Espelkamp
>> T: +49-5772-293-100
>> F: +49-5772-293-333
>> 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
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> 
> 
> 

-- 
Mit freundlichen Gr??en / Regards

Sven Kieske

Systemadministrator
Mittwald CM Service GmbH & Co. KG
K?nigsberger Stra?e 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
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

From S.Kieske at mittwald.de  Fri Dec 20 10:47:22 2013
From: S.Kieske at mittwald.de (Sven Kieske)
Date: Fri, 20 Dec 2013 10:47:22 +0000
Subject: [Engine-devel] missing javadoc for restapi?
Message-ID: <52B420D6.5010201@mittwald.de>

Hi,

we are not able to find the javadoc for the restapi.
I can find the javadoc for the java sdk but not for REST.

Are we looking in the wrong place?
Any links or help would be appreciated!
-- 
Mit freundlichen Gr??en / Regards

Sven Kieske

Systemadministrator
Mittwald CM Service GmbH & Co. KG
K?nigsberger Stra?e 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
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

From S.Kieske at mittwald.de  Fri Dec 20 10:56:32 2013
From: S.Kieske at mittwald.de (Sven Kieske)
Date: Fri, 20 Dec 2013 10:56:32 +0000
Subject: [Engine-devel] missing javadoc for restapi?
In-Reply-To: <52B420D6.5010201@mittwald.de>
References: <52B420D6.5010201@mittwald.de>
Message-ID: <52B422FB.3020607@mittwald.de>

I'm asking because the rsdl is not correct about cloud-init, specific:

http://www.ovirt.org/Features/Cloud-Init_Integration

e.g. it is not mentioned that there is an collection "ips",
not in the wiki and not in the rsdl.

ATM our developers are cursing at me/ovirt.

I'd like to stop this asap.

Am 20.12.2013 11:47, schrieb Sven Kieske:
> Hi,
> 
> we are not able to find the javadoc for the restapi.
> I can find the javadoc for the java sdk but not for REST.
> 
> Are we looking in the wrong place?
> Any links or help would be appreciated!
> 

-- 
Mit freundlichen Gr??en / Regards

Sven Kieske

Systemadministrator
Mittwald CM Service GmbH & Co. KG
K?nigsberger Stra?e 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
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

From shtripat at redhat.com  Fri Dec 20 11:52:50 2013
From: shtripat at redhat.com (Shubhendu Tripathi)
Date: Fri, 20 Dec 2013 17:22:50 +0530
Subject: [Engine-devel] Gluster volume capacity feature
Message-ID: <52B42F92.9080809@redhat.com>

Hi All,

A new wiki has been published for feature "Gluster Volume Capacity"
http://www.ovirt.org/Features/Gluster_Volume_Capacity

Please review the same and provide your comments.

Added Michael and Ori specifically for review of REST apis.

Thanks,
Shubhendu Tripathi



From S.Kieske at mittwald.de  Fri Dec 20 14:40:22 2013
From: S.Kieske at mittwald.de (Sven Kieske)
Date: Fri, 20 Dec 2013 14:40:22 +0000
Subject: [Engine-devel] [BUG] in UserMapper.java in 3.3.2
Message-ID: <52B45772.6050800@mittwald.de>

Hi,

afaik there's a bug in 3.3.2 rest-api implementation of
Cloud-Init:

This Class never gets the password:

http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=backend/manager/modules/restapi/types/src/main/java/org/ovirt/engine/api/restapi/types/UserMapper.java;h=a6aa3a5a5e0dca0ef6a54a38824c7da17228d041;hb=refs/heads/ovirt-engine-3.3.2

and I think there is a typo in line 48:
vdcUser.setDomainControler(adUser.getDomainControler
it should be Controller, not Controler.

there is no
model.setPassword
or similar.

so the data gets to the vm without the password, can somebody fix this?


-- 
Mit freundlichen Gr??en / Regards

Sven Kieske

Systemadministrator
Mittwald CM Service GmbH & Co. KG
K?nigsberger Stra?e 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
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

From S.Kieske at mittwald.de  Fri Dec 20 14:49:51 2013
From: S.Kieske at mittwald.de (Sven Kieske)
Date: Fri, 20 Dec 2013 14:49:51 +0000
Subject: [Engine-devel] [BUG] in UserMapper.java in 3.3.2
In-Reply-To: <52B45772.6050800@mittwald.de>
References: <52B45772.6050800@mittwald.de>
Message-ID: <52B459AB.5050802@mittwald.de>

I opened a BZ to track this:

https://bugzilla.redhat.com/show_bug.cgi?id=1045484

Am 20.12.2013 15:40, schrieb Sven Kieske:
> Hi,
> 
> afaik there's a bug in 3.3.2 rest-api implementation of
> Cloud-Init:
> 
> This Class never gets the password:
> 
> http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=backend/manager/modules/restapi/types/src/main/java/org/ovirt/engine/api/restapi/types/UserMapper.java;h=a6aa3a5a5e0dca0ef6a54a38824c7da17228d041;hb=refs/heads/ovirt-engine-3.3.2
> 
> and I think there is a typo in line 48:
> vdcUser.setDomainControler(adUser.getDomainControler
> it should be Controller, not Controler.
> 
> there is no
> model.setPassword
> or similar.
> 
> so the data gets to the vm without the password, can somebody fix this?
> 
> 

-- 
Mit freundlichen Gr??en / Regards

Sven Kieske

Systemadministrator
Mittwald CM Service GmbH & Co. KG
K?nigsberger Stra?e 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
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

From tjelinek at redhat.com  Fri Dec 20 15:30:55 2013
From: tjelinek at redhat.com (Tomas Jelinek)
Date: Fri, 20 Dec 2013 10:30:55 -0500 (EST)
Subject: [Engine-devel] REST Error during VM creation
In-Reply-To: <52B41BC8.8080909@mittwald.de>
References: <52B3FBF2.60305@mittwald.de> <52B40426.4020900@mittwald.de>
	<1591883432.9643281.1387533435890.JavaMail.root@redhat.com>
	<52B41BC8.8080909@mittwald.de>
Message-ID: <1181761488.9747897.1387553455522.JavaMail.root@redhat.com>

hey,

it was indeed a bug in the JSON part of the API.

Posted a patch for it: http://gerrit.ovirt.org/#/c/22593/

As a walkaround you can use XML instead of JSON.

Tomas

----- Original Message -----
> From: "Sven Kieske" <S.Kieske at mittwald.de>
> To: "Tomas Jelinek" <tjelinek at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Friday, December 20, 2013 11:25:49 AM
> Subject: Re: [Engine-devel] REST Error during VM creation
> 
> Hi,
> 
> the data gets submitted through json, as stated in the BZ, here it is:
> 
> POST request on https://virt-mgmt-01.internal/api/vms/:
> {"name":"vr00001","cluster":{"id":"2ad11b5e-9e74-499a-b317-5a9a3027cfca","name":"localcluster1"},"template":{"id":"10080414-d017-490b-b212-e02cee6a7b6e","name":"ubuntu-server-12.04"},"console":{"enabled":true}}
> 
> Am 20.12.2013 10:57, schrieb Tomas Jelinek:
> > hey,
> > 
> > could you please share the exact XML you have sent to the REST?
> > 
> > Thanx,
> > Tomas
> > 
> > ----- Original Message -----
> >> From: "Sven Kieske" <S.Kieske at mittwald.de>
> >> To: engine-devel at ovirt.org
> >> Sent: Friday, December 20, 2013 9:44:59 AM
> >> Subject: Re: [Engine-devel] REST Error during VM creation
> >>
> >> I created a BZ for this:
> >>
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1045350
> >>
> >> Am 20.12.2013 09:09, schrieb Sven Kieske:
> >>> Hi,
> >>>
> >>> when we try to create a vm via REST-API, we get the following error
> >>> via REST:
> >>>
> >>> <h1>HTTP Status 500 - org.codehaus.jackson.map.JsonMappingException:
> >>> (was java.lang.NullPointerException) (through reference chain:
> >>> org.ovirt.engine.api.model.VM[&quot;console&quot;])</h1><HR size="1"
> >>> noshade="noshade"><p><b>type</b> Status report</p><p><b>message</b>
> >>> <u>org.codehaus.jackson.map.JsonMappingException: (was
> >>> java.lang.NullPointerException) (through reference chain:
> >>> org.ovirt.engine.api.model.VM[&quot;console&quot;])</u></p><p><b>description</b>
> >>> <u>The server encountered an internal error
> >>> (org.codehaus.jackson.map.JsonMappingException: (was
> >>> java.lang.NullPointerException) (through reference chain:
> >>> org.ovirt.engine.api.model.VM[&quot;console&quot;])) that prevented it
> >>> from fulfilling this request.</u></p><HR size="1"
> >>> noshade="noshade"><h3>JBoss Web/7.0.13.Final</h3>
> >>>
> >>> However, the vm is correctly created (see attached engine.log).
> >>>
> >>> This is ovirt-engine 3.3.2-1.el6
> >>>
> >>> Any suggestions?
> >>>
> >>> We need to be able to get the correct response via API.
> >>>
> >>> Should I open a BZ for this?
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Engine-devel mailing list
> >>> Engine-devel at ovirt.org
> >>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>
> >>
> >> --
> >> Mit freundlichen Gr??en / Regards
> >>
> >> Sven Kieske
> >>
> >> Systemadministrator
> >> Mittwald CM Service GmbH & Co. KG
> >> K?nigsberger Stra?e 6
> >> 32339 Espelkamp
> >> T: +49-5772-293-100
> >> F: +49-5772-293-333
> >> 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
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> > 
> > 
> > 
> 
> --
> Mit freundlichen Gr??en / Regards
> 
> Sven Kieske
> 
> Systemadministrator
> Mittwald CM Service GmbH & Co. KG
> K?nigsberger Stra?e 6
> 32339 Espelkamp
> T: +49-5772-293-100
> F: +49-5772-293-333
> 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


From S.Kieske at mittwald.de  Fri Dec 20 15:53:24 2013
From: S.Kieske at mittwald.de (Sven Kieske)
Date: Fri, 20 Dec 2013 15:53:24 +0000
Subject: [Engine-devel] BUG: Typo in RSDL 3.3.2
Message-ID: <52B46890.1050300@mittwald.de>

Hi,

in the rsdl you got:

link href="/api/hosts/{host:id}/forceselectspm"
rel="forceselectspm"><description>force the specified to be selected as
storage pool manager</description><request><http_method>POST</http_method>

it should read "force the specified host to be selected"

I think there are more of those, but I can't list them all atm.
-- 
Mit freundlichen Gr??en / Regards

Sven Kieske

Systemadministrator
Mittwald CM Service GmbH & Co. KG
K?nigsberger Stra?e 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
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

From bob at doolittle.us.com  Fri Dec 20 16:12:08 2013
From: bob at doolittle.us.com (Bob Doolittle)
Date: Fri, 20 Dec 2013 11:12:08 -0500
Subject: [Engine-devel] oVirt 3.3.2 release
In-Reply-To: <52B2FCC1.7030206@redhat.com>
References: <52B2FCC1.7030206@redhat.com>
Message-ID: <52B46C58.6000701@doolittle.us.com>

I can't do an update of Engine for RHEL 6.

The 3.3.2 packages do not seem to have been pushed here:

http://resources.ovirt.org/releases/stable/rpm/EL/6/noarch/

-Bob

On 12/19/2013 09:03 AM, Sandro Bonazzola wrote:
> The oVirt development team is very happy to announce the general
> availability of oVirt 3.3.2 as of December 19th 2013. This release
> solidifies oVirt as a leading KVM management application and open
> source alternative to VMware vSphere.
>
> oVirt is available now for Fedora 19 and Red Hat Enterprise Linux 6.5
> (or similar).
>
> This release of oVirt includes 175 bug fixes and the first release of the
> Backup and Restore API, which enables backup programs to integrate with oVirt.
> This release also simplifies the Guide Me VM-creation wizard. See the release
> notes [1] for a list of the new features and bugs fixed.
>
> IMPORTANT NOTE: If you're upgrading from a previous version, please update
> ovirt-release to the latest version (10) and verify you have the correct
> repositories enabled by running the following commands
>
> # yum update ovirt-release
> # yum repolist enabled
>
> before upgrading with the usual procedure. You should see the ovirt-3.3.2 and
> ovirt-stable repositories listed in the output of the repolist command.
>
>
>
> [1] http://www.ovirt.org/OVirt_3.3.2_release_notes
>



From fabiand at redhat.com  Fri Dec 20 16:13:53 2013
From: fabiand at redhat.com (Fabian Deutsch)
Date: Fri, 20 Dec 2013 17:13:53 +0100
Subject: [Engine-devel] oVirt 3.3.2 release
In-Reply-To: <52B46C58.6000701@doolittle.us.com>
References: <52B2FCC1.7030206@redhat.com> <52B46C58.6000701@doolittle.us.com>
Message-ID: <1387556033.12243.0.camel@fdeutsch-laptop.local>

Am Freitag, den 20.12.2013, 11:12 -0500 schrieb Bob Doolittle:
> I can't do an update of Engine for RHEL 6.
> 
> The 3.3.2 packages do not seem to have been pushed here:
> 
> http://resources.ovirt.org/releases/stable/rpm/EL/6/noarch/

Thanks - I observed the same.

- fabian

> -Bob
> 
> On 12/19/2013 09:03 AM, Sandro Bonazzola wrote:
> > The oVirt development team is very happy to announce the general
> > availability of oVirt 3.3.2 as of December 19th 2013. This release
> > solidifies oVirt as a leading KVM management application and open
> > source alternative to VMware vSphere.
> >
> > oVirt is available now for Fedora 19 and Red Hat Enterprise Linux 6.5
> > (or similar).
> >
> > This release of oVirt includes 175 bug fixes and the first release of the
> > Backup and Restore API, which enables backup programs to integrate with oVirt.
> > This release also simplifies the Guide Me VM-creation wizard. See the release
> > notes [1] for a list of the new features and bugs fixed.
> >
> > IMPORTANT NOTE: If you're upgrading from a previous version, please update
> > ovirt-release to the latest version (10) and verify you have the correct
> > repositories enabled by running the following commands
> >
> > # yum update ovirt-release
> > # yum repolist enabled
> >
> > before upgrading with the usual procedure. You should see the ovirt-3.3.2 and
> > ovirt-stable repositories listed in the output of the repolist command.
> >
> >
> >
> > [1] http://www.ovirt.org/OVirt_3.3.2_release_notes
> >
> 
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20131220/984daa6c/attachment.sig>

From bob at doolittle.us.com  Fri Dec 20 16:23:44 2013
From: bob at doolittle.us.com (Bob Doolittle)
Date: Fri, 20 Dec 2013 11:23:44 -0500
Subject: [Engine-devel] oVirt 3.3.2 release
In-Reply-To: <1387556033.12243.0.camel@fdeutsch-laptop.local>
References: <52B2FCC1.7030206@redhat.com>	 <52B46C58.6000701@doolittle.us.com>
	<1387556033.12243.0.camel@fdeutsch-laptop.local>
Message-ID: <52B46F10.5000005@doolittle.us.com>

I think the problem may be other than I indicated, however, because I 
don't see ovirt-engine-3.3.2 in the FC19 stable repo either. Here's the 
error output of my update command:

Error: Package: ovirt-engine-3.3.1-2.el6.noarch (@ovirt-stable)
            Requires: ovirt-engine-websocket-proxy = 3.3.1-2.el6
            Removing: ovirt-engine-websocket-proxy-3.3.1-2.el6.noarch 
(@ovirt-stable)
                ovirt-engine-websocket-proxy = 3.3.1-2.el6
            Updated By: ovirt-engine-websocket-proxy-3.3.2-1.el6.noarch 
(ovirt-3.3.2)
                ovirt-engine-websocket-proxy = 3.3.2-1.el6
            Available: ovirt-engine-websocket-proxy-3.3.0-3.el6.noarch 
(ovirt-stable)
                ovirt-engine-websocket-proxy = 3.3.0-3.el6
            Available: ovirt-engine-websocket-proxy-3.3.0-4.el6.noarch 
(ovirt-stable)
                ovirt-engine-websocket-proxy = 3.3.0-4.el6
            Available: ovirt-engine-websocket-proxy-3.3.0.1-1.el6.noarch 
(ovirt-stable)
                ovirt-engine-websocket-proxy = 3.3.0.1-1.el6
            Available: ovirt-engine-websocket-proxy-3.3.1-1.el6.noarch 
(ovirt-stable)
                ovirt-engine-websocket-proxy = 3.3.1-1.el6

I have attached my current repo config, after the update of 
ovirt-release-el6-10-1

I'm not sure why it's not seeing 
http://resources.ovirt.org/releases/3.3.2/rpm/EL/6/noarch/ovirt-engine-3.3.2-1.el6.noarch.rpm

I do see that repository enabled in "yum repolist enabled" output.

-Bob

On 12/20/2013 11:13 AM, Fabian Deutsch wrote:
> Am Freitag, den 20.12.2013, 11:12 -0500 schrieb Bob Doolittle:
>> I can't do an update of Engine for RHEL 6.
>>
>> The 3.3.2 packages do not seem to have been pushed here:
>>
>> http://resources.ovirt.org/releases/stable/rpm/EL/6/noarch/
> Thanks - I observed the same.
>
> - fabian
>
>> -Bob
>>
>> On 12/19/2013 09:03 AM, Sandro Bonazzola wrote:
>>> The oVirt development team is very happy to announce the general
>>> availability of oVirt 3.3.2 as of December 19th 2013. This release
>>> solidifies oVirt as a leading KVM management application and open
>>> source alternative to VMware vSphere.
>>>
>>> oVirt is available now for Fedora 19 and Red Hat Enterprise Linux 6.5
>>> (or similar).
>>>
>>> This release of oVirt includes 175 bug fixes and the first release of the
>>> Backup and Restore API, which enables backup programs to integrate with oVirt.
>>> This release also simplifies the Guide Me VM-creation wizard. See the release
>>> notes [1] for a list of the new features and bugs fixed.
>>>
>>> IMPORTANT NOTE: If you're upgrading from a previous version, please update
>>> ovirt-release to the latest version (10) and verify you have the correct
>>> repositories enabled by running the following commands
>>>
>>> # yum update ovirt-release
>>> # yum repolist enabled
>>>
>>> before upgrading with the usual procedure. You should see the ovirt-3.3.2 and
>>> ovirt-stable repositories listed in the output of the repolist command.
>>>
>>>
>>>
>>> [1] http://www.ovirt.org/OVirt_3.3.2_release_notes
>>>
>> _______________________________________________
>> Arch mailing list
>> Arch at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/arch

-------------- next part --------------
[ovirt-stable]
name=Older Stable builds of the oVirt project
baseurl=http://ovirt.org/releases/stable/rpm/EL/$releasever/
enabled=1
skip_if_unavailable=1
gpgcheck=0

[ovirt-3.3.2]
name=oVirt 3.3.2 release
baseurl=http://resources.ovirt.org/releases/3.3.2/rpm/EL/$releasever/
enabled=1
skip_if_unavailable=1
gpgcheck=0

[ovirt-updates-testing]
name=Test Updates builds of the oVirt project
baseurl=http://ovirt.org/releases/updates-testing/rpm/EL/$releasever/
enabled=0
skip_if_unavailable=1
gpgcheck=0

[ovirt-beta]
name=Beta builds of the oVirt project
baseurl=http://ovirt.org/releases/beta/rpm/EL/$releasever/
enabled=0
skip_if_unavailable=1
gpgcheck=0

[ovirt-nightly]
name=Nightly builds of the oVirt project
baseurl=http://ovirt.org/releases/nightly/rpm/EL/$releasever/
enabled=0
skip_if_unavailable=1
gpgcheck=0

From bob at doolittle.us.com  Sat Dec 21 12:24:40 2013
From: bob at doolittle.us.com (Bob Doolittle)
Date: Sat, 21 Dec 2013 07:24:40 -0500
Subject: [Engine-devel] [Users] oVirt 3.3.2 release
In-Reply-To: <9a3eqe9cmlqcfluko0wta6k1.1387619712990@email.android.com>
References: <52B2FCC1.7030206@redhat.com> <52B46C58.6000701@doolittle.us.com>
	<1387556033.12243.0.camel@fdeutsch-laptop.local>
	<52B46F10.5000005@doolittle.us.com>
	<9a3eqe9cmlqcfluko0wta6k1.1387619712990@email.android.com>
Message-ID: <CA+4jJ+tyhMHD6bTgZcqA8zByS8s+FeZSkUPXuHx7roPMa1fnyQ@mail.gmail.com>

Thanks. I considered that but I've been hesitant to try manual workarounds
in case my environment proves helpful for troubleshooting or verifying a
solution. Clearly the community needs a real fix, although the lack of
response to this issue surprised me. Must be the holidays :-)

-Bob
On Dec 21, 2013 4:55 AM, "Markus Stockhausen" <stockhausen at collogia.de>
wrote:

> We are on centos 6.5 and got similar dependency errors but simply replaced
> ovirt-release with ovirt-release-el6 in the guide. Afterwards everything
> worked smoothly.
>
> Do not know if it helps
>
> Von meinem Xperia?-Smartphone  gesendet
>
> Bob Doolittle <bob at doolittle.us.com> schrieb:
>
>
> I think the problem may be other than I indicated, however, because I
> don't see ovirt-engine-3.3.2 in the FC19 stable repo either. Here's the
> error output of my update command:
>
> Error: Package: ovirt-engine-3.3.1-2.el6.noarch (@ovirt-stable)
>             Requires: ovirt-engine-websocket-proxy = 3.3.1-2.el6
>             Removing: ovirt-engine-websocket-proxy-3.3.1-2.el6.noarch
> (@ovirt-stable)
>                 ovirt-engine-websocket-proxy = 3.3.1-2.el6
>             Updated By: ovirt-engine-websocket-proxy-3.3.2-1.el6.noarch
> (ovirt-3.3.2)
>                 ovirt-engine-websocket-proxy = 3.3.2-1.el6
>             Available: ovirt-engine-websocket-proxy-3.3.0-3.el6.noarch
> (ovirt-stable)
>                 ovirt-engine-websocket-proxy = 3.3.0-3.el6
>             Available: ovirt-engine-websocket-proxy-3.3.0-4.el6.noarch
> (ovirt-stable)
>                 ovirt-engine-websocket-proxy = 3.3.0-4.el6
>             Available: ovirt-engine-websocket-proxy-3.3.0.1-1.el6.noarch
> (ovirt-stable)
>                 ovirt-engine-websocket-proxy = 3.3.0.1-1.el6
>             Available: ovirt-engine-websocket-proxy-3.3.1-1.el6.noarch
> (ovirt-stable)
>                 ovirt-engine-websocket-proxy = 3.3.1-1.el6
>
> I have attached my current repo config, after the update of
> ovirt-release-el6-10-1
>
> I'm not sure why it's not seeing
>
> http://resources.ovirt.org/releases/3.3.2/rpm/EL/6/noarch/ovirt-engine-3.3.2-1.el6.noarch.rpm
>
> I do see that repository enabled in "yum repolist enabled" output.
>
> -Bob
>
> On 12/20/2013 11:13 AM, Fabian Deutsch wrote:
> > Am Freitag, den 20.12.2013, 11:12 -0500 schrieb Bob Doolittle:
> >> I can't do an update of Engine for RHEL 6.
> >>
> >> The 3.3.2 packages do not seem to have been pushed here:
> >>
> >> http://resources.ovirt.org/releases/stable/rpm/EL/6/noarch/
> > Thanks - I observed the same.
> >
> > - fabian
> >
> >> -Bob
> >>
> >> On 12/19/2013 09:03 AM, Sandro Bonazzola wrote:
> >>> The oVirt development team is very happy to announce the general
> >>> availability of oVirt 3.3.2 as of December 19th 2013. This release
> >>> solidifies oVirt as a leading KVM management application and open
> >>> source alternative to VMware vSphere.
> >>>
> >>> oVirt is available now for Fedora 19 and Red Hat Enterprise Linux 6.5
> >>> (or similar).
> >>>
> >>> This release of oVirt includes 175 bug fixes and the first release of
> the
> >>> Backup and Restore API, which enables backup programs to integrate
> with oVirt.
> >>> This release also simplifies the Guide Me VM-creation wizard. See the
> release
> >>> notes [1] for a list of the new features and bugs fixed.
> >>>
> >>> IMPORTANT NOTE: If you're upgrading from a previous version, please
> update
> >>> ovirt-release to the latest version (10) and verify you have the
> correct
> >>> repositories enabled by running the following commands
> >>>
> >>> # yum update ovirt-release
> >>> # yum repolist enabled
> >>>
> >>> before upgrading with the usual procedure. You should see the
> ovirt-3.3.2 and
> >>> ovirt-stable repositories listed in the output of the repolist command.
> >>>
> >>>
> >>>
> >>> [1] http://www.ovirt.org/OVirt_3.3.2_release_notes
> >>>
> >> _______________________________________________
> >> Arch mailing list
> >> Arch at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/arch
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20131221/71fe177c/attachment.html>

From mtayer at redhat.com  Sat Dec 21 15:15:44 2013
From: mtayer at redhat.com (Mooli Tayer)
Date: Sat, 21 Dec 2013 10:15:44 -0500 (EST)
Subject: [Engine-devel] Help with "Packager install not implemented"
In-Reply-To: <1153804745.9982450.1387617210734.JavaMail.root@redhat.com>
Message-ID: <848629573.10003454.1387638944738.JavaMail.root@redhat.com>

For patch[1], running:

setup/ovirt-install

Produces:

[ INFO  ] Stage: Initializing
[ INFO  ] Stage: Environment setup
          Configuration files: []
          Log file: /tmp/otopi-20131221103813.log
          Version: otopi-1.2.0_master (otopi-1.2.0-0.0.master.20131007.git6f8ac6d.fc19)
[ INFO  ] Stage: Environment packages setup
[ ERROR ] Failed to execute stage 'Environment packages setup': Packager install not implemented
[ INFO  ] Stage: Pre-termination
[ INFO  ] Stage: Termination

The only relevant information I could find was here:
http://gerrit.ovirt.org/#/c/17637/1/packaging/setup/bin/ovirt-engine-remove

I've attached the otopi log

[1] http://gerrit.ovirt.org/#/c/22135/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: otopi-20131221162712.log
Type: text/x-log
Size: 37832 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20131221/fe8bebb5/attachment.bin>

From alonbl at redhat.com  Sat Dec 21 19:54:44 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Sat, 21 Dec 2013 14:54:44 -0500 (EST)
Subject: [Engine-devel] [ATN] [devenv] packaging: setup: refactoring
In-Reply-To: <52B194FF.6090509@redhat.com>
References: <52B194FF.6090509@redhat.com>
Message-ID: <969284360.27907795.1387655684356.JavaMail.root@redhat.com>

Hello all,

Please re-notice this announcement regarding master and update otopi to at least otopi-1.2.0-0.0.master.20131217 from[1]

If you want to use existing devenv installation, you should remove $HOME/ovirt-engine/share/ovirt-engine/setup, then install-dev.

Regards,
Alon Bar-Lev.

[1] http://resources.ovirt.org/releases/nightly/rpm/Fedora/

----- Original Message -----
> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Cc: "Alon Bar-Lev" <alonbl at redhat.com>
> Sent: Wednesday, December 18, 2013 2:28:47 PM
> Subject: [ATN] [devenv] packaging: setup: refactoring
> 
> Hello All,
> a patch refactoring the packaging of ovirt-engine-setup[1] will be merged
> soon.
> The change requires latest version of the otopi package to be installed.
> 
> Please update it in your development environment.
> 
> [1] http://gerrit.ovirt.org/20293
> 
> Thanks,
> 
> --
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com
> 


From alonbl at redhat.com  Sat Dec 21 19:58:43 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Sat, 21 Dec 2013 14:58:43 -0500 (EST)
Subject: [Engine-devel] Help with "Packager install not implemented"
In-Reply-To: <848629573.10003454.1387638944738.JavaMail.root@redhat.com>
References: <848629573.10003454.1387638944738.JavaMail.root@redhat.com>
Message-ID: <1531329480.27907820.1387655923515.JavaMail.root@redhat.com>

Related to[1]?

[1] http://comments.gmane.org/gmane.comp.emulators.ovirt.engine.devel/5697

----- Original Message -----
> From: "Mooli Tayer" <mtayer at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Saturday, December 21, 2013 5:15:44 PM
> Subject: [Engine-devel] Help with "Packager install not implemented"
> 
> For patch[1], running:
> 
> setup/ovirt-install
> 
> Produces:
> 
> [ INFO  ] Stage: Initializing
> [ INFO  ] Stage: Environment setup
>           Configuration files: []
>           Log file: /tmp/otopi-20131221103813.log
>           Version: otopi-1.2.0_master
>           (otopi-1.2.0-0.0.master.20131007.git6f8ac6d.fc19)
> [ INFO  ] Stage: Environment packages setup
> [ ERROR ] Failed to execute stage 'Environment packages setup': Packager
> install not implemented
> [ INFO  ] Stage: Pre-termination
> [ INFO  ] Stage: Termination
> 
> The only relevant information I could find was here:
> http://gerrit.ovirt.org/#/c/17637/1/packaging/setup/bin/ovirt-engine-remove
> 
> I've attached the otopi log
> 
> [1] http://gerrit.ovirt.org/#/c/22135/
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From ofrenkel at redhat.com  Sun Dec 22 15:37:13 2013
From: ofrenkel at redhat.com (Omer Frenkel)
Date: Sun, 22 Dec 2013 10:37:13 -0500 (EST)
Subject: [Engine-devel] missing javadoc for restapi?
In-Reply-To: <52B422FB.3020607@mittwald.de>
References: <52B420D6.5010201@mittwald.de> <52B422FB.3020607@mittwald.de>
Message-ID: <1738028297.37415717.1387726633311.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Sven Kieske" <S.Kieske at mittwald.de>
> To: engine-devel at ovirt.org
> Sent: Friday, December 20, 2013 12:56:32 PM
> Subject: Re: [Engine-devel] missing javadoc for restapi?
> 
> I'm asking because the rsdl is not correct about cloud-init, specific:
> 
> http://www.ovirt.org/Features/Cloud-Init_Integration
> 
> e.g. it is not mentioned that there is an collection "ips",
> not in the wiki and not in the rsdl.
> 
> ATM our developers are cursing at me/ovirt.
> 
> I'd like to stop this asap.
> 

what version are you working on?
please note that <network> under <cloud_init> was changed to <network_configuration> recently.
i've updated the wiki as well.

if this doesn't help, please attach the xml you are using and i could try and look for the error.


> Am 20.12.2013 11:47, schrieb Sven Kieske:
> > Hi,
> > 
> > we are not able to find the javadoc for the restapi.
> > I can find the javadoc for the java sdk but not for REST.
> > 
> > Are we looking in the wrong place?
> > Any links or help would be appreciated!
> > 
> 
> --
> Mit freundlichen Gr??en / Regards
> 
> Sven Kieske
> 
> Systemadministrator
> Mittwald CM Service GmbH & Co. KG
> K?nigsberger Stra?e 6
> 32339 Espelkamp
> T: +49-5772-293-100
> F: +49-5772-293-333
> 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
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From sbonazzo at redhat.com  Mon Dec 23 06:56:55 2013
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Mon, 23 Dec 2013 07:56:55 +0100
Subject: [Engine-devel] oVirt 3.3.2 release
In-Reply-To: <52B46F10.5000005@doolittle.us.com>
References: <52B2FCC1.7030206@redhat.com>	 <52B46C58.6000701@doolittle.us.com>
	<1387556033.12243.0.camel@fdeutsch-laptop.local>
	<52B46F10.5000005@doolittle.us.com>
Message-ID: <52B7DEB7.6080801@redhat.com>

Il 20/12/2013 17:23, Bob Doolittle ha scritto:
> I think the problem may be other than I indicated, however, because I don't see ovirt-engine-3.3.2 in the FC19 stable repo either. Here's the error
> output of my update command:
> 
> Error: Package: ovirt-engine-3.3.1-2.el6.noarch (@ovirt-stable)
>            Requires: ovirt-engine-websocket-proxy = 3.3.1-2.el6
>            Removing: ovirt-engine-websocket-proxy-3.3.1-2.el6.noarch (@ovirt-stable)
>                ovirt-engine-websocket-proxy = 3.3.1-2.el6
>            Updated By: ovirt-engine-websocket-proxy-3.3.2-1.el6.noarch (ovirt-3.3.2)
>                ovirt-engine-websocket-proxy = 3.3.2-1.el6
>            Available: ovirt-engine-websocket-proxy-3.3.0-3.el6.noarch (ovirt-stable)
>                ovirt-engine-websocket-proxy = 3.3.0-3.el6
>            Available: ovirt-engine-websocket-proxy-3.3.0-4.el6.noarch (ovirt-stable)
>                ovirt-engine-websocket-proxy = 3.3.0-4.el6
>            Available: ovirt-engine-websocket-proxy-3.3.0.1-1.el6.noarch (ovirt-stable)
>                ovirt-engine-websocket-proxy = 3.3.0.1-1.el6
>            Available: ovirt-engine-websocket-proxy-3.3.1-1.el6.noarch (ovirt-stable)
>                ovirt-engine-websocket-proxy = 3.3.1-1.el6


This is a bug in ovirt-engine-3.3.1 dependencies fixed in 3.3.2
(Bug 1033629 - Unable to run regular yum update due to implicit (undeclared) version lock on rhevm-websocket-proxy )
please follow upgrade path as in release notes:

# yum update ovirt-release
# yum repolist enabled
# yum update ovirt-engine-setup
# engine-setup





> 
> I have attached my current repo config, after the update of ovirt-release-el6-10-1
> 
> I'm not sure why it's not seeing http://resources.ovirt.org/releases/3.3.2/rpm/EL/6/noarch/ovirt-engine-3.3.2-1.el6.noarch.rpm
> 
> I do see that repository enabled in "yum repolist enabled" output.
> 
> -Bob
> 
> On 12/20/2013 11:13 AM, Fabian Deutsch wrote:
>> Am Freitag, den 20.12.2013, 11:12 -0500 schrieb Bob Doolittle:
>>> I can't do an update of Engine for RHEL 6.
>>>
>>> The 3.3.2 packages do not seem to have been pushed here:
>>>
>>> http://resources.ovirt.org/releases/stable/rpm/EL/6/noarch/
>> Thanks - I observed the same.
>>
>> - fabian
>>
>>> -Bob
>>>
>>> On 12/19/2013 09:03 AM, Sandro Bonazzola wrote:
>>>> The oVirt development team is very happy to announce the general
>>>> availability of oVirt 3.3.2 as of December 19th 2013. This release
>>>> solidifies oVirt as a leading KVM management application and open
>>>> source alternative to VMware vSphere.
>>>>
>>>> oVirt is available now for Fedora 19 and Red Hat Enterprise Linux 6.5
>>>> (or similar).
>>>>
>>>> This release of oVirt includes 175 bug fixes and the first release of the
>>>> Backup and Restore API, which enables backup programs to integrate with oVirt.
>>>> This release also simplifies the Guide Me VM-creation wizard. See the release
>>>> notes [1] for a list of the new features and bugs fixed.
>>>>
>>>> IMPORTANT NOTE: If you're upgrading from a previous version, please update
>>>> ovirt-release to the latest version (10) and verify you have the correct
>>>> repositories enabled by running the following commands
>>>>
>>>> # yum update ovirt-release
>>>> # yum repolist enabled
>>>>
>>>> before upgrading with the usual procedure. You should see the ovirt-3.3.2 and
>>>> ovirt-stable repositories listed in the output of the repolist command.
>>>>
>>>>
>>>>
>>>> [1] http://www.ovirt.org/OVirt_3.3.2_release_notes
>>>>
>>> _______________________________________________
>>> Arch mailing list
>>> Arch at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/arch
> 


-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com


From oliel at redhat.com  Mon Dec 23 08:46:46 2013
From: oliel at redhat.com (Ori Liel)
Date: Mon, 23 Dec 2013 03:46:46 -0500 (EST)
Subject: [Engine-devel] Proposal to add Juan Hernandez as maintainer to
 api/sdk/cli
In-Reply-To: <52B2C3BA.7000505@redhat.com>
References: <52AF1D8C.5010208@redhat.com>
	<667791144.34420751.1387375093421.JavaMail.root@redhat.com>
	<52B2C3BA.7000505@redhat.com>
Message-ID: <1193027693.8883136.1387788406245.JavaMail.root@redhat.com>

Sorry guys, I wasn't here - big +1 from me

----- Original Message -----
From: "Itamar Heim" <iheim at redhat.com>
To: "Einav Cohen" <ecohen at redhat.com>, "Michael Pasternak" <mpastern at redhat.com>
Cc: "engine-devel" <engine-devel at ovirt.org>, "infra" <infra at ovirt.org>
Sent: Thursday, December 19, 2013 12:00:26 PM
Subject: Re: [Engine-devel] Proposal to add Juan Hernandez as maintainer to api/sdk/cli

On 12/18/2013 08:58 AM, Einav Cohen wrote:
> +1, well deserved.

added.

>
> ----- Original Message -----
>> From: "Michael Pasternak" <mpastern at redhat.com>
>> To: "engine-devel" <engine-devel at ovirt.org>, "infra" <infra at ovirt.org>
>> Sent: Monday, December 16, 2013 10:34:36 AM
>> Subject: [Engine-devel] Proposal to add Juan Hernandez as maintainer to	api/sdk/cli
>>
>>
>> Juan has worked on oVirt for a long period of time, developing
>> several features in the different areas (including api and cli),
>> and obviously gained a lot of experience and knowledge,
>>
>> I'd like to propose Juan as a maintainer of the  api/sdk/cli projects.
>>
>> --
>>
>> Michael Pasternak
>> RedHat, ENG-Virtualization R&D
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> _______________________________________________
> Infra mailing list
> Infra at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
>

_______________________________________________
Engine-devel mailing list
Engine-devel at ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel


From mpastern at redhat.com  Mon Dec 23 11:11:15 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Mon, 23 Dec 2013 13:11:15 +0200
Subject: [Engine-devel] missing javadoc for restapi?
In-Reply-To: <52B420D6.5010201@mittwald.de>
References: <52B420D6.5010201@mittwald.de>
Message-ID: <52B81A53.7010001@redhat.com>

Sven,

if you would like to develop against REST-API
=============================================

REST-API is a web application, there is no javadoc for it
simply because you should develop against HTTP interface,

we have RSDL (RESTful service description language) that you
can use as api documentation [1].

[1] http(s)://server[:port]/api?rsdl
    http(s)://server[:port]/ovirt-engine/api?rsdl


if you would like to develop the REST-API itself
================================================

you working against the actual sources (not installed jar),
so you don't need any javadoc to be installed.

hope it helps.

On 12/20/2013 12:47 PM, Sven Kieske wrote:
> Hi,
> 
> we are not able to find the javadoc for the restapi.
> I can find the javadoc for the java sdk but not for REST.
> 
> Are we looking in the wrong place?
> Any links or help would be appreciated!
> -- Mit freundlichen Gr??en / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG K?nigsberger Stra?e 6 32339 Espelkamp T: +49-5772-293-100 F:
> +49-5772-293-333 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 _______________________________________________ Engine-devel mailing list Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From mpastern at redhat.com  Mon Dec 23 11:13:02 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Mon, 23 Dec 2013 13:13:02 +0200
Subject: [Engine-devel] missing javadoc for restapi?
In-Reply-To: <52B422FB.3020607@mittwald.de>
References: <52B420D6.5010201@mittwald.de> <52B422FB.3020607@mittwald.de>
Message-ID: <52B81ABE.6000107@redhat.com>

On 12/20/2013 12:56 PM, Sven Kieske wrote:
> I'm asking because the rsdl is not correct about cloud-init, specific:
> 
> http://www.ovirt.org/Features/Cloud-Init_Integration
> 
> e.g. it is not mentioned that there is an collection "ips",
> not in the wiki and not in the rsdl.

Omer?

> 
> ATM our developers are cursing at me/ovirt.
> 
> I'd like to stop this asap.
> 
> Am 20.12.2013 11:47, schrieb Sven Kieske:
>> Hi,
>>
>> we are not able to find the javadoc for the restapi.
>> I can find the javadoc for the java sdk but not for REST.
>>
>> Are we looking in the wrong place?
>> Any links or help would be appreciated!
>>
> 


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From liran.zelkha at gmail.com  Mon Dec 23 11:54:07 2013
From: liran.zelkha at gmail.com (Liran Zelkha)
Date: Mon, 23 Dec 2013 13:54:07 +0200
Subject: [Engine-devel] Installing RHEVM DWH 3.2
Message-ID: <CAJ3aYLcwR1JOrNwhNiL7quV+58hNDSq9YWD25oBv-Xji2nKfHg@mail.gmail.com>

Anybody knows how to install RHEVM DWH version 3.2 using the
subscription-manager?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20131223/fec0bf3f/attachment.html>

From mrao at redhat.com  Mon Dec 23 21:43:07 2013
From: mrao at redhat.com (Malini Rao)
Date: Mon, 23 Dec 2013 16:43:07 -0500 (EST)
Subject: [Engine-devel] Options for embedding Cloud init features into VM
 dialog - Need Input
In-Reply-To: <645376143.46637238.1387834492672.JavaMail.root@redhat.com>
Message-ID: <346065258.46639370.1387834987825.JavaMail.root@redhat.com>

Hello all, 

There is a current feature to embed cloud init configuration which was originally part of the Run dialog to be part of the create/ Edit VM dialog. This presents a challenge in terms of  good display of the hierarchies of information since the VM dialog is already having subtabs stacked vertically. Please find here (http://www.ovirt.org/UX/cloud_init) alternate concepts of how we might represent all the levels of hierarchy from the VM dialog sub tabs to the cloud init categories and the content ( which is also nested sometimes) for each.

I have provided brief explanations of each concept and I would like your feedback on these ... esp with regard to feasibility. The general goals that govern the various concepts are - 

- Correct representation of the hierarchy
- Not overloading the users with too much info and cluttering the screen
- Not utilizing the same UI paradigm ( like expand/ collapse) for different types of info. For example, we have categories of info where the fields are distinct from each other and then we have times where the user is able to add multiple instances of the same object type - e.g NICs and have the same set of fields be defined for each instance. 

Your feedback is appreciated.

Thanks
Malini


From mpastern at redhat.com  Tue Dec 24 09:29:55 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Tue, 24 Dec 2013 11:29:55 +0200
Subject: [Engine-devel] [CORE] broken backward compatibility for vm creation
Message-ID: <52B95413.8010508@redhat.com>


[oVirt shell (connected)]# add vm --name test --cluster-id 00000001-0001-0001-0001-000000000001 --template-id 00000000-0000-0000-0000-000000000000

  =========================================================================== ERROR =========================================================================
  status: 400
  reason: Bad Request
  detail: Cannot add VM. Selected operating system is not supported by the architecture.
  ===========================================================================================================================================================

[oVirt shell (connected)]# show template 00000000-0000-0000-0000-000000000000

id                        : 00000000-0000-0000-0000-000000000000
name                      : Blank
description               : Blank template
cluster-id                : 00000001-0001-0001-0001-000000000001
cpu-architecture          : UNDEFINED
cpu-topology-cores        : 1
cpu-topology-sockets      : 1
cpu_shares                : 0
creation_time             : 2008-04-01 00:00:00+03:00
delete_protected          : False
display-allow_override    : False
display-monitors          : 1
display-single_qxl_pci    : False
display-smartcard_enabled : False
display-type              : spice
high_availability-enabled : False
high_availability-priority: 0
memory                    : 1073741824
origin                    : rhev
os-boot-dev               : hd
os-type                   : other
stateless                 : False
status-state              : ok
type                      : desktop
usb-enabled               : False

[oVirt shell (connected)]# show cluster 00000001-0001-0001-0001-000000000001

id                                         : 00000001-0001-0001-0001-000000000001
name                                       : Default
description                                : The default server cluster
ballooning_enabled                         : False
data_center-id                             : 00000002-0002-0002-0002-000000000002
error_handling-on_error                    : migrate
gluster_service                            : False
memory_policy-overcommit-percent           : 100
memory_policy-transparent_hugepages-enabled: True
scheduling_policy-policy                   : none
threads_as_cores                           : False
trusted_service                            : False
tunnel_migration                           : False
version-major                              : 3
version-minor                              : 3
virt_service                               : True

-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From vitor.lima at eldorado.org.br  Tue Dec 24 12:04:32 2013
From: vitor.lima at eldorado.org.br (Vitor de Lima)
Date: Tue, 24 Dec 2013 12:04:32 +0000
Subject: [Engine-devel] [CORE] broken backward compatibility for vm
 creation
In-Reply-To: <52B95413.8010508@redhat.com>
References: <52B95413.8010508@redhat.com>
Message-ID: <B2CAFC4D5E2D574A883EF61ACD5ADE33566E16C7@SERV070.corp.eldorado.org.br>

This is temporarily broken due to the introduction of multi-architecture support. Changes #18227 and #20667 are going to fix this by blocking the addition of VMs into clusters without a defined architecture and properly selecting the default OS when creating VMs.

> -----Original Message-----
> From: engine-devel-bounces at ovirt.org [mailto:engine-devel-
> bounces at ovirt.org] On Behalf Of Michael Pasternak
> Sent: ter?a-feira, 24 de dezembro de 2013 07:30
> To: engine-devel
> Cc: Michal Skrivanek
> Subject: [Engine-devel] [CORE] broken backward compatibility for vm
> creation
> 
> 
> [oVirt shell (connected)]# add vm --name test --cluster-id 00000001-0001-
> 0001-0001-000000000001 --template-id 00000000-0000-0000-0000-
> 000000000000
> 
> 
> ==========================================================
> ================= ERROR
> ==========================================================
> ===============
>   status: 400
>   reason: Bad Request
>   detail: Cannot add VM. Selected operating system is not supported by the
> architecture.
> 
> ==========================================================
> ==========================================================
> =======================================
> 
> [oVirt shell (connected)]# show template 00000000-0000-0000-0000-
> 000000000000
> 
> id                        : 00000000-0000-0000-0000-000000000000
> name                      : Blank
> description               : Blank template
> cluster-id                : 00000001-0001-0001-0001-000000000001
> cpu-architecture          : UNDEFINED
> cpu-topology-cores        : 1
> cpu-topology-sockets      : 1
> cpu_shares                : 0
> creation_time             : 2008-04-01 00:00:00+03:00
> delete_protected          : False
> display-allow_override    : False
> display-monitors          : 1
> display-single_qxl_pci    : False
> display-smartcard_enabled : False
> display-type              : spice
> high_availability-enabled : False
> high_availability-priority: 0
> memory                    : 1073741824
> origin                    : rhev
> os-boot-dev               : hd
> os-type                   : other
> stateless                 : False
> status-state              : ok
> type                      : desktop
> usb-enabled               : False
> 
> [oVirt shell (connected)]# show cluster 00000001-0001-0001-0001-
> 000000000001
> 
> id                                         : 00000001-0001-0001-0001-000000000001
> name                                       : Default
> description                                : The default server cluster
> ballooning_enabled                         : False
> data_center-id                             : 00000002-0002-0002-0002-000000000002
> error_handling-on_error                    : migrate
> gluster_service                            : False
> memory_policy-overcommit-percent           : 100
> memory_policy-transparent_hugepages-enabled: True
> scheduling_policy-policy                   : none
> threads_as_cores                           : False
> trusted_service                            : False
> tunnel_migration                           : False
> version-major                              : 3
> version-minor                              : 3
> virt_service                               : True
> 
> --
> 
> Michael Pasternak
> RedHat, ENG-Virtualization R&D
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel


From mpastern at redhat.com  Tue Dec 24 12:10:13 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Tue, 24 Dec 2013 14:10:13 +0200
Subject: [Engine-devel] [CORE] broken backward compatibility for vm
	creation
In-Reply-To: <B2CAFC4D5E2D574A883EF61ACD5ADE33566E16C7@SERV070.corp.eldorado.org.br>
References: <52B95413.8010508@redhat.com>
	<B2CAFC4D5E2D574A883EF61ACD5ADE33566E16C7@SERV070.corp.eldorado.org.br>
Message-ID: <52B979A5.2010404@redhat.com>


Thanks Vitor,

Such changes should be merged all together, otherwise they create significant noise in master,
and make testing not possible what can lead to not stable master afterwards,

btw eyal, shouldn't Jenkins job be alerting on such changes?

On 12/24/2013 02:04 PM, Vitor de Lima wrote:
> This is temporarily broken due to the introduction of multi-architecture support. Changes #18227 and #20667 are going to fix this by blocking the addition of VMs into clusters without a defined architecture and properly selecting the default OS when creating VMs.
> 
>> -----Original Message-----
>> From: engine-devel-bounces at ovirt.org [mailto:engine-devel-
>> bounces at ovirt.org] On Behalf Of Michael Pasternak
>> Sent: ter?a-feira, 24 de dezembro de 2013 07:30
>> To: engine-devel
>> Cc: Michal Skrivanek
>> Subject: [Engine-devel] [CORE] broken backward compatibility for vm
>> creation
>>
>>
>> [oVirt shell (connected)]# add vm --name test --cluster-id 00000001-0001-
>> 0001-0001-000000000001 --template-id 00000000-0000-0000-0000-
>> 000000000000
>>
>>
>> ==========================================================
>> ================= ERROR
>> ==========================================================
>> ===============
>>   status: 400
>>   reason: Bad Request
>>   detail: Cannot add VM. Selected operating system is not supported by the
>> architecture.
>>
>> ==========================================================
>> ==========================================================
>> =======================================
>>
>> [oVirt shell (connected)]# show template 00000000-0000-0000-0000-
>> 000000000000
>>
>> id                        : 00000000-0000-0000-0000-000000000000
>> name                      : Blank
>> description               : Blank template
>> cluster-id                : 00000001-0001-0001-0001-000000000001
>> cpu-architecture          : UNDEFINED
>> cpu-topology-cores        : 1
>> cpu-topology-sockets      : 1
>> cpu_shares                : 0
>> creation_time             : 2008-04-01 00:00:00+03:00
>> delete_protected          : False
>> display-allow_override    : False
>> display-monitors          : 1
>> display-single_qxl_pci    : False
>> display-smartcard_enabled : False
>> display-type              : spice
>> high_availability-enabled : False
>> high_availability-priority: 0
>> memory                    : 1073741824
>> origin                    : rhev
>> os-boot-dev               : hd
>> os-type                   : other
>> stateless                 : False
>> status-state              : ok
>> type                      : desktop
>> usb-enabled               : False
>>
>> [oVirt shell (connected)]# show cluster 00000001-0001-0001-0001-
>> 000000000001
>>
>> id                                         : 00000001-0001-0001-0001-000000000001
>> name                                       : Default
>> description                                : The default server cluster
>> ballooning_enabled                         : False
>> data_center-id                             : 00000002-0002-0002-0002-000000000002
>> error_handling-on_error                    : migrate
>> gluster_service                            : False
>> memory_policy-overcommit-percent           : 100
>> memory_policy-transparent_hugepages-enabled: True
>> scheduling_policy-policy                   : none
>> threads_as_cores                           : False
>> trusted_service                            : False
>> tunnel_migration                           : False
>> version-major                              : 3
>> version-minor                              : 3
>> virt_service                               : True
>>
>> --
>>
>> Michael Pasternak
>> RedHat, ENG-Virtualization R&D
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From rgolan at redhat.com  Tue Dec 24 12:13:54 2013
From: rgolan at redhat.com (Roy Golan)
Date: Tue, 24 Dec 2013 14:13:54 +0200
Subject: [Engine-devel] [CORE] broken backward compatibility for vm
	creation
In-Reply-To: <52B979A5.2010404@redhat.com>
References: <52B95413.8010508@redhat.com>
	<B2CAFC4D5E2D574A883EF61ACD5ADE33566E16C7@SERV070.corp.eldorado.org.br>
	<52B979A5.2010404@redhat.com>
Message-ID: <52B97A82.5050609@redhat.com>

On Tue 24 Dec 2013 02:10:13 PM IST, Michael Pasternak wrote:
>
> Thanks Vitor,
>
> Such changes should be merged all together, otherwise they create significant noise in master,
> and make testing not possible what can lead to not stable master afterwards,
>
> btw eyal, shouldn't Jenkins job be alerting on such changes?
>
> On 12/24/2013 02:04 PM, Vitor de Lima wrote:
>> This is temporarily broken due to the introduction of multi-architecture support. Changes #18227 and #20667 are going to fix this by blocking the addition of VMs into clusters without a defined architecture and properly selecting the default OS when creating VMs.
>>
>>> -----Original Message-----
>>> From: engine-devel-bounces at ovirt.org [mailto:engine-devel-
>>> bounces at ovirt.org] On Behalf Of Michael Pasternak
>>> Sent: ter?a-feira, 24 de dezembro de 2013 07:30
>>> To: engine-devel
>>> Cc: Michal Skrivanek
>>> Subject: [Engine-devel] [CORE] broken backward compatibility for vm
>>> creation
>>>
>>>
>>> [oVirt shell (connected)]# add vm --name test --cluster-id 00000001-0001-
>>> 0001-0001-000000000001 --template-id 00000000-0000-0000-0000-
>>> 000000000000
>>>
>>>
>>> ==========================================================
>>> ================= ERROR
>>> ==========================================================
>>> ===============
>>>    status: 400
>>>    reason: Bad Request
>>>    detail: Cannot add VM. Selected operating system is not supported by the
>>> architecture.
>>>
>>> ==========================================================
>>> ==========================================================
>>> =======================================
>>>
>>> [oVirt shell (connected)]# show template 00000000-0000-0000-0000-
>>> 000000000000
>>>
>>> id                        : 00000000-0000-0000-0000-000000000000
>>> name                      : Blank
>>> description               : Blank template
>>> cluster-id                : 00000001-0001-0001-0001-000000000001
>>> cpu-architecture          : UNDEFINED
>>> cpu-topology-cores        : 1
>>> cpu-topology-sockets      : 1
>>> cpu_shares                : 0
>>> creation_time             : 2008-04-01 00:00:00+03:00
>>> delete_protected          : False
>>> display-allow_override    : False
>>> display-monitors          : 1
>>> display-single_qxl_pci    : False
>>> display-smartcard_enabled : False
>>> display-type              : spice
>>> high_availability-enabled : False
>>> high_availability-priority: 0
>>> memory                    : 1073741824
>>> origin                    : rhev
>>> os-boot-dev               : hd
>>> os-type                   : other
>>> stateless                 : False
>>> status-state              : ok
>>> type                      : desktop
>>> usb-enabled               : False
>>>
>>> [oVirt shell (connected)]# show cluster 00000001-0001-0001-0001-
>>> 000000000001
>>>
>>> id                                         : 00000001-0001-0001-0001-000000000001
>>> name                                       : Default
>>> description                                : The default server cluster
>>> ballooning_enabled                         : False
>>> data_center-id                             : 00000002-0002-0002-0002-000000000002
>>> error_handling-on_error                    : migrate
>>> gluster_service                            : False
>>> memory_policy-overcommit-percent           : 100
>>> memory_policy-transparent_hugepages-enabled: True
>>> scheduling_policy-policy                   : none
>>> threads_as_cores                           : False
>>> trusted_service                            : False
>>> tunnel_migration                           : False
>>> version-major                              : 3
>>> version-minor                              : 3
>>> virt_service                               : True
>>>
>>> --
>>>
>>> Michael Pasternak
>>> RedHat, ENG-Virtualization R&D
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
>
18227 is merged now.
Michael so while at it http://gerrit.ovirt.org/#/c/20667/ needs REST +1 
to be merged


From eedri at redhat.com  Tue Dec 24 12:21:35 2013
From: eedri at redhat.com (Eyal Edri)
Date: Tue, 24 Dec 2013 07:21:35 -0500 (EST)
Subject: [Engine-devel] [CORE] broken backward compatibility for vm
 creation
In-Reply-To: <52B979A5.2010404@redhat.com>
References: <52B95413.8010508@redhat.com>
	<B2CAFC4D5E2D574A883EF61ACD5ADE33566E16C7@SERV070.corp.eldorado.org.br>
	<52B979A5.2010404@redhat.com>
Message-ID: <641168458.9203758.1387887695868.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Michael Pasternak" <mpastern at redhat.com>
> To: "Vitor de Lima" <vitor.lima at eldorado.org.br>, "engine-devel" <engine-devel at ovirt.org>, "Eyal Edri"
> <eedri at redhat.com>
> Cc: "Michal Skrivanek" <mskrivan at redhat.com>
> Sent: Tuesday, December 24, 2013 2:10:13 PM
> Subject: Re: [Engine-devel] [CORE] broken backward compatibility for vm creation
> 
> 
> Thanks Vitor,
> 
> Such changes should be merged all together, otherwise they create significant
> noise in master,
> and make testing not possible what can lead to not stable master afterwards,
> 
> btw eyal, shouldn't Jenkins job be alerting on such changes?

we don't have currently any tests on engine rest other than unit tests/dao tests running on oVirt.


> 
> On 12/24/2013 02:04 PM, Vitor de Lima wrote:
> > This is temporarily broken due to the introduction of multi-architecture
> > support. Changes #18227 and #20667 are going to fix this by blocking the
> > addition of VMs into clusters without a defined architecture and properly
> > selecting the default OS when creating VMs.
> > 
> >> -----Original Message-----
> >> From: engine-devel-bounces at ovirt.org [mailto:engine-devel-
> >> bounces at ovirt.org] On Behalf Of Michael Pasternak
> >> Sent: ter?a-feira, 24 de dezembro de 2013 07:30
> >> To: engine-devel
> >> Cc: Michal Skrivanek
> >> Subject: [Engine-devel] [CORE] broken backward compatibility for vm
> >> creation
> >>
> >>
> >> [oVirt shell (connected)]# add vm --name test --cluster-id 00000001-0001-
> >> 0001-0001-000000000001 --template-id 00000000-0000-0000-0000-
> >> 000000000000
> >>
> >>
> >> ==========================================================
> >> ================= ERROR
> >> ==========================================================
> >> ===============
> >>   status: 400
> >>   reason: Bad Request
> >>   detail: Cannot add VM. Selected operating system is not supported by the
> >> architecture.
> >>
> >> ==========================================================
> >> ==========================================================
> >> =======================================
> >>
> >> [oVirt shell (connected)]# show template 00000000-0000-0000-0000-
> >> 000000000000
> >>
> >> id                        : 00000000-0000-0000-0000-000000000000
> >> name                      : Blank
> >> description               : Blank template
> >> cluster-id                : 00000001-0001-0001-0001-000000000001
> >> cpu-architecture          : UNDEFINED
> >> cpu-topology-cores        : 1
> >> cpu-topology-sockets      : 1
> >> cpu_shares                : 0
> >> creation_time             : 2008-04-01 00:00:00+03:00
> >> delete_protected          : False
> >> display-allow_override    : False
> >> display-monitors          : 1
> >> display-single_qxl_pci    : False
> >> display-smartcard_enabled : False
> >> display-type              : spice
> >> high_availability-enabled : False
> >> high_availability-priority: 0
> >> memory                    : 1073741824
> >> origin                    : rhev
> >> os-boot-dev               : hd
> >> os-type                   : other
> >> stateless                 : False
> >> status-state              : ok
> >> type                      : desktop
> >> usb-enabled               : False
> >>
> >> [oVirt shell (connected)]# show cluster 00000001-0001-0001-0001-
> >> 000000000001
> >>
> >> id                                         :
> >> 00000001-0001-0001-0001-000000000001
> >> name                                       : Default
> >> description                                : The default server cluster
> >> ballooning_enabled                         : False
> >> data_center-id                             :
> >> 00000002-0002-0002-0002-000000000002
> >> error_handling-on_error                    : migrate
> >> gluster_service                            : False
> >> memory_policy-overcommit-percent           : 100
> >> memory_policy-transparent_hugepages-enabled: True
> >> scheduling_policy-policy                   : none
> >> threads_as_cores                           : False
> >> trusted_service                            : False
> >> tunnel_migration                           : False
> >> version-major                              : 3
> >> version-minor                              : 3
> >> virt_service                               : True
> >>
> >> --
> >>
> >> Michael Pasternak
> >> RedHat, ENG-Virtualization R&D
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> 
> --
> 
> Michael Pasternak
> RedHat, ENG-Virtualization R&D
> 


From shaharh at redhat.com  Tue Dec 24 12:33:28 2013
From: shaharh at redhat.com (Shahar Havivi)
Date: Tue, 24 Dec 2013 14:33:28 +0200
Subject: [Engine-devel] Options for embedding Cloud init features into
 VM dialog - Need Input
In-Reply-To: <1749377184.772885.1387875352641.JavaMail.root@redhat.com>
References: <346065258.46639370.1387834987825.JavaMail.root@redhat.com>
	<1749377184.772885.1387875352641.JavaMail.root@redhat.com>
Message-ID: <20131224123327.GA22146@redhat.com>

Hi,
We have a feature page for the VM Init (including Cloud-Init and Windows
Sysprep):

http://www.ovirt.org/Features/vm-init-persistent


>From: "Malini Rao" <mrao at redhat.com>
>To: "engine-devel" <engine-devel at ovirt.org>
>Cc: "Eldan Hildesheim" <ehildesh at redhat.com>
>Sent: Monday, December 23, 2013 11:43:07 PM
>Subject: [Engine-devel] Options for embedding Cloud init features into VM dialog - Need Input
>
>Hello all, 
>
>There is a current feature to embed cloud init configuration which was originally part of the Run dialog to be part of the create/ Edit VM dialog. This presents a challenge in terms of  good display of the hierarchies of information since the VM dialog is already having subtabs stacked vertically. Please find here (http://www.ovirt.org/UX/cloud_init) alternate concepts of how we might represent all the levels of hierarchy from the VM dialog sub tabs to the cloud init categories and the content ( which is also nested sometimes) for each.
>
>I have provided brief explanations of each concept and I would like your feedback on these ... esp with regard to feasibility. The general goals that govern the various concepts are - 
>
>- Correct representation of the hierarchy
>- Not overloading the users with too much info and cluttering the screen
>- Not utilizing the same UI paradigm ( like expand/ collapse) for different types of info. For example, we have categories of info where the fields are distinct from each other and then we have times where the user is able to add multiple instances of the same object type - e.g NICs and have the same set of fields be defined for each instance. 
>
>Your feedback is appreciated.
>
>Thanks
>Malini
>_______________________________________________
>Engine-devel mailing list
>Engine-devel at ovirt.org
>http://lists.ovirt.org/mailman/listinfo/engine-devel


From ehildesh at redhat.com  Tue Dec 24 12:49:39 2013
From: ehildesh at redhat.com (Eldan Hildesheim)
Date: Tue, 24 Dec 2013 07:49:39 -0500 (EST)
Subject: [Engine-devel] Options for embedding Cloud init features into
 VM dialog - Need Input
In-Reply-To: <20131224123327.GA22146@redhat.com>
References: <346065258.46639370.1387834987825.JavaMail.root@redhat.com>
	<1749377184.772885.1387875352641.JavaMail.root@redhat.com>
	<20131224123327.GA22146@redhat.com>
Message-ID: <862653061.9206095.1387889379994.JavaMail.root@redhat.com>

Hi,
Can we merge those 2 pages together?
Eldan

----- Original Message -----
From: "Shahar Havivi" <shaharh at redhat.com>
To: "Malini Rao" <mrao at redhat.com>
Cc: "engine-devel" <engine-devel at ovirt.org>, "Eldan Hildesheim" <ehildesh at redhat.com>, "Omer Frenkel" <ofrenkel at redhat.com>, "Michal Skrivanek" <michal.skrivanek at redhat.com>
Sent: Tuesday, December 24, 2013 2:33:28 PM
Subject: Re: [Engine-devel] Options for embedding Cloud init features into VM dialog - Need Input

Hi,
We have a feature page for the VM Init (including Cloud-Init and Windows
Sysprep):

http://www.ovirt.org/Features/vm-init-persistent


>From: "Malini Rao" <mrao at redhat.com>
>To: "engine-devel" <engine-devel at ovirt.org>
>Cc: "Eldan Hildesheim" <ehildesh at redhat.com>
>Sent: Monday, December 23, 2013 11:43:07 PM
>Subject: [Engine-devel] Options for embedding Cloud init features into VM dialog - Need Input
>
>Hello all, 
>
>There is a current feature to embed cloud init configuration which was originally part of the Run dialog to be part of the create/ Edit VM dialog. This presents a challenge in terms of  good display of the hierarchies of information since the VM dialog is already having subtabs stacked vertically. Please find here (http://www.ovirt.org/UX/cloud_init) alternate concepts of how we might represent all the levels of hierarchy from the VM dialog sub tabs to the cloud init categories and the content ( which is also nested sometimes) for each.
>
>I have provided brief explanations of each concept and I would like your feedback on these ... esp with regard to feasibility. The general goals that govern the various concepts are - 
>
>- Correct representation of the hierarchy
>- Not overloading the users with too much info and cluttering the screen
>- Not utilizing the same UI paradigm ( like expand/ collapse) for different types of info. For example, we have categories of info where the fields are distinct from each other and then we have times where the user is able to add multiple instances of the same object type - e.g NICs and have the same set of fields be defined for each instance. 
>
>Your feedback is appreciated.
>
>Thanks
>Malini
>_______________________________________________
>Engine-devel mailing list
>Engine-devel at ovirt.org
>http://lists.ovirt.org/mailman/listinfo/engine-devel


From mpastern at redhat.com  Wed Dec 25 07:48:58 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Wed, 25 Dec 2013 09:48:58 +0200
Subject: [Engine-devel] ovirt-engine-sdk-python 3.4.0.1-1 released
In-Reply-To: <5270D591.3070604@redhat.com>
References: <5270D591.3070604@redhat.com>
Message-ID: <52BA8DEA.7090309@redhat.com>


- to host.install() added ssh related details
- to template added virtio_scsi.enabled
- to vm added virtio_scsi.enabled
- to File class added 'content' field
- Payload class now reuses Files instead of own List of <PayloadFile> objects
- added ability to attach a disk snapshot to the virtual machine
- to vms.add() added [action.vm.initialization.cloud-init]
- to NIC added OnBoot/BootProtocol properties
- to VersionCaps added a list of supported payload-encodings
- to Step added externalType
- to NIC added vnicProfile and bootProtocol
- to CPU added architecture
- to VnicProfilePermission added delete() method
- to Disk added readOnly
- to VMs.add() added [vm.cpu.architecture], [action.vm.initialization.cloud_init.*] arguments
- to Templates.add() added [template.cpu.architecture], [action.template.initialization.cloud_init.*] arguments
- to UserRoles.add() added permit.id|name arguments
- at VMSnapshot removed preview/undo/commit methods
- to DataCenterClusterGlusterVolumeGlusterBricks added activate/stopmigrate/migrate actions
- to NetworkVnicProfile added Permissions sub-collection
- to Cluster added [cluster.cpu.architecture]
- to DataCenter added Networks sub-collection
- to ClusterGlusterVolumeGlusterBricks added activate method
- to ClusterGlusterVolume added stoprebalance method
- to entry-point API added Permissions collection (for managing system-permissions)
- to host.install() added ssh related arguments
- to template added virtio_scsi.enabled
- to vm added virtio_scsi.enabled
- added ability to attach a disk snapshot to the virtual machine
- to File class added 'content' field
- Payload class now reuses Files instead of own PayloadFile collection
- to Cluster added [cluster.display.proxy]
- to VmPool added [vmpool.display.proxy]
- sdk ignores url attribute and hardcode /api #1038952
- support automatic auth session invalidation #1018559


more details can be found at [1].

[1] http://www.ovirt.org/Python-sdk-changelog

-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D




From mpastern at redhat.com  Wed Dec 25 07:53:06 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Wed, 25 Dec 2013 09:53:06 +0200
Subject: [Engine-devel] ovirt-engine-sdk-java 3.4.0.1-1 released
In-Reply-To: <5270DF6D.80800@redhat.com>
References: <5270DF6D.80800@redhat.com>
Message-ID: <52BA8EE2.70907@redhat.com>


- to vms.add() added [action.vm.initialization.cloud-init]
- to NIC added OnBoot/BootProtocol properties
- to VersionCaps added a list of supported payload-encodings
- to Step added externalType
- to NIC added vnicProfile and bootProtocol
- to CPU added architecture
- to VnicProfilePermission added delete() method
- to Disk added readOnly
- to VMs.add() added [vm.cpu.architecture], [action.vm.initialization.cloud_init.*] arguments
- to Templates.add() added [template.cpu.architecture], [action.template.initialization.cloud_init.*] arguments
- to UserRoles.add() added permit.id|name arguments
- at VMSnapshot removed preview/undo/commit methods
- to DataCenterClusterGlusterVolumeGlusterBricks added activate/stopmigrate/migrate actions
- to NetworkVnicProfile added Permissions sub-collection
- to Cluster added [cluster.cpu.architecture]
- to DataCenter added Networks sub-collection
- to ClusterGlusterVolumeGlusterBricks added activate method
- to ClusterGlusterVolume added stoprebalance method
- to entry-point API added Permissions collection (for managing system-permissions)
- to host.install() added ssh related arguments
- to template added virtio_scsi.enabled
- to vm added virtio_scsi.enabled
- added ability to attach a disk snapshot to the virtual machine
- to File class added 'content' field
- Payload class now reuses Files instead of own PayloadFile collection

more details can be found at [1].

[1] http://www.ovirt.org/Java-sdk-changelog

-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D




From nsoffer at redhat.com  Wed Dec 25 13:43:42 2013
From: nsoffer at redhat.com (Nir Soffer)
Date: Wed, 25 Dec 2013 08:43:42 -0500 (EST)
Subject: [Engine-devel] Request for power-user permissions
In-Reply-To: <1707752002.34415098.1387978523110.JavaMail.root@redhat.com>
Message-ID: <552514867.34415392.1387979022440.JavaMail.root@redhat.com>

Hi all,

I'm Nir from storage team. I work mostly on vdsm.

I want power-user permissions for jenkins.ovirt.org so I would be able to 
create and modify jobs related to vdsm.

Thanks,
Nir


From shtripat at redhat.com  Thu Dec 26 05:35:35 2013
From: shtripat at redhat.com (Shubhendu Tripathi)
Date: Thu, 26 Dec 2013 11:05:35 +0530
Subject: [Engine-devel] Is there is time based task scheduling available in
	oVirt ?
Message-ID: <52BBC027.10602@redhat.com>

We are in a requirement where time based task scheduling is required for 
gluster tasks.
I understand that, as is there is no such mechanism available in oVirt 
using which we can schedule tasks like volume snaps creation at a given 
time and frequency.

Wanted to know if there is some plan in near future for supporting this 
feature.
This certainly would open other automation options in oVirt.

Regards,
Shubhendu


From abaron at redhat.com  Thu Dec 26 08:10:27 2013
From: abaron at redhat.com (Ayal Baron)
Date: Thu, 26 Dec 2013 03:10:27 -0500 (EST)
Subject: [Engine-devel] Request for power-user permissions
In-Reply-To: <552514867.34415392.1387979022440.JavaMail.root@redhat.com>
References: <552514867.34415392.1387979022440.JavaMail.root@redhat.com>
Message-ID: <1418459252.43511749.1388045427429.JavaMail.root@redhat.com>



----- Original Message -----
> Hi all,
> 
> I'm Nir from storage team. I work mostly on vdsm.
> 
> I want power-user permissions for jenkins.ovirt.org so I would be able to
> create and modify jobs related to vdsm.

+1 from me.

> 
> Thanks,
> Nir
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From eedri at redhat.com  Thu Dec 26 10:30:45 2013
From: eedri at redhat.com (Eyal Edri)
Date: Thu, 26 Dec 2013 05:30:45 -0500 (EST)
Subject: [Engine-devel] [test email - sent at 12:30 IST]
Message-ID: <1014674092.9357766.1388053845063.JavaMail.root@redhat.com>

sorry for the noise, testing mailman.

Eyal.


From gustavo.pedrosa at eldorado.org.br  Thu Dec 26 12:45:57 2013
From: gustavo.pedrosa at eldorado.org.br (Gustavo Frederico Temple Pedrosa)
Date: Thu, 26 Dec 2013 12:45:57 +0000
Subject: [Engine-devel] Options for embedding Cloud init features into
 VM dialog - Need Input
Message-ID: <EF26FC1776F7FF46BFC072393EFD13A2558049E0@SERV070.corp.eldorado.org.br>

Hi,

In an initial analysis, in my opinion I would discard the "Alternate Concept 3", because it goes against the heuristic number #6 of Nielsen (recognition rather than recall), it soon becomes difficult for the user remember where are the options.
Also discard the "Alternate Concept 1", because it blends vertical and horizontal menus, it soon avoids a pattern (system of meaning) and confuses the user.

Thanks.




Date: Tue, 24 Dec 2013 07:49:39 -0500 (EST)
From: Eldan Hildesheim <ehildesh at redhat.com<mailto:ehildesh at redhat.com>>
To: Shahar Havivi <shaharh at redhat.com<mailto:shaharh at redhat.com>>
Cc: engine-devel <engine-devel at ovirt.org<mailto:engine-devel at ovirt.org>>
Subject: Re: [Engine-devel] Options for embedding Cloud init features into VM dialog - Need Input

Hi,
Can we merge those 2 pages together?
Eldan

----- Original Message -----
From: "Shahar Havivi" <shaharh at redhat.com>
To: "Malini Rao" <mrao at redhat.com>
Cc: "engine-devel" <engine-devel at ovirt.org>, "Eldan Hildesheim" <ehildesh at redhat.com>, "Omer Frenkel" <ofrenkel at redhat.com>, "Michal Skrivanek" <michal.skrivanek at redhat.com>
Sent: Tuesday, December 24, 2013 2:33:28 PM
Subject: Re: [Engine-devel] Options for embedding Cloud init features into VM dialog - Need Input

Hi,
We have a feature page for the VM Init (including Cloud-Init and Windows
Sysprep):

http://www.ovirt.org/Features/vm-init-persistent


>From: "Malini Rao" <mrao at redhat.com>
>To: "engine-devel" <engine-devel at ovirt.org>
>Cc: "Eldan Hildesheim" <ehildesh at redhat.com>
>Sent: Monday, December 23, 2013 11:43:07 PM
>Subject: [Engine-devel] Options for embedding Cloud init features into VM dialog - Need Input
>
>Hello all,
>
>There is a current feature to embed cloud init configuration which was originally part of the Run dialog to be part of the create/ Edit VM dialog. This presents a challenge in terms of  good display of the hierarchies of information since the VM dialog is already having subtabs stacked vertically. Please find here (http://www.ovirt.org/UX/cloud_init) alternate concepts of how we might represent all the levels of hierarchy from the VM dialog sub tabs to the cloud init categories and the content ( which is also nested sometimes) for each.
>
>I have provided brief explanations of each concept and I would like your feedback on these ... esp with regard to feasibility. The general goals that govern the various concepts are -
>
>- Correct representation of the hierarchy
>- Not overloading the users with too much info and cluttering the screen
>- Not utilizing the same UI paradigm ( like expand/ collapse) for different types of info. For example, we have categories of info where the fields are distinct from each other and then we have times where the user is able to add multiple instances of the same object type - e.g NICs and have the same set of fields be defined for each instance.
>
>Your feedback is appreciated.
>
>Thanks
>Malini
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20131226/9dbaf727/attachment.html>

From gshereme at redhat.com  Thu Dec 26 20:09:46 2013
From: gshereme at redhat.com (Greg Sheremeta)
Date: Thu, 26 Dec 2013 15:09:46 -0500 (EST)
Subject: [Engine-devel] Engine on Fedora 20
In-Reply-To: <20131219202255.GB3468@redhat.com>
References: <20131219200512.GA3468@redhat.com>
	<20131219202255.GB3468@redhat.com>
Message-ID: <1477991776.28243512.1388088586904.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Adam Litke" <alitke at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Thursday, December 19, 2013 3:22:55 PM
> Subject: Re: [Engine-devel] Engine on Fedora 20
> 
> On 19/12/13 15:05 -0500, Adam Litke wrote:
> >Has anyone had success running ovirt-engine on Fedora 20?  I upgraded
> >my system on Wednesday and thought everything was fine but then I
> >started getting the following error:
> >
> >2013-12-19 14:53:31,447 ERROR [org.ovirt.engine.core.bll.Backend] (MSC
> >service thread 1-5) Error in getting DB connection. The database is
> >inaccessible. Original exception is:
> >DataAccessResourceFailureException: Error retreiving database
> >metadata; nested exception is
> >org.springframework.jdbc.support.MetaDataAccessException: Could not
> >get Connection for extracting meta data; nested exception is
> >org.springframework.jdbc.CannotGetJdbcConnectionException: Could not
> >get JDBC Connection; nested exception is java.sql.SQLException:
> >javax.resource.ResourceException: IJ000453: Unable to get managed
> >connection for java:/ENGINEDataSource
> >
> >Has anyone encountered this recently?
> 
> Thanks to alonb for his help on IRC.  As it turns out, I had a poorly
> configured pg_hba.conf file that only started causing problems on F20.
> To fix I replaced my contents with the following two lines:
> 
> host    engine          engine          0.0.0.0/0               md5
> host    engine          engine          ::0/0                   md5
> 
> Otherwise, it seems to be working fine.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
This happened to me too.

Alon, should we wiki this in http://www.ovirt.org/OVirt_Engine_Development_Environment#Database  ? The current instructions say to use 127.0.0.1 instead of 0.0.0.0

Also, I find it strange that 127.0.0.1 wasn't working for me, whereas 0.0.0.0 does.

Greg


From alonbl at redhat.com  Thu Dec 26 20:13:25 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Thu, 26 Dec 2013 15:13:25 -0500 (EST)
Subject: [Engine-devel] Engine on Fedora 20
In-Reply-To: <1477991776.28243512.1388088586904.JavaMail.root@redhat.com>
References: <20131219200512.GA3468@redhat.com>
	<20131219202255.GB3468@redhat.com>
	<1477991776.28243512.1388088586904.JavaMail.root@redhat.com>
Message-ID: <1190997758.28243581.1388088805176.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Greg Sheremeta" <gshereme at redhat.com>
> To: "Adam Litke" <alitke at redhat.com>, "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Thursday, December 26, 2013 10:09:46 PM
> Subject: Re: [Engine-devel] Engine on Fedora 20
> 
> 
> 
> ----- Original Message -----
> > From: "Adam Litke" <alitke at redhat.com>
> > To: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Thursday, December 19, 2013 3:22:55 PM
> > Subject: Re: [Engine-devel] Engine on Fedora 20
> > 
> > On 19/12/13 15:05 -0500, Adam Litke wrote:
> > >Has anyone had success running ovirt-engine on Fedora 20?  I upgraded
> > >my system on Wednesday and thought everything was fine but then I
> > >started getting the following error:
> > >
> > >2013-12-19 14:53:31,447 ERROR [org.ovirt.engine.core.bll.Backend] (MSC
> > >service thread 1-5) Error in getting DB connection. The database is
> > >inaccessible. Original exception is:
> > >DataAccessResourceFailureException: Error retreiving database
> > >metadata; nested exception is
> > >org.springframework.jdbc.support.MetaDataAccessException: Could not
> > >get Connection for extracting meta data; nested exception is
> > >org.springframework.jdbc.CannotGetJdbcConnectionException: Could not
> > >get JDBC Connection; nested exception is java.sql.SQLException:
> > >javax.resource.ResourceException: IJ000453: Unable to get managed
> > >connection for java:/ENGINEDataSource
> > >
> > >Has anyone encountered this recently?
> > 
> > Thanks to alonb for his help on IRC.  As it turns out, I had a poorly
> > configured pg_hba.conf file that only started causing problems on F20.
> > To fix I replaced my contents with the following two lines:
> > 
> > host    engine          engine          0.0.0.0/0               md5
> > host    engine          engine          ::0/0                   md5
> > 
> > Otherwise, it seems to be working fine.
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> This happened to me too.
> 
> Alon, should we wiki this in
> http://www.ovirt.org/OVirt_Engine_Development_Environment#Database  ? The
> current instructions say to use 127.0.0.1 instead of 0.0.0.0
> 
> Also, I find it strange that 127.0.0.1 wasn't working for me, whereas 0.0.0.0
> does.

loopback should work. Have you put the ipv6 entry as well?

Alon


From gshereme at redhat.com  Thu Dec 26 20:18:57 2013
From: gshereme at redhat.com (Greg Sheremeta)
Date: Thu, 26 Dec 2013 15:18:57 -0500 (EST)
Subject: [Engine-devel] Engine on Fedora 20
In-Reply-To: <1190997758.28243581.1388088805176.JavaMail.root@redhat.com>
References: <20131219200512.GA3468@redhat.com>
	<20131219202255.GB3468@redhat.com>
	<1477991776.28243512.1388088586904.JavaMail.root@redhat.com>
	<1190997758.28243581.1388088805176.JavaMail.root@redhat.com>
Message-ID: <944984024.28243670.1388089137583.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "Greg Sheremeta" <gshereme at redhat.com>
> Cc: "Adam Litke" <alitke at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
> Sent: Thursday, December 26, 2013 3:13:25 PM
> Subject: Re: [Engine-devel] Engine on Fedora 20
> 
> 
> 
> ----- Original Message -----
> > From: "Greg Sheremeta" <gshereme at redhat.com>
> > To: "Adam Litke" <alitke at redhat.com>, "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Thursday, December 26, 2013 10:09:46 PM
> > Subject: Re: [Engine-devel] Engine on Fedora 20
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Adam Litke" <alitke at redhat.com>
> > > To: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Thursday, December 19, 2013 3:22:55 PM
> > > Subject: Re: [Engine-devel] Engine on Fedora 20
> > > 
> > > On 19/12/13 15:05 -0500, Adam Litke wrote:
> > > >Has anyone had success running ovirt-engine on Fedora 20?  I upgraded
> > > >my system on Wednesday and thought everything was fine but then I
> > > >started getting the following error:
> > > >
> > > >2013-12-19 14:53:31,447 ERROR [org.ovirt.engine.core.bll.Backend] (MSC
> > > >service thread 1-5) Error in getting DB connection. The database is
> > > >inaccessible. Original exception is:
> > > >DataAccessResourceFailureException: Error retreiving database
> > > >metadata; nested exception is
> > > >org.springframework.jdbc.support.MetaDataAccessException: Could not
> > > >get Connection for extracting meta data; nested exception is
> > > >org.springframework.jdbc.CannotGetJdbcConnectionException: Could not
> > > >get JDBC Connection; nested exception is java.sql.SQLException:
> > > >javax.resource.ResourceException: IJ000453: Unable to get managed
> > > >connection for java:/ENGINEDataSource
> > > >
> > > >Has anyone encountered this recently?
> > > 
> > > Thanks to alonb for his help on IRC.  As it turns out, I had a poorly
> > > configured pg_hba.conf file that only started causing problems on F20.
> > > To fix I replaced my contents with the following two lines:
> > > 
> > > host    engine          engine          0.0.0.0/0               md5
> > > host    engine          engine          ::0/0                   md5
> > > 
> > > Otherwise, it seems to be working fine.
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > This happened to me too.
> > 
> > Alon, should we wiki this in
> > http://www.ovirt.org/OVirt_Engine_Development_Environment#Database  ? The
> > current instructions say to use 127.0.0.1 instead of 0.0.0.0
> > 
> > Also, I find it strange that 127.0.0.1 wasn't working for me, whereas
> > 0.0.0.0
> > does.
> 
> loopback should work. Have you put the ipv6 entry as well?
> 
> Alon
> 
You're right, either of these works:

#host    engine          engine          0.0.0.0/0               md5
#host    engine          engine          ::0/0                   md5

host    all             all             127.0.0.1/32            password
host    all             all             ::1/128                 password

Sorry for the spam.


From danken at redhat.com  Fri Dec 27 00:34:36 2013
From: danken at redhat.com (Dan Kenigsberg)
Date: Fri, 27 Dec 2013 00:34:36 +0000
Subject: [Engine-devel] Request for power-user permissions
In-Reply-To: <1418459252.43511749.1388045427429.JavaMail.root@redhat.com>
References: <552514867.34415392.1387979022440.JavaMail.root@redhat.com>
	<1418459252.43511749.1388045427429.JavaMail.root@redhat.com>
Message-ID: <20131227003435.GB22940@redhat.com>

On Thu, Dec 26, 2013 at 03:10:27AM -0500, Ayal Baron wrote:
> 
> 
> ----- Original Message -----
> > Hi all,
> > 
> > I'm Nir from storage team. I work mostly on vdsm.
> > 
> > I want power-user permissions for jenkins.ovirt.org so I would be able to
> > create and modify jobs related to vdsm.
> 
> +1 from me.

+1


From wang.tianyi at qq.com  Fri Dec 27 09:29:02 2013
From: wang.tianyi at qq.com (=?gb18030?B?SnVzdE1hbg==?=)
Date: Fri, 27 Dec 2013 17:29:02 +0800
Subject: [Engine-devel] How to custom the UI for oVirt?
Message-ID: <tencent_2F670DD84311ABA713C38D22@qq.com>

HI All?


    If custom development the UI for oVirt, what's development technology must be learn, and where is the UI module in the resource? Where is the start step?


    Where can find oVirt architecture document? I goto the office website, already read some development document, but still very clear the architecture of oVirt, special of the GWT part.


ike


Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20131227/7df876d4/attachment.html>

From eedri at redhat.com  Sun Dec 29 06:51:58 2013
From: eedri at redhat.com (Eyal Edri)
Date: Sun, 29 Dec 2013 01:51:58 -0500 (EST)
Subject: [Engine-devel] Request for power-user permissions
In-Reply-To: <20131227003435.GB22940@redhat.com>
References: <552514867.34415392.1387979022440.JavaMail.root@redhat.com>
	<1418459252.43511749.1388045427429.JavaMail.root@redhat.com>
	<20131227003435.GB22940@redhat.com>
Message-ID: <1063617015.9554645.1388299917998.JavaMail.root@redhat.com>

OK, +1 from me as well, i don't see any objections.
Nir, i will send you the credentials in private, please contact
the infra team for any assistance in configuring a specific job if needed.

Eyal.

----- Original Message -----
> From: "Dan Kenigsberg" <danken at redhat.com>
> To: "Ayal Baron" <abaron at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, infra at ovirt.org
> Sent: Friday, December 27, 2013 2:34:36 AM
> Subject: Re: [Engine-devel] Request for power-user permissions
> 
> On Thu, Dec 26, 2013 at 03:10:27AM -0500, Ayal Baron wrote:
> > 
> > 
> > ----- Original Message -----
> > > Hi all,
> > > 
> > > I'm Nir from storage team. I work mostly on vdsm.
> > > 
> > > I want power-user permissions for jenkins.ovirt.org so I would be able to
> > > create and modify jobs related to vdsm.
> > 
> > +1 from me.
> 
> +1
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From ovedo at redhat.com  Sun Dec 29 07:09:47 2013
From: ovedo at redhat.com (Oved Ourfalli)
Date: Sun, 29 Dec 2013 02:09:47 -0500 (EST)
Subject: [Engine-devel] How to custom the UI for oVirt?
In-Reply-To: <tencent_2F670DD84311ABA713C38D22@qq.com>
References: <tencent_2F670DD84311ABA713C38D22@qq.com>
Message-ID: <624425480.47269863.1388300987173.JavaMail.root@redhat.com>

Hi

If you would like to customize the UI to fit your needs, like adding new tabs, new action buttons, and etc., then I recommend reading the wiki pages about UI plugins:
Formal page: http://www.ovirt.org/Features/UIPlugins

Blog posts regarding that:
http://ovedou.blogspot.co.il/
http://developerblog.redhat.com/2013/12/19/advanced_integration_rhevm-part2/
http://developerblog.redhat.com/2013/12/19/advanced_integration_rhevm-part1/
http://developerblog.redhat.com/2013/12/12/advanced_integration_rhevm-part1/

As for the architecture information, there is an architecture page on http://www.ovirt.org/Architecture, but it doesn't have a lot on GWT.
Vojtech/Einav - can you send some information on that, or better update the wiki page?

Thank you,
Oved

----- Original Message -----
> From: "JustMan" <wang.tianyi at qq.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Friday, December 27, 2013 11:29:02 AM
> Subject: [Engine-devel] How to custom the UI for oVirt?
> 
> HI All?
> 
> If custom development the UI for oVirt, what's development technology must be
> learn, and where is the UI module in the resource? Where is the start step?
> 
> Where can find oVirt architecture document? I goto the office website,
> already read some development document, but still very clear the
> architecture of oVirt, special of the GWT part.
> 
> ike
> 
> Thanks
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>


From gshereme at redhat.com  Mon Dec 30 19:51:19 2013
From: gshereme at redhat.com (Greg Sheremeta)
Date: Mon, 30 Dec 2013 14:51:19 -0500 (EST)
Subject: [Engine-devel] How to custom the UI for oVirt?
In-Reply-To: <624425480.47269863.1388300987173.JavaMail.root@redhat.com>
References: <tencent_2F670DD84311ABA713C38D22@qq.com>
	<624425480.47269863.1388300987173.JavaMail.root@redhat.com>
Message-ID: <1892413815.28466668.1388433079868.JavaMail.root@redhat.com>

The GWT architecture we use is based on GWTP, an MVP framework for GWT: https://github.com/ArcBees/GWTP

We don't currently have a widget hierarchy or catalog built.

If you're just starting out with GWT, it's a steep learning curve. If you're already familiar with GWT and GWTP, you'll be in better shape.

In addition to the UI Plugins that Oved mentioned, oVirt also has branding support for changing colors, logos, etc.: http://www.ovirt.org/Feature/Branding

If you're sure you want to do GWT development on oVirt, start here: http://www.ovirt.org/DebugFrontend

Greg

----- Original Message -----
> From: "Oved Ourfalli" <ovedo at redhat.com>
> To: "JustMan" <wang.tianyi at qq.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Sunday, December 29, 2013 2:09:47 AM
> Subject: Re: [Engine-devel] How to custom the UI for oVirt?
> 
> Hi
> 
> If you would like to customize the UI to fit your needs, like adding new
> tabs, new action buttons, and etc., then I recommend reading the wiki pages
> about UI plugins:
> Formal page: http://www.ovirt.org/Features/UIPlugins
> 
> Blog posts regarding that:
> http://ovedou.blogspot.co.il/
> http://developerblog.redhat.com/2013/12/19/advanced_integration_rhevm-part2/
> http://developerblog.redhat.com/2013/12/19/advanced_integration_rhevm-part1/
> http://developerblog.redhat.com/2013/12/12/advanced_integration_rhevm-part1/
> 
> As for the architecture information, there is an architecture page on
> http://www.ovirt.org/Architecture, but it doesn't have a lot on GWT.
> Vojtech/Einav - can you send some information on that, or better update the
> wiki page?
> 
> Thank you,
> Oved
> 
> ----- Original Message -----
> > From: "JustMan" <wang.tianyi at qq.com>
> > To: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Friday, December 27, 2013 11:29:02 AM
> > Subject: [Engine-devel] How to custom the UI for oVirt?
> > 
> > HI All?
> > 
> > If custom development the UI for oVirt, what's development technology must
> > be
> > learn, and where is the UI module in the resource? Where is the start step?
> > 
> > Where can find oVirt architecture document? I goto the office website,
> > already read some development document, but still very clear the
> > architecture of oVirt, special of the GWT part.
> > 
> > ike
> > 
> > Thanks
> > 
> > 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>


From dfediuck at redhat.com  Tue Dec 31 14:50:48 2013
From: dfediuck at redhat.com (Doron Fediuck)
Date: Tue, 31 Dec 2013 16:50:48 +0200
Subject: [Engine-devel] Broken devel setup on Gentoo?
Message-ID: <52C2D9C8.7090508@redhat.com>

While refreshing my devel environment, setup fails.
Log file shows this:

2013-12-31 16:26:05 DEBUG otopi.plugins.otopi.services.openrc
plugin.executeRaw:366 execute: ('/etc/init.d/ovirt-websocket-proxy',
'-q', 'status'), executable='None', cwd=
'None', env=None
2013-12-31 16:26:05 DEBUG otopi.plugins.otopi.services.openrc
plugin.executeRaw:389 execute-result:
('/etc/init.d/ovirt-websocket-proxy', '-q', 'status'), exception
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/otopi/plugin.py", line 376,
in executeRaw
    env=env,
  File "/usr/lib64/python2.7/subprocess.py", line 711, in __init__
    errread, errwrite)
  File "/usr/lib64/python2.7/subprocess.py", line 1308, in _execute_child
    raise child_exception
OSError: [Errno 2] No such file or directory

Should there be a redirection to use ovirt-websocket-proxy in a local
script rather than daemon?


From alonbl at redhat.com  Tue Dec 31 14:54:45 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Tue, 31 Dec 2013 09:54:45 -0500 (EST)
Subject: [Engine-devel] Broken devel setup on Gentoo?
In-Reply-To: <52C2D9C8.7090508@redhat.com>
References: <52C2D9C8.7090508@redhat.com>
Message-ID: <8964929.28517328.1388501685865.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Doron Fediuck" <dfediuck at redhat.com>
> To: engine-devel at ovirt.org
> Cc: "Alon Bar-Lev" <abarlev at redhat.com>
> Sent: Tuesday, December 31, 2013 4:50:48 PM
> Subject: [Engine-devel] Broken devel setup on Gentoo?
> 
> While refreshing my devel environment, setup fails.
> Log file shows this:
> 
> 2013-12-31 16:26:05 DEBUG otopi.plugins.otopi.services.openrc
> plugin.executeRaw:366 execute: ('/etc/init.d/ovirt-websocket-proxy',
> '-q', 'status'), executable='None', cwd=
> 'None', env=None
> 2013-12-31 16:26:05 DEBUG otopi.plugins.otopi.services.openrc
> plugin.executeRaw:389 execute-result:
> ('/etc/init.d/ovirt-websocket-proxy', '-q', 'status'), exception
> Traceback (most recent call last):
>   File "/usr/lib64/python2.7/site-packages/otopi/plugin.py", line 376,
> in executeRaw
>     env=env,
>   File "/usr/lib64/python2.7/subprocess.py", line 711, in __init__
>     errread, errwrite)
>   File "/usr/lib64/python2.7/subprocess.py", line 1308, in _execute_child
>     raise child_exception
> OSError: [Errno 2] No such file or directory
> 
> Should there be a redirection to use ovirt-websocket-proxy in a local
> script rather than daemon?

http://gerrit.ovirt.org/#/q/I40f061ec6cf658e1d8ec5c3663698ceca7569b38,n,z


From dfediuck at redhat.com  Tue Dec 31 15:20:24 2013
From: dfediuck at redhat.com (Doron Fediuck)
Date: Tue, 31 Dec 2013 17:20:24 +0200
Subject: [Engine-devel] Broken devel setup on Gentoo?
In-Reply-To: <8964929.28517328.1388501685865.JavaMail.root@redhat.com>
References: <52C2D9C8.7090508@redhat.com>
	<8964929.28517328.1388501685865.JavaMail.root@redhat.com>
Message-ID: <52C2E0B8.4070309@redhat.com>


On 12/31/2013 04:54 PM, Alon Bar-Lev wrote:
>
> ----- Original Message -----
>> From: "Doron Fediuck" <dfediuck at redhat.com>
>> To: engine-devel at ovirt.org
>> Cc: "Alon Bar-Lev" <abarlev at redhat.com>
>> Sent: Tuesday, December 31, 2013 4:50:48 PM
>> Subject: [Engine-devel] Broken devel setup on Gentoo?
>>
>> While refreshing my devel environment, setup fails.
>> Log file shows this:
>>
>> 2013-12-31 16:26:05 DEBUG otopi.plugins.otopi.services.openrc
>> plugin.executeRaw:366 execute: ('/etc/init.d/ovirt-websocket-proxy',
>> '-q', 'status'), executable='None', cwd=
>> 'None', env=None
>> 2013-12-31 16:26:05 DEBUG otopi.plugins.otopi.services.openrc
>> plugin.executeRaw:389 execute-result:
>> ('/etc/init.d/ovirt-websocket-proxy', '-q', 'status'), exception
>> Traceback (most recent call last):
>>   File "/usr/lib64/python2.7/site-packages/otopi/plugin.py", line 376,
>> in executeRaw
>>     env=env,
>>   File "/usr/lib64/python2.7/subprocess.py", line 711, in __init__
>>     errread, errwrite)
>>   File "/usr/lib64/python2.7/subprocess.py", line 1308, in _execute_child
>>     raise child_exception
>> OSError: [Errno 2] No such file or directory
>>
>> Should there be a redirection to use ovirt-websocket-proxy in a local
>> script rather than daemon?
> http://gerrit.ovirt.org/#/q/I40f061ec6cf658e1d8ec5c3663698ceca7569b38,n,z
Thanks.
I'm running on this branch (ovirt-3.3) and still hitting this issue.
I checked
packaging/setup/plugins/ovirt-engine-setup/config/websocket_proxy.py
and I can see the fix (now in line 258), but the issue is still there.


From alonbl at redhat.com  Tue Dec 31 15:28:24 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Tue, 31 Dec 2013 10:28:24 -0500 (EST)
Subject: [Engine-devel] Broken devel setup on Gentoo?
In-Reply-To: <52C2E0B8.4070309@redhat.com>
References: <52C2D9C8.7090508@redhat.com>
	<8964929.28517328.1388501685865.JavaMail.root@redhat.com>
	<52C2E0B8.4070309@redhat.com>
Message-ID: <9582066.28519242.1388503704694.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Doron Fediuck" <dfediuck at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Tuesday, December 31, 2013 5:20:24 PM
> Subject: Re: [Engine-devel] Broken devel setup on Gentoo?
> 
> 
> On 12/31/2013 04:54 PM, Alon Bar-Lev wrote:
> >
> > ----- Original Message -----
> >> From: "Doron Fediuck" <dfediuck at redhat.com>
> >> To: engine-devel at ovirt.org
> >> Cc: "Alon Bar-Lev" <abarlev at redhat.com>
> >> Sent: Tuesday, December 31, 2013 4:50:48 PM
> >> Subject: [Engine-devel] Broken devel setup on Gentoo?
> >>
> >> While refreshing my devel environment, setup fails.
> >> Log file shows this:
> >>
> >> 2013-12-31 16:26:05 DEBUG otopi.plugins.otopi.services.openrc
> >> plugin.executeRaw:366 execute: ('/etc/init.d/ovirt-websocket-proxy',
> >> '-q', 'status'), executable='None', cwd=
> >> 'None', env=None
> >> 2013-12-31 16:26:05 DEBUG otopi.plugins.otopi.services.openrc
> >> plugin.executeRaw:389 execute-result:
> >> ('/etc/init.d/ovirt-websocket-proxy', '-q', 'status'), exception
> >> Traceback (most recent call last):
> >>   File "/usr/lib64/python2.7/site-packages/otopi/plugin.py", line 376,
> >> in executeRaw
> >>     env=env,
> >>   File "/usr/lib64/python2.7/subprocess.py", line 711, in __init__
> >>     errread, errwrite)
> >>   File "/usr/lib64/python2.7/subprocess.py", line 1308, in _execute_child
> >>     raise child_exception
> >> OSError: [Errno 2] No such file or directory
> >>
> >> Should there be a redirection to use ovirt-websocket-proxy in a local
> >> script rather than daemon?
> > http://gerrit.ovirt.org/#/q/I40f061ec6cf658e1d8ec5c3663698ceca7569b38,n,z
> Thanks.
> I'm running on this branch (ovirt-3.3) and still hitting this issue.
> I checked
> packaging/setup/plugins/ovirt-engine-setup/config/websocket_proxy.py
> and I can see the fix (now in line 258), but the issue is still there.
> 

Please send setup log file.


From alonbl at redhat.com  Tue Dec 31 16:45:35 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Tue, 31 Dec 2013 11:45:35 -0500 (EST)
Subject: [Engine-devel] Broken devel setup on Gentoo?
In-Reply-To: <9582066.28519242.1388503704694.JavaMail.root@redhat.com>
References: <52C2D9C8.7090508@redhat.com>
	<8964929.28517328.1388501685865.JavaMail.root@redhat.com>
	<52C2E0B8.4070309@redhat.com>
	<9582066.28519242.1388503704694.JavaMail.root@redhat.com>
Message-ID: <271518451.28522345.1388508335524.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "Doron Fediuck" <dfediuck at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Tuesday, December 31, 2013 5:28:24 PM
> Subject: Re: [Engine-devel] Broken devel setup on Gentoo?
> 
> 
> 
> ----- Original Message -----
> > From: "Doron Fediuck" <dfediuck at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: engine-devel at ovirt.org
> > Sent: Tuesday, December 31, 2013 5:20:24 PM
> > Subject: Re: [Engine-devel] Broken devel setup on Gentoo?
> > 
> > 
> > On 12/31/2013 04:54 PM, Alon Bar-Lev wrote:
> > >
> > > ----- Original Message -----
> > >> From: "Doron Fediuck" <dfediuck at redhat.com>
> > >> To: engine-devel at ovirt.org
> > >> Cc: "Alon Bar-Lev" <abarlev at redhat.com>
> > >> Sent: Tuesday, December 31, 2013 4:50:48 PM
> > >> Subject: [Engine-devel] Broken devel setup on Gentoo?
> > >>
> > >> While refreshing my devel environment, setup fails.
> > >> Log file shows this:
> > >>
> > >> 2013-12-31 16:26:05 DEBUG otopi.plugins.otopi.services.openrc
> > >> plugin.executeRaw:366 execute: ('/etc/init.d/ovirt-websocket-proxy',
> > >> '-q', 'status'), executable='None', cwd=
> > >> 'None', env=None
> > >> 2013-12-31 16:26:05 DEBUG otopi.plugins.otopi.services.openrc
> > >> plugin.executeRaw:389 execute-result:
> > >> ('/etc/init.d/ovirt-websocket-proxy', '-q', 'status'), exception
> > >> Traceback (most recent call last):
> > >>   File "/usr/lib64/python2.7/site-packages/otopi/plugin.py", line 376,
> > >> in executeRaw
> > >>     env=env,
> > >>   File "/usr/lib64/python2.7/subprocess.py", line 711, in __init__
> > >>     errread, errwrite)
> > >>   File "/usr/lib64/python2.7/subprocess.py", line 1308, in
> > >>   _execute_child
> > >>     raise child_exception
> > >> OSError: [Errno 2] No such file or directory
> > >>
> > >> Should there be a redirection to use ovirt-websocket-proxy in a local
> > >> script rather than daemon?
> > > http://gerrit.ovirt.org/#/q/I40f061ec6cf658e1d8ec5c3663698ceca7569b38,n,z
> > Thanks.
> > I'm running on this branch (ovirt-3.3) and still hitting this issue.
> > I checked
> > packaging/setup/plugins/ovirt-engine-setup/config/websocket_proxy.py
> > and I can see the fix (now in line 258), but the issue is still there.
> > 
> 
> Please send setup log file.

Correct, the issue is that setup is trying to acquire service status before stopping.

Fix is available[1]

[1] http://gerrit.ovirt.org/#/q/I0454e3f136ad1181bc01c55411b33b1e2fc20e4c,n,z


From dfediuck at redhat.com  Tue Dec 31 17:17:40 2013
From: dfediuck at redhat.com (Doron Fediuck)
Date: Tue, 31 Dec 2013 19:17:40 +0200
Subject: [Engine-devel] Broken devel setup on Gentoo?
In-Reply-To: <271518451.28522345.1388508335524.JavaMail.root@redhat.com>
References: <52C2D9C8.7090508@redhat.com>	<8964929.28517328.1388501685865.JavaMail.root@redhat.com>	<52C2E0B8.4070309@redhat.com>	<9582066.28519242.1388503704694.JavaMail.root@redhat.com>
	<271518451.28522345.1388508335524.JavaMail.root@redhat.com>
Message-ID: <52C2FC34.50504@redhat.com>


On 12/31/2013 06:45 PM, Alon Bar-Lev wrote:
>
> ----- Original Message -----
>> From: "Alon Bar-Lev" <alonbl at redhat.com>
>> To: "Doron Fediuck" <dfediuck at redhat.com>
>> Cc: engine-devel at ovirt.org
>> Sent: Tuesday, December 31, 2013 5:28:24 PM
>> Subject: Re: [Engine-devel] Broken devel setup on Gentoo?
>>
>>
>>
>> ----- Original Message -----
>>> From: "Doron Fediuck" <dfediuck at redhat.com>
>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>>> Cc: engine-devel at ovirt.org
>>> Sent: Tuesday, December 31, 2013 5:20:24 PM
>>> Subject: Re: [Engine-devel] Broken devel setup on Gentoo?
>>>
>>>
>>> On 12/31/2013 04:54 PM, Alon Bar-Lev wrote:
>>>> ----- Original Message -----
>>>>> From: "Doron Fediuck" <dfediuck at redhat.com>
>>>>> To: engine-devel at ovirt.org
>>>>> Cc: "Alon Bar-Lev" <abarlev at redhat.com>
>>>>> Sent: Tuesday, December 31, 2013 4:50:48 PM
>>>>> Subject: [Engine-devel] Broken devel setup on Gentoo?
>>>>>
>>>>> While refreshing my devel environment, setup fails.
>>>>> Log file shows this:
>>>>>
>>>>> 2013-12-31 16:26:05 DEBUG otopi.plugins.otopi.services.openrc
>>>>> plugin.executeRaw:366 execute: ('/etc/init.d/ovirt-websocket-proxy',
>>>>> '-q', 'status'), executable='None', cwd=
>>>>> 'None', env=None
>>>>> 2013-12-31 16:26:05 DEBUG otopi.plugins.otopi.services.openrc
>>>>> plugin.executeRaw:389 execute-result:
>>>>> ('/etc/init.d/ovirt-websocket-proxy', '-q', 'status'), exception
>>>>> Traceback (most recent call last):
>>>>>   File "/usr/lib64/python2.7/site-packages/otopi/plugin.py", line 376,
>>>>> in executeRaw
>>>>>     env=env,
>>>>>   File "/usr/lib64/python2.7/subprocess.py", line 711, in __init__
>>>>>     errread, errwrite)
>>>>>   File "/usr/lib64/python2.7/subprocess.py", line 1308, in
>>>>>   _execute_child
>>>>>     raise child_exception
>>>>> OSError: [Errno 2] No such file or directory
>>>>>
>>>>> Should there be a redirection to use ovirt-websocket-proxy in a local
>>>>> script rather than daemon?
>>>> http://gerrit.ovirt.org/#/q/I40f061ec6cf658e1d8ec5c3663698ceca7569b38,n,z
>>> Thanks.
>>> I'm running on this branch (ovirt-3.3) and still hitting this issue.
>>> I checked
>>> packaging/setup/plugins/ovirt-engine-setup/config/websocket_proxy.py
>>> and I can see the fix (now in line 258), but the issue is still there.
>>>
>> Please send setup log file.
> Correct, the issue is that setup is trying to acquire service status before stopping.
>
> Fix is available[1]
>
> [1] http://gerrit.ovirt.org/#/q/I0454e3f136ad1181bc01c55411b33b1e2fc20e4c,n,z
>
Thanks for the quick fix, verified both for 3.3 and in master.

An unrelated issue I noticed when moving from 3.3 branch to master I
re-built everything,
yet I was unable to login. I had to update the DB with a new password to
login.
I suspect theres another issue here.


From alonbl at redhat.com  Tue Dec 31 18:10:46 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Tue, 31 Dec 2013 13:10:46 -0500 (EST)
Subject: [Engine-devel] Broken devel setup on Gentoo?
In-Reply-To: <52C2FC34.50504@redhat.com>
References: <52C2D9C8.7090508@redhat.com>
	<8964929.28517328.1388501685865.JavaMail.root@redhat.com>
	<52C2E0B8.4070309@redhat.com>
	<9582066.28519242.1388503704694.JavaMail.root@redhat.com>
	<271518451.28522345.1388508335524.JavaMail.root@redhat.com>
	<52C2FC34.50504@redhat.com>
Message-ID: <1708314940.28526523.1388513446173.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Doron Fediuck" <dfediuck at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Tuesday, December 31, 2013 7:17:40 PM
> Subject: Re: [Engine-devel] Broken devel setup on Gentoo?
>
> An unrelated issue I noticed when moving from 3.3 branch to master I
> re-built everything,
> yet I was unable to login. I had to update the DB with a new password to
> login.
> I suspect theres another issue here.
> 

I am unsure I follow, you cannot use the same prefix for both branches.
What the exact sequence?